Equipo para la localización automática de vehículoslaboratorios.fi.uba.ar/lse/tesis/LSE-FIUBA-Trabajo-Final-CESE-Mauro... · A los docentes de la Carrera de Especialización en

UNIVERSIDAD DE BUENOS AIRES

FACULTAD DE INGENIERÍA

CARRERA DE ESPECIALIZACIÓN EN SISTEMAS

EMBEBIDOS

MEMORIA DEL TRABAJO FINAL

Equipo para la localización automáticade vehículos

Autor:Ing. Mauro Moreyra

Director:Mgr. Lic. Marcelo Estévez (UTN-FRA)

Jurados:Dr. Ing. Pablo Gomez (FIUBA)

Esp. Ing. Alejandro Permingeat (FIUBA, VSATMotion)Ing. Juan Manuel Cruz (FIUBA, UTN-FRBA)

Este trabajo fue realizado en la Ciudad Autónoma de Buenos Aires, entre marzo de2018 y diciembre de 2019.

III

Resumen

En la presente memoria se describe el desarrollo e implementación de un equipopara la localización automática de vehículos. El mismo se desarrolló para la

empresa Ojos del Cielo, dedicada a la prestación de servicios de monitoreo deflotas de transporte urbano.

El equipo permite el seguimiento en tiempo real del vehículo en el cual seencuentra instalado, y, a través de una plataforma web de monitoreo de flota, se

puede observar su recorrido y ejecutar otras acciones adicionales. Asimismo,mediante una consola de usuario incorporada, el equipo ofrece comunicación de

audio y mensajería de texto.

El diseño se basó en el desarrollo de un circuito impreso ad hoc. Se utilizó unsistema operativo en tiempo real para la administración de los distintos

subsistemas, como así también el uso de técnicas de ingeniería de software para elcontrol de versiones del código y la documentación del proyecto. A su vez, se

aplicaron conceptos de metodologías ágiles para realimentar los requerimientosdel cliente durante todo el ciclo de desarrollo del equipo.

V

Agradecimientos

En primer lugar, a mi familia, por estar siempre presente a lo largo de mi formación,brindándome su apoyo incondicional.

Luego, agradecer al director y jurados, por guiarme en la concreción de este trabajofinal de carrera.

A los docentes de la Carrera de Especialización en Sistemas Embebidos, que sinduda evidencian su esfuerzo en transmitir el conocimiento y la vocación en laenseñanza.

A mis compañeros de carrera, con quienes compartimos un año de trabajo arduopero muy fructífero, cosechando así buenas amistades.

Finalmente, a mi socio de trabajo, Diego Aragunde, quien colaboró estrechamenteen el cumplimiento del objetivo buscado.

VII

Índice general

Resumen III

1. Introducción General 11.1. Localización automática de vehículos . . . . . . . . . . . . . . . . . 11.2. Equipos AVL de referencia . . . . . . . . . . . . . . . . . . . . . . . . 31.3. Motivación y contexto actual . . . . . . . . . . . . . . . . . . . . . . 41.4. Objetivos y alcance . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4

2. Introducción Específica 52.1. Descripción general del sistema . . . . . . . . . . . . . . . . . . . . . 52.2. Protocolos y estándares de comunicación . . . . . . . . . . . . . . . 8

2.2.1. Estándar NMEA 0183 . . . . . . . . . . . . . . . . . . . . . . 82.2.2. Protocolo AT . . . . . . . . . . . . . . . . . . . . . . . . . . . 92.2.3. Protocolo UDP . . . . . . . . . . . . . . . . . . . . . . . . . . 102.2.4. Protocolo cliente-servidor . . . . . . . . . . . . . . . . . . . . 112.2.5. Protocolo de comandos SMS . . . . . . . . . . . . . . . . . . 12

2.3. Requerimientos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 122.4. Planificación . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14

3. Diseño e Implementación 173.1. Hardware . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17

3.1.1. CPU e interfaces de comunicación . . . . . . . . . . . . . . . 183.1.2. Módulo GSM-GPS . . . . . . . . . . . . . . . . . . . . . . . . 193.1.3. Comunicación de audio . . . . . . . . . . . . . . . . . . . . . 223.1.4. Consola de interfaz de usuario . . . . . . . . . . . . . . . . . 233.1.5. Entradas y salidas digitales y analógicas . . . . . . . . . . . 253.1.6. Diseño de circuitos impresos y montaje en gabinete . . . . . 27

3.2. Firmware . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 303.2.1. Arquitectura del firmware . . . . . . . . . . . . . . . . . . . . 323.2.2. Tarea de gestión de la comunicación con módulo GSM-GPS 353.2.3. Tarea de gestión de eventos del sistema . . . . . . . . . . . . 423.2.4. Tarea de gestión de comandos del sistema . . . . . . . . . . 433.2.5. Tarea de gestión de la interfaz de usuario . . . . . . . . . . . 443.2.6. Tarea de gestión de las entradas y salidas analógicas y digitales 46

4. Ensayos y Resultados 474.1. Ensayos sobre el módulo GSM-GPS . . . . . . . . . . . . . . . . . . 47

4.1.1. Ensayo de calidad de señal celular y GPS . . . . . . . . . . . 474.1.2. Ensayo de adquisición de datos de geolocalización . . . . . 494.1.3. Ensayo sobre la comunicación UDP bidireccional . . . . . . 50

4.2. Ensayos sobre la interfaz de usuario . . . . . . . . . . . . . . . . . . 514.2.1. Ensayo sobre el display gráfico y la navegación en menúes . 514.2.2. Ensayo del protocolo 1-Wire y dispositivo iButton . . . . . . 52

VIII

4.3. Ensayo de parámetros eléctricos del equipo AVL . . . . . . . . . . . 544.4. Pruebas de campo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55

5. Conclusiones 575.1. Conclusiones y resultados . . . . . . . . . . . . . . . . . . . . . . . . 575.2. Trabajo futuro . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58

Bibliografía 61

IX

Índice de figuras

1.1. Modelo de equipo AVL. . . . . . . . . . . . . . . . . . . . . . . . . . 3

2.1. Diagrama en bloques del sistema. . . . . . . . . . . . . . . . . . . . . 52.2. Encabezado datagrama UDP. . . . . . . . . . . . . . . . . . . . . . . 102.3. Diagrama de actividad. . . . . . . . . . . . . . . . . . . . . . . . . . . 152.4. Diagrama de Gantt. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16

3.1. Diagrama en bloques del equipo AVL. . . . . . . . . . . . . . . . . . 183.2. Conexionado entre PCBs principal y consola. . . . . . . . . . . . . . 183.3. Kit de evaluación Quectel para módulo EC21. . . . . . . . . . . . . . 203.4. Circuito esquemático de interfaces de antenas. . . . . . . . . . . . . 213.5. Diseño en PCB de impedancia controlada sobre líneas de transmi-

sión de antenas. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 213.6. Circuito esquemático de referencia de comunicación de audio. . . . 223.7. Diagrama polar de micrófono unidireccional. . . . . . . . . . . . . . 223.8. Principio de funcionamiento de sensor capacitivo1. . . . . . . . . . 233.9. Display gráfico 128x64 píxeles. . . . . . . . . . . . . . . . . . . . . . 243.10. Buzzer2. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 243.11. LEDs RGB3. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 243.12. Dispositivo iButton y lector. . . . . . . . . . . . . . . . . . . . . . . . 243.13. Salida digital de propósito general. . . . . . . . . . . . . . . . . . . . 253.14. Entrada digital de propósito general. . . . . . . . . . . . . . . . . . . 263.15. Entrada analógica de propósito general. . . . . . . . . . . . . . . . . 263.16. Entrada analógica de sensado de tensión de batería. . . . . . . . . . 263.17. Entrada digital de sensado de ignición del vehículo. . . . . . . . . . 273.18. Circuito impreso principal - Render 3D. . . . . . . . . . . . . . . . . 273.19. Circuito impreso principal - Fabricado. . . . . . . . . . . . . . . . . . 283.20. Circuito impreso consola - Render 3D. . . . . . . . . . . . . . . . . . 283.21. Circuito impreso consola - Fabricado. . . . . . . . . . . . . . . . . . 283.22. Montaje de PCB principal en gabinete. . . . . . . . . . . . . . . . . . 293.23. Montaje de PCB consola en gabinete. . . . . . . . . . . . . . . . . . . 293.24. Montaje y unión entre PCB principal y PCB consola. . . . . . . . . . 303.25. Vista frontal del equipo AVL. . . . . . . . . . . . . . . . . . . . . . . 303.26. Arquitectura en capas del firmware. . . . . . . . . . . . . . . . . . . 323.27. Diagrama de interacción de tareas, handlers de interrupción y recur-

sos del sistema. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 333.28. Reporte de datos en estado de conexión válido. . . . . . . . . . . . . 343.29. Reporte de datos en estado de conexión inválido. . . . . . . . . . . . 353.30. Modelo productor-consumidor aplicado para el manejo de la trans-

misión de los paquetes de datos al servidor. . . . . . . . . . . . . . . 353.31. Máquina de estados - Tarea gsm(). . . . . . . . . . . . . . . . . . . . 363.32. Diagrama de flujo de registración en la red celular. . . . . . . . . . . 383.33. Diagrama de flujo de transmisión de datos a servidor remoto. . . . 39

X

3.34. Arquitectura implementada sobre el mapa de memoria flash delmicrocontrolador. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40

3.35. Diagrama de flujo de actualización remota del firmware - Contextorunning_app. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41

3.36. Diagrama de flujo de actualización remota del firmware - Contextorunning_bootloader. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42

3.37. Máquina de estados - Tarea eventos(). . . . . . . . . . . . . . . . . . 433.38. Máquina de estados - Tarea ejecutar_comando(). . . . . . . . . . . . 443.39. Máquina de estados - Tarea interfaz_de_usuario(). . . . . . . . . . . 453.40. Temporización de señales del protocolo 1-Wire. . . . . . . . . . . . . 463.41. Máquina de estados - Tarea entradas_y_salidas(). . . . . . . . . . . . 46

4.1. Recorrido realizado para ensayo de calidad de señal celular y GPS. 494.2. Representación de menues en display gráfico. . . . . . . . . . . . . . 514.3. Detección de dispositivo iButton. . . . . . . . . . . . . . . . . . . . . 534.4. Medición sobre bus 1-Wire con analizador lógico. . . . . . . . . . . 534.5. Banco de mediciones. . . . . . . . . . . . . . . . . . . . . . . . . . . . 544.6. Ensayo sobre recorrido línea de colectivo 105. . . . . . . . . . . . . . 554.7. Equipo AVL instalado en colectivo. . . . . . . . . . . . . . . . . . . . 55

XI

Índice de Tablas

1.1. Sistemas de comunicaciones móviles . . . . . . . . . . . . . . . . . . 21.2. Sistemas de navegación por satélite . . . . . . . . . . . . . . . . . . . 21.3. Comparativa de equipos AVL del mercado argentino . . . . . . . . 3

2.1. Estructura de mensaje NMEA . . . . . . . . . . . . . . . . . . . . . . 82.2. Sentencia NMEA GPGGA . . . . . . . . . . . . . . . . . . . . . . . . 92.3. Tipos de paquetes de datos cliente-servidor . . . . . . . . . . . . . . 112.4. Grupos de comandos SMS . . . . . . . . . . . . . . . . . . . . . . . . 12

3.1. Requerimientos eléctricos mínimos del equipo AVL . . . . . . . . . 173.2. Recursos del microcontrolador LPC4337JBD144 . . . . . . . . . . . 193.3. Subsistemas e interfaces de comunicación . . . . . . . . . . . . . . . 193.4. Especificaciones técnicas módulo EC21 . . . . . . . . . . . . . . . . 203.5. Mensajes URC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 373.6. Comandos AT para registración en red celular . . . . . . . . . . . . 373.7. Comandos AT para transmisión de datos a servidor remoto . . . . 39

4.1. Referencia entre calidad de señal, valores RSSI y potencia en dBm . 484.2. Mediciones de calidad de señal celular y GPS . . . . . . . . . . . . . 484.3. Mediciones de parámetros eléctricos del equipo AVL . . . . . . . . 54

1

Capítulo 1

Introducción General

En el presente capítulo se introducen las tecnologías que conciernen al trabajo delocalización automática de vehículos realizado, al contexto y motivación por lacuál se decidió emprenderlo, los objetivos y alcances.

1.1. Localización automática de vehículos

Se conoce como localización automática de vehículos (del inglés Automatic VehicleLocation, AVL), a la facultad que poseen ciertos dispositivos de permitir la localiza-ción georeferenciada y en forma automática de un vehículo [1]. En este sentido,se habla comúnmente de equipos AVL, los que pueden poseer las siguientesfuncionalidades:

Geolocalización: datos de posición (latitud y longitud), velocidad, acelera-ción, altitud, rumbo, fecha y hora, etc.

Telemetría: medición remota de variables físicas y/o químicas, como sertemperatura, humedad, caudal, etc.

Manejo de entradas y/o salidas analógicas y/o digitales: sensado de aperturade puertas, accionamiento de actuadores, etc.

Comunicación con otros sistemas a través de distintos protocolos: Bluetooth,radiofrecuencia, RS-232, 1-Wire, CAN, etc.

Gestión de eventos configurables: por exceso de velocidad, por tiempo deinactividad, por validación de usuario, etc.

Se observa que el espectro de aplicaciones es muy amplio, lo que hace a los equiposAVL muy versátiles, dada también su capacidad de configuración en forma remotasegún la circunstancia para la que se lo necesite.

Los equipos AVL fueron fomentados, principalmente, con el auge de las tecno-logías GSM (Global System for Mobile communications, Sistema Global para lascomunicaciones Móviles) y GPS (Global Positioning System, Sistema de Posiciona-miento Global). Para su funcionamiento en tiempo real requieren de una conexióna un servidor para la transmisión/recepción de datos. De esta forma, los equiposAVL reportan a una base de datos preconfigurada los distintos datos recolectados,mediante la red de datos celular. Cabe mencionar, que también existen equiposAVL que soportan redes de datos satelitales, aunque los mismos cubren nichos demercados específicos dados los altos costos asociados.

2 Capítulo 1. Introducción General

Para operar bajo la red de datos celular, el equipo AVL debe contar naturalmentecon un módulo de comunicación celular. Este tipo de módulo usualmente sopor-ta uno o varios de los distintos estándares de comunicación. En la tabla 1.1 seobservan los distintas generaciones de tecnología, con sus respectivos estánda-res predominantes, de los sistemas de comunicaciones móviles en vigencia en laArgentina.

TABLA 1.1: Sistemas de comunicaciones móviles

Generación Estándar

