Eduardo Marín

Así, con este tipo de trazado, muy utilizado para diferentes operaciones heurísticas (“manhattan distance”), podremos obtener de los vehículos un comportamiento más irregular, aleatorio, variable y caótico. Más real, a fin de cuentas. 

Como describimos en un punto anterior, podemos realizar nuestras propias descripciones de caminos y vías de forma manual, mediante la definición de nodos, bordes y carriles. Para un escenario simple como en el que hemos llevado a cabo las simulaciones anteriores, dicha descripción es sencilla y rápida. Sin embargo, para el nuevo escenario que proponemos, el número de nodos aumenta, así como los bordes y carriles asociados, lo que conlleva un trabajo meticuloso y arduo. Para evitar la definición manual y ahorrar tiempo, podemos utilizar una serie de herramientas que automatizan este proceso.

Creación automática del archivo de red – MOVE

Así, una de las herramientas que permiten generar automáticamente el archivo que define el mapa de carreteras (*.net.xml), es la aplicación MOVE (MObility model generator for VEhicular networks). Podemos descargarla desde la página oficial (http://lens1.csie.ncku.edu.tw/wiki/doku.php?id=%E2%80%A7realistic_mobility_generator_for_vehicular_networks).

En nuestro caso, como habíamos comentado, crearemos un escenario basado en “rejilla manhattan”, en concreto definida por seis calles horizontales y seis calles verticales, con una separación entre ellas de cuatrocientos metros:

Para ello, situándonos en el directorio donde hemos descargado MOVE.jar, ejecutaremos MOVE de la siguiente forma:

java -jar MOVE.jar

Nos encontraremos entonces con la siguiente ventana:

Tras seleccionar “Mobility Model”, nos encontraremos con las siguientes opciones:

Tras seleccionar “Random Map” la aplicación nos presenta la opción de definir una serie de parámetros antes de generar el mapa aleatorio. Así, en nuestro caso, seleccionamos el método de generación basado en rejilla (“grid layout”), estableciendo el número de intersecciones vertical y horizontal igual a seis y una separación entre ellas de cuatrocientos metros. Establecemos el nombre de salida de nuestro archivo de red (“manhattan.net.xml”) y confirmamos.

El resultado es un archivo xml que contiene la descripción de dicha red, y que más tarde SUMO podrá interpretar adecuadamente:

 

Creación automática del archivo de rutas – JTRROUTER

Una vez disponemos del archivo de red con la rejilla manhattan, necesitamos generar el comportamiento de cada uno de los vehículos. De la misma forma que con la definición del mapa, o archivo de red de carreteras, podríamos ir carril por carril, intersección por intersección, para cada uno de los vehículos que vayamos a inyectar en nuestro escenario, realizar la descripción de rutas únicas que permitan concluir en una simulación más o menos aleatoria. Sin embargo, si la definicion manual del mapa era tediosa, la definición de rutas de esta forma lo es mucho más.

Por suerte, de la misma manera que existe una herramienta para generar de forma automática la descripción del archivo de red, existe otra aplicación que facilita y automatiza la generación del archivo de rutas. Se trata de JTRROUTER (http://sourceforge.net/apps/mediawiki/sumo/index.php?title=JTRROUTER), una aplicación que, mediante la entrada de diferentes archivos, genera el archivo de rutas que necesitamos.

En concreto, esta aplicación puede tomar como entrada el archivo de red (*.net.xml) que hemos generado anteriormente; un archivo de flujos, que establezca el número de flujos diferentes que podemos tener; un archivo de “giros”, que define las probabilidades de que un determinado vehículo tome una u otra trayectoria en una intersección; o un archivo de configuración global que jtrrouter interpreta y aplica en consecuencia.

Para nuestro caso, basta con el archivo de red (“manhattan.net.xml”), el archivo de flujos (“mahattan.flows.xml”) y el archivo de configuración (“manhattan.jtr.cfg”) que detallamos a continuación:

<configuration>
<input
net-file="manhattan.net.xml"
flow-definition="manhattan.flows.xml"
/>
<output
output-file="manhattan.rou.xml"
/>
<processing
continue-on-unbuild="true"
turn-defaults="25,25,25,25"
sinks="4/0to5/0"
/>
</configuration>

Mediante este archivo de configuración, indicamos a jtrrouter que deseamos generar un archivo de rutas para un mapa que se encuentra definido en “manhattan.net.xml” y que, mediante el archivo de flujos “manhattan.flows.xml”, cuyo contenido es el siguiente,

<flowdefs>
<flow id="flow0" from="0/5to0/4" begin="0" end="100" no="25" />
</flowdefs>

tenemos la intención de que las rutas que se generen partan desde el edge “0/5to0/4” y se aplique a un total de 25 vehículos, que serán generados entre el intervalo de tiempo 0 a 100 segundos.

Pero además, y lo que es más importante, y que es lo que otorga a nuestro escenario el carácter aleatorio y caótico, se encuentra en las últimas líneas. En concreto, “turn-defaults”, que indica la probabilidad de que un vehículo gire a la izquierda, a la derecha, al frente, o hacia atrás, y que establecemos en un valor de 25% (el valor “sinks” define el punto final en el que muere un vehículo).

Finalmente, ejecutaremos, en línea de comandos:

jtrrouter -c manhattan.jtr.cfg -t manhattan.turns.xml

El resultado es un archivo (“manhattan.rou.xml”) que podremos inyectar a SUMO, junto con el archivo de red (“manhattan.net.xml”) para generar la simulación en la rejilla manhattan.

Como se dijo en el punto anterior, entre los valores a estudiar, se encuentra el número de vehículos ciegos (“blind vehicles”), esto es, el número de vehículos que no consiguen recibir un mensaje de alerta concreto en el tiempo de vida de este último.

Conocer este parámetro nos permite deducir si el algoritmo de reenvío es demasiado agresivo, lo que implica realizar pocos intentos de “rebroadcast” y bajas probabilidades de alcanzar vehículos cercanos al área de cobertura; o demasiado suave, donde el control sobre los reenvíos es menor y el problema de “broadcast storming” aumenta.

Así pues, necesitamos conocer, por cada mensaje que se genere, llevar el control de las veces que un vehículo lo recibe. Para ello, el observador debe ser avisado cada vez que un vehículo recibe un mensaje. El observador entonces anotará en el vector de valores tal suceso, relacionando la recepción de ese mensaje y el número de vehículos que lo han recibido hasta entonces. Al final, obtendremos, por cada mensaje, el total de vehículos que recibieron cada uno de ellos, y podremos promediar entre el total de mensajes.

Esquemáticamente, podemos hacernos una idea del proceso descrito:

Así, como estructura de datos para llevar dicho control, únicamente utilizaremos una tercera fila en nuestro array bidimensional para contabilizar el número de vehículos que han leído un mensaje con uid determinado, como puede verse a continuación.

A continuación podemos ver el muestreo realizado, manteniendo las condiciones de simulación anteriores (vía cuadrangular de 2500 x 2500 metros), en la que variamos, en cada simulación, el número de vehículos en circulación:

Total vehículos / Media Vehículos reciben mensaje / % Vehículos ciegos

20 / 4,76 / 76,2

40 / 4,6 / 88,5

60 / 4,928 / 91,78

80 / 5,3 / 93,37

100 / 48,5 / 51,5

120 / 76,87 / 35,94

140 / 92,26 / 34,1

160 / 129,36 / 19,15

180 / 138,16 / 23,24

200 / 156,7 / 21,65

220 166,23 24,44

240 174,2 27,41

260 180,63 30,52

Si observamos el gráfico, vemos como para una baja densidad de vehículos, el número de “blind vehicles” es bastante alto, llegando a cotas cercanas al 95% para 80 vehículos. La razón es que el bajo número de vehículos en proporción a las distancias entre ellos facilita la existencia de zonas en sombra, donde los mensajes no alcanzan a los vecinos más próximos, que se ven incapaces de reenviar hacia los más alejados del punto de alerta. En cambio, mientras aumenta el número de vehículos en el escenario, esas zonas en sombra pueden rellenarse, permitiendo mayores cotas de alcance, próximas al 15 % para 160 vehículos. Sin embargo, es interesante observar cómo, a partir de un cierto número de vehículos en escena, el algoritmo de reenvío pierde fuerza y reaparece el “broadcast storm problem”, donde las colisiones impiden que los mensajes alcancen finalmente su objetivo.

Resumiendo, el número de vehículos ciegos depende fuertemente de la densidad de tráfico existente en nuestro escenario, disminuyendo cuando ésta aumenta, hasta alcanzar un límite de saturación determinado (broadcast storm problem).

Para obtener estos resultados, únicamente hemos modificado la clase “observador”, añadiendo un nuevo vector de estadísticas (podríamos haber utilizado sin problemas un escalar), añadiendo otro método para obtener la media de estos vehículos ciegos, y modificando el método para guardar las estadísticas:

double Observador::haz_media_valores(){

int i;

double aux, aux1;

aux = 0;

for(i=0; i< i_valores_asociados; i++){

aux = aux + valores_asociados[0][i];

}

aux1 = (aux / i_valores_asociados);

return aux1;

}

double Observador::haz_media_bind_vehicles(){

int i;

double aux, aux1;

aux = 0;

for(i=0; i< i_valores_asociados; i++){

aux = aux + valores_asociados[2][i];

}

aux1 = (aux / i_valores_asociados);

return aux1;

}

void Observador::grabar_estadistica(double valor, double valor1)

{

st_valor.record(valor);

st_valor_02.record(valor1);

}

void Observador::finish()

{

this->grabar_estadistica(this->haz_media_valores(),this->haz_media_bind_vehicles());

}