Simulación y control de un sistema de trenes metropolitanos

141 

(1)PONTIFICIA UNIVERSIDAD CATOLICA DE CHILE ESCUELA DE INGENIERIA. SIMULACIÓN Y CONTROL DE UN SISTEMA DE TRENES METROPOLITANOS. PABLO GRUBE KREBS. Tesis para optar al grado de Magíster en Ciencias de la Ingeniería. Profesor Supervisor: ALDO CIPRIANO. Santiago de Chile, (julio, 2009) © 2009, Pablo Grube Krebs.

(2) PONTIFICIA UNIVERSIDAD CATOLICA DE CHILE ESCUELA DE INGENIERIA. SIMULACIÓN Y CONTROL DE UN SISTEMA DE TRENES METROPOLITANOS. PABLO GRUBE KREBS. Tesis presentada a la Comisión integrada por los profesores: DIEGO CELENTANO DORIS SÁEZ JUAN ENRIQUE COEYMANS ALDO CIPRIANO. Para completar las exigencias del grado de Magíster en Ciencias de la Ingeniería. Santiago de Chile, (julio, 2009).

(3) A mis padres, por todo su apoyo y ánimo. ii.

(4) AGRADECIMIENTOS Me gustaría agradecer a todos aquellos que colaboraron, directa o indirectamente, en la elaboración de esta tesis. En particular, a los señores Conrad Ziebold (jefe del Departamento de Proyectos), Arturo Didier y Luz María Velasco, del Metro de Santiago, así como al señor José Miguel Obando, gerente de operaciones del Metro de Valparaíso, por su disponibilidad para recibirme y hacer sugerencias para mejorar el simulador desarrollado. También a los profesores Juan Carlos Muñoz y Ricardo Giesen, del Departamento de Transporte de la Pontificia Universidad Católica de Chile, que igualmente aportaron con sugerencias e ideas. A Felipe Delgado, que me facilitó papers y resultados de su investigación. A Felipe Zúñiga, que me aportó algunos resultados de su propia tesis para hacer las pruebas de simulación. Agradecimientos especiales a los miembros de mi Comisión de Defensa, que se dieron el tiempo de leer el borrador de la tesis y corregir errores e imprecisiones y sugerir mejoras en la forma de presentar el material: los profesores Diego Celentano, Doris Sáez y especialmente a don Juan Enrique Coeymnas, que además me dio el contacto con el Metro de Valparaíso y me regaló parte de su tiempo acompañándome hasta allá. Y finalmente y por sobre todo, a mi profesor supervisor, don Aldo Cipriano, que me dedicó una gran cantidad de tiempo, estuvo siempre atento al progreso y forma que tomaba el trabajo y siempre estuvo disponible para aportar sugerencias o dar la ayuda que yo requiriera.. iii.

(5) INDICE GENERAL Pág. DEDICATORIA .......................................................................................................... ii AGRADECIMIENTOS .............................................................................................. iii INDICE DE TABLAS ............................................................................................... vii INDICE DE FIGURAS ............................................................................................. viii RESUMEN.................................................................................................................. ix ABSTRACT ................................................................................................................. x 1.. INTRODUCCIÓN .............................................................................................. 1 1.1 Hipótesis de trabajo .................................................................................... 1 1.2 Objetivos .................................................................................................... 2 1.3 Alcances ..................................................................................................... 2 1.4 Contenido ................................................................................................... 4. 2.. ESTADO DEL ARTE ........................................................................................ 5 2.1 Simuladores de sistemas de transporte ....................................................... 5 2.2 Estrategias de control ................................................................................. 6 2.2.1 Estrategias de planificación ............................................................. 7 2.2.2 Estrategias de control ....................................................................... 8 2.2.3 Respuesta a fallas ........................................................................... 10. 3.. SOFTWARE SIMULADOR DE RED DE TRENES METROPOLITANOS . 12 3.1. Preliminares.............................................................................................. 12 3.2 Descripción del simulador........................................................................ 14 3.2.1 Características generales y parámetros de la red ........................... 14 3.2.2 Condiciones iniciales ...................................................................... 19 3.2.3 Cálculo de energía ......................................................................... 20 3.2.4 Salidas de la simulación................................................................. 22 3.2.5 Interacción con el control en tiempo real ...................................... 24 iv.

(6) 3.3 Funcionamiento del simulador ................................................................. 27 3.3.1 Paradigmas empleados................................................................... 27 3.3.2 Implementación en el simulador .................................................... 30 3.4 Interfaz de operación ................................................................................ 33 4.. APLICACIÓN DEL SIMULADOR PARA EVALUAR ESTRATEGIAS DE CONTROL ....................................................................................................... 36 4.1 Antecedentes ............................................................................................ 36 4.2 Control experto......................................................................................... 37 4.3 Control Predictivo .................................................................................... 38 4.3.1 Información de estado requerida en línea ...................................... 40 4.3.2 Características del modelo ............................................................. 41 4.3.3 Parámetros y variables ................................................................... 44 4.3.4 Mecánica del modelo ..................................................................... 45 4.3.5 Función objetivo ............................................................................ 50 4.3.6 Restricciones .................................................................................. 50 4.3.7 Control de despacho desde terminales ........................................... 51 4.3.8 Limitación del número de trenes involucrados .............................. 52 4.3.9 Optimización con algoritmos genéticos......................................... 52 4.4 Resultados obtenidos ................................................................................ 55 4.4.1 Características de la línea de prueba .............................................. 55 4.4.2 Resultados de comparación entre estrategias ................................ 55 4.4.3 Resultados variando parámetros del controlador predictivo ......... 62. 5.. CONCLUSIONES Y RECOMENDACIONES ............................................... 69 5.1. Conclusiones ............................................................................................ 69 5.2 Recomendaciones para trabajo futuro ...................................................... 71. BIBLIOGRAFIA ....................................................................................................... 74 A N E X O S .............................................................................................................. 77 Anexo A: CLASES DEL SIMULADOR................................................................... 78 A.1 Línea ......................................................................................................... 78 A.2 Estación: ................................................................................................... 79 v.

(7) A.3 Tren .......................................................................................................... 80 A.4 Combinación ............................................................................................ 84 Anexo B: MANUAL DE USO DEL SIMULADOR ................................................. 85 B.1 Interfaz gráfica ........................................................................................... 85 B.2 Interacción con software de cómputo ........................................................ 95 Anexo C: ARTÍCULO ENVIADO AL JOURNAL OF MATHEMATICS AND COMPUTERS IN SIMULATION ................................................................... 99 Anexo D: ARTÍCULO PRESENTADO EN EL XVIII CONGRESO DE LA ASOCIACIÓN CHILENA DE CONTROL AUTOMÁTICO (ACCA 2008)111 Anexo E: ARTÍCULO ENVIADO AL XIV CONGRESO CHILENO DE INGENIERÍA DE TRANSPORTE (CCIT 2009) ......................................... 118. vi.

