Este documento presenta el proyecto final de grado de Pablo Zincarini para la empresa Federada Salud. El proyecto consistió en el diseño e implementación de un sistema AVL utilizando dispositivos Virloc 10 de la empresa Virtec para dar seguimiento en tiempo real a la flota vehicular de Federada Salud. El sistema desarrollado, llamado GeoManager, usó diversas tecnologías como Java, GeneXus, PostgreSQL y más. El proyecto logró su objetivo pero también enfrentó riesgos y desafíos imprevistos durante su desarrollo.

1. TRABAJO FINAL DE GRADO
INSTITUTO UNIVERSITARIO AERONÁUTICO
Proyecto: Diseño e implementación de sistema de
AVL en una empresa de salud
Alumno: Pablo Zincarini
Directora del proyecto: Daniela Díaz

2. Temas a tratar
• Contexto general de la situación
• Identificación del problema
• Estudio e investigación de la
solución propuesta
• Demo de GeoManager
• Detalle de los riesgos identificados
• Estimación de la inversión necesaria
• Conclusiones

3. Empresa encargada de
llevar adelante
el proyecto:
LEGADO IT
Empresa que tiene
el problema:
Federada SALUD
(cliente de Legado IT)

4. Tema sobre el cual se basó
la investigación:
AVL
(Automatic Vehicle Location o
Localización Vehicular
Automatizada)

5. Situación problemática
Actualmente Federada SALUD no
cuenta con un sistema que reporte en
tiempo real la situación de sus
vehículos, perdiendo así el control
sobre los mismos y consecuentemente
sobre las actividades que realizan los
choferes.

6. Fabricado por la empresa nacional Virtec SRL
Solución hardware de AVL propuesta

7. Hipótesis inicial
Utilizando el producto Virloc 10
podríamos cubrir y superar la
falencia que tiene hoy en día
Federada SALUD con respecto al
control de sus vehículos.

8. Formas de comunicación del
producto Virloc 10:
 Serial
 SMS
 GPRS (UDP/IP o TCP/IP)
 Orbcomm
 …

9. Esquema general

10. Prototipo software desarrollado
como solución

11. Tecnologías involucradas:
 Java SE Versión 8: para trabajo a bajo nivel en la
comunicación con el VL.
 GeneXus X Ev. 2: para generar la aplicación de
gestión utilizada por el usuario final. Uno de los
requerimientos de más alta prioridad era que
GeoManager fuese desarrollado mediante el IDE
GeneXus, debido a que todas las aplicaciones de
la empresa (Legado IT) están diseñadas mediante
esta herramienta.
 C#: código de salida del generador GeneXus.
 XVM: protocolo o lenguaje de comunicación
utilizado por el VL.

12.  PostgreSQL: motor de bases de datos de la
aplicación. Implementado inicialmente de forma
temporal.
 SQL Server: motor de bases de datos secundario
utilizado para almacenar “el conocimiento” de la
KB GeneXus. Además la aplicación final
(de Producción) deberá utilizar este DBMS.
LA MIGRACIÓN YA FUE REALIZADA DE
FORMA EXITOSA.

13.  CSS3: utilizado para el diseño del front end de GeoManager
(componente GeneXus).
 User Controls GeneXus: para extender las funcionalidades
básicas a las cuales nos limita la herramienta. Entre ellos:
* JSCook Menu: para la gestión del menú del
usuario.
* Timer: para refrescar periódicamente la pantalla y
por ende visualizar la información de las
unidades actualizada. Con esto evitamos que el
usuario tenga que presionar permanentemente el
botón REFRESCAR.
* Map Control: Google Map embebido, de forma
tal que la aplicación cuente con una interfaz de
usuario agradable.

14.  K2B Tools: lo que son los frameworks para la
mayoría de los lenguajes de programación de
tercera generación, son los PATRONES para
GeneXus, y K2B Tools es una de las dos ramas
con mayor peso a nivel mundial.

15. De segundo orden:
 WinRun4J: librería Java para “envolver” un .jar
y convertirlo en un servicio de Windows.
 RXTX: librería Java para interactuar a través
del puerto COM de la PC utilizando el protocolo
Serial.

16. Como puede observarse a simple vista
Uno de los puntos más
importantes de este proyecto
fue LA ARTICULACIÓN DE
UNA GRAN VARIEDAD DE
TECNOLOGÍAS

