ATAC Proyecto Final Análisis de Tránsito Asistido por Computadora

ATAC Proyecto Final Análisis de Tránsito Asistido por Computadora
desarrollado con Redes de Petri Licenciatura en Sistemas Universidad FASTA TIEMPO TOTAL DE LA PRESENTACION: 69 MINUTOS Tiempo: 1 min. Buenas tardes, mi nombre es Leandro. Desde ya muchas gracias por asistir a este evento. A continuación se llevará a cabo la presentación del proyecto que se realizó en el contexto de la materia “Proyecto Final” de la carrera Licenciatura en Sistemas de la Universidad Fasta.

Contenido Introducción Redes de Petri y el Tránsito
Desarrollo del Prototipo ATAC Validación del prototipo Métricas Conclusiones Preguntas Tiempo: 1 min. Durante la presentación les mostraremos una síntesis del Proyecto ATAC. Dividimos esta presentación en las siguientes etapas: Introducción: donde veremos los inicios del proyecto, los objetivos iniciales y el equipo de trabajo Redes de Petri y el Tránsito: daremos los lineamientos básicos de la teoría RdP y cómo se modela el tránsito Desarrollo del Prototipo ATAC: mostraremos el desarrollo del software que implementa el modelo. Validación del prototipo: demostraremos que la teoría de RDP es propicia para modelar el tránsito Métricas: daremos las mediciones de parámetros del prototipo y del esfuerzo que requirió el desarrollo Conclusiones: conclusiones del proyecto, llegamos a la meta? Preguntas: en la última sección podrán hacer preguntas.

Iniciativa del Proyecto
Introducción Iniciativa del Proyecto Problemas en el tránsito local Congestionamientos Accidentes Aplicación de nuevas teorías Aprendizaje De lo teórico a lo práctico Ausencia de herramientas informáticas Difícil planificación Difícil la toma de decisiones Tiempo: 1 min. Hace varios años que nuestra ciudad, San Carlos de Bariloche, a sufrido un aumento repentino del parque automotor. Este fenómeno ha saturado la estructura vial provocando congestionamientos y accidentes A su vez, queríamos investigar temas nuevos que no habiamos visto en la carrera, y aplicarlos. También notamos que en el municipio es difícil la planificación y toma de desiciones en el transito por la falta de herramientas.

Introducción Equipo de trabajo Alumnos DT: Ing. Pablo Argañaras
Catalina Salvati Francisco Suárez Leandro Cofre DT: Ing. Pablo Argañaras DF: Guillermina Alaniz (Posterior a Carlos Cattini y Alejandro Valdez) Tiempo: 2 min. Obs.: En esta diapositiva nos presentamos. El equipo de trabajo del proyecto fue constituido por los alumnos: Catalina Salvati, Francisco Suárez y Leandro Cofré. La dirección técnica del proyecto estuvo a cargo del Ingeniero Pablo Argañarás, quien fue el de la iniciativa de aplicar la teoría. El DT es el encargado de asistir técnicamente a los alumnos en caso de alguna dificultad, y a su vez es el que aprueba el proyecto. La Sra Guillermina Alaniz fue la Directora Funcional, cuyo rol consistió en hacer de cliente ya que conoce el problema a resolver. Como elegimos a nuestro DF por ser el encargado de la dirección de tránsito, tuvimos como DF a Carlos Catini y Alejandro Valdez.

