diseño e implementación en python de un modelo de...

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

Organización Industrial y Gestión de empresas I

Título: 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: José David Canca Ortiz

10

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.





11

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

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





12

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.





13

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.





14

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.





15

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.





16

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





17

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.





18

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





19

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





20

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





21

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





22

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





23

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.





24

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





25

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





26

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





27

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á





28

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





29

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





30

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.





31

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.





32

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





33

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.





34

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.





35

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





36

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.





37

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.





38

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).





39

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.





40

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.

http://www.python.org/

http://pygame.org/news.html

http://home.gna.org/oomadness/en/soya3d/index.html





41

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.

http://www.google.com.co/url?sa=t&source=web&ct=res&cd=1&ved=0CAgQFjAA&url=http%3A%2F%2Fqt.nokia.com%2Fproducts&rct=j&q=QT&ei=XDg2S6vYAZKYtgfz1fyACQ&usg=AFQjCNHvbVSZGc6lt-2HOiIGXSHp4Dy-6Q

http://www.riverbankcomputing.co.uk/software/pyqt/intro

http://www.wxwidgets.org/

http://www.wxpython.org/

http://boa-constructor.sourceforge.net/

http://boa-constructor.sourceforge.net/

http://www.panda3d.org/





42

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.

http://c2.com/cgi/wiki?DontRepeatYourself





43

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

http://es.wikipedia.org/wiki/IPython

http://es.wikipedia.org/wiki/Lenguaje_de_programaci%C3%B3n_Python

http://es.wikipedia.org/wiki/Programaci%C3%B3n_orientada_a_objetos

http://es.wikipedia.org/wiki/Programaci%C3%B3n_funcional

http://es.wikipedia.org/wiki/Maxima

http://es.wikipedia.org/wiki/SymPy

http://es.wikipedia.org/wiki/GNU_Scientific_Library

http://es.wikipedia.org/wiki/SciPy

http://es.wikipedia.org/wiki/NumPy





44

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.

http://es.wikipedia.org/wiki/Funci%C3%B3n_elemental

http://es.wikipedia.org/wiki/Funci%C3%B3n_especial

http://es.wikipedia.org/wiki/Estad%C3%ADstica

http://es.wikipedia.org/wiki/Interfaz_de_usuario

http://es.wikipedia.org/wiki/Procesamiento_de_im%C3%A1genes

http://es.wikipedia.org/wiki/Gr%C3%A1fica

http://es.wikipedia.org/wiki/CAD

http://es.wikipedia.org/wiki/GIS

http://es.wikipedia.org/wiki/N%C3%BAmeros_complejos

http://es.wikipedia.org/w/index.php?title=Aritm%C3%A9tica_de_precisi%C3%B3n_arbitraria&action=edit&redlink=1

http://es.wikipedia.org/wiki/Mathematica

http://es.wikipedia.org/wiki/Magma

http://es.wikipedia.org/wiki/Maple





45

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





46

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





47

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.





48

- 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:





49

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 6i 0,5 / ii donde el elemento i se

corresponde con la distancia entre las estaciones , 1i i

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.





50

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 ∗ 𝑁º 𝐸𝑠𝑡𝑎𝑐𝑖𝑜𝑛𝑒𝑠





51

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





52

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.





53

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.





54

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.

, ,

1,

( )0

( ) , [0, 1]1 n ij n ij

Nn ij

ij t tn

kf t i j NumEst

e





55

o ik : Constante.

o i : Pendiente de la sigmoide.

o it : 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 ( , , )ij ij ijk t 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 ( , , )ij ij ijk t ). 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.

- 1,03 0.3( 20)

100( ) [0,90]

1 tf t t

e

- 2,03 0.8( 50)

150( ) [0,90]

1 tf t t

e

- 3,03 0.3( 70)

120( ) [0,90]

1 tf t t

e

- ,03 1,03 2,03 3,03( ) ( ) ( ) [0,90]TF f t f t f t t





56

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.





57

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.





58

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





59

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.

01 02

10 12

20 21

0

0

0

X X

X X

X X

1 2

0 2

1 0

1 2

0 2

1 0

arg [ , ,0]

arg Re [0, , ]

NumEst NumEst

j i

j j

NumEst NumEst

i j

i j

PerfilC aDirecto X X

PerfilC a verso X X

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.

𝑁𝑢𝑚𝑇𝑟𝑒𝑛𝑒𝑠𝑈𝑝 = (𝐻𝑜𝑟𝑃𝑙𝑎𝑛 − 𝐷𝑒𝑠𝑓𝑈𝑝)/𝐻𝑒𝑎𝑑𝑈𝑝





60

𝑁𝑢𝑚𝑇𝑟𝑒𝑛𝑒𝑠𝐷𝑤 = (𝐻𝑜𝑟𝑃𝑙𝑎𝑛 − 𝐷𝑒𝑠𝑓𝐷𝑤)/𝐻𝑒𝑎𝑑𝐷𝑤

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’.





61

Capacidad1=max (PerfilCargaDirecto)

Capacidad2=max (PerfilCargaReverso)

If Capacidad1>Capacidad2

TrenCap=Capacidad1

TrenCap=Capacidad2

Si

No

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.





62

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.





63

𝑇. 𝑉𝑖𝑎𝑗𝑒𝑇𝑜𝑡𝑎𝑙 = 𝑉𝑒𝑙𝑜𝑐𝑖𝑑𝑎𝑑 ∗ ∑ 𝐷𝑖𝑠𝑡𝑎𝑛𝑐𝑖𝑎(𝑖)

𝑁𝑢𝑚𝐸𝑠𝑡−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:

01 02

10 12

20 21

0

0

0

X X

X X

X X

1 2

0 2

1 0

1 2

0 2

1 0

arg [ , ,0]

arg Re [0, , ]

NumEst NumEst

j i

j j

NumEst NumEst

i j

i j

PerfilC aDirecto X X

PerfilC a verso X X

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’.





64

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





65

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:





66

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.





67

Figura 7: Ejemplo trayectoria de trenes, modo 2





68

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:





69

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:

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

Tabla 6 Matriz de demandas de pasajeros entre cada par de estaciones modo 0

Tabla 7 Array de distancias entre estaciones modo 0





70

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.





71

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.





72

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.





73

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.





74

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.





75

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

2∗ (𝐿𝑒𝑎𝑣𝑒𝑇𝑖𝑚𝑒[𝑡𝑟𝑒𝑛, 𝑒𝑠𝑡] − 𝐿𝑒𝑎𝑣𝑒𝑇𝑖𝑚𝑒[𝑡𝑟𝑒𝑛 − 1, 𝑒𝑠𝑡]) + 𝑒𝑎𝑑[𝑡𝑟𝑒𝑛 − 1, 𝑒𝑠𝑡]

∗ (𝐿𝑒𝑎𝑣𝑒𝑇𝑖𝑚𝑒[𝑡𝑟𝑒𝑛, 𝑒𝑠𝑡] − 𝐿𝑒𝑎𝑣𝑒𝑇𝑖𝑚𝑒[𝑡𝑟𝑒𝑛 − 1, 𝑒𝑠𝑡])

WaitTime: Tiempo de espera en cada estación.

LeaveTime: Tiempo de salida desde cada estación.

Ead: Esperas acumuladas en cada estación.





76

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.





77

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





78

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.





79

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





80

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:





81





82





83





84





85





86

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:





87

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

Tabla 8: Matriz de demandas de pasajeros entre cada par de estaciones, modo 1

Tabla 9: Array de distancias entre estaciones modo 1





88

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





89

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.





90

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





91

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.





92

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.





93

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.





94

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.





95




estructura:





96





97





98





99





100





101





102

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.





103

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:

El fichero de horarios pasado al simulador será el siguiente:

Tabla 12: Fichero de horario.txt para el modo 2 de simulación

Tabla 11: Matriz de demandas de pasajeros, modo de simulación 2.





104

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.





105

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.





106

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.





107

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.





108

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





109

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.





110

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%.





111

Figura 25: Valores medios para el modo de simulación 2




estructura:





112





113





114





115





116





117





118

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.





119

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”





120

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.





121

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)





122

Esquema 2 Esquema 3 Atributos de la clase timetable

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





123

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.





124

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.





125

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.





126

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):





127

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:





128

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:





129

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





130

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():





131

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 ()





132

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:





133

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'





134

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]

PerfilCargaDirecto = SubenUp [est] -BajanUp [est]

For est (0,Numest):

PerfilCargaReverso = SubenDw [est] -BajanDw [est]

Exit

Diagrama de flujo 5: Función calcula_cargas (escala)





135

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’





136

class timetable (self,mod,TTfile,headUP,headDW,TrenSpeed,Desf1,Desf2,OverrideCap):

Almacena parámetros de entrada en atributos

If OverrideCap==1?

TrenCap=max(PerfilCarga)

If modo !=2 ?

TiempoViaje=long_linea/(TrenSpeed)+(NumEst-1)*DwellTime

RellenaModo2 (TTFile)

If modo ==0 ?

NumTrenesUp=(HorPlan-Desf1)/HeadUP

NumTrenesDw=(HorPlan-Desf2)/HeaDw

NumTrenesInicioUp=TiempoViaje/HeadUPNumTrenesInicioDw=TiempoViaje/HeadDw

TrenesUp=(HorPlan-Desf1)/HeadUPTrenesDw=(HorPlan-Desf2)/HeaDw

NumTrenesUp=NumTrenesInicioUp+TrenesUpNumTrenesDw=NumTrenesInicioUp+TrenesDw

self.calcula_tiempos()

No

Si

Si

No

Si

Diagrama de flujo 6: Class timetable





137

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.





138

def calcula_tiempos (self) :

Si

No

Tiempo llegada [tren=0,est=0]=Desfase inicialTiempo salida [tren=0,est=0] = Tiempo llegada [tren=0,est=0] + DwellTime

For tren (1,NumTrenes):

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

For est (0,NumEst):

Tiempo llegada [tren,est]=Tiempo llegada [tren-1,est]+HeadTiempo salida [tren,est] = Tiempo llegada [tren,est]+DwellTime

If Tiempo llegada[tren,est]<0 : If Tiempo llegada [tren,est]>0 :

Tiempo llegada tren [tren] = ANTES Tiempo llegada [tren,est] = DETRÁS

If Tiempo salida [tren,est]<0 : If Tiempo salida [tren,est]>0 :

Tiempo salida [tren,est] = DETRÁSTiempo salida [tren,est] = ANTES

Exit

No

Si

Si

Si

No

No

Diagrama de flujo 7: Método calcula_tiempos(self)





139

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





140

RellenaModo2 (self, FileTT):

if os.path.exists(FileTT): ?

Captura tiempos de llegadas [tren,est]Captura tiempos de salidas [tren,est]

Si

No

If Tiempo llegada[tren,est]==-1 : If Tiempo llegada [tren,est]>HorPlan :

Tiempo llegada tren [tren] = ANTES Tiempo llegada [tren,est] = DETRÁS

If Tiempo salida [tren,est]==-2 : If Tiempo salida [tren,est]>HorPlan :

Tiempo salida [tren,est] = DETRÁSTiempo salida [tren,est] = ANTES

No

Si

Si

Si

No No

If Tiempo llegada [tren,est]==-3 :

Tiempo llegada [tren,est] = SALTA

If Tiempo salida [tren,est]==-3 :

Tiempo salida [tren,est] = SALTO

print 'El Fichero de entrada '+FileTT+' no existe.'

Exit

Si

No


For est (0,NumEst):

Si Si

Diagrama de flujo 8: Método rellena_modo2 (self,FileTT)





141

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.





142

def calcula_llegadas (self,Escala,TipoDem) :


For est (0,NumEst):

For est (0,NumEst):

self.LastStoppedTren[est]=-3self.FirstStoppedTren[est]=0

FirstStoppedTren[est]=trenbreak

if self.tdep[tren,est]>0:


self.MatDem[tren]=self.demanda_tren(tren,sentido,Escala)

Exit

Si

No

Diagrama de flujo 9: Método calcula_llegadas(self)





143

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]





144

def demanda_tren (self,tren,sentido,Escala) :

For est (0,NumEst):

if tiempo de salida[tren,est]>0:

For Est (est+1,NumEst):

a = matriz[est,Est] / HorPlan*Tiempo de salida[tren,est]C[est,Est]=escala*a

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

Última parada tren [est]=tren

Exit

No

Si

Si

No

Diagrama de flujo 10: Método demanda_tren(self,tren,sentido,Escala)





145

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.





146

def calcula_incompletos (self) :

For tren (0,NumTren):

For est (0,NumEst):

If tiempo llegada == SALTA

If tiempo salida == DETRÁS

If tiempo salida == ANTES Incompletos[tren,est]=1

Exit

Si

Si

Si

No

No

No

If tiempo salida == TrenCortoInicio

If tiempo salida == TrenCortoFin

Incompletos[tren,est]=3




No

Si

Si

No

Diagrama de flujo 11: Función calcula_incompletos()





147

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.





148

def calcula_todo_timetable (self,Porcentaje1,Porcentaje2,TipoDem)

Self.agrega_llegadas_OD()

Rellenamos toda la matriz de plazas libres a TrenCap

For tren (0,NumTren)

For est (0,NumEst)

If tiempo de salida[tren,est]==ANTES

If tiempo de salida[tren,est]==DETRÁS

Plazas_libres[tren,est] = TrenCap*Porcentaje1/100

Plazas_libres[tren,est] = TrenCap*Porcentaje2/100

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

Si

No

Si

No

Diagrama de flujo 12: Método calcula_todo_timetable (porcentaje1, porcentaje2)





149

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.





150

Diagrama de flujo 13: Método calcula_todas_vars_timetable (porcentaje1,porcentaje2)





151

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

Total=Suma de todos los pasajeros llegados hasta el ultimo t renFO=acumulador/Total


Total+=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 HorPlanAcumulador+=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 llegados tras ultimo tren [est] +T de espera retrasos tras ultimo t ren [est]

Retraso Total= Sum_tiempos / Suma_llegadas


For est (0,NumEst)

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[tren]=>Acumulador_tiempo/Acumulador_demanda



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)

T.espera tras último tren[est]=esperas[est] * (HorPlan – t. salida del ultimo t ren[est])Acumulador+=T.espera tras último tren[est]

Diagrama de flujo 14: Método calcula_FO (self)





152

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





153

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.





154

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.





155

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.





156

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.





157

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.





158

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.





159

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.





160

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.





161

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.

diseño e implementación en python de un modelo de...

Documents