SciELO - Scientific Electronic Library Online

 
vol.42 número1Alternativa para el cálculo de las alturas reducidas sobre una tierra esférica índice de autoresíndice de materiabúsqueda de artículos
Home Pagelista alfabética de revistas  

Servicios Personalizados

Articulo

Indicadores

  • No hay articulos citadosCitado por SciELO

Links relacionados

  • No hay articulos similaresSimilares en SciELO

Compartir


Ingeniería Electrónica, Automática y Comunicaciones

versión On-line ISSN 1815-5928

EAC vol.42 no.1 La Habana ene.-abr. 2021  Epub 17-Mayo-2021

 

Artículo original

Computador de a bordo: Una solución nacional

Aboard computer: A national solution

0000-0003-3947-3529Tirso R. Ramos Bello1  *  a, 0000-0003-4132-1479Sergio D. Pupo Cruz1  b, 0000-0001-7449-1939Rafael A. Codorniú Trujillo2  c

1SERCONI. Holguín, Cuba

2Facultad de Ingeniería Eléctrica, Universidad de Oriente

RESUMEN

En este artículo se presenta el desarrollo de hardware y software de un dispositivo para el seguimiento y control de cualquier vehículo empleando el Sistema de Posicionamiento Global (GPS), el Sistema Global para las Comunicaciones Móviles (GSM), el Servicio General de Paquetes vía Radio (GPRS) y las redes de Fidelidad Inalámbrica (Wi-Fi). Este desarrollo responde a una demanda real del programa nacional de gestión y control de flotas del Ministerio del Transporte (MITRANS), para su producción por el grupo de la electrónica del Ministerio de Industria (MINDUS); dirigido a la creación de un nuevo producto para sustituir importaciones con independencia y soberanía tecnológica. El hardware se concibe de forma modular con dos placas electrónicas, una placa de procesamiento que exhibe un procesador NXP i.MX 6UltraLite ejecutando Linux y otra con los componentes específicos para este tipo de equipos incluyendo la fuente de alimentación. El software es una aplicación embebida C++ desarrollada con la herramienta multiplataforma Qt Creator; para supervisar y reportar, periódica y eventualmente, los datos de interés del vehículo. Además de los datos internos en el equipo pueden recolectarse datos externos mediante las interfaces de entradas/salidas (E/S), RS232 y la Red de Área de los Controladores (CAN). Para su visualización y análisis los datos pueden enviarse en tiempo real (modo activo) y/o descargarse de forma diferida (modo pasivo). La conformidad de los ensayos de laboratorio, atendiendo a las normas ISO 16750-2, y el éxito en la introducción de las primeras 3,000 unidades demuestran la validez de este desarrollo.

Palabras-clave: Seguimiento de vehículos; Gestión inteligente del transporte; Comunicaciones inalámbricas; Posicionamiento global

ABSTRACT

In this article is presented a device hardware and software development in order to track and control any vehicle using Global Positioning System (GPS), Global System for Mobile Communications (GSM), General Packet Radio System (GPRS) and Wireless Fidelity networks (Wi-Fi). This development answer a real demand made by the national fleet & control management program from Transport Ministry (MITRANS), in order to be manufactured by the electronic group from the Industry Ministry (MINDUS); oriented to the creation of a new product to replace imports with technology independence & sovereignty. Hardware is conceived in a modular way with two electronic boards, one board as processing that exhibit an NXP i.MX6 UltraLite processor running Linux and the other one with specific components for these types of equipment including power supply. Software is an embedded C++ application, developed with Qt Creator multiplatform tool; to supervise and report, periodic and eventually, vehicle’s relevant data. Besides equipment´s internal data external data can be collected from I/O, RS232 and controller area network (CAN) bus. Data for their visualization and analysis could be sent in real time (active mode) and/or downloaded deferred (passive mode). Compliance with labs essays, attending to ISO 16750-2, and the successful introduction of first 3,000 units demonstrate validity of this development.

Key words: Vehicle tracking; Transport intelligent management; Wireless communications; Global positioning

Introducción

Mundialmente las empresas que utilizan medios de transporte terrestres necesitan acceder oportunamente a la información del vehículo para poder garantizar un servicio de calidad a sus clientes con un uso eficiente de los recursos [1, 2]. La ubicación geográfica, la velocidad, el curso, el odómetro, las revoluciones por minutos del motor (RPM), el nivel de combustible, entre otras variables digitales y/o analógicas comúnmente conforman la información de interés. Para recolectar, almacenar y opcionalmente enviar esta información hacia un servidor remoto encargado de su gestión se instala en el vehículo un dispositivo electrónico conocido como dispositivo de seguimiento o computador de a bordo que se compone, en su nivel más elemental, de un módulo receptor GPS y un transceptor GSM/GPRS [3, 4, 5, 6, 7].

En Cuba, con el objetivo dar un mejor servicio y a la vez optimizar y ahorrar los recursos que intervienen en las transportaciones de carga y pasaje, navales vinculadas a la pesca, maquinarias agrícolas y transporte especializado, en febrero de 2006 se inició la implementación del Sistema de Gestión y Control de Flotas (SGCF) basado en el Sistema Global de Navegación por Satélites (GNSS). Su implantación generalizada se materializó en 2008 mediante la resolución 53/108 del MITRANS. A esta compleja tarea se fueron integrando varias empresas del país para poder garantizar los disímiles servicios demandados con la mayor independencia y soberanía tecnológica posible. El sistema Móvilweb desarrollado por la empresa GeoSí para la gestión y control de flotas pudiera considerarse el ejemplo más relevante de esta integración.

Los primeros dispositivos de seguimiento utilizados por el SGCF fueron de la marca TechAgro, en diferentes modelos siendo el SELVEC el más avanzado, desarrollados por técnicos cubanos del Centro de Producción de Animales de Laboratorio (CENPALAB). Su nivel de introducción rondó las 16,000 unidades, producidas entre los años 2006 y 2010, y gracias a la robustez de su diseño muchos todavía se encuentran en operación. Posteriormente, a partir del año 2013 fueron introducidos los localizadores IRIS, de la empresa española Tecnología GPS, que han sido los de mayor nivel de introducción en el país con más de 30,000 unidades.

Algunas empresas con requerimientos específicos optaron por otras soluciones. Dos ejemplos ilustrativos son la Unidad Constructora del Mariel (UCM) perteneciente a la Zona Especial del Mariel (ZED) y la empresa productora de níquel Comandante Pedro Soto Alba de Moa perteneciente al grupo empresarial CUBANÍQUEL. La primera instaló en 2018 aproximadamente 1,000 dispositivos Profi 2.0 de tecnología rusa en sus medios de transporte utilizando para la gestión de la flota el sistema de Gestión Inteligente del Transporte (GIT) de la empresa XETID. La segunda introdujo a partir de 2014 el control de 200 vehículos mineros empleando distintos dispositivos hasta que recientemente instalara el modelo FM6300 de tecnología rusa utilizando para la gestión de la flota el sistema MóvilWeb.

Para retomar las soluciones nacionales se le solicitó a la empresa de Servicios Técnicos de Computación, Comunicaciones y Electrónica del Níquel (SERCONI) desarrollar un computador de a bordo, para su producción y comercialización por la industria electrónica, con un diseño lo suficientemente flexible para adaptarse a un amplio espectro de exigencias. Como parte de este trabajo se realizó una revisión de las soluciones instaladas en Cuba, algunas soluciones foráneas y las publicaciones científicas de diferentes autores, identificándose ciertas limitaciones tecnológicas asociadas al hardware y software de estos dispositivos que limitan o dificultan su aplicación práctica. A partir de estas limitaciones surge como problema científico la necesidad de mejorar, mediante el diseño, la tecnología de los dispositivos de seguimiento de vehículos para obtener la información con mayor precisión y fiabilidad. Sobre las bases anteriores se procedió a desarrollar un dispositivo electrónico denominado CaBv3 con su software de gestión asociado que constituye el motivo de este artículo.

- Revisión del estado del arte

Se revisaron cerca de treinta publicaciones científicas de diferentes autores y cuatro de los principales dispositivos instalados en Cuba, tres de tecnología foránea y uno de tecnología nacional. Durante la revisión se prestó atención a los principales parámetros que caracterizan a este tipo de dispositivos, identificando sus limitaciones y posibles variantes de solución.

A continuación, se presentará un análisis crítico de la solución CaBv3 para conocer las ventajas que suponen mejoras tecnológicas, así como las limitaciones de esta versión. Para complementar el análisis se mostrará en la Tabla 1 una comparación de cinco de los dispositivos instalados en Cuba incluyendo CaBv3.

El seguimiento de vehículos consiste en determinar la ubicación geográfica de un vehículo y transmitir esta información hacia un servidor ubicado remotamente [2,8]. La tendencia ha sido al seguimiento en tiempo real (modo activo) y diferido (modo pasivo) [2]. El modo activo se refiere al envío de datos a intervalos regulares, a solicitud y/o eventualmente utilizando preferiblemente tecnología GSM/GPRS [3, 5]. El modo pasivo se refiere a la extracción de los datos, removiendo el medio que los contiene, cuando el vehículo retorna a una ubicación específica para descargarlos hacia una computadora [2].

