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 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) A mis padres, por todo su apoyo y ánimo ii 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 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 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 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 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 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 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 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 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. 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 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. 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. 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. 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 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 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 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 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 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. 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í 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 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 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. 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. 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 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). 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. 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) 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) 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. 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. 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, 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). 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 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, 28 se especifica tanto un conjunto de variables miembro, que permitirán luego representar el estado de cada objeto, como una serie de funciones miembro o métodos, que definirán el comportamiento del objeto, es decir, la forma en que el objeto puede interactuar con el resto del programa. En un software orientado a objetos bien diseñado, los datos miembro sólo pueden ser accesados desde fuera de la clase a través de los métodos de la misma, los cuales de esta forma pueden controlar qué se puede y qué no se puede hacer con cada objeto. Esto facilita el encapsulamiento de la información y de esta forma la independencia del código de la clase del que es externo a ella: los prototipos de los métodos, que debieran mantenerse fijos, constituyen la interfaz de la clase, mientras que el conjunto de variables miembro y código concreto de los métodos puede ir variando a medida que el software evoluciona. Lo importante es que si la interfaz se mantiene constante, estos cambios no afectarán en nada al resto del software. Así pues, la programación orientada a objetos permite la creación de fragmentos de código modulares y reutilizables de una forma flexible y robusta. Para mejorar la flexibilidad, incorpora también los conceptos de herencia y polimorfismo. El primero de éstos se refiere a que es posible crear clases nuevas a partir de clases ya existentes, incorporando su contenido (datos y métodos) y extendiéndolo. Por ejemplo, se podría definir la clase Tren Expreso, heredera de la clase Tren¸ que de esta forma podría contener todo el comportamiento e información de estado de un Tren normal pero a la vez incorporar algunos métodos y variables propios. Además, es posible sobreescribir el código de algunas funciones si es conveniente. El polimorfismo es la capacidad del programa de tratar a un objeto de una clase heredera como si correspondiera a un objeto de la clase “antepasada”; o base, invocado métodos declarados por esta última aunque posiblemente redefinidos de forma específica en la clase heredera. Por ejemplo, podríamos tener nuestra clase base Tren y dos clases herederas del mismo, Tren expreso y Tren de carga. Las tres clases incluyen el método acelerar, pero los dos tipos de clases herederas realizan el correspondiente procesamiento de forma distinta, tal vez porque la 29 implementación interna de los métodos y variables es diferente en cada una o porque alguna necesita tener comportamientos específicos al tipo de tren en cuestión que no aplican al otro, como por ejemplo revisar que la carga esté completa. Sin embargo, la parte del código que da a los trenes la orden de acelerar no necesita saber con qué tipo de tren está tratando, y es más simple para el diseño que trate a todos los objetos Tren de la misma forma. La solución es definir en la clase base a acelerar como un método virtual, y que cada clase heredera sobreescriba este método usando la implementación más conveniente en cada caso. El código externo recibe entonces objetos de cualquiera de las dos clases herederas “creyendo” que corresponden a objetos de la clase base, e invoca simplemente al método acelerar sin preocuparse de dónde y cómo éste se implementa; el lenguaje de programación debe proporcionar los mecanismos para redirigir esta invocación a la definición de método correcta. El lenguaje de programación Microsoft C#, en el que fue desarrollado el simulador, soporta íntegramente la programación orientada a objetos de una forma muy parecida a como lo hacen sus lenguajes predecesores, incluyendo a C++ y Java. b) Programación basada en eventos Matemáticamente, el “comportamiento” de un sistema a simular se puede representar como una función (y(t+δ),x(t+δ))=f(u(t),x(t)), donde δ corresponde a un “paso” que puede ser infinitesimal o de valor finito, como se explica a continuación. Para definir el “comportamiento” existen dos paradigmas principales (Hill y Yates, 1992). El primero lo representa mediante un conjunto de ecuaciones diferenciales o de diferencias que son funciones de las variables de entrada y de las de estado. Si las ecuaciones son diferenciales, el sistema es continuo y debe ser integrado usando algún método numérico; si son de diferencias, el sistema es discreto y se resuelve paso a paso para instantes específicos a intervalos uniformes en el tiempo. 30 El segundo paradigma lo constituye la modelación orientada a eventos, que de alguna forma es un caso intermedio entre los sistemas continuos y discretos. En este modelo, el procesamiento (actualización de variables de estado y producción de salidas en respuesta a las entradas) también se hace exclusivamente en instantes discretos bien definidos, pero que no ocurren a intervalos regulares. En lugar de eso, el instante en que ocurrirá el próximo “paso” o evento de la simulación se define durante el actual, y depende de los valores de las entradas y variables de estado. Por ejemplo, la llegada de un tren a una estación puede constituir un evento; cuando ocurre, el software actualiza las variables de estado relevantes (carga del tren, de la estación, etc.) y determina según alguna función cuánto tiempo necesita permanecer el tren allí. Así, calcula cuándo debe ocurrir el próximo evento, correspondiente a la salida del tren, y “salta” directamente a él, sin tomar en cuenta lo que pueda pasar entre medio (que en la práctica no es importante). Las ventajas del modelo orientado a eventos es que permiten un procesamiento mucho más rápido, pues sólo se toman en cuenta los instantes en que realmente ocurren hechos relevantes, y simplifica el modelamiento. La desventaja es que debe definirse qué constituye un “hecho relevante”; necesariamente algunos sucesos no serán considerados o serán considerados en un instante distinto del que realmente ocurren, creando una cierta distorsión. Sin embargo, para un sistema en que casi todo ocurre en instantes bien definidos como el de metro (llegadas de pasajeros a las estaciones, entradas y salidas de metros de estaciones), lo que se pierde es menor, siempre y cuando no se considere el detalle del movimiento dinámico de los trenes en las líneas y se simplifique éste asumiendo que los viajes toman un tiempo fijo. 3.3.2 Implementación en el simulador La forma en que se aplican los paradigmas en este caso está basado en que la simulación trabaja con una serie de clases: Líneas, Trenes, Estación y Combinación. Esta última corresponde a la combinación entre dos estaciones de 31 transferencia, ubicadas en líneas distintas. De cada una de ellas existen múltiples instancias, todas las cuales pueden gatillar el próximo evento. Para hacerlo funcionar, todas estas clases heredan de una clase base llamada Entidad, que define una variable miembro, TIEMPO DE PRÓXIMO EVENTO y un método virtual, Procesar Evento. El software mantiene una lista de todos los objetos, pertenecientes a cualquiera de las clases de la simulación, en una lista vinculada. La parte del código que dirige la simulación, llamada Procesador, mantiene en una variable el TIEMPO ACTUAL. En cada paso de la simulación, el Procesador revisa la lista entera de objetos (considerándolos a todos como simples Entidades, usando el polimorfismo) en busca del que tenga un menor TIEMPO DE PRÓXIMO EVENTO. Cuando lo encuentra, actualiza su TIEMPO ACTUAL con el valor correspondiente y llama a la función Procesar Evento del objeto escogido. Éste realiza entonces el procesamiento que corresponda en base al tipo de objeto de que se trate, a su estado y al estado de otros objetos con los que se relacione, actualiza los valores que haga falta y calcula un nuevo TIEMPO DE PRÓXIMO EVENTO para sí mismo. Una vez que ha concluido, el control vuelve al procesador, que repite todo el proceso. El proceso se ilustra en la figura 3-3, en que se observa, por una parte, que el Procesador sólo interactúa con la variable TIEMPO DE PRÓXIMO EVENTO y la función Procesar Evento de cada objeto, y por otro, que el Procesador escoge la Entidad con menor TIEMPO DE PRÓXIMO EVENTO (la Estación 2) y llama a su correspondiente función Procesar Evento, que se encarga de acceder al comportamiento específico de la clase. 32 ESTACIÓN 1 ESTACIÓN 2 ProxTiempo=15s ProxTiempo=35s TREN 1 TREN2 ProxTiempo=20s ProxTiempo=45s Procesar Evento() Procesar Evento() Procesar Evento() Procesar Evento() Comportamiento específico de estación Comportamiento específico de estación Comportamiento específico de tren Comportamiento específico de tren Variables específicas de tren Variables específicas de tren Variables específicas de estación Variables específicas de estación PROCESADOR TiempoActual= Min{35,15,20,45}=15s Figura 3-3. Diagrama del desarrollo de la simulación (Fuente: Elaboración propia) A continuación se indica a qué corresponden los eventos asociados a cada clase y se explica brevemente que hace la función Procesar Evento de cada una al ser invocada. Más detalles se dan en el Anexo A. a) La clase Línea no tiene eventos propios; sirve simplemente para contener ciertos parámetros y referencias a las Estaciones, Trenes y Combinaciones que contiene. b) Los eventos de la clase Estación corresponden a llegadas de pasajeros. Procesar Evento aumenta la cantidad de pasajeros en la cantidad correspondiente y calcula el tiempo (aleatorio) hasta la próxima llegada. c) Los eventos de la clase Tren pueden corresponder a llegadas a estaciones, salidas de estaciones, llegadas a terminales, etc. Dependiendo del caso, Procesar Evento puede tener que ejecutar ciertas acciones (como 33 embarcar y desembarcar pasajeros, si el evento corresponde a una llegada a estación) y después debe calcular el tiempo hasta el evento siguiente. d) Los eventos de la clase Combinación corresponden exclusivamente a grupos de pasajeros que están terminando de hacer la combinación y llegando a su andén de destino. Procesar Evento debe agregarlos al objeto Estación que corresponda. La partida de los pasajeros hacia la otra estación se hace en el momento en que el tren que los traía llega a la estación de origen, lo que corresponde un evento de la clase Tren. 3.4 Interfaz de operación Desde la ventana principal de la aplicación, mostrada en la figura 3-4, es posible modificar directamente la estructura de la red, incorporando o borrando líneas, estaciones, etc. A través de una serie de cuadros de diálogo se pueden fijar todos los parámetros relevantes, incluyendo las condiciones iniciales, así como escoger el archivo en que se encuentra la función MATLAB del Controlador, si se desea usar una. También es posible guardar toda esta información para recuperarla después. Tras ejecutar la simulación, se puede acceder a los valores de los indicadores de desempeño y guardar el desarrollo de la simulación en forma de matrices MATLAB o SCILAB, como se explicó en la sección 3.2.4. Finalmente, es posible obtener dos tipos de representación gráfica de dicho desarrollo. En la figura 3-5 se muestra el diagrama distancia-tiempo para una línea. El eje de las abscisas corresponde al tiempo y el de las ordenadas a la posición a lo largo de la línea, con la ubicación de las estaciones marcada. Cada línea de color en el gráfico corresponde a un tren distinto a medida que se desplaza por la línea; cuando van en la vía uno el trazo se mueve desde abajo hacia arriba, y cuando van en la línea dos en el sentido contrario. 34 Figura 3-4. Interfaz principal de la aplicación Figura 3-5. Diagrama distancia-tiempo para una línea Se observa en la figura 3-5 que en este caso, que corresponde a uno no controlado, hay ya desde los primeros minutos una tendencia de los trenes a agruparse, ya que un tren A que entra a una estación recientemente desocupada por su tren 35 predecesor B evidentemente la encuentra con menos pasajeros (ya que la mayoría ya ha embarcado en B), por lo que tarda menos tiempo en cruzarla y se acerca más a B. El proceso se repite en las estaciones subsiguientes, con el tren A demorándose cada vez menos en cada estación y acercándose más y más a B, hasta que los dos trenes se juntan. Este fenómeno se conoce como bunching y produce un aumento de los tiempos de espera de los pasajeros, ya que pasan largos intervalos de tiempo sin que pase ningún tren. El otro tipo de representación gráfica, que se ve en la figura 3-6, se presenta para cada estación y corresponde a su ocupación en función del tiempo. El eje de las abscisas es nuevamente el tiempo y el de las ordenadas el número de pasajeros que hay en la estación en un instante dado. Las porciones con fondo claro indican que en el correspondiente intervalo hay un tren parado en la estación; se observa que a su llegada ésta se vacía, pues los pasajeros que estaban en el andén han subido al tren. Una descripción más detallada de la interfaz de operación se da en el anexo B. Figura 3-6. Diagrama de subida de pasajeros para una estación 36 4. APLICACIÓN DEL SIMULADOR PARA EVALUAR ESTRATEGIAS DE CONTROL Como ya se indicó en el capítulo anterior, uno de los principales objetivos del simulador desarrollado es probar estrategias de control. La forma general en que deben ser implementadas y el modo en que interactúan con el simulador ya se explicó en la sección 3.2.5. A continuación se describe con más detalle en qué consisten estas estrategias de control y se proponen dos alternativas específicas para demostrar el uso, una relativamente simple y la otra más avanzada y costosa; los resultados entregados por el simulador permitirán realizar una comparación entre ambas en cuanto a efectividad. 4.1 Antecedentes En la figura 4-1 se muestra la estructura básica del sistema de control aplicado al caso del metro (Dorf y Bishop, 2005). Conceptualmente, el objetivo es lograr que ciertas variables, llamadas variables controladas o CVs, tomen un cierto valor deseado o se aproximen a él. En este caso las CVs corresponden a los tiempos de espera de los pasajeros en las estaciones y a sus tiempos de viaje en los trenes; el objetivo es que ambos tomen el valor más bajo posible. Para lograr este objetivo, el sistema controlador debe actuar en tiempo real sobre ciertas variables manipuladas o MVs del sistema; para este caso, las MVs usadas son los tiempos de holding de los trenes en las estaciones y los instantes en que se despacha el próximo tren desde las terminales (las otras dos que el simulador hace disponibles, despacho de y envío a ramas, no se usan en estas estrategias). Lo que distingue a los sistemas de control automático es que, para calcular el valor que deben tomar las MVs en un instante dado, emplean información obtenida en línea del estado del sistema, como queda representado por el lazo de realimentación en la figura 4-1. En este caso, esta información incluye número de pasajeros en estaciones y trenes, posición de los trenes, etc. 37 Figura 4-1. Esquema del sistema de control automático (Fuente: Elaboración propia) La forma en que se calculan las MVs siguientes a partir del estado depende del tipo de control que se esté usando; existen desde alternativas basadas en reglas heurísticas hasta sistemas que usan redes neuronales o complejos algoritmos de optimización. A continuación se revisan dos posibilidades. 4.2 Control experto Como primera alternativa se propone una estrategia de control basada en una regla simple basada en regularización del headway de salida de estaciones, es decir, el tiempo entre sucesivas salidas de trenes desde cierta estación. La idea es intentar hacer que este headway sea siempre constante e igual a H, un parámetro del control. Según la literatura (Daganzo, 1997), la regularización de los headway tiende a minimizar los tiempos de espera de los pasajeros en las estaciones. La estrategia es la siguiente: cada vez que un tren arriba a una estación en un instante tlleg, se computa el instante de la salida del tren anterior a esa misma estación, tant. El holding h se determina mediante las siguientes simples reglas: SI tlleg ≥ tant + H ENTONCES h=0 SI tlleg < tant + H ENTONCES h = tant + H − tlleg (4.1) Esto significa que el control intentará, a través del holding de los trenes en cada estación, mantener el headway de salida de ésta constante. Hay que notar que si el 38 tren llega muy tarde, el holding es cero para intentar hacerlo pasar lo más rápido posible; sin embargo, esto no significa que el tren abandone de inmediato la estación, pues requiere un tiempo mínimo para que suban y bajen todos los pasajeros. 4.3 Control Predictivo El control predictivo basado en modelos, o MPC, es una rama del control automático que se ha difundido mucho en las últimas décadas, sobre todo en aplicaciones industriales para controlar sistemas más complejos que los que se pueden tratar con las técnicas de control tradicionales. El MPC se basa en optimización (Camacho y Bordons, 2004). El requisito básico es contar con un modelo o representación matemática de la planta o sistema a controlar. El modelo es casi siempre del tipo discreto, en la forma de una función vectorial que puede ser del tipo x̂ [i]=f(x[i-1],u[i-1]) (4.2) donde x[i] corresponde al vector de estado (conjunto de variables necesarias para definir el estado de un sistema en un momento dado), x̂ [i] a la predicción del mismo obtenida mediante el modelo y u[i] a los valores de las entradas (las MVs), todo esto en el instante i. Esta función permite predecir el valor de las variables de estado en el paso actual en función tanto del estado como de las entradas en el paso anterior. Existen otras formulaciones, pero ésta es la que se usará en este trabajo. Conociendo los valores de las MVs que se aplicarán en los siguientes instantes de tiempo, y aplicando el modelo repetidas veces, es posible predecir cuáles serán los valores de las variables de estado varios pasos hacia el futuro. Al número de pasos para los que se repite el cálculo del modelo se le llama el horizonte de predicción N; al número de pasos para los que se aplican MVs (incluyendo el paso actual k) se le llama el horizonte de control Nu. El MPC plantea un modelo de optimización del tipo 39 Minu[k],u[k+1],…,u[k+Nu-1] J( x̂ [k+1],…, x̂ [k+N], u[k],…,u[k+Nu-1]) (4.3) sujeto a las restricciones ( x̂ [k+1],…, x̂ [k+N])=F(x[k], u[k],…,u[k+Nu-1]) (4.4) g( x̂ [k+1],…, x̂ [k+N], u[k],…u[k+Nu-1])=0 (4.5) donde las variables de optimización son los valores de las variables manipuladas desde el paso actual hasta el horizonte de predicción u[k],u[k+1],…,u[k+Nu-1]. J(x,u) es una función objetivo que el controlador intenta optimizar, F(x,u) es un vector de funciones f(x,u) que permite obtener los N valores futuros del estado, y g(x,u) es un conjunto de restricciones que las variables manipuladas o controladas no pueden violar. Esta optimización se repite en cada paso de la ejecución del sistema. Como se observa, el control predictivo tiene la ventaja de permitir llegar a un resultado que optimiza una cierta expresión escogida por el usuario, la que puede depender no sólo de las variables controladas sino también de las manipuladas. De esta forma es posible buscar soluciones que, por ejemplo, no sean demasiado exigentes en el uso de la energía empleada. Además, el MPC permite incorporar restricciones, como por ejemplo una distancia máxima de acercamiento entre trenes. Entre las desventajas del MPC se cuentan la gran capacidad de procesamiento requerida, especialmente para sistemas complejos y/o no lineales como el de metro, la necesidad de contar con un modelo del sistema, y el requisito de tener acceso al estado actual x del sistema en línea. Esto último implica que todas las variables de estado deben ser medidas o estimadas en tiempo real para que el controlador pueda calcular a partir de ellas cuáles deben ser los valores que deben tomar las MVs en cada paso del proceso. Existen distintas variantes del MPC, dependiendo de si se usan modelos lineales o no lineales, en variables de estado, del método de optimización, etc. Para muchos 40 de estos casos se han desarrollado técnicas específicas y métodos para medir estabilidad y otros aspectos importantes del control. Sin embargo, dadas las características del sistema bajo análisis, en este caso se optó por emplear un modelo no lineal, es decir, el tipo más general de MPC. En lo que sigue, se presentan las distintas partes del controlador MPC empleado para el sistema de trenes. En la sección 4.3.4 se presenta el modelo mismo usado para hacer las predicciones para las variables de estado; es decir, la función f(x,u). En la sección 4.3.5 se usan estas variables de estado para definir la función objetivo J(x,u). Las restricciones g(x,u) se explicitan en la sección 4.3.6. Para la optimización misma se empleó un algoritmo genético, como se explica en la sección 4.3.9. 4.3.1 Información de estado requerida en línea Como ya se indicó, el control predictivo requiere tener acceso en tiempo real al estado x[k] en cada paso del proceso. Específicamente, los datos que se necesita obtener en línea son: a) Posición en que se encuentra cada tren en cada instante, tanto si están actualmente en una estación como en un punto cualquiera de un tramo de línea o en una cola de maniobra. Los sistemas AVL (Automatic Vehicle Location) se encargan de recabar este tipo de información, empleando una variedad de técnicas, incluyendo GPS, RFID (identificación por radiofrecuencia) o sensores que determinan si puntos determinados de la línea están ocupados o no en un momento dado. b) Tiempo en que llegó cada tren a la última estación por la que pasó. Esta información puede obtenerse mediante sensores ubicados en cada estación. c) Número de pasajeros en cada tren y andén de la línea. Obtener este tipo de información es el trabajo de los sistemas APC (Automatic Passenger 41 Counting), que pueden ir desde estimaciones a partir de la cantidad de pasajeros que han pasado por los torniquetes de entrada a las estaciones hasta sistemas más sofisticados basados en tarjetas con RFID o técnicas basadas en reconocimiento de imágenes usando cámaras. Otra técnica muy usada es pesar los trenes al pasar sobre determinados puntos para determinar cuántos pasajeros llevan; sin embargo, esto sólo puede hacerse en puntos específicos de la línea que tengan la infraestructura instalada. Además, el controlador debe contar con los parámetros de la línea, como largo de los tramos, velocidad de los trenes (asumida constante), etc. Debe tenerse en cuenta que toda esta información debe ser transmitida a un computador central que contenga los algoritmos de control, ya que éstos operan a nivel global. Esto contrasta con el control experto ya descrito, que sólo necesita información local a las estaciones. 4.3.2 Características del modelo Para simplificar el problema, se considera a la línea como un corredor cerrado a través del cual van circulando los trenes, todos en la misma dirección, como se muestra en la figura 4-2. Esta representación es equivalente a una línea normal de dos vías, en que cada vía corresponde a una mitad del bucle. Las estaciones repartidas por el ciclo son en realidad andenes. Las colas de maniobra en los terminales se consideran simplemente como dos tramos de línea más; el hecho de que por ellos no circulen pasajeros no es una diferencia importante. 42 Figura 4-2. Representación del sistema de trenes empleada por el modelo del control (Fuente: Elaboración propia) El modelo usado es no lineal en variables de estado, es decir, se define un conjunto de variables que juntas dan toda la información necesaria para poder predecir la evolución del sistema a futuro. Además, el modelo es discreto, lo que significa que las variables de estado se actualizan con las nuevas predicciones en instantes de tiempo específicos. Sin embargo, a diferencia de lo que generalmente ocurre en este tipo de modelos, los instantes de actualización, o pasos, no ocurren a intervalos de tiempo regulares, sino que en los momentos en que un tren llega a una estación. Esto se muestra en la figura 4-3: aquí, el tren que gatilló el paso actual es el 1, que acaba de arribar a la estación 2; el paso siguiente será gatillado por el tren 3, que está a punto de llegar a la estación 5. El tiempo entre pasos es el que transcurra entre las sucesivas llegadas de trenes a estaciones. 43 Figura 4-3. Modo en que proceden los pasos de la simulación (Fuente: Elaboración propia) Las predicciones se hacen para a una cierta cantidad N de pasos discretos (N es el horizonte de predicción). Cada uno de estos pasos i ocurre en un instante de tiempo t asociado; sin embargo, los intervalos de tiempo entre pasos discretos sucesivos no tienen por qué ser iguales entre sí. Más aún, a priori no es posible saber a qué instante t corresponde cada paso i, pues depende de la forma en que evolucionen las variables de estado, la cual a su vez depende de las entradas que se le entreguen al modelo. De hecho, el instante de tiempo t asociado a cada paso i se considera como una variable de estado adicional. Las variables manipuladas son los tiempos de holding que se aplican a los siguientes N trenes que arriben a una estación, comenzando por el que acaba de llegar (los horizontes de control y de predicción son iguales en este caso). Exactamente a qué trenes se les aplican estos valores depende del estado inicial del sistema y de los valores de las variables manipuladas anteriores, por lo que a priori sólo tiene sentido hablar del i-ésimo holding aplicado, y no, por ejemplo, del holding aplicado al tren m en la estación e. En realidad, los valores de holding h[i] que usa el modelo no corresponden al tiempo total que el tren permanece en la estación, sino que al tiempo extra por sobre el que se requiere para cargar y descargar los pasajeros. Para determinar el holding verdadero, basta sumarle este tiempo, tal como se calcula en el modelo (corresponde a la variable de estado tpm[i] del tren que gatilla). Hacerlo así facilita 44 la optimización, pues de lo contrario todos los valores de holding inferiores al tiempo de carga y descarga producirían el mismo resultado. Para hacer más simple el modelo, sólo se usan variables de valor continuo. En particular, la cantidad de pasajeros que hay en un tren o estación en un momento dado es continua. Esto no corresponde a la realidad, por supuesto, pero la diferencia es menor. Las perturbaciones del sistema son principalmente las diferencias entre el valor previsto y real de pasajeros que llegan a cada estación, las diferencias en las proporciones de pasajeros que van a cada destino respecto de lo que prevén las matrices origen-destino y las diferencias entre el tiempo programado y el que realmente toman los trenes en recorrer una distancia. Para todas estas variables, el modelo emplea tasas o valores promedio para hacer sus predicciones. 4.3.3 Parámetros y variables El modelo emplea los siguientes parámetros: N: Horizonte de predicción C: Capacidad de los trenes λe : Tasa de llegada de pasajeros a la estación e α, β, γ : Coeficientes para determinar los tiempos de carga y descarga de trenes Me1,e2 : Elemento de la matriz origen destino indicando la proporción de pasajeros subidos en la estación e1 que van a la estación e2 Le : Largo del tramo de línea que sigue a la estación e D: Distancia mínima a la que se pueden acercar dos trenes v: Velocidad media de los trenes en los tramos de línea entre estaciones Además, se considera el conjunto M de todos los trenes que hay en la línea y el conjunto E de todas las estaciones. 45 Se usan las siguientes variables de entrada (manipuladas): h[i] : Holding aplicado al tren que gatilla el paso i al llegar a la estación (en realidad, diferencia entre el tiempo de permanencia del tren con holding y el que tendría sin holding). Puede tomar cualquier valor positivo. Como variables de estado se consideran: t[i] : Instante en que ocurre el paso i eam[i] : Estación en que se encuentra el tren m en el paso i tpm[i] : Tiempo de carga y descarga de pasajeros en la estación en que se encuentra el tren m durante el paso i pee[i] : Pasajeros que hay en la estación e en el instante i tlm[i] : Instante de llegada del tren m a la estación en que se encuentra durante el paso i pmm,e[i] : Pasajeros transportados por el tren m con destino a la estación e en el paso i tdv[i] : Instante en que debe ocurrir el siguiente despacho de un tren desde la cola de maniobra terminal hacia la vía v estando en el paso i tee[i] : Tiempo total de espera de pasajeros entre el paso i y el paso i-1 en la estación e tvm[i] : Tiempo total de viaje de pasajeros entre el paso i y el paso i-1 en el tren m 4.3.4 Mecánica del modelo Las variables de estado se inicializan, para i=k (paso en que el sistema invoca al control), con los valores entregados por el simulador (o, en el caso de un sistema real, por los sensores y estimadores disponibles). El estado inicial incluye el número de pasajeros pee[k] que hay en la estación e, la cantidad en el metro m, etc. Aunque se sabe cuántos pasajeros hay en cada tren, no se tiene el dato requerido 46 por el modelo de qué proporción de estos pmm,e[k] va a cada estación de la línea; estos valores deben estimarse previamente a partir de la matriz origen-destino. Otros, como el tiempo perdido en su estación actual por cada tren tpm[k] se calculan de la misma forma que en el desarrollo del modelo, que se explica a continuación. En todo caso, todos estos valores iniciales se asumen conocidos en el desarrollo que sigue. La función x̂ [i]=f(x[i-1],u[i-1]), para un paso i dado de la predicción, corresponde a las actualizaciones de variables de estado que se explican a continuación. Estas actualizaciones deben aplicarse N veces (i=k+1,…,N). a) Se comienza determinando en qué instante arriba a la próxima estación cada tren m en base al tiempo que debe permanecer en la estación actual y al que toma recorrer el tramo de línea que sigue. Asumiendo velocidad constante de los trenes a lo largo del tramo de línea, la ecuación resultante es: ˆ m = tlm [i − 1] + tpm [i − 1] + ta Leam [ i−1] v , ∀m ∈ M (4.6) Comparando estos valores se determina qué tren mˆ * arriba primero a una estación y por tanto gatilla el siguiente evento, y en qué instante: ˆ m} tˆ[i ] = min m∈M {ta (4.7) ˆ m} mˆ * = arg min m∈M {ta (4.8) tlˆ m*[i ] = tˆ[i] (4.9) tˆa m y mˆ * no son variables de estado sino que auxiliares: se usan para calcular el valor de otras variables de estado, pero una vez hecho esto no es necesario conservarlas para tener una representación completa del 47 estado del sistema en el paso i. Para diferenciarlas, se las escribe sin el valor entre corchetes [i]. Como el tren gatillante acaba de arribar a una nueva estación, debe aumentarse en 1 el valor de su estación actual: ˆ mˆ *[i ] = eamˆ *[i − 1] + 1 ea b) (4.10) Se calcula un valor a priori de la cantidad de pasajeros que hay en cada estación determinando cuántos debieran haber llegado desde el paso anterior. Como asumimos que los pasajeros son “continuos”, basta multiplicar la tasa de llegada por el tiempo transcurrido: ˆ 'e = pee [i − 1] + λe ( tˆ[i] − t[i − 1]) , pe ∀e ∈ E (4.11) Éstas son variables auxiliares; luego, en las ecuaciones 4.19 y 4.20, se corrigen estos valores con las subidas y bajadas de pasajeros para determinar el nuevo valor de las correspondientes variables de estado. c) Los tiempos de espera de los pasajeros se actualizan para incorporar el área bajo la curva de la figura 4-4: ˆ e [i ] = 1 ( tˆ[i ] − t[i − 1]) ( pe ˆ e [i ] − pee [i − 1]) , te 2 ∀e ∈ E (4.12) Lo mismo se hace para los trenes. En este caso, el total de pasajeros se mantiene constante para el trayecto entre pasos sucesivos: ˆ m [i ] = ( tˆ[i ] − t[i − 1]) ∑ pmm,e [i − 1] , tv e∈E ∀m ∈ M (4.13) 48 Figura 4-4. Gráfico de los tiempos de espera de pasajeros (Fuente: Elaboración propia) Las actualizaciones que siguen sólo se realizan hasta el penúltimo paso de predicción (i=k+N-1), pues corresponden a variables de estado que sólo se usan para ayudar a determinar cuándo debe ocurrir el siguiente paso. d) Las siguientes variables auxiliares permitirán simplificar las expresiones que siguen: i) Estación a la que acaba de llegar el tren que gatilló la acción: ˆ * = ea ˆ mˆ * [i ] ea ˆ * = ∑ pm ˆ mˆ *,e [i ] ii) Número total de pasajeros en el tren mˆ * : pmt e∈E iii) Capacidad que queda en el tren que acaba de llegar. Se deben restar de la capacidad total los pasajeros que vienen, excepto los que se bajan en la ˆ * + pmmˆ *,eaˆ *[i − 1] estación actual: cˆ* = C − pmt Se calcula la cantidad de pasajeros que bajan y suben del tren recién llegado, respectivamente. La primera corresponde a los pasajeros que tenían como destino la estación actual y la segunda a los que había en la estación, siempre y cuando haya capacidad para ellos en el tren: 49 ˆ = pmmˆ *,eaˆ *[i − 1] pb (4.14) ˆ = min { pe ˆ 'eaˆ * , cˆ *} ps (4.15) Esto sirve para determinar el tiempo perdido por dicho tren en la estación, tanto para subir y bajar pasajeros como para hacer holding en la estación. El modelo usado es una simplificación del introducido en la ecuación 3.1 para el simulador: ˆ mˆ *[i ] = α + β pb ˆ + γ ps ˆ + h[i ] tp (4.16) Los pasajeros que bajaron deben ser descontados del tren; los que suben deben ser repartidos por estación a la que van según la matriz origendestino: ˆ mˆ *,eaˆ *[i ] = 0 pm (4.17) ˆ mˆ *,e [i ] = pmmˆ *,e [i − 1] + M eaˆ *,e ps ˆ , pm ˆ * ∀e ∈ E , e ≠ ea (4.18) La cantidad de pasajeros en cada estación se actualiza a partir de los valores a priori para descontar los que se subieron en la estación gatillante: ˆ eaˆ *[ï ] = pe ˆ 'eaˆ * − ps ˆ pe (4.19) ˆ e [i] = pe ˆ 'e , pe (4.20) ˆ * ∀e ∈ E , e ≠ ea Todas las variables que no se indicó aquí cómo se actualizan (básicamente, las que no corresponden al tren que gatilló el paso actual) se entiende que conservan su valor del paso anterior. 50 4.3.5 Función objetivo La meta es minimizar una combinación de los tiempos de viaje y de espera de pasajeros, dentro del horizonte de predicción del modelo. Por lo tanto, la función objetivo es J= N 1 ⎛ ˆ e [k + j ] + (1 − μ ) ∑ tv ˆ m [k + j ] ⎞⎟ μ ∑ te ∑ ⎜ tˆ[k + N ] − t[k ] j =1 ⎝ e∈E m∈M ⎠ (4.21) donde μ es un ponderador que permite asignar mayor o menor peso al tiempo de espera en estaciones contra el tiempo de viaje en trenes. El factor normalizador a la izquierda de la ecuación se usa para considerar el hecho de que el tiempo continuo total abarcado por la predicción no es siempre el mismo y depende de las entradas empleadas. Así, un mayor valor de los tiempos totales de espera podría ser simplemente el resultado de que la predicción es a más largo plazo. El factor normalizador corrige esto. La minimización que se necesita entonces es: ˆ e [k + 1],..., te ˆ e [k + N ], tv ˆ m [k + 1],..., tv ˆ m [ k + N ]) Minh[ k ],...,h[ k + N −1] J ( t[ k ], tˆ[ k + N ], te (4.22) 4.3.6 Restricciones Las restricciones g(x,u) tienen relación con no permitir que dos trenes se acerquen a más distancia que D entre sí, valor que corresponde a un parámetro de seguridad. Tomando en cuenta la estructura del modelo, hay dos formas en que esta restricción podría violarse: cuando el tren m* que gatilló el paso anterior de la predicción está en la misma estación o tramo de línea que su antecesor y con tiempos de llegada tam* muy cercanos entre sí; o cuando el tren m* está una estación por delante de su sucesor con los tam* demasiado parecidos. Las restricciones entonces son: 51 ˆ mˆ * − ta ˆ mˆ *+1 > D ˆ m* [i + 1] ≠ ea ˆ mˆ *+1 [i + 1] ∨ ta ea v ˆ mˆ *−1 − ta ˆ mˆ * > ˆ mˆ *−1 [i + 1] ≠ eˆmˆ * [i + 1] ∨ ta ea D v (4.23) (4.24) ˆ mˆ * corresponde al paso i+1 de la simulación y se calcula según la Donde el ta ecuación 4.6. Como por las características del modelo es difícil plantear esta restricción en forma separada, se la implementó como una penalización a la función objetivo. En cada paso se le da un valor muy grande a una variable de estado adicional, r[i], si se viola la restricción en ese paso. La condición para que la restricción sea violada es que el tren esté en la misma estación o tramo de línea que su antecesor o una estación por delante de su sucesor, con tiempos de llegada a la estación siguiente muy cercanos entre sí: ⎧ ⎪N × C ⎪ ⎪ rˆ[i ] = ⎨ ⎪ ⎪ 0 ⎪ ⎩ ⎛ ˆ mˆ * − ta ˆ mˆ *+1 < D ⎞⎟ ∨ ˆ mˆ *[í + 1] = ea ˆ mˆ *+1[i + 1] ∧ ta si ⎜ ea v⎠ ⎝ ⎛ ˆ mˆ *−1 − ta ˆ mˆ * < D ⎞⎟ ˆ mˆ *−1[i + 1] = ea ˆ mˆ *[i + 1] ∧ ta ⎜ ea v⎠ ⎝ e.o.c. (4.25) donde C es un número muy grande. La función objetivo se transforma entonces en J= N N −1 1 ⎛ ˆ e [k + j ] + (1 − μ ) ∑ tv ˆ m [k + j ] ⎞⎟ + ∑ rˆ[k + j ] μ ∑ te ∑ ⎜ tˆ[k + N ] − t[k ] j =1 ⎝ e∈E m∈M ⎠ j =0 (4.26) 4.3.7 Control de despacho desde terminales Haciendo pequeñas modificaciones es posible incorporar los tiempos de despacho desde los terminales como variables manipuladas. Para ello se consideran las colas de maniobra como estaciones adicionales en las que es posible aplicar un holding, 52 que corresponde entonces al tiempo hasta realizar el siguiente despacho. El hecho de que no haya pasajeros no afecta, pues basta hacer α=β=γ=0 en los parámetros de la ecuación 4.16 para la “estación” correspondiente. 4.3.8 Limitación del número de trenes involucrados Como la cantidad de variables involucradas en el problema es bastante grande, al optimizador se le puede hacer difícil encontrar buenas soluciones en un plazo razonable. Se podría disminuir el horizonte de predicción N, pero al hacerlo es probable que la capacidad del modelo de prever hacia adelante se limite. En particular, la predicción puede que no alcance a incluir el momento en que el tren que gatilló la llamada al control y para el que se fija en definitiva el holding llega a la estación siguiente a la actual. Si esto ocurre, el optimizador no tomará en cuenta los efectos para la estación que sigue de retrasar mucho un tren, efectos que naturalmente son relevantes. Otra solución es limitar el conjunto de trenes involucrados en la solución. La idea es tomar sólo los M0 trenes que anteceden y suceden al que gatilló la llamada al control. Todos los demás se descartan, por lo que en total se toman en cuenta sólo (M0+1) trenes. M0 es un parámetro del control fijado desde el simulador vía los argumentos opcionales. Naturalmente, esta solución introduce un sesgo, en el sentido de que el modelo es miope ante lo que ocurre con los trenes no incluidos en el rango; su efectividad se basa en el supuesto de que las acciones realizadas sobre un tren no se propagan de forma demasiado importante muchos trenes más allá. Se trata de un supuesto razonable y bastante usado en la literatura, pero que debe ser comprobado empíricamente. 4.3.9 Optimización con algoritmos genéticos Para la optimización se usó el paquete de algoritmos genéticos de MATLAB. Los algoritmos genéticos permiten atacar problemas altamente multivariados no lineales y son relativamente rápidos, lo que los hace muy apropiados para emplearlos en este caso. Sin embargo, no garantizan llegar al óptimo. Esto no es 53 grave considerando que cada vez que un tren llega a una estación, el problema de optimización se resuelve de nuevo a partir de los nuevos valores que toman las variables de estado, sin tomar en cuenta los resultados de la optimización anterior. De esta forma, el valor de holding entregado por el controlador sólo afecta al metro actual, por lo que una solución cercana al óptimo es probablemente suficiente. La mecánica básica de los algoritmos genéticos (Goldberg, 1989) es que se escoge inicialmente una población aleatoria, consistente en un conjunto de soluciones factibles al problema de optimización. Los miembros de esta población son vectores (en este caso, vectores de N componentes con los próximos tantos holding que deben aplicarse); a los componentes de estos vectores se les llama en este contexto genes. En cada paso del algoritmo, se seleccionan los miembros más “fuertes” de la población (esto es, los que tienen un menor valor en la función objetivo) y, mediante una serie de operaciones entre ellos se llega a una nueva población, correspondiente a lo que se llama la siguiente generación. Estas operaciones pueden ser de dos tipos: combinación, en que se toman dos miembros “padres” y se forma uno nuevo de forma que cada componente es igual al de uno de los padres, elegido aleatoriamente; y mutación, en que se toman miembros individuales y aleatoriamente se alteran algunos de sus genes. Además, algunos de los miembros más fuertes (la elite) pasan directamente a la siguiente generación. El proceso sigue por un número definido de pasos o hasta que el mejor miembro de la generación actual ya no sea muy superior al de la generación anterior. Naturalmente, el proceso toma bastante tiempo, ya que evaluar cada miembro o solución factible en la función objetivo implica correr de nuevo todo el modelo, para encontrar los valores de tee[k], tvm[k] y r[k]. La función de algoritmos genéticos de MATLAB, ga(), tiene una serie de parámetros. Para este ensayo se escogieron los valores predeterminados. La idea es que logren mantener en cada paso la población lo suficientemente “diversa” (valores de los miembros no demasiado similares entre sí) como para que el 54 algoritmo no se sesgue, tendiendo al mismo tiempo a hacer aparecer los mejores miembros posibles. Los parámetros usados son: • Tamaño de la población: 20 miembros por generación. • Población inicial: Se crea aleatoriamente a partir de una distribución uniforme en que todos los genes deben tomar valores entre 0 y 100 segundos. • Escalamiento de valores: Para determinar qué miembros se usan para formar la generación siguiente, es necesario asignarle a cada uno un puntaje. Una opción sería usar simplemente el valor que toma en la función objetivo; sin embargo, en este caso se usa un sistema un poco más sofisticado, llamado rank. Este sistema ordena los miembros según su valor en la función objetivo y a cada uno se le asigna un puntaje proporcional a la raíz cuadrada de su rango. • Selección: El algoritmo escoge los miembros que se usarán para formar la siguiente generación usando un método estocástico uniforme, es decir, va escogiendo los miembros uno por uno, aleatoriamente, donde cada miembro tiene una probabilidad de ser escogido en cada pasada proporcional a su puntaje. Un mismo miembro puede ser elegido dos veces. • Reproducción: El algoritmo hace pasar directamente los mejores dos miembros del conjunto elegido a la generación siguiente; de los que quedan, el 80% se usa para combinación y el 20% para mutación. Estos valores son los que MATLAB usa por defecto. • Combinación: Es dispersa, es decir, cada gen de un nuevo miembro generado por combinación se escoge aleatoriamente entre los correspondientes genes de los dos padres. • Mutación: Para los miembros escogidos para mutación, se le suma a cada gen un valor aleatorio obtenido de una distribución gaussiana de media 0. La desviación estándar va disminuyendo a lo largo de los sucesivos pasos del algoritmo. 55 • Criterio de parada: El algoritmo se detiene cuando se llega a la centésima generación o cuando no hay un cambio mayor a 10-6 en el valor promedio de las poblaciones sucesivas durante 50 generaciones. 4.4 Resultados obtenidos 4.4.1 Características de la línea de prueba Como línea de prueba se escogió la del Metro de Valparaíso (Merval). Es una línea de veinte estaciones que corre entre el puerto de Valparaíso y la ciudad de Limache. En total tiene 43.13 km de largo, aunque de éstos, 12.71 corresponden exclusivamente al último tramo, entre las estaciones Peña Blanca y Limache. Las colas de maniobra tienen espacio para almacenar a un tren cada una. No se consideraron ramas laterales ni bucles en la línea. Aunque los trenes tienen distintas capacidades (hay de 400 y de 800 pasajeros), aquí se optó por considerar sólo trenes de 400 pasajeros. Se consideran 19 trenes en total entre ambas vías, repartidos inicialmente de forma uniforme a lo largo de éstas. Los trenes viajan por los tramos de línea a 50 km/hr. Las llegadas de pasajeros se obtuvieron a partir de una muestra de veinte días, siempre correspondiendo a días martes entre las 9:00 y las 9:15 de la mañana. La tecnología de tarificación de Merval permite determinar en qué estación se bajó cada pasajero subido, lo que facilita obtener las matrices origen-destino. En promedio llegan 0.27 pasajeros por minuto en la vía uno de la línea y 1.26 en la vía dos; las desviaciones estándar son, respectivamente, 0.29 pasajeros/min y 1.47 pasajeros/min. 4.4.2 Resultados de comparación entre estrategias Las dos estrategias de control descritas fueron implementadas en MATLAB y probadas usando el simulador descrito en el capítulo 3, usando la interfaz apropiada, como se explica en la sección 3.2.5. A continuación se enumeran e interpretan los resultados obtenidos, comparándolas con un caso que no usa información en tiempo real. 56 a) Resultados en lazo abierto Primeramente se hicieron pruebas en lazo abierto, es decir, sin aplicar control en tiempo real, de forma de tener una base sobre la que comparar la efectividad de las estrategias propuestas. En lugar de control, se aplica un holding h* constante a los trenes cada vez que llegan a una estación. Los trenes se despachan apenas llegan a las terminales. En las tablas 4-1 y 4-2 se incluyen los resultados obtenidos para simulaciones de 2 horas de duración usando el control experto simple descrito en la sección 4.2 para distintos valores del holding constante h*. La tabla 4-1 se refiere a los resultados más importantes de la simulación; esto es, el tiempo de espera promedio de los pasajeros en todas las estaciones de la línea y su tiempo de viaje promedio en los trenes. La tabla 4-2 agrega dos indicadores adicionales. El primero es el headway de entrada a las estaciones, del que se entregan el promedio y la desviación estándar (ambos abarcan todas las pasadas de trenes por todas las estaciones). El segundo es el número total de veces que algún tren, durante el curso de la simulación, se queda esperando frente a una estación sin poder entrar por encontrarla ocupada por el tren anterior. Tabla 4-1. Resultados en tiempos de espera y de viaje en lazo abierto Holding h* Tiempo de espera en Tiempo de viaje en (en estaciones (en trenes (en segundos ) minutos/pasajero) minutos/pasajero) 0 6.76 22.69 30 4.42 22.48 60 3.84 23.47 90 3.80 26.45 120 3.94 30.12 150 4.02 33.03 57 Tabla 4-2. Resultados en headway de entrada y en trenes en espera en lazo abierto Holding h* Headway de entrada en Número de trenes que (en estaciones (en segundos, quedan esperando por segundos ) como prom. y desv. est.) entrar a una estación 0 268.5 / 376.0 167 30 315.8 / 294.7 17 60 388.5 / 247.3 0 90 454.3 / 235.4 0 120 515.2 / 232.1 0 150 575.9 / 228.2 0 Se observa de la tabla 4-1 que el tiempo de espera en estaciones tiene su mínimo para un holding constante de 90 segundos; con valores menores a éste los trenes tienden a juntarse demasiado (bunching, ver la explicación dada en la sección 3.4) y para valores mayores la espera es excesiva. Los tiempos de viaje, lógicamente, aumentan al aumentar los holding, ya que los pasajeros que vienen en un tren deben quedarse más tiempo esperando en cada estación. Un buen compromiso se da con un holding de 60 segundos; en este caso, el tiempo de espera promedio es 3.84 minutos y el de viaje, 23.47 minutos. La tabla 4-2 demuestra que los headway promedio aumentan en forma sostenida al aumentar el holding; sin embargo, sus varianzas aumentan. Lo que ocurre es que como para holding pequeños los trenes tienden a juntarse, en muchas estaciones se acumulan trenes a la entrada que luego entran de inmediato, lo cual significa headway de entrada prácticamente nulos. Esto empuja hacia abajo el promedio de los headway. Sin embargo, las estaciones en que no se acumulan trenes quedan desatendidas, haciendo crecer la varianza. El efecto de acumulación de trenes en estaciones también se puede ver en la última columna de la tabla 4-2. 58 b) Resultados con control experto En las tablas 4-3 y 4-4 se muestran los mismos resultados de las tablas 4-1 y 4-2, respectivamente, pero esta vez aplicando la estrategia experta de la sección 4.2 y variando el parámetro de headway H. Notar que el headway que intenta fijar el parámetro H no es el mismo que el que se muestra como promedio en la tabla 4-4, ya que uno es a la salida de las estaciones y el otro a la entrada. Sin embargo, lo esperable sería que tomaran valores similares, ya que ambos headway están relacionados (después de todo, los trenes que entran y salen de las estaciones son los mismos). Tabla 4-3. Resultados en tiempos de espera y de viaje de aplicar control experto simple Parámetro Tiempo de espera en Tiempo de viaje en H (en estaciones (en trenes (en segundos ) minutos/pasajero) minutos/pasajero) 200 5.67 29.88 250 4.90 28.73 300 5.14 32.64 350 3.39 29.15 400 3.56 31.05 450 4.95 32.77 500 5.95 35.48 59 Tabla 4-4. Resultados en headway de entrada y en trenes en espera de aplicar control experto simple Parámetro Headway de entrada en Número de trenes que H (en estaciones (en segundos, quedan esperando por segundos ) como prom. y desv. est.) entrar a una estación 200 371.8 / 425.4 130 250 386.3 / 382.9 108 300 435.0 / 430.4 78 350 440.4 / 260.1 31 400 497.6 / 286.0 25 450 561.9 / 360.9 25 500 611.8 / 475.9 34 Considerando que la línea, tomando en cuenta ambas vías, tiene en total 86.26 km de largo, y que hay 19 trenes en ella, la distancia entre trenes sucesivos para mantenerlos uniformemente repartidos a lo largo de la línea es de 4.54 km. A 50 km/hr, esto se traduce en un headway de 5.45 minutos. A este valor se le debe agregar un tiempo extra para considerar lo que se pierde en cargar y descargar pasajeros en las estaciones. Considerando esto, el headway H debiera estar en torno a los 350 segundos. En la tabla 4-3 se aprecia que, efectivamente, este valor minimiza los tiempos de espera de pasajeros en las estaciones, así como los de viaje en trenes, obteniéndose 3.39 minutos por pasajero para el primero y 29.15 minutos por pasajero para el segundo. Es decir, un indicador mejora en un 12.7% y el otro empeora en un 24.2%. Es razonable que el tiempo de viaje empeore, ya que una estrategia enfocada en headway sólo atiende directamente a los tiempos de espera. En todo caso, la tabla 4-4 demuestra que con esta estrategia en ningún caso se alcanzan los headway promedio de entrada que el controlador intenta establecer, 60 sino que éstos son siempre mayores; la varianza entre headway también es grande. La razón se encuentra por un lado en la gran diferencia entre los largos de los distintos tramos de línea, en particular el último entre Peña Blanca y Limache, que dificultan mantener la regularidad, y por otro en las demoras para cargar y descargar pasajeros, que frecuentemente hacen que los trenes se queden parados en una estación más tiempo del programado. Los trenes también se acumulan bastante frente a estaciones, especialmente cuando H es muy bajo y los trenes se juntan, como se observa también en la tabla 4-4. c) Resultados con control predictivo En las tablas 4-5, 4-6, 4-7 y 4-8 se muestran los resultados aplicando el control predictivo descrito en la sección 4.3, para distintos valores del horizonte de predicción N y del parámetro ponderador μ. Los valores aquí mostrados consideran también simulaciones de 2 horas, en que sólo se hace control sobre los holding en estaciones, no sobre los tiempos de despacho. El número de trenes M0 que el controlador toma en cuenta para cada optimización es 3. La distancia mínima entre trenes D es de 300 metros. 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 μ 1 0.5 0 5 3.76 4.16 7.48 10 3.66 3.89 6.71 15 3.24 3.71 6.30 20 4.86 3.70 5.49 25 3.85 4.25 5.68 N 61 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 μ 1 0.5 0 5 25.06 29.75 39.28 10 26.40 24.92 31.00 15 24.45 24.26 30.68 20 27.69 26.93 28.42 25 26.38 26.21 29.40 N 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 μ 1 0.5 0 5 268.9 / 388.1 450.7 / 266.4 762.6 / 432.8 10 414.9 / 283.7 366.9 / 249.5 602.7 / 456.1 15 374.3 / 249.0 368.0 / 245.1 548.7 / 397.1 20 466.6 / 329.7 402.0 / 240.7 490.5 / 339.3 25 444.7 / 237.3 421.7 / 216.8 503.3 / 296.9 N 62 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 μ 1 0.5 0 5 171 46 35 10 12 21 44 15 15 15 30 20 14 16 18 25 6 8 19 N El mejor resultado se obtiene con μ=1 y N=15: 3.24 minutos por pasajero de espera en estaciones y 24.45 minutos de viaje en trenes. Esto representa una mejora de 9.6% y de 8.4%, respectivamente, en comparación con los valores correspondientes al mejor caso del controlador simple. El tiempo de viaje no es tan bajo como en el caso con lazo abierto pero está muy cerca. El headway es prácticamente igual en promedio que el mejor caso del control experto con una varianza bastante menor, lo que indica que el control predictivo es superior también en este aspecto. Para el número de trenes estancados, los números son tan buenos o mejores que los del control experto; sin embargo, no son nulos, lo que indica que las restricciones están siendo violadas cada cierto tiempo. 4.4.3 Resultados variando parámetros del controlador predictivo Como ya se discutió en la sección anterior, al control predictivo posee bastantes más parámetros modificables que el experto. Éstos incluyen el horizonte de predicción N, el ponderador μ de la función objetivo (explicado en la sección 4.3.5), el número de trenes M0 considerado por el optimizador (explicado en la sección 4.3.8) y la distancia D mínima entre trenes exigida por las restricciones (explicada en la sección 4.3.6). Además está la posibilidad de controlar sólo los 63 holding en las estaciones o también los tiempos de despacho desde los terminales, como se explica en la sección 4.3.7. En esta sección se describen las consecuencias de variar algunos de estos parámetros, incluyendo los parámetros N y μ cuyos resultados ya se presentaron en las tablas 4-5 a 4-8. En las tablas 4-5 a 4-8, correspondientes al caso en que M0=3 y D0=300 m, y no se actúa sobre los tiempos de despacho desde terminales, se aprecia que aumentar el horizonte de predicción no siempre es beneficioso. Probablemente la razón es que al aumentar N aumenta el número de variables de optimización que el algoritmo genético debe utilizar, haciendo más difícil que encuentre un óptimo global. Sin embargo, los datos de las tablas 4-5 y 4-6 dan a entender que conviene considerar un horizonte de predicción de por lo menos 15. Esto también permite disminuir el número de trenes que se quedan estancados. También se observa que darle más peso a los tiempos de viaje respecto de los de espera en la función objetivo no necesariamente mejora los primeros; de hecho, la tendencia es a que empeoren. El horizonte de predicción no es suficiente para permitir predecir adecuadamente los efectos de un mayor o menor holding sobre los tiempos de viaje de los pasajeros en determinado tren. De lo anterior se deduce que es más provechoso concentrarse en disminuir los tiempos de espera en estaciones; al hacerlo, los tiempos de viaje bajarán también. En las tablas 4-9, 4-10, 4-11 y 4-12 se repiten las mismas pruebas realizadas para las tablas 4-5 a 4-8, pero considerando ahora control sobre los tiempos de salida además de sobre los holding en estaciones. Los demás parámetros se mantienen igual. 64 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 μ 1 0.5 0 5 4.19 4.25 5.09 10 3.65 4.19 6.84 15 3.24 4.28 6.48 20 2.99 4.52 5.81 25 2.96 4.41 5.13 N 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 μ 1 0.5 0 5 25.61 29.29 38.67 10 26.07 26.56 30.79 15 24.14 26.90 30.12 20 26.49 26.03 33.46 25 26.40 27.58 32.79 N 65 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 μ 1 0.5 0 5 397.1 / 322.1 470.3 / 277.0 750.1 / 390.7 10 409.8 / 291.5 413.0 / 300.8 618.3 / 444.0 15 405.7 / 185.0 400.5 / 294.5 574.5 / 465.7 20 427.8 / 193.5 439.4 / 296.7 569.0 / 415.9 25 421.7 / 257.8 453.6 / 318.4 537.1 / 339.6 N 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 μ 1 0.5 0 5 16 46 28 10 8 36 46 15 5 29 34 20 6 19 22 25 7 29 17 N En este caso, aplicando un control predictivo N=25 y manteniendo μ=1, se obtiene un tiempo de espera en estaciones de 2.96 minutos por pasajero y de viaje en trenes de 26.40 minutos por pasajero; corresponden a una mejora de 9.1% y a un empeoramiento de 8.0%, respectivamente, comparado con el caso de sólo control de holding. Sin embargo, el mayor horizonte de predicción implica un mayor costo computacional para el optimizador. El headway promedio empeora y el número de 66 trenes atascados mejora, aunque esto último, nuevamente, es sólo debido al mayor horizonte de predicción. En las tablas 4-13, 4-14, 4-15 y 4-16 se comprueban los efectos de variar el número de trenes M0 considerados por el controlador, para distintos horizontes de predicción. En este caso se consideró μ=0.5 y D=300 metros. Se incluyen los casos para 2, 3 y 4 trenes por delante y por detrás del que gatilló la acción de control; es decir, en cada caso se consideran en total 5, 7 y 9 trenes, respectivamente. También se incluye el caso en que se toman en cuenta los 19 trenes de la simulación. 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 M0 Todos los 2 3 4 5 4.13 4.16 4.60 4.38 15 3.97 3.71 5.20 3.84 25 3.31 4.25 4.95 4.25 N trenes 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 M0 Todos los 2 3 4 5 25.62 29.75 31.59 35.58 15 24.02 24.26 26.58 28.45 25 26.93 26.21 27.07 27.00 N trenes 67 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 M0 Todos los 2 3 4 5 413.5 / 264.3 450.7 / 266.4 530.5 / 321.5 617.3 / 348.6 15 364.0 / 271.6 368.0 / 245.1 437.5 / 346.2 488.8 / 264.0 25 399.7 / 201.1 421.7 / 216.8 453.6 / 297.7 498.9 / 267.7 N trenes 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 M0 Todos los 2 3 4 5 41 46 46 28 15 16 15 30 35 25 19 8 19 26 N trenes Como ya se explicó, aumentar el M0 permite considerar el efecto de la acción de control sobre más trenes de la línea, al costo de tomar en cuenta menos información futura para cada tren individual, dependiendo del horizonte de predicción. Las tablas 4-13 y 4-14 confirman que se obtienen mayores beneficios aplicando esta estrategia para horizontes de predicción más cortos. Aunque el M0 óptimo depende de los demás parámetros, para N no demasiado grandes un valor de 2 ó 3 parece el más apropiado. Las tablas 4-15 y 4-16 indican que lo mismo es válido para los headway promedio y el número de trenes estancados, aunque para estos últimos el resultado es menos claro. Finalmente, las tablas 4-17 y 4-18 muestran el resultado de variar la velocidad de operación de los trenes cuando N=20, μ=0.5, M0=3 y D=300 metros. 68 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 Velocidad Tiempo de espera en Tiempo de viaje en de los trenes estaciones (en trenes (en (en km/hr) minutos/pasajero) minutos/pasajero) 45 3.72 25.81 50 3.32 24.25 55 3.80 26.00 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 Velocidad Headway de entrada en Número de trenes que de los trenes estaciones (en segundos, quedan esperando por (en km/hr) como prom. y desv. est.) entrar a una estación 45 369.5 / 291.0 19 50 392.5 / 206.5 17 55 405.1 / 257.6 17 Se observa que aumentar una mayor velocidad no necesariamente mejora los indicadores; es más relevante la regularidad en el servicio. 69 5. CONCLUSIONES Y RECOMENDACIONES 5.1. Conclusiones El simulador fue realizado exitosamente de acuerdo a los objetivos que se habían propuesto. Evidentemente, simplifica varios aspectos de la operación real de trenes, en particular aquéllos relacionados con su movimiento entre estaciones y los tiempos de subida, bajada y transferencia de pasajeros. Una validación real en un sistema de trenes auténtico está pendiente; se trata de una tarea que requiere de bastante más tiempo del que estaba disponible para realizar esta tesis. Sin embargo, el funcionamiento relativamente confiable de los sistemas de metro permite que un simulador simple como el actual se aproxime a la realidad con bastante fidelidad. Prácticamente todos los elementos importantes de un sistema de tren metropolitano normal están considerados en el simulador. Para ser una representación fiel de un sistema como los Metros de Santiago y Valparaíso, las principales carencias son la incapacidad de incorporar bucles (capacidad de cambiar trenes de vía en puntos a lo largo de la línea) y un tratamiento más detallado del consumo de energía. Esto último podría complementarse con normativas de tarificación eléctrica para incorporar aspectos como el cobro por potencia. El simulador logra representar exitosamente fenómenos conocidos de la operación de este tipo de sistemas como el bunching o tendencia de los trenes a juntarse si no se los controla. Esto da confianza en sus capacidades predictivas frente a escenarios más complejos que, por razones de tiempo, no pudieron ser probados exhaustivamente en esta tesis. Al permitir al usuario programar sus propias funciones de control en tiempo real en un lenguaje como MATLAB o SCILAB, el simulador ofrece una gran flexibilidad para desarrollar muy variadas estrategias de operación y de control en tiempo real, como muestran las dos alternativas presentadas en el capítulo 4. 70 El tiempo de ejecución de una simulación es muy reducido y no aumenta demasiado por la interacción con el software de cómputo para el control (a menos que la misma función escrita por el usuario tome mucho tiempo en ejecutarse por realizar cálculos muy complejos). Para estrategias de control normales, el simulador es capaz de realizar simulaciones de varias horas en segundos en un PC normal. Las pruebas con el simulador muestran que en lazo abierto (aplicando un tiempo de holding o retención constante en las estaciones), para holding muy pequeños los trenes tienden a juntarse (bunching). Esto se ve reflejado en un aumento de la variabilidad de los headway o intervalos entre entradas sucesivas de trenes a una estación y en el tiempo que un tren debe detenerse antes de ingresar a una estación por encontrarla ocupada. Para holding demasiado grandes, en cambio, el headway promedio tiende a aumentar, pero el movimiento se hace más regular. Tanto los headway demasiado grandes, producidos por holding muy largos, como los headway demasiado irregulares, producidos por holding muy breves, tienen un efecto negativo sobre los tiempos de espera de pasajeros, por lo que el óptimo se encuentra usando un tiempo de holding intermedio. Los tiempos de viaje, en cambio, se benefician en principio de un holding lo más breve posible (ojalá nulo), pues éste implica que los pasajeros que viajan en un tren deben esperar menos tiempo en cada estación. El controlador experto permite disminuir los tiempos de espera en alrededor de 12% respecto al caso sin control, pues aplica holding variable de forma de regularizar en lo posible los headway sin necesariamente hacerlos crecer demasiado. Los tiempos de viaje, en cambio, se mantienen iguales o empeoran, ya que el control experto no actúa específicamente para disminuirlos. El control predictivo usa los holding para intentar minimizar una función objetivo que considera tanto el tiempo de espera como el de viaje, sin preocuparse directamente de los headway. Logra una mejora de los tiempos de espera en torno al 9% en relación al control experto y en torno al 15% en relación al caso en lazo 71 abierto; los tiempos de viaje son aproximadamente equivalentes al caso sin control (aunque mejores que el experto en alrededor de 8%), pues los tiempos de espera no pueden disminuirse mucho sin aumentar los tiempos de viaje. Sin embargo, como psicológicamente los pasajeros sienten con más fuerza los tiempos de espera, el uso del control predictivo puede ser interesante. Naturalmente, esta ventaja tiene como contraparte la gran cantidad de procesamiento y de captura de datos en tiempo real que el control predictivo requiere, por lo que la inversión asociada no parece justificarse. Variar los parámetros del mismo control predictivo también tiene distintos resultados. Aumentar el horizonte de predicción, aparte de requerir un mayor esfuerzo computacional, sólo tiene un impacto beneficioso menor sobre los indicadores, pues en ocasiones el número excesivo de variables de optimización impide que el algoritmo genético encuentre el óptimo. Incorporar el tiempo de despacho desde las terminales como variable manipulada disminuye los tiempos de espera en aprox. 9% respecto al caso en que el control predictivo sólo incide en el holding en estaciones, aunque a costa del tiempo de viaje, que aumenta 8%. Variar el número de trenes considerados por el simulador es beneficioso principalmente cuando los horizontes de predicción son cortos. La velocidad constante de los trenes no influye en forma relevante en los tiempos de espera o de viaje. 5.2 Recomendaciones para trabajo futuro Aún existen diversos aspectos en los que el simulador puede seguir mejorando. Se espera realizar algunas de estas expansiones en el futuro próximo, siempre dentro del marco del proyecto ADI-32, según las sugerencias que hagan los propios Metros de Santiago y Valparaíso. Las principales actividades a realizar son las ya mencionadas incorporación de bucles y mejorías al modelo de energía. También podría modelarse con más precisión el movimiento de los carros entre estaciones para incorporar las 72 características del perfil de velocidad, y afinarse el modelo de subida y bajada de pasajeros para hacerlo más realista. Otra posible mejoría es la flexibilización del sistema de trenes expresos, para permitir usarlo en el contexto de control en tiempo real. Específicamente, la idea es que la función MATLAB pueda escoger el recorrido expreso que seguirá un tren al ser incorporado a una línea. Algunos de los parámetros que actualmente son genéricos para una línea podrían flexibilizarse para trenes individuales. Así, por ejemplo, podrían tenerse trenes con capacidades diferentes. Una mejora importante sería incorporar al simulador la posibilidad de crear disrupciones en momentos y lugares específicos que retrasen o retengan los trenes durante tiempos definidos. Así se podrían ensayar estrategias para regularizar el servicio tras las fallas o para proveer alternativas de servicio durante las mismas. Otra posibilidad, pensando en sistemas más complejos que los Metros de Santiago y Valparaíso (como por ejemplo el de Nueva York), sería permitir al usuario crear líneas con ramas y divisiones por las que circulen trenes con distintos destinos. Esto implicaría reformular el mecanismo de control y planificación de itinerarios. En cuanto al controlador, podrían hacerse los cambios para incorporar igualmente la minimización de la energía y otros costos a la función objetivo, además de incorporar controles adicionales como bucles o retención en ramas paralelas. También convendría estudiar los efectos de expandir el control a redes de más de una línea para determinar hasta qué punto vale la pena considerar el sistema globalmente en lugar de cada línea por separado. Finalmente, se podrían probar alternativas como aplicar holding sólo en algunas estaciones, o buscar alternativas que requieran medir menos variables de operación. Un desarrollo interesante que se podría ejecutar a partir de este trabajo, empleando una interfaz que comunique el simulador con sensores en línea, y aprovechando las capacidades predictivas del controlador, es un sistema de apoyo a la gestión de los operadores, que les proporcione información en tiempo real del estado actual y 73 futuro próximo del sistema y de las consecuencias de tomar una u otra decisión operacional. 74 BIBLIOGRAFIA Baohua, M., Wenzheng, J., Shaokuan, C. y Jianfeng, L. (2007). A Computer-Aided Multi-Train Simulator for Rail Traffic. IEEE International Conference on Vehicular Electronics and Safety (ICVES’07), Beijing, China 1-5. Barceló, J. y Casas, J. (2003). Dynamic Network Simulation with AIMSUN. Proceedings of the International Symposium on Transport Simulation, Yokohama, Japón. Camacho, E. y Bordons, C. (2004). Model Predictive Control, Second Edition. Springer, Londres, Reino Unido. Cury, J.E., Gomide, F.A.C. y Mendes, M.J. (1980). A Methodology for Generation of Optimal Schedules for an Underground Railway System. IEEE Transactions on Automatic Control, 25(2), 897-902. Daganzo, C. (1997). Fundamentals of Transportation and Traffic Operations, Editorial Pergamon-Elsevier, Cambridge, Reino Unido. Delgado, F., Muñoz, J.C., Giesen, R. y Cipriano, A. (2008). Control de Buses en un Corredor con Información en Tiempo Real Basado en Retención de Buses y Dosificación de Pasajeros. XV Congreso Panamericano de Ingeniería de Tránsito y Transporte (PANAM 2008), Cartagena de Indias, Colombia. De Schutter, B. y Van den Boon, T.J.J. (2002). Connection and Speed Control in Railway Systems — A Model Predictive Control Approach, Proceedings of the 6th International Workshop on Discrete Event Systems (WODES ’02), Zaragoza, España, 49–54. Dessouky, M., Hall, R., Zhang, L. y Singh, A. (2002). Real-Time Control of Buses for Schedule Coordination at a Terminal, Transportation Research Part A, 37(2), 145-164. Dorf, R.C. y Bishop, R.H. (2005). Modern Control Systems, 10th edition. Pearson Prentice Hall, New Jersey, EE.UU. Eberlain, X.J., Wilson, N.H.M. y Bernstein, D. (2001). The Holding Problem with Real– Time Information Available, Transportation Science, 35(1), 1-18. Fu, L., Liu, Q. y Calamai, P. (2003) Real-Time Optimization Model for Dynamic Scheduling of Transit Operations, Transportation Research Record, 1857, 48-55. Goldberg, D. (1989). Genetic Algorithms in Search, Optimization, and Machine Learning. Addison-Wesley, Massachusets, EE.UU. 75 Gomez, C., Bunks, C., Chancelier, J.P., Delebecque, F., Goursat, M., Nikoukhah, R. y Steer, S. (2004). Engineering and Scientific Computing with Scilab. Birkhäuser, Boston, EE.UU. Higgins, A., Kozan, E. y Ferreira, L. (1997) Heuristic Techniques for Single Line Train Scheduling, Journal of Heuristics, 3(1), 43-62. Hill, R.J. y Yates, T.K. (1992). Modelling Railway Block Signalling Systems Using Discrete-Event Simulation. Proceedings of the 1992 ASME/IEEE Spring Joint Railroad Conference, Atlanta, EE.UU, 31, 1-9. Kanacilo, E.M. y Verbraeck, A. (2005). A Distributed Multi-Formalism Simulation to Support Rail Infrastructure Control Design. Proceedings of the 2005 Winter Simulation Conference, Orlando, EE.UU., 2546-2553. Khanbaghi, M. y Malhame, R.P. (1994). Reducing Travel Energy Costs for a Subway Train via Fuzzy Logic Controls. Proceedings of the 1994 IEEE International Symposium on Intelligent Control, Columbus, Ohio, 99-104. Lin, T.H. y Wilson, N.H.M. (1992). Dwell Time Relationships for Light Rail Systems, Transportation Research Record, 1361, 287-295. Liu, R. y Golovitcher, I. (2003). Energy-Efficient Operation of Rail Vehicles. Transportation Research Part A, 37(10), 917-932. Luethi, M., Weidemann, U., Laube, F. y Medeossi, G. (2007). Rescheduling and Train Control: A New Framework for Railroad Traffic Control in Heavily Used Networks, 86th Transportation Research Board Annual Meeting 2007, Washington D.C., EE.UU. Microsoft Corporation (2007). Microsoft Developer Network. Washington, EE.UU. Nash, A. y Hürlimann, D. (2004). Railroad Simulation Using OpenTrack. Computers in Railways, 9, 45-54. O’Dell, S.W. y Wilson, N.H.M. (1999). Optimal Real-Time Control Strategies for Rail Transit Operations During Disruptions, Lecture Notes in Economics and Mathematical Systems, 471, 299-323. Ortiz de Zúñiga, M. (2007). Simulación del Tráfico de Trenes Durante los Transitorios de Encierre y Reposción de una Línea de Metro. Proyecto de fin de título, Instituto de Investigación Tecnológica, Universidad Pontificia Comillas, Madrid, España. 76 Paolucci, M. y Pesenti, R. (1999). An Object-Oriented Approach to Discrete-Event Simulation Applied to Underground Railway Systems. Simulation, 72(6), 372-383 Pillajo, A., Delgado, F. y Milla, F. (2007). Design of Fuzzy Expert Control Strategies for a Public Transport System. Cuarta Escuela de Verano Latinoamericana en Inteligencia Computacional y Primera Escuela de Verano de Robótica (EVIC 2007), Santiago, Chile. PTV Planung Transport Verkehr A.G. (2006). PTV Vission – Tutorial, VISSIM Basic Network. Karlsruhe, Alemania. Quadstone Paramics Ltd. (2006). Quadstone Paramics 6.5 Modeller User Guide. Edinburgh, Reino Unido. Radtke, A. y Hauptmann, D. (2004). Automated Planning of Timetables in Large Railway Networks Using a Microscopic Data Basis and Railway Simulation Technique. Computers in Railways IX, WIT Press, Southampton, EE.UU., 615-625. Sáez, D., Cortés, C.E., Sáez, E., Riquelme, M., Núñez, A. y Tirachini, A. (2007). Hybrid Predictive Control Strategy for a Public Transportation System with Uncertain Demand. Proceedings TRISTAN VI: The Sixth Triennal Symposium on Transportation Analysis, Phuket, Tailandia. Schmöcker, J.D., Cooper, S. y Adeney, W. (2005). Metro Service Delay Recovery: Comparison of Strategies and Constraints Across Systems, Transportation Research Record, 1930, 30-37. Stroustrup, B. (1997). The C++ Programming Language, Special Edition. AddisonWesley, Massachusets, EE.UU. The Mathworks, Inc. (2008). Matlab Builder NE 2 User’s Guide. Massachusets, EE.UU. Törnquist, J. (2005). Computer-Based Decision Support for Railway Traffic Scheduling and Dispatching: A Review of Models and Algorithms, 5th Workshop on Algorithmic Methods and Models for Optimization of Railways (ATMOS 2005), Palma Mallorca, España. Zhao, J., Bukkapatnam, S. y Dessouky, M.M. (2003). Distributed Architecture for RealTime Coordination of Bus Holding in Transit Networks, IEEE Transactions on Intelligent Transportation Systems, 4(1), 43-51. 77 ANEXOS 78 ANEXO A: CLASES DEL SIMULADOR A continuación se presenta una lista de las clases que usa el simulador, junto con los parámetros y variables que contiene cada una y la forma en que procesa la función Procesar Evento. A.1 Línea Posee una lista con referencias a todos los trenes y estaciones (para ambas vías) de la línea. Además, tiene los siguientes parámetros: • INDICE: Índice único para la línea dentro de la red • NOMBRE: Nombre de la línea • CAPACIDAD DE TRENES: Capacidad de los trenes que circulan por la línea • CAPACIDAD DE TERMINAL: Cantidad de trenes que caben de las colas de maniobra en los terminales de la línea • TIEMPO PARA DESPACHO: Tiempo que tarda a los trenes entrar o salir de las colas de maniobra. • TIEMPO PARA ENTRADA ESTACIÓN: Tiempo que les toma a los trenes ingresar a una estación de la línea. • α, β, γ, δ, μεE, σεE: Parámetros que controlan el tiempo mínimo que los trenes pasan en las estaciones, como se explicó en la sección 3.2.1. • μεL, σεL: Parámetros para darle una componente aleatoria al tiempo que toma viajar la distancia entre dos estaciones, como se explicó en la sección 3.2.1. • M, m, a, d, c, g: Parámetros para el cálculo de la energía consumida por los trenes en su movimiento, según se explica en la sección 3.2.3. • HOLDING ESTÁNDAR, VELOCIDAD ESTÁNDAR y TIEMPO ENTRE DESPACHOS ESTÁNDAR: Parámetros por defecto para los trenes de la línea en caso de no realizarse control en tiempo real, como se explicó en la sección 3.2.5. 79 Las líneas tienen las siguientes variables: • SIGUIENTE DESPACHO: Instante en que debe ser despachado el tren siguiente desde la cola de maniobra en cada vía de la línea. Esta clase no procesa eventos propios, por lo que el método Procesar Evento está vacío. A.2 Estación: Los objetos de esta clase representan más bien andenes a cierto lado de la línea; es decir, el andén de la vía en cada dirección de una estación física determinada se representa mediante dos objetos Estación distintos. La clase posee los siguientes parámetros: • ÍNDICE: Índice de la estación dentro de la vía a que corresponde; los índices van ordenados de la primera a la última estación por las que pasan los trenes. • NOMBRE: Nombre de la estación, p.ej., Baquedano • LARGO LÍNEA: Largo, en metros, del largo del tramo de línea que sigue a la estación • CAPACIDAD RAMA, POSICIÓN INICIAL RAMA, POSICIÓN FINAL RAMA y TIEMPO ENTRE DESPACHOS RAMA: Parámetros de la rama lateral en el tramo de línea que sigue a la estación, si es que existe. • λL, λG: Parámetros que determinan la llegada de pasajeros a la estación, como se explicó en la sección 3.2.1. En realidad, lo que la clase posee es una lista de ternas ordenadas (ti, λL, λG), donde ti corresponde al instante en que el i-ésimo par de parámetros (λL, λG) comienza a ser válido. • VECTOR DE PROBABILIDADES DE DESTINOS: Arreglo que corresponde a la fila de la matriz origen-destino que contiene las probabilidades de que los pasajeros que llegan a la estación actual vayan a cada una de las siguientes. 80 Las principales variables asociadas a la clase Estación son las siguientes: • ESTADO: Debe tomar uno de los valores Ocupada o Vacía, según si hay o no actualmente un tren en la estación. • TREN ACTUAL: Índice del tren actualmente en la estación, si es que hay uno. • NÚMERO DE PASAJEROS: Número de pasajeros en la estación, separados según su estación de destino (en realidad es un arreglo de números de tamaño igual a la cantidad de estaciones en la línea que siguen a la actual). • SIGUIENTE DESPACHO DESDE RAMA: Si el tramo de línea que sigue a la estación posee una rama lateral, este valor corresponde al instante en que debe ser despachado el primer tren que se encuentre allí. Los eventos asociados a las estaciones se relacionan con la llegada de pasajeros a ellas. La invocación de la función Procesar Evento indica que ha llegado un grupo de pasajeros en el instante actual. Se determina el tamaño del grupo de pasajeros, que luego se divide aleatoriamente en sub-grupos según su estación de destino y el resultado va a aumentar el componente correspondiente del arreglo NÚMERO DE PASAJEROS; esta división se hace según las probabilidades contenidas en el VECTOR DE PROBABILIDADES DE DESTINOS de la estación. Finalmente, se calcula el tiempo hasta la llegada del próximo grupo de pasajeros y se incorpora el resultado a la variable TIEMPO DE PRÓXIMO EVENTO de forma que la función Procesar Evento vuelva a ser invocada en el momento oportuno. Hay que recordar que las tasas λG y λL dependen del instante actual, pues pueden tomar distintos valores a medida que pasa el tiempo, como ya se explicó. A.3 Tren Ésta es la clase que tiene el mayor nivel de complejidad, pues maneja el movimiento de los trenes a través de la línea, el cual pasa por varias etapas. El tren tiene el siguiente parámetro asociado: 81 • ÍNDICE: Índice que identifica al tren en la línea; no está necesariamente relacionado con la posición del tren relativa a otros trenes pues ésta puede cambiar a partir de ciertas operaciones y el índice siempre se mantiene constante. También tiene varias variables asociadas: • ESTADO: Debe tomar uno de los valores En Estación, En Tramo de Línea, Entrando a Terminal, En Terminal, Saliendo de Terminal, Entrando a Rama, En Rama, Saliendo de Rama, Esperando Entrar a Estación o Esperando Entrar a Rama, según la situación actual del tren. • ÍNDICE ORDENADO: Posición del tren actual relativo a los otros trenes de la línea; los trenes que están en ramas laterales tienen este valor nulo y quedan fuera de la ordenación. Cuando un tren ingresa a la línea desde una rama, debe re-calcularse el índice de todos los trenes de la línea. • VÍA, ESTACIÓN ACTUAL: Dan la ubicación actual del tren. • NÚMERO DE PASAJEROS: Número de pasajeros actualmente a bordo del tren, separados por estación de destino (en realidad es un arreglo de tamaño igual al de la cantidad de estaciones en la línea). • HOLDING, VELOCIDAD: Valores actuales de estos parámetros que determinan la operación del tren. • ÍNDICE DE RECORRIDO EXPRESO: Índice que indica a qué entrada de la lista de recorridos expresos debe atenerse el tren actual, como se explicó en la sección 3.2.1: • PRÓXIMA RAMA: Si el tren está camino a alguna rama lateral en que debe ser almacenado, este valor indica a qué tramo de línea corresponde dicha rama. Esto ya se explicó en la sección 3.2.1. La función Procesar Evento se llama básicamente cada vez que el tren cambia de estado. Entonces, se actualiza la variable ESTADO para reflejar la nueva 82 condición del tren y se hace el procesamiento que corresponda, lo cual en casi todos los casos involucra hacer una llamada a Actualizar Controles, la función del Controlador que se encarga de actualizar los valores de las variables manipuladas de los trenes para el control en tiempo real, como se explicó en la sección 3.2.5. Procesar Evento termina actualizando la variable TIEMPO DE PRÓXIMO EVENTO con el instante en que el tren nuevamente debe cambiar de estado. A continuación se indica en qué consiste a grandes rasgos el procesamiento de Procesar Controles para los casos principales: • Cuando el tren llega a una cola de maniobra en uno de los terminales de la línea, se verifica que sea el primer tren en la cola. Si no es así, el tren se deja en espera, es decir, la variable TIEMPO DE PRÓXIMO EVENTO se deja en blanco; su valor debe ser fijado por el tren que antecede en la cola de maniobra en el momento en que salga de ella. Si el tren actual es el primero de la cola, su TIEMPO DE PRÓXIMO EVENTO y el SIGUIENTE DESPACHO de la línea se fijan de forma que se respete el TIEMPO ENTRE DESPACHOS ESTÁNDAR de la línea, aunque puede ser cambiado luego por el Controlador. • Cuando un tren está saliendo de la cola de maniobra, su TIEMPO DE PRÓXIMO EVENTO se fija con el TIEMPO PARA DESPACHO correspondiente a la línea actual. Se revisa si hay algún otro tren haciendo fila en la cola de maniobra y, de ser así, se fija su TIEMPO DE PRÓXIMO EVENTO de modo que se respete el tiempo entre despachos sucesivos. Además, si el tren que está saliendo va a operar en modo expreso o debe ir a una rama, se actualizan sus variables ÍNDICE DE RECORRIDO EXPRESO o PRÓXIMA RAMA según corresponda. • Cuando un tren llega a una estación, existen dos posibilidades: Si la estación está ocupada, el tren entra en estado de Esperando Estación y su TIEMPO DE PRÓXIMO EVENTO se deja nulo, con lo que se queda así indefinidamente 83 hasta que sea cambiado desde fuera. Si la estación estaba vacía, el tren entra en ella; se borra la entrada del NÚMERO DE PASAJEROS correspondiente a la estación actual y se le suman los que hay en el andén, desde las entradas del arreglo NÚMERO DE PASAJEROS de la estación a las correspondientes del arreglo del tren, siempre y cuando lo permita la capacidad de los metros. El TIEMPO DE PRÓXIMO EVENTO se calcula como el máximo entre el tiempo de holding asignado al tren (predeterminado o fijado por el Controlador) y el que toma cargar y descargar todos los pasajeros, como se explicó en la sección 3.2.1. Finalmente, si el tren iba a una rama o no le tocaba parar en la estación por estar en modo expreso, no se hace ningún intercambio de pasajeros y se actualiza simplemente el TIEMPO DE PRÓXIMO EVENTO con el doble del valor del TIEMPO PARA ENTRADA ESTACIÓN de la línea. • Cuando un tren sale de una estación, se calcula su TIEMPO DE PRÓXIMO EVENTO como el que le toma recorrer el tramo de línea que sigue, según se explicó en la sección 3.2.1, y usando la velocidad media asignada, predeterminada o la fijada por el Controlador. Si el tren actual va a una rama que se encuentra en el tramo de línea que sigue, la distancia que se usa es la que corresponde a la POSICIÓN ENTRADA RAMA correspondiente. Si había algún tren en estado Esperando Estación a la entrada de la estación, se actualiza su TIEMPO DE PRÓXIMO EVENTO con el valor de TIEMPO PARA ENTRADA ESTACIÓN. • Cuando un tren está entrando o saliendo de una rama lateral, se procede de forma parecida a cuando se entra o sale de una cola de maniobra terminal, sólo que usando los valores correspondientes a la rama en cuestión. La POSICION FINAL RAMA determina en qué punto del tramo de línea sale un tren despachado y se usa para calcular su TIEMPO DE PRÓXIMO EVENTO de forma parecida a como se hace al salir de una estación, sólo que usando la distancia que queda por recorrer en lugar del largo completo del tramo. 84 A.4 Combinación Esta clase maneja la interacción entre dos estaciones, pertenecientes a líneas distintas, entre las que existe una combinación. Contiene referencias a los cuatro objetos Estación involucrados (uno para cada andén de cada línea), además de los siguientes parámetros: • PROPORCIÓN DE PASAJEROS QUE VAN A VÍA uno, PROPORCIÓN DE PASAJEROS QUE VAN A VÍA dos, μC, σC, LÍMITE DE ATOCHAMIENTO, λA: Parámetros que controlan la cantidad de pasajeros que hacen la combinación y el tiempo que tardan en hacerla, como se explicó en la sección 3.2.1. Todos estos parámetros están repetidos cuatro veces. A modo de variables de estado, la clase posee una lista de todos los grupos de pasajeros que están haciendo actualmente la combinación en uno u otro sentido. Cada elemento de la lista contiene el tamaño del grupo, el andén de destino y el tiempo de llegada a él. Cuando un grupo de pasajeros llega a una estación que posee una combinación, el código correspondiente de la clase Estación debe invocar un método de Combinación que se encarga de agregar los hasta cinco grupos nuevos de pasajeros haciendo la combinación a la lista, como se explicó en la sección 3.2.1. Se revisa la lista completa en busca del grupo que debe arribar primero y se actualiza la variable TIEMPO DE PRÓXIMO EVENTO con el instante de llegada correspondiente. Los eventos gatillados por la clase Combinación corresponden así a la llegada de grupos de pasajeros en transferencia al andén al que van. Por lo tanto, en la función Procesar Evento se elimina el grupo que gatilló el suceso de la lista y se incorpora la cantidad de pasajeros que venían en él al objeto Estación correspondiente. Si quedan más grupos de pasajeros en la lista, se actualiza la variable TIEMPO DE PRÓXIMO EVENTO con el primer instante que allí se encuentra; si no, se deja la variable vacía. 85 ANEXO B: MANUAL DE USO DEL SIMULADOR B.1 Interfaz gráfica Al cargarse el software, se muestra durante un par de segundos la pantalla splash de inicio, que se ve en la figura B-1 y que da el título, los autores y una descripción breve del simulador. Figura B-1. Pantalla splash de inicio A continuación aparece la interfaz principal de la aplicación, que se muestra en la figura B-2, donde se muestra la representación que hace el software de una red como la del Metro de Santiago. Aquí es posible, seleccionando las opciones pertinentes de la barra de herramientas superior, crear rápidamente nuevas líneas, estaciones, ramas y combinaciones, así como borrar elementos de cualquiera de estos dos tipos. Los largos de los tramos de línea y las tasas de llegada λL/λG a las estaciones pueden modificarse también fácilmente aquí haciendo clic sobre los objetos correspondientes. Aquí mismo se eligen también los instantes de inicio y fin de la simulación, así como la semilla del generador de números aleatorios. 86 Figura B-2. Interfaz principal de la aplicación Haciendo clic sobre el nombre de una línea se puede acceder al cuadro de diálogo con los parámetros de éste, que se muestra en la figura B-3. Así es posible especificar los parámetros generales que afectan a la línea, como capacidad de sus trenes, capacidad de las colas de maniobra terminales, parámetros α, β, γ, δ, μεE y σεE sobre tiempo para carga y descarga de pasajeros en estaciones, parámetros M, m, a, d, c y g para cálculo de consumo energético, tiempo de despache de trenes hacia y desde una cola de maniobra y una estación, parámetros μεL y σεL sobre componente aleatoria del tiempo que toma recorrer un largo de línea, y valores predeterminados para los tiempos de holding, velocidad media e intervalo entre despachos sucesivos de trenes desde terminales, los cuales se usan en caso de no realizarse control en tiempo real. 87 Figura B-3. Cuadro de parámetros principales de línea Además de estos parámetros generales, es posible especificar, en pestañas separadas, las matrices origen-destino de ambas vías de la línea, como se ve en la figura B-4, y los recorridos expresos para cada vía, indicando en qué estaciones deben parar los trenes que sirvan a cada recorrido, como se ve en la figura B-5. 88 Figura B-4. Especificación de una matriz origen-destino Figura B-5. Especificación de recorridos expresos de la línea Haciendo clic sobre las estaciones en la interfaz principal es posible también especificar intervalos para los que son válidos ciertos pares de parámetros (λL, λG) como se muestra en la figura B-6. Se indica para cada intervalo su instante de 89 inicio y el valor de los parámetros durante él; pueden especificarse todos los que se quieran. Figura B-6. Ingreso de parámetros de llegada de pasajeros a estaciones Haciendo clic sobre las ramas, pueden ingresarse los parámetros que les corresponde a éstas: capacidad, posiciones de entrada y salida desde el tramo de línea en que se encuentran, y tiempo predeterminado entre despachos sucesivos de trenes, que se usa si no se aplica control en tiempo real. El cuadro se muestra en la figura B-7. Figura B-7. Parámetros de las ramas Haciendo clic sobre las estaciones de combinación puede accederse también a los parámetros correspondientes, como se muestra en la figura B-8: Proporción de los pasajeros llegados que hacen la combinación hacia una u otra vía de la línea 90 contraria, límite de pasajeros en combinación para atochamiento, y parámetros , μC, σC y λA sobre el tiempo que toma hacer la transferencia. Hacer clic sobre cada una de las estaciones que conforman la combinación no da acceso al mismo conjunto de parámetros: en un caso se accede a los que corresponden a la transferencia de pasajeros desde la primera línea a la segunda y en el otro a los que corresponden al movimiento contrario. Figura B-8. Parámetros de las estaciones de combinación Escogiendo ciertas opciones de la barra de herramientas de la interfaz principal es posible fijar las condiciones iniciales de la simulación. Al hacer luego clic sobre una línea, tramo de línea, estación o rama, se pueden escoger los valores deseados. Por ejemplo, en la figura B-9 se muestra la configuración de condiciones iniciales para una estación, donde se puede indicar si hay inicialmente un tren en alguno de los andenes de la estación, cuándo llegó, cuántos pasajeros traía, su tiempo de holding asignado, el recorrido expreso que sirve. También se sebe especificar el número de pasajeros esperando en los andenes. En la figura B-10 se muestra el cuadro para el caso de un tramo de línea, en que se pide entregar el número de trenes que hay en cada vía, su posición, velocidad asignada, número de pasajeros que transporta y recorrido expreso servido. 91 Figura B-9. Condiciones iniciales en una estación Figura B-10. Condiciones iniciales en un tramo de línea Al cerrar la aplicación, todas las configuraciones hechas por el usuario se guardan en un archivo especial llamado datos.dat, ubicado en el mismo directorio de la aplicación, y se vuelvan a leer al abrirla de nuevo. Además, es posible guardar y abrir la información actual acerca de la estructura de la línea en archivos creados por el usuario, para así poder trabajar con varias redes al mismo tiempo. Las condiciones iniciales pueden guardarse y abrirse también en archivos separados; la idea es que una misma red se pueda hacer operar fácilmente bajo distintas configuraciones iniciales almacenadas en disco. La estructura de los archivos de almacenamiento de condiciones iniciales es especialmente simple para permitir 92 editarlos con facilidad desde un editor de texto; básicamente cada línea del archivo corresponde a un tren o una estación de la que se deben indicar los parámetros que correspondan. En cuanto al control en tiempo real, los parámetros se fijan desde un cuadro como el que se muestra en la figura B-11, el cual se invoca desde la interfaz principal. Aquí se puede especificar qué tipos de variables manipuladas se desea que el Controlador pueda afectar, la ubicación en disco de la función MATLAB o SCILAB escrita por el usuario para realizar el control y los valores de los seis argumentos opcionales que se le pasan a dicha función, como se explicó en la sección 3.2.5. Figura B-11. Configuración del Controlador Una vez definidos todos los parámetros, se debe hacer clic sobre el botón play para dar inicio a la simulación. Apenas esta termina, el software avisa al usuario mediante un mensaje y una alerta sonora. Éste puede acceder entonces, haciendo clic derecho sobre los objetos que corresponda, a los resultados por línea y por estación, a través de informes en cuadros de diálogo como el de la figura B-12, 93 que incluyen una pestaña con los valores generales de los indicadores producidos y otros con valores específicos, ordenados por intervalos de 15 minutos cada uno. Figura B-12. Resultados para una línea Además de los indicadores generales, es posible guardar a disco un registro del desarrollo de la simulación en forma de matrices MATLAB o SCILAB, como se explicó en la sección 3.2.4. Finalmente, es posible obtener dos tipos de representación gráfica de dicho desarrollo. En la figura B-13 se muestra el diagrama distancia-tiempo para una línea. El eje de las abscisas corresponde al tiempo y el de las ordenadas a la posición a lo largo de la línea, con la ubicación de las estaciones marcada. Cada línea de color en el gráfico corresponde a un tren distinto a medida que se desplaza por la línea; cuando van en la vía uno el trazo se mueve desde abajo hacia arriba, y cuando van en la línea dos en el sentido contrario. 94 Figura B-13. Diagrama distancia-tiempo para una línea El otro tipo de representación gráfica, que se ve en la figura B-14, se presenta para cada estación y corresponde a su ocupación en función del tiempo. El eje de las abscisas es nuevamente el tiempo y el de las ordenadas el número de pasajeros que hay en la estación en un instante dado. Las porciones con fondo claro indican que en el correspondiente intervalo hay un tren parado en la estación; a su llegada ésta se vacía, pues los pasajeros que estaban en el andén han subido al tren. Figura B-14. Diagrama de subida de pasajeros para una estación 95 B.2 Interacción con software de cómputo La función MATLAB o SCILAB escrita por el usuario debe respetar el siguiente prototipo: function controles = ctrlProm(tpo, controles_act, metros, estaciones, despachos, metro_actual, parametros) Los parámetros corresponden a matrices (como es usual en MATLAB y SCILAB) que contienen los siguientes elementos: a) tpo: Contiene únicamente el tiempo actual, en segundos. b) controles_act: Vector de cuatro elementos indicando cuáles tipos de variables manipuladas el usuario ha decidido hacer controlable desde el simulador; un 1 en la entrada correspondiente indica que se pueden modificar las variables de cada tipo y un 0 lo contrario. c) metros: Matriz que contiene una fila por cada tren del sistema y nueve columnas con la siguiente información para cada tren: i) Estado del metro: 1 si está en una estación, 2 si está en un tramo de línea, 3 si está esperando a entrar en una estación o rama, 4 si está en una cola de maniobra terminal y 5 si está en una rama. ii) Línea a que pertenece el metro. iii) Vía de la línea actual. iv) Índice de la estación en la vía actual. v) Si el tren está en una estación, holding asignado; si está en un tramo de línea, velocidad asignada. vi) Si el tren está en una estación, instante en que llegó; si está en un tramo de línea, posición en metros medidos desde la estación anterior; si está 96 entrando a una cola de maniobra o una rama, tiempo hasta entrar completamente en ella. vii) Si el tren está en una estación, pasajeros que había cuando llegó; si está en un tramo de línea, pasajeros que transporta actualmente; un valor de -1 indica que va de camino a una rama y por lo tanto debe saltarse las estaciones en el camino. viii) Si el tren está en una estación, pasajeros que había en el andén de ésta a la llegada; si está de camino a una rama, índice del tramo de línea en que ésta se encuentra. ix) Índice del recorrido expreso, de entre los previamente definidos por el usuario en el software, que sirve el tren actual; 0 indica que debe parar en todas las estaciones. estaciones: Matriz que contiene una fila por cada andén del sistema y d) cinco columnas con información para cada una. En la oración anterior se usó la palabra andén en lugar de estación porque cada estación aparece dos veces representada en la matriz: primero se listan todas las estaciones de la vía uno de cada línea y luego las de la vía dos. Las columnas corresponden a los siguientes valores: i) Índice de la línea a que pertenece la estación. ii) Pasajeros que hay actualmente en la estación o, si hay un tren actualmente en ella, los que había al arribar éste. iii) Instante en que arribó el último tren a la estación, sea que yazga aún allí o no iv) Instante en que el último tren abandonó la estación. v) Si el tramo de línea que sigue a la estación posee una rama lateral, instante en que debe ser despachado el primer tren que esté aguardando en él. 97 e) despachos: Matriz con una fila por cada línea y dos columnas, que contiene en ellas los instantes en que debe ser despachado el primer tren aguardando en la cola de maniobra da ambas vías de la línea. f) metro_actual: Vector de dos elementos; el primero indica a qué línea pertenece el tren que gatilló la llamada a la función (es decir, que acaba de llegar o salir de alguna estación, rama o terminal), y el segundo corresponde a su índice en la matriz metros. g) parametros: Corresponde a un vector de seis elementos que contienen 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. La salida de la función es una matriz de controles de al menos una fila y cinco columnas. La primera fila contiene sólo ceros; la segunda columna y las subsiguientes contienen instrucciones al Controlador de alterar el valor de alguna variable manipulada. La fila de ceros permite enviar algo incluso si no se quiere modificar ninguna variable. Debe recordarse que es posible actuar sobre cualquier tren, terminal o rama de la línea, no sólo el que gatilló la llamada. Los valores en las columnas contienen el contenido de cada instrucción como sigue: a) Tipo de variable manipulada a fijar: 1 si es de holding, 2 si es de velocidad, 3 si es de despacho de tren desde una terminal de línea, 4 si es de despacho de tren desde una rama y 5 si es de enviar el próximo tren que salga desde una terminal de línea a alguna rama b) Línea a que pertenece el tren, rama o terminal sobre el que se desea actuar 98 c) Si se está actuando sobre un tren, índice en la matriz metros a que corresponde; si se está actuando sobre un terminal o rama, número de la vía (uno o dos) a que corresponde. d) Si se está despachando un tren desde una rama (la opción 4 en la primera columna), índice del tramo de línea en que se encuentra ésta. e) Nuevo valor de la variable manipulada que se quiere fijar, según la opción que figure en la primera columna: Tiempo de holding en la estación siguiente; velocidad media en el siguiente tramo de línea (o el actual, en cuyo caso se cambia la velocidad a medio camino); instante en que debe ocurrir el próximo despacho desde el terminal o rama que corresponda; o tramo de línea en que se encuentra la rama lateral a la que se desea enviar el próximo tren que salga de la terminal. 99 ANEXO C: ARTÍCULO ENVIADO AL JOURNAL OF MATHEMATICS AND COMPUTERS IN SIMULATION Low-Cost Dynamic Simulator for the Metropolitan Rail System in Santiago, Chile Pablo Grubea and Aldo Ciprianob a b College of Engineering, Pontificia Universidad Católica de Chile Vicuña Mackenna 4860, Santiago, Chile 782-0436 e-mail: [email protected], phone: 56-2-3547909 (Corresponding author) College of Engineering, Pontificia Universidad Católica de Chile Vicuña Mackenna 4860, Santiago, Chile 782-0436 e-mail: [email protected] Abstract: The inauguration of Transantiago, the new Urban Transportation Plan developed for Santiago, Chile, has posed a major challenge for the city's Metro rail system: in a very short period of time, the number of people it carries has nearly doubled. Several measures have been studied and introduced, including express trains along the most-demanded line, in order to revert the decline in the quality of service. One of the many conclusions gained from this experience is that better advantage must be taken of available technology like dynamic system simulation and its applicability to public transportation. This paper presents a very low-cost dynamic simulator developed for the metropolitan rail system (Metro) in Santiago, Chile. The simulator is event-driven and uses object-oriented programming, and has the capacity to interact with SCILAB programs written by the user to design and evaluate control systems in real time. The article describes the user interface, proposes some applications, and demonstrates how to use the simulator in control applications. Keywords: Transportation system, metro, train, real-time control, event-oriented modeling 100 1. INTRODUCTION Transantiago, the new Urban Transportation Plan developed for Santiago, the capital of Chile, was created in order to provide the city with a more efficient, cost-effective, and environmentally sustainable transportation system [1]. According to the Plan, Metro was supposed to be the system’s articulated backbone, in terms of the way its routes are structured and because of its technological integration, taking into account its efficiency in transporting large numbers of passengers. Considering the Plan’s major shortcomings, which were revealed when it became operational on February 10, 2007, and considering the new integrated fare system that made its services more accessible, many users began to prefer riding the Metro. Thus, while before the Metro had carried 1.2 million people daily, in a very short period of time it faced the challenge of carrying 2.3 million, equivalent to more than one-third of all Transantiago trips. This heavy increase in the number of passengers led to a decline in the quality of service, which was reverted by studying and introducing several measures: infrastructure development, acquisition of new trains, redistribution of the fleet, increase in supply, and informational campaigns to promote a proper use of the service. Express trains were also implemented along the route with the heaviest demand, and train speed was improved. With these measures, in 2010 the Metro will have a network of 103 kilometers, 107 stations, and close to 1,000 cars, making it one of the largest metropolitan rail networks in Latin America. One of the many conclusions gained from this experience is that it is necessary to take better advantage of available technology like dynamic system simulation and its applicability to public transportation. In Santiago and in many other cities, metropolitan rail systems, or metros, are the main form of public transportation. As we have seen in the above example, increases in demand lead to an expansion of infrastructure. However, expanding infrastructure is costly and becomes unsustainable at a certain point. This means that the only feasible solution is to improve the train's management system, which is done using two kinds of methods: those that are determined offline, for example, pre-programming schedules using historic information, including strategies for keeping certain trains from stopping at certain stations; and those that make use of information about the system’s status that is obtained on line while the system is in operation. This information may include the trains’ positions, number of passengers at stations and on trains, eventual disturbances affecting the system’s normal operation, etc. In some cases, it is the operators who make relevant decisions. However, sometimes human beings are incapable of taking into account all the relevant information in order to make a decision, while a computer control system is capable of doing so. One compromise between a system that is totally operator-managed and one that is totally software-managed is a management support system, in which the software provides the operator with real-time suggestions of actions that may be taken, and it is up to the operator to accept or ignore them. In any of these cases, the introduction of a new planning or control system, be it on or off line, requires prior testing that, at least in the initial stage, is not easy to carry out in the transportation system itself because of the costs involved and the effects on users. The usual solution in these cases involves conducting simulations, and in fact there are many simulation platforms available for these types of systems. One of these is OpenTrack, which is very useful for analyzing the effects of installing new infrastructure, establishing schedules, experimenting with different signal systems, and analyzing the effects of failures [8]. Another alternative, which focuses more on learning, is Bahn, a shareware program written by Jan Bochmann that is used for designing and testing train or streetcar transportation networks. RailSys [12], yet another software 101 system, integrates a timetable and infrastructure manager with synchronous microscopic simulation and automatic dispatching. Bahoua et al. [2] present an alternative capable of single-train traction calculation, multi-train simulation and timetable assessment. Other simulators have been proposed that focus on more specific issues, like for simulating inter-modal cargo and passenger transportation terminals [13], or for visually modeling and simulating rail services [4]. However, very few simulators make it easy to design and evaluate on-line control strategies. Many of the issues involved are discussed in Verseegt et al. [15]. Examples of these platforms are the Quadstone Paramics [11] and PTV Vissim [10] micro-simulators, which are highly complex and costly and do not include specific support for metros. While these platforms are useful for definitively validating the algorithms that have been created, they are not at all practical for carrying out rapid testing during the development phase. One alternative is presented by Paolucci et al. [9], whose software system supports the generation of simulation codes and is able to automatically define the skeleton of a code. This article presents a low-cost, reduced-scale, fast, and easy-to-use dynamic simulator for metro systems, with the capacity to simulate the complete network of Santiago, Chile's Metro. The simulator allows users to control the train speed along routes, the holding time at stations, and the dispatch time for trains from terminal stations. This simulator is programmed in the C# language [7], which has the advantage of being easy to use, providing good support for object-oriented programming and making it easy to develop graphic interfaces. The control algorithms are programmed in SCILAB, a popular software package that is used for numeric calculations. 2. SIMULATOR APPLICATIONS The software has been designed to simulate the global operation of a metropolitan rail system with an adequate level of detail. This makes it possible to conduct a satisfactory initial analysis of the effects of measures like increasing the number of trains in operation, injecting trains at different points along the line, etc. when faced with different conditions of operation and demand, and for any initial system configuration. As a result, a series of important indicators can be obtained for system planning, as detailed in Section 4, the most important of which are waiting times, travel times, and station occupation densities. The system also provides a description of the simulation’s total development for its subsequent analysis. The simulator allows the user to fully define the fleet's management strategy, using any desired degree of information available. This can range from sticking to schedules planned beforehand, to complex predictive control techniques [3], with intermediate alternatives like, for example, heuristics that only use local information from the station and/or train under analysis. The simulator quickly predicts how a system will behave with each strategy applied, providing indicators like waiting times and travel times. It is also possible for some trains to skip certain stations (station skipping), or, if the infrastructure allows, they may turn around at some intermediate point in the route and return to the terminal from where they started (shortturning). An interesting additional development that is being considered for the future is the ability to connect the simulator through an interface to data available online, to create a decision-support system. 102 3. CHARACTERISTICS OF THE SIMULATOR 3.1. Paradigms used In order to define the model, object-oriented programming [14] was used. This is a very popular programming paradigm that consists of defining classes of objects specifically designed to carry out certain functions. Each class defines a set of member data that represents all the information needed to define the state of an object from the corresponding class. It also implements a set of member functions, or methods, that determine the object's behavior, since they can be called on by other parts of the program to act on member data. This makes it possible to modularize the code and allows the abstract objects to constitute a suitable representation of real elements, like metro stations, trains, etc., that share a common class but of which there are multiple instances or objects. For the simulation, an event-oriented scheme was chosen, in contrast to the continuous simulation paradigm [5]. This means that, instead of integrating dynamic differential or difference equations that define the system's behavior at each moment in time, the processing is only conducted at irregular moments of discreet time. At each of these moments, or steps, the system’s state variables are updated and the time at which the next step should occur is calculated. What may happen between steps is not taken into account. The advantage of this is to significantly reduce the processing capacity requirements, although details about the process are naturally lost. The use of this paradigm is justified by the fact that all the major events in this application (trains’ station arrivals and departures, arrival of passengers, etc.) happen at well-defined moments, and what happens between two events, like for example the exact way in which trains move along the tracks, does not greatly affect control decisions. 3.2. Characteristics of the simulation The software can simultaneously simulate any number of routes that are connected by transfer stations. As a case study, the entire network of Santiago’s Metro, with 5 lines, 93 stations, and 7 transfer stations, has been simulated. What follows is a description of the diverse aspects of the simulator. The lines are bidirectional and can contain any number of stations, including terminal stations at each end. The time in which trains move along lines and stop at stations depends as much on passenger occupancy (see below) as it does on the control strategy used. In the sections of line between stations, it is assumed that the trains move at a constant speed. This is a simplification of reality, because trains have a variable speed profile along the entire line, but for the purpose of evaluating the system’s global operation, this approximation is close enough to reality and there is no need to examine the details of a train's movement at each moment. This constant speed can be changed at discreet moments by control actions, which means that there may be trains with different velocities. If a train arrives at a station where another train is stopped, it switches to “waiting mode” until the station is clear, and then moves forward into the station. A similar procedure is followed if one train catches up to another one along the line. 103 There are “maneuvering areas” at the ends of each line, which have space to store a number of trains as defined by the user. The control determines when to dispatch the train that is first in line in the maneuvering area. In certain sections of the line between stations, the user can define lateral tracks where trains can temporarily park. When a train is dispatched, the control system may determine that instead of functioning normally, it should skip stations and detour to lateral tracks where it will stay parked until the control allows it to resume normal operation. Lateral tracks make it possible to have trains waiting, and when certain parts of the line get overly congested, the train quickly moves to the congested part of the line without having to travel along the rest of the line. Passengers arrive at the stations according to a composite Poisson distribution, meaning that they arrive in variable-size groups separated by exponentially-distributed intervals of time. The value of measures can be discreetly varied throughout the simulation if the user so desires, as the user may specify different values for different intervals of time. When a train arrives at a station, it must stay there for a minimum amount of time (dwell time), which is determined by the model described in [6]: T = α + β PS + γ PB + δ PO (1) where PS is the number of passengers who board the train (which is generally the number of passengers in the station, unless the train is already at maximum capacity), PB is the number of passengers who deboard at the station, and PO is the total number of passengers who are in the station and on the metro, regardless of whether they board or deboard, in order to determine the congestion effect caused by an excessive number of passengers. α, β, γ and δ are parameters defined by the user. The above dwell time is not necessarily the time during which the train will be stopped at the station; it could be greater if the control specifies a holding time. However, the train cannot leave the station until the dwell time is over. The destination station of passengers who board the train is determined randomly, based on probabilities defined in an origin-destination matrix that can be different for each of the line’s directions (tracks). When a train arrives at a transfer station, a set proportion of passengers who deboard there transfer to the other line. Not all these passengers take the same amount of time to make the transfer, and a delay effect caused by bottlenecks is taken into account if there is an excess of passengers. Travel times and dwell times can incorporate a random component whose parameters are set by the user. The number of metros running and their initial position are manually specified by the user, who can situate them initially at any station, section along the line, branch, or terminal; indicating values like the time needed to arrive at the current station, or the initial position along a section of line, allowing the software to decide how the trains should behave when the simulation begins. 104 3.3. Real-time control The simulator can operate in an open-loop or closed-loop mode. In the open-loop mode, all trains have a set speed, stop for the predetermined holding or stop times at all stations, and when arriving at terminals, are dispatched from them at regular intervals. All the parameters that affect these actions can be set by the user. In the closed-loop mode, the simulator allows the user to define control functions that, depending on the desired objectives, may include real-time information about the operation. These functions must be programmed in SCILAB using .SCI files, respecting the entry and exit variables defined by the simulator. The simulator accesses SCILAB services (and through these, the function written by the user) through the DLLs provided by SCILAB. The control system can currently act on four types of manipulated variables: holding times, velocities along the line, times until the following train is dispatched from terminal stations, and times until trains are dispatched from lateral tracks. The first two manipulated variables are defined for each train, while the third is associated with lines and the last with lateral tracks. If the dispatch from lateral tracks is being controlled, the user can also manipulate which trains will operate normally and which will be sent to one of these lateral tracks. Each time a train changes its status, meaning that it arrives at or leaves a station, arrives at a terminal station or at a branch, etc., the control system is called upon to update all the manipulated variables. To do so, it gathers information about the status of the entire system, and transfers this information to the SCILAB userdefined function in the form of matrix-represented arguments. The control system generates an exit matrix with all the manipulated variables whose values should change. The program immediately makes the needed changes and then continues on with the simulation. 4. OPERATING INTERFACE The operating interface, shown in Figure 1 for part of the Santiago Metro network, allows the user to graphically create new lines, stations, transfer stations, etc. using the mouse. Also, by clicking on different elements, the user can access dialogue boxes to input the corresponding parameters. As shown in Figure 2, these are the general parameters of a line, including trains’ capacity, parameters α, β, γ and δ of the dwell time model, origin-destination matrices, and all the others mentioned in Section 2.2. Similar boxes can be called up to parameterize stations, transfer stations, and lateral tracks. Other values that can be directly set in the main window are the simulation's start and finish times, and the random number generating seed. Once the lines have been input, the following step is to input initial conditions, like the number of and initial position of trains, and the initial number of passengers in the various stations and trains. Finally, the name and location can be defined in the .SCI file drive that contains the control function written by the user, together with all the manipulated variables that the user wants the function to control. Once these values are selected, the simulation begins. Once the simulation is finished, the user can access statistics about the metro line or station, including: • Average passenger waiting time (per station or for the entire line). 105 • • • • Average travel time. Average occupancy of stations and trains. Average frequency of trains in a station. Total number of trains that must wait to enter a station because it is occupied by another train. The above statistics can be obtained for the total time of the simulation or at 15-minute intervals. Besides the statistics, two types of graphic representation are created after the simulation is finished. The first is a distance-time diagram for each line, an example of which is shown in Figure 3. Here, axis X represents time and axis Y represents the distance of the entire line; each colored line represents a different train as it moves along the line. The simulator also creates a graph of the number of passengers in each station as a function of time, as shown in Figure 4. Lastly, it is possible to save a register of the simulation’s development as a SCILAB data file (a .DAT file). 5. AN APPLICATION EXAMPLE FOR THE SIMULATOR In order to show how the simulator works, a simple real-time control scheme is proposed, based on regularizing the headway of station departures, that is, the time between successive train departures from a given station. The example intends to maintain this headway constant and equal to H, a control parameter. The strategy is as follows: every time a train arrives at a station at a moment tarr, the moment when the previous train departs the same station, tprev is computed. The headway is then calculated as follows: tarr ≥ t prev + H 0, ⎧ h=⎨ ⎩t prev + H − tarr , tarr < t prev + H (2) This means that the control will try to keep this station’s headway constant by holding trains at each station. It is important to note that if the train arrives very late, the holding is zero, so it can move through the station as fast as possible, considering that it will need a minimum amount of time for all the passengers to board and deboard. The control scheme was tested on Line 5 of the Santiago Metro, with 18 stations in each direction, and a total length of 14.5 [km]. A total of 26 trains are included in this example, initially distributed uniformly along the line, which move from station to station at an average speed of 70 [km/hr]. Passengers arrive at the stations at an average rate of 0.25 [passengers/sec] in one direction and 0.16 [passengers/sec] in the other; the standard variations in these rates from one station to another are 0.26 [passengers/sec] and 0.15 [passengers/sec], respectively. The dwell time model uses the parameters α=5[sec], β=γ=0.5 [sec/passenger], δ=0. The simulation's duration is one half hour. Considering the length of the line and the number of trains, there should be approximately 1.2 [km] of distance between each train in order for them to be perfectly distributed along the line. At a speed of 70 [km/hr], the headway between successive trains should be at least 1 min., and in fact even greater due to the dwell time in stations. Table 1 shows the results of the simulation for different values of headway parameter 106 H, and the average passenger waiting time in stations and travel time in trains. As a comparison, an uncontrolled case is also included in which the holding is constant for all stations and equal to 15 seconds; the results are clearly less desirable. Contrary to the controlled case, when uncontrolled, the trains tend to run together (a phenomenon called bunching), which progressively increases waiting times. From stability's point of view, the system is unstable in the open-loop mode. The above can be seen in Figure 5, which shows the distance-time diagrams for the controlled and uncontrolled cases. Figures 6 and 7 illustrate the results from Table 1; it can be seen that a good value for parameter H, which allows for a compromise between waiting and travel times, is H=90 [sec]. 6. CONCLUSIONS AND FUTURE WORK This simulator simplifies several details involved in the operation of a metropolitan rail system, in order to facilitate the programming and evaluation of control strategies. This makes it possible to conduct rapid simulations of relatively complex systems, like the Santiago Metro network. The improvements considered and currently being developed include: a) incorporate a speed profile for trains in different sections of the line; b) model passenger boarding and deboarding times in a more precise way; c) incorporate functions to calculate the energy required for the movement of trains and incorporate it as an additional result of the simulation; d) eliminate the restriction that all passengers that fit must board the metro in order to close its doors and depart; e) consider failures or other events that limit normal operation; f) allow the simulator to communicate with data acquisition systems in order to develop a useful tool to provide online support for decisions made by system operators. ACKNOWLEDGEMENTS This research has been funded by CONICYT, ADI-32 project "Real Time Intelligent Control for Integrated Transit Systems." We also wish to thank the Santiago Metro Projects Department for its suggestions and comments. REFERENCES [1] 2007 Annual Report, Metro de Santiago, Santiago, Chile, 2007. [2] M. Baohua, J. Wenzheng, C. Shaokuan, L. Jianfeng, A Computer-Aided Multi-Train Simulator for Rail Traffic, IEEE International Conference on Vehicular Electronics and Safety (2007) 1-5. [3] E. Camacho, C. Bordons, Model Predictive Control, Second Edition, Springer, London, U.K., 2004. 107 [4] V. Ceric, Visual Interactive Modeling and Simulation as a Decision Support in Railway Transport Logistic Operations, Journal of Mathematics and Computers in Simulation, Vol. 44 Nr. 3 (1997) 251261. [5] R.J. Hill, T.K. Yates, Modelling Railway Block Signalling Systems Using Discrete-Event Simulation. Railroad, Proceedings of the 1992 ASME/IEEE Spring Joint Conference, Vol. 31 (1992) 1-9. [6] T.H. Lin, N.H.M. Wilson, Dwell Time Relationships for Light Rail Systems, Transportation Research Record, Nr. 1361 (1992) 287-295. [7] Microsoft Developer Network, Microsoft Corporation, Washington, U.S.A., 2007. [8] A. Nash, D. Hürlimann, Railroad Simulation Using OpenTrack, Computers in Railways, Vol 9 (2004) 4554. [9] M. Paolucci, R. Pesenti, An Object-Oriented Approach to Discrete-Event Simulation Applied to Underground Railway Systems, Simulation, Vol. 72 Nr. 6 (1999) 372-383. [10] PTV Vision – Tutorial, VISSIM Basic Network, PTV Planung Transport Verkehr AG, Karlsruhe, Germany, 2008. [11] Quadstone Paramics 6.5 Modeller User Guide, Quadstone Paramics Ltd., Edinburgh, U.K., 2006. [12] A. Radtke, D. Hauptmann, Automated Planning of Timetables in Large Railway Networks Using a Microscopic Data Basis and Railway Simulation Technique, in: J. Allan, C.A. Brebbia, R.J. Hill, G. Sciutto, S. Sone.(Eds.), Computers in Railways IX, WIT Press, Southampton, U.S., 2004, pp. 615-625. [13] A. Rizzoli, N. Fornara, L.M. Gambardella, A Simulation Tool for Combined Rail/Road Transport in Intermodal Terminals, Journal of Mathematics and Computers in Simulation, Vol. 59 (2002) 57-71. [14] B. Stroustrup, The C++ Programming Language, Special Edition, Addison-Wesley, Massachusetts, U.S.A., 1997. [15] C. Verseegt, A. Verbraeck, Supporting the Design of Automated Transport Systems Using Innovative Simulation, in: J.W. Konings, R. Konings, H. Priemus, P. Nijkamp (Eds.), The Future of Automated Freight Transport: Concepts, Design and Implementation, Edward Elgar Publishing, Cheltenham, U.K., 2005, pp. 167-181. 108 FIGURES Figure 1: Application interface’s main window. Figure 2: Configuration box for the line’s parameters. 109 Figure 3: Distance-time diagram of a line. Figure 4: Diagram of passengers boarding trains in a station. Figure 5: Distance-time diagrams for the uncontrolled (below) and controlled (above) cases. 110 Figure 6: Average passenger waiting time in stations as a function of parameter H. Figure 7: Average passenger travel time in trains as a function of parameter H. TABLES Average waiting times in stations (in sec/passenger) Uncontrolled 78.50 70 44.43 80 37.18 90 25.48 100 24.23 110 24.78 120 24.83 130 25.19 Table 1: Results of the simulations Parameter H (in seconds) Average travel time on trains (in min/passenger) 10.09 8.78 8.23 8.36 8.91 9.37 9.90 10.34 111 ANEXO D: ARTÍCULO PRESENTADO EN EL XVIII CONGRESO DE LA ASOCIACIÓN CHILENA DE CONTROL AUTOMÁTICO (ACCA 2008) Simulador Basado en Eventos de Sistema de Trenes Metropolitanos para Diseño y Evaluación de Sistemas de Control Pablo Grube*, Aldo Cipriano* * Escuela de Ingeniería, Pontificia Universidad Católica de Chile, Santiago, Chile (e-mail: [email protected], [email protected]) Abstract: Se presenta un simulador dinámico de trenes metropolitanos (metros) basado en eventos y en programación orientada a objetos, con capacidad para interactuar con programas MATLAB para fines de diseñar y evaluar sistemas de control en tiempo real. Se describe la forma de ingresar los datos y la interfaz de usuario y se demuestra como utilizar el simulador desarrollando un ejemplo de aplicación de control. Palabras clave: Simulación, sistemas dinámicos, metros, trenes, sistemas de transporte, control en tiempo real, programación orientada a objetos, modelación orientada a eventos 1. INTRODUCCIÓN Los trenes metropolitanos, o metros, constituyen el principal medio de transporte público en muchas ciudades del mundo. Los aumentos en los requerimientos de su demanda han motivado la expansión de este tipo de sistemas; sin embargo, aumentar la infraestructura es caro y llega un momento en que se hace insostenible. Entonces la única solución factible consiste en mejorar el sistema de gestión de los trenes, y la forma más actual de hacerlo consiste en utilizar información medida en línea de variables tales como posición de los trenes, número de pasajeros en estaciones y metros, etc., para que un sistema de control automático tome decisiones en tiempo real que permitan optimizar el flujo de los pasajeros. Naturalmente, no es fácil realizar ensayos en sistemas reales de este tipo de técnicas debido a los grandes costos que esto implica. Como es usual en estos casos, la solución consiste en realizar simulaciones, y de hecho existen bastantes plataformas de simulación para este tipo de sistemas. Entre ellas se puede mencionar OpenTrack, que resulta muy útil para hacer análisis de los efectos de instalar nueva infraestructura, construir horarios, probar diferentes sistemas de señales o analizar efectos de fallas [Hürlimann (2001)]. Otra alternativa más enfocada al aprendizaje es BAHN, un programa shareware escrito por Jan Bochmann que permite diseñar y probar redes de transporte de trenes o tranvías. Sin embargo, muy pocos simuladores ofrecen facilidades para diseñar y evaluar estrategias de control en tiempo real. Ejemplos de estas plataformas son los microsimuladores de alta complejidad y costo Quadstone Paramics [Quadstone (2000)] y PTV Vissim [PTV (2001)], los que además no incluyen soporte específicamente para metros. Aunque estas plataformas son útiles para validar en forma definitiva los algoritmos creados, resultan poco prácticos para hacer pruebas rápidas durante el desarrollo. En este artículo se presenta un simulador de sistemas de metro de tamaño reducido, rápido y fácil de usar, que permite diseñar y evaluar. En su versión actual permite controlar la velocidad de los trenes en las líneas, el tiempo de holding o retención de los mismos en las estaciones y el tiempo de despacho de los trenes desde la estación inicial de la línea. El simulador funciona completamente basado en eventos, lo que evita que tenga que realizar tareas consumidoras de tiempo como integración de ecuaciones dinámicas. En su desarrollo se consideraron los siguientes supuestos simplificadores, los cuales permiten acelerar los tiempos de simulación considerablemente. Los trenes son “creados” al momento de su despacho y “destruidos” al arribar a la estación terminal. Aunque en teoría 112 es posible crear infinitos metros de esta forma, el sistema de control implementado por el usuario puede impedir que se sigan despachando metros hasta que algún otro haya dado la vuelta al circuito o se haga disponible de alguna otra forma. En el simulador las líneas son en una dirección. De todas formas, para crear una línea bidireccional basta replicarla pero con las estaciones invertidas. La velocidad a lo largo de los tramos de línea es constante, es decir, no existe un perfil de velocidades en la línea. Aunque esto claramente es una idealización, la velocidad se puede considerar como un promedio a lo largo del recorrido. Se estima que el error introducido de esta forma no es relevante para evaluar un sistema de control que intenta optimizar el sistema en forma global. Los pasajeros llegan a las estaciones siguiendo un proceso de Poisson a tasa constante. La proporción de pasajeros que llegan a una estación y tienen como destino una cualquiera de las estaciones que siguen a lo largo de la línea está dada por una matriz origen-destino que caracteriza a la línea. El metro no puede abandonar una estación hasta que todos los pasajeros que corresponda se suban o bajen de él. Al llegar un metro a una estación, todos los pasajeros que corresponda se bajan o suben instantáneamente, y después el metro debe permanecer en la estación el tiempo suficiente para justificar este movimiento. Este tiempo de latencia es directamente proporcional al total de pasajeros que bajan y suben. Esta simplificación no resulta excesivamente alejada de la realidad, aunque en la práctica el exceso de pasajeros, tanto en el tren como en la estación esperando, puede hacer más lento el proceso de subida y bajada. En las estaciones de combinación, una proporción fija de los pasajeros que llegan hace la combinación, y estos pasajeros requieren un tiempo fijo en recorrer la distancia que los separa de la otra línea. El simulador está programado en lenguaje C# [Microsoft], el cual tiene la ventaja de ser fácil de usar, proveer un buen soporte para lo programación orientada a objetos y dar facilidades para el desarrollo de interfaces gráficas. Los algoritmos de control se programan en MATLAB [Mathworks (2008)] y se adjuntan como DLLs con el prototipo correcto de función, como se describe más adelante. 2. DESARROLLO DEL SIMULADOR 2.1. Programación orientada a objetos Para definir el modelo se empleó programación orientada a objetos [Stroustrup (1997)]. Se trata de un paradigma de programación muy popular que consiste en definir clases de objetos diseñados específicamente para realizar determinada funcionalidad. Cada clase define un conjunto de datos miembros que representa toda la información necesaria para definir el “estado” de un objeto de la clase correspondiente. Además, implementa un conjunto de funciones miembro, o métodos, que determinan el “comportamiento” del objeto, y que pueden ser llamados por otras partes del programa para actuar sobre los datos miembros. La ventaja es que los datos miembros son inaccesibles desde fuera de la clase si no es a través de estos métodos, lo que permite encapsularlos y así controlar la forma en que estos datos interactúan con el resto del programa. Entre las principales ventajas de este enfoque se encuentra la modularización del código, que da la capacidad de separar la interfaz de un objeto (los prototipos de las funciones miembro) de su implementación (el conjunto específico de datos miembros usados y la forma en que las funciones miembro los manipulan). Además, los objetos abstractos constituyen una representación conveniente de elementos reales, como estaciones de metro, trenes, etc. que comparten una “clase” común pero de la que existen múltiples instancias u objetos. Otros dos elementos fundamentales de la programación orientada a objetos son los conceptos de herencia y polimorfismo. La herencia consiste en que una clase puede extender a otra preexistente, para lo cual incluye todo su contenido (datos y funciones miembros) y puede agregar el suyo propio. Así, por ejemplo, si tenemos una clase base “edificio”, podemos crear una clase derivada “hotel”, que comparte todas las características de su base pero además tiene algunas que son específicas suyas y que deben ser definidas acordemente. El polimorfismo, por su parte, permite que se usen objetos correspondientes a una clase derivada como si se tratara de su clase base; volviendo al ejemplo anterior, una parte del código que está tratando con un objeto de la clase “hotel” podría llamar a la función miembro “ContarPisos()”, definida en la clase base “edificio”, sin siquiera saber que se trata de un hotel y no de otro tipo de edificación. Algunas de estas funciones miembro pueden ser virtuales, es decir, aparecen en la definición de la clase base pero se implementan en las clases derivadas. 2.2. Modelación continua y orientada a eventos Los modelos de simulación pueden ser de tipo continuo o discreto (Hill y Yates, 1992). En el primer caso, el simulador resuelve por integración las ecuaciones dinámicas que definen el comportamiento del sistema para cada instante de tiempo, para lo cual el tiempo se discretiza en unidades de largo uniforme lo suficientemente pequeñas para lograr una representación adecuada. En el segundo, también llamado modelación basada en eventos, el procesamiento sólo se realiza en instantes irregulares de tiempo discretos. En cada uno de estos instantes, o pasos, se actualizan las variables de estado del sistema y se calcula el instante en que debe ocurrir 113 el próximo paso. Lo que pueda ocurrir entre pasos no se toma en cuenta. Esto da la ventaja de reducir considerablemente los requisitos de capacidad de procesamiento, aunque naturalmente se pierde detalle del proceso. Evidentemente, la elección correcta de uno u otro paradigma depende de la aplicación; por ejemplo, la modelación orientada a eventos no es apropiada para simular el movimiento de un vehículo, pero sí para modelar la llegada de pasajeros a un terminal, en que los eventos principales ocurren claramente en ciertos instantes discretos claramente definidos. Para esta aplicación se optó por el esquema orientado a eventos, pues todos los sucesos principales (llegadas y salidas de trenes de estaciones, llegadas de pasajeros, etc.) ocurren en instantes bien definidos. Para los propósitos de esta aplicación, lo que ocurre entre dos eventos, por ejemplo, la forma exacta en que se desplazan los trenes a través de las vías, no es relevante, pues no afecta mayormente las decisiones de control. - El número de pasajeros que actualmente se encuentran en la estación. - Presencia o no de un metro en la estación, y si lo hay, su índice. Además, almacena algunos parámetros, que se definen antes de comenzar la simulación, tales como la tasa de llegada de pasajeros, el largo del tramo de línea que sigue a la estación y un vector con las proporciones de pasajeros que van desde la estación hacia cada una de las que la siguen en la línea, lo cual es equivalente a una fila de la matriz origen-destino. La figura 1 muestra el procesamiento de ProcesarEvento() para las estaciones. Incrementar en 1 el n° de pasajeros esperando 2.3. Procedimientos de la simulación Para poner en práctica lo anterior, se definieron una serie de clases para representar los principales elementos que interactúan en la simulación: líneas de metro, trenes, estaciones y combinaciones (que permiten representar estaciones de combinación). Todas estas clases heredan de la clase base Entidad, que contiene la variable miembro proxTiempo, cuyo valor corresponde al próximo instante de tiempo en que debe “activarse” el objeto en cuestión, así como la función miembro virtual ProcesarEvento(), que debe ejecutarse en ese instante y cuya implementación específica depende del tipo de clase derivada de que se trate. Cada vez que se crea un objeto de cualquiera de los tipos anteriores, se incluye una referencia a él en una lista especial. Luego, una vez iniciada la simulación, durante la cual pueden crearse perfectamente objetos adicionales, que se van agregando a la lista, una rutina recorre todos los objetos de la lista, determina cuál tiene el menor ProxTiempo, y llama a su función ProcesarEvento(). De esta forma la rutina no necesita saber a qué clase exacta pertenece cada objeto de la lista, sólo que es una Entiodad y por lo tanto debe implementar la función mencionada. Una vez llamada, la función y el objeto mismo se encargan del resto del trabajo, realizando el procesamiento que se requiera y actualizando el ProxTiempo correspondiente. A continuación se describen los datos miembro más importantes de cada tipo de entidad, así como el procesamiento que cada una realiza al ser llamada la correspondiente función ProcesarEvento(): Estaciones: Los principales datos almacenados por las estaciones son: ProxTiempo=Tactual+T, T ~ exp(λ) Fig 1: Función ProcesarEvento() de las estaciones Esta función básicamente se limita a manejar la llegada de pasajeros. El tiempo hasta la próxima llegada se calcula como una variable aleatoria de distribución exponencial, de forma que la llegada de pasajeros a la estación constituya un proceso de Poisson. Trenes: Estos objetos contienen los siguientes datos: - - Un arreglo con el número de pasajeros que van en el tren con destino a cada una de las estaciones que siguen. El número total de pasajeros que van en el tren es la suma de los que hay en cada uno de estos grupos. El estado del tren actual, el cual puede ser en estación, en línea, en espera o terminado. El número de estación o tramo de línea en que se encuentra. Tiempo de llegada a la última estación o ramo de línea. Su velocidad. Su tiempo de holding asociado. Si otra parte del programa consulta al objeto tren por su posición dentro de un tramo de línea, éste la calcula en el momento a partir del tiempo en que arribó a dicho tramo y la velocidad que lleva. Esto ocurre a menos que la posición entregada por el tren precedente sea menor que la del actual, en cuyo caso la posición del tren actual se entregará como la del que lo antecede más una distancia fija de separación. Los parámetros fijos que almacena la clase son la capacidad del tren y las tasas de subida y bajada de pasajeros. 114 La figura 2 muestra el diagrama de flujo de la función ProcesarEvento() de la clase tren. EstadoTren = En Estación? Es la actual la última estación? Está ocupada la siguiente estación? EstadoTren = En Estación EstaciónActual = EstaciónActual+1 EstadoTren = En Línea EstadoTren = Terminado EstadoTren = En Espera Actualizar Controles Actualizar Controles ProxTiempo = NULL Actualizar Controles Eliminar los pasajeros que venían a esta estación ProxTiempo = Tactual + LargoLinea/ Velocidad ProxTiempo = ProxTiempo(tren anterior) + Textra PasajSuben = min(Capacidad del tren, pasajeros en estación) Dividir aleatoriamente los PaajSuben en los grupos que van a cada estación y sumarlos a los que vinen en el metro ProxTiempo = Tactual + max(Holding, PasajSuben/ tasaSub+PasajBajan/ tasaBaj) Fig 2: Función ProcesarEvento() de los trenes Como se puede ver, se realizan distintas acciones dependiendo del estado. Se observa que si al tren le corresponde llegar a la siguiente estación y ésta está ocupada, el estado cambia a en espera, de modo que la llegada a la siguiente estación se posterga hasta un tiempo fijo Textra después de la salida del tren que está ocupando la estación. Esto también se hace si hay otro tren delante del actual en el mismo tramo de línea. Como se indicó, los pasajeros que vienen en el tren se representan agrupados según su destino a cada estación. Así se puede saber inmediatamente cuántos pasajeros deben bajarse en la estación actual. Después de determinar cuántos pasajeros suben, este número se divide aleatoriamente en grupos de tamaño proporcional al vector origen-destino correspondiente a la estación actual; los pasajeros de cada uno de estos grupos se suman a los que ya iban con destino a cada una de las estaciones que siguen. El tiempo mínimo de permanencia en la estación corresponde al que toma subir y bajar a todos los pasajeros del tren, o al tiempo de holding definido por el sistema de control. En todos los casos anteriores, se llama al objeto controlador para que el sistema de control en tiempo real actualice las variables de control, como se explica más adelante. Líneas: Las líneas almacenan: - Una lista con todas las estaciones de la línea. Otra lista con todos los trenes que actualmente se encuentran en ella. El tiempo entre despachos de trenes. La función ProcesarEvento() se limita a generar un nuevo metro, poniéndolo al principio de la línea y calculando el tiempo del próximo evento (la generación del próximo metro) usando el valor de la variable tiempo entre despacho de metros, que puede ser modificada por el sistema de control. Combinaciones: Contienen simplemente referencias a las dos estaciones, pertenecientes a líneas distintas, que forman la estación de combinación, además del tiempo que toma a los pasajeros recorrer la distancia desde una línea a la otra. Cuando arriba un tren a una estación de combinación, se llama al objeto combinación correspondiente con el número de pasajeros que se están bajando; una proporción fija de dichos pasajeros, que define un parámetro de la clase combinación, se considera que se transfiere a la otra línea, para lo cual se actualiza en ese momento el ProxTiempo de forma que sea igual a un tiempo constante más adelante, el que corresponde al tiempo que requieren los pasajeros para recorrer la distancia entre una línea y otra. Durante la llamada a ProcesarEvento(), simplemente se agregan los pasajeros transferidos a la estación que corresponde. A medida que van llegando nuevos pasajeros a las estaciones se crea una lista de próximos eventos pendientes, para el caso de que los pasajeros aún no hayan terminado de hacer la transferencia cuando llegue el próximo tren a una de las dos estaciones de la combinación; esta lista se va vaciando a medida que las transferencias se van completando. 2.4. Control en Tiempo Real Actualmente el sistema de control puede actuar sobre 3 tipos de “variables manipuladas”: tiempos de holding, velocidades de línea y tiempos hasta el despacho del siguiente metro. Las primeras dos se definen para cada tren, mientras que la última está asociada a las líneas. Como ya se indicó, cada vez que un tren cambia de estado se invoca al sistema de control para que actualice las variables manipuladas. Para hacerlo, éste comienza recabando información sobre el estado del sistema completo, lo cual implica obtener la siguiente información de cada tren: estado (en estación, en línea o en espera, identificados respectivamente con los números 1, 2 y 3), índice del tren y línea a la que pertenece. Además, si está en una estación, se incluyen el tiempo de llegada a ella, el número de pasajeros con que llegó y el número de los que había en la estación al momento del arribo, así como el tiempo de holding preasignado al tren. Si el tren está en un tramo de línea, se 115 incluyen su velocidad, su posición y el número de pasajeros que lleva. En cuanto a las estaciones, se explicitan la línea a la que pertenecen, el número de pasajeros que transporta, así como el tiempo de la última llegada y la última salida de un metro de la estación. Finalmente, se incluyen el tiempo actual, y el índice y línea a que pertenece el metro que gatilló la llamada al sistema de control. Toda esta información se almacena en sendas matrices de Mathworks MATLAB y se entregan como argumentos de una llamada a una función escrita en MATLAB, compilada para Microsoft .NET usando el .NET Builder de MATLAB e incluida en el proyecto del simulador en formato DLL. Se espera que esta función use algún criterio de control para generar una matriz de salida con las variables manipuladas que deben cambiar de valor. Esta matriz debe tener tantas filas como controles se pretendan cambiar; en cada fila se incluye el tipo de variable que se quiere alterar (holding, velocidad o tiempo para despacho), la línea y el índice del tren (este último sólo si corresponde) y el nuevo valor que debe tomar la variable de control. El programa realiza inmediatamente los cambios requeridos y le devuelve el control a la función ProcesarEvento() del tren que gatilló la acción para que siga con su procesamiento, ya explicado. 3. INTERFAZ DE OPERACION El simulador se ha implementado como una aplicación de Microsoft Windows. Al iniciarla, el usuario debe cargar un archivo XLS, de Microsoft Excel, que debe contener toda la información necesaria para inicializar las líneas que componen el sistema. El archivo debe estar organizado de forma que la información de cada línea del sistema se encuentre en una hoja de datos distinta dentro del archivo, e incluya nombre de la línea, capacidad de los trenes, tasas de subida y bajada de pasajeros, y los valores predeterminados para los tiempos de holding, velocidades de línea y tiempo entre despachos de metros. Además, cada hoja debe incluir un listado con todas las estaciones incluidas en la línea, incluyendo para cada una el nombre de la estación, la tasa de llegada de pasajeros y el largo del tramo de línea que sigue a la estación. Finalmente, debe incluirse la matriz origen-destino correspondiente a toda la línea. Finalmente, una hoja de datos final en el archivo debe incluir un listado de todas las estaciones de combinación, con índices y línea de las dos estaciones que conforman la combinación. Naturalmente, toda esta información debe estar en un orden predeterminado. Una vez cargado el archivo, el programa muestra un diagrama de la línea definida por el usuario, como se muestra en la figura 3. Ahora se puede elegir una duración (en segundos) para la simulación y escoger entre activar o no el controlador. Al hacer click sobre el botón ejecutar, la simulación se procesa en un thread paralelo, es decir, se ejecuta en un proceso propio, para no bloquear a la aplicación completa hasta que termine la simulación completa. Fig 3: Vista principal de la aplicación, con líneas de metro cargadas Una vez terminada la simulación, el programa entrega inmediatamente el tiempo total perdido, en forma de horashombre, por todos los pasajeros que arribaron al sistema durante el periodo de simulación tanto en las estaciones que esperan a un metro como dentro de los trenes durante el viaje. Este tiempo incluye tanto tiempos de viaje como el tiempo transcurrido en el tren mientras éste estaba detenido en una estación. Además, haciendo click sobre una estación cualquiera es posible obtener un gráfico del número de pasajeros que había en la estación en cada instante de tiempo, junto con el tiempo total y promedio por pasajero perdido esperando en esa estación específica. Haciendo click sobre una línea aparece un diagrama distancia-tiempo de los trenes que han pasado por ella, como se muestra en la figura 4. Finalmente, es posible exportar los resultados de la simulación a un archivo XLS para un análisis posterior de los datos. El programa crea una hoja de datos para cada estación y cada tren del sistema, y registra las variables de estado pertinentes para cada instante de tiempo relevante para el tren o estación en cuestión, los que básicamente corresponden a los instantes en que se activa un evento para la entidad respectiva. 116 fin que persigue, pues la alternativa con holding constante también lo cumple. Fig 4: Diagrama espacio-tiempo generado por la aplicación 4. EJEMPLO DE APLICACIÓN En esta sección se demuestra el uso del simulador descrito para una aplicación de control muy simple. Ésta consiste en que, al llegar un tren a una estación, el controlador calcule el tiempo de holding como T[salida del metro anterior]T[actual]+ΔT[fijo]; es decir, de el headway de salida de la estación es constante e igual a ΔT[fijo]. Naturalmente, si el tren está más atrasado que eso, es imposible hacerlo; en este caso, el holding se fija en 0. Este valor se hace igual al tiempo entre despachos de metros, que en este caso corresponde a 150 seg. El objetivo es regularizar los viajes. Se consideró un sistema de dos líneas, una con 23 estaciones y la otra con 17 (además de las terminales). La primera línea tiene 15,9 km de largo en total; la segunda, 16,2 km. Para la primera línea, la tasa promedio de llegada de pasajeros a estaciones es de 1,9 con una desviación estándar de 0,7; para la segunda, el promedio es de 0,4 con σ de 0,2. La capacidad de todos los metros es de 1200 pasajeros; su velocidad se fijó en 70 km/hr. Las tasas de subida y bajada de pasajeros de los trenes se fijaron ambas en 5 pasajeros/seg. La simulación se hizo correr por 10.000 seg, es decir, 2,8 hr. Se comparó el resultado obtenido con el sistema de control descrito y con un esquema sin control, en que el holding se mantiene constante en 15 seg. para cada estación. Para este último caso, el tiempo total perdido fue de 410.408,5 hrshombre. En cambio, para el caso con sistema de control el tiempo perdido fue de 403502,3 hrs-hombre. Es decir, el control produjo una mejoría de un 1,7%, un valor marginal que indica que no hay una auténtica ventaja en aplicar esta estrategia versus la de holding constante. En la figura 5 se muestra el diagrama distancia-tiempo para los casos sin y con control. Se observa que ambos tienes headway de salida bastante regulares, que era precisamente el objetivo del controlador. Esto ayuda a explicar la débil mejoría que se obtiene aplicándolo: no es realmente necesario para lograr el Fig 5: Diagramas distancia-tiempo para el caso sin control (arriba) y con control (abajo) 5. CONCLUSIONES Y TRABAJO FUTURO El simulador simplifica varios detalles de la operación de un sistema de trenes metropolitanos, con el fin de obtener simulaciones rápidas y facilitar el desarrollo y evaluación de de sistemas de control. Entre las mejoras consideradas se incluye: a) incorporar un perfil de velocidades de los metros en los tramos de línea más acorde con la realidad; b) modelar en forma más precisa los tiempo de subida y bajada de pasajeros; c) eliminar la restricción de que todos los pasajeros que caben tienen que terminar de subir al metro para que éste pueda cerrar sus puertas y partir; d) considerar fallas u otros eventos que limitan la operación normal. Actualmente se trabaja también en la incorporación al simulador de estrategias de control más elaboradas, basadas en sistemas inteligentes y control predictivo híbrido. AGRADECIMIENTOS Esta investigación ha sido financiada por el proyecto Anillo de Investigación en Ciencia y Tecnología ADI-32 "Real Time Intelligent Control for Integrated Transit Systems". REFERENCIAS Hill, R.J. y Yates, T.K. (1992). Modelling Railway Block Signalling Systems Using Discrete-event Simulation. Railroad Proceedings of the 1992 ASME/IEEE Spring Joint Conference, Vol. 31, pp. 1-9. Hürlimann, D. (2001). Objektorientierte Modellierung von Infrastrukturelementeu und Betriebsvorgängen im 117 Eisenbahnwesen. PhD Thesis, Eidgenössische Technische Hochschule Zürich. Mathworks (2008). Matlab Builder NE 2 User’s Guide, The Mathworks, Inc., Massachusets, U.S.A. Microsoft (2007). Microsoft Developer Network, Microsoft Corporation, Washington, U.S.A. PTV (2001). VISSIM User Manual – Version 3.60. PTV Planung Transport Verkehr AG, Karlsruhe, Germany. Quadstone (2000). PARAMICS v3.0 User Guide and Reference Manual. Quadstone Ltd., Edinburgh, U.K. Stroustrup, B. (1997). The C++ Programming Language, Special Edition, Capítulo 2. Addison-Wesley, Massachusets, U.S.A. 118 ANEXO E: ARTÍCULO ENVIADO AL XIV CONGRESO CHILENO DE INGENIERÍA DE TRANSPORTE (CCIT 2009) Simulador Dinámico de Sistemas de Tren Metropolitano Pablo Grube, Aldo Cipriano Escuela de Ingeniería, Pontificia Universidad Católica de Chile Santiago, Chile E-mail: [email protected], [email protected] RESUMEN Se presenta un simulador dinámico de trenes metropolitanos (metros) basado en eventos y en programación orientada a objetos, con capacidad para interactuar con programas SCILAB para fines de diseñar y evaluar sistemas de control en tiempo real. Se describe la forma de ingresar los datos y la interfaz de usuario y se demuestra cómo utilizar el simulador desarrollando un ejemplo de aplicación de control. Palabras clave: Simulación, metro, control en tiempo real ABSTRACT An event-based, object-oriented dynamic simulator for metropolitan trains, with the ability to interact with SCILAB programs, is presented. It is intended to assist in the design and evaluation of real-time control systems. The means to enter the data and the user interface are described. A demonstration of how to use the simulator is also included through an example of a control application. Keywords: Simulation, metro, real-time control 119 1. INTRODUCCIÓN Los trenes metropolitanos, o metros, constituyen el principal medio de transporte público en muchas ciudades del mundo. Los aumentos en los requerimientos de su demanda han motivado la expansión de este tipo de sistemas; sin embargo, aumentar la infraestructura es caro y llega un momento en que se hace insostenible. Entonces la única solución factible consiste en mejorar el sistema de gestión de los trenes, para lo cual existen dos tipos de técnicas: aquéllas determinadas fuera de línea, por ejemplo pre-programando itinerarios (schedules) en base a información histórica, incluyendo estrategias como hacer que ciertos trenes no paren en ciertas estaciones; y técnicas que hacen uso de información del estado del sistema obtenida en línea durante la operación del mismo. Esta información puede incluir posición de los trenes, números de pasajeros en estaciones y metros, eventuales perturbaciones a la marcha normal del sistema, etc. En algunos casos, las decisiones relevantes las pueden tomar operadores, aunque esto no siempre es posible o deseable. Por ejemplo, no es práctico tomar una decisión cada vez que un tren llega a una estación; aún si no es esto lo que se desea, el operador no es capaz de considerar toda la información relevante para tomar las mejores decisiones, como sí puede hacerlo un sistema de control computacional. Un compromiso entre un sistema totalmente manejado por un operador y uno totalmente manejado por software son los sistemas de apoyo a la gestión, en los que el software le da al operador sugerencias en tiempo real de las acciones que puede tomar, pero es éste quien finalmente decide si las acepta o las ignora. En cualquier caso, la introducción de cualquier nueva técnica de planificación o control, sea en o fuera de línea, exige realizar previamente ensayos que, al menos en una etapa inicial, no son fáciles de hacer en sistemas reales debido a los grandes costos que esto implica. Como es usual en estos casos, la solución consiste en realizar simulaciones, y de hecho existen bastantes plataformas de simulación para este tipo de sistemas. Entre ellas se puede mencionar OpenTrack, que resulta muy útil para hacer análisis de los efectos de instalar nueva infraestructura, construir horarios, probar diferentes sistemas de señales o analizar efectos de fallas (Hürlimann, 2001). Otra alternativa más enfocada al aprendizaje es BAHN, un programa shareware escrito por Jan Bochmann que permite diseñar y probar redes de transporte de trenes o tranvías. Sin embargo, muy pocos simuladores ofrecen facilidades para diseñar y evaluar estrategias de control en línea. Ejemplos de estas plataformas son los microsimuladores de alta complejidad y costo Quadstone Paramics (Quadstone, 2000) y PTV Vissim (PTV, 2001), los que además no incluyen soporte específicamente para metros. Aunque estas plataformas son útiles para validar en forma definitiva los algoritmos creados, resultan poco prácticas para hacer pruebas rápidas durante el desarrollo. En este artículo se presenta un simulador de sistemas de metro de tamaño reducido, rápido y fácil de usar, que permite diseñar y evaluar estrategias de control tanto en como fuera de línea. En su versión actual permite controlar la velocidad de los trenes en las líneas, el tiempo de holding o retención de los mismos en las estaciones y el tiempo de despacho de los trenes desde las estaciones terminales de la línea. El simulador está programado en lenguaje C# (Microsoft), el cual tiene la ventaja de ser fácil de usar, proveer un buen soporte para lo programación orientada a objetos y dar facilidades para el 120 desarrollo de interfaces gráficas. Los algoritmos de control deben ser programados en SCILAB, un popular paquete de software gratuito para cómputo numérico. 2. CARACTERÍSTICAS DEL SIMULADOR 2.1. Paradigmas empleados Para definir el modelo se empleó programación orientada a objetos (Stroustrup, 1997). Se trata de un paradigma de programación muy popular que consiste en definir clases de objetos diseñados específicamente para realizar determinada funcionalidad. Cada clase define un conjunto de datos miembros que representa toda la información necesaria para definir el estado de un objeto de la clase correspondiente. Además, implementa un conjunto de funciones miembro, o métodos, que determinan el comportamiento del objeto, y que pueden ser llamados por otras partes del programa para actuar sobre los datos miembros. Por un lado, esto permite modularizar el código, y por otro, los objetos abstractos constituyen una representación conveniente de elementos reales, como estaciones de metro, trenes, etc. que comparten una clase común pero de la que existen múltiples instancias u objetos. Por otro lado, se optó por un esquema de simulación orientado a eventos, contrapuesto al paradigma de simulación continua (Hill y Yates, 1992). Esto significa que, en lugar de resolver por integración las ecuaciones dinámicas que definen el comportamiento del sistema para cada instante de tiempo, el procesamiento sólo se realiza en instantes irregulares de tiempo discretos. En cada uno de estos instantes, o pasos, se actualizan las variables de estado del sistema y se calcula el instante en que debe ocurrir el próximo paso. Lo que pueda ocurrir entre pasos no se toma en cuenta. Esto da la ventaja de reducir considerablemente los requisitos de capacidad de procesamiento, aunque naturalmente se pierde detalle del proceso. El uso de este paradigma se justifica pues todos los sucesos principales en esta aplicación (llegadas y salidas de trenes de estaciones, llegadas de pasajeros, etc.) ocurren en instantes bien definidos, y lo que transcurre entre dos eventos, como por ejemplo la forma exacta en que se desplazan los trenes a través de las vías, no es relevante, pues no afecta mayormente las decisiones de control. 2.2. Características de la simulación El software puede simular simultáneamente cualquier número de líneas conectadas entre sí a través de estaciones de combinación. A continuación se describen diversos aspectos del mismo: • Las líneas son bidireccionales y pueden contener cualquier número de estaciones, incluyendo dos estaciones terminales en cada extremo. Los trenes se van desplazando por la línea y parando en las estaciones un tiempo que depende tanto de la ocupación de pasajeros (ver más adelante) como de la estrategia de control que se emplee. • En los tramos de líneas entre estaciones, se asume que éstos se mueven con velocidad constante, de modo que el tiempo que tardan en recorrer el trayecto es simplemente: 121 t = v / d + tA (1) donde v es la velocidad, d la distancia y tA un tiempo aleatorio. Esto representa evidentemente una simplificación del caso real, en el cual los trenes tienen un perfil de velocidad a lo largo de la línea, pero si se interpreta la velocidad simplemente como “distancia recorrida” / “tiempo empleado” la aproximación debiera ser suficientemente cercana a la realidad para los propósitos de evaluar la operación del sistema a nivel global, sin entrar en detalles sobre el movimiento en cada momento de los trenes. tA es, como ya se indicó, una variable aleatoria que distribuye normal y permite incorporar un componente estocástico al movimiento de los trenes; su media y desviación estándar deben ser fijados por el usuario y son únicos para todos los tramos de la línea. • Aunque la velocidad de los trenes es en principio constante, puede ser cambiada debido a acciones de control, como se explica en la sección 2.3. Esto implica que puede haber trenes con velocidades distintas e incluso un mismo tren puede comenzar un tramo con cierta velocidad y terminarlo con otra. Aquí se considera, simplemente, que la velocidad cambia bruscamente de un valor a otro. • Los trenes van numerados según su posición relativa, y en condiciones normales este orden no puede cambiarse, es decir, los trenes no pueden adelantarse entre sí. Si un tren arriba a una estación que está ocupada entra en “modo de espera” hasta que la estación se desocupe y recién entonces ingresa en ella. Algo parecido ocurre si los trenes se alcanzan unos a otros dentro de la línea. • En los extremos de las líneas existen “colas de maniobra” en las cuales es posible almacenar un determinado número de trenes definido por el usuario. Al abandonar una estación terminal, los trenes tardan un tiempo fijo en llegar a la respectiva cola, e igualmente tardan un tiempo fijo en abandonarla y llegar a la primera estación en el sentido contrario. El momento en que se despacha el primer tren que se encuentra en la cola está determinado por el control, como se explica en la sección 2.3. Si la cola está llena, un tren que se encuentre en la estación terminal correspondiente no la abandona hasta que el primer tren de la cola la abandone; igualmente, si la primera estación en la vía contraria está ocupada, el primer tren en la cola se queda ahí hasta que se desocupe. • Además, en los tramos de línea entre estaciones el usuario puede definir “vías laterales” paralelas a algunos tramos de línea en que los trenes se pueden mantener temporalmente estacionados. Al ser despachado un tren, el control puede definir que en lugar de funcionar normalmente, salte las estaciones y se dirija a determinada vía lateral de la línea donde se queda hasta que el control le permita abandonarla y reintegrarse a la operación normal. El mecanismo de control del tren se explica en la sección 2.3. El usuario debe definir en qué puntos del tramo de línea se encuentran la entrada y salida de la vía lateral. Al igual que los depósitos de los terminales, cada vía lateral tienen cierta capacidad y, si ésta es excedida, el siguiente tren que quiera entrar en ella se quedará parado en espera, bloqueando la vía principal en el punto en que se encuentra. Las vías laterales permiten tener a los trenes que esperan en ellas aguardando a que cierta parte de la línea se congestione más y en ese 122 momento “soltarlos” para servir rápidamente a la parte congestionada de la línea sin tener que pasar por el resto. • Los pasajeros llegan a las estaciones según un proceso de Poisson compuesto; es decir, llegan en grupos separados por intervalos de tiempo que distribuyen exponencial. El tamaño de cada grupo distribuye Poisson. Por lo tanto, se requieren dos parámetros para determinar la llegada de pasajeros a cada estación: el número de grupos que llegan por unidad de tiempo y el tamaño medio de estos grupos. El valor de ambos parámetros puede ir variando a lo largo de la simulación en forma discreta si así lo desea el usuario, que puede especificar valores distintos para distintos intervalos de tiempo. • Al arribar un tren a una estación, debe permanecer allí un tiempo mínimo (dwell time), el cual está dado por un modelo simple del tipo que se puede encontrar en (Lin y Wilson, 1992): T = α + β PS + γ PB + δ PO + TA (2) donde PS es el número de pasajeros que aborda el tren (generalmente, el número de pasajeros que hay en la estación, a menos que el tren haya llegado al tope de su capacidad), PB es el número de pasajeros que bajan en la estación, PO es el total de pasajeros que se encuentran tanto en la estación como en el metro, ya sea que suban/bajen o no, con el fin de considerar el efecto de congestión que produce un número excesivo de pasajeros, y TA es un tiempo aleatorio de distribución normal que permite incorporar un componente estocástico al dwell time y cuyos parámetros deben ser determinados por el usuario en forma única para toda la línea. α, β, γ y δ son parámetros también definidos por el usuario. La capacidad de los trenes también es un parámetro constante para todos los trenes de la línea. • El dwell time anterior no es necesariamente el tiempo que el tren permanecerá en la estación; éste puede ser mayor si el control especifica un tiempo de retención o holding, como se explica en la sección 2.3. Sin embargo, el tren no puede salir de la estación antes de pasado el dwell time. • En cada tren los pasajeros están divididos en grupos según su estación de destino. Cada vez que un pasajero sube a un tren, se decide aleatoriamente a qué estación se dirige en base a las probabilidades dadas por una matriz origen-destino que el usuario debe especificar para la línea. Se especifica una matriz origen-destino distinta para cada sentido (vía) de la línea. Cuando un tren llega a una estación, todos los pasajeros del grupo correspondiente deben bajar. • Al llegar un tren a una estación de combinación, se considera que una proporción fija de los pasajeros que ahí descienden hace la transferencia a la otra línea. Si el número de estos pasajeros es mayor que 5, se dividen en 5 grupos de distintos tamaños (siguiendo una curva normal). A cada grupo se le asigna un tiempo que demora en hacer la combinación, en base a los parámetros de tiempo medio y desviación estándar ingresados por el usuario: el primer grupo tarda el tiempo medio menos 2 desviaciones estándar, el segundo el tiempo medio menos 1 desviación estándar, el tercero justo el tiempo medio, etc. Además, si el número de 123 pasajeros transferidos supera un mínimo definido por el usuario, se genera “atochamiento” y se penaliza el tiempo que demora cada grupo en hacer la combinación en una cantidad proporcional al total de pasajeros que ya han pasado. Al pasar el tiempo correspondiente a cada grupo, los pasajeros que contiene se agregan a la estación en la línea opuesta. • El número de metros en funcionamiento y su posición inicial son especificados manualmente por el usuario, quien puede situarlos inicialmente en cualquier estación, tramo de línea, rama o terminal, indicando valores como el tiempo de llegada a la estación actual o su posición inicial dentro de un tramo de línea para permitirle al software decidir cómo deben comportarse al comenzar la simulación. 2.3. Control en Tiempo Real El simulador puede operar en modo de “lazo abierto”, en el cual los trenes tienen todos una velocidad fija, se detienen un tiempo de holding o stop predeterminado en todas las estaciones y, al llegar a los terminales, son despachados a intervalos regulares desde ellos, todos éstos parámetros que pueden ser fijados por el usuario. Sin embargo, el objetivo principal del simulador es permitir al usuario escribir sus propias funciones de control que pueden, según los objetivos buscados, incluir información en tiempo real de la operación. Estas funciones deben ser escritas en SCILAB en archivos .SCI, respetando, las variables de entrada y salida definidas por el simulador. Éste accede a los servicios de SCILAB (y, a través de éstos, a la función escrita por el usuario) a través de las DLLs provistas por SCILAB. Actualmente el sistema de control puede actuar sobre 4 tipos de “variables manipuladas”: tiempos de holding, velocidades de línea, tiempos hasta el despacho desde los terminales del siguiente metro y tiempo hasta el despacho desde las vías laterales. Las primeras dos se definen para cada tren, mientras que la tercera está asociada a las líneas y la última a las vías laterales. En el caso de controlar el despacho desde las vías laterales, se puede manipular también qué trenes serán dirigidos al momento del despacho hacia una de estas vías en lugar de operar normalmente. Cada vez que un tren cambia de estado, es decir llega o sale de una estación, arriba a un depósito terminal o a una rama, etc., se invoca al sistema de control para que actualice las variables manipuladas. Para hacerlo, éste recaba información sobre el estado del sistema completo, lo cual implica obtener la siguiente información de cada tren: estado (en estación, en línea o en espera), índice del tren y línea a la que pertenece. El índice numera a los trenes ordenadamente según su posición relativa. Además, si está en una estación, se incluyen el tiempo de llegada a ella, el número de pasajeros con que llegó y el número de los que había en la estación al momento del arribo, así como el tiempo de holding pre-asignado al tren. Si el tren está en un tramo de línea, incluyendo el caso en que está esperando para entrar a una estación ocupada, se incluyen su velocidad, su posición y el número de pasajeros que lleva. En cuanto a las estaciones, se explicitan la línea a la que pertenecen, el número de pasajeros que hay en ellas, así como el tiempo de la última llegada y la última salida de un metro de cada estación. Además de todo esto, se incluyen el tiempo actual y el índice y línea a que pertenece el metro que gatilló la llamada al sistema de control. Finalmente, se pueden definir 6 parámetros opcionales para la función de control, según lo requiera el usuario. 124 Toda esta información se almacena en sendas matrices de SCILAB que se entregan como argumentos a la función definida por el usuario. Se espera que esta función use algún criterio de control para generar una matriz de salida con las variables manipuladas que deben cambiar de valor. Esta matriz debe tener tantas filas como controles se pretendan cambiar; en cada fila se incluye el tipo de variable que se quiere alterar (holding, velocidad o tiempo para despacho de terminal o vía lateral), la línea y el índice del tren (este último sólo si corresponde) y el nuevo valor que debe tomar la variable de control. El programa realiza inmediatamente los cambios requeridos y luego procede con la simulación. 3. INTERFAZ DE OPERACION La interfaz, que se muestra en la figura 1, permite al usuario crear gráficamente nuevas líneas, estaciones, combinaciones, etc. con el mouse. Además, haciendo clic en los distintos elementos es posible acceder a cuadros de diálogo para ingresar los parámetros correspondientes, como en la figura 2, que corresponde a los parámetros generales de una línea, incluyendo capacidad de los trenes, parámetros α, β, γ y δ del modelo de dwell time, matrices origen-destino y los demás que ya se mencionaron en las sección 2.2. Cuadros similares pueden invocarse para parametrizar estaciones, estaciones de combinación y vías laterales. Otros valores que pueden fijarse directamente en la ventana principal son los tiempos de inicio y fin de la simulación y la semilla del generador de números aleatorios. Dejar constante el valor de la semilla permite correr la simulación bajo las mismas condiciones (por ejemplo, los pasajeros arribarán a las estaciones de exactamente la misma manera) pero con estrategias de control distintas. Además, es posible guardar las líneas representadas para volver a usarlas en una ocasión posterior. Figura 1. Ventana principal de la interfaz de la aplicación 125 Figura 2. Cuadro de configuración de los parámetros de la línea Una vez ingresadas las líneas, el siguiente paso consiste en ingresar las condiciones iniciales, esto es, el número y posición inicial de los trenes y la cantidad inicial de pasajeros en las distintas estaciones y trenes. Para ello, se debe hacer clic sobre un botón especial y a continuación seleccionar las estaciones, tramos de línea, ramas o terminales en que se desea agregar un tren o especificar la cantidad inicial de pasajeros, además de parámetros como el tiempo de llegada del tren a cierta estación o su posición dentro de un tramo de línea. Finalmente, se puede definir el nombre y ubicación en disco del archivo .M que contiene la función de control escrita por el usuario, cuáles variables manipuladas se desea que ésta controle (holding, velocidad de trenes y/o tiempos para despacho de terminales/vías laterales) así como los valores de los 6 parámetros opcionales que se le pasan. Una vez seleccionados estos valores, se da inicio a la simulación. Terminada ésta, es posible acceder a estadísticas por línea o por estación, incluyendo: • Tiempo de espera promedio de pasajeros (por estación o total de la línea) • Tiempo de viaje promedio • Ocupación promedio de las estaciones y trenes • Frecuencia promedio de trenes en una estación • Número total de trenes que se quedan esperando para entrar a una estación por estar ésta ocupada al llegar a ella Las estadísticas anteriores pueden obtenerse para el total de la simulación o sus promedios a lo largo de intervalos de 15 minutos. Además de las estadísticas, se pueden obtener 2 tipos de representación gráfica del desarrollo de la simulación. El primero es el diagrama distancia-tiempo de cada línea, un ejemplo del cual se muestra en la figura 3. Aquí, el eje X representa el tiempo y el eje Y la distancia a lo largo de la línea; cada línea representa un tren distinto a medida que se desplaza por la línea. También es 126 posible obtener un gráfico de la cantidad de pasajeros en cada estación en función del tiempo como muestra la figura 4. Figura 3. Diagrama distancia-tiempo de una línea Figura 4. Diagrama de subida de pasajeros en una estación Finalmente, es posible almacenar un registro del desarrollo de la simulación en forma de un archivo de datos SCILAB (un archivo .DAT). Almacena una matriz para cada estación y cada tren. Cada fila de las matrices representa un instante de tiempo en que ocurrió algún suceso en el tren o estación correspondiente, como la llegada de un pasajero o el arribo a una estación. Las distintas columnas contienen los valores de las variables de estado relevantes, como total de pasajeros, posición del tren, etc. 4. EJEMPLO DE APLICACIÓN Para mostrar cómo opera el simulador se propone un sencillo esquema de control en tiempo real basado en regularización del headway de salida de estaciones, es decir, el tiempo entre sucesivas salidas de trenes desde cierta estación. Se pretende que este headway sea siempre constante e igual a H, un parámetro de control. La estrategia es la siguiente: cada vez que un tren arriba a una 127 estación en un instante tlleg, se computa el instante de la salida del tren anterior a esa misma estación, tant. El headway h se calcula como sigue: 0, tlleg ≥ tant + H ⎧ h=⎨ ⎩tant + H − tlleg , tlleg < tant + H (3) Esto significa que el control intentará, a través del holding de los trenes en cada estación, mantener el headway de salida de ésta constante. Hay que notar que si el tren llega muy tarde, el holding es cero para intentar hacerlo pasar lo más rápido posible considerando que el tren puede requerir un tiempo mínimo para que suban y bajen todos los pasajeros. El control fue probado para una línea similar a la Línea 5 del Metro de Santiago, con 18 estaciones en cada sentido, con un largo total de 14.5 km. Se consideran en total 26 trenes, inicialmente repartidos uniformemente a lo largo de la línea, los cuales se mueven entre estaciones con una velocidad promedio de 70 km/hr. Los pasajeros arriban a las estaciones con una tasa promedio de 0.25 pasajeros/seg en un sentido y de 0.16 pasajeros/seg en el otro; las desviaciones estándar de estas tasas entre estaciones son de 0.26 pasajeros/seg y 0.15 pasaj/seg, respectivamente. El modelo de dwell time considera los parámetros α=5 seg, β=γ=0.5 seg/pasaj, δ=0. El tiempo de simulación es de media hora. Considerando el largo de la línea y el número de trenes, éstos debieran estar a aprox. 1.2 km de distancia uno de otro para estar perfectamente repartidos a lo largo de la línea. A una velocidad de 70 km/hr, esto significa un headway de por lo menos 1 min entre trenes sucesivos, el cual debiera aumentar debido al dwell time en estaciones. En la tabla 1 se muestran los resultados de la simulación para distintos valores del parámetro de headway H, junto con el tiempo promedio de espera de pasajeros en estaciones y de viaje en trenes. Como comparación, se incluye también el caso sin control en que el holding es constante para todas las estaciones e igual a 15 seg; los resultados son claramente peores y, a diferencia del caso controlado, empeoran al aumentar el tiempo de simulación debido a que los trenes tienden a juntarse (fenómeno conocido como “bunching”) haciendo aumentar cada vez más los tiempos de espera: el sistema es inestable en lazo abierto. Lo anterior se puede observar en la figura 5, que muestra los diagramas distanciatiempo para los casos con y sin control. Tabla 1. Resultados de las simulaciones Parámetro H (segundos) Tiempo promedio de Tiempo promedio de espera en estaciones viaje en trenes (seg/pasaj) (min/pasaj) Sin Control 78.50 10.09 70 44.43 8.78 80 37.18 8.23 90 25.48 8.36 100 24.23 8.91 110 24.78 9.37 120 24.83 9.90 130 25.19 10.34 128 Figura 5. Diagramas distancia-tiempo para el caso sin control (abajo) y con control (arriba) En las figuras 6 y 7 se grafican los resultados de la tabla 1; de aquí se observa que un buen valor para el parámetro H, que permite un compromiso entre tiempos de espera y de viaje, es de H=90 seg. Figura 6. Tiempo promedio de espera de pasajeros en estaciones en función de parámetro H 129 Figura 7. Tiempo promedio de viaje de pasajeros en trenes en función de parámetro H 5. CONCLUSIONES Y RECOMENDACIONES El simulador simplifica varios detalles de la operación de un sistema de trenes metropolitanos, con el fin de obtener simulaciones rápidas y facilitar el desarrollo y evaluación de sistemas de control. Entre las mejoras consideradas se incluye: a) incorporar un perfil de velocidades de los metros en los tramos de línea más acorde con la realidad; b) modelar en forma más precisa los tiempo de subida y bajada de pasajeros; c) incorporar funciones de cálculo de energía requerida para el movimiento de los metros para incorporarlo como un resultado adicional de la simulación; d) eliminar la restricción de que todos los pasajeros que caben tienen que terminar de subir al metro para que éste pueda cerrar sus puertas y partir; e) considerar fallas u otros eventos que limitan la operación normal; f) incluir facilidad para probar en el simulador estrategias de operación expresa o station skipping (haciendo que los trenes se salten algunas estaciones), así como de short-turning, es decir, puentes para que los trenes se puedan devolver en ciertos puntos de la línea yendo en el sentido contrario al que iban; g) combinar el simulador con estrategias de control específicas para desarrollar una herramienta útil para el apoyo en línea a las decisiones de los operadores del sistema. Actualmente se trabaja también en la incorporación al simulador de estrategias de control más elaboradas, basadas en sistemas inteligentes y control predictivo. AGRADECIMIENTOS Esta investigación ha sido financiada por el proyecto Anillo de Investigación en Ciencia y Tecnología ADI-32 "Real Time Intelligent Control for Integrated Transit Systems". Agradecemos también al Departamento de Proyectos del Metro de Santiago por sus sugerencias y observaciones. 130 REFERENCIAS Hill, R.J. y Yates, T.K. (1992) Modelling Railway Block Signalling Systems Using Discreteevent Simulation. Railroad Proceedings of the 1992 ASME/IEEE Spring Joint Conference, 31, 1-9. Hürlimann, D. (2001) Objektorientierte Modellierung von Infrastrukturelementeu und Betriebsvorgängen im Eisenbahnwesen. PhD Thesis, Eidgenössische Technische Hochschule Zürich. Lin, T.H. y Wilson, N.H.M. (1992) Dwell Time Systems. Transportation Research Record, 1361, 287-295 Relationships for Light Rail Microsoft (2007) Microsoft Developer Network, Microsoft Corporation, Washington, U.S.A. PTV (2001) VISSIM User Manual – Version 3.60, PTV Planung Transport Verkehr AG, Karlsruhe, Germany. Quadstone (2000) PARAMICS v3.0 User Guide and Reference Manual, Quadstone Ltd., Edinburgh, U.K. Stroustrup, B. (1997) Abstraction Mechanisms. In The C++ Programming Language, Special Edition, 3ª Ed., Addison-Wesley, Massachusets, U.S.A.