2G GSM2.5G GPRS2.75G EDGE3G UMTS (WCDMA)3.5G HSPA, HSPA+4G LTE

Para que un módulo celular se pueda registrar en la red y tener una conexiónde datos activa, debe contar con una tarjeta SIM (Suscriber Identification Module,Módulo de Identificación de Abonado). La tarjeta SIM almacena en su memoriainterna, de forma segura, el código IMSI (International Mobile Subscriber Identity,Identidad Internacional del Abonado Móvil). Este código, único e irrepetible, esutilizado por el terminal móvil (módem) para identificarse y autenticarse en la redcelular, con el fin de que pueda traficar datos en redes GSM [2].

Respecto a la geolocalización, en un sentido amplio se debe hablar de GNSS(Global Navigation Satellite System, Sistema Global de Navegación por Satélite). ElGNSS está conformado por una constelación de satélites que permite, a través deun módulo o equipo receptor, el posicionamiento en cualquier parte del globoterrestre. En la tabla 1.2 se observan los sistemas de posicionamiento por satélitesen vigencia actualmente.

TABLA 1.2: Sistemas de navegación por satélite

Sistema Propietario

GPS Estados Unidos de AméricaGLONASS Federación de RusiaGalileo (*) Unión EuropeaBeiDou (*) República Popular de ChinaQZSS (*) Estado del JapónNAVIC (*) República de India

(*) Sistemas de navegación en desarrollo (no desplegados en su totalidad), o queabarcan cierta fracción de la superficie terrestre.

1.2. Equipos AVL de referencia 3

1.2. Equipos AVL de referencia

En el mercado de los equipos AVL existe una amplia oferta, aunque tambiénuna gran variedad de dispositivos según su uso específico. Sin embargo, el nichode proveedores de los equipos AVL utilizados en el transporte público es muyreducido. Estos últimos equipos poseen características enfocadas a la gestión deflota e interoperabilidad con otros sistemas, y funcionalidades relacionadas conla experiencia de usuario. A modo comparativo, en la tabla 1.3 se indican lascaracerísticas más relevantes de dos equipos que actualmente se ofrecen en elmercado argentino. Por último, en la figura 1.1 se ilustra un equipo AVL modeloT-800.

TABLA 1.3: Comparativa de equipos AVL del mercado argentino

Característica U+ Touch [3] T-800 [4]

Pantalla TFT 7” táctil LCD gráficoTeclado En pantalla MembranaAudio No NoMensajería de texto Sí SíProtocolos de comunicación WiFi 802.11,

BluetoothWiFi 802.11

Identificación de usuario Sí (lector NFC) SíTecnología de acceso celular 3G 3G, 4GGNSS GPS GPS y GLONASSAntenas GNSS y GSM Internas Internas y/o externasEventos de sistema Temporizadores,

exceso de velocidad,etc.

No especifica

Otras características Cálculo de atraso oadelanto respecto a

recorridoprogramado

Integración consistema SUBE

FIGURA 1.1: Modelo de equipo AVL.

4 Capítulo 1. Introducción General

1.3. Motivación y contexto actual

El equipo AVL desarrollado surgió principalmente de una oportunidad comercialcon una empresa del rubro de monitoreo de vehículos (sesgada hacia el transportepúblico de pasajeros). Este negocio, que se definió paralelamente al inicio de laCarrera de Especilización en Sistemas Embebidos de la UBA, permitió trasladarrápidamente a la práctica los conocimientos adquiridos en las distintas asignaturasde la carrera.

Actualmente, dicha empresa ya posee instalados equipos AVL de otro fabricanteen los vehículos de las flotas que tienen bajo servicio. El objetivo priordial esreemplazar, en el plazo de dos años, estos equipos por el que se ha desarrollado enel presente trabajo, por la necesidad de actualizar la tecnología de comunicacióncelular de los equipos actuales. Los que se encuentran en funcionamiento hoy endía sólo soportan redes 2G y 3G, requiriéndose que soporten redes 2G, 3G y 4G.Lo anterior se funda en la migración tecnológica que están llevando a cabo lasempresas prestadoras de servicios de telefonía celular, en forma gradual, haciaredes 3G + 4G, siendo de conocimiento público que la cobertura de la red 2G estámenguando en el ámbito del AMBA (Área Metropolitana de Buenos Aires).

Por otro lado, el proveedor actual de equipos AVL de la empresa no les satisfaceotras integraciones requeridas, tanto de hardware como de firmware. Por esoes que una parte importante de la relación comercial se basa en una dedicaciónexclusiva a sus requerimientos, al menos en esta primera fase del proyecto.

Finalmente, el contexto actual marca una tendencia en el crecimiento de los ser-vicios de monitoreo de flotas de vehículos. Esto es provocado por una fuertedemanda del seguimiento, control y seguridad de las operaciones que se llevana cabo, principalmente en el ámbito de los servicios de logística y de transportede pasajeros. Las regulaciones locales también incentivan la utilización de estosservicios, como ser el sistema predictivo de transporte urbano que comenzó aoperar en el año 2019 en el ámbito de la Ciudad Autónoma de Buenos Aires.Asimismo, es cada vez más común el requerimiento por parte de compañias ase-guradoras respecto a que el vehículo a asegurar posea instalado un equipo AVLsobre el vehículo a asegurar. Los servicios de seguimiento y control de flotas sonpotenciados por la diversidad de funciones adicionales que ofrecen los equiposAVL, algunas de ellas indicadas en la sección 1.1. Consecuentemente, existe unamayor oferta de servicios, lo que hace a la competitividad tecnológica del mercado.

1.4. Objetivos y alcance

El objetivo del trabajo es diseñar, implementar y construir un circuito impresofuncional del equipo AVL, que cumpla ampliamente con los requerimientos de laempresa cliente. Se incluye, además, la documentación referida a las especificacio-nes técnicas del equipo y al protocolo de comunicación con el mismo.

Por último, el presente trabajo no comprende la puesta en funcionamiento deun servidor que reciba y almacene los datos reportados por el equipo AVL, ni eldesarrollo del software que hace tratamiento de los mismos (todo esto es provistopor la empresa cliente).

5

Capítulo 2

Introducción Específica

En este capítulo se hace referencia a las tecnologías implementadas, se detallan losrequerimientos y la planificación del proyecto.

2.1. Descripción general del sistema

El equipo AVL desarrollado es parte de un sistema integral de monitoreo y controlde flota. Está compuesto por el vehículo sobre el que se instala el equipo, la redcelular a través de la que se transmiten datos entre el equipo y el servidor web, y elsoftware de gestión de flota. En la figura 2.1 se ilustra el diagrama correspondiente.

FIGURA 2.1: Diagrama en bloques del sistema.

6 Capítulo 2. Introducción Específica

En el diagrama en bloques de la figura 2.1 se observan los diferentes sistemas, loscuales se describen a continuación:

Equipo AVL: equipo desarrollado en el presente trabajo.

Vehículo: donde se encuentra instalado el equipo AVL, y en el que se encuen-tran los distintos elementos opcionales a sensar y activar, según necesidad,como por ejemplo:

• Ignición: señal de ignición del vehículo, sensada a través de entradadigital del equipo AVL (entrada específica para tal fin).

• Tensión de batería: tensión de la batería del vehículo, sensada a travésde entrada analógica del equipo AVL (entrada específica para tal fin).

• Sensores: se pueden mencionar sensores magnéticos de aperturas depuertas, sensados a través de entradas digitales, o sensores de pará-metros ambientales, como ser la temperatura, sensados mediante lasentradas analógicas.

• Actuadores: como ser relé de corte eléctrico del vehículo, o cerraduraelectromagnética de seguridad (comandada mediante relé).

Red celular: medio inalámbrico por el que se efectúa la comunicación bidi-reccional entre el equipo AVL y el servidor web.

Servidor web: encargado de gestionar la comunicación con el equipo AVL.Trabaja en conjunto con una base de datos, en la que se almacenan losreportes recibidos desde el mismo.

Software de gestión de flota: aplicación (front end) que ofrece, a nivel usuario,la capacidad de monitoreo de la flota y funciones de interacción con losequipos, como ser el envío de mensajes de texto a representar en el display.

Específicamente, el equipo AVL desarrollado consta de los siguientes subsistemas:

CPU: microcontrolador NXP LPC4337 [5], núcleo ARM Cortex-M4/M0 de32 bits, en el que se ejecutará el firmware que administra el sistema y losdistintos elementos periféricos.

Entradas y salidas digitales y analógicas: de propósito general, a excepciónde la entrada de ignición (sensado digital) y de la entrada de tensión debatería (sensado analógico).

Módulo GSM-GPS: módulo de telecomunicaciones Quectel EC21 [6], quesoporta las tecnologías de comunicaciones móviles 2G, 3G y 4G, y poseereceptor GNSS integrado.

SIM Holder (SIM Card): ranura para la inserción de la tarjeta SIM, la cual esnecesaria para disponer de una conexión de datos móviles activa.

Audio codec: circuito integrado que opera en conjunto con el módulo Quec-tel EC21, encargado de resolver la codificación y decodificación del audio(entrada de micrófono y salida de parlante), cuando se establece una comu-nicación por voz. El equipo admite recepción de llamadas efectuadas desdeuna línea telefónica.

Consola de usuario: subsistema que provee los recursos para la interaccióndel usuario (conductor del vehículo) con el equipo, los cuales son:

2.1. Descripción general del sistema 7

• Teclado: compuesto por cuatro teclas del tipo capacitivas (táctiles), que,junto al display, permiten la navegación a través de los distintos demenúes y funciones que ofrece el equipo a nivel usuario.

• Display: del tipo gráfico y monocromático, de tamaño en píxeles 128x64,que permite la visualización de datos al usuario, como ser, la velocidaddel vehículo, hora, y la mensajería de texto entrante.

• Buzzer: utilizado para el aviso sonoro mediante pitido de ciertas accio-nes del equipo, por ejemplo, ante una llamada de voz entrante.

• LEDs: array del tipo RGB, de propósito general.

• iButton: lector de dispositivos iButton [7], que permite la identificacióndel conductor del vehículo.

• Parlante y micrófono: utilizados para la comunicación por voz.

Desde el punto de vista funcional, a continuación se mencionan las característicasmás relevantes del equipo AVL:

Reporte periódico de datos de geolocalización.

Reporte de eventos del sistema. Ejemplo: por mensaje de texto saliente; porgestión de validación de usuario (iButton); por velocidad máxima excedida;por ignición y/o contacto del vehículo, etc.

Mensajería de texto: entrante hasta 240 caracteres (enviada desde la aplica-ción), y saliente (mensajes predeterminados y configurables por comandos,se reportan en formato de evento con código asociado para cada mensaje).

Comunicación por voz: bidireccional (full-duplex), con ajuste de ganancia delmicrófono y de volumen del parlante.

Gestión de identificación del conductor del vehículo mediante dispositivoiButton o código de ocho dígitos.

Gestión de identificación del inspector mediante código de cuatro dígitos.

Actualización del firmware en forma remota (firmware upgrade over-the-air,FOTA).

Configuración de parámetros: a través de SMS o aplicación web, medianteprotocolo propietario. El equipo permite el ajuste de los siguientes grupos:

• Parámetros de audio: ganancia del micrófono; volumen del parlante.

• Parámetros de conectividad: nombre del punto de acceso (Access PointName, APN); servidor de reporte de datos (dirección IP y puerto).

• Parámetros de interfaz de usuario (tiempo de autoapagado de backlightdel display, etc.)

• Parámetros de reporte: período de tiempo entre adquisición de datosde geolocalización; período de tiempo entre reintentos de envíos depaquetes ante inexistencia de conexión con servidor remoto.

• Parámetros de FOTA: ajustes del servidor de archivos (File TransferProtocol, FTP).


2.2. Protocolos y estándares de comunicación

En la presente sección se introduce a los protocolos y estándares de comunicacionesutilizados para el desarrollo del equipo AVL. Sus implementaciones se abordan enel capítulo 3.

2.2.1. Estándar NMEA 0183

El estándar NMEA 0183 [8], establecido por la National Marine Electronics Association,define los requerimientos eléctricos, el protocolo y tiempos de transmisión de da-tos, y la especificación de los formatos de las sentencias de datos sobre un busde comunicación serial, para ser utilizado en dispositivos electrónicos de usomarino. Particularmente, este estándar ha sido adoptado ampliamente en los equi-pos receptores de los sistemas GNSS (GPS, GLONASS, Galileo, etc.), por lo queactualmente se lo considera como el estándar de facto para esta industria.

Los mensajes NMEA se transmiten mediante bus serial, en formato ASCII, desdeun “emisor”, hacia uno o múltiples “destinatarios”. Para el caso de los receptoresGNSS, la estructura se compone según se observa en la tabla 2.1:

TABLA 2.1: Estructura de mensaje NMEA

Campo Descripción

$ Caracter de inicio de todo mensaje NMEA (1 byte)ID Emisor Depende del tipo de receptor GNSS: “GP” para GPS, “GL”

para GLONASS, etc. (1-2 bytes)ID Mensaje NMEA ID de mensaje NMEA (3 bytes)Campo de datos Campos de datos, delimitados por coma “,”* Caracter terminador del campo de datos (1 byte)Checksum Suma de verificación hexadecimal, calculada mediante

la operación X-OR de todos los caracteres comprendidosentre “$” y “*” (2 bytes)

<CR><LF> Cada mensaje NMEA termina con códigos ASCII decarriage return y line feed (2 bytes)

A continuación se listan algunas de las sentencias más comunes para receptoresGPS:

GPGGA: datos de posicionamiento globales, como ser posición, tiempo, etc.

GPRMC: datos de posicionamiento mínimos recomendados.

GPGSV: datos detallados de satélites.

GPGSA: datos generales de satélites.

GPVTG: datos de velocidad y rumbo.

En el presente trabajo, se hizo uso de los datos obtenidos de las sentencias GPGGAy GPVTG. A modo ilustrativo, en la tabla 2.2 se observan los datos contenidos enla sentencia GPGGA.

Ejemplo:

$GPGGA, 0 1 5 5 4 0 . 0 0 0 , 3 1 5 0 . 6 8 3 7 8 ,N, 1 1 7 1 1 . 9 3 1 3 9 , E, 1 , 1 0 , 0 . 6 , 0 0 5 1 . 6 ,M, 0 . 0 ,M, ,∗58 <CR><LF>

2.2. Protocolos y estándares de comunicación 9

TABLA 2.2: Sentencia NMEA GPGGA

Campo Descripción