A diferencia de las soluciones más recientes que priorizan el modo activo (vea por ejemplo Profi 2.0 y FM6300 en la Tabla 1) CaBv3 potencia ambos modos de operación. Puede trabajar en modo activo a través de la red GPRS o a través de una red Wi-Fi (note en la Tabla 1 que solo CaBv3 dispone de esta funcionalidad) como una alternativa económica al servicio de datos móviles liberando la sobrecarga en dichas redes [9]. El modo pasivo dispone de dos opciones, una por comunicación Wi-Fi y otra por memoria USB. La opción Wi-Fi con mayor velocidad, alcance y capacidad de conexiones que la alternativa Bluetooth de IRIS-807 permite gestionar simultáneamente a distancia todos los vehículos dentro de la base de transporte sin necesidad de interactuar físicamente con el equipo. La opción por memoria USB hace una copia de la trayectoria actual sin eliminarla del dispositivo, a diferencia de SELVEC que limpia la Compact Flash al finalizar cada descarga lo cual consume mucho más tiempo. Es importante señalar que CaBv3 cuenta con mayor capacidad de almacenamiento interno que el resto de las soluciones (vea el parámetro # Flash en la Tabla 1) pudiendo almacenar trayectorias de hasta un año de antigüedad. Esta ventaja puede apreciarse mejor si se compara con los históricos de las soluciones SELVEC e IRIS-807 que están por debajo de los 30 días. Por estas razones se considera más eficiente la gestión de flotas utilizando CaBv3.

Tabla 1 Comparativa de las soluciones instaladas en Cuba. 

Marca Fabricante, País Procesador, Velocidad @ RAM # Flash Modos de operación GNSS @ Respaldo (horas) Com. @ E/S Costo Referencia
TechAgro SELVEC CENPALAB, Cuba PIC18F8722, 40MHz @ 3,936B # 128KB, 1KB EEPROM Pasivo (Compact Flash), * Activo (GPRS) GPS @ - (0h) 2xRS232 @ 10 $150.00
IRIS-807 Tecnología GPS, España LPC2387, 72MHz (máx.) @ 64KB # 512KB, 32Mb Flash serie Activo (GPRS), Pasivo (Bluetooth) GPS+GLONASS @ Litio 1150mAh (4h) 1-Wire, 1xRS232, Mini-USB @ 7 €180.00 (Pasivo) €207.00 (Activo)
CaBv3 SERCONI, Cuba i.MX 6UltraLite, 528MHz @ 512MB # 4GB Activo (GPRS, Wi-Fi), Pasivo (Wi-Fi, USB) GPS/QZSS +GLONASS @ Litio 1200mAh (4h) 2xRS232, CAN, USB, MiniUSB @ 3 $154.00
Profi 2.0 Omnicomm, Rusia **MHz @ **MB # 8MB Activo (GPRS) GPS+GLONASS @ Li-Polímero (7h) 1-Wire, USB, CAN, 1xRS232, 1xRS485 @ 9 $316.46
FM6300 Teltonika, Rusia STM32, **MHz @ **MB # 1MB+Ranura Memoria Externa Activo (GPRS,SMS) GPS+GLONASS @ Ni-MH 8.4V 550mA (2h10min) 1-Wire (4xTemp), 1-Wire, 1xRS232/RS485, J1708,LVCAN @ 11 $150.00

* SELVEC ha sido aplicado solamente en modo pasivo para el SGCF.

** Se desconoce su valor.

CaBv3 utiliza un procesador ARM de alto rendimiento que permite ejecutar el Sistema Operativo (S.O.) Linux. El uso de ARM (Advanced RISC Machines) se ha hecho popular debido a una mayor capacidad de procesamiento que el resto de los microcontroladores, como los PICs (Peripheral Interface Control) de Microchip, o los MSPs (Mixed Signal Processors) de Texas Instruments [10, 11]. Un sistema embebido simple y de bajo costo puede realizarse sin usar un S.O., sin embargo, considerando el tiempo y esfuerzo de diseño se presenta como mejor opción el uso de un S.O. embebido [12]. El uso de Linux se debe a la calidad y disponibilidad de código, amplio soporte de hardware, implementación de diversos protocolos de comunicación e interfaces para la programación de aplicaciones (API), variedad de herramientas de desarrollo disponibles, condiciones favorables de licencia, independencia de proveedores y costo [11]. El núcleo de Linux tiene soporte para muchos buses de datos y protocolos de comunicación de utilidad para los desarrolladores incluyendo como mínimo bus CAN, Modbus, SPI, I2C y puerto serie [11]. Todo esto permitió desarrollar desde cero en un tiempo muy breve la aplicación al nivel de la competencia.

Recientemente, es muy común que los módulos receptores GPS se beneficien del soporte multi-GNSS [13]. Entre los beneficios está la reducción de los errores horizontales y verticales [14]. Por ejemplo, a cielo abierto el 50% del error horizontal es aproximadamente 3 m para GPS y de 1.8 m a 2.8 m cuando se usan combinaciones de dos sistemas [14]. El 50% del error vertical se reduce de 4.6 m a 3.9 m cuando se utilizan tres sistemas comparado con GPS [14]. En cañones urbanos severos el error de posición para GPS puede ser 10 veces mayor y la disponibilidad de la solución puede ser menor que la mitad de la disponibilidad para una solución multi GNSS [14]. También, por cuestiones de seguridad es decisivo que puedan continuar operativos aun cuando alguno de los sistemas GNSS pudiera quedar fuera de servicio. Por estas razones se seleccionó un receptor con capacidad para recibir las señales provenientes de los sistemas GPS americano, GLONASS ruso y QZSS para la región del pacífico cubriendo Japón y Australia (vea la opción GNSS en la Tabla 1). Note que todas las soluciones poseen soporte multi GNSS con excepción de SELVEC que fue diseñada antes que GLONASS contara con cobertura global completa.

Para las conexiones con el mundo exterior se eligió bus CAN siguiendo la tendencia de los vehículos modernos [15] El bus CAN fue desarrollado por Robert Bosh GmbH en la década de 1980, para la comunicación entre las unidades de control electrónico (ECUs) en el interior de un vehículo, simplificando el cableado hasta en un 75 por ciento [15]. De esta forma se facilita la conexión a una gran variedad de sensores/actuadores y módulos electrónicos compatibles bus CAN (note de la opción Com. en la Tabla 1 que no todas las soluciones disponen de bus CAN). Adicionalmente, se destinó un puerto serie RS232 para la conexión de sensores/actuadores inteligentes y se agregó un número reducido de entradas y salidas (E/S) para la conexión de sensores/actuadores simples. No disponer de interfaz RS485, como las soluciones Profi 2.0 y FM6300 (vea la opción Com. en la Tabla 1), se identifica como una limitación de CaBv3 que requeriría de un adaptador externo RS232/RS485.

Actualmente es común agregar un acelerómetro para la detección de accidentes y maniobras peligrosas [16] lo cual facilita la detección de detenciones. Por su parte CaBv3, al igual que otros sistemas [17-19], acude a algoritmos avanzados de software para compensar la ausencia de un acelerómetro.

La mayoría de las soluciones recurren a la fuente de alimentación eléctrica del vehículo para energizar el dispositivo de seguimiento y unas pocas funcionan utilizando únicamente una batería interna propia [20]. CaBv3 se alimenta desde el vehículo y puede continuar funcionando a partir de usar su batería interna, con una autonomía de 4 h (batería 3.7 V y 1200 mAh), si se interrumpiera su alimentación externa. Otras soluciones, como SELVEC, carecen de autonomía por lo que se apagan al desconectarse de la alimentación del vehículo dejando de registrar datos de trayectoria.

Diseño de hardware

El diseño electrónico de CaBv3 tiene una arquitectura modular compuesta por dos placas electrónicas delimitadas en la Fig. 1 por líneas discontinuas. A la izquierda aparece la placa de procesamiento y a la derecha la placa base.

La placa de procesamiento utiliza un procesador ARM Cortex-A7 de NXP Semiconductors (i.MX 6UltraLite), 512 MB de memoria de acceso aleatorio (RAM), 4 GB de almacenamiento eMMC donde se encuentra instalada la versión 3.14.52 del S.O. Linux y un microcontrolador de 8-bits de la serie STM8S como perro guardián inteligente. La placa base alberga los diferentes subsistemas (GPS, GSM/GPRS, Wi-Fi, CAN, UARTs, etc.), la fuente de alimentación y los diferentes conectores. De forma general la selección de los componentes principales para ambas placas se realizó atendiendo a su funcionalidad, a su costo y al tiempo de permanencia en el mercado para evitar su temprana obsolescencia.

Fue escogida una arquitectura modular para facilitar el desarrollo sostenible del producto, su producción, uso y soporte técnico [21]. Este tipo de arquitectura ofrece además una mayor flexibilidad para satisfacer las necesidades del mercado. Hipotéticamente, si se quisieran aprovechar las potencialidades de las redes 3G, la placa base podría actualizarse reemplazando el circuito integrado GSM/GPRS sin necesidad de modificar la placa de procesamiento. En la Fig. 2 se muestra la vista interior y exterior del dispositivo.

Fig. 1 Arquitectura general CaBv3. 

Fig. 2 Vistas del dispositivo. 

3.1.- Procesador

De forma simplificada, la función del procesador i.MX 6UltraLite es inicializar, cargar y ejecutar el S.O. Linux. Al concluir la fase de arranque del S.O. se ejecuta la aplicación principal como un nuevo proceso que toma el control del equipo en virtud del seguimiento de vehículos. Esta aplicación constituye el firmware del dispositivo.

El i.MX 6UltraLite es una familia de procesadores ultra eficiente de alto poder de ejecución que exhibe una implementación avanzada con un único núcleo ARM Cortex-A7 de NXP Semiconductors con una velocidad máxima de 696 MHz [22].

La placa de procesamiento fue diseñada en un formato genérico que provee todos los subsistemas del procesador a través de sus dos conectores laterales y con varias opciones de memoria para soportar múltiples aplicaciones. La placa base diseñada para la aplicación CaBv3 utiliza solamente una parte de los recursos del procesador desde los terminales correspondientes. En la Tabla 2 se resumen las características del procesador y la capacidad de memoria utilizada por CaBv3.

Tabla 2 Características de la placa de procesamiento para CaBv3. 

Características Descripción
Procesador Modelo MCIMX6G2CVM05AB. Producción en masa, familia i.MX 6UltraLite, seguridad estándar, 1536 eFuse bit, cache L2=128 KB, 2xUSB con PHY, 2xCAN (usado 1), Ethernet 10/100M (no usado), 8 UARTs (5 usados), SPI, I2S, Timer/PWM=4/8 (no usado), ADC=2 (No usados), CSI, LCD (No usado), Juntura de temperatura industrial, frecuencia 528 MHz.
Memoria RAM Modelo MT41K256M16HA-125:E. Micron Technology DRAM DDR3L SDRAM 4 Gbit 256Mx16 400 MHZ (512 MB).
Almacenamiento Modelo H26M31001HPR. SK hynix Flash, e-NAND MMC (eMMC), 1ra generación (4 GB).

La elección de este procesador se fundamenta en su soporte para Linux, manejo de suficiente capacidad de memoria para las aplicaciones y datos históricos de trayectoria, bus CAN, audio, USB 2.0 para la conexión de memorias, cantidad de puertos serie necesarios para la conexión con una computadora personal (PC), los subsistemas (GPS, GSM/GPRS y STM8S) y un puerto serie externo para la conexión de sensores/actuadores.

3.2.- Microcontrolador

De forma simplificada la función del microcontrolador STM8S003F3 es supervisar el voltaje interno, controlar el encendido/apagado del sistema y monitorear la ejecución de la aplicación de forma externa al procesador. De esta forma, ante un evento de fallo, el microcontrolador puede ejecutar alguna acción mitigadora, como se refiere en [10, 23]. Se mantiene una estricta vigilancia del nivel de voltaje interno deteniendo el procesamiento y apagando el sistema antes de la llegada de una condición de bajo-voltaje, cuando está por agotarse la batería interna, evitando interrumpir abruptamente las operaciones del S.O. que pudieran dañar la integridad del sistema. Simultáneamente, se monitorea la aplicación para detectar la ocurrencia de fallos de software (lazos infinitos o abortos) para restablecer su ejecución aplicando un reinicio. Los temporizadores perro-guardián son requeridos por muchos de los estándares de seguridad para sistemas embebidos como IEC 61508, ISO 26262 y MISRA, su diseño ha sido identificado como un factor importante en la seguridad contra fallos [23].

De las ocho opciones disponibles en la serie de microcontroladores STM8S se seleccionó el dispositivo STM8S003F3 de la línea de valor y baja densidad [24]. Las características utilizadas se resumen en la Tabla 3.

Tabla 3 Características utilizadas del microcontrolador. 

Características Descripción
Microcontrolador STM8S003F3 de la serie STM8S de 8-bits; Núcleo de 16 MHz; Arquitectura Harvard y tubería de 3 etapas; Conjunto de instrucciones extendido. Encapsulado de 20-terminales.
Memoria 1 KB memoria RAM, 8 KB memoria flash (retención 20 años @ 55 ℃) pasados los 100 ciclos. 128 B EEPROM (100,000 ciclos escritura/borrado).
Temporizadores Temporizadores de propósito general de 16-bit; Temporizador básico de 8-bit con pre-escalador de 8-bit; Temporizador perro guardián.
Comunicación UART en modo asíncrono a 115,200 bps e interface I2C a 400 Kbit/s.
E/S Dos salidas digitales de las 16 E/S (Diseño robusto, inmune contra corriente de inyección).
A/D Un canal ADC de 10-bits (± 1 LSB) de los cinco canales multiplexados disponibles.
Alimentación Voltaje de operación: 3.3 V (Rango de operación 2.95 V a 5.5 V).

La elección de este microcontrolador se fundamenta en su pequeño formato de 20-terminales con soporte para temporizadores de propósito general y perro guardián interno, UART/I2C para el intercambio con el procesador i.MX6UL, un canal de entrada analógica para la medición del voltaje interno, dos E/S para controlar la alimentación del sistema y el procesador.

3.3.- Receptor GPS

Como receptor GPS se utilizó el módulo GPS ST-91-U7 de SATES consistente en una placa electrónica compacta basada en un núcleo ublox-7. Este núcleo se caracteriza por su alto rendimiento, un motor de posición multi-GNSS (GPS, GLONASS, QZSS, SBAS - listo para Galileo y Compass) y bajo consumo de potencia, como se refiere en [25]. En la Tabla 4 se resumen los parámetros utilizados por CaBv3.

La elección de este módulo receptor GPS se fundamenta principalmente en su capacidad multi GNSS (especialmente para los sistemas GPS y GLONASS), soporte para el protocolo estándar NMEA implementado por las librerías de Qt y puerto serie para la conexión con el procesador.

Tabla 4 Características utilizadas del módulo GPS. 

Características Descripción
Núcleo Ublox UBX-G7020 (u-blox 7); 56 canales; Motor de posición multi GNSS (GPS, GLONASS).
Protocolos NMEA 0183 v2.3 comandos: GGA, GSA, GSV, RMC; Binario UBX; Puerto serie: 9,600 bps.
Sensibilidad Seguimiento: -162 dBm; Readquisición: -160 dBm; Arranque en frío: -148 dBm
Tiempos En frío: 29 s promedio, Cálido: 29 s promedio, Caliente: 1 s promedio.
Precisión Posición horizontal: Autónoma<2.5 m promedio, SBAS<2.0 m promedio; Velocidad: 0.1 m/s.
Alimentación Voltaje de operación y respaldo: 3.3 V.

3.4.- Módulo inalámbrico GSM/GPRS

Para las comunicaciones GSM/GPRS se utiliza el módulo M26 de QUECTEL consistente en un circuito integrado que provee una solución inalámbrica para la comunicación de voz, mensajes y la transmisión de datos a través de la moderna tecnología celular, como se refiere en [26]. En la Tabla 5 se resumen los parámetros utilizados por CaBv3.

Tabla 5 Características utilizadas del módulo GSM/GPRS. 

Características Descripción
Bandas Funcionamiento en las cuatro bandas: GSM850/EGSM900/DCS1800/PCS1900.
Interfaces Hardware E/S de propósito general; Pin de encendido; Función SIM; Entrada de voltaje de respaldo; Manos libres. Puerto serie: 115,200 bps.
Interfaces Software Compatibles: GSM Rec. 27.07, GSM Rec. 27.05, ITU-T Rec. V25ter, ITU-T Rec. T.32.
Servicios de Voz/Datos Mensajes cortos (SMS texto y PDU, Reporte de entrega).
Soporte de SIM 1.8 V/3 V.
Voltaje de Alimentación Voltaje de operación: 3.8 V (Rango de operación 3.3 V a 4.2 V, Voltaje normal 3.8 V).

La elección de este módulo GSM/GPRS se fundamenta principalmente en su capacidad para operar en las cuatro bandas de frecuencia, disponer de las interfaces de software estándares implementadas por las librerías de Qt y un puerto serie para la conexión con el procesador.

Para alojar el módulo de identificación del suscriptor (SIM) se utilizó un receptáculo inaccesible desde el exterior que evita su extracción accidental o intencional. Para las llamadas de voz se usó un conector de 3.5 mm que permite conectar un conjunto de manos libres.

3.5.- Módulo inalámbrico WI-FI

Para las comunicaciones Wi-Fi se utiliza el módulo RTL8189ES-CG de REALTEK consistente en un circuito integrado que provee una solución completa con un alto rendimiento durante la transferencia de datos del dispositivo inalámbrico LAN (WLAN), como se refiere en [27]. En la Tabla 6 se resumen los parámetros utilizados por CaBv3.

La elección de este módulo de comunicación Wi-Fi se fundamenta principalmente en su capacidad para operar en la banda de 2.4 GHz pudiendo soportar velocidades de hasta 72.2 Mbps en recepción y 150 Mbps en transmisión con niveles de seguridad WPA y WPA2, así como disponer de manejadores que integran su funcionamiento al soporte de red del S.O.

Tabla 6 Características utilizadas del módulo de comunicación Wi-Fi. 

Características Descripción
Generales Código de Autenticación de Mensajes (MAC) CMOS; PHY banda base; RF en un único circuito integrado de WLAN compatible IEEE 802.11b/g/n. Solución 802.11n completa para la banda de 2.4 GHz. 72.2 Mbps de razón PHY de recepción y 150 Mbps razón PHY de transmisión usando un ancho de banda de 40 MHz. Compatible con la especificación 802.11n. Compatibilidad hacia atrás con dispositivos 802.11b/g mientras opera en el modo 802.11n. Encapsulado QFN de 32-terminales.
Estándares Soportados WLAN compatible IEEE 802.11b/g/n. Mejoramiento de la Calidad del Servicio (QoS) IEEE 802.11e (WMM). Seguridad IEEE 802.11i (WPA, WPA2).
Interface Anfitrión (Host) Cumple con SDIO 1.1/2.0/3.0 para WLAN con una razón reloj de hasta 100 MHz. Linux dispone de manejadores para ésta interfaz.
Alimentación Voltaje de operación: 3.3 V. Nivel de señal de interface SDIO/GSPI desde 1.8 V a 3.3 V.

3.6.- Comunicaciones serie, USB y BUS CAN

Se utilizaron las comunicaciones serie con niveles lógicos TTL internamente y al exterior con niveles RS232. El receptor GPS, el módulo inalámbrico GSM/GPRS y el microcontrolador se interconectaron directamente con el procesador usando tres puertos serie. Al exterior salen dos puertos serie, uno para la conexión con la consola de administración de Linux del equipo desde una PC y el otro para conectar sensores/actuadores u otros dispositivos inteligentes.

Dos interfaces USB, una del tipo dispositivo y la otra del tipo anfitrión, posibilitan descargar el software base desde una computadora personal (PC) durante la producción y conectar memorias USB durante la operación del equipo, respectivamente.

Para la comunicación con la red CAN del vehículo y con sensores/actuadores compatibles CAN se añadió una interfaz bus CAN flexible, de conformidad con la especificación CAN 2.0B, con un circuito terminador de bus incorporado. Se seleccionó el circuito integrado SN65HVD233DG4 como manejador de bus CAN.

Todas éstas comunicaciones son controladas por los subsistemas correspondientes del procesador [22] y gestionadas a través de los manejadores del S.O. Linux.

3.7.- Entrada/salidas (E/S)

El procesador cuenta internamente con cinco módulos de E/S de propósito general (GPIO) de 32 bits [22]. Se utiliza una gran cantidad de E/S, las internas se manejan con niveles lógicos TTL y las externas se acondicionan mediante transistores. Los indicadores lumínicos, el control de varios de los circuitos integrados, el zumbador, entre otras funciones, son manejados por E/S. Se emplean dos entradas digitales para gestionar el botón de pánico externo y la señal de ignición del motor, y una salida digital para manejar el relé externo.

3.8.- Audio de salida

Se dispone de una salida de audio estéreo para la reproducción de sonido, música y mensajes de voz en diferentes formatos de audio (ejemplos: wav y mp3) a través de un conector estándar de 3.5mm. El procesador cuenta con tres interfaces de audio sincrónicas (SAI) [22]. La salida del canal 2 se interconecta a un codificador de audio estéreo WM8960 de Wolfson Microlectronics para acondicionar el nivel de las señales posibilitando el manejo de audífonos y altavoces clase D de 1 W.

3.9.- Fuente de alimentación

Al utilizar la energía del propio vehículo, la fuente de alimentación del dispositivo debe operar en un rango para adaptarse al voltaje de cada vehículo, así como propiciar su uso en otros medios de transporte que utilicen voltajes de alimentación diferentes de 12 V y 24 V. Por esta razón el diseño de la fuente de alimentación admite voltajes en el rango de 6 V a 42 V.

Para evitar averías, los dispositivos electrónicos que funcionan en automóviles deben disponer de una serie de protecciones en sus fuentes de alimentación para contrarrestar las perturbaciones que ocurren en estos sistemas eléctricos, y que se resumen en la norma ISO 16750-2 [28]. En correspondencia con lo anterior el diseño de la fuente de alimentación incluye, entre otras, protecciones contra polaridad invertida, el efecto de desconexión abrupta de la carga (“load-dump”) y el consumo excesivo de corriente por la salida de voltaje auxiliar y el puerto USB. La autonomía del dispositivo se garantiza mediante una batería de litio de 3.7 V interna al equipo. En la Fig. 3 se muestra un esquema general de la fuente de alimentación.

Fig. 3 Esquema general de la fuente de alimentación. 

3.10.- Protección contra transientes

Con el objetivo de proteger los componentes sensibles a las descargas electrostáticas (ESD), transientes eléctricos rápidos (EFT) y relámpagos se ha conectado a todas las señales en contacto con el exterior supresores de transientes de voltaje (TVS) bidireccionales. Asegurar una correcta protección ESD a la electrónica del automóvil es absolutamente necesario para asegurar la fiabilidad y seguridad [29]. Los TVS son una opción ideal para la protección contra las ESD al soportar el transitorio entrante cuando éste alcanza el límite prestablecido, propiciando un camino de baja impedancia que desvía la corriente transitoria a tierra, previniendo el daño del semiconductor protegido.

En la selección de los TVS, se priorizaron los dispositivos individuales de montaje superficial por poseer mínima inductancia al acortarse el largo de sus terminales y los arreglos de diodos TVS de baja capacitancia (3 pF típicos), fundamentalmente para líneas de datos de alta velocidad como las asociadas a los puertos USB.

La robustez de la protección depende tanto de la selección de los parámetros del TVS como del seguimiento de las directivas para el trazado del PCB [29]. Por esta última razón se consumió mayor espacio de PCB, tiempo de diseño y tiempo en ensayos de comprobación.

3.11.- Conexiones externas

Las conexiones con el mundo exterior se realizan a través de un conjunto de conectores ubicados sobre la tapa frontal y trasera, como se muestra en la Fig. 4.

Fig. 4 Conexiones externas. 

-Diseño de software

Una de las ventajas distintivas del CaBv3 es que el software interno y los programas auxiliares para manejarlo fueron desarrollados en Cuba, lo que permite su continuo desarrollo y adaptación a entornos nuevos. La configuración del firmware consta de más de 40 parámetros que se almacenan en un archivo con formato .INI. A este archivo sólo se puede acceder con derechos administrativos o a través de la interfaz de servicio de comunicación Wi-Fi.

Cuando la aplicación arranca se lee este archivo de configuración. A partir de ahí el software se encontrará constantemente intentando definir su posición mediante el GPS, validará la información recibida y se depositarán estos datos en una lista (trayectoria temporal). Una vez transcurrido un tiempo configurable, la trayectoria temporal se simplifica y se salvan los datos de tiempo y posición más significativos al disco eMMC que posee el equipo. Si el equipo está configurado para operar en tiempo real la aplicación enviará copia de estos datos a través de la red GPRS o de la red Wi-Fi hacia un servidor remoto. Para garantizar que el servidor reciba todos los datos, aunque la cobertura GPRS se haya perdido temporalmente, se implementa un almacenamiento (caché) donde se guardan los puntos que no se hayan podido trasmitir para su posterior envío una vez que se reestablezca la cobertura.

La interfaz de comunicación Wi-Fi permite interactuar con la aplicación a través de 33 comandos. Algunos de estos comandos pueden también invocarse a través de mensajes SMS o mediante un archivo específico colocado en la memoria USB que se introduzca en el equipo.

La aplicación fue programada en C++ con el entorno de desarrollo Qt Creator, haciendo uso de las bibliotecas Qt 5. Para ello se descargaron las herramientas cruzadas (compilador, ensamblador, enlazador y otras) del procesador i.MX 6UltraLite para Linux de 64-bits y se configuró el Qt Creator para aceptarlas. También fue necesario realizar la compilación cruzada de las librerías de la Qt 5.6 para el procesador i.MX 6UltraLite utilizando la versión 4.8 del compilador de la colección de compiladores GNU (GCC). Posteriormente se copiaron los binarios resultantes de la compilación hacia la memoria de la tarjeta de procesamiento del CaBv3. La aplicación fue diseñada empleando un solo hilo de ejecución y el procesamiento de las tareas es totalmente asíncrono.

El software está compuesto por varios módulos, entre los cuales los más significativos son:

  1. Módulo de gestión del GPS.

  2. Módulo de gestión de GSM/GPRS.

  3. Módulo de gestión de la comunicación Wi-Fi.

  4. Gestión del puerto USB.

4.1.- Gestión del GPS

Para el manejo del receptor GPS se realiza una configuración inicial del mismo con los parámetros que se enumeran a continuación:

  1. El puerto serie al que está conectado el GPS es configurado a 9600 bps, 8 bits de datos, sin paridad y 1 bit de parada.

  2. Se configura el modelo dinámico a utilizar en el GPS. Para el CaBv3 se establece en “Automotive”. Este modelo del receptor es usado para aplicaciones cuya dinámica puede compararse con la de un vehículo de pasajeros lo que se corresponde con la aplicación propuesta. En este caso se asumen los siguientes límites: Altitud Máxima [m]: 6000; Velocidad Máxima sobre el terreno [m/s]: 84 y Velocidad Vertical Máxima [m/s]: 15. El modelo dinámico se establece mediante el comando UBLOX: CFG-NAV5 que permite recuperar o establecer los parámetros de navegación del receptor [30].

  3. Se seleccionan los mensajes NMEA que se deben recibir del receptor, para ello se han deshabilitado, mediante el comando UBX, 40 (“Set NMEA message output rate”), todos los mensajes NMEA a excepción de los mensajes RMC y GGA. El mensaje RMC (“Recommended Minimum data”) proporciona los datos de fecha y hora, latitud, longitud, altitud, velocidad sobre el terreno y curso mientras que el mensaje GGA (“Global positioning system fix data”) proporciona, entre otros, fecha y hora, latitud, longitud, altitud, satélites usados y HDOP. Estos mensajes se programan para ser recibidos continuamente. El CaBv3 utiliza la información duplicada entre ambos mensajes para reestablecer los datos ausentes en alguno de ellos por problemas de recepción. La información del número de satélites es utilizada para descartar las tramas con menos de siete satélites usados [20].

Una vez configurado el receptor GPS, el firmware activa el módulo de atención al GPS que recibe constantemente los datos de posición del receptor. Como primer paso se eliminan los datos anómalos de posición, para ello:

  1. Si la velocidad sobre el terreno contenida en la trama GPS es mayor que un valor configurable (“highFilterSpeed”) la trama se declara inválida.

  2. Si la velocidad sobre el terreno calculada a partir de las posiciones y de las marcas de tiempo del punto actual y del último punto válido excede al valor de “highFilterSpeed” se rechaza la trama. El valor por defecto del parámetro “highFilterSpeed” es de 200 km/h.

Finalmente, cuando el nuevo punto es aceptado, se actualiza el odómetro y se envía al detector de detenciones. La experiencia práctica, en los más de 3,000 computadores instalados, ha demostrado que las reglas de filtrado, a pesar de su simplicidad, son suficientes para el ámbito del control de flotas.

El CaBv3 almacena las tramas de posición con una frecuencia configurable. La frecuencia depende de si el equipo está detenido o en movimiento al igual que si tiene coordenadas válidas de GPS o no. Esto permite economizar tramas en los periodos en que el equipo esté detenido o parqueado. Además de lo anterior el sistema salva automáticamente las tramas cuando ocurren determinados eventos, algunos de los cuales se exponen a continuación:

  1. Cuando se enciende o se apaga el vehículo.

  2. Cuando ocurren cambios en el estado de la antena del GPS. (Por ejemplo, si se retira la antena o la misma cae en cortocircuito).

  3. Si el equipo cambia su fuente de alimentación (si se ve obligado a trabajar con la batería interna del equipo).

  4. Si el estado de la batería interna cambia. Esto puede ocurrir si hay un fallo en la carga de la batería que indica la necesidad de reemplazarla.

  5. Si el botón de pánico del equipo se oprime.

  6. Si se retira o inserta la tarjeta SIM en el equipo.

  7. Si el vehículo recorre una distancia configurable. En este caso ocurre una salva (y eventualmente una trasmisión GPRS) cuando el vehículo se desplace más de un umbral, teniendo como referencia la última posición transmitida.

  8. Cuando hay una detención del vehículo y cuando retoma su movimiento.

Detección de detenciones

La detección de las detenciones del vehículo es muy importante para los sistemas de rastreo vehicular. Por detención entenderemos la localización y el momento en que el movimiento recesa con el objetivo de realizar alguna actividad intencional o como resultado del control de tráfico. Esta información agrupada correspondientemente puede ser útil en la detección de zonas de interés, patrones de comportamiento y adicionalmente puede servir para la segmentación y manejo inteligente de las trayectorias. Algunos parámetros de los equipos de rastreo vehicular, por ejemplo, la frecuencia de trasmisión, pueden cambiar en dependencia de si el vehículo está en movimiento o detenido.

Desafortunadamente cuando un vehículo está realmente detenido el GPS sigue reportando cambios de posición y velocidades mayores que cero lo que hace difícil la detección de las detenciones a partir de información del GPS. Este comportamiento ocurre debido al efecto multitrayectoria [31]. Si el receptor está situado cerca de superficies reflectoras, tales como edificios, montañas o lagos, el receptor puede recibir, además (o en lugar) de la señal real del satélite, reflexiones de esta señal, que arriban en diferentes instantes de tiempo, provocando mediciones falsas. Algunos errores pueden ser significativos y alcanzar más de 15 metros. El efecto multitrayectoria es mucho menos severo cuando el vehículo está en movimiento debido a que, cuando la antena está en movimiento, las mediciones falsas que provienen de señales reflejadas desaparecen rápidamente de la cobertura y solo la señal directa se mantiene estable.

Recientemente han aparecido diferentes métodos para la detección de detenciones [32, 33] desde los que se basan en información adicional captada del vehículo, como el estado del motor, hasta los que realizan la segmentación de la trayectoria basada en clasificadores. En el CaBv3 se implementa una versión modificada del algoritmo descrito en [34]. La variante aplicada adapta el algoritmo mencionado al modo de operación en tiempo real que es consustancial a los equipos de rastreo vehicular.

El software del CaBv3 clasifica cada punto de la trayectoria en tres modos a) “stop” (detenido), b) “trip” (en movimiento) y c) “parked” (parqueado). Abusando del lenguaje, si la última trama GPS recibida ha sido clasificada como “stop” (“trip”, “parked”) se dirá que el equipo está en modo “stop” (“trip”, “parked”). La clasificación se efectúa a partir de un conjunto de reglas que se enumeran a continuación:

  1. El CaBv3 arranca en modo “stop”.

  2. Si el equipo cae en modo “stop” o “parked”, no pasa a modo “trip” a menos que la posición del vehículo salga del área de un círculo con radio configurable (“stopDistance”) o su velocidad sea válida y mayor que un valor configurable (“lowFilterSpeed”) por un tiempo superior al parámetro “stopDeadTime”. El centro del círculo es el centroide de todos los puntos que se han agrupado dentro del círculo (“cluster”) mientras el equipo estaba en modo “stop” o “parked” (Fig. 5).

  3. Si el vehículo está en modo “stop” por un tiempo mayor a cinco minutos se declara en modo “parked”.

  4. Cada vez que el vehículo sale del área de detención definida por el agrupamiento se inicializa un nuevo proceso de agrupamiento con la última posición recibida.

  5. Si el vehículo está en modo “trip” y cae dentro del grupo de detención por un tiempo superior a un valor configurable (“tripDeadTime”) y su velocidad es válida y menor que el parámetro “lowFilterSpeed” por un tiempo superior a “tripDeadTime” se declara que ha pasado a modo “stop”.