Introducción Objetivos Proyecto Personales Cliente
Determinar si el modelado de tránsito vehicular con Redes de Petri refleja la realidad Personales Adquirir el conocimiento necesario de la teoría de Redes de Petri para modelar, analizar y resolver problemas complejos de la vida real Contribuir a la comunidad con el aporte de una herramienta que ayude a la planificación del tránsito Tiempo: 2 min. Al inicio del proyecto postulamos distintos objetivos. Objetivos del Proyecto Determinar si el modelado de tránsito vehicular con Redes de Petri refleja la realidad. Objetivos personales Adquirir el conocimiento necesario de la teoría de Redes de Petri para la aplicación de modelos abstractos que nos permitan analizar y resolver problemas complejos de la vida real. Contribuir a la comunidad con el aporte de una herramienta que ayude a la planificación del tránsito. Objetivos del cliente Obtener una herramienta que le permita modelar circunstancias reales del tráfico vehicular para poder anticiparse de manera virtual. --Introducción a la próxima diapositiva Luego de plantear los objetivos, estudiamos la teoría de RdP. A continuación les mostraremos los elementos básicos de modelado de la red, para luego mostrarles cómo modelamos el tránsito con estos elementos. Cliente Obtener una herramienta que le permita modelar el tránsito para poder detectar problemas y procurar solucionarlos de manera virtual

Las Redes de Petri y el Tránsito
Elementos de una RdP Arcos Transición Marca Lugares Tiempo: 2 min. Daremos una noción básica de las RdP. Las Redes de Petri (RdP) son una teoría matemática postulada por el alemán Carl Adam Petri que permite modelar sistemas no determinísticos, distribuidos y/o estocásticos, con procesos concurrentes, paralelos y asíncronos. Como modelo de descripción, una RdP es un grafo orientado en el que intervienen dos clases de nodos, los lugares y las transiciones, unidos alternativamente por arcos dirigidos. Un lugar puede o no contener marcas. Las marcas se suelen representar mediante un punto en el interior de un lugar. El conjunto de marcas asociadas a cada uno de los lugares en un momento dado, constituye un marcado de la RdP. Para la descripción funcional de sistemas concurrentes los marcados representan estados y las transiciones sucesos, que dependen del cumplimiento de determinadas condiciones.

Evolución de una RdP M Mprev(t) Mpost(t) = Mf Tiempo: 2 min. Los cambios de estado de red están dados por el disparo de transiciones. Es fácil representar la estructura de la red con matrices binarias. La Matriz de incidencia previa está constituida por los lugares origen de cada transición. La Matriz de incidencia posterior está constituida por los lugares destino de cada transición. La matriz de marcados es aquella que muestra las marcas por lugar, luego del disparo de una transición. Matriz de incidencia previa (Prev) Matriz de incidencia posterior (Post) Matriz de marcados (M) Evolución, para cada lugar/transición Mf[lug]= Mi[lug] – Prev[lug, trans] + Post[lug, trans] - + =

Modelado del tránsito - Equivalencias Tiempo: 1 min. La siguiente tabla es una equivalencia entre los elementos que forman parte del tráfico vehicular y las RdP. Estas definiciones fueron las que propusimos para modelar el tránsito. Vehículo=Marca Lugar físico donde se encuentra un vehículo = Lugar Paso de una vehículo de un lugar a otro = Transición Flujo vehicular = Evolución del marcado Semáforo = Retardo de transiciones

Modelado de una intersección Tiempo: 2 min. Obs.: Acá mostramos cómo modelamos una esquina simple, ponemos el programa que hicimos al principio, hay que poner un link para hacer evolucionar las marcas. Este el modelado de una intersección simple de acuerdo a las definiciones de la diapositiva anterior. En los inicios del proyecto desarrollamos un software que modelaba y hacía evolucionar las RdP, lo hicimos sólo para una intersección simple.

Nuevas definiciones Lugares K-acotado (P1) Árbitro Fuente (P2) Sumidero (P4) Transiciones Con retardos Trabadas (T1) Tiempo: 4 min. Obs.: Las marcas aparecen y desapareen de acuerdo a la definición (falta animación). Al final se pondrá un link a JARP para hacer evolucionar una RdP con un árbitro. Modelamos situaciones específicas que hacen a un flujo y especialmente al flujo vehicular. Lugares k-acotado: sólo una marca por lugar, un vehículo por lugar Árbitro: resolvemos situaciones de competencia, entre varios vehiculos para pasar por un lugar Fuente: Lugar no acotado. Corresponde al lugar de origen por donde entran los vehiculos a la estructura modelada (estacionamiento, ruta, inicio de la estructura vial modelada) Sumidero: Lugar no acotado. Corresponde al lugar de llegada de los vehiculos (estacionamiento, ruta, fin de la estructura vial modelada) Transiciones Con retardos: los retardos representan los tiempos verde y rojo de los semaforos. A pesar de que una transicion se pueda disparar porque tiene marcas en los lugares de entrada, no lo va a poder hacer si está retardada. Trabadas: Definimos una transición trabada, si sus lugares destino tienen una marca.