(8) INDICE DE TABLAS Pág. Tabla 4-1. Resultados en tiempos de espera y de viaje en lazo abierto ........................... 56 Tabla 4-2. Resultados en headway de entrada y en trenes en espera en lazo abierto ..... 57 Tabla 4-3. Resultados en tiempos de espera y de viaje de aplicar control experto simple ...................................................................................................................................... 58 Tabla 4-4. Resultados en headway de entrada y en trenes en espera de aplicar control experto simple .............................................................................................................. 59 Tabla 4-5. Resultados en tiempos de espera en estaciones (en minutos/pasajero) de aplicar control predictivo sobre holding, con M0=3 y D=300m .................................. 60 Tabla 4-6. Resultados en tiempos de viaje en trenes (en minutos/pasajero) de aplicar control predictivo sobre holding, con M0=3 y D=300m .............................................. 61 Tabla 4-7. Resultados en headway de entrada en estaciones (en segundos, como prom. y desv. est.) de aplicar control predictivo sobre holding, con M0=3 y D=300m ............ 61 Tabla 4-8. Resultados en número de trenes que quedan esperando por entrar a una estación de aplicar control predictivo sobre holding, con M0=3 y D=300 m .............. 62 Tabla 4-9. Resultados en tiempos de espera en estaciones (en minutos/pasajero) de aplicar control predictivo sobre holding y despachos, con M0=3 y D=300m.............. 64 Tabla 4-10. Resultados en tiempos de viaje en trenes (en minutos/pasajero) de aplicar control predictivo sobre holding y despachos, con M0=3 y D=300m ......................... 64 Tabla 4-11. Resultados en headway de entrada en estaciones (en segundos, como prom. y desv. est.) de aplicar control predictivo sobre holding y despachos, con M0=3 y D=300m ....................................................................................................................... 65 Tabla 4-12. Resultados en número de trenes que quedan esperando por entrar a una estación de aplicar control predictivo sobre holding y despachos, con M0=3 y D=300m ....................................................................................................................... 65 Tabla 4-13. Resultados en tiempos de espera en estaciones (en minutos/pasajero) de aplicar control predictivo sobre holding, con μ=0.5 y D=300m .................................. 66 Tabla 4-14. Resultados en tiempos de viaje en trenes (en minutos/pasajero) de aplicar control predictivo sobre holding, con μ=0.5 y D=300m .............................................. 66 Tabla 4-15. Resultados en headway de entrada en estaciones (en segundos, como prom. y desv. est.) de aplicar control predictivo sobre holding, con μ=0.5 y D=300m ......... 67 Tabla 4-16. Resultados en número de trenes que quedan esperando por entrar a una estación de aplicar control predictivo sobre holding, con μ=0.5 y D=300m ............... 67 Tabla 4-17. Resultados en tiempos de espera y de viaje de aplicar control predictivo sobre holding, con N=20, μ=0.5, M0=3 y D=300m ...................................................... 68 Tabla 4-18. Resultados en headway de entrada y en trenes en espera de aplicar control predictivo sobre holding, con N=20, μ=0.5, M0=3 y D=300m .................................... 68. vii.

(9) INDICE DE FIGURAS Pág. Figura 3-1. Diagrama general del simulador.................................................................... 12 Figura 3-2. Perfil de velocidad de un tren en un tramo de línea ...................................... 21 Figura 3-3. Diagrama del desarrollo de la simulación ..................................................... 32 Figura 3-4. Interfaz principal de la aplicación ................................................................. 34 Figura 3-5. Diagrama distancia-tiempo para una línea .................................................... 34 Figura 3-6. Diagrama de subida de pasajeros para una estación...................................... 35 Figura 4-1. Esquema del sistema de control automático.................................................. 37 Figura 4-2. Representación del sistema de trenes empleada por el modelo del control .. 42 Figura 4-3. Modo en que proceden los pasos de la simulación ....................................... 43 Figura 4-4. Gráfico de los tiempos de espera de pasajeros .............................................. 48 Figura B-1. Pantalla splash de inicio ............................................................................... 85 Figura B-2. Interfaz principal de la aplicación................................................................. 86 Figura B-3. Cuadro de parámetros principales de línea ................................................... 87 Figura B-4. Especificación de una matriz origen-destino ................................................ 88 Figura B-5. Especificación de recorridos expresos de la línea ........................................ 88 Figura B-6. Ingreso de parámetros de llegada de pasajeros a estaciones......................... 89 Figura B-7. Parámetros de las ramas................................................................................ 89 Figura B-8. Parámetros de las estaciones de combinación .............................................. 90 Figura B-9. Condiciones iniciales en una estación .......................................................... 91 Figura B-10. Condiciones iniciales en un tramo de línea ................................................ 91 Figura B-11. Configuración del Controlador ................................................................... 92 Figura B-12. Resultados para una línea ........................................................................... 93 Figura B-13. Diagrama distancia-tiempo para una línea ................................................. 94 Figura B-14. Diagrama de subida de pasajeros para una estación ................................... 94. viii.

(10) RESUMEN El control de sistemas de transporte en áreas metropolitanas es un tema que ha recibido mucha atención desde hace bastantes años, y acerca del cual se han ensayado diferentes técnicas, tanto de planificación como de control en tiempo real. En el marco del proyecto ADI-32 se están probando distintas alternativas enfocadas a buses. Esta tesis es un esfuerzo por extender estas ideas al caso de trenes metropolitanos, o metros. El trabajo se divide en dos partes. La primera y principal corresponde al desarrollo de un software capaz de simular tanto la operación de los trenes en las líneas como el movimiento de los pasajeros. El simulador emplea los paradigmas de programación orientada a objetos y simulación basada en eventos, y es de tamaño reducido, rápido y fácil de usar. Su utilidad principal es la evaluación de estrategias de control tanto en como fuera de línea, para lo cual puede interactuar con funciones programadas por el usuario en MATLAB o SCILAB, en las que éste puede ensayar con gran flexibilidad estrategias de control de diverso grado de complejidad. En la segunda parte de la tesis se describe la aplicación del simulador al desarrollo de dos estrategias de control que usan información en tiempo real. La primera corresponde a un control experto simple que emplea una regla heurística sencilla para regularizar los headway o intervalos entre pasadas sucesivas de metros por cierta estación. La segunda, bastante más compleja, es una estrategia de control predictivo, que usa un modelo del sistema para llegar a una solución óptima con respecto a los tiempos de espera y de viaje de los pasajeros. La tesis incluye una comparación por simulación de ambas estrategias con el caso en lazo abierto (que no usa información en tiempo real) considerando diversos indicadores. Palabras Claves: Metro, Tren Metropolitano, Simulación, Control en Tiempo Real. ix.

(11) ABSTRACT Control of bus systems in urban areas is a subject that has received much attention for several years now, and about which many different techniques have been tried out, both of the scheduling and of the real-time control variety. In the context of the ADI-32 project, different alternatives are being tested with an emphasis on buses. This thesis represents an effort to extend these ideas to the case of metropolitan trains, or subways. The work consists of two parts. The first and most important one involves the development of a software application capable of simulating both train operation in lines and passenger movement. The simulator uses the object-oriented programming and the event-driven simulation paradigms, and is small-sized, fast and easy to use. Its main application is for evaluation of both online and offline control strategies, for which it can interact with functions programmed by the user in either MATLAB or SCILAB, where he can try out control strategies of various levels of complexity with great flexibility. These can act on a number of manipulated variables. The second part of the thesis describes the application of the simulator to the development of two control strategies that make use of information gathered in real time. The first involves a simple expert control system which uses a heuristic rule to regularize headways. The second and more complex strategy corresponds to a predictive control strategy, which uses a model of the system to arrive to a solution that is optimal with respect to passenger waiting and travel times. The thesis includes a comparison made by simulation between both strategies and the open-loop case (which doesn’t make use of real-time gathered information) considering a variety of indicators. Keywords: Metro, Subway, Metropolitan Train, Simulation, Real-Time Control. x.

(12) 1. 1.. INTRODUCCIÓN. La gestión de los sistemas de transporte público es un tema que ha recibido considerable atención durante los años. La principal causa es que es mucho menos costoso optimizar la operación del sistema en base a la infraestructura ya existente que construir infraestructura nueva, lo que en algunos casos ni siquiera es posible debido a restricciones físicas. Para gestionar adecuadamente estos sistemas en caso de cambios en la demanda o situaciones imprevistas o que de alguna forma se desvían de lo que estaba planificado de antemano, se han propuesto diversas estrategias y técnicas, pero las más recientes son las que tienen relación con el uso de información obtenida en tiempo real del estado del sistema. El proyecto ADI-32, que actualmente está siendo ejecutado en conjunto por un grupo de investigadores de la Pontificia Universidad Católica de Chile, la Universidad de Chile y la Universidad de los Andes, pretende proponer soluciones a algunos de los principales problemas planteados, especialmente en las áreas de medición de las variables relevantes (como el conteo de pasajeros en paraderos o estaciones) y en el uso de dicha información para conformar un sistema de gestión en tiempo real de la flota. En particular se han ensayado alternativas basadas en control experto difuso y control predictivo híbrido, limitadas al control de buses. El actual trabajo es un intento de expandir estas ideas al caso de una red de trenes metropolitanos, o metro, produciendo herramientas que asistan en la elaboración de este tipo de técnicas. 1.1. Hipótesis de trabajo. La hipótesis de este trabajo es que un sistema de apoyo a la operación basado en modelos predictivos no lineales del sistema global de metro y ocupando información obtenida en tiempo real del estado del sistema puede mejorar los tiempos de espera y de viaje de los pasajeros con respecto al caso sin control o con un esquema de control local simple..