Figura 5 Detección de detenciones con dos agrupamientos de “stop” y un fragmento en modo “trip”. 

Los valores por defecto de los parámetros son “stopDistance” = 30 m; “stopDeadTime” = 1 s; “lowFilterSpeed” = 2 km/h; “tripDeadTime” = 15 s. La configuración por defecto trata de detectar rápidamente el inicio del movimiento y evitar que paradas muy cortas o movimientos lentos (como los que se efectúan en calles congestionadas) generen falsas detenciones. Una vez determinado el modo en que se encuentra el vehículo, este estado se almacena como una propiedad adicional del punto para su eventual salva en el archivo histórico o su trasmisión por GPRS.

Simplificación de trayectorias

La base de datos espacio-temporal obtenida a través del GPS y que se corresponde con el movimiento del vehículo en un período seleccionado se conoce como trayectoria. Desde el punto de vista geométrico una trayectoria es la poligonal formada por una secuencia de mediciones GPS. Los computadores de a bordo y los dispositivos de rastreo a distancia recolectan la información de posición con un período generalmente no mayor a un segundo. Como resultado, las trayectorias pueden contener un número grande de puntos. Las trayectorias contienen además información adicional acerca del movimiento del vehículo (por ejemplo, velocidad y curso) u otras que faciliten el diagnóstico de fallos en el equipo por lo que pueden requerir de volúmenes importantes de memoria lo cual es indeseable debido a: a) Limitaciones en el hardware del computador, b) Limitaciones en el ancho de banda de los medios de comunicación utilizados para transferir la información y c) Problemas en el rendimiento de los visualizadores de las trayectorias cuando el número de puntos es excesivamente grande. Esto conduce a la necesidad de disminuir la cantidad de puntos en las trayectorias manteniendo en lo posible su capacidad de reflejar de forma precisa el movimiento realizado por el objeto, lo que se conoce como simplificación de trayectorias.