Desarrollo del prototipo ATAC
Análisis de Tránsito Asistido por Computadora Desarrollo de un prototipo que sea capaz de Modelar una estructura vial fija (5 esquinas) con RdP Ejecutar la RdP y determinar si la estructura provoca congestionamientos y retardos Paradigma OO Lenguaje C++ BD MySql Tortoise (SVN) Tiempo: 3 min. Para comprobar la validez del modelado, desarrollamos un prototipo, un software que permita, a grandes rasgos: Modelar una estructura vial (vehiculos, carriles, Sentidos, semaforos, probabilidades, bloqueo de carriles, contiguidades y cantidad de vehiculos de entrada) con RdP Ejecutar la RdP y determinar a partir de las propiedades que cumpla o no la red construida, si la estructura vial dada provoca congestionamientos y retardos La estructura vial modelada es fija, las 5 esquinas de belgrano, 20 de febrero y paso. Elegimos esta esquina porque ha cambiado varias veces. En Paradigma OO si bien no es el mas eficiente, fue el que nos resultó más natural para representar la realidad. Sobre todo a partir de la representación gráfica de las rdp y de la analogía de ésta con la estructura vial. Necesitamos un lenguaje que soporte OO. Los lenguajes que compitieron fueron java y c++. Escogimos C++ por las nuevas librerias que incorporaba el framework 3.5 de Visual Studio y por la interfaz gráfica. Para la definición de una estructura vial, utilizamos una base de datos MySql. Son muchas variables y muchas relaciones entre ellas, con lo cual era mas sencillo modelar una BD que utilizar un archivo de texto. Algo que nos fue de suma utilidad a la hora de trabajar en equipo, fue mantener versionado el trabajo mediante una herramienta llamada Tortoise. El tortoise es un cliente SVN que en nuestro caso utiliza el ASSEMBLA (servidor gratuito).

Componentes Tiempo: 4 min. Obs.: Acá va a mostrar un diagrama de los componentes y una relación entre ellos. Hay que hacer que se vea bien. Definimos tres módulos del sistema: GUI, RdP y Ejecución. El módulo GUI consiste en todo lo que respecta a la interfaz de usuario El módulo RdP es el algoritmo que convierte la estructura vial en una RdP El módulo Ejecución es el que ejecuta la red y obtiene los resultados para el usuario.

GUI: Interfaz de usuario Tiempo: 5 min Dado que desarrollamos un prototipo, En un principio habíamos determinado hacer una interfaz de usuario austera a modo “líneas de comando”, pero al momento de tomar conocimiento de la cantidad de variables que era necesario determinar para modelar una intersección, decidimos poner un mayor esfuerzo para simplificarle a un usuario y a nosotros mismos, la tarea de configurar. Confeccionamos una base de datos para almacenar las configuraciones y una interfaz gráfica interactiva para la configuración de las variables. Obs: Aqui se mostrará una imagen del SW con un link a él. Explicar, mientras se muestra, que todo se guarda en la bd. Que se pueden configurar y guardar distintos escenarios. Se deberán configurar las siguientes cosas: Habilitación/Deshabilitación de carriles Cambio de sentido de carriles Ajustes Carriles contiguos y sus probabilidades Cantidad de autos Semáforos y sus tiempos

RdP: Estructura vial Tiempo: 4 min El módulo RdP corresponde al algoritmo propiamente dicho. Esta es la parte del sistema que traduce los objetos de la interfaz en clases y que convierte esas clases en una RdP. Este módulo también requirió un esfuerzo extra ya que el algoritmo inicialmente lo habíamos definido de modo estructurado y hubo que convertirlo en objetos. El gráfico que observamos en esta diapositiva es la lectura de una estructura vial. Cuadra: Es la fracción de una calle, intersectada en los extremos por otras 2 calles. Toda cuadra pertenece a una única calle. Una cuadra posee un conjunto de cuadras contiguas. Además se le asigna una de dos direcciones posibles. Por ejemplo, una cuadra cuyos autos se trasladan de este a oeste o viceversa podrá tener dirección este o dirección oeste. En la definición de carril veremos con qué criterio asignar la dirección a la cuadra. Calle: representa un conjunto de cuadras concatenadas. En este conjunto de cuadras, cada una es la continuación de otra. CuadraContigua: Una cuadra contigua sólo existe en relación con otra cuadra. Representa la relación de proximidad entre dos cuadras. También posee una ubicación relativa a la cuadra a la que pertenece. CarrilContiguo: Un carril contiguo representa la adyacencia efectiva entre dos carriles. Posee además información sobre la conexión entre estos dos carriles: cuál es la probabilidad de que un auto pase del carril origen al destino y sus tiempos de semáforo. Punto cardinal: Es la clase más compuesta por las demás. Explicado de manera abstracta sólo representa los 8 puntos cardinales posibles. Cuando es asociado a otras clases es que obtiene significación. En un carril representa el punto cardinal al que se dirigen los autos que pasan por él. En una cuadra significa uno de los dos sentidos que pueden tener los carriles que le pertenecen a ella. Por último, en una cuadra contigua representa la ubicación de ella con respecto a la cuadra que la compone. Carril: Representa la vía por donde puede pasar una fila de autos. Esta clase se relaciona directa o indirectamente con todas las demás clases de la estructura vial. Por esta razón la siguiente etapa de procesamiento sólo necesita un conjunto de carriles como entrada. Los carriles son insertados en la cuadra a la que pertenecen teniendo en cuenta el sentido de la misma. Por ejemplo, una cuadra con sentido este deberá insertar primero los carriles que están más al norte. Así el orden de los carriles será de norte a sur. La siguiente figura lo ilustra claramente: (figura2) Cruce: Es la intersección de dos calles. Por cuestiones prácticas se decidió hacer que cada cruce contenga el conjunto de carriles que desembocan en él. En la figura anterior hay dos cruces. Al de la izquierda desemboca el segundo carril y al de la derecha los carriles primero y tercero. Por otro lado, el cruce contiene los lugares árbitros de la intersección, elementos de RdP de los que hablaremos en breve.

RdP: Construcción de la Red Tiempo: 4 min Obs: vamos aponer un link a la imagen de la red completa! Es muy grande por eso no se muestra aca Una vez definida la estructura vial, Cómo traducimos estos elementos en una RdP? Utilizando un algoritmo genérico que lo hace. Esta fue la base de nuestro proyecto. El algoritmo es OO, los objetos que se muestran son los que determinan la estructura de la red. Lo que finalmente le va a interesar a la red propiamente dicha, para ser ejecutada, van a ser las transiciones y los lugares y la relación entre ellos. La segunda imagen nos muestra cómo se modela una intersección de una esquina con 2 calles y un carril cada una. Finalmente vemos (haciendo click en el link) como queda la red al modelar las cinco esquinas de belgrano, paso y 20 de febrero, con la configuración actual. Obs2:Habría que ver si detallamos mas el algoritmo (que es lo mas importante) aunque no se si nos va a dar el tiempo prara explayarnos mucho. Habría que buscar una síntesis mejor porque con esa imagen no explicamos mucho el algoritmo.

