ES2322627T3 - Aparato sensor para camion hormigonera. - Google Patents

Abstract

Un aparato (280) sensor para un tambor (287) mezclador de un camión (195) hormigonera, caracterizado por un sensor (280) para producir una señal que indica la velocidad y sentido del tambor mezclador del camión; comprendiendo también el aparato al menos un imán (292) montado alrededor del eje de rotación del tambor mezclador del camión, y sensores (288, 289) de campo magnético duales montados en relación enfrentada fija en el mismo, en el que los sensores detectan el imán cuando el imán pasa delante de los sensores, y un circuito (135) de lógica de estados que determina si el camión hormigonera está en un estado de carga, un estado de comenzar vertido o un estado de finalizar vertido basándose en la velocidad y sentido del tambor señalada por el sensor (280).

Description

Aparato sensor para camión hormigonera.

La invención dada a conocer en el presente documento se refiere, en general, a sistemas de gestión de activos y, más particularmente a un sistema para rastrear la ubicación y estatus en tiempo real de vehículos de una flota, y para la comunicación entre los vehículos y un expedidor o expedidor situado en las oficinas de la flota.

Los operadores de empresas de vehículos de flota necesitan conocer dónde está ubicado y qué está haciendo cada vehículo de la flota, para tomar decisiones sobre cómo usar los vehículos de la forma más eficaz. En los últimos años, se han desarrollado sistemas de localización de vehículos que usan información por satélite de Sistemas de Posicionamiento Global (GPS), y, para mayor precisión, sistemas de GPS diferencial (DGPS). Estos sistemas son muy precisos cuando existen condiciones de línea de visión (LOS), esto es, cuando el vehículo (o más precisamente, el receptor de GPS del vehículo) tiene una LOS clara con el número apropiado de satélites de GPS. Pero, normalmente, tales condiciones no están disponibles, o al menos están disponibles con menor frecuencia, para un vehículo que opera en las calles de una ciudad, particularmente en áreas en las que hay edificios de varios pisos, debido al apantallamiento que producen tales edificios. En esas circunstancias puede usarse un sistema de navegación alternativo, tal como navegación estimada (DR), para proporcionar datos de posición y vector velocidad del vehículo en zonas urbanas encajonadas (es decir, calles limitadas por edificios altos), donde las mediciones de GPS están disponibles sólo intermitentemente. O puede usarse una técnica de correspondencia de mapa o cuadrícula de navegación como otra alternativa o alternativa adicional.

En la actualidad, la comunicación de voz inalámbrica entre expedidores y conductores es el medio principal para tratar la necesidad del propietario u operador de la flota de conocer qué está haciendo cada vehículo, es decir, las operaciones del vehículo que tienen lugar en cualquier momento dado, y dónde está ubicado el vehículo cuando se produce una operación particular. En sectores industriales en los que los vehículos realizan una secuencia repetitiva de eventos con cada carga, tal como para operaciones de hormigón de mezcla preparada, se han empezado a usar recientemente "cuadros de estatus". Los cuadros de estatus requieren que el conductor presione un botón en cada fase de operación, tal como "cargar", "dejar la planta", "llegar al trabajo", "comenzar el vertido", etcétera.

El problema principal, ya sea con comunicación de voz inalámbrica o sistemas de cuadro de estatus, es que los datos se proporcionan manualmente al expedidor desde el conductor del vehículo. Esto conduce a datos inoportunos (tardíos) y, quizá peor, imprecisos más del noventa por ciento del tiempo, según análisis realizados por los propietarios/operadores de la flota. La disponibilidad de datos oportunos y precisos es esencial si el operador de la flota va a operar su empresa eficaz y económicamente.

Pueden usarse redes inalámbricas de acceso múltiple por división de tiempo (TDMA), que están en uso para muchas aplicaciones, incluyendo teléfonos celulares digitales y redes de área local inalámbrica, para la comunicación entre expedidores y conductores. Una red de TDMA permite, asignando ranuras de tiempo específicas a cada usuario para su uso exclusivamente para transmisión, múltiples usuarios de un único canal o frecuencia. Para un rendimiento óptimo de las redes de TDMA, se requiere una sincronización de tiempo precisa entre los miembros de la red. El uso eficaz del ancho de banda en la red requiere que se minimicen los tiempos de separación entre las transmisiones de cada usuario, que es tiempo perdido. Un componente importante para el tiempo de separación es la incertidumbre de tiempo en todos los participantes en la red. La sincronización de redes inalámbricas es, a menudo, muy basta, requiriendo grandes separaciones entre las transmisiones si no se usa hardware especializado. Además, la sincronización de elementos de red con una referencia precisa, como información de sincronismo basado en GPS, implica tener un receptor de GPS ubicado en cada elemento de red, tanto móvil como fijo, aumentando los costes y complejidad de la instalación tanto para dispositivos de red móvil como para infraestructura de red fija, especialmente si no se requieren los datos de navegación proporcionados por el GPS.

La sincronización de tiempo precisa entre todos los dispositivos inalámbricos en la red puede realizarse de diversas formas. Normalmente, una referencia de tiempo precisa y estable, tal como la basada en el Sistema de Posicionamiento Global (GPS) u otros servicios de distribución de tiempo, está ubicada dentro de cada dispositivo inalámbrico, o sólo dentro de la infraestructura fija de la red, con información de sincronización que se transmite a las unidades móviles. En estos casos, se aumentan los costes de dispositivo o infraestructura, porque el equipo de sincronismo tiene que distribuirse entre varias ubicaciones o dispositivos e instalarse donde el espacio y acceso para mantenimiento son limitados.

Transmitir tanta información como sea posible, en una cantidad dada de ancho de banda, es un objetivo de diseño importante en cualquier red de comunicaciones. Esto es especialmente cierto en redes inalámbricas en las que el ancho de banda disponible es muy limitado, y los requisitos del cliente para caudal de datos son inmensos. La operación, en la mayor parte de las bandas inalámbricas, está sujeta a restricciones de ancho de banda ocupado, requiriendo que la señal de datos esté contenida en una región muy estrecha del espectro electromagnético. En redes de TDMA, es un desafío minimizar los tiempos de separación entre las transmisiones y la sobrecarga asociada con cada paquete de datos, con objeto de enviar tantos datos portando información por la red tan continuamente como sea posible. La presente invención afronta estos dos requisitos con filtrado digital, para controlar el ancho de banda ocupado y la recuperación de datos por el sistema receptor, lo cual no requiere que se transmitan patrones de sincronización.

El documento EP 0, 901 017 A2 da a conocer un procedimiento para comprobar el asentamiento de una carga de hormigón de mezcla preparada, en el punto de reparto en un vehículo de reparto, del tipo que tiene un tambor giratorio en el que está contenida la carga de hormigón. Se proporcionan medios para detectar la masa de la carga de hormigón, y para usar una masa detectada para determinar el valor de asentamiento en el vehículo de reparto y/o en la
base.

El documento alemán dado a conocer DE 43 11 267 A1 da a conocer un localizador para monitorizar la velocidad angular y el sentido de rotación de un árbol motor accionado. El localizador comprende un patín magnetizado, que interactúa con sensores de campo magnético, proporcionados sobre una placa que se extiende en vertical con respecto al eje del árbol.

Sumario de la invención

El objetivo principal del sistema de gestión de flota de la presente invención (denominado a veces a continuación en el presente documento sistema PROTRAK o sistema Galileo (cada uno de PROTRAK y Galileo, o bien solo o con diversos sufijos anexos, es una marca registrada de Fleet Management Services, Inc. de Chandler, Arizona, al que se ha transferido la presente solicitud de patente), sistema de gestión de flota, o simplemente sistema) es proporcionar a los clientes información de gestión de flota (es decir, los propietarios, operadores, abonados, o usuarios de la flota que pretenden aprovechar ellos mismos las ventajas de un sistema de rastreo de vehículos, comunicación y gestión de flota) para permitirles gestionar sus activos con mayor rentabilidad. El sistema dota a sus clientes de varios medios para lograr esto. En primer lugar, el sistema PROTRAK da al operador de flota la capacidad de localizar los vehículos de la flota en tiempo real. En segundo lugar, el sistema permite al operador comunicarse con esos vehículos por una red inalámbrica muy eficaz y fiable - una red inalámbrica de acceso múltiple por división de tiempo (TDMA). En tercer lugar, el sistema permite al operador recibir datos oportunos y precisos respecto a qué está haciendo cada vehículo de la flota, es decir, qué operación/operaciones está(n) realizando en cualquier momento dado. En cuarto lugar, el sistema proporciona al operador capacidad para correlacionar la información de posición y mensajería generada por el sistema con los otros sistemas de información de gestión del operador, para proporcionar una fuente de información integrada para gestión de negocio de flota mejorada.

Con respecto al último, los sistemas de gestión existentes de un operador de flota están constituidos normalmente por contabilidad, recursos humanos, inventario, y otros sistemas que pueden no estar bien integrados. Además, el operador puede no tener una forma fiable de medir el rendimiento de vehículo y del conductor, lo cual es crítico para las operaciones del operador. El sistema PROTRAK proporciona la información de vehículo y conductor requerida, junto con un sistema de gestión de base de datos, que puede recopilar tal información e integrarla con datos recuperados de los otros sistemas de información del operador en una aplicación de gestión de base de datos. El operador puede usar esta aplicación para generar informes que están personalizados para su empresa y se basan en todos los datos disponibles.

El sistema PROTRAK está diseñado particularmente para operar en un nicho de mercado entre radio móvil especializada (SMR), celular, y servicios de radiomensajería. El sistema puede usarse para rastrear prácticamente cualquier número de vehículos de una flota por todas las áreas metropolitanas cubiertas por la red.

Pueden hacerse disponibles automáticamente para el operador de la flota datos oportunos y precisos, combinando tecnología de red de datos inalámbrica, un ordenador de datos inalámbrico (al que se hace referencia también en el presente documento como ordenador de rastreo, o simplemente rastreador), sensores, y ordenadores y software de información a la base de datos y/o de expedición en las instalaciones del operador de flota para recibir, visualizar y procesar los datos proporcionados por los vehículos. El ordenador de vehículo tiene interfaces a diversos sensores, que indican las operaciones que está realizando el vehículo. Los datos proporcionados por los sensores se procesan por algoritmos de software en el ordenador, para determinar cuándo se producen eventos de interés. El evento, los parámetros relevantes, y la hora del evento se transmiten entonces inmediatamente a través de la red inalámbrica al operador de flota.

La red usada para permitir, muy eficazmente, la información de estatus accionada por evento está diseñada para proporcionar paquetes de datos pequeños y frecuentes, de vehículos a propietarios de la flota. La arquitectura de red es un diseño de dúplex completo único para operaciones de área metropolitana. Los datos se transmiten a los vehículos por una subportadora en una estación de radio de FM. Los vehículos transmiten sus datos usando un protocolo de TDMA en un único canal de UHF. Los datos de vehículo se reciben por concentradores de red, que son receptores colocados en torres comerciales alrededor del área metropolitana de interés. Los datos recibidos se envían de vuelta a un centro de distribución de red (NDC, al que ocasionalmente se hace referencia en el presente documento como centro de control de red) a través de líneas de teléfono, y se retransmiten a los propietarios de la flota a través de Internet, conexión de teléfono, u otros medios preferentemente inalámbricos. Los datos que los propietarios envían a los vehículos se envían, en primer lugar, al NDC, que los envía al equipo de transmisión en la estación de radio a través de líneas de teléfono.

El protocolo de TDMA en la red se controla por servidores en el NDC. Un patrón de sincronización, contenido en la difusión de datos de subportadora que se recibe por los vehículos y los concentradores de red dentro del sistema PROTRAK, controla el sincronismo preciso requerido por la red de TDMA para una operación eficaz. Esto permite que todos los vehículos y concentradores tengan una referencia de tiempo común, que tiene una precisión de aproximadamente tres microsegundos. Esto, a su vez, permite cada segundo una multitud de informes de vehículo (por ejemplo, 50), en la red de TDMA. Los servidores asignan ranuras de tiempo e intervalos de información a los vehículos, de modo que pueden enviar datos y cambios de estatus automáticamente. Las actualizaciones periódicas típicas de datos de navegación u otra información no crítica se proporcionan en intervalos de dos a tres minutos; no es práctico para el ordenador de vehículo (rastreador) esperar un intervalo periódico de esa longitud para enviar datos de evento de tiempo crítico.

Un total de 50 ranuras de tiempo de 20 ms de longitud están disponibles para transmisiones periódicas. Múltiples vehículos comparten ranuras, dependiendo el número de la tasa de actualización de la ranura. Por ejemplo, 60 vehículos pueden compartir una ranura de intervalo de actualización de un minuto. Las ranuras no asignadas a actualizaciones periódicas están abiertas para que las use cualquier vehículo para solicitar acceso a la red. Si más de un vehículo intenta usar el mismo intervalo en una ranura particular, ambas pueden seguir escuchándose, si un sitio de recepción de concentrador separado escucha cada una. De otro modo, hay una colisión (interferencia) de datos, y los vehículos implicados deben reintentar sus solicitudes.

La invención se define en la reivindicación independiente 1.

Según un aspecto de la invención, se dan a conocer un procedimiento y aparato, para determinar automáticamente e informar de, eventos de un vehículo a un propietario o expedidor del vehículo en una ubicación remota. Los eventos que van a informarse son cambios en el estatus de operación del vehículo, ubicación, o mediciones de sistemas o carga del vehículo. Un ordenador (ordenador de rastreo, al que en general se hace referencia en el presente documento como rastreador) instalado en el vehículo está conectado a diversos sensores, que miden parámetros de interés para el expedidor o propietario, e informa, sobre la red inalámbrica de TDMA, de cambios críticos en parámetros. Unos ordenadores en una ubicación fija visualizan estos cambios de estatus, para que el expedidor los use, o registran los datos para su análisis posterior. El software en el rastreador del vehículo, junto con datos suministrados por lo que puede ser un pequeño número o una amplia variedad de sensores, permite que el rastreador determine e informe de eventos de estatus múltiples, complicados y abstractos que son relevantes para aplicaciones específicas de vehículo o del sector industrial. Los informes generados automáticamente desde los rastreadores proporcionan datos más precisos y oportunos a las oficinas de gestión de flota del cliente de los que están disponibles de los conductores de los vehículos.

El ordenador de rastreo tiene hardware y software de navegación para determinar la ubicación, velocidad y dirección de desplazamiento del vehículo en el que está instalado. El software de aplicación usado por los operadores para recibir datos de sus vehículos también les permite enviar órdenes de "expedición de sitio" a los rastreadores, lo que indica una región rectangular, que va a usarse para indicar dónde deberían tener lugar eventos tales como "cargar", o "descargar", por ejemplo. La información de ubicación se combina, entonces, con los datos de sensor en los algoritmos, para determinar la secuenciación de eventos, salvo en el caso de informe de excepción para indicar que el vehículo realizó una acción específica en una ubicación errónea, realizó paradas no autorizadas de camino a o de vuelta de un trabajo, u otros eventos específicos de una empresa o sector industrial particular.

En una realización ejemplar de este aspecto o característica de la invención, se combinan tres componentes básicos para permitir que los datos de vehículo sean útiles para el operador de flota, concretamente: (1) sensores en el vehículo, para medir parámetros que van a combinarse en un ordenador, para determinar automáticamente cuándo se producen eventos de interés, (2) una red inalámbrica, que permite una transmisión rápida y económica de paquetes de datos pequeños conteniendo estatus de evento, al operador de flota, y (3) aplicaciones de software, para almacenar y procesar adicionalmente información de eventos, para gestión de activos mejorada por el operador de flota.

El rastreador tiene varias entradas y salidas, para permitirle detectar y controlar numerosas funciones del vehículo simultáneamente, con interfaces configurables que incluyen interfaces serie, entradas analógicas, entradas discretas, salidas discretas y una interfaz para medir de impulsos o salidas de reloj. El rastreador también tiene interfaces dedicadas para medir tensión de batería, arranque, velocidad y marcha atrás. Éstos permiten la medición de una amplia variedad de funciones del vehículo, o bien directamente o a través de módulos de sensor auxiliares, que proporcionan datos a las interfaces serie del ordenador. Las salidas permiten el control de funciones del vehículo remotamente, a través de la red inalámbrica.

El software de rastreador permite el procesamiento y la integración de diversas entradas de sensor, para posibilitar que se determinen e informen eventos de estatus abstractos o de nivel superior. Por ejemplo, en un estatus de "cargando" para un camión hormigonera, se determina una carga a partir de un número de entradas combinando la ubicación del camión en la planta, camión estacionario y tambor del camión girando en el sentido de carga a una velocidad mayor que una velocidad mínima predeterminada durante un intervalo de tiempo mínimo. Ejemplos de otros eventos de estatus incluyen "luces de emergencia de ambulancia encendidas" o "tracción a las cuatro ruedas activa", que, como con otros eventos de estatus más simples, simplemente se detectan e informen.

El rastreador informa de eventos sobre la red inalámbrica cuya arquitectura y protocolos están personalizados para una información rápida de eventos, mientras soporta, de forma simultánea, intervalos de actualización periódicos y más lentos para menos datos críticos. Como se observó anteriormente, la red usa un protocolo de TDMA, para permitir que un gran número de vehículos envíen, en un único canal inalámbrico, paquetes de datos cortos de forma frecuente. Los datos se envían a los vehículos por una subportadora sobre un canal de difusión de FM. Un aspecto importante de la invención es la provisión de sincronización de tiempo precisa, requerida para el protocolo de TDMA sobre el enlace de FM a los vehículos y sitios de recepción. En la realización ejemplar, pueden informar de datos tantos como My vehículos por segundo, en una variedad de intervalos de actualización que varían entre cinco segundos y una hora.

Se proporcionan actualizaciones periódicas típicas de datos de navegación, y otra información no crítica, en intervalos de dos a tres minutos. Sin embargo, no es práctico para el rastreador esperar intervalos periódicos de esa longitud para enviar datos de evento de tiempo crítico. En consecuencia, para tales eventos, la red mantiene un número de ranuras de tiempo para acceso adicional a la red, en caso de solicitud de cualquier vehículo que necesite transmitir datos de evento. Entonces, se conceden al vehículo solicitante tiempos de información auxiliar suficientes, en intervalos de doce segundos, para que envíe sus datos. La latencia total, entre un evento que está detectándose y la transmisión de datos, se mantiene inferior a treinta segundos.

Se dota, a los propietarios y expedidores de vehículos de flota, de aplicaciones informáticas de software, que permiten la conexión de sus PC de sobremesa a la red de TDMA usando Internet u otros medios. Los datos facilitados desde los vehículos se encaminan a estas aplicaciones por los servidores de red, y también se almacenan en una base de datos local. Una de estas aplicaciones de software permite ver las ubicaciones del vehículo como iconos en un mapa visualizado en un monitor, mostrando cambios de evento para cada vehículo en el mapa en tiempo real, a medida que se producen, y también permite al expedidor enviar mensajes, o ubicaciones de expedición, a los vehículos. Pueden proporcionarse eventos automáticos, así como otras aplicaciones de gestión de vehículos o expedición, según se requiera. Ventajosamente, estas aplicaciones integran datos de evento de vehículo con otros sistemas utilizados en la empresa del operador de flota, tal como gestión de llamada y entrada de orden. Los informes de eventos de vehículo pueden generarse desde estas aplicaciones por Internet, a partir de datos almacenados en la base de datos de red.

Según otro de sus aspectos, la presente invención minimiza el coste de infraestructura para referencias de tiempo en la red inalámbrica de TDMA, y localiza la referencia de tiempo en una instalación de control de red central que se mantiene y monitoriza fácilmente. La referencia de tiempo usa tiempo de referencia de GPS, y un lazo de seguimiento de fase (PLL) inalámbrico mantiene en sincronización con la referencia de GPS el tiempo de red de TDMA, eliminando el requisito de localizar la referencia de tiempo dentro de los elementos de infraestructura o los dispositivos de transceptor inalámbricos. Este aspecto de la invención permite una sincronización de tiempo precisa de todos los elementos inalámbricos de red, usando hardware de sincronismo especial, y distribuyendo una única referencia de tiempo basada en GPS remota por toda la red, usando un PLL inalámbrico. Los datos digitales se sincronizan remotamente en la red de TDMA, un sistema dúplex completo diseñado para transmitir, eficazmente, ráfagas cortas de datos, de los vehículos móviles a su propietario, de forma frecuente. Los vehículos transmiten datos, usando un protocolo de TDMA en la banda de frecuencia UHF, en ranuras de tiempo controladas de forma precisa a una tasa de transmisión de 50 vehículos por segundo. Los vehículos envían datos de mensaje, ubicación y estatus a los propietarios de la flota o expedidores, que están conectados a la red inalámbrica a través de Internet u otros medios. Los datos transmitidos a los vehículos se difunden sobre una subportadora de una estación de radio de FM, incluyendo también información de control y sincronismo de red y mensajes e información de los operadores de flota.

El sincronismo de la parte de TDMA de la red se controla desde una instalación de control de red central, que alberga los servidores que controlan el acceso del vehículo a la red y gestionan las conexiones del propietario de la flota a la red. La sincronización de los dispositivos del vehículo y los sistemas de receptor de concentrador fijo que reciben datos de vehículo, se mantiene a través de información de sincronización contenida en la difusión de subportadora de FM. Se hace referencia a los datos de sincronismo de subportadora de FM, a su vez, como fuente de tiempo basada en GPS en el centro de control de red.

Un ordenador de control de subportadora (SCC), responsable de proporcionar los datos al modulador de subportadora, está ubicado en el transmisor de la estación de radio de FM o instalaciones del taller. Éste temporiza los datos de transmisión en intervalos precisos, basándose en órdenes de sincronismo desde un ordenador de control de sincronismo de red (NTCC), ubicado en el centro de control de red. El NTCC y SCC están conectados a través de un módem, para las órdenes de control de sincronismo y datos enviados al SCC. El NTCC calcula las órdenes de sincronismo, basándose en la información de sincronización desde una referencia de tiempo del receptor de GPS y la de un receptor de subportadora de FM, que recibe datos del SCC. El NTCC procesa la diferencia en tiempo de la referencia de tiempo de GPS y los datos de sincronización recibidos por la subportadora de FM, usando un algoritmo de PLL para generar una corrección de sincronismo que se envía al SCC.

Este lazo de control de sincronismo inalámbrico de PLL permite a una referencia de tiempo única y remotamente ubicada sincronizar la red de TDMA. Además, la realimentación inherente en el lazo de control permite al sistema compensar las variaciones en el retardo de grupo de estación de radio de FM, de modo que los datos de sincronización de difusión pueden aplicarse en la antena de FM. Esto es importante para grandes redes que se basan en esta tecnología, que requieren múltiples estaciones de FM para cubrir áreas geográficas que se solapan, porque permite que las estaciones de FM se sincronicen.

La invención también se refiere a optimizaciones de ancho de banda para la transmisión de datos por redes de datos de TDMA inalámbricas. La invención minimiza el ancho de banda ocupado en un canal inalámbrico, filtrando digitalmente los datos que van a transmitirse antes de la modulación. El filtro se implementa en un microcontrolador de bajo coste, que reemplaza cada flanco en un flujo de datos de onda cuadrada digital, con transiciones que tienen la forma de ondas sinusoidales crecientes o decrecientes. Esto tiene las ventajas de reducir armónicos superiores en la señal de datos, especialmente a la tasa de transmisión de datos más alta, donde la onda cuadrada se reemplaza efectivamente por una onda sinusoidal. Otro aspecto de la invención maximiza la eficacia de la red de TDMA, haciendo que se abstenga de enviar cualquier información de sincronización de bits especial además de los datos. En la mayoría de los sistemas, un gran número de bits se dedica a sincronización, entramado o recuperación de reloj de datos. En un aspecto de la presente invención, la sincronización de datos y reloj de bits se realizan por el receptor usando algoritmos de corrección de errores sin canal de retorno, entrelazado de bits especial y hardware y software de procesamiento de señal digital de alto rendimiento. Aún otro aspecto de la invención usa diversidad de espacio, que combina entre múltiples sitios de recepción, para mejorar la fiabilidad de datos de recepción. Una recepción de datos más fiable ahorra ancho de banda, reduciendo el número de reintentos requerido para mover datos a través de la red.

Breve descripción de los dibujos

Los anteriores y otros fines, objetos, características, aspectos y ventajas acompañantes de la invención se harán evidentes a partir de la siguiente descripción detallada, del mejor modo contemplado actualmente para poner en práctica la invención, con referencia a procedimientos y realizaciones ejemplares preferidos actualmente de la misma, en conjunción con los dibujos adjuntos, en los que:

la figura 1 es un diagrama de bloques simplificado del sistema PROTRAK global, incluyendo la red de TDMA, de la invención;

la figura 2 es un diagrama de bloques de la arquitectura del sistema para interfaces de aplicación de cliente;

la figura 3 es un diagrama esquemático detallado de los componentes de la red inalámbrica y las interfaces de cliente;

la figura 4 ilustra detalles del NDC en la red de la figura 3;

la figura 5 es una línea de tiempos de flujo de datos en la red;

la figura 6 es un diagrama de bloques del lazo de realimentación de mensajes base para el sincronismo de sincronización de bits;

la figura 7 es un diagrama del formato de difusión de mensajes base;

la figura 8 es un diagrama de una trama de transmisión de mensajes de módulo de rastreador ejemplar;

la figura 9 es un diagrama que ilustra la relación del intervalo de repetición con ranuras, tramas y ciclos de trama para paquetes de mensaje de rastreador;

la figura 10 ilustra la relación entre rastreadores, ranuras e intervalos de repetición;

la figura 11 es un diagrama de una cuadrícula de navegación nominal usada en el sistema de la invención;

la figura 12 es un diagrama de un lazo de seguimiento de fase (PLL) de control de sincronismo, según un aspecto de la invención, para la red de TDMA de la figura 1;

la figura 13 es un diagrama de sincronismo de la secuencia de impulsos de sincronización, transmitida por el SCC en la subportadora de FM al comienzo de los datos de cada segundo, para el lazo de control de la figura 12;

las figuras 14A-D son diagramas de flujo del procesamiento de lazo de control de sincronismo, realizado en modos operativos de la sincronización del software de NTCC de la red de TDMA con el tiempo de GPS;

la figura 15 es un diagrama de bloques (matemático) del lazo de control de sincronismo;

la figura 16 es un diagrama de bloques del procesamiento de datos del TDMA de transmisión, realizado por el ordenador de rastreo (rastreador) instalado en un vehículo de flota;

la figura 17 es un tabla que ilustra el patrón de entrelazado de datos de transmisión de TDMA;

las figuras 18A-C son diagramas que comparan una secuencia datos de TDMA original con la versión codificada en retardo de esa secuencia, y que ilustran también un filtrado premodulación de la secuencia codificada en retardo;

la figura 19 es un diagrama de flujo del algoritmo de filtrado, realizado por un microcontrolador especialmente seleccionado que implementa un filtrado premodulación, para el resultado mostrado en la figura 18C;

la figura 20 es un diagrama que representa una comparación de los espectros de potencia relativa aproximada de los datos no codificados, codificados en retardo y filtrados, de las figuras 18A-C;

la figura 21 es un diagrama de bloques que ilustra el procesamiento de datos de TDMA de recepción, realizado por el receptor de concentrador de red;

la figura 22 es un diagrama de flujo del algoritmo de diversidad de espacio usado por el servidor de NDC para combinar los datos de vehículo recibidos por los concentradores de red;

la figura 23 ilustra una colocación ejemplar del rastreador, un terminal de datos móvil (MDT) y antenas, en un vehículo de flota típico, estando equipado además el vehículo para alojar diversos sensores para información de eventos;

la figura 24 es un diagrama de bloques simplificado de un rastreador instalado en un vehículo de la figura 23;

la figura 25 es un diagrama de bloques de la distribución de potencia interna del rastreador,

la figura 26 es un diagrama de bloques del resumen de distribución de potencia del rastreador;

la figura 27 es un diagrama de la lógica de transición de estados de modo de potencia del rastreador;

la figura 28 es un diagrama de sincronismo de sincronización y temporización de datos para el rastreador y los concentradores de red;

la figura 29 es un diagrama de sincronismo de las transmisiones de datos de rastreador;

la figura 30 es un diagrama de bloques simplificado de un concentrador de red;

la figura 31 es un diagrama de bloques simplificado de un ordenador de control de subportadora (SCC);

la figura 32 es un diagrama del flujo de datos de NTCC/SCC;

la figura 33 es un diagrama que ilustra diversos sensores, entradas, salidas e interfaces al rastreador de la figura 24;

la figura 34 es un zona rectangular ejemplar en un mapa almacenado, usado para determinar y visualizar la ubicación del rastreador (en particular, la del vehículo en la que está montado el rastreador);

la figura 35 es un diagrama de bloques simplificado de un sensor de rotación del tambor, usado para un camión hormigonera;

la figura 36 es un diagrama de sincronismo de los impulsos que resultan de la interacción de sensor e imanes en la rotación del tambor, para la realización del sensor de la figura 35;

la figura 37 es un diagrama de transición de estados, que define la lógica usada por el rastreador para combinar datos de sensor y navegación, para obtener automáticamente el estatus de un camión hormigonera; y

la figura 38 es un diagrama de flujo de un algoritmo de diversidad preferido, usado por el rastreador para recuperar datos dañados.

Descripción detallada de procedimientos y realizaciones ejemplares I. El sistema PROTRAK global

En primer lugar, es deseable proporcionar una visión general del sistema de rastreo de vehículos, comunicación y gestión de flota PROTRAK global, un diagrama de bloques simplificado del cual se muestra en la figura 1. En el apéndice A se expone, además de definiciones de acrónimos y otros términos abreviados presentados en el presente documento, un glosario de términos abreviados, usado por toda esta memoria descriptiva. El "cerebro" del sistema es el centro 10 de distribución de red (NDC) que es responsable de interconectar con flotas de abonado (al que se hace también referencia de forma diversa en el presente documento como cliente, propietario, operador, abonado de flota o usuario) a través de un módem en una línea de red de teléfono pública conmutada (PSTN) o Internet u otra red de área amplia, e interconectar con vehículos de flota a través de una multitud de concentradores de red (a los que a veces se hace referencia en el presente documento como concentradores de red, o simplemente, concentradores) tal como 11-1, 11-2,...11-i, y una o más estaciones de radio de FM tales como 12.

La información que va a pasarse a los vehículos en una o más flotas de interés se genera por un terminal de oficina de expedición de flota o estación de orden de cliente (CCS) tales como 14 para el cliente A, 15 para el cliente B,... y 16 para el cliente i, para el reparto a los vehículos tales como 17-1, 17-2,... 17-n para el cliente A (etcétera para los clientes B,... i). La información se envía inicialmente desde los CCS respectivos a través de módem sobre la PSTN (por ejemplo, líneas 19, 20, 21) o a través de Internet u otros medios al NDC 10. El NDC prioriza la información y la envía a través de un módem sobre la PSTN (por ejemplo, línea 22) o por otros tales medios, a la estación 12 de radio de FM, desde la que se difunde la información, por ejemplo, en una subportadora de FM de 67 KHz o 92 KHz. La información se difunde con sincronismo preciso definido por información de navegación por satélite GPS.

Todos los vehículos en la red reciben la difusión de subportadora de FM modulada por desplazamiento en frecuencia binaria (BFSK) de aproximadamente 4.664 bits por segundo (bps) de la estación de radio de FM (y otras, si es aplicable) y descodifican la información contenida en la misma. A cada vehículo se asigna una ranura de tiempo para difundir su ubicación y respuestas a las solicitudes de CCS. Las ranuras asignadas son únicas, para excluir la difusión simultánea por dos o más vehículos, y el sincronismo de difusión está controlado de forma precisa, a través de sincronización de subportadora de FM y GPS.

Cuando llega el tiempo de difundir de un vehículo, éste envía un mensaje de 144 bits a una tasa de transmisión de 7.812,5 bits por segundo. Esta información se recibe por al menos uno de los concentradores 11-1,..., 11-i de red, que demodula el mensaje y proporciona datos a partir del mismo a través de un módem al NDC 10 sobre la PSTN (por ejemplo, a través de líneas 24, 25, 26). El NDC 10 analiza sintácticamente todos los datos recibidos y proporciona la información de estatus y ubicación del vehículo para cada abonado de flota específico a su CCS respectivo sobre la PSTN.

El rastreo en tiempo real de la ubicación y estatus del vehículo puede realizarse por el sistema PROTRAK tan a menudo como una vez cada cinco segundos, por ejemplo, pero más generalmente se actualiza a una tasa de una vez cada tres minutos. Las ubicaciones del vehículo se rastrean con una precisión de aproximadamente 5 metros, a través del uso de información de DGPS proporcionada por la difusión de subportadora de FM. Cuando el GPS no está disponible intermitentemente, debido a enmascaramiento de señal cuando los vehículos están ubicados en calles de ciudad limitadas por edificios altos o debido a otras obstrucciones, el sistema emplea correspondencia de mapa, navegación estimada (DR) y/u otras técnicas de navegación, para detectar la ubicación del vehículo.

El sistema inalámbrico proporciona un medio versátil, para enviar mensajes breves que están constituidos por paquetes de información cortos, a o desde un instrumento u otro dispositivo de comunicaciones inalámbricas, montado en el vehículo. Aunque el sistema está destinado a la gestión de activos de empresa, el servicio inalámbrico soporta una amplia gama de necesidades de comunicación de paquetes para activos fijos así como móviles. No se requiere el uso de GPS en el dispositivo de receptor, debido a la sincronización de GPS de las difusiones de subportadora de FM.

La capacidad del sistema es suficiente para albergar, al menos, 5.000 vehículos individuales, que están rastreándose en la red en cualquier momento, con el ancho de banda proporcionado por una única subportadora de estación de radio de FM a 67 KHz o 92 KHz, para comunicaciones salientes, y una única frecuencia de ancho de banda de 12,5 KHz de servicios de comunicación personal (PCS) de banda estrecha o de UHF, para mensajes de vehículos entrantes. Puede proporcionarse una ampliación del sistema, por ejemplo, en bloques de 5.000 vehículos, añadiendo otra subportadora de estación de radio de FM y otra frecuencia de PCS de banda estrecha o UHF. Cuando es factible, se aplican principios de reutilización de frecuencia en frecuencias de PCS de banda estrecha o UHF, antes de que se añada otra frecuencia entrante, para maximizar la capacidad del canal.

Las comunicaciones en el sistema PROTRAK proporcionan una mayor fiabilidad que la radio móvil especializada (SMR) o celular, y posiblemente que los sistemas de radiomensajería, con recepción de mensajes fiable anticipada por vehículos y expedidores, de un 97% a la primera. Si no se recibe información a la primera, el sistema puede realizar esa determinación y reintentará la transmisión hasta que tenga éxito, o hasta que se averigüe que no puede hacerse el reparto. A pesar de las condiciones adversas, tales como cortes de potencia, al menos algunos operadores de flota (por ejemplo, servicios de ambulancia) requieren una operación fiable. El sistema global tiene respaldos internos para evitar fallos de punto único.

Se permite a los vehículos del abonado de flota "itinerar" desde una red del sistema a otra, tal como cuando un vehículo está en tránsito desde un área metropolitana a otra. El sistema permite al vehículo salir fácilmente de la primera red de ciudad y entrar de forma similar en la segunda red de ciudad cuando está en el alcance de la segunda ciudad.

Los componentes del sistema están diseñados para soportar una amplia gama de abonados de flota. Los rastreadores de vehículo (es decir, los módulos de rastreador a bordo) pueden albergar un número de funciones periféricas, tales como recopilación de datos analógica, digital, de interfaz serie y de velocidad superior requeridas por algunos abonados. Los concentradores de red pueden soportar diversas configuraciones de la antena y el receptor para mejorar la cobertura, y diversas configuraciones de potencia para soportar la operación de sitio remoto. La no disponibilidad de líneas de teléfono no supone un problema, puesto que se usan medios inalámbricos para la interconexión indirecta o directa al NDC.

\vskip1.000000\baselineskip

II. La aplicación de gestión de datos de flota

La arquitectura del sistema PROTRAK y las aplicaciones de gestión de base de datos que interactúan con los sistemas de información existentes de cada abonado (cliente) incluyen el NDC y los CCS que se usan para proporcionar capacidad de mensajes y ubicación en tiempo real del vehículo para expedidores. El lado de cliente del sistema PROTRAK está constituido por tres aplicaciones, incluyendo (1) un servidor de CCS y gestión de base de datos (DMCS) que vincula la información de red y cliente, (2) los CCS con sus servicios de ubicación en tiempo real y mensajería, y (3) generación de informes que permite a los clientes acceder a y manipular los datos gestionados por el DMCS.

En la figura 2 se muestra un diagrama de bloques de la arquitectura del sistema con respecto a las interfaces de aplicación de cliente. El NDC 10 ejecuta dos aplicaciones de servidor, concretamente, un servidor 32 NDC que proporciona información en tiempo real a clientes conectados, y un servidor 33 de registro de datos de rastreo, que recopila información de rastreo del sistema en tiempo real y la almacena en una base de datos de gran capacidad, con capacidad adicional para responder a consultas de datos de rastreo de histórico. El cliente establece una única conexión (34, 35) TCP/IP convencional con cada uno de estos servidores a través de una única línea conmutada directamente al NDC o a través de Internet (a través de un proveedor de servicios de Internet o ISP).

El DMCS 27, que puede estar ubicado en la instalación 28 del cliente remota al NDC 10, controla las conexiones al NDC. Todos los datos en tiempo real disponibles para todos los vehículos del cliente se proporcionan a esta aplicación de DMCS. El DMCS 27 almacena estos datos y los pasa a las aplicaciones 30 de CCS en formato filtrado, de modo que los operadores del CCS pueden observar (por ejemplo, como iconos en un monitor o pantalla en sus estaciones respectivas) y comunicarse sólo con esos vehículos de los que son responsables.

Otra función del DMCS 27 es proporcionar interfaces a otras aplicaciones de gestión de un cliente tales como contabilidad 31, recursos 32 humanos, control 33 de inventario y sistemas 34 de expedición asistido por ordenador. Una aplicación 36 de informe a la base de datos accede a los datos y genera los informes. La interfaz entre el DMCS 27 y el CCS 30 y las aplicaciones 36 de informe a la base de datos es TCP/IP convencional. Estas aplicaciones pueden ejecutarse en los mismos ordenadores u ordenadores separados usando, por ejemplo, Windows (marca registrada de Microsoft Corporation) 95, Windows 98 o Windows NT (o cualquier antelación de tal software, o cualquier software de otros proveedores que permita realizar las mismas funciones o funciones similares). Las otras aplicaciones del operador se interconectan con el DMCS 27 a través de protocolos de interfaz estándar o personalizados.

La aplicación de DMCS es responsable de vincular las aplicaciones de servidor de NDC, las aplicaciones de informe a la base de datos y CSS, y las aplicaciones existentes del operador (por ejemplo, los sistemas de información de gestión del cliente y de back office) en un sistema integrado. El DMCS actúa como la conexión de empresa al NDC 10. Éste establece conexiones de socket de TCP/IP al NDC en tiempo real y servidores 32 y 33 de registro de datos según se requiera, y mantiene el acceso a los datos para todos los vehículos del operador de la flota que va a rastrear el sistema PROTRAK. El NDC 10 proporciona los datos de mensaje y ubicación del vehículo, y el DMCS 27 envía mensajes y órdenes en tiempo real a los vehículos y puede solicitar información de rastreo archivada del NDC para periodos de tiempo en los que el DMCS no había iniciado sesión en el NDC.

El CCS (o cada uno de múltiples CCS) 30 es principalmente una herramienta de mensajería y visualización de ubicación del vehículo en tiempo real para soportar funciones de expedición. El DMCS 27 encamina órdenes y mensajes del CCS 30 al NDC 10, y proporciona datos de rastreo del NDC al CCS sólo para los vehículos que está controlando el operador del CCS (es decir, expedición, monitorización, planificación, etc.). El DMCS soporta múltiples aplicaciones de CCS que operan simultáneamente, controlando y viendo diferentes grupos de vehículos de una flota global.

El DMCS 27 soporta también consultas de base de datos de múltiples CCS 30 y aplicaciones 36 de informe a la base de datos. Cada CCS 30 requiere información en tiempo real de la base de datos respecto a conductores, de expedición, planificación y carga de vehículos. La aplicación de informe a la base de datos requiere datos de rastreo de histórico e información de otros sistemas, según sea necesario, para producir informes relativos a la empresa del cliente.

III. El centro de distribución de red

La arquitectura del NDC 10 se describirá brevemente con referencia al sistema de software y hardware de NDC ejemplar en el diagrama de bloques simplificado de la figura 3, que resalta los protocolos de comunicación usados por las aplicaciones de software de NDC. Como se observó anteriormente, el NDC 10 controla el flujo de información entre vehículos (por ejemplo, 17) y su estación de orden de abonado de flota (por ejemplo, los CCS 14 y 15 en el sitio 13 de cliente) que han iniciado sesión en el sistema. El NDC gestiona la red de RF controlando el sincronismo de red, y determinando la naturaleza de los datos transmitidos a los vehículos. Todos los datos recibidos por los concentradores de red (por ejemplo, 11-1, 11-2) se recopilan por el NDC 10 para su procesamiento, distribución a clientes y archivado de datos, y el NDC permite a los clientes iniciar sesión a través de Internet, la red de TCP/IP, u otra conexión 40 adecuada. Una interfaz a un centro de datos PROTRAK (PDC, no mostrado) soporta la itinerancia entre ciudades y la identificación del rastreador-abonado de flota global.

Un servidor 42 de NDC en el NDC 10 se comunica con los CCS 14, 15, etc., así como con las estaciones de orden de NDC (no mostradas) dentro del NDC y los concentradores 11-1,... 11-i de red, a través de sockets respectivos y conexiones de red relacionadas, incluyendo un encaminador y un módem, y también con un ordenador de sincronismo de red y control (NTCC) 47, a través de una interfaz 49 serie. El servidor de NDC tiene sólo una interfaz - un protocolo de mensajería que se describirá a continuación. Los administradores de NDC usan estaciones de orden de NDC (que son similares a los CCS, pero dentro del NDC) para la visualización, control, análisis y mantenimiento del servidor de NDC. Se asigna al servidor 42 de NDC un nombre de dominio registrado y una dirección de IP de Internet, para permitir a los abonados de flota y/o estaciones de orden de NDC conectarse con el servidor a través de Internet en lugar de usar un banco de módems de sistema. A modo de ejemplo ilustrativo y no de limitación, se muestran, en el diagrama de bloques de hardware de NDC de la figura 4, tres opciones de conectividad diferentes.

Como se observó anteriormente, el DMCS 27 interconecta con las aplicaciones 31, etc. de empresa críticas del cliente, incluyendo contabilidad, control de inventario, recursos humanos, etc., así como con los CCS 14, 15, etc., y el NDC 10. El servidor 42 de NDC controla todos los datos enviados a y recibidos desde vehículos y estaciones de orden, y también controla la configuración de la red de radio de UHF de transmisión de vehículo de TDMA asignando vehículos a ranuras de tiempo específicas para su transmisión y controlando a qué vehículos se les permite operar. Los datos desde los vehículos 17 recibidos desde los concentradores 11-1, etc. de red se combinan y descodifican, y entonces se proporcionan a los CCS de abonado de flota, para su uso en mantener el control de la red de radio. Los datos de los CCS se envían a los vehículos según se requiera, y también se usan para planificar el nivel apropiado de servicio de actualización, transmitiéndose los datos a los vehículos sobre una interfaz serie a cada ordenador NTCC en el NDC.

La función de control de red es la tarea más crítica del servidor 42 de NDC, realizada en tiempo real basándose en indicaciones del NTCC 47. Los requisitos de sistema para soporte de TCP/IP, Internet, y estaciones de trabajo de mantenimiento y soporte sustanciales requieren el uso de una plataforma tal como Windows NT, que permite al sistema hacer uso de hardware y software de terceros. La ejecución de esta tarea periódicamente, una vez por segundo, se logra, en primer lugar, dotando a la función de control de red de suficiente prioridad para completar sus tareas requeridas dentro del periodo permitido de un segundo; y, en segundo lugar, sondeando la interfaz serie de NTCC a una alta tasa para detectar la recepción de datos de sincronismo que indica que el servidor debería iniciar la tarea de control de red.

El NTCC 47 controla la parte en tiempo real del sistema PROTRAK, incluyendo el SCC 48 que transmite el sincronismo a través de un lazo de realimentación (que va a explicarse a continuación en conexión con la figura 6), usando un receptor de FM en un módulo de techo. Existe un módulo 55 de techo de NTCC (figura 4) para cada estación 12 de radio de FM soportada por el NDC 10. El NTCC 47 es responsable, también, de introducir los datos de ID de trama y los datos de corrección diferencial en el flujo de datos transmitido. Los paquetes de datos generados por el servidor 42 se envían al NTCC 47, para su inclusión en el flujo de datos de salida. Haciendo que el NTCC 47 se comunique con el SCC 48 a través de un módem 51 dedicado y una línea de teléfono u otra línea, que no es parte del armario de módems usado para los concentradores de red y los CCS, se separa la interfaz de tiempo crítico para el sincronismo y correcciones de cualquier actividad impredecible de la interfaz de ethernet o del armario de módems.

El NTCC 47 monitoriza la difusión de la estación 12 de FM para sincronismo y contenido. Si la difusión se recibió desplazada con respecto al segundo entero de GPS, entonces las órdenes de corrección de sincronismo se envían al SCC 48. El NTCC también compara los datos de difusión recibidos con el bloque de datos que se transmitió, para garantizar que los datos eran correctos. La intensidad de señal recibida de FM se monitoriza también, para detectar cambios en la potencia de difusión de FM. El estatus de SCC y la difusión se proporcionan al servidor 42 de modo que éste puede determinar qué acción tomar en caso de fallo.

Un número de estaciones de trabajo de Windows NT constituyen las estaciones de orden de NDC (por ejemplo, 43, 45, figura 4), que están conectadas a un servidor 42 de NDC a través de ethernet de 100 Mbps u otra trayectoria adecuada, tal como una red de área local (LAN). Estas estaciones proporcionan la capacidad para realizar varias funciones, incluyendo visualizaciones de diferentes áreas de la cuadrícula de navegación, monitorización de red y módem, análisis de registro de datos, mantenimiento de cuenta de usuario y desarrollo de software.

El servidor 42 de NDC puede comunicarse con los concentradores de red y los CCS a través de un TCP/IP, o por medio de otras opciones de conectividad tales como las mostradas en la figura 4. Un armario de módems Total Control de US Robotics, por ejemplo, puede usarse para proporcionar conectividad de TCP/IP al servidor. Cada armario se implementa para soportar 48 módems a través de 2 líneas de T1 convencionales, y varios armarios pueden apilarse para soportar un mayor número de módems. El servidor puede, por ejemplo, tener dos redes de ethernet independientes, y el armario de módems está en una red separada de las estaciones de orden de NDC de modo que la actividad de red de estación de orden de NDC no introducirá ninguna latencia en los datos de módem. Las conexiones de usuario no tienen ningún requisito en tiempo real, pero los datos transferidos entre el servidor 42 y los concentradores de red (por ejemplo, 41-1,..., 41- I) deben producirse regularmente, en intervalos de un segundo.

En la figura 5 se muestra una línea de tiempos del flujo de datos de la red. Los datos transmitidos por los vehículos en la trama 1 están disponibles para el servidor 42 de NDC (figura 3) al comienzo de la trama 3. Al detectar el inicio del estatus de trama desde el NTCC 47, se procesan los datos y los datos de usuario recibidos durante la trama 2. Los paquetes de datos que van a transmitirse a los vehículos también se envían al NTCC. En la última parte de la trama 3, el NTCC formula un bloque de datos que se envía al SCC 48 durante la trama 4. El SCC finalmente difunde el bloque de datos en la trama 5.

La función de control de red comprende gestión de red de radio, procesamiento de datos de entrada de vehículo y usuario, y procesamiento de datos de salida base. Basándose en la línea de tiempos mostrada en la figura 5, estas tareas combinadas deben comenzar inmediatamente tras la detección del inicio de una trama (basándose en datos serie recibidos del NTCC), y completarse dentro de aproximadamente medio segundo.

El NDC 10 controla la asignación de ranuras de transmisión de red a los vehículos y gestiona la salida y entrada de vehículos dentro y fuera de la red. También coordina la difusión del control de red, control de vehículos, mensaje y paquetes de identificación de sistema a los vehículos. La gestión de red en el sistema debe ejecutarse en intervalos de un segundo y completarse dentro de aproximadamente medio segundo. El sistema mantiene estructuras de datos para todos los vehículos y estaciones de orden de abonado de flota activos, y tiene capacidad para realizar referencias cruzadas de vehículos a flotas y a ranuras de difusión asignadas. Los datos requeridos incluyen:

\bullet

posición del vehículo para su transmisión a abonados de flota, y para registro de datos; los datos de posición pueden también usarse para reutilización de frecuencia de UHF o asignación de canal de FM;

\bullet

la(s) ranura(s) de transmisión ocupada(s) por el vehículo;

\bullet

el ID de rastreador del vehículo, ID de control local, propietario y grupo;

\bullet

acuses de recibo de mensaje y control, reintentos y tiempos límite;

\bullet

información de itinerancia; y

\bullet

tipo de servicio, incluyendo tasas de actualización nominal, requisitos de historial de rastreo o servicio en tiempo real.

El servidor de NDC requiere algoritmos eficaces y lógicos para asignar vehículos a las ranuras de transmisión. Deben tenerse en cuenta las diversas tasas de actualización de vehículo, así como reservar espacio para entrada de red y transmisiones de vehículo de respuesta sondeadas. Puede requerirse también la desfragmentación de ranura de transmisión periódica. En la práctica, a medida que el sistema se ejecuta, los vehículos entran en y salen de la red continuamente, y las ranuras deben reasignarse para su uso por los vehículos subsiguientes.

Los datos transmitidos por los vehículos, tales como 17 (figura 3), se reciben en el NDC 10 desde los concentradores de red (por ejemplo, 11-1,11-2), a través de un banco de módems en el que los módems conectados a los concentradores tienen la más alta prioridad con respecto a la transferencia de datos entre los concentradores y el servidor 42 de NDC. El NDC 10 procesa los datos de red en intervalos de un segundo, y por tanto, los datos de vehículo de cada concentrador deben estar disponibles para su procesamiento por el servidor de NDC, durante el intervalo de un segundo después de que los concentradores recibieran esos datos de la trama.

El servidor 42 realiza un procesamiento de diversidad de espacio, descodificación de control de errores y corrección de errores, y descifrado en los paquetes de datos de vehículo recibidos. Los datos recibidos en las ranuras de tiempo asignadas a los vehículos pueden estar disponibles de múltiples concentradores. Puesto que sólo un vehículo 17 ha estado transmitiendo, los datos recibidos en cada concentrador deberían ser los mismos. La pérdida de señal multitrayectoria y otros factores pueden producir errores en los datos recibidos, pero es probable que esos errores sean diferentes para cada concentrador. El NDC 10 puede combinar entonces los datos de todos los concentradores, para producir la solución más probable.

Después de completar el procesamiento de diversidad, se realiza el procesamiento de detección/corrección de error. Se codifican los paquetes de datos de vehículo, para permitir que numerosos errores de bits se corrijan a través del entrelazado de los bits de datos y la codificación de corrección de errores sin canal de retorno. Entonces, se descifran los paquetes de datos.

Los paquetes de datos recibidos se analizan sintácticamente, y se usa la información para actualizar las estructuras de datos de control de red de NDC. Los datos de estado y estatus se registran para el análisis sin conexión. Los datos de estado de vehículo y los datos de abonado de flota se proporcionan a los abonados de flota que han iniciado sesión, a medida que se reciben. Los datos de estado registrados pueden usarse para dotar de historial de rastreo de vehículos a los abonados de flota en lugar de datos de rastreo en tiempo real.

En el caso de datos recibidos desde clientes (abonados de flota, propietarios o arrendatarios, por ejemplo) 13, los datos se procesan según sigue. Las órdenes y solicitudes de datos de abonados de flota que han iniciado sesión se combinarán con información de vehículos, para generar control de vehículos, control de red y paquetes de mensajería, que van a transmitirse a los respectivos vehículos 17. Los eventos tales como clientes iniciando o finalizando sesión pueden controlar si se permite o no a los vehículos entrar en la red, o se les obliga a salir. Para los clientes que desean sólo rastreo de datos en tiempo real, los respectivos vehículos no se permiten en la red a menos que hayan iniciado sesión. Otros clientes pueden requerir información de historial de rastreo y, en esos casos, los vehículos se rastrean en cualquier momento en que estén encendidos. Los abonados de flota con bajas necesidades de tasa de actualización, por ejemplo, unas pocas veces al día, pueden solicitar posiciones de vehículo manualmente a través de sus estaciones de orden. El NDC 10 sondea sus vehículos basándose en una solicitud de CCS de flota, pero no pueden entrar en la parte periódica de la red. Algunos abonados, tales como los que proporcionan servicios de respuesta de emergencia, pueden solicitar cambios en las tasas de actualización de posición del vehículo desde sus estaciones de orden.

Cuando se implementa la itinerancia, se permite a las flotas rastrear vehículos en cualquier cuadrícula independientemente de su conexión de NDC. Puesto que los abonados de flota pueden no saber dónde están ubicados sus vehículos en cualquier momento dado, el sistema de la invención agrega datos para todos los vehículos a través de una red de área amplia que conecta cada NDC, para posibilitar que el CCS visualice todos los vehículos, independientemente del mercado (metropolitano u otra área) en que están ubicados.

Los datos de transmisión se procesan, en general, según sigue. En cada segunda trama, el NDC 10 genera paquetes de datos de mensaje base, que van a difundirse a los vehículos 17. El NDC envía periódicamente paquetes de identificación de cuadrícula, FM y UHF. Los paquetes de datos de usuario y mensaje de texto se envían según se solicitan por los CCS tales como 14, 15. Los paquetes de control de vehículos y configuración de red se generan a partir de la función de gestión de red. Todos los paquetes se envían desde el servidor 42 de NDC, sobre una interfaz 49 serie de alta velocidad, al NTCC 47. El NTCC combina paquetes de NDC con paquetes en tiempo real y correcciones diferenciales, y envía un bloque de mensajes base completo al SCC 48. Entonces, el SCC 48 transmite el mensaje base al comienzo del siguiente segundo. Existe un retardo, de al menos dos segundos, entre el tiempo en que el servidor 42 de NDC envía un paquete al NTCC 47, y el tiempo en que éste se transmite por el 48.

Puesto que el servidor 42 de NDC ubica, esencialmente, paquetes de datos dentro una cola de salida en el ordenador NTCC, el NTCC 47 debe indicar al servidor el espacio disponible en la memoria intermedia. Dependiendo de las acciones del vehículo y del usuario, algunas tramas pueden generar muchos paquetes de mensaje o control de red/vehículos y otras pueden no generar ninguno. Los paquetes de corrección de DGPS suministrados por el NTCC usan también ancho de banda periódicamente. Esto produce un retardo variable, entre el tiempo en que los paquetes se generan por el servidor 42 y el tiempo en que realmente los vehículos 17 los reciben. El NTCC 47 debe proporcionar información de servidor 42 respecto al tamaño de la cola, de modo que el servidor, de media, no supere el ancho de banda de salida de la difusión de FM desde la estación o torre 12.

Puede implementarse un sistema de prioridad de paquete de datos, de modo que algunos paquetes se envíen antes que paquetes de prioridad inferior, que se pusieron en cola primero. Por ejemplo, los paquetes de mensaje de texto pueden tener una prioridad inferior que los paquetes de control de vehículos. A medida que los paquetes se retardan en la cola, su prioridad se aumenta, de modo que se asegura que van a transmitirse con un máximo de unas pocas tramas de retardo.

Los datos que va a registrar el servidor de NDC incluyen información para facturación, historial de rastreo de vehículos para algunos abonados, y datos de registro de paquete de radio detallados para fines de prueba, análisis y mantenimiento.

Un centro de datos PROTRAK vincula los NDC 10 de ciudad individual en un sistema integrado para soportar itinerancia nacional, y sirve como punto central para una base de datos de ID de rastreador montado en vehículo e ID de cliente con una referencia cruzada. Los perfiles de abonado indican qué servicios y tasas de actualización requiere cada rastreador de vehículo. Los datos para itinerancia de vehículos se transfieren, del NDC 10 en el que se recibe al NDC en que está ubicado el abonado, a través del PDC.

La base de datos de NDC desde la que el servidor dispensa información a los CCS, estaciones de orden de NDC, etc., tras la solicitud, es un programa de base de datos de alta capacidad, tal como el servidor de lenguaje de consulta estructurado (SQL) de Microsoft u Oracle 8 Enterprise. Puesto que a estas aplicaciones y sus usuarios asociados sólo se les permite acceder a un subconjunto de los datos almacenados en la base de datos, el servidor de NDC es responsable de autenticar usuarios y evitar el acceso a datos no autorizado. Por ejemplo, a un CCS usado por el cliente A no se le permite normalmente acceder a los datos de rastreo registrados para el cliente B, a menos que el cliente B lo autorice.

IV. La red PROTRAK

Los datos de usuario, mensajería y control de red de RF de acceso múltiple por división de tiempo (TDMA) del sistema PROTRAK, se transmiten a los ordenadores de rastreo (rastreadores) instalados en los respectivos vehículos de flota que van a rastrearse, por una subportadora de difusión de FM. Las transmisiones de rastreador incluyen la posición del rastreador, el estatus de la red y datos de usuario. Los datos de vehículo se transmiten a sitios de concentrador de red usando la banda comercial de UHF convencional. El sincronismo de trama de red y sincronismo de ranura de transmisión de rastreador se controlan en última instancia por un sincronismo preciso obtenido por GPS. El NDC gestiona la asignación de ranura de rastreador y red. Los datos enviados por el NDC se transmiten a través de módem a la estación de difusión de FM, y los datos recibidos desde los rastreadores se proporcionan a través de módem desde los sitios de concentrador.

Para la difusión base, el sincronismo de red de TDMA se basa en tiempo preciso desde el GPS. La red se divide en tramas de un segundo de duración, 3600 tramas se encuentran en un ciclo de trama, y en una semana existen 168 ciclos de trama. Puesto que el periodo de ciclo de trama es un divisor par de 604800 (el número de segundos en una semana), el número de trama puede determinarse directamente a partir del tiempo de GPS. Para soportar usuarios de red (abonados de flota) sin receptores de GPS, el número de trama se transmite en cada mensaje base.

Una sincronización de bits en la difusión base controla el sincronismo de toda la red, indicativo del inicio de cada trama de red a los rastreadores y concentradores de red, todos los cuales tienen receptores de FM. Los concentradores y rastreadores con información de posición tienen en cuenta sus distancias respecto a la antena de transmisión de FM, para obtener el tiempo de inicio de trama.

La manera de manipular el sincronismo de lazo cerrado se describirá con referencia a la figura 6, que ilustra el lazo de realimentación de mensajes base para el sincronismo de sincronización de bits. El mensaje base contiene un patrón de sincronización de bits, que se usa para controlar el sincronismo de difusión de rastreador. Un sistema de realimentación de lazo cerrado controla la sincronización para indicar cada segundo entero de GPS. El NTCC 47 en el NDC usa un receptor 58 de FM y un receptor 54 de GPS, para medir el retardo entre el segundo entero y la llegada de la sincronización de bits en la transmisión de subportadora de FM recibida en el receptor de FM. Después de tener en cuenta la distancia predeterminada entre la antena 53 de difusión de FM y el NDC, la diferencia entre el segundo entero indicado por el GPS y el indicado por la sincronización de bits se envía al SCC 38 en la estación de FM, a través del/de los módem(s) 47. El SCC 38 desvía entonces el tiempo de inicio de difusión, para corregir el error medido.

El SCC recibe los datos de transmisión e información de control de sincronismo desde el ordenador NTCC 47, y registra la salida de los datos al modulador 68 de subportadora. Por ejemplo, un módem de 28,8 Kbps de US Robotics externo está conectado al SCC 48 a través de una interfaz de comunicaciones serie (SCI) periférica 68332 de Motorola. El SCC 48 responde las llamadas del NTCC 47, el NTCC proporciona los datos que van a transmitirse en la siguiente trama, y el SCC almacena en memoria intermedia esos datos para su transmisión. El NTCC 47 proporciona al SCC 48, también, órdenes de control de sincronismo, que usa el SCC para ajustar el tiempo de inicio y el periodo de su reloj de trama de transmisión, para mantener la coherencia con el segundo entero de GPS. El SCC envía la información de estatus y modo al NTCC.

El SCC 48 debe controlar con precisión el sincronismo del inicio del flujo de datos de salida, de modo que el patrón de sincronización de bits deja la antena de transmisión en un tiempo preciso con respecto al segundo entero de GPS. Es deseable que el inicio de la transmisión de datos pueda repetirse a menos de un microsegundo (\mus) y pueda controlarse dentro de aproximadamente 0,4 \mus. El SCC usa temporizadores programables dentro de la unidad de procesamiento de tiempo (TPU) del microprocesador 68332 de Motorola, para activar la transmisión de datos al modulador de subportadora. El NTCC 47 usa datos del receptor 58 de FM y del receptor 54 de GPS, para evaluar la desviación y el periodo de la transmisión base. La sincronización se logra cambiando el periodo de temporizador, basándose en órdenes desde el NTCC. Cuando el sistema se enciende por primera vez, se requiere un periodo de aproximadamente 20-30 segundos para lograr la sincronización. A partir de entonces, se proporcionan, periódicamente, correcciones de poca importancia a la temporización del SCC. El reloj de datos tiene una precisión de menos de aproximadamente 2 partes por millón (ppm) relativa a los relojes de datos de recepción en los rastreadores remotos. Una descripción detallada de los algoritmos de control de sincronismo empleados por el NTCC y los rastreadores instalados en los vehículos, se presenta en la sección V a continuación.

En la práctica, el SCC 38 está montado junto con el modulador 68 de subportadora, el módem y la fuente de alimentación de CC para el SCC en un armario. El modulador 68 de subportadora puede ser un generador de modulación de subportadora SCA-300B disponible de Circuit Research Labs, Inc. de Tempe, Arizona, que recibe datos binarios del SCC 48 en un puerto 61 de entrada de datos de \pm12V. Los datos binarios se filtran y modulan en una subportadora generada digitalmente. El modulador 68 de subportadora tiene también dos entradas 59, 60 de cierre de conmutador discretas, que el SCC 48 usa para apagar y encender la subportadora.

El módulo 55 de techo de NTCC incluye el receptor 54 de GPS, la CPU 56 de PROTRAK y el receptor 58 de FM. La CPU 56 compara el tiempo en que el receptor 58 recibe la sincronización de bits de FM con el impulso-por-segundo (PPS) de segundo entero desde la señal recibida por el receptor 54 de GPS. La diferencia de tiempo se mide, grabando en un registro de control de sincronismo de la TPU en el microprocesador 68332 de Motorola, a la recepción del PPS y a la recepción de la sincronización de bits. La resolución del temporizador de TPU es del orden de 0,2 \mus. La diferencia de tiempo medida proporcionada al NTCC 47 se usa para calcular correcciones de temporizador para que el SCC 48 aplique a su temporizador de transmisión.

El NTCC actúa como la interfaz en tiempo real entre el servidor de NDC y la red. Para el control de sincronismo, el NTCC 47 mantiene la cuenta de trama de red basándose en tiempo de GPS, y calcula y proporciona actualizaciones al temporizador de transmisión de SCC, para mantener la transmisión base alineada con el tiempo de GPS. Están disponibles tres controles de sincronismo, tales como sigue: (1) En el control de retraso/adelanto de trama, para desviaciones de sincronización de bits de PPS mayores de 0,5 segundos, el NTCC puede retardar o adelantar el número de trama contenido en los datos de salida, de modo que el número de trama transmitido corresponde a la trama actual según se define por el GPS, lo que permite ajustar el tiempo en etapas de un segundo. (2) En el control de retraso/adelanto de temporizador de transmisión de SCC, para desviaciones de 0,5 segundos o menos, el temporizador de transmisión puede cargarse con un valor más largo o más corto, para introducir un desplazamiento de uso único en el tiempo de salida con respecto al segundo entero de GPS. (3) En el control de ajuste del periodo de temporizador de transmisión de SCC, puede medirse el intervalo entre partes temporales de sincronización de bits y el segundo entero de PPS, y pueden corregirse errores de factor de escala (frecuencia) en el temporizador de transmisión, ajustando el valor de temporizador nominal hacia arriba o hacia abajo.

Al usar los controles (1) y (2) anteriores, puede ser necesario o deseable un periodo de 20-30 segundos de alineación basta. Una vez se sincroniza el SCC, se usan los controles (2) y (3) para realizar correcciones finas de la sincronización para tener en cuenta pequeños errores de temporizador atribuibles a la temperatura y errores de sincronización residuales.

Los "mensajes base" son datos enviados del NDC a los rastreadores por la red de difusión en la subportadora de FM. Los datos de mensaje base contienen información de control de red, definiciones de asignación de ranura de intervalo de repetición, datos de corrección de DGPS, datos de mensajería/radiomensajería y datos específicos del usuario. El formato de la difusión de datos base a los rastreadores se describirá a continuación en el presente documento.

Para el flujo de información, los datos de mensaje que controlan la actividad de red (paquetes de control de red y rastreador) se crean por el servidor 42 de NDC (figura 4) en respuesta a los datos recibidos desde los rastreadores y desde los CCS (por ejemplo, 44) (o los NDC, por ejemplo, 43). Los paquetes de datos de usuario y radiomensajería los crean, a partir de órdenes, los usuarios. Estos paquetes se envían al NTCC 47, para su ensamblaje en un mensaje base. El NTCC añade datos de corrección de DGPS y un número de trama de red, según se requiera, y entonces aplica cifrado, codificación de control de errores y entrelazado de bits. El mensaje resultante se envía al SCC 48, que inserta el patrón de sincronización de bits y transmite los datos de mensaje al comienzo de la siguiente trama. Las etapas de procesamiento se resumen según sigue:

1.

el NDC 10 calcula paquetes de datos de mensaje base y los envía al NTCC 47.

2.

En cada intervalo de un segundo, el NTCC 47:

a)

ensambla paquetes de datos disponibles a partir del NDC 10, número de trama, y correcciones de DGPS, si es necesario, en un único bloque de mensajes. Los bytes sin usar se rellenan con un relleno.

b)

Realiza el cifrado en el bloque de mensajes

c)

Realiza la codificación de control de errores en el bloque de mensajes. En la realización preferida en la actualidad se usa un código Golay (23, 12), pero puede usarse un código diferente.

d)

Realiza el entrelazado de bits. Los datos se transmiten enviando segmentos largos de todos los primeros bits seguidos por los segundos bits, etc., lo que proporciona capacidad de corrección de errores en ráfaga significativa.

e)

Envía el bloque de mensajes al SCC 48, para su transmisión.

3.

El SCC 48 inserta un patrón de sincronización de bits delante del bloque de mensajes, codifica los datos a código Miller y los transmite al modulador 68 de subportadora (figura 6), al comienzo de la trama después de que el bloque de mensajes se recibe desde el NTCC 47.

\vskip1.000000\baselineskip

El formato del bloque de mensajes es según sigue. La tasa de transmisión de bits máxima, para el generador de modulación de subportadora SCA-300B usado como 68, es de 4800 bps. Es deseable usar la tasa de transmisión de bits disponible máxima consistente con los requisitos de índice de modulación (para la sensibilidad del receptor) y el tamaño de bloque de datos. Un código Golay (23, 12) se usa con entrelazado de bits; los datos se envían en 40x23 = 920 bloques de bit. Se transmiten cinco bloques, para un total de 4600 bits. El SCC 48 codifica los datos a código Miller y añade la sincronización de bits. El código Miller dobla el número de bits, de modo que el SCC transmitirá los datos a una tasa de transmisión de bits de aproximadamente 9328,36 bps. 4600 bits requieren 986,24 milisegundos. Puesto que una sincronización de bits de 24 bits de longitud y un preámbulo de 8 bits requieren 6,8608 ms, el SCC 48 tiene un tiempo de separación de 6,8992 milisegundos para reiniciar el reloj de transmisión con sincronizaciones actualizadas para enviar el siguiente mensaje.

La figura 7 es un diagrama del formato de difusión de mensajes base (NDC). Al comienzo 70 de cada segundo entero, se transmite el patrón 71 de sincronización de bits, seguido por los datos 72 de mensaje base, y finalmente, por un intervalo 73 muy breve de tiempo muerto hasta el inicio del siguiente segundo entero. Se aplica entrelazado de bits al mensaje base, para reducir la susceptibilidad a errores de ráfaga. El entrelazado se aplica de bloque a bloque. El código Golay corrige 3 errores en 23, de modo que un entrelazado de 40 bits de anchura permite corregir una ráfaga de 120 bits o 25,728 milisegundos. Esto es lo suficientemente largo para corregir la desensibilización que se produce, cuando un rastreador transmite en su ranura de TDMA de 20 milisegundos, en la antena de transmisión/recepción compartida.

Para la sincronización de bits, los rastreadores y concentradores de red usan la sincronización de bits en la difusión de FM, para sincronizar sus relojes para la transmisión y recepción de datos de rastreador. Los rastreadores con datos de posición válidos pueden usar el intervalo conocido por el sitio de difusión de FM, para desviar sus transmisiones para tener en cuenta el retardo en la recepción de la sincronización de bits.

Para la identificación del rastreador, se asigna a todos los rastreadores, en la fábrica, un ID de rastreador de 30 bits, único para todo el sistema PROTRAK. Aunque éste podría ser el único ID usado para identificar un rastreador, se asigna a los rastreadores un ID más corto cuando reciben su asignación de ranura de intervalo de repetición principal, lo que permite al servidor de NDC identificar los rastreadores en su cuadrícula de red de RF con menos bits de datos. Los ID más cortos están constituidos por un ID de red y un ID de interfaz. Puesto que se usan dos tamaños de red, se usa el bit más significativo del ID de 16 bits para indicar el tamaño de la red. A continuación, la tabla 1 muestra el formato de ID de red/interfaz para los dos tamaños de lote usados.

TABLA 1 Formato de ID de red/interfaz

1

\vskip1.000000\baselineskip

Para minimizar la interrupción del texto, en el apéndice B se exponen otras tablas, en su mayor parte.

Puede asignarse un ID a los rastreadores dentro de una de las 128 redes con 256 ID de interfaz o una de las 2048 redes con 16 ID de interfaz. El servidor de NDC usa los ID de red para reducir el número de bits requerido para identificar un subconjunto de módulos de rastreador de un cliente. Por ejemplo, si un operador de flota envía un mensaje a diez de sus rastreadores (vehículos), que están contenidos en la misma red de 16 rastreadores, el servidor de NDC puede tratar individualmente estos rastreadores usando 52 bits, con 12 bits que indican el ID de red y requiriéndose sólo 4 bits para identificar cada ID de interfaz de rastreador.

Puesto que el DMCS gestiona los grupos de clientes, el servidor de NDC puede coordinarse con el DMCS para aprender acerca de los grupos de clientes. O, el servidor de NDC puede usar datos registrados para determinar qué rastreadores se han agrupado entre sí. Como resultado, el servidor de NDC ubica los rastreadores del mismo ID de cliente y/o grupo en la misma red. Aunque los rastreadores de diferentes clientes y/o grupos pueden colocarse en la misma red, los grupos de rastreadores que se colocan juntos en la misma red pueden identificarse con un número de bits relativamente pequeño.

El esquema de asignación de ID de red/interfaz se usa en formatos de paquete de datos. Los datos de difusión base contienen un número de paquetes de datos cortos variable concatenados entre sí, que son de longitud fija o variable dependiendo del tipo. Los paquetes incluyen datos de corrección de DGPS, información de descripción de red, mensajería y órdenes de usuario, y órdenes de control de rastreador.

\vskip1.000000\baselineskip

A. Formatos y paquetes de datos

La descodificación de los paquetes de datos se realiza después de la detección/corrección y el descifrado de errores. Cada mensaje base (es decir, del NDC 10) comienza con un ID de trama. Los paquetes de datos siguen hasta que se llena el espacio disponible en el bloque de datos o no quedan paquetes para enviar. El espacio sin usar en el mensaje se llena con todo ceros, que se codifican a un patrón uno-cero alternante en código Miller. Cada paquete comienza con un byte de ID de paquete, seguido por los datos en el paquete y una palabra de suma de comprobación/paridad. La sincronización del descodificador de paquetes en los datos se mantiene verificando que el primer byte después del ID de trama es un ID de paquete, y entonces, mirando por adelantado el número de bytes en el primer paquete, para verificar que la suma de comprobación es correcta y el byte subsiguiente es, también, un ID de paquete válido. Esto continúa hasta que todos los paquetes de datos están descodificados. En la tabla 2 (apéndice B) se expone un resumen de paquetes base.

Los paquetes de mensaje de texto se generan en respuesta a órdenes de radiomensajería/mensajes desde estaciones de orden de usuario (es decir, desde los CCS). A modo de ejemplo para la presente realización ejemplar, se supone que la longitud de mensaje máxima es de 80 caracteres. Además, puede anexarse un conjunto de respuesta de 28 caracteres opcional según, se explica a continuación con referencia a conjuntos de respuesta de mensaje predefinido.

Los mensajes de texto pueden dirigirse a los rastreadores (es decir, a los ordenadores de rastreo instalados en los vehículos 17), de las siguientes formas:

\bullet

ID de rastreador

\bullet

ID de red/interfaz

\bullet

ID de cliente

\bullet

ID de interfaz

\bullet

intervalo de ID de interfaz dentro de una red

\vskip1.000000\baselineskip

En la presente realización ejemplar, el número de ID de rastreador es de 30 bits, el ID de red/interfaz es de 16 bits y el ID de cliente es de 24 bits. Se reserva un número variable de bits de dirección, dependiendo del modo de dirección y del número de rastreadores que está dirigiéndose.

El acuse de recibo de mensajes de texto se realiza al solicitar el rastreador una ranura de tiempo de intervalo de repetición auxiliar. La ranura auxiliar se repite en intervalos de 12 segundos, e incluye ranuras suficientes para enviar el acuse de recibo, por ejemplo, una más ranuras adicionales para permitir reintentos. La tabla 3: "paquete de mensaje de texto - rastreador único o toda la flota"; tabla 4: "conjuntos de respuesta de mensaje predefinido"; tabla 5: "paquete de mensaje de prueba - grupo de rastreador"; tabla 6: "paquete de lista de ID de interfaz de mensaje de grupo de rastreador"; y tabla 7: "bloque de lista de ID de rastreador", se exponen en el apéndice B.

Un paquete de "definición de mensaje predefinido" (tabla 8, apéndice B) proporciona a los rastreadores (a los que a veces se hace referencia en el presente documento como módulos de rastreador) un mensaje de texto, que debería asociarse con un ID de mensaje predefinido especificado. Aunque los rastreadores individuales solicitan esta definición, el mensaje se difunde a todos los rastreadores asociados con un cliente particular (operador de flota, abonado o usuario, puesto que esos términos se usan de forma intercambiable en el presente documento). Los rastreadores que reciben este mensaje almacenan, si el ID de cliente especificado corresponde a su ID de cliente conocido, la definición de mensaje predefinido. Esta asociación almacenada se usa entonces para visualizar el mensaje apropiado tras la recepción de un "paquete de mensaje predefinido". El último paquete permite un formato de mensaje más corto para mensajes de usuario "preestablecidos" que se transmiten frecuentemente por un cliente individual. Puesto que los rastreadores conocen el texto de estos mensajes a priori, el NDC sólo necesita enviar un ID de mensaje y una comprobación de redundancia cíclica (CRC) de 16 bits. El ID identifica el mensaje, y la CRC permite al rastreador determinar si el texto corresponde a la CRC del mensaje predefinido conocido.

Las CRC de mensaje predefinido se calculan usando todo el mensaje predefinido. Así, un rastreador puede determinar si el ID se ha reasignado a un nuevo mensaje. En este caso, o si no se conoce un mensaje predefinido especificado, el rastreador puede solicitar todo el mensaje predefinido, usando un "paquete de solicitud de mensaje predefinido". Tras la recepción de un paquete de solicitud de este tipo, el servidor de NDC proporciona al rastreador solicitante el mensaje predefinido en un "paquete de definición de mensaje predefinido". El tratamiento de rastreador es similar al de los mensajes de texto. La estructura de "paquete de mensaje de ID predefinido" para un rastreador único o toda la flota se muestra en la tabla 9, y para un grupo de rastreador, en la tabla 10, del apéndice B.

Los paquetes de datos de corrección de DGPS (tabla 11) se generan por el NTCC, y se insertan dentro del bloque de mensajes base, en intervalos de aproximadamente 10 segundos. El receptor de GPS calcula las correcciones de intervalo/tasa de transmisión de intervalo (por ejemplo, 54, figura 6), en el módulo 55 de techo de NTCC. Éstas pueden estar en RTCM u otro formato deseado. El escalado en las correcciones es el mismo que el del RTCM-104. El NTCC transmite datos de corrección en un formato con correcciones de estilo completas de "tipo 1" y "tipo 2". Como alternativa, pueden soportarse otros tipos de mensaje de RTCM, si se desea. Los tipos de mensaje de RTCM 1 y 2 tienen el mismo formato, siendo diferentes sólo los ID de trama. El paquete es de longitud variable dependiendo del número de correcciones en el mismo. El número de bytes es 5+5N_{sv}.

Un paquete de mensaje de datos de usuario soporta datos genéricos, específicos del usuario, que se envían a los rastreadores desde los CCS. El formato del mensaje es similar al paquete de mensaje de texto, teniendo 80 bytes de datos disponibles para cualquier fin de cliente. El software específico del cliente debe programarse en el rastreador, el MDT, y el CCS para que el cliente haga uso de este mensaje. El tratamiento y los acuses de recibo de paquete de datos de usuario son idénticos a los de paquetes de texto. La estructura del "paquetizador de mensaje de datos de usuario" para un rastreador único o toda la flota se muestra en la tabla 12, y para un grupo de rastreador se muestra en la tabla 13.

Un "paquete de identificación de cuadrícula" (tabla 14) proporciona a los rastreadores el centro de las cuadrículas de navegación PROTRAK local y adyacentes (por ejemplo, véase la figura 11, que va a explicarse a continuación en el presente documento). En una realización ejemplar, la cuadrícula de navegación es un área cuadrada de aproximadamente 262 km en un lado, aproximadamente centrada en cada área de mercado PROTRAK. Cada cuadrícula de navegación (mercado) tiene un único número de ID de 15 bits. El "paquete de ID de cuadrícula" se transmite en intervalos de aproximadamente 20 segundos, y alterna entre la cuadrícula local y cuadrículas adyacentes. La información de cuadrícula adyacente se proporciona para permitir a los rastreadores itinerantes localizar rápidamente el sistema PROTRAK en mercados nuevos a medida que se mueven a través de los mercados. Preferentemente, los rastreadores almacenan la información de cuadrícula en memoria no volátil.

El centro de la cuadrícula de navegación se proporciona en enteros a escala de 24 bits, con un LSB (bit menos significativo) de aproximadamente 2,4 m de latitud, que debería ser adecuado para la mayor parte de aplicaciones de navegación de rastreador. Se supone que la cuadrícula de navegación nominal es cuadrada y está constituida por 1024 cuadrados contiguos de 64 km cuadrados. Si es necesario, pueden añadirse a este mensaje datos adicionales para definir cuadrículas de navegación rectangulares o de forma irregular.

Un "paquete de identificación de FM" (tabla 15) proporciona, a los rastreadores, las frecuencias de difusión base de FM y las ubicaciones de transmisor, para las cuadrículas de navegación PROTRAK local y adyacentes. La ubicación de transmisor se usa para cálculos de tiempo de retardo de difusión. También se proporciona la frecuencia de la subportadora. Preferentemente, los rastreadores almacenan también información de transmisor en memoria no volátil. La ubicación de transmisor se proporciona en enteros a escala de 24 bits con un LSB de aproximadamente 2,4 m de latitud, que es bastante adecuado para los cálculos de retardo de difusión. Cada cuadrícula de navegación puede tener múltiples transmisores de FM. El paquete soporta hasta 4 transmisores para un número de ID de transmisor. Si se requiere, pueden usarse datos adicionales en este mensaje u otro mensaje, para definir áreas de cuadrícula a las que da servicio cada transmisor por razones de capacidad o cobertura.

Un "paquete de identificación de UHF" (tabla 16) dota a los rastreadores de la frecuencia de UHF en la que deben transmitir sus datos de estado. Las frecuencias se proporcionan para las cuadrículas de navegación PROTRAK local y adyacentes. Aquí de nuevo, los rastreadores deberían almacenar la información de frecuencia de UHF en memoria no volátil. Cada cuadrícula de navegación puede tener múltiples frecuencias de transmisión de rastreador, y el "paquete de identificación de UHF" soporta hasta 4 frecuencias por un número de ID de frecuencia. Si es necesario, pueden usarse datos adicionales en este mensaje u otro mensaje para definir áreas de cuadrícula en las que usar cada frecuencia de UHF por razones de capacidad o cobertura.

El NDC 10 transmite un paquete que contiene el tiempo de GPS actual en intervalos de 10-20 segundos para ayudar a la inicialización de los receptores de GPS montados en el vehículo asociados con los rastreadores. El "paquete de tiempo de GPS" (tabla 17) se calcula e inserta en el bloque de mensajes base por el NTCC. La desviación de zona de tiempo y segundos intercalares de UTC se añaden al tiempo de GPS actual para determinar tiempo local.

Un "ajustar paquete de definición de ranura de intervalo de repetición principal" (tabla 18), asigna un intervalo de repetición continuo y un ID de red/interfaz a un rastreador. Los rastreadores que reciben este paquete envían una actualización de rastreo al servidor 42 de NDC cuando (ID de trama) mod (longitud de intervalo) es igual al índice de intervalo de repetición indicado en el paquete. Si un rastreador ya tiene un intervalo de repetición principal asignado, se reemplazará por el intervalo en este paquete. Los rastreadores pueden determinar si este paquete se dirige a ellos comprobando si el campo de ID de rastreador es igual al ID de rastreador del destinatario. Si lo es, el rastreador usará el intervalo de repetición e ID de red/interfaz asignados. De otro modo, el rastreador garantizará que ninguno de sus intervalos de repetición corresponde al intervalo descrito. Si el intervalo descrito corresponde al intervalo principal actual del rastreador, el rastreador dejará de usar este intervalo (e ID de red/interfaz) e intentará una entrada de red. O, si el intervalo descrito corresponde a uno de los intervalos auxiliares actuales del rastreador, el rastreador eliminará este intervalo de su lista.

El ID de red/interfaz asignados al intervalo de repetición principal es válido mientras el intervalo de repetición principal sea válido. Como resultado, los rastreadores responderán a los mensajes con su ID de rastreador o su ID de red/interfaz temporales, mientras están en la red de RF. Una vez que un rastreador sale de la red de RF (o tiene su intervalo de repetición principal purgado), el ID de red/interfaz asociado ya no es válido para ese rastreador. Los rastreadores que reciben una asignación de intervalo de repetición principal pueden usar el intervalo asignado hasta que soliciten salir de la red, acusen recibo de purgar paquete de intervalo de repetición o excedan la cuenta de actualización de autopurgar.

Un "añadir paquete auxiliar de definición de ranura de intervalo de repetición" asigna un intervalo de repetición a un rastreador para un único intervalo (tabla 19). Los rastreadores que reciben este paquete envían una actualización de rastreo al servidor 42 de NDC cuando (ID de trama) mod (longitud de intervalo) es igual al índice de intervalo de repetición indicado en este paquete. Como resultado de recibir este paquete, los rastreadores enviarán una única actualización. Los rastreadores pueden determinar si este paquete se dirige a ellos usando el ID de rastreador o el campo de ID de red/interfaz. Si el campo de ID de rastreador identifica al destinatario, el rastreador usará el intervalo de repetición asignado para comunicar su información de rastreo al servidor de NDC. De otro modo, el rastreador garantizará que no comunique su información de rastreo usando el intervalo descrito. Debe observarse que aunque un rastreador puede tener múltiples intervalos de repetición auxiliares, cada rastreador tiene sólo un intervalo de repetición principal. La tabla 20 (apéndice B) muestra la estructura de "añadir paquete auxiliar de definición de ranura de intervalo de repetición" para un único intervalo por ID de red/interfaz.

El paquete de "añadir definición de ranura de intervalo de repetición auxiliar" para un número limitado de intervalos asigna un intervalo de repetición a un rastreador, para un número de intervalos especificado. Los rastreadores que reciben este paquete envían una actualización de rastreo al servidor de NDC cuando (ID de trama) mod (longitud de intervalo) es igual al índice de intervalo de repetición indicado en este mensaje, y estas actualizaciones se envían por los rastreadores un número de veces de cuenta de intervalo. De nuevo aquí, los rastreadores pueden determinar si este paquete se dirige a ellos usando el ID de rastreador o el campo de ID de red/interfaz, y comunicar su información de rastreo respectiva al servidor de NDC, o no, de la misma forma que se especificó anteriormente. Las tablas 21 y 22 muestran la estructura de la estructura de paquete de "añadir definición de ranura de intervalo de repetición auxiliar" para un número limitado de intervalos por ID de rastreador y por ID de red/interfaz, respectivamente.

Un paquete de "ranuras de entrada de red disponibles" (tabla 23) contiene una cuenta de ranura que indica el número de ranuras dentro de una trama de un segundo, y una máscara de bits que indica las ranuras que están disponibles en la actualidad para entrada de red. El bit 0 del byte 2 indica si la ranura 0 está disponible, el bit 1 del byte 2 indica si la ranura 1 está disponible, el bit 0 del byte 3 indica si la ranura 8 está disponible, etc. Antes de permitir a un rastreador enviar un paquete de "solicitud de entrada de red", debe recibir un paquete de "ranuras de entrada de red disponibles" y recibir con éxito cada mensaje de paquete base antes de enviar su "solicitud de entrada de red". El paquete es válido sólo hasta que se recibe el siguiente, de modo que el rastreador no enviará una solicitud de entrada de red en una ranura que ya no está disponible. El servidor 42 de NDC difunde este paquete a medida que cambian las ranuras de entrada de red disponibles, y también lo envía al menos una vez cada 10 segundos.

Un paquete de "información de configuración de ranura de intervalo de repetición" (tabla 24), enviado cada 30 segundos por el servidor de NDC, indica la longitud del ciclo de trama, la cuenta de intervalo de autopurgar y el modo de solicitud de ID de rastreador. Cada uno de estos valores es necesario para que un rastreador determine el formato y/o sincronismo de transmisión de sus paquetes de actualización de rastreo periódico. La longitud del ciclo de trama indica el número de tramas de un segundo que están contenidas en un ciclo de trama. Puesto que este número será siempre un divisor del número de segundos en una semana de GPS, puede determinarse un ID de trama usando el tiempo de GPS. El ID de trama se calcula usando el segundo de GPS según sigue:

ID de trama = (Segundo de GPS) mod (longitud de ciclo de trama)

La cuenta de actualización de autopurgar indica el número de actualizaciones periódicas que un rastreador puede proporcionar en una ranura de intervalo de repetición asignada, sin solicitar volver a entrar en la red. Los rastreadores con una ranura de intervalo de repetición asignada deben solicitar tener su ranura de intervalo de repetición reasignada a ellos indicando "Reasignar solicitud de ranura de intervalo de repetición principal" o "Reasignar solicitud de ranura de intervalo de repetición auxiliar" para su código de estatus de la red. Los rastreadores que no consiguen tener su ranura de intervalo de repetición reasignada antes de alcanzar la cuenta de actualización de autopurgar, purgarán su ranura de intervalo de repetición asignada.

El "modo de solicitud de ID de rastreador" indica si se requiere que los rastreadores suministren su número de ID de rastreador dentro de paquetes de datos de rastreador. Este modo de solicitud puede indicar que no se requiere a los rastreadores que suministren su número de ID de rastreador, que se requiere a los rastreadores que suministren su ID de rastreador sólo para su siguiente actualización, o que se requiere a los rastreadores que suministren su ID de rastreador para todas las actualizaciones.

Los módulos de rastreador recopilan información de prueba incorporada (BIT), que entonces se suministra al servidor de NDC a la tasa de transmisión (en segundos) especificada en el paquete de "info de config de ranura de intervalo de repetición". Si la tasa de transmisión es cero, no se requiere que el rastreador suministre el paquete de BIT. Si la tasa de transmisión es mayor que cero, el rastreador proporcionará su paquete de BIT a la tasa de transmisión indicada. Para suministrar una actualización de paquete de BIT, los rastreadores solicitan una ranura auxiliar cuando (ID de rastreador) mod (tasa de transmisión de paquete de BIT) es igual al ID de trama actual. Como resultado, las solicitudes de rastreador de ranuras auxiliares se distribuyen uniformemente. Si una solicitud de ranura auxiliar interfiere con la actualización planificada de un rastreador, el rastreador aplazará la solicitud hasta un momento posterior.

El servidor de NDC usa un paquete de "respuesta de entrada de red" (tabla 25) para responder a la solicitud de entrada de red de un rastreador cuando el tipo de servicio del rastreador no permite de otro modo la entrada de red. El código de estado del rastreador asignado contenido en este paquete permite a un rastreador determinar su tipo y requisitos para asignársele una ranura de intervalo de repetición. Los rastreadores de rastreo manual han de esperar un paquete de "definición de ranura de intervalo de repetición (único intervalo)", y el rastreo sólo de inicio de sesión y los rastreadores desconocidos deben esperar un mensaje de "permiso de solicitud de entrada de red". El servidor 42 de NDC puede enviar un mensaje de "permiso de solicitud de entrada de red" como resultado de un CCS (por ejemplo, 14, figura 3) que conecta al DMCS 27, o porque ha cambiado un tipo de servicio del rastreador individual.

El servidor de NDC envía un paquete de "permiso de solicitud de entrada de red" (tabla 26) a toda la flota de un abonado de rastreadores LOT, a un grupo de rastreadores de abonado, o a un rastreador individual, para que uno o más rastreadores soliciten entrada de red. Si un abonado no está conectado para ver su grupo de rastreadores LOT, no se permite a los rastreadores entrar en la red de RF sino que en su lugar se les notifica que esperen al permiso de solicitud de entrada de red. Cuando un abonado se conecta al DMCS usando software de CCS, el DMCS comprueba si un abonado con este ID ya está conectado, y si no, envía un mensaje al servidor de NDC, identificando todos los rastreadores en el grupo del usuario de CCS. El servidor de NDC responde a este mensaje enviando un paquete de "permiso de solicitud de entrada de red" para permitir a los rastreadores en el grupo del usuario de CCS solicitar la entrada de red. Dependiendo del tamaño de grupo de abonado o tamaño de flota de abonado, el servidor puede enviar este paquete a toda la flota o a sólo un grupo de rastreadores, con una vista para reducir el ancho de banda de RF requerido tanto como sea posible. El paquete de "permiso de solicitud de entrada de red" también puede enviarse si se modifica un tipo de servicio del rastreador, tal como si se cambia un rastreador de rastreo manual a un rastreador de rastreo continuo.

El servidor de NDC envía un mensaje de "purgar intervalos de repetición asignados" (tabla 27), por paquete de lista de ID de rastreador, ID de cliente o ID de rastreador, para indicar que un rastreador o un grupo de rastreadores debería purgar algunos o todos sus intervalos de repetición asignados. Esto se haría, por ejemplo, cuando el único abonado en un grupo de rastreadores LOT se desconecta del DMCS, porque la información de esos rastreadores ya no se comunica cuando se detiene su visionado por el abonado desconectado. El DMCS proporciona una lista de rastreadores que van a eliminarse de la red de RF al servidor de NDC. El mensaje de "purgar intervalos de repetición asignados" puede enviarse también a rastreadores individuales, tal como cuando un rastreador de rastreo continuo tiene su servicio cambiado a rastreo manual, caso en el que se informa al rastreador en cuestión de su nuevo servicio y que espere una ranura de intervalo de repetición. De forma similar, si se cambian tanto el tipo de servicio de un rastreador individual como una tasa de actualización (por ejemplo, de continuo con una tasa de actualización de 30 segundos a LOT con una tasa de actualización de 60 segundos) se enviará este mensaje si su abonado no está conectado al servidor de NDC. Y, cuando se ha asignado un intervalo auxiliar a un rastreador para una condición de emergencia, para comunicar datos a una alta tasa de actualización, por ejemplo, durante un corto periodo además de su intervalo de repetición principal, el servidor de NDC envía el mensaje a ese rastreador cuando la emergencia termina, para purgar su intervalo de repetición auxiliar.

Los rastreadores acusan recibo de recepción del mensaje de "purgar intervalos de repetición asignados" ajustando el bit de estatus apropiado en su siguiente actualización periódica, o, si es necesario, solicitando una ranura de tiempo para proporcionar un acuse de recibo. Un rastreador cuya ranura de intervalo de repetición principal se purga, puede usar esa ranura una última vez, para proporcionar el acuse de recibo en un paquete de rastreador de estatus y estado. Cuando el servidor de NDC recibe un acuse de recibo de purgar, éste puede reasignar la ranura de intervalo de repetición a ese tiempo, o esperar hasta que se haya alcanzado una cuenta de actualización de autopurgar para reasignarla.

Cuando se envía un mensaje de texto o de texto predefinido a un rastreador, puede identificarse un conjunto de respuesta predefinido o personalizado, que indica las etiquetas de texto asociadas con las teclas programables de terminal de datos móvil cuando se visualiza el mensaje. Cuando se pulsa una tecla programable para responder a un mensaje, el número de tecla programable se devuelve al servidor de NDC en un "estatus y estado de respuesta de mensaje" o un "estatus y estado reducido de respuesta de mensaje". Un mensaje base de "acuse de recibo de respuesta de mensaje" (tabla 28) acusa el recibo de la recepción con éxito de un paquete de respuesta, por parte del servidor de NDC. El módulo de rastreador descarta una respuesta de mensaje sólo si ha recibido con éxito un acuse de recibo en 2 minutos; de otro modo, se reenvía la respuesta.

Un mensaje de "expedición de sitio" (tabla 29) ayuda a automatizar la capacidad del operador de la flota para determinar cuándo un rastreador específico ha llegado a/salido de un sitio de trabajo, proporcionando al módulo de rastreador un par de valores de latitud/longitud que definen el siguiente sitio de trabajo del rastreador, y una descripción de texto de la ubicación del sitio (dirección de destino). Tras la recepción, el módulo de rastreador acusa recibo del mensaje usando un paquete de "estatus y estado de respuesta de mensaje" o "datos de usuario y respuesta de mensaje".

Los rastreadores envían paquetes de "estatus de sitio" cuando entran en o dejan uno de sus sitios conocidos. Un paquete de mensaje de "purga de sitio" (tabla 30) del NDC solicita a un rastreador que elimine uno de sus sitios conocidos. Después de recibir este paquete, el rastreador ya no proporcionará un mensaje de "estatus de sitio" para el sitio asociado con el "ID de sitio" especificado en el mensaje de "purga de sitio".

Un paquete de "acuse de recibo de datos de usuario" (tabla 31) sirve para acusar recibo de la recepción del NDC de un mensaje de datos de usuario fiable de un rastreador del vehículo. El rastreador retiene una copia de todos los paquetes de datos de usuario fiables hasta que recibe este mensaje de acuse de recibo desde el servidor de NDC. Si el acuse de recibo no se recibe en 2 minutos, el rastreador volverá a enviar el paquete de datos de usuario fiable.

El rastreador puede usar un "ID de secuencia de inicio de servidor de NDC" para determinar si se ha reiniciado el servidor de NDC de una cuadrícula de navegación (véase la referencia a y descripción del paquete de "identificación de cuadrícula" anteriormente). Cuando un módulo de rastreador descubre que este ID ha cambiado, purga toda la información de estado de RF (incluyendo las asignaciones de ranura de RI) recibida con un ID de secuencia de inicio previo. Entonces, la información de estado de RF nueva recibida se asocia con el nuevo "ID de secuencia de inicio de servidor de NDC". El "ID de secuencia de inicio de servidor de NDC" permite, a los rastreadores en bajo modo de potencia o los rastreadores que han estado fuera del intervalo de subportadora de FM, determinar si su ranura de RI y otra información son aún válidas. Los rastreadores que han estado de este modo durante un periodo de tiempo prolongado, deben garantizar que la cuenta de inicio de servidor de NDC no haya cambiado antes de que proporcionen una actualización de rastreo. Un "paquete de identificación de cuadrícula 2" (tabla 32) proporciona el "ID de secuencia de inicio de servidor de NDC".

Un paquete de "acuse de recibo de estatus de sitio" (tabla 33) se usa para el acuse de recibo de la recepción de NDC de un mensaje de "estatus de sitio" fiable desde un rastreador. El rastreador retiene una copia de cada paquete de mensaje de estatus de sitio fiable, hasta que recibe este mensaje de acuse de recibo del servidor de NDC. Si el acuse de recibo no se recibe en 2 minutos, el rastreador reenvía el paquete de "estatus de sitio" fiable.

B. Mensajes de rastreador

Los mensajes de rastreador se transmiten, desde los rastreadores al NDC, por la red de radio de UHF de TDMA. Los datos de rastreador están constituidos por información de estado de navegación, respuestas a órdenes relacionadas con la red desde el NDC, respuestas de radiomensajería/mensajería y datos específicos del usuario. Cada rastreador tiene su(s) propia(s) ranura(s) de intervalo de repetición única(s) asignada(s) para transmitir sus datos. Los datos se reciben por los concentradores de red y se transmiten al NDC cuando cada trama está completa. Según un aspecto de la invención, puesto que un paquete de datos de rastreador puede recibirse por más de un concentrador, se dota al NDC de capacidad para realizar un procesamiento de diversidad para ayudar a recuperar los datos dañados.

Aunque, según la invención, los rastreadores tienen en general una ranura de tiempo de intervalo de repetición continuo asignado en la red de TDMA, se realiza una provisión, para los rastreadores con requisitos de tasa de actualización baja, para operar en un modo sondeado, en el que el NDC 10 debe solicitar que tal rastreador con necesidad de actualización baja, instalado en un vehículo 17, transmita durante una única ranura de tiempo de intervalo de repetición. Poco tiempo antes del tiempo de transmisión asignado del rastreador, el rastreador debe ensamblar un paquete de datos para su transmisión. Basándose en la sincronización de bits de FM de difusión recibida en el receptor 58 de FM de módulo 55 de techo de NTCC y la distancia estimada a la antena 53 de difusión (figura 6), el rastreador aplicable debe comenzar su transmisión en su tiempo de transmisión asignado en su ranura de intervalo de repetición asignada con una precisión de aproximadamente un microsegundo.

En cada trama, cada concentrador de red 11-1, etc., intenta recibir datos de rastreadores en cada ranura de tiempo. Al final de la trama, los paquetes recibidos por concentrador se empacan en un único mensaje y se envían a través de un módem al NDC 10. El servidor 42 de NDC realiza corrección de errores y procesamiento de diversidad en los paquetes de rastreador de todos los concentradores. Los datos de estado del rastreador se registran y/o transmiten a las estaciones de orden de CCS y/o de NDC aplicables a través de TCP/IP u otra aplicación de conectividad. Resumiendo, las etapas de procesamiento son:

1.

En la trama antes de su ranura de transmisión de intervalo de repetición asignada, el rastreador:

a)

forma un paquete de datos que va a transmitirse;

b)

realiza el cifrado en el mensaje;

c)

realiza la codificación de control de errores en el mensaje (preferentemente usando un código (12,8), aunque puede emplearse un código diferente si se desea);

d)

realiza entrelazado de bits (se requiere un patrón de entrelazado complicado para reducir errores de bits cuando los datos se desplazan 1 bit de los verdaderos, para permitir el procesamiento de banda base del concentrador. El esquema de entrelazado proporciona una anchura de 11 bits, que mejora la capacidad de corrección de errores en ráfaga).

2.

Un temporizador de alta resolución, sincronizado con el segundo entero de GPS usando la sincronización de bits de FM y la posición del rastreador, se ajusta para activar la transmisión de rastreador en el tiempo apropiado, con una precisión de aproximadamente un microsegundo.

3.

Cada concentrador intenta registrar la entrada de datos en el tiempo apropiado para cada ranura.

4.

Al final de una trama, los concentradores envían todos los datos de rastreador recibidos por la trama al NDC.

\vskip1.000000\baselineskip

Deben considerarse el sincronismo del mensaje de rastreador y el formato del bloque de datos de rastreador. La red de TDMA de difusión de rastreador está constituida por 168 ciclos de trama en una semana, teniendo cada ciclo de trama 3600 tramas de un segundo de duración. Cada trama se divide en varias ranuras de tiempo de transmisión de rastreador. El número de ranuras depende de la longitud del mensaje de rastreador, la tasa de transmisión de bits de transmisión y la separación requerida entre ranuras para encender/apagar el transmisor y el retardo de propagación de mensaje. La tasa de transmisión es de 7812,5 bps (15625 bps codificada por codificación Miller). Una longitud del mensaje de rastreador es 144 bits, 8 bits Miller de preámbulo (10101010). Los datos de transmisión requieren 18,944 milisegundos. Por tanto, se asigna un tiempo de ranura total de 20 milisegundos, para permitir retardos de la velocidad de la luz y tiempo de encendido/apagado de transmisor; en consecuencia, están disponibles 50 ranuras de transmisión de rastreador en cada trama. Un ejemplo de una trama de transmisión de rastreador se muestra en la figura 8, en la que paquetes 76 de mensaje de vehículo (rastreador) se transmiten secuencialmente en sus ranuras asignadas respectivas (de los rastreadores) desde el inicio 77 de un segundo entero, y seguidos por un intervalo de tiempo 78 muerto (si es necesario), que es suficiente para ocupar la compensación de la trama hasta el inicio 79 del siguiente segundo entero.

Debido a limitaciones de hardware y tiempos de carga de CPU requeridos para configurar los relojes y temporizadores de transmisión, un rastreador no puede transmitir en dos ranuras de tiempo adyacentes. La separación entre ranuras de transmisión de rastreador debe ser suficientemente grande para tener en cuenta el retardo de propagación de la señal de radio a través del aire y el tiempo requerido para que el transmisor se encienda y apague. El retardo de propagación de peor caso es de 1,2 ms. Este es el tiempo necesario para que la luz se desplace dos veces la longitud de la diagonal de la cuadrícula de navegación. Un tiempo de separación de esta duración evitará la transmisión desde un rastreador que está a 181 km del transmisor de FM y está usando sólo la sincronización de bits de FM para el sincronismo de transmisión a partir de solapamiento con la transmisión desde un rastreador que está cerca del transmisor de FM y que usa GPS para ayudar al sincronismo de transmisión. Dadas la potencia de transmisión de rastreador y las alturas de antena, una distancia razonable a la que un concentrador puede escuchar una transmisión de rastreador será de aproximadamente 30 km. Por tanto, el tiempo de separación debe soportar aproximadamente 211 km o 0,7 ms. Se requiere que el tiempo de apagado/encendido de radio sea menor de 0,1 ms. Así, el tiempo de separación total entre las transmisiones de rastreador debe ser al menos de 0,8 ms.

El paquete de datos de rastreador normal requiere 90 bits de datos (incluyendo 24 bits de datos de usuario). Los otros paquetes de datos de rastreador requieren 90 ó 96 bits de datos. Estos requisitos de tamaño de paquete de mensaje determinan directamente los requisitos de codificación de control de errores para los paquetes. El presente diseño de codificación de errores de paquete de rastreador ejemplar usa un código (12,8) para todos los paquetes de rastreador, lo que proporciona una longitud de paquete total de 144 bits con 96 bits de datos para todas las ranuras de tiempo.

Los rastreadores usan la sincronización de bits de intervalo de un segundo en la difusión de FM para su sincronismo de transmisión. El tiempo de transmisión tiene una precisión de hasta un microsegundo. En el presente enfoque, el rastreador estima el tiempo de segundo entero, a partir del tiempo de evento de sincronización de bits de difusión de FM recibido. Entonces se conocerá el valor de temporizador de una TPU (es decir, unidad de procesamiento de tiempo del microprocesador 68332 usado en los rastreadores, los CCS y concentradores de redes) para cada segundo entero. A partir de eso puede calcularse el valor de temporizador de TPU para el inicio del tiempo de transmisión del rastreador. La TPU está programada para imponer la clave de transmisión para iniciar el reloj de datos de salida de forma precisa al comienzo del tiempo de ranura de transmisión, y para eliminar la imposición de la clave para detener el reloj de datos cuando el mensaje está completo.

Para la temporización de datos en el concentrador de red (por ejemplo, 11-1, que va a describirse en mayor detalle en la descripción subsiguiente de la figura 31, pero para los fines actuales se hace ahora breve referencia al último), se usa un procesador 80 de señal digital (microprocesador DSP) en el concentrador, para demodular los datos de mensaje recibidos desde los rastreadores de vehículo por el receptor 81 de UHF del concentrador, y proporcionarlos a la CPU 82 de concentrador. La CPU 82 determina el tiempo de TPU (del microprocesador 83 68332 de Motorola) para el segundo entero, basándose en la sincronización de bits de difusión de FM recibida en el receptor 85 de FM. Los dos receptores 81, 85 y el DSP 80 están en una tarjeta 86 de RF del concentrador. La CPU 82 señala a la DSP 80 que comience a muestrear datos de UHF al comienzo de cada ranura de tiempo de transmisión. Entonces, el DSP recopila los datos, recupera el reloj de bits y muestrea los bits. Realiza descodificación Miller, desentrelazado y detección de errores (12,8), para hasta 13 retardos de bits diferentes, para soportar el retardo de la velocidad de la luz desconocido del rastreador al concentrador. Se selecciona el retardo de bits con el menor número de palabras de código con errores y esos datos se temporizan a la CPU 82, para su transmisión por el concentrador de red al servidor 42 de NDC (figura 3) en el NDC 10, a través de un módem 87 u otra opción de conectividad. El DSP 80 debe completar todo su procesamiento en la ventana de 20 milisegundos disponible para cada transmisión de rastreador.

Como se describió antes en el presente documento, cada segunda trama se divide en ranuras de transmisión de paquete de rastreador de longitud fija. Puesto que el número de ranuras dentro de una trama es también fijo, los rastreadores en el sistema de la invención deben compartir estas ranuras de transmisión. La mayor parte de los rastreadores transmiten su información de datos de usuario, posición y/o estado de forma periódica. En consecuencia, se selecciona un esquema de asignación de ranura periódico para su uso mediante el que compartir ranuras individuales dentro de una trama a través de un intervalo de tiempo.

En este esquema de asignación de ranura periódico, las ranuras individuales están asociadas a intervalos de repetición. Esto permite, a los rastreadores con una tasa de actualización periódica común, compartir una ranura específica a través de un intervalo (equivalente a la tasa de actualización periódica común) de tiempo que contiene múltiples tramas y que es un divisor de 3600. La figura 9 ilustra un intervalo de repetición para varias ranuras de transmisión individuales para paquetes de mensaje de rastreador, que muestra la relación del intervalo de repetición con ranuras, tramas y ciclos de trama. El ciclo 90 de trama está constituido por una multitud de tramas (por ejemplo, 90-1,..., 90-i,..., 90-n), como se mencionó anteriormente. Cada trama contiene una multitud de ranuras 91, que se asignan a las transmisiones de mensaje de rastreador según el esquema. El índice de intervalo para el intervalo 92 de repetición asociado con la ranura 0 es diferente del índice de intervalo para el intervalo 93 de repetición para la ranura 1, y así sucesivamente para las ranuras 2,..., n-2, n-1, n. El índice de intervalo mostrado puede calcularse usando la siguiente ecuación:

Índice de intervalo de repetición = (ID de trama) mod (longitud de intervalo)

Se asigna a los rastreadores un intervalo de repetición principal y/o intervalos de repetición auxiliares múltiples, para transmitir sus datos de rastreo. Los rastreadores transmiten los datos de rastreo durante su intervalo de repetición principal, hasta que el servidor de NDC les informa de que dejen de transmitir, o hasta que cambia el estado del rastreador (por ejemplo, se conmuta a modo de baja potencia). Los intervalos principales sólo se asignan a rastreadores con servicio de rastreo continuo o LOT. Los rastreadores transmiten sus datos de rastreo durante intervalos auxiliares para un número de veces especificado, a menos que su estado cambie o el servidor de NDC les informe de otra cosa. Pueden asignarse uno o más intervalos de repetición auxiliares a rastreadores de todo tipo de servicios.

Como se indica en la figura 9, cada intervalo de repetición se define por una ranura, un índice de intervalo de repetición, y una longitud de intervalo. Además, los intervalos de repetición auxiliares tienen una cuenta de intervalo. Puesto que un rastreador puede calcular el ID de trama usando el segundo de GPS, el índice de intervalo de repetición puede calcularse también usando la longitud de intervalo de repetición y el ID de trama. Los rastreadores transmitirán su información de rastreo en su ranura asignada durante la trama cuando (ID de trama) mod (longitud de intervalo) sea igual a su índice de intervalo asignado. Los rastreadores proporcionan las actualizaciones del intervalo de repetición auxiliar un número de veces de cuenta de intervalo. Los rastreadores a los que se asigna un intervalo de repetición auxiliar con una cuenta de intervalo de -1 proporcionarán actualizaciones de rastreo indefinidamente durante su intervalo de repetición asignado.

Como se ha señalado anteriormente, pueden manejarse por sondeo intervalos de actualización muy largos (por ejemplo, más largos que 3600 segundos). Los rastreadores que tienen necesidades de actualización tan largas no tienen un intervalo de repetición continuo asignado, sino que sólo transmiten en respuesta a órdenes desde el servidor de NDC. Las tasas de transmisión de intervalo de repetición de actualización de rastreador se resumen en la tabla 34 (apéndice B).

Puesto que las ranuras dentro de una trama están asociadas dinámicamente con un intervalo de repetición, de modo que los rastreadores con una tasa de actualización de rastreo común pueden compartir una ranura a través de un intervalo de tiempo, el servidor de NDC usa un conjunto de algoritmos de asignación de ranura de intervalo de repetición, para asociar dinámicamente ranuras con intervalos de repetición, según sigue.

Inicialización

Hacer que todas las ranuras sean ranuras de entrada de red.

Añadir un rastreador a un intervalo de repetición deseado para una cuenta de intervalo deseada:

1)

Añadir un rastreador al mejor intervalo de repetición disponible:

\bullet

Buscar una ranura asociada con el intervalo de repetición deseado con la menor cantidad de espacio disponible,

\bullet

Si se encuentra un intervalo de repetición disponible, añadir el rastreador al intervalo de repetición para la cuenta de intervalo deseada y ajustar el estatus de intervalo como igual al asignado,

\bullet

Si el rastreador no se añadió a un intervalo de repetición, ir a la etapa 2,

\bullet

Si no, conceder la solicitud.

2)

Asociar el intervalo de repetición deseado con una ranura de entrada de red disponible.

\bullet

Buscar una ranura de entrada de red disponible,

\bullet

Si se encuentra una ranura de entrada de red disponible, asociar la ranura con el intervalo de repetición deseado,

\bullet

Si no, si el intervalo de repetición # a la longitud de ciclo de trama, cambiar el intervalo de repetición deseado al siguiente intervalo de repetición disponible. Ir a la etapa 1.

3)

Añadir el rastreador al intervalo asociado con una ranura en la etapa 2.

\bullet

Añadir el rastreador al intervalo para la cuenta de intervalo deseada,

\bullet

Conceder la solicitud.

Encontrar el ID de rastreador para un paquete recibido (y disminuir la cuenta de intervalo si es necesario):

1)

Usar el número de ranura de paquete para determinar si la ranura está asociada con un intervalo de repetición.

2)

Si la ranura está asociada con un intervalo de repetición, determinar el ID de rastreador usando el índice de intervalo, reinicializar la cuenta de actualización que falta, disminuir la cuenta de intervalo si es necesario, ajustar el estatus de intervalo a activo, y liberar la ranura si es necesario.

\bullet

Calcular el índice de intervalo: (ID de trama de paquete) mod (longitud de intervalo)

\bullet

Usar el índice de intervalo para determinar el ID de rastreador.

\bullet

Ajustar la cuenta de actualización que falta a 0.

\bullet

Si la cuenta de intervalo es * a -1, disminuir la cuenta de intervalo.

\bullet

Si la cuenta de intervalo = 0, eliminar el rastreador del intervalo de repetición. Si ningún otro rastreador está asociado con este intervalo de repetición de ranura, convertir esta ranura para que sea una ranura de entrada de red.

3)

Si no, la ranura es una ranura de entrada de red. El ID de rastreador debe estar en el paquete de rastreador.

\global\parskip0.970000\baselineskip

Procesar la ranura vacía:

1)

Usar el número de ranura de actualización de paquete que falta, para determinar el tipo de ranura.

2)

Si la ranura está asociada con un intervalo de repetición, aumentar la cuenta de actualización que falta de rastreador.

3)

Si el estatus de intervalo = estatus de intervalo o asignado = activo, sondear el rastreador.

4)

Si el estatus de intervalo = asignado, retransmitir la asignación de ranura de intervalo de repetición.

\vskip1.000000\baselineskip

Eliminar el rastreador del intervalo de repetición:

1)

Buscar la ranura asociada con el intervalo de repetición del rastreador.

2)

Eliminar el rastreador de intervalo de repetición.

\bullet

Ajustar el estatus de intervalo = vacío.

\bullet

Enviar el paquete base al rastreador para purgar el intervalo de repetición asignado.

3)

Si ningún otro rastreador está asociado con este intervalo de repetición de ranura, convertir la ranura para que sea una ranura de entrada de red.

\vskip1.000000\baselineskip

El servidor 42 de NDC mantiene, en memoria, la información relativa a la relación entre rastreadores, ranuras, e intervalos de repetición, como una forma de almacenamiento de asignación de ranura de intervalo de repetición. La figura 10 es un diagrama que ilustra la relación de entidad de ranura de intervalo de repetición, con las notaciones de diagrama en las que:

caja = entidad

óvalo = atributo

caja doble = entidad débil

subrayado = clave

diamante = relación

subrayado discontinuo = clave parcial

diamante doble = relación débil

óvalo discontinuo = atributo derivado

\quad

(x, y) = (mínimo, máximo)

\vskip1.000000\baselineskip

También, las restricciones no capturadas son según sigue:

1 <= longitud de intervalo <= longitud de ciclo de trama

La longitud de intervalo es un divisor de la longitud de ciclo de trama

Índice de intervalo = (ID de trama) mod (longitud de intervalo)

Si la cuenta de intervalo = -1, los rastreadores proporcionan actualizaciones indefinidamente.

Estatus de intervalo = {vacío, asignado, activo, inactivo}

Tipo de intervalo = (principal, auxiliar, ninguno)

\vskip1.000000\baselineskip

Así, por ejemplo, la relación de "solicita entrada de red en" (diamante 100) en la figura 10 indica que los rastreadores pueden solicitar la entrada de red en las ranuras (cuadro 101 doble) que no están asociadas con un intervalo de repetición (cuadro 102 doble). Por tanto, deben notificarse las ranuras de entrada de red válidas a los rastreadores antes de intentar solicitar la entrada de red. Y la relación de "proporciona actualizaciones en" (diamante 103) indica que los rastreadores proporcionan actualizaciones de rastreo en intervalos de repetición (cuadro 102 doble). Además, los atributos como el tipo de intervalo (óvalo 104), la cuenta de intervalo (óvalo 105), el estatus de intervalo (óvalo 106) y la cuenta de actualización que falta (óvalo 107) están asociados con esta relación. La cuenta de intervalo indica el número de intervalos de repetición que el rastreador debe transmitir su información de rastreo. La cuenta de actualización que falta indica el número de veces sucesivas que un rastreador no ha conseguido proporcionar su actualización de rastreo durante su intervalo de repetición asignado. El estatus de intervalo es un tipo enumerado, que indica si un intervalo está vacío, asignado, activo, o inactivo. El tipo de intervalo es un tipo enumerado, que indica si un intervalo de repetición con un estatus no vacío es un intervalo principal o auxiliar o no se ha asignado ningún intervalo.

\global\parskip1.000000\baselineskip

El formato de bloque de mensaje de rastreador de los datos transmitidos por los rastreadores está constituido por un bloque de datos de bit entrelazado y codificado mediante codificación de errores. Puesto que el receptor/transmisor de UHF requiere que los datos contengan cambios de estado frecuentes de modo que el lazo de seguimiento de fase (PLL) no siga los datos, los datos de transmisión están codificados en línea Miller para garantizar tal contenido de cambios de estado.

Los requisitos de tamaño de datos básicos para la información transmitida por los rastreadores, y los requisitos de espacio mínimo para el estado del rastreador, el estatus de la red, y las respuestas de orden de red se definen según sigue. El estado del rastreador está constituido por posición, velocidad, y dirección. Como se ha expuesto anteriormente, la cuadrícula de navegación del sistema PROTRAK para la presente realización preferida tiene aproximadamente 262 km de lado. La cuadrícula se divide en 1024 zonas de cuadrícula de 8,192 km por 8,192 km. La posición suministrada por el rastreador está constituida por una zona de cuadrícula y una desviación hacia la zona desde la esquina suroeste. La cuadrícula de navegación nominal es cuadrada, pero pueden usarse otras formas, tales como cuadrículas de forma irregular, si se desea o es más adecuado en una configuración de sistema/red particular. La formación irregular puede conseguirse disponiendo zonas en patrones únicos.

La figura 11 es un diagrama de una cuadrícula de navegación nominal, para una latitud de 45 grados en el centro. Debe observarse que, en la práctica, (aunque no se muestre en la figura idealizada) la curvatura de la Tierra hace que la cuadrícula sea más amplia en latitud en el norte que en el sur. Las líneas de longitud constante que delimitan la cuadrícula están, aproximadamente, 3 km más cerca entre sí en el extremo norte que en el extremo sur de la
cuadrícula.

Para una cuadrícula dada, se proporciona la latitud y longitud (\Phi_{0}, \lambda_{0}) del centro de la cuadrícula a los rastreadores por el NDC en el paquete de identificación de cuadrícula. El rastreador calcula su latitud y longitud, (\Phi, \lambda), y a continuación calcula la desviación desde el centro de la cuadrícula \Delta\Phi= \Phi - \Phi_{0} y \Delta\lambda= \lambda -\lambda_{0}. Las posiciones delta norte y este desde el centro de la cuadrícula son:

2

\vskip1.000000\baselineskip

en las que \rho_{0} y \nu_{0} son los radios de curvatura de la Tierra:

3

en las que a el semieje mayor de la Tierra y e es la excentricidad de la Tierra.

\vskip1.000000\baselineskip

Por ejemplo, la esquina inferior izquierda del cuadrado de 8,192 km que contiene la posición es:

4

\vskip1.000000\baselineskip

La desviación en el cuadrado es:

5

\vskip1.000000\baselineskip

Para la cuadrícula de navegación cuadrada nominal, el número de zona de 8 km se calcula como:

6

El NDC calcula la latitud y longitud originales añadiendo las desviaciones norte y este al norte y estas coordenadas de la esquina SO de la zona indicada por el rastreador usando las siguientes ecuaciones:

7

Entonces calcula la latitud como:

8

Entonces la longitud puede calcularse como:

9

La latitud y longitud completas se proporcionan al CCS aplicable por medio de datos de mensaje desde el rastreador al/a los concentrador(es) de red que se retransmiten al NDC y a continuación al sitio de cliente.

La cantidad de datos requerida para describir el estado del rastreador es de 48 bits. El número de ID de zona requiere 10 bits. Las desviaciones norte y este dentro de la zona requieren, cada una, 11 bits, para una resolución de 4 metros. La velocidad requiere 7 bits, para una resolución de 0,5m/s (aproximadamente 1,1 mph) y un valor máximo de aproximadamente 143 mph. El rumbo requiere 7 bits para una resolución de 0,015625 de semicircunferencia (aproximadamente 2,8 grados). Se definen dos bits de validez de datos de estado. Pueden proporcionarse dos sobrantes adicionales, para hacer que los datos de estado se ajusten simplemente en un "bloque de datos de estado de rastreador" de 48 bits (cuyas definiciones de byte/bit se resumen en la tabla 35).

Se requiere un "bloque de datos de estado reducido" (definiciones de byte/bit resumidas en la tabla 36) de modo que los rastreadores pueden proporcionar su número de ID completo de rastreador, responder a mensajes de usuario y/o a órdenes de NDC, y proporcionar datos de usuario. Este bloque de datos contiene sólo una posición de baja resolución (8 metros), y requiere 34 bits.

Los rastreadores usan un "código de estatus de la red" (definiciones en la tabla 37) para entrar y salir de la red de RF. Pueden proporcionarse códigos adicionales, para automatizar cambios de servicio de rastreo. En la presente realización ejemplar, se definen nueve códigos de estatus de la red, de un total disponible de 32.

La mayoría de los paquetes de datos proporcionan espacio para los datos definidos por el cliente que han de proporcionarse a los CCS. El NDC pasa simplemente los datos a través del cliente, siendo el contenido de los datos específico para las necesidades de los clientes respectivos. Los datos de usuario están constituidos por un mínimo de 1 byte, y pueden ser tan largos como un paquete de transmisión de rastreador completo. Todo esto lo define el usuario, y se hace referencia a los datos de usuario, en este caso, como el "bloque de datos de usuario"

Los rastreadores acusan recibo de los mensajes de texto, mensajes predefinidos, datos de usuario, y mensajes de expedición de sitio, para indicar su recepción. Además, los mensajes de texto, mensajes predefinidos, y mensajes de expedición de sitio pueden requerir dos respuestas, una siendo una recepción de retorno que indica cuándo se leyó el mensaje, e indicando la otra la respuesta de tecla programable del destinatario. Los acuses de recibo/respuestas se envían al servidor de NDC en un bloque de "acuse de recibo de mensaje/respuesta" (tabla 38).

Se usa un número de ID de paquete para identificar cada paquete. El ID de paquete requiere 4 bits, para un total de 16 tipos de paquete diferentes. Los primeros 4 bits de cada paquete se reservan para el bloque de ID.

Los formatos de paquete de datos de rastreador incluyen lo siguiente. El bloque de datos de transmisión de rastreador está constituido por un único paquete de datos, teniendo cada uno de los cuales 96 bits de longitud para un bloque codificado mediante codificación de errores (12,8). Inicialmente, todos los rastreadores deben enviar un paquete de "solicitud de entrada de red" para entrar en la red de RF. Este paquete permite a los rastreadores solicitar su ranura de intervalo de repetición principal o un único intervalo de repetición auxiliar.

Una vez en la red de RF, los rastreadores pueden enviar varios tipos de paquete diferentes dependiendo del estado del rastreador. El paquete normal usado por los rastreadores periódicos es un paquete de estatus y estado. Los rastreadores usan también un paquete de estatus y estado corto cuando el servidor de NDC solicita a los rastreadores que proporcionen su número de ID de rastreador. Los rastreadores que necesitan enviar una gran cantidad de datos de usuario pueden usar el paquete de "datos de usuario" y/o el paquete de "datos de usuario cortos" durante su intervalo de repetición. Cuando los rastreadores necesitan enviar su número de ID de rastreador, su información de posición, y sus datos de usuario, puede usarse un paquete de datos de "datos de usuario de estado reducidos y estatus". Los rastreadores que necesitan acusar recibo de datos de usuario o acusar recibo/responder a mensajes de texto/predefinidos pueden usar paquetes de "respuesta de mensaje" y de "datos de usuario".

Los tipos de paquete de rastreador se identifican por ID de paquete, proporcionando espacio para 16 tipos de paquete diferentes (resumidos en la tabla 39). Los bits y bytes de datos no usados o sobrantes en los paquetes se ajustan a cero. Los paquetes están constituidos por bloques de datos empaquetados en bits, cada uno de los cuales se ha definido anteriormente en el presente documento.

Los módulos de rastreador usan un paquete de "solicitud de entrada de red" (definiciones de bit mostradas en la tabla 40) para entrar en la red de RF. Los rastreadores pueden solicitar su ranura de intervalo de repetición principal o una ranura de intervalo de repetición auxiliar de uso único. Antes de que se permita a un rastreador enviar una solicitud de este tipo, debe recibir un paquete base de "ranuras de entrada de red disponibles" y continuar recibiendo satisfactoriamente la difusión base de FM hasta que envíe un paquete de "solicitud de entrada de red". De las ranuras de entrada de red disponibles, los rastreadores generarán un número aleatorio para seleccionar la siguiente trama para enviar la solicitud, y generarán un segundo número aleatorio para seleccionar una ranura disponible. Para cada número aleatorio generado, los rastreadores pueden usar su ID de rastreador. Un rastreador reenvía la solicitud si no recibe una asignación de ranura de intervalo de repetición (RI) dentro de 60 segundos después de enviar una solicitud de entrada de red.

Puesto que es posible que múltiples rastreadores puedan hablar dentro de la misma ranura, el paquete de "solicitud de entrada de red" indica el tipo de ranura de RI y el ID de rastreador múltiples veces para permitir al servidor de NDC determinar si el paquete es válido. Los rastreadores deben purgar su ranura de RI principal antes de enviar un paquete de "solicitud de entrada de red". Por ejemplo, un rastreador que ha estado en modo de "baja potencia" purgará su ranura de baja potencia antes de enviar la solicitud de entrada de red. Esta regla permite al servidor de NDC liberar ranuras de RI reasignadas asociadas con un rastreador que solicita entrada de red.

Un paquete de "estatus y estado" es el paquete normal transmitido por los rastreadores periódicos. Este paquete contiene el vector velocidad, la posición del rastreador de resolución completa, información de estado de red, y cinco bytes de datos de usuario. Las definiciones de bit de paquete de "estatus y estado" se muestran en la tabla 41.

Un paquete de "datos de usuario fiables" (definiciones de bit en la tabla 42) proporciona varios bytes de datos de usuario. En lugar de proporcionar información de posición durante su intervalo de repetición asignado, un rastreador puede utilizar este paquete de datos de usuario para enviar diez bytes de datos de usuario de uso único. Si es necesario, puede solicitarse una ranura intervalo de repetición de uso único, para enviar/reenviar este paquete.

Tras recibir un paquete de "datos de usuario fiables", el servidor de NDC difunde un mensaje de "acuse de recibo de respuesta de mensaje" con el mismo ID de secuencia de datos de usuario. Los rastreadores deben conservar una copia de cada paquete de "datos de usuario fiables" hasta que el servidor de NDC acuse recibo de ello satisfactoriamente. Si no se recibe un acuse de recibo en 2 minutos, el rastreador reenviará el paquete de datos de usuario.

Los rastreadores difunden un paquete de "estatus y estado corto" (definiciones de bit ilustradas en la tabla 43) durante su ranura de transmisión normal cuando el servidor de NDC solicita que los rastreadores envíen su estado. Contiene el vector velocidad y la posición del rastreador de resolución completa, un byte de datos de un usuario, e información de estado de red.

Un paquete de "datos de usuario cortos fiables" (mostrando la tabla 44 sus definiciones de bit) se transmite para proporcionar varios bytes de datos de usuario. En lugar de proporcionar información de posición durante su intervalo de repetición asignado, un rastreador puede emplear este paquete de datos de usuario para enviar seis bytes de datos de usuario de uso único. Tras recibir un paquete de "datos de usuario fiables", el servidor de NDC difunde un mensaje de "acuse de recibo de respuesta de mensaje", con el mismo ID de secuencia de datos de usuario. Los rastreadores deben conservar una copia de cada paquete de "datos de usuario fiables" hasta que el servidor de NDC acuse recibo satisfactoriamente de ello. Si no se recibe un acuse de recibo en 2 minutos, el rastreador reenvía el paquete.

Los rastreadores usan un paquete de "estatus y datos de usuario de estado reducidos" (definiciones de bit mostradas en la tabla 45) para proporcionar un estatus y estado reducidos con datos de usuario. El paquete contiene estado de red, el número completo de ID de rastreador, datos de estado reducidos, y datos de usuario.

Un paquete de "respuesta de mensaje y datos de usuario" (definiciones de bit mostradas en la tabla 46) se difunde durante la ranura de transmisión de normal de un rastreador. Este paquete proporciona tanto un acuse de recibo/respuesta como datos de usuario. Si es necesario, los módulos de rastreador pueden elegir solicitar una única ranura para proporcionar esta respuesta al servidor de NDC de forma más rápida que esperar a su ranura de transmisión normal para enviar el paquete. Pueden asignarse ranuras individuales a un rastreador, usando un paquete de "solicitud de entrada de red".

Un paquete de "respuesta de mensaje corto y datos de usuario" (tabla 47) se difunde durante una ranura de transmisión de rastreador normal, cuando el servidor de NDC solicita que los rastreadores envíen su ID de rastreador. Este paquete contiene el ID de rastreador de 30 bits completo, un acuse de recibo/respuesta, y datos de usuario. Como en el caso del paquete de "respuesta de mensaje y datos de usuario" ordinario analizado anteriormente, si es necesario, los rastreadores pueden elegir solicitar una ranura individual para proporcionar esta respuesta al servidor de NDC de forma más rápida que usando su ranura de transmisión normal. Pueden asignarse ranuras individuales a un rastreador usando, un paquete de "solicitud de entrada de red".

Un mensaje de "expedición de sitios" desde la oficina de expedición de clientes (a través de un CCS) indica al rastreador el área de un sitio de trabajo. Por consiguiente, el rastreador puede determinar cuándo el rastreador ha llegado a o ha salido de un sitio de trabajo. Un rastreador usa un paquete de "estatus de sitio" (tabla 48) para indicar llegada/salida a/de un sitio de trabajo. Este paquete indica el ID de rastreador, el ID de secuencia de mensaje (originalmente asociado con el mensaje de expedición de sitios), el estatus de llegada/salida, la hora de llegada/salida, la fuente de estatus de llegada/salida, y los datos de usuario.

La geocodificación con datos de mapeo puede no siempre ser precisa. Por tanto, no siempre se puede determinar si un rastreador ha alcanzado el sitio de trabajo usando la latitud/longitud esperada para una dirección. El rastreador envía un paquete de "estatus de sitio" basándose en latitud/longitud si se produce llegada/salida (usando los valores de latitud/longitud en el mensaje de "expedición de sitios") para permitir al usuario indicar la llegada/salida de manera manual. El bit de fuente de sitio en este paquete indica cómo se determinó la llegada/salida. Inicialmente, el paquete de "estatus de sitio" puede enviarse dos veces para la llegada y dos veces para la salida, usando las dos fuentes de estatus. Si es necesario, los rastreadores pueden en este caso elegir también solicitar una ranura individual, para proporcionar esta respuesta al servidor de NDC de forma más rápida que lo que sucedería usando su ranura de transmisión normal. Las ranuras individuales pueden asignarse a un rastreador usando un paquete de "solicitud de entrada de red".

Se envía un paquete de rastreador de "prueba incorporada" (BIT), para dotar al NDC de información acerca de rastreadores, para ayudar a probar el sistema y para determinar si los rastreadores están funcionando de manera apropiada. A una tasa de transmisión especificada en el paquete base de "config ranura de RI", los rastreadores proporcionan uno de los paquetes de "BIT" válidos en una ranura auxiliar solicitada por cada rastreador. Cada tipo de paquete de "BIT" debe enviarse en rotación. Si es necesario, la rotación del tipo de paquete de "BIT" puede modificarse para suministrar información de prueba incorporada urgente. Las definiciones de bit para el paquete de "BIT" se muestran en la tabla 49, y los diversos tipos de bloques de datos de paquete de "BIT" se muestran en las tablas 50 (sistema de RF y red, tipo = 0), 51 (vehículo y entorno, tipo = 1), 52 (navegación, tipo = 2), 53 (versión, tipo = 3), y 54 (mezcla preparada, tipo = 4). Todos los valores suministrados en un bloque de datos de paquete de "BIT" indican los valores registrados desde que el último paquete de "BIT" del mismo tipo de paquete se suministró al servidor de NDC.

Cuando un rastreador recibe un mensaje predefinido, analizado anteriormente en el presente documento, muestra el mensaje conocido asociado con el ID/CRC de 16 bits de mensaje predefinido especificado. Sin embargo, si el rastreador no conoce el mensaje asociado con ese ID, o determina que la CRC del mensaje conocido no coincide con la CRC en el paquete recibido, puede solicitar la definición de mensaje transmitiendo un paquete de "solicitud de definición de mensaje predefinido". Para un uso más eficaz del ancho de banda, el rastreador puede enviar este paquete en una ranura de entrada de red.

Cuando el servidor de NDC recibe este paquete de solicitud, difunde un paquete de "definición de mensaje predefinido" (tabla 55) que dota al rastreador de una pareja ID de mensaje predefinido/mensaje. Puesto que los mensajes predefinidos se definen cliente a cliente, todos los rastreadores asociados con el mismo cliente se benefician de este paquete de definición de mensaje. Por tanto, no siempre es necesario que los rastreadores soliciten el paquete de definición de mensaje del servidor de NDC, incluso cuando reciben un ID de mensaje predefinido por primera
vez.

\vskip1.000000\baselineskip

V. Sincronismo de red de Acceso Múltiple por División de Tiempo (TDMA)

Como se ha analizado en el presente documento anteriormente, una característica de la red de TDMA es que permite múltiple usuarios de un único canal o frecuencia asignando ranuras de tiempo específicas a cada usuario para usar exclusivamente para la transmisión de datos. El uso eficaz del ancho de banda en una red de este tipo requiere minimizar los tiempos de separación entre las transmisiones de cada usuario, que es tiempo malgastado. El tiempo de separación debe ser suficiente para tener en cuenta las incertidumbres en los relojes de usuario, retardos de propagación, y tiempos de encendido y apagado de transmisor. La minimización de la incertidumbre de reloj es un objetivo principal de este aspecto de la invención.

Los tiempos de encendido y apagado de transmisor están en función del hardware electrónico. En el sistema global, el hardware de interfaz de red informática de vehículo está optimizado para encenderse y apagarse en menos de 128 microsegundos. La minimización de los retardos de propagación está limitada por los retardos de la velocidad de la luz entre los vehículos y los sitios de recepción de concentrador. Se asignan, aproximadamente, 800 microsegundos en la red para las ubicaciones de vehículos cercanas/lejanas de peor caso de 240 kilómetros. Fijando estos parámetros, entonces, la atención se centra en minimizar la incertidumbre de reloj.

El diagrama de bloques simplificado de la figura 1, descrito anteriormente en el presente documento, pero al que se hace referencia de nuevo para los fines del presente análisis, ilustra toda la red inalámbrica de TDMA utilizada en la realización ejemplar de la invención. El NDC 10 mantiene una sincronización precisa de los rastreadores a bordo de los vehículos 17-1, 17-2,..., 17-n y los concentradores 11-1,11-2,... ,11-i de red, para permitir el funcionamiento de la red de TDMA. La sincronización del sincronismo de los rastreadores, entre sí y con los concentradores de red que reciben los datos transmitidos por los rastreadores, se consigue a través de la recepción de un patrón de sincronización en los datos transmitidos por la difusión de subportadora modulada, desde la estación 12 de radio de FM. Los receptores en el NDC, los rastreadores y los concentradores reciben los datos de subportadora de FM, y estas unidades alinean sus relojes internos a impulsos de sincronización contenidos en los datos.

La estimación de error para la sincronización de reloj entre cada vehículo (o más específicamente, el rastreador del mismo), por ejemplo, 17-1, y los sitios de concentrador de red, por ejemplo, 11-1, es de 10 microsegundos. Es esencial que los rastreadores tengan el tiempo correcto dentro de esta ventana, o corren el riesgo de transmitir al mismo tiempo que otro rastreador, reduciendo la posibilidad de que ninguna de las dos transmisiones se reciba correctamente. De manera similar, si los receptores de concentrador (por ejemplo, 81, figura 31) carecen del tiempo correcto dentro de la ventana de 10 microsegundos, puede que no se activen en el tiempo correcto para recibir transmisiones de rastreador.

La referencia de reloj interno, en la realización ejemplar, para cada componente de red, SCC, rastreador, receptor de concentrador, y receptor de NDC, es un oscilador de cristal de temperatura compensada (TCXO), con una estabilidad de frecuencia de 1,5 ppm. Esto significa que el reloj generará menos de 1,5 microsegundos de error en un segundo; sin embargo, la estimación de error de 10 microsegundos no se respetaría en siete segundos de funcionamiento de marcha continua. Los relojes en todos los vehículos y sitios de recepción derivarán a diferentes tasas de transmisión y diferentes direcciones. Se requiere una referencia de reloj estable para mantener todos los relojes sincronizados entre sí. Un receptor de GPS ubicado en el NDC a diferencia del sitio de transmisor, es la referencia de tiempo estable para la red de TDMA.

La figura 12 es un diagrama simplificado del lazo 110 de control de sincronismo (un lazo de seguimiento de fase (PLL) de control de sincronismo remoto) para la red de TDMA. El lazo 110 de control de sincronismo incluye una referencia de tiempo del receptor 111 de GPS, un receptor 112 de subportadora de FM, y el NTCC 47, todos ubicados en el NDC 10 (al que se hace referencia en este caso y ocasionalmente en otros lugares del presente documento como centro de control de red). El PLL 110 también incluye el SCC 48 en la estación 12 de radio de FM para controlar el sincronismo de los datos transmitidos, y el modulador 68 de subportadora para proporcionar los datos al equipo de mezclador en un transmisor 113 en la estación de radio, para difundir sobre la señal 114 de subportadora de FM a través de la torre 53 de transmisor.

Los osciladores de cristal (que incluyen los TCXO) son fuentes de tiempo relativamente precisas, pero, sin una corrección periódica, derivan a lo largo del tiempo. El receptor 111 de GPS actúa como una referencia de tiempo precisa y estable para la sincronización del sincronismo de red de TDMA, que proporciona un impulso por segundo (PPS) sobre una interfaz de salida discreta. El PPS está en un tiempo de GPS indicado por un mensaje en la interfaz de salida serie del receptor 111, normalmente sobre límites de segundo entero, y normalmente tiene una precisión de hasta aproximadamente 300 nanosegundos, cuando está sometido a disponibilidad selectiva introducida en las señales 115 de satélite de GPS.

El receptor 112 de subportadora de FM en el NDC 10, que es idéntico a los receptores de subportadora de FM usados por los rastreadores y los concentradores de red, recibe los impulsos de sincronización desde el SCC 48 en la señal 114 de subportadora de FM. El mismo hardware garantiza que se minimiza la variación en retardo a través de los receptores. El receptor 112 de subportadora determina el tiempo de recepción de los impulsos de sincronización relativos a la recepción del PPS desde el receptor 111 de GPS. La diferencia dt entre el tiempo promedio de los impulsos de sincronización y el tiempo del PPS se proporciona a través de una interfaz 116 serie al NTCC 47. El software de NTCC procesa la diferencia de tiempo, y calcula, de diferentes maneras dependiendo de su modo de funcionamiento, una orden de corrección de tiempo que va a enviarse al SCC 48. En su modo continuo normal, las correcciones de tiempo se calculan usando un lazo de control de ancho de banda bajo.

Cada segundo, el SCC 48 envía un nuevo bloque de datos, de longitud ligeramente más corta que un segundo, dejando una separación muy corta en los datos de un segundo al siguiente. Al principio de los datos, está presente una secuencia de tres impulsos de sincronización . El SCC 48 aplica las órdenes de corrección de tiempo recibidas al tiempo en que empieza a enviar el siguiente bloque de datos. La separación entre bloques de datos permite ajustar el tiempo de inicio de los datos, para que sea anterior o posterior al intervalo usado por el SCC 48 en el tiempo que se emitió la orden.

La figura 13 ilustra los tres impulsos 120, 121, 122 de sincronización de tiempo, de una longitud de 964,8 microsegundos cronometrada con precisión con un intervalo preciso de 750,4 microsegundos, transmitido por el SCC 48 (figura 12) en el inicio 125 de los datos de cada segundo. Los datos 126 de transmisión siguen inmediatamente esta secuencia de sincronización y duran 986240 microsegundos. La separación 127 resultante - aproximadamente de 8600 microsegundos de longitud, pero variando en longitud a medida que se aplican correcciones de tiempo enviadas desde el NTCC 47 al SCC 48 (figura 12) -, ocupa el resto del intervalo de un segundo hasta el inicio 128 del siguiente intervalo de un segundo.

El software de NTCC realiza la sincronización de la red a tiempo de GPS, ilustrado por los diagramas de flujo de proceso de las figuras 14A-D. El NTCC atraviesa cuatro modos operativos de alineación de tiempo, en concreto: inicialización (figura 14A), desviación basta (14B), tasa de transmisión basta (14C), y tasa de transmisión fina (14D). En el modo de inicialización (figura 14A), el NTCC 47 (figura 12) garantiza que el intervalo de reloj del que informa el SCC 48 está dentro de 10 ppm de la cuenta de un segundo nominal. En circunstancias normales, el intervalo de reloj de SCC debe estar dentro de 2,2 ppm, que es la raíz cuadrada de la suma de los cuadrados (RSS) de la precisión de 1,5 ppm de los relojes de SCC y el receptor de subportadora. Si está fuera de la ventana de 10 ppm, el NTCC 47 ordena al SCC 48 ajustar su intervalo de reloj al valor nominal. El SCC espera a que cada orden tenga efecto, y cuando está dentro de la tolerancia, ajusta el modo de alineación de tiempo a desviación basta.

El modo de desviación basta (figura 14B), el NTCC 47 toma tres muestras de la diferencia de tiempo dt entre el PPS desde el receptor 111 de GPS y el patrón de sincronización recibido en el receptor 112 de FM desde la subportadora de FM. Se calcula una desviación promedio desde el tiempo de GPS (\Sigmadt/3), a partir de los tres valores. Si la magnitud de la desviación es superior a o igual a 100 \mu s, se envía una orden al SCC 48, para desplazar el tiempo de inicio del impulso de secuencia de sincronización por la cantidad de desviación. Entonces, el NTCC 47 espera tres segundos, repite el proceso hasta que se consigue la tolerancia de 100 microsegundos y, a continuación, ajusta el modo de alineación de tiempo a la tasa de transmisión basta.

El modo de tasa de transmisión basta (figura 14C) se usa para casi alinear la desviación de tiempo de SCC y el intervalo de reloj en preparación para operación de lazo cerrado del modo de tasa de transmisión fina. La diferencia de tiempo dt de la que informa el receptor 116 de subportadora se muestrea cada segundo durante 20 segundos, y se realiza un ajuste lineal por mínimos cuadrados a las 20 muestras. El resultado del ajuste es una línea con pendiente m y desviación b:

10

donde dt está en función del tiempo, t. Una orden de tasa de transmisión se envía al SCC 48 para corregir m a cero. A continuación se envía una orden de desviación al SCC, que compensa el tiempo requerido para calcular el ajuste y el tiempo requerido para que la orden tenga efecto, un total de 23 segundos: m (20+3) + b. Una vez que la desviación promedio de las últimas tres muestras está por debajo de 20 microsegundos, se cambia el modo de alineación de tiempo a tasa de transmisión fina.

En el modo de tasa de transmisión fina (figura 14D), el NTCC ejecuta un PLL de ancho de banda bajo, para controlar de manera continua el sincronismo de red, y monitoriza el lazo de control para condiciones de error. El NTCC 47 monitoriza de manera continua los valores de dt, desviación y tasa de transmisión del reloj de SCC. Si el valor de dt tiene un error de más de 40 microsegundos durante tres muestras consecutivas, y la desviación promedio tiene un error de más de 16 microsegundos, entonces el modo de alineación de tiempo vuelve a ajustarse a desviación basta, y se elimina el indicador de sincronización. Se ejecuta un ajuste por mínimos cuadrados, de manera continua, sobre la señal de error de reloj. Si el valor promedio tiene un error de más de 8 microsegundos o la tasa de transmisión tiene un error de más de 1 ppm para 5 muestras seguidas, entonces el modo vuelve a ajustarse a tasa de transmisión basta, y se elimina el indicador de sincronización. Si se cumplen estas dos condiciones cuando el lazo no está sincronizado, entonces se ajusta el indicador de sincronización.

Un diagrama de bloques del PLL 110 de control de sincronismo en la figura 15 ilustra matemáticamente las funciones del receptor 112 de subportadora, el NTCC 47, y el SCC 48 al realizar el control de sincronismo. El ancho de banda de lazo cerrado del PLL es, aproximadamente, de 0,014 Hz, (un periodo de, aproximadamente, 70 segundos). El NTCC 47 muestrea, de manera continua, la salida de dt del receptor 112 de subportadora y ejecuta el controlador 130 de PLL para generar órdenes de tasa de transmisión para enviar al SCC 48. Las órdenes de tasa de transmisión sirven para corregir pequeños errores 131, 132 de reloj en los TCXO del SCC 48 y el receptor 112 de subportadora.

En la presente realización ejemplar, cada ordenador que recibe o transmite sobre el TDMA de red usa un microcontrolador 68332 de Motorola, un procesador de 32 bits con un núcleo 68020, con periféricos de servidor montados en chip. Uno de los periféricos es una unidad de procesamiento de tiempo (TPU, por ejemplo, mostrada en conjunción con el procesador 83 en el diagrama de bloques de concentrador de la figura 30), que tiene 16 canales de hardware especializado para medir anchos de impulso y generar relojes. Con un reloj de 20 MHz, puede realizar mediciones con una resolución de 0,2 microsegundos. La TPU se usa para detectar los impulsos de sincronización de la subportadora de FM y generar los relojes precisos para los datos transmitidos, tanto sobre la subportadora como por los ordenadores de rastreo de vehículos en la red de TDMA.

Así, la TPU detecta y sincroniza el patrón de impulso de sincronización transmitido sobre la subportadora de FM. A este respecto, el procesamiento realizado por el receptor de subportadora de NDC, el rastreador, y los receptores de concentrador de red, es virtualmente idéntico. La CPU ejecuta dos temporizadores, en concreto, un reloj de 2048 Hz para la planificación de tareas y el reloj interno de 5 MHz de la TPU (reloj de sistema dividido por cuatro). Para fines de sincronismo, se usa el reloj de 2048 Hz, para tener en cuenta la ambigüedad en el tiempo de TPU debido al desbordamiento de su contador de 16 bits cada 13 milisegundos. Las asignaciones de función de canal de TPU se muestran en la tabla 56 (apéndice B).

Con referencia a esa tabla, en operación de la TPU para la sincronización y la generación del reloj, se detecta el impulso de secuencia de sincronización ejecutando una función de acumulación de ancho de impulso/periodo (PPWA) sobre el canal 4 de TPU. La TPU interrumpe al procesador en cada flanco de caída detectado en los datos de entrada, y proporciona al procesador el tiempo de flanco de caída y el ancho del impulso anterior. Cuando el procesador detecta tres impulsos del ancho y espaciado apropiados, dentro de una ventana de tolerancia, determina el tiempo de inicio de la sincronización en las cuentas de TPU, basándose en el tiempo promedio de flanco de caída de los impulsos recibidos. El rastreador tiene dos receptores para los datos de FM. Dependiendo de la calidad de la señal disponible en ambas antenas, puede intentar detectar la secuencia de sincronización sobre el segundo canal, usando el procedimiento del canal 11 de TPU, descrito inmediatamente antes.

El inicio del patrón de sincronización se usa como una referencia por parte de todos los receptores, para generar el reloj de datos necesario para sincronizar los datos de FM en registros de desplazamiento y en la memoria de procesador, para su descodificación. Todos los elementos de red usan un algoritmo de sincronización idéntico, para garantizar que se minimiza la variabilidad en las estimaciones de tiempo. La CPU mantiene una estimación del tiempo de inicio de la sincronización, usando un PLL de ancho de banda bajo, similar al usado por el NTCC para controlar la sincronización relativa al tiempo de GPS. Las CPU en el rastreador, el concentrador de red, y el receptor de subportadora de NDC ejecutan todos un PLL de segundo orden con un ancho de banda de 0,05 Hz para crear una estimación del tiempo de inicio de la sincronización, de modo que el ruido en los datos de recepción no causa una fluctuación sustancial en el tiempo de sincronización. Permite también al procesador mantener una estimación de tiempo, que sólo se degrada lentamente en precisión (error de TCXO) cuando faltan los impulsos de sincronización, manteniendo así la capacidad de recibir y transmitir datos en condiciones de recepción de RF malas. La estimación de tiempo se usa para iniciar los relojes de datos, usando cuatro canales de TPU.

El canal 5 de TPU ejecuta una función de comparación de salida (OC), que está diseñada para generar transiciones de salida únicas o relojes continuos. Usando la estimación de tiempo de sincronización, la CPU programa el canal para emitir como salida un impulso con un retardo preciso desde ese tiempo. El canal 6 de TPU ejecuta la función de captura/cuenta de transición de entrada (ITC), que se establece para detectar cambios en una línea de entrada, e interrumpe el procesador y/o inicia el procesamiento sobre otros canales de TPU. En este caso, detecta el impulso desde el canal 5, e inicia funciones OC sobre los canales 7 y 8, que generan un reloj de bit y un reloj de byte. El reloj de bit conmuta para cada bit de recepción, y hace que cada bit se desplace a un registro de desplazamiento. El reloj de byte funciona a un octavo de la tasa de transmisión del reloj de bit y coloca por latch el byte en el procesador. Una vez que se ha registrado la entrada de todos los bits de datos, el procesador apaga los relojes en el tiempo de separación antes de los datos del siguiente segundo.

Tal como se describió anteriormente en el presente documento, el receptor 112 de subportadora de NDC (figura 12) compara el tiempo de sincronización recibido con el tiempo de PPS desde el receptor 111 de GPS, para proporcionar la medición de dt al software de NTCC 47. La medición precisa de dt se realiza conectando la señal de salida de PPS desde el receptor 111 de GPS, al canal 11 de TPU sobre la CPU del receptor de subportadora. El canal 11 ejecuta una función de ITC que detecta el impulso e interrumpe el procesador. El procesador registra el tiempo de PPS. Entonces, en condiciones normales, los tres impulsos de sincronización se detectan sobre el canal 4, y se calcula el tiempo de sincronización. Estos tiempos tienen una precisión de 0,2 microsegundos y la exactitud del TCXO, 1,5 ppm, siendo el dt simplemente la diferencia entre los tiempos.

Los rastreadores usan la estimación de tiempo de sincronización como una referencia para iniciar la secuencia de datos de transmisión. Aproximadamente un segundo antes de producirse la ranura de tiempo asignada a un rastreador, la CPU establece tareas de procesamiento para formatear los datos que han de transmitirse, carga las memorias intermedias de salida, e inicializa los canales de TPU. El canal 0 de TPU ejecuta una función de OC, que se inicializa aproximadamente 6 milisegundos antes de que comience la secuencia de transmisión. Este canal impone la línea de clave de transmisión de la tarjeta de RF, y también inicia la cadena de otros eventos de TPU requeridos para transmitir datos en la red de TDMA. La función de OC genera una única transición, al inicio de la ranura de tiempo de 20 milisegundos apropiada, encendiendo el transmisor. Esta señal se alimenta también al canal 1 de la TPU, que ejecuta la función de ITC. La detección de la transición sobre el canal 0 inicia un reloj de transmisión de datos sobre el canal 2, retardado 96 microsegundos para permitir que la potencia del transmisor se estabilice. El reloj transmite datos desde un registro de desplazamiento sobre la TPU, una interfaz periférica serie puesta en cola (QSPI, por ejemplo, véase el procesador 83, figura 30). El reloj se alimenta también al canal 3 de TPU, que ejecuta una función de ITC, para contar el número de bits transmitidos. El procesador usa la cuenta de bit de transmisión para rellenar el registro de salida de la QSPI, basándose en una interrupción desde el ITC cuando se alcanza la cuenta de salida deseada. La CPU apaga también la clave de transmisión de OC sobre el canal 0, planificando una transición opuesta de 19200 microsegundos, después de imponer la señal de clave.

La CPU de sitio de recepción de concentrador de red usa la TPU para generar la información de entramado para indicar el inicio de cada ranura de tiempo TDMA de 20 milisegundos. Basándose en el tiempo de inicio de la sincronización estimado, la CPU establece una función de OC sobre un canal de TPU, para conmutar en intervalos de 20 milisegundos precisos. Esta señal controla los tiempos de inicio del procesamiento para que un procesador de señal digital (DSP) temporice y recupere los datos, de cualquier dato recibido en cada ranura. En este caso, la TPU no puede usarse para generar la temporización de datos, puesto que los retardos de la velocidad de la luz desde los rastreadores montados en vehículo al receptor de concentrador son variables e impredecibles. El procesador de DSP (por ejemplo, 80, figura 30) realiza un procesamiento de lotes sobre los datos registrados de la ranura anterior, mientras que los datos para la presente ranura se almacenan en un banco de memoria. En la siguiente conmutación de intervalo de ranura, el DSP conmuta los bancos, y los nuevos datos se almacenan en el banco recién procesado.

El SCC es el generador del patrón de sincronización en los datos de difusión de FM que usan, como una referencia de tiempo precisa para operar en la red de TDMA, los otros elementos en el sistema. El SCC usa la misma secuencia de funciones de TPU sobre los canales para enviar sus datos a la subportadora de modulador de FM que usa el rastreador para transmitir datos en la red de TDMA Las diferencias son que el SCC transmite durante casi un segundo, y el tiempo de inicio de la transmisión se controla por orden desde el NTCC a través de un enlace de módem. El SCC se ejecuta sobre un TCXO de 10 MHz en lugar de un reloj de 20 MHz, de modo que su resolución de tiempo es 0,4 microsegundos en lugar de 0,2 microsegundos.

Cerca del comienzo de cada segundo entero, el SCC recibe una orden de corrección de reloj desde el NTCC y los datos que van a transmitirse en el siguiente segundo. Mientras está recibiendo estos datos, el SCC está transmitiendo los datos del segundo actual. El SCC formatea un flujo de bits que incluye la secuencia de impulso de sincronización al inicio, seguida de los datos. Al final del ciclo de transmisión de datos actual, la CPU establece funciones de TPU y carga la memoria intermedia de salida (también la QSPI) con los datos que van a transmitirse. Se inicializa una función de OC, para conmutar en la cuenta de intervalo de un segundo de la TPU, según ha modificado la orden de NTCC.

La orden de NTCC puede ser, o bien una desviación de uso único durante la alineación de tiempo inicial del SCC, o una orden de ajuste de tasa de transmisión, durante el modo de alineación de tiempo de tasa de transmisión fina normal. Por ejemplo, la cuenta de TPU nominal, durante un intervalo de un segundo sobre el SCC, es de 2500000. Si el NTCC determina que el reloj de SCC es 0,4 ppm más rápido, enviará una orden de ajuste de tasa de transmisión al SCC para alargar su cuenta en uno a 2500001, de modo que el reloj rápido de SCC debe contar 0,4 microsegundos adicionales para alcanzar un intervalo verdadero de un segundo. El SCC usa este intervalo hasta que el NTCC lo corrige de nuevo.

Como con el ordenador de rastreo, se usa una función de ITC sobre otro canal, para detectar la transición de OC, e iniciar una temporización de bit de OC continua sobre un tercer canal. Un cuarto canal cuenta los bits transmitidos y rellena las memorias intermedias de la QSPI, según se requiera. Una vez transmitidos todos los bits, la CPU apaga el reloj de salida e inicia una repetición del proceso.

VI. Sistema de transceptor inalámbrico eficaz en ancho de banda

Como se observó en la sección anterior sobre la red de TDMA, el uso eficaz del ancho de banda es esencial para redes de datos digitales de TDMA inalámbricas. Las técnicas empleadas según otro aspecto de la invención, que van a describirse en esta sección de la memoria descriptiva, maximizan la eficacia filtrando los datos de banda base para reducir el ancho de banda ocupado del canal y eliminando la transmisión de información de sincronización para minimizar la sobrecarga de datos no portadores de información. El filtro de banda base se implementa por un microcontrolador digital, y sustituye el flujo de datos de onda cuadrada original por transiciones determinísticas, que reducen el contenido de armónicos y mantienen los anchos de bit, independientemente de la frecuencia de entrada de datos. La adición de reloj intensivo de procesador y algoritmos de recuperación de datos en el sitio de recepción permite la eliminación de los datos de sincronización. La red usa también codificación de corrección de errores sin canal de retorno y procesamiento de diversidad de espacio, según otros aspectos de la invención, para aumentar la fiabilidad de los datos recibidos, lo que reduce el ancho de banda usado para la retransmisión de datos corruptos.

La red de TDMA de la realización ejemplar se divide en 50 ranuras de tiempo de transmisión de vehículo por segundo. Por medios descritos en la sección anterior de esta memoria descriptiva, los rastreadores y los ordenadores del receptor de concentrador de red se sincronizan todos dentro de unos pocos microsegundos de exactitud de sincronismo, de modo que los tiempos de separación entre las 50 ranuras de tiempo son mínimos. Los rastreadores mantienen una cuenta de tiempo exacta, para determinar el punto en el tiempo en el que un paquete de datos va a transmitirse. El procesamiento realizado por los rastreadores para transmitir los paquetes de datos incluye codificación por corrección de errores sin canal de retorno (FEC), entrelazado de bits, codificación por línea de retardo, filtrado premodulación, y modulación por desplazamiento de frecuencia binaria (BFSK). A la recepción del paquete, el ordenador de concentrador realiza demodulación FSK a una frecuencia intermedia (IF), muestreo digital de la señal de IF, recuperación de reloj de bit, sincronización de bits usando un proceso iterativo, y descodificación de datos. Cada segundo, se transmiten hasta 50 paquetes de datos de vehículo al servidor de red de NDC, que combina datos desde otros receptores de concentrador de red en un algoritmo de procesamiento de diversidad, y realiza descodificación FEC sobre el paquete de datos resultante.

La figura 16 es un diagrama de bloques del procesamiento de paquete de datos y TDMA de transmisión, realizado por el rastreador (ordenador de rastreo) 135 en cada vehículo. Un paquete 137 de datos está constituido por 12 bytes portadores de datos de información totales, o 96 bits. Los datos que van a transmitirse es empaquetan por bits, de manera muy condensada en la mayoría de los casos, de modo que se malgastan pocos bits entre campos de ítem de datos. El contenido de los paquetes de datos enviados por el rastreador varía, dependiendo del tipo de datos sobre los que necesita informar el rastreador; los paquetes contienen, normalmente, datos de navegación en las ranuras de informe periódicas y datos especiales, tales como informes de eventos (por ejemplo, qué está haciendo el vehículo o qué está encontrándose), información de control de red, o códigos de mensaje saliente en las ranuras de informe auxiliares.

El rastreador realiza, en primer lugar, una codificación 138 de corrección de errores sin canal de retorno (FEC) de los datos. Se emplea un código (12, 8), que usa palabras de código que tienen una longitud de 12 bits para codificar cada byte de datos. Éste es un código de corrección de error de BCH modificado, que permite al servidor corregir un bit en cada palabra de código de 12 bits. El procesador de concentrador del receptor de red usa también el código (12,8) en su algoritmo de sincronización de bits, para ubicar el inicio probable de los paquetes de datos, seleccionando la desviación de reloj que minimiza el número errores de palabra de código. El resultado de la etapa 138 de codificación FEC es un total de 144 bits de datos que van a transmitirse.

A continuación se entrelazan los 144 bits de datos, en 139, sin lo cual, cada palabra de código transmitiría en orden. Los datos inalámbricos en entornos móviles pueden corromperse por errores de ráfagas, que causan que se reciban varios bits consecutivos con error. Puesto que el algoritmo FEC puede corregir sólo un bit en cada palabra de código, una ráfaga de errores de bit haría que una palabra fuera incorregible. El entrelazado de bits garantiza que el primer bit de cada palabra se envíe en primer lugar, seguido de todos los segundos bits, y así sucesivamente, para proporcionar cierta inmunidad a los errores de ráfaga. Esto permite al algoritmo FEC corregir una ráfaga que destruya todos los primeros bits, por ejemplo, puesto que afecta sólo a un bit en todas las palabras de código en lugar de a todos los bits en una única palabra de código. En cada paquete, todas las palabras de código deben descodificarse con éxito para que el paquete tenga sentido.

Se usa un esquema de entrelazado sencillo para los datos transmitidos por el vehículo rastreador, para permitir que funcione el algoritmo de sincronización de bits usado por el receptor de concentrador. En lugar de la ordenación sencilla de todos los primeros bits, todos los segundos bits, hasta todos los duodécimos bits, el ordenamiento usado se muestra en la figura 17. Esto proporciona una profundidad de entrelazado de 11, en lugar de los 12 posibles con entrelazado sencilla, pero proporciona una aleatorización de los bits de datos, para garantizar que desplazamientos de bit sencillos en los datos recibidos causen errores en todas las palabras de código. En la figura 17, se muestra la ordenación de bit entrelazado en forma tabular: las filas son palabras de 12 bits entrelazados, y las columnas son los bits dentro de las palabras. Los bits se transmiten de izquierda a derecha y de arriba abajo. Los bits de las palabras de código de FEC originales se identifican por el formato W/B en cada posición de bit entrelazado. Estos son los bits, B, de la palabra de código, W.

Volviendo a la figura 16, tras el entrelazado, la CPU codifica los datos usando un algoritmo 140 de codificación lineal de retardo, o Miller. La codificación de retardo es similar a la codificación Manchester en que garantiza transiciones en los datos digitales codificados. Difiere en que no aumenta la tasa de transmisión de baudios máxima de los datos no codificados. Una desventaja del código de retardo es que es ligeramente más complicado de codificar que el Manchester. El código de retardo sustituye cada '1' en el flujo de datos original con una transición en el punto de bit medio; la transición comienza en el nivel de salida de bit anterior. Un '0' en los datos originales se representa por ningún cambio de estado, excepto si el bit no codificado anterior era un '0'. En este caso, el segundo '0' se codifica como un cambio de estado entre límites de bit. El algoritmo garantiza que haya tres anchos de bit distintos: 1, 1,5, y 2 veces el ancho de los bits originales. Las figuras 18A-C, que se analizarán posteriormente en el presente documento, proporcionan una comparación de una secuencia de datos original con la versión codificada en retardo de esa secuencia, y una ilustración del filtrado de la secuencia codificada en retardo.

Volviendo de nuevo a la figura 16, los datos digitales de onda cuadrada, como con la secuencia de datos original, y la versión codificada en retardo de la misma, debe filtrarse, para redondear los flancos de modo que se minimizan los armónicos que causan que el ancho de banda ocupado de los datos transmitidos sea ancho. En la presente realización ejemplar, se implementa un filtro 141 de premodulación para la versión codificada en retardo, usando un microcontrolador PIC^{TM} 16F84-10I/SO (PIC es una marca registrada de Microchip Technology Inc. de Chandler, Arizona, fabricante del dispositivo), seguido de un convertidor 142 analógico-digital (DAC), construido usando una red de resistencias precisa. Se modula la representación analógica filtrada del flujo de datos digitales original, usando modulación por desplazamiento de frecuencia, en 143, y se transmite por el rastreador desde una antena 145 del mismo, después de la amplificación en 144.

En la figura 19, se muestra en forma de diagrama de flujo el algoritmo de filtrado usado en el filtro 141 de premodulación para garantizar que hay tres anchos de bit distintos: 1, 1,5, y 2 veces el ancho de los bits originales. El microcontrolador PIC^{TM} muestrea, de manera continua, los datos digitales de entrada, buscando una transición. Cuando se produce una transición, en 147, el microcontrolador ejecuta código en línea, para emitir como salida, rápidamente, valores de byte que representan la transición como una forma de onda sinusoidal, al DAC 142. Cuando se ha completado la salida de la curva de transición, el software de microcontrolador vuelve a buscar la siguiente transición de datos de entrada.

El microcontrolador PIC^{TM} sustituye, de manera digital, cada transición de datos con una subida o bajada de media onda sinusoidal, según se requiera. La tasa máxima de transmisión de baudios de los datos codificados de retardo es 7812,5 bps. Esto es equivalente a una frecuencia máxima de datos de 3906,25Hz. En esta aplicación, el microcontrolador funciona con un reloj de 10 MHz, y tiene un ciclo de instrucción de 4 ciclos de reloj. El procedimiento para la salida más rápida de datos al DAC requiere dos instrucciones por punto, o 0,8 microsegundos. El periodo de los datos de frecuencia más alta es de 256 microsegundos. De manera ideal, cada transición se sustituiría con una media curva sinusoidal de 160 puntos (128 microsegundos divididos por 0,8 microsegundos por punto), de modo que los datos de frecuencia más alta presentes aparezcan en el modulador como una onda pura sinusoidal.

No es posible usar todos los 128 microsegundos para producir la salida de transición filtrada, debido a que debe dejarse tiempo para la cabecera de detección de transición y otras funciones. Por tanto, se usa una curva de transición de 150 puntos. Las figuras 18B y 18C, respectivamente, ilustran los datos codificados de retardo y la salida filtrada creada por el filtro de premodulación digital. Cada flanco en los datos en la versión codificada en retardo de la figura 18B se retarda, aproximadamente, 64 microsegundos. Puesto que este retardo de filtrado es constante, se tiene en cuenta en la temporización de datos de transmisión proporcionada por la CPU. La figura 20 proporciona una comparación esquemática de los espectros de potencia aproximada de los datos 137 no codificados, codificados 140 en retardo, y filtrados de las figuras 18A-C. La codificación de retardo concentra más energía, a un promedio de aproximadamente 3/4 de la frecuencia máxima. Los espectros para dos versiones filtradas se muestran en el diagrama de la figura 20, siendo uno un filtro 148 de transición de 160 puntos ideal ilustrado para fines de referencia, y siendo el otro una implementación 141 práctica de 150 puntos. Este último tiene una potencia ligeramente más alta, entre una y tres veces la frecuencia fundamental. El filtro corta sustancialmente el ancho de banda de canal requerido para transmitir los datos de TDMA FSK, por motivos señalados anteriormente.

Un filtro digital de este tipo proporciona la ventaja considerable de que su salida tiene un retardo constante, independientemente de la frecuencia de entrada, que es equivalente al retardo de fase lineal con aumento de frecuencia. Ésta es una propiedad de los filtros de respuesta de impulsos finitos digitales. Las técnicas tradicionales de filtrado de respuesta de impulso infinito, digital o analógico, tienen fase no lineal, que puede distorsionar los anchos de bit a medida que varía la frecuencia de entrada. Dependiendo de la frecuencia de corte de filtro, esto puede causar una interferencia entre símbolos. El retardo constante permite que se transmitan sin distorsión unos anchos de bit precisos. Cuando se reciben datos con anchos de bit determinísticos y repetibles, los bits y valores de bit pueden temporizarse y descodificarse de manera fiable.

En la sección de modulador de transmisor de UHF usada en el presente procesamiento de datos de rastreador ejemplar de la figura 16, el microcontrolador 141 toma la entrada de datos de transmisión (TXD) y proporciona como salida un valor de byte. Esta salida alimenta una red de escalera de resistencias Bourns 2QP16TF6235, que actúa como DAC 142. El microcontrolador 141 realiza también la tarea de modulación del transmisor de rastreador, basándose en señales cronometradas con precisión desde la tarjeta 149 de CPU.

Después del filtrado, los datos se modulan sobre una portadora de UHF en la banda de empresa de uso compartido de 450-470 MHz, sobre un canal de desviación de 12,5 KHz. El control de ancho de banda proporcionado por el filtro de premodulación es un elemento clave para permitir una tasa de transmisión de datos de 7812,5 bps sobre un canal tan estrecho, usando una técnica de modulación FSK muy sencilla. La modulación usa, aproximadamente, 2 KHz de desviación. El transmisor de rastreador tiene una salida de dos vatios.

Los receptores de concentrador de red están ubicados alrededor del área metropolitana, para recibir las transmisiones de TDMA desde los rastreadores de vehículo. La figura 21 es un diagrama de bloques del procesamiento realizado por cada concentrador 11 de red sobre las señales RF recibidas. El hardware de extremo frontal del receptor de TDMA de UHF (tarjeta 151 RF) está siempre encendido. Las señales recibidas en la antena 152 se demodulan en 153 a una señal de frecuencia intermedia (IF) de 455 KHz, que se digitaliza en 154. Un circuito 155 integrado de aplicación específica (ASIC), que realiza filtrado digital y demodulación a una señal de banda base, procesa adicionalmente la frecuencia IF. En intervalos precisos de 20 milisegundos, correspondientes a los límites entre transmisiones de vehículo, cada segmento de 20 milisegundos de la señal de banda base se muestrea (156) a una tasa de transmisión alta y se almacena en memoria.

Un procesador de señal digital (DSP) (por ejemplo, 80, figura 29) en la sección 158 de CPU del concentrador de red, se usa para extraer los datos desde la señal muestreada de banda base. El procesamiento se realiza, en un modo por lotes sobre todo el paquete de datos, después de haberlo recibido. Entre tanto, los datos que están recibiéndose se almacenan en un banco de memoria alternativo, para su procesamiento en el siguiente ciclo de 20 milisegundos. El procesamiento por lotes prevé el uso de algoritmos más potentes, porque entonces el conjunto de datos puede analizarse en su totalidad. El procesamiento en tiempo real requiere que el algoritmo recupere los datos sobre la marcha, sin el beneficio de datos de entrada posteriores. El DSP realiza la recuperación de reloj y, a continuación, ubica los datos dentro de la ventana de 20 milisegundos. Los datos recuperados se desentrelazan, y los datos para las 50 ranuras de tiempo se envían al servidor de red de NDC para su procesamiento adicional.

La recuperación de los datos es un algoritmo intensivo de procesador. Para reducir el número de bits transmitido por los vehículos, y por tanto aumentar el número de vehículos que pueden informar cada segundo, no se envían patrones de bit especiales con los paquetes de datos para que el receptor los detecte. Requerir que los patrones de sincronización de bits detecten los datos también reduce la fiabilidad en un entorno de RF móvil porque si el patrón de bits se corrompe, el paquete de mensaje no puede recuperarse, incluso si se recibe sin error. Cada transmisión de vehículo se produce en un momento muy preciso, pero la velocidad de la luz retarda su recepción con la distancia entre el vehículo y el receptor de concentrador, en hasta 800 microsegundos. El concentrador debe ubicar el inicio del mensaje dentro de la ventana de 20 milisegundos sin ayuda de patrones de sincronización de bits especiales. Para esto, usa una búsqueda iterativa que temporiza de manera secuencial la entrada de los datos con retardos cada vez mayores desde el tiempo de inicio del mensaje nominal hasta que se localiza un paquete de datos válido.

En primer lugar, el algoritmo de DSP recupera el reloj de bit (160, figura 21) para los datos recibidos, diferenciando los datos recibidos. Los datos diferenciados tendrán valores de magnitud grandes en los flancos de bit. Con codificación de retardo, los flancos de bit serán frecuentes, puesto que se garantizan transiciones en los datos. Se mide el retardo de tiempo desde el comienzo del conjunto de datos hasta cada flanco de bit aparente, módulo 64 microsegundos. El se promedia el retardo de modulo, para determinar un tiempo de flanco de reloj de datos promedio, que es aplicable para todo el conjunto de datos. Se calcula un tiempo bit medio, como una desviación de 32 microsegundos desde el retardo promedio.

Con esta desviación, los datos en la memoria intermedia se muestrean a 15625 bits por segundo (intervalos de 64 microsegundos). Esta tasa de transmisión de reloj se usa para recuperar el código de retardo, puesto que tiene transiciones en el punto de bit medio para los unos en los datos no codificados originales. Se registra la entrada de un total de 288 bits codificados en retardo.

La descodificación (161) en retardo se realiza en los 288 bits muestreados, para producir 144 bits de datos originales. Sólo ciertos patrones de bit admisibles están presentes en el código de retardo. Si un error de bit causa un patrón no válido, el patrón se descodifica a uno de los posibles bits representados por el patrón. Si un procesamiento de detección de errores posterior sobre los datos descodificados indica un error, entonces, si sólo se encontró un patrón de datos ambiguo en esta palabra de código particular durante el proceso de descodificación en retardo, se usa el otro valor de bit y se repite la detección de error. Si tiene éxito, se conserva el segundo valor de bit. Si más de un bit es ambiguo o el segundo bit tampoco consigue dar como resultado datos válidos, se conserva el valor original, y se permite que el procesamiento avance. El error de bit puede ser corregible en una fase posterior en la cadena de procesamiento de datos.

Los bits se entrelazan (162) entonces, y se comprueban para errores (163) las palabras de código FEC pero no se corrigen. La secuencia de entrelazado tiene un papel importante en este proceso. El entrelazado estándar de todos los primeros bits seguido de todos los segundos bits, etc. sólo hará que la primera o la última palabra de código sea errónea si el reloj de bit tiene un error de hasta 12 bits. Esto hace inútil el uso de detección de error para alinear el reloj de bit para ubicar los datos correctos. El esquema de entrelazado usado en este caso embrolla los datos suficientemente y los desplazamientos de un único bit hacen que todas las palabras de código tengan errores.

El número de palabras de código correctas se cuenta y se almacena. Entonces, el reloj de bit se conmuta (retarda) 64 microsegundos, y el proceso de descodificación 161 de retardo, desentrelazado 162, y detección 163 de error se repite (164). En la presente realización ejemplar, esto se realiza 12 veces, para cubrir la totalidad del intervalo de 800 microsegundos de retardos posibles. Los datos 165 descodificados en la desviación de reloj que tiene las palabras de código más correctas, tal como se determina por este procesamiento por el concentrador 11 de red de los datos de rastreador del vehículo 17 en las señales RF recibidas, se empaquetan para su transmisión al servidor 42 de NDC (figura 3).

Cada segundo, el servidor 42 recibe datos para todas las 50 ranuras de tiempo desde todos los receptores de concentrador de red. La red se diseña de modo que múltiples concentradores recibirán la transmisión de datos de cada rastreador. El servidor combina estos datos redundantes, usando un algoritmo de votación de diversidad de espacio, que aumenta la fiabilidad de los datos recibidos. Un diagrama de flujo del algoritmo de diversidad de espacio del servidor 42 de NDC se muestra en la figura 22, realizándose este algoritmo para cada una de las 50 ranuras de tiempo, en cada periodo de un segundo.

Cada paquete de rastreador tiene 12 palabras de código. El servidor usa el código FEC para detectar errores en las palabras de código proporcionadas por cada concentrador. Si al menos 6 palabras de código de las 12 no tienen errores (170), el paquete se conserva para su procesamiento (171) adicional. Se supone que si la mayoría de las palabras de código tienen errores, la probabilidad de recuperar con éxito datos válidos de todo el paquete es baja. Una vez recogidos todos los paquetes válidos para la ranura de tiempo (172), se toma una de las dos trayectorias de procesamiento.

Si la ranura de tiempo se define para informe periódico (173), entonces se aplica el algoritmo de votación de diversidad, como se indica en la trayectoria 174 de procesamiento. Los paquetes recogidos en la primera fase se suman bit a bit usando la intensidad de señal recibida de la que informa el concentrador, como un factor (175) de ponderación. Se usa la intensidad de señal como una indicación de la probabilidad de que el mensaje se reciba con éxito. Los bits puestos a uno en el paquete de mensaje se añaden a la suma, usando la intensidad de señal positiva; los bits puestos a cero se añaden a la suma, usando intensidad (176) de señal negativa. Como ejemplo sencillo, considérense las tres secuencias de bit posteriores, con sus intensidades de señal correspondientes. Después de la suma, los bits con sumas de valor positivo se descodifican como bits puestos a uno, y los bits con sumas de valor negativo se descodifican como bits puestos a cero. Si un paquete contiene un bit con una suma de cero (un empate), el paquete se descarta.

11

Resultados de votación

12

Después de la votación, se aplica corrección de errores sin canal de retorno al resultado, para corregir los errores restantes en las palabras de código (177). El código (12,8) permite corregir un error en cada palabra de código. Cada paquete contiene un código de CRC (comprobación de redundancia cíclica), de 8 bits o de 16 bits, para verificar que es improbable que el paquete tenga errores (178); sin embargo, todavía es posible que el paquete contenga errores de bit. La comprobación final sobre los datos consiste en verificar la razonabilidad de los datos contenidos en el paquete, y, si es así, el paquete se almacena (179).

Si no se define una ranura de tiempo para informes periódicos, está disponible para cualquier rastreador transmitir un paquete de "solicitud de entrada de red" para obtener una ranura de intervalo de informe principal o auxiliar. Los vehículos 17 (figura 3) mutuamente cercanos que transmiten de manera simultánea, casi con toda probabilidad se corromperán mutuamente las transmisiones. Si están ampliamente separados, los concentradores 11-1,11-2,..., 11-i, cerca de cada uno de los vehículos pueden recibir de manera fiable sus paquetes de datos de rastreador. El servidor 42 procesa los paquetes en estas ranuras de manera individual. En lugar de usar el algoritmo de votación de diversidad, el procesamiento continúa a lo largo de la trayectoria 180 (figura 22). Los paquetes de entrada de red contienen, además de la CRC, datos redundantes, lo que permite al servidor determinar, con un alto grado de fiabilidad, si el paquete es válido. En este caso, no se realiza ninguna votación pero se realizan corrección de errores sin canal de retorno (181) y comprobaciones (182) de CRC, seguidas de una determinación de validez de los paquetes de datos a partir de los datos redundantes en el respectivo paquete de "solicitud de entrada de red" (183). Si este esquema de procesamiento determina que el paquete de datos es válido, se almacena en memoria (184).

VII. Rastreador y software de rastreador

Las funciones principales del rastreador instalado en cada vehículo respectivo son navegación y comunicación de radio. Sus tareas secundarias son dar soporte a la interfaz de usuario del terminal de datos móvil (MDT), la recopilación de datos discreta y analógica, y el control de potencia de sí mismo y de los periféricos. La figura 23 es una ilustración representativa de una colocación ejemplar del rastreador 135, el MDT 190, y las antenas (incluyendo la antena 191 de recepción de FM, la antena 192 de UHF/FM, y la antena 193 de GPS) sobre un vehículo 195 de flota típico (ilustrado como un mezclador de cemento, por ejemplo). Como se ilustra, el vehículo 195 está equipado, además, para alojar diversos sensores para informar de eventos, que se describirán en otra sección de esta memoria descriptiva, más adelante.

Se emplea un ejecutivo en tiempo real, flexible pero eficaz, para dar soporte a las principales funciones del rastreador. Antes de describir el ejecutivo en tiempo real, sin embargo, se hace referencia a un diagrama de bloques simplificado del rastreador (ordenador de rastreo) 135, mostrado en la figura 24. Está constituido por dos tarjetas o secciones de circuito principales: una sección 200 de CPU y una sección 201 de interfaz de red inalámbrica, o RF. La sección 200 de CPU contiene las fuentes de alimentación para el rastreador, el microprocesador 203 principal (unidad central de procesamiento, o CPU) para realizar todo el procesamiento de datos, un conjunto de chips de GPS (que incluye un componente de extremo frontal de RF, GP2010, y un componente de correlator, GP2021, de un conjunto de chips de Plessey ejemplar) integrados con el procesador para la recepción y descodificación de señales de satélite de GPS, y la electrónica e interfaces de sensor. La sección 200 de CPU realiza la navegación (en parte a través de la sección 204 de navegación de GPS pero también a través de navegación a estima y/o coincidencia de mapas u otros sensores de navegación a través de entradas a la CPU 203), así como procesamiento de datos y procesamiento de sensor a través de la CPU 203.

La navegación estimada en un entorno de vehículo terrestre mantiene, cuando puede que los datos de GPS no estén disponibles, como resultado del enmascaramiento de satélite en túneles o por edificios altos, durante el desplazamiento del vehículo, o en un sitio de trabajo, una solución de navegación robusta. Un giroscopio (no mostrado) se monta dentro de la caja de rastreador, para detectar la tasa angular en el eje vertical. El ordenador de rastreo, que usa una tasa angular para estimar el rumbo del vehículo, está también unido a una salida de sensor de velocidad del vehículo a partir de la transmisión y hasta las luces traseras del vehículo, para indicar si la velocidad detectada está en el sentido directo o marcha atrás. El sensor de velocidad es una parte integral de otras funciones de medición de sensor, que dependen de las salidas de distancia recorrida o de la verificación de que el vehículo está estacionario o moviéndose a poca velocidad.

Como se analizará, adicionalmente, en conexión con una figura posterior, se prevén tres fuentes de alimentación (en general designadas por el bloque 205) sobre la tarjeta 200 de CPU, una primera fuente de 12 VCC, que proporciona potencia a la tarjeta de RF, una segunda una fuente de 12 VCC, que proporciona potencia al MDT y otros periféricos externos de la unidad, incluyendo sensores, y una tercera una fuente de 5 VCC para las funciones de procesamiento de la CPU 203.

La sección o tarjeta 201 de RF contiene los circuitos de radiofrecuencia (incluyendo los receptores 207 y 208, que reciben entradas, respectivamente, desde las antenas 191 y 192, montadas en vehículo), necesarios para la recepción y demodulación de datos de radiofrecuencia recibidos a través de la subportadora de FM desde la estación 12 de radio. La sección 201 de RF contiene también circuitos (en el transmisor 210) necesarios para la modulación y amplificación de datos de transmisión en la banda de UHF, usando el protocolo de red de TDMA. Sin embargo, la tarjeta de RF no realiza por sí misma ningún procesamiento de datos. En su lugar, la CPU 203 principal es responsable del procesamiento de todos los datos de banda base, para la corrección de errores sin canal de retorno de descodificación y codificación de mensaje, y la temporización de datos, en el rastreador 135.

En cuanto al software de rastreador, haciendo referencia otra vez al ejecutivo en tiempo real empleado para dar soporte a las principales funciones del rastreador, será útil señalar de nuevo que las CPU usadas en cada uno de los rastreadores y concentradores de red son sustancialmente idénticas. La CPU 82 de concentrador de red ilustrada en el diagrama de bloques simplificado de la figura 29, por ejemplo, muestra un microprocesador 68332 de Motorola con periféricos sobre chip asociados tal como una TPU, QSPI, y SCI, y un registro de desplazamiento relacionado, como constituyendo preferentemente la CPU. El rastreador 203 de CPU se corresponde con la misma. Tiene dos fuentes de interrupción periódicas para la planificación y el expedición de tareas, en concreto, un interruptor acumulador (ACCUMINT) desde el GP2021 y un temporizador de interrupción periódica (PIT) obtenido a partir del reloj de CPU. El ACCUMINT se usa para ejecutar un sencillo expedidor de tiempo real, de alta prioridad, mientras que el PIT se usa para ejecutar un planificador accionado por prioridad más lento, para la navegación de larga duración y las tareas de comunicación.

La prioridad de interrupción es:

1. TPU

nivel 6

2. SCI

nivel 4

3. ACCUMINT

nivel 3

4. PIT

nivel 2

\vskip1.000000\baselineskip

La interrupción ACCUMINT ejecuta un expedidor de alta prioridad periódico para tareas de corta duración (< 1 ms). Las interrupciones de TPU se producen a partir de eventos de TPU relacionados con comunicación y sincronismo de red. El PIT ejecuta una interrupción de tasa baja, secundaria y que debe ser la de menor prioridad, debido a que sólo se permite cuando la rutina de servicio de interrupción (ISR) de ACCUMINT se completa. El SCI genera interrupciones de UART, a partir de comunicación serie con la brújula y otros periféricos. La QSPI se usa para la transmisión de datos de vehículo, debe dársele servicio dos veces durante una transmisión de vehículo, y no genera interrupciones. Los manejadores de interrupción de TPU y SCI deben ser tan rápidos como sea posible.

El ACCUMINT se suministra por el GP2021, y se obtiene a partir del TCXO de 10 MHz, que también acciona el reloj de procesador de 20 MHz (también a partir del GP2021). La tasa de ACCUMINT se programa nominalmente para una tasa aproximada de 2048,131 Hz (el periodo es 488,25 \mus). Éste tiene un error, a partir de una tasa real de 2048 Hz, de 64 ppm. El ACCUMINT puede deshabilitarse y rehabilitarse escribiendo en un registro de GP2021. El indicador de tics (TIC) de temporizador de GP2021, que se programa para una tasa de transmisión de 8 Hz, controla cuándo están disponibles los datos de medición de GPS, y se usa para planificar el procesamiento de navegación estimada.

La estructura del manejador ACCUMINT/expedidor en tiempo real se esboza como:

300

Con la implementación de lazo de rastreo de la presente realización ejemplar, las tareas de leer los datos de acumulador y actualizar los lazos de rastreo requieren como promedio, aproximadamente, 160 \mus para 8 canales. Esto incluye la recopilación y demodulación de datos para todos los canales y el cierre del lazo de rastreo para un canal. Cada canal genera datos de acumulación en intervalos de 1 ms (aproximadamente un ACCUMINT sí y otro no). Es importante que se complete el procesamiento de actualización de lazo de rastreo para cada canal, antes de disponer de nuevos datos de acumulación para ese canal.

El planificador inicia las tareas relacionadas con la comunicación y puntualidad de la red, leyendo y almacenando datos de medición de GPS, tareas periódicas que incluyen AID y procesamiento de E/S discreto, programación de sintetizador, y cualquier otra tarea de alta prioridad y corta duración (inferior a 500 \mus).

Un indicador TIC se genera por el GP2021, e indica cuándo se han colocado por latch datos de medición de GPS. La tasa de transmisión TIC por defecto es 10 Hz. Para el rastreador; la tasa de transmisión se programa a aproximadamente 8 Hz (un periodo de 0,125000050 s), y se usa para colocar por latch datos de sensor de rueda/de cuentakilómetros además de datos de medición de GPS. La tasa de transmisión de 8 Hz permite un cálculo simple de potencias de dos para intervalos de tiempo y reduce el procesamiento de medición en un 20%. Se requieren las funciones de procesamiento de GPS para mantener la tasa de transmisión TIC en periodo con el tiempo de GPS, pero no es necesario (sobre el rastreador) alinear el TIC con el segundo entero de GPS. Como parte del procesamiento de navegación, el periodo de TIC ajustado para TIC individuales se requiere para mantener una tasa de transmisión TIC promedio de 0,125 segundos con respecto al tiempo de GPS. El expedidor ACCUMINT actualiza el intervalo de TIC según lo requiera el procesamiento de navegación.

El chip GP2021 tiene dos UART, que no generan interrupciones, de modo que deben sondearse. Cada UART tiene una FIFO (primero en entrar - primero en salir) de 8 bytes. Si la tasa de transmisión de datos en los UART está restringida a 38,4 kbps, entonces la FIFO puede llenarse aproximadamente cada 2 ms. La CPU puede dar servicio a cada UART un ACCUMINT sí y otro no, y no perder datos. Uno de los UART se usa para comunicarse con el MDT; y el otro puede usarse para un periférico adecuado.

Las tareas de comunicaciones de RF críticas en el tiempo se ejecutan según se requiera, lo que incluye configurar los canales de TPU para:

\bullet

iniciar y detener los relojes de datos

\bullet

iniciar y detener la QSPI

\bullet

encender y apagar el transmisor

\bullet

programar la TPU para detectar la siguiente sincronización de bits.

\vskip1.000000\baselineskip

Planificar estas tareas requiere unos pocos milisegundos de resolución en algunos casos.

El rastreador usa la QSPI para la transmisión de mensajes. Los datos de transmisión están codificados en línea en formato Miller, lo que requiere 288 bits de código, que van a transmitirse a 15625 bps, para un equivalente de 144 bits de datos a 7812,5 bps. La memoria intermedia de salida de la QSPI puede acumular 256 bits, de modo que la QSPI puede precargarse con 256 bits y después rellenarse con el resto del mensaje, unos pocos milisegundos después. Debe registrarse el tiempo de salida de una palabra de datos adicional (para un total de 304 bits) a la tarjeta de RF. Un preámbulo de 8 bits precede a los datos, y 8 bits siguen a los datos después de apagar el transmisor, para garantizar que el último bit de datos transmitido es bajo.

El rastreador usa la TPU para temporizar datos hacia registros de desplazamiento externos para recibir datos. Se reciben dos flujos de datos de FM desde antenas colocadas en lugares distintos. Los datos se codifican en línea en formato Miller, lo que requiere 9200 bits de código, que van a transmitirse a aproximadamente 9328,36 bps, para un equivalente de 4600 bits de datos a aproximadamente 4664,18 bps. Un preámbulo y un patrón de sincronización de 64 bits precede a los datos. Los dos flujos de datos se temporizan de manera síncrona, pero se procesan de manera independiente. Los bytes se leen desde el registro de desplazamiento sobre el flanco de caída del reloj de latch, dejando 428,8 \mus para leer los datos.

Con respecto a tareas de recopilación de datos, los eventos de TIC señalizan que los datos de medición de GPS están disponibles a partir del correlator GP2021. Cuando estos se producen, el procesador debe leer los datos antes del siguiente TIC (aproximadamente 125 ms). El procesador también lee datos de rueda/cuentakilómetros. En el ISR, los datos sólo se almacenan (el procesamiento de datos tiene lugar bajo el control del planificador de PIT).

El software de rastreador tiene también un número de tareas periódicas, de corta duración, que puede ejecutar el expedidor ACCUMINT. Éstas incluyen funciones A/D para leer datos del giroscopio y otras fuentes de datos; así como conmutación de bit para implementar interfaces serie sencillas para programar sintetizadores de tarjeta de RF y el PIC usado para el control de potencia del módulo de rastreador.

La TPU se usa para el sincronismo de comunicación de RF, la entrada de datos de RF y la temporización de salida, y las entradas de sensor de velocidad o de la rueda del vehículo. Como se describió anteriormente en el presente documento, los canales (16) y las funciones de TPU se resumen en la tabla 56 (apéndice B).

Para manejar las entradas de sensor de velocidad y de rueda a partir de la navegación estimada del sistema PROTRAK, la TPU cuenta impulsos a partir de estos sensores para medir la velocidad del vehículo. En la TPU, los canales 13 y 14 se reservan para entradas de cuadratura a partir de los sensores de rueda, los canales 12 y 15 se reservan para la dirección del vehículo y las entradas de sensor de velocidad de control de crucero, el canal 15 ejecuta una función de ITC, y el canal 12 ejecuta una función de entrada discreta. En la mayoría de los sistemas, se usa un sensor de velocidad de control de crucero.

El UART de SCI en el procesador 68332 de Motorola se usa para una interfaz de la brújula magnética u otro dispositivo de tasa de transmisión de datos relativamente baja (4800-9600 bps). Cuando está ejecutándose, el SCI genera interrupciones de transmisión o recepción en intervalos de aproximadamente 1 ms (a 4800 bps). Debe darse servicio a estas interrupciones en 1 ms.

El PIT del procesador se ejecuta a 32 Hz, y de este modo la ISR del PIT ejecuta un ejecutivo de priorización, que realiza las siguientes tareas, en el siguiente orden de prioridad:

1. tareas de planificación/sincronismo de RF y comunicación

2. Descodificación de error de datos de FM

3. Navegación estimada (DR) (propagación de solución 8 Hz)

4. Análisis sintáctico de datos de FM

5. Procesamiento de medición de GPS (mediciones de tasa de transmisión pseudoalcance/alcance, adquisición de satélite)

6. Filtrado combinado de navegación estimada/de GPS (actualización de filtro Kalman de la solución de DR)

7. Asignación de canal/visibilidad de satélite de GPS

\vskip1.000000\baselineskip

Para el ejecutivo, las tareas se planifican de manera periódica o a petición en orden de prioridad. Se permite que las tareas de alta prioridad interrumpan las tareas de prioridad inferior.

La arquitectura de la fuente de alimentación para el rastreador 135 incluye cuatro fuentes de alimentación independientes que funcionan a partir de potencia de batería de entrada (6-28 V). Con referencia a las figuras 25 y 26, que son diagramas de bloques de la distribución de potencia interna al rastreador y el resumen de distribución de potencia, respectivamente, una de estas fuentes es una fuente 215 de 5 V lineal que proporciona potencia al microcontrolador
(\mu C) 216 PIC^{TM} de Microchip, usado para el control de potencia maestra del rastreador. También mantiene una SRAM (no mostrada) alimentada de modo que se mantiene el estado de la máquina mientras el procesador está apagado.

El microcontrolador 216 funciona a una corriente muy baja y está encendido en todo momento, controlando una fuente 217 de CPU de 5 V y una fuente 218 de radio de 12 V. La fuente 217 de 5 V es una fuente de alimentación conmutada que proporciona potencia a la CPU 203, a la electrónica digital y al receptor 204 de GPS de la sección 200 de CPU. La fuente 218 de radio de 12 V suministra potencia a la tarjeta 201 de RF, y alimenta también el amplificador 219 de bajo ruido (LNA) de antena de GPS a través de un regulador 220 lineal de 5 V. Puesto que el TCXO que acciona en última instancia el reloj de CPU reside en la tarjeta 201 de RF, la CPU 203 requiere que, tanto esta fuente (218) como la fuente 217 de CPU de 5 V, estén encendidas. La última de las cuatro fuentes de alimentación independientes es una fuente 222 auxiliar de 12 V, que proporciona potencia de 12 V regulada a todos los periféricos externos (por ejemplo, el MDT 190, la brújula 230 y otros 232, figura 26), designados por 223 (en la figura 25), y potencia a un giroscopio 224, a bordo a través de un regulador 225 lineal de 5 V. La CPU 203 controla esta fuente 222 auxiliar de 12 V. El rastreador recibe también una entrada 226 discreta de 12 voltios a la CPU 203 y al microcontrolador 216, que indica que el conmutador 233 de arranque está en la posición RUN/ACC.

El microcontrolador 216 controla la potencia al rastreador 135, y, junto con la SRAM de la CPU, permanece encendido en todo momento. Estos dos extraen menos de 5 mA de corriente. Cuando la discreta de arranque indica que el conmutador está en la posición RUN o ACC, el microcontrolador 216 enciende la CPU 203 y las fuentes 217 y 218 de alimentación. Cuando el arranque está apagado, la CPU 203 puede ordenar al microcontrolador 216 que apague la potencia durante intervalos de tiempo entre 5 y 630 minutos, o hasta que se encienda el arranque, lo que suceda en primer lugar.

El rastreador 135 soporta modos de ahorro de potencia, de forma que el consumo de potencia de la batería del vehículo se minimiza cuando el arranque del vehículo está apagado, lo que también tiene implicaciones en el control de red de radio y de retención de datos. Los modos de ahorro de potencia de rastreador son:

\bullet

Todo encendido: el rastreador 135 y los periféricos externos están encendidos y operando con normalidad.

\bullet

Periféricos apagados: el rastreador 135 está encendido y operando con normalidad, pero la fuente 222 de alimentación periférica de 12 V auxiliar está apagada. Los periféricos se apagan inmediatamente o, si se desea, dentro de un tiempo T1 predeterminado, por ejemplo, 1-2 minutos después de apagar el arranque, lo que inhibe la navegación DR porque tanto el giroscopio 224 interno como la brújula 230 externa estarán apagados

\bullet

Espera: Con el arranque apagado, la CPU 203 se apaga una duración T2 de tiempo especificada previamente (por ejemplo, aproximadamente 40 minutos). Cuando la CPU vuelve a encenderse (modo de periféricos apagados), puede escuchar cualquier mensaje nuevo u otros datos, responder y a continuación apagarse de nuevo. El modo en espera permite que sistemas de sólo iniciar sesión y de rastreo continuo reciban datos desde la estación de orden, mientras el arranque está apagado. Los vehículos sólo de sondeo permanecerán en modo en espera, y no se activarán hasta que se encienda el arranque. El sistema permanece también en modo en espera si la tensión de batería cae por debajo de un límite inferior predeterminado.

\bullet

Apagado- En este modo, no se aplica potencia al rastreador.

\vskip1.000000\baselineskip

Dependiendo de los requisitos específicos del cliente, el control del modo de ahorro de potencia de rastreador puede variar, por ejemplo:

\bullet

Los operadores de vehículo de emergencias pueden desear que el sistema siempre esté en modo Todo Encendido, para permitir la capacidad del CCS para comunicarse, en todo momento (a través de la red de TDMA), con el vehículo.

\bullet

Algunos usuarios pueden preferir un enfoque de ahorro de potencia por fases, en el que los vehículos que se encienden y apagan de manera periódica, tal como los camiones de reparto, permanecen en la red mientras están apagados.

\vskip1.000000\baselineskip

La figura 27 es un diagrama que ilustra la lógica para las transiciones de estado de control de modo de potencia del rastreador 135. Las duraciones T1 y T2 de tiempo se ajustan según se desee. El tiempo en espera es el tiempo apagado dirigido por la CPU para el modo 240 en espera. Las transiciones de modo, y la operación relacionada con la red en cada modo, son según sigue.

El estado 241 apagado se alcanza cuando se retira la potencia de batería externa del rastreador. Cuando se aplica potencia de batería al rastreador, el procesador de control de potencia (microcontrolador 216) se reinicia y enciende la CPU 203 y las fuentes 218 de radio, encendiendo el rastreador pero dejando los periféricos 223 apagados (modo 242).

En el modo (243) todo encendido, las secciones 201 y 200 de RF y CPU se encienden. El sistema navegará y operará en la red de RF con normalidad. Se asignan ranuras de transmisión periódicas a los rastreadores de rastreo continuo (CT). Se asignan ranuras de transmisión periódicas a los rastreadores de rastreo de sólo inicio de sesión (LOT) si el cliente respectivo ha iniciado sesión. Sin que un cliente (es decir, abonado de flota o propietario) haya iniciado sesión, estas unidades intentarán, ocasionalmente, entrar en la red, o permanecerán en silencio hasta que el NDC notifique que su propietario ha iniciado sesión. Los rastreadores de sólo sondeo intentarán una entrada de red, y, a continuación, permanecerán en silencio hasta que se les solicite que transmitan.

Cuando el arranque se apaga, los periféricos (por ejemplo, el MDT 190, la brújula 230 magnética, si están incorporados, etc., y el giroscopio 224 interno (opcional)) alimentados por el rastreador se apagan inmediatamente, o después de que expire la duración de tiempo T1 (modo 242). La brújula y los sensores de navegación de giroscopio se apagan basándose en la suposición de que si el arranque está apagado, el vehículo no estará en movimiento. El rastreador volverá al modo 243 todo encendido si el arranque vuelve a encenderse.

Desde el modo 242 de periférico apagado, los rastreadores de LOT y CT pueden entrar en el modo 240 en espera, después de una duración de tiempo de T2 desde que se apagó el arranque. Para alcanzar el modo en espera, el rastreador solicita una ranura de red periódica de baja potencia al NDC, que tiene un intervalo de transmisión largo. Cuando se concede la ranura, el rastreador almacena los datos necesarios para un área en SRAM, guarda cualquier dato en memoria flash según se requiera, y ordena al microcontrolador 216 que apague la CPU 203 durante un periodo en espera de unos pocos minutos menor que el intervalo de transmisión de baja potencia. Los rastreadores de sólo sondeo solicitarán apagado de baja potencia al NDC. Cuando se acusa recibo de, o expira, la solicitud de apagado, el rastreador almacena los datos en SRAM y memoria flash, si se requiere, y ordena al microcontrolador 216 que apague la CPU 203 hasta que el arranque vuelva a encenderse.

Cuando el microcontrolador 216 activa el rastreador (en realidad, la CPU 203) desde el modo 240 en espera, la CPU comprueba la tensión de la batería y el estado de sistema previo almacenado en la SRAM. Si el rastreador está en una ranura de baja potencia, escuchará los datos de subportadora de FM durante una ventana de 3-4 minutos alrededor del tiempo de ranura para determinar si el NDC envía cualquier información dirigida a él. En este momento, el NDC tiene la oportunidad de enviar al rastreador un mensaje u otros datos. Una vez que se han completado todas las transacciones de red, el rastreador ordenará de nuevo al microcontrolador que apague la CPU.

Si el arranque permanece apagado durante una duración de tiempo predeterminada o cae la tensión de la batería por debajo del umbral V_{MIN} mínimo, el rastreador solicitará, en su próxima oportunidad de transmisión, un apagado de baja potencia al NDC. Cuando se acusa recibo de, o expira, la solicitud de apagado, se ordena al microcontrolador 216 que no active la CPU 203 hasta que el arranque vuelva a encenderse.

La recuperación del estado de SRAM se consigue según sigue. Puesto que todos los contenidos de las variables globales y la pila se mantienen durante el modo 240 en espera, la CPU 203 puede reiniciar un punto específico en el código, con todos los datos intactos. Esto puede realizarse si los registros, el contador de programa, y el puntero de pila se introducen en la pila, y el puntero de pila se almacena en una ubicación conocida. Debe realizarse una CRC sobre partes pertinentes de la SRAM, para garantizar la integridad de los datos al reiniciar, después de lo cual se permite que la CPU envíe una orden de apagar al microcontrolador. Al reiniciar, la CPU comprueba la CRC en la SRAM, para determinar si estaba reiniciando. Si es así, el software ajusta los indicadores apropiados, y a continuación recupera ,de la pila, el puntero y los registros de pila. Entonces puede saltar al punto en el que se quedó antes de apagarse. Si falla la CRC en la SRAM, la CPU ejecuta un arranque normal.

Cuando el rastreador se enciende, debe buscar la difusión de SCC en la subportadora de FM recibida. En condiciones normales, el rastreador tendrá información de canal, almacenada en la memoria flash, para el canal de FM principal que va a usarse, e inicialmente buscará canales y subportadoras que ha almacenado en memoria. Si no se encuentran patrones de sincronización de SCC, debe buscar sistemáticamente todos los canales y subportadoras de FM. Para ello, se realiza localización de sincronización de bits, buscando un patrón de sincronización único predeterminado. Si el evento de sincronización de bits se pierde (es decir, no se producen los tres impulsos dentro de la ventana de tiempo esperada), no se aplica ninguna corrección nueva, y se permite que el reloj funcione libremente. La estimación de tiempo se actualiza todavía, basándose en el cambio de distancia al transmisor, si los datos de navegación son válidos. Si se pierde la sincronización de bits de manera continua durante más de 20 segundos, el error en la estimación de tiempo de segundo entero puede derivar fuera de límites admisibles. Cuando esto sucede, la CPU debe reanudar la localización de sincronización de bits sobre el canal actual y otros canales de FM disponibles.

El sincronismo y temporización para la recepción de datos de FM de seguidor (y concentrador de red), se manejan como se indica por el diagrama de sincronismo y temporización de la figura 28. La CPU 203 planifica la temporización de los datos 246 de FM recibidos, para comenzar en un valor de temporizador de TPU específico, que no está directamente relacionado con el patrón 247 de sincronización de datos de FM, pero está relacionado con el tiempo de segundo entero estimado más el retardo 248 estimado de velocidad de la luz. El sincronismo en la figura se indica en unidades de TICS de 5 MHz de TPU. El flanco ascendente del reloj 250 de desplazamiento hace que los bits se desplacen en un registro de desplazamiento externo. El flanco ascendente del reloj 252 de latch coloca por latch el byte recibido en la salida del registro de desplazamiento. La CPU 203 recibe una interrupción sobre el flanco de caída del reloj de latch para leer los datos, con 428,8 \mus para leer el byte.

La diferencia 253, entre el tiempo del patrón de sincronización recibido y el tiempo en que la CPU lo esperaba, se muestra en la figura 28 a escala exagerada. La diferencia 253 es, normalmente, inferior a 20 \mus, causada por el movimiento del vehículo, errores de reloj entre el SCC y el rastreador/concentrador, y fluctuación y otros errores causados por el receptor de FM. La CPU 203 usa la diferencia promedio en los tres impulsos para corregir su estimación de corriente para el tiempo de segundo entero para el siguiente segundo.

El sincronismo, la temporización y la transmisión de datos UHF del rastreador se manejan como se muestra en el diagrama de sincronismo, temporización y transmisión de datos de rastreador de la figura 29. En la trama justo antes o durante la trama en la que el rastreador va a transmitir, el ejecutivo en tiempo real debe planificar las tareas de transmisión de datos. Las tareas se planifican para funcionar con tiempo de espera apropiado (hasta 6,5 ms) para iniciar tareas de TPU para generar cambios de estado de salida en los valores de temporizador de TPU deseados. La clave de transmisor y reloj de datos serie deben iniciarse y detenerse con precisión. Los primeros 16 bytes de los datos de salida se cargan en el registro de desplazamiento de la QSPI antes de que comience la transmisión, y la última parte de los datos se carga antes de que la QSPI se vacíe. Los tiempos indicados en la figura 29 están también en unidades de tics de temporizador de 5 MHz de TPU. Puede requerirse que el canal 3 de TPU cuente los bits de salida, de modo que el reloj de datos y la QSPI puedan detenerse fácilmente.

Por supuesto, los datos transmitidos por el rastreador incluyen información para identificar la ubicación o posición precisa del vehículo en la que está instalado el rastreador. Como se ha señalado anteriormente en el presente documento, el rastreador utiliza navegación estimada (DR) de alto rendimiento, para proporcionar datos de posición y vector velocidad del vehículo en túneles urbanos en los que se dispone de las mediciones GPS sólo de manera intermitente. Los sensores de DR incluyen medición de velocidad que, en la presente realización ejemplar, se basa preferentemente en el sensor de velocidad de control de crucero del vehículo, si está disponible, y un giroscopio de azimut y posiblemente una brújula magnética que se utilizan para la determinación del rumbo. Un sensor de marcha atrás puede ligarse a las luces traseras. Estos sensores se calibran mediante el uso de un filtro Kalman, basándose en entradas de medición en bruto corregidas por DGPS. El objetivo de exactitud para el navegador DR es del 0,2% de la distancia recorrida (probable en un 95%), después de 4 minutos de disponibilidad de medición de DGPS sobre una trayectoria de vehículo "típica".

Los requisitos del algoritmo de DR tienen en cuenta lo siguiente. La tasa de de actualización del sistema de navegación de DR, en la presente realización preferida, es, aproximadamente, de 8 Hz. Los datos de giroscopio de azimut se muestrean a una tasa alta (aproximadamente de 100 Hz) y se integran para propagar una estimación de rumbo. Los datos de cuenta de impulso de rueda o sensor de velocidad se muestrean con alta prioridad, para garantizar intervalos de etiquetado de tiempo regulares a 8 Hz, y se transforman a través del rumbo y se integran para propagar una estimación de posición.

Los requisitos de medición de GPS incluyen mediciones de pseudoalcance disponibles a partir de la sección de GPS del software a 8 Hz. Estas mediciones se muestrean y preprocesan según se requiera. Las mediciones de GPS se usan por un filtro Kalman ejecutado en intervalos de dos segundos. Se usa o bien la última medición disponible o bien un promedio de los datos de medición disponibles hasta el tiempo de actualización. Los requisitos de filtro Kalman reconocen que el filtro Kalman usado para mezclar datos de DGPS y de estimación debe soportar y estimar estados de error de sensor con suficiente fidelidad para conseguir la exactitud de navegación estimada deseada. Además, el filtro Kalman soporta alineación basta (incertidumbre de error de rumbo mayor que la de un ángulo pequeño) y opera cuando algunos sensores auxiliares (tal como una brújula) no están conectados.

Un filtro de medición en bruto debe tener estados de error de vector velocidad y de posición tridimensionales y un buen modelo de error de reloj. Los estados de error de filtro incluyen:

\bullet 3 de error de posición (NED)

\bullet 3 de error de velocidad (NED)

\bullet 1 estado de error de rumbo o ángulo de ruta

\bullet 2 ó 3 estados de error de reloj

\bullet 2 estados de error de giroscopio (factor de escala y de desviación)

\bullet 2 estados de error de cuentakilómetros (factor de escala y no linealidad de factor de escala)

\bullet 1 estado de error de alineación de la brújula

\vskip1.000000\baselineskip

Las brújulas magnéticas, normalmente, tienen características de error que varían de manera sinusoidal con el rumbo; de modo que es importante utilizar un procedimiento eficaz para manejar el error de alineación de la brújula variable. Los errores de la brújula pueden manejarse fuera de la estructura del filtro Kalman. El procesador tiene un sensor de temperatura que puede usarse para la compensación de temperatura del giroscopio.

Cuando se enciende el sistema de navegación, puede inicializarse a partir de la posición y rumbo almacenados en el apagado. Sin embargo, estos datos no son completamente fiables, por lo que las covarianzas iniciales deben ser grandes. Si el sistema tiene una brújula magnética, las mediciones iniciales de la misma pueden estar dañadas por campos magnéticos cercanos. El filtro debe poder soportar un modo "alineación basta", que normalmente implica usar estados de error que son el seno y el coseno del error de ángulo de rumbo/ruta porque la propagación de error es lineal con estos términos. Una vez que los errores seno y coseno son pequeños, el sistema puede conmutar a un único estado de error de rumbo.

El filtro Kalman propaga el modelo de error para el proceso de estimación, basándose en datos de sensor de giroscopio y velocidad. Propaga también modelos de error de sensor auxiliar, que incluyen errores de reloj de GPS y errores de alineación de la brújula. Las mediciones disponibles para el filtro incluyen:

1) Pseudoalcance de GPS

2) Rumbo magnético de brújula

3) Desviación de giroscopio a vector velocidad cero

\vskip1.000000\baselineskip

Las mediciones de vector velocidad cero (tasa angular cero) están disponibles sólo cuando el vehículo se detiene.

La propagación de error de filtro Kalman y el ciclo de actualización pueden requerir más de un segundo para completarse. Cuando se inicia el procesamiento de filtro, los datos de medición y la información de modelo de error deben colocarse por latch en software, de modo que la propagación de solución de navegación estimada de 8 Hz pueda continuar en tiempo real, mientras que el filtro opera sobre los datos del ciclo anterior.

El etiquetado de tiempo de los datos de medición de GPS y de navegación a estima es crítico para una navegación con éxito. Las cuentas de impulso de sensor de velocidad de navegación estimada y los datos de giroscopio, se muestrean de modo que son válidos en eventos de TIC de GPS. Las mediciones en bruto de GPS son válidas también en los eventos de TIC, de modo que la alineación de tiempo puede realizarse de una manera sencilla.

Parte de la estimación de filtro Kalman es un error de desviación y vector velocidad del reloj del receptor (el TCXO de 10 MHz maestro). Debido a este error y a la incapacidad para ajustar el intervalo de TIC con precisión, el intervalo de TIC deriva ligeramente desde una tasa de transmisión de 8 Hz real con respecto al tiempo de GPS. Es deseable tener en cuenta este error y, de manera periódica, ajustar el intervalo de TIC, para corregir la deriva.

El rastreador tiene varias entradas analógicas, que deben compartirse a través de un A/D multiplexado. La entrada analógica de prioridad más alta es el giroscopio, que debe muestrearse a entre 50 Hz y 100 Hz cuando el vehículo puede estar moviéndose (es decir, en cualquier momento en que el arranque esté encendido). Se monitoriza la tensión de la batería, principalmente cuando el arranque está apagado, para garantizar que la unidad no está consumiendo batería. Pueden conectarse al rastreador varios sensores externos analógicos, para proporcionar información específica de cliente sobre los parámetros del vehículo. Los requisitos para monitorizar estos sensores son específicos del
cliente.

La tarjeta de RF tiene un indicador de intensidad de señal recibida (RSSI), que se muestrea de manera periódica, para determinar la intensidad de la difusión de la subportadora de FM. El sensor de temperatura sobre la placa de CPU es otra señal analógica más, usada para la calibración del giroscopio.

El manejo del almacenamiento de parámetros es un aspecto importante. La tarjeta de CPU de rastreador usa memoria flash, para el almacenamiento de parámetros a largo plazo, cuando la unidad está apagada o desconectada de la potencia del vehículo. Se hace una copia de seguridad de la SRAM mediante la potencia del vehículo de modo que el almacenamiento de modo en espera a corto plazo del estado de la máquina permanezca intacto. Los datos se almacenan en la memoria flash diaria o semanalmente de modo que la pérdida de potencia sólo hará que se pierdan los datos más recientes.

La tarjeta de CPU tiene, por ejemplo, 512 Kbytes de memoria flash de banco borrable. Los datos constantes y de programa ocupan preferentemente la mitad inferior de la memoria, reservando los 256 K superiores para el almacenamiento de parámetros. Una desventaja de la memoria flash es que, si cualquier banco está escribiéndose o borrándose, no está disponible ninguna parte del dispositivo, hasta que la operación se complete. Puesto que el código está en la memoria flash, debe tenerse cuidado cuando se escribe en el dispositivo. El código que escribe en la memoria flash debe ejecutarse en RAM, con las interrupciones deshabilitadas. El borrado debe usar la característica de suspender borrado del dispositivo. Esto se implementa con manejo de interrupción mientras está realizándose el borrado. En la mayoría de los casos, la escritura y el borrado en la memoria flash se producirá cuando la CPU pretende que el microcontrolador la apague. Por tanto, no es un problema deshabilitar todas las interrupciones, porque no estarán teniendo lugar ni navegación ni comunicaciones de radio.

El dispositivo de memoria flash puede direccionarse por palabras (de 16 bits). Los datos escritos en flash deben realizarse por palabras, incluso en los límites de byte. Los bytes, sin embargo, pueden leerse en límites de bytes impares.

Como procedimiento de almacenamiento, un sistema almacenamiento de archivo lineal (LFS) se usa preferentemente para almacenar datos de parámetro. Este procedimiento genera una lista enlazada de registros de longitud variable, que se extiende para llenar un bloque de memoria. Cuando el bloque está lleno, los registros no marcados para reclamación se copian en un bloque nuevo, y se borra el bloque antiguo. El sistema de archivos debe recuperarse de la pérdida de potencia durante la escritura y la reclamación. El enfoque de LFS un soporta manejo robusto de condiciones de pérdida de potencia. Los registros almacenados en la memoria flash deben tener una CRC, o una suma de comprobación, para garantizar que los datos son válidos.

Los datos de parámetro se almacenan en, al menos, un banco de memoria flash, y se actualizan, de manera periódica, a medida que se dispone de nueva información. La memoria flash almacena los siguientes tipos de datos:

1.

Datos de almanaque de satélite de GPS, para adquisición de satélite: los datos de almanaque nuevos se almacenan semanalmente. Se leen cuando la CPU se enciende, y se escriben cuando los datos nuevos desde los satélites son, al menos, una semana más nuevos que los datos almacenados. Un conjunto completo de almanaques requiere 2 K de memoria.

2.

Información de mercado del sistema PROTRAK: datos sobre la ubicación y frecuencias de los transmisores de subportadora de FM usados en cada mercado se almacenan a medida que los datos se transmiten desde el NDC. Almacenar esta información permite al rastreador buscar frecuencias de PROTRAK conocidas para los datos de difusión de NDC, acelerando de ese modo la inicialización del sistema. Los centros de navegación de la cuadrícula y las frecuencias de transmisión de UHF para cada mercado se almacenan también. Debe reservarse un espacio adecuado para estos datos, para permitir que se almacenen 5-10 conjuntos de datos.

3.

Número de serie de rastreador: el número de serie de la unidad se almacena en la memoria flash, y nunca se borra ni se modifica, excepto en la fábrica. El número de serie y los datos de configuración específicos del cliente/dispositivo, se almacenan por separado de los datos de parámetros, en la memoria flash.

\vskip1.000000\baselineskip

Otros parámetros se definen según se requiera.

El rastreador soporta datos de registro, por ejemplo, registro de posición y otra información de sensor, en la memoria flash, para su descarga posterior. Esto es útil para determinar la ubicación de un vehículo cuando se mueve fuera del área de servicio; y, al volver al área de servicio, los datos pueden descargarse a través de la interfaz del MDT o la radio.

VIII. Terminal de datos móvil

El MDT 190 sirve como una unidad de visualización y control (CDU) para el rastreador 135 (figuras 23, 26), principalmente para la comodidad del operador del vehículo. El MDT es un pequeño ordenador programable convencional, similar a, pero, generalmente, más pequeño que, un PC portátil (con software específico del cliente) y un terminal de visualización con pantalla de cristal líquido (LCD), teclado numérico, memoria asociada, y sistema de circuitos interno (integrado), para permitir la visualización de texto y otros datos, y para permitir al operador del vehículo responder a mensajes de radiomensajería de texto e introducir otros datos que van a transmitirse al expedidor. El MDT 190 y el rastreador 135 se comunican a través de una interfaz serie, asíncrona, diferencial y equilibrada que, en la realización ejemplar, usa un circuito de interfaz receptor/conductor diferencial dual SN65C1167NS de Texas Instruments (TI). El rastreador 135 soporta tasas de transmisión de baudios "estándar" de hasta 38400 bps, y el MDT 190 debe soportar una tasa de transmisión de baudios de, al menos, 4800 bps. La programación del MDT se controla, también, a través de la interfaz serie. Los formatos de protocolo y mensaje, así como las interfaces de potencia y programación, se describen con mayor detalle posteriormente.

El protocolo de interfaz serie preferido para la comunicación entre el rastreador y el MDT, y que se usa también en otras interfaces serie del sistema PROTRAK, se basa en la interfaz de motor Rockwell NavCore V GPS descrita en "NavCore Designer's Guide", de Rockwell Internacional, Rev.H, 14 diciembre de 1993 (a la que se hace referencia en lo sucesivo en el presente documento como el protocolo de interfaz NavCore). La interfaz del MDT usa diferente tasas de transmisión de baudios y sincronismo del mensaje.

Adoptando NavCore y otras convenciones de numeración de mensajes, cada interfaz se identifica por un lugar de millar diferente en el número de ID de mensaje. La interfaz rastreador-MDT usa 7000 como el identificador de interfaz. Los mensajes transmitidos por el rastreador 135 usan números de ID que comienzan por 7100 y los mensajes recibidos por el mismo usan números que comienzan por 7200. En la realización ejemplar, los ID de mensaje son:

Para rastreador a MDT:

7101

Datos de navegación

7102

Datos de mensaje recibidos

7103

Datos de usuario recibidos

7104

Datos de mensaje disponibles

7106

Lista de mensajes de datos de usuario

\vskip1.000000\baselineskip

Para MDT a rastreador:

7101

Solicitud de datos

7102

Respuesta de mensaje de texto

7103

Salida de datos de usuario

7104

Solicitar datos de mensaje disponibles

7105

Solicitar mensaje

7106

Solicitar lista de mensajes de datos de usuario

\vskip1.000000\baselineskip

Cuando lo solicita el MDT 190 (por acción del operador del vehículo), el rastreador 135 envía datos de navegación (mensaje 7201, tabla 57, apéndice B) al MDT que incluyen posición, vector velocidad y hora actuales, a, aproximadamente, 1 Hz. Cuando el rastreador recibe un "mensaje de solicitud" (7205, tabla 66) desde el MDT, envía los datos para el mensaje de texto solicitado al MDT usando un paquete de "datos de mensaje recibidos" (7102, tabla 58). Este último contiene, o bien el texto completo del mensaje recibido, o bien un número de ID que indica un texto "preestablecido" para su visualización. Se envía, junto con el mensaje de texto, un conjunto de respuesta, que contiene un conjunto único de elementos de texto que el operador del vehículo puede seleccionar, en respuesta al mensaje
recibido.

Cada mensaje tiene un identificador, o emisión de datos (IOD), un contador de desbordamiento, para diferenciar mensajes dentro del sistema y para asociar mensajes con sus respuestas. Cuando el operador selecciona una respuesta para un mensaje (por ejemplo, una pregunta del expedidor), la IOD de ese mensaje se envía de nuevo al rastreador con la respuesta, en el mensaje 7202. La respuesta se selecciona usando teclas de flecha en el frontal (teclado numérico) del MDT. El MDT almacena el texto, que puede ser de hasta un máximo de 80 caracteres, de un único mensaje mientras, se visualiza para el operador. El texto de cada respuesta puede estar limitado (por ejemplo, a aproximadamente 10 caracteres), atribuible al tamaño de la pantalla.

En los "datos de mensaje recibidos" (tabla 58), el tipo de mensaje indica si el mensaje contiene un mensaje de texto completo o preestablecido. Si el mensaje es preestablecido, el siguiente byte contiene el número de ID del mensaje; en otro caso, contiene la longitud en bytes del texto de mensaje recibido. Los siguientes 2 bytes contienen el número de IOD del mensaje de texto recibido y la respuesta de usuario si ya se ha enviado un mensaje. Las siguientes 3 palabras indican la fecha y la hora a las que se recibió el mensaje. La siguiente palabra contiene el número de respuestas válidas en la lista de respuestas. A continuación, está la lista de 4 respuestas de texto que van a visualizarse sobre las teclas programables del MDT. Las cadenas de respuesta no usadas se rellenan con ceros. Si el mensaje es texto completo, los caracteres del mensaje siguen en orden. Para un número impar de bytes, el último byte de mensaje se ajusta a 0. La suma de comprobación de datos sigue a la respuesta ajustada en el caso de un mensaje preestablecido o a los datos de texto en el caso de un mensaje de texto completo.

El rastreador recibe datos definidos por el cliente desde el NDC, en un paquete que está constituido por un identificador de datos (1 byte) y 20 bytes de datos. Dependiendo de los requisitos del cliente y el tipo de datos recibidos, el rastreador o bien actúa él mismo sobre los datos, o bien los retransmite al MDT enviando un mensaje de "datos de usuario recibidos" (7103, tabla 59) para la atención del operador del vehículo. En el MDT, un software específico del cliente procesa los datos recibidos.

El rastreador puede, a partir del NDC, recibir y almacenar numerosos mensajes de texto. Cuando el rastreador recibe un mensaje nuevo (así como en intervalos periódicos), envía un mensaje de "datos de mensaje disponibles" (7104, tabla 60) al MDT, indicativo del número de mensajes no leídos y el número de mensajes guardados, así como un ID único para cada mensaje, para su uso para recuperar un mensaje específico del rastreador. Tras recibir este mensaje 7104, el MDT emite un sonido, de manera periódica, por un altavoz u otro dispositivo de aviso (por ejemplo, una lámpara, LED, o la propia pantalla LCD) dentro del MDT, si el número de mensajes no leídos no es cero, para informar al operador del vehículo de mensajes no leídos que necesitan una respuesta. Los mensajes no leídos individuales pueden recuperarse desde el rastreador enviando el conductor un mensaje de solicitud (7205, tabla 66) desde el MDT.

El rastreador 135 está programado con un conjunto de mensajes de "datos de usuario" preestablecidos, del que el MDT puede solicitar su visualización en una lista (mensaje 7106, tabla 61) mediante el envío por parte del conductor del mensaje de "solicitar lista de mensajes de datos de usuario" (7206, tabla 67). Tras la posterior recepción de un "mensaje de solicitud", para un mensaje de "datos de usuario" específico, el rastreador proporcionará al MDT el texto de dicho mensaje solicitado. Cada mensaje tiene una longitud fija de 30 caracteres con ubicaciones no utilizadas ajustadas a 0x00.

Varios mensajes de estado y de depuración están disponibles a partir del rastreador para salida periódica, y el MDT puede solicitar que estos mensajes (o algunos específicos de éstos, mediante designación de ID de mensaje) se activen o desactiven enviando un mensaje de "solicitud de datos" (7201, tabla 62). Por defecto, todos los que están disponibles de estos mensajes periódicos están desactivados. Una vez que se activa un mensaje de este tipo, sin embargo, el rastreador continuará emitiéndolo como salida de manera periódica, hasta que el mensaje se desactive o se elimine la potencia completa del rastreador.

Cuando el operador de vehículo selecciona una respuesta para un mensaje de texto recibido, el MDT envía dicha respuesta al rastreador, usando un mensaje de respuesta de mensaje de texto (7202, tabla 63) que contiene la IOD del mensaje que al que está contestándose y el valor de respuesta numérico.

El rastreador se usa para enviar datos definidos por el cliente al NDC y en el expedidor o abonado a través del (de los) concentrador(es), usando un paquete de salida que está constituido por un identificador de datos (1 byte) y, o bien 1, o bien 9 bytes de datos, con interfaces de MDT específicas de cliente, que permiten la entrada de datos. Los datos pueden estar constituidos por solicitudes de emergencia, o por un simple estatus del vehículo como "trabajo completo," o información más compleja. En cualquier caso, tras la entrada de datos se envían del MDT al rastreador por medio de un mensaje de "salida de datos de usuario" (7203, tabla 64), para su transmisión por el rastreador hasta el NDC. El mensaje tiene una longitud fija con espacio real para 10 bytes de datos, y sólo 1 ó 9 tienen significado, basándose en el LSB de la palabra 6. El resto de bytes de datos tienen sus valores ajustados a cero.

Cuando el operador de vehículo desea ver cualquier mensaje guardado, él o ella introduce el MDT 190 para enviar un mensaje de "solicitar datos de mensaje disponibles" (7204, tabla 65) al rastreador para recuperar la lista mensajes de texto disponibles, y el rastreador responde con una lista de los "datos de mensaje disponibles" (7104, tabla 60). A partir de entonces, el operador de vehículo envía un "mensaje de solicitud" (7205, tabla 66) desde el MDT para recuperar desde el rastreador uno específico de los mensajes de texto disponibles a partir de los contenidos en la lista. Como se observó anteriormente, el operador de vehículo envía un mensaje de "solicitar lista de mensaje de datos de usuario" (7206, tabla 67) desde el MDT para recuperar una lista de los mensajes de "datos de usuario" preestablecidos almacenados por el rastreador.

Volviendo a las consideraciones de potencia, el rastreador 135 suministra una potencia de 12 VCC al MDT 190, como se indicó anteriormente en la figura 26, con corriente máxima extraída por el MDT, incluyendo el encendido y la activación de luz posterior, preferentemente limitada a 0,5 A. El MDT tiene un solo conector de interfaz, que es un tipo D de 9 clavijas montado en un circuito impreso en la presente realización ejemplar. Las señales de conector desde el rastreador hasta el MDT son:

1. Control de carga de arranque (no conectado)

2. Datos +RX

3. Datos -RX

4. Datos +TX

5. Datos -TX

6. Tierra

7. +12 V

8. +12 V

9. Tierra

La memoria de sólo lectura (ROM) del MDT puede programarse a través de la interfaz serie. El MDT se pone en el modo de programación, imponiendo (bajo arrastre) una señal de control de carga de arranque, y entonces se programa enviando bloques de datos a través del puerto de serie.

IX. Concentradores de red

Con referencia ahora al diagrama de bloques simplificado de un concentrador de red ejemplar en la figura 30, el concentrador 11 recibe transmisiones de datos de vehículo, recupera los datos binarios, y envía los datos al NDC a través de una línea telefónica. El concentrador de red incluye un receptor 85 de radio de FM (que es idéntico al receptor de radio de FM en cada rastreador de vehículo), para recibir mensajes de difusión con fines de sincronismo, un receptor 81 de radio de UHF para recibir transmisiones de vehículo, y un módem 87, para la comunicación con el NDC.

Los concentradores de red se instalan en puntos estratégicos (normalmente, espacio alquilado en torres de radio existentes en y alrededor del área metropolitana a la que da servicio), para recibir transmisiones de datos de vehículo. Los concentradores requieren una potencia de CA de sólo 110 V y una línea telefónica especial para empresas para funcionar. En un mercado típico, se necesitan entre 10 y 30 concentradores, para dar servicio a las diversas operaciones de flota que demandan rastreo de vehículos. Este número relativamente pequeño de unidades y la necesidad de un rendimiento de RF alto hace que el coste sea un factor menos importante para los concentradores que para los rastreadores en los vehículos. La sensibilidad de los receptores de FM y UHF y la fiabilidad del sistema son muy importantes.

Cada concentrador de red se divide en cuatro áreas funcionales principales, concretamente: 1) CPU 82, 2) fuente 84 de alimentación, 3) módem 87, y 4) tarjeta 86 de RF. La CPU 82 se corresponde estrechamente con la CPU de rastreador, usando un microcontrolador 68332 de Motorola que funciona a 20 MHz. El 68332 está idealmente adaptado para esta aplicación debido a los periféricos SCI, QSPI, y TPU. La CPU 82 de concentrador utiliza un procesador, una SRAM, y una memoria flash como en el rastreador, pero no requiere la sección de GPS del rastreador. Otras similitudes/diferencias con la CPU de rastreador en la CPU de concentrador son la adición en ésta de un TCXO, conversión de nivel para la interfaz de módem, y la sustitución de la interfaz de transmisor de UHF con una interfaz de receptor de UHF, pero reteniendo la misma interfaz de receptor de FM. La memoria flash de CPU puede programarse en circuito a través de un cabezal o conector usando la interfaz de modo BDM del procesador.

El concentrador usa el flujo de datos de FM, que tiene una tasa de transmisión de aproximadamente 4664 bps, desde el receptor 85 de FM, para la sincronización de tiempo de sistema exactamente como lo hacen los rastreadores. Se prevé que los rastreadores usen los datos de FM, pero todavía deben descodificarse en el concentrador en el grado requerido para obtener los datos de sincronismo. La TPU en el 68332, a la que se envía el flujo de datos de FM, y el software que se ejecuta en la CPU, usan información de sincronización de bits en el flujo de datos de FM, para permitir que la TPU genere los relojes de datos de bits y bytes usados, para controlar un registro 88 de desviación en la tarjeta de CPU, que también recibe el flujo de datos de FM, y registra la entrada de datos en el procesador 83. Como con la CPU de rastreador, la CPU de concentrador es responsable de la programación de la frecuencia de FM y desviación de subportadora de la tarjeta de RF sobre una interfaz serie.

Para la interfaz del receptor de UHF, el receptor 81 de UHF usa un microprocesador 80 de DSP para extraer los relojes de bits y bytes desde el flujo de datos de UHF recibido. El procesador en la tarjeta de UHF está dotado de información de sincronismo desde la CPU, por la que puede determinar las ventanas a tiempo para buscar los datos de vehículo recibidos.

El microcontrolador 68332 83 usa el periférico UART de SCI para comunicarse con el módem 87 de USRobotics externo que tiene una interfaz RS-232. La conversión se realiza entre las señales de nivel de RS-232 y 5 V. La SCI soporta una tasa de transmisión de bits de 19200 bps, que genera hasta, aproximadamente, 2800 interrupciones de recepción y transmisión por segundo, conectando el módem a 14400 bps. Si se desea soporte de tasas de transmisión de bits más rápidas, puede lograrse usando un UART externo con un FIFO, o incluyendo los componentes GP2010 y GP2021 del conjunto de chips de GPS, para proporcionar los UART almacenados en memoria intermedia y sondeados.

La fuente 84 de alimentación convierte 110 V de CA en 12 V de CC, para las secciones de CPU y RF del concentrador que regula de manera independiente la potencia a 5 V de CC de modo que se aíslan las dos secciones. La conversión de CA a CC se realiza mediante un transformador y una fuente de potencia lineal genéricos.

La potencia de módem se suministra a través de un transformador enchufable, y la CPU proporciona las señales de interfaz serie para soportar el control de flujo de hardware con el módem. El software de la CPU controla el módem para llamar al NDC, iniciar sesión, y verificar que la conexión está operativa. Si la conexión se interrumpe, el concentrador colgará y volverá a llamar para reestablecerla, volviendo a llamar repetidamente hasta que se realice una conexión si el módem de NDC no responde inicialmente. El número de teléfono de NDC, el ID de usuario de concentrador y la contraseña, se almacenan en la memoria flash de CPU. Se usa una velocidad de conexión de 14400 bps para maximizar la fiabilidad de la conexión. Puede necesitarse un módem reforzado de EMI (interferencia electromagnética) en algunas situaciones, puesto que el sistema opera cerca de transmisores de RF.

La sección 86 de RF del concentrador recibe la difusión de NDC en la subportadora de FM en el receptor 85 de FM, y recibe las transmisiones de vehículo de TDMA en un canal de UHF en el receptor 81 de UHF. Los datos se proporcionan a la CPU como flujos serie. La CPU genera los relojes de datos para los datos de difusión de NDC, así como programa las frecuencias de recepción de la tarjeta de RF, y la tarjeta de RF genera los relojes para los datos de vehículo.

Los datos de subportadora de FM presentan una desviación de 67 KHz o de 92 KHz de los canales de FM habituales, y la desviación y la frecuencia de recepción de FM son completamente programables por la CPU. Los datos de subportadora se modulan mediante la SCA-300B 68 (figura 6), que usa un sencillo esquema de modulación BFSK.

Los rastreadores de vehículo transmiten paquetes de datos en tiempos asignados a una frecuencia en la banda de empresa de UHF, siendo también la frecuencia de recepción de UHF programable por la GPU, en desviaciones de 12,5 KHz entre 450 MHz y 470 MHz. Para un uso eficaz del ancho de banda disponible, la tasa de transmisión de datos de vehículo es 7812,5 bps.

El software de la CPU le permite llevar a cabo sus tareas primarias, incluyendo la sincronización de tiempo en la red de TDMA, la comunicación con el NDC a través de módem, la programación de tarjeta de RF y el control, la recepción y la descodificación de los datos de subportadora de FM, y la recepción de datos de vehículo de UHF y la retransmisión de los datos al NDC. Diversas funciones de software se escriben para ser comunes con las mismas funciones en otras partes del sistema. Por ejemplo, muchas funciones relacionadas con la comunicación de módem con el NDC son idénticas a las usadas en el SCC, aunque los mensajes de datos serie son diferentes, y el concentrador debe llamar e iniciar sesión mientras no se requiera que el SCC lo haga. La programación del sintetizador de RF, la recepción de datos de FM, y el código de sincronización de tiempo de flujo de datos de FM, son idénticos a los del rastreador.

X. Ordenador de control de subportadora (SCC)

El hardware del ordenador 48 de control de subportadora (figura 6) de una realización ejemplar se muestra en el diagrama de bloques simplificado de la figura 31. El SCC controla la transmisión del mensaje de difusión base de NDC. Se registra la salida del mensaje al modulador 68 de subportadora de SCA-300B con tiempos de inicio del mensaje precisos y una tasa de transmisión de datos precisa. El SCC se monta preferentemente sobre un bastidor junto con el modulador de subportadora en la estación 12 de radio de FM. El NTCC 47 en el NDC 10 llama al módem 57 de SCC para conectar el SCC 48 al NDC. El NTCC 47 proporciona los datos de mensaje de difusión para que el SCC los envíe al modulador 68, y el NTCC también controla el tiempo en el que comienza cada transmisión.

La CPU 260 del SCC (preferentemente, como en los ejemplos de las CPU usadas para el concentrador de red y el rastreador, un procesador 68332 de Motorola de 16 MHz), usa un periférico de UART de SCI (véase, por ejemplo, la CPU 83 del concentrador de red de la figura 30) como la interfaz para comunicación con el módem 57 externo (preferentemente de USRobotics) a través de una tarjeta 262 de entrada/salida (E/S). Se realiza una conversión entre las señales de nivel de RS-232 y 5 V. El módem se ajusta para comunicarse con la CPU 260 a 19200 bps, y tiene permiso para conectarse con el NTCC 47 a tasas de transmisión de entre 14400 bps y 19200 bps. En esta tasa de transmisión de comunicación, la SCI puede generar hasta aproximadamente 2800 interrupciones de recepción y transmisión por segundo.

La CPU 260 usa el periférico de QSPI del dispositivo 68332 (véase de nuevo, por ejemplo, la CPU 83 del concentrador de red de la figura 30) para la interfaz de modulador de subportadora, para enviar los datos de transmisión serie al modulador 68 de subportadora. Aquí también, se realiza una conversión entre las señales de nivel de RS-232 y 5 V. La QSPI se temporiza por la TPU del procesador 68332 para el ajuste de fase de reloj controlado con precisión. La tasa de transmisión de datos de salida es aproximadamente 4664,18 bps (2,5 MHz/536). Sin embargo, los datos de transmisión tienen una codificación Miller de modo que 2 bits de código Miller se transmiten para cada bit de datos (9328,36 de bps de código), para un divisor de 268. La función de TPU de OC (comparación de salida) usa una cuenta de semiciclo de 134. Se usa un reloj serie de RF existente desde la TPU hasta la QSPI para el reloj de datos de salida.

La temporización y el sincronismo de datos de transmisión requieren tres canales de TPU, puesto que iniciar el reloj de datos en la hora correcta requiere utilizar dos canales de TPU adicionales. El primer canal de TPU está cableado al segundo canal. En el primer canal, la CPU inicia una única OC de transición en un tiempo deseado, y programa un tercer canal para OC con modo de impulso continuo, con un tiempo de inicio del registro de control de sincronismo (TCR) preciso, igual al tiempo de inicio deseado real. El segundo canal se configura para ejecutar la ITC (captura/cuenta de transición de entrada) con un enlace con el tercer canal. Cuando el procesador inicia la transición en el primer canal, la TPU, a través del enlace de ITC, inicia el reloj de datos en el tercer canal en el tiempo de inicio preciso.

Al mantener el sincronismo preciso requerido por el sistema PROTRAK, el SCC 48 se ejecuta directamente desde un oscilador de cristal de TCXO a 1,5 ppm. Para mantener tasas de transmisión de bits comunes entre el SCC, los concentradores de red y los rastreadores, que funcionan 20 MHz, la TPU de la CPU 260 se ejecuta a 10 MHz. La ejecución en tiempo real se ejecuta a una tasa de transmisión de 1 KHz, que permite la resolución de programación requerida de las funciones de TPU. El ejecutivo necesita el valor del contador de TCR de TPU en cada tic de temporizador de ejecutivo, de modo que el tiempo de ejecutivo puede sincronizarse con el temporizador de TPU, para programar las funciones de transmisión de datos. Para ese fin, es conveniente usar la función de TPU de ITC para generar interrupciones para el ejecutivo. Las interrupciones se generan detectando transiciones desde un segundo canal de TPU que ejecuta una función de modulación de ancho de impulso (PWM) a la tasa de ejecución deseada.

La CPU 260 inicia una onda cuadrada de ciclo de trabajo del 50% en el primer canal de la TPU. La frecuencia PWM debería ser un divisor conveniente de 2,5 MHz; se considera adecuado un ancho de semiperiodo de 2500 (tasa de ejecución de 1 KHz). La salida de este canal se alimenta en la entrada del segundo canal que ejecuta el ITC. El ITC muestrea el TCR1 e interrumpe el procesador en cada transición de la señal de PWM. El ejecutivo puede entonces leer el registro de TPU para determinar el valor de TCR1 en dicha interrupción de TIC.

La función primaria del SCC 48 es transmitir el mensaje de difusión base proporcionado por el NTCC 47 a una tasa de transmisión precisa de 1 Hz, sincronizado con el segundo entero de GPS. El NTCC 47 escucha la difusión iniciada de SCC y controla el sincronismo comparando el inicio de cada mensaje de difusión recibido con el tiempo de GPS, calculando una corrección de sincronismo basándose en la diferencia entre el tiempo de recepción y el tiempo de GPS y enviando una corrección de vuelta al SCC. El SCC 48 ajusta entonces el tiempo de transmisión de los mensajes posteriores basándose en esta corrección. Este proceso de sincronismo se ha descrito con mayor detalle anteriormente en el presente documento.

La interfaz 47 de módem de NTCC se implementa de modo que el SCC 48 responderá a la llamada establecida por el NTCC a su módem. El SCC recibe datos de mensaje de difusión y órdenes de control de sincronismo sobre la interfaz serie, enviándose el mensaje de difusión desde el NTCC 47, habitualmente, en cinco paquetes. El SCC monta entonces los paquetes en orden, y envía los datos de mensaje al modulador 68 de subportadora en el siguiente segundo entero. Se usa una pantalla 263 de panel de LCD en el SCC 48 para visualizar la información de estatus y de depuración.

Varias funciones de software se escriben para ser comunes con funciones en otras partes del sistema. Por ejemplo, muchas funciones relacionadas con la comunicación de módem, mediante el SCC, con el NTCC, son idénticas a las usadas en el concentrador de red. Sin embargo, los mensajes de datos serie son diferentes y, a diferencia del SCC, el concentrador debe llamar e iniciar sesión. Partes del ejecutivo y del código de sincronización de tiempo son comunes con los concentradores de red y los rastreadores.

Durante operaciones habituales, el SCC 48 recibe, del NTCC 47, 5 bloques de 155 bytes de datos, que va a transmitir la estación 12 de radio cada segundo en la difusión de subportadora de FM. El Miller de SCC codifica los datos, inserta un patrón de preámbulo y de sincronización en el comienzo, y coloca los 9264 bits resultantes en una memoria intermedia de salida. Antes del siguiente tiempo de transmisión, el reloj de datos de salida se detiene y se ajusta para comenzar de nuevo en el siguiente tiempo de inicio deseado tal como ordene el NTCC. Se prepara la memoria intermedia de salida de la QSPI, y la CPU 260 conmuta un canal de salida de TPU para iniciar el proceso de sincronización de transmisión.

Para la sincronización de NTCC-SCC, el NTCC 47 coordina el sincronismo de enviar los datos de difusión al SCC 48, basándose en el tiempo de recepción de un mensaje de estatus de SCC (véase la tabla 72 del apéndice B, al que se hace referencia en el análisis de la sección de NTCC a continuación). El SCC envía este mensaje cada vez que inicia una transmisión de datos. En ese momento, el NTCC 47 envía un nuevo mensaje de datos de difusión (1102, véase la tabla 71 del apéndice B, a la que también se hace referencia en el análisis de la sección de NTCC a continuación). Este esquema de sincronismo garantiza una latencia mínima de los datos de difusión, y elimina las ambigüedades de sincronismo entre el NTCC y el SCC que pueden atribuirse a la falta de una referencia de tiempo absoluta
en el SCC.

Los 5 bloques (575 bytes) completos transmitidos por el NTCC 47 requieren, aproximadamente, 500 ms para enviarse al SCC 48, a 14400 bps. El SCC permite un total de aproximadamente 900 ms para la recepción de nuevos datos, antes de que el procesamiento deba completarse para la transmisión de los datos en el siguiente segundo. Este tiempo adicional permite volver a intentar uno o dos bloques de mensaje que pueden haberse corrompido. Una tasa de transmisión de bits de conexión más alta permitirá realizar intentos adicionales, pero con la posibilidad de que sea menos fiable. Los datos de difusión no válidos desde un mensaje de NTCC con una cabecera válida, deben trasmitirse incluso si no está disponible una recuperación sin errores desde el NTCC, ya que los datos codificados con código Golay pueden corregirse por los propios rastreadores de vehículo.

Para el procesamiento de datos de mensaje, el SCC 48 forma la memoria intermedia de datos de transmisión completa, poniendo el patrón de preámbulo y de sincronización de bits en la memoria intermedia y, a continuación, añadiendo los datos. El NTCC envía los datos de transmisión al SCC con codificación de línea sin retorno a cero (NRZ). El SCC se requiere para la codificación Miller de los datos, que convierte los 4600 bits de datos de NRZ a 9200 bits Miller. El proceso de codificación dura aproximadamente 12-15 ms. El código Miller usa memoria de los bits codificados anteriormente de modo que puede realizarse en un bloque de datos sólo si el bloque anterior se ha recibido. El preámbulo es un patrón de bits Miller uno-cero alternante insertado antes del patrón de sincronización de bits: 11 00 11 00 11 00 11 00, transmitiéndose, en primer lugar, los bits más a la izquierda. El patrón de sincronización de bits es de una longitud de 48 bits Miller y tiene 9 bits altos seguidos de 7 bits bajos, repetidos 3 veces.

La QSPI del procesador 68332 de la CPU 260 se usa como el registro de desplazamiento de salida. La memoria intermedia de la QSPI interna contiene 16 bytes si está configurada para transferencias de 8 bits. Con transferencias de 8 bits se vaciará cada 13,72 ms, de manera que debe planificarse una tarea en el ejecutivo de tiempo real para dar servicio a la cola de la QSPI. La QSPI envía, en primer lugar, los datos con los bits más significativos, lo que se tiene en cuenta cuando se forman los patrones de preámbulo y de sincronización de bits y cuando se carga la QSPI.

El flujo de datos de NTCC/SCC se ilustra en el diagrama de sincronismo de la figura 32. El SCC 48 envía de manera simultánea los datos 265 de difusión para la trama actual y recibe los datos 266 desde el NTCC para la siguiente trama. Tras aproximadamente 900 ms en la trama actual (en 267), el SCC debe cortar la recepción de datos desde el NTCC 47 y comenzar a procesar los bloques disponibles. Si los bloques de datos faltan completamente, el SCC asume que los datos de NRZ son todo ceros y lleva a cabo la consiguiente codificación Miller. El SCC 48 debe también calcular un nuevo tiempo de transmisión, basándose en órdenes recibidas desde el NTCC. La TPU se programa con el nuevo tiempo de transmisión durante el tiempo 269 de separación entre las transmisiones de datos de difusión.

La totalidad del sincronismo y la sincronización de transmisión se produce en los, aproximadamente, 6,9 ms del tiempo 269 de separación entre las transmisiones. Durante este tiempo, el SCC 48 lleva a cabo las siguientes etapas para comenzar la transmisión de los datos para el siguiente tiempo:

1.

Detener la QSPI.

2.

Desactivar el reloj de datos de OC en el canal 3 de TPU.

3.

Conmutar la memoria intermedia de datos de salida con los datos recién recibidos.

4.

Programar el canal 3 de TPU para que el modo de impulso continuo comience en el siguiente tiempo de transmisión.

5.

Cargar la QSPI con los nuevos datos y habilitar la QSPI.

6.

Enviar el mensaje de estatus de SCC al NTCC.

7.

Conmutar el estado de OC de canal 1 de TPU para iniciar el proceso de sincronización.

\vskip1.000000\baselineskip

La temporización y el sincronismo de los datos de transmisión requieren 3 canales de TPU: El canal 1 se programa para ser una única función de OC de transición, que está configurada para conmutar durante el tiempo de intervalo por la CPU. El canal 1 de salida está cableado al canal 2 de entrada.

\newpage

Los parámetros de canal son:

14

El canal 2 está programado con la función de ITC, para generar, de manera continua, enlaces con el canal 3. La ITC se configura para activarse sobre cualquier transición.

\vskip1.000000\baselineskip

Los parámetros de canal son:

15

El canal 3 está programado con una función de OC de impulso continuo. Este es el reloj de datos de salida y está cableado a la entrada de reloj de la QSPI. Durante el tiempo de intervalo, se reprograma con un REF_TTME actualizado que es el tiempo de inicio de transmisión.

\vskip1.000000\baselineskip

Los parámetros de canal son:

16

Los punteros de dirección de referencia apuntan a ubicaciones en RAM (memoria de acceso aleatorio) de parámetro de TPU. Por lo tanto, el espacio de parámetro de canales no usados debe usarse para almacenar los datos para este canal. Las interrupciones desde estos canales pueden deshabilitarse.

El SCC 48 tiene tres modos de operación: inicialización, en reposo y ejecución. Cuando el SCC se activa, entra en el modo de inicialización. En este modo, el software inicializa variables de sistema, activa la LCD 263 y la luz posterior, inicializa el módem 57, y configura la TPU para iniciar el ejecutivo de tiempo real. Tras completarse la inicialización, el SCC entra en el modo en espera.

En el modo en espera, el SCC 48 espera a que el NTCC 47 reciba una llamada. Mientras espera, el SCC no envía datos al modulador 68 de subportadora, y la salida permanece alta o baja. El módem 57 se monitoriza para un evento de conexión. Cuando el módem se conecta, el SCC entra en el modo de ejecución y recibe órdenes desde el NTCC.

En modo de ejecución, el NTCC 47 ordena al SCC 48 en uno de dos modos de transmisión de datos, concretamente: sincronización o difusión. El NTCC usa, en primer lugar, el modo de sincronización, para alinear el patrón de sincronización de difusión con el tiempo de GPS. En este modo, el SCC elige un tiempo de inicio arbitrario y transmite un patrón de preámbulo y de sincronización de bits sin ningún dato en intervalos de un segundo. El NTCC ordena al SCC mover el tiempo de inicio de transmisión hasta que se consiga la sincronización con el tiempo de GPS. En este punto, el NTCC ordena al SCC asumir el modo de difusión. En este modo, el NTCC proporciona cada segundo los cinco bloques de datos para transmitirse. Durante la operación en modo de ejecución, el SCC envía su mensaje de estatus al NTCC antes de que comience cada transmisión, como se describió anteriormente.

Si se están recibiendo detenciones de datos de mensaje válidas desde el NTCC durante un periodo de tiempo predeterminado, el SCC cuelga el módem, reinicializa el módem, y vuelve al modo en reposo para esperar otra llamada desde el NTCC.

XI. Ordenador de control y sincronismo de red (NTCC)

Como se ha descrito anteriormente en el presente documento (y con una breve referencia de nuevo a la figura 6), el NTCC 47 se interconecta con otras varias aplicaciones, incluyendo el servidor 42 de NDC, el módulo 55 de techo de NTCC, y a través de un módem, el SCC 48. El NTCC sirve como una interfaz de control en tiempo real con la red de radio para el NDC, y también recibe datos de sincronismo y correcciones de DGPS, desde un receptor 54 de GPS XR5M de NavSymm en el módulo de techo. Las interfaces entre los ordenadores son PPS serie y se soportan discretas reajustadas entre el NTCC 47 y el módulo 55 de techo.

El servidor 42 de NDC, el módulo 55 de techo y el SCC 48 usan todos los mismos formatos de protocolo y de mensaje, para comunicarse con el NTCC 47, basándose en el protocolo de interfaz de NavCore anteriormente mencionado. El protocolo de interfaz de NavCore está modificado para los fines de la presente realización ejemplar del sistema de PROTRAK, en que el byte más bajo de la palabra de indicador de estatus en la cabecera se usa para un contador de mensajes de ejecución libre. El contador de mensajes identifica de manera única el mensaje y se utiliza como respuesta de ACK/NACK si se requiere un acuse de recibo para el mensaje. Esto permite que múltiples mensajes del mismo tipo queden pendientes (esperando acuses de recibo) de manera simultánea. El contador de mensajes en el ACK/NACK identifica el mensaje específico cuyo recibo está acusándose.

Para mantener determinadas convenciones de numeración de mensajes y NavCore, cada interfaz se identifica mediante diferentes unidades de millar en el número de ID del mensaje. Los mensajes transmitidos por el NTCC 47 usan números de ID que comienzan con x100 y los mensajes recibidos por el NTCC usan números de ID que comienzan con x200, donde x es la unidad de millar del identificador de interfaz. Los ID de mensaje para cada interfaz serie se muestran a continuación en la tabla 68.

TABLA 68 Números de ID de mensaje de interfaz serie

17

Las interfaces serie de NTCC se llevan a cabo usando una placa de ES serie de multipuerto COM-8SF-2 de Contec, que puede comunicarse hasta a 115200 bps. Se soportan PPS y discretas reajustadas mediante una placa P10-48W de Contec.

El NTCC se comunica con el SCC, el servidor de NDC, y el módulo de techo con mensajes de datos serie. Con referencia de nuevo a la figura 6, el NTCC 47 establece una conexión con el SCC 48, estableciendo una llamada al SCC a través del módem 57. Cuando el módem está conectado, el NTCC comienza a enviar mensajes de control de sincronismo, y el SCC comienza a enviar mensajes de estatus. Una vez conseguida la sincronización de tiempo, el NTCC comienza a enviar conjuntos de datos de transmisión completos que están constituidos por datos de DGPS y mensajes generados por el NDC que están constituidos por 5 tramas de 115 bits de longitud. El SCC es responsable de generar la sincronización de bits y el inicio de la difusión de FM. Los mensajes usados para la comunicación entre el NTCC y el SCC se resumen en la tabla 69 (apéndice B), y, con más detalle, a continuación y en otras tablas del apéndice B, como se indica más abajo.

El NTCC 47 controla el sincronismo de la difusión de subportadora de FM usando un mensaje de "control de sincronismo" (1101, tabla 70). El SCC 48 usa los datos de este mensaje para ajustar su temporizador de transmisión, de modo que la sincronización de bits de datos de difusión se sincronizará con el tiempo del GPS. El mensaje de control de sincronismo se transmite mediante el NTCC cerca del comienzo de un intervalo de un segundo. El temporizador de segundo entero de SCC se programa usando el control de temporizador contenido en el mensaje de control de sincronismo, antes de que expire el temporizador actual.

En resumen, y con referencia a la tabla 70 (apéndice B), el modo de control de sincronismo es el byte menos importante de la palabra 6 en el mensaje de control de sincronismo, y tiene tres valores: 0 = desactivado, 1= basto, y 2 = fino. El tipo de control es el byte más significativo de la palabra 6, que indica cómo va a aplicarse el control de temporizador en las palabras 7 y 8 del mensaje. El tipo de control tiene tres valores: 0 = no usar, 1= añadir a nominal y 2 = una aplicación. Si el tipo de control es 0, se ignora; si es 1, el valor del control de temporizador se añade al valor del temporizador de nominal y se reprograma el temporizador; y si es 2, el temporizador se programa, una vez, con el valor del control de temporizador, y entonces vuelve al valor nominal.

Un mensaje de "trama de datos de transmisión" (1102, tabla 71), contiene una parte de todo el mensaje de difusión de SCC que se difunde cada segundo. El mensaje de difusión se descompone en tramas más pequeñas, de modo que, si se pierde parte del mensaje, pueda repetirse de forma más rápida que repitiendo el mensaje de difusión entero.

El mensaje de difusión nominal está constituido por, normalmente, cinco tramas de 115 bytes (intercalado de 23 bits de código Golay (23,12)), lo que hace que todo el mensaje de difusión tenga una longitud de 4600 bits de datos. Los mensajes de trama de datos que contienen datos que han de transmitirse en la siguiente trama de difusión, se transmiten al SCC desde el NTCC en la trama actual. El SCC transmite los datos de difusión disponibles al comienzo de cada segundo. Si faltan tramas de datos , las tramas que faltan se sustituyen por ceros en el flujo de los datos de transmisión.

Cerca del comienzo de cada segundo, el NTCC determina los datos que van a transmitirse en el siguiente segundo, y estos datos se descomponen en tramas. Varios mensajes con ID 1102, uno para cada trama, se ponen en cola a la vez.

El ID de trama de difusión en la palabra 6 del mensaje de "trama de datos de transmisión" indica la trama de difusión para la que se prevén los datos de transmisión. El SCC usa este valor para evitar la mezcla de los datos previstos para diferentes tramas de difusión. El número de trama y el número total de tramas se contienen en los bytes menos significativos y más significativos de la palabra 7, para indicar la manera de ensamblado de las tramas de datos si los mensajes se reciben desordenados. El número de bytes en la trama, l (en la palabra 8), indica el número de bytes de datos a seguir. Si l es impar, el byte más significativo de la última palabra de datos se rellena con 0x00. Los bytes de datos se ordenan de modo que se transmitan al SCC en el mismo orden en el que van a retransmitirse por el SCC.

El SCC 48 transmite información de estatus al NTCC 47 en intervalos de un segundo, en mensajes de "estatus de SCC" (1201, tabla 72). Un temporizador nominal actual en el mensaje contiene el valor nominal actual de la cuenta regresiva del temporizador de transmisión. El estatus de SCC en la palabra 8 está codificado en bits.

El NTCC 47 se comunica con el servidor 42 del NDC a través de una interfaz serie de 115200 bps, o directamente a través de TCP/IP, o por línea conmutada. El servidor soporta dos sistemas de NTCC simultáneos, para la redundancia de la estación de FM/NTCC, enviando los mismos datos de rastreador a ambos sistemas de NTCC, pero los rastreadores y concentradores de red operan sólo desde una cada vez. Este es el sistema principal, y si ese sistema falla, el servidor 42 de NDC ordena a los concentradores de red conmutar a la estación de FM secundaria, y poco después de esto los rastreadores conmutarán también a la estación secundaria.

Durante el funcionamiento normal, el servidor 42 envía paquetes que contienen datos que van a transmitirse a los vehículos (es decir, a los rastreadores instalados en los mismos), al NTCC 47. El NTCC formatea los datos en tramas de datos de transmisión y los envía al SCC. El NTCC dota al servidor 42 de un mensaje de estatus que va a transmitirse al comienzo de cada segundo entero, para permitir al servidor planificar las tareas de procesamiento. El mensaje de estatus indica el estatus del NTCC y el SCC al servidor, e informa al servidor respecto al espacio disponible en la cola de salida para los datos que van a enviarse a los vehículos.

Los mensajes usados en la comunicación entre el NTCC 47 (así como un NTCC adicional, si está presente) y el servidor 42 de NDC, se resumen en la tabla 73. Los NTCC de línea conmutada deben iniciar sesión dos veces, con un servidor de radio y banco de módems de 3Com/U.S. Robotics para el primer inicio de sesión, usando las indicaciones de "identificador de inicio de sesión:" y "contraseña:" estándar para autenticar el ID de usuario y la contraseña. Si un NTCC de línea conmutada inicia una sesión con éxito en la red, se conecta a un puerto de TCP en el servidor de NDC reservado para las conexiones de concentrador de red. Una vez conectado, el servidor de NDC envía un mensaje de "solicitud de información de inicio de sesión" (2104, tabla 74) al concentrador de red de conexión para autenticarlo con el servidor de NDC. El mismo par de ID/contraseña de usuario usado para iniciar sesión con el banco de módems se envía como respuesta en un mensaje de "respuesta de información de inicio de sesión" (2304, tabla 75). Sin embargo, los NTCC con conectividad TCP/IP con el servidor de NDC no necesitan iniciar sesión con el banco de módems, sino simplemente conectarse con un puerto de TCP en el servidor de NDC y responder al mensaje de "solicitud de información de inicio de sesión".

Una vez autenticado el NTCC, el servidor de NDC solicita un perfil de NTCC enviando un mensaje de "solicitud de perfil de NTCC" (4105, tabla 76). Aunque el NTCC puede modificar su perfil, el servidor de NDC mantiene un perfil preciso usando la información contenida en un mensaje de "respuesta de perfil de NTCC" (4305, tabla 77) que se envía mediante el NTCC en respuesta al mensaje de solicitud.

El NTCC controla la parte en tiempo real de la red de radio para el servidor de NDC. El NTCC envía un "mensaje 2 de estatus" (2103, tabla 78) al servidor al inicio de cada segundo, para usarse por el servidor como una marca de tiempo aproximada para planificar tareas periódicas. La precisión de la marca de tiempo depende de la tasa de transmisión a la que el NTCC y el servidor dan servicio de transmisión serie y reciben colas de datos, respectivamente. Si dos NTCC están conectados al servidor, el servidor usa la información de marca de tiempo desde el NTCC principal.

Cuando el NTCC solicita la conexión con el servidor de NDC, el servidor transmite datos que describen la estación de radio de FM a la que intentará conectarse el NTCC en un mensaje de "datos de FM" (2201, tabla 79) que indica la frecuencia de la estación de FM y la frecuencia de subportadora en la que opera el sistema de PROTRAK. La posición del transmisor de FM en latitud, longitud y altitud se proporciona en el mensaje para permitir al NTCC calcular el retardo de propagación de la difusión. El número de teléfono en el mensaje es una cadena ASCII terminada en nulo, que el NTCC debe marcar para conectarse con el SCC.

Para cada paquete de transmisión de estación base generado por el servidor de NDC, por ejemplo, "identificación de FM" "asignación de ranura" etc., el servidor envía un mensaje de "paquete de vehículo" (2202, tabla 80) que contiene el paquete de transmisión al NTCC, que va a transmitirse finalmente a los vehículos por el SCC a través de la subportadora de FM. El NTCC coloca este paquete en la cola de salida, y en el mensaje de difusión de estación base como permita el espacio. El NTCC no acusa recibo de los mensajes "paquete de vehículo", simplemente debido al volumen de mensajes que ha de coordinar el servidor.

Cuando el NTCC se conecta al servidor de NDC, éste último envía un mensaje de "desplazamiento de zona de tiempo local" (2203, tabla 81) al NTCC indicativo del desplazamiento, que el NTCC difunde a los rastreadores (a través del SCC y la transmisión de radio de subportadora de FM) con el paquete base de "tiempo de GPS". El servidor de NDC envía este mensaje 2203 de desplazamiento al NTCC no sólo en respuesta a la recepción de un mensaje de respuesta de perfil de NTCC válido, sino al inicio de cada hora. De esta manera, el NTCC mantiene la última información de zona de tiempo en todas las zonas de tiempo locales que cambian cada la hora.

El NTCC 47 se comunica a través de una interfaz serie a 38400 bps con el módulo 55 de techo, cuya CPU 56 recibe la difusión de FM a través del receptor 58 desde el SCC 48 en la estación 12 de radio. Como se describió anteriormente en el presente documento, el tiempo de llegada de los datos de FM se compara con el segundo entero de GPS, y la diferencia entre el inicio del segundo entero y el tiempo en el que se reciben los datos de mensaje se proporciona al NTCC 47 para desarrollar una corrección para la realimentación de control de sincronismo al SCC 48. El NTCC compara los datos recibidos con los datos proporcionados al SCC, para verificar que los datos correctos se transmitieron. El NTCC 47 proporciona información de RF al módulo 55 de techo, para permitir a éste sintonizar el receptor 58 de FM con la subportadora y canal adecuados.

Los mensajes usados para la comunicación entre el NTCC 47 y el módulo 55 de techo se resumen en la tabla 82. El NTCC envía un mensaje de "control de frecuencia" (3101, tabla 83) al módulo de techo durante la inicialización, ordenando a éste sintonizar con la frecuencia de radio de FM apropiada.

El NTCC proporciona tiempo e información de estatus al módulo de techo enviando un mensaje de "tiempo/estatus" (3102, tabla 84) en intervalos de un segundo. Aunque el modulo de techo en la realización ejemplar usa el tiempo de GPS para la sincronización con el PPS a partir del receptor de GPS, como alternativa puede usarse una CPU 56 de módulo de techo que no requiera información de tiempo periódica, sino simplemente información de inicialización para el receptor 54 de GPS. El mensaje de "tiempo/estatus", enviado poco después del PPS, contiene el tiempo en el PPS. Otra información de estatus y modo se proporciona también a la CPU de modulo de techo.

En un mensaje de "estatus" (3201, tabla 85), el módulo de techo proporciona su estatus al NTCC, incluyendo la frecuencia actual que está usándose. Una palabra de estado de sincronismo en el mensaje indica el estatus de sincronización de tiempo de GPS con bit 0 = tiempo recibido válido y bit 1= tiempo sincronizado. La palabra de estatus de FM está codificada con bit 0 = sintetizadores bloqueados, bit 1= modo de localización de sincronización de bits, bit 2 = sincronización detectada.

El módulo de techo comunica los datos de FM recibidos en un mensaje (3202, tabla 86) al NTCC, que el NTCC compara con los datos transmitidos para la sincronización de tiempo de trama y monitorización del transmisor y del receptor de módulo de techo. Durante el funcionamiento normal, los datos de FM se reciben empezando cerca del comienzo del segundo entero y finalizan un poco antes de finalizar el mismo de modo que se informa de los datos de FM durante un intervalo de un segundo al NTCC al comienzo del siguiente intervalo.

El módulo de techo indica la diferencia de tiempo (retardo) entre el segundo entero y la sincronización de bits de FM recibida en el NTCC en un mensaje de "sincronismo" (3203, tabla 87), para el control de lazo de sincronismo. El segundo entero se define por el PPS de GPS, y el mensaje de "sincronismo" debe enviarse de manera inmediata una vez calculado el retardo para permitir al NTCC calcular una corrección de reloj y enviarla al SCC antes del inicio del siguiente segundo entero. En el modo de ejecución normal, se detecta la sincronización aproximadamente 15 ms después del segundo entero. El tiempo y semana de GPS se proporcionan en el mensaje de "sincronismo" para el inicio del segundo entero para el que se calcula el retardo. El retardo especificado es el tiempo desde el inicio del segundo entero hasta la detección de la sincronización. La TPU que funciona a 5 MHz tiene una resolución de 0,2 \mus.

El receptor 54 de GPS del módulo 55 de techo es un receptor de GPS XR5M de NavSymm para la generación de la corrección de DGPS. El NTCC tiene dos interfaces serie para el receptor XR5M (un puerto de CDU y el puerto de salida de DGPS, usándose el puerto de CDU para controlar la operación del receptor y suministrando el puerto de DGPS correcciones de DGPS de formato RTCM) 104. De manera alternativa, el módulo 55 de techo puede implementarse de modo que la interfaz con su CPU 56 soporte las funciones de GPS.

Las interfaces discretas incluyen PPS (impulso por segundo) y reinicio, requiriendo el NTCC un PPS para sincronizar su ejecutivo con el tiempo de GPS. El módulo de techo usa también un PPS para el sincronismo de la difusión de subportadora, y en la realización actual, el receptor de GPS XR5M de Navstar proporciona el PPS, y el NTCC usa una señal de reinicio para controlar la inicialización de ese receptor.

\vskip1.000000\baselineskip

XII. Gestión de bases de datos y servidor de CCS (DMCS)

El DMCS (por ejemplo 27, figura 3) en un sitio 13 de cliente se describe de manera conveniente junto con el control de la interfaz entre el servidor 42 de NDC y los componentes que se comunican con el servidor, incluyendo los CCS (por ejemplo, 14, 15), las estaciones de orden de NDC (por ejemplo, 43, 45, figura 4), los concentradores de red (por ejemplo, 11-1, 11-2, figura 3), y el NTCC 47, y los mensajes usados para estas comunicaciones.

El formato de mensaje estándar usado para la comunicación entre el servidor de NDC y el resto de sistemas se basa en el formato de mensaje definido en el protocolo de interfaz de NavCore mencionado anteriormente, con una sección de cabecera de cinco palabras fija y una sección de datos opcional, tal como se muestra en la tabla 88. El formato de cabecera de mensaje estándar se muestra en la tabla 89.

La palabra de inicio del mensaje siempre es Ox8IFF, que indica el inicio del un mensaje válido. El ID de tipo de mensaje estándar (IDNN) indica la interfaz (I) en la que se usa un mensaje, la dirección (D) del mensaje, el fin, y el número (NN). El intervalo de ID de tipo de mensaje válido para los componentes de software que se interconectan con el servidor de NDC se muestra en la tabla 90, y, para los componentes de software que se interconectan con el DMCS, en la tabla 91. El campo de cuenta de palabras de datos indica el número de palabras de 16 bits contenidas en la parte de datos de un mensaje (siendo este campo 0 si el mensaje no tiene sección de datos), excluyendo el campo de suma de comprobación de datos.

En el campo de ID de indicadores/mensaje, el byte menos significativo (bits 7-0) identifica el mensaje si es necesario un acuse de recibo o un acuse de recibo negativo, y los bits 12, 11, y 10 son indicadores que indican el acuse de recibo requerido, acuse de recibo, y acuse de recibo negativo, respectivamente. Si un mensaje se envía con el bit (12) de acuse de recibo ajustado, el receptor debe responder usando el mismo ID de mensaje con el bit (11) de acuse de recibo o el bit (10) de acuse de recibo negativo establecido. Si no se recibe un acuse de recibo requerido dentro de un espacio de tiempo preestablecido, o se recibe un acuse de recibo negativo, el emisor debe enviar de nuevo el mensaje.

La suma de comprobación de cabecera se calcula añadiendo todas las palabras contenidas en la cabecera y llevando a cabo un complemento a 2 en la suma, expresada matemáticamente como (a partir del protocolo de interfaz de NavCore):

SUMA = Mod 2^{16}

\hskip0.3cm

\sum\limits^{4}_{1}palabra(I)

Suma de comprobación de cabecera = -SUMA si SUMA \neq -32768. Suma de comprobación de cabecera = SUMA si SUMA = -32768 donde:

1. La negación unaria se calcula como el complemento a 2 de palabras de datos de 16 bits.

2. Mod 2^{16} indica los 16 bits menores de un proceso aritmético (sólo se mantienen los 16 bits inferiores).

3. La suma es la suma binaria algebraica de las palabras indicadas por el subíndice (I).

4. El valor de suma -32768 debe tratarse como un caso especial puesto que no puede negarse.

\vskip1.000000\baselineskip

La mayoría de los mensajes estándar usados para comunicarse con el servidor de NDC tiene una sección de datos tal como se muestra en la tabla 92. La cuenta de palabras de datos en la cabecera de mensaje identifica el número de palabras de datos en la sección de datos, siendo éstas palabras de datos de 16 bits que forman un mensaje en el formato indicado por el ID de tipo de mensaje estándar. Los mensajes sin una sección de datos no tienen suma de comprobación de datos. Los mensajes con una sección de datos sí tienen suma de comprobación de datos, que se calcula de la misma manera que la suma de comprobación de cabecera. La única diferencia entre los dos cálculos es que la suma de comprobación de cabecera se calcula usando las primeras cuatro palabras de la cabecera, mientras que la suma de comprobación de datos se calcula usando todas las palabras de datos anteriores al campo suma de comprobación de datos.

Cada byte del mensaje estándar se transfiere con bits ordenados desde el menos significativo al más significativo, es decir, transmitiéndose/recibiéndose primero el bit menos significativo. Cada palabra se envía con el byte menos significativo en primer lugar.

Los formatos de mensaje usados para la interfaz servidor/DMCS de NDC son como sigue. Con respecto a los mensajes de orden/respuesta y las secuencias de solicitud/respuesta de mensaje que puede iniciar el servidor 42 de NDC, una vez que se ha conectado un DMCS 27 al servidor de NDC, debe estar listo para recibir y responder, si es necesario, a mensajes enviados por el servidor. El ID de tipo de mensaje 71XX identifica mensajes que inicia el servidor de NDC, mientras que las respuestas necesarias a estos mensajes se indican por de ID de tipo de mensaje 73XX (tal como se muestra en la tabla 90).

Se requiere que las aplicaciones de DMCS de línea conmutada inicien sesión dos veces. Un servidor RADIUS y un banco de módems U.S. Robotics llevan a cabo el primer inicio de sesión, usando indicaciones de inicio de sesión de PPP estándar para solicitar autenticación del ID y contraseña de usuario. Si un DMCS de línea conmutada inicia sesión con éxito en la red, puede conectar un puerto de TCP al servidor de NDC, punto en el que el servidor envía un mensaje de "solicitud de info de inicio de sesión" (7101, tabla 93) al DMCS que está conectando, para la autenticación con el servidor. El mismo par de ID/contraseña de usuario usado para iniciar sesión con el banco de módems se envía como una respuesta en un mensaje de "respuesta de info de inicio de sesión" (7301, tabla 94). El servidor de NDC devuelve un mensaje de "resultado de respuesta de info de inicio de sesión" (7107, tabla 95), para indicar el resultado del intento de inicio de sesión. El doble inicio de sesión es necesario para controlar el acceso tanto a la red del servidor de NDC como al propio servidor de NDC, y se oculta de los usuarios de DMCS de línea conmutada. Las aplicaciones de DMCS con conectividad de TCP/IP con el servidor de NDC no requieren iniciar sesión con el banco de módems, sino simplemente conectarse a un puerto de TCP en el servidor de NDC y responder al mensaje de "solicitud de info de inicio de sesión".

Cuando se envían mensajes (texto, predefinido o de expedición de sitio) a los rastreadores, puede especificarse un valor de tiempo límite. Si no se acusa recibo de un mensaje antes de su valor de tiempo límite especificado, el servidor de NDC envía un mensaje de "tiempo límite de mensaje" (7107, tabla 96) para indicar que no se había acusado recibo del mensaje y que no se intentará más enviar el mensaje a menos que se realice una solicitud de reenvío. Los mensajes enviados a rastreadores múltiples pueden tener acuse de recibo por un subconjunto de la lista original de recepción. Los ID de rastreador enumerados en el "tiempo límite de mensaje" son para los rastreadores que no consiguieron acusar recibo del mensaje antes del tiempo límite.

Las estaciones de orden de NDC tienen la opción de enviar un mensaje de "orden de NDC" (7102, tabla 97) a los CCS conectados al DMCS, para notificar a los usuarios de CCS eventos importantes (por ejemplo, aviso de caída del sistema durante la prueba). Un DMCS que recibe un mensaje de "orden de NDC" responde usando un mensaje de "respuesta de orden de NDC" (7302, tabla 98) y remitiéndolo a todos los CCS.

Mientras que el DMCS está conectado al servidor de NDC, recibe datos de rastreo en tiempo real desde el servidor en un mensaje de "datos de rastreo en tiempo real" (7103, tabla 99) para rastreadores asociados con el cliente respectivo. Tales mensajes, que pueden contener mensajes de varios tipos diferentes, por ejemplo, ubicación del rastreador, velocidad del rastreador, rumbo del rastreador, datos de usuario recibidos desde un rastreador, respuestas/acuses de recibo de mensaje, e información de estatus de sitio, se envían al DMCS a medida que los recibe el servidor. Los mensajes de datos de rastreo para rastreadores con un servicio de rastreo continuo o servicio de rastreo de sólo inicio de sesión (LOT) se reciben a una tasa de transmisión especificada por la tasa de actualización activa asociada del rastreador. Y para rastreadores con servicio de rastreo manual, los mensajes de datos de rastreo se reciben como resultado de una solicitud realizada por el DMCS con un mensaje de enviar solicitud de rastreo. El formato de mensaje de datos de rastreo en tiempo real se muestra en la tabla 100.

Como se describió anteriormente en el presente documento, los rastreadores tienen capacidad para detectar cuándo se ha encendido o apagado el arranque del vehículo asociado. Si un rastreador está en la red de RF y se apaga el arranque de un vehículo durante un intervalo de tiempo predeterminado, el rastreador solicita una ranura de baja potencia desde el servidor de NDC. Tras recibir su ranura de baja potencia, el rastreador se apaga hasta justo antes de su siguiente actualización. Los rastreadores continúan proporcionando actualizaciones en esta ranura mientras que el arranque permanece apagado o el voltaje de la batería del vehículo está por debajo de un valor mínimo. Un mensaje de "modo de potencia de rastreador" (7107, tabla 101) se envía al DMCS aplicable cada vez que un rastreador del que es responsable conmuta a o desde el modo de baja potencia.

Cuando la estación de orden de DMCS o NDC actualiza un perfil de rastreador, la información de perfil actualizada se reenvía a todas las aplicaciones de DMCS conectadas asociadas con el perfil en forma de mensaje de "actualización de perfil de rastreador" (7104, tabla 102), con el formato de perfil de rastreador mostrado en la tabla 103.

El servidor 42 de NDC no gestiona el historial de instalación para rastreadores, pero puede consultar el DMCS (por ejemplo, 27) para determinar cuándo se han instalado y retirado rastreadores en y de los vehículos. Un mensaje de "recuperar historial de instalación de rastreador" (7105, tabla 104) permite al servidor de NDC especificar un intervalo de fecha de instalación. El DMCS usa un mensaje de "respuesta de recuperar historial de instalación de rastreador" (7305, tabla 105) para suministrar información al servidor de NDC para todos los rastreadores que se instalaron en los vehículos durante el periodo de tiempo especificado. Puesto que el mensaje de respuesta puede ser bastante largo, se devuelve un mensaje de respuesta individual para cada rastreador instalado. Un registro de instalación de rastreador ejemplar se muestra en la tabla 106.

El DMCS 27, que es responsable de la gestión de la información de perfil de vehículo (por ejemplo, número de identificación de vehículo (VIN), estado, licencia, fabricación, modelo, año), proporciona esta información al servidor 42 de NDC en forma de mensaje de "recuperar lista de perfil de vehículo" (7106, tabla 107), tras la solicitud. El servidor de NDC normalmente realiza esta solicitud si conoce un VIN (que ha aprendido a partir del mensaje de "respuesta de recuperar historial de instalación de rastreador") y necesita información adicional sobre el vehículo. Si no se conoce el VIN, puede usarse recuperar perfil de vehículo por rastreador instalado. Un mensaje de respuesta de recuperar lista de perfil de vehículo y formato de perfil de vehículo se muestran en las tablas 108 y 109, respectivamente.

Una vez que un DMCS ha iniciado sesión con éxito en el servidor de NDC, puede enviar mensajes de orden al servidor con un ID de tipo de mensaje 72XX. Cualquier respuesta del servidor a estos mensajes de orden se identifica por el ID de tipo de mensaje 74XX. Los mensajes de orden/respuesta y las secuencias de solicitud/respuesta de mensaje iniciados por un DMCS que ha iniciado sesión se comentan a continuación.

Cuando los mensajes (texto, predefinido o expedición de sitio) se envían a los rastreadores, se asocia un ID de secuencia de mensaje con el mensaje. Los mensajes pendientes de acuse de recibo pueden cancelarse con el envío de un mensaje de "cancelar" (7215, tabla 110) con el ID de secuencia de mensaje asociado, que va seguido de un mensaje de "respuesta de cancelar mensaje" (7415, tabla 111).

Es necesaria una combinación de ID y contraseña de usuario para el acceso por línea conmutada o acceso por TCP al servidor de NDC. Los usuarios que inician sesión en la aplicación y red del servidor de NDC usan el mismo ID y contraseña de usuario para ambos. Una vez que un usuario ha iniciado sesión en el servidor de NDC, un mensaje de "modificar contraseña de cuenta" (7201, tabla 112) puede usarse para modificar la contraseña, y se responde con un mensaje de respuesta de modificar contraseña de cuenta (7401, tabla 113).

Cuando un perfil de rastreador se introduce en la base de datos del servidor de NDC, se introduce un servicio de rastreo como parte del perfil. Cada rastreador tiene un servicio de rastreo, con servicios de rastreo válidos siendo rastreo continuo, LOT, y rastreo manual. Los rastreadores con servicio de rastreo continuo envían su información de rastreo de forma periódica, incluso si un DMCS no está conectado al servidor de NDC para recibir esta información. Los rastreadores con servicio LOT transmiten su información de manera periódica si un DMCS está conectado al servidor de NDC para recibir esta información de rastreo. Los rastreadores con servicio de rastreo manual sólo transmiten su información de rastreo tras una solicitud. Para continuo y LOT, se introduce también una tasa de actualización (en segundos) como parte del perfil, para indicar la tasa de transmisión periódica a la que el rastreador debería enviar su información de rastreo, usándose la tasa de transmisión para establecer inicialmente una tasa de actualización activa del rastreador cuando un rastreador es apto por primera vez para introducir la red de radio. Puede enviarse un mensaje de "modificar servicio de rastreo" (7202, tabla 114), para modificar el servicio de rastreo y la tasa de actualización asociada, y va seguido de un mensaje de "respuesta de modificar servicio de rastreo" (7402, tabla 115).

Las aplicaciones de DMCS pueden enviar un mensaje de "solicitud de ping" (7203, tabla 116) para verificar su conexión con el servidor de NDC. Si se recibe un mensaje de "respuesta de ping" (7403, tabla 117), la conexión está activa y el servidor de NDC está operativo.

Con referencia de nuevo al mensaje de "tiempo límite de mensaje" enviado por el servidor de NDC, descrito anteriormente, se envía un mensaje de "reenviar" (7216, tabla 118) al servidor para indicar que debería volver a enviarse un mensaje a los rastreadores desde la lista original de los receptores que no consiguieron acusar recibo del mensaje antes del periodo de tiempo límite, seguido de un mensaje de "respuesta de reenviar mensaje" (7416, tabla 119).

Como con la responsabilidad del DMCS para la gestión y mantenimiento de la información de perfil del vehículo, y el uso de una lista de perfil de vehículo de recuperación, descrita anteriormente, el servidor de NDC mantiene un perfil de información para cada rastreador, que contiene información para identificar al rastreador. La información incluye los indicadores de servicio, tipo de servicio y la tasa de actualización del rastreador. Se envía un mensaje de "recuperar lista de perfil de rastreador" (7204, tabla 120) para recuperar una lista de perfiles de rastreador asociada con una cuenta de cliente. La lista que va a devolverse puede limitarse especificando los ID de rastreador. El mensaje de respuesta aplicable (7404) se muestra en la tabla 121. Los mensajes de texto pueden enviarse a los vehículos con un rastreador y un MDT. Un mensaje de "enviar" (7205, tabla 122) ordena al servidor de NDC enviar un mensaje de texto a todos los rastreadores asociados con el usuario solicitante o con una lista de rastreadores individuales identificados por ID de rastreador. Los conjuntos de respuesta de mensaje ejemplar predefinida se muestran en la tabla 123. Si el servidor de NDC pone en cola con éxito un mensaje que va a enviarse, se usa un mensaje de "respuesta de enviar mensaje" (7405, tabla 124) para indicar el ID de secuencia de mensaje asociado con el mensaje que está enviándose. Si el mensaje tiene acuse de recibo con éxito y/o se responde por un rastreador, el DMCS recibe un paquete de "respuesta de mensaje y datos de usuario" o "respuesta de mensaje corto y datos de usuario" dentro de un mensaje de "datos de rastreo en tiempo real" (comentado anteriormente) que contiene el mismo ID de secuencia de mensaje.

Los mensajes de texto predefinidos pueden también enviarse a vehículos con un rastreador y un MDT. Un mensaje de "enviar ID de mensaje predefinido" (7206, tabla 125) ordena al servidor de NDC enviar un ID de mensaje predefinido a todos los rastreadores asociados con el usuario solicitante o a una lista de rastreadores individuales identificados por ID de rastreador. Si el servidor de NDC pone en cola con éxito un mensaje que va a enviarse, se usa un mensaje de "respuesta de enviar ID de mensaje predefinido" (7406, tabla 126) para indicar un ID de secuencia de mensaje asociado con el ID de mensaje que está enviándose. Si el mensaje tiene acuse de recibo con éxito y/o se responde por un rastreador, el DMCS recibirá un paquete "respuesta de mensaje y datos de usuario" o "respuesta de mensaje corto y datos de usuario" dentro de un mensaje de "datos de rastreo en tiempo real" que contiene el mismo ID de secuencia de mensaje.

Se usa un mensaje de "enviar expedición de sitio" (7207, tabla 127) para facilitar la expedición y automatizar el registro de la llegada/partida del sitio. Se envía por el DMCS a un rastreador para indicar un área de sitio de trabajo y un mensaje (por ejemplo, dirección de la calle del sitio) para que el operador del vehículo lo visualice. Puede definirse un conjunto de respuesta predefinida o personalizada para permitir una respuesta manual. Tras la llegada/partida al/desde el sitio definido por el mensaje, el rastreador envía un paquete de "estatus de sitio" dentro de un mensaje de "datos de rastreo en tiempo real" para indicar la llegada/partida del sitio, o bien según la determinación del rastreador basándose en su latitud/longitud relativa al área de sitio de trabajo, o bien del operador del vehículo que usa el MDT para indicar la llegada/partida del sitio del rastreador, y un mensaje de "respuesta de enviar expedición de sitio" consecuente (7407, tabla 128).

Un mensaje de "enviar datos de usuario" (7208, tabla 129) ordena al servidor de NDC enviar un mensaje de datos de usuario a todos los rastreadores asociados con el usuario solicitante (cliente) o a una lista de rastreadores individuales por ID de rastreador. Si el servidor de NDC pone en cola con éxito un mensaje que va a enviarse, un mensaje de "respuesta de enviar datos de usuario" (7408, tabla 130) indica un ID de secuencia de mensaje asociado con el mensaje que está enviándose. Si un rastreador acusa recibo del mensaje con éxito, el DMCS recibe un paquete de "respuesta de mensaje y datos de usuario" o "respuesta de mensaje corto y datos de usuario" dentro de un mensaje de "datos de rastreo en tiempo real" que contiene el mismo ID de secuencia de mensaje.

Los rastreadores que tienen un servicio de rastreo manual sólo transmiten su información de rastreo tras solicitud. Un mensaje de "enviar solicitud de rastreo" (7209, tabla 131) permite al DMCS solicitar información de rastreo desde un rastreador específico. Si un rastreador recibe con éxito una solicitud de información de rastreo, transmite su información de rastreo durante la siguiente ranura de tiempo disponible para tal transmisión, y el DMCS solicitante recibe un mensaje de "datos en tiempo real" con la información de rastreo solicitada. Un mensaje de "respuesta de enviar de solicitud de rastreo" (7409) se muestra en la tabla 132.

Cuando el DMCS crea/actualiza/modifica un registro de instalación de rastreador, el registro se reenvía al servidor de NDC como una actualización enviada en forma de mensaje de "actualización de registro de instalación de rastreador" (7210, tabla 133). También, cuando el DMCS actualiza un perfil de vehículo, la información de perfil actualizada se reenvía al servidor de NDC en forma de mensaje de "actualización de perfil de vehículo" (7212, tabla 134).

XIII. Informe de estatus activado por eventos

Este aspecto de la invención proporciona un procedimiento y aparato para determinar e informar automáticamente de eventos desde un vehículo a un propietario o expedidor del vehículo en una ubicación que es remota al vehículo. Los eventos de los que va a informarse incluyen cambios en el estatus de ubicación, operación de vehículo o mediciones de carga y sistemas de vehículo. El ordenador de rastreo (rastreador) del vehículo se conecta a varios sensores que miden parámetros de interés para el expedidor o propietario, e informa de cambios críticos en parámetros en los ordenadores de CCS/DMCS de la red de TDMA en los cambios de estatus de visualización de ubicación del cliente para su uso por el expedidor, o registra datos para su análisis posterior. El software en el rastreador y una variedad de sensores permiten eventos de estatus abstractos, múltiples y complicados que son relevantes para aplicaciones específicas industriales o de vehículo que el rastreador va a determinar y de los que va a informar. Los informes generados automáticamente desde los vehículos permiten proporcionar al sitio del cliente datos considerablemente más precisos y oportunos que los disponibles de los operadores humanos de los vehículos.

La figura 33 es un diagrama de varios tipos de sensores y/o fuentes de medición conectados/suministrados de manera sencilla al ordenador 135 de rastreo (rastreador), o bien de manera separada o combinados entre sí, incluyendo determinados sensores "básicos", entradas analógicas, entradas discretas, entradas de TPU, e interfaces serie con el rastreador que pueden configurarse para casi cualquier medición y propósito de control. Una lista ampliada de entradas de sensor se explica a continuación. Éstas entran en las dos categorías amplias de (1) funciones de vehículo básicas y (2) funciones operativas del vehículo específicas en el sector industrial en el que se usa. Las funciones operativas requieren la adición de sensores a un vehículo estándar. El lector también puede regresar de nuevo a la figura 23 que ilustra determinados sensores particularmente significativos de funciones operativas para camiones hormigonera, tales como el camión 195, un sensor 281 de rotación del tambor y un sensor 281 de detección de caudal de agua de lavado, así como un conjunto de entradas 280 generalizado para el rastreador 135 desde fuentes de medición/sensores de los tipos a los que se ha hecho referencia en esta sección de la memoria descriptiva.

Los parámetros o funciones de vehículo básicas que se miden directamente por el rastreador pueden variar de un vehículo a otro, pero normalmente incluyen lo siguiente:

\bullet

Arranque de vehículo y tiempo de ejecución

\bullet

Iluminación

\bullet

Marcha atrás

\bullet

Velocidad de rueda (desde la transmisión)

\bullet

Puerta del pasajero/conductor abierta

\bullet

Acoplamiento de accionamiento de las cuatro ruedas

\bullet

Sirenas/luces de ambulancia

\bullet

Nivel de combustible

\bullet

Temperatura del líquido de refrigeración

\bullet

Presión del aceite

\bullet

Voltaje de la batería

\bullet

Avisos de motor

\vskip1.000000\baselineskip

Otras funciones de vehículo pueden requerir la adición de sensores para la medición, o puede medirse directamente sobre el equipo añadido al vehículo para llevar a cabo una función específica del ámbito en el que se usa el vehículo. Algunas funciones o parámetros típicos que entran dentro de esta categoría son:

\bullet

Alarmas por forzamiento o robo

\bullet

Apertura de puerta de carga

\bullet

Temperatura de carga

\bullet

Peso del vehículo

\bullet

Acoplamiento de toma de potencia: las tomas de potencia (PTO) pueden hacer funcionar una amplia gama de equipo que incluye:

- Bombas

- Cigüeñales

- Grúas

- Barrenas

\bullet

Comprobación de parámetros de bus de datos de motor y tolerancia

\bullet

Subida de caja volcadora o escotilla abierta

\bullet

Velocidad y sentido de rotación del tambor de mezcla preparada

\bullet

Uso de agua de lavado de mezcla preparada

\bullet

Volumen de agua de llenado de mezcla preparada

\vskip1.000000\baselineskip

Las funciones del vehículo se combinan con información de ubicación y velocidad desde el sistema de navegación. La correlación de mediciones con el movimiento del vehículo permite la activación de eventos basándose en la ubicación del vehículo, o calificar los datos medidos como la operación adecuada de un vehículo, o como una excepción a las operaciones habituales, tales como abrir una puerta de carga en el exterior de zonas habituales de carga/descarga del cliente o empresa.

A este respecto, el sistema permite al propietario o expedidor del vehículo definir zonas rectangulares en un mapa almacenado del área metropolitana de interés; por ejemplo, una zona 300 como la que se muestra en la figura 34. Las esquinas que definen las zonas (por ejemplo, 301, 302, 303, 304 para la zona 300) se envían a los vehículos de modo que el rastreador pueda determinar, basándose en su solución de navegación, si se encuentra dentro o fuera de cualquier zona en particular. Estas zonas se configuran normalmente para identificar sitios domésticos o de planta donde se ubican normalmente los vehículos o recogen la carga, o sitios de trabajo donde los vehículos se expiden normalmente para repartir una carga o realizar un servicio.

Las zonas pueden definir también zonas de mapa con otros fines como velocidad restringida, peso restringido o fronteras que no se permite sobrepasar al vehículo. Usando únicamente la navegación, el rastreador puede informar de

\bullet

Distancia recorrida entre zonas

\bullet

Encendido y apagado del motor

\bullet

Conducción sobre una velocidad especificada

\bullet

Conducción en tiempos inapropiados

\bullet

Paradas no autorizadas

\bullet

Tiempos de llegada y partida a y desde ubicaciones especificadas

\vskip1.000000\baselineskip

La combinación de información de ubicación con otros parámetros medidos en el vehículo puede generar otros eventos de estatus, tales como usar la ubicación del vehículo para confirmar el estatus correcto del vehículo, notificar al expedidor si una puerta de carga se abre en un momento o lugar inapropiado, o correlacionar un problema del motor con una ubicación en particular para entender las circunstancias subyacentes.

Cuando un rastreador del vehículo necesita transmitir datos de evento, solicita ranuras de tiempo especiales usando una de estas ranuras de tiempo. Se otorgan entonces tiempos de informe auxiliar suficientes, en intervalos de doce segundos, para enviar sus datos. La latencia total entre un evento que se detecta y la transmisión de datos se mantiene, preferentemente, inferior a treinta segundos.

Todos los datos que pasan a través de la red y otra información de estatus se almacenan en grandes servidores de bases de datos para la posterior recuperación de informes o análisis de actividad del vehículo. El rastreador informa de eventos, usando diferentes tipos de paquetes de datos dependiendo del evento. Los eventos indicados simplemente mediante la medición directa de una entrada se comunican en un formato de paquete de evento común que indica la entrada medida (discreta o analógica) y el nuevo valor. Éstos son eventos tales como puerta de carga abierta, cuatro ruedas motrices acopladas o bomba accionada por PTO activa. Estos datos se almacenan en la base de datos y se pasan a las aplicaciones del cliente. Puesto que un propietario (operador o abonado) de una flota puede tener muchos tipos de vehículos en la flota, y cada uno puede tener diferentes datos de interés de evento en las mismas entradas en el rastreador, los datos deben poder identificarse claramente de un vehículo a otro.

La identificación de los informes de evento por el rastreador se logra mediante una aplicación de configuración de rastreador que se ejecuta en el NDC. Cuando un rastreador se instala en un vehículo y se conectan sensores a sus entradas, la aplicación de configuración activa el rastreador enviándole una orden para las entradas anexas que identifica umbrales e histéresis al activar un evento en la entrada. La aplicación de configuración también almacena la asociación de cada una de las entradas del rastreador al tipo de evento específico, tal como puerta de carga abierta. En situaciones más complicadas en las que un vehículo tiene para operar un conjunto detallado de lógica para determinar cuándo y qué tipo de eventos suceden, por ejemplo un camión hormigonera o una ambulancia, la aplicación de configuración envía una orden al rastreador del vehículo para activar una sección entera de software para procesar entradas. En estos casos, los paquetes de datos específicos del sector industrial se envían por el rastreador para identificar estatus de evento detallado y datos que se corresponden con el evento.

A continuación se describen varias aplicaciones específicas para informar del estatus del vehículo basándose en eventos. Ejemplos de aplicaciones para sectores industriales específicos, a modo de ilustración y de manera no limitativa, son los siguientes: hormigón preparado, transporte de polvo a granel, transporte de transporte de aglomerados a granel y operación de ambulancia. Podrían enumerarse muchos más ejemplos de aplicaciones que requieren informes de evento automatizado. Las combinaciones y aplicaciones de parámetros que pueden medirse y de los que puede informarse son prácticamente ilimitadas.

A. Hormigón preparado

Mientras que el uso eficaz de los activos fijos es importante en cualquier empresa, es particularmente importante en el sector industrial del hormigón preparado. Este es principalmente un negocio de reparto, puesto que el producto que se reparte es esencialmente un producto básico y los costes de materia prima no varían de manera significativa entre los proveedores. El negocio, por lo tanto, es uno en el que el uso eficaz de los activos de transporte muy caros marca la diferencia entre la ganancia y la pérdida.

El camión hormigonera tiene una secuencia bien definida de eventos a través de los que se ejecuta en el proceso de reparto de hormigón, comprendiendo generalmente las etapas de

1)

Cargar

2)

Dejar la planta

3)

Llegar al trabajo

4)

Comenzar el vertido

5)

Finalizar el vertido

6)

Lavar

7)

Dejar el trabajo

8)

Llegar a la planta

\vskip1.000000\baselineskip

Se sabe que el sector industrial del hormigón preparado ha estado buscando un procedimiento para indicar estos eventos al expedidor de manera económica, precisa y oportuna. La indicación fiable de estos eventos al expedidor da como resultado el uso más eficaz de la flota de camiones. Conociendo la fase de operación en la que se encuentra cada camión, el expedidor puede elegir los mejores camiones disponibles para las siguientes cargas. Esto es particularmente cierto cuando las planificaciones planeadas se cambian por las necesidades del cliente o por retrasos en el reparto. Las compañías de mezclas preparadas han usado para estos eventos, normalmente, la voz del conductor o cuadros de estatus operados por el conductor.

El uso de voz y cuadros de estatus tiene una limitación fundamental porque se requiere la acción del conductor para notificar al expedidor su estado de operación actual. Incluso conductores bienintencionados olvidan con demasiada frecuencia notificar al expedidor. Las estimaciones del sector industrial revelan que la precisión de los datos proporcionados a través de estos medios es inferior al 10%. Los cuadros de estatus son cabezales de control interconectados con las radios de voz, teniendo el cuadro de estatus múltiples botones, normalmente un botón operable para indicar cada una de las fases de reparto mencionadas anteriormente. Una ventaja del cuadro de estatus es que los datos de éste pueden proporcionarse a aplicaciones de expedición habituales usadas en el sector industrial, para permitir al software de expedición rastrear el camión a través de las fases sin la intervención manual del expedidor. Sin embargo, esta ventaja se lleva a efecto con poca frecuencia debido a la poca fiabilidad de los datos del conductor, y la consecuente incapacidad del expedidor de realizar decisiones apropiadas para el uso más eficaz de los activos.

Con los sensores apropiados en el camión de transporte de hormigón y el software en el ordenador de datos inalámbrico, las fases de reparto de hormigón preparado pueden determinarse de manera automática y fiable. El secuenciado automatizado y fiable se consigue según este aspecto de la presente invención con la implementación de tres sensores básicos en el camión, así como con navegación fiable, y lógica de estados implicada. En una realización preferida, los sensores comprenden un sensor 280 de rotación del tambor (figura 23) que mide tanto la velocidad como el sentido del tambor mezclador, un sensor 281 de caudal de agua que mide el agua que está usándose para lavar el camión, y un interruptor de puerta (por ejemplo, asociado con el interruptor que es sensible a la apertura de la puerta para encender las luces interiores en la cabina del camión) que indica cuándo está abierta la puerta del conductor. La información con respecto a la ubicación y velocidad del vehículo se requiere para determinar cuándo el camión está en un sitio de planta o de trabajo (o de camino hacia el sitio). La lógica de estados une toda esta información para permitir al rastreador informar de cada fase del proceso de reparto de nuevo al sitio del abonado.

El sensor 280 de rotación del tambor mide la velocidad y sentido del tambor 287 del camión 195. En una realización preferida, el sensor 280 es, diferente a los contadores de revolución de tambor habituales instalados en camiones hormigonera que usan conmutadores de límite o conmutadores de proximidad o de efecto Hall magnético para contar las revoluciones de tambor, sino que en su lugar proporciona con precisión tanto la velocidad como el sentido, parámetros que son necesarios para ayudar a determinar cuándo está cargándose el camión, cuándo se inicia el vertido de contenidos de hormigón húmedo del tambor y cuándo se termina. La carga se lleva a cabo normalmente haciendo funcionar el tambor en el sentido de la "carga" a alta velocidad, mientras que el mezclado normal se realiza mientras el camión está en camino y a una velocidad de carga mucho más baja. El vertido se lleva a cabo normalmente a una velocidad de descarga muy baja, y la velocidad del tambor con frecuencia aumenta a medida que el tambor se vacía. Con referencia al diagrama de bloques del sensor 280 de rotación del tambor de la figura 35, se emplean dos sensores 288, 289 Allegro 3240 de efecto Hall, separados aproximadamente 5 centímetros (dos pulgadas) sobre una ménsula 290 que se monta en la parte superior de la transmisión 291 que acciona el tambor 287 de mezcla preparada. El sensor 280 se activa mediante seis imanes que se colocan alrededor del eje de rotación del tambor sobre la placa de interfaz entre la transmisión y el tambor. Los conjuntos 292 de imanes usados para accionar los sensores 288, 289 de efecto Hall se acoplan al reborde 293 de interfaz de transmisión del tambor.

La transmisión a la interfaz de tambor es la ubicación ideal para el sensor 280 de rotación cuando se añade al mezclador tras su construcción. Se prefiere la medición directa de RPM de transmisión pero sólo es práctica si la transmisión puede modificarse en la fábrica para suministrar una salida de velocidad/sentido de rotación. La interfaz de transmisión tiene dimensiones bien controladas y está relativamente libre de contaminantes y de la interferencia del conductor. Es también común entre los mezcladores de descarga delanteros y traseros. Otras ubicaciones potenciales para la colocación de sensores, tal como las ruedas locas en la boca del tambor o entre el punto medio del tambor y el chasis del camión, tienen inconvenientes que incluyen variaciones dimensionales de un fabricante a otro y de un modelo de vehículo a otro. Estas ubicaciones también están más expuestas a la grasa, la suciedad, los daños y variaciones en las distancias de separación debido a la flexión de la estructura del camión y rebote del tambor fuera de sus ruedas locas.

La parte superior de la interfaz de transmisión estándar tiene disponibles orificios de montaje para refrigeradores de aceite y tanques de agua, y pueden usarse para el montaje de sensores. A pesar del gran tamaño de un camión 195 de transporte de hormigón (figura 23), los márgenes con respecto a la interfaz de transmisión son muy estrechos. También existen aproximadamente 2,5 centímetros (una pulgada) de margen entre los pernos que sujetan el tambor a la placa de la interfaz y el pedestal en el que está montada la transmisión. Las opciones para el montaje de imanes se restringen si deben alojarse contadores de rotación instalados en fábrica. Estos sensores son de diversa variedad incluyendo conmutadores Reed que usan un diseño de perno de imán similar, conmutadores de límite accionados mediante un reborde acoplado a uno de los pernos de tambor, o sensores de proximidad accionados por un reborde justo fuera del radio de la placa de interfaz.

Para montar imanes en el radio de perno de tambor de la placa de interfaz para camiones hormigonera de cualquier fabricante, se usa una ménsula de soporte de imán. Para modelos de camión hormigonera actuales, se soportan las siguientes configuraciones: (1) sin ménsula, (2) una sola ménsula usada para desplazar un imán de actuación de contador de rotación, o (3) seis ménsulas usadas para sujetar imanes en radio cuando no hay disponibles orificios de pernos. Los mezcladores que usan transmisiones de ZF de la mayoría de fabricantes no requieren ménsula. En estos casos, están disponibles seis orificios roscados en la placa de interfaz, para insertar pernos de imán. Los mezcladores fabricados por McNeilus con transmisiones de ZF tienen un contador de rotación del conmutador Reed accionado por un perno de imán instalado en fábrica en la placa de interfaz, que se sustituye por un remache de imán desplazado respecto al radio de perno normal junto a la ménsula. El conmutador Reed se mueve desde su ménsula de fábrica hasta un orificio en la ménsula de sensor de velocidad y sentido recién instalada. Las transmisiones de EIP ocupan todos excepto dos orificios en la placa de interfaz con pernos para sujetar el tambor a la transmisión. Para esta transmisión, la ménsula se gira 90 grados y se invierte, de modo que el remache de imán se sujeta entre los pernos que acoplan el tambor a la placa. Se usan o bien seis conjuntos de ménsula-remache, o bien una combinación de dos pernos de imán y cuatro conjuntos de ménsula-remache.

El sensor 280 en esta realización ejemplar tiene una interfaz 294 de cuatro cables para el rastreador 135: potencia, tierra y una línea de señal desde cada sensor de efecto Hall. Las señales son entradas a la TPU del microcontrolador (CPU) 68332 de Motorola para el rastreador. La TPU tiene hardware dedicado para medir impulsos con un sincronismo muy preciso. Cuando un imán en el tambor pasa junto a un sensor, el sensor emite un impulso bajo. Con referencia ahora a la figura 36 que es un diagrama de sincronismo de los impulsos que resultan de la interacción de los sensores y el imán en la rotación del tambor, con los dos sensores 288, 289 indicados con A y B, respectivamente, se realiza una simple determinación de la velocidad y sentido del tambor 287. La velocidad se determina mediante dos impulsos 295, 296 sucesivos desde el sensor A. El tiempo entre impulsos (T_{A/A}) en segundos dividido por 6 imanes (impulsos) por revolución multiplicado por 60 segundos en un minuto da como resultado las RPM del tambor. La velocidad máxima de un tambor de mezcla preparada es de, aproximadamente, 16 RPM. El sentido se determina por el sincronismo relativo de los impulsos detectados por ambos sensores. Si el tiempo entre un impulso 295 en el sensor A y un impulso 297 en el sensor B (T_{A/B}) es inferior al tiempo al siguiente impulso 296 en el sensor A (T_{A/A}), entonces el tambor se gira en el sentido de A hacia B, que es el sentido de carga. A la inversa, si el tiempo entre un impulso en el sensor A y un impulso en el sensor B es superior al tiempo al siguiente impulso en el sensor A, entonces el tambor se gira en el sentido de B hacia A, que es el sentido de descarga.

La separación 298 (figura 35) entre las caras de los imanes y el sensor es una consideración importante. Durante la carga y en la carretera, el camión experimenta fuertes cargas de choques y vibración. Estas cargas pueden provocar que el tambor rebote en sus ruedas locas y que la estructura del camión se doble. Al envejecer los camiones y las transmisiones, el problema se agrava. Preferentemente, se proporciona una separación 298 de al menos aproximadamente 1,9 centímetros (tres cuartos de una pulgada) para evitar daños en los sensores o imanes.

Los camiones hormigonera tienen normalmente un tanque de agua que almacena agua a presión. El agua se usa para añadir agua a la mezcla de hormigón y también para lavar el camión cuando se ha completado un vertido. Para determinar cuándo está teniendo lugar el lavado, el agua que fluye a través de la manguera se mide usando un interruptor de caudal. El interruptor de caudal se activa a un umbral de volumen de flujo preestablecido. Varias tecnologías para el interruptor de caudal pueden usarse para detectar el caudal, concretamente: presión de aire en tanque de agua, corriente en remolino, presión diferencial a través de un orificio, y paletas o elementos deslizantes de deflexión de muelle. Un interruptor de caudal es un sensor 281 preferido (figura 23) para esta aplicación porque el volumen de caudal no es importante, únicamente el tiempo que se emplea en lavar el camión. Una consideración de diseño clave para un sensor o interruptor de caudal es que debe funcionar con agua que esté contaminada con suciedad y desechos como rocas y fragmentos grandes de óxido.

Para mezcladores de descarga posterior, el conductor debe salir del camión para configurar los conductos antes del vertido. Se usa un interruptor de puerta para determinar cuándo se abre la puerta del conductor. La apertura de la puerta del conductor se usa para confirmar la llegada al sitio de trabajo, pero no es crítica para la operación apropiada del sistema.

En la figura 37 se muestra un diagrama de transición de estados que define la lógica usada por el rastreador para combinar datos de sensor y de navegación para obtener automáticamente el estatus del mezclador. La lógica es necesariamente compleja para considerar todas las anomalías del flujo de reparto de hormigón normal que pueden encontrarse. Los umbrales y tiempos límite se ajustan para evitar falsas activaciones de estados lógicos a expensas de un pequeño retardo al indicar el evento. Los estados principales enumerados anteriormente se muestran en negrita en la figura.

El proceso de reparto se inicia encendiendo el arranque del camión (310) en la planta (311). Una vez inicializado el sistema de navegación, el rastreador instalado en el camión determina que está en la planta. Los mezcladores se cargan aparcándolos bajo la planta de hormigonado y haciendo funcionar muy rápido el tambor en el sentido de la carga. Esto lo detecta el rastreador si el camión tiene una velocidad de menos de aproximadamente 3,2 km (dos millas) por hora, el camión está en la planta, y la velocidad y sentido del tambor es aproximadamente el umbral de carga rápida, todo durante 60 segundos. Cuando esto se detecta (312), el rastreador transmite el estatus de carga (313).

Tras la carga, el camión normalmente continúa al foso de lavado donde se añade agua a la mezcla, se limpia el polvo del camión y se llena completamente el tanque de agua del camión. Un estado que puede detectarse pero que, normalmente, no requiere una compañía de mezcla preparada, es identificar si un camión está en el foso de lavado (314). Esto puede determinarse por un ligero cambio en la posición del camión y el estacionamiento tras la carga sin dejar la planta. A continuación, el camión dejará la planta. Esto se determina teniendo una ubicación fuera de la zona rectangular predeterminada (por ejemplo, véase la figura 34) que define la planta, y una velocidad por encima de 24 km (15 millas) por hora. Cuando esto se detecta (315), el rastreador transmite el estatus de salida de la planta (316). Se coloca una histéresis en el cruce de la frontera de la zona, de modo que un camión que se conduce a lo largo del borde de la zona no genere múltiples secuencias de llegada-salida de la planta.

El uso óptimo del sistema requiere que el expedidor envíe un mensaje de expedición al camión, que indica al rastreador la zona rectangular que define las fronteras del sitio de trabajo, pero no se requiere que el rastreador proporcione un estatus automatizado. La información de ubicación del sitio de trabajo permite al rastreador determinar la llegada al trabajo independientemente del comienzo del vertido, permite al rastreador determinar información de excepción sobre vertidos que tienen lugar lejos de los sitios de trabajo, y permite al software de optimización de ruta disponer de información fiable sobre los tiempos de viaje.

La llegada al trabajo se determina por entrar el camión en la zona de trabajo definida y después tener una velocidad por debajo de los 8 km (cinco millas) por hora durante al menos un minuto, o la apertura de la puerta del conductor, lo que suceda primero (317). Si no se ha definido una zona de trabajo, entonces se determina la llegada al trabajo por operar el tambor en el sentido de descarga durante más de 10 segundos (318). Como alternativa, puede usarse una fracción de una revolución del tambor en el sentido de descarga. Cuando se detectan estas condiciones, el rastreador transmite el estatus de llegada al trabajo (319).

El inicio de la condición de vertido se determina cuando el tambor se hace funcionar en el sentido de descarga durante 20 segundos, o como alternativa, a una o dos revoluciones. Una vez detectado esto (320), el vertido de inicio se transmite por el rastreador (321). Esto coloca el software de rastreador en el estado de vertido (322), y entonces se busca una condición de final de vertido.

El final del vertido puede detectarse de varias formas. Algunos vertidos se conducen en descarga lenta. Cuando el tambor está casi vacío, se acelera el tambor para extraer lo que queda de hormigón. Si el tambor se hace funcionar en descarga rápida durante 10 segundos después del funcionamiento en descarga lenta (323), esto activará el final del vertido (324). Si se usa el agua de lavado durante dos minutos (325), también se activa el final del vertido (326), ya que el uso de tanta cantidad de agua indica casi con certeza que el camión está lavándose. El final del vertido (327) también puede activarse si la velocidad del camión está por encima de 48 km (30 millas) por hora (328). Los camiones no suelen moverse tan rápido en un sitio de trabajo, particularmente si todavía están vertiendo porque los conductos se dejan normalmente acoplados al camión hasta que finaliza el vertido. Un procedimiento alternativo puede posibilitarse si la información con respecto a la cantidad de hormigón cargado en el camión se proporciona al rastreador de vehículo desde el expedidor (desde un CCS en el sitio del abonado a través del DMCS, el servidor de NDC, el NTCC, el SCC, la difusión de FM y el modulador de subportadora). En este caso, el final del vertido puede estimarse mejor mediante el número de revoluciones requerido para vaciar el tambor para un volumen dado originalmente cargado. Una segunda alternativa es usar un sistema de medición de peso a bordo tal como el AW4600 o el AW5600 de Air-Weigh. La tara del camión vacío puede compararse con el peso durante el vertido, y puede detectarse el final del vertido cuando el peso se aproxima a la tara.

El comienzo del lavado se determina por el uso de agua para lavar el camión durante una cantidad de tiempo predeterminada. Si el final del vertido (324) se detectó mediante un evento de descarga rápida (323), entonces el agua debe usarse durante un minuto (329) para indicar el estatus de lavado (330). Si el final del vertido (326) se determinó a partir del uso de agua durante dos minutos (325), entonces el estatus de lavado (331) se transmite junto con el estatus de final de vertido (326).

Un evento de salida del trabajo se transmite cuando el vehículo deja el sitio de trabajo definido. Se proporciona una copia de seguridad, tal como se muestra en la figura 37, para permitir el envío del estatus de salida del trabajo en caso de que no se haya definido una zona de trabajo. La salida del trabajo (332, 333) se determina en cualquier caso si la velocidad del vehículo es superior a 48 km (30 millas) por hora (334). Debe observarse que el estatus del sistema puede volver a vertido (322) en algunos casos después de detectar el lavado (331) o de la salida de trabajo (333), si el tambor se hace funcionar en descarga de nuevo antes de que el camión regrese a un sitio de planta (335). Esto permite al sistema soportar anomalías operativas como verter hormigón desde un camión en dos ubicaciones diferentes en un sitio de trabajo global.

Si se definen sitios de trabajo para el rastreador, pueden usarse para controlar el comportamiento del vehículo o del conductor que sea contrario a la política de los operadores (abonados) de flotas. Por ejemplo, si se detecta un vertido fuera del rectángulo del sitio de trabajo definido, el ordenador del vehículo puede generar una excepción y transmitirla. Esto alertará al expedidor de que el conductor puede estar vertiendo hormigón en una ubicación no autorizada y reducir la pérdida de material y mejorar la eficacia. Finalmente, la llegada a la planta (311) se detecta cuando el camión entra en un rectángulo que define una ubicación de planta y la velocidad es inferior a 24 km (15 millas) por hora (337).

Además de la secuencia de reparto de mezcla preparada normal, al propietario del negocio le interesa determinar la cantidad de agua añadida al tambor mezclador en el sitio de trabajo. De nuevo, los conductores son una fuente poco fiable de esta información puesto que no suelen registrar la cantidad añadida real. Es primordial añadir y conocer la cantidad correcta porque una mezcla incorrecta podría curarse de manera inapropiada.

La determinación de la cantidad de agua añadida puede lograrse colocando un medidor de caudal de agua en línea con la tubería que llena el tambor. Un ejemplo de una de estas unidades es la pieza nº 1200-1-1 de EMCO/Fluidyne. Estos tipos de medidores proporcionan normalmente un impulso o salida analógica. Cualquier tipo se integra fácilmente en las entradas estándar del ordenador de rastreo. El agua añadida se cuenta entre el tiempo en el que llega el camión al sitio de trabajo y termina el vertido. La cantidad añadida se transmite como un evento junto con el evento de final de vertido.

\vskip1.000000\baselineskip

B. Transporte de polvo a granel

Los camiones de transporte a granel transportan material en polvo tal como cal, cemento y cenizas volantes. Las tolvas graneleras se cargan desde la parte superior por la gravedad. Éstas se descargan haciendo pasar aire a través de una red de tuberías bajo las tolvas que, junto con la gravedad, empuja el material fuera de las tolvas y lo bombea hacia silos de almacenamiento. Las compañías de transporte a granel necesitan conocer cuándo el camión llega al sitio del cliente, cuándo comienza la descarga, cuándo finaliza la descarga y cuándo deja el sitio. Los requisitos básicos son muy similares a los descritos anteriormente para el sector industrial del hormigón preparado.

La descarga se realiza bombeando aire a través de las tuberías bajo las tolvas graneleras. La presión de aire se genera normalmente por el propio camión. Se realiza o bien por una bomba accionada por PTO o bien con una turbobomba accionada mediante gas de escape. En la mayoría de empresas, la bomba accionada por escape es más popular porque pesa mucho menos que la bomba de PTO. Con cualquier bomba el motor del camión funciona a altas RPM para generar la presión de aire requerida.

Determinar cuándo está encendida la bomba de PTO es bastante sencillo. Una de las entradas discretas se conecta a la entrada para la lámpara de la bomba que indica que se ha encendido. El cableado de entrada se diseña para garantizar que la entrada se activa incluso si la lámpara está inservible. Cada vez que el PTO se enciende o se apaga, el rastreador transmite un mensaje de estatus correspondiente para indicar el evento de cambio de estatus.

En camiones con turbobombas accionadas por escape, medir directamente es muy difícil si la bomba se ha acoplado. Puesto que la bomba se acciona mediante el escape del motor, el alojamiento está muy caliente. No pueden usarse de manera fiable mecanismos electrónicos de circuito integrado en este tipo de entorno, por lo que es difícil utilizar interruptores de caudal electrónicos e interruptores de presión. La palanca de acoplamiento en la bomba es mecánicamente poco precisa y difícil de manejar. Además, cualquier sensor fuera del camión cerca de la bomba está sujeto a manipulaciones indebidas.

\newpage

Con estas dificultades en mente, se usa un sensor de tacómetro para determinar si el camión está bombeando material. El circuito de sensor se diseña para detectar una señal analógica de nivel bajo, convertirla en un nivel de señal digital y dividir la frecuencia a un valor más bajo. La señal de frecuencia más baja se conecta al rastreador a través de la interfaz de TPU para una entrada discreta. El software en la CPU de rastreador cuenta los impulsos recibidos y los convierte a RPM.

La velocidad del motor se usa junto con el camión parado para determinar el estatus de carga. Si el camión está parado y la velocidad de motor está por encima del umbral de RPM apropiado durante el tiempo suficiente para que el conductor configure el camión y conecte las mangueras de reparto, entonces se transmite el estatus de descarga. Si el expedidor ha proporcionado al rastreador información del sitio, ésta se usa para garantizar que la descarga tiene lugar en el sitio. Si está fuera del sitio, el rastreador transmite una excepción para avisar al expedidor.

C. Transporte de agregados a granel

Los camiones de transporte de agregados a granel son camiones volcadores que transportan grava, roca y arena generalmente para su uso por empresas de mezclas preparadas, construcción o diseño de paisajes. Este sector industrial tiene requisitos similares para el informe de estatus del camión cuando se transporta material de polvo a granel. Los propietarios del vehículo necesitan conocer cuándo y con qué frecuencia un camión volcador vacía su carga. Los vehículos en este sector industrial se alquilan a menudo por empresas de mezclas preparadas u otras que no disponen de sus propios camiones de transporte de agregados. El propietario del vehículo requiere informes de horas de tiempo de ejecución, millas de odómetro y el número de cargas transportadas, con fines de facturación; y el arrendador necesita conocer las mismas cuestiones, para garantizar que está consiguiendo la eficacia deseada del camión.

Para determinar si la plataforma volcadora del camión está levantada, debe usarse un sensor fiable que sea inmune a la vibración, el choque y el entorno de carga extremo. Se prefiere un sensor de proximidad que pueda percibir la presencia de metal a distancias de más de media pulgada, y tal sensor está disponible en una gama de modelos de sensores de la compañía de sensores Turck. El sensor se conecta a una de las entradas discretas en el rastreador. Cuando el rastreador determina que la plataforma volcadora ha dejado la proximidad del sensor por un intervalo de tiempo de protección para eliminar ruido, transmite el estatus de la volcadora.

Los propietarios de camiones volcadores también están interesados en evitar las pérdidas de carga. Como con las mezclas preparadas, si se proporcionan definiciones limítrofes o de zona geográfica aplicables en datos de mapeo o de otro modo al rastreador, entonces puede determinar si la volcadora se elevó fuera de las áreas en las que debía repartirse el producto.

D. Ambulancia

Los operadores de ambulancia deben demostrar al gobierno que cumplen con los tiempos de respuesta requeridos para llamadas de emergencia y de no emergencia. Esto lo hacen proporcionando informes de cada trayecto, con respecto a la ubicación de recogida, el hospital al que se dirigieron, la hora de las llamadas y otros factores. Los informes se recopilan a menudo manualmente basándose en registros de llamadas. Las empresas de ambulancias también deben cumplir con reglamentos, regulaciones y ordenanzas locales especiales que se aplican a vehículos de emergencia operativos tales como abstenerse de utilizar luces de emergencia y sirenas en carreteras sin tráfico o en situaciones no urgentes.

Estas funciones pueden automatizarse hasta un grado significativo percibiendo cuándo se apagan y se encienden las luces y las sirenas y usando zonas de expedición. Cuando las ubicaciones de escena de llamada y las ubicaciones de hospital o clínica se rodean por zonas y se proporcionan al rastreador del vehículo, y se instalan sensores en las luces de emergencia, el rastreador puede determinar los tiempos de respuesta y suministrar ubicaciones de manera automática.

Cuando el rastreador detecta que las luces de emergencia están encendidas, transmite el evento y el momento en el que se encendieron las luces. Comienza entonces también a contar el tiempo y la distancia hasta que el vehículo llega a la escena de llamada. La llegada a la escena de llamada puede determinarse automáticamente si se proporciona una zona al rastreador o puede determinarse manualmente por el conductor pulsando un botón de estatus en el terminal de visualización. Una vez que se determina la llegada a la escena, el rastreador transmite el tiempo de llegada y la distancia recorrida. La secuencia de salir de la escena y llegar al hospital se establece de manera similar a través de los sensores y la detección de zona.

Para la generación de informes, todos los datos informados por el rastreador se almacenen para su procesamiento posterior en el sitio del propietario de la ambulancia. El informe contiene entonces cada ubicación, distancia recorrida y tiempo de respuesta de llamada junto con la condición de emergencia para cada tramo del viaje.

XIV. Procesamiento de diversidad de FM de rastreador

La recepción fiable de datos en un entorno de radio móvil es difícil de lograr. La calidad de la señal varía rápidamente con el tiempo a medida que un vehículo se mueve a través de las perturbaciones de obstrucciones, reflexiones y fuentes de radio que interfieren. La señal de datos de subportadora de FM recibida por el rastreador de vehículo puede aparecer y desaparecer rápidamente debido al oscurecimiento de señal y a reflexiones multitrayectoria. Para recuperar datos de la forma más fiable posible, el diseño de red usa una combinación de codificación FEC, entrelazado de bits, CRC en paquetes de mensaje y diversidad de espacio en el sistema de antena del vehículo. Aunque los tres primeros de éstos se han comentado anteriormente en el presente documento, se revisarán brevemente para comodidad del lector.

La corrección de errores sin canal de retorno es un código (23, 12) Golay. Este algoritmo codifica cada 12 bits de información de mensaje en 23 bits de código. Una vez recibido, el algoritmo de descodificación puede corregir errores de hasta 3 de los 23 bits de código. El transmisor de FM envía 300 bytes de mensaje (2400 bits) de datos codificados de esta manera en 4600 bits de código cada segundo.

Para mejorar la inmunidad del enlace a ráfagas de errores provocados por efectos de multitrayectoria o bloqueo, se entrelazan los bits transmitidos. Las 200 palabras de código transmitidas en la subportadora de FM cada segundo se dividen en cinco bloques de 40 palabras. Dentro de cada bloque de 40 palabras, el orden de bits de los datos transmitidos se vuelve a disponer de modo que los primeros 40 bits de cada palabra se envían en primer lugar, seguidos de los segundos 40 bits, y así sucesivamente. Este entrelazado permite al algoritmo Golay corregir hasta 120 errores de bits consecutivos.

Algunas condiciones de error son tan graves que pueden corregirse de manera fiable por el código FEC. Para protegerse de esto, cada paquete de mensaje en los datos de FM contiene una CRC de 16 bits estándar usada para la detección de errores. Si la CRC no es correcta para un paquete, entonces el paquete se expulsa. La CRC puede detectar cualquier error de bit impar, todos los errores de bits dobles y muchas otras combinaciones de errores. Para longitudes de paquete de mensaje cortas normalmente transmitidas en el sistema, el algoritmo de CRC de 16 bits es suficiente junto con el entrelazado y la corrección de errores sin canal de retorno.

La diversidad de espacio en el sistema de recepción del vehículo se usa para reducir errores provocados por oscurecimientos o desvanecimientos de multitrayectorias de duración más larga que no pueden corregirse sólo con el entrelazado. Dos receptores (207, 208, figura 24) y antenas (191, 192, véase también la figura 23) independientes se usan para recibir la señal de subportadora de FM para el rastreador 135. Las antenas de recepción están separadas en el techo del vehículo tanto como sea razonablemente posible. A frecuencias de FM de 100 MHz, la distancia entre las antenas sobre el vehículo debe ser de, aproximadamente, 4 pies, para un procesamiento de diversidad óptimo. Normalmente, esta distancia se consigue en la mayoría de los vehículos. Las señales de las dos antenas se demodulan de manera independiente para los datos de banda base, usando dos cadenas de receptor. El CPU 203 de rastreador usa entonces un algoritmo de procesamiento de diversidad, para recuperar los datos.

La CPU 203 de rastreador descodifica los datos recibidos usando una secuencia de algoritmos: (1) desentrelazado de bits, (2) descodificación de FEC Golay, (3) procesamiento de diversidad y análisis sintáctico de paquete de mensaje. El desentrelazado y la descodificación Golay son algoritmos relativamente sencillos. El algoritmo de diversidad y el de análisis sintáctico se describen a continuación.

Un diagrama de flujo del algoritmo de diversidad se muestra en la figura 38. Cada segundo, el rastreador comienza a procesar datos recibidos sobre la subportadora de FM. Los dos flujos de datos recibidos se indican mediante el flujo A y el flujo B. La descodificación de diversidad se inicia al comienzo del bloque de mensaje, o bien con el flujo A o bien con el B. La sincronización de mensaje se ajusta al comienzo porque el primer byte que va a procesarse en los datos de cada segundo es el inicio de un paquete de mensaje. También se ajusta un indicador, para permitir la conmutación al flujo (350) alternativo si no puede descodificarse apropiadamente un mensaje.

Si el siguiente byte que va a procesarse es un ID de mensaje válido (351), entonces el flujo actual se analiza sintácticamente para el paquete de mensaje (352). Si se supera la CRC para el paquete (353), la sincronización de mensaje se mantiene (354) y el puntero se incrementa en la longitud de mensaje (355). Entonces el siguiente byte se comprueba para un ID de mensaje válido (351). Éste es el flujo normal de procesamiento hasta que se detecta el final de la marca de memoria intermedia (358) o no hay más espacio en la memoria intermedia para mensajes (359).

Si un ID de mensaje válido no se detecta y el otro flujo no se ha comprobado, entonces el byte correspondiente en el otro flujo (360) se comprueba para un ID de mensaje válido (351). Si es válido, entonces el mensaje se analiza sintácticamente, tal como se describió anteriormente. De manera alternativa, en cualquiera de los casos anteriores, si la CRC no es válida (362), entonces el paquete de mensaje está dañado. Si había sincronización de mensaje (363), entonces se incrementa una cuenta de error (364); de lo contrario, esto indica que el ID de mensaje no era el inicio de un mensaje real. Si el otro flujo no ha sido analizado sintácticamente para el mensaje, se somete a prueba.

Si en cualquier punto ninguno de los flujos consigue producir un ID de mensaje válido o paquete de mensaje analizado sintácticamente, el algoritmo vuelve a comprobar ambos flujos byte a byte para localizar el siguiente paquete de mensaje válido.

Se apreciará, a partir de la descripción anteriormente detallada, que ciertos objetivos, características y aspectos de la presente invención son particularmente dignos de mención. Por un lado, se proporciona un sistema de información de gestión de flota de vehículos para la gestión de activos de flota que permite la identificación de ubicación y dirección de movimiento de cada vehículo de la flota en tiempo real y la comunicación automática directamente con las oficinas de gestión, para informar de la dirección y ubicación del vehículo, y también, del estatus de eventos predeterminados en los que el vehículo puede estar implicado, en el que un aparato en un centro de distribución o control de red asigna a cada vehículo de la flota una única ranura de tiempo para transmitir su información de comunicación sobre una red de comunicaciones sin interferir sustancialmente en transmisiones de otros vehículos en sus propias ranuras de tiempo respectivas. Por otro lado, se proporciona una sincronización de tiempo precisa a todos los elementos de la red, que es al menos en parte una red inalámbrica de TDMA, por medio de un PLL de control de sincronismo, para distribuir una referencia de tiempo basada en GPS de satélite de posición global remota por toda la red. La red incluye una interfaz de dúplex completo de doble banda con TDMA en una mitad de la interfaz y difusión en la otra mitad. También, los microprocesadores en los componentes en toda la red tienen cada uno una unidad de procesamiento de tiempo para llevar a cabo una sincronización de reloj precisa en 10 microsegundos para la parte de TDMA de dicha red.

Otro más reside en la provisión de un aparato para establecer un protocolo para las entradas por transmisores de vehículo en la red, en ranuras de tiempo asignadas para la transmisión periódica de mensajes, y un aparato para proporcionar diversidad de espacio de los mensajes recibidos desde el transmisor de vehículo, para evitar datos dañados. Se proporcionan, también, diferentes intervalos de transmisión periódica, para diferentes vehículos en la red, asignando dinámicamente las ranuras para varias tasas de actualización. Adicionalmente, se proporcionan ranuras de informes auxiliares, para permitir informes rápidos de datos importantes por los respectivos transmisores de vehículo, independientemente de intervalos de transmisión periódica más lentos. Y un aparato en el sistema soporta reparto, tanto garantizado como no garantizado, de datos de mensajes. Además, las ranuras asignadas son únicas para los respectivos vehículos, para minimizar el uso de ancho de banda permitiendo que la identidad del vehículo de transmisión se deduzca a partir de la ranura de tiempo en la que se recibió la transmisión. Cada transmisor de vehículo tiene un filtro para los datos de banda base para reducir el ancho de banda ocupado del canal en el que se transmiten los datos, incluyendo la eliminación de los datos de sincronización para minimizar la sobrecarga de datos que no portan información. El filtro de banda base se implementa por un microcontrolador digital que sustituye un flujo de datos de onda cuadrada original de los datos de banda base con transiciones deterministas que reducen el contenido harmónico y mantienen anchos de bits, independientemente de la frecuencia de entrada de datos. Cada receptor en la red tiene la capacidad para recuperar los datos transmitidos sin información de sincronización transmitida ubicando el inicio de cada mensaje de datos dentro de una ventana de tiempo de exploración predeterminada sin ayuda de patrones de sincronización de bits. Con este fin, se lleva a cabo una búsqueda iterativa que registra secuencialmente la entrada de los datos en retardos cada vez más grandes desde el tiempo de inicio del mensaje nominal hasta que se localiza un paquete de datos válido.

Aún otro más se proporciona para captar, detectar o medir ciertos eventos repetidos en los que el vehículo estará implicado según la misma naturaleza básica de su uso, y según el sector industrial en el que se use, y para el informe automático de los eventos detectados a la oficina de gestión de flota. Éstos son aspectos especialmente importantes para vehículos que deben seguir una rutina prescrita, por motivos de eficacia, por la oficina de gestión de flota, tal como camiones hormigonera, transportadores de materiales aglomerados y en polvo, ambulancias, etc.

Aunque en el presente documento se han descrito ciertas realizaciones y procedimientos ejemplares y preferidos en este momento para ilustrar el mejor modo actualmente contemplado para poner en práctica la invención, resultará evidente para los expertos en la técnica pertinente, que pueden realizarse variaciones y modificaciones sin apartarse del verdadero espíritu y alcance de la invención. Por consiguiente, se prevé que la invención se considere limitada sólo en la medida requerida por las reivindicaciones adjuntas y las reglas y principios de la ley pertinente.

\vskip1.000000\baselineskip

Apéndice A

Glosario de términos abreviados

ACCUMINT (interruptor de acumulador)

BFSK (modulación por desplazamiento en frecuencia binaria)

CCS (estación de orden de cliente)

CDU (unidad de control y visualización)

CPU (unidad de procesamiento central)

CRC (comprobación de redundancia cíclica)

DGPS (sistema de posicionamiento global diferencial)

DMCS (gestión de base de datos y servidor de CCS)

DR (navegación a estima)

DSP (procesador de señal digital)

FEC (corrección de errores sin canal de retorno)

FM (modulación en frecuencia)

FSK (modulación por desplazamiento en frecuencia)

GP 2010 (componente de extremo frontal de RF del conjunto de chip de GPS Plessey)

GP2021 (componente correlator de conjunto de chip de GPS Plessey)

GPS (sistema de posicionamiento global)

SI (frecuencia intermedia)

IOD (emisión de datos)

ISP (proveedor de servicios de Internet)

ISR (rutina de servicio de interrupción)

ITC (captura/cuenta de transición de entrada)

LFS (almacén de archivo lineal)

LNA (amplificador de bajo ruido)

LOT (rastreo de sólo inicio de sesión)

MDT (terminal de datos/visualización móvil)

NDC (centro de distribución de red)

NTCC (ordenador de control de sincronismo de red)

OC (comparación de salida)

PCS (servicios de comunicación personal)

PDC (centro de datos PROTRAK^{TM})

PIT (temporizador de interrupción periódica)

PPM (partes por millón)

PPP (protocolo punto a punto)

PPWA (modulación por ancho de impulso periódico)

PSTN (red de teléfono pública conmutada)

PWM (modulación por ancho de impulso)

QSPI (interfaz periférica serie en cola, un periférico de procesador 68332 de Motorola)

RF (radiofrecuencia)

RI (intervalo de repetición)

RSS (raíz cuadrada de la suma de los cuadrados)

RXD (datos de recepción)

SCA (autorización de comunicaciones subsidiarias)

SCC (ordenador de control de subportadora)

SCI (interfaz de comunicaciones serie)

SMR (radio móvil especializada)

SQL (lenguaje de consulta estructurado)

SRAM (memoria de acceso aleatorio estática)

TCR (registrador de control de sincronismo)

TCXO (oscilador de cristal de temperatura compensada)

TIC (marca de tiempo (tics de temporizador) del conjunto de chip de GPS)

TDMA (acceso múltiple por división de tiempo)

TPU (unidad de procesamiento de tiempo)

TXD (datos de transmisión)

UART (receptor/transmisor asíncrono universal)

UHF (frecuencia ultra alta)

\vskip1.000000\baselineskip

Apéndice B

Tablas TABLA 2 Resumen de paquete base

18

19

TABLA 3 Paquete de mensaje de texto - rastreador único o toda la flota

20

\vskip1.000000\baselineskip

TABLA 4 Conjuntos de respuesta de mensaje predefinido

21

\vskip1.000000\baselineskip

TABLA 5 Paquete de mensaje de texto -grupo de rastreador

22

23

\vskip1.000000\baselineskip

TABLA 6 Paquete de lista de ID de interfaz de mensaje de grupo de rastreador

24

\vskip1.000000\baselineskip

TABLA 7 Bloque de lista de ID de rastreador

25

26

27

TABLA 8 Paquete de definición de mensaje de ID predefinido

28

\vskip1.000000\baselineskip

TABLA 9 Paquete de mensaje de ID predefinido - rastreador único o toda la flota

29

\vskip1.000000\baselineskip

TABLA 10 Paquete de mensaje de ID predefinido - grupo de rastreador

30

31

\vskip1.000000\baselineskip

\vskip1.000000\baselineskip

\vskip1.000000\baselineskip

TABLA 11 Paquete de DGPS

32

TABLA 12 Paquete de mensaje de datos de usuario - rastreador único o toda la flota

33

\vskip1.000000\baselineskip

\vskip1.000000\baselineskip

\vskip1.000000\baselineskip

\vskip1.000000\baselineskip

TABLA 13 Paquete de mensaje de datos de usuario - grupo de rastreador

35

TABLA 14 Paquete de ID de cuadrícula

36

\vskip1.000000\baselineskip

\vskip1.000000\baselineskip

TABLA 15 Paquete de identificación de FM

37

\vskip1.000000\baselineskip

\vskip1.000000\baselineskip

TABLA 16 Paquete de identificación de UHF

39

TABLA 17 Paquete de tiempo de GPS

40

\vskip1.000000\baselineskip

\vskip1.000000\baselineskip

TABLA 18 Ajustar paquete de definición de ranura de intervalo de repetición principal

41

\vskip1.000000\baselineskip

\vskip1.000000\baselineskip

TABLA 19 Añadir definición de ranura de intervalo de repetición auxiliar-único intervalo por paquete de ID de rastreador

42

TABLA 20 Añadir definición de ranura de intervalo de repetición auxiliar - único intervalo por paquete de ID de red/interfaz

43

\vskip1.000000\baselineskip

\vskip1.000000\baselineskip

\vskip1.000000\baselineskip

TABLA 21 Añadir definición de ranura de intervalo de repetición auxiliar - número limitado de intervalos por paquete de ID de rastreador

44

\vskip1.000000\baselineskip

\vskip1.000000\baselineskip

\vskip1.000000\baselineskip

TABLA 22 Añadir intervalo de repetición auxiliar SA por paquete de ID de red/interfaz

45

TABLA 23 Paquete de ranuras de entrada de red disponibles

47

\vskip1.000000\baselineskip

\vskip1.000000\baselineskip

TABLA 24 Paquete de info de config de ranura de intervalo de repetición

48

\vskip1.000000\baselineskip

\vskip1.000000\baselineskip

TABLA 25 Paquete de respuesta de entrada de red

49

TABLA 26 Paquete de permiso de solicitud de entrada de red

50

\vskip1.000000\baselineskip

\vskip1.000000\baselineskip

\vskip1.000000\baselineskip

\vskip1.000000\baselineskip

TABLA 27 Purgar intervalos de repetición asignados - por paquete de lista de ID de rastreador, ID de cliente, o ID de rastreador

51

TABLA 28 Acuse de recibo de respuesta de mensaje

52

\vskip1.000000\baselineskip

\vskip1.000000\baselineskip

\vskip1.000000\baselineskip

\vskip1.000000\baselineskip

TABLA 29 Mensaje de expedición de sitio

53

TABLA 30 Mensaje de purga de sitio

54

\vskip1.000000\baselineskip

\vskip1.000000\baselineskip

\vskip1.000000\baselineskip

\vskip1.000000\baselineskip

TABLA 31 Paquete de acuse de recibo de datos de usuario

56

TABLA 32 Paquete de ID de cuadrícula 2

57

\vskip1.000000\baselineskip

TABLA 33 Acuse de recibo de estatus de sitio

58

\vskip1.000000\baselineskip

TABLA 34 Tasas de transmisión de intervalo de repetición de actualizador de rastreador planeado

60

TABLA 35 Definiciones de byte/bit de bloque de datos de estado de rastreador

61

\vskip1.000000\baselineskip

\vskip1.000000\baselineskip

\vskip1.000000\baselineskip

TABLA 36 Definiciones de byte/bit de bloque de datos de estado reducido

62

\vskip1.000000\baselineskip

\vskip1.000000\baselineskip

\vskip1.000000\baselineskip

TABLA 37 Definiciones de código de estatus de red

63

TABLA 38 Bloque de acuse de recibo/respuesta de mensaje

64

\vskip1.000000\baselineskip

\vskip1.000000\baselineskip

\vskip1.000000\baselineskip

TABLA 39 Resumen de paquete de rastreador

65

TABLA 40 Definiciones de bit de paquete de solicitud de entrada de red

67

\vskip1.000000\baselineskip

\vskip1.000000\baselineskip

TABLA 41 Definiciones de bit de paquete de estado y estatus

68

\vskip1.000000\baselineskip

\vskip1.000000\baselineskip

TABLA 42 Definición de bit de paquete de datos de usuario fiables

69

TABLA 43 Definiciones de bit de paquete de estado y estatus cortos

70

\vskip1.000000\baselineskip

\vskip1.000000\baselineskip

TABLA 44 Definiciones de bit de paquete de datos de usuario cortos fiables

71

\vskip1.000000\baselineskip

\vskip1.000000\baselineskip

TABLA 45 Definiciones de bit de paquete de estatus y datos de usuario de estado reducidos

72

TABLA 46 Definiciones de bit de paquete de respuesta de mensaje y datos de usuario

74

\vskip1.000000\baselineskip

TABLA 47 Definiciones de bit de paquete de respuesta de mensaje corto y datos de usuario

75

\vskip1.000000\baselineskip

TABLA 48 Definiciones de bit de paquete de estatus de sitio

76

TABLA 49 Definiciones de bit de paquete de prueba incorporada (BIT)

78

\vskip1.000000\baselineskip

TABLA 50 Bloque de datos de paquete de prueba incorporada (BIT) (Sistema de RF y Red, Tipo= 0)

79

\vskip1.000000\baselineskip

\vskip1.000000\baselineskip

TABLA 51 Pruebas incorporadas (BIT)

80

TABLA 52 Bloque de datos de paquete de prueba incorporada (BIT) (Navegación, tipo=2)

81

\vskip1.000000\baselineskip

\vskip1.000000\baselineskip

\vskip1.000000\baselineskip

TABLA 53 Bloque de datos de paquete de prueba incorporada (BIT) (Versión, tipo = 3)

82

TABLA 54 Bloque de datos de paquete de prueba incorporada (BIT) (Mezcla preparada, tipo = 4)

83

TABLA 55 Definición de mensaje predefinido

84

TABLA 56 Canales y funciones de TPU

85

86

TABLA 57 Datos de navegación

87

\vskip1.000000\baselineskip

\vskip1.000000\baselineskip

TABLA 58 Datos de mensaje recibido (7102)

88

TABLA 59 Datos de usuario recibidos (7103)

89

\vskip1.000000\baselineskip

\vskip1.000000\baselineskip

TABLA 60 Datos de mensaje disponibles (7104)

90

\vskip1.000000\baselineskip

\vskip1.000000\baselineskip

TABLA 61 Lista de mensaje de datos de usuario (7106)

91

TABLA 62 Solicitud de datos (7201)

92

\vskip1.000000\baselineskip

\vskip1.000000\baselineskip

TABLA 63 Respuesta de mensaje de texto (7202)

93

\vskip1.000000\baselineskip

\vskip1.000000\baselineskip

TABLA 64 Salida de datos de usuario (7203)

94

\vskip1.000000\baselineskip

\vskip1.000000\baselineskip

TABLA 65 Solicitar datos de mensaje disponibles (7204)

95

TABLA 66 Mensaje de solicitud (7205)

96

\vskip1.000000\baselineskip

\vskip1.000000\baselineskip

TABLA 67 Solicitar lista de mensajes de datos de usuario (7206)

97

\vskip1.000000\baselineskip

\vskip1.000000\baselineskip

TABLA 69 Resumen de mensaje de NTCC/SCC

98

\vskip1.000000\baselineskip

\vskip1.000000\baselineskip

TABLA 70 Control de sincronismo (1101)

99

TABLA 71 Trama de datos de transmisión (1102)

100

\vskip1.000000\baselineskip

\vskip1.000000\baselineskip

TABLA 72 Estatus de SCC (1201)

101

\vskip1.000000\baselineskip

\vskip1.000000\baselineskip

TABLA 73 Resumen de mensaje de servidor/NTCC

102

TABLA 74 Mensaje de solicitud de info de inicio de sesión (2104)

103

\vskip1.000000\baselineskip

\vskip1.000000\baselineskip

\vskip1.000000\baselineskip

\vskip1.000000\baselineskip

TABLA 75 Mensaje de respuesta de info de inicio de sesión (2304)

104

\vskip1.000000\baselineskip

\vskip1.000000\baselineskip

\vskip1.000000\baselineskip

\vskip1.000000\baselineskip

TABLA 76 Mensaje de solicitud de perfil de NTCC (4105)

105

TABLA 77 Mensaje de respuesta de perfil de NTCC (4305)

106

\vskip1.000000\baselineskip

\vskip1.000000\baselineskip

TABLA 78 Mensaje de estatus 2 (2103)

107

108

109

\vskip1.000000\baselineskip

TABLA 79 Datos de FM (2201)

110

\vskip1.000000\baselineskip

TABLA 80 Paquete de vehículo (2202)

111

TABLA 81 Desviación de zona de tiempo local (2203)

112

\vskip1.000000\baselineskip

\vskip1.000000\baselineskip

\vskip1.000000\baselineskip

TABLA 82 Resumen de mensaje de módulo de techo/NTCC

113

\vskip1.000000\baselineskip

\vskip1.000000\baselineskip

\vskip1.000000\baselineskip

TABLA 83 Control de Frecuencia (3101)

114

TABLA 84 Tiempos/Estatus (3102)

115

\vskip1.000000\baselineskip

\vskip1.000000\baselineskip

TABLA 85 Estatus (3201)

116

\vskip1.000000\baselineskip

\vskip1.000000\baselineskip

TABLA 86 Datos de FM recibidos (3202)

117

TABLA 87 Sincronismo (3203)

118

\vskip1.000000\baselineskip

\vskip1.000000\baselineskip

TABLA 88 Formato de mensaje estándar

119

\vskip1.000000\baselineskip

\vskip1.000000\baselineskip

TABLA 89 Formato de cabecera de mensaje estándar

121

TABLA 90 Servidor de intervalo de ID de tipo de mensaje para NDC

122

\vskip1.000000\baselineskip

\vskip1.000000\baselineskip

TABLA 91 Intervalo de ID de tipo de mensaje para DMCS

124

TABLA 92 Sección de datos de mensaje estándar

125

\vskip1.000000\baselineskip

\vskip1.000000\baselineskip

TABLA 93 Mensaje de solicitud de información de inicio de sesión (7101)

126

\vskip1.000000\baselineskip

\vskip1.000000\baselineskip

TABLA 94 Mensaje de respuesta de inicio de sesión (7301)

127

TABLA 95 Mensaje de resultado de respuesta de info de inicio de sesión (7501)

129

\vskip1.000000\baselineskip

\vskip1.000000\baselineskip

TABLA 96 Mensaje de tiempo límite de mensaje (7107)

130

\vskip1.000000\baselineskip

\vskip1.000000\baselineskip

TABLA 97 Mensaje de orden de NDC (7102)

131

132

\vskip1.000000\baselineskip

TABLA 98 Mensaje de respuesta de orden de NDC (7302)

1320

\vskip1.000000\baselineskip

TABLA 99 Mensaje de datos de rastreo en tiempo real (7103)

133

134

\vskip1.000000\baselineskip

TABLA 100 Formato de mensaje de datos de rastreo en tiempo real

135

136

137

\vskip1.000000\baselineskip

\vskip1.000000\baselineskip

\vskip1.000000\baselineskip

TABLA 101 Mensaje de modo de potencia de rastreador (7107)

138

TABLA 102 Mensaje de actualización de perfil de rastreador (7104) Mensaje de actualización de perfil (7104)

139

\vskip1.000000\baselineskip

\vskip1.000000\baselineskip

\vskip1.000000\baselineskip

\vskip1.000000\baselineskip

TABLA 103 Formato de perfil de rastreador

140

TABLA 104 Mensaje de recuperar historial de instalación de rastreador (7105)

141

TABLA 105 Mensaje de respuesta de recuperar historial de instalación de rastreador (7305)

143

\vskip1.000000\baselineskip

\vskip1.000000\baselineskip

\vskip1.000000\baselineskip

\vskip1.000000\baselineskip

TABLA 106 Registro de instalación de rastreador

144

145

\vskip1.000000\baselineskip

\vskip1.000000\baselineskip

\vskip1.000000\baselineskip

\vskip1.000000\baselineskip

TABLA 107 Mensaje de recuperar lista de perfil de vehículo (7106)

146

TABLA 108 Mensaje de respuesta de recuperar lista de perfil de vehículo (7306)

147

\vskip1.000000\baselineskip

\vskip1.000000\baselineskip

\vskip1.000000\baselineskip

TABLA 109 Formato de perfil de vehículo

149

TABLA 110 Mensaje de cancelar (7215)

150

\vskip1.000000\baselineskip

TABLA 111 Mensaje de respuesta de cancelar mensaje (7415)

151

\vskip1.000000\baselineskip

TABLA 112 Mensaje de modificar contraseña de cuenta (7201)

152

TABLA 113 Mensaje de respuesta de modificar contraseña de cuenta (7401)

153

\vskip1.000000\baselineskip

\vskip1.000000\baselineskip

TABLA 114 Mensaje de modificar servicio de rastreo (7202)

154

TABLA 115 Mensaje de respuesta de modificar servicio de rastreo (7402)

155

\vskip1.000000\baselineskip

\vskip1.000000\baselineskip

\vskip1.000000\baselineskip

TABLA 116 Mensaje de solicitud de ping (7203)

156

\vskip1.000000\baselineskip

\vskip1.000000\baselineskip

\vskip1.000000\baselineskip

TABLA 117 Mensaje de respuesta de ping (7403)

157

TABLA 118 Mensaje de reenviar (7216)

158

\vskip1.000000\baselineskip

\vskip1.000000\baselineskip

\vskip1.000000\baselineskip

TABLA 119 Mensaje de respuesta de reenviar mensaje (7416)

159

TABLA 120 Mensaje de recuperar lista de perfil de rastreador (7204)

160

\vskip1.000000\baselineskip

\vskip1.000000\baselineskip

TABLA 121 Mensaje de respuesta de recuperar lista de perfil de rastreador (7404)

161

\vskip1.000000\baselineskip

\vskip1.000000\baselineskip

TABLA 122 Mensaje de enviar (7205)

163

TABLA 123 Conjuntos de respuesta de mensaje predefinido

165

\vskip1.000000\baselineskip

\vskip1.000000\baselineskip

\vskip1.000000\baselineskip

TABLA 124 Mensaje de respuesta de enviar mensaje (7405)

166

167

\vskip1.000000\baselineskip

TABLA 125 Mensaje de enviar ID de mensaje predefinido (7206)

168

TABLA 126 Mensaje de respuesta de enviar ID de mensaje predefinido (7406)

169

\vskip1.000000\baselineskip

TABLA 127 Mensaje de enviar expedición de sitio (7207)

170

171

\vskip1.000000\baselineskip

\vskip1.000000\baselineskip

\vskip1.000000\baselineskip

TABLA 128 Mensaje de respuesta de enviar expedición de sitio (7407)

172

173

\vskip1.000000\baselineskip

\vskip1.000000\baselineskip

TABLA 129 Mensaje de enviar datos de usuario (7208)

174

TABLA 130 Mensaje de respuesta de enviar datos de usuario (7408)

175

\vskip1.000000\baselineskip

\vskip1.000000\baselineskip

\vskip1.000000\baselineskip

TABLA 131 Mensaje de enviar solicitud de rastreo (7209)

176

TABLA 132 Mensaje de respuesta de enviar solicitud de rastreo (7409)

177

\vskip1.000000\baselineskip

\vskip1.000000\baselineskip

TABLA 133 Mensaje de actualización de instalación de rastreador (7210)

178

\vskip1.000000\baselineskip

\vskip1.000000\baselineskip

TABLA 134 Mensaje de actualización de perfil de vehículo (7212)

179

Claims (6)

1. Un aparato (280) sensor para un tambor (287) mezclador de un camión (195) hormigonera,

caracterizado por

un sensor (280) para producir una señal que indica la velocidad y sentido del tambor mezclador del camión; comprendiendo también el aparato al menos un imán (292) montado alrededor del eje de rotación del tambor mezclador del camión, y sensores (288, 289) de campo magnético duales montados en relación enfrentada fija en el mismo, en el que los sensores detectan el imán cuando el imán pasa delante de los sensores, y

un circuito (135) de lógica de estados que determina si el camión hormigonera está en un estado de carga, un estado de comenzar vertido o un estado de finalizar vertido basándose en la velocidad y sentido del tambor señalada por el sensor (280).

2. El aparato según la reivindicación 1, en el que la señal es una señal eléctrica.

3. El aparato según la reivindicación 2, en el que la fase de la señal eléctrica indica el sentido del movimiento del tambor.

4. Aparato según la reivindicación 2, en el que la frecuencia de la señal eléctrica indica la velocidad del tambor.

5. El aparato según la reivindicación 2, en el que se producen al menos dos señales eléctricas, y en el que la frecuencia de una de la señales indica la velocidad del tambor, y la fase relativa entre las dos señales indica el sentido del tambor.

6. El aparato según la reivindicación 1, en el que el al menos un imán comprende al menos dos imanes individuales.