El objetivo principal de cualquier sistema de simplificación de trayectorias consiste en garantizar que la trayectoria obtenida sea lo más cercana posible a la trayectoria real del vehículo, utilizando para ello la menor cantidad de puntos.

En el caso de los computadores de a bordo utilizados en Cuba predomina la variante más simple de simplificación que consiste en trasmitir (o salvar a memoria interna) a una frecuencia mucho menor que la usada para recibir los datos del GPS. Por ejemplo, se puede definir un período de salva o trasmisión de los datos configurable por el usuario. Utilizar un período de 30 segundos, por ejemplo, permitiría reducir en 30 la cantidad de puntos de la trayectoria asumiendo que se muestrea el GPS a 1 Hertz. A mayor período, mayor reducción, pero sin medidas adicionales esto puede provocar una pérdida grande de precisión en el seguimiento del vehículo como se muestra en la Fig. 6.

Fig. 6 Errores típicos al reducir trayectorias. En color rojo la trayectoria real del vehículo en un minuto, en azul la trayectoria aparente (tomando muestras cada 30 segundos). 

En [34] se discuten ampliamente los diferentes enfoques utilizados actualmente para la simplificación de trayectorias, que abarcan métodos geométricos, métodos basados en densidad y métodos basados en propiedades.

El método utilizado para la simplificación de trayectorias en el computador de a bordo CaBv3 es un método geométrico que se basa en el algoritmo de Douglas-Peucker [35]. Este algoritmo reduce el número de puntos utilizados en la aproximación de una curva. Se fundamenta en la búsqueda de puntos críticos a partir de una tolerancia lineal. Los puntos críticos, que constituirán la línea simplificada, serán los que progresivamente vayan alcanzando una distancia perpendicular mayor respecto a la línea base considerada, siempre superior a la tolerancia impuesta. Este algoritmo y sus modificaciones posteriores han sido utilizados en varios trabajos para la simplificación de trayectorias [36, 37]. El algoritmo Douglas-Peucker es sencillo de implementar y consume relativamente pocos recursos. Su complejidad computacional es de On logn, donde n es la cantidad de puntos almacenados en la trayectoria a simplificar. En la Fig. 7 se muestra una síntesis del mismo.

