Sistema de monitoreo y seguimiento

vehicular en redes LTE

Germán González Rozo

Pontificia Universidad Javeriana

Facultad de Ingenierı́a - Maestrı́a en Ingenierı́a del Internet de las Cosas
Bogotá D.C., Colombia
2022
Sistema de monitoreo y seguimiento
vehicular en redes LTE

Germán González Rozo

Trabajo de grado presentado como requisito parcial para optar al tı́tulo de:
Magı́ster o Magistra en Ingenierı́a del Internet de las Cosas

Director(a):
Diego Méndez Chaves, Ph.D

Énfasis de Profundización:
Computación y Analı́tica en IoT
Pontificia Universidad Javeriana
Facultad de Ingenierı́a - Maestrı́a en Ingenierı́a del Internet de las Cosas
Bogotá D.C., Colombia
2022
(Dedicatoria)

”Vive como si fueras a morir mañana... aprende

como si fueras a vivir siempre”

Mahatma Gandhi.
 iv

Resumen

Las empresas de logı́stica con el vertiginoso cambio que ha tenido la situación mundial y
nacional, por cuenta de la Pandemia enfrentan el reto de ser más eficientes y competitivas,
para entregar sus productos en tiempo, reducir costos y en lo posible proveer productos
personalizados a las exigencias de los usuarios finales [1]. De otro lado los proveedores de
redes celulares han comenzado a eliminar gradualmente sus redes 2G y 3G sobre las cuales
están sustentados muchos de los sistemas de localización que utilizan hoy dı́a las empresas
de logı́stica [2]. Un ejemplo de ello es el operador Claro en Colombia, quien ya anuncio el
apagado de sus redes 2G para marzo de 2023 [3].
Por lo anterior en el presente trabajo de grado se propone un sistema de monitoreo y se-
guimiento vehicular empleando las redes LTE, de manera que se puedan identificar opor-
tunamente anomalı́as en el servicio y visualizar oportunidades de reducción de sus costos
operativos.
Palabras clave: Seguimiento vehicular, logı́stica, IoT..

Abstract

Logistics companies with the vertiginous change that the global and national situation has
had, due to the Pandemic, face the challenge of being more efficient and competitive, to
deliver their products on time and reduce costs, and as far as possible provide personalized
products to the demands of end users [1]. On the other hand, cellular network providers
have begun to gradually eliminate their 2G and 3G networks, on which many of the location
systems used today by logistics companies are based [2].
Therefore, in this degree work, a vehicle monitoring, and tracking system is proposed using
LTE networks, so that anomalies in the service can be identified in a timely manner and
opportunities to reduce operating costs.
Keywords: Vehicle tracking, logistics, IoT..
Contenido
Resumen IV

1. Introducción 2
1.1. Objetivos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1.1. Objetivos General . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1.2. Objetivos especı́ficos . . . . . . . . . . . . . . . . . . . . . . . . . . . 2

2. Estado del Arte 4

2.1. Origen de los sistemas de seguimiento vehicular . . . . . . . . . . . . . . . . 4
2.2. Elementos del sistema de seguimiento vehicular . . . . . . . . . . . . . . . . 5
2.3. Impacto del apagado de las redes móviles 2G y nuevas redes LTE . . . . . . 6
2.4. Requerimientos normativos . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
2.5. Innovación en el los sistemas de seguimiento vehicular . . . . . . . . . . . . . 7

3. Sistema 9
3.1. Arquitectura y funcionalidades de la solución . . . . . . . . . . . . . . . . . . 9
3.2. Especificaciones del sistema . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
3.3. Selección de componentes . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11

4. Desarrollos 15
4.1. Consideraciones de diseño . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
4.2. Descripción modelo de datos . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
4.2.1. Estructura de datos almacén . . . . . . . . . . . . . . . . . . . . . . . 19
4.2.2. Estructura de datos conductores . . . . . . . . . . . . . . . . . . . . . 20
4.2.3. Estructura de reportes . . . . . . . . . . . . . . . . . . . . . . . . . . 20
4.2.4. Estructura de datos operadores . . . . . . . . . . . . . . . . . . . . . 20
4.3. Eventos y reportes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
4.4. Reporte en tiempo real . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
4.5. Reporte de Alertas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
4.6. Reportes generales . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
4.7. Estructura de gestión de almacenamiento (Dominio de la nube o “cloud”) . . 25

5. Experimentos y Análisis de Resultados 27

5.1. Ambiento de operación . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
 vi Contenido

5.2. Proceso de pruebas operador . . . . . . . . . . . . . . . . . . . . . . . . . . . 32

5.3. Proceso de pruebas conductor . . . . . . . . . . . . . . . . . . . . . . . . . . 35
5.4. Análisis de madurez tecnológica . . . . . . . . . . . . . . . . . . . . . . . . . 36

6. Conclusiones y Trabajo Futuro 37

6.1. Conclusiones . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
6.2. Trabajos Futuros . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38

Bibliografı́a 39

A. Anexo: Paquetes de Widget utilizados en el proyecto 41

B. Anexo: Arquitectura Flutter 45

B.1. Plataforma Flutter y lenguaje Dart . . . . . . . . . . . . . . . . . . . . . . . 45
B.1.1. ¿Qué es Flutter? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45
B.1.2. Estructura de una aplicación en Flutter . . . . . . . . . . . . . . . . . 46
B.1.3. Manejo de procesos asincrónicos en el lenguaje Dart . . . . . . . . . . 48

C. Anexo: Diagramas de las aplicaciones móvil y Wen 50

Lista de Figuras

2-1. Elementos del sistema de seguimiento vehicular. Imagen realizada por el autor 5
2-2. Opciones de reemplazo de 2G por nuevas tecnologı́as. Imagen realizada por el
autor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
2-3. Soluciones logı́sticas para todo tipo de activos parachoque-parachoque. Fuente. 8

3-1. Arquitectura general de la solución. Imagen realizada por el autor . . . . . . 9

3-2. Plataforma de desarrollo Flutter. Fuente. . . . . . . . . . . . . . . . . . . . . 11
3-3. Arquitectura general de la solución con la plataforma Flutter y lenguaje Dart. 12
3-4. Alternativas de conexión desde la plataforma Flutter a sistemas de almacena-
miento en la nube. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
3-5. Arquitectura general de la solución integrada con Fluter y Firebase, tanto en
el acceso como en core. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13

4-1. Carpetas de la aplicación móvil . . . . . . . . . . . . . . . . . . . . . . . . . 18

4-2. Comunicación Firebase. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26

5-1. Ambiente de operación . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27

5-2. Ambiente de operación con almacenes de cadena . . . . . . . . . . . . . . . . 28
5-3. Menú aplicación móvil conductor . . . . . . . . . . . . . . . . . . . . . . . . 29
5-4. Autorización de permisos y arranque de App móvil. . . . . . . . . . . . . . . 30
5-5. App móvil en operación y restricción de lı́mite de velocidad. . . . . . . . . . 31
5-6. App móvil en operación y restricción de lı́mite de velocidad. . . . . . . . . . 32
5-7. Pantalla operador de acceso al aplicativo de monitoreo. . . . . . . . . . . . . 33
5-8. Menú de gestión del operador. . . . . . . . . . . . . . . . . . . . . . . . . . . 34
5-9. Agregar geocerca. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
5-10.Reporte conductor. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35

B-1. Comunicación de Flutter con la plataforma de SDK . . . . . . . . . . . . . . 46

B-2. Estructura de una aplicación en Flutter por medio de Widgets . . . . . . . . 47
B-3. Estructura de Widgets sin estado [13]. . . . . . . . . . . . . . . . . . . . . . 47
B-4. Estructura de Widgets con estado [13]. . . . . . . . . . . . . . . . . . . . . . 48
B-5. Comparación procesos sincrónico y asincrónicos. Fuente. . . . . . . . . . . . 49
B-6. Flujo de trabajo ası́ncrono Flutter/Dart. Fuente. . . . . . . . . . . . . . . . . 49
Lista de Figuras 1

C-1. Conexión Andina Conductor. . . . . . . . . . . . . . . . . . . . . . . . . . . 51

C-2. Conexión Andina Operador. . . . . . . . . . . . . . . . . . . . . . . . . . . . 52
1. Introducción
Hoy dı́a la industria del transporte logı́stico del transporte de mercancı́as al igual que otras
industrias han sido impactadas por los nuevos requerimientos que ha traı́do la pandemia,
esto es las empresas logı́sticas requieren tener más información de dónde está la carga que
ha solicitado un cliente determinado, cuál es el tiempo de atención para una entrega de
mercancı́a, conocer si se ha tenido o no dificultades en la entrega del producto, ver meca-
nismos de reducir costos por uso eficiente del combustible y hacer seguimiento al tiempo de
conducción de para evitar accidentes.
Por lo anterior las compañı́as de logı́stica hoy dı́a tienen el reto de poder tener una comuni-
cación bidireccional con los conductores de manera tal que se pueda notificar al conductor
que se ha salido de la ruta de trabajo o que el conductor pueda estar reportando información
de las condiciones en las cuales se está prestando el servicio, es decir conocer la velocidad
en la cual se está conduciendo, tener información de la efectividad del uso del combustible
y tener información de la distancia recorrida, ası́ como el tiempo de conducción. Es por ello
por lo que todos estos elementos son servicios adicionales al básico seguimiento vehicular
que se tiene hoy dı́a

1.1. Objetivos

1.1.1. Objetivos General

Diseñar e implementar un sistema de monitoreo y seguimiento vehicular, empleando la red

móvil LTE.

1.1.2. Objetivos especı́ficos

Seleccionar el periférico que permita conocer la información de posicionamiento del

vehı́culo, el módulo de radio LTE, que puedan ser integrados en un sistema embebido.
Diseñar un sistema embebido que permita integrar los módulos seleccionados.
Implementar una plataforma en la nube que permite consolidar, procesar y visualizar
la información proveniente del dispositivo embebido
1.1 Objetivos 3

Validar el funcionamiento modular de cada uno de los componentes del sistema.

Validar el funcionamiento integrado del sistema bajo un caso de uso del transporte
logı́stico.
2. Estado del Arte
Al analizar la situación actual y tendencias entorno a los sistemas de seguimiento vehicular
en el segmento de transporte logı́stico en paı́ses como USA y algunos paı́ses de Europa
como Francia (donde se presentan los mayores avances en cuanto a sistemas de seguimiento
vehicular se refiere), se encuentra que la industria presenta varios retos y oportunidades,
para aprovechar los habilitadores tecnológicos que trae consigo la Industria 4.0, en adición
de algunas tendencias regulatorias entorno a la seguridad en el servicio.
En este contexto se expone a continuación las caracterı́sticas que el presente trabajo pretende
contribuir a los sistemas de seguimiento vehicular en Colombia.

Origen de los sistemas de seguimiento vehicular.

Elementos del sistema de seguimiento vehicular.
Impacto del apagado de las redes móviles 2G y nuevas redes LTE.
Requerimientos normativos con respecto a la operación de los sistemas de gestión
vehicular.
Innovación en el los sistemas de seguimiento vehicular y carros conectados.
ˆ Integración de mecanismos de diagnóstico abordo.
ˆ Control de rutas.
ˆ Optimización de la operación.
ˆ Inclusión de Inteligencia Artificial como asistente digital.

2.1. Origen de los sistemas de seguimiento vehicular

Los sistemas de seguimiento vehicular actuales, tienen sus raı́ces en proyectos de uso militar
en USA [3] y [4] en la década de los años 60 y 70, con la primera tecnologı́a de GPS (Sistema
de Posicionamiento Global (GPS; en inglés, Global Positioning System), Para finales de los
años 90, con la directiva presidencial del presidente Bill Clinton dio apertura a su uso civil y
comercial, y fue justo la administración de flotas, uno de sus primeros usuarios para el control
de sus vehı́culos. En los primeros dı́as del seguimiento de flotas, para realizar un seguimiento
adecuado de una flota, cada vehı́culo tenı́a que estar habilitado con un costoso dispositivo
2.2 Elementos del sistema de seguimiento vehicular 5

GPS. La empresa estaba obligada a pagar una tarifa mensual normalmente alta para utilizar
el sistema de seguimiento por satélite. Aunque útiles, estos primeros sistemas eran difı́ciles
de implementar, costosos de usar y, a veces, inconvenientes tanto para los conductores como
para la gestión de flotas, Internet no era algo que se encontrara en todas las oficinas y si
estaba disponible, los mapas en lı́nea y el software de enrutamiento en vivo no existı́an, todo
tenı́a que ser un proceso fuera de lı́nea y los mapas tenı́an que cargarse manualmente en
cada computadora.
Por lo tanto, tomó varios años para que el concepto se hiciera popular. En los primeros dı́as,
solo las flotas grandes y ricas se aprovecharon de la tecnologı́a. En sus inicios los sistemas
de seguimiento vehicular basados en los GPS, no eran de uso masivo por los costos de los
dispositivos receptores de GPS, y tampoco estaban enlazados a Internet, para enlazarlos
con mapas en lı́nea, y solo en los casos de conexión a través de redes 2G se podı́an enviar
información a través de las redes móviles, con la información básica de posicionamiento
(Latitud y longitud).

2.2. Elementos del sistema de seguimiento vehicular

En la imagen 2-1 se muestra la arquitectura básica de un sistema de seguimiento vehicular.

Figura 2-1.: Elementos del sistema de seguimiento vehicular. Imagen realizada por el autor

En este modelo un receptor de GPS recopila datos de al menos 4 satélites para determinar la
posición precisa. Este proceso llamado trilateración usa la posición de tres o más satélites de
la red del Sistema Global de Navegación por Satélite y su distancia de ellos para determinar
la latitud, la longitud, la elevación y el tiempo. El receptor puede mejorar la precisión de
la posición adicionando información de localización de redes móviles (inicialmente GSM)
al hacer esta tarea al hacer referencia a la información de la torre celular más cercana al
 6 2 Estado del Arte

dispositivo de rastreo GPS. Entre las dos tecnologı́as, los sistemas GPS son capaces de
realizar mediciones de ubicación mucho más precisas, dentro de un metro, mientras que con
la tecnologı́a de seguimiento GSM, el posicionamiento solo se puede determinar dentro de
los 10 metros.

2.3. Impacto del apagado de las redes móviles 2G y

nuevas redes LTE
Con la evolución de la tecnologı́a móvil, la arquitectura presentada previamente se modifica,
para permitir la introducción de nuevas tecnologı́as.

Figura 2-2.: Opciones de reemplazo de 2G por nuevas tecnologı́as. Imagen realizada por el
autor

De la gráfica 2-2 se aprecia como los requisitos de las nuevas aplicaciones señaladas en la
gráfica a la izquierda en color verde, están soportadas sobre las redes LTE para los diferentes
tipos de dispositivos están ampliamente disponibles (Cat 6,4,3,1) y es la clara opción para el
remplazo de las aplicaciones como la de seguimiento y monitoreo vehicular. Esto claramente
vuelve arcaico la redes 2G, sobre las redes LTE 4G [5].

2.4. Requerimientos normativos

Desde el punto de vista normativo tanto la regulación de USA (FMCSA y el Departamento
de Transporte), ası́ como los reguladores europeos, han creado una serie de normativas para
crear un entorno seguro para los conductores comerciales, reducir la fatiga del conductor,
hacer cumplir las reglas de Horas de servicio y minimizar los accidentes de tráfico. En [6] y
[7] su objetivo principal es mejorar la seguridad vial y reducir el número de accidentes
2.5 Innovación en el los sistemas de seguimiento vehicular 7

2.5. Innovación en el los sistemas de seguimiento

vehicular
Con la llegada de las nuevas tecnologı́as de redes móviles y la capacidad de conexión a
Internet, junto con habilitadores tecnológicos como la Inteligencia Artificial, las redes 4G,5G
y el Big Data, se integran nuevas funcionalidades a los sistemas de seguimiento vehicular
tales como:
Integración de mecanismos de diagnóstico abordo.
Control de rutas.
Optimización de la operación.
Inclusión de Inteligencia Artificial como asistente digital.
Las flotas dependen cada vez más de los sistemas a bordo para ejecutar sus operaciones
de manera eficiente, por lo que cualquier cosa que acelere esas comunicaciones podrı́a traer
grandes beneficios. Ası́ es como 5G cambiará las cosas para su flota
Lo anterior se puede ver en [8], donde se indica como las flotas dependen cada vez más de
los sistemas a bordo para ejecutar sus operaciones de manera eficiente, por lo que cualquier
cosa que acelere esas comunicaciones podrı́a traer grandes beneficios. Tales como:
Velocidad: Las redes 4G y 5G disponen de una mayor velocidad, eliminado la po-
sibilidad de demoras en la comunicación y permitiendo la inclusion de aplicaciones
avanzadas de IA (inteligencia artificial) y análisis de video, lo que mejorará significa-
tivamente el mantenimiento predictivo y prescriptivo del vehı́culo y la seguridad del
conductor en la carretera.
Registro de instantáneo de cambios de rutas, permitiendo el apoyo a los conductors de
manera inmediata, para su protección y el de al carga.
Capacidad de comunicación en doble via, ası́ como llamadas automáticas que alertan
a las autoridades en caso de accidente.
Capacidades avanzadas de autoconducción o autoestacionamiento.
Una flota más segura no solo protege a los empleados, los activos y la carga a bordo,
sino que también mejora la vida útil del vehı́culo, el tiempo de actividad de la flota, el
control de costos y la experiencia general del cliente con actualizaciones instantáneas.
Se destaca en [9] la importancia de incorporar inteligencia en los equipos de abordo de los
vehı́culos, como la integración de habilidades automotrices de Alexa para vehı́culos conecta-
dos mediante las interfaces de hogar inteligente y Alexa.Automotive. Con lo anterior se abre
un abanico de servicios que se pueden incorporar ea los teléfonos inteligentes y conectarlos
por a los sistemas del vehı́culo.
 8 2 Estado del Arte

Adicionalmente se abre la posibilidad a tener un monitoreo enriquecido del sistema, no solo

del vehı́culo, sino también de la carga.

Figura 2-3.: Soluciones logı́sticas para todo tipo de activos parachoque-parachoque. Fuente.
3. Sistema

En este capı́tulo se hace una descripción del Sistema de monitoreo y seguimiento vehicular,
indicando las especificaciones y los criterios de selección de los componentes.

3.1. Arquitectura y funcionalidades de la solución

Figura 3-1.: Arquitectura general de la solución. Imagen realizada por el autor

La figura 3-1 muestra la arquitectura general de la solución. En esta arquitectura se identi-

fican tres dominios:
El dominio del conductor el dominio.
El dominio del operador
En el centro se aprecia el dominio de la nube o “cloud”.
En el dominio del conductor se identifica el dispositivo LTE. Este dispositivo LTE debe tener
la capacidad de comunicarse con el dominio “cloud” y con el dominio del operador para poder
enviar la información de localización del dispositivo en todo momento (a través de la red
LTE), además este en este dominio del conductor se encuentra la interfaz del conductor el
conductor. que como se destaca en el capı́tulo de Estado del arte, debe tener la capacidad
de entrar datos al dispositivo con su identificación con lo cual el dispositivo debe tener una
 10 3 Sistema

pantalla y un teclado para poder ingresar los datos de identificación y la identificación de

la placa del vehı́culo, además debe tener el dispositivo mecanismos para poderle notificar al
conductor por los eventos que está sucediendo en el vehı́culo, como excesos de velocidad o
notificaciones para cuando el conductor se sale del área designada de operación.
De otro lado, en la figura 3-1 se identifica el dominio del operador, y es en este dominio del
operador donde está el sistema de monitoreo y seguimiento vehicular. El operador ingresa
a este sistema a través de un navegador, el cual debe proveer la visibilidad de lo que está
pasando con los vehı́culos, es decir poder identificar dónde está el vehı́culo y las condiciones en
las que se está prestando el vehı́culo como: localización, velocidad, consumo de combustible,
tiempos de inicio y finalización de ruta, distancias recorridas y alertas por paradas de los
vehı́culos (carga/descarga/descanso de los conductores) y salidas de los vehı́culos del área
de operación definida.
En la mitad de la figura 3-1 se encuentra la plataforma de nube o “cloud” allı́ en esta plata-
forma de cloud está la lógica de la operación para poder manejar las transacciones recibidas
por el dispositivo LTE y también para poder realizar los procesos de almacenamiento en el
cloud, todo este proceso ocurre sobre la internet.

3.2. Especificaciones del sistema

Las especificaciones del sistema de monitoreo vehicular deben tener en cuenta los siguientes
aspectos identificados en la etapa de Estado de arte, estos son:

Debe ser una solución que permita operar a través de la red LTE.
Se debe poder centralizar la información en una base de datos.
La solución debe tener la capacidad de poderse visualizar a través de un navegador
por parte de los operadores.
La solución debe tener la capacidad debe tener la capacidad de poder identificarse ante
el sistema con usuario y password a los conductores.
Se debe poder ingresar los datos de placa del vehı́culo en el dispositivo móvil LTE.
El dispositivo móvil debe tener la capacidad de almacenar localmente el estado de
la comunicación, es decir debe tener la posibilidad de almacenar la identificación del
usuario que está en operación de manera tal que si se apaga el dispositivo o agota su
energı́a, se mantenga la configuración una vez se restablece el dispositivo móvil.
El dispositivo LTE debe poder tener la capacidad de alertar al conductor en los eventos
donde tiene exceso de velocidad y en los eventos cuando se sale de las áreas de operación
o geocercas definidas para su operación.
3.3 Selección de componentes 11

El dispositivo debe tener la capacidad de integrar un GPS de manera tal que se tenga
la ubicación geográfica del vehı́culo.
La plataforma central web para el monitoreo de la solución, debe ser una plataforma
escalable que pueda comenzar con un número reducido de vehı́culos, es decir decenas
de vehı́culos y poder crecer a centenas de vehı́culos y poder llegar a miles de vehı́culos.
En otras palabras, crecer por demanda o decrecer de manera controlada.

3.3. Selección de componentes

Teniendo en cuenta las especificaciones del numeral anterior, a continuación se indican los
criterios de selección para cada uno de los elementos de la solución.
Lo primero para definir fue la selección del dispositivo LTE y para ello tomando como
referencia al estado del arte está claro que el dispositivo de LTE es un dispositivo integrado,
es decir un un dispositivo que tenga teclado, que tenga pantalla e incorpore un GPS y que
pueda incorporar inclusive parlantes para poder enviar mensajes, por lo cual y teniendo en
cuenta lo que se tienen en las diferentes lideres del mercado se selecciona un dispositivo móvil
celular para que haga esta función.
A continuación la pregunta está por la selección de la plataforma de desarrollo, tanto para
el dispositivo LTE en este caso para el dispositivo celular o para la plataforma central. por
lo cual se seleccionó la plataforma de Google llamada Flutter y desarrollo de código con el
lenguaje de programación Dart, la cual permite como se muestra en la figura 2 desarrollar
código para plataformas móviles, para plataformas web. para plataformas de escritorio y para
sistemas embebidos. Haciendo de esta manera que sea más fluido y reutilizable las rutinas
que se trabajen en esta plataforma de desarrollo Flutter.

Figura 3-2.: Plataforma de desarrollo Flutter. Fuente.

 12 3 Sistema

Esta selección de plataforma desarrollo para el proyecto es fundamental, ya que no va a

depender del tipo de dispositivo que se tenga en el vehı́culo, es decir que se tenga un dispo-
sitivo móvil ya sea con sistema operativo Android o con sistema iOS o que eventualmente se
disponga de un dispositivo con una Raspberry Pi ya que la misma plataforma de desarrollo
permite generar código para dispositivos que se creen a la medida donde se puedan incor-
porar mediciones adicionales de parámetros, punto este clave en la industria de logı́stica ya
que para los proyectos básicos y de arranque podemos utilizar un dispositivo móvil pero en
la medida en que hagamos los procesos de logı́stica más elaborados podrı́amos incorporar
sobre la misma plataforma de desarrollo de Flutter nuevas variables o mejor el monitoreo de
más variables sobre el vehı́culo haciendo más más poderoso lo que se haga en arranque y se
pueda crecer a futuro. Lo mismo sucede para la parte del core en el Cloud, ya que la plata-
forma Flutter (Con el lenguaje DART) se puede implementar en alguna de las plataformas
disponibles de cloud del mercado como las de Google Amazon o Microsoft Azure, de manera
tal que se pueda aprovechar las bondades de estas plataformas para hacer un sistema de
escalable y poder soportar miles y decenas de miles de usuarios de manera simultáneamente.
La siguiente figura 3 muestra ya la arquitectura con la plataforma Flutter y los desarrollos
hechos sobre lenguaje Dart para el dispositivo móvil y para la plataforma de cloud
Cabe señalar que algunas de las rutinas o programas que se realizan para el dispositivo móvil
se pueden reutilizar para la plataforma cloud, haciendo que sea más rápido el desarrollo y
la depuración de errores de la solución y siendo más consistente al tener un solo lenguaje de
programación, en este caso el lenguaje Dart.

Figura 3-3.: Arquitectura general de la solución con la plataforma Flutter y lenguaje Dart.

Finalmente se tiene la selección de la plataforma almacenamiento en la nube, para ello se

ha seleccionado la plataforma Firebase la cual es una plataforma de estilo no SQL, donde se
permite el almacenamiento de volúmenes de información escalables (comenzando con datos
de cientos de vehı́culos, hasta el manejo de decenas de vehı́culos), manejando la estructura
de clave valor, adecuada para la aplicación de localización y que permite para este tipo de
3.3 Selección de componentes 13

proyectos poder responder de manera ágil a los requerimientos de los dispositivos móviles.
Esta plataforma Firebase está diseñada para recibir comunicaciones en tiempo real como
las comunicaciones que tenemos en este proyecto de localización de vehı́culos y cambios de
estado en segundos, haciendo que sea una solución escalable y con un tiempo de respuesta
adecuado para la aplicación móvil que tenemos en curso.
En la siguiente figura 3-4 se muestran algunas de las alternativas que se tienen de plataformas
de almacenamiento de backend. Se destaca que la plataforma de desarrollo Flutter dispone
de APIs para la plataforma Firebase de manera nativa, por lo cual se reduce la complejidad
de la integración con el sistema flutter, además por el soporte a largo plazo que tiene su
fabricante Google, el cual provee respaldo de la selección realizada.

Figura 3-4.: Alternativas de conexión desde la plataforma Flutter a sistemas de almacena-

miento en la nube.

Figura 3-5.: Arquitectura general de la solución integrada con Fluter y Firebase, tanto en
el acceso como en core.

La figura 3-5 muestra a la arquitectura general de la solución utilizando para ello la plata-
forma de flutter, el lenguaje Dart y la plataforma de almacenamiento Firebase tanto en el
core, como en el acceso. En esta arquitectura se identifican las diferentes funcionalidades que
se tienen en la solución. En el dispositivo IoT se tienen los diferentes módulos de interfaz de
conductor, la lógica de dispositivo y los módulos para las comunicaciones en lı́nea.
 14 3 Sistema

De otro lado en la plataforma de core se tiene la capacidad de almacenamiento a través

de la plataforma Firebase para el manejo de la base de datos y la autentificación. Cabe
señalar que la plataforma Firebase también ofrece el hosting, haciendo que la solución sea
una solución escalable sobre la plataforma de Google. Finalmente se aprecia la interface del
administrador, donde en esta interface del administrador se tiene la capacidad de poder vi-
sualizar los diferentes reportes del vehı́culo y el manejo de conductor listado de conductores
como también se identifica la capacidad de manejo de manejo y definición de geo cercas, la
capacidad de editar la información de conductores y vehı́culos. Una de las secciones de la
Interfaz de monitoreo es el Dashboard en lı́nea, de manera tal que se pueda sobre un mapa
ver la localización del vehı́culo
4. Desarrollos

En el presente capitulo se describe la solución realizada, incluyendo los criterios de diseño y

algoritmos diseñados para resolver la problemática del presente proyecto de seguimiento y
monitoreo vehicular. Los desarrollos se han realizado considerando una aplicación de logı́stica
para la entrega de productos de 3 almacenes de cadena ubicados en la ciudad de Bogotá.

4.1. Consideraciones de diseño

Como se indicó en el capı́tulo de 3, la plataforma de desarrollo escogida es Flutter, la cual
es un software de código abierto, y sobre la cual se tienen las siguientes consideraciones de
diseño, para atender la problemática de la solución de Seguimiento móvil vehicular.

*Se hace uso de una sola plataforma de desarrollo de software (Flutter de Google), de
manera tal que genere código para los conductores con dispositivos móviles Android y
IOS, como también para que genere el código de la solución Web para hacer lo procesos
de monitoreo por parte de los operadores.
La arquitectura de Flutter se basa en widgets, sin estado y con estado como se explica
en el anexo 1, de manera tal que en las situaciones donde se requiera un cambio de
estado, se reconstruye solo widget que tiene el cambio, comparando con una descripción
anterior para identificar los puntos que deben actualizarse/cambiarse. Ejemplos de
estos Widget con estado, son los de actualización de posición, geográfica, velocidad y
distancia recorrida instantáneas.
Dentro de esta categorı́a, también se encuentran los Streams que se establecen con
Firebase para hacer la grabación en tiempo real de la información del dispositivo móvil
El desarrollo de la solución se ha realizado siguiendo la practica por trabajo por com-
ponentes de negocio o BLoC (Business Logic Components) por sus siglas en inglés, de
manera que se ha utilizado el mismo código de forma independiente en la aplicación
web y la aplicación móvil. De esta manera se simplifica el desarrollo y se simplifican
las pruebas del software.
Dado que la estructura central en el desarrollo de Flutter son los Widgets, se han
tenido las siguientes consideraciones
 16 4 Desarrollos

Se ha unificado el manejo de los nombres de las variables

ˆ Las constantes, variables, parámetros y parámetros con nombre deben etiquetarse
en lowerCamelCase.
ˆ Las clases, tipos, nombres de extensión y enumeraciones deben escribirse en Up-
perCamelCase.
Se ha procurado el manejo de widgets y la utilización de sus estados para que solo se
reconstruye la parte de la interfaz de usuario que debe actualizarse.
La navegación y el enrutamiento son aspectos en la aplicación móvil de seguimiento
móvil, se ha realizado de manera tal que sea fácil para el conductor, como para el
operador la navegación en la aplicación.
Por lo anterior la Navegación es estática usando RouteMap, con un mapa con claves
de cadena para identificar métodos, como se ilustra a continuación para la aplicación
móvil.
routes: {

"home" : (BuildContext context) => HomePage(),

"login" : (BuildContext context) => LoginPage(),

"register/conductor" : (BuildContext context) => RegisterConductorPage(),

"register/operador" : (BuildContext context) => RegisterOperadorPage(),

"portal/conductor" : (BuildContext context) => ConductorPortalPage(),

"portal/operador" : (BuildContext context) => OperadorPortalPage(),

Las aplicaciones están organizadas en una modelo–vista-controlador, donde se ha bus-

cado independizar la parte de la presentación, la lógica del negocio y del almacena-
miento de la información.
Es por ello por lo que esta solución es altamente escalable dado que la información de
base de datos está centralizada y se puede realizar una arquitectura escalable donde
la página de home la página de home Page puede escalar en diferentes servidores si se
requiere. Por lo anterior entonces hay 6 áreas identificadas básicas que son:
ˆ La página de home: donde encontramos la página del controlador y la página del
4.1 Consideraciones de diseño 17

home page.
ˆ La página de login: donde encontramos la página del controlador y la página del
login o Las páginas de los portales: donde encontramos dos portales, un portal
para el conductor y otro portal para el operador.
ˆ La parte de registro, donde tenemos independiente también la parte del registro
del conductor y la parte de registro del operador
ˆ El área para los modelos de datos es decir los modelos de datos para: el almacén,
el conductor, del operador y los reportes que estamos haciendo.
ˆ El área donde se tienen las aplicaciones para hacer las definiciones de conexiones
a las bases de datos en este caso la base de datos de Firebase donde de un lado
tenemos la parte de autentificación de los usuarios de otro lado está todos los
procesos de consulta y grabación para conductor y todos los procesos de consulta
y grabación para el operador y Finalmente en todos los procesos que tienen que
ver con el intercambio de información con la base de datos y dos carpetas para lo
que son utilidades y lo que son los widgets
La estructura de carpetas para la aplicación se presenta a continuación, donde se ha
buscado claridad, y en especial para hacer depuración y seguimiento a la lógica del
negocio. Las carpetas de programas están organizadas por caracterı́sticas comunes y
sus funciones.
En el Anexo C se encuentra el diagrama de las aplicaciones, tanto para el conductor,
como para el operador.
 18 4 Desarrollos

Figura 4-1.: Carpetas de la aplicación móvil

Para mejorar el rendimiento cargan los elementos a demanda

La aplicación cuenta con un sistema de autenticación de usuarios, de manera que
están independientes las páginas que pueden trabajar conductores y operadores, es
decir están organizadas por perfiles.

Las anteriores consideraciones de diseño se realizaron de acuerdo con las recomendaciones

4.2 Descripción modelo de datos 19

de Flutter de: Fuente.

4.2. Descripción modelo de datos

A continuación, se describe el modelo de datos del presente proyecto El modelo de datos

en esta solución de seguimiento móvil comparte un modelo de datos común tanto para el
dispositivo móvil, para la aplicación de visualización y la consolidación de la base de datos
Firebase en la nube. En ello encontramos cuatro fuentes de datos comunes:

La estructura de los almacenes de cadena para la distribución de la mercancı́a, llamada

estructura: almacén.
La estructura de datos de los conductores de la empresa de logı́stica: llamada estruc-
tura: conductor.
La estructura de reportes de actividades del móvil, en el proceso diario de entrega de
mercancı́a: llamada estructura: reporte.
La estructura de datos para los operadores encargados del monitoreo y el seguimiento,
llamada estructura: operador.

A continuación, se describen los campos en cada una de estas estructuras de datos.

4.2.1. Estructura de datos almacén

Almacen({
this.nombreAlmacen,
this.almacenLatitud,
this.almacenLongitud,
this.almacenRadio,
});

Con esta estructura de datos para el almacén se busca conocer el nombre del almacén, su
ubicación geográfica tanto de coordenadas de latitud y longitud y el radio de cobertura para
el área de venta de productos. Este radio de cobertura va a definir la geocercas, es decir el
área de trabajo de cada uno de los conductores, la idea es identificar si el conductor está
dentro o fuera del área de cobertura.
 20 4 Desarrollos

4.2.2. Estructura de datos conductores

Conductor({
this.id,
this.username,
this.email,
this.password,
this.placa,
this.nombreAlmacen,
});

Con esta estructura de datos para los conductores se busca identificar al conductor con un
número de identificación interna (id) para la aplicación, un nombre de usuario un correo
electrónico, un password, la placa del vehı́culo que conduce y el nombre del almacén al cual
está adscrito de manera tal que se pueda monitorear la geocerca definida para dicho almacén.

4.2.3. Estructura de reportes

Reporte({
this.idConductor,
this.nombreConductor,
this.numeroReporte,
this.numeroPlaca,
this.horaEvento,
this.posicionLatitud,
this.posicionLongitud,
this.evento,
this.descripcion,
});

Con esta con esta estructura de datos para los reportes, se busca identificar cada una de los
eventos por los cuales se puede monitorear a los conductores.

4.2.4. Estructura de datos operadores

Operador({
this.id,
this.username,
this.email,
4.3 Eventos y reportes 21

this.password,
});

Con esta estructura para los operadores se busca tener control de las personas que pueden
hacer el monitoreo de los vehı́culos, considerando que en la solución se pueden tener varias
personas y en varios turnos de trabajo. En este contexto cada operador tiene su nombre,
password, correo electrónico y su identificación interna en la aplicación.

4.3. Eventos y reportes

A continuación, se muestran los eventos y registros que se tienen a nivel de la aplicación móvil
para el conductor y los reportes que se tienen para los operadores en el en el seguimiento y
monitoreo de los conductores.

Registros en tiempo real.

ˆ Reporte Instantáneo de Velocidad por segundo
ˆ Reporte Instantáneo de Distancia recorrida por segundo
ˆ Reporte localización instantánea
Reporte de Alertas.
ˆ Reporte de abandonos de una Geo-cerca.
ˆ Reporte de excesos de velocidad.
Reportes generales.
ˆ Registro hora nuevo dı́a.
ˆ Registro hora fin de dı́a.
ˆ Registro kilometraje recorrido en el dı́a.
ˆ Registro horas de trabajo.
ˆ Promedio de eficiencia de combustible del dı́a.

4.4. Reporte en tiempo real

El reporte en tiempo real está dirigido hacia el conductor del vehı́culo la idea es que el
conductor pueda visualizar la velocidad a la cual está circulando por la ciudad, la distancia
recorrida en cada trayecto y la localización geográfica de su vehı́culo.
 22 4 Desarrollos

Reporte Instantáneo de Velocidad por segundo

Reporte Instantáneo de Distancia recorrida por segundo
Reporte localización instantánea

Para lograr estos reportes en tiempo real se hace uso de los complementos disponibles para
Flutter tales como:

Google Maps para Flutter (google maps flutter): Google Maps para Flutter, el que
permite obtener la información geográfica de manera del dispositivo móvil y poder
visualizarla sobre un mapa.
Complemento de geolocalización de Flutter (geolocalizador): permite conocer la últi-
ma ubicación conocida, la ubicación actual del dispositivo y puede lograr tener las
actualizaciones de ubicación continuas.
Complemento de ubicación Flutter(location): el cual se obtiene la información de ubi-
cación del GPS.

Cabe señalar que estas utilidades o complementos de Flutter trabajan con las funcionalidades
del sistema operativo para Android o para iOS, en el caso del presente proyecto se han
utilizado dispositivos Android y se puede apreciar la tabla de precisión para cada dispositivo
en el anexo número 1. Para la plataforma Android se tiene una precisión está en alrededor
de 100 metros,
La información de localización, distancia recorrida y velocidad, se registras en tiempo real,
en la base datos de Firebase, con los siguientes datos:

ID usuario.
Placa.
Hora.
Posición.
Evento: posición.
Descripción: velocidad y distancia recorrida.

Esta información se puede visualizar por parte de los operadores de la aplicación en el centro
de seguimiento vehicular.

4.5. Reporte de Alertas

Los reportes de alertas de abandono de una geocerca o los excesos de velocidad que pueda
presentar el conductor están dirigidos para informar al conductor de esta situación, donde
4.5 Reporte de Alertas 23

se está excediendo una velocidad de la ciudad (en este caso 50 km/h para la ciudad de
Bogotá) o para cuando se identifica que se ha abandonado el área de operación alrededor de
los almacenes de cadena.

Reporte de abandonos de una Geo-cerca.

Reporte de excesos de velocidad.

Estos mismos reportes se tienen en el centro de monitoreo y seguimiento por parte de los
operadores a quienes les llega la información de estos abandonos de geocercas o excesos de
velocidad por parte de los conductores.
La forma cómo operan estos reportes es como sigue:
Para el caso de abandonos de geocerca: cada dı́a el conductor descarga la geo cerca asignada
de acuerdo con su área de operación asignada, esto es el radio de cobertura desde el almacén
de cadena en cı́rculo alrededor del almacén, por lo cual entonces se tiene en el dispositivo
móvil una aplicación que está monitoreando sı́ el móvil está dentro o fuera del área de
cobertura alrededor del almacén. Al presentarse un abandono del área de trabajo geocerca,
entonces se tiene la notificación al conductor y el envı́o de esta del registro del reporte de
abandono al centro de seguimiento para que sea visualizada por el operador.
Para el reporte de alerta por exceso de velocidad la aplicación en el dispositivo móvil está
monitoreando permanentemente la velocidad del móvil y evalúa en el momento en que el
conductor supera el lı́mite de velocidad de la ciudad de Bogotá que es de 50 km, cuando
esta situación sucede entonces el móvil envı́a aplicación en el dispositivo móvil reporte a la
central de monitoreo de manera tal que queda registrada ese exceso de velocidad
La información de alertas se registra en tiempo real, en la base datos de Firebase, con los
siguientes datos:
Reporte de abandonos de una Geo-cerca

ID usuario.
Placa.
Hora.
Posición.
Evento: Cruce geocerca.
Descripción: Entra geocerca o sale geocerca.

Reporte de excesos de velocidad

ID usuario.
Placa.
 24 4 Desarrollos

Hora.
Posición.
Evento: exceso de velocidad.
Descripción: velocidad registrada.

4.6. Reportes generales

Los reportes generales son:

Registro hora nuevo dı́a.

Registro hora fin de dı́a.
Registro kilometraje recorrido en el dı́a.
Registro horas de trabajo.
Promedio de eficiencia de combustible del dı́a.

En lı́nea con la legislación norteamericana y europea que se vio en la sección del Estado del
arte la aplicación tiene la capacidad de generar una serie de reportes de tipo general esto es:
La aplicación registra cada nuevo dı́a la hora cuando comienza el conductor a conducir el
vehı́culo y la hora cuando termina de conducirlo de manera tal que se puede registrar la
distancia recorrida por el vehı́culo durante el dı́a y también las horas que ha laborado, esto
es importante ya que se lleva un registro de cuánto tiempo labora el conductor y que no se
vayan a presentar excesos que puedan afectar la salud del conductor y por ende la seguridad
de la persona y de las personas donde se mueve el vehı́culo.
De otro lado la aplicación tiene la capacidad de llevar el registro de las diferentes recargas
de combustible que hace el conductor de manera tal que al final del dı́a se pueda tener un
registro de la eficiencia de combustible

Registro hora nuevo dı́a.

Registro hora fin de dı́a.
Registro kilometraje recorrido en el dı́a.
Registro horas de trabajo.
Promedio de eficiencia de combustible del dı́a.

La información de reportes generales se registra al inicio y fin del dı́a en la base datos de
Firebase, con los siguientes datos:
Registro de apertura y cierre de ruta
4.7 Estructura de gestión de almacenamiento (Dominio de la nube o
“cloud”) 25

ID usuario.
Placa.
Hora.
Posición.
Evento: “operacionDia”.
Descripción: “iniciaDia”, “cierreDia”.

Reporte horas laboradas

ID usuario.
Placa.
Hora.
Posición.
Evento: horas trabajo.
Descripción: Horas en conducción.

Registro kilómetros en el dı́a

ID usuario.
Placa.
Hora.
Posición.
Evento: distancia recorrida en el dı́a.
descripción: valor distancia recorrida.

4.7. Estructura de gestión de almacenamiento (Dominio

de la nube o “cloud”)
Firebase es la plataforma en la nube de Google empleada en el presente proyecto y que ha
permitido desarrollar rápidamente la solución Lo anterior, gracias a su base de datos NoSQL
en la nube, proporcionando una base de datos en tiempo real, permitiendo ser consultada
por conductores y operadores en tiempo real. Para el proyecto se utilizan los mecanismos
de autenticación robusta de Firebase, lo que ha permitido desarrollar la aplicación más
rápido la solución y con los niveles de seguridad de Google. El presente proyecto ha utilizado
las bibliotecas de Firebase (Descritos en el anexo A), permitiendo aprovechar la seguridad
 26 4 Desarrollos

integrada, el alojamiento de archivos estáticos, creación de reglas de búsqueda para los

reportes de manera segura. Entre las librerı́as de Firebase utilizadas, se tienen:

firebase core: este paquete de widget de Firebase Core básicamente lo que nos permite
es establecer la conexión con la base de datos, es decir hacer la inicialización de la
conexión entre la aplicación cliente ya sea en el móvil o en el en la web.
cloud firestore: este paquete the cloud Store básicamente lo que nos permite es man-
tener las conexiones entre los clientes y la base de datos y permite que eventualmente
se tengan operaciones fuera de lı́nea, de manera tal que en el momento que haya co-
nectividad se hace la sincronización de los datos.
firebase app check: este paquete de firebase check es una nueva funcionalidad de segu-
ridad que tiene la base de datos de manera tal que se puedan autenticar las conexiones
entre la base de datos y el servidor o entre la base de datos y los clientes esta es una
protección que utiliza servidores de recaptcha.

Dada la estructura del proyecto de seguimiento vehicular, el uso de una base de datos NoSQL,
permite una fácil integración entre las aplicaciones desarrolladas y la base de datos Firebase,
ya que esta es como un gran objeto JSON donde puede almacenar la combinación de pares
clave/valor, descrita en los modelo de datos en el presente proyecto.

Figura 4-2.: Comunicación Firebase.

Las comunicaciones de Firebase se hacen por http sobre TCP. Las operaciones se desde
las aplicaciones en el móvil, como en la Web, se hacen empleando APIs, las cuales utilizan
RESTful y gRPC. Las aplicaciones cliente utilizan utiliza Servicio: firestore.googleapis.com,
para acceder al API de almacenamiento en la nube. Esto es acceder a la base de datos
de documentos NoSQL creados para escalado automático, alto rendimiento y facilidad de
desarrollo de aplicaciones.
5. Experimentos y Análisis de Resultados
Para el desarrollo de los experimentos, pruebas y análisis de resultados, se tomo como caso
de aplicación en logı́stica, la distribución de productos en la ciudad de Bogotá, para los
almacenes de cadena.

5.1. Ambiento de operación

Se tomaron un conjunto de 5 Almacenes de cadena en Bogotá, como se muestra en la figura
a continuación:

Figura 5-1.: Ambiente de operación

Se procedió entonces realizar las pruebas de Inicio de ruta, entrega de productos en diferentes
casas, y cierre de ruta. Registrando para cada caso, la localización, velocidad, distancia
recorrida, consumo de combustible, ası́ como registrando las situaciones de salidas de las
áreas de operación o geocercas.
Las coordinadas de los almacenes de las pruebas fueron:

Almacenes de cadena a evaluar Coordenadas

Almacén de cadena La Felicidad @4.6525239,-74.2592525
Almacén de cadena Salitre Plaza @4.6533045,-74.175514
 28 5 Experimentos y Análisis de Resultados

Almacén de cadena Gran Estación @4.6482999,-74.1673923

Almacén de cadena Quirinal @4.6542241,-74.1525972
Almacén de cadena Norte @4.7545109,-74.1763186

Se fueron registrando para cada sitio, la localización, velocidad, distancia recorrida, consumo
de combustible, ası́ como registrando las situaciones de salidas de las áreas de operación o
geocercas y excesos de velocidad

Figura 5-2.: Ambiente de operación con almacenes de cadena

En este proceso se identificaron los diferentes pasos para la operación de la aplicación, esto
es:

Registro del usuario en la aplicación.

Acceso del usuario en la aplicación.
Aprobación del usuario para utilizar el GPS.
Inicio de dı́a en la aplicación.
Inicio de la ruta.

continuación, se indican los diferentes pantallazos del proceso del conductor.

5.1 Ambiento de operación 29

Figura 5-3.: Menú aplicación móvil conductor

 30 5 Experimentos y Análisis de Resultados

Figura 5-4.: Autorización de permisos y arranque de App móvil.

Una vez el conductor está haciendo el recorrido en torno al almacén de cadena entonces se
registra la velocidad de operación del vehı́culo la distancia recorrida y el posicionamiento
geográfico del mismo sobre el mapa en el celular.
5.1 Ambiento de operación 31

Figura 5-5.: App móvil en operación y restricción de lı́mite de velocidad.

 32 5 Experimentos y Análisis de Resultados

Figura 5-6.: App móvil en operación y restricción de lı́mite de velocidad.

Durante el trayecto también el conductor del vehı́culo que está haciendo el recorrido para
alguna vı́a eleva levemente la velocidad, superando el lı́mite de velocidad arriba de 30 km/h
(Figura 5-5) y sale el área de cobertura (Figura 5-6).

5.2. Proceso de pruebas operador

Para las pruebas del operador se registra entonces el proceso desde:

El registro del operador en la plataforma

Acceso del operador en la plataforma
Entrada del operador al portal de gestión y monitoreo

Una vez en el portal de gestión el operador puede:

5.2 Proceso de pruebas operador 33

Figura 5-7.: Pantalla operador de acceso al aplicativo de monitoreo.

 34 5 Experimentos y Análisis de Resultados

Figura 5-8.: Menú de gestión del operador.

Definir una nueva cerca o hacer alguna modificación a las geocercas existentes para los
almacenes de cadena (Figura 5-9).
El operador puede ir a la parte de gestión (Configuración) de conductores, para hacer
la modificación de parámetros de perfil de los conductores como: nombre, correo, placa
de vehı́culo y almacén que está operando (Figura 5-10).
El operador puede acceder a los registros de reportes de los conductores, donde puede
visualizar en lı́nea la velocidad del conductor, la localización y la distancia recorrida
por el mismo.
El operador puede ver allı́ también el registro de eficiencia de gasolina de cada vehı́cu-
lo medida como Combustible consumido entre cargas de combustible y la distancia
recorrida por el vehı́culo
5.3 Proceso de pruebas conductor 35

Figura 5-9.: Agregar geocerca.

Figura 5-10.: Reporte conductor.

5.3. Proceso de pruebas conductor

Para las pruebas del conductor se ubicó el vehı́culo en cada uno de los locales del de cadena,
descritos en la imagen del numeral anterior, la idea es realizar el recorrido con un vehı́culo
partiendo del Almacén de cadena y haciendo un giro en torno a la geocerca definida de ope-
ración, y a continuación se fue monitoreando a continuación la velocidad versus la velocidad
del vehı́culo y distancia recorrida.
 36 5 Experimentos y Análisis de Resultados

5.4. Análisis de madurez tecnológica

Con la finalidad de establecer el alcance de las actividades asociadas a la Investigación, el
Desarrollo tecnológico y la Innovación (I+D+i), el departamento administrativo de ciencia,
tecnologı́a e Innovación, conocido como Colciencia, presenta un documento para la identifi-
cación del nivel de madurez tecnológica o TRL por sus siglas en ingles (Technology Readiness
Level) donde se describe las caracterı́sticas de cada grupo asociado a un producto resultante
[10].
Al finalizar el desarrollo y pruebas del sistema se considera que el proyecto está clasificado
en el grupo TRL5 debido a que en la fase de pruebas estas fueron realizadas en un entorno
similar al real, pero se deben realizar pruebas adicionales para que este con un nivel de
madurez comercial- Su operatividad es aún a nivel laboratorio
6. Conclusiones y Trabajo Futuro

6.1. Conclusiones

En en la realización del presente proyecto se evidencia la necesidad que hay en Colombia

de disponer de una aplicación semejante a la que está expuesta en el presente trabajo para
el seguimiento vehicular de los conductores en Colombia Esta situación se deduce de la
evaluación del Estado del arte y se observa cómo en Colombia hay un atraso en la adopción de
mecanismos de seguimiento vehicular de monitoreo, y control del número de horas trabajadas
por los conductores, controles en lı́nea de velocidad y control en la gestión de geocercas. Hoy
dı́a la mayorı́a de los conductores en Colombia disponen de un teléfono celular y en un en alto
porcentaje es Android, con lo cual este tipo de soluciones es costo efectivo, pues se pueden
implementar rápido sin necesidad de instalar equipos costosos en cada vehı́culo, haciendo
que su despliegue sea inmediato, con pocas barreras de entrada Se destaca también que
durante este trabajo se evidencia la posibilidad de incluir funcionalidades detalladas para el
monitoreo del comportamiento de los conductores como detallar que actividades hacen los
conductores al parar en cada estación, pudiendo entonces sacar más estadı́sticas y mejorar
la operación. En este proyecto también se destaca la facilidad de creación de aplicaciones
con la plataforma Flutter que permitió en un en un tiempo relativamente corto, realizar
una aplicación más elaborada para el servicio móvil, como también para la web, empleando
y reutilizando las mismas rutinas de acceso, control de autenticación y seguimiento. Esta
situación se destaca, pues dentro del trabajo realizado dado la complejidad de este, el uso de
herramientas como flutter o como el acceso a la base de datos Firebase hace que el proyecto
se fuera exitoso y no se tuviese que parar por temas de integración con bases de datos o con
sistemas de backend aparte. Como conclusión del trabajo realizado también se evidencia la
necesidad de realizar ajustes en los temas de precisión de ubicación como también en los
temas de medición de distancias pues a bajas velocidades y a corta distancia la precisión
de las medidas de las herramientas que provee el dispositivo de Android hace que no sean
precisas. En resumen, se presenta una excelente oportunidad, para que aplicaciones como
la que se presenta en este trabajo, se puedan implementar en Colombia e inclusive en la
región para poder mejorar la operación de transporte logı́stico, mejorando la seguridad y
reduciendo costos con pues se controla la velocidad de los vehı́culos y también se identifican
los vehı́culos que requieren atención por su alto consumo de combustible
 38 6 Conclusiones y Trabajo Futuro

6.2. Trabajos Futuros

Dentro de los trabajos futuros a este proyecto se abre un abanico de posibilidades y en lı́nea
con el estado del arte aparecen oportunidades para:

Incluir inteligencia artificial para poder hacer que el dispositivo móvil reciba informa-
ción del vehı́culo y el estado de este.
Se abre la posibilidad para desarrollar o mejor implementar la aplicación para disposi-
tivos iOS y cubrir otros mercados como por ejemplo el control de rutas escolares donde
la problemática es semejante a la de rutas de logı́stica.
Para trabajos futuros también se abre la posibilidad para poder permitir que los dueños
de los vehı́culos puedan tener acceso a la aplicación de monitoreo de manera tal que
puedan ver cómo están y dónde están sus vehı́culos y como están conduciendo los
conductores los vehı́culos.
Se abre una posibilidad para ofrecer este tipo de servicios a compañı́as de seguros
donde se requiera tener un registro del comportamiento de los conductores, de manera
tal que las pólizas de seguro se puedan asociar al buen comportamiento de conducción
de los vehı́culos.
Bibliografı́a

[1] D. L. República, “Los ocho retos de colombia para fortalecer su competitividad y superar
la crisis económica,” Tomado de google.com, 2020.
[2] Powerfleet, “How to prepare your fleet for the 3g sunset.” Tomado de
https://www.powerfleet.com/powercenter/how-to-prepare-your-fleet-for-the-3g-
sunset/, 2021.
[3] Geotab, “Don’t get left behind: 2g sunset faqs,” Tomado de
https://www.policia.gov.co/grupo-información-criminalidad/estadistica-delictiva,
2015.
[4] S. Kumar and K. B. Moore, “The evolution of global positioning system (gps) techno-
logy,” Journal of science Education and Technology, vol. 11, no. 1, pp. 59–80, 2002.
[5] T. Botos, “Ocaso de 2g/3g y simplificación de la migración a 4g lte,” Tomado de
https://neuronicworks.com/blog/2G-3G-sunset/, 2020.
[6] “Electronic logging devices.” [Online]. Available: https://www.fmcsa.dot.gov/
hours-service/elds/electronic-logging-devices
[7] M. Telematics, “Are you compliant with the eld mandate?” [Online]. Available:
https://www.mixtelematics.com/us/products/eld
[8] M. FC, “5g: How next-gen networks will transform
fleet management.” [Online]. Available: https://blog.fleetcomplete.com/
5g-how-next-gen-networks-will-transform-fleet-management
[9] Amazon, “Connected vehicle skills for alexa,” Tomado de
https://developer.amazon.com/en-US/docs/alexa/automotive/connected-vehicle-
overview.html, 2022.
[10] Colciencias, “Niveles de madurez tecnológica.” Colombia Cientı́fica, vol. Anexo 13, p. 5,
2016. [Online]. Available: https://www.colciencias.gov.co/sites/default/files/upload/
convocatoria/anexo-13-niveles-madurez-tecnologica-conv.pdf
[11] “Development.” [Online]. Available: https://flutter.dev/development
[12] “Flutter vs . Industry-leading Frameworks - The Ultimate Comparison Guide.”
[13] T. Bailey, A. Biessek, and T. Wills, Flutter for Beginners: An introductory guide to
 40 Bibliografı́a

building cross-platform mobile applications with Flutter 2.5 and Dart, 2nd Edition.
Packt Publishing, 2021. [Online]. Available: https://books.google.com.co/books?id=
7qZJEAAAQBAJ
A. Anexo: Paquetes de Widget
utilizados en el proyecto

Autenticación de Firebase para Flutter

Firebase auth: 3.1.5
Es un complemento de Flutter para usar la API de autenticación de Firebase. Firebase
Authentication proporciona servicios de backend y SDK, para autenticar a los usuarios en
la aplicación móvil y WEB. Admite la autenticación mediante contraseñas, números de
teléfono, proveedores de identidad federados populares como Google, Facebook y Twitter, y
más.
[1] API de autenticación de Firebase. Enlace.
Núcleo de Firebase para Flutter
Firebase core: 1.10.2
Es un complemento de Flutter para usar Firebase Core API, que permite conectarse a varias
aplicaciones de Firebase. El complemento firebase core se encarga de conectar la aplicación
Flutter al proyecto Firebase en el Cloud. El complemento debe instalarse e inicializarse antes
de usar cualquier otro complemento de FlutterFire. Proporciona funciones básicas como la
inicialización de FlutterFire.
[2]Firebase Core API. Enlace.
Complemento de Cloud Firestore para Flutter
cloud firestore: 3.1.2
Es un complemento de Flutter para usar la API de Cloud Firestore. Firestore es una base de
datos en la nube NoSQL flexible y escalable para almacenar y sincronizar datos. Mantiene
los datos sincronizados entre las aplicaciones de los clientes en las aplicaciones, a través de
agentes que escuchan en tiempo real y ofrece soporte fuera de lı́nea para que se puedan
crear aplicaciones receptivas que funcionen independientemente de la latencia de la red o la
conectividad a Internet.
[3]API de almacenamiento en la nube. Enlace.
Mensaje de proceso en curso
 42 A Anexo: Paquetes de Widget utilizados en el proyecto

progress dialog null seguro: 1.0.4

Un paquete ligero para mostrar el diálogo de progreso. Como es un widget con estado, puede
cambiar el texto que se muestra en el cuadro de diálogo de forma dinámica.
[4]Progress dialog. Enlace.
Complemento de preferencias compartidas
shared preferences: 2.0.15
Un paquete que considera el almacenamiento persistente especı́fico de la plataforma para
datos simples (NSUserDefaults en iOS y macOS, SharedPreferences en Android, etc.). El
complemento shared preferences se puede usar para conservar los datos de clave-valor en el
disco del móvil. El complemento de preferencias compartidas envuelve NSUserDefaults en
iOS y SharedPreferences en Android, proporcionando un almacenamiento persistente para
datos simples.
Este paquete utiliza los siguientes pasos:
Agregar la dependencia.
Guardar datos.
Leer datos.
Eliminar datos.
[5]Complemento de preferencias compartidas. Enlace.
Google Maps para Flutter
google maps flutter: 2.2.1
Este complemento de Flutter proporciona un widget de Google Maps. Google Maps se utiliza
para obtener información sobre una ubicación geográfica de manera simple y visual. Presenta
los lugares del mundo mostrando su forma y tamaño, ubicaciones y distancia entre ellos.
Este complemento puede acceder automáticamente a los servidores de Google Maps, mostrar
mapas y responder a los gestos del usuario. También nos permite añadir marcadores al mapa
desplegado en el móvil o en el escritorio. Flutter prefieren Google Maps ofrece un rendimiento
nativo tanto para Android como para iOS.
El complemento Flutter de Google Maps se proporciona en el widget de Google Map que
admite funcionalidades como initialCameraPosition, maptype y onMapCreated. Se puede
establecer la posición de la cámara y el marcador en cualquier lugar de la tierra. También
viene con una propiedad de zoom en una posición de cámara para proporcionar el zoom en
la vista del mapa de Google en la página inicial.
[6]Complemento Google Maps para Flutter Enlace.
Complemento de geolocalización de Flutter
 43

geolocalizador: 8.2.1
Un complemento de geolocalización de Flutter que brinda fácil acceso a los servicios de
ubicación especı́ficos de la plataforma (FusedLocationProviderClient o, si no está disponible,
LocationManager en Android y CLLocationManager en iOS). La geolocalización es el proceso
de identificar la ubicación fı́sica actual de un usuario cuando interactúa con su aplicación.
Caracterı́sticas:

Obtener la última ubicación conocida.

Obtener la ubicación actual del dispositivo.
Obtenga actualizaciones de ubicación continuas.
Comprobar si los servicios de ubicación están habilitados en el dispositivo.
Calcular la distancia (en metros) entre dos geocoordenadas.
Calcular el rumbo entre dos geocoordenadas.

Precisión de la ubicación
La siguiente tabla describe las opciones de precisión por plataforma:

Android iOS
El más bajo[m] 500 3000
Bajo[m] 500 1000
Medio[m] 100 - 500m 100
Alto[m] 0 - 100 10
El mejor[m] 0 - 100 0
Mejor para la navegación[m] 0 - 100 Optimizado para la navegación

[7]Complemento Flutter Geolocator Enlace.

Complemento de ubicación Flutter
location: 4.2.0
Este complemento para Flutter maneja la obtención de una ubicación en Android e iOS.
También proporciona información cuando se cambia la ubicación. A veces, para proporcio-
nar la mejor experiencia de usuario posible, es necesario conocer la ubicación GPS de su
dispositivo. El paquete location le permite obtener la ubicación geográfica actual del disposi-
tivo y escuchar los cambios. Puede usar estos datos para mostrar mapas, calcular distancias,
determinar la dirección hacia la que mira el dispositivo y más.
[8]Complemento de location Flutter. Enlace.
GeoFlutterFire
 44 A Anexo: Paquetes de Widget utilizados en el proyecto

geoflutterfire: 3.0.1
GeoFlutterFire es una biblioteca de código abierto que le permite almacenar y consultar un
conjunto de datos en función de su ubicación geográfica. Su principal beneficio es la posi-
bilidad de recuperar solo aquellos datos dentro de un área geográfica determinada, todo en
tiempo real. GeoFlutterFire utiliza la base de datos Firebase Firestore para el almacena-
miento de datos, lo que permite que los resultados de las consultas se actualicen en tiempo
real a medida que cambian. GeoFlutterFire carga selectivamente solo los datos cerca de cier-
tas ubicaciones, manteniendo sus aplicaciones livianas y receptivas, incluso con conjuntos de
datos extremadamente grandes. GeoFlutterFire está diseñado como un complemento ligero
para el complemento cloud firestore. Para simplificar las cosas, GeoFlutterFire almacena
datos en su propio formato dentro de su base de datos de Firestore. Esto permite que su
formato de datos existente y las reglas de seguridad permanezcan sin cambios mientras le
brinda una solución fácil para las consultas geográficas.
[9]Complemento GeoFlutterFire Enlace.
B. Anexo: Arquitectura Flutter
En el presente capitulo se describe la solución realizada, incluyendo los criterios de diseño y
algoritmos diseñados para resolver la problemática del presente proyecto de seguimiento y
monitoreo vehicular.

B.1. Plataforma Flutter y lenguaje Dart

Como se indicó previamente, la plataforma de desarrollo seleccionada fue Flutter, buscando
aprovechar las ventajas de Flutter, de permitir el desarrollo de aplicaciones, basada en un
solo lenguaje de programación orientado a objetos, como lo es el lenguaje Dart y que se
puedan cumplir los programas de manera tal que sean lo más cercano al código nativo [11].

B.1.1. ¿Qué es Flutter?

Google Flutter es el programa de desarrollo de aplicaciones multiplataforma de código abierto

desarrollado por la compañı́a en 2017. Flutter es de código abierto gratuito y está ubicado
como una de las plataformas de mayor crecimiento y aceptación por los desarrolladores,
dada su capacidad de generar código tanto para dispositivos móviles Android, como para
dispositivos IOS, de manera que se reducen los tiempos de desarrollo de aplicaciones y se
reutilizan librerı́as entre las diferentes plataformas [12].
A continuación, se indican las caracterı́sticas destacadas de Flutter pare el desarrollo del
presente proyecto:

Plataforma basada en código único.

La plataforma Flutter, permite desarrollar el código para los dispositivos móviles del
presente proyecto, como para la plataforma Web del backend.
Se utiliza una sola herramienta de desarrollo, en este caso Android Studio, plataforma
sobre la cual se instalan los módulos de Flutter y Dart.
La plataforma de desarrollo, tiene la funcionalidad de recarga en caliente, lo cual per-
mite ver el resultado de la aplicación casi inmediatamente se hace un cambio, lo cual
hace que el desarrollo y pruebas de alas aplicaciones sea sumamente rápido.
 46 B Anexo: Arquitectura Flutter

Flutter esta diseñado con el concepto de widgets, con lo cual de base se tiene una
biblioteca de widgets para el desarrollo de aplicaciones.
Flutter utiliza el lenguaje de programación Dart, el cual permite la generación de código
como si fuese una aplicación nativa, haciendo que el desempeño de las aplicaciones esa
bueno.
Soporte y actualizaciones oportunas de Google.
Se tiene una fuerte integración entre la Plataforma Firebase con Flutter, de manera
que se reduce la complejidad y posibilidad de error en el proceso de integración, al ser
ya soportadas las integraciones desde el móvil o Web, para el caso que nos ocupa en
el presente proyecto.
Flutter cuenta con una comunidad de desarrolladores, lo cual facilita el trabajo cola-
borativo, para resolver dudas.

B.1.2. Estructura de una aplicación en Flutter

Figura B-1.: Comunicación de Flutter con la plataforma de SDK

En la figura B-1 se muestra como Flutter gestiona mediante el SDK de desarrollo, los
diferentes elementos fı́sicos, permitiendo que el desarrollo de la aplicación sea transparente
a la plataforma base (Android, IOS, Web, Windows o Linux) [13].
Ahora bien, el desarrollo de la aplicación esta basada en estructuras llamadas Widgets,
loa cuales en si mismo contienen la lógica de presentación o de ejecución en si misma. Por
ejemplo, cada elemento en una pantalla de la aplicación se puede representar como un widget.
La vista de la pantalla depende completamente de la elección y la secuencia de los widgets
utilizados para crear la aplicación. Y la estructura del código de una app es un árbol de
B.1 Plataforma Flutter y lenguaje Dart 47

widgets. De hecho, en Flutter se dice [13] que una aplicación es un Widget, y que se a su
vez se comen de un conjunto de Widgets, organizados como un árbol, como se muestra en
la siguiente Figura.

Figura B-2.: Estructura de una aplicación en Flutter por medio de Widgets

Estos Widgets, puede contener información estática o dinámica, de manera tal que Flutter
adicionalmente utiliza dos estructuras poderosas para la creación de aplicaciones, como lo
son los Widgets estáticos (stateless Widgets) figura B-3 y los widgets interactivos (stateful
Widgets) como se muestra en las figuras B-4.

Figura B-3.: Estructura de Widgets sin estado [13].

Los widgets sin estado, se utilizan generalmente para manejar información estética.
 48 B Anexo: Arquitectura Flutter

Figura B-4.: Estructura de Widgets con estado [13].

Los widgets con estado, son claves para el manejo interactivo de la información en una
aplicación, de manera que Flutter permite definir qué información es clave “refrescar”, cada
vez que dicha información cambie, sin necesidad de recargar toda la aplicación, permitiendo
mejorar el rendimiento de la aplicación y la rapidez de la misma, a la vez que consume
menos recursos. Esta estructura de widgets con estado donde se utiliza la funcionalidad de
solo Reconstruir la información que ha cambiado para reflejar la descripción del nuevo estado
ha sido ampliamente utilizada en el desarrollo de la solución de Seguimiento vehicular, ya
que aquı́ se maneja información que cambia en segundos, como lo es la posición geográfica, la
velocidad, la distancia entre otras variables, además nos permite manejar mas eficientemente
la información dinámica, por ejemplo del movimiento de un marcador que representa un
vehı́culo o vehı́culos en un mapa.

B.1.3. Manejo de procesos asincrónicos en el lenguaje Dart

Otra de las caracterı́sticas poderosas utilizadas en el presente proyecto, es la capacidad

del lenguaje Dart de manejar procesos asincrónicos. Esto es en el lenguaje de programación
Dart se ejecuta en un solo ”hilo”de ejecución, por lo cual, en una estructura de programación
sincrónica, se puede dar la situación de encontrar un código que bloquea el hilo de ejecución
puede hacer que el programa se congele, como se muestra en la siguiente figura B-5.
B.1 Plataforma Flutter y lenguaje Dart 49

Figura B-5.: Comparación procesos sincrónico y asincrónicos. Fuente.

En este contexto Flutter tiene en el lenguaje de programación la estructura llamada async/await,

de manera que se pude definir en el código los widgets o procesos que se van a tomar un
tiempo en responder, como lo son el obtener datos de geolocalización de un dispositivo LTE,
o el de grabar un dato de localización o envı́o de un reporte a la base de datos, de manera que
en la lógica de la aplicación se tiene en consideración esta situación de procesos asincrónicos
como se muestra en la figura B-6.

Figura B-6.: Flujo de trabajo ası́ncrono Flutter/Dart. Fuente.

 Home Conductor

Registro Conductor
Login/Portal Operador
(Autenticación usuarios)
móvil y Wen

Recarga Combustible
Inicio Dia (Reporte) Cierre Dia (Reporte) Mapa Nombre Conductor
(Reporte)

ID Conductor ID Conductor Mostrar Mapa Registrar parada Reiniciar viaje Registro Instantáneo ID Conductor Correo Conductor

Iniciar Distancia Gasolina Cerrar Distancia Recorrida Localización Razón Parada Cierre hora Parada ID Conductor Localización Velocidad Distancia Recorrida Revisa Geocerca Registro Consumo/Distancia Password

Iniciar horas laboradas Cerrar horas laborables Velocidad Registrar hora inicios Parada Continuar horas conducidas SI sale Registro Placa vehículo

Iniciar horas conducidas Distancia Recorrida Parar horas conducidas Si entra Registro Nombre Almacén de Trabajo

Registro Conductor
Carga geocerca
(Conductores)

Figura C-1.: Conexión Andina Conductor.

51

C. Anexo: Diagramas de las aplicaciones

 52

Home Operador

Registro
Login/ Portal Operador Operador(Autenticación
usuarios)

Reporte Inicio Dia/Cierre Operaciones CRUD de

Reportes por Conductor Éxito Geocerca CRUD Nombre Operador
día Conductores

Registros de
ID Conductor Mostrar Mapa paradas/Horas Reporte de Alertas ID Conductor Latitud y Longitud Correo Operador
conducidas

Eficiencia de Combustible Localización Exceso de velocidad Nombre Conductor Radio Password

Horas laboradas Velocidad Salida de Geocerca Correo Conductor Nombre Almacén

Distancia Recorrida Distancia Recorrida Placa vehículo

Password

Figura C-2.: Conexión Andina Operador.

Almacén
C Anexo: Diagramas de las aplicaciones móvil y Wen