$ Caracter de inicio de todo mensaje NMEAGPGGA ID de mensaje NMEATiempo UTC Tiempo en formato ‘hhmmss.sss’Latitud Latitud en formato ‘ddmm.mmmm’ (grados y minutos)N/S ‘N’ = Norte; ‘S’ = SurLongitud Longitud en formato ‘dddmm.mmmm’ (grados y minu-

tos)E/W ‘E’ = Este; ‘W’ = OesteEstado de fix ‘0’ = Inválido; ‘1’ = GNSS fix; ‘2’ = DGPS fixNúmero de sat Número de satélites en uso (0-12)HDOP Dispersión de la precisión horizontalAltitud Altitud de acuerdo al sistema WGS84 (metros)M Campo fijoSeparación GeoID Altura de GeoID de acuerdo al sistema WGS84 (metros)M Campo fijoDGPS Age Edad de los datos DGPS (segundos)DGPS Station ID ID de estación DGPS* Caracter terminador del campo de datosChecksum Suma de verificación hexadecimal<CR><LF> Fin de mensaje NMEA

2.2.2. Protocolo AT

El protocolo de comandos AT (del inglés attention, atención) es un estándar decomunicación diseñado para los módems de telecomunicaciones, y se encuentraoriginalmente específicado por la ITU-T en su recomendación V.250 [9]. Posterior-mente, con el advenimiento de las tecnologías de comunicación mediante datosmóviles, se estandarizó el protocolo AT para operar con módems de telecomunica-ciones celulares, bajo la especificación 3GPP TS 27.007 [10] (ETSI TS 127.007 [11]).Si un módem es compatible con el estándar, se dice que es AT compatible, aunquelos fabricantes pueden expandir el conjunto de instrucciones especificado segúnsus propias necesidades, manteniendo los lineamientos del estándar.

La sintaxis básica del protocolo AT establece que toda línea de comandos comienzacon el prefijo AT, continuado por la propia sintaxis de cada comando, y concluyecon el código ASCII1<CR> (carriage return, retorno de carro). Luego, los comandosson usualmente seguidos por una respuesta proveniente del módem celular, queincluye <CR><LF><response><CR><LF>, donde <response> es el texto o string derespuesta ante el comando enviado, y <LF> es el código ASCII de line feed (nuevalínea).

Los comandos AT se clasifican según:

Comandos de prueba (test commands): retornan la lista de parámetros yrangos de valores admitidos por el correspondiente comando de escrituray/o procesos internos al dispositivo.- Sintaxis: AT<command name>=?

1https://www.ascii-code.com

https://www.ascii-code.com


- Ejemplo: AT+CFUN=?- Descripción: devuelve listado de estados de funcionalidad soportados porel módem celular.

Comandos de lectura (read commands): retornan el valor de configuraciónactual del parámetro consultado.- Sintaxis: AT<command name>?- Ejemplo: AT+CREG?- Descripción: devuelve el estado actual de conexión con la red celular.

Comandos de escritura (write commands): configuran los valores de los pará-metros definibles por el usuario.- Sintaxis: AT<command name>=value1, value2, . . . , valueN- Ejemplo: AT+IPR=115200- Descripción: configura el baudrate en 115200 sobre la interfaz serial decomunicación del módem celular.

Comandos de ejecución (execution commands): retornan parámetros no modi-ficables afectados por los procesos internos del módem.- Sintaxis: AT<command name>=parameter1, parameter2, . . . , parameterN- Ejemplo: AT+GSN- Descripción: devuelve el número IMEI (International Mobile Equipment Iden-tify) del módem celular.

2.2.3. Protocolo UDP