Fig. 7 Algoritmo Douglas-Peucker. 

En el CaBv3 se define un período de salva o trasmisión, pero puede enviar más de un punto si considera que hay más de un punto significativo desde el envío anterior. El algoritmo que se ha implementado puede sintetizarse en los siguientes pasos, como se muestra en la Fig. 8.

Fig. 8 Simplificación de Trayectorias en el CaBv3. 

Además de la simplificación de trayectorias el CaBv3 utiliza un período de salva variable, en dependencia de si el vehículo está en movimiento, detenido o parqueado, lo que permite una reducción adicional de las trayectorias. Debe señalarse que ninguno de los otros computadores de a bordo que se comercializan en Cuba realiza una simplificación de trayectorias y consecuentemente las trayectorias obtenidas por el CaBv3 son de mayor calidad y generalmente de menor tamaño que las obtenidas por otros equipos.

4.2.- Gestión de GSM/GPRS

La gestión del módulo GSM/GPRS posibilita la comunicación con el equipo utilizando la red GSM, en particular, permite el envío de ciertos comandos de configuración vía SMS, habilita que se puedan efectuar llamadas desde teléfonos autorizados al equipo para interactuar con el conductor y posibilita la trasmisión de las tramas de posición hacia servidores dedicados a través del GPRS. Aunque la versión de Linux utilizada en el CaBv3 poseía manejadores para el circuito integrado GSM/GPRS, los mismos no ofrecían un nivel adecuado en la depuración de los errores de conexión por lo que fue necesario controlar directamente el circuito integrado a través del puerto serie. Este control se realiza mediante comandos “AT” [38] lo que requirió programar un analizador sintáctico de las respuestas a los comandos enviados así como de las respuestas no solicitadas que el circuito integrado envía ocasionalmente.