(13) 2. 1.2. Objetivos. Este trabajo tiene dos objetivos principales interrelacionados, conducentes a intentar demostrar la hipótesis planteada. El primero es el desarrollo de un software de simulación de redes de metro. Dicho software debe cumplir con tener un tamaño razonable en cuanto al uso de memoria y otros recursos para facilitar la realización de pruebas rápidas como las que se hacen durante el desarrollo de nuevas estrategias de operación. Sin embargo, debe poseer el suficiente nivel de detalle para producir resultados útiles, y ser lo suficientemente general para admitir la mayor cantidad posible de situaciones, al menos como para representar fielmente la red del Metro de Santiago o del Metro de Valparaíso. Finalmente, debe permitir realizar pruebas de estrategias de control en tiempo real con gran flexibilidad para el usuario. El segundo objetivo es desarrollar una nueva estrategia de control en tiempo real basada en un esquema MPC (Model Predictive Control), que actúe sobre los tiempos de permanencia u holding de los trenes en las estaciones y sobre el despacho de los mismos desde los terminales. Su efectividad será probada por medio del simulador ya mencionado y comparada con el caso de sistema en lazo abierto (sin usar información obtenida en tiempo real) y con una estrategia heurística simple basada en reglas que usa sólo información en línea local. Se usarán dos indicadores principales, tiempo de espera global de los pasajeros en las estaciones y tiempo de viaje en los trenes, además de dos indicadores secundarios, headway promedio o intervalo promedio entre sucesivas entradas de trenes a una estación y número de veces que trenes se quedan esperando frente a una estación sin poder entrar. 1.3. Alcances. Durante el desarrollo de este trabajo, se le debe dar al simulador por lo menos toda la funcionalidad necesaria para servir como herramienta de prueba de las estrategias de control que se ensayarán en la segunda parte de la tesis. Además, se.

(14) 3. espera incorporar características adicionales, como manejo de líneas expresas, que den mayor flexibilidad y permitan modelar una red como la del Metro de Santiago; sin embargo, algunas pueden quedar como trabajo futuro. La interfaz debe ser lo suficientemente cómoda y fácil de usar como para hacer ágil la prueba de nuevas redes y estrategias operacionales, sin necesariamente poseer un nivel de software profesional; por ejemplo, basta que sea posible ver los gráficos de salida, pero no es necesario que sean editables y configurables como en una aplicación estilo MATLAB (The Mathworks, 2008) o SCILAB (Gomez et al., 1999). En cuanto a la estrategia de control predictivo, se actuará exclusivamente sobre dos variables manipuladas: tiempos de holding y despachos de los trenes desde los terminales. Como se verá. más adelante en el capítulo 4, ambas pueden. considerarse como una misma variable manipulada si se imaginan las colas de maniobra como estaciones adicionales en las que los trenes esperan un tiempo de holding antes de ser despachados. Otras variables sobre las que se pueda actuar no serán tomadas en cuenta. Se intentará minimizar sólo los tiempos de espera y tiempos de viajes de los pasajeros, dejando de lado otros indicadores como energía consumida. Se usarán estas dos variables para comparar la estrategia predictiva con la alternativa experta, además de las dos variables secundarias mencionadas en la sección 1.2; no se considerarán otras. La estrategia operará a nivel global del sistema, asumiendo conocidas las variables de estado del sistema (posición de los trenes, número de pasajeros en las estaciones, etc.); la medición de éstas queda fuera del alcance de esta tesis. Asimismo, no se considerará el problema de comunicar las decisiones del sistema de control central a los trenes. Finalmente, se asumirá un funcionamiento normal del sistema, dejando fuera el problema de recuperación ante fallas e imprevistos mayores..

(15) 4. 1.4. Contenido. El capítulo 2 presenta el estado del arte de los trabajos realizados en las áreas relacionadas con la tesis, tanto en simulación como en control de sistemas de transporte público. El capítulo 3 describe el simulador desarrollado. La sección 3.1 es una introducción general. La sección 3.2 da una descripción general, funcional, del simulador, incluyendo parámetros, mecanismo de interacción con funciones de control en tiempo real definidas por el usuario y resultados que entrega. La sección 3.3 entrega información de los paradigmas usados en el simulador y la forma en que se usan durante el desarrollo de la simulación. La sección 3.4 da una breve descripción de la interfaz de operación. El capítulo 4 presenta estrategias de control que se pueden probar con el simulador. La sección 4.1 explica en términos generales en qué consiste el control automático y cómo se aplica a un sistema de trenes. La sección 4.2 describe un método de control experto muy sencillo y local basado en reglas. La sección 4.3 detalla un sistema de control más complejo del tipo predictivo, describiendo el modelo empleado para ello, la función objetivo y las restricciones. Además ofrece una extensión para considerar como variables manipuladas los despachos desde terminales además de los holding en estaciones. La sección 4.4 muestra resultados comparados de ambas técnicas contra el caso en lazo abierto. El capítulo 5 contiene las conclusiones. La sección 5.1 las detalla y la 5.2 da sugerencias para extensiones y trabajo futuro..

(16) 5. 2.. ESTADO DEL ARTE. A continuación se presenta una breve reseña de algunas publicaciones y desarrollos existentes en las áreas cubiertas por la tesis. 2.1. Simuladores de sistemas de transporte. Existen tanto paquetes de software de simulación comerciales como resultados de investigaciones académicas. A continuación se indican algunos de los más conocidos, junto con sus diferencias respecto de lo que se propone en esta tesis. Entre los simuladores más usados está el Quadstone Paramics (Quadstone, 2006). Es capaz de producir microsimulaciones (simulaciones que llegan al nivel de vehículos individuales) con un gran nivel de detalle y entregar resultados gráficos en forma de vídeos tridimensionales del movimiento de los vehículos. Permite crear redes de cualquier tamaño y ofrece una gran capacidad de personalización, incluyendo la posibilidad de interactuar con software durante la simulación para proveer control en tiempo real del sistema. Capacidades similares ofrece el PTV Vissim (PTV, 2008), otro microsimualdor de gran escala y potencia. Similar es el TSS Aimsun (Barceló y Casas, 2003), que tiene capacidad para representar tres tipos de modelos: asignación de tráfico estática (donde los vehículos se tratan a nivel agregado), un simulador mesosoico (para redes grandes; abarca vehículos individuales pero los trata de una forma simplificada) y un microsimulador. Sin embargo, los tres productos son costosos y exigen tiempo para familiarizarse con su uso; además, ninguno tiene soporte específico para sistemas de trenes. Un simulador enfocado específicamente a trenes es el OpenTrack (Nash y Hürlimann, 2004), que se basa en una combinación de simulación orientada a eventos y continua. Da muchas posibilidades de personalización de la línea y los itinerarios de viaje y entrega la información de salida ordenadamente en diagramas y gráficos. Sin embargo, una característica que no ofrece es la posibilidad de hacer control en tiempo real del sistema, que es lo que interesa hacer en esta tesis..

