Diseño e Implementacion en Python de Un Modelo de Simulación de Horarios de Servicios Ferroviarios PDF

Proyecto Fin de Carrera
Ingeniería de Telecomunicaciones
Diseño e implementación en Python de un

modelo de simulación de horarios de servicios
ferroviarios
Autor: Francisco Hernández de la Torre
Tutor: Dr. José David Canca Ortiz

Acta
Título:
Autor: Francisco Hernández de la Torre
Tutor: Dr. José David Canca Ortiz
El tribunal nombrado para juzgar el proyecto arriba indicado, compuesto por los
siguientes miembros:
Presidente:
Secretario:
Vocal:
Acuerdan otorgarle la calificación de:
Sevilla, a de de 2014
RESUMEN
La planificación de redes y servicios de transporte ferroviario es una actividad de

enorme complejidad cuya característica fundamental radica en la necesidad de
disponer de una infraestructura específica dedicada a soportar la prestación de los
servicios, permitiendo el desplazamiento de las diferentes unidades y equipos.
Las inversiones necesarias para el desarrollo de las infraestructuras y el hecho de que

éstas sean de uso exclusivo de este modo de transporte, condicionan de manera
importante su gestión, despliegue y la aparición de nuevos servicios.
Este proyecto se centra en el diseño e implementación, en lenguaje Python, de una

aplicación que integre un módulo de construcción de líneas de transporte ferroviario,
sobre las que se va a poder simular cualquier horario específico ante cualquier
descripción de la demanda. Para ello se desarrolla un módulo de simulación que permite
evaluar aspectos básicos de la calidad del servicio horario, durante un periodo específico
de planificación.
ABSTRACT
The Planning of networks and rail transport´s services is a very complex activity. Its main
characteristic is based on the need of a specific infrastructure, dedicated to support the
services provision. That allows to have a clear movement of units and equipment.
The investments needed for the infrastructure’s development, has a significant effect
on management, deployment, and emergence of new services. Especially, when this
kind of transport is usually used by these investments.
This project is focused on the design and implementation of an application using Python
language. This application has to integrate a construction module of rail lines. So that,
it can be possible to simulate any specific timetable with any description of any
passenger’s demand. To accomplish this goal, it is necessary to develop a simulation
module to evaluate basics aspects of schedule service quality, during a specific period
of planning.
AGRADECIMIENTOS
Quisiera expresar mi más sincero agradecimiento a todos

aquellos que tanto directa como indirectamente han hecho
posible la realización del presente trabajo.
En primer lugar agradecer a mi director de proyecto, Dr. José

David Canca Ortiz, por la dirección y supervisión de este
trabajo así como por haber hecho posible que se llevase a
cabo. Gracias por tu dedicación, profesionalidad, paciencia y
disponibilidad.
También quiero agradecer a los miembros del

Departamento de Organización Industrial y Gestión de
Empresas I por su ayuda y colaboración prestada,
igualmente he de agradecer a la Universidad de Sevilla por
hacer posible la realización de este trabajo.
Especialmente, quiero agradecer a mi familia y a Lorena, por

estar siempre a mi lado, por su cariño y apoyo incondicional
y por haber sufrido con paciencia la terminación de este
Proyecto.
ÍNDICE
1 INTRODUCCIÓN .................................................................................................. 10
1.1 INTRODUCCIÓN A LA PLANIFICACIÓN FERROVIARIA ........................................................10
1.2 PROBLEMAS ESTRATÉGICOS ......................................................................................11
1.2.1 Diseño de Redes (Network Design) ................................................................11
1.2.2 Planificación de Líneas (Line Planning) ..........................................................14
1.3 PROBLEMAS TÁCTICOS .............................................................................................18
1.3.1 Scheduling y determinación de horarios (Timetabling) .................................18
1.3.2 Platforming .....................................................................................................22
1.3.3 Rolling Stock ...................................................................................................24
1.3.4 Crew Scheduling .............................................................................................30
1.3.5 Crew Rostering ...............................................................................................31
2 OBJETIVO DEL PROYECTO.................................................................................... 35
3 ALCANCE ............................................................................................................ 37
3.1 REQUISITOS MÍNIMOS ALCANZABLES ..........................................................................37
4 DESCRIPCIÓN DEL PROBLEMA DE SCHEDULING.................................................... 38
5 PYTHON COMO LENGUAJE DE DESARROLLO ........................................................ 40
5.1 CARACTERÍSTICAS ...................................................................................................40
5.2 VENTAJAS .............................................................................................................41
5.3 DESVENTAJAS ........................................................................................................41
5.4 PYTHON EN LA WEB................................................................................................42
5.5 MÓDULOS Y PAQUETES EN PYTHON ...........................................................................42
5.6 SAGE ....................................................................................................................43
5.6.1 Características de Sage ..................................................................................43
5.6.2 Paquetes incluidos en Sage ............................................................................45
6 IMPLEMENTACIÓN.............................................................................................. 46
6.1 DESCRIPCIÓN DEL SIMULADOR ..................................................................................46
6.2 PARÁMETROS DEL SIMULADOR..................................................................................47
6.2.1 Parámetros de entrada ..................................................................................47
6.2.2 Parámetros de salida .....................................................................................56
6.3 MODOS DE SIMULACIÓN ..........................................................................................58
6.3.1 Modo 0 ...........................................................................................................58
6.3.2 Modo 1 ...........................................................................................................62
6.3.3 Modo 2 ...........................................................................................................65
7 EVALUACIÓN DE LA IMPLEMENTACIÓN ............................................................... 68
7.1 INTRODUCCIÓN AL ENTORNO DE PRUEBAS...................................................................68
7.2 PRUEBAS REALIZADAS Y RESULTADOS .........................................................................68
7.2.1 Prueba modo de simulación 0 ........................................................................68
7.2.1.1 Fichero de resultados para el modo de simulación 0 .............................80
7.2.2 Prueba modo de simulación 1 ........................................................................86
7.2.2.1 Fichero de resultados para el modo de simulación 1 .............................95
7.2.3 Prueba de simulación modo 2 ..................................................................... 102
7.2.3.1 Fichero de resultados para el modo de simulación 2 .......................... 111
7.2.4 Comparación de los 3 objetos “Horario” obtenidos.................................... 118
8 EXPLICACIÓN DETALLADA DEL CÓDIGO.............................................................. 120
8.1 CLASES .............................................................................................................. 121
8.2 ATRIBUTOS ......................................................................................................... 121
8.2.1 Explicación de atributo: ............................................................................... 123
8.3 MÉTODOS .......................................................................................................... 129
8.4 PSEUDOCÓDIGO .................................................................................................. 130
8.4.1 main() .......................................................................................................... 130
8.4.2 Carga_distancias (DisDataFile) ................................................................... 132
8.4.3 Carga_matriz (MatDataFile) ....................................................................... 132
8.4.4 calcula_cargas (Escala) ............................................................................... 133
8.4.5 class timetable ............................................................................................ 135
8.4.6 Método calcula_tiempos (self) .................................................................... 137
8.4.7 Método rellena_modo2 (self,FileTT) ........................................................... 139
8.4.8 Método calcula_llegadas (self, Escala, TipoDem)....................................... 141
8.4.9 Método: demanda_tren (self,tren,sentido,escala) ..................................... 143
8.4.10 Método: calcula_incompletos() ............................................................... 145
8.4.11 Método: calcula_todo_timetable (Porcentaje1, Porcentaje2) ................ 147
8.4.12 Método calcula_todas_vars_timetable (Porcentaje1, Porcentaje2)....... 149
8.4.13 Método: calcula_FO_UP(self) .................................................................. 149
9 CONCLUSIONES Y LÍNEAS DE TRABAJO FUTURAS ................................................ 152
9.1 CONCLUSIONES ................................................................................................... 152
9.2 LÍNEAS DE TRABAJO FUTURAS................................................................................. 153
10 BIBLIOGRAFÍA ................................................................................................... 154
ÍNDICE DE GRÁFICAS
Figura 1: Esquema general de problemas en planificación de servicios ferroviarios ....11

Figura 2: Diagrama UML entradas, salidas ......................................................................47
Figura 3: Función de demanda calculada a partir de matrices estáticas .......................54
Figura 4: Función continúa de demanda calculada a partir de sigmoides. ....................56
Figura 5: Ejemplo de trayectoria de trenes, modo 0 ......................................................62
Figura 6: Ejemplo de trayectoria de trenes modo 1 .......................................................64
Figura 7: Ejemplo trayectoria de trenes, modo 2 ...........................................................67
Figura 8: Trayectorias de trenes modo 0 ........................................................................70
Figura 9: Trasvase de pasajeros entre estaciones sentido Up, modo 0 .........................72
Figura 10: Trasvase de pasajeros entre estaciones sentido Dw, modo 0.......................73
Figura 11: Ocupación y de demanda atendida en sentido Up, modo 0 .........................74
Figura 12: Ocupación y de demanda atendida en sentido Dw, modo 0 ........................75
Figura 13: Tiempo medio de espera en cada estación y tren sentido UP modo 0.........77
Figura 14: Tiempo medio de espera en cada estación y tren sentido Dw, modo 0 .......78
Figura 15: Valores medios para modo de simulación 0 ..................................................79
Figura 16: Trayectorias de trenes modo 1 ......................................................................89
Figura 17: Trasvase de pasajeros entre estaciones sentido Up, modo 1 .......................90
Figura 18: Ocupación y demanda atendida, sentido Up y modo de simulación 1 .........92
Figura 19: Tiempo medio de espera, sentido UP, modo de simulación 1 ......................93
Figura 20: Valores medios para modo de simulación 1. .................................................94
Figura 21: Trayectorias de trenes modo de simulación 2............................................ 105
Figura 22: Trasvase de pasajeros entre estaciones, modo de simulación 2 ............... 107
Figura 23: Ocupación y demanda atendida para el modo de simulación 2 ................ 108
Figura 24: Tiempo medio de espera para el modo simulación 2 ................................ 110
Figura 25: Valores medios para el modo de simulación 2 ........................................... 111
Figura 26: Comparación de objetos “horario” ............................................................. 119
ÍNDICE DE TABLAS
Tabla 1: Fichero de distancias entre estaciones .............................................................49

Tabla 2: Fichero de demanda de pasajeros ....................................................................50
Tabla 3: Fichero de tiempos para la simulación del modo 2 ..........................................51
Tabla 4: Fichero de saltos para simulación de modos 0 y 1 ..........................................53
Tabla 5: Análisis de velocidades para el tren 1, en el ejemplo de simulación del modo 2
.........................................................................................................................................66
Tabla 6 Matriz de demandas de pasajeros entre cada par de estaciones modo 0 .......69
Tabla 7 Array de distancias entre estaciones modo 0 ....................................................69
Tabla 8: Matriz de demandas de pasajeros entre cada par de estaciones, modo 1 ......87
Tabla 9: Array de distancias entre estaciones modo 1 ...................................................87
Tabla 10 Fichero de saltos para modo de simulación 1 ..................................................87
Tabla 11: Matriz de demandas de pasajeros, modo de simulación 2. ........................ 103
Tabla 12: Fichero de horario.txt para el modo 2 de simulación .................................. 103
Tabla 13: Programación de paradas para el modo de simulación 2............................ 104
Tabla 14: Clasificación de los trenes que van a parar en cada estación por orden de
llegada, para el modo de simulación 2. ....................................................................... 109
ÍNDICE DE DIAGRAMAS DE FLUJO
Diagrama de flujo 1: Calculo de la capacidad del tren....................................................61

Diagrama de flujo 2: Función main () ........................................................................... 131
Diagrama de flujo 3: Función carga_distancias (DisDataFile) ...................................... 132
Diagrama de flujo 4: Función carga_matriz (MatDataFile) .......................................... 133
Diagrama de flujo 5: Función calcula_cargas (escala) ................................................. 134
Diagrama de flujo 6: Class timetable ........................................................................... 136
Diagrama de flujo 7: Método calcula_tiempos(self).................................................... 138
Diagrama de flujo 8: Método rellena_modo2 (self,FileTT) .......................................... 140
Diagrama de flujo 9: Método calcula_llegadas(self).................................................... 142
Diagrama de flujo 10: Método demanda_tren(self,tren,sentido,Escala) .................... 144
Diagrama de flujo 11: Función calcula_incompletos()................................................. 146
Diagrama de flujo 12: Método calcula_todo_timetable (porcentaje1, porcentaje2) . 148
Diagrama de flujo 13: Método calcula_todas_vars_timetable
(porcentaje1,porcentaje2) ........................................................................................... 150
Diagrama de flujo 14: Método calcula_FO (self) ......................................................... 151
Título: Diseño e implementación en python de un
Organización Industrial modelo de simulación de horarios de servicios
y Gestión de empresas I ferroviarios
Autor: Francisco Hernández de la torre
Tutor: José David Canca Ortiz
1 Introducción
1.1 Introducción a la planificación ferroviaria
La planificación de redes y servicios de transporte ferroviario es una actividad de

enorme complejidad. La característica fundamental que diferencia este tipo de
transporte del resto de transportes públicos radica en la necesidad de disponer de
una infraestructura específica dedicada a soportar la prestación de los servicios,
permitiendo el desplazamiento de las diferentes unidades y equipos.
Las inversiones necesarias para el desarrollo de las infraestructuras y el hecho de que

éstas sean de uso exclusivo de este modo de transporte, condicionan de manera
importante su gestión, despliegue y la aparición de nuevos servicios.
La complejidad de los problemas asociados a la planificación del transporte

ferroviario hace que tradicionalmente su estudio se divida en un conjunto de
problemas que se organizan de manera jerárquica. Los problemas que encabezan
esta jerarquía son de tipo estratégico (largo plazo y altas inversiones) y los niveles
inferiores representan problemas operacionales que exigen respuestas inmediatas.
A modo de resumen se introduce a continuación una descripción de este conjunto

de problemas y se realiza una revisión del estado de la cuestión en cada uno de ellos.
10
Figura 1: Esquema general de problemas en planificación de servicios ferroviarios
1.2 Problemas estratégicos
1.2.1 Diseño de Redes (Network Design)
El diseño de la red es el primer paso en el estudio de la planificación de

infraestructuras ferroviarias.
En la realidad, resulta muy difícil encontrar posibilidades para la realización de un

diseño de una red comenzando desde cero (por ejemplo, el diseño de nuevas líneas
de metro). Habitualmente los problemas de diseño se ciñen a aspectos de expansión
11
de una red existente, planteando la inclusión de nuevos tramos sobre una red
desplegada a lo largo de muchos años, cuya topología debe, en general, ser respetada
incluso si su evolución ha sido poco adecuada o si la evolución geográfica de una
región, comarca o área metropolitana ha convertido un buen diseño inicial en una
red poco conveniente.
La inclusión de nuevas infraestructuras debe llevarse a cabo de acuerdo a una

planificación temporal que considere la disponibilidad de las inversiones. El análisis
de este tipo de problemas debe tener en cuenta fundamentalmente aspectos
económicos, relacionados con el coste de construcción de nuevos tramos y aspectos
de tipo técnico, relativos a la existencia de accidentes geográficos, tipo de suelo…
que condicionan la viabilidad de las nuevas infraestructuras. También suelen ser
importante los aspectos sociales y políticos que en último término, influyen en gran
medida en la selección de nuevas soluciones.
Pese a que el análisis cuantitativo de este tipo de problemas puede ayudar de forma
importante a los decisores en la elección de un diseño adecuado en relación con los
aspectos mencionados con anterioridad, raramente las decisiones de diseño serán
puramente técnicas.
Este tipo de problemas estratégicos se ve rodeado de numerosos aspectos

cualitativos que, por lo general, llevan a una toma de decisiones de carácter político.
Los actores fundamentales (decisores) en esta etapa son aquellos organismos

públicos gubernamentales competentes en transporte. En el proceso de decisión
suelen intervenir diferentes empresas que se encargan de llevar a cabo esta
naturaleza.
12
Revisión bibliográfica.
Varios son los estudios han abordado problemas de diseño de redes de metro o
ferrocarril. La ubicación individual de nuevas líneas ha sido tratada en los trabajos de
Bruno et al. (1998, 2002) y Dufourd et al. (1996). En el primero, se minimiza la suma
ponderada de costes de viaje, mientras que en el segundo se maximiza la cobertura
de la población susceptible de utilizar la nueva línea.
El trabajo de Laporte et al. (2005), incorpora datos origen-destino con el fin de

maximizar la cobertura de viaje.
Los artículos de Hamacher et al. (2001) y Laporte et al. (2002) consideran el problema
de localización de estaciones a lo largo de un corredor mediante dos pasos. El
primero de ellos asume que existe una definición parcial de la nueva línea en la que
den ubicarse algunas estaciones. En el segundo paso se considera un conjunto de
puntos candidatos para localizar las estaciones.
García y Marín (2001, 2002) estudian el cambio de modo y el diseño de parkings

utilizando programación bi-nivel. Laporte et al. (2007) extienden el trabajo anterior
al caso de localización de estaciones en varios corredores de la red. El modelo
propuesto maximiza la cobertura considerando restricciones presupuestarias. Marín
(2007) analiza la inclusión de un número variable de líneas de manera que los
orígenes y destinos de cada línea pueden ser determinados.
13
1.2.2 Planificación de Líneas (Line Planning)
Establecida la red de transporte, es necesario especificar la forma en que debe

llevarse a cabo el transporte regular de pasajeros (o mercancías). Básicamente en
esta etapa se trata de encontrar tanto el origen como el destino final de cada servicio
y el camino sobre la red que debe seguir cada uno de ellos.
Resulta frecuente que en proyectos como el despliegue de un metro, se discuta sobre

la conveniencia o no de la puesta en servicio de una nueva línea, refiriéndose a la
misma en términos físicos, es decir considerando la construcción de las
infraestructuras que darán soporte físico a un conjunto de desplazamientos.
Sin embargo una vez establecida nuevas líneas y por tanto ampliada la red con las
nuevas infraestructuras, sería fácil revisar la definición de los servicios a prestar,
redefiniendo las líneas (caminos), sus longitudes, orígenes y destinos adaptando la
oferta a nuevas realidades en el comportamiento de la demanda.
La visión clásica de este problema en la literatura científica consiste en plantear un

modelo de optimización con el objetivo de “mover” a la mayor cantidad posible de
usuarios, desde sus puntos de origen hacia sus destinos habituales, minimizando el
número de trasbordos necesarios. Para efectuar este proceso se suele utilizar una
descripción de la demanda de transporte en forma de matrices Origen-Destino
(matrices cuadradas de dimensión el número de orígenes o destinos –normalmente
coinciden- cuyos elementos representan el número de viajeros que se desplazan
durante cierto intervalo de tiempo).
De acuerdo a la literatura científica la fase de planificación de líneas suele

proporcionar también las frecuencias necesarias para cada una de ellas, esto es la
obtención de las frecuencias se aborda de forma simultánea al proceso de selección
de líneas. Por lo general, la determinación de líneas se concreta en un problema de
selección de líneas de entre un conjunto de líneas candidatas predefinidas a priori no
obstante este enfoque presenta algunos inconvenientes.
14
La solución depende por tanto de la habilidad del modelador y del decisor para definir
el conjunto potencial de líneas candidatas. Sin duda este método facilita
enormemente tanto la formulación del modelo de Line Planning como el
procedimiento de resolución del problema, pero también sesga de forma importante
la calidad de la solución encontrada, que estará por tanto formada por un conjunto
de líneas de entre las definidas a priori.
Por otro lado, la frecuencia de servicio en cada una de las líneas se determina en base
a demandas máximas en cada tramo. Como consecuencia, las frecuencias son
siempre altas. Esta situación empeora conforme se consideran matrices de demanda
correspondientes a períodos más largos. Si por el contrario se consideran matrices
Origen-Destino correspondientes a períodos cortos (p.e. 1 hora), entonces es difícil
que las soluciones encontradas para diferentes períodos coincidan, siendo preciso
llevar a cabo un procedimiento de ajuste de frecuencias para intervalos consecutivos.
Habitualmente se utiliza una matriz de demanda diaria para definir el conjunto de

líneas de la red y posteriormente se consideran matrices correspondientes a
períodos punta y valle para determinar frecuencias.
Conviene citar que para la determinación de las frecuencias se consideran también

conocidas las capacidades de las unidades que prestarán el servicio.
De la misma forma que la etapa anterior, la planificación de líneas es un problema

estratégico. Los decisores son los organismos públicos gubernamentales
competentes en cada caso y como se comentó con anterioridad, apoyan sus
decisiones en recomendaciones de consultoras y empresas de ingeniería.
Revisión bibliográfica.
Hay un número limitado de artículos que tratan el problema de planificación de

líneas. La mayoría de ellas están relacionadas con el estudio de líneas de un único
tipo. Ninguno de los documentos distingue entre la utilización de líneas de un único
sentido o de doble sentido, aunque esta distinción parezca ser relevante.
15
Dienst (1978) describe un método de branch and bound (ramificación y poda) para
diseñar un sistema de líneas con el objeto de maximizar el número de pasajeros que
realizan trayectos directos
Bussieck et al. (1996) presentan también un sistema de diseño de líneas con el objeto
de maximizar el número de viajeros directos. Utilizaron variables de decisión
representando la frecuencia de cada línea y asumen que todos los trenes tienen la
misma capacidad, fijada inicialmente. Con el fin de reducir el número de variables de
decisión utilizaron un método de agregación de variables. Esta agrupación exige una
relajación de las restricciones de capacidad de los trenes. El modelo propuesto por
estos autores se resuelve aplicando diferentes técnicas de pre-procesamiento y
usando posteriormente un Solver ILP genérico. Los autores describen diferentes tipos
de desigualdades para mejorar la obtención de cotas inferiores. Posteriormente
Bussieck (1998) presenta una extensión del método propuesto.
Claessens et al. (1998) estudian el problema de encontrar un sistema de líneas de

mínimo coste. Para ello utilizan un modelo no lineal de programación mixta-entera
con variables binarias para la selección de líneas y variables adicionales para las
frecuencias y longitudes de los trenes. Los autores simplifican el modelo inicial para
transformarlo en uno lineal. El modelo se resuelve mediante un Solver ILP (integer
linear program) de propósito general, después de aplicar varias técnicas de
procesamiento previo.
Goossens et al. (2004) también se centran en el diseño de un sistema de líneas de

coste mínimo. El modelo que proponen es similar al modelo descrito por Claessens
et al. (1998). En Goossens et al. (2004) se describe un método de branch and bound
para resolver el modelo de optimización propuesto para el problema de planificación
de líneas. La característica principal del método es el uso de diferentes técnicas de
pre-procesamiento combinadas con varios tipos de desigualdades válidas para
mejorar las cotas inferiores del problema relajado y un conjunto de estrategias para
la selección de variables y selección de ramas en el proceso de ramificación.
Goossens et al. (2005) consideran el problema de diseño de un sistema de líneas