17. Y algunas particularidades de GeoManager
 Multiempresa.
 Diseño de núcleo (estructura de
tablas) con el fin de poder migrar
la aplicación de un cliente a otro
de forma instantánea.

18. A continuación,
una demo del sistema

19. Los riesgos identificados en el
inicio (y las trabas que surgieron
durante el desarrollo) fueron varios.
Por mencionar algunos…

20. Generación del Check SUM para mensajes XVM
Ejemplo de mensaje:
>QGP;ID=1234;#8000;*5C<[CR][LF]
Se calcula haciendo una XOR con
todos los códigos ASCII de los
caracteres que componen el mensaje,
comenzando con el carácter y
terminando con el último incluido,
pero no el indicador de Check SUM.

21. int chksum = 0;
for (int r = 0;r < entrada.length();r++){
char C = entrada.charAt (r);
int decVal = (int) C;
chksum = chksum ^ decVal;
}
string checkSUM = Integer.toHexString(chksum);
checksum = checkSUM.toUpperCase();

22. Gestión de usuarios de la BD
• postgres (en Postgre SQL) o sa (en SQL Server):
componente GeneXus.
• usuarioGPSmain: componente JAVA, hebra inicial
que recupera parámetros del sistema (generales)
e inicia a los otros dos hilos.
• usuarioEscucha: componente JAVA, hebra que
escucha permanentemente lo que se recibe en el
puerto UDP (por defecto y por el momento
Nº 4097).
• usuarioSender: componente Java, hebra que
envía mensajes al VL (tanto mensajes ACK como
consultas o seteos por parte de la base).

24. Nota:
Para eliminar cualquier posibilidad
de que se produzca un INTERBLOQUEO
entre las hebras (la que escucha y la que
envía), se utilizó el patrón de diseño
SINGLETON (con atributo estático – de
clase) para el acceso al socket. Y la
concurrencia de ambas hebras sobre la
BD es manejada por el DBMS.

25. Punto inconcluso
En el diseño inicial se utilizaba un sólo usuario de
BD, tanto para la hebra que escucha como para la que
responde. Luego de la caída del sistema y el bloqueo
del DBMS, se aplicó una corrección temporal creando
tres usuarios distintos para la BD (más uno para el
componente GeneXus). Se tomó esta medida tan
extrema debido a que no se podía seguir con el sistema
parado, y menos aún correr el riesgo de que se bloquee
nuevamente el servidor de bases de datos (lo cual
estuvo acompañado de la pérdida de toda la
información almacenada en las tablas), pero es un
tema que se encuentra actualmente bajo estudio con el
fin de identificar cuál fue la causa exacta de tal bloqueo.

26. Rutina de inicialización para Virlocs de Legado IT:
1) QVR Identificación del equipo
2) SCF0000,MX2,APN datos.personal.com Comando de
AUTOCONFIGURACIÓN
3) VSIPO,190.136.174.135.4096.4097 Especificación de la IP y
puerto a reportar
(incluyendo el puerto
desde donde envía)
4) CBU Limpio el buffer de salida
5) STDO10030 Bajo el tiempo que tarda en enviar un nuevo
reporte

27. Estimación de la inversión inicial
Cada equipo VL USD279
x 25 unidades USD6975
Convertido a ARS $59287,50 (aproximadamente,
tomando una relación
de conversión de 8,5)
+ el 21 % de IVA $71737,88

28. Conclusiones

29. • La tecnología de Virtec SRL
efectivamente nos permite
mantener un control en tiempo real
de la situación de cada vehículo
perteneciente a la flota de nuestra
empresa

30. • Aumenta exponencialmente los
costos del proyecto tratar de construir
un sistema informático que actúe de
forma perfecta cuando se depende
en tan gran medida de un hardware
específico como el VL. Por eso, en la
evaluación inicial resulta clave definir
la precisión con la cual responderá el
software a desarrollar

31. • Cayendo nuevamente en
conclusiones rescatadas en el
proyecto de pre-grado, por más
que se planifique hasta la última
hora-hombre a invertir, siempre
existe la posibilidad de que surjan
contratiempos que retrasen el
avance general del trabajo

32. ¿Dudas?
¿Consultas?

33. ¡Muchas gracias
por su atención!