(17) 6. En el ámbito académico, Paolucci y Pesenti (1999) proponen un software basado en eventos, orientado a objetos y enfocado específicamente a sistemas de metro subterráneo, el cual ofrece capacidades de control en tiempo real además de soporte para el diseño de itinerarios. Kanacilo y Verbraeck (2005), por su parte, proponen un entorno de apoyo a la toma de decisiones basado en simulación para el diseño del control de la red. Basado en un esquema orientado a objetos, permite representar los distintos elementos del sistema mediante formalismos diferentes (principalmente continuos o discretos), diseñarlos en forma distribuida y acceder a sistemas de información externos. Sin embargo, el paquete es bastante complejo y, al menos en su fase de desarrollo actual, no permite control en tiempo real. Baohua et al. (2007) presenta una alternativa de simulación para trenes múltiples basada en cálculos de tracción, usando un enfoque orientado a objetos y una estructura modular. Facilita el diseño de itinerarios y el estudio de relaciones entre demoras y variación de headway o intervalos de tiempo entre pasadas sucesivas de trenes por una estación, pero, nuevamente, no ofrece soporte para control en tiempo real. Ortiz (2007) propone un simulador enfocado a hacer pruebas de operación en torno al encierre y reposición de trenes al sistema, durante el traspaso de horario valle a horario punta o viceversa. Permite modelar los distintos aspectos del sistema, desde líneas hasta restricciones de operación, y provee una interfaz gráfica basada parcialmente en Microsoft Excel. Sin embargo, está enfocado principalmente en probar maniobras de encierre y reposición de trenes, y deja de lado otros aspectos operacionales como el movimiento de los pasajeros y el control en tiempo real. 2.2. Estrategias de control. A lo largo de los años se han propuesto muchas estrategias de control para sistemas de trenes, algunas enfocadas a la planificación fuera de línea y otras al control en tiempo real en línea. Casos particulares de estas últimas son las.

(18) 7. diseñadas específicamente para responder a fallas o disrupciones a la operación normal. 2.2.1 Estrategias de planificación Cury et al. (1980) proponen optimizar los tiempos de headway o permanencia de trenes en estaciones a partir de un modelo basado en una representación matricial del problema. Su función objetivo incluye el tiempo de espera de pasajeros, el total de trenes en la línea y la diferencia entre el número deseado y real de pasajeros en las estaciones. Lo resuelven mediante programación matemática de gran dimensión. Higgins et al. (1997) proponen una serie de técnicas heurísticas para resolver el problema. de. optimización. de. la. planificación,. el. cual. es. NP-Hard. (computacionalmente difícil de resolver) con respecto al número de conflictos que se presentan. Las técnicas emplean heurísticas de búsqueda local, búsqueda tabú, algoritmos genéticos y algoritmos híbridos. Radtke y Hauptmann (2004) presentan el software RailSys, que emplea técnicas de simulación microscópica síncrona para encontrar horarios de salida óptimos, considerando características de los trenes y de la infraestructura y las restricciones operacionales definidas por el usuario. Törnquist (2005) hace una diferencia entre scheduling o cálculo de itinerarios táctico, scheduling operacional y re-scheduling; este último consiste en rehacer la planificación cuando hay desviaciones grandes respecto a ésta. A partir de esto, revisa una amplia gama de estrategias que se han propuesto a través de los años, desde algunas muy simples basadas en prioridades a otras que usan programación matemática y tecnología de agentes. Las soluciones anteriores dan distintas respuestas al problema de determinar previamente un itinerario fuera de línea. Sin embargo, si hay información en línea disponible, puede ser ventajoso emplearla para corregir los itinerarios (generalmente por medio del holding) en tiempo real, para así adecuarse a las nuevas condiciones de demanda o responder a distintas perturbaciones que se.

(19) 8. puedan producir. Tal es el objetivo de las estrategias de control en tiempo real, como las que se presentan en esta tesis y como las que se indican a continuación. 2.2.2 Estrategias de control Se trata de técnicas que emplean información obtenida en línea del estado del sistema para tomar decisiones en tiempo real. Esta información se basa en sensores dispuestos en el sistema e incluye localización automática de buses o trenes, conteo automático de pasajeros en estaciones o paraderos, etc. Dessouky et al. (2002) comparan algunas técnicas de control que usan estas tecnologías con otras que se basan sólo en información local en estaciones. Determinan que el uso de la tecnología produce mayores beneficios cuando el tiempo de slack (diferencia entre el tiempo que se le da a un bus para recorrer un trayecto dado y el que en la práctica le toma, en promedio, recorrerlo) es pequeño, cuando los headway son grandes y cuando hay muchos buses haciendo una conexión. En el marco del proyecto ADI-32, hay dos trabajos en la línea de minimizar tiempos de espera y de viaje de los pasajeros usuarios: Sáez et al. (2007) están trabajando en un sistema de gestión para sistemas de buses basado en control predictivo híbrido y un modelo no lineal resuelto con algoritmos genéticos. Las variables de control son el holding, la posibilidad de saltarse estaciones y la coordinación de los semáforos. Delgado et al. (2008), por su parte, están atacando un problema similar pero desde una perspectiva de programación matemática, usando como variables de control la permanencia de los buses en los paraderos y la posibilidad de dejar pasajeros fuera de los buses. Dentro del proyecto se han investigado además técnicas expertas difusas más sencillas (Pillajo et al, 2007), basadas en reglas locales para regularizar los headway. Son modelos pensados para buses; el objetivo de este trabajo es usar ideas similares aplicándolas al caso de metros. Eberlain et al. (2001) emplean un modelo analítico determinístico del sistema, planteándolo como una función objetivo cuadrática (minimización de tiempos de espera) con restricciones lineales. Se actúa sólo sobre un conjunto de trenes según.

(20) 9. un esquema de horizonte móvil. Se aprovechan ciertas características del problema para llegar a una solución heurística que, según se demuestra, resulta ser óptima. Sin embargo, para que esto ocurra se realizan una serie de simplificaciones en el modelo que en ciertas circunstancias pueden ser poco realistas; en particular, se considera infinita la capacidad de los trenes y se dejan de lado las matrices origendestino, haciendo que los pasajeros que bajan en una estación sean simplemente una fracción del total. Además, el holding sólo se aplica en una estación de la línea. De Schutter y van den Boon (2002) proponen también un esquema predictivo pero enfocado a trenes interurbanos. Las líneas pueden ramificarse, pero los trenes tienen sus rutas pre-fijadas; la idea es sincronizar las llegadas de trenes de forma que se respete en lo posible el itinerario predeterminado y los pasajeros que necesiten hacer conexiones entre trenes puedan realizarlas con tiempo suficiente. Para esto se definen restricciones de dos tipos: de itinerario (los trenes no pueden salir de una estación antes del tiempo preestablecido) y de conexión (dos trenes que tienen una conexión deben coincidir una cierta cantidad de tiempo en la misma estación); las primeras son inviolables y las segundas pueden romperse incurriendo en un costo en la función objetivo. Además se permite actuar sobre la velocidad de los trenes, también a un costo. El problemas se resuelve usando ELCP (Extended Linear Complementarity Problem). Una limitación es que en cada ciclo o paso de predicción se asigna a cada tramo de línea uno (y sólo uno) de los trenes; además, esta estrategia se enfoca en lograr cumplir las restricciones (los términos de la función objetivo sólo incluyen costos asociados a romperlas o a cambiar la velocidad) en lugar de en disminuir directamente los tiempos de espera o de viaje. Las anteriores características le quitan flexibilidad al algoritmo para casos con menores headway como una línea de metro. Zhao et al. (2003) proponen una solución basada en una arquitectura multi-agente, en que los agentes corresponden a paradas y buses. Al aproximarse, deben negociar localmente en base a la optimización conjunta de funciones de costo.