considerando varios tipos de líneas de forma simultánea. Con el fin de reducir el
16
número de variables de decisión, combinan y desagregan los flujos origen-destino

de pasajeros. Esto se justifica por el hecho de que sólo consideran la minimización de
costes y que no se consideran las consecuencias del uso de un único objetivo para
los pasajeros.
Lindner (2000) también estudia la minimización de los costes del sistema de líneas.
Lindner propone un método branch and bound para resolver el problema de diseño.
Su modelo integra el problema de planificación con la obtención de un horario
(Timetabling) de tipo cíclico. La parte del modelo encargada del problema de
Timetabling se basa en el modelo para la programación de eventos periódicos
(Periodic Event Scheduling –PESP) definido por Serafini y Ukovich (1989).
Recientemente, Scholl (2005) ha considerado el problema de planificación de líneas

con el objetivo de minimizar el número de trasbordos entre trenes, siendo este
objetivo bastante más complejo que la maximización del número de pasajeros en
trayectos directos. En casos reales, este tipo de redes resultan enormes. A la hora de
resolver, Scholl utiliza la relajación Lagrangiana para la obtención de cotas inferiores
y varios métodos heurísticos para generar soluciones factibles.
17
1.3 Problemas tácticos
1.3.1 Scheduling y determinación de horarios (Timetabling)
El tercer paso en la cadena jerárquica de problemas asociados a la planificación de

servicios ferroviarios es el denominado Scheduling. Antes de continuar es
conveniente resaltar las diferencias entre los términos Scheduling y Timetabling,
usados a veces de forma equivalente o poco clara en la literatura científica. El último
de ellos hace referencia exclusiva a la determinación de horarios, esto es, instantes
de salida y llegada de cada uno de los servicios a cada una de las estaciones de las
diferentes líneas de la red.
El término Scheduling es más general, incluye la determinación de horarios pero

además considera el movimiento de los vehículos y por tanto aspectos relacionados
con el orden de paso de los vehículos por ciertas estaciones (aspecto especialmente
importante en el caso de estaciones conectadas mediante segmentos de vía única),
es decir trata de identificar la secuencia que siguen los trenes con el objetivo de
completar los diferentes servicios ofertados.
Como se ha comentado, los problemas de Scheduling incorporan decisiones

adicionales como pueden ser los adelantamientos, tanto en estaciones como en
tramos de doble vía, las detenciones en apartaderos, los cruces en sentido contrario,
tiempos largos de parada en alguna de las estaciones y paso por estaciones sin
detención. De forma similar a lo que ocurre en otros campos (por ejemplo,
producción), los problemas de Scheduling pueden ser realmente complejos y de
difícil solución. Suelen dar lugar a modelos de optimización que representan
problemas NP-completos2.
Atendiendo a estas inconveniencias y al hecho de que en muchos casos, cercanías y

metro, los usuarios prefieren horarios regulares o repetitivos, desde el inicio del
estudio de problemas de tipo Scheduling en el campo ferroviario, los investigadores
18
han optado por centrar la mayoría de sus esfuerzos en el análisis de horarios de tipo
periódico, en consonancia con las frecuencias obtenidas en la etapa anterior.
El enfoque periódico considera que la definición última de los horarios corresponde

a un planificador central (el caso de Adif en España) que recibe unos horarios
tentativos por parte de los diferentes proveedores de servicios de transporte
(compañías de transporte). El planificador debe entonces obtener los horarios que
mejor se ajusten a los deseos de sus clientes (los operadores), que hacen uso de una
infraestructura común, propiedad del planificador. Este esquema es cada vez más
frecuente a nivel mundial, especialmente en los países desarrollados, como
consecuencia de la entrada en vigor de políticas de liberalización en el mercado del
transporte.
La separación entre infraestructura y servicios es ya clásica en los E.E.U.U, el caso de

Europa es diferente, sólo en la última década se ha consolidado este esquema como
consecuencia de la imposición de condiciones de libre competencia por parte de la
Comisión Europea.
Habitualmente los modelos de Scheduling ferroviario no incorporan información

acerca de la demanda de transporte. Tratan simplemente de obtener un patrón
repetitivo (periódico) de salidas y paso por estaciones.
Existen estudios de diversos autores que contemplan la obtención de horarios no

periódicos. Por lo general, este tipo de soluciones se adaptan mejor a las variaciones
de la demanda y suelen ser siempre convenientes en el caso de mercancías y de larga
distancia. Los modelos matemáticos que representan este tipo de problemas suelen
ser menos estructurados.
Revisión bibliográfica
Los problemas de Scheduling y determinación de horarios han recibido una

considerable atención en la literatura. Existen numerosas referencias que consideran
formulaciones mixtasenteras en las que los tiempos de llegada a las estaciones y los
19
instantes de salida se representan mediante variables continuas y se utilizan variables

binarias para representar el orden en las salidas de los diferentes trenes de cada una
de las estaciones. Szpigel (1973) considera una variante de estos modelos en la que
el orden de las salidas de los trenes de cada estación no utiliza variables binarias sino
que se modela mediante restricciones disyuntivas.
Este enfoque le permitió resolver instancias pequeñas mediante branch and bound,
calculando cotas a partir de la relajación de las restricciones disyuntivas.
Jovanovic y Harker (1991) resuelven mediante branch and bound una versión de
estos modelos que busca soluciones factibles en lugar de utilizar un procedimiento
de optimización guiado por una función objetivo.
Cai y Goh (1994) utilizan una heurística voraz para uno de los modelos anteriores.
Carey y Lockwood (1995) consideran una heurística que trabaja con los trenes de uno
en uno (en un orden apropiado) y para cada tren resuelven un problema MILP (Mixed
Integer Linear Programming).
Análogo a los modelos comentados con el fin de planificar los horarios de forma
óptima, manteniendo los caminos obtenidos para los trenes previamente calculados.
De forma algo más precisa, el orden relativo de las salidas de los trenes se mantiene
fijo, mientras que los tiempos de salida y llegada, así como el orden de llegada pueden
ser cambiados. Higgings et al. (1997) utilizan un procedimiento de búsqueda tabú
(TabuSearch), para un modelo de la familia antes mencionada.
Brannlund et al. (1998) discretizan el tiempo en intervalos de un minuto y subdividen

la línea en diferentes bloques. Utilizan entonces un conjunto de restricciones que
impiden que un mismo tren se encuentre en el mismo intervalo en bloques
diferentes. Definen un modelo entero y lineal con variables binarias que recogen la
situación de cada tren en cada bloque para cada instante.
Oliveira and Smith (2000) modelan el problema de determinación de horarios como

un caso especial del Job-Shop Scheduling Problem, considerando los trenes como
trabajos a ser programados en cada una de las líneas, que asumen la función de
20
recursos. Presentan un algoritmo híbrido basado en programación por restricciones

(Constraint Programming) y comentan las posibles adaptaciones de este enfoque en
aplicaciones a casos reales.
Caprara et al. (2002,2006) presentan dos modelos basados en la representación

gráfica del problema. En ambos trabajos usan una discretización del tiempo en
intervalos de un minuto y usan relajación Lagrangiana para calcular cotas del valor de
la solución óptima que para conducir el procedimiento heurístico de resolución. Este
enfoque permite el análisis de redes de gran tamaño.
En el caso cíclico, Schrijver y Steenbeek (1994) desarrollaron un algoritmo de

propagación de restricciones para resolver el PESP (Periodic Event Scheduling
Problem) ya comentado en la etapa de Line Planning. Este algoritmo se implementó
en el sistema DONS, usado por los ferrocarriles holandeses para la determinación de
horarios en su red nacional.
Con el fin de hacer frente a la débil relajación PL de los modelos basados en

restricciones, Nachtigall (1999), Lindner (2000) y Peeters (2003) también describen
una formulación de la PESP basada en bases cíclicas. Esta formulación es de alguna
manera más fácil de resolver que la formulación basada en restricciones, debido al
menor número de variables tipo entero y a una mejor relajación PL.
Nachtigall y Voget (1996) utilizan PESP para generar horarios cíclicos con tiempos de
espera mínimos para los pasajeros. Odijk (1996) utiliza la PESP a un nivel estratégico
para determinar la capacidad de la infraestructura alrededor de las estaciones. Kroon
y Peeters (2003) describen un modelo PESP incluyendo tiempos de viaje variables.
Esto puede resultar en una mayor flexibilidad que conduce a una mayor probabilidad
de obtener una solución factible.
Por último, Kroon et al. (2005) describen una variante de optimización estocástica
del PESP. Su modelo tiene en cuenta de forma explícita las perturbaciones
estocásticas de los procesos ferroviarios, distinguiendo entre un calendario previsto
y la realización de varios horarios bajo las perturbaciones estocásticas
predeterminadas
21
1.3.2 Platforming
El paso posterior al problema de Scheduling/&Timetabling suele ser el problema de

asignación de andén a los trenes que llegan a una estación (Platforming o TPP).
Existen varias versiones del problema que resultan relativamente sencillas para
estaciones pequeñas pero extremadamente difíciles cuando se aplican a estaciones
más grandes con topologías más complejas como las grandes estaciones europeas,
que cuentan con cientos de trenes y decenas de andenes.
Una estación principal típicamente dispone de varias líneas externas, generalmente

con dos vías que la conectan con otras estaciones, en el contexto de los TPP estas
líneas se denominan direcciones. Además, existen varios puntos en los que los trenes
pueden detenerse para que accedan los pasajeros, estos puntos son los andenes. Se
consideran andenes de diferentes tipos y longitudes, algunos corresponden a vías
muertas y otros continúan a través de la estación. La conexión entre las líneas y los
andenes se realizan a través de líneas internas llamadas rutas y definen el itinerario
dentro de la estación, que une una línea y un andén dados. Se diferencia entre rutas
de llegada y de salida de los andenes respectivamente, además, existen rutas
bidireccionales.
Dependiendo del contexto particular pueden existir más restricciones relacionadas

con el diseño de la estación, la seguridad o aspectos operacionales.
El problema tiene como objetivo definir para cada tren el andén en el que se detendrá
así como las rutas de llegada y salida, asegurando que se satisfacen todas las
restricciones operativas y minimizando el tiempo necesario para completar los
movimientos entre llegadas y salidas de la estación.
Hasta ahora no ha recibido demasiada atención en la literatura. De Luca y Mione

(1998) consideran la versión simplificada en la que, para cada tren, los horarios
22
programados de llegada y salida no pueden ser alterados y las rutas de llegada y salida
se determinan únicamente según la elección del andén.
Esta versión del problema se modela como un problema decoloración de grafos con
restricciones adicionales, para el que se propone y aplica un algoritmo heurístico a
ejemplos reales. La misma versión del TPP es estudiada por Billionnet (2003) que
considera una formulación ILP clásica para coloración de grafos y muestra cómo
incorporar al modelo las restricciones asociadas con la lista de parejas incompatibles.
Se resuelven ejemplos generados aleatoriamente usando un solver ILP genérico.
Una visión más general del problema en la que los instantes y rutas de llegada y salida
no están fijadas a priori es abordada por Zwaneveld (1997), Zwaneveld et al. (1996),
Zwaneveld et al. (2001), and Kroon et al. (1997). En realidad, estos autores
diferencian entre rutas de entrada (inbound routes), de salida (outbound routes) y
de andén (platform route) correspondiendo con el trayecto seguido por el tren para
entrar en la estación (sin ir a un andén), el trayecto dentro de la estación y la parada
en el andén y el trayecto para salir de la estación respectivamente. Aunque en la
práctica a cada tren haya que asignarle una ruta de cada tipo, los autores consideran
la posibilidad de que puedan no encontrarse algunas de ellas o, incluso, no se
encuentre ninguna. Esta versión es modelada mediante un problema de conjuntos
estables en un grafo en el que cada nodo corresponde a una elección para un tren
con un coste asociado y las aristas unen tanto nodos asociados al mismo tren como
nodos correspondientes a selecciones incompatibles para distintos trenes. El modelo
es formulado como un ILP con una variable binaria asociada a cada nodo y un grupo
de restricciones en forma de desigualdades. Las referencias anteriores describen
algoritmos heurísticos y exactos basados en la solución del problema PL relajado. Este
enfoque está incluido dentro del sistema STATIONS usado por la compañía alemana
de ferrocarriles para resolver el problema. En Zwaneveld (1997) se recogen los
resultados de problemas reales en las principales estaciones de Alemania.
La versión estudiada en Carey y Carville (2003) se encuentra en un punto intermedio

entre las dos versiones anteriores. En este caso, los instantes de salida y llegada
pueden ser modificados, pero la asignación del tren a un andén determina
inequívocamente la ruta de entrada y salida de la estación.
23
1.3.3 Rolling Stock
El problema de gestión de material rodante (Rolling Stock Circulation Problem (RSCP))

se centra en una actividad que resulta fundamental para los operadores de servicios
de transporte ferroviario, dado que la adquisición de material rodante supone
inversiones muy importantes a largo plazo. El coste de operación de los equipos
móviles (desplazamiento, mantenimiento, pernoctación y operaciones de
acoplamiento y desacoplamiento de vagones y locomotoras) es sustancial,
incluyendo costes de mantenimiento, personal (tripulaciones y limpieza) y costes de
la energía eléctrica consumida. Estos costes están positivamente correlacionados con
el número de kilómetros recorridos.
Los operadores ferroviarios deben decidir cuidadosamente el tipo y cantidad de

material rodante y su distribución en los diferentes servicios. Es más, la disponibilidad
de material rodante y su gestión puede influir en aspectos relacionados con la fase
de Scheduling, de ahí que existan algunos intentos por abordar conjuntamente
ambos problemas.
Con el objeto de ajustar el material rodante disponible y la demanda de viajes, la

composición de los trenes puede cambiar a lo largo de su recorrido en determinadas
estaciones, añadiendo o eliminando vagones de los trenes. Este tipo de operaciones
conllevan ciertos costes que deben ser considerados en el proceso y pueden afectar
a aspectos relacionados con la determinación de horarios y con la calidad de los
servicios.
Los vagones separados de los trenes se podrán usar posteriormente para aumentar
la capacidad de trenes que saldrán de la misma estación. Esto obliga a disponer de
cierto espacio dedicado al almacenamiento de los vagones en las estaciones y de un
sistema de gestión más complejo.
Normalmente, los cambios en la composición de los trenes deben respetar ciertas

condiciones relacionadas con el tiempo de operación necesario para efectuar los
acoplamientos y desacoplamientos y los tiempos disponibles en las estaciones entre
paso de trenes consecutivos. Por esta razón, el orden del material en la composición
24
es muy importante, ya que las operaciones de acoplamiento/desacoplamiento

requieren menos tiempo para equipamiento ubicado en la cola o la cabeza de los
trenes.
Podemos encontrar diferentes versiones del RSCP dependiendo de los equipos

usados y de la naturaleza de la red de transporte. De acuerdo al primero de estos
aspectos, tenemos:
1. Locomotoras y vagones de forma independiente.

2. Conjuntos locomotora/s-vagones definidos, denominados unidades de
tren.
Estas unidades hacen referencia a trenes compuestos por un número fijo de vagones
y locomotoras (una o dos) y que se pueden mover sobre la vía en ambas direcciones.
Ejemplos de esto lo tenemos en los trenes de alta velocidad, compuestos por dos
locomotoras y un número de vagones que suele oscilar entre 6 y 10. Es posible, según
sea necesario enganchar dos unidades para obtener trenes de mayor capacidad en
los momentos precisos que posteriormente se controlan en mando único, cediendo
el poder tractor a la locomotora de cabeza pero aprovechando la potencia de ambas
unidades.
En el primer caso, (Locomotoras y vagones de forma independiente) para cada

servicio programado en el horizonte temporal, se debe determinar el número y tipo
de locomotoras y el número y tipo de vagones. Estas cantidades están relacionadas
entre sí, ya que el número de vagones determina el tipo y numero de locomotoras
que se necesitan con el objeto de conseguir la suficiente capacidad de tracción.
En el Segundo caso (unidades), es necesario determinar sólo el tipo y el número de

unidades de cada tipo que deben ser usadas para completar los servicios. En el caso
de varias unidades de diferente tipo formando un convoy, el orden de las diferentes
unidades es importante. Puesto que las unidades se pueden mover sobre una línea
en ambas direcciones, los tiempos de cambio de dirección en los extremos de las
líneas son muy pequeños, lo que no ocurre en el primer caso, en el que es preciso
25
cambiar la posición y sentido de la/s locomotora/s o disponer de una vía especial en

Y.
Redes de alta densidad:
Para el caso de redes de alta densidad, Schrijver (1993) describe un modelo para
determinar el mínimo número de unidades que deben ser utilizadas en una línea
simple para evitar falta de asientos. Una línea se define por dos puntos entre los
cuales circulan trenes en ambos sentidos de acuerdo con el horario programado. En
el caso considerado, la compañía ferroviaria trabaja con un servicio de frecuencia
horaria y en el que sólo se utiliza un tipo de unidad (conjunto de locomotora/s y
vagones). Existen, sin embargo, dos subtipos de unidades que se diferencian en
longitud y en el número de asientos de primera y segunda clase. Un tren puede estar
formado por varias unidades de estos subtipos. Para cada viaje, se conoce la
demanda de asientos de primera y segunda clase. Las unidades pueden unirse o
separarse en varias estaciones a lo largo de la línea. Como es obvio, una unidad sólo
podrá unirse a un tren si, en la estación en la que este se encuentra, hay alguna
unidad disponible en ese momento. El modelo es básicamente un modelo de Flujo
Entero Multiproducto con algunas restricciones adicionales.
El modelo propuesto por Schrijver (1993) asume que una composición puede
transformarse en otra composición totalmente diferente en una estación entre dos
viajes consecutivos. En la práctica sin embargo, hay varias restricciones referentes a
la combinación de unidades que se deben tener en cuenta. Por lo tanto no sólo es
importante el número de unidades utilizadas sino el orden que ocupan en la
composición. En este caso particular, sólo se permite una operación (unión o
separación). Además, el lugar en el que las unidades se unen o se separan está
predeterminado: según la estación en la que se encuentre el conjunto las unidades
se añadirán o se separarán del convoy por la parte delantera o trasera. Además,
Schrijver (1993) asume que el material rodante (Rolling Stock) disponible por tren es
tal que se satisface toda la demanda. Sin embargo, en ausencia de un sistema de
reserva la demanda tiene carácter estocástico. Es por ello que no se puede garantizar
26
un sitio para cada pasajero. Un asunto que Schrijver (1993) no trata es que, si un tren
llega al final de la línea, este deja la estación cuanto antes. Esto significa que el tren
realizará el primer viaje de la misma línea que salga de la estación, posiblemente
después de que se hayan unido o separado varias unidades. Dicho esto, el primer
viaje de un tren después de llegar al final de la línea es conocido, distinguiéndose
varias secuencias de viajes a las que se denomina tren.
Para hacer frente a los puntos anteriores, Peeters y Kroon (2003) proponen un
modelo que minimice una función ponderada que depende de la escasez de plazas y
de otros costes, aproximados por el número de kilómetros recorridos. Además,
Peeters y Kroon (2003) tienen en cuenta explícitamente el número de cambios en las
composiciones ya que pueden dar una idea de la robustez del material rodante en
circulación. Su enfoque para tratar las restricciones sobre las posibilidades de
transición de una composición otra se basa en el concepto de grafo de transiciones
que será explicado más tarde.
Fioole et al. (2006) trabajan con una versión más compleja del RSCP. Su problema
también incluye la separación y unión de trenes en marcha. Como en estos casos es
complicado aplicar el concepto de grafo de transiciones, especialmente en el caso de
que las ramas en las que se divide la línea no tengan la misma longitud, ellos usan un
modelo MIP que se puede entender como una versión extendida del modelo descrito
por Schrijver (1993). Gracias a varios métodos para mejorar la calidad del modelo LP
relajado, se pueden resolver ejemplos relativamente extensos y complejos llegando
a soluciones próximas al óptimo en un tiempo razonable utilizando CPLEX.
Otro trabajo en el caso de redes de alta densidad es el de Brucker et al. (2003), que
se centra en la reasignación de rutas a transportes tirados por locomotoras. Su
objetivo es ajustar demanda y oferta en una región de Alemania que puede ser
considerada como una red densa. LA asignación de ruta a las locomotoras es llevada
a cabo en una etapa posterior del proceso de planificación y no es objeto de este
epígrafe. Para cada viaje, los instantes de llegada y salida y las estaciones son datos
así como la composición estándar del tren. El flujo de material rodante, impuesto por
los viajes programados, probablemente no es factible dada la disponibilidad limitada
de material rodante, es decir, el material rodante necesario no siempre estará
27
disponible en la estación de origen en el instante de salida, teniendo en cuenta los

requisitos necesarios para otros viajes. Para llegar a una solución de compromiso
entre el número de vagones solicitados y el número de vagones disponibles existen
dos opciones: añadir vagones vacíos al convoy o introducir viajes de
reaprovisionamiento de vagones entre estaciones. Obviamente la segunda opción es
mucho más cara. El modelo resultante es un modelo de flujo entero multirrecurso
que se resuelve heurísticamente usando recocido simulado (Simulated Annealing).
El modelo descrito por Peeters y Kroon (2003) se puede entender como una
extensión del modelo de Schijver. Para hacer frente al hecho de que en cada estación
las posibilidades de transición de una composición a otra son limitadas, ellos usan el
concepto de grafo de transiciones. Cada tren tiene su propio grafo de transiciones.
Como fue mencionado con anterioridad, un tren es una secuencia de viajes que se
llevan a cabo por el mismo convoy.
En el grafo de transiciones de un tren los nodos representan las composiciones

factibles, y los arcos representan las transiciones factibles entre composiciones. Más
específicamente, para cada viaje, las composiciones factibles son enumeradas
teniendo en cuenta el número de subcategorías, las limitaciones en la longitud del
convoy y el número máximo permitido de faltas de asientos de primera y segunda
clase. Después se determinan todas las transiciones posibles para los siguientes viajes
teniendo en cuenta las limitaciones para añadir o quitar vagones en las estaciones.
Seleccionando una ruta para cada tren mediante los grafos de transiciones, se
determina una composición factible para cada viaje, incluyendo transiciones factibles
entre dos composiciones. Como una unidad sólo se puede unir a una composición, si
está disponible en el momento y la estación justos, la interacción entre diferentes
trenes que viajan simultáneamente se modela haciendo un seguimiento de la
posición de los subtipos en cada instante relevante durante el periodo de tiempo
considerado. La cantidad de material en un evento e es igual al material rodante en
el instante inicial más los vagones que se han separado de sus trenes y menos los
vagones que se han unido a otros trenes en todos los instantes anteriores al evento
e. El modelo garantiza que en todas las estaciones, en cualquier instante el inventario
de todos los subtipos es mayor o igual a cero. Esto da pie a reformular el modelo
28
Dantzig-Wolfe cuyo LP relajado es resuelto por Peeters y Kroon (2003) mediante un

algoritmo de generación de columnas.
Redes de baja densidad:
Como el horizonte de planificación en una red dispersa o poco densa es normalmente

mucho más amplio que en redes de alta densidad, y los controles sobre el tiempo de
viaje hasta los centros de mantenimiento y ocurre lo mismo con el tiempo de viaje
hasta los centros de mantenimiento, los requisitos de mantenimiento deben ser
considerados explícitamente en la determinación del material rodante.
Cordeau et al. (2001) presentan un modelo para la asignación simultánea de

locomotoras y vagones. De este modo, el número y tipo de ambos equipamientos se
debe determinar para cada tren, teniendo en cuenta que las locomotoras asignadas
disponen de suficiente capacidad de arrastre. En general, son factibles varias
combinaciones de locomotoras y vagones existiendo diferencias en el número y clase
(primera o segunda) de las plazas en los vagones y de capacidad de arrastre en las
locomotoras. La velocidad de operación de los diferentes tipos de equipos puede
variar, siendo la velocidad de operación de un tren la velocidad de operación de su
componente más lento, es por esto que se requiere cierta flexibilidad en los horarios.
La solución encontrada es cíclica y puede ser repetida, periodo tras periodo, durante
toda la temporada.
Lingaya et al. (2002) presentan un modelo para hacer frente a la estacionalidad,

adaptando el modelo de Cordeau et al. (2001) a revisiones a corto plazo de la
demanda. Basándose en datos reales de billetes vendidos, el modelo trata de
encontrar ciclos alternativos buscando maximizar el beneficio esperado sujeto a
varias restricciones operativas.
Una vez determinados los ciclos, estos ya no pueden variar, ya que son la base para
el problema de gestión de personal o Crew Schedulling. Las restricciones más
importantes están referidas a los requisitos de mantenimiento y al tiempo mínimo
necesario para añadir o quitar vagones del tren (switching time) entre dos viajes
consecutivos que el convoy debe realizar. El switching time depende de los vagones
29
en la composición. El cambio de un vagón del “interior” del tren llevará más tiempo
que añadir o quitar un vagón al final del tren. Para cada vagón y día del horizonte de
planificación, en el que el vagón pueda comenzar un ciclo, se genera una red que
representa todos los ciclos potenciales para el vagón. Estas redes incluyen las
posibles condiciones inicial y final para el vagón impuestas por su posición al inicio
del periodo de planificación o por el hecho de que antes de un día dado, el vagón
debe estar en el centro de mantenimiento. El modelo tiene en cuenta tanto las
posiciones de las unidades dentro del tren como que un cambio en la cola del tren
sólo puede ser llevado a cabo por los vagones situados en la cola del conjunto. Se
propone un procedimiento de generación de columnas para resolver el LP relajado y
después se aplica un esquema heurístico de ramificación y corte para encontrar una
solución entera. Generalmente, el tiempo computacional es pequeño.
Maroti y Kroon (2007) describen un modelo para resolver el problema de asignación

de ruta para el mantenimiento que requiere muchos detalles de los cambios
potenciales como entrada. Esos detalles son necesarios para ser capaces de evaluar
la complejidad de los cambios de vía. Dado que los datos necesarios pueden ser
difíciles de conseguir, Maroti y Kroon (2005) también describen un modelo
simplificado que requiere entradas menos detalladas. Como el número de de
unidades a enrutar de forma urgente suele ser pequeño (de una a cinco), ambos
modelos pueden resolverse rápidamente mediante CEPLEX.
1.3.4 Crew Scheduling
Bajo esta denominación se conoce al problema de obtención de turnos de trabajo.

Una vez determinados los diferentes servicios programados (calculados en etapas
anteriores – Scheduling&/Timetabling) y el plan de gestión de material rodante
(Rolling Stock), incluidos los desplazamientos en vacío o fuera de servicio (Train
Shunting y desplazamientos en vacío para pernoctación- empty runs), es necesario
agrupar la carga de trabajo de conductores y personal auxiliar (en su caso) en
diferentes turnos que permitan atender todos los desplazamientos previstos.
30
Puesto que las frecuencias en las diferentes líneas suelen cambiar a lo largo del día
(dependiendo de las fluctuaciones de la demanda de transporte), la organización de
los turnos de trabajo raramente resultará homogénea, de forma que a determinadas
horas del día se concentrarán varios turnos en paralelo.
La definición de los turnos se complica con aspectos relacionados con los derechos
colectivos de los trabajadores adquiridos a lo largo de la actividad profesionaly
reflejados en los convenios laborales específicos firmados entre empresa y
trabajadores.
El resultado de la etapa de Crew Scheduling será un conjunto de turnos diarios,

dependientes del tipo de día, que deberán recoger no sólo su inicio y fin, sino
información sobre el lugar de inicio, la línea asignada (incluiso el vehículo), las
rotaciones y el lugar de finalización.
El grado de complejidad de estos problemas es en general elevado, dependiendo en

gran manera de las condiciones impuestas, resultando a veces muy complejo obtener
soluciones admisibles, lo que obliga a relajar las exigencias sobre el problema.
1.3.5 Crew Rostering
Una vez obtenido el plan de turnos que proporcione cobertura a todos los servicios
programados, es necesario proceder con la asignación individual del personal
disponible.
Dado que, generalmente, los turnos no serán exactamente iguales, ni en duración ni

desde un punto de vista cualitativo, teniendo en cuenta, además, los derechos
individuales adquiridos por los trabajadores (antigüedad, categoría, servicios
especiales asumidos…), resulta fácil comprender la dificultad de este proceso de
asignación.
31
Frecuentemente los planes de asignación de conductores y tripulación deben

considerar patrones de trabajo que garanticen dos o tres días de descanso después
de cierto número de días de trabajo consecutivo.
En muchas ocasiones es necesario incorporar condiciones de lugar de inicio o

finalización de servicio para determinados conductores, especialmente en el caso de
redes de larga distancia o cuando la explotación de las líneas se lleva a cabo por
diferentes compañías/autoridades dependiendo de aspectos geográficos (por
ejemplo, el caso de trenes de mercancías en líneas de larga distancia en E.E.U.U).
Dado que, en la mayoría d los casos, las cargas individuales de trabajo obtenidas (para
cierto intervalo de planificación) en el plan de asignación de personal no son
exactamente las mismas para todos los trabajadores, puede resultar necesario
considerar un sistema rotatorio de turnos que, atendiendo a las especificaciones de
ciertos conductores, permita equilibrar la carga de trabajo a lo largo de un período
completo de explotación (típicamente un año).
Resulta también frecuente la necesidad de mantener una bolsa de horas a nivel

individual, con el objeto de realizar compensaciones o exigir servicios especiales, bien
de un año para otro o actuando sobre períodos vacacionales o períodos especiales.
Revisión bibliográfica:
Son numerosos los trabajos sobre gestión de personal han sido tratados en la
literatura científica. Para trabajos relativos a transporte masivo y transporte aéreo,
se refiere al lector interesado a las revisiones de Arabeyre et al. (1969), Bodin et al.
(1983), Rousseau (1985), Daduna y Wren (1988), Desrochers y Rousseau (1992),
Barnhart et al. (1994), Desrosiers et al. (1995, Daduna y Voss (2001), y Ernst et al. (
2001,2004a, 2004b).
En cuanto a las aplicaciones ferroviarias, Caprara et al. (1997) presentan un estudio

de los métodos utilizados en la literatura. La mayoría de estos trabajos se centran en
la fase de Scheduling, que son por lo general resueltos mediante la generación de un
32
subconjunto adecuado de todos los turnos de trabajo y la posterior selección de ellos

mediante la resolución de un problema de cobertura (Set Covering Problem),
normalmente con la inclusión de restricciones adicionales.
Los métodos de resolución de problemas de cobertura descritos en la literatura

pueden resolver casos con varios cientos de servicios y varios miles de turnos, ver
Beasley (1987), Beasley y Jornsten (1992) y Balas y Carrera (1996). En la actualidad,
los mejores métodos para resolver los problemas de optimización hasta alcanzar el
óptimo de las soluciones siguen basados en el uso de Solvers ILP de propósito
general, ver Caprara et al. (2000). Cuando se abordan los casos más grandes, es
preciso recurrir a técnicas heurísticos.
Los clásicos algoritmos voraces son muy rápidos en la práctica, pero por lo general
no ofrecen soluciones de alta calidad, como se describió en Balas y Ho (1980) y Balas
y Carrera (1996). Jacobs y Brusco (1995) y Beasley y Chu (1996) proponen una
algoritmo genético y un algoritmo de recocido simulado, respectivamente, mientras
que Lorena y Lopes (1994) utilizan un enfoque sustitutivo basado en la relajación del
problema.
Sin embargo, los métodos heurísticos más eficaces para este tipo de problemas
parecen ser los que basados en relajación de Lagrangiana, siguiendo el trabajo
seminal de Balas y Ho (1980) y las mejoras por Beasley (1990), Fisher y Kedia (1990),
Wedelin ( 1995), Balas y Carrera (1996), Ceria et al. (1998), Caprara et al. (1999),
Kroon y Fischetti (2001), y Yagiura et al. (2006), este último haciendo también uso
extensivo de la búsqueda local y proporcionando las mejores soluciones conocidas
hasta ahora, aunque necesitando tiempos de computación considerablemente
mayores que, por ejemplo, los obtenidos por Caprara et al. (1999).
Abbink et al. (2005) describen un problema de scheduling ferroviario en los Países

Bajos, donde uno de los objetivos consiste en asignar la carga de trabajo total de la
forma más justa posible entre los puntos de origen y destino (depots) de la
tripulación, teniendo en cuent tanto las partes ventajosas como las menos atractivas
de los diferentes servicios.
33
En cuanto al problema de construcción de rosters (Asignación de tripulaciones), los

métodos de optimización descritos en la literatura presentan una clara concentración
en aplicaciones al caso de Italia y se describen en Caprara et al. (1998). La mayoría de
trabajos publicados se centran en aplicaciones al caso de autobuses urbanos donde
el número mínimo de equipos necesarios para realizar las tareas se puede determinar
fácilmente, y el objetivo consiste en distribuir uniformemente la carga de trabajo
entre los equipos. En el caso del transporte aéreo caso, se pueden utilizar enfoques
tipo Set Partitioning enfoques, consultar Ryan (1992), Gamache y Soumis (1998),
Gamache et al. (1999), así como las revisiones mencionadas de Bodin et al. (1983) y
Ernst et al. (2004a, 2004b. Problemas relacionados con la construcción de agendas
cíclicas de trabajo se describen en Balakrishnan y Wong (1990), y Caprara et al.
(2003).
Los mayores intentos de integrar Crew Scheduling y Rostering de forma conjunta

corresponden a Caprara et al. (2001), Ernst et al. (2001), y Freling et al. (2004). Los
dos últimos se basan en enfoques tipo Set Covering/parttioning.
34
2 Objetivo del proyecto
El principal objetivo de este proyecto es el diseño e implementación, en lenguaje

Python, de una aplicación que integre un módulo de construcción de líneas de
transporte ferroviario y un módulo de simulación que permita evaluar aspectos
básicos de calidad de servicio, teniendo como parámetros de entrada tanto aspectos
físicos de la línea (distancias entre estaciones consecutivas) como la definición de la
demanda de pasajeros entre cada par de estaciones y las características de los
vehículos (velocidad, capacidad), permitiendo diseñar o imponer horarios timetables,
especificando los desfases iniciales de los vehículos y los tiempos de parada durante
un periodo específico de planificación.
Además, el simulador incorporará diferentes modos de simulación para generalizar

el tipo de horarios que pueden ser impuestos sobre las líneas, como se comentará
posteriormente.
Se pretende que el constructor de líneas establezca una base sólida sobre la que
simular cualquier línea y cualquier horario (dentro de los diferentes modos
incorporados) cuya descripción se haya introducido en los parámetros de entrada del
simulador. Esto se trata de una herramienta general, capaz de simular cualquier línea
típica de un sistema de transito rápido, de media o de larga distancia y cualquier
horario específico ante cualquier descripción de la demanda, tanto en forma de
matrices origen destino como de demanda variable.
En este sentido, para demostrar la generalidad del simulador propuesto, se incluirán

varios escenarios que recogerán los diferentes modos de funcionamiento del
simulador.
En este proyecto sólo se realizan simulaciones del comportamiento de diferentes

horarios, quedando fuera del ámbito de este proyecto cuestiones relacionadas con
el control del tráfico ferroviario propiamente dicho o el uso simultáneo de la misma
35
vía por parte de dos trenes. Este tipo de problemas se consideran líneas de trabajo
futuras y objeto por tanto de proyectos venideros.
36
3 Alcance
El alcance del proyecto define y detalla los límites y objetivos que se deberán haber
alcanzado al término de su desarrollo.
Para ello, se ha incluido una lista con los requisitos mínimos que se deben cumplir en
el proyecto.
3.1 Requisitos mínimos alcanzables
El diseño de la aplicación de gestión de tráfico ferroviario que ha sido desarrollado

en lenguaje Python, deberá alcanzar los siguientes objetivos:
- 3 Modos diferentes de simulación, los cuales gestionarán de forma

independiente la demanda de personas y horarios seguidos por los trenes.
- Puede haber trenes que comiencen antes del inicio de nuestro espacio
temporal de trabajo, con el fin de acercar los resultados a la realidad
(equivalente a periodos warm up de una simulación, necesarios para
alcanzar un régimen estacionario).
- Puede haber trenes que no paren en algunas estaciones durante su

trayecto. Estrategias stop-skipping.
- Puede haber trenes que no necesiten recorrer todas las estaciones y por
tanto que comiencen y acaben en estaciones intermedias. Servicios
especiales tipo Short-turning y lanzaderas que concentren sus
movimientos en zonas específicas de una línea.
37
4 Descripción del problema de Scheduling
Uno de los aspectos clave de la gestión de redes ferroviarias es la determinación de

la programación de los trenes ya que afecta tanto al nivel de satisfacción de los
usuarios como al rendimiento y rentabilidad de la red.
Este tema tiene características específicas dependiendo del servicio a prestar. De

este modo, para redes de corto recorrido, como redes locales o de metro, donde la
frecuencia es normalmente bastante alta, determinar la frecuencia es más
importante que definir la programación (horarios) propiamente dicha.
El establecimiento de los horarios (o Timetabling) es la tercera etapa en un esquema

jerárquico compuesto por cinco etapas: Análisis de la demanda, planificación de
líneas, programación de servicios (o Scheduling), material rodante (o Rolling-Stock) y
gestión de personal. Los tiempos de llegada y salida se obtienen en la fase de
programación de los servicios.
En realidad, los horarios regulares son fácilmente memorizados por los usuarios y
también pueden ser calculados con menor esfuerzo. Por otro lado, en el caso de
redes de media y larga distancia, la demanda depende de la programación de los
servicios. En este tipo de escenarios en el que la demanda parece depender de la
programación, el enfoque periódico puede no ser eficiente.
Incluso en la simulación de redes de metro y redes ferroviarias locales, cuando la

demanda se considera uno de los factores principales para determinar los horarios,
la programación periódica no es óptima desde el punto de vista del usuario. Además,
un diseño ineficiente puede desembocar en comportamientos indeseables por parte
de los usuarios, que podrían elegir un medio de transporte alternativo (causando una
caída de la rentabilidad de la red).
38
La programación no periódica es especialmente importante en tramos largos con alta

densidad de tráfico. Este enfoque permite obtener tiempos de salida y llegada
óptimos tras la etapa de planificación de líneas.
Se debe mencionar que la mayoría de los enfoques existentes no formulan hipótesis

realistas sobre el comportamiento de la demanda de cada una de las líneas a lo largo
de un día completo sino que, en su lugar, utilizan una demanda uniforme contenida
en una (o varias) matriz origen-destino.
De hecho, el análisis de la demanda normalmente se hace sólo en la primera etapa

del proceso de planificación, generando una matriz origen-destino para el día
completo que es usada para determinar las frecuencias en la fase de planificación de
líneas.
El modelo de simulación descrito en este trabajo permite el análisis de medidas de

calidad de servicio, como tiempos de espera medios, ocupación de los vehículos y
número de personas que desean subir a los trenes, en contraposición a medidas del
rendimiento y rentabilidad de la red, relacionadas con el coste, aunque sería
relativamente sencillo obtener estos resultados a partir de los resultados de las
simulaciones.
39
5 Python como lenguaje de desarrollo
Python es un lenguaje de programación de scripting de alto nivel y de propósito

general, además de ser multiplataforma, busca lograr una gran simplicidad,
versatilidad y rapidez, tanto para su aprendizaje como para el desarrollo de
aplicaciones (Allen Downey,Jeffrey Elknery ChrisMeyers ,2002)
5.1 Características
 Python es un lenguaje de scripting interpretado, por lo tanto su código no

requiere compilación, basta con tener el intérprete para ejecutar las
aplicaciones. Por este motivo es usable (al igual que Java) en cualquier
entorno informático bajo cualquier sistema operativo.
 Es un lenguaje no fuertemente tipado y como consecuencia no requiere que

se declare el tipo de variable. Es un lenguaje orientado a objetos y por tanto
dispone de las características más importantes de este paradigma: Clases y
objetos, encapsulamiento de objetos y polimorfismo.
 Es un lenguaje minimalista, todo lo que no sirve no se usa, por lo que evita el

uso de las llaves {}, en cambio usa la indentación de código para definir
campos de actividad del código.
 No es aconsejable para programación de bajo nivel, Python es de muy alto

nivel como para tener control de memoria.
 Python posee infinidad de librerías que permiten trabajar desde diseño

dinámico de sitios web hasta la programación de escritorio
o diseñando videojuegos de gran calidad: podemos crear videojuegos tanto
en 2D con Pygame, como en 3D con SOYA 3D.
40
 Para programar interfaces gráficas lo mejor es QT y PyQT, o se puede

usar WxWidgets con WxPython y usando el constructor de GUI Boa
Constructor.
 Si se desea hacer juegos más profesionales se puede usar Panda 3D, es

multiplataforma y se puede usar con Python o C++.
 Permite la utilización de módulos algebraicos y sistemas computacionales

mediante SAGE que será explicado en el punto 5.6
5.2 Ventajas
 Curva de aprendizaje muy reducida.
 Código muy limpio y legible
 Posee gran variedad de librerías para todo lo que puedas imaginar.
 Es multiplataforma, solo es necesario programar una vez y no requieren

ajustes o compilaciones para otras plataformas.
5.3 Desventajas
 No posee un entorno de programación propio, pero debido a su sencillez,

podemos programar con un simple editor de texto.
41
5.4 Python en la Web
Django es un entorno de desarrollo y framework web de código abierto escrito en

Python que fomenta el desarrollo rápido y el diseño limpio y pragmático. Permite
construir aplicaciones web de manera rápida y con menos código. Se centra en
automatizar todo lo posible y se adhiere al principio DRY (Don't Repeat Yourself).
5.5 Módulos y paquetes en Python
Python está compuesto por módulos y paquetes Un módulo es un objeto que sirve
como contenedor para organizar código. Cada módulo tiene asignado un espacio de
nombres y dentro de ese espacio de nombres puede haber cualquier cantidad de
objetos y como en Python todo es un objeto, también puede contener otros módulos.
En lenguajes como C, lo equivalente es #include <math.h>, pero la diferencia está en

que todas las funciones, variables y constantes de la librería se quedan disponibles
en el espacio de nombres global.
Cuando se incluyen muchas librerías y el código se hace muy grande y se corre el

peligro de contaminar el espacio de nombres (namespace pollution), provocando la
colisión de nombres (namespace collision o namespace clash).
Con los módulos de Python se cubren los dos objetivos:
- Son una manera de organizar código

- Se reduce la posibilidad de colisión de nombres y contaminar el espacio de
nombres global.
Además de los módulos, Python incluye el concepto de paquetes. Un paquete es un

módulo de Python que contiene otros módulos y/o paquetes. La diferencia entre un
módulo y un paquete radica en que el paquete contiene un atributo __path__ que
indica la ruta en el disco duro donde está almacenado el paquete.
42
En Python, los archivos con extension.py son módulos, mientras que cualquier
directorio que contenga un archivo con el nombre __init__.py se convierte en un
paquete.
5.6 Sage
Sage (iniciales de Software for Algebra and Geometry Experimentation – Software

para Experimentación de Algebra y Geometría) es un entorno de cálculos
matemáticos de código abierto.
Mientras que la mayor parte de los entornos de cálculo matemático son entidades
independientes, SAGE provee algunos algoritmos por sí mismo y otros los toma de
otros entornos de cálculo matemático. Esta estrategia le permite a SAGE proveer de
múltiples entornos de cálculo matemáticos dentro de una arquitectura capaz de
evolucionar para satisfacer futuras necesidades.
SAGE está escrito Python y el lenguaje de programación orientado a las matemáticas

que SAGE hace disponible a los usuarios, es una extensión de Python (J.L Tábara
2009).
5.6.1 Características de Sage
 Una línea de comandos basada en texto usando iPython
 El lenguaje de programación Python, soporta expresiones en programación

orientada a objetos y funcional.
 Cálculo usando Maxima y SymPy
 Álgebra lineal numérica usando GSL, SciPy y NumPy
43
 Control interactivo de los cálculos
 Librerías de funciones elementales y especiales
 Gráficas en 2D y 3D tanto de funciones como de datos.
 Herramientas de manipulación de datos y matrices.
 Librerías de estadística multivariable
 Una caja de herramientas para añadir interfaces de usuario a cálculos y

aplicaciones
 Herramientas para procesamiento de imágenes usando pylab así como

Python
 Herramientas para visualizar y analizar gráficas
 Librerías para funciones de teoría de números
 Filtros para importar y exportar datos, imágenes, vídeo, sonido, CAD, y GIS
 Soporte para números complejos, aritmética de precisión arbitraria, y

computación simbólica de funciones donde esto sea apropiado.
 Interfaces a otro software como Mathematica, Magma y Maple, que le

permite a los usuarios combinar software y comparar resultados y
desempeño.
44
5.6.2 Paquetes incluidos en Sage
Álgebra GAP, Maxima, Singular
Álgebra lineal Linbox, IML
Álgebra lineal numérica GSL, SciPy, NumPy
Aritmética de precisión arbitraria GMP, MPFR, MPFI, NTL
Cálculo Maxima, Sympy
Combinatoria Symmetrica, MuPAD-Combinat
Geometría algebraica Singular, Macaulay2
Geometría aritmética PARI, NTL, mwrank, ecm
Gráficos Matplotlib, Tachion3d
Teoría de grafos NetworkX
Teorías de grupos GAP
Tabla: 1: Paquetes incluidos en SAGE
45
6 Implementación
El objetivo de esta etapa es desarrollar una aplicación software, que pueda ser
ejecutada correctamente cumpliendo con los criterios especificados en las fases de
análisis y diseño. La dificultad reside en cómo realizar esta implementación de la
mejor manera posible, ya que va a depender de factores como el lenguaje de
programación, la metodología empleada y el entorno de desarrollo establecido.
6.1 Descripción del simulador
Este software se encargará de simular el comportamiento y el impacto de un

conjunto de trenes a lo largo de una línea, de forma general, para cualquier escenario
que se pretenda definir, analizando el impacto sobre la demanda de pasajeros.
Dada una línea genérica, las dos direcciones de movimiento de vehículos serán
arbitrariamente definidas como UP (sentido ascendente) y DW (sentido
descendente).
Cada escenario se define a partir de una descripción de la línea, que básicamente se

reduce a un fichero CSV con las distancias de los segmentos, otro fichero con la matriz
de demandas de pasajeros correspondiente a un cierto intervalo temporal y un
conjunto de variables globales que permiten definir características generales de la
línea.
Opcionalmente, se podrán añadir dos ficheros CSV, el primero contiene los horarios
de salida y llegada de cada tren (si se desea simular un horario específico), así como
las estaciones de salida y llegada de los trenes, e incluso aquellas estaciones en las
que un tren no tenga programada una parada (aplicable al modo 2 de simulación) y
un segundo fichero que contiene las estaciones en las cuales los trenes no realizan
46
parada cuando se desea simular una estrategia skipping-stop (aplicable a los modos
de simulación 0 y 1).
6.2 Parámetros del simulador
ENTRADAS
- Fichero de demandas
- Fichero de distancias
- Fichero de horarios
- Variables globales
SALIDAS
- Fichero de resultados
- Graficas de resultados
Figura 2: Diagrama UML entradas, salidas
6.2.1 Parámetros de entrada
Modo:
Escogemos el modo en el que realizaremos la simulación.
- Modo 0: Generación de un horario regular dentro del horizonte de

planificación.
47
- Modo 1: Generación de un horario regular, incluyendo trenes que

comiencen con anterioridad al inicio del horizonte de planificación. El
objetivo de este modo es el de suavizar el impacto de la demanda en
primeros y últimos trenes del horizonte de simulación.
- Modo 2: Carga de un horario específico desde un fichero externo.
NumEst:
Número de estaciones.
TrenCap:
Capacidad de un tren en plazas.
HeadwayUp:
Intervalo de tiempo entre cada par de trenes en sentido UP medido en minutos.
HeadwayDw:
Intervalo de tiempo entre cada par de trenes en sentido UP medido en minutos.
HorPlan:
Horizonte de análisis en minutos.
TrenSpeed:
Velocidad media de los trenes en km/hora.
DwellTime:
Tiempo de parada en cada estación para subidas y bajadas de viajeros expresado en

minutos. Aplicable a los modos de simulación 0 y 1.
DisDataFile.txt:
48
Fichero CSV donde escribimos las distancias entre estaciones. Los datos van
expresados en metros y separados por (;)
Ejemplo del fichero:
Tabla 1: Fichero de distancias entre estaciones
Este ejemplo será válido para el caso de tener 7 estaciones y los datos serán
almacenados en un array de dimensión i  6 i  0,5 / i  donde el elemento i se
corresponde con la distancia entre las estaciones i, i  1
MatDataFile.txt:
Fichero CSV donde escribimos la demanda de viajeros entre cada par de estaciones.
Este fichero tendrá forma de matriz cuadrada de dimensión ¡*j, donde el elemento ij
se corresponde con el número de pasajeros que se van a desplazar entre las
estaciones i y j.
Si i>j, el elemento hace referencia a la demanda correspondiente a trenes que

viajarán en sentido ascendente (Up) pero por el contrario si i<j la demanda se refiere
a los trenes que se desplazan en sentido descendente (Down).
La diagonal principal correspondiente a los elementos (i,j), i=0…NumEst-1, será cero

ya representa la demanda de pasajeros entre una estación y ella misma.
49
Ejemplo del fichero CSV:
Tabla 2: Fichero de demanda de pasajeros
Horario.txt:
En caso de que se desee imponer un horario cualquiera sobre la línea, (simulando

en modo 2) será posible proveer este horario específico a partir de un fichero CSV.
El primer elemento de la primera fila se corresponde con el número de trenes que

viajan en sentido Up, mientras que el segundo elemento de la misma fila nos indica
el número de trenes que viajan en sentido Dw.
Cada una de las filas restantes define los tiempos de salida y llegada de cada tren a
cada una de las estaciones.
Los tiempos de paso de cada tren por las estaciones se escriben por orden,
escribiendo primero los trenes asociados al sentido Up y posteriormente los
asociados al sentido Dw. El número de columnas es dos veces el de estaciones, ya
que en cada estación se indica el tiempo de llegada y el de salida de cada tren.
𝑁º𝐹𝑖𝑙𝑎𝑠 = 1º𝑓𝑖𝑙𝑎 + 𝑁º𝑡𝑟𝑒𝑛𝑒𝑠𝑈𝑝 + 𝑁º𝑡𝑟𝑒𝑛𝑒𝑠𝐷𝑤
𝑁º𝐶𝑜𝑙𝑢𝑚𝑛𝑎𝑠 = 2 ∗ 𝑁º 𝐸𝑠𝑡𝑎𝑐𝑖𝑜𝑛𝑒𝑠
50
El fichero CSV tendrá el siguiente formato:
Tabla 3: Fichero de tiempos para la simulación del modo 2
La primera fila nos indica que en el trayecto tendremos 4 trenes que se desplazan en
sentido Up y 2 que se desplazan en sentido Dw.
Las filas 1,2, 3 y 4, corresponden a los trenes en sentido Up, mientras que las filas 5
y 6 representan los trenes que viajan en sentido DW.
Tenemos cuatro tipos de valores negativos:
- -1: El tren realizará la parada en la estación en un instante anterior al

comienzo del espacio temporal (t<0).
- -3: Indica que el tren pasará de largo por dicha estación sin realizar parada.
- -4: El tren no va a iniciar su recorrido en la estación 0.
- -5: Indica que el tren no va a finalizar su trayecto en la última estación.
Por ejemplo, el primer tren en sentido Up correspondiente a la fila 1, sale desde la

estación origen (estación 0) para t<0 (indicado con un -1) llega a la estación 1 en t =
2 min, realiza una parada de 2min y sale de la misma en t=4min, posteriormente llega
a la estación 2 en t=10 min y sale de esta en t = 12 min, para finalmente llegar a la
estación 3 en t = 20 min donde bajarán todos los pasajeros, ya que nos encontramos
51
en el final del trayecto por lo que en t=22min se cierran las puertas y finaliza el
servicio.
La fila 6, correspondiente al último tren en sentido Dw, nos estaría indicando que
este tren inicia su trayecto en la estación 2 para t = 20 min, y finaliza el mismo en la
estación 1 para t = 32 min.
El siguiente fichero correspondiente a saltos.txt, será únicamente necesario para los

modos de simulación 0 y 1, dando la posibilidad de que existan trenes que pasen de
largo por las estaciones seleccionadas, sin necesidad de realizar las paradas propias
de un horario regular completo.
El fichero saltos.txt, se corresponde con una matriz donde cada fila representa un
tren, comenzando por los trenes en sentido UP y seguido de los trenes en sentido
DW, por lo que inicialmente será necesario realizar la simulación sin incluir este
fichero para saber el número de trenes que viajan en cada sentido.
Las estaciones se representan en cada una de las columnas de la matriz.
𝑁º𝐹𝑖𝑙𝑎𝑠 = 𝑁º𝑇𝑟𝑒𝑛𝑒𝑠𝑈𝑝 + 𝑁º𝑇𝑟𝑒𝑛𝑒𝑠𝐷𝑤
𝑁º𝐶𝑜𝑙𝑢𝑚𝑛𝑎𝑠 = 𝑁º𝐸𝑠𝑡𝑎𝑐𝑖𝑜𝑛𝑒𝑠
Hay que rellenar con un ‘1’ aquellas posiciones de la matriz, en las cuales un tren no
va a realizar parada en una estación, si por el contrario ponemos un ‘0’, el tren
realizará la parada programada.
52
Tabla 4: Fichero de saltos para simulación de modos 0 y 1
Este fichero se corresponde con un ejemplo en el cual tenemos 4 trenes en sentido

Up y 3 trenes en sentido Dw, por tanto, se puede observar como la matriz de saltos
está compuesta por 7 filas, (0….6) y 6 columnas, (0….5) correspondientes al número
de estaciones.
De aquí es fácil interpretar que el segundo tren en sentido Up (segunda fila), no

realiza parada en la estación 1 y que el tren 0 en sentido Dw, no realiza parada en las
estaciones 1 y 2.
Como restricciones ningún tren nunca podrá realizar saltos, ni en la estación origen
ni en la estación destino.
Modo de simulación de demanda:
Para cada modo de simulación, el simulador ofrece posibilidad de simular funciones

continuas de demanda o de matrices estáticas.
a) Matrices estáticas: La demanda de pasajeros se va a distribuir de

manera uniforme a lo largo del periodo de análisis. Las pruebas
realizadas en la fase de simulación se corresponden con este modo de
distribución de demanda.
53
En la siguiente Figura (Figura 3) se ha representado la llegada de pasajeros a una

estación, para un horizonte temporal de 50 min y con un intervalo de tiempo de
salida de trenes (Headway) de 5min. Analizando la gráfica puede observar como el
número acumulado de pasajeros llegados se traduce por una función lineal
dependiente del tiempo.
Figura 3: Función de demanda calculada a partir de matrices estáticas
b) Funciones continúas de demanda: La demanda de pasajeros en este

caso va a ser una función continua que se aproxima por la
superposición de funciones sigmoides.
N 1 kn,ij
f (tij )     n ,ij ( t tn ,ij )
i, j  [0, NumEst  1]
n 0 1 e
54
o ki : Constante.
o  i : Pendiente de la sigmoide.
o t i : Desplazamiento en el horizonte temporal de análisis.
En cada estación la llegada de pasajeros se va a aproximar por la superposición de N

funciones sigmoides. Para realizar esta aproximación va a ser necesario cargar un
fichero CSV (“_kbx.txt”_) que va a contener los valores (kij , ij , tij ) de cada par de
estaciones (i, j )i  j .
En el ejemplo siguiente se consideran tres sigmoides (N=3). El fichero CSV va a

contener tres matrices por cada sigmoide introducida y cada una de ellas con sus
respectivos valores (kij , ij , tij ) ). De acuerdo con esto, el fichero en este ejemplo va
a estar compuesto por 9 matrices que representan las funciones sigmoide de
demandas de pasajeros llegados, entre cada par de estaciones.
100
- f1,03 (t )  t  [0,90]
1  e0.3(t  20)
150
- f 2,03 (t )  t  [0,90]
1  e0.8(t 50)
120
- f3,03 (t )  t  [0,90]
1  e0.3(t 70)
- FT ,03  f1,03 (t )  f 2,03 (t )  f3,03 (t )t [0,90]
55
Figura 4: Función continúa de demanda calculada a partir de sigmoides.
6.2.2 Parámetros de salida
Fichero resultados.txt que contiene lo siguientes parámetros:
 Perfil de carga directo.

 Perfil de carga reverso.
 Instantes de llegadas y salidas de los trenes a cada estación.
 Personas que llegan.
 Personas que suben.
 Personas que bajan.
 Personas que llegan y tienen que esperar.
 Personas que esperaban anteriormente.
 Plazas libres.
 Plazas ocupadas.
 Porcentaje de demanda atendida.
 Porcentaje de ocupación.
 Tiempos medios de esperas.
56
 Porcentajes de ocupaciones.
 Porcentajes de demandas atendidas.
Gráfica 1 (Diagrama espacio-tiempo):
Representa las estaciones en el eje ‘x’ y el tiempo en minutos en el eje ‘y’ y muestra
las trayectorias de los trenes que se desplazan en ambos sentidos con los tiempos de
llegada y salida desde cada una de las estaciones.
Gráfica 2 (Llegadas y esperas):
En esta gráfica representamos las plazas ocupadas, el número de personas que

llegan, los pasajeros que suben, los pasajeros que bajan y los que quedan a la espera
del siguiente tren.
Se representa una sub-gráfica para cada tren con la ocupación en función de las
estaciones.
Gráfica 3 (Demanda atendida y ocupación):
Cada tren se corresponde con cada una de las sub-gráficas y representa el porcentaje
de demandas atendidas y el porcentaje de ocupación en cada estación.
57
Gráfica 4 (Tiempos medios de espera por estación):
En la gráfica 4 se representa una sub-gráfica para cada estación en cada una de las
cuales se mostrará el tiempo de espera para cada uno de los trenes.
Gráfica 5 (Resultados medios por tren):
Esta gráfica representa los valores estadísticos medios, en tres sub-gráficas

diferentes.
 La primera se corresponde con los tiempos medios de espera.
 La segunda representa el porcentaje de ocupación medio para cada tren.
 La última gráfica ilustra el porcentaje medio de demanda de pasajeros

atendidos para cada tren.
6.3 Modos de simulación
La función más importante del simulador, es aquella que se encarga de la creación

de objetos tipo horario. Esta se implementa mediante métodos de la clase Timetable.
El simulador incorpora tres formas diferentes de crear horarios (objetos “timetable”)

en función de los cuales gestionará el transporte ferroviario sobre la línea de estudio.
6.3.1 Modo 0
En este modo, el objeto timetable recibe como parámetros de entrada, el fichero que
contiene la distancia entre cada par de estaciones, el fichero que contiene la matriz
58
de demandas de pasajeros y un fichero opcional de saltos, por si se desea que uno o

varios trenes no realicen parada en alguna estación.
La velocidad del tren, es otra de las variables pasadas al simulador. En este modo se
calcula el tiempo que tarda cada tren, en llegar a cada una de las estaciones y por
consiguiente, el tiempo total que tardaría este, en recorrer la línea completa.
𝑁𝑢𝑚𝐸𝑠𝑡−1
𝑇𝑖𝑒𝑚𝑝𝑜𝑇𝑜𝑡𝑎𝑙 = 𝑉𝑒𝑙𝑜𝑐𝑖𝑑𝑎𝑑 ∗ ∑ 𝐷𝑖𝑠𝑡𝑎𝑛𝑐𝑖𝑎(𝑖)

𝑖=0
Donde 𝐷𝑖𝑠𝑡𝑎𝑛𝑐𝑖𝑎(𝑖) es la distancia entre las estaciones i e i+1
Gracias a la matriz de demandas de pasajeros y unos sencillos cálculos, se puede

deducir el número de pasajeros que se encuentran en cada estación durante todo el
horizonte temporal.
En el caso de una matriz de demandas de pasajeros compuesta por tres estaciones,

se realiza el siguiente cálculo.
NumEst 1 NumEst  2
0 X 01 X 02 PerfilC arg aDirecto  [ j 1
X0 j , j 0
X i 2 , 0]
X 10 0 X 12 NumEst 1 NumEst  2
X 20 X 21 0 PerfilC arg a Re verso  [0, 
i 1
X i0 , 
j 0
X2 j ]
Posteriormente, se realiza el cálculo del número de trenes que recorrerán cada una
de las estaciones en ambos sentidos. Este modo a diferencias de los modos 1 y 2, no
considera la posibilidad de que se existan trenes en movimiento anteriores al inicio
del intervalo temporal (HorPlan), es decir, el primer tren siempre parte de la estación
0 para t>=0.
A partir de esto, se obtiene el número de trenes que viajarán en cada sentido, de

forma que vaya saliendo un tren desde la estación origen cada Headway minutos.
𝑁𝑢𝑚𝑇𝑟𝑒𝑛𝑒𝑠𝑈𝑝 = (𝐻𝑜𝑟𝑃𝑙𝑎𝑛 − 𝐷𝑒𝑠𝑓𝑈𝑝)/𝐻𝑒𝑎𝑑𝑈𝑝
59
𝑁𝑢𝑚𝑇𝑟𝑒𝑛𝑒𝑠𝐷𝑤 = (𝐻𝑜𝑟𝑃𝑙𝑎𝑛 − 𝐷𝑒𝑠𝑓𝐷𝑤)/𝐻𝑒𝑎𝑑𝐷𝑤
La capacidad de los trenes en ambos sentidos, puede ser establecida de dos formas
diferentes.
a) El primer método consiste en pasarle al simulador la capacidad como

parámetro, por lo que funcionará como una constante de la cual
depende la satisfacción de la demanda.
A la hora de escoger este parámetro, hay que prestar especial atención

a la matriz de demandas de pasajeros, ya que si escogemos un valor
demasiado bajo, las esperas van a ser elevadas y a causa de esto el
porcentaje de demanda de pasajeros atendidos rozará valores
mínimos.
Por el contrario si la capacidad escogida es muy superior a la nominal,

aseguraremos una demanda de pasajeros atendidos del 100%, no
obstante el porcentaje de ocupación será bajo y la gestión de la
planificación habría sido pésima.
b) El segundo método para calcular la capacidad, sería igualarla al valor

máximo del vector ‘Perfil_de_Carga’.
60
Capacidad1=max (PerfilCargaDirecto)
Capacidad2=max (PerfilCargaReverso)
No
If Capacidad1>Capacidad2 TrenCap=Capacidad2
Si
TrenCap=Capacidad1
Exit
Diagrama de flujo 1: Calculo de la capacidad del tren
Este método presenta el mismo inconveniente que pasarle al simulador una

capacidad alta como parámetro y por lo tanto volverá a haber una demanda
atendida del 100%, mientras que el porcentaje de ocupación sería mínimo, o lo que
es lo mismo tendríamos un elevado número de plazas libres.
El caso 0 se corresponde con la figura 3, donde queda reflejado que todos los trenes
salen desde la estación cero y que el primer tren en salir se produce para un tiempo
t=Desfase inicial.
Por otro lado queda reflejado el momento de llegada de cada tren a cada una de las
estaciones, y su posterior salida. El diferencial de tiempo entre la llegada a una
estación y la salida de la misma, se corresponde con el valor de DwellTime, que es
pasado como parámetro al simulador.
En ambas gráficas se puede dar el caso de que uno o más trenes excedan el espacio
temporal en un momento dado.
61
La primera gráfica de la figura 3 se corresponde con los trenes que viajan en sentido
UP, los cuales parten siempre desde la estación 0, mientras que la segunda ilustración
representa los trenes que viajan en sentido Dw y estos a diferencia de los anteriores,
parten desde la última estación hasta finalizar su trayecto en la estación 0.
En esta gráfica se puede observar que el espacio temporal trabajo será de 40 minutos
y como el tren 3 en ambos sentidos excede este tiempo.
Figura 5: Ejemplo de trayectoria de trenes, modo 0
6.3.2 Modo 1
Al igual que en el modo anterior, en este modo, el simulador exigirá como parámetros
de entrada el fichero de distancias entre estaciones contiguas, el fichero de
demandas de pasajeros, fichero opcional de saltos y algunos parámetros globales.
De la misma forma a partir del número de estaciones pasado como parámetro y el

fichero de distancias entre estaciones contiguas, se realiza el cálculo para obtener el
tiempo que tarda cada tren en realizar el trayecto completo.
62
𝑁𝑢𝑚𝐸𝑠𝑡−1
𝑇. 𝑉𝑖𝑎𝑗𝑒𝑇𝑜𝑡𝑎𝑙 = 𝑉𝑒𝑙𝑜𝑐𝑖𝑑𝑎𝑑 ∗ ∑ 𝐷𝑖𝑠𝑡𝑎𝑛𝑐𝑖𝑎(𝑖 )

𝑖=0
Donde 𝐷𝑖𝑠𝑡𝑎𝑛𝑐𝑖𝑎(𝑖) es la distancia entre las estaciones i e i+1.
A partir de la matriz de demandas de pasajeros, se obtienen los perfiles de cargas

directo y reverso:
NumEst 1 NumEst  2
0 X 01 X 02 PerfilC arg aDirecto  [ j 1
X0 j , j 0
X i 2 , 0]
X 10 0 X 12 NumEst 1 NumEst  2
X 20 X 21 0 PerfilC arg a Re verso  [0, 
i 1
X i0 , 
j 0
X2 j ]
La principal diferencia con respecto al modo anterior, se nos presenta a la hora de

calcular el número de trenes, ya que en este modo, se consideran trenes dentro del
horizonte temporal que hayan salido desde la estación 0, antes del instante inicial de
simulación, lo que dará lugar a que en t=0 pueda producirse el cruce de uno o más
trenes, por estaciones superiores a la cero.
𝐻𝑜𝑟𝑃𝑙𝑎𝑛 − 𝐷𝑒𝑠𝑓𝑈𝑝
𝑁𝑢𝑚𝑇𝑟𝑒𝑛𝑒𝑠1 =
𝐻𝑒𝑎𝑑𝑈𝑝
𝑇. 𝑉𝑖𝑎𝑗𝑒𝑇𝑜𝑡𝑎𝑙
𝑁𝑢𝑚𝑇𝑟𝑒𝑛𝑒𝑠2 =
𝐻𝑒𝑎𝑑𝑈𝑝
𝑁𝑢𝑚𝑇𝑟𝑒𝑛𝑒𝑠𝑈𝑝 = 𝑁𝑢𝑚𝑇𝑟𝑒𝑛𝑒𝑠1 + 𝑁𝑢𝑚𝑇𝑟𝑒𝑛𝑒𝑠2
El cálculo del número de trenes en sentido DW, se realizará de igual manera. De este
modo, el número de trenes será la suma de los trenes que salieron para t<0, más el
número de trenes que salen para t>0 cada Headway minutos.
Para la capacidad de los trenes se procede de la misma forma que en caso anterior,
tenemos la opción de pasarla como parámetro de entrada, o de fijarla al valor
máximo del vector ‘Perfil_de_Carga’.
63
La figura 4 muestra el funcionamiento del simulador para el modo 1, separando la

circulación de los trenes en ambos sentidos y mostrando los tiempos de parada y
salida de estos, en cada estación.A excepción del caso anterior, se puede observar
como en el gráfico correspondiente a los trenes en sentido Up, el tren 0 salió de la
estación origen en un tiempo t<0 y como para t≈0, este tren se encuentra llegando a
la estación 1.
Lo mismo ocurre para los trenes en sentido DW donde el tren 0 sale de la estación 3
en t<0 y para t≈0, éste llega a la estación 2.
Para este tipo de casos, dado que se desconoce la demanda fuera del intervalo de
planificación, la ocupación será pasada como parámetro de entrada al simulador y se
considera por igual para todos los trenes afectados por esa situación.
Figura 6: Ejemplo de trayectoria de trenes modo 1
64
6.3.3 Modo 2
Este modo difiere de los anteriores en un aspecto fundamental y es que el simulador

no va a recibir como parámetro de entrada el fichero de distancias entre estaciones,
ya que se le especificará un objeto Timetable a partir de un fichero externo. Este
fichero almacena el número de trenes que se desplazan en cada sentido y un horario
con los tiempos de parada y salida de cada tren desde cada una de las estaciones.
Adicionalmente a lo descrito en el modo 1, el modo2 añade una función adicional

que estará presente cuando un tren no tenga programado realizar el trayecto
completo, permitiendo así la simulación de horarios con servicios especiales y
estrategias de aceleración (por ejemplo Short-Turning). En este caso no será
necesario que el tren parta desde la estación origen, o que tenga que finalizar su
trayecto en la última estación, pudiendo realizar la programación del trayecto de
diversas formas.
Dado que se fijan los instantes de llegada y salida en cada estación, los trenes pueden
variar su velocidad a lo largo de la línea.
Por tanto en este modo de simulación, ya no tendremos un espacio temporal de

trenes equiespaciados cada Headway minutos sino que la distribución de trenes en
el espacio y tiempo, viene definida en cada fichero Timetable que se defina.
Los tiempos de desfase inicial en ambos sentidos y el DwellTime (tiempo de parada

en cada estación) tampoco se tendrán en cuenta en este modo, ya que de nuevo este
dato será proporcionado por el fichero de tiempos.
La capacidad de cada tren se definirá de la misma forma que los casos anteriores.
En la figura 5 podemos ver claramente el funcionamiento del modo 2 de simulación.

Se aprecia como los trenes varían su velocidad a lo largo del trayecto.
Haciendo un análisis de los tiempos para el tren 1 en sentido UP obtenemos la

siguiente tabla:
65
Estaciones Distancias Tiempo Velocidad

0-1 2345m 2 min 70.35 Km/h
1-2 1234m 2 min 37.02 km/h
2-3 3500m 4 min 52.25 km/h
Tabla 5: Análisis de velocidades para el tren 1, en el ejemplo de simulación del modo 2
En función de la tabla 5, se puede ver claramente como el tren 1 en sentido Up, irá
variando su velocidad a lo largo de su paso por las diferentes estaciones. Esta
situación también se va a producir para el resto de trenes en ambos sentidos.
También se puede ver en las dos gráficas de la figura 5, que hay tantos trenes que
salen desde estación origen en t<0, como trenes que sobrepasan el espacio temporal
y como mencionamos anteriormente, los trenes incompletos una vez sobrepasan la
barrera de t=0, llevaran un cierto porcentaje de ocupación predefinido como
parámetro de entrada.
En los trenes que sobrepasan el espacio temporal (t>HorPlan), todos los pasajeros se
verán obligados a bajar en la última estación en que dicho tren realice una parada,
en consecuencia los pasajeros que viajen en el tren 4 en sentido UP, únicamente
podrán bajar en la estación 1, esto significa, a efectos de simulación, que no se
permitirá la subida al tren de pasajeros con destinos posteriores a la estación 1.
En este modo de simulación, también es posible gestionar desplazamientos

especiales de trenes, de forma que ciertos trenes puedan saltar su parada en algunas
estaciones.
Esto se puede observar entre otros, en el tren 2 desplazándose en sentido UP, el cual
no va a realizar la parada pertinente en la estación 1, o también en el caso del tren 3
desplazándose en sentido DW que tampoco va a realizar parada en la estación 1.
66
Figura 7: Ejemplo trayectoria de trenes, modo 2
67
7 Evaluación de la implementación
7.1 Introducción al entorno de pruebas
En la evaluación de la implementación utilizada, se ha optado por la realización de

pruebas en los diferentes modos de simulación, de esta forma se puede ver tanto
numéricamente como gráficamente la evolución de cada tren en cada estación en
tanto y en cuanto a número de pasajeros, plazas libres, tiempos medios de espera
por pasajero y por estación, demandas atendidas, tiempos de llegadas, tiempos de
salidas y algunos parámetros más.
En la realización de las pruebas se buscará llevar el simulador al límite, para poder

evaluar correctamente su comportamiento ante situaciones extremas, como pueden
ser desbordamientos en las esperas o en la matriz de demandas de pasajeros, de esta
forma evitaremos comportamientos extraños durante el funcionamiento del mismo.
7.2 Pruebas realizadas y resultados
En este apartado, las pruebas se van a realizar en función de los modos de simulación,
mostrando todos los resultados obtenidos a lo largo de cada una de las trayectorias
de los trenes y de esta formar evaluar las diferencias presentes entre los 3 modos de
simulación.
7.2.1 Prueba modo de simulación 0
Esta simulación se ha realizado con la creación de un objeto horario (Timetable) de

acuerdo a la siguiente sentencia:
68
Timetable (0, ' ', 8, 10, 60, 8, 10, 0)
 Modo de simulación cero.

 HeadwayUP (espaciado entre trenes en sentido UP en min) = 8min
 HeadwayDW (espaciado entre trenes en sentido DW en min) = 10min
 Velocidad del tren = 60 km/h
 Desf1 (desfase inicial en sentido UP) = 8 min
 Desf2 (desfase inicial en sentido DW) = 10 min
 La capacidad de cada tren será fijada en 400 plazas
 Ficheros de distancias y matriz de demandas correspondientes a 6 estaciones:
Tabla 6 Matriz de demandas de pasajeros entre cada par de

estaciones modo 0
Tabla 7 Array de distancias entre

estaciones modo 0
Después de introducir todos los parámetros procedemos a ejecutar la simulación. La

primera gráfica mostrada, es la correspondiente a la figura 6. Se trata de una
reproducción de las trayectorias seguidas por cada uno de los trenes, con los tiempos
de llegada y salida desde cada estación.
A simple vista se puede ver como en sentido UP viajarán 4 trenes mientras que en
sentido DW únicamente viajarán 3, esto es debido a que tanto el desfase inicial como
69
el Headway, son mayores en sentido DW y como consecuencia de esto, para un

espacio temporal fijado en 40min, podremos representar mayor número de trenes
en sentido UP.
Por otro lado podemos observar cómo el tren 2 y el tren 3 en sentido UP y el tren 2
en sentido DW, son trenes incompletos que no van a realizar el trayecto completo.
En este caso en sentido UP, el tren 2 se va a desplazar entre las estaciones 0 y 4,
mientras que el tren 3 lo hará entre las estaciones 0 y 2. Para el sentido DW, el tren
2 se va a desplazar entre las estaciones 5 y 3.
También debemos tener en cuenta que todos los trenes realizan el mismo trayecto a
la misma velocidad, no obstante la distancia entre cada par de estaciones no tiene
por qué coincidir (en la Figura 6, las estaciones aparecen equiespaciadas, de ahí que
aparentemente los trenes estén realizando trayectos a diferente velocidad. Sin
embargo, esto no es así, todos los trenes se mueven a la misma velocidad en todos
los segmentos).
Figura 8: Trayectorias de trenes modo 0
En la siguiente figura se pretende representar la ocupación que presenta cada tren

en el transcurso de su viaje, así como el número de personas que suben, bajan o
quedan a la espera del siguiente tren por motivos de espacio o simplemente porque
el tren no parará en la estación deseada.
70
Analizando la figura 7 correspondiente a los trenes en sentido UP, vemos que para el
tren 0 en la primera estación, se subirán todos los pasajeros (197) y si recordamos
los parámetros pasados al simulador la capacidad de los trenes quedó fijada en 400
plazas.
En la estación 1 bajarán 90 personas y subirán todos los pasajeros llegados, alcanzado

una ocupación de 383 plazas.
En la estación 2 se producirá el primer desbordamiento ya que le número de

pasajeros llegados menos el número de pasajeros bajados supera la capacidad del
tren, por lo que unos 180 pasajeros tendrán que quedar a la espera del próximo tren.
En la estación 3, disminuirá el número de esperas aunque seguimos manteniendo

una ocupación máxima, mientras que en la estación 4 subirán todos los pasajeros que
llegan y no se producirá ninguna espera.
Finalmente el tren 0 acabará su recorrido en la estación 5 donde bajarán todos los

pasajeros.
El tren 1 se desarrollará de forma similar, aumentando el desbordamiento en la

estación 2, porque ahora, a parte de satisfacer la gran demanda de pasajeros
llegados, también se cuenta con un gran número de pasajeros que no pudieron coger
el tren anterior y quedaron a la espera del siguiente tren.
En el caso de los trenes 2 y 3, se producen esperas en las estaciones 0, 1 y 3, debido

a que estos trenes no realizan el trayecto completo, por lo que habrá personas que
queden a la espera de otro tren, que los pueda transportar a las estaciones 4 y 5.
En el tren 3 queda reflejado el resultado de la acumulación de esperas en las

restantes estaciones, una vez finalizado el espacio temporal de análisis.
Cuando en una estación hay esperas previas, estos pasajeros llevarán preferencia a
la hora de subir a un tren, sobre los pasajeros que lleguen nuevos.
71
Figura 9: Trasvase de pasajeros entre estaciones sentido Up, modo 0
La gráfica 8 muestra los mismos resultados que la figura 7, a excepción de que en

este caso los trenes se desplazan en sentido contrario, es decir desde la estación 5
hasta la 0 (dirección DW).
La matriz triangular inferior de la matriz de demandas de pasajeros, se corresponde

con sentido DW y cómo podemos ver, la demanda de pasajeros en la estación 3, es
superior al resto de estaciones, por lo que será objeto de acumulación de pasajeros.
Para el tren 0 en la estación 5 suben todos los pasajeros que llegan, mientras que en
la estación 4, ya se producen 50 esperas, pero el problema recae sobre la estación 3,
donde el número de pasajeros que llegan es demasiado alto, dando lugar a que más
de 200 pasajeros queden a la espera del siguiente tren. En las estaciones 2 y 1 de este
mismo tren, aunque se mantiene una ocupación de casi el 100%, no se producen
esperas, dado que la demanda de pasajeros llegados es menor que en las estaciones
anteriores. Finalmente en la estación 0 bajarán todos los pasajeros.
El tren 1 va a experimentar una situación similar al tren 0, incrementando el número

de esperas en la estación 3, sin embargo en la estación 4 el número de esperas
disminuye con respecto al tren anterior.
El tren 2 es un caso especial ya que al no realizar su trayecto completo, habrá muchas

personas que deseen ir a estaciones por las cuales este no pasará, y por tanto tendrán
que quedar a la espera del siguiente tren.
72
Figura 10: Trasvase de pasajeros entre estaciones sentido Dw, modo 0
En la siguiente figura (Figura 9) se representa las demandas atendidas, así como la

ocupación de cada tren en sentido UP.
Para el tren 0 en sentido UP, en su trayecto entre las estaciones 0-1, la demanda
atendida es máxima (100%) y el porcentaje de ocupación aumenta hasta alcanzar su
máximo en la estación 2, donde el porcentaje de demandas atendidas caerá hasta
casi el 40% como consecuencia de las esperas producidas.
La siguiente gráfica correspondiente al tren 1 en sentido Up, se puede ver como la

ocupación en la estación 2 se incrementa hasta un 100%, dado que la demanda de
pasajeros llegados durante las primeras estaciones es elevada. En esta estación se
producirá un gran número de esperas, provocando una caída en el porcentaje de
demandas atendidas, no obstante para las estaciones 3 y 4, este porcentaje se va a
incrementar al 100%, ya que el número de pasajeros llegados será menor y por tanto
habrá una pequeña caída en el porcentaje de ocupación.
Como comentamos anteriormente, el tren 2 y el tren 3, no van a realizar su trayecto

completo dentro del horizonte temporal de análisis, por lo que esta situación dará
lugar a un incremento en el número de esperas, bajo porcentaje de ocupación y por
supuesto bajo porcentaje de demandas atendidas.
73
Figura 11: Ocupación y de demanda atendida en sentido Up, modo 0
La Figura 10 representa el porcentaje de demandas atendidas, así como la ocupación

de cada tren para el sentido DW.
El tren 0, presenta una ocupación del 100% durante todo el recorrido a excepción de
la primera estación (estación 5), donde la ocupación es del 60%, sin embargo
podemos ver una caída abrupta del porcentaje de demanda atendida en la estación
3, debido al gran número de pasajeros llegados.
El tren 1 presenta un comportamiento similar, con una fuerte caída de la demanda

de pasajeros en la estación 3, mientras que el tren 2 presentará unos niveles muy
bajos tanto en su ocupación, como en su porcentaje de demandas atendidas debido
a su corta trayectoria dentro del espacio temporal de análisis.
74
Figura 12: Ocupación y de demanda atendida en sentido Dw, modo 0
Para la siguiente prueba hemos querido realizar un análisis de los tiempos medios de
retraso experimentados por los pasajeros en cada una de las estaciones, para de esta
forma poder hacer un estudio de cuáles son las estaciones más cargadas y poder así
ofrecer otras alternativas, como abrir nuevas servicios con paradas concretas con el
fin de disminuir los tiempos de espera.
La Figura 11 muestra 5 gráficas, correspondientes a las cinco primeras estaciones en

sentido UP, ya que el análisis de la sexta no va a ser necesario. En ella el tiempo de
espera va a ser cero debido a que al ser la última estación, es el final del trayecto y
por tanto todos los pasajeros bajan.
Para comenzar el análisis de dicha gráfica, podemos decir que los tiempos medios de
espera en la estación 0, son más o menos constantes dado que se corresponde con
los tiempos mínimos de espera.
1
𝑊𝑎𝑖𝑡𝑇𝑖𝑚𝑒 [𝑒𝑠𝑡] = ∗ (𝐿𝑒𝑎𝑣𝑒𝑇𝑖𝑚𝑒[𝑡𝑟𝑒𝑛, 𝑒𝑠𝑡] − 𝐿𝑒𝑎𝑣𝑒𝑇𝑖𝑚𝑒[𝑡𝑟𝑒𝑛 − 1, 𝑒𝑠𝑡]) + 𝑒𝑎𝑑[𝑡𝑟𝑒𝑛 − 1, 𝑒𝑠𝑡]
2
∗ (𝐿𝑒𝑎𝑣𝑒𝑇𝑖𝑚𝑒[𝑡𝑟𝑒𝑛, 𝑒𝑠𝑡] − 𝐿𝑒𝑎𝑣𝑒𝑇𝑖𝑚𝑒[𝑡𝑟𝑒𝑛 − 1, 𝑒𝑠𝑡])
WaitTime: Tiempo de espera en cada estación.
LeaveTime: Tiempo de salida desde cada estación.
Ead: Esperas acumuladas en cada estación.
75
est: Estación.
De acuerdo con la fórmula de la expresión anterior, vemos como el tren 0 sale de la

estación 0, en t = 9 min, por lo que el tiempo medio de espera por pasajero será de
4.5 min. También observamos, que el tren 0 a medida que va pasando por las
diferentes estaciones, va aumentando su tiempo de espera, situación que es normal
ya que los pasajeros comienzan a llegar a las diferentes estaciones para t >= 0 min
por lo que los pasajeros que lleguen en t=0 a la última estación tendrán que esperar
a que el tren 0 recorra todo el trayecto.
Para la estación 1 tendremos un comportamiento similar al de la estación 0, sin

embargo en la estación 2, ya se produce un aumento de los tiempos de espera, dado
que esta estación presentaba un gran número de pasajeros llegados.
Como puede comprobarse en la Figura 6 (trayectorias de los trenes para el modo de

simulación 0), tanto el tren 2 como el tren 3, no van a realizar parada en la estación
4, por lo que el tiempo medio de espera en esta estación va a ser nulo.
76
Figura 13: Tiempo medio de espera en cada estación y tren sentido UP modo 0
Las gráficas correspondientes a la Figura 12 (tiempos medios de espera, para los

trenes que viajan en sentido DW) se puede interpretar de manera simular, teniendo
en cuenta que ahora el recorrido será desde la estación 5 hasta la estación 0, por lo
que comenzaremos el análisis por la estación 5.
Como comentamos anteriormente, aquí también se va a verificar que el tren 0

aumenta el tiempo medio de espera a medida que recorre las diferentes estaciones.
También observamos como el desbordamiento de pasajeros en sentido Dw, se va a

producir en la estación 3, y esto queda claramente reflejado en la Figura 12, donde
el tiempo medio de espera en esta estación, será ligeramente superior a los tiempos
de espera en el resto de las estaciones.
Por último, también podemos ver reflejado en está Figura, como el tren 2, va a ser
un tren incompleto que iniciará su recorrido en la estación 5 y lo finalizará en la
77
estación 4, dando como resultado un tiempo de espera nulo en las estaciones 3,2 y
1.
Figura 14: Tiempo medio de espera en cada estación y tren sentido Dw, modo 0
La última gráfica de este modo de simulación (ver Figura 13), presenta los resultados
globales de cada línea de tren.
Si comenzamos analizando el tren 0 en sentido UP, vemos como este tendrá un

tiempo medio de espera por pasajero de 7.3 min frente a una ocupación del 84.1% y
un porcentaje de demandas de pasajeros atendidos del 82.6%. En base a estos datos
podemos decir que su tiempo medio de espera es ligeramente superior a la media
como ya se explicó anteriormente y en cuanto a demanda atendida y ocupación son
resultados bastante satisfactorios.
78
El tren 1 presenta un tiempo medio de espera bastante inferior al tren 0, y aunque

su porcentaje de ocupación es también algo inferior, presenta un porcentaje de
demanda atendida del 92.2%.
En el caso de los trenes 2 y 3, al ser trenes que no van a recorrer todas las estaciones,
van a presentar porcentajes de ocupación y demandas de pasajeros atendidos por
debajo de la media, por lo que se puede pensar en disminuir levemente el tiempo del
desfase inicial para conseguir mayor número de trenes que realicen las trayectorias
completas y así mejorar la calidad de la línea.
Para los trenes en sentido DW, se puede observar que el tren 0 como era de esperar,
presenta un tiempo de espera por encima de la media, no obstante tanto la
ocupación como la demanda atendida, son valores aceptablemente positivos.
El tren 1 en sentido DW, presenta unos valores positivos, en tanto y en cuento a su

tiempo de espera, porcentaje de ocupación y porcentaje de demandas atendidas,
mientras que el tren 2, al ser un tren incompleto (no va a realizar parada en todas las
estaciones), presentará los inconvenientes comentados anteriormente.
Figura 15: Valores medios para modo de simulación 0
79
7.2.1.1 Fichero de resultados para el modo de simulación 0
El simulador proporciona todos los resultados de forma numérica escribiendo un

fichero de reporte con los aspectos previamente comentados y con la siguiente
estructura:
80
81
82
83
84
85
7.2.2 Prueba modo de simulación 1
En esta simulación utilizamos parámetros similares al el caso anterior, pero en este

caso hemos incluido el fichero de saltos. Para la simulación, únicamente
representaremos las gráficas correspondientes a los trenes en sentido Up, dado que
el análisis correspondiente a los trenes en sentido Dw, se haría de forma similar.
La llamada a la clase timetable va a requerir los siguientes parámetros de entrada:
timetable (1,' ', 8, 10, 60, 8, 10, 0)
El primer parámetro se ha modificado, ya que ahora ejecutamos el modo de

simulación 1.
 Modo de simulación 1.
 HeadwayUP (espaciado entre trenes en sentido UP en min) = 8min
 HeadwayDW (espaciado entre trenes en sentido DW en min) = 10min
 Velocidad del tren = 60 km/h
 Desf1 (desfase inicial en sentido UP) = 8 min
 Desf2 (desfase inicial en sentido DW) = 10 min
 La capacidad de cada tren será fijada en 400 plazas
 El porcentaje de ocupación para trenes que salieron desde la estación origen
con anterioridad a t=0 va a ser del 50%.
 El porcentaje de ocupación para trenes que finalizan su trayecto antes de
llegar a la última estación será del 0%
 Ficheros de distancias y demanda de pasajeros correspondientes a 6
estaciones:
86
Tabla 8: Matriz de demandas de pasajeros entre cada par de

estaciones, modo 1
Tabla 9: Array de distancias entre

estaciones modo 1
 Fichero de saltos, donde hemos señalado que el tren 2 en sentido Up, no va

a realizar parada en la estación 1 y que el tren 3 en el mismo sentido, no va a
realizar parada en la estación 2.
Tabla 10 Fichero de saltos para modo de simulación 1
87
Con los datos introducidos ejecutamos la aplicación y procedemos a analizar los

resultados.
A diferencia del modo anterior y como se observa en la Figura 14, tenemos trenes
que salieron desde la estación origen en un instante anterior al comienzo de nuestro
intervalo temporal y gracias a esto, aunque continua habiendo trenes incompletos,
se dispone de un conjunto de servicios que cubren por completo el intervalo
temporal de análisis.
En concreto para los datos introducidos, tenderemos que el tren 0 únicamente

realizará una parada en la estación 5 dentro del intervalo temporal de análisis, por
tanto no va a intervenir en los cálculos ya que ningún pasajero tiene la posibilidad de
subir a dicho tren.
El tren 1, va a realizar su primera parada dentro de nuestro intervalo de análisis en la

estación 3 para un tiempo t = 2 min, por lo que únicamente va a recorrer las
estaciones 4 y 5 dentro del horizonte de trabajo.
El tren 2 va a pasar de largo por la estación 1 sin realizar parada (Salto), mientras que
el tren 3 recorrerá todas las estaciones a excepción de la 2 donde va a realizar un
Salto.
En función de los parámetros introducidos, hemos de recordar que los trenes

incompletos que aparecen en estaciones posteriores a la 0, para t>= 0 min,
presentarán una ocupación del 50%.Por otro lado vemos que, tanto los tiempos de
separación entre trenes, como el desfase inicial, se corresponde con los parámetros
introducidos.
Los trenes 5 y 6 exceden el espacio temporal de análisis antes de finalizar su trayecto,

por consiguiente, los pasajeros podrán viajar como máximo, hasta las estaciones 4 y
2 respectivamente.
Aunque los trenes 5 y 6 continúan después de parar en su última estación, estos van
a quedar fuera de nuestro horizonte de análisis y por tanto, el simulador solo va a
88
estudiar su comportamiento hasta la última estación disponible dentro de HorPlan

(en este caso se corresponde con 40min).
Figura 16: Trayectorias de trenes modo 1
La Figura 15, describe el conjunto de pasajeros en sentido UP, que llegan a una
estación, cuántos de ellos suben, cuantos bajan o los que quedan esperando al
siguiente tren por problemas de capacidad o porque el tren no para en dicha
estación.
Como vemos en la gráfica correspondiente al tren 0, este no presenta valor de

interés, ya que ningún pasajero tendrá la opción de subir a dicho tren, en cambio
como se ha establecido en los valores iniciales, su ocupación en las estaciones
anteriores al comienzo del horizonte temporal de análisis será del 50%.
El funcionamiento general de la gráfica ya se ha descrito anteriormente, no obstante

va a ser motivo de interés el primer salto producido por el tren 2 al pasar por la
estación 1, ya que este va a pasar de largo por dicha estación sin realizar parada.
89
A consecuencia de esto en la estación 0 del tren 2, va a haber un cierto número de

pasajeros que deseen viajar a la estación 1 y dado que este tren no tiene programada
esa parada en su trayecto, va a haber un porcentaje de personas que queden
esperando al siguiente tren.
El tren 3, siempre y cuando tenga capacidad disponible, recogerá en la estación 0

tanto a los pasajeros que llegan nuevos, como a los que quedaron esperando, que
tendrán privilegio sobre los anteriores.
El segundo salto producido por el tren 3 en la estación 2, dará lugar a esperas en las
estaciones 0 y 1 como consecuencia de los pasajeros que desean viajar a la estación
2.No obstante, debido a los saltos producidos, las llegadas de pasajeros aumentarán
tanto en la estación 1 para el tren 3, como en la estación 2 para el tren 4, dando lugar
a un aumento en las esperas de pasajeros de ambas estaciones.
En la gráfica correspondiente al tren 6 se puede observar el número de esperas

definitivas en cada estación después de finalizar el horizonte de análisis.
Figura 17: Trasvase de pasajeros entre estaciones sentido Up, modo 1
90
En la Figura 16, se representa el porcentaje de demandas atendidas de cada tren en

sentido UP, frente a su porcentaje de ocupación para cada una de las estaciones.
El tren 0 va a quedar fuera del espacio de análisis ya que no participa en la gestión de

pasajeros.
El tren 1 en su corto recorrido, tendrá una demanda de pasajeros atendidos del 100%
frente a un 60% de ocupación.
En esta figura también se aprecian el efecto producido por los saltos del tren 2 y del
tren 3 en las estaciones 1 y 2 respectivamente, donde se puede ver que la demanda
cae al 0%, mientras que la ocupación se mantiene constante, como consecuencia de
que no se detienen en las mencionadas estaciones, por lo que ningún pasajero podrá
subir o bajar del tren.
El porcentaje de ocupación en el resto de las estaciones para los trenes 2 y 3, no será

demasiado alto, no obstante mantenemos casi un 100% de demandas de pasajeros
atendidos en ambos trenes.
Los saltos introducidos van a provocar esperas en la estación 2 para el tren 4, que
quedarán reflejadas en una disminución de la demanda de pasajeros atendidos,
frente a un 100% de ocupación.
Los trenes 5 y 6 a causa de sus trayectorias incompletas, presentarán esperas en sus

estaciones, provocando bajos niveles de demandas atendidas y bajos porcentajes
ocupación.
91
Figura 18: Ocupación y demanda atendida, sentido Up y modo de simulación 1
La siguiente Figura (Figura 17), es muy aclarativa a la hora de apreciar las esperas de
pasajeros provocadas por los saltos de estaciones.
El primer salto, se produce en la estación 1, para el tren 2, por lo que si se observa la

Figura 17, segunda gráfica, se puede apreciar que en esa estación el tiempo medio
de espera es de 0 min, ya que al no parar el tren 2 en dicha estación, ningún pasajero
va a demandar ese tren. En cambio, esto dará lugar a una llegada de pasajeros extra
para el siguiente tren, que provocando que muchos pasajeros queden a la espera y
por tanto que el tiempo de espera se incremente a 6.2 min.
La misma situación se va a producir para el tren 3 en la estación 2 (donde realizará

un salto), originando una alta llegada de pasajeros para el siguiente tren (tren 4) y
dando nuevamente lugar, a una espera por pasajero de 8 min. No obstante, el resto
de tiempos de espera se mantienen en valores mínimos durante todo el trayecto.
92
Figura 19: Tiempo medio de espera, sentido UP, modo de simulación 1
Para analizar la Figura 18 correspondiente a los resultados globales de cada tren, se

va a comenzar por los tiempos medios de espera por pasajero.
Como ya se ha comentado en anteriores ocasiones, el tren 0 quedará fuera de

nuestro análisis, ya que este no participa en la gestión de los pasajeros.
El salto realizado por el tren 3 en la estación 1, dio lugar a una elevada llegada de
pasajeros al tren 4 en esta misma estación, lo que origino gran cantidad de esperas
dando como resultado un tiempo medio de espera por pasajero de 5.6 min en
dicho tren.
Con respecto a la ocupación, se puede decir que el porcentaje de ocupación del tren
2 es inferior a la media, situación evidente dado que este pasa por la estación 1 sin
realizar parada.
Para los trenes 3 y 4 la ocupación será más elevada, mientras que para los trenes 5 y
6, esta vuelve a disminuir ya que se trata de trenes incompletos.
93
La demanda atendida de pasajeros (gráfica 3) se mantiene casi al 100% para todos

los servicios, exceptuando aquellos trenes que no realizan el trayecto completo.
Figura 20: Valores medios para modo de simulación 1.
94

estructura:
95
96
97
98
99
100
101
7.2.3 Prueba de simulación modo 2
En este modo de simulación, vamos a incluir un fichero auxiliar con un horario

específico. La capacidad se sigue especificando como parámetro, en lugar de
calcularla con el perfil de carga.
Para realizar la simulación, la llamada al constructor del objeto timetable se realiza

como se muestra en la siguiente sentencia:
timetable (2,'horario_prueba2.txt ', 8, 10, 60, 8, 10, 0)
En la llamada vemos que todos los datos introducidos en la clase timetable, son
idénticos a los empleados, pero hay que tener en cuenta que en este modo de
simulación esos parámetros no tendrán ningún efecto, ya que los tiempos de salida
y llegada de cada tren vienen proporcionados por el fichero de horario que se desea
imponer sobre la línea, en el ejemplo “horario_prueba2.txt”. Por tanto el simulador
únicamente recogerá el parámetro correspondiente al modo 2 de funcionamiento y
el nombre del fichero que almacena el horario.
102
También se le pasará al simulador el fichero correspondiente a las demandas de

pasajeros y algunos parámetros como:
 El espacio temporal (HorPlan) ajustado a 60 min.
 La capacidad del tren la volveremos a fijar en 400 plazas.
 El porcentaje de ocupación para los trenes que salieron desde la estación

origen con anterioridad a t=0 min, va a ser del 50%.
 El porcentaje de ocupación para trenes que finalizan su trayecto antes de

llegar a la última estación, va a ser del 0%.
El fichero de demandas de pasajeros, será el mismo que en los casos anteriores:
Tabla 11: Matriz de demandas de pasajeros, modo de

simulación 2.
El fichero de horarios pasado al simulador será el siguiente:
Tabla 12: Fichero de horario.txt para el modo 2 de simulación
103
La simulación a realizar para el modo 2, va a presentar un comportamiento un tanto

extraño, no obstante no se busca conseguir resultados óptimos, sino ver las
posibilidades que ofrece este modo de ejecución.
A diferencia de las simulaciones anteriores, aquí se ha optado por un horizonte

temporal de 60min y únicamente comentaremos los resultados de los trenes en
sentido UP, ya que el análisis de los trenes en sentido DW se realiza de forma similar.
De acuerdo con el fichero “horario.txt”, en el horizonte temporal de análisis van a
viajar 6 trenes en sentido Up.
Se puede observar como no se ha introducido ningún tren que comience su trayecto

para un tiempo anterior a t=0 min, ni tampono ninguno que finalice su trayecto para
un tiempo t>HorPlan, en el sentido UP.
La siguiente tabla va a indicar de manera explícita tanto la estación de salida de cada

tren, como la estación en la que estos finalizan su recorrido, así como aquellas
estaciones en las que los trenes no realizan parada (Salta).
EST-0 EST-1 EST-2 EST-3 EST-4 EST-4 EST-5

TREN-0 Salida Parada Parada Parada Parada Parada Finaliza
TREN-2 ------------ Salida Parada Parada Parada Finaliza ---------
-
TREN-3 Salida Salta Parada Parada Parada Parada Finaliza
TREN-4 Salida Parada Parada Parada Finaliza --------- ---------
Tabla 13: Programación de paradas para el modo de simulación 2.
Tanto en la tabla 12 (“horario.txt para el modo 2 de simulación”) como en la Figura 19, se

puede apreciar como los trenes 2 y 4 serán un tipo de trenes que realizan servicios
incompletos y que únicamente pueden imponerse en este modo de simulación.
104
Una vez introducidos todos los parámetros procedemos a la simulación del modo 2,
comprobando en la Figura 19, correspondiente a los trayectos, que los vehículos
reproducen el comportamiento explicado anteriormente.
Figura 21: Trayectorias de trenes modo de simulación 2
En la Figura 20 se representa la ocupación que presenta cada tren en el trayecto a lo

largo de las estaciones, así como el número de personas que suben, bajan o quedan
a la espera del siguiente tren por motivos de capacidad o simplemente porque el tren
no va a parar en la estación deseada.
El tren 0, realizará su trayectoria completa partiendo desde la estación 0 hasta la

estación 5, sin presentar ningún problema de ocupación durante su recorrido.
105
El tren 1, dará lugar a que se produzcan algunas esperas en las estaciones 0, 1 y 2,

como consecuencia del salto que este realiza en la estación 3, en la que su ocupación
se mantiene constante.
El tren 2 comienza su recorrido en la estación 1, por lo tanto las esperas que se

produjeron en la estación 0 van a continuar, no obstante, aunque recoge a los
pasajeros que llegan a la estación 1, se producen nuevas esperas como consecuencia
de los pasajeros que desean viajar a las estación 5 y no podrán subir, dado que el tren
2 finaliza su recorrido en la estación 4.
El tren 3 no va a realizar parada en la estación 1 generando esperas en la estación 0,

sin embargo eliminará todas las esperas producidas por el tren 2, en el resto de
estaciones.
El tren 4 vuelve a generar esperas, dado que este únicamente realiza el trayecto
comprendido entre las estaciones 0-3.
El tren 5 aunque realiza todo el trayecto completo, va a dejar pasajeros esperando

en las estaciones 2 y 3 puesto que este alcanza una ocupación del 100% en ambas
estaciones.
106
Figura 22: Trasvase de pasajeros entre estaciones, modo de simulación 2
En la gráfica 21, se muestra el porcentaje de demandas atendidas en cada tren y en

cada una sus estaciones para el sentido Up.
El tren 0 mantiene durante todo su trayecto una ocupación media del 25%, dado que
el número de pasajeros llegados es reducido, no obstante presenta un porcentaje de
demanda de pasajeros atendidos del 100% durante todo el recorrido.
El tren 1 en cuanto a ocupación tiene unos valores muy aproximados al tren 0, no

obstante en cuanto a porcentaje de demandas atendidas, habrá una caída en la
estación 3 como consecuencia del salto producido en dicha estación. Para el resto de
estaciones el porcentaje de demanda atendida varia en torno al 80%.
Los trenes 2 y 4 al realizar recorridos parciales, van a generar múltiples esperas en

algunas de sus estaciones, dando lugar a una disminución del porcentaje de
demandas atendida.
107
El tren 3 no va a realizar parada en la estación 1, disminuyendo así su demanda

atendida y generando las correspondientes esperas, sin embargo para el resto del
trayecto va a mantener un porcentaje de demanda atendida del 100%.
El tren 5 a pesar de realizar el trayecto completo, presentará una caída del porcentaje
de demandas atendidas en las estaciones 2 y 3 como consecuencia de un
desbordamiento en el número de pasajeros llegados, manteniendo así una ocupación
del 100%.
Figura 23: Ocupación y demanda atendida para el modo de simulación 2
En la siguiente tabla (Tabla 14), se representa el orden en el cual los trenes van a ir
realizando sus paradas para cada estación. En esta tabla vemos claramente como en
la estación 0 (fila 0) el orden de paradas de los trenes va a ser:
Tren 0 – Tren 1 – Tren 3 – Tren 4 – Tren 5
108
También se ve claramente como la estación 2 (fila 2), va a ser la única en la cual todos
los trenes van a realizar parada.
EST-0 Tren-0 Tren-1 Tren-3 Tren-4 Tren-5 ----------

EST-2 Tren-0 Tren-1 Tren-2 Tren-3 Tren-4 Tren-5
Tabla 14: Clasificación de los trenes que van a parar en cada estación por orden de llegada, para el
modo de simulación 2.
Dicho esto se procede a simular la siguiente Figura (Figura 22), donde se pueden
apreciar los tiempos medios de espera de los pasajeros, en cada una de las
estaciones.
La estación 0 correspondiente a la primera gráfica, presenta un pico en el tiempo

medio de espera del tren 3, no obstante si se observa la tabla 14, se puede apreciar
que el tren 2 no va a realizar parada en dicha estación, por lo que los pasajeros que
no pudieron subir al tren 1, tuvieron que quedar a la espera del tren 3 provocando
un aumento del tiempo medio de espera.
En la estaciones 1, 3 y 4 también se van a presentar máximos en los tiempos medios

de espera, causados por trenes que no van a realizar paradas en las estaciones
citadas.
Los tiempos medios de espera en la estación 2 se mantienen más o menos

constantes, ya que esta estación, va a ser la única en la cual todos los trenes van a
realizar parada.
109
Figura 24: Tiempo medio de espera para el modo simulación 2
La Figura 23 se corresponde con los resultados medios de tiempo de retraso,

ocupación y demanda atendida para cada tren.
Los tiempos medios de espera, se van a mantener con pequeñas variaciones, no

obstante para los trenes 0 y 1, este tiempo va a ser algo menor, dado que las esperas
se comienzan a producir para el resto de los trenes.
El porcentaje de ocupación se va a mantener en niveles bajos, a causa de la poca

demanda de pasajeros llegados durante todo el trayecto, sin embargo el tren 5 va a
superar al resto con una ocupación media de casi el 80%,
El porcentaje de demanda atendida va a presentar valores bastante óptimos para

todos los trenes, a excepción de los trenes 2 y 4 que al no realizar el trayecto
completo, van a presentar unos valores en torno al 50%.
110
Figura 25: Valores medios para el modo de simulación 2

estructura:
111
112
113
114
115
116
117
7.2.4 Comparación de los 3 objetos “Horario” obtenidos
Una vez generados los horarios (utilizando diferentes modos de simulación, o con el
mismo modo de simulación pero variando los parámetros de entrada) se procede a
la ejecución de la función “grafCmp1(horario1, horario2, horario3)” desarrollada en
el simulador, la cual va a mostrar las diferencias entre los horarios obtenidos, en
tanto y en cuanto a su tiempo medio de espera, porcentaje de ocupación media y
porcentaje medio de demandas atendidas. Para la ejecución de la función
“grafCmp1” los horarios obtenidos tienen que tener concordancia en cuanto al
número de estaciones simuladas.
De acuerdo con la Figura obtenida (Figura 26), se va a comenzar analizando la primera

gráfica correspondiente al tiempo medio de espera para los diferentes modos de
simulación. A simple vista se puede ver que el modo de simulación 1, va a tener
menor tiempo medio de espera en todas sus estaciones, ya que al tener mayor
número de trenes que paran en cada una de las estaciones, el servicio proporcionado
por este modo de simulación va a ser más eficiente.
La segunda gráfica simulada, refleja un porcentaje de ocupación para el horario

simulado en el modo 0 levemente superior al resto, esto se debe a que este modo
cuenta con un menor número de trenes, por lo que cada tren va a presentar una
mayor demanda de pasajeros llegados y subidos.
118
La última gráfica correspondiente con el porcentaje medio de demandas atendidas.

Por lo general el modo de simulación 1 va a presentar un mayor porcentaje de
demandas atendidas que el modo 0, sin embargo en esta grafica se puede como en
las estaciones 0 y 2, el porcentaje medio de demandas atendidas va a ser mayor en
el modo 0. Esto se debe a que los saltos introducidos en el modo 1, disminuyen el
porcentaje de demandas atendidas en las estaciones 0,1 y 2.
En este ejemplo los resultados obtenidos por el modo 2 de simulación van a ser de
peor calidad. Esto es consecuencia de haber introducido un horario no óptimo a
modo de prueba. El fichero “horarios.txt” contiene trenes que realizan saltos o trenes
que se no se van a desplazar entre origen y destino, dando lugar a altos tiempos de
espera por parte de los pasajeros, y bajos porcentajes de demandas de pasajeros
atendidos.
Figura 26: Comparación de objetos “horario”
119
8 Explicación detallada del código
Una vez explicados los modos de simulación, así como los parámetros de cada modo
y los ficheros de datos, procede a la explicación del código que da lugar al
procedimiento de simulación.
En primer lugar el simulador va a realizar la carga del fichero de distancias entre

estaciones y corroborará su congruencia con el número de estaciones introducido
como parámetro de entrada, posteriormente se va a realizar el mismo proceso con
la matriz de demandas.
Una vez cargados los datos en el sistema, se va a proceder a calcular los perfiles de
carga en cada una de las estaciones y en los dos sentidos de circulación, para
posteriormente crear al menos un objeto (Timetable) asociado a un modo concreto
y en cuya creación se van a especificar los diferentes prámetros requeridos para la
simulación.
Cuando se dispone de un objeto Timetable, se invocarán “calcula_incompletos” y

“calcula_todo_timetable” que se van a encargar y llevar a cabo la simulación del
objeto horario.
Finalmente se vuelcan todos estos datos en un fichero llamado “_resultados.txt_” y

procedemos a representar los resultados obtenidos tras la simulación.
120
8.1 Clases
Para la implementación de la aplicación se ha desarrollado la clase timetable, que se

encarga de generar objetos ‘horario’ en función de los parámetros introducidos al
simulador.
class timetable:
def __init__(self,modo,TTfile,headUP,headDW,TrenSpeed,Desf1,Desf2,OverrideCap):
Esquema 1: Clase
8.2 Atributos
ATRIBUTOS
self.AWT_u/d
self-AWT
self.Acumulado_u/d
self.ESP_tras_ut_u/d = np.zeros(NumEst, dtype=int).reshape(NumEst)
self.Eij_u/d=np.zeros(self.NumTrenU/D*NumEst*NumEst, dtype=float).reshape(self.NumTrenU/D,NumEst,NumEst)
self.escala
self.FirstStoppedTrenU/D =np.zeros(NumEst, dtype=int).reshape(NumEst)
self.LLE_tras_ut_u/d=np.zeros(NumEst, dtype=int).reshape(NumEst)
self.LastStoppedTrenU/D=np.zeros(NumEst, dtype=int).reshape(NumEst)
self.MatDemU/D=np.zeros(self.NumTrenU/D*NumEst*NumEst, dtype=float).reshape(self.NumTrenU/D,NumEst,NumEst)
self.ND_U/D=np.zeros(self.NumTren*NumEst, dtype=float).reshape(self.NumTren,NumEst)
self.NO_U/D=np.zeros(self.NumTrenD*NumEst, dtype=float).reshape(self.NumTrenD,NumEst)
self.NumSaTrD/U=np.zeros(self.NumTrenD/U, dtype=float).reshape(self.NumTrenD/U
self.NumTrenAntesU/D=np.zeros(self.NumTrenU/D, dtype=float).reshape(self.NumTrenU/D)
121
self.NumTrenU/D
self.NumTrenDetrasU/D=np.zeros(self.NumTrenU, dtype=float).reshape(self.NumTrenU/D)
self.Por_ocup_u/d
self.Ret_tras_ut_u/d
self.Sij_u/d=np.zeros(self.NumTrenU/D*NumEst*NumEst, dtype=float).reshape(self.NumU/DTrenU,NumEst,NumEst)
self.TESP_tras_ut_u/d=np.zeros(NumEst, dtype=int).reshape(NumEst)
self.TLLE_tras_ut_u/d=np.zeros(NumEst, dtype=int).reshape(NumEst)
self.Total_u/D
self.TrenAntesD/U=np.zeros(self.NumTrenD/D*NumEst, dtype=float).reshape(self.NumTrenD,/UNumEst)
self.TrenDetrasU/D=np.zeros(self.NumTrenU/D*NumEst, dtype=float).reshape(self.NumTrenU/D,NumEst)
self.TrenSaltaU/D=np.zeros(self.NumTrenU/D*NumEst, dtype=float).reshape(self.NumTrenU/D,NumEst)
self.TrenSpeed
self.WTA_est_u/d=np.zeros(self.NumTrenU/D, dtype=float)
self.WTA_tren_u/d=np.zeros(NumEst,dtype=float)
self.WT_tras_ut_u/d=np.zeros(NumEst, dtype=int).reshape(NumEst)
self.WTestU/D=np.zeros(NumEst*self.NumTrenU, dtype=float).reshape(self.NumTrenU,NumEst)
self.desfU/D
self.ead_u/d=np.zeros(self.NumTrenU/D*NumEst, dtype=float).reshape(self.NumTrenU/D,NumEst)
self.eeij_u/d=np.zeros(self.NumTrenU/D*NumEst*NumEst, dtype=float).reshape(self.NumTrenU/D,NumEst,NumEst)
self.headU/D
self.modo
self.neij_u=np.zeros(self.NumTrenU/D*NumEst*NumEst, dtype=float).reshape(self.NumTrenU/D,NumEst,NumEst)
self.nsij_u/d=np.zeros(self.NumTrenU/D*NumEst*NumEst, dtype=float).reshape(self.NumTrenU/D,NumEst,NumEst)
self.pl_u/d=np.zeros(self.NumTrenU/D*NumEst, dtype=float).reshape(self.NumTrenU/D,NumEst)
self.po_u/d=np.zeros(self.NumTrenU/D*NumEst, dtype=float).reshape(self.NumTrenU/D,NumEst)
self.pocDemU/D
self.pocU/Dest=np.zeros(NumEst,dtype=float).reshape(NumEst)
self.pocU/D=np.zeros(self.NumTrenU/D,dtype=float).reshape(self.NumTrenU/D)
self.psubU/D=np.zeros(self.NumTrenU/D,dtype=float).reshape(self.NumTrenU/D)
self.psubU/Eest=np.zeros(NumEst,dtype=float).reshape(NumEst)
self.sad_u/d=np.zeros(self.NumTrenU/D*NumEst, dtype=float).reshape(self.NumTrenU/D,NumEst)
self.sao_u/d=np.zeros(self.NumTrenU/D*NumEst, dtype=float).reshape(self.NumTrenU/D,NumEst)
self.tarrU/D=np.arange(NumEst*self.NumTrenU/D,dtype=float).reshape(self.NumTrenU/D,NumEst)
self.tdepU/D=np.arange(NumEst*self.NumTrenU/D,dtype=float).reshape(self.NumTrenU/D,NumEst)
self.tfinviajeU/D
Esquema 2 Esquema 3 Atributos de la clase timetable
122
8.2.1 Explicación de atributo:
self. AWT_u/d:
Retraso medio en las esperas para el sentido Up y Dw, únicamente de los pasajeros
que llegan durante el recorrido de los trenes, se mide en (min/pasajero).
Self.AWT:
Media entre el retraso Up, Dw y el total de pasajeros que llegan durante Horplan, se
mide en (min/pasajero).
self.Acumulado_u/d:
Tiempo total de espera en cada sentido, se mide en (min).
self.ESP_tras_ut_u/d = np.zeros(NumEst, dtype = int).reshape(NumEst):
Pasajeros que esperan en cada estación después de haber pasado el último tren.
self.Eij_u/d=np.zeros(self.NumTrenU/D*NumEst*NumEst, dtype = float):
Pasajeros que quedan esperando tras la salida del tren, para cada par de estaciones
en ambos sentidos.
self.escala:
Parámetro que nos permite escalar las demandas durante la simulación.
self.FirstStoppedTrenU/D = np.zeros(NumEst, dtype=int).reshape(NumEst):
Variable que nos indica el primer tren que parará en cada estación.
self.LLE_tras_ut_u/d = np.zeros(NumEst, dtype=int).reshape(NumEst):
Pasajeros que llegan a cada estación después de haber pasado el último tren.
123
self.LastStoppedTrenU/D = np.zeros(NumEst, dtype = int).reshape(NumEst):
Ultimo tren que para en cada estación.
self.MatDemU/D = np.zeros(self.NumTrenU/D*NumEst*NumEst, dtype = float):
Indica el número de personas que se desplazan entre cada par de estaciones para
cada tren.
self.ND_U/D=np.zeros(self.NumTren*NumEst,dtype=float):
Número de pasajeros que se suben a cada tren en cada una de las estaciones.
self.NO_U/D = np.zeros(self.NumTrenD*NumEst).reshape(self.NumTrenD,NumEst):
Número de pasajeros que se baja de cada tren en cada una de las estaciones.
self.NumSaTrD/U = np.zeros(self.NumTrenD/U, dtype=float):
Numero de saltos que realiza cada tren.
self.NumTrenAntesU/D = np.zeros(self.NumTrenU/D, dtype=float):
Número de estaciones por las que pasa un tren para t<0.
self.NumTrenU/D:
Número de trenes que se desplazan en cada sentido.
self.NumTrenDetrasU/D = np.zeros(self.NumTrenU/D, dtype=float):
Número de estaciones por las que pasa un tren para t>HorPlan.
self.Por_ocup_u/d:
Porcentaje de ocupación medio para cada sentido.
124
self.Ret_tras_ut_u/d:
Retraso total (suma de pasajeros que esperan en cada estación tras el último tren,
más la suma de pasajeros llegados a cada estación tras el último tren) dividido entre
el tiempo de espera a causa de los retrasos más el tiempo espera de los pasajeros
llegados tras el último tren.
self.Sij_u/d = np.zeros(self.NumTrenU/D*NumEst*NumEst,dtype = float):
Número de pasajeros que consiguen subir a cada tren para cada par de estaciones.
self.TESP_tras_ut_u/d = np.zeros(NumEst, dtype=int).reshape(NumEst):
Tiempo total de esperas acumuladas después del último tren por los pasajeros que
quedan a la espera en cada estación (min).
self.TLLE_tras_ut_u/d = np.zeros(NumEst, dtype=int).reshape(NumEst):
Tiempo total de espera para todas personas que llegaron después del último tren, en
cada estación).
self.Total_u/D:
Número total de esperas acumuladas después de pasar el último tren más los que
llegan después de pasar este.
self.IncompletosD/U=np.zeros(self.NumTrenU/D*NumEst,dtype = float):
Matriz para trenes incompletos que pueden presentar los siguientes valores:
 0: El tren realiza una parada regular en esa estación.
 1: El tren va a realizar la parada en la estación, para un tiempo fuera del

espacio temporal de análisis t<0.
 2: El tren va a realizar la parada en la estación para un tiempo fuera del

espacio temporal de análisis t>HorPlan.
125
 3: Indica que el tren va a pasar de largo por dicha estación sin realizar parada.
 4: Indica que el tren no va a iniciar su recorrido en la estación 0.
 5: Indica que el tren no va a finalizar su trayecto en la última estación.
Marca con un ‘1’ las posiciones en las que un tren llegará a una estación para un
tiempo t<0.
self.TrenSpeed:
Velocidad media del tren(km/hora).
self.WTA_est_u/d = np.zeros(self.NumTrenU/D, dtype = float):
Retraso medio en cada tren (min/pasajero).
self.WTA_tren_u/d = np.zeros(NumEst,dtype = float):
Retraso medio en cada estación (min/pasajero).
self.WT_tras_ut_u/d = np.zeros(NumEst, dtype = int).reshape(NumEst):
Retraso medio por persona en cada estación para pasajeros llegados después del
último tren (min/pasajero).
self.WTestU/D=np.zeros(NumEst*self.NumTrenU).reshape(self.NumTrenU,NumEst)
Tiempo total de esperas acumuladas para cada tren y estación (min).
self.desfU/D:
Desfase inicial.
self.ead_u/d = np.zeros(self.NumTrenU/D*NumEst, dtype = float):
126
Esperas agregadas sumando destinos.
self.eeij_u/d=np.zeros(self.NumTrenU/D*NumEst*NumEst, dtype=float):
Pasajeros que esperaban y siguen sin poder subir al tren, para cada par de estaciones
y tren.
self.esij_u/d = np.zeros(self.NumTrenU/D*NumEst*NumEst, dtype = float):
Pasajeros que esperaban y logran subir, para cada par de estaciones y tren.
self.headU/D:
Tiempo entre salidas de trenes.
self.modo:
Modo de funcionamiento del simulador.
self.neij_u = np.zeros(self.NumTrenU/D*NumEst*NumEst, dtype=float):
Pasajeros que llegan y tienen que esperar (por causas de capacidad, o porque el tren
no va a parar en el destino deseado), para cada par de estaciones y tren.
self.nsij_u/d = np.zeros(self.NumTrenU/D*NumEst*NumEst, dtype = float):
Pasajeros que llegan y suben, para cada par de estaciones y tren.
self.pl_u/d = np.zeros(self.NumTrenU/D*NumEst, dtype=float):
Plazas libres para cada tren y estación.
self.po_u/d = np.zeros(self.NumTrenU/D*NumEst, dtype = float):
Plazas ocupadas para cada tren y estación.
self.pocDemU/D:
127
Variable que almacena el porcentaje de demanda atendida en cada sentido.
self.pocU/Dest = np.zeros(NumEst,dtype = float).reshape(NumEst):
Porcentaje de ocupación en cada estación.
self.pocU/D = np.zeros(self.NumTrenU/D,dtype = float).reshape(self.NumTrenU/D):
Porcentaje medio de ocupación en cada tren.
self.psubU/D = np.zeros(self.NumTrenU/D,dtype=float).reshape(self.NumTrenU/D):
Porcentaje de demandas atendidas para cada tren.
self.psubU/Dest = np.zeros(NumEst,dtype = float).reshape(NumEst) :
Porcentaje de demandas atendidas en cada estación.
self.sad_u/d = np.zeros(self.NumTrenU/D*NumEst, dtype = float):
Subidas agregadas sumando destinos en cada tren y estación.
self.sao_u/d = np.zeros(self.NumTrenU/D*NumEst, dtype = float):
Subidas agregadas sumando orígenes en cada tren y estación.
self.tarrU/D=np.arange(NumEst*self.NumTrenU/D,dtype=float).reshape(self.NumTr
enU/D,NumEst):
Tiempo de llegada de cada tren, a cada una de las estaciones (min).
self.tdepU/D=np.arange(NumEst*self.NumTrenU/D,dtype=float)reshape(self.NumTr
enU/D,NumEst)
Tiempo de salida de cada tren desde cada una de las estaciones (min).
self.tfinviajeU/D:
128
Duración en minutos del trayecto completo de los trenes para los modos de
simulación 0 y 1.
8.3 Métodos
Métodos
RellenaModo0(self,headUP,headDW,TrenSpeed,tviajeU,tviajeD):
RellenaModo1(self,Head1,Head2,TrenSpeed,tviajeU,tviajeD):
RellenaModo2(self,FileTT):
calcula_tiempos(self):
calcula_llegadas(self,Escala=1):
calcula_incompletos(self):
demanda_tren(self,tren,sentido,Escala):
acumulada(self,Est1,Est2,Valor):
calcula_todo_timetable(self,porcentaje,porcentaje2,direcciones=AMBAS):
agrega_llegadas_OD(self):
calcula_todas_vars_timetable_UP/DW(self,porcentaje,porcentaje2):
calcula_FO_Dw(self):
calcula_FO_Dw(self):
report(self,Filereport,direccion=AMBAS):
Plot(self):
Esquema 4 Métodos clase timetable
129
8.4 Pseudocódigo
En este apartado haremos una pequeña definición de cada una de las funciones
principales del simulador, así como entradas, salidas y sus diagrama UML
correspondientes.
8.4.1 main()
Función principal de nuestro software, que se va a encargar de realizar la llamada a

todas las funciones y cargará en memoria todos los atributos de los diferentes objetos
creados.
No recibirá nada por línea de comandos.
La siguiente figura muestra el diagrama UML de la función main():
130
Def main ():
carga_distancias (distancias.txt)
Coincide con NumEst?
carga_matriz (matriz.txt)
Coincide con NumEst?
calcula_cargas (escala)
Creamos el objeto horario
Horario = timetable (modo=1,TTFile,headUP,headDW,TrenSpeed,Desf1,Desf2,OverrideCap)
Horario.calcula_llegadas(escala)
Horario.calcula_incompletos ()
Horario.calcula_todo_timetable (Porcentaje1,Porcentaje2)
Horario.report ('Resultados.txt')
Horario.plot ()
Exit
Diagrama de flujo 2: Función main ()
131
8.4.2 Carga_distancias (DisDataFile)
Esta función carga los datos procedentes del fichero DisDataFile en la variable global
LongSeg=np.arange(NumEst-1, dtype=int).reshape(NumEst-1) mediante una función
propia de la librería numpy, np.loadtxt(File)
Entradas:
 Fichero de distancias entre estaciones en metros.
carga_distancias (DisDataFile):
LongSeg=np.loadtxt(DisDataFile, delimiter=';', usecols=None,dtype=float)
Exit
Diagrama de flujo 3: Función carga_distancias (DisDataFile)
8.4.3 Carga_matriz (MatDataFile)
Esta función carga los datos procedentes del fichero MatDataFile en la variable global
matriz=np.arange(NumEst*NumEst, dtype=float).reshape(NumEst,NumEst)
mediante una función propia de la libreria numpy, np.loadtxt(File).
Presenta la opción de ralizar un escalado de la matriz de demandas, con la variable

global Escala
Entradas:
132
 Fichero de demanda de pasajeros entre estaciones.txt
carga_matriz(MatDataFile):
matriz=np.loadtxt(File, delimiter=';', usecols=None)
For i (0,Numest):
For j (0,Numest):
matriz[i,j]=Escala*matriz[i,j]
Exit
Diagrama de flujo 4: Función carga_matriz (MatDataFile)
8.4.4 calcula_cargas (Escala)
Esta función calcula la demanda de pasajeros en cada estación para el sentido Up y

almacena dicha demanda en la variable:
PerfilCargaDirecto = np.arange(NumEst, dtype = float).reshape(NumEst)
Para el sentido Dw almacena la demanda en la variable:

PerfilCargaReverso=np.arange(NumEst,dtype=float).reshape(NumEst)
Entradas:
 Escala: parámetro para escalar la variable 'matriz'
133
def calcula_cargas (escala):
For est (0,Numest):
Calcula los pasajeros que suben en sentido Up [est]

Calcula los pasajeros que suben en sentido Dw [est]
Calcula los pasajeros que bajan en sentido Up [est]

Calcula los pasajeros que bajan en sentido Dw [est]
For est (0,Numest):
PerfilCargaDirecto = SubenUp [est] -BajanUp [est]
PerfilCargaReverso = SubenDw [est] -BajanDw [est]
Exit
Diagrama de flujo 5: Función calcula_cargas (escala)
134
8.4.5 class timetable
Entradas:
 Modo: El simulador cuenta con 3 modos de funcionamiento

 TTfile: fichero de tiempos necesario para ejecutar el simulador en modo 2
 HeadUP, HeadDw: Tiempo de separación entre trenes contiguos en cada
sentido
 TrenSpeed: Velocidad del tren
 Desf1, Desf2: Tiempo de desfase para el primer tren en cada sentido
 OverrideCap=1: La capacidad de cada tren se establece en la variable global
TrenCap
 OverrideCap=0: La capacidad la fija el valor máximo del vector
‘Perfil_de_Carga’
135
class timetable (self,mod,TTfile,headUP,headDW,TrenSpeed,Desf1,Desf2,OverrideCap):
Almacena parámetros de entrada en atributos
If OverrideCap==1?
Si
TrenCap=max(PerfilCarga)
No
If modo !=2 ? RellenaModo2 (TTFile)
Si
TiempoViaje=long_linea/(TrenSpeed)+(NumEst-1)*DwellTime
No
NumTrenesInicioUp=TiempoViaje/HeadUP
If modo ==0 ?
NumTrenesInicioDw=TiempoViaje/HeadDw
Si
NumTrenesUp=(HorPlan- TrenesUp=(HorPlan-Desf1)/HeadUP
Desf1)/HeadUP TrenesDw=(HorPlan-Desf2)/HeaDw
NumTrenesDw=(HorPlan- NumTrenesUp=NumTrenesInicioUp+TrenesUp
Desf2)/HeaDw NumTrenesDw=NumTrenesInicioUp+TrenesDw
self.calcula_tiempos()
Diagrama de flujo 6: Class timetable
136
8.4.6 Método calcula_tiempos (self)
Función para rellenar los tiempos de llegada y salida de los trenes, a cada una de las
estaciones, en los modos 0 y 1.
Se pone en sentido Up el primer tren partiendo de t=0 y a partir de ahí se calculan el

resto.
Después restamos a todos los trenes el tiempo desf1 lo que traslada todo el timetable
hacia la izquierda en el eje de tiempos.
Finalmente todos los que tengan valor < 0 se ponen a -1 = ANTES y los que tengan
valor > HorPlan se ponen a -2 = DESPUÉS.
137
def calcula_tiempos (self) :
Tiempo llegada [tren=0,est=0]=Desfase inicial

Tiempo salida [tren=0,est=0] = Tiempo llegada [tren=0,est=0] + DwellTime
For tren (1,NumTrenes):
For est (0,NumEst):
Tiempo llegada [tren,est]=Tiempo llegada [tren-1,est]+Head

Tiempo salida [tren,est] = Tiempo llegada [tren,est]+DwellTime
Tiempo llegada [tren,est]=Tiempo llegada [tren,es]+Head

Tiempo salida [tren,est] = Tiempo llegada [tren,est]+DwellTime
No No
If Tiempo llegada[tren,est]<0 : If Tiempo llegada [tren,est]>0 :
Si Si
Tiempo llegada tren [tren] = ANTES Tiempo llegada [tren,est] = DETRÁS
No
If Tiempo salida [tren,est]<0 : If Tiempo salida [tren,est]>0 :
No
Si Si
Tiempo salida [tren,est] = ANTES Tiempo salida [tren,est] = DETRÁS
Exit
Diagrama de flujo 7: Método calcula_tiempos(self)
138
8.4.7 Método rellena_modo2 (self,FileTT)
Esta función captura, tanto el número de trenes en cada sentido, como los tiempos
de llegada y salida en el fichero FileTT, y los almacena en los atributos tarrU/D y
tdep/D.
Posteriormente comprueba aquellos tiempos que quedan fuera del intervalo HorPlan
y los debidos a saltos.
Entradas:
 Fichero de tiempos horario.txt
139
RellenaModo2 (self, FileTT):
No
if os.path.exists(FileTT): ? print 'El Fichero de entrada '+FileTT+' no existe.'
Si
Captura tiempos de llegadas [tren,est]

Captura tiempos de salidas [tren,est]
For est (0,NumEst):
No No
If Tiempo llegada[tren,est]==-1 : If Tiempo llegada [tren,est]>HorPlan : If Tiempo llegada [tren,est]==-3 :
Si Si Si
Tiempo llegada tren [tren] = ANTES Tiempo llegada [tren,est] = DETRÁS Tiempo llegada [tren,est] = SALTA
No No
If Tiempo salida [tren,est]==-2 : If Tiempo salida [tren,est]>HorPlan : If Tiempo salida [tren,est]==-3 :
Si Si Si
Tiempo salida [tren,est] = ANTES Tiempo salida [tren,est] = DETRÁS Tiempo salida [tren,est] = SALTO
Exit
Diagrama de flujo 8: Método rellena_modo2 (self,FileTT)
140
8.4.8 Método calcula_llegadas (self, Escala, TipoDem)
Función que crea 4 atributos de tipo array y de tamaño NumEst, donde almacenará
cual es el primer tren en parar en cada estación (1 para cada sentido) y cuál es el
último tren en parar en cada estación (1 para cada sentido).
Posteriormente define dos atributos self.MatDemU y self.MatDemD, para almacenar

el número de pasajeros que se desplaza en cada tren, entre cada par de estaciones.
Entradas:
 Escala: Parámetro para escalar las demandas.

 TipoDem: Escogemos el modo de función continua de demanda o de matriz
estática.
141
def calcula_llegadas (self,Escala,TipoDem) :
For est (0,NumEst):
self.LastStoppedTren[est]=-3
self.FirstStoppedTren[est]=0
For est (0,NumEst):
No
if self.tdep[tren,est]>0:
Si
FirstStoppedTren[est]=tren
break
self.MatDem[tren]=self.demanda_tren(tren,sentido,Escala)
Exit
Diagrama de flujo 9: Método calcula_llegadas(self)
142
8.4.9 Método: demanda_tren (self,tren,sentido,escala)
Calcula la demanda de pasajeros para cada tren y para cada par de estaciones. Toma
los instantes de salida tdep[tren] según el sentido del trayecto.
Entradas:
 tren: Rellena la matriz de demandas para cada tren.

 Sentido: UP o DW.
 Escala: Parámetro para escalar las demandas.
Salidas:
 Matriz de demandas [tren]
143
def demanda_tren (self,tren,sentido,Escala) :
For est (0,NumEst):
No
if tiempo de salida[tren,est]>0:
Si
For Est (est+1,NumEst):
No a = (matriz[est,Est] / HorPlan) *Tiempo de salida[tren,est]

If ÚltimaParadaTren[Est] == -3 b = (matriz[est,Est] / HorPlan) * Tiempo de salida último tren [est]
C[est,Est]=(a-b) * escala
Si
a = matriz[est,Est] / HorPlan*Tiempo de salida[tren,est]

C[est,Est]=escala*a
Última parada tren [est]=tren
Exit
Diagrama de flujo 10: Método demanda_tren(self,tren,sentido,Escala)
144
8.4.10 Método: calcula_incompletos()
Define la matriz Incompletos de tamaño Numero_Trenes*Número_Estaciones,

donde almacena lo trenes que comienzan para t<0 (ANTES), los trenes que exceden
el espacio temporal para t>HorPlan (DETRÁS) y aquellos trenes que realizar
trayectorias intermedias.
145
def calcula_incompletos (self) :
For tren (0,NumTren):
For est (0,NumEst):
Si
If tiempo llegada == SALTA Incompletos[tren,est]=3
No
Si
If tiempo salida == DETRÁS Incompletos[tren,est]=2
No
Si
If tiempo salida == ANTES Incompletos[tren,est]=1
No
Si
If tiempo salida == TrenCortoInicio Incompletos[tren,est]=4
No
Si
If tiempo salida == TrenCortoFin Incompletos[tren,est]=5
No
Exit
Diagrama de flujo 11: Función calcula_incompletos()
146
8.4.11 Método: calcula_todo_timetable (Porcentaje1, Porcentaje2)
En esta función se van a calcular todos los atributos del objeto timetable: Esperas
para cada par de estaciones E(i,j), subidas S(i,j), así como sus componentes ns(i,j),
ne(i,j), es(i,j), ee(i,j) (desagregación por cada par de estaciones) y las plazas libres y
ocupadas pl(tren,estación) y po(tren,estación).
Se usarán tablas globales en las cuales se van a ir almacenando los resultados.
Entradas:
 Porcentaje1 : Porcentaje de ocupación para los trenes que salen de la

estación origen en t<0
 Porcentaje2 : Porcentaje de ocupación en las estaciones en las cuales

t>HorPlan

estática.
147
def calcula_todo_timetable (self,Porcentaje1,Porcentaje2,TipoDem)
Self.agrega_llegadas_OD()
Rellenamos toda la matriz de plazas libres a TrenCap
For tren (0,Num Tre n)
For est (0,Num Est)
If tiempo de Si
salida[tren,est]==ANTES Plazas_libres[tren,est] = TrenCap*Porcentaje1/100
No
If tiempo de Si
salida[tren,est]==DETRÁS Plazas_libres[tren,est] = TrenCap*Porcentaje2/100
No
self.calcula_todas_vars_timetables (Porcentaje1,Porcentaje2)
agregaD(self.ead,self.Eij,self.NumTren)
agregaO(self.sao,self.Sij,self.NumTren)
agregaD(self.sad,self.Sij,self.NumTren)
self.Acumulado, self.Total, self.AWT = self.calcula_FO()
Exit
Diagrama de flujo 12: Método calcula_todo_timetable (porcentaje1, porcentaje2)
148
8.4.12 Método calcula_todas_vars_timetable (Porcentaje1,

Porcentaje2)
Realiza el cálculo de todas las variables, subidas, bajadas, plazas libres, plazas
ocupadas, esperas... considerando todos los tipos de trenes (ANTES, DETRÁS y
SALTO). A la hora de subir a un tren, los pasajeros que estuviesen esperando, siempre
llevarán preferencia sobre los recién llegados.
Entradas:
 Porcentaje1: Porcentaje de ocupación para los trenes que salen de la estación

origen en t<0
 Porcentaje2: Porcentaje de ocupación en las estaciones en las cuales

t>HorPlan
La ilustración 41 muestra el diagrama UML de la función.
8.4.13 Método: calcula_FO_UP(self)
Ahora calculamos la función objetivo del timetable sin contar los que llegan al final
del todo. Primero identificamos el primer tren que para en cada estación.
Entradas:

estática.
Salidas:
 Acumulador: Tiempo total de espera acumulado en todo el intervalo.

 Total: Número de personas totales en todo HorPlan.
 FO: Tiempo medio de espera de los retrasos en todo el trayecto.
149
Diagrama de flujo 13: Método calcula_todas_vars_timetable (porcentaje1,porcentaje2)
150
Def calcula_FO (TipoDem):
For est (0,NumEst-1)
For tren
(PrimeraParada[est],UltimaParada[est]+1)
Acumulador+=(esperas*t.esperas)+(0.5*llegadas*t.espera llegadas)
TiempoEspera[tren,est]=t.esperas+t.espera llegadas
T.espera tras último tren[est]=esperas[est] * (HorPlan – t. salida del ultimo t ren[est])

Acumulador+=T.espera tras últi mo tren[est]
Tot al=Suma de todos los pasajeros llegados hasta el ultimo t ren

FO=acumulador/Tot al
Tot al+=personas llegadas t ras ultimo tren[est]

T. de espera personas llegadas tras ult imo tren[est]=personas llegadas después de ul timo tren [est]*T.espera hasta finalizar HorPl an
Acumulador+=T. de espera personas llegadas tras ult imo tren[est]
Suma_llegadas+=llegadas tras úl timo tren[est] + Esperas tras último tren[est]

Suma _tiempos+=T. de espera ll egados tras ultimo tren [est] +T de espera retrasos tras ultimo t ren [est]
Retraso Total= Sum_tiempos / Suma_llegadas
For tren (0,NumTren)
For est (0,NumEst)
Acumulador_demanda+=Personas llegadas[tren,est]+Esperas acumuladas en el último tren [est]

Acumulador_tiempo+=Tiempo de espera [tren,est]*(Personas l legadas [tren,est]+ Esperas acumuladas en el últi mo tren [est]
Tiempo de espera[tren]=>Acumulador_tiempo/Acumulador_demanda
For tren (0,NumTren)
Acumulador_demanda+=Personas l legadas[tren,est]+Esperas acumuladas en el último tren [est]

Acumulador_tiempo+=Tiempo de espera [tren,est]*(Personas l legadas [tren,est]+ Esperas acumuladas en el último tren [est]
Tiempo de espera[est]=>Acumulador_tiempo/Acumulador_demanda
Return (Acumulador, total, FO)
Diagrama de flujo 14: Método calcula_FO (self)
151
9 Conclusiones y líneas de trabajo futuras
9.1 Conclusiones
En este proyecto se ha tratado de diseñar e implementar una herramienta útil, fácil de

manejar y general, que pueda resultar aplicable a la simulación de horarios en las líneas
de una red ferroviaria.
Se cumple, por un lado, el objetivo de disponer de una herramienta para crear una base
sólida, con los elementos necesarios para la construcción de modelos de simulación
ferroviaria y por otro lado el de disponer de un software para simular diferentes
condiciones de servicio y evaluar la efectividad del sistema en términos de calidad, ante
situaciones variables de demanda.
Se han incorporado 3 métodos de simulación diferentes e incluso se ha desarrollado

una función adicional, para realizar comparaciones, en base a los datos obtenidos para
3 objetos “horario”.
La labor de introducción de datos y parámetros, se simplifica gracias a la posibilidad de

cargar ficheros con el valor de todos los parámetros, durante la fase de simulación.
Además, resulta sencillo variar los datos de entrada de forma que puedan simularse
diferentes escenarios prácticamente sin esfuerzo por parte del usuario.
La fase de simulación, es la etapa más compleja del proceso, ya que es necesario llevar
un control exhaustivo de los pasajeros durante todo el trayecto.No obstante, después
de haber realizado múltiples pruebas con el simulador, concluimos que el
comportamiento de un sistema real se corresponde con la parte central de la
simulación, dado que al acotar el espacio temporal, los trenes de los extremos no
realizarán el trayecto completo.
En base a los resultados obtenidos, se puede decir que el modelo presentado refleja el
comportamiento del sistema real, con un reducido margen de error, lo que permite
152
realizar los ensayos necesarios para aproximar el comportamiento del sistema real en
un escenario determinado.
9.2 Líneas de trabajo futuras
Como líneas de trabajo futuro, puede ser necesario el desarrollo de una interfaz gráfica,
facilitando en gran medida la gestión del simulador por parte del usuario.
Esta puede ser desarrollada en QT o PYQT dando como resultado una visual bastante
más atractiva y eliminando la necesidad de estar trabajando sobre el propio código, que
puede resultar algo engorroso.
Por otra parte también tenemos algunas posibles líneas de trabajo futuro, como pueden
ser:
o Desarrollar posibles transbordos.
o Desarrollar sistemas de control de tráfico.
o Establecer el uso de vías, e incluso en algunos casos establecer el uso

simultáneo de las mismas.
153
10 Bibliografía
Abbink, E.W.J., van den Berg, B.W.V., Kroon, L.G., Salomon, M. (2004). Allocation of
railway rolling stock for passenger trains. Transportation Science 38, 33-41.
Allen Downey, Jeffrey Elkner y Chris Meyers 2002, Aprenda a pensar como un
programador con Python.
Arabeyre, J., Fearnley, J., Steiger, F., Teather, W. (1969). The airline crew scheduling
problem: A survey. Transportation Science 3, 140-163.
Balakrishnan, N., Wong, R.T. (1990). A network model for the rotating workforce
scheduling problem. Networks 20, 25-42.
Balas, E., Carrera, M.C. (1996). A dynamic subgradient-based branch-and-bound

procedure for set covering. Operations Research 44, 875-890.
Balas, E., Ho, A. (1980). Set covering algorithms using cutting planes, heuristics and
subgradient optimization: A computational study. Mathematical Programming Study
12,37-60.
Barber F., Abril M., Salido M.A., Ingolotti L., Tormos P., Lova A. (2007). Survey of
automated systems for railway management. Technical Report DSIC-II/01/07,
Department of Computer Systems and Computation. Technical University of Valencia.
Barnhart, C., Johnson, E.L., Nemhauser, G.L., Savelsbergh, M.W.P., Vance, P.H. (1994).
Branchand-price: Column generation for solving huge integer programs. In: Birge, J.R.,
Murty, KG. (Eds.), Mathematical Programming: State of the Art 1994. University of
Michigan Press, Ann Arbor, pp. 186- 207.
Beasley, J.E. (1987). An algorithm for set covering problems. European Journal of
Operational Research 31, 85-93.
154
Beasley, J.E. (1990). A Lagrangian heuristic for set covering problems. Naval Research
Logistics 37, 151-164.
Beasley, J.E., Chu, P.C. (1996). A genetic algorithm for the set covering
problem.European Journal of Operational Research 94,392-404.
Beasley, J.E., Jornsten, K. (1992). Enhancing an algorithm for set covering

problems.European Journal of Operational Research 58,293-300.
Bodin, L., Golden, B., Assad, A., Ball, M. (1983). Routing and scheduling of vehicles and
crews: The state of the art. Computers & Operations Research 10, 63-211.
Burdett R.L., Kozan E. (2006). Techniques for absolute capacity determination in

railways. Transportation Research B, 40, 616-632.
Bussieck M.R. (1998). Optimal lines in public rail transport. PhD thesis, Technische
Universität Braunschweig.
Bussieck M.R., Winter T, Zimmermann UT (1997). Discrete optimization in public rail

transport. Mathematical Programming 79 (1-3), 415-444.
Bruno, G., Gendreau, M., and Laporte, G. (2002). A Heuristic for the Location of a Rapid
Transit Line, Computers & Operations Research, 29, pp: 1-12.
Bruno, G., Ghiani, G., and Improta, G. (1998). A Multi-modal Approach to the Location
of a Rapid Transit Line, European Journal of Operational Research, 104, pp: 321-332.
Cacchiani V. (2008). Models and Algorithms for Combinatorial Optimization Problems

arising in Railway Applications. 4OR: A Quarterly Journal of Operations Research, 7 (1),
109-112.
Cai, X., Goh, C.J. (1994). A fast heuristic for the train scheduling problem.Computers &
Operations Research 21,499-510.
Canca D. (2009). Operación mixta de una línea de ferrocarril. Análisis de capacidad y

gestión de material rodante. Dirección y Organización, 39, 45-53.
155
Canca D., Zarzo A., Espinosa P. (2009). Operación compartida de líneas de ferrocarril.
Análisis de Capacidad. Un primer enfoque. Proceedings of the 2nd Conference on

Optimization Models for Robustness Planning and Emergency Management in Public
Transportation. MORE 2009. (pp. 39-55), Seville: University of Seville.
Canca D., Zarzo A., Algaba E., Barrena E. (2011). Confrontation of Different Objectives in
the determination of train scheduling. Procedia - Social and Behavioral Sciences, 20,
302-312.
Caprara, A., Fischetti, M., Toth, P., Vigo, D., Guida, P.L. (1997). Algorithms for railway
crew management.Mathematical Programming 79,125-141.
Caprara, A., Fischetti, M., Toth, P., Vigo, D. (1998). Modeling and solving the crew
rostering problem. Operations Research 46, 820-830.
Caprara, A., Fischetti, M., Toth, P. (1999).A heuristic method for the set covering
problem.Operations Research 47,730-743.
Caprara, A., Fischetti, M., Toth, P. (2000).Algorithms for the set covering problem.Annals
of Operations Research 98,353-371.
Ernst, A.T., Jiang, H., Krishnamoorthy, M., Nott, H., Sier, D. (2001).An integrated
optimization model for train crew management. Annals of Operations Research 108,
211-224.
Ernst, A.T., Jiang, H., Krishnamoorthy, M., Owens, B., Sier, D. (2004b).Annotated
bibliography of personnel scheduling and rostering. Annals of Operations Research
127,21-144.
Ernst, A.T., Jiang, H., Krishnamoorthy, M., Sier, D. (2004a). Staff scheduling and
rostering: A review of applications, methods and models. European Journal of
Operational Research 153,3-27.
156
Fisher, M.L., Kedia, P. (1990). Optimal solutions of set covering/partitioning problems

using dual heuristics. Management Science 36, 674-688.
Ferris M., Rishabh J., Dirkse S. (2011). GDXMRW: Interfacing GAMS and MATLAB
Fores, S., Proll, L., Wren, A. (2001). Experiences with a flexible driver scheduler. In:
Daduna, J.Voss, S. (Eds.), Computer-Aided Transit Scheduling. Lecture Notes in
Economics and Mathematical Systems, vol. 505. Springer-Verlag, Berlin, pp. 137-152.
Freiing, R., Lentink, R.M., Odijk, M. (2001). Scheduling train crews: A case study for the
Dutch railways. In: Daduna, J., Voss, S. (Eds.), Computer-Aided Transit Scheduling.
Lecture Notes in Economics and Mathematical Systems, vol. 505. Springer-Verlag,
Berlin, pp. 153-166.
Freiing, R., Lentink, R.M., Wagelmans, A.P.M. (2004). A decision support system for
crewplanning in passenger transportation using a flexible branch-and-price
algorithm.Annals of Operations Research 127,203-222.
Gamache, M., Soumis, F. (1998).A method for optimally solving the rostering problem.
In: Yu,G. (Ed.), Operations Research in Airline Industry. Kluwer Academic, Boston, pp.
124-157.
Gamache, M., Soumis, F., Marquis, G., Desrosiers, J. (1999). A column generation
approach forlarge scale aircrew rostering problems. Operations Research 47,247-263.
García Álvarez, A. (2011). Magnitudes, unidades y conceptos básicos del transporte de

viajeros.El “Load factor” en el ferrocarril (14ª ed.)
García Álvarez A., Cillero Fernández A. y Rodríguez Jericó M.P. (1998) Operación de
Trenes de Viajeros. Claves para la gestión avanzada del Ferrocarril. Fundación de los
Ferrocarriles Españoles.
García, R. and Marín, A. (2001). Urban Multimodal Interchange Design Methodology, in

Mathematical Methods on Optimization in Transportation Systems, Ed. M. Pursula and
J.Niittymäki, Kluwer, Boston, pp: 49-79.
157
García, R. and Marín, A. (2002). Parking Capacity and Pricing in Park'n Ride Trips: A
Continuous Equilibrium Network Design Problem, Annals of Operations Research, 116,
pp: 153-178.
Hamacher, H., Liebers, A., Schöbel, A., Wagner, D., and Wagner, F. (2001).Locating New
Stops in a Railway Network, Electronic Notes in Theoretical Computer Science, 50, 11
pages.
Higgins A., Kozan E. (1998) Modeling train delays in urban networks, Transportation
Science, 32 (4), 346-357
Higgings, A., Kozan, E., Ferreira, L. (1997). Heuristic techniques for single line train
scheduling. Journal of Heuristics 3,43-62.
Ingolotti L., Lova A., Barber F., Tormos P., Salido M.A., Abril M. (2006). New heuristics to
solve the csop railway timetabling problem. Advances in Applied Artificial Intelligence.
LNAI, Subseries of Lecture Notes in Computer Science.
Jacobs, L.W., Brusco, MJ. (1995). A local search heuristic for large set-covering problems.
Naval Research Logistics 52,1129-1140.
Jovanovic, D., Harker, P.T. (1991). Tactical scheduling of rail operations: The SCAN I
system. Transportation Science 25,46-64.
J.L Tábara, (2009). Matemáticas elementales con Sage 1-4
Kroon, L.G., Dekker, R., Vromans, MJ.C.M. (2005). Cyclic railway timetabling: A
stochastic optimization approach. Technical Report ERS-2005-051-LIS, Erasmus
University Rotterdam.
Kroon, L.G., Peeters, L.W.P. (2003). A variable trip time model for cyclic railway
timetabling.Transportation Science 37,198-212.
Kroon, L.G., Romeijn, H.E., Zwaneveld, PJ. (1997). Routing trains through railway
stations: Complexity issues. EuropeanJournal of OperationalResearch 98,485-498.
158
Kwan, A., Kwan, R., Parker, M., Wren, A. (2001). Producing train driver schedules under
different operating strategies. In: Wilson, N. (Ed.), Computer-Aided Transit Scheduling.
Lecture Notes in Economics and Mathematical Systems, vol. 471. Springer-Verlag,
Berlin, pp. 129-154.
Laporte, G., Marín, A., Mesa, J.A., and Ortega, F.A. (2007). An Integrated Methodology
for the Rapid Transit Network Design Problem. Lecture Notes in Computer Science.
Algorithmic Methods for Railway Optimization, volume 4359, pp: 187-199.
Laporte, G., Mesa, J.A., and Ortega, F.A. (2002).Locating Stations on Rapid Transit
Lines,Computers & Operations Research, 29, pp: 741-759.
Laporte, G., Mesa, J.A., Ortega, F.A., and Sevillano, I. (2005). Maximizing Trip Coverage
in the Location of a Single Rapid Transit Alignment, Annals of Operations Research,
136,pp: 49-63.
Liebchen C., Möhring R. (2002). A case study in periodic timetabling, Electronic Notes in
Theoretical Computer Science, 66 (6), 1-14.
Liebchen C., Peeters L. (2002). Some practical aspects of periodic timetabling, in: P.
Chamoni et al. (Eds.), Operations Research 2001, Germany: Springer.
Liebchen C., Peeters L. (2009). Integral cycle bases for cyclic timetabling, Discrete
Optimization, 6 (1), 98-109
Lorena, L.A.N., Lopes, F.B. (1994). A surrogate heuristic for set covering
problems.European Journal of Operational Research 79,138-150.
Marín, A. (2007). An extension to Rapid Transit Network Design Problem, TOP, 15, pp:
231-241.
Morgado, E., Martins, J. (1992). Scheduling and managing crew in the Portuguese
railways. Expert Systems with Applications 5,301-321.
159
Nachtigall K., (1994). A Branch and Cut Approach for Periodic Network Programming,
Technical Report 29, Hildesheimer Informatik-Berichte.
Nachtigall K., Voget S., (1997). Minimizing waiting times in integrated fixed interval
timetables by upgrading railway tracks, European Journal of Operational Research, 103
(3), 610-627.
Pham Ngoc H. (2004). Intercity train timetable with better passenger service, Master
Thesis, Centre for Industrial Management, Catholic University Leuven, Belgium.
Rousseau, J.M. (Ed.) (1985). Computer Scheduling of Public Transport 2.North-Holland,

Amsterdam.
Ryan, D.M. (1992). The solution of massive generalized set partitioning problems in
aircrew rostering. Journal of the Operational Research Society 43,459-467.
Scholl, S. (2005).Customer-oriented line planning.PhD thesis, University of

Kaiserslautern.
Schrijver, A. (1993). Minimum circulation of railway stock.CWI Quarterly 6,205-217.
Serafini, P., Ukovich, W. (1989). A mathematical model for periodic event scheduling
problems.SIAM Journal on Discrete Mathematics 2,550-581.
Shannon, R; Johannes, J. D. (1976). «Systems simulation: the art and science». IEEE
Transactions on Systems, Man and Cybernetics 6(10). pp. 723-724.
Sweetser, A., (1999), "A Comparison of System Dynamics (SD) and Discrete Event
Simulation (DES)", Proceedings of 17th International Conference of the System
Dynamics Society and 5th Australian & New Zealand Systems Conference, Wellington,
New Zealand, 20-23 July, p. 8, The System Dynamics Society.
Vansteenwegen P., Van Oudheusden D. (2006). Developing railway timetables which
guarantee a better service. European Journal of Operational Research, 173, 337-350.
160
Voorhoeve M. (1993). Rail Scheduling with Discrete Sets, Technical Report, University of
Technology, Eindhoven, The Netherlands.
Wardman M., Shires J., Lythgoe W., Tyler J. (2004). Consumer benefits and demand
impacts of regular train timetables, International Journal of Transport Management, 2
(1), 39-49.
161

Diseño e Implementacion en Python de Un Modelo de Simulación de Horarios de Servicios Ferroviarios PDF

Cargado por

Información del documento

Título original

Derechos de autor

Formatos disponibles

Compartir este documento

Compartir o incrustar documentos

Opciones para compartir

¿Le pareció útil este documento?

¿Este contenido es inapropiado?

Copyright:

Formatos disponibles

Diseño e Implementacion en Python de Un Modelo de Simulación de Horarios de Servicios Ferroviarios PDF

Cargado por

Copyright:

Formatos disponibles

Proyecto Fin de Carrera

Diseño e implementación en Python de un

Autor: Francisco Hernández de la Torre

Tutor: Dr. José David Canca Ortiz

Autor: Francisco Hernández de la Torre

Tutor: Dr. José David Canca Ortiz

Acuerdan otorgarle la calificación de:

La planificación de redes y servicios de transporte ferroviario es una actividad de

Las inversiones necesarias para el desarrollo de las infraestructuras y el hecho de que

Este proyecto se centra en el diseño e implementación, en lenguaje Python, de una

Quisiera expresar mi más sincero agradecimiento a todos

En primer lugar agradecer a mi director de proyecto, Dr. José

También quiero agradecer a los miembros del

Especialmente, quiero agradecer a mi familia y a Lorena, por

Figura 1: Esquema general de problemas en planificación de servicios ferroviarios ....11

Tabla 1: Fichero de distancias entre estaciones .............................................................49

Diagrama de flujo 1: Calculo de la capacidad del tren....................................................61

1.1 Introducción a la planificación ferroviaria

La planificación de redes y servicios de transporte ferroviario es una actividad de

Las inversiones necesarias para el desarrollo de las infraestructuras y el hecho de que

La complejidad de los problemas asociados a la planificación del transporte

A modo de resumen se introduce a continuación una descripción de este conjunto

Figura 1: Esquema general de problemas en planificación de servicios ferroviarios

1.2 Problemas estratégicos

1.2.1 Diseño de Redes (Network Design)

El diseño de la red es el primer paso en el estudio de la planificación de

En la realidad, resulta muy difícil encontrar posibilidades para la realización de un

La inclusión de nuevas infraestructuras debe llevarse a cabo de acuerdo a una

Este tipo de problemas estratégicos se ve rodeado de numerosos aspectos

Los actores fundamentales (decisores) en esta etapa son aquellos organismos

El trabajo de Laporte et al. (2005), incorpora datos origen-destino con el fin de

García y Marín (2001, 2002) estudian el cambio de modo y el diseño de parkings

1.2.2 Planificación de Líneas (Line Planning)

Establecida la red de transporte, es necesario especificar la forma en que debe

Resulta frecuente que en proyectos como el despliegue de un metro, se discuta sobre

La visión clásica de este problema en la literatura científica consiste en plantear un

De acuerdo a la literatura científica la fase de planificación de líneas suele

Habitualmente se utiliza una matriz de demanda diaria para definir el conjunto de

Conviene citar que para la determinación de las frecuencias se consideran también

De la misma forma que la etapa anterior, la planificación de líneas es un problema

Hay un número limitado de artículos que tratan el problema de planificación de

Claessens et al. (1998) estudian el problema de encontrar un sistema de líneas de

Goossens et al. (2004) también se centran en el diseño de un sistema de líneas de

Goossens et al. (2005) consideran el problema de diseño de un sistema de líneas

número de variables de decisión, combinan y desagregan los flujos origen-destino

Recientemente, Scholl (2005) ha considerado el problema de planificación de líneas

1.3 Problemas tácticos

1.3.1 Scheduling y determinación de horarios (Timetabling)

El tercer paso en la cadena jerárquica de problemas asociados a la planificación de

El término Scheduling es más general, incluye la determinación de horarios pero

Como se ha comentado, los problemas de Scheduling incorporan decisiones

Atendiendo a estas inconveniencias y al hecho de que en muchos casos, cercanías y

El enfoque periódico considera que la definición última de los horarios corresponde

La separación entre infraestructura y servicios es ya clásica en los E.E.U.U, el caso de

Habitualmente los modelos de Scheduling ferroviario no incorporan información

Existen estudios de diversos autores que contemplan la obtención de horarios no

Los problemas de Scheduling y determinación de horarios han recibido una

instantes de salida se representan mediante variables continuas y se utilizan variables

Brannlund et al. (1998) discretizan el tiempo en intervalos de un minuto y subdividen

Oliveira and Smith (2000) modelan el problema de determinación de horarios como

recursos. Presentan un algoritmo híbrido basado en programación por restricciones

Caprara et al. (2002,2006) presentan dos modelos basados en la representación

En el caso cíclico, Schrijver y Steenbeek (1994) desarrollaron un algoritmo de