Solución funcional cubana para monitorizar el transporte en tiempo real

Temas a tratar:

  1. Veremos lo que se ha hablado de este tema a nivel de país en los medios de prensa.
  2. Se verá una arquitectura de alto nivel de una posible solución arquitectónica a nivel de país o ministerio de transporte.
  3. Se mostrará la solución que actualmente tengo implementada y desplegada en una laptop usando un servidor de mapas local.

Empecemos!!!!!

En una entrada anterior comentaba sobre la posibilidad de monitorizar el transporte en la ciudad en tiempo real, no todo el transporte, pero si aquellos medios que tuvieran GPS y que fueran de servicio público, dígase el transporte de las empresas estatales, tanto interno como para el público.

Las ventajas serían varias, una que se me viene a la cabeza ahora es la del ahorro de combustible y otra sería la de mejorar el servicio de recogida en las paradas cumpliendo con horarios establecidos. Pensando un poco más en los que toman decisiones, cada empresa que tuviera una flotilla de vehículos podría monitorizar en todo momento su uso.

En cubadebate publicaron una entrada con un sistema que están desarrollando los JCC de las Tunas, y que fue publicada primeramente en su periódico provincial. Luego la publicaron en el Granma. La idea es la misma, pero no se dan detalles técnicos.

Como comentaba en la entrada anterior, hacer esta solución no es complicado, su arquitectura a muy muy alto nivel a nivel de ministerio o de país podría ser la siguiente:

Donde en dependencia del dimensionamiento de la cantidad de vehículos a seguir será la infraestructura a necesitar, tal vez para una empresa pequeña no se requiera clusterización y con 1 servidor para BD y 1 servidor para el WSO2 CEP o SP baste.

Lo principal a tener en cuenta es que:

  1. Los clientes puedan acceder desde una aplicación web o desde un dispositivo móvil vía web o a través de una APK.
  2. Todas las herramientas deben estar clusterizadas para garantizar alta disponibilidad y un correcto rendimiento del sistema.
  3. Todas las APIs deben ser expuestas de manera segura y estandarizada a través de un API Manager lo que permite usar Oauth y monitorizar el uso de las APIs, incluso monetizar dicho uso si se quiere vender el acceso a determinados clientes.
  4. El sistema backend que habilita todo el tráfico de los eventos generados por los GPS será el WSO2 Complex Event Processor o el WSO2 Stream Processor(queda por revisar si con este se puede lograr el mismo escenario), capaz de recibir eventos en múltiples formatos, procesarlos, tomar decisiones, generar reportes y nuevos eventos así como alertas..
  5. Todo lo anterior deberá estar soportado por bases de datos relacionales y no relacionales para manejar el enorme volumen de datos que una solución de este tipo va a demandar.

Como todo, implementar una solución de este tipo con las herramientas correctas es bastante sencillo, lo complicado está en los requerimientos no funcionales y me explico:

Digamos que se tiene un parque de 100 vehículos y que los dispositivos GPS mandar una señal cada 1s… Si esto se produce durante 8h al día, la cantidad de eventos de inicio que debe ser capaz de procesar el sistema es igual a 100 eventos por segundo, lo que llevado a todo el día de trabajo da: 100*60*60*8  = 2,880,000 eventos de inicio.

Digo eventos de inicio pues en dependencia de lo que se haga con esos eventos se pueden desencadenar más procesamiento interno, para generar alarmas, notificaciones, nuevos hilos de proceso, operaciones matemáticas para determinar límites de velocidad, acceso a determinadas zonas, paradas no definidas, etc…, etc…O sea el procesamiento puede llegar a ser enorme. De ahí que se requiera una solución capaz de escalar tanto vertical como horizontalmente…Nada de un servidorcito de 2GB de RAM y 1 micro de 1 solo core.

De momento ya tengo una solución funcional  a modo de prueba de concepto, PoC, con la siguiente arquitectura de componentes:

Para generar los eventos estoy siguiendo 3 vías a modo de prueba:

  1. Un generador de eventos que viene con el WSO2 CEP, para probar que se produce la ubicación en el mapa.
  2. Un cliente JAVA capaz de autenticarse contra el WSO2 CEP y mandar eventos al componente de escucha HTTP.
  3. Mi propio teléfono, con un apk que determina la ubicación y manda un correo con un fichero .gpx que tiene dentro la latitud, longitud, velocidad, inclinación, etc.. y se puede procesar el fichero y mandar entonces el evento al WSO2 CEP.

 

Para demostrar el funcionamiento veamos algunas imágenes luego de usar los siguientes puntos geográficos como eventos:

punto 1:

  • latitud: 23.13820
  • longitud: -82.35984

punto 2:

  • latitud: 23.13823
  • longitud: -82.35963

punto 3:

  • latitud: 23.13823
  • longitud: -82.35920

El mapa antes de lanzar el evento, ubicación en pleno Centro Habana:

Se lanza el primer evento:

Y se posiciona automaticamente en el mapa:

Se lanza el segundo evento:

Y se actualiza en el mapa:

Se lanza el tercer evento:

Y se actualiza en el mapa:

Como ven se han generado 3 eventos y el indicador azul se mueve…solo resta que a alguien le interese y poder generar muchos más eventos en tiempo real para ver la capacidad de procesamiento de esta solución.

Entre sus principales características están:

  1. Se le puede definir una velocidad máxima, y entonces aquellos dispositivos que se pasen de esa velocidad se mostrarán en color rojo.
  2. Se puede ver el histórico de la ruta seguida con las variaciones de velocidad.
  3. Se puede definir una alerta de posicionamiento para saber cuando el dispositivo está detenido.
  4. Se puede definir una alerta de proximidad para saber cuando un dispositivo se aproxima a otro.
  5. Se puede definir una zona de manera tal que cuando un dispositivo entre o salga de dicha zona se genere una alerta.

En próximas entradas estaremos viendo estas características en acción.

Espero les sea de utilidad.