Ejecución Evolucionan los marcados Se analizan las propiedades Vivacidad Conservatividad Seguridad Se obtienen resultados Esperas Bloqueos Cantidad de vehículos que entraron /salieron de cada carril Tiempo: 3 min El módulo final es el de la Ejecución de la RdP. Es la parte encargada de hacer evolucionar el flujo en la RdP construida y, a partir de las propiedades que ésta cumple o no, interpretar los resultados para mostrar al usuario. Cuando desarrollamos este módulo redefinimos la aplicación del algoritmo. En la ejecución - Evolucionan los marcados a través de los disparons de las transiciones - A partir de las propiedades de la RDP de Conservatividad, Seguridad y Vivacidad, definimos: Espera: Veces que una transición estuvo bloqueada durante dos evoluciones consecutivas. Bloqueo: Ninguna transición de la red pudo dispararse en una evolución y la siguiente. Cantidad de vehículos que salieron de la estructura vial: Cantidad de marcas en los lugares sumidero en el marcado final. Cantidad de vehículos que entraron a la estructura vial: Cantidad de marcas en los lugares fuente en el marcado inicial menos cantidad de marcas en los lugares fuente en el marcado final. Cantidad de vehículos que entraron a un carril: suma de cambios en el marcado (con marca – sin marca) de los lugares de entrada de un carril. Cantidad de vehículos que salieron de un carril: suma de cambios en el marcado (con marca – sin marca) de los lugares de salida de un carril.

Ejecución Tiempo: 4 min Los siguientes informes, corresponden a las salidas del sistema, luego de la ejecución. Obtenemos dos tipos de informes: Para un usuario que sólo necesita los resultados interpretados para el análisis del tránsito, como cuántos autos pasaron por cada lugar, cuántos esperaron, si hubo bloqueos, etc. Para un usuario conocedor de las RdP que puede entender las propiedades de la red, con las que se interpretan los resultados

Validación del Prototipo
Realidad vs Modelo Tiempo: 4 min. Obs.: Falta la animación. Para validar el prototipo, modelamos una inetrsección específica las 5 esquinas (grafico 1) Modelamos esa estructura (figura 2) y luego tomamos mediciones (figura 3) Las siguientes mediciones fueron las que tomamos en el lugar un día de la semana a las 18:00hs durante 10 minutos (600 s): Finalmente comparamos las ejecuciones del sistema con las mediciones realizadas ->next. Carril 3 9 10 13 14 71 72 75 76 Cant. Vehículos 33 65 136 129 56 79 62

Validación del Prototipo
Resultados Mediciones Resultados del sistema Tiempo: 2 min. El primer gráfico muestra la desviación de lo medido (los puntos rojos) con respecto a distintas ejecuciones del modelo (cambiando probabilidades de trayectorias de los vehículos). El segundo gráfico muestra la diferencia entre el tiempo real transcurrido y el tiempo de los distintos modelados. Como podemos ver en los gráficos los valores se han acercado a la realidad, aunque no hemos modelado algunas de las variables de la realidad como tamaños de vehículos, aceleración de los vehículos, rotondas, topografía, estado de las vías según el clima, comportamiento de los conductores.

Métricas Prototipo Código Fuente Documentos: 20 Archivos 81
Líneas de código 12176 Comentarios 3915 Clases 35 Formularios 3 Tiempo: 2 min. Obs.: Las métricas es para discutir si las ponemos o no... Es como para que vean la dimensión del proyecto En cuanto a la magnitud del prototipo, les mostramos a continuación las mediciones que realizamos sobre el producto final entregado. La codificación del prototipo fue una de las tareas que más tiempo nos llevó. A partir de la siguiente tabla se puede ver la magnitud del código fuente del prototipo. En cuanto a la documentación realizamos 20 documentos, entre ellos: Presentación del proyecto Documento de Requerimientos Planificación Inicial 4 Minutas de reunión 2 Informes de avance de proyecto 1 Presentación Manual de RdP Organización de la Bibliografía Documento de diseño de la interfaz de usuario Documento de diseño detallado Manual del desarrollador Documento de descripción del código fuente generado con DoxyGen Manual de usuario Memorias del Proyecto Documento de validación del Prototipo y definición de RdP ATAC Documentos: 20

Métricas Esfuerzo: 2153 horas El proyecto nos llevó 2153 horas.
Tiempo: 2 min. Obs.: Las métricas es para discutir si las ponemos o no... Es como para que vean la dimensión del proyecto El proyecto nos llevó 2153 horas. El siguiente gráfico muestra el porcentaje de horas invertidas en cada etapa sobre el total de horas del proyecto. Aunque predomina la etapa de implementación, se puede observar claramente que la capacitación y el diseño cumplieron un papel significativo.

Planificado vs Realidad
Métricas Planificado vs Realidad Planificado 1783 hs Real 2153 hs Tiempo: 2 min. La cantidad de horas entre los tres integrantes invertidas en el proyecto superó en un 17% las horas planificadas. En el siguiente gráfico se puede observar el contraste de las desviaciones entre las actividades planificadas y las realizadas. Lo más notorio de estos resultados fue la diferencia en las actividades de capacitación y codificación. Esto se debe a que no le dedicamos suficiente tiempo a la investigación de RdP, lo cual, al momento de la codificación produjo redefiniciones y rediseños. Nuestra idea original consistía en que la investigación y el diseño fueran lo primordial y no tanto la codificación, pero recién cuando comenzamos a implementar nos dimos cuenta de las necesidades reales. Asimismo, la codificación nos implicó tiempo y esfuerzo extra que no teníamos pensado dedicar pero surgió la necesidad de hacerlo debido a que era la cara visible del producto ante el cliente y debía ser claro e intuitivo. Una actividad que descartamos fue la de sectorizar la totalidad del mapa porque no era objetivo del proyecto y nos concentramos en modelar una sola intersección para probar el algoritmo. Finalmente la coordinación estuvo presente a lo largo del proyecto a pesar de que no habíamos tenido en cuenta su importancia.

Planificado vs Realidad
Métricas Planificado vs Realidad Tiempo: 4 min. En cuanto a la fecha de finalización del proyecto, nos atrasamos 11 meses con respecto a la fecha de entrega estimada. Espeábamos terminar el 4 de Julio de 2008 y finalizamos el 14 de Junio de 2009. En gran medida la diferencia entre la fecha estimada y la fecha real de finalización se debió a que subestimamos la duración del resto de las actividades académicas que debimos realizar. En este gráfico podemos observar la razón de la desviación con respecto a la fecha entrega. En ciertos trimestres podemos observar que el proyecto final se vio opacado por el resto de las actividades académicas. Como por ejemplo los dos últimos trimestres del año 2008 en los que dedicamos todo el tiempo en la finalización de los proyectos de otras materias Se puede observar una caída importante hacia fines del año 2007 en la producción debido a que los integrantes Francisco Suárez y Leandro Cofré comenzaron actividades laborales en relación de dependencia. Durante dicho período el equipo de trabajo en su totalidad se encontraba en estado de desgano con respecto al proyecto y a la carrera, lo que trajo aparejado poca dedicación y escasos avances. Fue en esos momentos en que se hizo recurrente la frase “¿Por qué no hicimos el sistema para un hotel?”, por supuesto, sin desmerecer este tipo de desarrollos.

Conclusiones Cumplimos con los objetivos Coordinamos un proyecto real
Las RdP son adecuadas para modelar tránsito El prototipo fue aceptado por el cliente Aprendimos más que la teoría de RdP Coordinamos un proyecto real Hicimos un aporte a la comunidad Tiempo: 3 min. Obs.: Quizás algunas fotos como marca de agua por debajo de las letras Complimos con los objetivos iniciales del proyecto: Pudimos determinar que las RdP son propicias para modelar el tránsito, tanto porque es una herramienta muy intuitiva para modelar y por los resultados que obtubimos de la comparación entre las mediciones y lo modelado. Nuestro cliente se mostró más que satisfecho con el prototipo y destacó la potencialidad y utilidad del mismo. Sus comentarios principales giraron en torno a las configuraciones y la interpretación de los resultados proporcionados por el sistema. Incluso nos planteó la posibilidad de que uno de los integrantes a su cargo se interiorice más en la utilización del sistema para poder usarlo como herramienta de decisión. En cuanto al desarrollo profesional hemos superado nuestras propias expectativas. Comprobamos en un proyecto de esta envergadura que somos capaces de estudiar una teoría matemática, modificarla de acuerdo a nuevas necesidades de modelado y luego implementarla con un desarrollo de software. Aquí nos dimos cuenta de la importancia de haber hecho éste proyecto en lugar de otro menos complejo, aunque no menos importante, como “el sistema para un hotel”. Aprendimos que la planificación y coordinación de un proyecto son muy importantes para su desarrollo. Consideramos que nos ahorró mucho tiempo organizarnos desde el principio y no trabajar a la deriva. La definición de hitos y prioridades nos permitió conocer el grado de avance en cada momento. Aprendimos a definir prioridades para no “distraernos” del objetivo principal. También consideramos que pudimos adquirir un criterio para definir el límite entre “lo que hay que hacer” y “lo que se podría mejorar”. Esto fue de suma importancia al momento de darle un cierre al proyecto ya que tuvimos que priorizar el objetivo del proyecto para descartar las actividades que lo excedían. Al llegar al final del proyecto nos encontramos ampliamente satisfechos por haber logrado integrar la teoría con la práctica y con la realidad. Mientras definíamos los objetivos del proyecto no veíamos la magnitud del mismo, pero ahora entendemos que tiene un gran potencial. Ha dejado varios puntos de partida abiertos para otros proyectos similares a este que pudieran completar y robustecer el proyecto ATAC. Nos mostramos convencidos de la necesidad de mantener actualizada la documentación para evitar posibles errores. Congelar los requerimientos en un documento también nos ayudó a no distraernos en “mejorar el prototipo”, cosas que no hacían al objetivo del proyecto y que el cliente no necesitaba. Por otro lado creemos que es importante documentar esas posibles mejoras para los nuevos grupos que pudieran continuar, en el caso de un proyecto académico, o para nuevas versiones en el caso de un cliente.

Conclusiones Extensiones de ATAC
Abrimos una puerta a nuevos desarrollos Modelar nuevas variables como tamaño de vehículos, topografía, clima, rotondas, aceleración y desaceleración Mostrar la evolución progresiva del modelado Modelar el comportamiento de los conductores Sincronizar automáticamente los tiempos de los semáforos Tiempo: 2min. Obs.: Quizás algunas fotos como marca de agua por debajo de las letras El proyecto ATAC es una demostración tecnológica que abre el camino a nuevos desarrollos de gran aporte a la tecnología y a la comunidad. Hemos comprobado el potencial de ATAC y creemos que se puede mejorar para obtener un producto más completo. Proponemos nuevos objetivos para proyectos futuros: Modelar nuevas variables tales como distintos tamaños de vehículos, aceleración de los vehículos, rotondas, topografía, estado de las vías según el clima. Modelar otras estructuras viales. Mostrar la evolución del flujo en tiempo real. Modelar el comportamiento de los conductores. Asistir a la programación de los semáforos.

Demostración Tiempo: 3 min. Obs: Link al video.
A continuación les mostraremos uno de los efectos que puede llegar a tener la utilización del prototipo.

Preguntas Tiempo: 15 min. Preguntas posibles Cuán genérico es el SW
Cuán fácil modelar otra estructura ¿Sirve para otros flujos que no sean el transito? ¿Hubieron retrasos en el proyecto?

ATAC Proyecto Final Análisis de Tránsito Asistido por Computadora

Presentaciones similares

Presentación del tema: "ATAC Proyecto Final Análisis de Tránsito Asistido por Computadora"— Transcripción de la presentación:

Presentaciones similares

Sobre el proyecto

Feedback

Iniciar la sesión

Autorizarse a través de una red social:

ATAC Proyecto Final Análisis de Tránsito Asistido por Computadora

Presentaciones similares

Presentación del tema: "ATAC Proyecto Final Análisis de Tránsito Asistido por Computadora"— Transcripción de la presentación:

Presentaciones similares

Sobre el proyecto

Feedback