(21) 10. marginales definidas para cada uno de forma de determinar el tiempo de holding a aplicar. También se introduce una alternativa para considerar los paraderos aguas abajo del actual. Sin embargo, a pesar de esta última adición el algoritmo no puede hacer una evaluación realmente global del sistema para la optimización, y el hecho de que la solución se obtenga analíticamente exige simplificar aspectos del problema como la capacidad de los buses, que se considera infinita. Fu et al. (2003) basan su estrategia en la re-planificación de itinerarios, actuando sobre el skipping (capacidad de saltarse paraderos) dinámico de los buses, aplicado sólo bus por medio. Se trata de un problema no lineal con variables binarias, que se resuelve exhaustivamente. Se hacen varias simplificaciones, incluyendo asumir capacidad infinita y que los buses nunca se adelantan entre sí, además de demoras fijas para la subida y bajada de pasajeros en paraderos. Por otro lado, el skipping dinámico es una alternativa confusa para los pasajeros, que deben estar muy atentos para saber si el bus actual parará en su destino o no; problema que se hace más relevante para el caso de metros debido a la mayor frecuencia. 2.2.3 Respuesta a fallas Schmöcker et al. (2005) hacen un recuento de las estrategias usadas por seis metros alrededor del mundo. Determinan en cuáles casos es más importante la puntualidad y en cuáles la regularidad en función de las frecuencias (headway bajo los 12 a 15 minutos se benefician más de la regularidad y viceversa), explicitan las posibles restricciones, listan los tipos de incidente según gravedad, explican el efecto propagador de los accidentes e identifican diez estrategias usadas por los metros. Es una descripción básica del tipo de técnicas más que un conjunto de estrategias completas. O’Dell y Wilson (1999) introducen una alternativa enfocada a dar respuesta a disrupciones cortas actuando sobre el holding y el short-turning (posibilidad de hacer que los trenes se “devuelvan” por la vía contraria en puntos específicos de la línea). Asumen una línea con ramas y proponen diversas alternativas según cuántos trenes se ven afectados, resolviendo cada uno mediante programación.

(22) 11. lineal entera. Esto exige linealizar las expresiones y aproximar la función objetivo, inicialmente cuadrática, por una lineal a tramos, lo cual introduce algunos problemas computacionales que se resuelven mediante trucos ad-hoc. Sin embargo, el nivel de detalle que se pierde sigue siendo relevante. Luethi et al. (2007) proponen una alternativa bastante general que divide el problema en dos: el de re-planificación en tiempo real del itinerario predefinido en respuesta a la violación de determinados umbrales y el de control del tren para ajustarse al nuevo itinerario. Es un enfoque que no intenta anticiparse a demoras futuras, sino que actúa sólo cuando se exceden los límites permitidos y entonces re-calcula el itinerario completo, esfuerzo excesivo para un sistema rápido y muy sujeto a perturbaciones como el de un metro..

(23) 12. 3.. SOFTWARE. SIMULADOR. DE. RED. DE. TRENES. METROPOLITANOS 3.1. Preliminares El software simulador fue diseñado como una alternativa rápida, eficiente y de bajo costo con respecto a los paquetes de simulación que existen en el mercado, específicamente con el objetivo de representar el comportamiento de una red de trenes metropolitanos como el Metro de Santiago o el Metro de Valparaíso. El simulador hace varios supuestos y simplificaciones respecto del sistema real que se describen más adelante; sin embargo, el nivel de detalle debiera ser suficiente para obtener una representación bastante fiel del comportamiento del sistema a nivel global. La figura 3-1 muestra un diagrama general del simulador. SOFTWARE SIMULADOR. INTERFAZ DE USUARIO. -Parámetros de la red -Condiciones iniciales SIMULADOR Resultados de la simulación Estado del sistema. LEYENDA Al principio y fin de la simulación Durante la simulación. Valores de variables manipuladas. CONTROL (SOFTWARE DE CÓMPUTO ). Figura 3-1. Diagrama general del simulador (Fuente: Elaboración propia) Como se observa en la figura, el software simulador consta de dos componentes principales. El usuario ingresa todos los parámetros de la red (número de líneas y estaciones, largos de líneas, tasas de llegada, estaciones de transferencia, etc.), así.

(24) 13. como las condiciones iniciales para la simulación (posición inicial de los trenes, número de pasajeros en cada punto del sistema, etc.) a través de una interfaz gráfica. Luego da la orden de ejecutar la simulación. Ésta procede hasta el final y entrega de vuelta una serie de resultados a la interfaz (indicadores de desempeño e historia de la simulación) para que el usuario pueda consultarlos, en forma de números o gráficos. Como ya se indicó en la introducción, el detonante para querer desarrollar un nuevo simulador es incorporar la capacidad de hacer pruebas con distintas formas de operación de una forma muy flexible y posiblemente incorporando información en tiempo real del estado actual del sistema. La forma en que se hace esto es que durante el desarrollo de la simulación, al ocurrir ciertos eventos, el simulador invoca una función escrita por el usuario en un software de cómputo externo (MATLAB o SCILAB) enviándole toda la información disponible acerca del estado del sistema (posición de los trenes, número y ubicación de los pasajeros, etc.) en ese momento. La función debe responder indicando qué variables manipuladas se desea alterar. Las variables sobre las que es posible actuar son los tiempos holding, es decir el tiempo que un tren debe permanecer en la siguiente estación, las velocidades medias de los trenes en sus recorridos entre estaciones, los tiempos en que deben ser despachados los próximos trenes desde los puntos terminales de las líneas y los tiempos en que deben ser despachados desde ramas laterales que pueden existir en ciertos tramos de líneas. Es importante recalcar que el control no es parte integrante del simulador sino que debe ser implementado por el usuario en forma aparte; el simulador simplemente interactúa con él. El simulador mismo se describe a un nivel funcional en las secciones 3.2.1 y 3.2.3; en la sección 3.3 se entrega una explicación básica de la forma en que opera internamente. En cuanto a las entradas, los parámetros de la red se cubren junto con la descripción del simulador en la sección 3.2.1, mientras que las condiciones iniciales se tratan de forma aparte en la sección 3.2.2.. Las salidas con que. responde la interfaz se describen en la sección 3.2.4. Una descripción de la interfaz.

(25) 14. misma se deja para la sección 3.4. La interacción con el control (incluyendo entradas y salidas) se detalla en la sección 3.2.5., aunque, como ya se explicó, no se proponen estrategias específicas; algunas se proponen en el capítulo 4. El software fue desarrollado en el lenguaje de programación Microsoft C# (Microsoft, 2007), que tiene las ventajas de incluir todas las características de sus predecesores orientados a objetos, como C y C++, con una sintaxis simplificada, y de dar gran facilidad para el desarrollo de interfaces gráficas. 3.2. Descripción del simulador. 3.2.1 Características generales y parámetros de la red El software puede simular una red con cualquier número de líneas y estaciones. El usuario debe especificar los nombres de las líneas y estaciones y la distancia (en metros) entre estaciones sucesivas. Las líneas son bidireccionales; los trenes que van en un sentido se considera que están haciendo el recorrido de la “vía uno” y los que van en el sentido contrario, la “vía dos”. Para cada estación, debe especificarse la tasa de llegada de pasajeros para cada vía. Los pasajeros arriban según un proceso de Poisson compuesto; esto es, llegan en grupos con intervalos de tiempo exponenciales entre llegadas sucesivas. Se decidió hacerlo así por un lado porque exige menos esfuerzo computacional hacer que los pasajeros lleguen en grupos en lugar de simular cada llegada adicional, y por el otro porque el comportamiento de los pasajeros realmente tiende a seguir este patrón. Por ejemplo, en el caso de Santiago los pasajeros frecuentemente vienen de hacer una combinación con un bus y por lo tanto llegan en grupos grandes. Lo mismo ocurre con los horarios de cierre de las empresas, etc. El tamaño de los grupos es una variable aleatoria que distribuye Poisson. El usuario debe especificar la tasa de llegada de grupos λL (el intervalo medio entre llegadas sucesivas será entonces 1/λL) y el tamaño medio λG de los grupos. La tasa de llegada de pasajeros efectiva es entonces λLλG. El simulador da la posibilidad de especificar varios valores para estos dos parámetros junto con el intervalo de tiempo en que cada par.

(26) 15. de valores (λL, λG) es válido; de esta forma, la tasa de llegada de pasajeros puede ir variando a medida que transcurre la simulación, aunque en forma discreta: las tasas sólo pueden cambiar bruscamente en instantes bien definidos de tiempo. Los trenes se desplazan a lo largo de la línea transportando a los pasajeros. Cuando los trenes llegan a una estación, descargan todos los pasajeros que iban con destino a ella y cargan a los que están en el andén esperando, siempre y cuando quepan en el tren; en la implementación actual, todos los trenes de la línea tienen la misma capacidad, que debe ser fijada por el usuario. La proporción de pasajeros que van a cada estación es aleatoria y depende de las probabilidades definidas por el usuario en una matriz origen-destino, cuyas filas corresponden a estaciones de partida y cuyas columnas corresponden a estaciones de parada; cada elemento es la proporción de pasajeros de la estación de partida que van a la de llegada. La matriz es cuadrada, triangular superior y el número de filas/columnas es igual a uno menos que el total de estaciones en la línea. El usuario debe definir matrices origen-destino distintas para cada vía. Los trenes permanecen en cada estación al menos el tiempo necesario para permitir la subida y bajada de todos los pasajeros. El tiempo requerido para esto se calcula usando la relación publicada por Lin y Wilson (1992): TE = α + βPS + γPB + δPO + εE. (3.1). donde PS es la cantidad de pasajeros que suben, PB es la cantidad de pasajeros que bajan y PO es la cantidad total de pasajeros que hay tanto en el andén como en la estación. Este último término permite incorporar los efectos de atochamiento que se producen cuando hay demasiados pasajeros, aunque no suban ni bajen del tren. α, β, γ y δ son parámetros definidos por el usuario, y εE es una variable aleatoria que distribuye normal para darle un componente estocástico al proceso; su media μεE y su desviación estándar σεE deben ser especificados por el usuario. En todo caso, TE no es necesariamente el tiempo que el tren permanecerá en la estación, pues éste puede ser mayor si así lo exige el tiempo de holding asignado al tren..

(27) 16. El tiempo que les tarda a los trenes recorrer los tramos de línea entre estaciones se calcula simplemente como TL = (L + εL) / v. (3.2). donde L es el largo del tramo y v la velocidad asignada al tren. En este cálculo no se está tomando en cuenta el perfil de velocidad del tren a lo largo de la línea, es decir, el hecho de que hay que pasar por un periodo de aceleración y desaceleración que toma un tiempo adicional. Sin embargo, si se considera a v como la velocidad media del tren durante el recorrido del tramo de línea, el cálculo resulta correcto; el supuesto básico es que el tiempo que toma recorrer una distancia es proporcional a ésta. εL es una variable aleatoria que permite darle una componente estocástica a los tiempos de viaje; distribuye normal y sus parámetros μεL y σεL deben ser especificados por el usuario. Al final de cada vía existe una “cola de maniobra” por la cual tienen que pasar los trenes antes de poder ser despachados para iniciar su recorrido en el sentido contrario. Los trenes pueden permanecer en esta cola un tiempo si así lo determina el usuario; la cantidad total de trenes que pueden permanecer simultáneamente en una cola es un parámetro de la simulación. También lo es el tiempo que tarda a los trenes entrar y salir de las colas. El usuario puede definir “ramas laterales” en ciertos puntos de la línea; estos son depósitos donde es posible almacenar temporalmente un número determinado de trenes para luego despacharlos a la línea. Esto permite tener trenes (vacíos) en espera para servir a una porción de la línea cuando la demanda en ésta aumente sin tener que pasar por las estaciones anteriores. El usuario debe especificar en qué vía y en qué tramo de línea entre estaciones se encuentra cada rama que se desee crear, y a qué altura (en metros medidos desde la estación inmediatamente anterior) se encuentran la entrada y salida de la rama. También debe especificar la capacidad de la rama y el tiempo que toma entrar y salir de ella..

(28) 17. Cuando un tren es despachado a la línea desde los terminales, el control puede asignarle una rama en la que debe permanecer almacenado. Si es así, el tren pasa por todas las estaciones anteriores sin recoger pasajeros, tomando sólo un tiempo fijo determinado por el usuario para atravesar por ellas, hasta que llega al punto en que comienza la rama e ingresa en ella. Puede ocurrir que los trenes se alcancen unos a otros, especialmente cuando uno llega a una estación que no ha sido desocupada por el tren anterior. En este caso, el tren se queda esperando a la entrada de la estación en espera de que el anterior la abandone, y luego toma un tiempo que el usuario debe definir para entrar en ella. Otro caso es cuando una de las colas está llena; en este caso, un tren que esté en la estación terminal anterior se queda esperando allí hasta que haya espacio. Si un tren quiere entrar a una rama llena, se queda esperando, bloqueando la línea. Finalmente, cuando un tren con una velocidad mayor que la de su antecesor lo alcanza dentro de la línea, baja la velocidad para irlo siguiendo. También es posible definir una operación expresa para los trenes. El usuario puede definir una serie de recorridos expresos para cada vía, especificando para cada uno en qué estaciones debe parar un tren que lo siga. Los trenes se van turnando los recorridos expresos entre ellos; la intención a futuro es que el control pueda asignar el recorrido a los trenes en el momento del despacho. Los trenes pasan de largo las estaciones que no corresponden a su recorrido, tardando sólo un tiempo definido por el usuario en atravesarlas. En las estaciones en que sí paran, sólo se pueden subir pasajeros que vayan a las estaciones que formen parte del recorrido expreso del tren; se asume que éste tiene marcado de alguna forma qué recorrido sirve (como las líneas 4 y 5 del Metro de Santiago, que actualmente usan un código de colores para indicarlo). Adicionalmente, puede haber estaciones de transferencia, en las que los pasajeros provenientes de una línea pueden pasarse a uno de los andenes de la otra. Desde el punto de vista de las matrices origen-destino de las líneas, se supone que los pasajeros que tienen como destino una estación perteneciente a otra línea van a la.

(29) 18. primera estación de transferencia que les permita hacer el trayecto de la forma más rápida posible; sólo una vez que los pasajeros desembarcan en el andén de la estación de transferencia se separa un grupo de ellos para que haga la combinación. Este grupo de pasajeros se divide en dos; los pasajeros de cada uno de los sub-grupos se agregan a los andenes de las dos vías de la estación correspondiente en la otra línea, donde nuevamente son contabilizados como pasajeros normales que pueden ir a cualquiera de las estaciones que siguen. El usuario debe definir qué proporción de los pasajeros que llegan a una estación de transferencia hace la combinación en lugar de abandonar la red en esa estación, así como qué proporción de los pasajeros que hacen la combinación va hacia cada vía. Además, debe especificar una serie de parámetros que determinan el tiempo que toma hacer la combinación y que se explican en el párrafo siguiente. Todos estos parámetros deben especificarse cuatro veces: uno por cada andén de cada línea. El tiempo que toma hacer la combinación se determina como sigue. El usuario debe especificar una media μC y una desviación estándar σC para este tiempo. Los pasajeros que hacen la combinación hacia determinado andén se dividen en cinco grupos (siempre y cuando sean más de cinco pasajeros). El primer grupo concentra el 38% de los pasajeros y toma exactamente μC en hacer la combinación. Otros dos grupos tienen un 24% de pasajeros cada uno y se demoran μC. +. σC y μC - σC. respectivamente en hacer la combinación. Los dos últimos grupos tienen el 7% de los pasajeros cada uno y tardan μC ± σC. Los porcentajes son los que corresponden a una partición en cinco partes de una distribución normal. Si el total de pasajeros haciendo la combinación excede un cierto límite definido por el usuario, el efecto de atochamiento se toma en cuenta incorporando a cada grupo una demora adicional proporcional al tamaño del grupo e inversamente proporcional a una tasa λA definida por el usuario (que corresponde aproximadamente a la tasa de servicio de una cola que se supone que se forma a la salida del andén debido al exceso de pasajeros)..

(30) 19. El usuario también debe indicar los tiempos de inicio y fin de la simulación, así como la semilla de los generadores de números aleatorios que se usan. Esto último permite correr la simulación varias veces exactamente de la misma forma, tal vez variando las condiciones de operación, para poder hacer comparaciones más correctas. Si a este campo se le da el valor 0, se usa la hora actual como semilla. 3.2.2 Condiciones iniciales Además de los parámetros de la línea misma y de la simulación, el usuario debe especificar las siguientes condiciones iniciales: a). Cantidad de trenes que entran en la simulación y sus posiciones iniciales.. b). Número de pasajeros esperando en los andenes de las estaciones inicialmente desocupadas.. c). Para los trenes que se encuentran inicialmente en una estación, tiempo en que llegaron, holding asignado, pasajeros que traían al llegar y cuántos había esperando en el andén en ese momento (para poder calcular el tiempo que les queda en la estación por causa del holding o por efecto de carga y descarga).. d). Para los trenes inicialmente en un tramo de línea (puede haber más de uno en un mismo tramo), cantidad de pasajeros que lleva, posición inicial medida desde la estación anterior y velocidad asignada, para así calcular el tiempo que falta para llegar a la estación siguiente.. e). Para todos los trenes, recorrido expreso que están sirviendo.. f). Para las colas de maniobra y ramas, tiempo de despacho asignado al primer tren esperando en ellas..

(31) 20. 3.2.3 Cálculo de energía La energía consumida por los trenes se calcula durante la simulación. Se asume que los trenes gastan energía durante su movimiento a través de los tramos de línea. Como se explica en la sección 3.3, el simulador funciona orientado a eventos, por lo que no es posible ir calculando el consumo energético en cada instante; en lugar de ello, es necesario encontrar una expresión cerrada que entregue la energía consumida en un cierto tramo en función de valores globales como la distancia recorrida y el tiempo empleado en ello. Cada vez que un tren cambia de velocidad dentro de un tramo de línea o llega a una estación o rama, se calcula el gasto de energía realizado en el recorrido recién completado y se suma al total acumulado. Según la literatura (Liu y Golovitcher, 2003), la ecuación diferencial que rige la dinámica de un tren tiene la forma MT. dv = f (v ) − g − b(v ) − w(v ) dt. (3.3). donde MT=M+n×m es la masa total del tren, igual a la propia de los vagones M más la masa m del pasajero promedio por el número n de pasajeros actualmente a bordo; v es su velocidad; f(v) es la fuerza de tracción ejercida por los motores; g es la fuerza de resistencia ejercida por la línea (se asume que es constante a lo largo de ella); b(v) es la fuerza de frenado y w(v) es la fuerza de resistencia ejercida por el aire, para la que se asumirá la siguiente forma (Khanbaghi y Malhame, 1994): w(v) = cv 2. (3.4). La energía total requerida en un cierto tramo de línea se puede calcular como L. T. 0. 0. E = ∫ f (v)dx = ∫ vf (v)dt. (3.5).

(32) 21. donde L es el largo del tramo y T el tiempo que toma recorrerlo. Para calcular esta integral, se asumió que el perfil de velocidad a lo largo de la línea tiene la forma que se muestra en la figura 3-2, con un fase I de aceleración constante a (parámetro definido por el usuario) durante un tiempo TI durante el cual se recorre la distancia LI; una fase II de movimiento uniforme con la velocidad v0 (asignada por el Controlador) durante un tiempo TII durante el cual se recorre la distancia LII y una fase III de desaceleración constante d (parámetro también definido por el usuario) durante un tiempo TIII durante el cual se recorre la distancia LIII.. Figura 3-2. Perfil de velocidad de un tren en un tramo de línea (Fuente: Elaboración propia) Por características del movimiento uniformemente acelerado, la fase I debe durar TI=v0/a, y durante ese tiempo se debe recorrer la distancia LI=v02/a. Como no hay acción de frenado, la ecuación 3.3 se reduce a. f I (v) = M T a + w(v) + g. (3.6). y la integral de la ecuación 3.5 se convierte en TI 2 ⎡ ⎞⎤ 1 ⎛ cv 2 m E I = ∫ at M T a + c(at ) 2 + g dt = v0 ⎢ + ⎜⎜ 0 + g ⎟⎟⎥ 0 ⎠⎥⎦ ⎣⎢ 2 2a ⎝ 2. (. ). (3.7).

(33) 22. La fase III debe durar TIII=v0/d, y durante ese tiempo se debe recorrer la distancia LIII=v02/d. Por lo tanto, durante la fase II se debe recorrer la distancia que queda: LII=L-LI-LIII=L-v02(1/a+1/d), lo cual en un movimiento uniforme toma el tiempo TII=L/v0-v0(1/a+1/d). La ecuación 3.3 para este caso con velocidad constante y sin frenado queda. f II (v) = w(v) + g. (3.8). de donde la integral 3.5 se convierte en E II =. TI +TII. ∫ v (cv 0. 2 0. TI. ). ⎡ 1 ⎞⎤ 2 2⎛ 1 + g dt = (cv0 + g ) ⎢ L − v0 ⎜ + ⎟⎥ ⎝ a d ⎠⎦ ⎣. (3.9). Como durante la fase III no se aplica fuerza de tracción sino que sólo frenado, no hay contribución al consumo de energía en este caso. Así pues, la energía total gastada para recorrer un tramo de línea es E=EI+EII: ⎡ m 1 ⎛ cv0 2 ⎞⎤ ⎜ ⎟⎥ + (cv0 2 + g ) ⎡⎢ L − v0 2 ⎛⎜ 1 + 1 ⎞⎟⎤⎥ E = v0 ⎢ + + g ⎜ ⎟ ⎝ a d ⎠⎦ ⎣ ⎢⎣ 2 2a ⎝ 2 ⎠⎥⎦ 2. (3.10). Este análisis se hizo suponiendo que el tren parte y termina en reposo, que es lo que ocurre cuando recorre directamente la distancia entre dos estaciones. Si necesita cambiar la velocidad a medio camino, es necesario introducir algunos términos adicionales. 3.2.4 Salidas de la simulación Al terminar la simulación, se entregan una serie de indicadores de desempeño por línea y por estación, que son los que se dan a continuación. Para cada línea: a). Total de trenes que participaron en la simulación..

(34) 23. b). Total de pasajeros que llegaron a estaciones en la línea, junto con la tasa promedio de llegada en pasajeros por segundo.. c). Tiempo total de espera de todos los pasajeros de todas las estaciones de la línea en los andenes, en horas-hombre, junto con el tiempo de espera promedio y su desviación estándar. Estos valores se entregan para la simulación completa y para intervalos de 15 minutos para permitirle al usuario hacerse una idea de en qué momento fueron más críticos.. d). Tiempo total de viaje de todos los pasajeros en los trenes, junto con el tiempo de viaje medio y su desviación estándar. Nuevamente, los valores se dan además para intervalos de 15 minutos.. e). Energía empleada por todos los trenes durante la simulación, en kW-hora, junto con el gasto de energía medio por tren y la desviación estándar entre trenes. La forma en que se calculan estos valores se indica en la sección 3.2.3.. f). Ocupación promedio y máxima de los trenes, como número de pasajeros y como porcentaje de la capacidad de los carros. También se entregan estos valores para intervalos de 15 minutos.. Para cada estación: a). Total de pasajeros llegados, junto con la tasa de llegada promedio.. b). Espera total de pasajeros en la estación, junto con la espera promedio. Se entrega además por intervalos de 15 minutos.. c). Frecuencia promedio con que los trenes pasan por la estación. Se entrega también por intervalos de 15 minutos..

