simulación y control de un sistema de trenes

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.