El protocolo UDP (User Datagram Protocol, Protocolo de Datagrama de Usuarioes un protocolo definido en la capa de transporte del modelo OSI2 (Open SystemInterconnection [12]). Este protocolo no está “orientado a la conexión”, lo quesignifica que la comunicación no requiere que previamente se haya establecido elcanal de conexión (ruta), ni se hayan negociado otros parámetros. En la figura 2.2se ilustra el encabezado correspondiente a un datagrama UDP, el cual consta deocho bytes únicamente.

FIGURA 2.2: Encabezado datagrama UDP.

Como se observa en la figura 2.2, el encabezado se compone de los siguientescampos:

Puerto origen y destino: especifica desde y a qué proceso del terminal (pro-grama) están destinados los datos.

Longitud de UDP: longitud del paquete UDP (65.535 bytes máximo).

Suma de verificación: algoritmo para detectar errores en la recepción.

2Modelo de referencia para protocolos de red.

2.2. Protocolos y estándares de comunicación 11

El protocolo UDP no ejecuta control de flujo (no realiza un secuenciamiento de losdatagramas enviados), ni control de confirmación (no existe la confirmación deentrega, y no solicita retransmisión en caso de que se haya recibido un paquete conerrores). Sin embargo, UDP es muy útil en aquellos procesos que deben correr entiempo real y que no necesitan retransmisión, como es el caso de comunicacionesde telefonía IP, video, consulta a DNS, tráfico de multicast, etc. En aquellos casosen que se requiera retransmisión, deberá ser implementado en capas superiores.Tener en cuenta que este tipo de comunicaciones son sensibles a la latencia (tiempode propagación de los paquetes a través de la red) y al jitter3.

Dado que el equipo AVL desarrollado requiere conexiones de datos en tiempo realy con la menor carga de encabezado posible (menor consumo de datos), se utilizóel protocolo UDP para establecer la comunicación con el servidor de aplicación. Elacknowledgement (ACK, acuse de recibo) desde el servidor se encuentra resueltoa nivel aplicación. La retransmisión de paquetes desde el equipo AVL, ante norecepción del ACK, se implementó mediante un algoritmo propietario.

2.2.4. Protocolo cliente-servidor

El equipo AVL desarrollado se comunica con el servidor de aplicación mediante unprotocolo propietario. Por razones de confidencialidad, no se expone un análisisdetallado del mismo, pero a grandes rasgos, en la tabla 2.3 se indican los distintostipos de paquetes de datos que se intercambian.

TABLA 2.3: Tipos de paquetes de datos cliente-servidor

Tipo de paquete Descripción

Saludo inicial Es el primer paquete de datos que envía el equipo trascada inicio o reinicio del mismo, y la aplicación respondecon un ACK al convalidar el registro en la base de datos

Posición Datos de geolocalización, enviados períodicamenteEvento Datos de eventos, correspondientes a los generados por

el propio sistema y por el usuario del equipo (cada eventoposee un código único y predeterminado)

Gestión de usua-rio

Datos de gestión de usuario, originados por acciones deidentificación de conductor o identificación de inspector

Configuración deparámetros

Configuración de parámetros del sistema (ejemplo: perío-do de reporte de posición; servidor de reporte; mensajespredeterminados; etc.)

Comandos Enviados por la aplicación, con comandos (acciones) aejecutar en el equipo (ejemplo: activación de LEDs RGB;display de mensajes personalizados; etc.). Los coman-dos se reciben únicamente de forma concatenada a lasrespuestas (ACK) ante los eventos enviados por el equipo

3El jitter o variación del retardo, es la medida de la desviación estándar en los tiempos de llegadade los paquetes de datos transmitidos en forma sucesiva. El flujo de los paquetes a través de una redpuede seguir distintas rutas, por lo que es posible que lleguen al receptor en un orden distinto alque fueron enviados. Si sucede lo anterior, el jitter se incrementa, lo cual no es deseado.


Cada tipo de paquete de datos posee un encabezado único que lo identifica. Paracada paquete enviado por el equipo, el servidor responde con un ACK, con el finde confirmar su recepción. Cabe destacar, que el protocolo contempla la adiciónde un checksum hexadecimal al final de cada paquete enviado, utilizado por elreceptor para validar la integridad de los datos.

2.2.5. Protocolo de comandos SMS

El protocolo de comandos SMS (Short Message Service) permite realizar acciones deconsulta y configuración de parámetros del equipo AVL. Para ello, es necesariocontar con un equipo celular con el servicio de mensajería de texto activo. Al igualcomo se mencionó en la subsección 2.2.4, este protocolo también es de carácterpropietario, por lo que en la tabla 2.4 se indican, sin entrar en detalles, los distintosgrupos de comandos admitidos.

TABLA 2.4: Grupos de comandos SMS

Grupo Descripción

Básicos Consulta y configuraciones básicas del equipo AVL (ejem-plo: consulta de IMEI; consulta de número de serie; con-sulta de nivel de señal GSM y GPS; etc.)

Conectividad Consulta y configuración de servidor de reporte y APNAudio Consulta y configuración de volumen del parlante y ga-

nancia del micrófonoAdministración Consulta y configuración de parámetros admin. Incluye

acción de actualización del firmware vía FOTA

2.3. Requerimientos

A continuación se enumeran los requerimientos del sistema, donde para cadagrupo éstos se encuentran listados en orden descendente de prioridad. En general,se han obtenido tomando como base las prestaciones del equipo AVL que actual-mente utiliza la empresa, su protocolo de comunicaciones, y a especificacionesobtenidas en el diálogo con el jefe de desarrollo de software y con el jefe técnicode la empresa cliente.

1. Grupo de requerimientos asociados con la comunicación GPS

1.1. El sistema debe leer los datos del módulo GPS e informarlos a travésde comunicación celular hacia el servidor de aplicación.

1.2. Los datos a procesar son: posición (latitud y longitud); velocidad; acele-ración; rumbo; hora; tiempo.

1.3. Debe tener una sensibilidad tal que en la cabina del vehículo se poseauna adquisición óptima de satélites (preferentemente con coberturaGPS + GLONASS para aumentar la sensibilidad).

1.4. La adquisición de los datos debe ser constante (frecuencia de muestreo1 Hz).

2.3. Requerimientos 13

2. Grupo de requerimientos asociados con la comunicación GSM

2.1. La comunicación celular debe soportar cobertura en redes 2G, 3G y 4G.

2.2. Debe tener una sensibilidad tal que en la cabina del vehículo se poseauna óptima conexión con la red celular (de ser necesario, mejorarla conantena externa).

2.3. La frecuencia de la transmisión de datos de geolocalización hacia elservidor debe ser variable según el estado de ignición del vehículoy/o de la velocidad del mismo, en valores preconfigurados. Ejemplovehículo en marcha, reportes cada 1 minuto; vehículo detenido, reportescada 5 minutos.

2.4. La comunicación de datos debe ser bidireccional bajo protocolo UDP.

2.5. La comunicación por voz debe ser full-duplex.

3. Grupo de requerimientos asociados con el display

3.1. Deberá poseer mínimamente representación de información mediantedisplay gráfico 128x64.

3.2. Ajuste de tiempo de autoapagado de backlight del display por software.

4. Grupo de requerimientos asociados con el teclado

4.1. Deberá poseer teclas/botones para ingreso y/o comando del equipo porparte del usuario.

5. Grupo de requerimientos asociados con los LEDs de estado

5.1. Deberá poseer LEDs de estado de propósito general

6. Grupo de requerimientos asociados con las entradas y salidas

6.1. Deberá poseer al menos 2 entradas digitales para detección de variables,con protecciones contra sobretensión.

6.2. Deberá poseer al menos 3 entradas analógicas para detección de varia-bles, con protecciones contra sobretensión.

6.3. Deberá poseer al menos 2 salidas digitales, con las protecciones corres-pondientes, para manejo de cargas a definir.

6.4. Deberá poseer entrada digital para detección de ignición del vehículo(encendido).

7. Grupo de requerimientos asociados con el gestor de eventos

7.1. Deberá disparar reportes ante eventos por aceleración/desaceleraciónabrupta; por cambio de rumbo; por tiempo y/o distancia; por control detiempo (fecha y hora); por límites de velocidad.

7.2. Deberá enviar reporte geolocalizado al producirse el encendido o apa-gado del vehículo, con fecha y hora.

7.3. La periodicidad de los reportes dependerá de la entrada de ignición, ypodrá modificarse. En forma predeterminada, la periodicidad de losreportes será menor si el vehículo se encuentra detenido.


8. Grupo de requerimientos asociados con el sistema de administración

8.1. Gestión remota: deberá poder ser configurado y actualizado vía remota(OTA, over the air), siempre y cuando el equipo posea cobertura celular.

8.2. Almacenamiento: deberá poseer una capacidad de almacenamiento deal menos 100 reportes de datos, ante no conexión con el servidor.

8.3. Consumo: deberá gestionar el consumo y llevar al equipo a estado debajo consumo siempre que no esté ejecutando tareas.

2.4. Planificación

En esta sección se representan aspectos relacionados con la planificación delpresente trabajo. De esta forma, al inicio del proyecto, se confeccionó el diagramade actividad (AON, diagrama de Activity-On-Node), y el diagrama de Gantt, losque se ilustran en las figuras 2.3 y 2.4, respectivamente.

El diagrama de actividad representa la evolución temporal del proyecto, dondecada cuadro es una tarea, y con la letra t se indica la duración en horas. Lasflechas señalan el flujo del trabajo a través de las distintas etapas, y se estimaronun total de 620 horas para su conclusión. Sin embargo, esta planificación no fueestrictamente cumplida. Las principales causas de esto fueron la inexperiencia enel desarrollo de un sistema embebido de la magnitud del trabajo realizado, y laredefinición de ciertos requerimientos iniciales por parte de la empresa cliente enun estadío intermedio del proyecto. Por ende, se tuvo que dedicar más horas detrabajo al diseño e implementación, lo que ocasionó que el plazo de la planificaciónestipulado se excediera.

2.4. Planificación 15

FIGURA 2.3: Diagrama de actividad.


FIGURA 2.4: Diagrama de Gantt.

17

Capítulo 3

Diseño e Implementación

En este capítulo se detalla el proceso de diseño del hardware del equipo AVL, y laarquitectura de firmware implementada.

3.1. Hardware

Para la obtención de la versión funcional (de producción) el equipo atravesó tresfases diferentes de desarrollo según el hardware base utilizado, para la validaciónde las integraciones de hardware y firmware:

Fase de prototipado con EDU-CIAA-NXP [13]: con esta placa de desarrollose realizó la integración inicial del módulo Quectel EC21 (aceptación delmódulo para su utilización en siguientes fases).

Fase de prototipado con circuito impreso (versión 1): se diseñó y fabricóun prototipo, el cual integraba todos los subsistemas del equipo AVL. Sinembargo, tras ensayos de funcionamiento y redefinición de requerimientos(particularmente, que el equipo no debía poseer conectores tipo Molex Micro-Fit [14]), se decidió realizar otro diseño acorde a las nuevas necesidades. Detodas formas, se tenía previsto que ésta no fuese la versión final, dado que eldiseño contemplaba la impresión de circuitos adicionales para otros ensayos(por ejemplo, un acelerómetro).

Fase de producción con circuito impreso (versión 2): corresponde al utilizadoen el equipo AVL desarrollado. En la subsección 3.1.6 se ilustran los circuitosimpresos diseñados y fabricados.

Por otro lado cabe destacar, que la electrónica del equipo AVL se diseñó paraque sea instalada en un gabinete estándar [15] de fabricante local de productostermoformados. No se optó por un diseño a medida, dado los altos costos asocia-dos para la producción de pocas cantidades de gabinetes en plástico inyectado,principalmente por la necesidad de la fabricación inicial de la matriz de inyección.

En la tabla 3.1 se indican las características eléctricas que debe cumplir el equipoAVL.

TABLA 3.1: Requerimientos eléctricos mínimos del equipo AVL

Característica Descripción

Rango de tensión de alimentación 10 a 30 vCorriente de consumo máxima 500 mA @ 24 V

18 Capítulo 3. Diseño e Implementación

El diseño incluye una fuente de alimentación del tipo switching (topología step-down -buck-), mediante uso del regulador LM2596HV [16]. Esta fuente posee unrango de tensión de entrada de 7 V a 60 V, para una tensión de salida de 5 V, porlo que cumple el rango de alimentación requerido según tabla 3.1. Por otro lado, elequipo posee protección contra inversión de polaridad (diodo), protección contrasobretensión (varistor), y protección contra cortocircuito (fusible reseteable).

El diagrama en bloques del equipo AVL construido se ilustra en la figura 3.1. Enlas siguientes subsecciones se describen los criterios de diseño e implementacióndel hardware asociado a cada parte del sistema.

FIGURA 3.1: Diagrama en bloques del equipo AVL.

Para que el diseño sea versátil, por futura posibilidad de no utilizar la consola deusuario en caso de que así se requiera, se decidió fabricar dos circuitos impresos,uno correspondiente al PCB “principal”, y otro al PCB “consola”. El PCB principalintegra todos los subsistemas del equipo AVL, a excepción de la consola de usuario,la cual se integró en el PCB consola. La unión entre ambos circuitos impresos seimplementó mediante cable plano, lo cual se ilustra en la figura 3.2.

FIGURA 3.2: Conexionado entre PCBs principal y consola.

3.1.1. CPU e interfaces de comunicación

El microcontrolador que se utilizó fue el LPC4337JBD144 de NXP Semiconductors.El motivo fundamental de su elección fue para reducir los tiempos de diseño ydesarrollo, dado que inicialmente se utilizó la placa de desarrollo EDU-CIAA-NXP(que cuenta con dicho microcontrolador), la cual además se encuentra soportadapor la biblioteca para programación de sistemas embebidos sAPI [17]. En la tabla3.2 se indican los recursos a destacar que provee este microcontrolador, los cualesson suficientes para la implementación del equipo AVL.

3.1. Hardware 19

TABLA 3.2: Recursos del microcontrolador LPC4337JBD144


Núcleo ARM Cortex M4-M0 32 bits, 204 MHz fr. máx.Nro. GPIO1 83Convertidores de datos A/D 8x10b; D/A 1x10bInterfaces de comunicación UART/USART, SPI, I2C, SSP, USB, CAN, etc.Memoria Flash 1 MBMemoria EEPROM 16 KBMemoria RAM 136 KB

Las interfaces de comunicación utilizadas y los subsistemas asociados se detallanen la tabla 3.3.

TABLA 3.3: Subsistemas e interfaces de comunicación

Subsistema Interfaz de comunicación

Entradas digitales GPIO x 3Salidas digitales GPIO x 2Entradas analógicas GPIO (adquisición A/D) x 3Teclado GPIO x 4Buzzer GPIO x 1LEDs RGB GPIO x 3Display SPIiButton 1-Wire (bit banging2 por software)Módulo GSM-GPS UART (comunicación) y GPIO x 3 (control)Debug SWD3

3.1.2. Módulo GSM-GPS

Se optó utilizar por el módulo de telecomunicaciones EC21 de Quectel [6], porrecomendación de desarrollador conocido que trabajó con este módulo, y trasrevisión de sus características técnicas. El módulo EC21 posee receptor GNSSintegrado. El mismo se evaluó mediante un kit de evaluación, el cual se ilustra enla figura 3.3, provisto por un representante local del fabricante.

El módulo EC21 cumple satisfactoriamente con los requerimientos del trabajo,expuestos en la subsección 2.3. La comunicación de datos con el microcontroladores mediante UART, a una velocidad de 115200 baudios, y a través de GPIOs secontrola el estado de bajo consumo, reset por hardware y encendido del móduloEC21. En la tabla 3.4 se indican las características técnicas más relevantes delmismo.

1Del inglés General Purpose Input Output, entrada-salida de propósito general.2Bit banging es una técnica para transmisión de datos, por la cual mediante software se generan y

procesan las señales, en vez de utilizar recursos de hardware dedicados. El software se encarga deescribir y leer el estado del pin o pines asociados a la interfaz implementada, y debe establecer losparámetros de la señal, como ser el nivel de tensión, tiempos, sincronización, etc.

3Serial Wire Debug es un protocolo e interfaz para la programación y debugging de microcontrola-dores con núcleo ARM.


FIGURA 3.3: Kit de evaluación Quectel para módulo EC21.

TABLA 3.4: Especificaciones técnicas módulo EC21


Tensión de alimentación 3.3 V a 4.3 VCobertura celular LTE, UMTS/HSPA+ y GSM/GPRS/EDGEBandas LTE: B1/B2/B3/B4/B5/B7/B8/B28/B40; UMTS:

B1/B2/B5/B8; GSM: 850/900/1800/1900 MHzVelocidad LTE Máx. 10 Mbps (descarga); Máx. 5 Mbps (subida)Interfaz de audio PCM 16-bit (codec externo)Otras interfaces UART (principal y debug); USB 2.0Receptor GNSS GPS, GLONASS, Galileo, BeiDou, QZSSProtocolo GNSS NMEA 0183Protocolos TCP, UDP, PPP, FTP, HTTP, NTP, PING, QMI,

CMUX, HTTPS, SMTP, MMS, FTPS, SMTPS, SSL,FILE

Comandos AT Cumple con 3GPP TS 27.007, 27.005 y set de coman-dos mejorados de Quectel

Interfaces de antena Antena celular (ANT_MAIN); antena GNSS(ANT_GNSS); antena RX-diversity (ANT_DIV)

3.1. Hardware 21

El diseño de las pistas correspondientes a las interfaces de antenas celular y GNSSse siguió de acuerdo a las recomendaciones indicadas en hoja de datos del móduloEC21. Para mantener una impedancia controlada de 50 Ohm en cada una deestas líneas de transmisión, necesario para una óptima adaptación entre la propiaantena, su conector (tipo U.FL), y la interfaz del módulo EC21, el diseño se basóen una línea del tipo microstrip [18], con un ancho de pista de 0,8 mm y unaseparación contra plano de masa de 0,15 mm (siendo el espesor del dieléctrico delcircuito impreso de 1,6 mm). También se recomienda que exista buena coberturay continuidad de masa, por lo que se adicionaron en la periferia de las pistas,múltiples vías que unen la capa superior e inferior del plano de masa. En la figura3.4 se observa el circuito esquemático de referencia, y en la figura 3.5 se ilustra eldiseño final sobre el PCB de la zona correspondiente a las interfaces de antenas.

FIGURA 3.4: Circuito esquemático de interfaces de antenas.

FIGURA 3.5: Diseño en PCB de impedancia controlada sobre líneasde transmisión de antenas.

Por último, la tarjeta SIM o SIM card, se inserta en el SIM holder. Para protegeral módulo EC21 y tarjeta SIM ante descargas electrostáticas (ESD, ElectrostaticDischarge), principalmente causadas por la manipulación humana de la tarjetaSIM, se colocó un array de diodos TVS en las líneas de comunicación entre ambaspartes.


3.1.3. Comunicación de audio

Dado que el módulo EC21 provee una salida de audio digital mediante PCM [19](Pulse-Code Modulation, Modulación por Codificación de Pulsos), es necesario colo-car externamente un códec de audio. Esto se resolvió utilizando el códec NAU8814[20] de Nuvoton, tomando como referencia el circuito recomendado en hoja dedatos del módulo EC21, el cual se visualiza en la figura 3.6. La comunicación conel códec la resuelve el propio módulo EC21, y las configuraciones de audio serealizan mediante comandos AT desde el microcontrolador.

FIGURA 3.6: Circuito esquemático de referencia de comunicaciónde audio.

En cuanto a los elementos transductores, se utilizó un parlante de 2 W de potenciay 8 Ohm de impedancia, y un micrófono electret unidireccional de sensibilidadintermedia (-47 dB). Repecto a la elección de este último, cabe destacar que fueronprobados los distintos tipos de micrófonos según su direccionalidad o patronespolares (omnidireccionales, unidireccionales y cancelación de ruidos), lográndosela mejor calidad de audio con el micrófono unidireccional. En la figura 3.7 seilustra el diagrama polar de recepción de audio de este tipo de micrófonos.

FIGURA 3.7: Diagrama polar de micrófono unidireccional.

3.1. Hardware 23

3.1.4. Consola de interfaz de usuario

La consola de interfaz de usuario se compone por todos aquellos módulos que dealguna forma interactúan físicamente con el usuario del equipo. A continuación sedescribe la implementación de cada uno de ellos.

Teclado

Inicialmente se ideó el diseño a través de un teclado con botones, en el formatode teclado membrana. Sin embargo, teniendo en cuenta que toda parte que sufradesgaste mecánico es propensa a fallas por su uso contínuo, se concluyó desarrollarun teclado del tipo capacitivo (táctil) de cuatro teclas. Conceptualmente, cada teclaes un electrodo (superficie de cobre, de forma cuadrada en este caso), que oficiacomo una de las “placas” de un capacitor. La segunda placa está representadapor la capacitancia parásita del sistema “C0”, y por la capacitancia “CT ” quesurge por la aproximación de un objeto conductivo, como lo es el dedo humano.Luego, mediante un circuito integrado (TTP223 [21]) que sensa periódicamentela capacidad total del sistema descripto, se obtiene una salida del tipo pulsante oestado activo (configurable), correspondiente al nivel de detección de capacitancia(umbral) configurado. Esto último se determina mediante la adición, o no, deun capacitor externo. Aspectos que se tuvieron en cuenta en el diseño fueronel tamaño y forma del electrodo, el espesor del dieléctrico (correspondiente aldel propio gabinete, más un frente plástico que contiene la gráfica de las teclas),y el nivel de sensibilidad adecuado. En la figura 3.8 se observa el principio defuncionamiento de un sensor capacitivo táctil.

FIGURA 3.8: Principio de funcionamiento de sensor capacitivo4.

Display

De acuerdo al requerimiento impuesto, se utilizó un display gráfico de 128 por64 píxeles, con controlador ST7920 [22], como el que se ilustra en la figura 3.9. Lacomunicación entre el microcontrolador y el display se resolvió mediante bus SPI.El encendido del backlight se controla mediante GPIO, a través de un transistor.

4Tomado de https://www.electronicshub.org/wp-content/uploads/2015/02/Capacitive-Touch-Sensor-Principle.jpg.

https://www.electronicshub.org/wp-content/uploads/2015/02/Capacitive-Touch-Sensor-Principle.jpg

https://www.electronicshub.org/wp-content/uploads/2015/02/Capacitive-Touch-Sensor-Principle.jpg


FIGURA 3.9: Display gráfico 128x64 píxeles.

Buzzer y LEDs

El buzzer sirve para generar alertas sonoras (pitidos) ante recepción de mensajes,ingreso de llamadas de voz, o el presionado de las teclas. Se utilizó un buzzerestándar de 5 V, comandado mediante GPIO, como el que se observa en la figura3.10. En cuanto a los LEDs, se utilizó un array del tipo RGB, tal como el que seilustra en la figura 3.11, donde cada color es comandado por una GPIO a través detransistor MOSFET.

FIGURA 3.10:Buzzer5.

FIGURA 3.11:LEDs RGB6.

iButton

El iButton [7] es un dispositivo pasivo que en su memoria ROM interna poseegrabado un código único e irrepetible de 64 bits. Mediante protocolo 1-Wire [23],al posicionarse el iButton sobre el lector correspondiente, es posible leer el códigoROM y, en consecuencia, ejecutar acciones de validación (ejemplo, identificaciónde usuario). En la figura 3.12 se observan ambas partes.

FIGURA 3.12: Dispositivo iButton y lector.

5Tomado de http://bit.ly/2OwNEP4Buzzer.6Tomado de http://bit.ly/37iKTcQLedRgb.

http://bit.ly/2OwNEP4Buzzer

http://bit.ly/37iKTcQLedRgb

3.1. Hardware 25

La comunicación entre el microcontrolador y el iButton, como se mencionó, es através de protocolo 1-Wire, el cual se implementó sobre una GPIO, utilizando latécnica de bit banging por software.

3.1.5. Entradas y salidas digitales y analógicas

El equipo AVL posee entradas y salidas digitales y analógicas de propósito general.Además, posee entrada analógica de sensado de tensión de batería y entradadigital de sensado de ignición (encendido) del vehículo.

Salidas digitales de propósito general

El equipo posee tres salidas digitales del tipo open drain (drenador abierto). En lafigura 3.13 se ilustra el circuito esquemático de referencia. El diodo es del tipo zenerpara protección contra sobretensión. En este tipo de salidas, el MOSFET es utilizadocomo llave electrónica, comandado mediante GPIO desde el microcontrolador. Porejemplo, en el drenador del MOSFET se puede colocar un relé, conectado en el otroextremo a la tensión de alimentación correspondiente. En estado “inactivo” (salidade GPIO en bajo), el MOSFET se comporta como una llave abierta, por lo tantono existe conducción de corriente. En estado “activo” (salida de GPIO en alto), elMOSFET se comporta como una llave cerrada, por ende, se cierra el circuito y lacorriente circula desde tensión positiva hacia la masa, atravesando el bobinadodel relé y activando así el contacto de su circuito secundario.

FIGURA 3.13: Salida digital de propósito general.

Entradas digitales de propósito general

El equipo posee dos entradas digitales con detección por conexión a masa. En lafigura 3.14 se ilustra el circuito esquemático de referencia. El diodo es del tipoTVS para protección contra descargas electrostáticas y transitorios de alta tensión.En este tipo de entradas, se sensa mediante GPIO si existe conexión a masa. Paraello, la GPIO se encuentra configurada con su resistencia de pull-up interna. Porejemplo, se puede colocar un sensor magnético de apertura de puertas el cual,al estar cerrada la puerta, hace conexión a masa, y, por lo tanto, la GPIO detectaun estado bajo. Caso contrario, no existe conexión a masa, y la GPIO detecta unestado alto debido a la resistencia de pull-up interna.


FIGURA 3.14: Entrada digital de propósito general.

Entradas analógicas de propósito general

El equipo posee tres entradas analógicas para el sensado de variables análogas. Enla figura 3.15 se ilustra el circuito esquemático de referencia. El diodo es del tipoTVS para protección contra descargas electrostáticas y transitorios de alta tensión.En este caso, a través de la GPIO se pueden sensar parámetros físicos, como ser latemperatura o la humedad, mediante transductores que ofrezcan salida variableen tensión.

FIGURA 3.15: Entrada analógica de propósito general.

Entrada analógica de sensado de tensión de batería

El equipo posee una entrada analógica reservada para el sensado de la tensiónde la batería del vehículo. En la figura 3.16 se ilustra el circuito esquemático dereferencia. El diodo es del tipo TVS para protección contra descargas electrostáticasy transitorios de alta tensión. El divisor resistivo, conformado por resistencias al1 % de tolerencia, se calculó para que la medición permita un rango óptimo detensión de batería capaz a sensar. De esta forma, se definió una tensión máxima desensado de 30 V, suficiente para poder medir la tensión de batería de los colectivosurbanos, la cual oscila en 24 V.

FIGURA 3.16: Entrada analógica de sensado de tensión de batería.

3.1. Hardware 27

Entrada digital de sensado de ignición

El equipo posee una entrada digital reservada para el sensado de ignición (encen-dido) del vehículo. En la figura 3.17 se ilustra el circuito esquemático de referencia.El divisor resistivo se calculó para que en el rango de tensiones de 9 V a 30 V (secontemplan vehículos con tensión de batería de 12 V y de 24 V), el MOSFET seactive y, por lo tanto, exista conexión a masa en la GPIO (estado bajo). De estaforma, al estar configurada la GPIO con su resistencia de pull-up interna, se puededetectar si el vehículo se encuentra encendido.

FIGURA 3.17: Entrada digital de sensado de ignición del vehículo.

3.1.6. Diseño de circuitos impresos y montaje en gabinete

Como bien se mencionó anteriormente, el equipo AVL está compuesto por doscircuitos impresos, el PCB principal y el PCB consola. La comunicación entreellos es a través de cable plano con conectores IDC (en serigrafía, los extremos seconectan donde dice “CONN-CONSOLA” en cada circuito impreso). Los diseñosde los circuitos esquemáticos, circuitos impresos y modelos 3D se realizaron conel software KiCad [24]. En las figuras 3.18, 3.19, 3.20 y 3.21 se ilustran los diseñosrenderizados 3D e imágenes reales de los circuitos impresos que finalmente sefabricaron. En las figuras 3.22, 3.23 y 3.24 se muestra el montaje final realizadosobre el gabinete plástico, y en la figura 3.25 la vista frontal del equipo cerrado.

FIGURA 3.18: Circuito impreso principal - Render 3D.


FIGURA 3.19: Circuito impreso principal - Fabricado.

FIGURA 3.20: Circuito impreso consola - Render 3D.

FIGURA 3.21: Circuito impreso consola - Fabricado.

3.1. Hardware 29

FIGURA 3.22: Montaje de PCB principal en gabinete.

FIGURA 3.23: Montaje de PCB consola en gabinete.


FIGURA 3.24: Montaje y unión entre PCB principal y PCB consola.

FIGURA 3.25: Vista frontal del equipo AVL.

3.2. Firmware

Para el desarrollo del firmware del equipo AVL se utilizó como framework7 el siste-ma operativo en tiempo real FreeRTOS [25]. Dicho sistema operativo se encuentraen constante evolución y posee un soporte activo por parte de sus desarrollado-res y comunidad de usuarios. Además, es provisto junto a una API (ApplicationProgramming Interface) completa y documentada, la cual integra funciones para elmanejo de tareas, colas de datos, señales (semáforos, mutexes), timers, etc. Ademásde esto último, la decisión de su uso se basó en las bondades que ofrece un sistemaoperativo en tiempo real, entre ellas, la administración de tareas con prioridades

3.2. Firmware 31

definidas, y la respuesta del sistema en tiempos comprometidos ante eventosprioritarios.

Las bibliotecas que se utilizaron fueron:

sAPI (simpleAPI) [17]: biblioteca correspondiente al firmware del proyectoCIAA, que provee una mayor abstracción (respecto a bibliotecas provistaspor fabricantes de microcontroladores) para la programación de sistemasembebidos.

LPCOpen [26]: HAL8 (Hardware Abstraction Layer) provista por NXP que in-cluye drivers, middleware y programas ejemplo, para el desarrollo de firmwaresobre microcontroladores de la línea LPC.

u8g2 [27]: biblioteca para el manejo de displays monocromos.

Otras bibliotecas propietarias desarrolladas, por ejemplo, para el manejo dedispositivos iButton mediante protocolo 1-Wire, para la comunicación me-diante comandos AT con el módulo de telecomunicaciones, o para el manejode la interfaz de usuario (subsistema de display y menúes de navegación).

Como forma de trabajo se aplicaron conceptos de metodologías ágiles para re-alimentar los requerimientos del cliente durante todo el ciclo de desarrollo delequipo. De esta forma, se fueron validando progresivamente los requerimientosdel sistema, lo cual generó satisfacción y afianzó la relación con la empresa cliente.A continuación, se indican las herramientas y softwares que se utilizaron para darsoporte al desarrollo:

MCUXpresso SDK [28]: entorno de desarrollo para la programación demicrocontroladores de NXP Semiconductors.

Segger Ozone [29]: software para el debugging del firmware en tiempo real.Posee un plugin con funciones adicionales para el análisis de FreeRTOS.

GitLab [30]: servicio web (repositorio remoto) para el control del versionadoy documentación del firmware. Para el trabajo se utilizó un repositorioprivado.

Sourcetree [31]: software que provee una interfaz de usuario gráfica paragestionar repositorios (locales y remotos) bajo control de versiones por Git.

Trello [32]: software de administración de proyectos orientado al trabajocolaborativo.

Markdown [33]: lenguaje de marcado ligero con entrada en texto plano. Seutilizó para generar la documentación del proyecto (protocolo de comunica-ción e información técnica).

7Un framework o entorno de trabajo es una estructura conceptual y tecnológica de asistenciadefinida, normalmente, con artefactos o módulos concretos de software, que puede servir de basepara la organización y desarrollo de software. Típicamente, puede incluir soporte de programas,bibliotecas, y un lenguaje interpretado, entre otras herramientas, para así ayudar a desarrollar y unirlos diferentes componentes de un proyecto.

8Una HAL o capa de abstracción de hardware es un subsistema (por ejemplo, una API), quefunciona como interfaz entre el software de alto nivel y el hardware del sistema.


3.2.1. Arquitectura del firmware

La arquitectura del firmware desarrollado se ilustra en la figura 3.26, donde sepuede observar la modularización en capas del sistema [34].

FIGURA 3.26: Arquitectura en capas del firmware.

La aplicación se compone por las distintas tareas del sistema operativo que secrearon. Se definieron tres niveles de prioridades para las mismas, “baja”, “media”y “alta”, además de existir un nivel de prioridad mayor “IRQ” correspondiente alos handlers de las rutinas de interrupción y de los timers por software. En la figura3.27 se ilustra el diagrama detallado de las tareas, handlers y otros recursos del sis-tema (semáforos y colas de datos) que interactúan, según los niveles de prioridadasignados. Asimismo, se utilizó un mutex para controlar el acceso recurrente albus UART de comunicación con el módulo de GSM-GPS.

En el siguiente listado se describe el propósito de cada semáforo y cola de datosdel sistema:

semOneSecPos: semáforo que notifica solicitud de consulta de datos degeolocalización.

semFota: semáforo que notifica solicitud de ejecución de proceso de actuali-zación remota de firmware.

queUartData: cola que almacena los datos provenientes desde módulo GSMmediante bus UART.

queUartGsmData: cola que almacena strings de datos pre-procesados prove-nientes del módulo GSM.

queEvents: cola que notifica eventos generados en el sistema para su proce-samiento.

queTxData: cola que almacena los paquetes de datos para ser reportados alservidor de aplicación.

queExeCmd: cola que notifica comando a ejecutar (protocolo de comandosSMS).

3.2. Firmware 33

queSmsData: cola que almacena los SMS a enviar a destinatario (númeroorigen de comando SMS).

queButtons: cola que notifica datos de las teclas presionadas (previo a vali-dación por máquina de estado anti-rebote).

queButtonPressed: cola que notifica tecla presionada (tras validación pormáquina de estado anti-rebote).

queMsgCustom: cola que almacena los mensajes entrantes (enviados desdeel servidor de aplicación) a mostrar en display.

queGnssData: cola que notifica datos GNSS (hora y velocidad del vehículo)a mostrar en display.

queDigOut: cola que notifica salida digital a actualizar de estado.

FIGURA 3.27: Diagrama de interacción de tareas, handlers de inte-rrupción y recursos del sistema.


En cuanto a la capacidad de encolamiento de los paquetes de datos a reportaral servidor, generados por los eventos del sistema (ejemplo, evento periódicode reporte de datos de geolocalización), se abordó la solución tomando comoreferencia el modelo “productor-consumidor”9. Para esto, se creó una cola dedatos (queue), denominada queTxData, encargada de almacenar todos los paquetesde datos a reportar al servidor de aplicación. Por ello, en cuanto a la conectividaddel equipo con el servidor, existen dos estados de funcionamiento:

Conexión válida entre equipo y servidor: estado de funcionamiento “co-nectado” del equipo. La comunicación de datos mediante la red celular seencuentra activa y existe conexión con el servidor de aplicación. En este esta-do, cada vez que el sistema genera un paquete de datos a reportar, el mismoingresa a la cola queTxData, y el proceso TxDataToServer inmediatamente loremueve para transmitirlo al servidor. Esto se ilustra en la figura 3.28. Porlo tanto, mientras exista conexión valida entre el equipo y el servidor, todoslos datos que ingresan a la cola, son removidos y transmitidos automática-mente. Se observa que la cola permanece con un nivel de ocupación máximoequivalente a un elemento (un paquete de datos).

FIGURA 3.28: Reporte de datos en estado de conexión válido.

Conexión inválida entre equipo y servidor: estado de funcionamiento “noconectado” del equipo. La comunicación de datos mediante la red celularse encuentra inactiva (sin cobertura o crédito de datos móviles, APN malconfigurado, etc.), o no existe conexión con el servidor de aplicación porotros motivos (servidor no operativo o no emite respuesta, dirección IPde reporte mal configurada, etc.). En este estado, y considerando que lacola se encuentra vacía, cuando el sistema genera un paquete de datos areportar, el mismo ingresa a la cola queTxData, y el proceso TxDataToServer loremueve para transmitirlo al servidor. Sin embargo, al no existir conexión, elproceso TxDataToServer ejecuta un algortimo periódico de reintento de envíodel paquete, el cual sólo concluye cuando finalmente lo logró transmitircorrectamente (retiene el paquete hasta que se envía exitosamente). En estasituación, el sistema puede ir generando otros paquetes a reportar, los cualesse irán encolando en queTxData. Esto se ilustra en la figura 3.29. Mientrasno exista conexión, se observa que la cola se irá llenando en la medida queel sistema genere paquetes de datos a reportar. En caso de que la cola se

9El modelo de productor-consumidor de datos se utiliza para caracterizar procesos que compar-ten un buffer de datos de tamaño finito, donde uno de los mismos introduce datos en el buffer, yel otro los remueve. En esta interacción, puede suceder que el buffer se llene, por ende, el procesoque introduce datos se “bloquea” hasta que se libera espacio. Y en el caso opuesto, el buffer estávacío, por lo que el proceso que remueve datos se encuentra en estado de “reposo” hasta tanto nose ingresen nuevos datos. Un aspecto que toma relevancia para dar solución a estos sistemas es lasincronización de los procesos intervinientes (por ejemplo, con un semáforo).

3.2. Firmware 35

llene, todos los nuevos paquetes de datos a reportar que genere el sistema sedescartarán. Solo cuando se restablece la conexión con el servidor, la cola seirá vaciando para dar lugar a nuevos paquetes. Cabe aclarar que la cola esdel tipo LIFO (Last-In First-Out), donde el último elemento en ingresar, es elprimero en salir.

FIGURA 3.29: Reporte de datos en estado de conexión inválido.

La cola queTxData es alimentada por los distintos subsistemas que generan lospaquetes de datos en función de los eventos que se originan. En la figura 3.30se puede observar la aplicación del modelo productor-consumidor, donde eneste caso existen múltiples productores de paquetes de datos (subsistemas deeventos), y un único consumidor (proceso TxDataToServer). Cabe destacar, quetodos los eventos del sistema, previamente a ingresar a la cola, son “encapsulados”según según formato estándar establecido por el protocolo de comunicación conel servidor de aplicación.

FIGURA 3.30: Modelo productor-consumidor aplicado para el ma-nejo de la transmisión de los paquetes de datos al servidor.

3.2.2. Tarea de gestión de la comunicación con módulo GSM-GPS

Esta tarea, denominada “gsm()”, es la encargada de administrar íntegramente elmódulo GSM-GPS. Consta de una máquina de estado según se ilustra en la figura3.31, donde se puede observar la secuencia de estados y una breve descripción delas funciones que realiza cada uno.


FIGURA 3.31: Máquina de estados - Tarea gsm().

3.2. Firmware 37

Gestión de los mensajes URC

La validación de mensajes URC10 (Unsolicited Result Codes, estado “verify_urc”)contempla los distintos mensajes que se detectaron con la utilización del móduloEC21 [35]. En la inicialización del mismo se configuran los mensajes URC queinteresan recibir. En la tabla 3.5 se observan los mensajes que son gestionados porla tarea.

TABLA 3.5: Mensajes URC

Mensaje URC Descripción

RING Llamada entranteNO CARRIER Desconexión de llamada+QSIMSTAT Estado de tarjeta SIM (insertada, removida o descono-

cido)+QIND Indicaciones varias del módem (inicialización SMS

terminada, memoria SMS llena, etc.)+QIOPEN Puerto de servicio de datos activo+QIURC Indicaciones referidas a comunicación de datos (datos

entrantes, desactivación del contexto PDP, etc.)POWERED DOWN Módulo GSM apagado (en modo hiberación, bajo con-

sumo)+CFUN Estado de funcionalidad del módem

Registración en la red celular

La registración en la red celular (estado “gsm_network_registration”) se imple-mentó según el diagrama de flujo de la figura 3.32, de acuerdo a recomendacionesdel fabricante del módulo EC21 [36]. En la tabla 3.6 se describen los comandos ATutilizados para el proceso en cuestión.

TABLA 3.6: Comandos AT para registración en red celular

Comando AT Descripción

AT+CPIN Consulta estado de SIM card (se identifica o no presencia)AT+CREG Consulta estado de registración en la red celularAT+QICSGP Configuración de parámetros de contexto PDP11 (se confi-

gura APN de prestadora de servicio celular)AT+CGQREQ Configuración de perfil de calidad de servicio (QoS) solicita-

do (se mantienen valores por defecto)AT+CGQMIN Configuración de perfil de calidad de servicio (QoS) mínimo

aceptable (se mantienen valores por defecto)AT+QIACT Activación del contexto PDP y consulta de IP localAT+QIDEACT Desactivación del contexto PDP

10Los URC son mensajes provenientes desde el módulo GSM que proveen información respectoa eventos asincrónicos. Es decir, no son solicitados por el host (microcontrolador), sino que elmódulo GSM los remite espontáneamente de acuerdo a la ocurrencia de determinados eventos.Entre estos mensajes, se pueden mencionar los correspondientes a llamada entrante, SMS entrante,datos entrantes, de-registración de la red celular, etc.


FIGURA 3.32: Diagrama de flujo de registración en la red celular.

11Contexto PDP (Packet Data Protocol, Protocolo de Paquete de Datos) se refiere a la conexión que seestablece entre la estación de datos móviles (a la que está conectado el módem) y la dirección destino(servidor remoto). Para establecer esta conexión, se debe proveer información de identificación deusuario, esto es, el APN (Access Point Name, Nombre del Punto de Acceso), usuario, contraseña ymodo de autenticación. El APN es el punto de acceso para redes de datos 3G y 4G, el cual es provistopor el operador del servicio de datos (en Argentina: Movistar, Claro o Personal).

3.2. Firmware 39

Transmisión de datos a servidor remoto

La transmisión de datos hacia el servidor remoto (estado “gsm_tx_data_to_server”)se implementó según el diagrama de flujo de la figura 3.33, de acuerdo a reco-mendaciones del fabricante del módulo EC21 [36]. En la tabla 3.7 se describen loscomandos AT utilizados para el proceso en cuestión.

FIGURA 3.33: Diagrama de flujo de transmisión de datos a servidorremoto.

TABLA 3.7: Comandos AT para transmisión de datos a servidorremoto

Comando AT Descripción

AT+QIOPEN Abrir conexión de datos (socket) con IP destino (servicioUDP)

AT+QISEND Enviar datos (string de caracteres) a IP destinoAT+QIRD Lectura de datos recibidos (ACK) desde IP destinoAT+QICLOSE Cerrar conexión de datos (socket) establecida


Actualización remota del firmware (FOTA)

La actualización remota del firmware es un proceso que permite la actualizacióndel firmware del microcontrolador del equipo. Consiste en regrabar el códigode aplicación tal como si se estuviese haciendo en forma física a través de unacomputadora y un dispositivo programador con conexión cableada. Para que sepuede ejecutar, se deben validar las siguientes condiciones:

1. Parámetros del servidor FTP válidos: el equipo deberá tener configuradoslos parámetros de acceso al servidor FTP (IP destino y usuario) [37].

2. Servidor FTP operativo: el equipo se deberá poder identificar y configurarcarpeta de acceso (donde se encuentra el archivo de actualización).

3. Conectividad celular activa y estable: para que la descarga del archivo deactualización a la memoria del módulo EC21 se ejecute sin errores.

4. Archivo binario “.bin” de nueva versión de firmware cargado en servidorFTP: el firmware del equipo se encuentra versionado bajo un código deter-minado. El código de versión del firmware alojado en el equipo debe serdistinto al del firmware del archivo binario alojado en servidor FTP.

La arquitectura implementada de la memoria flash del microcontrolador se ilustraen la figura 3.34. El microcontrolador LPC4337 posee 1 MB de memoria flashinterna, la cual se dividió en tres sectores: el sector de memoria de la aplicaciónque se ejecuta “running_slot”; el sector de memoria que aloja el archivo binariodescargado desde el servidor FTP “upload_slot”; y el sector de memoria de laaplicación bootloader denominado “bootloader_slot”12.

FIGURA 3.34: Arquitectura implementada sobre el mapa de memo-ria flash del microcontrolador.

De esta forma, existen dos contextos de ejecución de la aplicación. El contexto“running_app”, que corresponde a la ejecución del código que se aloja en el sectorde memoria “running_slot”, esto es, el código de aplicación del equipo AVL. Y elcontexto “running_bootloader”, que corresponde a la ejecución del código que sealoja en el sector de memoria “bootloader_slot”, esto es, el código de aplicación del“bootloader”.

12Aplicación que se ejecuta inmediatamente tras cada (re)inicio del sistema, que, en forma gene-ralizada en los sistemas embebidos, se utiliza para realizar acciones básicas de inicialización delsistema y actualización del firmware (código de aplicación).

3.2. Firmware 41

En la figura 3.35 se observa el inicio del proceso de actualización mediante coman-do SMS o de aplicación, con aplicación corriendo en contexto “running_app”. Acontinuación suceden todas las configuraciones para conectividad con servidorFTP, donde se encuentra alojado el archivo binario a descargar. Una vez descarga-do el mismo (alojado en memoria flash del módulo EC21), se procede a grabarloen el sector de memoria “upload_slot”. Tras esto último, se verifica su integridadmediante un checksum calculado mediante CRC32 y, en caso de ser exitoso, sereinicia el sistema.

FIGURA 3.35: Diagrama de flujo de actualización remota delfirmware - Contexto running_app.


Posterior al reinicio del sistema, la aplicación inicia su ejecución en el contexto“running_bootloader”, tal como se ilustra en la figura 3.36. En el bootloader se verificaque el flag “actualización_disponible” está activo (se pasa a estado bajo), por loque se procede a regrabar el código de aplicación alojado en “running_slot”, con laimagen binaria alojada en el “upload_slot”.

FIGURA 3.36: Diagrama de flujo de actualización remota delfirmware - Contexto running_bootloader.

Finalmente, tras la actualización del código de aplicación, el sistema se reinicia,y nuevamente se ejecuta el bootloader. Sin embargo, esta vez el flag “actualiza-ción_disponible” se encuentra en estado bajo, por lo que se procede a iniciar laejecución del código de aplicación alojado en “running_slot” (cambio de contextohacia running_app). Así se concluye el proceso de actualización de firmware.

Cabe mencionar que, si bien no se representó en los diagramas, también se imple-mentó el manejo de errores en cada uno de los subprocesos.

El grabado en memoria flash se gestionó con la utilización de las rutinas del módu-lo IAP (In-Application Programming), alojadas en la Boot ROM del microcontrolador.Estas rutinas permiten las operaciones básicas de borrado (erase) y grabado (write)de la memoria flash del microcontrolador [38].

3.2.3. Tarea de gestión de eventos del sistema

Esta tarea, denominada “eventos()”, tiene como función atender los distintoseventos generados en el sistema, encapsularlos en paquetes de datos según elprotocolo cliente-servidor, y enviarlos a la cola de datos queTxData. Consta de una

3.2. Firmware 43

máquina de estado según se ilustra en la figura 3.37, donde se puede observar lasecuencia de estados y una breve descripción de las funciones que realiza cadauno.

FIGURA 3.37: Máquina de estados - Tarea eventos().

A continuación se listan los eventos que la tarea gestiona:

Evento de posición periódica de sistema: se genera cada 1 segundo, paraconsultar datos de geolocalización y disponerlos para otras acciones.

Evento de posición periódica de usuario: se genera cada “x” segundos (con-figurable), para consultar datos de geolocalización y ser transmitidos aservidor remoto.

Evento de mensaje de usuario: se genera cuando el usuario solicita envío demensaje de texto desde la consola (teclado y display).

Evento de validación de usuario: se genera cuando se identifica un usuariomediante lectura de iButton.

Evento de exceso de velocidad: se genera cuando se supera umbral de velo-cidad configurado (comparación contra datos de geolocalización obtenidospor evento de posición periódica de sistema).

3.2.4. Tarea de gestión de comandos del sistema

Esta tarea, denominada “ejecutar_comando()”, se encarga de gestionar los coman-dos recibidos mediante protocolo SMS. Consta de una máquina de estado segúnse ilustra en la figura 3.37, donde se puede observar la secuencia de estados y unabreve descripción de las funciones que realiza cada uno.


FIGURA 3.38: Máquina de estados - Tarea ejecutar_comando().

A continuación se listan los comandos que la tarea gestiona:

Comando de consulta de datos técnicos del equipo (IMEI; número de seríe;versión de firmware; ID de equipo).

Consulta de nivel de señal GSM y GPS.

Consulta y configuración de parámetros del equipo (período de reportede datos de geolocalización a servidor; servidor de reporte; APN; servidorFTP; umbral de velocidad para evento de exceso de velocidad; volumen delparlante; ganancia del micrófono; etc.).

Actualización remota del firmware (FOTA).

Activación/desactivación de salidas digitales.

Reset de equipo.

3.2.5. Tarea de gestión de la interfaz de usuario

Esta tarea, denominada “interfaz_de_usuario()”, se encarga de administrar lossubsistemas de la consola de usuario, esto es, el display, el teclado, el iButton eindicaciones mediante buzzer y LEDs. Consta de una máquina de estado según seilustra en la figura 3.39, donde se puede observar la secuencia de estados y unabreve descripción de las funciones que realiza cada uno.

3.2. Firmware 45

FIGURA 3.39: Máquina de estados - Tarea interfaz_de_usuario().

Identificación de usuario - iButton

La comunicación con el dispositivo iButton es a través de protocolo 1-Wire, elcual se implementó mediante la técnica de bit-banging por software [23]. De estemodo, existen cuatro operaciones básicas a resolver, esto es, la escritura de unbit en estado lógico alto (1), la escritura de un bit en estado lógico bajo (0), lalectura de un bit, y la acción de reset. Luego, la lectura o escritura de un byte(ocho bits) se gestiona como una secuencia de lecturas o escrituras de un bit. Latemporización, del orden de los microsegundos, se gestionó mediante el uso deretardos (delays) del tipo bloqueantes. Para la comunicación, se utilizó una GPIOdel microcontrolador que, para el caso de la acción de escritura, se configura comosalida (output), y para la acción de lectura, se configura como entrada (input). En lafigura 3.40 se ilustran las operaciones básicas implementadas, y los tiempos que sedeben respetar de acuerdo al protocolo.


FIGURA 3.40: Temporización de señales del protocolo 1-Wire.

3.2.6. Tarea de gestión de las entradas y salidas analógicas y digitales

Esta tarea, denominada “entradas_y_salidas()”, se encarga de verificar el estadode las entradas y salidas digitales y analógicas del equipo. Consta de una máquinade estado según se ilustra en la figura 3.41, donde se puede observar la secuenciade estados y una breve descripción de las funciones que realiza cada uno.

FIGURA 3.41: Máquina de estados - Tarea entradas_y_salidas().

47

Capítulo 4

Ensayos y Resultados

En este capítulo se detallan los ensayos realizados para validar los requerimientosdel equipo AVL y sus resultados.

4.1. Ensayos sobre el módulo GSM-GPS

A continuación se identifican los ensayos realizados para la validación del móduloGSM-GPS.

4.1.1. Ensayo de calidad de señal celular y GPS

Este ensayo tuvo como fin verificar la correcta recepción de señal celular y GPSdel módulo EC21. Para ello, se recorrió en vehículo una zona de la localidad deSantos Lugares, correspondiente al partido Tres de Febrero, provincia de BuenosAires. El recorrido se hizo en dicha zona por pedido expreso de la empresa cliente,siendo que con el equipo AVL que utilizan, poseen específicamente mala coberturade señal celular, lo que provoca desconexiones temporales con la aplicación. Elensayo se realizó con la placa de evaluación del módulo EC21, antena celularpasiva con recepción en bandas de 2G, 3G y 4G, y antena GPS activa.

Para validar el nivel de señal celular, se utilizó el comando AT+CSQ, el cual proveeun reporte de la calidad de señal. A continuación se observa el formato de envío yrespuesta de este comando:

1 AT+CSQ2 +CSQ: < r s s i > ,< ber >3

4 Ejemplo :5 +CSQ: 12 ,99

El parámetro que interesa es <rssi>, que es la indicación del nivel de fuerza dela señal (valores válidos entre 0 y 31). En la tabla 4.1 se indican los valores dereferencia de calidad de señal que son tomados en la práctica según el valor RSSI[39].

48 Capítulo 4. Ensayos y Resultados

TABLA 4.1: Referencia entre calidad de señal, valores RSSI y poten-cia en dBm

Calidad de señal Valor RSSI Valor dBm

Excelente RSSI ≥ 22 dBm ≥ −65Buena 14 ≤ RSSI < 22 −75 ≤ dBm < −65Moderada 7 ≤ RSSI < 14 −85 ≤ dBm < −75Pobre RSSI < 7 dBm < −85No detectable 99 -

Respecto a la calidad de señal GPS, se utilizó el comando AT+QGPSLOC parasu validación. A continuación se observa el formato de envío y respuesta de estecomando:

1 AT+QGPSLOC2 +QGPSLOC:3 <UTC>,< l a t i t u d e >,< longitude >,<hdop>,< a l t i t u d e >,< f i x >,<cog >,<spkm>,<spkn

>,< date >,< nsat >4

5 Ejemplo :6 +QGPSLOC:7 1 4 2 2 4 2 . 0 , 3 4 3 5 . 7 1 5 6 S , 0 5 8 3 2 . 2 7 1 7W, 0 . 7 , 1 0 . 6 , 2 , 2 8 0 . 4 5 , 2 2 . 5 , 1 2 . 1 , 0 2 0 4 1 9 , 1 0

En este caso, los parámetros que interesan son <hdop> (dispersión horizontal dela posición) y <nsat> (cantidad de satélites). Valores menores a 1 para <hdop> ymayores a 4 para <nsat> son óptimos.

En la figura 4.1 se puede observar el recorrido realizado con el vehículo, con lalocalización de los puntos donde se tomaron las muestras. Los resultados de lasmediciones en el recorrido se ilustran en la tabla 4.2 (no se muestran todos losvalores tomados, sólo una muestra representativa). En conclusión, las medicionesrealizadas fueron satisfactorias, tanto de calidad de señal celular como GPS.

TABLA 4.2: Mediciones de calidad de señal celular y GPS

Pos ID Valor RSSI Calidad RSSI Valor HDOP Valor NSAT

1 12 Moderada 0.7 102 10 Moderada 0.7 103 15 Buena 0.7 104 18 Buena 0.7 95 11 Moderada 0.7 96 22 Excelente 0.7 97 21 Buena 0.7 98 18 Buena 0.7 99 17 Buena 0.9 910 9 Moderada 0.7 1011 28 Excelente 0.7 1012 24 Excelente 0.7 10

4.1. Ensayos sobre el módulo GSM-GPS 49

FIGURA 4.1: Recorrido realizado para ensayo de calidad de señalcelular y GPS.

4.1.2. Ensayo de adquisición de datos de geolocalización

Para lograr la adquisición de datos con un período de muestreo de un segundo, seutilizó un timer por software mediante la API de FreeRTOS. En el algoritmo 4.1se observa su implmentación. El semáforo es tomado por la tarea eventos() pararealizar la consulta al módulo EC21.

1 # def ine TIMER_PERIOD_POSICION (1000 / portTICK_PERIOD_MS )2

3 /∗ Creacion de timer con periodo 1 segundo y autorecargable en funcionde i n i c i a l i z a c i o n de FreeRTOS ∗/

4 timOneSecPos = xTimerCreate ( " t imer_pos ic ion " , TIMER_PERIOD_POSICION ,pdTRUE, ( void ∗ ) 1 , t imer_pos ic ion ) ;

5

6 /∗ Callback t imer_pos ic ion ∗/7 void t imer_pos ic ion ( TimerHandle_t xTimer ) {8

9 /∗ S o l i c i t a consul ta per iod ica de datos de g e o l o c a l i z a c i o n ∗/10 xSemaphoreGive ( semOneSecPos ) ;11 }

ALGORITMO 4.1: Código de timer para adquisición de datos degeolocalización.

Como resultado del ensayo, se obtuvo la siguiente secuencia de consultas y res-puestas (muestra representativa de cinco consultas consecutivas), donde se puedeobservar que el campo de “hora” (primer campo luego de “+QGPSLOC:”) va-ría cada un segundo (texto en rojo). De esta forma se validó correctamente elrequerimiento.

1 AT+QGPSLOC?2 +QGPSLOC: 103115 . 0 , 3 4 3 7 . 8 5 5 9 S , 0 5 8 2 2 . 6 0 6 9W, 3 . 2 , 3 4 , 2 , 1 7 8 . 2 4 , 0 , 0 , 1 1 0 8 1 9 , 0 33 OK4

5 AT+QGPSLOC?


6 +QGPSLOC: 103116 . 0 , 3 4 3 7 . 8 5 5 9 S , 0 5 8 2 2 . 6 0 6 9W, 3 . 2 , 3 4 , 2 , 1 7 8 . 2 4 , 0 , 0 , 1 1 0 8 1 9 , 0 37 OK8



17 AT+QGPSLOC?18 +QGPSLOC: 103119 . 0 , 3 4 3 7 . 8 5 5 9 S , 0 5 8 2 2 . 6 0 6 9W, 3 . 2 , 3 4 , 2 , 1 7 8 . 2 4 , 0 , 0 , 1 1 0 8 1 9 , 0 319 OK

4.1.3. Ensayo sobre la comunicación UDP bidireccional

Para validar la comunicación con el servidor remoto de aplicación medianteprotocolo UDP, se enviaron los comandos correspondientes a la transmisión dedatos al servidor, según se expuso en subsección 3.2.2. A continuación se observala secuencia de comandos y respuestas obtenidas. Se aclara que el mensaje enviadofue de prueba (no corresponde a envío real de datos del equipo AVL), y que seconfiguró el servidor remoto para que responda un mensaje a los efectos de validarla comunicación. También, se oculta el dato de servidor destino, siendo éste elservidor de la aplicación de la empresa cliente.

1 /∗ Abrir conexion de datos UDP con serv idor dest ino ∗/2 AT+QIOPEN=1 ,0 , "UDP" , " servidor−remoto . com . ar " , "PORT" , "PORT" ,03

4 /∗ Puerto de s e r v i c i o de datos a c t i v o ∗/5 +QIOPEN: 0 ,06

7 /∗ Enviar datos a serv idor dest ino ∗/8 AT+QISEND=09 > PRUEBA DE DATOS ENVIADOS A SERVIDOR DESTINO ;

10 SEND OK11

12 /∗ Datos e n t r a n t e s r e c i b i d o s ( respuesta ) ∗/13 +QIURC : " recv " ,014

15 /∗ Lectura de datos r e c i b i d o s desde serv idor dest ino ∗/16 AT+QIRD=017 +QIRD : 1618 MENSAJE RECIBIDO@6619 OK20

21 /∗ Cerrar conexion de datos e s t a b l e c i d a ∗/22 AT+QICLOSE=023 OK

4.2. Ensayos sobre la interfaz de usuario 51

4.2. Ensayos sobre la interfaz de usuario

A continuación se identifican los ensayos realizados para la validación del sistemade interfaz de usuario y los requerimientos asociados.

4.2.1. Ensayo sobre el display gráfico y la navegación en menúes

Para que el usuario interactúe con el equipo AVL, se implementaron una seriede menúes con representación en display, de acuerdo a las distintas funcionesque ofrece el equipo. La navegación se efectúa mediante las acciones del tecladocapacitivo de cuatro teclas (“arriba”, “abajo”, “retornar” y “ok”). Su representaciónse ilustra en la figura 4.2.

FIGURA 4.2: Representación de menues en display gráfico.


A continuación se describe cada menú enumerado:

1. Menú de bienvenida: menú predeterminado del equipo. Ofrece informaciónde hora y velocidad del vehículo.

2. Menú principal: menú desde el cual se accede a las funciones del equipo.

3. Menú enviar mensaje: menú que lista los distintos mensajes predeterminadosalmacenados en memoria del dispositivo.

4. Menú mensaje enviado: al estar en menu enviar mensaje, al presionar “ok”se envía el mensaje seleccionado al servidor remoto.

5. Menú gestión inspector: menú desde el cual se accede a las funciones degestión inspector.

6. Menú inspector sube: al ingresar los cuatro dígitos del pin del inspectory presionar “ok”, se envía evento correspondiente al servidor remoto. Laoperatoria es equivalente para el menú inspector baja.

7. Menú gestión asistencia: menú desde el cual se accede a las funciones degestión asistencia.

8. Menú personal ingresa: al ingresar los ocho dígitos del pin del usuario ypresionar “ok”, se envía evento correspondiente al servidor remoto. Eneste menú se habilita la lectura del dispositivo iButton. La operatoria esequivalente para el menú personal egresa.

4.2.2. Ensayo del protocolo 1-Wire y dispositivo iButton

Para validar la lectura de sensor iButton, se implementó la función del algoritmo4.2. Todas las funciones “ONE_WIRE” corresponden a la biblioteca desarrolladapara manejar el protocolo 1-Wire.

1 oneWireSensorState_t ONE_WIRE_readSensorRomData ( oneWireSensorData_t ∗sensorData ) {

2

3 u i n t 8 _ t byteIndex ;4

5 /∗ Envio sena l de r e s e t para determinar s i hay presenc ia de sensor ∗/6 i f ( ONE_WIRE_touchReset ( ) == FALSE)7 re turn ( oneWireData . s e n s o r S t a t e = ONE_WIRE_SENSOR_NO_PRESENCE) ;8

9 /∗ Envio comando de l e c t u r a de codigo de ROM ∗/10 ONE_WIRE_writeByte (ONE_WIRE_COMMAND_READ_ROM) ;11

12 /∗ Leo ROM data ∗/13 f o r ( byteIndex = 0 ; byteIndex < ROM_CODE_LENGHT; byteIndex ++) {14 sensorData−>romCode [ byteIndex ] = ONE_WIRE_readByte ( ) ;15 /∗ Guardo datos en v a r i a b l e s para acceso inmediato ∗/16 i f ( byteIndex == ONE_WIRE_ROM_DATA_FAMILY_CODE)17 sensorData−>familyCode = sensorData−>romCode [ byteIndex ] ;18 e l s e i f ( byteIndex <= ONE_WIRE_ROM_DATA_SN_BYTE6)19 sensorData−>serialNumber [ byteIndex − 1] = sensorData−>romCode [

byteIndex ] ;20 e l s e21 sensorData−>c r c = sensorData−>romCode [ byteIndex ] ;22 }23

24 /∗ Check f a l s e c o n t a c t e r r o r ∗/25 i f ( sensorData−>romCode [ONE_WIRE_ROM_DATA_FAMILY_CODE] == 0x00 )

4.2. Ensayos sobre la interfaz de usuario 53

26 re turn ( oneWireData . s e n s o r S t a t e = ONE_WIRE_SENSOR_ERROR) ;27

28 /∗ V e r i f i c o CRC ∗/29 i f (ONE_WIRE_checkCRC ( ) == FALSE)30 re turn ( oneWireData . s e n s o r S t a t e = ONE_WIRE_SENSOR_ERROR) ;31 e l s e32 re turn ( oneWireData . s e n s o r S t a t e = ONE_WIRE_SENSOR_OPERATIONAL) ;33 }

ALGORITMO 4.2: Función de lectura de dispositivo iButton.

En la figura 4.3 se puede ver el resultado del ensayo, al acercar un dispositivoiButton al lector. La salida muestra el código único de identificación del sensorROM Code, el cual se desglosa en el Family Code (código que identifica a la familiade dispositivos iButton), en el Serial Number (número de serie del dispositivoiButton), y en el CRC (código de redundancia cíclica para validar la integridad delos datos). La salida indica “NO_PRESENCE” cuando no se detecta iButton sobreel lector, e indica “ERROR” cuando se apoya el iButton al lector, pero existe falsocontacto. Esto último es natural que suceda cada vez que se apoya el iButton sobreel lector, por la forma constructiva de cada una de las partes.

FIGURA 4.3: Detección de dispositivo iButton.

En la figura 4.4 se observa la medición realizada con analizador lógico sobre el bus1-Wire, cuando existe detección de iButton. En la misma se puede ver la secuenciade lectura de los datos correspondientes al código único de identificación delsensor (“FAMILY”, “ROM CODE” y “CRC”). Al comienzo de la comunicaciónel microcontrolador envía el byte de “RESET”, que corresponde a señal de resetpara señalizar el inicio de la comunicación. Y luego envía el byte de “READ”, quecorresponde al comando que se desea ejecutar sobre el iButton, en este caso, lalectura del “ROM CODE”.

FIGURA 4.4: Medición sobre bus 1-Wire con analizador lógico.


4.3. Ensayo de parámetros eléctricos del equipo AVL

Se realizaron mediciones del consumo de corriente del equipo AVL para dostensiones de alimentación de referencia, 12 V y 24 V. Esto es así, dado que losvehículos (automóviles, camiones, colectivos, etc.) poseen baterías de estos va-lores. El consumo de corriente máximo se determinó en base a tres estados defuncionamiento (con el receptor GNSS activado):

Estado “pasivo”: el equipo no se encuentra realizando reportes de datos aservidor remoto, ni con una llamada de voz en curso. Es el estado de menorconsumo de corriente.

Estado “llamada de voz en curso”: el equipo se encuentra con una llamadade voz en curso. Estado de alto consumo de corriente.

Estado “reporte de datos en curso”: el equipo se encuentra realizando repor-tes de datos a servidor remoto. Estado de alto consumo de corriente.

En la tabla 4.3 se reflejan los valores medidos. De esta forma, se validó que elconsumo del equipo se encuentra por debajo del máximo requerido, de acuerdo atabla 3.1. En la figura 4.5 se observa el banco de mediciones utilizado.

TABLA 4.3: Mediciones de parámetros eléctricos del equipo AVL

EstadoCorriente de consumo máximaTensión 12 V Tensión 24 V

Pasivo 180 mA 90 mALlamada de voz en curso 350 mA 230 mAReporte de datos en curso 330 mA 190 mA

FIGURA 4.5: Banco de mediciones.

4.4. Pruebas de campo 55

4.4. Pruebas de campo

Se realizó una prueba integral del equipo AVL en campo, esto es, instalado enun colectivo de la línea 105 de transporte de pasajeros. El ensayo consistió enverificar la calidad de señal celular y GPS, y la latencia de reporte hacia el servidorde aplicación. El resultado se observa en la figura 4.6, donde se puede ver queexiste una continuidad entre todas las posiciones que se reportaron. Asimismo, elcolor turquesa de las posiciones indica que todos los reportes fueron recibidos conuna latencia menor a diez segundos (diferencia entre horario de datos de paquetede posición y horario de recepción de paquete en servidor de aplicación). Casocontrario, se observarían posiciones en color rojo. Por último, en la figura 4.7 semuestra el equipo instalado en la cabina del colectivo.

FIGURA 4.6: Ensayo sobre recorrido línea de colectivo 105.

FIGURA 4.7: Equipo AVL instalado en colectivo.

57

Capítulo 5

Conclusiones

En este capítulo se analizan los resultados obtenidos, se exponen las conclusionesde cada caso, y se plantean tareas pendientes y el trabajo futuro sobre el equipodesarrollado.

5.1. Conclusiones y resultados

El equipo AVL desarrollado surgió como una oportunidad comercial que, graciasa la aplicación de los conocimientos obtenidos en la Carrera de Especialización enSistemas Embebidos (CESE), fue posible materializar. El equipo logrado cumpliólos requerimientos de la empresa cliente, con vistas de sumar a futuro otrasintegraciones de hardware y de firmware al equipo fabricado.

En lo personal, la experiencia de haber desarrollado en forma íntegra un sistemaembebido, que involucró diseño e implementación tanto de hardware como defirmware, superó ampliamente las expectativas que se fijaron al comienzo de estetrabajo. Respecto a los conocimientos adquiridos en las asignaturas de la carrera ypuestos en práctica, caben destacar los siguientes:

Ingeniería de software: herramientas para el control de versiones del firmwarey documentación del proyecto, conceptos de metodologías ágiles para unarápida validación de los requerimientos, y conocimiento de los patrones dediseño (arquitecturas) de software.

Gestión de proyectos: planificación inicial, seguimiento del grado de avancede los objetivos planteados, y replanificación de acuerdo a esto último. Esimportante disponer de métricas del esfuerzo insumido en realizar las dis-tintas tareas del trabajo, para formular en futuros trabajos predicciones másprecisas.

Testing de software embebido: realización de pruebas unitarias para la vali-dación del firmware desarrollado. Se tomó conciencia de la importancia queposee la etapa de verificación y validación de los requerimientos iniciales.

Programación de microcontroladores: prácticas recomendadas para un ópti-ma escritura del código y reutilizacion del mismo.

Sistemas operativos en tiempo real: adquisición de conocimiento sobre eldesarrollo en este tipo de sistemas, considerando las ventajas que ofrecenpara la escalabilidad del proyecto. El firmware se basó en la utilización deun RTOS (FreeRTOS).

58 Capítulo 5. Conclusiones

Diseño de circuitos impresos para manufacturabilidad: conceptos, recomen-daciones y lineamientos para el diseño de circuitos impresos para su manu-facturabilidad en escala.

5.2. Trabajo futuro

Para promover la comercialización del equipo, naturalmente es necesario continuarrealizando integraciones en el hardware y en el firmware. El nicho de mercadoque abarca la utilización de los equipos AVL se encuentra en constante evolución,y la empresa cliente para la cual se lo desarrolló posee interés en continuar con elvínculo.

En función de lo anterior, y en la medida que se fueron implementando los distintossubsistemas del equipo AVL, se identificaron las siguientes mejoras a incorporarpara una próxima versión:

Redimensionamiento del microcontrolador utilizado: se detectó que el mi-crocontrolador LPC4337JBD144 se encuentra sobredimensionado, tanto encantidad de pines como en capacidad de procesamiento (no es necesario queel microcontrolador posea doble núcleo). La utilización de un microcontrola-dor adecuadamente dimensionado implicaría, en principio, una reducciónde los costos de fabricación asociados.

Modificaciones varias al circuito impreso diseñado: por ejemplo, para laprogramación del microcontrolador, se observó la posibilidad de utilizar unconector que no requiere del conector físico (conector de encastre) montadoen PCB. Es un conector del tipo tag-connect [40], que solo requiere de padsimpresos bajo determinado layout en el PCB.

Diseño y fabricación de gabinete customizado: según la capacidad económicadel proyecto, se evaluará la posibilidad de utilizar un gabinete inyectado amedida.

Ampliación de la capacidad de manejo de eventos del sistema: por ejemplo,integrar la generación de eventos por temporizadores de usuario, o pordefinición de geocercas (puntos de referencia -latitud, longitud y radio deacción-) en las que cuando el vehículo ingresa o egresa de dicha zona, segenera evento.

Ampliación del set de comandos: tanto comandos bajo protocolo SMS comoprotocolo cliente-servidor, para agregar funcionalidades de consulta y/oconfiguración de parámetros del equipo.

Investigar sobre tecnología de comunicación celular 5G: en un futuro nolejano será el estándar predominante de comunicaciones móviles (hoy lo es4G).

Integraciones de hardware/firmware pendientes de evaluación:

• Display color y táctil: para proveer una experiencia de usuario másagradable.

• Batería de litio: para proveer autonomía al equipo en caso de corte decorriente del vehículo.

5.2. Trabajo futuro 59

• CAN bus: comunicación con el vehículo mediante bus bajo dicho proto-colo [41].

• Lector de tarjetas RFID: para proveer otro mecanismo de identificaciónde usuario.

• Procesamiento de imágen: para proveer adquisición y transmisión deimágenes (no video) mediante cámara/s instalada/s en el vehículo.

• Sensores de radiofrecuencia: para integrar sensores varios que operaninalámbricamente (ejemplo, mediante enlaces de 433 MHz).

• Punto de acceso a internet (WiFi): para proveer internet inalámbrica alos pasajeros del vehículo.

• Conectividad Bluetooth: para integrar comunicación con otros disposi-tivos mediante este protocolo.

61

Bibliografía

[1] Wikipedia. Localización automática de vehículos.https://es.wikipedia.org/wiki/Rastreo_vehicular_automatizado.

[2] Wikipedia. International Mobile Subscriber Identity. https://en.wikipedia.org/wiki/International_mobile_subscriber_identity.

[3] EFISAT. Equipo AVL U+ Touch. http://www.efisat.net/U+Touch.html.[4] Laser Argentina. Equipo AVL T-800.

https://www.laserargentina.com.ar/t-800/.[5] NXP Semiconductors. Microcontrolador LPC4337.

https://www.nxp.com/docs/en/data-sheet/LPC435X_3X_2X_1X.pdf.Mar. de 2016.

[6] Quectel. Quectel EC21 IoT/M2M-optimized LTE Cat 1 Module.https://www.quectel.com/UploadFile/Product/Quectel_EC21_LTE_Specification_V1.8.pdf.

[7] Maxim Integrated. Application Note 3808 - What is an iButton device?https://www.maximintegrated.com/en/design/technical-documents/app-notes/3/3808.html. Mayo de 2006.

[8] National Marine Electronics Association. Estándar NMEA 0183.https://www.nmea.org/content/STANDARDS/NMEA_0183_Standard.

[9] ITU-T. V.250: Serial asynchronous automatic dialling and control.https://www.itu.int/rec/T-REC-V.250/en. Jul. de 2003.

[10] 3GPP. 3GPP TS 27.007 - AT command set for User Equipment (UE).https://portal.3gpp.org/desktopmodules/Specifications/SpecificationDetails.aspx?specificationId=1515. Sep. de 2019.

[11] ETSI. ETSI TS 127 000 - AT command set for User Equipment (UE).https://www.etsi.org/deliver/etsi_ts/127000_127099/127007/15.07.00_60/ts_127007v150700p.pdf. Oct. de 2019.

[12] Tanenbaum - Wetherall. Redes de computadoras 5ta edición. Pearson, 2012.[13] Proyecto CIAA. Computadora Industrial Abierta Argentina - EDU-CIAA-NXP.

http://www.proyecto-ciaa.com.ar/devwiki/doku.php?id=desarrollo:edu-ciaa:edu-ciaa-nxp.

[14] Molex. Micro-Fit Connector System. http://bit.ly/2NQOxmqMolexMicroFit.[15] Productos Termoformados. Gabinete estándar CN.

http://www.pro-te.com.ar/PROTE_GABINETE_CN_PLANO.PDF.[16] HM semi. LM2596HV Step-Down Voltage Regulator.

http://hmsemi.com/downfile/LM2596HV.PDF.[17] Eric Pernia. Biblioteca sAPI. https://github.com/epernia/firmware_v3.[18] Analog Devices. Microstrip and stripline design. https:

//www.analog.com/media/en/training-seminars/tutorials/MT-094.pdf.Ene. de 2009.

[19] Lipshits - Vanderkooy. Pulse-Code Modulation - An Overview. https://pdfs.semanticscholar.org/adb4/2181de4cb2f40ab7503d99d87ba582e920d4.pdf.Oct. de 2003.

https://es.wikipedia.org/wiki/Rastreo_vehicular_automatizado

https://en.wikipedia.org/wiki/International_mobile_subscriber_identity

https://en.wikipedia.org/wiki/International_mobile_subscriber_identity

http://www.efisat.net/U+Touch.html

https://www.laserargentina.com.ar/t-800/

https://www.nxp.com/docs/en/data-sheet/LPC435X_3X_2X_1X.pdf

https://www.quectel.com/UploadFile/Product/Quectel_EC21_LTE_Specification_V1.8.pdf

https://www.quectel.com/UploadFile/Product/Quectel_EC21_LTE_Specification_V1.8.pdf

https://www.maximintegrated.com/en/design/technical-documents/app-notes/3/3808.html

https://www.maximintegrated.com/en/design/technical-documents/app-notes/3/3808.html

https://www.nmea.org/content/STANDARDS/NMEA_0183_Standard

https://www.itu.int/rec/T-REC-V.250/en

https://portal.3gpp.org/desktopmodules/Specifications/SpecificationDetails.aspx?specificationId=1515

https://portal.3gpp.org/desktopmodules/Specifications/SpecificationDetails.aspx?specificationId=1515

https://www.etsi.org/deliver/etsi_ts/127000_127099/127007/15.07.00_60/ts_127007v150700p.pdf

https://www.etsi.org/deliver/etsi_ts/127000_127099/127007/15.07.00_60/ts_127007v150700p.pdf

http://www.proyecto-ciaa.com.ar/devwiki/doku.php?id=desarrollo:edu-ciaa:edu-ciaa-nxp

http://www.proyecto-ciaa.com.ar/devwiki/doku.php?id=desarrollo:edu-ciaa:edu-ciaa-nxp

http://bit.ly/2NQOxmqMolexMicroFit

http://www.pro-te.com.ar/PROTE_GABINETE_CN_PLANO.PDF

http://hmsemi.com/downfile/LM2596HV.PDF

https://github.com/epernia/firmware_v3

https://www.analog.com/media/en/training-seminars/tutorials/MT-094.pdf

https://www.analog.com/media/en/training-seminars/tutorials/MT-094.pdf

https://pdfs.semanticscholar.org/adb4/2181de4cb2f40ab7503d99d87ba582e920d4.pdf

https://pdfs.semanticscholar.org/adb4/2181de4cb2f40ab7503d99d87ba582e920d4.pdf

62 Bibliografía

[20] Nuvoton. NAU8814 Mono Audio Codec IC.http://www.nuvoton.com/resource-files/NAU8814DatasheetRev2.9.pdf.

[21] Tontek. One key touch pad detector IC.https://datasheet.lcsc.com/szlcsc/TTP223-BA6_C80757.pdf. Nov. de 2009.

[22] Sitronix. LCD controller/driver.https://www.lcd-module.de/eng/pdf/zubehoer/st7920_chinese.pdf.Oct. de 2002.

[23] Maxim Integrated. Tutorial 1796 - Guide to 1-Wire communication.https://www.maximintegrated.com/en/design/technical-documents/tutorials/1/1796.html. Jun. de 2008.

[24] KiCad. Software para el diseño de circuitos electrónicos. http://kicad-pcb.org/.[25] FreeRTOS - MIT. Sistema operativo en tiempo real. https://www.freertos.org/.[26] NXP Semiconductors. LPCOpen Libraries and Examples.

https://www.nxp.com/pages/design/microcontrollers-developer-resources/lpcopen-libraries-and-examples:LPC-OPEN-LIBRARIES.

[27] Oliver Kraus. Monochrome graphics library for embedded devices.https://github.com/olikraus/u8g2/wiki.

[28] NXP Semiconductors. MCUXpresso Software Development Kit (SDK).https://www.nxp.com/design/software/development-software/mcuxpresso-software-and-tools/mcuxpresso-software-development-kit-sdk:MCUXpresso-SDK.

[29] Segger. Ozone - The J-Link Debugger and Performance Analyzer.https://www.segger.com/products/development-tools/ozone-j-link-debugger/.

[30] GitLab. Servicio web para control de versiones. https://gitlab.com/.[31] Sourcetree. Git GUI for local hosted repositories.

https://www.sourcetreeapp.com/.[32] Trello. Software para el trabajo colaborativo. https://trello.com/.[33] John Gruber. Markdown. https://github.com/adam-p/markdown-

here/wiki/Markdown-Cheatsheet/.[34] Eric Pernia. Modularización en capas.

http://bit.ly/3467FTtModularizacionEnCapas/.[35] Quectel. EC25 EC21 AT Commands Manual V1.0. https://itbrainpower.net/

downloadables/Quectel_EC25_EC21_AT_Commands_Manual_V1.0.pdf.Mayo de 2016.

[36] Quectel. EC2x EG9x EM05 TCP/IP AT Commands Manual V1.0.https://sixfab.com/wp-content/uploads/2018/09/Quectel_EC2xEG9xEM05_TCPIP_AT_Commands_Manual_V1.0.pdf. Nov. de 2017.

[37] Quectel. EC2x EG9x EM05 FTP(S) AT Commands Manual V1.0.https://sixfab.com/wp-content/uploads/2018/09/Quectel_EC2xEG9xEM05_FTPS_AT_Commands_Manual_V1.0.pdf. Nov. de 2017.

[38] NXP Semiconductors. LPC43xx/LPC43Sxx ARM Cortex-M4/M0multi-coremicrocontroller. https://studio.segger.com/packages/LPC4300/CMSIS/Documents/UM10503.pdf. Dic. de 2015.

[39] USAT. Understanding LTE Signal Strength Values.https://usatcorp.com/faqs/understanding-lte-signal-strength-values/.

[40] Tag-Connect. Tag-Connect products. http://www.tag-connect.com/.[41] National Instruments. Introducción a CAN.

https://www.ni.com/es-cr/innovations/white-papers/06/controller-area-network--can--overview.html.

http://www.nuvoton.com/resource-files/NAU8814DatasheetRev2.9.pdf

https://datasheet.lcsc.com/szlcsc/TTP223-BA6_C80757.pdf

https://www.lcd-module.de/eng/pdf/zubehoer/st7920_chinese.pdf

https://www.maximintegrated.com/en/design/technical-documents/tutorials/1/1796.html

https://www.maximintegrated.com/en/design/technical-documents/tutorials/1/1796.html

http://kicad-pcb.org/

https://www.freertos.org/

https://www.nxp.com/pages/design/microcontrollers-developer-resources/lpcopen-libraries-and-examples:LPC-OPEN-LIBRARIES

https://www.nxp.com/pages/design/microcontrollers-developer-resources/lpcopen-libraries-and-examples:LPC-OPEN-LIBRARIES

https://github.com/olikraus/u8g2/wiki

https://www.nxp.com/design/software/development-software/mcuxpresso-software-and-tools/mcuxpresso-software-development-kit-sdk:MCUXpresso-SDK



https://www.segger.com/products/development-tools/ozone-j-link-debugger/

https://www.segger.com/products/development-tools/ozone-j-link-debugger/

https://gitlab.com/

https://www.sourcetreeapp.com/

https://trello.com/

https://github.com/adam-p/markdown-here/wiki/Markdown-Cheatsheet/

https://github.com/adam-p/markdown-here/wiki/Markdown-Cheatsheet/

http://bit.ly/3467FTtModularizacionEnCapas/

https://itbrainpower.net/downloadables/Quectel_EC25_EC21_AT_Commands_Manual_V1.0.pdf

https://itbrainpower.net/downloadables/Quectel_EC25_EC21_AT_Commands_Manual_V1.0.pdf

https://sixfab.com/wp-content/uploads/2018/09/Quectel_EC2xEG9xEM05_TCPIP_AT_Commands_Manual_V1.0.pdf

https://sixfab.com/wp-content/uploads/2018/09/Quectel_EC2xEG9xEM05_TCPIP_AT_Commands_Manual_V1.0.pdf

https://sixfab.com/wp-content/uploads/2018/09/Quectel_EC2xEG9xEM05_FTPS_AT_Commands_Manual_V1.0.pdf

https://sixfab.com/wp-content/uploads/2018/09/Quectel_EC2xEG9xEM05_FTPS_AT_Commands_Manual_V1.0.pdf

https://studio.segger.com/packages/LPC4300/CMSIS/Documents/UM10503.pdf

https://studio.segger.com/packages/LPC4300/CMSIS/Documents/UM10503.pdf

https://usatcorp.com/faqs/understanding-lte-signal-strength-values/

http://www.tag-connect.com/

https://www.ni.com/es-cr/innovations/white-papers/06/controller-area-network--can--overview.html

https://www.ni.com/es-cr/innovations/white-papers/06/controller-area-network--can--overview.html