(35) 24. d). Ocupación promedio y máxima de la estación, indicando en qué instante ocurrió el máximo. Se entrega también por intervalos de 15 minutos.. e). Máximo número de trenes que debieron quedarse haciendo cola para entrar a la estación por encontrarse ésta ocupada al arribar a ella, indicando el instante en que ocurrió este máximo. Se entrega también por intervalos de 15 minutos.. Los resultados pueden pedirse para cualquiera de los dos andenes de cada estación. Además, el software va registrando la historia de la evolución de cada tren y estación. a medida que transcurre la simulación; al terminar ésta, es posible. almacenar este historial a disco en la forma de matrices MATLAB. Se almacena una matriz por cada estación y por cada tren. Cada fila de cada matriz corresponde a un suceso determinado (llegada o salida de un tren, o arribo de un grupo de pasajeros, por dar ejemplos) y en cada columna se entrega información acerca del suceso, como instante en que ocurrió, cantidad de pasajeros que quedan en ese momento en la estación, etc., siguiendo ciertas convenciones. El simulador puede también entregar parte de esta información en forma gráfica, como se explica en la sección 3.4 sobre la interfaz. 3.2.5 Interacción con el control en tiempo real Como ya se indicó antes, el objetivo principal del simulador es dar la posibilidad de controlar el sistema de una forma flexible. La forma en que esto está implementado es que cada vez que un tren entra o sale de una estación, cola de maniobra terminal o rama, un módulo especial del simulador, al que se llamará Controlador, llama a una función que el usuario debe escribir en MATLAB o SCILAB (para simplificar la discusión, de aquí en adelante se asumirá que está escrita en MATLAB, aunque las explicaciones funcionan igual para el caso SCILAB), pasándole una serie de argumentos que contienen toda la información acerca del sistema en el instante actual, incluyendo ocupación de andenes y trenes,.

(36) 25. posiciones de trenes, etc. La interconexión entre el simulador y el software de cómputo se hace a través del COM Automation Server Support en el caso de MATLAB y de las DLLs provistas en el caso de SCILAB. La idea es permitir probar estrategias de control que asuman conocimiento de estas variables; en el sistema real éstas deben ser medidas mediante sensores como los contadores de pasajeros en los torniquetes de entrada de las estaciones, pesaje dinámico de los carros, sistemas de trackeo de los trenes, etc. También puede que se incorporen alternativas más sofisticadas como sistemas de conteo de pasajeros basados en visión o en medición de la presencia de tarjetas de pasaje con RFID. Por supuesto, si en el sistema real que se va a simular no está disponible la medición de alguno de estos valores y consiguientemente la estrategia de control correspondiente no puede tomarla en cuenta, el usuario puede simplemente ignorar el argumento correspondiente al escribir la función MATLAB de control. El Controlador entrega la siguiente información de estado a la función MATLAB: a). Tiempo actual de la simulación.. b). Tipos de variable manipulada que está permitido alterar (holding, despacho desde terminal, despacho desde rama y envío a rama; ver más adelante).. c). Índice y línea del metro que gatilló la llamada al control. d). Para cada metro, su estado (en estación, en un tramo de línea, etc.), línea a que pertenece, vía y estación en que se encuentra, holding y velocidad asignados, posición dentro del tramo de línea actual o tiempo en que llegó a la estación actual (según corresponda), pasajeros que lleva y que había en el andén de la estación actual al llegar a ella, rama a la que se dirige (si alguna) y recorrido expreso que está haciendo actualmente (si alguno)..

(37) 26. e). Para cada estación, línea a que pertenece, pasajeros que tiene actualmente, últimos instantes de arribo y salida de algún tren, y tiempo de despacho desde la rama que se encuentre en el tramo de línea que sigue a la estación (si la hay).. f). Tiempo de despacho desde cada cola de maniobra.. g). Seis parámetros optativos fijados por el usuario desde el software; de esta forma, una misma estrategia de control puede probarse con parámetros distintos rápidamente sin modificar el archivo MATLAB.. No se entrega a la función información acerca de los parámetros de la línea misma (como tasas de llegada, largos de línea o matrices origen-destino) sino que sólo de variables de estado a través de los argumentos a la función MATLAB para no seguir sobrecargando la llamada. Los parámetros deben ser integrados en el código de la función MATLAB misma; como no cambian durante la simulación, no hay inconvenientes en hacerlo así. La salida de la función es un conjunto de instrucciones de cambiar el valor de las cuatro variables manipuladas posibles: tiempo de holding y velocidad media de los trenes y tiempo en que debe ser despachado el próximo tren desde los puntos terminales de las líneas y desde las ramas. En cada llamada a la función MATLAB pueden fijarse estas variables manipuladas para cualquier tren y cualquier rama o terminal. El simulador permite determinar cuáles de los cuatro tipos de variables manipuladas es posible modificar; si la función MATLAB intenta cambiar una variable manipulada prohibida, el Controlador simplemente lo ignora. En el caso de no controlar alguna variable manipulada, el simulador emplea opciones por defecto escogidas por el usuario, que puede determinar un tiempo de holding (en esta caso también llamado de stop, al ser fijo) predeterminado, una velocidad en línea predeterminada, e intervalos entre despachos sucesivos de trenes desde los.

(38) 27. terminales predeterminados. Si no se controla el uso de las ramas, éstas ni siquiera operan. En el anexo B se da una descripción más detallada de la forma en que deben pasarse y recibirse las variables de entrada y salida de la función MATLAB. 3.3. Funcionamiento del simulador. 3.3.1 Paradigmas empleados a). Programación orientada a objetos (OOP). Se trata de uno de los paradigmas que ha dominado el desarrollo de software desde los años noventa (Stroustrup, 1997). En su base está la idea de la modularización, es decir, separar el código en partes que sean lo más independientes posible entre sí, y que interactúen unas con otras sólo a través de interfaces, o conjuntos de llamadas a funciones, bien definidas. De esta forma, si la interfaz da cada módulo se mantiene fija, su “contenido” (básicamente su implementación, es decir, la forma concreta en que realiza las funciones que le corresponden) puede cambiarse fácilmente sin afectar al resto del software. Lo anterior tiene dos ventajas principales: permite atacar los problemas por partes, dando la posibilidad de concentrarse en cada módulo por separado sin tener que considerar en todo momento todo el contexto general, y facilita la actualización del software, ya que los cambios que se requieran se pueden hacer de forma local sin tener que escribir el código completo desde cero. La programación orientada a objetos básicamente formaliza y extiende las nociones anteriores a través de ciertos constructos que deben formar parte de todo lenguaje de programación que se adhiera al paradigma. El más importante de éstos son las clases, que básicamente corresponden a tipos de datos definidos por el usuario. Una clase representa un “tipo” de objeto del que posteriormente pueden definirse múltiples instancias en el programa. Por ejemplo, se podría definir una clase llamada Tren que represente trenes de metro. Cada vez que se quiera contar con un nuevo tren, crea una instancia u objeto de esta clase. Al definir una clase,.

Show more

Nuevo documento

Al modelo simulado, aplicarle las estrategias de control Skyhook, Groundhook e Hı́brido, variando la ganancia de cada estrategia de forma heurı́stica para identificar la relación entre

Además, los alumnos pueden anticipar cómo se desarrollaran algunas actividades como por ejemplo la lectura de un texto, ya que la maestra suele seguir casi siempre las mismas pautas en

3.4 JORNADA ELECTORAL Después de varios meses de campañas –del 19 de enero al 28 de junio- y de algunos cambios en las preferencias electorales ver gráfica 6, sobretodo entre los

PRESENTACIÓN DEL DESARROLLO DE LAS SESIONES -Recuerdo de aspectos importantes de la sesión anterior 10 minutos -Recuerdo de Objetivos y reglas 5 minutos -Elección conjunta de la

int CVICALLBACK SETPIDGAIN int panel, int control, int event, void *callbackData, int eventData1, int eventData2 { switch event { case EVENT_COMMIT: break; } return 0; }.. int

Aprendizaje de la Amistad El aprendizaje de la amistad es una intervención dirigida a promover cambios en sus pensamientos y conductas para hacer y mantener amigos, que se fundamenta en

Aprendizaje de la amistad El “aprendizaje de la amistad” es una intervención dirigida a promover cambios en los pensamientos y conductas de los niños para hacer y mantener amigos, que

El capítulo 4 se explica un caso experimental donde se describen los pasos para desarrollar una configuración y puesta en marcha de la metodología propuesta haciendo uso de un Kit

audiodescripción, traducción pedagógica, MCER Marco Común Europeo de Referencia, y por último, traducción audiovisual en clase de lenguas, centrándonos sobre todo en la

De esta forma: 1 se puede considerar al proceso de monitoreo como aquél en el cual se revisan las actividades para compararlas con respecto al plan de trabajo; 2 con respecto a los