universidad de sevillabibing.us.es/proyectos/abreproy/10978/fichero/proyecto.pdfagradecimientos...

UUNNIIVVEERRSSIIDDAADD DDEE SSEEVVIILLLLAA

ESCUELA SUPERIOR DE INGENIEROS

INGENIERÍA SUPERIOR DE TELECOMUNICACION

DDEEPPAARRTTAAMMEENNTTOO DDEE OORRGGAANNIIZZAACCIIÓÓNN IINNDDUUSSTTRRIIAALL YY GGEESSTTIIÓÓNN DDEE EEMMPPRREESSAASS

DDEESSAARRRROOLLLLOO DDEE UUNN GGEENNEERRAADDOORR DDEE MMOODDEELLOOSS LLIINNEEAALLEESS PPAARRAA LLAA

CCOOOORRDDIINNAACCIIÓÓNN SSEEMMAAFFÓÓRRIICCAA MMEEDDIIAANNTTEE MMAAXXIIMMIIZZAACCIIÓÓNN DDEE

BBAANNDDAA

FRANCISCO SOLANO VELÁZQUEZ MARTÍNEZ

Agradecimientos Agradezco la ayuda que se me ha dado por parte de mi familia, mis amigos y mi

novia durante todo el tiempo que ha durado la carrera. Gracias a todos.

2

Índice

ÍNDICE

ÍNDICE.............................................................................................................................3

LISTA DE FIGURAS......................................................................................................6

LISTA DE TABLAS........................................................................................................9

1 INTRODUCCIÓN Y OBJETIVOS DEL PROYECTO..........................................10

1.1 INTRODUCCIÓN A LOS SISTIEMAS INTELIGENTES DE TRANSPORTE

(ITS)............................................................................................................................10

1.2 INTRODUCCIÓN A LA COORDINACIÓN DE SEÑALES SEMAFÓRICAS .11

1.3 DESCRIPCIÓN DEL VIARIO..............................................................................13

1.3.1 Descripción de las cajas semafóricas..................................................................17

1.4 OBJETIVOS DEL PROYECTO .................................................................................. 21

2 MODELOS DE COORDINACIÓN SEMAFÓRICA .............................................22

2.1 INTRODUCCIÓN .................................................................................................22

2.2 DESCRIPCIÓN DEL PROBLEMA ......................................................................23

2.3 DESCRIPCIÓN DE LOS MÉTODOS ..................................................................25

2.3.1. Problema básico de maximización del ancho de banda...............................25

2.3.2. Problema extendido de maximización del ancho de banda .........................29

2.3.2.1 Cálculo de la sincronización..............................................................32

2.3.3. Método multi-banda.....................................................................................33

3 MODELADO ORIENTADO A OBJETOS .............................................................37

3.1 INTRODUCCION A UML....................................................................................37

3.1.1. Breve historia de UML ................................................................................37

3.1.2. ¿Qué es UML? ¿Por qué usar UML?...........................................................39

3.2 ESPECIFICACIÓN FUNCIONAL DEL MODELO DE COORDINACIÓN ......43

3.2.1. Diagramas de casos de uso...........................................................................43

3.2.1.1 Modelo de coordinación semafórica..................................................46

3.2.1.1.1 Diagramas de caso de uso de nivel 0 o de contexto .................46

3.2.1.1.2 Diagramas de casos de uso de nivel 1 ......................................47

3.2.1.1.3 Diagramas de casos de uso de nivel 2 ......................................47

3.2.2. Diagramas de paquetes.................................................................................50

3.2.2.1 Diagramas de paquetes del algoritmo de coordinación .....................51

3.2.3. Diagrama de clases.......................................................................................52

3

Índice

3.2.3.1 Paquete de datos “Grupo semafórico”...............................................55

3.2.3.1.1 Descripción de las clases del paquete “Grupo semafórico” .....55

3.2.3.1.1.1 Clase “Estructura” .......................................................55

3.2.3.1.1.2 Clase “Código _ estructura” ........................................58

3.2.3.1.1.3 Clase “Código_señal”..................................................59

3.2.3.1.1.4 Clase “Fase” ................................................................60

3.2.3.1.1.5 Clase “Código _ fase” .................................................61

3.2.3.1.1.6 Clase “Intermedio” ......................................................62

3.2.3.1.1.7 Clase “Código _ intermedio”.......................................63

3.2.3.1.1.8 Clase “Señal _ semafórica” .........................................63

3.2.3.1.2 Diagrama de clases del paquete “Grupo Semafórico”.............66

3.2.3.2 Paquete de datos “Algoritmo coordinación” .....................................67

3.2.3.2.1 Descripción de las clases del paquete “Algoritmo

coordinación” ....................................................................................67

3.2.3.2.1.1 Clase “Signal” .............................................................67

3.2.3.2.1.2 Clase “Datos_modelo” ................................................68

3.2.3.2.1.3 Clase “Coordina_signal” .............................................70

3.2.3.2.2 Diagrama de clases del paquete “Algoritmo coordinación”.....72

3.2.3.3 Paquete de datos “Interfaz gráfica” ...................................................72

3.2.3.3.1 Descripción de las clases del paquete “Interfaz gráfica”..........72

3.2.3.3.1.1 Clase “Señal _ elegida” ...............................................72

3.2.3.3.1.2 Clase “Coordinación_interactiva” ...............................73

3.2.3.3.2 Diagrama de clases del paquete “Grupo semafórico” ..............76

3.2.3.4 Paquete de datos “Lista”....................................................................76

3.2.3.4.1 Descripción de las clases del paquete “Lista” ..........................77

3.2.3.4.1.1 Clase “Lista_inf” .........................................................77

3.2.3.4.2 Diagrama de clases del paquete “Lista” ...................................80

3.2.3.5 Paquete de datos “VCL”....................................................................80

3.2.3.6 Paquete de datos “Viario” .................................................................81

3.2.3.6.1 Descripción de las clases del paquete “Viario” ........................81

3.2.3.6.1.1 Clase “Contexto” .........................................................81

3.2.3.6.1.2 Clase “Mapa”...............................................................82

3.2.3.6.1.3 Clase “Punto” ..............................................................84

3.2.3.6.1.4 Clase “Datos _ cruce”..................................................85

4

Índice

3.2.3.6.1.5 Diagrama de clases del paquete “Viario”....................86

4 IMPLEMENTACIÓN DEL MODELO E INTERFAZ GRÁFICA.......................86

4.1 INTRODUCCIÓN .................................................................................................86

4.2 IMPLEMENTACIÓN DEL MODELO.................................................................88

4.3 INTERFAZ GRÁFICA........................................................................................104

5 PRUEBAS DEL SISTEMA .....................................................................................109

5.1 PRUEBA DE FUNCIONAMIENTO DE LA XA ...............................................109

5.1.1. Solución aportada por la XA......................................................................114

5.1.2. Solución aportada por el Solver de EXCEL ..............................................116

5.1.2.1 Funcionamiento básico del Solver...................................................117

5.1.2.2 Solución obtenida mediante el Solver .............................................121

5.2 PRUEBA DE LA APLICACIÓN SOBRE UN ESCENARIO REAL.................123

5.2.1. Prueba realizada en la avenida Carlos V....................................................125

5.2.2. Prueba realizada en la avenida Alfonso XII...............................................128

6 CONCLUSIONES Y EXTENSIONES ...................................................................133

6.1 CONCLUSIONES ...............................................................................................133

6.2 POSIBLES EXTENSIONES ...............................................................................135

7 BILIOGRAFÍA .........................................................................................................136

5

Lista de figuras

LISTA DE FIGURAS

Figura 1.3-1. Representación del viario. .........................................................................13

Figura 1.3-2. Tramos y Nodos.........................................................................................15

Figura 1.3-3. Representación de giros. ............................................................................16

Figura 1.3-4. Posibles estados de la señal semafórica.....................................................18

Figura 1.3-5. Ejemplo de caja semafórica .......................................................................19

Figura 1.3-6. Estructura de una caja semafórica .............................................................20

Figura 2.2-1. Diagrama espacio-tiempo mostrando las bandas verdes en ambas

direcciones .......................................................................................................................24

Figura 2.3-1. Geometría de las bandas verdes. Notar que ( ) ( )i,hi,h Φ+Φ debe equivaler

a un entero. ......................................................................................................................26

Figura 2.3-2. Relaciones geométricas para la formulación multi-banda.........................33

Figura 3.2-1. Notación de actores....................................................................................45

Figura 3.2-2. Notación de casos de uso. ..........................................................................45

Figura 3.2-3. Notación de relaciones...............................................................................45

Figura 3.2-4. Casos de uso de nivel 0..............................................................................46

Figura 3.2-5. Casos de uso de nivel 1..............................................................................47

Figura 3.2-6. Diagramas de casos de uso de nivel 2. Obtención de los datos .................48

Figura 3.2-7. Diagramas de casos de uso de nivel 2. Obtención de la solución..............49

Figura 3.2-8. Diagramas de paquetes del algoritmo de coordinación .............................51

Figura 3.2-9. Ejemplo de clase ........................................................................................55

Figura 3.2-10. Estructura, fases y ciclo ...........................................................................56

Figura 3.2-11. Clase “Estructura” ...................................................................................56

Figura 3.2.-12. Clase “Codigo_estructura” .....................................................................59

Figura 3.2-13. Clase “Codigo_senal” ..............................................................................59

Figura 3.2-14. Clase “Fase”.............................................................................................60

Figura 3.2-15. Clase “Codigo_fase”................................................................................61

Figura 3.2-16. Clase “Intermedio” ..................................................................................62

Figura 3.2-17. Clase “Codigo_intermedio”.....................................................................63

Figura 3.2-18. Clase “Senal_semaforica”........................................................................64

Figura 3.2-19. Diagrama de clases “Grupo semafórico”.................................................66

Figura 3.2-20. Clase “Signal”..........................................................................................67

Figura 3.2-21. Clase “Datos_modelo”.............................................................................68

6

Lista de figuras

Figura 3.2-22. Clase “Coordina_signal”..........................................................................70

Figura 3.2-23. Diagrama de clases “Grupo semafórico”.................................................72

Figura 3.2-24. Clase “Senal_elegida” .............................................................................73

Figura 3.2-25. Clase “Coordinacion_interactiva” ...........................................................74

Figura 3.2-26. Diagrama de clases “Coordinacion_interactiva” .....................................76

Figura 3.2-27. Clase “Lista_inf” .....................................................................................77

Figura 3.2-38. Diagrama de clases del paquete Lista ......................................................80

Figura 3.2-29. Diagrama de clases del paquete VCL......................................................80

Figura 3.2-30. Clase “Contexto” .....................................................................................81

Figura 3.2-31. Clase “Mapa”...........................................................................................82

Figura 3.2-32. Clase “Punto”...........................................................................................84

Figura 3.2-33. Clase “Datos_cruce” ................................................................................85

Figura 3.2-34. Diagrama de clases del paquete Viario....................................................86

Figura 4.2-1 Estructura general del programa .................................................................89

Figura 4.2-2 Extracción de una señal determinada de una caja semafórica ....................91

Figura 4.2-3 Ejemplo del formato de un archivo de entrada a la xa ..............................93

Figura 4.2-4 Método que crea el archivo que contiene el problema lineal de

coordinación ....................................................................................................................97

Figura 4.2-5 Primera parte del archivo de salida de la xa ...............................................98

Figura 4.2-6 Método que resuelve el problema lineal de coordinación ..........................99

Figura 4.2-7 Segunda parte del archivo de salida de la xa ............................................100

Figura 4.2-8 Método que procesa el archivo de salida de la xa.....................................103

Figura 4.3-1 Muestra la selección de nuestra aplicación...............................................104

Figura 4.3-2 Pantalla de selección de los nodos cuyas señales vamos a coordinar.......105

Figura 4.3-3 Aplicación que permite importar una caja a un nodo ...............................106

Figura 4.3-4 Representación gráfica de una caja semafórica asociada a un nodo.........107

Figura 4.3-5 Interfaz para la introducción de datos y presentación de resultados.........108

Figura 4.3-6 Presentación de los resultados de desfase entre las señales......................109

Figura 5.1-1 Escenario de la prueba de validez.............................................................111

Figura 5.1-2 Representación gráfica de las señales a coordinar....................................112

Figura 5.1-3 Programa lineal de maximización del ancho de banda.............................112

Figura 5.1-4 Avenida que vamos a coordinar ...............................................................115

Figura 5.1-5 Representación gráfica de la coordinación ...............................................116

Figura 5.1-6 Representación del problema en la hoja de cálculo de EXCEL ...............119

7

Lista de figuras

Figura 5.1-7 Configuración de los parámetros del Solver.............................................119

Figura 5.1-8 Agregar restricción a los parámetros del Solver.......................................120

Figura 5.1-9 Condición de no negatividad ....................................................................120

Figura 5.1-10 Resultado de la configuración de los parámetros del Solver .................121

Figura 5.1-11 Hoja de cálculo con el problema lineal de coordinación ........................122

Figura 5.2-1 Plano de las avenidas a coordinar .............................................................123

Figura 5.2-2 Señales que rigen la avenida Carlos V......................................................124

Figura 5.2-3 Modelo lineal de coordinación de la avenida Carlos V............................126

Figura 5.2-4 Resultado gráfico de la coordinación de la avenida Carlos V en la dirección

outbound ........................................................................................................................127

Figura 5.2-5 Señales que rigen la avenida Alfonso XII ................................................128

Figura 5.2-6 Modelo lineal de coordinación de la avenida Alfonso XII.......................130

Figura 5.2-7 Resultado gráfico de la coordinación de la avenida Alfonso XII en la

dirección outbound ........................................................................................................132

8

Lista de tablas

LISTA DE TABLAS Tabla 5.1-1 Datos de distancia, velocidades y cambios en la velocidad .......................111

Tabla 5.1-2 Valor de las variables en el óptimo............................................................113

Tabla 5.1-3 Valor de los datos de interés ......................................................................114

Tabla 5.2-1 Límites de velocidad, cambios de velocidad y distancia ...........................123

Tabla 5.2-2 Solución del problema lineal de coordinación de la avenida Carlos V......124

Tabla 5.2-3 Datos de interés para la coordinación ........................................................125

Tabla 5.2-4 Límites de velocidad y distancia ................................................................127

Tabla 5.2-5 Solución del problema lineal de coordinación de la avenida Alfonso XII 129

Tabla 5.2-6 Datos de interés para la coordinación de esta avenida...............................129

9

Introducción y objetivos del proyecto

1 Introducción y objetivos del proyecto.

1.1 Introducción a los sistemas inteligentes de transporte (ITS) El transporte es un motor de desarrollo económico y de bienestar general de todo

el mundo. La vida moderna exige una movilidad cada vez mayor. A menudo ésta se

consigue mediante una creciente utilización de los coches particulares. Esto implica la

multiplicación de la demanda de tráfico sobre las ya sobrecargadas infraestructuras de

transporte. A pesar de los ingentes gastos en nuevas infraestructuras viales, la

congestión del tráfico sigue aumentando. Las mejoras conseguidas anteriormente en

materia de seguridad vial y de protección del medio ambiente empiezan a perder

importancia.

Es poco probable que estos problemas puedan resolverse simplemente

construyendo más carreteras y partiendo únicamente de los enfoques del pasado. Es

evidente que se hace necesario la puesta en práctica de los sistemas inteligentes de

transporte o ITS. Los sistemas inteligentes de transporte (ITS) abarcan un gran abanico

de nuevas herramientas para la gestión de redes de transporte que prometen nuevas vías

para conseguir una movilidad duradera en nuestra sociedad de la comunicación y de la

información.

Los ITS son sistemas de transporte que aplican las tecnologías de la

información, de la comunicación y la normativa para ayudar a explotar las redes de

transporte. Las herramientas ITS, se basan en tres características fundamentales:

información, comunicación e integración. La adquisición, el tratamiento, la integración

y la difusión de la información en “tiempo real” sobre las condiciones de circulación

actuales de una red o información en línea para la planificación de un desplazamiento,

las herramientas ITS permiten a las autoridades, a los operadores y a los usuarios tomar

decisiones con mayor grado de información y de forma integrada.

Algunos sistemas ITS no son más que mejoras de sistemas antiguos, como en el

caso del control de tráfico, pero otros son completamente nuevos, como el guiado

dinámico en ruta. La mayoría son ideas que los profesionales del transporte llevan

desarrollando desde hace mucho tiempo, pero cuya implementación estaba lejos de la

10


tecnología disponible o resultaba excesivamente costosa. Lo que ITS significa como

novedad es una visión integral que alcanza lo tecnológico, financiero y organizativo,

con la correspondiente planificación y compromiso de tos los estamentos públicos y

privados implicados. ITS es una iniciativa global en respuesta a los problemas que el

transporte tiene en nuestro mundo.

1.2 Introducción a la coordinación de señales semafóricas

Como consecuencia del creciente número de vehículos, el tráfico de las ciudades

comienza a ser un grave problema. Con el fin de evitar las grandes aglomeraciones de

vehículos formadas fundamentalmente en las intersecciones reguladas por semáforos, se

trata de coordinar la sucesión de semáforos de una avenida de tal forma, que en el

intervalo en que estos están en verde pasen el mayor número de vehículos posible.

La coordinación de señales semafóricas a lo largo de una calle proporciona un

gran número de ventajas que indicamos a continuación:

• Reducción del número de paradas y reduciendo el tiempo de

viaje mediante el aumento de la velocidad en conjunto.

• Tráfico más fluido y aumento de la capacidad de la vías.

• Velocidades más uniformes animando a los conductores más

lentos a acelerar su marcha.

• Hay menos violaciones de la luz roja reduciendo el número de

colisiones.

• Mayor obediencia de las señales por parte de los peatones.

• Reducción del tráfico de las calles paralelas de menor

capacidad.

Las primeras aplicaciones empleadas para la coordinación de arterias reguladas

por semáforos es conocido como el método de progresión (FHWA, 1985). Las señales

de tráfico tienden a agrupar los vehículos en pelotones, siendo deseable que los

pelotones presente un movimiento continuo a lo largo de las diferentes señales. Bajo

tales condiciones los diagramas espacio-tiempo, donde se representa cada señal, son

11


diseñados para maximizar el tiempo en verde siempre en ambas direcciones de

circulación buscando una velocidad constante en el desplazamiento. En general este tipo

de método funciona mejor para aquellas calles o avenidas principales donde las

incorporaciones de vehículos en mitad del recorrido son insignificantes.. Bajo tal

método, una banda verde continua y uniforme es provista en cada dirección de la arteria

a la velocidad deseada de viaje, con el fin de proporcionar un movimiento continuo de

los pelotones de vehículos.

En los últimos años con el gran auge de los sistemas de información y las

comunicaciones se ha sustituido el diseño manual de diagramas de espacio-tiempo por

modelos computerizados. Existe una gran cantidad de estos modelos, entre los que

podemos nombrar están: SIGART (Metropolitan Toronto, 1965), SIGPROG (Bleyl,

1967), modelos de IBM (Brooks; Yardeni, 1964), NO-STOP-1 (Leuthardt, 1975),

PASSER-II (Messer et al., 1973), y Maximización del Ancho de banda (Morgan and

Little, 1964; Little, 1966).

Uno de los más avanzados y versátiles es el modelo de Máximo de Banda

(MAXBAND), cuya última versión fue desarrollada por Little, Kelson y Gartner en

1981. Este método permite calcular mediante un modelo de programación lineal, una

solución global óptima que maximiza el ancho de banda ambas direcciones de

circulación de la arteria. Sin embargo, la principal limitación de los programas basados

en el ancho de banda es que en el criterio de optimización (Función Objetivo) no

consideran los volúmenes y los flujos de tráfico actual en cada sección.

Consecuentemente, no es posible garantizar el modelo de progresión más adecuado para

los diferentes patrones de tráfico. Es por esto, por lo que se generó una nueva

aproximación a la optimización de la progresión a lo largo de una arteria que incorpora

un criterio sistemático dependiente del tráfico. El método genera una progresión

variable del ancho de banda, de forma que en que cada sección de carretera se obtiene

un ancho de banda individual (de aquí surge el término multi-banda). Para la

optimización se usa la programación lineal. Los resultados de las simulaciones indican

que este método produce ventajas considerables con respecto a los métodos de

progresión tradicionales.

12


El siguiente trabajo se basa en la aplicación del método de máximo de banda a la

coordinación semafórica de un área de Sevilla, dejando para futuras ampliaciones a este

trabajo el desarrollo del modelo multi-banda.

1.3 Descripción del viario

La descripción del viario consiste en la definición de los elementos que lo

componen, de forma que posteriormente se puedan diseñar las estructuras de datos

apropiadas para contener toda la información necesaria para el desarrollo del modelo.

La mayoría de los modelos definen el viario como un grafo, ( )AVG , (dirigido o no

dirigido) donde las calles están representadas mediante los arcos del grafo y las

intersecciones o cruces están representados mediante nodos del grafo.

Figura 1.3-1. Representación del viario.

13


Esta descripción, si bien es correcta y en general suficiente, no comprende a la

totalidad de los componentes de un viario, ya que este no sólo está formado por calles y

cruces, sino que existe otra serie de elementos como los contadores de vehículos, giros

definidos, cajas semafóricas... etc.

Este apartado pretende recoger los elementos más importantes que componen el

viario y los específicos para este trabajo.

• Nodos

El viario está representado por un grafo ( )AVG , que contiene un conjunto

de vértices y arcos. Los vértices también llamados nodos, representan las

intersecciones del viario. Los atributos contenidos en nodos son:

o Código del nodo. Cada nodo está identificado en la red por un código

único que lo diferencia del resto de nodos.

o Tipo de nodo. Se han considerado dos tipos de nodos:

Normales. Son nodos que representan las intersecciones o cruces

existentes en el viario.

Centroides. Nodos especiales definidos en el viario que no se

corresponden con intersecciones de calle. Son puntos desde donde

parte y llega la demanda de viajes de una determinada zona.

o Posición. Para representar gráficamente el viario es necesario dotar a

los nodos del atributo posición, que contendrá a las coordenadas del

nodo.

• Tramos.

Los tramos representan a las calles del viario. Los atributos que

caracterizan a los tramos son:

o Código del tramo. Identificación de cada calle del viario. Los tramos

suelen ser unidireccionales, es decir, representan un solo sentido de

circulación. Para representar una calle con dos sentidos serán necesarios

dos tramos.

o Nodo origen. Todos los tramos parten de un nodo, al que denominamos

nodo origen.

14


o Nodo destino. Los tramos finalizan en una intersección representada por

el nodo destino.

o Número de carriles. Espacios disponibles para el desplazamiento de

vehículos.

o Modos de transporte. Cada tramo permite la circulación de unos tipos

de vehículos (peatonal, vehículos... etc.).

o Función volumen retraso. A cada tramo se le asocia una función que

devuelva el tiempo que emplea un vehículo en recorrer el tramo en

función de la intensidad de la circulación.

o Longitud. La longitud del tramo.

Nodo

Tramo

Figura 1.3-2. Tramos y Nodos.

15


• Giros

Las intersecciones son puntos de unión de los tramos y son empleadas por

los vehículos como medio de selección del tramo que conduce a su destino

final. Las intersecciones representan el punto de unión entre tramos, pero no

todos los tramos que llegan a una intersección están comunicados a través de

ella. Las posibilidades de acceso de unos tramos a otro en una intersección

están indicadas por los giros que se definen en el nodo. Un giro habilita la

posibilidad de circulación de vehículos entre dos tramos que llegan y parten de

un nodo.

En un giro se definen los siguientes atributos:

o Número de giro. Número secuencial creciente que identifica al giro.

o Código del nodo. Nodo que identifica al movimiento.

o Tramo origen. Tramo de donde proceden los vehículos.

o Tramo destino. Tramo a donde se dirigen los vehículos.

o Función volumen retraso. A veces se incluye una función volumen

retraso para obtener el tiempo empleado en realizar el giro.

Figura 1.3-3. Representación de giros.

• Detectores

Los detectores son elementos situados en los carriles de los tramos del

viario que proporcionan datos sobre la intensidad del tráfico en dichos tramos.

Los atributos que contiene son:

o Código del detector. Código que identifica unívocamente al detector.

o Código del tramo. Código del tramo en el que está el detector.

16


o Tipo de detector. Los detectores pueden ser de varios tipos, desde

cámaras de televisión hasta los contadores por espiras.

o Flujo de vehículos. Número de vehículos que han pasado por el detector

en un intervalo de tiempo.

o Posición del detector. Posición del detector relativa al comienzo del

tramo.

o Estado del detector. Especifica si el detector está en funcionamiento,

averiado o pasivo.

1.3.1 Descripción de las cajas semafóricas

Asociado a un nodo del viario, se puede encontrar una caja semafórica que

contiene las señales que determinan el funcionamiento de los distintos dispositivos

reguladores de tráfico (semáforos) del nodo en cuestión.

Los semáforos son dispositivos físicos que restringen o conceden derecho de

paso a un conjunto de vehículos y funcionan de acuerdo a una señal que regula el

comportamiento (estado) del mismo.

Una señal describe el comportamiento de uno o varios semáforos a lo largo del

tiempo. El comportamiento de la señal es cíclico, es decir, se repite en cada cierto

intervalo de tiempo (ciclo). Las señales se agrupan para formar las cajas de señales o

estructuras que contienen todas las señales definidas que regulan el comportamiento de

los dispositivos en el nodo. Un nodo puede contener varias estructuras dependiendo del

efecto que se desea producir en la regulación del tráfico.

Todas las señales de una estructura se dividen en etapas o fases que muestran el

estado de la señal en un intervalo de tiempo. Asimismo, cada una de las fases suele

subdividirse en pequeños intervalos de tiempo que se denominan tiempos intermedios.

Los tiempos intermedios son tiempos fijos que garantizan la no ocurrencia simultánea

de cambios de rojo a verde para grupos diferentes. Su misión es principalmente la de

establecer breves intervalos de tiempo de seguridad, con el objetivo de evitar conflictos

entre los primeros vehículos que atraviesan la línea de detención asociada a la señal para

un grupo que acaba de recibir derecho de paso y los últimos vehículos correspondientes

17


a los que se les ha suprimido este derecho. Con frecuencia, los tiempos intermedios

contienen el tiempo en ámbar asignado a los diferentes grupos. Cada etapa queda

entonces definida por un conjunto de tiempos intermedios, de longitud fija y en igual

número para todos los grupos, y un tiempo de longitud variable asignado a la fase.

El estado de la señal viene determinado por el color que puede tomar la fase o

bien el tiempo de intermedio. Los posibles estados de la señal son:

Figura 1.3-4. Posibles estados de la señal semafórica

A modo de ejemplo, a continuación se muestra una estructura formada por ocho

señales. Cada una de dichas señales se encuentra dividida en tres fases, las dos primeras

de ellas disponen de cuatro tiempos intermedios, mientras que la última fase tiene cinco

tiempos intermedios, tanto los de una fase como los de otra se encuentran ubicados al

final de las mismas.

18


Figura 1.3-5. Ejemplo de Caja Semafórica

Los datos que permiten la representación de la caja como la del ejemplo de la

figura 1.3-5, se almacenan en archivos cuya estructura se explica a continuación:

19


Figura 1.3-6. Estructura de una caja semafórica

En primer lugar, se indica el nombre de la calle en la que se encuentra ubicado el

nodo al que esta asociado la caja, después se indica el número del nodo que lo identifica

dentro del viario, a continuación se puede ver el número de estructuras que contiene la

caja. El siguiente dato es el ciclo de las señales de la estructura y si los tiempos que en

la caja aparecen vienen expresados en porcentaje de tiempo de ciclo,”P” o en tiempo

(segundos) “T”. Además, se dice si los intermedios de los que puede constar una fase de

la señal se encuentran al final de la fase, “P” o al principio de la misma, “T”. En la

siguiente línea se indica la estructura a la que pertenece los datos de tiempo de ciclo, de

número de fases, tiempos de fases e intermedios y colores de los mismos, y a

continuación, se expresa el número de fases de las que se compone las señales de dicha

estructura. La sucesión de datos que aparecen ahora expresan el tiempo de las fases y

de los intermedios y que según si éstos van delante o detrás, el primer o último valor

corresponde con el de la fase y el resto con los de los intermedios. Debajo de estos datos

20


se indica el número de señales presentes en la caja y continuación el código de colores

de las fases y los intermedios que conforman cada señal.

Estos datos no sólo sirven para la representación gráfica de las señales como se

ha explicado más arriba, si no que también van a servir para la construcción del modelo

lineal de maximización de ancho de banda en verde.

1.4 Objetivos del proyecto

El objetivo del siguiente trabajo es el desarrollo de un entorno donde se provea a

los ingenieros de tráfico de las herramientas para la obtención de una buena

coordinación de las señales luminosas de tráfico, es decir, maximizar el número de

vehículos que atraviesan, sin realizar ninguna parada, una avenida regulada por

semáforos.

La coordinación semafórica se obtendrá mediante la aplicación y resolución de

un modelo de programación lineal que tiene en cuenta el flujo de tráfico en ambas

direcciones, así mismo mediante un factor modificador (k), es posible dar mayor

prioridad a los vehículos de una dirección de la avenida con respecto a los de la otra.

También es importante considerar las velocidades de los vehículos en cada tramo de la

avenida y la brusquedad del cambio de las mismas de un tramo a otro.

Como parte de los objetivos, se tratará de integrar las librerías comerciales de

optimización lineal XA, a las que se le llamarán para la resolución del problema lineal y

para la obtención de los resultados.

Finalmente el sistema desarrollado será integrado en una aplicación más general,

TRAMOS (Traffic and Transport Análisis, Modeling and Optimization System), que

comprende diversas herramientas para la gestión del tráfico y la planificación del

transporte en núcleos urbanos. Dicha integración se realizará mediante una interfaz

gráfica basada en las ventanas, de forma que el usuario pueda resolver el problema de la

coordinación, sin necesidad de tener conocimientos algunos acerca de la programación

lineal, es decir, esto es transparente para el usuario.

21

Modelos de coordinación semafórica

2 Modelos de coordinación semafórica.

2.1 Introducción

El método más extendido para la coordinación de una arteria, tanto en Estados

Unidos como en otros países, es el método de progresión. Las señales de tráfico

tienden a formar pelotones de vehículos de forma progresiva. El efecto de formación de

pelotones se acentúa en las avenidas donde la presencia de señales semafóricas en las

intersecciones es más frecuente. En estas circunstancias, parece deseable conseguir un

movimiento continuo y constante de los pelotones de vehículos a través de las señales

de tráfico. Para conseguirlo, se diseñan los tiempos de las señales de forma que se

maximice el ancho de la banda continua de verde en las dos direcciones de la avenida

con velocidades de viaje programadas. En general, estos sistemas de diseño de tiempos

funcionan mejor cuando los flujos de vehículos predominantes son los directos y el

número de vehículos procedentes de las calles anexas a la avenida es pequeño.

En los últimos años el gran auge y crecimiento de los sistemas informáticos ha

permitido el diseño de diagramas espacio tiempo mediante modelos computerizados. Se

desarrollaron una larga variedad de modelos tales como SIGART (Metropolitan

Toronto, 1965), SIGPROG (Bleyl, 1967), los modelos de IBM (Yardani, 1964), NO-

STOP-1 (Leuthardt, 1975), PASSER-II (Messer, 1973), y Bandwidth Maximization

(Morgan y Little, 1964; Little, 1966). Los avances en las técnicas de optimización y la

capacidad computacional han permitido que los modelos sean cada vez más

sofisticados. El modelo más avanzado y versátil de todos es el modelo de ancho de

banda (MAXBAND) descrito por Little, Kelson y Gartner en 1981. Este modelo usa

toda la fuerza de los modelos de optimización permitiendo determinar una solución

óptima global así como el ciclo, los desfases, las velocidades de progresión y los

cambios de fase de manera que se maximice el ancho de banda en verde(tiempo mínimo

que permita a un conductor que parte del comienzo de la calle atravesarla en el menor

tiempo posible) para ambas direcciones de la avenida.

En los últimos años, la Administración Federal de Carreteras de los Estados

Unidos (FWHA), ha estado promoviendo la optimización de las señales de tráfico en las

áreas urbanas, como consecuencia se desarrolló un método de optimización basado en el

22


retraso, TRANSYT-7F (Wallace, 1981). El objetivo es obtener unos flujos de tráfico

para la avenida más refinados que los permitidos por el TRANSYT. Otros métodos

fueron propuestos por Wallace y Courage como combinación de los métodos basados

en la minimización de los retrasos y los basados en la maximización del ancho de

banda, donde se aprovechaban las ventajas de uno y otro método. Los métodos que

nosotros desarrollaremos a continuación combinan las ventajas de unos y otros.

2.2 Descripción del problema

Una de las limitaciones básicas que existen en los programas basados en el

ancho de banda es que los criterios de diseño no dependen de los flujos de tráfico

actuales en los cruces de la avenida y por lo tanto, son muy sensibles a las variaciones

en dichos flujos. El ancho de banda obtenido se puede distribuir según se desee en

distintas proporciones en cada una de las direcciones de la avenida, esto se puede

realizar variando el valor de la razón de volumen direccional, k. La elección de este

parámetro de un modo u otro no asegura la mejor progresión de los flujos de tráfico.

Se define ahora el problema de coordinación: se considera una avenida con dos

direcciones que está regulada por n señales de tráfico. Las direcciones se identificarán

como inbound (“de entrada”) y outbound (“de salida”). Las señales se denotarán por

donde el subíndice crece en la dirección outbound. La siguiente figura

muestra un diagrama espacio-tiempo del viaje a lo largo de una avenida.

n21 S,,S,S K

23


( 1 )

( 2 )

Figura 2.2-1. Diagrama espacio-tiempo mostrando las bandas verdes en ambas

direcciones.

Las líneas rojas indican cuando están las señales en rojo. Las líneas en zigzag (1)

y (2) indican las trayectorias de los vehículos en su paso sin interrupciones por la

avenida en la dirección señalada. Los cambios de pendiente corresponden con cambios

en la velocidad. La posible definición de trayectorias sin interrupciones en una

dirección determinada forma la banda verde, cuyo grosor determina el ancho de banda

para esa dirección. Aunque sólo se haya dibujado una vez, la banda verde ocurre una

vez por ciclo, formando una sucesión de bandas paralelas a lo largo del diagrama.

Ciertas señales forman la última limitación del ancho de banda, a estas señales

se les denomina señales críticas. A una señal cualquiera se le denomina crítica si un

lado de uno de sus rojos toca la banda verde en una dirección y otro lado toca la banda

verde en la otra dirección. Un ejemplo de señales críticas lo encontramos en las señales

y de la figura 2.2-1.

jS

iS hS

24


Para desarrollar el método multi-banda, es necesario describir el problema

básico de maximización del ancho de banda y después se amplia añadiendo variables

de decisión. De todos los modelos de programación lineal entera-mixta existente en la

literatura, solo se describen tres modelos donde partiendo de un modelo inicial la

complejidad irá creciendo progresivamente. El primero, MILP-1 (Mixed Integer

Linear Programming), es el básico, simétrico y de ancho uniforme; el segundo, MILP-

2, a diferencia del primero incluye anchos de banda asimétricos en direcciones

opuestas, especificación de la velocidad entre los distintos cruces de la avenida y

determinación de la longitud del ciclo. El tercero, MILP-3, presenta el nuevo método

multi-banda, el cual nos permite incorporar previamente todas las variables de

decisión.

2.3 Descripción de los métodos

2.3.1 Problema básico de maximización del ancho de banda

El siguiente método sería el procedimiento más directo si no fuera por las

restricciones enteras, sin embargo, dichas restricciones son necesarias puesto que las

bandas verdes para ambas direcciones han de guardar una relación especial para cada

señal. Obviamente, cada banda verde transcurre a través de un tiempo en verde de una

señal determinada y, entre los tiempos en verde ocurren un número entero de ciclos, por

lo que una restricción entera es creada por cada señal. En este trabajo se desarrollan las

restricciones de forma general y luego se especializan para una avenida concreta.

25


Figura 2.3-1. Geometría de las bandas verdes. Notar que ( ) ( )i,hi,h Φ+Φ debe equivaler

a un entero.

Sean y dos señales tales que sigue a en la dirección outbound.

Referido a la figura 2.3-1 tenemos:

hS iS iS hS

= tiempo en rojo de la señal en la calle bajo estudio, se expresa en

tiempo de ciclo.

ir iS

( )bb = ancho de banda en la dirección outbound (inbound) en tiempo de

ciclo.

( ) ( )[ i,hti,ht ] = tiempo de viaje de a en la dirección outbound (tiempo de viaje

de a en la dirección inbound) en tiempo de ciclo.

hS iS

iS hS

( ) ( )[ i,hi,h ΦΦ ] = tiempo desde el centro de un rojo de al centro de un rojo particular

de . Los rojos se elegirán de tal forma que sean los que están

inmediatamente a la izquierda (derecha) de la misma banda verde en

la dirección outbound (inbound).

hS

iS

( ii ww ) = tiempo desde el borde derecho (izquierdo) del rojo hasta la banda

verde en la dirección outbound (inbound) en tiempo de ciclo.

( ) ( ) ( )i,hi,hi,hm Φ+Φ= (1)

26


Todas las cantidades que tienen dimensiones de tiempo se pueden expresar en

tiempo de ciclo con tan sólo dividir su valor por el periodo de la señal.

De la figura 2.3-1 podemos identificar las siguientes identidades:

( ) ( )i,hr21wi,htwr2

1iihh Φ=−−++ (2a)

( ) ( )i,hr21wi,htwr2

1iihh Φ=−−++ (2b)

El valor de ( i,h )Φ y ( i,hΦ ) forman una restricción importante en la que la su

suma debe ser igual a un entero, puesto que de otro modo no seria restricción.

( ) ( ) ( ) ( ) ( ) ( )ihiihh rri,hmi,hti,htwwww −−=+++−+ , (3)

( ) =i,hm entero.

Hasta ahora se ha requerido que siguiera a en la dirección outbound, pero

esta restricción puede ser eliminada si se define apropiadamente el parámetro t (h,

i). Por razones físicas mantendremos la relación:

iS hS

( ) ( ) ( );j,iti,htj,ht += (4a)

de donde, igualando h = j, obtenemos

( ) ( i,hth,it −= ) (5a)

y un argumento parecido se aplica para ( )i,ht . Por consiguiente, ( ) ( )[ ]l,ktl,kt es

la magnitud contraria del tiempo de viaje de a en la dirección outbound. lS kS

27


Ahora manteniendo (2) y (3) para unas señales arbitrarias y y iS hS

( ) ( ) ( j,ii,hj,h Φ+Φ=Φ ) (4b)

( ) ( ) ( j,imi,hmj,hm += ) , (4c)

( ) ( )i,hh,i Φ−=Φ , (5b)

( ) ( )i,hmh,im −= , (5c)

manteniendo las correspondientes expresiones para Φ .

De la figura 3.3-1 también podemos deducir que:

ii r1bw −≤+ , (6a)

ii r1bw −≤+ . (6b)

El modelo puede ser simplificado mediante la definición:

( 1i,ixx i += ) , (7)

para

m,,,t,tx ΦΦ= .

El problema básico puede ser presentado por un programa lineal entero-mixto.

Las restricciones (6) son necesarias para cada señal y la restricción (3) para cada par de

señales adyacentes.

28


LP1

Encontrar b, , iw iw , para im

max b,

sujeto a:

⎭⎬⎫

−≤+

−≤+

,r1bw

,r1bw

ii

ii ( )n,...1i = ( )( )b8

a8

( )ii ww +

( ) ( ) ( )

⎭⎬⎫

=−−=+++− +++

,egerintm,rrmttww

i

1iiiii1i1i ( )1n,...,1i −= (9)

.0w,w,b ii ≥

LP1 tiene 3n – 1 restricciones y 3n variables, sin contar con las variables de

holgura y las variables artificiales. El número de variables enteras es de n-1.

2.3.2 Problema extendido de maximización del ancho de banda

El problema básico descrito en el anterior apartado es ampliado en éste por la

adicción de un número importante de variables de decisión para la mejora del control

del tráfico. La primera extensión concierne a la carga direccional de ambas bandas. En

muchos casos se desea favorecer una dirección de tráfico sobre la otra (p.e: la dirección

inbound durante el pico que se produce por la mañana y la dirección outbound durante

el pico que se produce durante la tarde). Tomaremos k = relación de proporción entre el

ancho de banda en la dirección inbound y la dirección outbound.

A continuación, se considera el periodo y la velocidad como variable. Cada una

está restringida por límites superiores e inferiores. Además, se limitarán los cambios en

la velocidad de un segmento de la calle al siguiente. Finalmente, como se ha descrito

anteriormente, los anchos de banda en ambas direcciones no serán iguales si no que uno

será una proporción fija del otro.

29


La solución a este problema es proporcionada mediante la resolución del modelo

de programación lineal que es generado automáticamente por el sistema para el

conjunto de señales semafóricas en una avenida determinada.

Los parámetros y variables son:

k = constante de proporcionalidad entre b y b .

T = periodo de la señal en segundos.

, = límites inferiores y superiores del periodo, p.e: 1T 2T

21 TTT ≤≤ , en segundos.

z = frecuencia de la señal en ciclos por segundos.

d (h, i) = distancia entre y en metros. hS iS

= d (i, i + 1). id

( )ii vv = velocidad entre y en la dirección outbound ( y

en la dirección inbound) en metros por segundo.

iS 1iS + 1iS +

iS

, (ie if ie , if ) = límites superiores e inferiores de velocidad en la dirección

outbound (inbound) en metros por segundo.

1/ , 1/ (1/ih ig ih , 1/ ig ) = límites superiores e inferiores en los cambios del recíproco

de la velocidad en la dirección outbound (inbound), p.e:

( ) ( ) ( )ii1ii g1v1v1h1 ≤−≤ + , en metros por segundo a

la menos uno.

Los cambios en la velocidad son restringidos mediante la imposición de límites

superiores e inferiores en la velocidad recíproca. Aunque con esto no se consigue

exactamente restringir los cambios en la velocidad, seguramente satisface la intención

básica, que no es otra que la de obtener un método de prevención para los cambios

abruptos en la velocidad. La razón por la cual se trabaja con la velocidad recíproca es

como consecuencia que aparece de forma lineal en las restricciones y por tanto, se

puede transformar en , de este modo: it

( ) ,zvdt iii = ( ) ,zvdt iii = (10)

30


En el modelo extendido , it it y z son variables de decisión, la cuales, una vez

conocidas permiten determinar las velocidades.

LP2

Encontrar b, b , z, , iw iw , , it it , para im

( )bbmax + ,

sujeto a:

kbb = , (11)

12 T1zT1 ≤≤ , (12)

⎭⎬⎫

−≤+

−≤+

,r1bw,r1bw

ii

ii ( )n,...,1i = ( )( )b13

a13

( ) ( )( ) ( )

( ) ( )( ) ( ) ⎪

⎪⎪

⎭

⎪⎪⎪

⎬

⎫

≤≤

≤≤=

−−=++

+−+

+

++

,zedtzfd,zedtzfd

,egerintm,rrmtt

wwww

iiiii

iiiii

i

1iiiii

1i1iii

( )1n,,1i −= K ( )( )( )b15

a1514

( ) ( ) ( )( ) ( ) ( ) ⎭

⎬⎫

≤−≤

≤−≤

++

++

,zgdttddzhd

,zgdttddzhd

iii1i1iiii

iii1i1iiii ( )2n,,1i −= K ( )( )b16

a16

0w,w,b,b ii ≥

LP2 contiene (11n – 10) restricciones y 5n variables, sin contar las variables de

holgura ni las artificiales. El número que de estas variables serán enteras es de n-1.

31


2.3.2.1 Cálculo de la sincronización

Las variables lineales del programa determinan la sincronización de las señales.

Definimos

)i,h(θ = fase relativa (offset) de y , medida como el tiempo del hS iS

centro de un rojo de al centro del rojo siguiente de , hS iS

expresado en tiempo de ciclo.

Una ilustración de lo que es )i,h(θ se nos da en la figura 3.3-1. Asumiremos que

se verifica la siguiente expresión 1)i,h(0 <θ≤ . A los valores de )i,1(θ , i = 2,….,n los

llamaremos sincronización de las señales.

Para simplificar expresiones explícitas de θ , definimos, para x real y arbitrario:

[ ] xmayorenteroelxint ≤= ,

[ ] [ ]xintxxman −= . (14)

De esta forma, por ejemplo, int [5.2] = 5, man [5.2] = 0.2, int [-1.3] = -2,

man [-1.3] = 0.7.

De la figura 3.3-1 podemos ver que

[ ])i,h(man)i,h( φ=θ , (15)

y, usando (2a), (4a), y (7), obtenemos

(16) ⎥⎦

⎤⎢⎣

⎡−++−=θ ∑

−

=

1i

1ki1ki1 )rr)(2/1(twwman)i,1(

Los desfases entre una señal y el resto queda definidos por la expresión anterior.

32


2.3.3 Método multi-banda

El método multibanda se caracteriza por definir distintos anchos de bandas para

los diferentes tramos que componen la arteria (en ambas direcciones).

Cada ancho de banda es una proporción de la función objetivo total.(Nota: La

banda es continua; sólo la anchura puede variar). De esta manera, se tiene un método

que es sensible a la variación de las condiciones del tráfico y puede adaptar el esquema

de progresión a los diferentes flujos de tráfico posibles del modelo. El usuario puede

también elegir una progresión uniforme del ancho de banda si así lo desea, pero esto

sólo es una opción de las muchas disponibles para el usuario.

Figura 2.3-2. Relaciones geométricas para la formulación multi-banda.

La figura 2.3-2, permite definir las siguientes variables:

( )ii bb = ancho de banda de la dirección outbound (inbound) entre las señales

y ; ahora hay una banda específica para cada tramo de la avenida

en ambas direcciones.

iS

1iS +

33


( ii ww ) = Tiempo desde el borde derecho (izquierdo) de un rojo de la señal a

la línea central de la banda verde de la dirección outbound.

iS

Las siguientes restricciones se aplican en la dirección outbound para la señal : iS

( ) iii r1b21w −≤+ (17)

( ) 0b21w ii ≥− . (18)

El par de restricciones pueden ser combinadas de la siguiente forma:

( ) ( ) ( ) iiii b21r1wb21 −−≤≤ . (19)

Debe haber una relación parecida para , ya que la banda debe ser

restringida en ambos extremos:

1iS + ib

( ) ( ) ( ) i1i1ii b21r1wb21 −−≤≤ ++ . (20)

Las correspondientes relaciones existen en la dirección inbound (marcadas con

una raya sobre las variables):

( ) ( ) ( ) iiii b21r1wb21 −−≤≤ (21)

( ) ( ) ( ) i1i1ii b21r1wb21 −−≤≤ ++ . (22)

Estas restricciones se denominarán restricciones de interferencia direccional.

Notar que redefinimos la referencia de tiempo a los puntos de la línea central de las

bandas (o, la línea progresiva), más que a los bordes, la restricción dada por la ecuación

(3) permanece invariable y lo mismo ocurre con las restricciones del tiempo de viaje y

cambios de velocidad.

La restricción de la proporción (11) se modifica también para reflejar la

situación de la multi-banda:

( ) ( ) iiiii bkk1bk1 −≥− (23)

donde, proporción entre el ancho de banda de la dirección inbound y la outbound

en la sección i (tomada de la proporción correspondiente del volumen en cada

dirección).

=ik

34


El cambio más importante tiene lugar en la función objetivo. Ya que para los

tramos específicos de las bandas, podemos ponderar gradualmente el peso de cada uno

para reflejar los objetivos deseados en el tráfico de cada enlace. De esta forma, la

nueva función objetivo tiene la siguiente forma:

(∑−

=

+−

=1n

1iiiii baba

1n1BMAX ) (24)

donde ( )ii aa son los pesos de cada tramo específico en las dos direcciones. Hay

multitud de opciones disponibles para determinar los coeficientes de peso. Escogemos

investigar las siguientes opciones de carga: p

i

iia ⎟⎟

⎠

⎞⎜⎜⎝

⎛ζν

= p

i

iia ⎟⎟

⎠

⎞⎜⎜⎝

⎛ζν

=

donde,

( )ii νν = volumen direccional en la sección i, outbound (inbound); del volumen

total o del total que puede ser usado.

( )ii ζζ = flujo de saturación en la sección i, outbound (inbound)

p = poder exponencial; p puede tomar los valores p= 0,1,2,4.

Para obtener un valor de la función objetivo de acuerdo con las usadas

previamente, normalizamos el peso de los coeficiente para obtener

∑−

=−=

1n

1ii 1na ; ∑

−

=−=

1n

1ii 1na

El programa de optimización de la multi banda está resumido en MILP-3.

35


MILP - 3. Encontrar iiiiiiiii m,,,t,t,w,w,z,b,b δδ en

(∑−

=+

−=

1n

1iiiii baba

1n1BMAX ) (25)

Sujeto a

( ) ( ) iiiii bkk1bk1 −≥− (26)

12 C1zC1 ≤≤ (27)

( ) ( ) ( )( ) ( ) ( )( ) ( ) ( )( ) ( ) ( ) ⎪

⎪⎭

⎪⎪⎬

⎫

−−≤≤

−−≤≤

−−≤≤−−≤≤

++

++

i1i1ii

iiii

i1i1ii

iiii

b21r1wb21b21r1wb21

b21r1wb21b21r1wb21

1n,,1i −= K (28)

( ) ( ) ( ) i1i1i1i1iiiiiii1i1iii mllllttwwww −δ+δ−δ−δ++++−+ ++++++ (29)

( ) ( iii1i rr τ+τ )+−= + , 1n,,1i −= K

( ) ( )( ) ( ) ⎭

⎬⎫

≤≤

≤≤

zedtfd

zedtfd

iiiii

iiiii 1n,,1i −= K (30)

( ) ( ) ( )( ) ( ) ( ) ⎭

⎬⎫

≤−≤

≤−≤

++

++

zgdttddhd

zgdttddhd

iii1i1iiii

iii1i1iiii 2n,,1i −= K (31)

0t,t,w,w,z,b,b iiiiii ≥

im entero

ii , δδ cero/una variables

MILP-3 contiene (18n – 20) restricciones y (6n-3) variables continuas, hasta 2n

cero/una variables y n-1 variables enteras no restringidas, sin contar las variables de

holgura. De estas variables n-1 serán enteras.

Además, las restricciones del borde izquierdo en iδ y iδ deben añadirse hasta

un total de 2n. Las divisiones verdes y rojas están determinadas de la misma forma que

en MILP-2.

36

Modelado orientado a objetos

3 Modelado orientado a objetos 3.1 Introducción a UML

En este apartado se va a hacer una revisión de cómo surge, qué es y por qué se

utiliza el Lenguaje de Modelado Unificado (UML). Este lenguaje es una especificación

de notación orientada a objetos y se emplea para modelar el sistema y representar las

distintas relaciones entre los componentes del mismo.

3.1.1 Breve historia de UML

Los lenguajes de modelados orientados a objetos aparecieron a mediados de los

70 y finales de los 80, influidos por técnicas como los modelos de Entidad/Relación y el

Specifications & Description Language (SDL, circa 1976, CCITT), como diversas

metodologías que se aproximaban al análisis y diseño orientado a objetos.

El número de lenguajes de modelado sufrió un espectacular incremento entre los

años 1989 y 1994, llegando a identificarse hasta 50 lenguajes diferentes con los

problemas que esto conllevaba para los usuarios. A mediados de los 90 aparecieron

nuevas interacciones entre los diferentes métodos, destacando el Booch’93, la evolución

del OMT (Object Modeling Techniques) y Fusion. Los métodos empezaron a incluir

técnicas unos de los otros, predominando un pequeño grupo de ellos, incluyendo el

OOSE (Object Oriented Software Engineering), OMT-2 y el Booch’93. Cada uno de

ellos era un método completo con sus puntos fuertes y flaquezas.

Simplificando, OOSE era un lenguaje que se orientaba hacia los casos de uso,

dando un excelente soporte para los análisis de requerimientos en la ingeniería. OMT-2

era especialmente adecuado para el análisis de sistemas de información y bases de

datos. Finalmente Booch’93 destacaba por su utilidad en las fases de diseño y

construcción de proyectos, llegando a ser muy popular para el desarrollo de proyectos

de ingeniería.

Con este panorama, en Octubre del 94, comenzó el desarrollo del UML cuando

Grady Booch y Jim Rumbaugh, del grupo Rational Software Corporation, comenzaron

un trabajo conjunto para unificar los métodos Booch y OMT. Se daba el caso de que los

37


métodos Booch y OMT estaban conocidos en todo el mundo como los líderes entre los

métodos de modelado orientados a objetos, por lo que Booch y Rambaugh unieron sus

esfuerzos para unificar sus trabajos. Un primer boceto (versión 0.8) del Unified Method,

como fue llamado entonces, se dio a conocer en Octubre del 95. A finales de 1995, Ivar

Jacobson y su compañía de unieron a Rational y a su esfuerzo por unificar el lenguaje,

aportando lo ya desarrollado en el OOSE.

Los autores de los métodos Booch, OMT y OOSE (Grady Booch, Jim

Rumbaugh e Ivar Jacobson), estaban por lo tanto decididos a crear un lenguaje

unificado de modelado por tres razones:

• En primer lugar, los métodos se estaban desarrollando unos

independientemente de los otros. Era de sentido común continuar la

evolución conjuntamente mejor que por separado, eliminando la

posibilidad de crear diferencias innecesarias que posteriormente podrían

confundir a los usuarios.

• Por otro lado, unificar la nomenclatura y la semántica traería estabilidad

al mercado de los lenguajes orientados a objetos, permitiendo que los

proyectos se centraran en un solo lenguaje, dejando a los desarrolladores

de herramientas crear mejor aplicaciones.

• Finalmente, ellos esperaban que su colaboración pudiera conllevar

importantes mejoras en los tres métodos, de forma que se pudieran

abarcar nuevos problemas que ninguno de los tres métodos originales

resolvía adecuadamente.

Cuando de comenzó la unificación, se establecieron cuatro objetivos

primordiales en los que centrar sus esfuerzos:

• Permitir el modelado de sistemas, y no solo de software, usando

conceptos de la orientación hacia objetos.

38


• Modelar el sistema, desde el concepto hasta los artefactos ejecutables,

utilizando técnicas orientadas a objetos.

• Cubrir las cuestiones relacionadas con el tamaño inherente a los sistemas

complejos y críticos.

• Crear un lenguaje de modelado utilizable tanto por las personas como

por las maquinas.

En Junio de 1996 se publicaron las versiones 0.9 y 0.91. Durante ese año los

autores invitaron, y recibieron respuesta, de toda la comunidad internacional relacionada

con el tema. Además, varias corporaciones vieron el UML como un punto estratégico en

el desarrollo de sus actividades. Algunas de las empresas contribuyeron a la aparición

de la versión 1.0 en Enero de 1997 fueron IBM, Hewlet-Packard, Dell, Texas

Instruments... Esta versión fue ofrecida a la OMG (Object Management Group) para su

estandarización, en respuesta a su solicitud de propuestas para un lenguaje estándar de

modelado.

Entre Enero y Julio de 1997, el grupo inicial de colaboradores se amplió para

incluir prácticamente a todas las organizaciones que habían aportado algo al proyecto,

creándose un grupo de trabajo liderado por Cris Kobryn para trabajar en la semántica.

Como resultado se le entregó a la OMG la versión 1.1 para su estandarización en Julio

de 1997. Esta versión se aceptó el 14 de Noviembre de 1997 por la OMG.

El control del mantenimiento de UML fue asumido por la OMG Revision Task

Force, dirigida por Cris Kobryn. La RTF publicó una revisión editorial, UML 1.2, en

Junio de 1998. En otoño de 1998 la RTF publicó UML 1.3, que es la versión utilizada

en este proyecto.

3.1.2 ¿Qué es UML? ¿Por qué usar UML?

UML es un lenguaje estándar para escribir planos de software. Se puede utilizar

para especificar, construir y documentar los artefactos de un sistema que involucran

una gran cantidad de software.

39


UML es apropiado para modelar desde sistemas de información de empresas,

hasta aplicaciones distribuidas basadas en la web, e incluso para sistemas empotrados de

tiempo real muy exigentes. Es un lenguaje expresivo, que cubre todas las vistas

necesarias para desarrollar y luego desplegar tales sistemas.

UML es sólo un lenguaje, por lo tanto es tan sólo una parte de un método de

desarrollo de software. Es independiente del proceso, aunque para utilizarlo

óptimamente se debería usar en un proceso que fuese dirigido por los casos de uso,

centrado en la arquitectura, iterativo e incremental.

En general, UML es un lenguaje para visualizar, especificar, construir y

documentar los artefactos de un sistema con gran cantidad de software.

Como lenguaje, UML proporciona un vocabulario y unas reglas para combinar

las palabras de dicho vocabulario con el objetivo de posibilitar la comunicación. Un

lenguaje de modelado es un lenguaje cuyo vocabulario y reglas se centran en la

representación conceptual y física del sistema. Un lenguaje de modelado como es UML

es, por tanto, un lenguaje estándar para los planos de software.

El modelado proporciona una comprensión de un sistema. Nunca es suficiente

un único modelo. Más bien, para comprender cualquier cosa, a menudo se necesitan

múltiples modelos conectados entre sí, excepto en los casos más triviales. Para sistemas

con gran cantidad de software, se requiere un lenguaje que cubra las diferentes vistas de

la arquitectura de un sistema mientras evoluciona a través del ciclo de vida del desrrollo

del software.

El vocabulario y las reglas de un lenguaje como UML indican cómo crear y leer

modelos bien formados, pero no dicen qué modelos se deben crear ni cuándo se

deberían crear. Ésta es la tarea del proceso del desarrollo del software. Un proceso bien

definido guiará a su usuario a decidir qué artefactos producir, qué actividades y personal

se emplean para crearlos y gestionarlos, y cómo usar estos artefactos para medir y

controlar el proyecto de forma global.

40


Para muchos programadores, la distancia entre pensar en una implementación y

transformarla en código es casi nula. Lo piensas, lo codificas. De hecho, algunas cosas

se modelan mejor directamente en código. En este caso, el programador todavía está

haciendo mentalmente algo de modelado, si bien lo hace de forma totalmente mental.

No obstante, esta manera de proceder plantea algunos problemas:

• Primero, la comunicación de estos modelos conceptuales se torna

complicada y está sujeta a errores, salvo que las dos partes hablen el

mismo lenguaje. Normalmente, los proyectos y las organizaciones

desarrollan su propio lenguaje, y es difícil comprender lo que está

pasando para alguien ajeno al grupo.

• Segundo, hay algunas cuestiones en un sistema de software que no se

pueden entender amenos que se construyan sobre modelos que

trasciendan el lenguaje de programación textual. Por ejemplo, el

significado de una jerarquía de clases puede inferirse, pero no capturarse

completamente inspeccionando el código de todas las clases en la

jerarquía.

• Tercero, si el desarrollador que escribió el código no dejó documentación

escrita de los modelos que hacía de forma mental, esa información se

perderá para siempre, o como mucho, será sólo parcialmente

reproducible a partir de la implementación una vez que el desarrollador

se haya marchado.

Al escribir modelos UML, se afronta el tercer problema: un modelo explícito

para facilitar la comunicación.

Algunas cosas se modelan mejor textualmente, otras se modelan mejor de forma

gráfica. En realidad, en todos los sistemas interesantes hay estructuras que trascienden

lo que puede ser representado mediante un lenguaje de comunicación. UML es uno de

esos lenguajes gráficos. Así afronta el segundo problema mencionado anteriormente.

41


UML es algo más que un simple compendio de símbolos gráficos. Más bien,

detrás de cada símbolo en la notación UML hay una semántica bien definida. De

manera que un desarrollador puede escribir un modelo en UML, y otro desarrollador, o

incluso otra herramienta, pude interpretar ese modelo sin ambigüedad. Así afronta el

primer problema mencionado con anterioridad.

En este contexto, especificar significa construir modelos precisos, no ambiguos

y completos. En particular, UML cubre la especificación de todas las decisiones de

análisis, diseño e implementación que se deben realizar al desarrollar y desplegar un

sistema con gran cantidad de software.

UML no es un lenguaje de programación visual, pero sus modelos pueden

conectarse a gran variedad de lenguajes de programación. Esto significa que es posible

establecer correspondencias desde un modelo UML a un lenguaje de programación

como C++, Java o Visual Basic, o incluso tablas en una base de datos relacional o

almacenamiento persistente en una base de datos orientada a objetos. Las cosas que se

expresan mejor gráficamente también se representan gráficamente con UML, mientras

que las cosas que se representan mejor textualmente se plasman con un lenguaje de

programación.

Esta correspondencia permite la ingeniería directa: generación de código a partir

de un modelo UML en un lenguaje de programación. Lo contrario también es posible:

se puede reconstruir un modelo en UML a partir de una implementación. Pero este

proceso no es automático, a menos que se codifique esa información en l a

implementación, la información se pierde cuando se pasa del modelo al código. La

ingeniería inversa requiere, por lo tanto, de herramientas que la soporten e intervención

humana. La combinación de estas dos vías de generación de código y de ingeniería

inversa produce una ingeniería “de ida y vuelta”, entendiendo por eso la posibilidad de

trabajar en una vista gráfica o textual, mientras que las herramientas mantienen la

consistencia de las dos vistas.

Además de esta correspondencia directa, UML es lo suficientemente expresivo y

no ambiguo como para permitir la ejecución directa de modelos, la simulación de

sistemas y la instrumentación de sistemas en ejecución.

42


UML cubre la documentación de la arquitectura de un sistema y todos sus

detalles. UML también proporciona un lenguaje para expresar requisitos y pruebas.

Finalmente, UML proporciona un lenguaje para modelar las actividades de

planificación de proyectos y gestión de versiones.

3.2 Especificación funcional del modelo de coordinación

El modelo de coordinación que en este proyecto se ha desarrollado ha sido

implementado en un lenguaje de programación orientado a objetos como es C++. Por

ello, resulta adecuado el uso de UML para explicar su diseño.

A continuación se muestran los diagramas que forman parte del lenguaje de

modelado unificado del proyecto, así como una breve introducción a los mismos, con el

fin de que su interpretación sea de utilidad a la hora de entender el modelo aquí

implementado.

3.2.1 Diagramas de casos de uso

Los casos de uso permiten describir el comportamiento de un sistema desde el

punto de vista del usuario basándose en un conjunto de acciones y reacciones. Es por lo

tanto una técnica que permite capturar los requisitos funcionales del sistema. De esta

forma queda delimitado el alcance del sistema y cuál es su relación con el entorno.

En estos diagramas, el sistema queda reducido a una “caja negra”, ya que no

interesa cómo lleva a cabo sus funciones, sino simplemente qué acciones visibles desde

el exterior son las que realiza.

Los casos de uso están basados en lenguaje natural, lo que los hace accesibles a

cualquier usuario. Además, aquellos casos de uso que resulten muy complejos pueden

descomponerse en nuevos casos de uso de un nivel inferior, hasta llegar a un nivel tal

que resulten fáciles de analizar.

Los casos de uso guían todo el proceso de desarrollo del sistema, lo que quiere

decir que en momentos determinados de dicho proceso, el sistema debe ser validado

comprobando que se ajusta al diagrama de casos de uso.

43


Los diagramas de casos de uso están formados por tres elementos

fundamentales:

• Actores. Los actores son los participantes de os casos de uso, se

corresponden con los usuarios que interactúan con el sistema. Estos

actores pueden ser humanos, dispositivos externos que interactúen con el

sistema, o incluso temporizadores que envíen eventos al mismo. Un actor

se caracteriza por la forma de interaccionar con el sistema, por lo que un

mismo usuario puede ejercer de varios actores, y un actor puede

representar a varios usuarios.

• Casos de uso. Son los escenarios de interacción de los actores.

Representan el comportamiento del sistema en relación con los usuarios.

De esta forma, un caso de uso define la secuencia de interacciones entre

uno o más usuarios y el sistema.

• Relaciones. Representan el flujo de información intercambiada entre los

actores y los casos de uso, o entre diferentes casos de uso. Normalmente,

se emplean para que un caso de uso obtenga la información necesaria

para llevar a cabo alguna acción, o para que el proceso proporcione algún

resultado. Estas relaciones pueden ser unidireccionales o bidireccionales.

Los diagramas de casos de uso se clasifican en diferentes niveles, en función del

grado de detalle con el que se represente el funcionamiento del sistema. De esta forma,

los diagramas de nivel 0 o contexto representan el sistema completo con un nivel de

detalle muy bajo, mientras que al aumentar el nivel, el grado de detalle va

incrementándose.

Notación

A continuación de muestra la notación empleada para la representación de los

distintos elementos que forman los diagramas de casos de uso.

44


Los actores son representados mediante figuras de hombre de palo, con su

correspondiente nombre debajo de la figura.

Xa

Figura 3.2-1. Notación de actores

Los casos de uso, o procesos, se representan mediante una elipse, con su nombre

correspondiente debajo de la misma.

Coordinación semafórica

Figura 3.2-2. Notación de casos de uso.

Por último, las relaciones se representan mediante flechas que unen los casos

de uso, o el caso de uso y el actor, entre los que existe un flujo de información.

Figura 3.2-3. Notación de relaciones

Debido a la similitud de los dos algoritmos implementados, los diagramas de

diseño UML de ambos métodos se irán presentando de forma paralela y conjunta. No en

vano, ambos algoritmos poseen partes en común que serán más fácilmente identificables

si se muestran a la vez.

45


3.2.1.1 Modelo de coordinación semafórica

3.2.1.1.1 Diagramas de caso de uso de nivel 0 o de contexto

En este diagrama se muestra la aplicación con el menor grado de detalle,

permitiendo una visión global de su comportamiento.

Xa

ViarioUsuario

Modelo de coordinación semafórica

Figura 3.2-4. Casos de uso de nivel 0

El usuario es la persona que se encuentra realizando la coordinación de los

semáforos de una cierta avenida. Su relación con el modelo de coordinación es

bidireccional, dado que proporciona la información necesaria para su ejecución y

recibe los resultados del proceso.

El viario es un agente externo y su relación es unidireccional con el modelo. En

concreto, se encarga de proporcionar al modelo los datos necesarios del viario relativos

a configuración del grafo que sirve de representación del mismo. Entre la información

que suministra se encuentran las cajas semafóricas de cada nodo, las señales de tráfico

que contiene cada caja, la información relativa a cada señal, etc...

Por último, se encuentra la xa, que es el programa que se encarga de resolver el

modelo de coordinación y cuya relación con este sistema es bidireccional, ya que recibe

del mismo la información necesaria para resolver el modelo y a su vez, proporciona los

resultados del proceso.

46


3.2.1.1.2 Diagramas de casos de uso de nivel 1

En este nivel se pretende profundizar en el funcionamiento interno del modelo

de coordinación semafórica.

Figura 3.2-5. Casos de uso de nivel 1

En este diagrama se divide el modelo en 2 procesos que se relacionan entre sí e

intercambian información.

El proceso de obtención de datos se encarga de obtener todos los datos

necesarios para el diseño del modelo de coordinación, para ello necesita la lista de todos

los nodos del viario, con el fin de elegir aquellos que conciernen a la avenida de

semáforos a coordinar. Además, necesitará cierta información para elaborar el modelo,

que sólo podrá obtener por medio del usuario.

Toda la información recopilada en el proceso anterior se la entregará al proceso

de obtención de la solución, el cual, proporcionará el modelo generado a partir de dicha

información y con un formato determinado a la xa. Ésta, resolverá el problema de

programación lineal y devolverá los resultados del mismo, que tras ser procesados

convenientemente, serán presentados de una forma legible al usuario.

3.2.1.1.3 Diagramas de casos de uso de nivel 2

Se ha creído conveniente entrar a explicar con mayor grado de detalle los

procesos que se han añadido al diagrama de casos de uso de nivel 1.

47


• Obtención de los datos

En este proceso se pretende obtener toda la información necesaria para generar

el modelo, que más tarde entregará al caso de uso obtención de la solución.

Figura 3.2-6. Diagramas de casos de uso de nivel 2. Obtención de los datos

El proceso de obtención de los nodos crea una lista de los nodos que contienen

las señales que serán coordinadas en el modelo. La información necesaria para la

creación de dicha lista le será proporcionada por el viario y por el usuario, este último

mediante la selección de los nodos integrantes de la lista.

La misma información se le proporciona tanto al modulo de representación de

caja como al de obtención de señales. El primero realiza una representación gráfica de

todas las señales semafóricas de la caja seleccionada; mientras que el segundo, con la

ayuda del usuario, confecciona la lista de señales que serán coordinadas.

Por último, en el proceso de obtención datos modelo se recogen todos los datos

del modelo concernientes a la distancia entre los semáforos, así como, los límites de

velocidad permitidos entre los mismos.

48


• Obtención de la solución

Este proceso se encarga de generar el modelo que se le pasará a la xa para que lo

resuelva y de presentar los datos de forma adecuada al usuario.

Figura 3.2-7. Diagramas de casos de uso de nivel 2. Obtención de la solución

El proceso generación modelo recibe los datos adquiridos en proceso obtención

de los datos y crea el modelo en un determinado formato que es capaz de leer la xa, para

finalmente pasarlo al caso de uso resolución modelo.

En el modulo resolución modelo se envía el modelo creado a la xa para que lo

resuelva y se procesa el archivo resultado determinándose si el problema de

programación lineal planteado tiene solución óptima o no.

Tanto el modulo de generación modelo como el de resolución modelo son

usados por el proceso de representación de resultados, a través de los cuales obtiene la

solución al problema de coordinación. En el caso que la solución sea óptima, este

modulo procesa el archivo devuelto por la xa obteniendo los datos relevantes y los

muestra de forma comprensible para el usuario.

49


3.2.2 Diagramas de paquetes

El objetivo de este tipo de diagramas es obtener una visión mucho más clara del

sistema de información orientado a objetos, organizándolo en diferentes subsistemas,

agrupando los elementos del análisis, diseño o construcción y detallando las relaciones

de dependencias entre ellos. El mecanismo de agrupación utilizado se denomina

paquete.

Estrictamente hablando, los paquetes y sus dependencias son elementos de los

diagramas de casos de uso, de clases y de componentes, por lo que se podría decir que

el diagrama de paquetes es una extensión de éstos.

En estos diagramas de pueden diferenciar dos tipos de elementos:

• Paquetes: Un paquete es la agrupación de elementos, bien sea casos de

uso, clases o componentes. Los paquetes pueden contener a su vez otros

paquetes anidados que en última estancia contendrán alguno de los

elementos anteriores.

• Dependencia entre paquetes. Existe una dependencia cuando un

elemento de un paquete requiere de otro que pertenece a un paquete

distinto. Es importante resaltar que las dependencias no son transitorias.

Los paquetes se van a representar mediante un símbolo en forma de carpeta, en

el cual se coloca el nombre del paquete correspondiente. Por su parte, las dependencias

entre paquetes se representan con una flecha discontinua con inicio en el paquete que

depende del otro.

A continuación se adjunta el diagrama de paquetes del algoritmo de

coordinación.

50


3.2.2.1 Diagramas de paquetes del algoritmo de coordinación

En el siguiente gráfico se pueden observar los paquetes que componen el

algoritmo de coordinación.

Viario

Algoritmo coordinación

Interfaz gráfica Lista

Grupo semafórico

VCL

Figura 3.2-8. Diagramas de paquetes del algoritmo de coordinación

En el diagrama se observan seis paquetes o elementos, que están relacionados

entre sí. Los paquetes son los siguientes:

• Viario: Este paquete contiene las clases utilizadas para describir el viario.

Por lo tanto, contendrá toda la información referente a los nodos

existentes en el escenario de simulación donde se incluye la información

sobre las señales luminosas de tráfico, es decir, todo lo que hace

referencia a los componentes estáticos del modelo.

• Grupo semafórico: Este paquete contiene las clases que se encargan de

recopilar los datos acerca de la caja semafórica asociada a un nodo

determinado.

51


• Algoritmo de coordinación: Dentro de este paquete se encuentran las

clases mas importantes, ya que además de almacenar todos los datos

necesarios para la construcción del modelo, son las encargadas de

generar el archivo con el problema programación lineal necesario para la

coordinación de las señales semafóricas.

• Lista: Este paquete contiene una clase parametrizada que será usada para

la implementación de listas de estructuras de las clases definidas en otros

paquetes. Es pues un paquete auxiliar, y su clase no tiene un significado

propio dentro del algoritmo, aunque es tremendamente útil a la hora del

procesamiento de los datos.

• VCL (Visual Component Library): Este paquete engloba a todos los

elementos visuales de la librería de Borland que se utilizan en la

aplicación.

• Interfaz gráfica: En este paquete se incluyen las clases que componen los

formularios visuales que permiten la interacción entre la aplicación y el

usuario. Estas clases hacen uso de los elementos VCL propios de

Borland.

3.2.3 Diagramas de clases

El objetivo principal de este modelo es la representación de los aspectos

estáticos del sistema, utilizando diversos mecanismos de abstracción (clasificación,

generalización, agregación).

El diagrama de clases recoge las clases existentes en los paquetes y sus

correspondientes asociaciones. En este diagrama se representa la estructura y

comportamiento de cada uno de los objetos del sistema y sus relaciones con los demás

objetos, pero no se muestra ninguna información temporal. Con el fin de facilitar la

comprensión del diagrama, se pueden incluir paquetes como elementos del mismo,

donde cada uno de ellos agrupa un conjunto de clases que tienen algún tipo de relación.

52


Este diagrama no refleja los comportamientos temporales de las clases, aunque para

representarlos puede usarse un diagrama de transición de estados.

Los elementos básicos del diagrama son:

• Clases. Una clase describe un conjunto de objetos con propiedades

(atributos) similares y un comportamiento común. Los objetos son

instancias de las clases.

No existe un procedimiento inmediato que permita localizar las clases

del diagrama de clases. Éstas suelen corresponderse con sustantivos que

hacen referencia al ámbito del sistema de información y que se

encuentran en los documentos de las especificaciones de requisitos y de

los casos de uso.

Dentro de la estructura de una clase se definen los atributos, que

representan los datos asociados a los objetos instanciados por esa clase, y

los métodos, que representan las funciones o procesos propios de los

objetos de una clase, caracterizando a dichos objetos.

Dentro de las clases es importante destacar un caso especial, las

plantillas o templates. Éstas son clases que están parametrizadas, es

decir, que necesitan de un parámetro a la hora de formarse.

• Relaciones. Los tipos más importantes de relaciones estáticas entre

clases son las siguientes:

o Asociación. Las relaciones de asociación representan un conjunto de

enlaces entre objetos o instancias de clases. Es el tipo de relación más

general, y denota básicamente una dependencia semántica. Por ejemplo

un Carril pertenece a un Tramo. Cada asociación puede representar

elementos adicionales que doten de mayor detalle al tipo de relación:

Rol, o nombre de la asociación, que describe la semántica de la

relación en el sentido indicado. Por ejemplo, la asociación entre

53


Carril y Tramo recibe el nombre de pertenece a, como rol en ese

sentido.

Multiplicidad, que describe la cardinalidad de la relación, es decir,

especifica cuántas instancias de una clase están asociadas a una

instancia de la otra clase. Los tipos de multiplicidad son: uno a uno,

uno a muchos, muchos a muchos...

o Herencia. Las jerarquías de generalización / especialización se conocen

como herencia. La herencia es el mecanismo que permite a una clase de

objetos incorporar atributos y métodos de otra clase, añadiéndolos a los

que ya posee. Con la herencia se refleja una relación es-un entre clases.

La clase de la cual se hereda se denomina superclase, y la que lo hereda

subclase.

o Agregación. La agregación es un tipo de relación jerárquica entre un

objeto que representa la totalidad de ese objeto y las partes que lo

componen. Permite el agrupamiento físico de estructuras relacionadas

lógicamente. Los objetos son-parte-de otro objeto completo.

o Composición. La composición es una forma de agregación donde la

relación de propiedad es más fuerte, e incluso coinciden el tiempo de

vida del objeto y las partes que lo componen.

o Dependencia. Una relación de dependencia se utiliza entre dos clases o

entre una clase y una interfaz, e indica que una clase requiere de otra

para proporcionar alguno de sus servicios.

A continuación se va a dar una explicación de la notación seguida para la

representación de estos diagramas.

Una clase se representa por una caja, separada en tres zonas por líneas

horizontales.

En la zona superior se muestra el nombre de la clase y propiedades generales

como el estereotipo. Si la clase es abstracta el nombre aparece en cursiva. El nombre es

único y sirve para diferenciarlo del resto de las clases.

54


La zona central contiene una lista de atributos, uno en cada línea. La notación

utilizada para representarlos incluye, dependiendo del detalle, el nombre del atributo, su

tipo y su valor por defecto, con el formato:

Visibilidad nombre: tipo = valor_inicial

Figura 3.2-9. Ejemplo de clase

3.2.3.1 Paquete de datos “Grupo semafórico”

Este paquete de datos contiene la información concerniente al funcionamiento de

los dispositivos reguladores de tráfico.

3.2.3.1.1 Descripción de las clases del paquete “Grupo semafórico”

3.2.3.1.1.1 Clase “Estructura”

Esta clase agrupa el conjunto de grupos semafóricos que pueden imponerse en

un nodo, el cual puede contener varias estructuras distintas que pueden aplicarse en

cualquier instante. Incluso dos estructuras asignadas a un mismo nodo pueden tener

ciclos diferentes, un número de fases distintas y estados desiguales.

55


Estructura Fases

Ciclo Figura 3.2-10. Estructura, fases y ciclo

Estructuracod_estructura : Codigo_estructuranumero_fases : unsigned charnumero_senales : unsigned charciclo : unsigned intposicion_intermedios : boolincluidos : booltiempo : boolactiva : bool

Cod_estructura() : Codigo_estructuraNumero_fases() : unsigned charNumero_senales() : unsigned charCiclo() : unsigned intIncluido() : boolPosicion_intermedios() : boolTiempo() : boolActiva() : boolActualiza_ciclo(c : unsigned int)Activar()Desactivar()Activar_tiempo()Desactivar_tiempo()Intermedios_delante()Intermedios_detras()Actualiza_incluido(inc : bool)Actualiza_codigo_estructura(codigo : Codigo_estructura)Actualiza_numero_fases(numero : unsigned char)Actualiza_numero_senales(numero : unsigned char)operator=(es : Estructura) : Estructuraoperator==(es : Estructura) : bool

Figura 3.2-11. Clase “Estructura”

56


• Atributos de la clase “Estructura”:

o cod_estructura : Identifica unívocamente a la estructura.

o numero_fases : Número de etapas o fases de las que consta la

estructura.

o numero_senales : Número de señales que se han definido en la

estructura.

o ciclo : Tiempo en segundos que dura el ciclo de la estructura.

o posicion_intermedios : Indica si los tiempos intermedios se producen

antes o después de cada fase.

o incluidos : Indica si los tiempos intermedios están incluidos en las

señales.

o tiempo : Indica si los tiempos se expresan en porcentajes o en segundos.

o activa : Indica si la estructura está actualmente regulando el tráfico.

• Métodos de la clase “Estructura”:

o Codigo_estructura Cod_estructura (void) : Devuelve el código de la

estructura en cuestión.

o unsingned char Numero_fases (void) : Devuelve el número de fases de

las señales presentes en la estructura.

o unsigned char Numero_senales (void) : Devuelve el número de señales

que componen la estructura.

o unsigned int Ciclo (void) : Devuelve el valor del ciclo de la estructura.

o void Incluido (void) : Devuelve el valor del atributo incluidos.

o bool Posición_intermedios (void) : Devuelve el valor del atributo

posición_intermedios.

o bool Tiempo (void) : Devuelve el valor del atributo tiempo.

o bool Activa (void) : Devuelve el valor del atributo activa.

o void Actualiza_ciclo (unsigned int c) : Actualiza el valor del ciclo de la

estructura.

o void Activar (void) : Activa la estructura.

57


o void Desactivar (void) : Desactiva la estructura.

o void Activar_tiempo (void) : Hace que los tiempos se expresen en

segundos.

o void Desactivar_tiempo (void) : Hace que los tiempos se expresen en

porcentajes.

o void Intermedios_delante (void) : Hace que los tiempos intermedios se

produzcan antes que las fases.

o void Intermedios_detras (void) : Hace que los tiempos intermedios se

produzcan después de las fases.

o void Actualiza_incluido (bool inc) : Actualiza el valor del atributo

incluido.

o void Actualiza_codigo_estructura (Codigo_estructura codigo) :

Actualiza el valor del atributo cod_estructura.

o void Actualiza_numero_fases (unsigned char numero) : Actualiza el

número de fases de la estructura.

o void Actualiza_numero_senales (unsigned char numero) : Actualiza el

número de señales de la estructura.

o Estructura operador= (Estructura es) : Copia una estructura origen en

una estructura destino.

o Bool operator== (Estructura es) : Compara dos instancias de la clase

estructura.

3.2.3.1.1.2 Clase “Codigo_estructura”

Esta clase se emplea para identificar unívocamente a una de las estructuras

analizadas anteriormente.

58


Codigo_estructuracodigo_nodo : unsigned intcod_estructura : unsigned int

Codigo_nodo() : unsigned intCod_estructura() : unsigned intActualiza_codigo_nodo(nodo : unsigned int)Actualiza_cod_estructura(cod : unsigned int)operator=(cod : Codigo_estructura) : Codigo_estructuraoperator==(cod : Codigo_estructura) : bool

Figura 3.2.-12. Clase “Codigo_estructura”

• Atributos de la clase “Codigo_estructura”:

o codigo_nodo : Nodo en el que se encuentra la estructura.

o cod_estructura : Código de la estructura en ese nodo.

• Métodos de la clase “Codigo_estructura”:

Se corresponden con los métodos habituales para el manejo de los

atributos, por los que su explicación se omitirá.

3.2.3.1.1.3 Clase “Codigo_senal”

Representa los estados que tomarán uno o varios semáforos durante todo el ciclo

de la estructura. Estos códigos tomarán un valor único que permita identificar las

distintas señales.

Codigo_senalCod_estructura : Codigo_estructuranumero_senal : unsigned char

Numero_senal() : unsigned charCod_estructura() : Codigo_estructuraActualiza_estructura(cod : Codigo_estructura)Actualiza_numero_senal(n : unsigned char)operator=(s Codigo_senal) : Codigo_senaloperator==(s Codigo_senal) : bool

Figura 3.2-13. Clase “Codigo_senal”

59


• Atributos de la clase “Codigo_senal”:

o cod_estructura : Código de la estructura a la que pertenece la señal.

o numero_senal : Número propio de la señal en el interior de la estructura

que la contiene.

• Métodos de la clase “Codigo_senal”:

Se corresponden con los métodos habituales para el manejo de los

atributos.

3.2.3.1.1.4 Clase “Fase”

Las fases o etapas muestran el estado que tienen cada una de las señales durante

un intervalo de tiempo concreto.

Fasecod_fase : Codigo_fasecolor : unsigned chartiempo : unsigned intporcentaje : floatnumero_intermedios : unsigned charpuntero_intermedios : unsigned int

Cod_fase() : Codigo_faseColor() : unsigned charTiempo() : unsigned intPorcentaje() : floatNumero_intermedios() : unsigned charPuntero_intermedios() : unsigned intActualiza_codigo_fase(c : Codigo_fase)Actualiza_color(c : unsigned char)Actualiza_tiempo(t : unsigned int)Actualiza_porcentaje(p : float)Actualiza_intermedios(numero : unsigned char)Actualiza_puntero_intermedios(p : unsigned int)operator=(f Fase) : Faseoperator==(f Fase) : bool

Figura 3.2-14. Clase “Fase”

• Atributos de la clase “Fase”:

60


o cod_fase : Identifica unívocamente cada fase.

o color : Estado que tiene la señal en la fase.

o tiempo : Duración de la fase en segundos.

o porcentaje : Tanto por ciento de duración de la fase respecto al ciclo

total.

o numero_intermedios : Número de tiempos intermedios de los que

dispone la fase.

o puntero_intermedios : Índice de la lista de intermedios en el que

comienzan los intermedios correspondientes a la fase.

• Métodos de la clase “Fase” :

Los métodos de esta clase son los correspondientes a la obtención y

modificación de los valores de los atributos, por lo que su significado es

suficientemente claro y no se detallará.

3.2.3.1.1.5 Clase “Codigo_fase”

Este código se utiliza para diferenciar a una fase concreta del resto de fases.

Codigo_fasenumero_fase : unsigned charCod_senal : Codigo_senal

Numero_fase() : unsigned charCod_senal() : Codigo_senalActualiza_fase(numero : unsigned char)Actualiza_senal(codigo : Codigo_senal)operator=(c : Codigo_fase) : Codigo_faseoperator==(c : Codigo_fase) : bool

Figura 3.2-15. Clase “Codigo_fase”

• Atributos de la clase “Codigo_fase”:

61


o numero_fase : Número que identifica a la fase dentro de la señal

correspondiente.

o cod_senal : Código de la señal a la que pertenece la fase.

• Métodos de la clase “Codigo_fase”:

Los métodos son los habituales en el manejo de los atributos.

3.2.3.1.1.6 Clase “Intermedio”

Los tiempos intermedios son tiempos fijos que garantizan la no ocurrencia

simultánea de cambios de rojo a verde para grupo diferentes.

Intermediocod_intermedio : Codigo_intermedioduracion : unsigned charcolor : unsigned char

Cod_intermedio() : Codigo_intermedioDuracion() : unsigned charColor() : unsigned charActualiza_duracion(d : unsigned char)Actualiza_color(c : unsigned char)Actualiza_codigo(c : Codigo_intermedio)operator=(i : Intermedio) : Intermediooperator==(i : Intermedio) : bool

Figura 3.2-16. Clase “Intermedio”

• Atributos de la clase “Intermedio”:

o cod_intermedio : Código que identifica al intermedio.

o duracion : Tiempo en segundos que dura el intermedio.

o color : Estado asignado al tiempo intermedio.

• Métodos de la clase “Intermedio”:

Los métodos son los habituales en el manejo de atributos y en el manejo de

instancias de dicha clase.

3.2.3.1.1.7 Clase “Codigo_intermedio”

62


Este código permite identificar unívocamente a los tiempos intermedios.

Codigo_intermediocod_intermedio : unsigned intcod_fase : Codigo_fase

Cod_intermedio() : unsigned intCod_fase() : Codigo_faseActualiza_numero_intermedio(n : unsigned int)Actualiza_codigo_fase(c : Codigo_fase)operator=(c : Codigo_intermedio) : Codigo_intermediooperator==(c : Codigo_intermedio) : bool

Figura 3.2-17. Clase “Codigo_intermedio”

• Atributos de la clase “Codigo_intermedio”:

o cod_intermedio : Identifica los distintos tiempos intermedios

pertenecientes a una misma fase.

o cod_fase : Identifica la fase a la que pertenece el intermedio.

• Métodos de la clase “Codigo_intermedio”:

Los habituales en el manejo de atributos.

3.2.3.1.1.8 Clase “Senal_semaforica”

Un semáforo es un dispositivo físico que regula el desplazamiento de vehículos

en el interior de una intersección.

63


Senal_semaforica

e : Estructuradesfase : unsigned intlista_fases : Lista_inf <Fase>lista_intermedios : Lista_inf <Intermedio>

Senal_semaforica()Inicial izacion()Desfase() : unsigned intNumero_fases() : unsigned charNumero_senales() : unsigned charCiclo() : unsigned intLista_fases() : Lista_inf <Fase>Lista_intermedios() : Lista_inf <Intermedio>Valor_estructura() : EstructuraAdd_fase(f : Fase)Add_intermedio(i : Intermedio)Actual iza_estructura(es : Estructura)Actual iza_desfase(d : unsigned int)Actual iza_l ista_fases(lista_f : Lista_inf <Fase>)Actuaiza_lista_intermedios(l ista_i : Lista_inf <Intermedio>)operator=(s : Senal_semaforica) : Senal_semaforicaoperator==(s : Senal_semaforica) : boolDestruir_l ista()Borrar_l ista()Procesar_cadena_importacion(cadena : char*, descripcion : int*, numero : unsigned int, ....) : boolImportar_senal(nombre : char*, numero_elementos : unsigned int*, .....) : boolSalvar_senal(nombre : char*)Salvar_senal(nombre : char*, modo : char*)Cargar_senal(nombre : char*) : boolCargar_senal_cont(F1 : FILE *) : boolSalvar_senal_cont(F1 : FILE*)Exportar_senal(nombre : char*)Procesar_cadena_exportacion(descripcion : int*, F1 : FILE*) : boolEstado_senal(senal : unsigned int, instante_simulacion : float) : unsigned charObtener_intermedios(fase : unsigned char) : intModificar_fase(fase : unsigned char, segundos : unsigned int)Modificar_intermedio(fase : unsigned char, intermedio : unsigned int, segundos : unsigned int)Modificar_intermedio(intermedio : Intermedio)Modificar_fase(fase : Fase)Datos_segundos(fas : int*, inte : int*, segundos : float, despl : bool, fase_ant : int, inte_ant : int) : boolModificar_intermedios_fase_final (fase : unsigned char, intermedio : int, sg_total : int, sg : int)Modificar_intermedios_mitad(fase : unsigned char, intermedio : int, sg_total : int, sg : int)Modificar_intermedios_final(fase : unsigned char, fase_sig : unsigned char, ....t)Modificar_fase_inter(fase : unsigned int, fase_sig : unsigned int, intermedio : int, ....) : intModificar_intermedio(senal : int, fase : int, intermedio : int, sg : int, final : bool, Posterior : bool)Modificar_fase_intermedio_fin(fase : int, sg : int)Obtener_tiempo(intermedio : int, fase : int) : intTiempos_intermedios(fase : unsigned char) : unsigned intRedimension_caja(nuevo_ciclo : unsigned int) : unsigned intActivar_estructura()Desactivar_estructura()Actual iza_porcentajes()

Figura 3.2-18. Clase “Senal_semaforica”

• Atributos de la clase “Senal_semaforica”:

o e : Estructura a la que pertenece la señal semafórica.

o desfase : Tiempo de desfase entre los distintos semáforos.

o lista_fases : Lista de las fases que pertenecen a la señal semafórica.

o lista_intermedios : Lista de los tiempos intermedios que pertenecen a la

señal semafórica.

64


• Métodos de la clase “Senal_semaforica”:

o void Inicializacion (void) : Crea las listas correspondientes a la señal

semafórica.

o Senal_semaforica operator= (Senal_semaforica s) : Permite la copia de

una instancia de la clase senal_semaforica en otra del mismo tipo.

o bool operator== (Senal_semaforica s) : Permite la comparación entre

dos instancias de la misma clase.

o void Destruir_lista (void) : Destruye las listas correspondientes a la

señal semafórica.

o void Borrar_lista() : Borra las listas correspondientes a la señal

semafórica.

o bool Procesar_cadena_importacion (char* cadena, int* descripcion,

unsigned int numero, Lista_inf<Intermedio>* lista_int,

Lista_inf<Fase>* lista_fas, unsigned int* numero_estructuras,

unsigned int cod_nodo, FILE* F1) : Procesa una línea de un fichero en

la que se encuentra información sobre la señal semafórica.

o bool Importar_senal (char* nombre, unsigned int* numero_elementos,

unsigned int elemento, unsigned int cod_nodo) : Con esta función se

obtiene toda la información almacenada en un archivo acerca de las

estructuras de un nodo. Para procesar el archivo hace uso del método

anterior.

o void Exportar_senal (char *nombre) : Nos permite exportar una señal

de la estructura contenida en la señal semafórica a un determinado

archivo.

o bool Procesar_cadena_exportacion (int *descripcion,FILE *F1) : Nos

permite introducir datos en un archivo en una línea determinada. Es

usado por el método anterior.

o unsigned char Estado_senal (unsigned int senal, float

instante_simulacion) : Devuelve el estado de la señal semafórica

teniendo en cuenta el instante de simulación y la señal de la que se

desea ver el estado que tiene.

65


o unsigned int Redimension_caja (unsigned int nuevo_ciclo) : Permite

cambiar el tiempo de ciclo de una estructura.

El resto de métodos no se comentan por ser los habituales en el manejo de

atributos y de los elementos constituyentes de una señal semafórica, tales como: las

fases, intermedios,etc…

3.2.3.1.2 Diagrama de clases del paquete “Grupo Semafórico”

El siguiente diagrama muestra las clases que componen el paquete, así como su

interrelación.

Codigo_estructura Punto(from Viario)Estructura1 1

+identifica a

1 1 10..* 1

+regula a

0..*

Senal_semaforica

Codigo_intermedio

Codigo_senal

1..*

1

+pertenece a

1..*

1

0..*1 0..*

+se asigna a1

Codigo_fase

Intermedio

1

1

+identifica a

1

1

Fase

1

1..*

+contiene a

1

1..*

1

1

+identidica a

1

1

1..*1 1..*

+contiene a

1Signal(from Algoritmo coordinación)

1..*1 1..*

+se compone de

1

Figura 3.2-19. Diagrama de clases “Grupo semafórico”

66


3.2.3.2 Paquete de datos “Algoritmo coordinación”

En este paquete se encuentran las clases que se encargan de almacenar los datos

para la posterior generación del modelo de coordinación, así como las encargadas de

generar dicho modelo. El modelo al mismo tiempo que se genera se va escribiendo en

un archivo de texto interpretable por el actor externo “xa”, que se encargará de resolver

el modelo planteado.

3.2.3.2.1 Descripción de las clases del paquete “Algoritmo coordinación”

3.2.3.2.1.1 Clase “Signal”

Esta clase permite almacenar los datos de una señal necesarios para su

coordinación, es decir, el ciclo y las fases de la misma.

Signalciclo_signal : unsigned intsenal : Lista_inf <Fase>senal_i : Lista_inf <Intermedio>

Signal()Leer_ciclo() : unsigned intLeer_lista() : Lista_inf <Fase>Leer_lista_i() : Lista_inf <Intermedio>Actualiza_ciclo(tiempo : unsigned int)Actualiza_lista(sen : Lista_inf <Fase>)Actualiza_lista_i(sen_i : Lista_inf <Intermedio>)operator=(s : Signal) : Signaloperator==(s : Signal) : bool

Figura 3.2-20. Clase “Signal”

• Atributos de la clase “Signal”:

o ciclo_signal : Indica el valor del ciclo de la señal cuyos datos

necesarios para su coordinación se almacenan en esta clase.

o senal : Contiene una lista con las fases de la señal, éstas serán

necesarias para su coordinación más adelante.

67


• Métodos de la clase “Signal”:

Los métodos de esta clase son los habituales en el manejo de los atributos, con lo

que su significado es evidente y por tanto, se omite su explicación.

3.2.3.2.1.2 Clase “Datos_modelo”

Esta clase almacena todos lo datos suministrados por el usuario, tales como:

distancia entre semáforos, velocidad máxima permitida en el tramo que separa a dos

semáforos, etc.., y que son necesarios para resolver el modelo de coordinación.

Datos_modelok : floatdistancia : Lista_inf <float>velocidad_max1 : Lista_inf <float>velocidad_max2 : Lista_inf <float>velocidad_min1 : Lista_inf <float>velocidad_min2 : Lista_inf <float>cambiove_max1 : Lista_inf <float>cambiove_max2 : Lista_inf <float>cambiove_min1 : Lista_inf <float>cambiove_min2 : Lista_inf <float>

Datos_modelo()Leer_valor_k() : floatLeer_elemento_distancia(i : unsigned int) : floatLeer_elemento_velocidad_max1(i : unsigned int) : floatLeer_elemento_velocidad_max2(i : unsigned int) : floatLeer_elemento_velocidad_min1(i : unsigned int) : floatLeer_elemento_velocidad_min2(i : unsigned int) : floatLeer_elemento_cambiove_max1(i : unsigned int) : floatLeer_elemento_cambiove_max2(i : unsigned int) : floatLeer_elemento_cambiove_min1(i : unsigned int) : floatLeer_elemento_cambiove_min2(i : unsigned int) : floatInsertar_valor_k(ka : float)Insertar_elemento_distancia(dis : float)Insertar_elemento_velocidad_max1(vel_max1 : float)Insertar_elemento_velocidad_max2(vel_max2 : float)Insertar_elemento_velocidad_min1(vel_min1 : float)Insertar_elemento_velocidad_min2(vel_min2 : float)Insertar_elemento_cambiove_max1(cvel_max1 : float)Insertar_elemento_cambiove_max2(cvel_max2 : float)Insertar_elemento_cambiove_min1(cvel_min1 : float)Insertar_elemento_cambiove_min2(cvel_min2 : float)Borrar_datos()

Figura 3.2-21. Clase “Datos_modelo”

68


• Atributos de la clase “Datos_modelo”:

o k : Contiene el valor de la proporción entre los anchos de banda

existentes en ambos sentidos de la circulación de la avenida a coordinar

: “inbound” y “outbound”.

o distancia : Lista que contiene la distancia que hay entre todos los

tramos existentes en la avenida a coordinar. Entendiéndose por tramo el

trozo de avenida comprendido entre dos señales luminosas de tráfico.

o velocidad_max1 : Lista que contiene la velocidad máxima permitida a

los conductores entre los distintos tramos existentes en la avenida y en

el sentido definido como “outbound”.

o velocidad_max2 : Lista que contiene la velocidad máxima permitida a


el sentido definido como “inbound”.

o velocidad_min1 : Lista que contiene la velocidad mínima permitida a


sentido definido como “outbound”.

o velocidad_min2 : Lista que contiene la velocidad mínima permitida a


sentido definido como “inbound”.

o cambiove_max1 : Lista que contiene el cambio en la velocidad máxima

permitida a los conductores entre los distintos tramos existentes en la

avenida y en sentido definido como “outbound”.

o cambiove_max2 : Lista que contiene el cambio en la velocidad máxima


avenida y en sentido definido como “inbound”.

o cambiove_min1 : Lista que contiene el cambio en la velocidad mínima


avenida y en sentido definido como “outbound”.

o cambiove_min2 : Lista que contiene el cambio en la velocidad mínima


avenida y en sentido definido como “inbound”.

69


• Métodos de la clase “Datos_modelo”:

o Datos_modelo() : Constructor que se encarga de crear las listas que

conforman los atributos de la clase.

o void Borrar_datos() : Método que se ocupa de borrar las listas que

conforman los atributos de la clase.

El resto de métodos no se detallarán por ser su uso el común para la

gestión de los atributos.

3.2.3.2.1.3 Clase “Coordina_signal”

Es esta la clase más importante, debido a que genera el archivo con el modelo de

coordinación que se le pasará más tarde a la “xa” para que lo resuelva. Para ello se sirve

de la lista de señales que contiene y de los datos almacenados en la clase

“Datos_modelo”.

Coordina_signalciclo_max : unsigned intcilco_min : unsigned intsignal_group : Lista_inf <Signal>

Coordina_signal()Leer_ciclo_max() : unsigned intLeer_ciclo_min() : unsigned intLeer_lista() : Lista_inf <Signal>Numero_elementos() : unsigned intInsertar_senal(sig : Signal)Borrar_senal(i : unsigned int)Borra_lista()Extraer_senal(indice : unsigned int) : SignalGenera_archivo(nombre : AnsiString, dato : Datos_modelo)

Figura 3.2-22. Clase “Coordina_signal”

• Atributos de la clase “Coordina_signal”:

o ciclo_max : Contiene el valor del ciclo más alto de las señales que se

van a coordinar.

o ciclo_min : Contiene el valor del ciclo más bajo de las señales que se

van a coordinar.

70


o Signal_group : Es una lista de todas las señales que se van a coordinar.

Cada elemento de esta lista es un objeto de la clase signal, es decir,

contiene el ciclo de la señal y sus fases.

A continuación se va a describir sólo aquellos métodos que por su especial

funcionalidad tienen cierto interés.

• Métodos de la clase “Coordina_signal”:

o Coordina_signal() : Constructor que crea la lista de señales, es decir,

reserva memoria para la misma.

o void Inserter_senal(Signal sig) : Este método además de introducir una

señal nueva en la lista, compara el ciclo de esta señal con el de las ya

existentes para que en caso de que éste sea el menor actualizar el valor

del atributo ciclo_min y en caso de ser el mayor actualizar el valor del

atributo ciclo_max.

o void Genera_archivo(AnsiString nombre,Datos_modelo dato) : Método

que haciendo uso de la lista de señales de la clase y de los datos

provistos por el usuario a través del objeto “dato”, genera el archivo que

contiene el modelo de programación lineal usado para la coordinación

de señales semafóricas y que será resuelto por la “xa”.

71


3.2.3.2.2 Diagrama de clases del paquete “Algoritmo coordinación”


interrelación.

Fase(from Grupo semafórico)Signal

1..*1

+pertenece a

1..*

+se compone de

1

Datos_modeloCoordina_signal

1..*

0..*

+pertenece a 1..*

+se compone de 0..*11 1

+hace uso de

1

Figura 3.2-23. Diagrama de clases “Grupo semafórico”

3.2.3.3 Paquete de datos “Interfaz gráfica”

Este paquete contiene las clases que posibilitan la comunicación entre la

aplicación y el usuario de la misma. Esta comunicación se realiza a través de una serie

de elementos tales como botones, cajas, listas de elementos, etc.., contenidos en un

formulario que se genera al iniciar la aplicación y se destruye al cerrarla.

3.2.3.3.1 Descripción de las clases del paquete “Interfaz gráfica”

3.2.3.3.1.1 Clase “Senal_elegida”

Esta clase permite manipular la lista formada por las señales elegidas por el

usuario para ser coordinadas. Facilita la interacción entre el usuario y la aplicación por

permitir la inclusión y la exclusión de señales de distintas cajas en la lista a coordinar.

72


Senal_elegidanumero_caja : AnsiStringnumero_estructura : AnsiStringnumero_senal : AnsiString

Actualiza_caja(caja : AnsiString)Actualiza_estructura(estructura : AnsiString)Actualiza_senal(senal : AnsiString)Numero_caja() : AnsiStringNumero_estructura() : AnsiStringNumero_senal() : AnsiStringoperator=(sen : Senal_elegida) : Senal_elegidaoperator==(sena : Senal_elegida) : bool

Figura 3.2-24. Clase “Senal_elegida”

• Atributos de la clase “Senal_elegida”:

o numero_caja : Contiene el número de la caja, asociada a un nodo del

viario, de la cual proviene la señal elegida.

o numero_estructura : Contiene el número de la estructura, asociada a

una caja, de la cual proviene la señal elegida.

o numero_senal : Contiene el número de la señal, asociada a una

estructura, elegida.

• Métodos de la clase “Senal_elegida”:

Los métodos de esta clase no se van a explicar porque son los habituales en

el manejo de los atributos.

3.2.3.3.1.2 Clase “Coordinacion_interactiva”

Esta clase es la encargada de generar el formulario, a través del cual el usuario

se comunicará con la aplicación. Este formulario está formado por una serie de botones

y cajas que facilitan al usuario la interacción con el programa.

A continuación, se detallará la clase completa, por carecer gran parte de los

atributos y métodos asociados a éstos de interés, dado que hacen referencia a los

elementos del paquete VCL.

73


Coordinacion_interactivainfo : Datos_modelolista_senales : Coordina_signalgrafica : Caja_interactivacaja : Lista_inf <Senal_semaforica>senales : Lista_inf <Senal_elegida>

Generar_formulario(padre : TWinControl*)Extraer_senal(nodo : unsigned int, senal : unsigned int, ....., tiempo_ciclo : unsigned int *) : boolResuelve_modelo_xa(nombre_entrada : AnsiString, nombre_salida : AnsiString *) : boolEvento_sel_nodo(Sender : TObject*)Activacion_seleccion_nodo(context : Contexto*)Sel_nodo(Sender : TObject*, Button : TMouseButton, Shift : TShiftState, X : int, Y : int)

Figura 3.2-25. Clase “Coordinacion_interactiva”

• Atributos de la clase “Coordinacion_interactiva”:

o info : Atributo que recoge los datos necesarios para la coordinación,

tales como: distancia entre tramos, velocidad máxima entre tramos,

etc… y que son suministrados por el usuario por medio del formulario.

o lista_senales : Lista que almacena las señales seleccionadas por el

usuario.

o grafica : Atributo que nos permite la representación gráfica de una

estructura perteneciente a una caja semafórica determinada.

o caja : Lista que contiene las estructuras presentes en la caja asociada al

nodo seleccionado.

o senales : Lista que almacena los datos de localización de las señales

seleccionadas para su coordinación, tales como: caja en la que se

encuentra, estructura a la que pertenece y número de la misma dentro de

esa estructura.

Recordar que sólo se han descrito los atributos más relevantes de esta

clase.

• Métodos de la clase “Coordinacion_interactiva”:

o void Generar_formulario (TWinControl *padre) : Genera en tiempo de

ejecución el formulario a través del cual el usuario se comunica con la

aplicación.

74


o bool Extraer_senal (unsigned int nodo,unsigned int senal,unsigned int

estructura,Lista_inf <Fase> *lista_f,Lista_inf <Intermedio> *lista_i,

unsigned int *tiempo_ciclo) : Método que nos permite extraer una señal

de una caja determinada y de una estructura específica dentro de la

misma. La señal estará compuesta por sus fases, intermedios y el

tiempo de su ciclo.

o bool Resuelve_modelo_xa (AnsiString nombre_entrada,AnsiString

*nombre_salida) : Método que resuelve el modelo de coordinación

contenido en el archivo indicado, el cual, tiene una estructura específica

que permite a la “xa” su interpretación. La solución se devuelve en otro

archivo para ser procesada mas tarde.

o void_fastcall Evento_sel_nodo (TObject *Sender) : Activa la función de

selección de nodo.

o void Activacion_seleccion_nodo (Contexto context*) : Gestiona los

movimientos del ratón a lo largo del viario.

o void_fastcall Sel_nodo (TObject *Sender, TMouseButton Button,

TShiftState Shift, int X, int Y) : Muestra el nodo seleccionado por el

usuario a través del viario.

75


3.2.3.3.2 Diagrama de clases del paquete “Grupo Semafórico”


interrelación.

Senal_elegida

Senal_semaforica(from Grupo semafórico)

Datos_modelo(from Algoritmo coordinación)

Coordina_signal(from Algoritmo coordinación) Coordinacion_interactiva

1

1..*

1

1..*

1..*

1

1..*

1

11 11111 1+contiene a+contiene a

Figura 3.2-26. Diagrama de clases “Coordinacion_interactiva”

3.2.3.4 Paquete de datos “Lista”

El paquete de datos Lista contiene una clase parametrizada que sirve para crear

listas de instancias de otras clases, así como su manipulación. Entre las funciones que

pueden realizarse están la de añadir elemento, eliminar elemento, modificar elemento,

borrar lista,... En el siguiente gráfico se muestra el diagrama de clases de este paquete.

En realidad, cualquier clase que tenga sobrecargados los operadores necesarios, puede

ser parámetro de esta clase, por lo que solamente se muestra una relación en forma de

ejemplo.

76


3.2.3.4.1 Descripción de las clases del paquete “Lista”

3.2.3.4.1.1 Clase “Lista_inf”

Esta clase permite la organización de objetos de diversos tipos en una lista, de

forma que los datos pueden ser manejados con mayor facilidad. Los datos pueden ser

modificados, extraídos, eliminados,…

Lista_inflista : TList*

Crea_lista()Add_elemento(inf : Y)Lista() : TList *Insertar_elemento(posicion : Y, elemento : Y)Insertar_elemento_ind(elemento : Y, i : unsigned)Insertar_elemento_detras(elemento : Y, posicion : Y)Borrar_elemento(ele : Y)Borrar_elemento_indice(indice : unsigned int)Borrar_ultimo_elemento()Modificar_elemento(ele : Y)Modificar_elemento_indice(ele : Y, i : unsigned int)Borra_lista()Destruir_lista()Elemento(i : unsigned int) : YBuscar(el : Y) : unsigned intBuscar(elemento : Y, encontrado : bool *) : YNumero_elementos() : unsigned intGrabar_Informacion(nombre : char *)Cargar_Informacion(nombre : char *)Grabar_Informacion_cont(F1 : FILE *)Cargar_Informacion_cont(F1 : FILE *)operator=(l : Lista_inf) : Lista_inf

Y

Figura 3.2-27. Clase “Lista_inf”

77


• Atributos de la clase “Lista_inf”:

o lista: Lista de direcciones que mantendrá las posiciones de memoria de

los elementos que conformen la lista de objetos. Es una herramienta de

Borland que implementa métodos de inserción, eliminación y acceso a

los elementos, entre otros.

• Métodos de la clase “Lista_inf”:

o void Crea_lista(void): Método que inicializa la lista, reservando

memoria para la lista de punteros.

o void Add_elemento(Y inf): Añade el elemento inf a la lista al final de la

misma.

o void Lista(void): Devuelve el contenido de la lista de punteros y se usa

para saber si la lista está inicializada.

o void Insertar_elemento(Y posicion, Y elemento): Inserta el objeto

elemento en la posición ocupada por el elemento posicion. Éste último

y los posteriores se desplazarán para dejar hueco.

o void Insertar_elemento_ind(Y elemento, unsigned i): Inserta el objeto

elemento en la posición i.

o void Insertar_elemento_detras(Y elemento, Y posicion): Inserta el

objeto elemento en la posición posterior a la ocupada por el elemento

posicion. Los posteriores se desplazarán para dejar hueco.

o void Borrar_elemento(Y ele): Elimina de la lista el elemento ele.

o void Borrar_elemento_indice(unsigned int indice): Elimina de la lista el

elemento que se encuentra en la posición indice. Los índices de las

listas comienzan en el cero.

o void Modificar_elemento(Y ele): Modifica el elemento que es igual al

objeto ele por el nuevo ele. Esto puede parecer que no hace nada, pero

se explica con el hecho de que dos elementos para ser iguales, no han

de coincidir en cada uno de sus atributos, sino solamente en los

definidos en la sobrecarga del operados ‘= =’.

78


o void Modificar_elemento_indice(Y ele, unsigned int i): Reemplaza el

elemento con índice i por el elemento ele.

o void Borrar_lista(void): Elimina todos los elementos de la lista, pero al

contrario que el método Destruir_lista la lista sigue estando

inicializada.

o void Destruir_lista(void): Destruye la lista y cada uno de sus elementos.

o Y Elemento(unsigned int i): Devuelve el elemento situado en la posición

i (recordar que el primero está en la posición cero).

o unsigned int Buscar(Y ele): Devuelve el índice del elemento ele dentro

de la lista. Si no existe, devuelve el número de elementos de la lista.

o Y Buscar(Y elemento, bool* encontrado): Devuelve el elemento igual al

objeto elemento. La variable encontrado indicará si la búsqueda ha sido

realizada con éxito o no.

o unsigned int numero_elementos(void): Devuelve el número de

elementos en la lista.

o void Grabar_informacion(char* filename): Almacena la lista en el

archivo con nombre filename. Si el archivo existe, su contenido es

eliminado.

o void Grabar_informacion_cont(FILE* F1): Almacena la lista en el

archivo ya abierto y que es apuntado con el puntero F1. La información

se añade al final del archivo.

o void Cargar_informacion(char* filename): Recupera la lista del archivo

con nombre filename. El proceso busca los datos al principio del

mismo.

o void Cargar_informacion_cont(FILE* F1): Recupera la lista del

archivo ya abierto y que es apuntado con el puntero F1. Esta función se

usa cuando la información no esta al inicio del fichero. Es preciso que

el archivo se encuentre en la posición de inicio de la lista.

o Lista_inf operator= (Lista_inf l): Este método permite la copia de una

lista en otra lista del mismo tipo. Si la lista destino poseía datos (no

estaba vacía) los nuevos elementos serán añadidos al final de la misma.

79


3.2.3.4.2 Diagrama de clases del paquete “Lista”


interrelación.

Signal(from Algoritmo coordinación)Lista_inf

0..*1

+pertenece a

0..*

+le pertenece

1

Y

Figura 3.2-28. Diagrama de clases del paquete Lista

3.2.3.5 Paquete de datos “VCL”

En este paquete se incluyen los componentes visuales de la librería de Borland

que se han usado para la generación de la interfaz gráfica. El siguiente diagrama

muestra algunos de esos componentes visuales. Todos son parte integrantes de la clase

Coordinacion_interactiva que representa un formulario. El resto de clases se

corresponden con botones, listas, etiquetas, paneles,...

TButton

TForm TPageControl

TGroupBox

TLabel

TListBox

TStringGrid TEdit

TMemo

TComboBox

TTabSheet

Coordinacion_interactiva(from Interfaz gráfica)

80


Figura 3.2-29. Diagrama de clases del paquete VCL

3.2.3.6 Paquete de datos “Viario”

Este paquete es utilizado para representar todos los componentes que conforman

el viario de una ciudad. Dicho viario será representado por un grafo formado por nodos

y tramos. En concreto existirá un tramo para cada sentido de circulación que tengan las

calles del viario, mientras que los nodos representan los cruces o intersecciones entre las

diferentes calles.

3.2.3.6.1 Descripción de las clases del paquete “Viario”

3.2.3.6.1.1 Clase “Contexto”

Esta clase agrupa todos los datos referentes al escenario de trabajo. De el se

extraen toda la información necesaria para representar el viario sobre el que se va a

trabajar. Posee muchos atributos y métodos. Se han descrito los más importantes.

Contextomapa : Mapaancho : floatalto : float

Ancho() : floatAlto() : float

Figura 3.2-30. Clase “Contexto”

• Atributos de la clase “Contexto”:

o Mapa: Instancia de la clase Mapa que contiene los datos referentes al

viario, entiéndanse nodos, tramos, longitudes,.... Es el atributo más

importante de la clase. Tiene visibilidad pública, por lo que es accesible

desde fuera de la clase.

o Ancho: Mantiene el ancho del mapa, para la representación gráfica del

viario.

81


o Alto: Contiene el alto del mapa, para la representación gráfica del

viario.

• Métodos de la clase “Contexto”:

o float Ancho(void): Devuelve el valor de la variable ancho.

o float Alto(void): Devuelve el valor de la variable alto.

3.2.3.6.1.2 Clase “Mapa”

Es la clase que contiene los datos de la red viaria. La clase se muestra en el

siguiente gráfico.

Mapacod_mapa : unsigned intnombre_mapa : char[255]Lista_nodos : Lista_inf<Punto>Lista_tramos : Lista_inf<Tramo>Lista_pm : TList*

Codigo() : unsigned intNombre_Mapa() : char*Actual iza_codigo(codigo : int)Actual iza_nombre_mapa(nombre : char*)Obtener_nodo(i : int) : PuntoObtener_tramo(i : int) : TramoLectura_pm(fichero : char*)Leer_nodos(nombre_fichero : char*)Leer_tramos(nombre_fichero : char*)Buscar_nodo(cod_nodo : unsigned int) : PuntoBuscar_tramo(cod_tramo : unsigned int) : Tramo

Figura 3.2-31. Clase “Mapa”

• Atributos de la clase “Mapa”:

o cod_mapa: Código que identifica el mapa que esta siendo utilizado.

o nombre_mapa: Nombre del mapa. Es una información aclaratoria del

mapa y complementaria al código del mapa.

o Lista_nodos: Lista de los nodos que componen la red viaria.

o Lista_tramos: Lista de los tramos que componen la red viaria y unen los

nodos de la misma.

82


o Lista_pm: Lista de los tramos que poseen detectores magnéticos de

tráfico.

• Métodos de la clase “Mapa”:

o unsigned int Codigo(void): Devuelve el valor del atributo cod_mapa.

o char* Nombre_Mapa(void): Devuelve el valor del atributo

nombre_mapa.

o void Actualiza_codigo(int codigo): Modifica el valor del atributo

cod_mapa.

o void Actualiza_nombre_mapa(char* nombre): Modifica el valor del

atributo nombre_mapa.

o Punto Obtener_nodo(int i): Devuelve el elemento i-ésimo de la lista de

nodos.

o Tramo Obtener_tramo(int i): Devuelve el elemento i-ésimo de la lista

de tramos.

o void Lectura_pm(char* fichero): Lee de un archivo de nombre fichero

la lista de tramos con detectores y la guarda en el atributo Lista_pm.

o void Leer_nodos(char*fichero): Carga la lista de nodos del archivo de

nombre fichero.

o void Leer_tramos(char*fichero): Carga la lista de tramos del archivo de

nombre fichero.

o Punto Buscar_nodo(unsigned int cod_nodo): Devuelve el nodo con

código de nodo igual a cod_nodo.

o Tramo Buscar_tramo(unsigned int cod_tramo): Devuelve el tramo con

código de nodo igual a cod_tramo.

83


3.2.3.6.1.3 Clase “Punto”

La clase Punto instancia objetos que representan a las intersecciones del viario.

Puntocod_nodo : unsigned intdescripcion : char[255]cod_estructura : unsigned inttipo : unsigned intcoord_x : floatcoord_y : float

Cod_Nodo() : unsigned intDescripcion() : char *Cod_Estructura() : unsigned intTipo() : unsigned intCoord_X() : floatCoord_Y() : floatActual iza_Cod_Nodo(u : unsigned int)Actual iza_Descripcion(cadena : char*)Actual iza_Cod_Estructura(u : unsigned int)Actual iza_Tipo(u : unsigned int)Actual iza_Coord_X(f : float)Actual iza_Coord_Y(f : float)operator=(p : Punto) : Puntooperator==(p : Punto) : bool

Figura 3.2-32. Clase “Punto”

• Atributos de la clase “Punto”:

o cod_nodo: Código del nodo que representa el objeto y lo diferencia del

resto de nodos de la red.

o descripcion: Cadena de texto que sirve de identificación del nodo. Es

informativa.

o cod_estructura: Estructura actual de funcionamiento del nodo.

o tipo: Variable que indica si el nodo es un centroide o no. Sólo los

centroides son origen o destino de viaje. El resto son de tránsito.

84


o coord_x: Variable que indica la coordenada x del nodo para su

representación gráfica.

o coord_y: Variable que indica la coordenada y del nodo para su

representación gráfica.

• Métodos de la clase “Punto”:

Los métodos de esta clase son los correspondientes a la obtención y

modificación de los valores de los atributos, por lo que su significado es

suficientemente claro y no se detallará. La sobrecarga de los operadores

posibilita la implementación de listas con objetos de esta clase como

elementos de la misma.

3.2.3.6.1.4 Clase “Datos_cruce”

Esta clase da información acerca de un nodo determinado, indicándo si el nodo

en cuestión tiene una caja semafórica asociada. Se describirá los atributos y métodos

más interesantes.

Datos_crucenodo : unsigned intdefinida_caja : bool

Actualiza_informacion(p : Punto)Actualiza_definida_caja(n : bool)Definida_caja() : boolNodo() : unsigned intActualiza_nodo(n : unsigned int)

Figura 3.2-33. Clase “Datos_cruce”

• Atributos de la clase “Datos_cruce”:

o nodo: Código del nodo al que pertenecen los datos del cruce.

o definida_caja: Atributo que indica si el nodo al que hacen referencia los

datos de la clase tiene caja semafórica asociada.

85


• Métodos de la clase “Datos_cruce”:

o void Actualiza_informacion(Punto p): Actualiza todos los datos de la

clase con la información del punto que se le pasa a la función. Por

defecto, sitúa el valor de definida_caja en falso.

o void Actualiza_definida_caja(bool n): Actualiza el valor del atributo

definida_caja.

o bool Definida_caja(): Devuelve el valor del atributo definida_caja.

o unsigned int Nodo(): Devuelve el valor del atributo nodo.

o void Actualiza_nodo(unsigned int n): Modifica el valor del atributo

nodo.

3.2.3.6.2 Diagrama de clases del paquete “Viario”


interrelación.

86


Mapa

Contexto

1

1

1

1

Coordinacion_interactiva(from Interfaz gráfica)

1

1

+hace uso de

1

1

Datos_cruce

Punto0..*1 0..*1

1

1

1

1

+se relaciona con

Figura 3.2-34. Diagrama de clases del paquete Viario

4 Implementación del modelo e interfaz gráfica.

4.1 Introducción

Para la implementación del modelo y posterior resolución se ha optado por el

uso de un lenguaje orientado a objetos como es C++. Más concretamente se ha

empleado el entorno de programación que proporciona la herramienta C++ Builder, la

cual suministra un entorno de programación visual que facilita en gran medida el

empleo de un lenguaje como C++, que se caracteriza por tener una gran cantidad de

reglas y términos diferentes.

En este apartado se va a realizar una descripción muy breve de lo que es la

programación orientada a objetos y de aquellos componentes fundamentales que forman

parte de la misma.

87

Implementación del modelo e interfaz gráfica

La programación orientada a objetos (POO) se define como una técnica o estilo

de programación que utiliza objetos como bloque esencial de construcción. Un objeto es

una unidad que contiene datos y las funciones que operan sobre esos datos. Estos

objetos se corresponden con los elementos que debe utilizar el programa, como pueden

ser los tramos o los vehículos en el caso del simulador.

Una clase es una colección de objetos que poseen características y operaciones

comunes. En una clase se encuentra contenida toda la información necesaria para crear

nuevos objetos pertenecientes a esa misma clase.

Los objetos solamente pueden ser accedidos y manipulados por las operaciones

que previamente se hayan definido sobre su clase. Para evitar que dichos objetos sean

utilizados en otras operaciones, se utiliza una técnica denominada encapsulación, que

esconde los datos y sólo permite acceder a ellos de forma controlada.

Otros conceptos de interés en la POO son el polimorfismo que permite utilizar

un mismo nombre para un tipo genérico de acciones, y la herencia, mediante la cual un

objeto puede adquirir las propiedades de otro objeto.

4.2 Implementación del modelo

Para la resolución del problema se ha optado por implementar el segundo

modelo de los vistos en el apartado 3 de esta memoria, modelo extendido de

maximización del ancho de banda, que trata de obtener el mayor intervalo de tiempo

posible para que los vehículos puedan atravesar la avenida sin detenerse ante alguna

señal luminosa de tráfico.

Dicho modelo de programación lineal, coordina las señales de una avenida,

teniendo en cuenta que el flujo de tráfico puede ser más espeso en la dirección de salida

en un momento determinado o en la dirección de entrada en otro. Ésta situación se

modela a través de un factor de proporción que denominamos k. Además, este modelo

88


considera la velocidad a la que los conductores pueden transcurrir a lo largo de los

diferentes tramos formados por la distancia existente entre dos semáforos consecutivos,

limitándola superior e inferiormente. También nos permite controlar los cambios en la

velocidad de los vehículos para que estos no sean demasiados abruptos. Para

conseguirlo, lo que se hará será limitar inferior y superiormente el recíproco de la

velocidad.

El modelo se construirá de forma que sea interpretable por el programa de

optimización lineal, xa, que se usará para la resolución del problema de coordinación.

Dicho programa, recibe un archivo que contiene el problema de programación lineal

que se quiere resolver, y devuelve un archivo con la solución del mismo. Archivo, que

posteriormente será procesado para la obtención de los datos necesarios para la

presentación de la solución.

El diseño del programa va ser representado mediante los diagramas de flujo

correspondientes a la implementación en C++ de las funciones principales que

intervienen en él.

La estructura básica del programa de coordinación de señales de tráfico viene

determinada por el diagrama de flujo de la figura 5.2-1.

89


Figura 4.2-1 Estructura general del programa

En primer lugar se carga el escenario, del cual se obtendrá los nodos de la

avenida que se coordinará, después se obtienen los datos del modelo mediante la carga

de los archivos de cajas asociados a los nodos seleccionados y que contienen toda la

información acerca de las señales luminosas de tráfico que rigen a éstos. Los demás

datos necesarios para la construcción del modelo, se obtienen por medio de la

interacción entre el usuario y la interfaz gráfica. A continuación, se construye el archivo

que contiene el modelo de coordinación y que se le pasará a la xa para que resuelva el

problema lineal. Finalmente se presentan los resultados obtenidos al usuario.

Siguiendo el diagrama de flujo de la figura 4.2-1, se puede describir con más

detalles los bloques que lo conforman. Se comienza por describir el segundo bloque, ya

que en el primero, Carga Escenario, tan solo se obtienen los datos referentes a los

90


distintos nodos y tramos que componen el viario. En el segundo bloque el usuario

selecciona los nodos que forman parte de la avenida que se quiere coordinar, una vez

seleccionados éstos, se visualiza la caja semafórica asociada al nodo elegido o se le

asocia una en caso de no tener éste ninguna asociada. Tras visualizar la caja, se

selecciona la señal que se quiere coordinar y se extrae de la misma mediante el siguiente

método:

91


Inicio

Sí

nombre=Application->Exenamenombre_caja=nombre.SetLength(nombre.Length()-12)nombre_caja=nombre_caja+AnsiString(“datos\\Caja\\

N_”)+AnsiString(nodo)+AnsiString(“.caj”)extracion=senal_sen.Importar_senal(nombre_caja.c_str(),&n_ele

mentos,estructura,nodo)

!asociada

Extracion==false

senal_sen=caja.Elemento(estructura)extracion=true

No

return(extracion)Sí

lista_fase.Crea_lista()lista_intermedio.Crea_lista()

*tiempo_ciclo=senal_sen.Ciclo()lista_fase=senal_sen.Lista_fases()

lista_intermedio=senal_sen.Lista_intermedios()n_fases=(int)senal_sen.Numero_fases()

f_aux=n_fases*(senal)i=0

No

i<n_fases

fase_aux=Lista_fase.Elemento(f_aux+i)n_inte=n_inte+(int)fase_aux.Numero_in

termedios()lista_f->Add_elemento(fase_aux)

i++

Sí

i_aux=n_inte*(senal)j=0No

J<n_intelista_fase.Destruir_lista()

lista_intermedio.Destruir_lista()return(extracion)

j++

inte_aux=lista_intermedio.Elemento(i_aux+j)lista_i->Add_elemento(inte_aux)

Sí

No

Fin

Figura 4.2-2 Extracción de una señal determinada de una caja semafórica

92


Se puede comprobar en la figura 4.2-2, que para la extracción de la señal es

necesario saber si el nodo seleccionado tiene una caja asociada o no, puesto que de esto

depende el que la extracción se realice de un modo u otro. Esto se debe a que el formato

del archivo en el que se guardan los datos de las señales de una caja es diferente para

aquellos nodos que tienen una asociada. Una vez se ha extraído los datos de la caja del

nodo elegido, se obtienen los datos de la señal de una lista que contiene la información

acerca de las fases de las señales de la caja y de otra lista que contiene los datos de los

intermedios.

Conformada la lista de señales de la avenida que se quiere coordinar, se pasa a

resolver el modelo creado a partir de esta lista y de los datos referentes a distancia entre

tramos de la avenida y velocidades de los vehículos en los mismos, datos éstos,

obtenidos a través de la relación entre el usuario y la interfaz gráfica.

Hasta aquí llega el segundo bloque del diagrama de flujo de la figura 4.2-1, a

partir de ahora todos los métodos que se van a ver forman parte del tercer bloque de este

diagrama y son aquellos encargados de generar y resolver el modelo así como de

presentar los datos obtenidos al usuario.

Antes de mostrar a través del diagrama de flujo correspondiente el método que

se encarga de generar el modelo, se explica el formato del archivo en el cual se guardará

el modelo generado y que se le pasará a la xa para que lo resuelva. Para explicar el

formato de este archivo se usa el ejemplo que se muestra en la figura 4.2-3:

93


Figura 4.2-3 Ejemplo del formato de un archivo de entrada a la xa

Se observa en la figura 4.2-3, como en la cabecera del archivo se introduce el

título del modelo, cuya importancia es nula, el siguiente paso es indicar a la xa si lo que

se desea es maximizar o minimizar la función objetivo del problema, que para el

modelo usado será maximizar puesto que el objetivo de la coordinación es que las

bandas verdes a través de las cuales un vehículo puede atravesar la avenida sin

detenerse sean lo más anchas posibles. A continuación, se desarrolla la función objetivo

en la que además de indicar la proporción en la cual participan las variables del

problema se indica si alguna de ellas ha de ser un numero entero, lo que se expresa

mediante la situación de la variable entre paréntesis, como en el caso de M1 en el

ejemplo. Tras expresar la función objetivo, se exponen las restricciones del problema,

en éstas, deben de estar las variables a la izquierda de la igualdad y la parte numérica a

94


la derecha. En la parte final del modelo, se expresan como restricciones los posibles

valores que pueden tomar las variables del problema.

Una vez explicado el formato que deben de tener los archivos que contienen el

problema lineal a resolver, se puede describir el método que los genera mediante su

diagrama de flujo:

95


Inicio

DecimalSeparator='.'nombre=street + ".lp"

archivo=fopen(nombre.c_str(),"w+t")fprintf(archivo,"..TITLE\n")

fprintf(archivo," Coordinacion semaforica deavenida\n\n")

fprintf(archivo,"..OBJECTIVE MAXIMIZE\n")auxiliar=" B1 + B2 + 0 Z + \n"

l=0

l<signal_group.Numero_elementos()

auxiliar+=" + 0 W1" + AnsiString(l+1)auxiliar+=" + 0 W2" + AnsiString(l+1)

Sí

l<signal_group.Numero_elementos()-1

auxiliar+=" + 0 T1" + AnsiString(l+1)auxiliar+=" + 0 [M" + AnsiString(l+1)

auxiliar+="] + 0 T2" +AnsiString(l+1) + " +\n"

Sí

l++

No

fprintf(archivo,auxiliar.c_str()) fprintf(archivo,"\n\n")fprintf(archivo,"..CONSTRAINTS\n")

auxiliar="R1: B2 - " + AnsiString(dato.Leer_valor_k()) + " B1 = 0"fprintf(archivo,auxiliar.c_str())

fprintf(archivo,"\n") auxiliar="R2: Z >= " + AnsiString(1.0/ciclo_max)

fprintf(archivo,auxiliar.c_str()) fprintf(archivo,"\n")

auxiliar="R3: Z <= " + AnsiString(1.0/ciclo_min)fprintf(archivo,auxiliar.c_str())

fprintf(archivo,"\n") aux=4

i=0

i<signal_group.Numero_elementos()

No

senal_aux=signal_group.Elemento(i)fases_senal.Crea_lista()

fases_senal=senal_aux.Leer_lista()n_fases=fases_senal.Numero_eleme

ntos()j=0

Sí

j<n_fases

auxiliar="R" + AnsiString(aux) + ": B1 >= 0"fprintf(archivo,auxiliar.c_str())

fprintf(archivo,"\n") aux=aux+1

auxiliar="R" + AnsiString(aux) + ": B2 >= 0"fprintf(archivo,auxiliar.c_str())

fprintf(archivo,"\n") fases_senal.Destruir_lista() fclose(archivo)

Fin

No

Sí

J++

No

Notciclo=senal_aux.Leer_ciclo()

ri=(tiempo*1)/tciclolista_rojos->Add_elemento(ri)

i++

96


fase_senal=fases_senal.Elemento(j)

color=fase_senal.Color()

color=='B'

Sí

suma=fase_senal.Tiempo()tiempo=tiempo+suma

Sí

No

i!=0

anterior=ri-anteriorauxiliar="R" + AnsiString(aux) + ": (W1" + AnsiString(i)

auxiliar+=" + W2" + AnsiString(i) + ") - (W1" + AnsiString(i+1)auxiliar+=" + W2" + AnsiString(i+1) + ") + (T1" + AnsiString(i)

auxiliar+=" + T2" + AnsiString(i) + ") - M" + AnsiString(i)auxiliar+=" = " + AnsiString(anterior)

fprintf(archivo,auxiliar.c_str())fprintf(archivo,"\n")

aux=aux+1

Sí

i<signal_group.Numero_elementos()-1

No

auxiliar="R" + AnsiString(aux) + ": T1" + AnsiString(i+1) + " - " +AnsiString(dato.Leer_elemento_distancia(i)/dato.Leer_elemento_velocidad_max1(i)) + " Z >= 0"


aux=aux+1 auxiliar="R" + AnsiString(aux) + ": T1" + AnsiString(i+1) + " - " +

AnsiString(dato.Leer_elemento_distancia(i)/dato.Leer_elemento_velocidad_min1(i)) + " Z <= 0"fprintf(archivo,auxiliar.c_str())


auxiliar="R" + AnsiString(aux) + ": T2" + AnsiString(i+1) + " - " +AnsiString(dato.Leer_elemento_distancia(i)/dato.Leer_elemento_velocidad_max2(i)) + " Z >= 0"


aux=aux+1 auxiliar="R" + AnsiString(aux) + ": T2" + AnsiString(i+1) + " - " +

AnsiString(dato.Leer_elemento_distancia(i)/dato.Leer_elemento_velocidad_min2(i)) + " Z <= 0"fprintf(archivo,auxiliar.c_str()) fprintf(archivo,"\n")

aux=aux+1 auxiliar="R" + AnsiString(aux) + ": T1" + AnsiString(i+1) + " >= 0"

fprintf(archivo,auxiliar.c_str()) fprintf(archivo,"\n") aux=aux+1

auxiliar="R" + AnsiString(aux) + ": T2" + AnsiString(i+1) + " >= 0" fprintf(archivo,auxiliar.c_str())


Sí

i==0

No

di_anterior=dato.Leer_elemento_distancia(i) Sí

i>0 &&i<signal_group.Numero_

elementos()-1

No

Sí

No

97


di_actual=dato.Leer_elemento_distancia(i) auxiliar="R" + AnsiString(aux) + ": " + AnsiString(di_anterior/di_actual) + " T1" + AnsiString(i+1)

auxiliar+=" - T1" + AnsiString(i) + " - " +AnsiString(di_anterior*(dato.Leer_elemento_cambiove_max1(i-1))) + " Z <= 0"


aux=aux+1 auxiliar="R" + AnsiString(aux) + ": " + AnsiString(di_anterior/di_actual) + " T1" + AnsiString(i+1)

auxiliar+=" - T1" + AnsiString(i) + " - " +AnsiString(di_anterior*(dato.Leer_elemento_cambiove_min1(i-1))) + " Z >= 0"



auxiliar+=" - T2" + AnsiString(i) + " - " +AnsiString(di_anterior*(dato.Leer_elemento_cambiove_max2(i-1))) + " Z <= 0"



auxiliar+=" - T2" + AnsiString(i) + " - " +AnsiString(di_anterior*(dato.Leer_elemento_cambiove_min2(i-1))) + " Z >= 0"


aux=aux+1di_anterior=di_actual

Sí

Sí

anterior=ri ri=1-ri

auxiliar="R" + AnsiString(aux) + ": W1" + AnsiString(i+1) + " + B1 <= " + rifprintf(archivo,auxiliar.c_str())


auxiliar="R" + AnsiString(aux) + ": W2" + AnsiString(i+1) + " + B2 <= " + rifprintf(archivo,auxiliar.c_str())


auxiliar="R" + AnsiString(aux) + ": W1" + AnsiString(i+1) + " >= 0"fprintf(archivo,auxiliar.c_str())


auxiliar="R" + AnsiString(aux) + ": W2" + AnsiString(i+1) + " >= 0"fprintf(archivo,auxiliar.c_str())

fprintf(archivo,"\n") aux=aux+1 tiempo=0 n_fases=0

No

Figura 4.2-4 Método que crea el archivo que contiene el problema lineal de

coordinación

Como se puede ver en el diagrama de flujo, al mismo tiempo que el modelo se

crea según el patrón legible por la xa se va escribiendo el archivo de entrada a ésta. Este

método crea un archivo con un nombre específico y con la extensión “.lp”, el cual, se

pasa como parámetro a la función que resuelve el problema lineal. Dicha función

determina si la solución al problema aportada por la xa a través de un fichero de salida

es óptima o por el contrario, es irrealizable.

Antes de describir la función que resuelve el problema, se va a explicar el

formato del archivo de salida de la xa mediante un ejemplo:

98


Figura 4.2-5 Primera parte del archivo de salida de la xa

Lo primero que se ve en el archivo de salida es el modelo que se acaba de

resolver, tal y como se escribió en el archivo de entrada, después se presentan las

estadísticas del modelo y la información de si el modelo tiene solución optima o no, y

en caso de tenerla (como en el ejemplo de la figura 4.2-5) el valor óptimo de la función

objetivo.

El objetivo de la función que se encarga de resolver el modelo, no sólo es el de

llamar a la xa, si no también el de determinar si el modelo planteado tiene solución

óptima. Para ello, como se puede comprobar en el diagrama de flujo de la figura 4.2-6,

se procesa el archivo de salida de la xa en busca de la cadena de caracteres formada por

las letras “OPT” de la palabra “óptima” (ver figura 4.2-5), ya que esta sucesión de letras

tan sólo aparece en el archivo de salida cuando el problema presenta solución.

A continuación se muestra el diagrama de flujo de la función de la que se acaba

de hablar:

99


Inicio

nombre_aux=nombre_entrada num_c=nombre_aux.Length() num_c=num_c-3 nombre_aux.SetLength(num_c) *nombre_salida=nombre_aux + ".dat"

nombre=Application->ExeName nombre=nombre.SetLength(nombre.Length() - 12) auxiliar=nombre + "xa.exe"

result = spawnl(P_WAIT,auxiliar.c_str(),auxiliar.c_str(), "Modeloxa.lp", "output","Modeloxa.dat",NULL) auxiliar=*nombre_salida

nombre=nombre + *nombre_salida *nombre_salida=nombreF1=fopen(nombre.c_str(),"rt")

auxiliar!="|"fgets (cadena,2,F1)

auxiliar=AnsiString(cadena)Sí

auxiliar=="O"

fgets (cadena,2,F1)auxiliar=AnsiString(cadena)

auxiliar==" "


auxiliar=="P"


auxiliar==" "


auxiliar=="T"fclose(F1) return(true)

fclose(F1) return (false)

Sí

Sí

Sí

Sí

Sí

Fin

No

No

Figura 4.2-6 Método que resuelve el problema lineal de coordinación

100


Una vez que se comprueba la viabilidad del problema planteado, se pasa al

análisis del archivo de salida para obtener los valores de las variables para la solución

óptima dada. Antes de describir el método que se encarga de procesar el archivo, se

describirá la segunda parte del archivo de salida mediante el ejemplo de la figura 4.2-7.

Figura 4.2-7 Segunda parte del archivo de salida de la xa

Como se puede ver en la figura el archivo de salida presenta en una tabla el valor

de todas las variables así como su coste. Hay que comentar que esta tabla sólo aparece

cuando el problema planteado tiene solución. Esta parte del archivo se encuentra por

debajo de la parte mostrada en la figura 4.2-5. Además de las partes mostradas del

archivo de salida, hay una tercera parte que no se muestra por carecer de interés para los

objetivos de este trabajo, que muestra como se cumplen las restricciones y el valor de

las variables del problema dual.

Se muestra ahora el diagrama de flujo del método que se encarga de realizar el

procesado del archivo que se acaba de comentar:

101


Inicio

F1=fopen(nombre_archivo.c_str(),"rt")

auxiliar!="|"


Sí

retorno!=2

No

fgets (cadena,2,F1)auxiliar=AnsiString(ca

dena)

auxiliar=="\n"

retorno++

Sí

Sí

No

num_senales=Numero_elemento_ListBox_senal()num_senales=num_senales*5

filas=num_senales/2 num_senales=filas

i=0

No

i<num_senales

primero=falsej=1

Sí

j<9

fscanf(F1,"%s",cadena)caracter=cadena[0]

Sí

J++

No

i++

No

102


(caracter=="|" ||caracter=="I") &&

primero

fin++

Sí

fin==2

No

fclose(F1)return

j==2

Sí

No

auxiliar=AnsiString(cadena)var_auxiliar.Actualiza_nombre(auxiliar)

j==3

Sí

No

auxiliar=AnsiString(cadena)filas=auxiliar.ToDouble()

var_auxiliar.Actualiza_valor(filas) variables->Add_elemento(var_auxiliar)

primero=true

j==6

Sí

No

auxiliar=AnsiString(cadena)var_auxiliar.Actualiza_nombre(auxiliar)

j==7

Sí

No

auxiliar=AnsiString(cadena)filas=auxiliar.ToDouble()

var_auxiliar.Actualiza_valor(filas) variables->Add_elemento(var_auxiliar)

Sí

No

NoNo

103


retorno=0fin=0

retorno!=3


Sí

auxiliar=="\n"

retorno++

Sí

No

No

fclose(F1)

Fin

No

Figura 4.2-8 Método que procesa el archivo de salida de la xa

En el diagrama de flujo de la figura 4.2-8 se ve como se va obteniendo los

valores de las variables de la tabla del archivo de salida y se van almacenando en un

lista para después poder calcular los desfases que deben tener las señales entre sí para

maximizar el ancho de banda.

Por último, en este bloque se procede a la presentación de los resultados, es

decir, el modelo de coordinación, el ancho de banda en ambas direcciones, el tiempo de

ciclo y el desfase de cada una de las señales con respecto a la primera.

Hasta aquí llega todo lo referente a la implementación del modelo, en la que se

ha visto en detalle aquellas funciones cuyo interés es más destacado, a partir de ahora se

entra en la descripción de la interfaz gráfica con la cual interactúa el usuario.

104


4.3 Interfaz gráfica

A continuación se realiza una descripción de la interfaz gráfica a través de la

cual el usuario va a poder plantear el problema de coordinación, resolver dicho

problema y visualizar la solución del mismo. Para la descripción se va a usar una serie

de capturas de pantalla que facilitarán la compresión de la misma.

Se inicia el programa global sobre tráfico en el que se encuentra enmarcado este

trabajo, a continuación se procede a la carga del escenario en el cual se encuentra la

avenida cuyas señales luminosas de tráfico se quieren coordinar. Ahora, se selecciona la

acción que sobre el escenario se quiere realizar, en este caso, la coordinación

semafórica, como se puede ver en la figura 4.3-1.

Figura 4.3-1 Muestra la selección de nuestra aplicación

105


Una vez dentro de la aplicación desarrollada, se encuentra una pantalla con tres

pestañas, en la primera pestaña se tiene todo lo necesario para seleccionar los nodos

pertenecientes a la avenida que se quiere coordinar, así como lo necesario para

seleccionar las señales que se van a coordinar.

Zona de elección de nodos

Minimapas Elección de señales de la caja visualizada

Figura 4.3-2 Pantalla de selección de los nodos cuyas señales se van a coordinar

Como se puede ver en la figura 4.3-2, se tiene una zona en la que hay una lista

con todos los nodos que hay en el escenario cargado, para seleccionar un nodo se puede

buscar a través de los minimapas o bien en la lista. Una vez elegidos los nodos que

conforman la avenida a coordinar, se visualizan las cajas asociadas a los mismos, es

decir, las señales semafóricas que rigen dichos nodos. Puede ocurrir que un nodo no

106


tenga asociada ninguna caja, en cuyo caso, la aplicación permite importar una y en caso

de que se quiera, asociársela tal y como se observa en la figura 4.3-3. En el supuesto de

que se haya asociado la caja importada al nodo elegido, se tiene luego la posibilidad de

deshacer esta asociación, por lo que la aplicación permite importar, asociar y eliminar la

asociación entre una caja y un nodo.

Figura 4.3-3 Aplicación que permite importar una caja a un nodo

Para facilitar la elección de la señal que se quiere coordinar, se puede ver un

gráfico de las señales que componen la caja semafórica pulsando sobre la pestaña

“Representación caja”, tal y como se puede apreciar en la figura 4.3-4.

107


Figura 4.3-4 Representación gráfica de una caja semafórica asociada a un nodo

Una vez que hemos confeccionado la lista de señales que se quieren coordinar se

pasa a la fase de introducción de los datos de distancia entre tramos, velocidades

máximas y mínimas entre los mismos y cambios en la velocidad máximos y mínimos,

datos éstos, necesarios para la construcción del modelo lineal de maximización de

ancho de banda. Para introducir los datos se selecciona la pestaña “Ancho de banda”

que muestra a una pantalla en la que se encuentran cuadros de texto donde se pueden

introducir los datos y una zona en la que se expone la solución al problema de

coordinación. En esta zona, se puede observar en la figura 4.3-5 que por defecto

muestra el modelo lineal que se le pasa a la xa para que lo resuelva.

108


Zona de introducción de datos

Zona de presentación de resultados

Figura 4.3-5 Interfaz para la introducción de datos y presentación de resultados

A través de las pestañas de la zona de presentación de resultados se obtiene los

aspectos más importantes de la solución al problema de coordinación, así de este modo

se puede optar por visualizar el modelo construido a partir de las señales a coordinar y

de los datos suministrados a la interfaz como ocurre en la figura 4.3-5, por visualizar el

tiempo de ciclo adecuado así como los anchos de banda en la dirección de salida y

entrada a la avenida para la solución óptima dada por la xa, o bien visualizar a través de

la pestaña “Desfase” de la zona de presentación de resultados, el tiempo que hay que

retrasar las señales respecto a la primera para conseguir que la coordinación sea óptima

para el problema planteado, como se puede ver en la figura 4.3-6.

109


Figura 4.3-6 Presentación de los resultados de desfase entre las señales

Como se ha visto la interfaz no presenta ningún tipo de complicación y tan sólo

hay que conocer la construcción del problema para el manejo correcto y útil de los

resultados.

110


5 Pruebas del sistema

En este capítulo se va a realizar diferentes pruebas de la aplicación creada con el

fin de mostrar la finalidad de la misma. Se llevará a cabo dos tipos de pruebas, la

primera tratará de demostrar que el programa utilizado por la aplicación para la

resolución del problema de programación lineal, xa, funciona correctamente; mientras

que el segundo tipo de prueba mostrará la utilidad de la aplicación para un caso real

situado en la ciudad de Móstoles, de la cual, se tiene los datos referentes a la señales

reguladoras de tráfico de las avenidas donde se va a realizar la coordinación.

5.1 Prueba de funcionamiento de la XA

En este apartado se demostrará el correcto funcionamiento de la xa, programa

que usa la aplicación para resolver el problema lineal de coordinación.

Para realizar esta demostración se va a resolver por un lado, un modelo de

coordinación mediante la aplicación desarrollada y por otro, se resolverá el mismo

modelo usando la utilidad de resolución de problemas lineales que se encuentra en el

programa Excel asociado al paquete de Microsoft Office y que se denomina Solver. A

continuación se describirá el modelo que se va a resolver mediante ambas aplicaciones.

Para demostrar la validez de la xa se va a realizar la coordinación de señales

luminosas de tráfico situadas en una avenida del escenario que se va a usar. Este

escenario está compuesto por 1345 nodos, de los cuales, sólo se utilizarán tres, donde se

suponen ubicados los semáforos que se van a coordinar. Además, estos nodos estarán

unidos por dos tramos de los 4422 que conforman el escenario, y de los que se conocen

su longitud, así como la velocidad a la que los vehículos podrán circular por ellos.

Dicho escenario se puede ver en la siguiente figura:

111

Pruebas del sistema

Figura 5.1-1 Escenario de la prueba de validez

Los nodos que se han seleccionado para la coordinación son el 586-585-584, a

los cuales, se le han asignado una caja de forma que: nodo 586 → caja 23, nodo 585 →

caja 21 y nodo 584 → caja 22. De cada caja se extrae una señal, así pues de la caja 23 se

toma la señal 2, de la caja 21 se coge la señal 1 y de la caja 22 se extrae la señal 1. La

representación gráfica de estas señales se puede observar en la siguiente figura:

112

Pruebas del sistema

Caja 23

Caja 21

Caja 22

Señales elegidas de su caja correspondiente

Señal elegida en esta caja

Figura 5.1-2 Representación gráfica de las señales a coordinar

A través de una tabla se exponen los datos de distancia entre los tramos que unen

los nodos, las velocidades máximas y mínimas a las que se va a poder circular por las

mismas y los cambios en la velocidad máximos y mínimos (esto evita que los cambios

en la velocidad del vehículo sean bruscos), que junto con los datos del tiempo en rojo y

el ciclo de las señales extraídas de las cajas, permiten conformar el modelo de

programación lineal con el que se resuelve el problema de coordinación.

113

Pruebas del sistema

Tramos del nodo 1 al nodo 2

del nodo 2 al nodo 3

Distancia (m) 75 70 Velocidad máxima outbound (m/s) 11.11 9.72 Velocidad máxima inbound (m/s) 11.11 9.72 Velocidad mínima outbound (m/s) 9.72 8.33 Velocidad mínima inbound (m/s) 9.72 8.33 Cambio velocidad máxima outbound (s/m) 0.015 Cambio velocidad máxima inbound (s/m) 0.015 Cambio velocidad mínima outbound (s/m) 0.01 Cambio velocidad mínima inbound (s/m) 0.01

Tabla 5.1-1 Datos de distancia, velocidades y cambios en la velocidad

Con todos los datos de los que se disponen junto con el dato de la constante de

proporcionalidad entre el ancho de banda de salida y entrada, k = 3 para este caso, se

puede construir el modelo de programación lineal cuya solución proporciona el ancho

de banda verde en ambas direcciones. El modelo que se usa es el del problema

extendido de maximización del ancho de banda que se explicó en el apartado 2.3.2. De

manera que el problema lineal generado es el siguiente:

114

Pruebas del sistema

Figura 5.1-3 Programa lineal de maximización del ancho de banda

A continuación se expone la solución al problema aportada por ambas

aplicaciones.

5.1.1 Solución aportada por la XA

A través de la interfaz gráfica explicada en el apartado 4, se crea el modelo de

coordinación mediante la selección de los nodos (ver figura 5.1-4) y de las señales de

las cajas asociadas a estos.

115

Pruebas del sistema

Nodos y tramos que vamos a coordinar

Figura 5.1-4 Avenida que vamos a coordinar

Tras introducir los datos de distancia y de velocidades se pasa a resolver el

problema usando la xa, obteniéndose los siguientes valores de las variables:

B1 B2 Z W11 W21 T11 M1

0.16667 0.50000 0.01250 0.14091 0.00000 0.08708 0.00000

T21 W12 W22 T12 M2 T22 W13 W23

0.08708 0.15329 0.04000 0.09002 0.00000 0.09002 0.33333 0.00000

Tabla 5.1.-2 Valor de las variables en el óptimo

116

Pruebas del sistema

Conociendo el valor de las variables se obtiene el valor de lo datos que interesan

mediante las fórmulas explicadas en los apartados 2.3.2 y 2.3.2.1. Estos son el ciclo, el

ancho de banda en ambas direcciones y el desfase de una señales con otras.

Ciclo señales Ancho banda

salida

Ancho banda

entrada

Desfase señales

1-2

Desfase señales

1-3

80 13.3336 40 18.2392 25.2056

Tabla 5.1-3 Valor de los datos de interés

Ahora se representa gráficamente como quedan las señales luminosas de tráfico

una vez han sido coordinadas, es decir, habiéndole aplicado el retraso calculado

anteriormente.

Figura 5.1-5 Representación gráfica de la coordinación

117

Pruebas del sistema

Por tanto, un vehículo que llegue al primer semáforo dentro de la banda puede

atravesar la avenida conformada por los tres semáforos sin detenerse en ninguno y

circulando a la velocidad determinada por el usuario en cada tramo. Cabe comentar que

se considera cualquier tiempo que no sea rojo como tiempo durante el cual se puede

atravesar el semáforo sin detenerse.

A continuación se obtiene la solución al problema haciendo uso del Solver, que

será la misma que se obtiene mediante la xa, lo que confirma que ésta es una aplicación

válida para su uso en el programa aquí desarrollado.

5.1.2 Solución aportada por el Solver de Excel

Antes de mostrar la solución que se obtiene mediante esta utilidad se realizará

una descripción básica del funcionamiento de la misma para facilitar su comprensión.

5.1.2.1 Funcionamiento básico del Solver

Para la descripción de esta utilidad se va a usar un ejemplo práctico que se

muestra a continuación:

Max Z = 10 X1 + 8 X2

Sujeto a:

30X1 +20X2 <= 120

2X1 + 2X2 <= 9

4X1 + 6X2 <= 24

X1, X2 >=0

La única dificultad que se tiene es la de modelar el problema dentro del Excel, y

eso, es muy fácil. Por supuesto, hay infinidad de maneras de hacerlo, aquí se propone

una.

118

Pruebas del sistema

Se activa Excel y en una hoja:

• Se ubican las celdas que se corresponderán con el valor de las

variables de decisión; en éste caso, las celdas B6 y C6, se les da un

formato para diferenciarlas de las demás, aquí azul oscuro (ver figura

5.1-6). Se ubica también, las celdas que contendrán los costes de las

variables de decisión, B4 y C4, y se llenan con sus respectivos

valores, 10 y 8. Aunque éste último paso, se podría omitir y dejar los

coeficientes definidos en la celda de la función objetivo, así es mejor

para los análisis de sensibilidad y para que la hoja quede portable

para otro programa.

• Se ubica la celda que se corresponderá con la función objetivo (celda

objetivo), la B3. En ella se escribe la fórmula que representa a la

función objetivo, en éste caso, será el coeficiente de X1 (en B4) por

el valor actual de X1 (en B6) mas el coeficiente de X2 (en C4) por el

valor actual de X2 (en C6) O sea: =$B$4 * $B$6 + $C$6 * $C$4.

• Coeficientes para la primera restricción: se pueden escribir en la

misma columna de las variables de decisión; en las celdas B7 y C7,

con los valores 30 y 20, seguido del sentido de la desigualdad (≤) y

de su correspondiente RHS: 120. A la derecha se ubicará el valor

actual de consumo de la restricción, ella se escribirá en función de las

variables de decisión y de los coeficientes de la restricción. Esta

celda, la utilizará Solver como la restricción real cuando se le indique

que el valor de ésta celda no puede sobrepasar la de su

correspondiente RHS. De nuevo será el valor del coeficiente por el de

la variable:=B7 * $B$6 + C7 * $C$6. Nótese que ahora B7 y C7 no

tienen el signo $, ya que una vez que se haya escrito ésta celda, se

podrá arrastrar hacia abajo para que Excel escriba la fórmula

automáticamente. Se repite los pasos anteriores para las demás

restricciones.

119

Pruebas del sistema

Figura 5.1-6 Representación del problema en la hoja de cálculo de Excel

Ahora para resolverlo se debe hacer click en Herramientas->Solver,

obteniéndose una pantalla como la de la figura 5.1-7. Lo primero que hay que hacer es

especificar la celda objetivo, B3 en este caso, y el propósito: maximizar. A

continuación, se selecciona las celdas que van a cambiar como consecuencia de la

resolución del problema, es decir, el valor de las variables, que en este caso serán B6 y

C6. Esto se puede llevar a cabo bien escribiendo el nombre de las celdas en el recuadro

Cambiando las celdas, bien señalándolas en la hoja de cálculo directamente.

Figura 5.1-7 Configuración de los parámetros del Solver

120

Pruebas del sistema

Y ahora para las restricciones se hace click en agregar:

Figura 5.1-8 Agregar restricción a los parámetros del Solver

Como se puede ver en Referencia de la celda se introduce la celda en la cual el

Solver calculará el valor de la restricción. A continuación, se especifica el sentido de la

restricción ≤, ≥ ó =, aquí también se puede especificar el tipo de variable, que por

defecto es continua, pero se puede escoger "Int" para entera o "Bin" para binaria. En el

recuadro de la derecha se establece la cota. Aquí se escribirá 120 pero mejor se escribe

$E$7 para que quede direccionado a la celda que contiene el 120, lo que permite poder

después cambiarlo y volver a encontrar la respuesta a manera de análisis de sensibilidad.

Se repite éste paso para las otras dos restricciones.

La condición por la que una variable no puede ser negativa hay que incluirla

manualmente del siguiente modo:

Figura 5.1-9 Condición de no negatividad

121

Pruebas del sistema

El cuadro de diálogo debe quedar de la siguiente manera:

Figura 5.1-10 Resultado de la configuración de los parámetros del Solver

De este modo, con una hoja de cálculo de Excel y la utilidad Solver, se puede

escribir problemas lineales de manera muy flexible y resolverlos fácilmente.

Hasta aquí llega esta breve explicación de esta utilidad del Excel que facilita la

comprensión de la demostración de validez de la xa que a continuación se muestra.

5.1.2.2 Solución obtenida mediante el Solver

Mediante una hoja de cálculo de Excel se construye el problema lineal y como

se ha explicado en el punto anterior se resuelve con el Solver, obteniéndose el siguiente

resultado:

122

Pruebas del sistema

Figura 5.1-11 Hoja de cálculo con el problema lineal de coordinación

Se comprueba que la solución aportada por el Solver es la misma que la aportada

por la aplicación desarrollada, basada en la xa, aunque se observa que el valor de

algunas variables es diferente. Esto se debe a que el problema tiene más de una solución

óptima, es decir, hay una arista de la región admisible en la que todos sus puntos son

solución. Depende del método de resolución que use el programa, el que éste nos de una

u otra solución. En cualquier caso el valor de la función objetivo es el mismo en todas

las soluciones posibles.

Este resultado demuestra la validez de la xa como programa de resolución de

problemas lineales. Del mismo modo demuestra también el buen funcionamiento de la

aplicación desarrollada.

123

Pruebas del sistema

5.2 Prueba de la aplicación sobre un escenario real

En este punto se procede a la coordinación de dos avenidas situadas en un

escenario real como es la ciudad de Móstoles y de las que se conoce el número de

señales luminosas de tráfico y como se rigen éstas.

Las dos avenidas que se coordinan son la avenida de Carlos V y la avenida de

Alfonso XII que se observan en la figura 5.2-1. Hay que comentar que los datos de los

que se disponen de las avenidas y de las señales luminosas que las rigen se han obtenido

mediante medición manual, lo que quiere decir que están sujetos a ligeras variaciones

con respecto a los reales. Además esto provoca que no se conozca la distribución de los

intermedios de las señales con lo que la distribución de los tiempos se realizará de

manera aleatoria entre fases e intermedios.

Figura 5.2-1 Plano de las avenidas a coordinar

124

Pruebas del sistema

5.2.1 Prueba realizada en la avenida Carlos V

Se comienza por describir los datos que sobre la avenida se conocen, es decir, el

número y el color de las fases de las señales, así como la distancia existente entre los

distintos semáforos que rigen la avenida. También se exponen las limitaciones de

velocidad que se pondrán entre señal y señal, y la relación de proporción entre el ancho

de banda de entrada y salida. Por último se mostrará la solución propuesta por la

aplicación.

Antes de ver las señales que rigen esta avenida, hay que comentar que al

desconocer las fases, los intermedios y el comienzo del ciclo de la señal, se ha puesto

uno al azar que no obedece a ninguna norma preestablecida.

A continuación se ven las señales semafóricas que se van a coordinar:

Figura 5.2-2 Señales que rigen la avenida Carlos V

125

Pruebas del sistema

Conocidas las señales se muestran los datos de velocidades, cambios de

velocidad y distancias que se van a aplicar a la avenida a coordinar.

Tramos del nodo 1 al nodo 2

del nodo 2 al nodo 3

Distancia (m) 156 182 Velocidad máxima outbound (m/s) 12.5 9.72 Velocidad máxima inbound (m/s) 12.5 9.72 Velocidad mínima outbound (m/s) 11.11 8.33 Velocidad mínima inbound (m/s) 11.11 8.33 Cambio velocidad máxima outbound (s/m) 0.03 Cambio velocidad máxima inbound (s/m) 0.03 Cambio velocidad mínima outbound (s/m) 0.023 Cambio velocidad mínima inbound (s/m) 0.023

Tabla 5.2-1 Límites de velocidad, cambios de velocidad y distancia

El valor que se usa de la constante de proporcionalidad entre el ancho de banda

de entrada y salida es el de k = 1.

Con estos datos y habiendo creado las cajas que contienen las señales reales que

regulan la avenida de Carlos V, se pasa a resolver el problema haciendo uso de la

aplicación desarrollada. Para hacer uso de ésta se ha cargado un escenario cualquiera ya

que no se dispone del propio de la ciudad de Móstoles, y elegido tres nodos al azar a los

que se le han asociado momentáneamente las cajas creadas. Tras elegir las señales de

las cajas, se introducen los datos que se muestran en la tabla 5.2-1 y se resuelve el

modelo generado que se muestra en la siguiente figura:

126

Pruebas del sistema

Figura 5.2-3 Modelo lineal de coordinación de la avenida Carlos V

La resolución de este modelo genera unos resultados que se aprecian en la

siguiente tabla:

B1 B2 Z W11 W21 T11 M1

0.25076 0.25076 0.01111 0.34924 0.34924 0.15173 1.00000

T21 W12 W22 T12 M2 T22 W13 W23

0.13867 0.00000 0.00000 0.22353 0.00000 0.20829 0.07147 0.07147

Tabla 5.2-2 Solución del problema lineal de coordinación de la avenida Carlos V

127

Pruebas del sistema

Mediante la manipulación de estos resultados y la utilización de la fórmula que

proporciona el desfase que debe de haber entre una señal y otra para que el ancho de

banda de salida y entrada sea el obtenido, se obtienen los siguientes valores de interés:

Ciclo señales Ancho banda

salida

Ancho banda

entrada

Desfase señales

1-2

Desfase señales

1-3

90 22.5706 22.5706 13.6570 26.1386

Tabla 5.2-3 Datos de interés para la coordinación

Ya se esta en disposición de poder mostrar el resultado gráfico que se genera

como consecuencia de la aplicación de los desfases a las señales luminosas de tráfico

que regulan la avenida que se ha coordinado:

Figura 5.2-4 Resultado gráfico de la coordinación de la avenida Carlos V en la dirección

outbound

128

Pruebas del sistema

Por tanto, todos los vehículos que alcancen el primer semáforo dentro del ancho

de banda verde pueden atravesar la avenida sin detenerse a una velocidad prefijada para

cada tramo, lo que provoca que el tráfico sea más fluido por no producirse

aglomeraciones de vehículos en las señales luminosas de tráfico.

5.2.2 Prueba realizada en la avenida Alfonso XII

Al igual que en el ejemplo anterior se comenzará por mostrar las señales que

rigen la avenida en cuestión, que en este caso serán cuatro. La distribución de las fases y

los intermedios es al azar, ya que como ocurría en la avenida anterior se desconoce el

orden de los mismos dentro del ciclo de funcionamiento.

Así pues, las señales a coordinar quedan del siguiente modo:

Figura 5.2-5 Señales que rigen la avenida Alfonso XII

129

Pruebas del sistema

Conocidas las señales se muestran los datos de velocidades y distancia que se

van a aplicar a la avenida a coordinar:

Tramos 1-2 2-3 3-4

Distancia (m) 220 210 312

Velocidad máxima outbound (m/s) 12.5 9.72 9.72

Velocidad máxima inbound (m/s) 12.5 9.72 9.72

Velocidad mínima outbound (m/s) 11.11 8.33 8.33

Velocidad mínima inbound (m/s) 11.11 8.33 8.33

Cambio velocidad máxima outbound (s/m) 0.03 0

Cambio velocidad máxima inbound (s/m) 0.03 0

Cambio velocidad mínima outbound (s/m) 0.023 0

Cambio velocidad mínima inbound (s/m) 0.023 0

Tabla 5.2-4 Límites de velocidad y distancia

El valor que se usa de la constante de proporcionalidad entre el ancho de banda

de entrada y salida es el de k = 1.

Con todos los datos disponibles se creará a través de nuestra aplicación el

programa lineal cuya solución permite coordina las señales de la avenida en cuestión. El

modelo propuesto por la aplicación es el siguiente:

130

Pruebas del sistema

Figura 5.2-6 Modelo lineal de coordinación de la avenida Alfonso XII

131

Pruebas del sistema

La resolución de este modelo genera unos resultados que se aprecian en la

siguiente tabla:

B1 B2 Z W11 W21 T11 M1 T21 W12 W22

0.2396 0.2396 0.0105 0.1772 0.1804 0.2090 1.0000 0.2090 0.0000 0.0000

T12 M2 T22 W13 W23 T13 M3 T23 W14 W24

0.2660 0.0000 0.2660 0.1271 0.1271 0.3951 1.0000 0.3951 0.0000 0.0000

Tabla 5.2-5 Solución del problema lineal de coordinación de la avenida Alfonso XII

Mediante la manipulación de estos resultados y la utilización de la fórmula que

proporciona el desfase que debe de haber entre una señal y otra para que el ancho de

banda de salida y entrada sea el obtenido, se obtienen los siguientes valores de interés:

Ciclo señales Ancho

banda

salida

Ancho

banda

entrada

Desfase

señales 1-2

Desfase

señales 1-3

Desfase

señales 1-4

94.7867 22.7099 22.7099 19.5033 39.3118 59.1203

Tabla 5.2-6 Datos de interés para la coordinación de esta avenida

Ya se puede mostrar el resultado gráfico que se genera como consecuencia de la

aplicación de los desfases a las señales luminosas de tráfico que regulan la avenida que

se ha coordinado:

132

Pruebas del sistema

Figura 5.2-7 Resultado gráfico de la coordinación de la avenida Alfonso XII en la

dirección outbound

Se comprueba que para este caso un vehículo no es capaz de atravesar la avenida

en un solo ciclo de las señales, si no que cuando llega a la cuarta señal ya se encuentra

en el segundo ciclo de la misma. Sin embargo, atraviesa la avenida sin detenerse ya que

alcanza la cuarta señal en el tiempo en verde de su segundo ciclo.

133

Conclusiones y extensiones

6 Conclusiones y extensiones

Es este capítulo se realiza un resumen del trabajo realizado en el proyecto,

comentando las principales conclusiones a las que se ha llegado y proponiendo posibles

extensiones al trabajo realizado.

6.1 Conclusiones

El objetivo del trabajo consistía en desarrollar una aplicación capaz de coordinar

las señales semafóricas que rigen la circulación de vehículos en una avenida.

Se ha podido comprobar que la coordinación de señales haciendo uso del

modelo de coordinación de maximización del ancho de banda verde, depende mucho de

los límites impuestos en las variables. De esta forma, para limitar el valor del tiempo de

ciclo se ha usado para el límite inferior el valor del ciclo de la señal con dicho valor más

bajo, y para el superior el resultado de la suma del valor del ciclo de la señal con dicho

valor más alto y el tiempo que tarda un vehículo en atravesar la avenida. Hay que

comentar que para calcular el tiempo que tarda un vehículo en atravesar la avenida se

han usado los límites inferiores de velocidad para cada tramo.

En principio se pueden coordinar el número de señales que el usuario desee, sin

embargo, cuanto mayor es ese número, mayor es la complejidad del problema y más

difícil resulta encontrar una solución óptima al mismo. Por lo tanto, se puede decir que

más de cuatro señales resulta casi imposible coordinarlas.

Una limitación que presenta el modelo es la imposibilidad de coordinar en

ambas direcciones una avenida irregular, es decir, una en la cual las distancias entre los

dispositivos reguladores de tráfico son distintas para cada dirección de la avenida.

En el caso de que las señales a coordinar presenten distinto ciclo, cabe comentar,

que para aquellas cuyo ciclo es inferior al proporcionado en la solución como óptimo, se

repite su ciclo hasta alcanzar el valor de dicho ciclo. Mientras que para aquellas señales

cuyo ciclo es superior al óptimo, se le reduce un tanto por ciento equitativo entre sus

distintas fases.

134


La principal novedad que presenta el modelo usado para la coordinación, es la

posibilidad que éste ofrece de dar mayor prioridad a un sentido de circulación sobre el

otro. Es decir, al coordinar dicho modelo en ambas direcciones de la avenida se puede

elegir que dirección permitirá el paso de un número mayor de vehículos sin detenerse

ante ninguna señal reguladora de tráfico. Esta particularidad, se consigue mediante el

valor que se le asigna al parámetro K, de forma, que si éste es mayor que uno los

vehículos que circulan en la dirección marcada como inbound dispondrán de mayor

tiempo para cruzar la avenida sin detenerse, mientras que si es menor que uno serán

aquellos que circulan en la dirección marcada como outbound los que dispongan de más

tiempo.

En el capítulo 1 se realizó una breve introducción sobre la coordinación de

señales semafóricas y los sistemas inteligentes de transporte. Además, se habló de los

objetivos del proyecto y se describió tanto el viario como las cajas semafóricas.

En el capitulo 2 se explicaron tres de los modelos de maximización de ancho de

banda verde más importantes en la actualidad, donde uno de ellos ha sido el usado para

desarrollar la aplicación.

El capítulo 3 comprende el modelado orientado a objetos de los algoritmos

diseñados e implementados. En concreto, se han incluido y documentado los diagramas

pertenecientes a UML (Unified Modelling Language) que sirven para la especificación

de dichos procesos.

El capítulo 4 incluye la descripción de los aspectos más importantes de la

aplicación mediante el uso de diagramas de flujo, así como una descripción de los

interfaces diseñados para la misma.

El capítulo 5 muestra las pruebas realizadas sobre el programa diseñado con el

fin de mostrar su correcto funcionamiento.

Se ha desarrollado una interfaz gráfica que permite al usuario seleccionar de

forma clara y sencilla una avenida de un escenario real y coordinar las señales

135


semafóricas que rigen a la misma. Además permite al usuario la gestión de la asociación

de cajas semafóricas a nodos del escenario.

6.2 Posibles extensiones

Entre las posibles extensiones, cabe destacar la que tiene en cuenta, para la

coordinación de las señales, los flujos de tráfico procedentes de las calles

perpendiculares a la avenida a coordinar. Para tener en cuenta estos flujos, se puede

desarrollar otro modelo de coordinación visto en el capítulo 3, modelo multi-banda, en

el que los anchos de banda de los distintos tramos de la avenida tienen un tamaño

distinto.

También se puede considerar el hecho de darle la posibilidad al usuario de elegir

entre varios métodos de coordinación, con el fin de que el usuario pueda seleccionar la

complejidad del problema, lo que supone obtener una solución más o menos factible a

la realidad del tráfico actual.

Por último, otra de las posibles extensiones es la de dar al usuario la posibilidad

de elegir como se calculará el tiempo que tarda un vehículo en atravesar la avenida.

Como se explicó anteriormente, esto se usaba para calcular el límite superior del tiempo

de ciclo que tendrán las señales coordinadas. En nuestra aplicación se usa el límite

inferior de la velocidad que puede desarrollar el vehículo en cada tramo para atravesar

la avenida sin detenerse, que es la opción más conservadora de entre las posibles, sin

embargo, en la extensión se podría permitir elegir entre usar el límite inferior, el límite

superior, o bien la media entre ambos límites. Con esto se conseguiría ajustar en mayor

o menor medida el tamaño que ha de tener el ciclo de las señales para obtener un ancho

de banda verde máximo.

136

Bibliografía

7 BIBLIOGRAFÍA

James Rumbaugh, Ivar Jacobson, Grady Booch. El lenguaje unificado de

modelado, manual de referencia. Addison Wesley.

Grady Booch, James Rumbaugh, Ivar Jacobson. El lenguaje unificado de

modelado. Addison Wesley.

Francisco Charte. Programación en Builder C++. Editorial Anaya.

Nathan H. Gartnert, Susan F. Assmannt, Fernando Lasaga, and Dennis L. Hout.

A multi-band approach to arterial traffic signa optimisation. Department of Civl

Engineering and Department of Mathematics, University of Lowell, Lowell, MA

01854, U.S.A.

Chang E.C.P. (1988) Program for optimizing left turn phase sequence in multi-

arterial closed networks. Transpn. Res. Rec., 1181, 61-67.

Chang E.C.P., Messer C.J. and Cohen S.L. (1986) Directional weighting for

maximal bandwidth arterial signal optimization programd. Transpn. Res. Rec.,

1057, 10-19.

Cohen S.L. (1983) Concurrent use of MAXBAND and TRANSYT signal timing

programs for arterial signal optimization. Transpn. Res. Rec., 906, 81-84.

Cohen S.L. and Liu C.C. (1986) The bandwidth-constrained TRANSYT signal-

optimization program. Transpn. Res. Rec., 1057, 1-7.

Federal Highway Administration (FHWA) (1980) Traffic Network Analysis with

NETSIM. Implementation Package FHWA-IP-80-3, U.S. Dept. of Transportation,

Washington, D.C.

137

Bibliografía

Gartner N.H., Assman S.F., Lasaga F., and Hou D. (1989) Multiband Arterial

Progression: A New Desing Scheme for Arterial Traffic Signal Control. Report

prepared for Massachusetts Department of Public Works. Research Foundation,

University of Lowell, Lowell, MA, January 1989.

Hisai M. (1987) Delay-minimizing control and bandwidth-maximizing control of

coordinated traffic signals by dynamic programming. In Transportation and Traffic

Theory ( Edited by N.H. Gartner and N.H.M. Wilson). Elsevier, NY.

Jhon D. C. Little. The synchronization of traffic signals by mixed-integer linear

programming. Massachusetts Institute of Technology, Cambridge, Massachusetts.

138

universidad de sevillabibing.us.es/proyectos/abreproy/10978/fichero/proyecto.pdfagradecimientos...

Documents