15 opiniones en “Solución funcional cubana para monitorizar el transporte en tiempo real”

  1. La propuesta en si es interesante, el tema pasa como siempre por problemas de conectividad y recursos, el experimento de las tunas es una idea genial de utilizar lo que tenemos en función de mejorar la información de cara al pueblo, aunque por mi experiencia personal no es tan sencillo como parece porque estas entidades no tienen los recursos humanos muy desarrollados en este tema y en la implementación se complican las cosas, he abierto un nuevo blog sobre el transporte zafiro2018.cubava.cu si el tiempo me da te escrbire mi propia experiencia sobre el tema.

    1. Bueno tampoco es tan complicado, de hecho ya eso está implementado, funcional y con capacidad para soportar una alta concurrencia de eventos…El problema como yo lo veo es que alguien con capacidad de decisor decida meterle el pecho y adentrarnos en el sigo XXI…ya te digo temas técnicos no hay complicación, la complicación son de logística.

  2. Excelente Jorge, muy interesante tu propuesta sobre todo porque va con llave en mano ajajaj, propuesta y solución a la vez. Solo necesitas una 3G constante que te pueda suministrar a tu API la data necesaria o montarte en un P14 e ir con tu APK abierta guardando toda la info para un file y luego mandarlo al CEP para que lo procese y puedas graficar en tu mapa con mucha mas data. Espero que alguien de los que decide logre leer tu post y le preste al menos un poco de atención.

    1. ah ya para eso encontre una apk que obtiene latitud y longitud y me manda por correo un ficherito con esos datos y ya en el ESB puedo leer del correo sacar el fichero procesarlo y obtener la data en un servicito proxy ahí sato, tu verás como me monto en un P14 un día de estos para probar a ver que pasa…aunque recuerda que el DAS/CEP tiene para recibir eventos por casi cualquier vía, email, socket, http, y la madre santa.

  3. Muy de acuerdo con tu apreciación, me llega muy de cerca tu descripción y en mi opinión es un esquema bastante deducible para las capacidades de nuestros profesionales. Coincido plenamente con el criterio de zafiro2018, el problema mayor es en caliente, la logística y las gestiones necesarias. En las tunas pues si ya tenemos este esquema funcionando, la plataforma geotrans en encargada de realizar la tarea soporta además escenarios multientidad, permitiendo participar a varias estructuras organizaciones. Varios servidores encargados de servir mapas, fuentes binarios y exponer el api de interacción con versionado de metadatos y otras cosas más. Las rutas hoy son diseñadas en el propio sistema, no hace falta montarse en la guagua(con datos vectoriales es muy sencillo). Por otra parte geotrans es sólo la punta del iceberg, detrás(red corporativa) hay un gran sistema controlando los procesos de negocio de la empresa, en particular operaciones que se encarga de realizar las aperturas, emitir hojas de rutas, chequeos de parámetros técnicos etc. Una vez realizada seat confirma apertura a geotrans y que además convierte este dato a información pública transmitida además en paneles visuales en lugares de interés, tenemos uno de estos en la terminal. Por lo escueto de la nota publica no se abunda mucho, esta pendiente publicación en granma sobre el proyecto en general, no sólo la guagua(es lo que la gente ve y entiende).
    Saludos, buen post

    1. Entiendan que por logística me refiero a:
      1. Compra de los equipos GPS con capacidad para emitir eventos vía GPRS o cualquier otro mecanismo que sea factible.
      2. Convenio con ETECSA para que brinde su plataforma.

      Y ya. Fuera de eso no hay que empapelarse más, que nos gusta el tema de los procesos, los papeles, las reuniones, en fin…nuestras cubanadas. Y entonces un proyecto de 1mes se transforma en un proyecto de 1año. Que los he visto.

      Sobre los temas técnicos:
      1. Servidores que sirvan mapas, eso con docker se puede tener una solución clusterizada en lo que canta un gallo.
      2. Definir las paradas(se puede implementar un API que de este dato) y las rutas es algo que se hace en esta solución sobre el mismo mapa, si un generador de eventos se sale de la ruta, se emite una alarma. Así de sencillo, esa alarma puede ser cualquier cosa, un email, sms, evento a otro sistema, etc…

      Lo que se necesita es una licitación pública, que se hagan las cosas como se deben hacer…ya alguien más comentaba unir esfuerzos, y yo digo mejor que unir esfuerzos es licitar abiertamente y que las empresas y particulares puedan saber que se requieren sistemas de este tipo y se enfoquen en dar la mejor solución. Solo así tendremos la mejor solución.

      1. Arduino < 5 usd (Aliexpress)
        SIM808 Module (GPS+2G+3G+4G) para Arduino aprox 40usd (Aliexpress). OJO los hay mas baratos.

        Por supuesto tienes que implementar el software que controle el Arduino.

        Es todo lo que necesitas en cuanto a equipamiento. No creo que sea una gran inversion.

        Lo mas complicado es que las infraestructuras funcionen de manera fiable (digase la conexion 3G por ejemplo). Y por supuesto en un entorno tan centralizado y burocratizado que los que deciden, se decidan.

        1. Hola ATS, gracias por la info.
          Digamos que se arranca con 100 vehículos, de esos que más gastan combustible y nunca se sabe donde están. O con las ambulancias que tienen un tiempo de demora bastante prolongado para criterio del paciente que las necesita pero ya. Sería una inversión inicial de 4000USD en este equipamiento que se recuperaría en ahorro de combustible o en salvarle la vida a varios enfermos lo cual no tiene precio.
          La otra inversión sería en servidores para clusterizar la solución.
          Si los decisores se decidieran, yo hasta hiciera toda la implementación que estuviera a mi alcance de gratis, para que tuvieramos un sistema de este tipo en el país.
          Sigue quedando como siempre que los decisores, se interesen y se decidan.

  4. Sugiero que si un grupo de desarrollo de Las Tunas tiene algo desarrollado y en prueba y cuenta con el apoyo de los decisores se integren y conversen en la mejor solución y así se aporta más integrando esfuerzos.

    1. me gusta más la competencia…cuales son las características de la solución de las tunas, su arquitectura, que facilidad de escalabilidad tienen, y de incluir nuevas funcionalidades, como manejan el tema de miles y miles de eventos concurrentes desde ciento y cientos de generadores de eventos…ese de unir esfuerzos es lo que se ha hecho en todos estos años en el país y es lo que ha creado islitas de empresas estancadas en sus productos que los pintan cada año para darles un poco de colorete.

      Lo mejor es un demo o una PoC, o mejor una licitación pública.

      1. Se dice fácil, yo decía lo mismo, la verdad es que el problema principal radica ahí, mentalidad y mucha reingeniería de procesos (algo que no comentas) para lograr informatizar algo como el tema del transporte. Para eso no solo necesitas una solución y licitaciones públicas, necesitas además alguien integrado directamente a los procesos de negocio de la empresa. Lo que empieza por 1 mes (mirandolo friamente) termina siendo 3 años (analizandolo objetivamente).
        Todo el mundo está en libertad de hacer competencia (un concepto inversamente proporcional a la integración), de hecho, XETID tiene su plataforma igual, existe de igual manera Movilweb y otras plataformas para esto, no es nuevo lo que propones, ni lo que nosotros tenemos, nuestro objetivo siempre empezó por informatizar los procesos de negocio, ahora en esta etapa necesitabamos esta solución que es el servicio de información pública, hoy la tenemos. En fin es una relación de más de 3 años de trabajo conociendo como funciona todo, cambiando metodologías, procesos y cuanto díos a aparecido. Puede ser que una licitación te de el mejor partido, pero le toca evaluar a la empresa costo-beneficio, pero hay mucho en juego, no solo es un software.

  5. Los temas técnicos de las soluciones es algo que siempre es muy demandado, sabes que no funciona así, existe una contratación, derechos, obligaciones y clausulas de confidencialidad. Hay cuestiones que son públicas y pueden ser discutibles, otras de las cuales se pudiera hablar pero no tengo el derecho a divulgarla. Todo parace simple pero no lo es, hay principios éticos profesionales que deben respetarse.
    Si crees que existen mejores variantes proponlas, nosotros hicimos lo mismo y aquí estamos.

    1. Ese para mi es el problema…lo que ustedes han hecho se lleva haciendo desde hace más de 5-10 años, no hay misterio, no hay novedad científica me imagino, no hay un framework supersecreto por detrás, es puro y plano análisis/diseño/codificación y aun y así no se puede mostrar arquitectura, no se pueden mostrar demos, no se puede validar por parte de 3ros que la solución es eficiente…y eso pasa con casi todo el software que se hace en Cuba…a manera de ejemplo puedo poner la plataforma de ETECSA y la apk de TODUS…nadie validó realmente que esas plataformas sirvieran en el entorno real cubano….

      Si no existe una licitación pública, la empresa que los contrató se tiene que comer su sistema con papas, no tendrán idea si existe uno mejor, más caro o más barato, porque ya los contrataron..ese es mi punto..antes de contratar se debe licitar, hacer una demo o un PoC, que demuestre validez de la arquitectura con los RF y RNF, que valide la carga y el nivel de concurrencia, en fin….

      Una solución puede funcionar, pero será la más óptima?

      Saludos.

      1. No son 5 ni 10 y tampoco hay misterio en el asunto, solo que no es decisión nuestra. La eficiencia se valorará cuando existan las licitaciones y ya en ese caso le tocará decidir siempre a la empresa. Como vez nadie está en desacuerdo con el tema de las licitaciones, es una forma de crecer, solo que ahora no se aplicar por x, y o z y el mundo sigue girando, las empresas tienen que producir y tenemos que comer, mientras tanto seguir trabajando.

        1. La eficiencia y calidad de un sistema se valora en las pruebas que se le realice, midiendo cantidad de transacciones por segundo que soporta, niveles de concurrencia, uso de la red, uso de los servidores (CPU, RAM, accesos a discos) y tiempos de respuesta de cara a los usuarios. Además midiendo la facilidad para escalar en cuanto a hardware, ya sea vertical u horizontalmente y en cuanto a funcionalidades, o sea qué tan fácil se le pueden incluir funcionalidades nuevas al core del sistema sin afectar al resto…

Deja un comentario

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *