Proyectos de Fin de Grado:

Transcripción

1 IEEE Uruguay Communications Society Proyectos de Fin de Grado: Sistema de Predicción n de Arribos en el Transporte Metropolitano Universidad de Montevideo Ing. Fernando Bresciano Ing. Gonzalo Faral Tutores: Ing. Thomas Hobbins Ing Marcelo Abreu Unjversidad ORT Federico Pais Javier Chavez Tutores: Ing. Jorge Gallo Ing. Gonzalo Escuder

2 Universidad ORT Sistema de Información de Demoras para el Transporte Metropolitano Federico Pais Javier Chavez Tutores: Ing. Jorge Gallo Ing. Gonzalo Escuder

3 Introducción Necesidad de un sistema de información de demoras: Los usuarios, en general no tienen acceso al listado de horarios y frecuencias de las distintas líneas l de ómnibus. Los horarios suelen no cumplirse.

4 Momento tecnológico Los ómnibus del sistema de transporte cuentan con dispositivos GPS Los costos de las comunicaciones a precios más m s accesibles

5 Solución n propuesta Un sistema que soporte el acceso desde múltiples sistemas de comunicación

6 Numeración n de Paradas

7 Interacciones del Sistema Interacción n Sistema informático Ómnibus Interacción n Sistema informático Usuario

8 Servidor Central

9 Estructura básicab

10 Central Telefónica

11 Estructura básica

12 Servidor SMS

13 Servidor SMS

14 Acceso vía v Internet

15 Acceso vía v a Internet Cliente Web Service montado en uno o varios sitios Web. Servicio funciona de manera similar a sitios Web genéricos de reserva de hoteles, vuelos, etc.

16 Arquitectura de la solución

17

18 Dimensionamiento y Escalabilidad

19 Dimensionamiento y Escalabilidad Estudio de los requerimientos para la implementación n de este sistema en la ciudad de Montevideo. Alternativas de escalabilidad para hacerlo viable en cualquier otra ciudad. Objetivo: determinar HARDWARE

20 Datos para Dimensionamiento 292 millones de boletos al año a 800 mil boletos diarios 6.00 am hasta pm 50 mil boletos por hora Hipótesis: 20% usuarios transporte utilizan el sistema 10 mil llamadas por hora Duración n promedio de la llamada: 40 seg

21 Hardware para Central Telefónica Placa: Servidor Asterisk: : Dual Core 3 GHz Memoria 2 GB RAM

22 Capacidad de atención: n x 120 líneas Escalabilidad

23 Escalabilidad Capacidad de enlace: n x 8 Kbytes/seg

24 Escalabilidad Arquitectura de Centrales Telefónicas distribuidas

25 Asterisk SIP Server Escalabilidad

26 Funciones adicionales Redundancia en hardware

27 Funciones adicionales Sistema de monitoreo y gestión n de fallas

28 Falla de Central Telefónica Funciones adicionales

29 Falla de Servidor Central Funciones adicionales

30 Conclusiones El sistema diseñado brinda una solución a la necesidad inicial de proveer a los usuarios de transporte, un Sistema que informe sobre la demora de los ómnibus que esperan. Arquitectura adecuada e interesante para cualquier sistema de consultas, ya que permite múltiples funcionalidades de acceso a los usuarios. Gran escalabilidad. Asterisk y Web Services: tecnologías cada vez más utilizadas a nivel mundial y en constante desarrollo.

31 Muchas gracias!

32 Universidad de Montevideo Sistema de Predicción n de Arribos de Transporte vía a SMS Ing. Fernando Bresciano Ing. Gonzalo Faral Tutores: Ing. Thomas Hobbins Ing Marcelo Abreu

33 Objetivo General Sistema que calcule tiempos de arribo de ómnibus dinámicamente Predicciones precisas Distintas plataformas de conexión n a la red celular Distintos sistemas de procesamiento de los datos de posicionamiento

34 Requerimientos de Software Precisión Predicciones acertadas Usabilidad Mensajes fáciles f de escribir Respuestas fáciles f de entender Tolerancia a fallos Funcionar sin intervención n humana No suponer cumplimiento de horarios

35 Requerimientos de Software Seguridad Recibir SMS sólo s de teléfonos Conexón a BD de posiciones por VPN Portabilidad Distintas plataformas Distintas ciudades y compañí ñías de transporte

36 Arquitectura del sistema

37 Acceso a datos externos Solución n activa: Replicar la base de datos externa continuamente. Acapara recursos. Solución n pasiva: Acceder solamente al realizar predicciones Costo elevado por predicción. Solución n intermedia: Actualizar periódicamente y realizar consultas especiíficas para cada predicción Actualizador de calendarios Actualizador de posiciones Actualizador de históricos PERSISTENCIA BASE DE DATOS ADAPTACIÓN BD

38 Pruebas de precisión Rango estimado de arribo Error absoluto Error relativo = Error absoluto Duración predicción Envío consulta Duración predicción Arribo real Resultados Error absoluto promedio: 9,1 segundos Error relativo promedio: 3,4% Rango de arribo promedio: 16,2% de la duración de predicción

39 Pruebas de carga Servidor de BD PC con procesador de 1.1GHz, 512 MB RAM. Se logró promedio de 17 consultas por minuto. Utilización del procesador: : entre 70% y 100%. No se observó ninguna variación en la consumo de memoria. Aplicación ejecutada sobre una PC conectada al servidor BD a través de LAN de 100 Mbps. Tráfico promedio: : entre 1,2 y 1,8 Mbps. Utilización del procesador: : entre el 40% y 70%. Se logró promedio de 20 consultas por minuto. Se cambió servidor BD por dual core de 2.8 GHz y 1 GB de RAM. Utilización del procesador: : ambos entre el 50% y 60%. Se logró promedio de 50 consultas por minuto.

40 Dimensionamiento La carga soportada del sistema se estima a partir de su capacidad para realizar predicciones Si llegara ser una limitante la velocidad de envío o y recepción n SMS, se acoplarían an más m s plataformas de comunicación n SMS. Durante las pruebas de carga se observó que el cuello de botella está en el servidor BD. Pruebas con líneas,, paradas y un promedio de ómnibus simultáneamente neamente. Montevideo: 560 líneas y paradas. Se estima promedio de ómnibus (viajes por día d a de para cada línea) l registrados simultáneamente. Lo que más m s carga agrega a una predicción n es la cantidad de paradas.

41 Dimensionamiento En 2007 se vendieron 256 millones de boletos en Montevideo. Estimado 1 consulta cada 10 viajes, deberían atenderse 26 millones de consultas al año. a Si se distribuyen homogéneamente entre 12 horas por día d a (momentos de mayor movimiento), se obtiene que el sistema debería a ser capaz de procesar aproximadamente 100 consultas por minuto. Extrapolando las pruebas de carga realizadas: Servidor BD debería tener un procesador con cuatro núcleos de 2.4GHz.

42 Conclusiones Preciso: nivel de error inferior a los otros sistemas estudiados Eficiente: capaz de operar a escala real Genérico: aplicable a una gran variedad de escenarios Versátil: parámetros de personalización Autónomo: adaptación n automática tica a cambios en el entorno

43 Demo Línea 145 Llegada 04:32:05 p.m. Línea 151 Llegada 05:00:36 p.m :34:24 p.m :01:29 p.m :35:42 p.m :02:05 p.m. Enviar 1105 <línea< nea> al :36:27 p.m. 04:36:39 p.m. 04:37:13 p.m. 04:37:29 p.m. 04:38:44 p.m. 04:41:37 p.m :06:27 p.m. 05:06:33 p.m. 05:06:41 p.m. 05:07:04 p.m. 05:07:13 p.m. 05:07:37 p.m :41:37 p.m :08:44 p.m :41:47 p.m :09:29 p.m. Arribos a la parada 1105 entre 16:30 a 17:30 del 03/11/ :42:05 p.m. 04:43:48 p.m. 04:45:29 p.m. 04:46:24 p.m. 04:47:51 p.m :10:24 p.m. 05:12:05 p.m. 05:13:48 p.m. 05:14:41 p.m. 05:17:29 p.m :51:27 p.m :19:57 p.m :51:39 p.m :19:58 p.m :52:05 p.m :20:32 p.m :52:13 p.m :21:27 p.m :53:29 p.m :22:05 p.m :53:37 p.m :22:13 p.m :53:44 p.m :23:41 p.m :54:01 p.m :23:44 p.m :54:37 p.m :23:53 p.m :58:24 p.m :25:24 p.m :58:48 p.m :28:48 p.m.

44 Muchas gracias!