El Sistema General de Paquetes de Datos, GPRS, es un estándar para el transporte de paquetes de datos que comparte con GSM su rango de frecuencias. Pensado para facilitar la compatibilidad entre operadores, se implementa sobre la red GSM añadiendo las entidades funcionales que la doten de esta nueva capacidad, y que a su vez posibiliten el funcionamiento con redes externas basadas en paquetes de datos como Internet. En el CaBv3, el GPRS se utiliza para establecer conexiones TCP/IP con los servidores de gestión de flotas y enviar, a través de esta conexión, las tramas de posición. La gestión de las conexiones TCP es compleja y su algoritmo simplificado se expone en la Fig. 9.

Fig. 9 Gestión de las conexiones TCP/IP. 

En muchas aplicaciones no se permite mantener la conexión TCP/IP abierta, por tanto, luego de cada envío es necesario cerrarla. Por otra parte, si por alguna razón las tramas seleccionadas para el envío no se pudieron trasmitir, el software las almacena para enviarlas en cuanto se reestablezca la conexión. Puede ocurrir que en la ejecución del algoritmo de la Fig. 9 se reciban eventos no relacionados con la conexión TCP/IP tales como el arribo de un SMS o una llamada entrante. El software entonces detiene momentáneamente la ejecución de la gestión de conexiones y procesa el SMS (enviando una respuesta si así lo requiere) o queda a la espera de que el conductor, mediante el cable de manos libres rechace la llamada o la atienda.

El envío de las tramas y su formato a través de GPRS o de Wi-Fi activo se realiza mediante “plugins” que encapsulan las características específicas de la comunicación con un sistema de gestión de flota y que se configuran mediante la selección del “Códec” de comunicación. En la actualidad existen “plugins” para el sistema Móvilweb y el Sistema de Gestión Inteligente del Transporte, para los sistemas internacionales GeoLink y OpenGps y para la trasmisión directa por Wi-Fi activo.

En la Fig. 10 se muestran los sistemas de gestión en virtud del Códec. Pueden crearse nuevos “plugins” sin modificar el código de la aplicación principal lo que permite adecuar el equipo a nuevos entornos.

Fig. 10 Códec asociado a diferentes sistemas de gestión. 

4.3.- Gestión de la comunicación WI-FI

El módulo de la comunicación Wi-Fi en el CaBv3 es utilizado para varios propósitos. El escenario más común es para la utilización del equipo en modo pasivo. En este caso el operador en la base de transporte puede descargar inalámbricamente la trayectoria deseada. Pero además, independientemente del modo de operación (activo o pasivo), puede utilizarse para configurar el equipo y para modificarle el firmware incluso desde un teléfono móvil. Esto representa una ventaja competitiva importante con respecto a otros equipos que están presentes en el mercado cubano.

El manejo de la comunicación Wi-Fi es realizado directamente por el S.O. del equipo. Cuando la aplicación se inicia, activa la comunicación por Wi-Fi y queda a la espera de que aparezca una red cercana cuyo identificador sea uno de los configurados. Si se detecta esta red y se logra conectar a la misma, el equipo comienza a enviar tramas UDP a la red inalámbrica para notificarles a los demás equipos de la red su dirección IP y otros datos. El operador de la base de transporte o el encargado de mantenimiento puede entonces ver a ese equipo dentro de una lista de equipos disponibles y opcionalmente puede conectarse al mismo. El intercambio de información entre las PC o móviles y el CaBv3 se realiza a través de una interfaz de servicio.

La interfaz de comandos del CaBv3 está diseñada para cumplir específicamente con la función principal a la que se destina el equipo, que es el control de flotas. La comunicación con el CaBv3 puede realizarse a través de SMS, por Wi-Fi y muy limitadamente a través de una memoria USB. La comunicación vía SMS no requiere una autenticación específica ya que sólo se chequea si el móvil de donde proviene el mensaje SMS pertenece a la lista de teléfonos autorizados que se encuentra en la configuración del equipo.

En el caso de la comunicación Wi-Fi, en virtud de que los mensajes circulan de forma inalámbrica, se implementaron medidas específicas para la autenticación de los clientes. En particular en el CaBv3 un cliente puede autenticarse como Usuario simple para la invocación de las funciones necesarias en una base de transporte o como Administrador, generalmente destinado al equipo que da mantenimiento a los CaBv3 y que ofrece funcionalidades extendidas. En el archivo de configuración del CaBv3 deben especificarse tanto la contraseña del usuario simple como la del administrador. El protocolo utilizado para la autenticación es un protocolo de “desafío-respuesta” [39]. La secuencia de pasos en la autenticación es la siguiente.

  1. Cuando un cliente se conecta al CaBv3, éste inmediatamente genera un número aleatorio N s de 32 bits, que es un desafío al cliente, para verificar que el mismo posee realmente la clave secreta. N s se envía al cliente y queda almacenado en el CaBv3.

  2. El cliente recibe N s y, en dependencia del modo en que se desea autenticar (cliente simple o administrador), selecciona la contraseña P Luego efectúa un resumen (“hash”) criptográfico de la concatenación de la cadena decimal que representa a N s y la cadena 𝑃. El resumen debe realizarse con el algoritmo MD4 [38]. La cadena resultante, de 16 bytes, se transforma a un número de 32 bits R c sumando todos sus bytes con rotación del acumulador en cada paso, dos bits a la izquierda.

  3. El cliente genera un número aleatorio N c de 32 bits que representará el desafío al CaBv3. El cliente envía entonces el comando de autenticación (“OS” u “OA”, en dependencia del modo) conjuntamente con R c y N c . N c es almacenado en el cliente.

  4. El CaBv3 recibe el comando de autenticación y selecciona la contraseña P en dependencia de si el comando es de autenticación como usuario simple o como administrador. Utilizando el valor de N s repite las operaciones descritas en el punto 2 y obtiene un número N de 32 bits. Si N coincide con el R c recibido en el mensaje, se puede asegurar que el cliente conoce la contraseña secreta. Si no hay coincidencia se envía un mensaje de error al cliente.

  5. El CaBv3 toma el desafío N c y efectúa un resumen criptográfico, de la concatenación de la cadena decimal que representa a N c y la cadena P, con el algoritmo MD4. La cadena resultante se transforma a un número de 32 bits R s del mismo modo al descrito en el punto 2. El CaBv3 envía un mensaje de aceptación y adicionalmente envía R s .

  6. El cliente, una vez recibido el mensaje de aceptación, toma el desafío almacenado N c y realiza los mismos pasos descritos en el punto 5 para obtener un número N de 32 bits. Si N coincide con el R s recibido en el mensaje, se puede asegurar que el cliente se ha conectado a una CaBv3 válido y no a un tercero malicioso.

Este protocolo permite que tanto el cliente como el CaBv3 tengan cierta certeza de que la contraparte conoce la contraseña secreta sin necesidad de trasmitir la misma. Es conocido que tanto la función criptográfica de resumen MD4 como el protocolo de autenticación “desafío-respuesta” tienen ciertas debilidades, pero la solución ofrecida aporta un balance adecuado entre seguridad y complejidad computacional.

Los comandos en el CaBv3 son cadenas de texto que pueden tener una o más líneas. La primera línea del comando contiene el identificador del comando y los parámetros (si fueran necesarios) separados por el carácter “;”. Los comandos más simples solo contienen esa primera línea. Otros necesitan más líneas en cuyo caso el fin de la información se señaliza mediante una línea vacía. Cuando se trasmiten archivos (por ejemplo, cuando se cambia el firmware o se trasmiten trayectorias) el archivo se comprime y se codifica en Base64.

El CaBv3 permite notificar en las tramas hasta 32 variables discretas y 10 variables analógicas que pueden ser medidas por otras aplicaciones en el equipo a través de los puertos de comunicación del CaBv3 (RS-232, bus CAN). Por ello la interfaz de comandos proporciona comandos para encuestar el valor de estas variables.

En total hay más de 27 comandos disponibles. En la Tabla 7 se muestran los que pueden ejecutarse luego de autenticarse como usuario simple.

Tabla 7 Comandos no administrativos del CaBv3. 

Id. Descripción Disponible vía SMS
OS Abre sesión en el equipo como usuario sin derechos de administración. El comando requiere tres parámetros. Los dos primeros son cadenas que representan números enteros. El primero es la respuesta del cliente al reto del CaBv3, el segundo es el reto del cliente al CaBv3 y el tercer parámetro es una identificación del dispositivo desde donde se inició la conexión. Ejemplo: OS;23487;15463;0144876123 No es necesario
GT Recupera la última trayectoria (la actual) del equipo. El comando no requiere parámetros. La respuesta al comando es “OK;<n>” donde <n> es un número entero que representa un estimado de la cantidad de líneas que contiene el archivo que se transfiere. Luego a partir de la próxima línea se envía la trayectoria comprimida y codificada en base64. En caso de no existir el archivo o de algún otro fallo que imposibilite la transferencia del archivo se devuelve “Error;<e>” donde <e> es un código de error Ejemplo: GT No
PT Recupera la trayectoria especificada por el único parámetro del comando. La respuesta al comando es similar al del comando “GT”. Ejemplo: PT;CAB01 _201906030130.hist No
LT Lista todas las trayectorias presentes en el CaBv3. El comando no requiere parámetros. La respuesta al comando es “OK;<n>” donde <n> es un número entero que representa un estimado de la cantidad de trayectorias que se devolverán. Luego a partir de la próxima línea se envían los nombres de las trayectorias uno por cada línea. En caso de algún fallo que imposibilite la transferencia se devuelve “Error;<e>” donde <e> es un código de error Ejemplo: LT No
CT Cierra la trayectoria actual y abre una trayectoria nueva. El comando no requiere parámetros. Ejemplo: CT No
GC

Este comando espera a la entrada una lista de alias de atributos cuyos valores se desea obtener. Los alias son abreviaturas de las propiedades de configuración. Los alias deben ir separados por el carácter ';'.

Ejemplo: GC;WE;TT

Respuesta: WE=0;TT=60;

Si se pasa un alias que el sistema no reconoce se devuelve ese alias con un signo de interrogación sin afectar al resto de los alias.

Ejemplo: GC;WE;XX

Respuesta: WE=0;XX=?

Si
SR0 Establece la salida a relé del equipo con el valor 0. El comando no requiere parámetros. Ejemplo: SR0 Si
SR1 Establece la salida a relé del equipo con el valor 1. El comando no requiere parámetros. Ejemplo: SR1 Si
GD Obtiene el valor de las variables discretas. El comando no requiere parámetros. El CaBv3 admite hasta 32 variables discretas cuyos valores se empaquetan en una palabra de 32 bits. La respuesta del comando es: OK;<n> Donde cada bit de <n> refleja el estado de una variable discreta. Ejemplo: GD Si
GA Devuelve el valor de todas las variables analógicas del equipo. El comando no requiere parámetros. Los valores retornados son números enteros separados por punto y coma. Ejemplo: GA Respuesta: Ok;98;123;4500 Si
SY Devuelve información acerca del funcionamiento del Sistema. El comando no requiere parámetros. La información que se devuelve incluye los bits de estado, la conectividad del GPRS, la fecha y hora de la última trama enviada por GPRS, la fecha y hora de la última trama correcta de GPS, la dirección Ip en la red GPRS, la versión del firmware, la temperatura del procesador, el voltaje del núcleo y el valor de las entradas discretas. Ejemplo: SY Si

4.4.- Gestión del USB

El puerto USB disponible en la cara delantera del equipo puede ser usado, al igual que la comunicación Wi-Fi, para descargar trayectorias, para configurar el equipo y para modificar el firmware. Para ello, la aplicación detecta cuando se inserta una memoria e inmediatamente busca en la misma un archivo de solicitud que se encuentra encriptado y debe ser previamente preparado por el operador de la base de transporte o el mantenedor del equipo. Este archivo de solicitud contiene las acciones que deben realizarse. La acción más común es la de descarga de la última trayectoria que es muy usada en bases de transporte que trabajan el CaBv3 en modo pasivo y no cuentan con comunicación Wi-Fi en su infraestructura. Una vez que la transferencia de archivos culmina, la memoria USB es expulsada del sistema de archivos y el equipo emite un sonido característico que le avisa al operador que ya la memoria puede ser retirada del puerto. Los archivos de solicitud son individuales para cada equipo, por tanto es posible preparar la memoria, por ejemplo, para extraer la trayectoria de 10 vehículos, y pasar consecutivamente por cada uno de ellos, sin necesidad de regresar al ordenador de la base entre uno y otro.

5.- Conclusiones

En este trabajo se ha presentado el diseño e implementación de un computador de a bordo como solución nacional para lograr mejores niveles de servicio y un eficaz uso de recursos en flotas de transporte terrestres en Cuba garantizando la soberanía e independencia tecnológica. El producto presenta mejoras significativas con respecto a productos similares existentes en el mercado internacional. Entre las características que más se destacan están su diseño modular que simplifica su producción, soporte técnico y evolución tecnológica, posibilidad de configuración por software que permite cambiar la funcionalidad de acuerdo a las necesidades de los usuarios, capacidad para almacenar trayectorias por un año sin pérdida de información, acceso eficiente a los datos históricos por las diferentes vías de acceso al equipo y algoritmo de tratamiento de la información para mejorar la calidad de las trayectorias almacenadas. La aplicación práctica de este producto ha probado su efectividad para lograr un mejor servicio en las flotas de transporte y el ahorro de los recursos que intervienen en estas transportaciones.

6.- Referencias

1.  Jose D, Prasad S, Sridhar V, editors. Intelligent vehicle monitoring using global positioning system and cloud computing. Procedia Computer Science; 2015. [ Links ]

2.  Ibraheem IK, Hadi SW, editors. Design and Implementation of a Low-Cost Secure Vehicle Tracking System. 2018 International Conference on Engineering Technology and their Applications (IICETA); 2018: IEEE. [ Links ]

3.  Tarapiah S, Atalla S, AbuHania R. Smart on-board transportation management system using gps/gsm/gprs technologies to reduce traffic violation in developing countries. International Journal of Digital Information and Wireless Communications (IJDIWC). 2013; 3(4):96-105. [ Links ]

4.  Kumar GA, Arun B, Divya S, editors. A Proficient Model for Vehicular Tracking Using GPS Tracking System. 2019 3rd International Conference on Trends in Electronics and Informatics (ICOEI); 2019: IEEE. [ Links ]

5.  Thakkar D, Rajput P, Dubey R, Parekh R.Design and Implementation of Autonomous UAV Tracking System Using GPS and GPRS. Progress in Advanced Computing and Intelligent Engineering: Springer; 2019. p. 433-9. [ Links ]

6.  Ma C, Pang X, Wang S, Yang Y, Zeng Z, editors. The Design of Vehicle Tracking and Positioning System. 2018 10th International Conference on Intelligent Human-Machine Systems and Cybernetics (IHMSC); 2018: IEEE. [ Links ]

7.  Mahamulkar SU, Yawale R, editors. Design and Development of Vehicle Tracking and Monitoring System. 2017International Conference on Current Trends in Computer, Electrical, Electronics and Communication (CTCEEC); 2017: IEEE. [ Links ]

8.  Almashari S. Real Time Vehicle Tracking System and Energy Reduction: University of Waterloo; 2017. [ Links ]

9.  Zhou H, Wang H, Li X, Leung VC. A survey on mobile data offloading technologies. IEEE Access. 2018; 6:5101-11. [ Links ]

10.  Peña-Fernandez M, Lindoso A, Entrena L, García-Valderas M, Philippe S, Morilla Y, et al. PTM-based hybrid error-detection architecture for ARM microprocessors. Microelectronics Reliability. 2018; 88:925-30. [ Links ]

11.  Leppinen H. Current use of Linux in spacecraft flight software. IEEE Aerospace and Electronic Systems Magazine .2017; 32(10):4-13. [ Links ]

12.  Seo S, Kim J, Kim SM. An Analysis of Embedded Operating Systems: Windows CE Linux VxWorks uC/OS-II and OSEK/VDX. International Journal of Applied Engineering Research. 2017; 12(18):7976-81. [ Links ]

13.  Paziewski J, Wielgosz P. Investigation of some selected strategies for multi-GNSS instantaneous RTK positioning. Advances in Space Research. 2017; 59(1):12-23. [ Links ]

14.  Söderholm S, Bhuiyan MZH, Thombre S, Ruotsalainen L, Kuusniemi H. A multi-GNSS software-defined receiver: design, implementation, and performance benefits. Annals of Telecommunications. 2016; 71(7-8):399-410. [ Links ]

15.  Abbott-McCune S, Shay LA, editors. Intrusion prevention system of automotive network CAN bus. 2016 IEEE International Carnahan Conference on Security Technology (ICCST); 2016: IEEE. [ Links ]

16.  Srabanti S, Asaduzzaman M, Mokter MKB, Anannya TT, Tumpa SN, Afroze L, et al., editors. A Proposed System for Automatic Vehicle Monitoring and Accident Detection in Bangladesh. 2018 International Conference on Computer, Communication, Chemical, Material and Electronic Engineering (IC4ME2); 2018: IEEE. [ Links ]

17.  Mandal R, Agarwal N, Das P, Pathak S, Rathi H, Nandi S, et al., editors. A system for stoppage pattern extraction from public bus GPS traces in developing regions. Proceedings of the Third ACM SIGSPATIAL International Workshop on Mobile Geographic Information Systems; 2014: ACM. [ Links ]

18.  Shen L, Stopher PR. Review of GPS travel survey and GPS data-processing methods .Transport Reviews. 2014; 34(3):316-34. [ Links ]

19.  Zhao F, Ghorpade A, Pereira FC, Zegras C, Ben-Akiva M. Stop detection in smartphone-based travel surveys. Transportation research procedia. 2015; 11:218-26. [ Links ]

20.  Mistary PV, Chile R, editors. Real time Vehicle tracking system based on ARM7 GPS and GSM technology. 2015Annual IEEE India Conference (INDICON); 2015: IEEE. [ Links ]

21.  Sonego M, Echeveste MES, Debarba HG.The role of modularity in sustainable design: A systematic review. Journal of Cleaner Production. 2018; 176:196-209. [ Links ]

22.  Freescale Semiconductor I. IMX6ULAEC Microprocessor Datasheet 2016. Available from: www.nxp.com/docs/en/data-sheet/IMX6ULAEC.pdf22.  . [ Links ]

23.  Roy S, Hahn A, Xue M, editors. Feedback control systems with cyber fault-management mechanisms: Modeling and tradeoff analysis for simple examples. 2017 IEEE Conference on Control Technology and Applications (CCTA); 2017: IEEE. [ Links ]

24.  STMicroelectronics. STM8S003F Microcontroller Datasheet 2016. Available from: www.st.com/resource/en/datasheet/stm8s003f3.pdf24.  . [ Links ]

25.  SATES (HONG KONG) CO. L. ST-91-U7 GPS Module Datasheet. HONG KONG (CHINA) 2015. Available from: www.boardcon.com/download/EM3288_Module/ST-91-U7_GPS.pdf25.  . [ Links ]

26.  Corporation Q . M26 GSM/GPRS Wireless Module Datasheet 2008. Available from: wless.ru/files/GSM/Qisda/M26/M26_Datasheet.pdf26.  . [ Links ]

27.  REALTEK. RTL8189ES-CG Wireless LAN Datasheet 2012. Available from: www.microchip.ua/wireless/rtl8189es.pdf27.  . [ Links ]

28.  ISO16750-2. Road vehicles - Environmental conditions and testing for electrical and electronic equipment - Part 2: Electrical loads 2012. Available from: https://www.iso.org28.  . [ Links ]

29.  Chuang C-H, Ker M-D. System-level ESD protection for automotive electronics by Co-design of TVS and CAN transceiver chips. IEEE Transactions on Device and Materials Reliability. 2017; 17(3):570-6. [ Links ]

30.  AG u-b. u-blox 7 Receiver Description Including Protocol Specification V142013. Available from: https://www.u-blox.com30.  . [ Links ]

31.  Hadaller D. Mitigating gps error in mobile environments. Citeseer, 2008. [ Links ]

32.  Cich G, Knapen L, Bellemans T, Janssens D, Wets G. TRIP/STOP detection in GPS traces to feed prompted recall survey. Procedia Computer Science. 2015; 52:262-9. [ Links ]

33.  Wang Y, Mcarthur DP. Detecting Stops from GPS Trajectories: A Comparison of Different GPS Indicators for Raster Sampling Methods. 2017. [ Links ]

34.  Vrotsou K, Janetzko H, Navarra C, Fuchs G, Spretke D, Mansmann F, et al. SimpliFly: A methodology for simplification and thematic enhancement of trajectories. IEEE Transactions on Visualization and Computer Graphics. 2014; 21(1):107-21. [ Links ]

35.  Douglas DH, Peucker TK. Algorithms for the reduction of the number of points required to represent a digitized line or its caricature. Cartographica: the international journal for geographic information and geovisualization. 1973; 10(2):112-22. [ Links ]

36.  Etienne L, Devogele T, Bouju A. Spatio-temporal trajectory analysis of mobile objects following the same itinerary. Advances in Geo-Spatial Information Science. 2012; 10:47-57. [ Links ]

37.  Zhao L, Shi G. A method for simplifying ship trajectory based on improved Douglas-Peucker algorithm. Ocean Engineering. 2018; 166:37-46. [ Links ]

38.  Quectel. GSM/GPRS Module Series AT Commands Manual 2016. Available from: https://www.quectel.com38.  . [ Links ]

39.  Van Tilborg HC, Jajodia S. Encyclopedia of cryptography and security: Springer Science & Business Media; 2014. [ Links ]

40.  ISO14064-1. Greenhouse gases - Part 1: Specification with guidance at the organization level for quantification and reporting of greenhouse gas emissions and removals2018. Available from: https://www.iso.org40.  . [ Links ]

Recibido: 01 de Julio de 2020; Aprobado: 26 de Octubre de 2020

*Autor para la correspondencia: tbello@eros.moa.minem.cu

No existe conflicto de intereses entre los autores, ni con ninguna institución a la que cada uno está afiliado, ni con ninguna otra institución.

La contribución del autor Tirso Ramón Bello Ramos en el presente trabajo incluye las tareas de conceptualización, curación de datos, análisis formal, investigación, metodología, administración de proyecto, software, supervisión, validación y verificación, visualización, redacción del borrador original y la redacción del trabajo publicado

La contribución del autor Sergio Daniel Cruz Pupo en el presente trabajo incluye las tareas de conceptualización, curación de datos, análisis formal, investigación, metodología, validación y verificación.

La contribución del autor Rafael Arturo Trujillo Codorniú en el presente trabajo incluye las tareas de conceptualización, curación de datos, análisis formal, investigación, metodología, software, supervisión, validación y verificación, visualización, redacción del borrador original y la redacción del trabajo publicado.

a

Tirso Ramón Bello Ramos, Ing. en Electrónica, Especialista Principal Grupo Desarrollo de Equipos de Automática, SERCONI, Holguín, Cuba. Investiga y desarrolla equipos electrónicos de automática.

b

Sergio Daniel Cruz Pupo, Ing. en Control Automático, Especialista Principal Grupo Ingeniería, SERCONI, Holguín, Cuba. Investiga y desarrolla proyectos de automática. scpupo@eros.moa.minem.cu

c

Rafael Arturo Trujillo Codorniú, Dr. en Ciencias Matemáticas, Especialista Principal Grupo Desarrollo de Software de Automática, SERCONI, Holguín, Cuba, Profesor Titular, Facultad de Ingeniería Eléctrica, Universidad de Oriente, Santiago de Cuba, Cuba. Investiga y desarrolla software de automática, métodos de reducción de ruido en señales y aplicaciones de las redes neuronales profundas al análisis de encefalogramas. rtrujillo@uo.edu.cu

Creative Commons License