Entorno de simulación de tráfico aéreo experimental basado ... · El simulador ha sido implementado como un sistema Multiagente con el fin de considerar los futuros escenarios

29

introDucción

Los futuros sistema de Comunicación,Navegación, Vigilancia y Gestión delTráfico Aéreo (CNS/ATM), permitiránque los datos de navegación de cual-quier aeronave (posición, velocidad,rumbo, plan de vuelo, etc.) que se en-cuentren en una determinada regióndel espacio aéreo puedan ser envia-dos desde sus sistemas de navega-ción a bordo al control de tránsi toaéreo o a otras aeronaves circun dan - tes (Morales, 2001). Esta facilidadpara compartir datos, unido a la flexi -bilidad de rutas basadas en la navega -ción por satélite, sugiere la necesi dadde elaborar nuevos procedimientostanto para la navegación aérea comopara la gestión del tránsito aéreo.

En este contexto, la RTCA (RadioTechnical Commission for Aeronau-tics) ha introducido el concepto free-

flight. Este concepto se define como“…una operación de vuelo segura yeficiente que opera bajo las reglas devuelo instrumental (IFR) en la que losoperadores tienen libertad para se-leccionar sus sendas y velocidadesen tiempo real. Las restricciones detráfico aéreo están sólo impuestas pa -ra asegurar la separación, para im-pedir exceder la capacidad del aero-puerto, para prevenir vuelos no auto -rizados en determinadas regiones opara mantener la seguridad del vue -lo” (Rtca, 1997; Nasa, 1999).

La implementación de nuevos pro-cedimientos operacionales para en-

Entorno DE siMulación DE tráfico aérEo ExPEri-MEntal BasaDo En sistEMas MultiaGEntE

En este artículo se presenta una implementación de un simulador de trá-fico aéreo experimental que modela el comportamiento de diferentes tiposde aeronaves mientras ejecutan un plan de vuelo o siguen las órdenesprocedentes de un controlador de tráfico aéreo (atc). El simulador hasido implementado como un sistema Multiagente con el fin de considerarlos futuros escenarios de tráfico aéreo donde las aeronaves compartensus datos de navegación con el atc y con otras aeronaves. Por tanto,este simulador no solo proporciona datos sintéticos del trafico aéreo quepermitan diseñar y evaluar algoritmos específicos para la gestión del trá-fico aéreo (detección y resolución de conflictos, secuenciación de aero-naves durante el descenso y aproximación al aeropuerto, etc.), si no quetambién admite futuras ampliaciones para incorporar procedimientos denegociación aire-tierra y aire-aire así como nuevos interfaces hombre-má-quina para llevarlos a cabo.

In this paper we present a model to implement an experimental air traffic simu-

lator which accounts the aerodynamic behaviour of different aircraft types while

executing a flight plan or orders from an Air Traffic Controller (ATC). The simu-

lator has been implemented as a Multi-Agent System in order to consider future

scenarios of air traffic where the aircrafts can share their own navigation data

with the ATC and with other aircraft. Thus this simulator not only provides aircraft

synthetic data to evaluate algorithms for the management of the air traffic (de-

tection and resolution of conflicts, sequence of aircraft during the descent and

approach to the airport, etc.), but also it allows further extensions to evalua te air-

ground and air-air negotiation procedures and as well as new man-machine in-

terfaces.

José Miguel canino rodríguezsalvador Durá Bernalluis Gómez Déniz

l o s a r t í c u l o s a r t í c u l o s a r t í c u l o s a r t í c u l o s a r t í c u l o s a r t í c u l o s a r t í c u l o s

tornos free-flight no sólo requiere elsoporte tecnológico de los sistemasCNS/ATM si no que, además, es pre-ciso desarrollar nuevos procedimien-tos y subsistemas complementariosdestinados a la navegación aérea yal control del tráfico aéreo. Dichossubsistemas deberán procesar losdatos procedentes de las aeronavescon el fin de detectar y resolver posi-bles conflictos entre éstas, así comopresentar toda esta información deforma adecuada en dispositivos devisualización utilizados por la Tripu-lación (Cockpit Display Traffic Infor-mation o CDTI) o por los Contro lado-res de Tráfico Aéreo.

Para llevar a cabo el diseño y eva-luación preliminar de estos nuevosprocedimientos y sistemas es precisodisponer de plataformas virtuales quesimulen el tráfico aéreo en un en-torno free-flight, (simuladores de trá-fico aéreo experimentales). La simu -lación de tráfico aéreo se ha consoli-dado no sólo como uno de los meca-nismos más eficaces en el análisis delos sistemas CNS/ATM sino como unaherramienta que proporciona datossintéticos sobre los cuales validar fu-turos conceptos operacionales (Yü-cesan et ál., 2002; Prevot et ál., 2003).

En este artículo se presenta unapropuesta para la implementación deun simulador de tráfico aéreo experi-mental que modela un escenario demúltiples aeronaves como entidadescapaces de intercambiar datos con elControl de Tránsito Aéreo (ATC). Eldiseño realizado permite además unaposterior ampliación del mismo paraque las aeronaves puedan intercam-biar entre sí sus datos de navegacióny establecer protocolos de negocia-ción para la navegación autónoma endeterminadas fases del vuelo.

El escenario descrito ha sugeridola conveniencia de implementar di-cho simulador en base a la tecnolo-gía software de Sistemas Multia gen-te (SMA). La programación de SMA esun nuevo paradigma de la programa-ción en el que el bloque fundamental

de construcción es el agente (Wool-dridge, 2002; Pérez et ál., 2004). Apesar de que no existe una definiciónúnica de agente, éste se puede en-tender como un proceso computa-cional que desarrolla unas determi-nadas tareas. Dichas tareas se orde-nan y estructuran adecuadamentedando lugar a los diversos comporta-mientos del agente, los cuales ade-más incluyen procesos de comunica-ción entre éstos mediante el envío yrecepción de mensajes debidamenteestandarizados. La actuación coordi-nada de un conjunto de agentes pue -de contribuir a la resolución de pro -blemas de sistemas abiertos (en losque la estructura del sistema cambiadinámicamente) y distribuidos (en losque cada agente intenta alcanzar susobjetivos haciéndolos compatiblescon los objetivos de los demás).

arQuitEctura DEl siMulaDorDE tráfico ExPEriMEntal

Un simulador de tráfico aéreo con-vencional está constituido por tresbloques principales (Figura 1): un pri-mer bloque que contiene el núcleodel simulador, es decir, el modelo quegenera un número determinado deaeronaves y desde donde se puedencontrolar diversos parámetros típicosde la simulación (cantidad de aero-naves, tipo, posiciones iniciales, me-teorología, rutas disponibles, etc.).Un segundo bloque (puesto de con-trolador aéreo) está constituido porun interfaz gráfico donde se repre-sentan los datos radar de cada unade las aeronaves. Es decir, es unarepresentación gráfica 2D del tráficoa la que se pueden añadir otros da-tos como la velocidad, rumbo y alti-tud de cada aeronave. El tercer blo-que (puesto/s de pseudopiloto/s) estáconstituido por el interfaz gráfico y decontrol desde donde se pueden mo-dificar los parámetros de vuelo (alti-tud, rumbo y velocidad) de cada unade las aeronaves. Cada pseudopilotocontrola un determinado número deaviones mediante la introducción decomandos en respuesta a instruccio-nes verbales de los controladores de

a r t í c u l o s a r t í c u l o s a r t í c u l o s a r t í c u l o s a r t í c u l o s a r t í c u

30

La simu lación de trá-

fico aéreo se ha conso-

lidado no sólo como

uno de los mecanismos

más eficaces en el aná-

lisis de los sistemas

CNS/ATM sino como

una herramienta que

proporciona datos sin-

téticos sobre los cuales

validar futuros concep-

tos operacionales

Control de la

simulación

Modelo aeronaves

(Tráfico aéreo)

Modelo aeronaves

(Pseudopilotos)

Pantalla radar

(Control de

tráfico aéreo)

tráfico aéreo del mismo modo que ha - ría un piloto cuando controla su avión.

Los simuladores de tráfico aéreoexperimentales que pretenden simu-lar entornos de tráfico aéreo free-flight

mantienen esta arquitectura pero de -ben incorporar nuevas funciones ta -les como la posibilidad de establecercomunicaciones y negociaciones aire-tierra y aire-aire, exclusivamente enbase al intercambio de datos median -te mensajes electrónicos. Además,cada aeronave debe proporcionar in-formación no sólo de su estado actual(posición, rumbo y velocidad), si notambién de sus intenciones (plan devuelo previsto, estimación de trayec-torias, etc.).

El desarrollo de un simulador conlas características descritas en el pá-rrafo anterior hace aconsejable eluso de SMA, porque ésta tecnologíafacilita la implementación de diferen-tes agentes capaces de interactuar ynegociar entre sí para lograr sus res-pectivos objetivos.

Para implementar SMA existen nu-merosas plataformas de desarrollode agentes. Una descripción deta-llada de las características de cadauna de ellas se puede encontrar en(Pérez et ál., 2004). En nuestro casose ha optado por utilizar la plataformade desarrollos de agentes JADE (Ja-va Agent DEvelopment Framework)(Telecom, 2000). Dicha plataforma

está constituida por un conjunto de li-brerías programadas en Java paracrear agentes. Los agentes llevan acabo varias tareas concurrentes enrespuesta a diferentes eventos ex-ternos. Estos agentes pueden comu-nicarse entre sí mediante un lenguajede comunicación de agentes (ACL)estandarizado por FIPA (Foundationfor Intelligent Physical Agents) (Fipa,2002). El lenguaje FIPA-ACL se basaen la teoría de los actos del habla(speech act theory) que asigna unaintención a cada acto comunicativo.

El funcionamiento y relación queexiste entre los agentes que consti-tuyen nuestro simulador está repre-sentado en el esquema de la Figura2. En ella, los agentes se muestrancomo cajas amarillas y los mensajesentre agentes como flechas rojas.Las flechas azules representan losagentes lanzados por el agente en-cargado de proporcionarles los pará-metros de la configuración inicial dela simulación (Agente Configuración).Las flechas negras indican las partesde la interfaz gráfica u objetos quepertenecen a cada agente.

Como se puede apreciar en el grá-fico anterior, la aplicación está cons-tituida por los agentes físicos siguien-tes:

• Los Agentes Aeronaves, que si-mulan el comportamiento de vue -lo de aeronaves reales, pudiendoejecutar tanto planes de vuelos


31

Datos Datos

Voz

Figura 1. Esquema de un simulador de tráfico aéreo convencional

La aplicación está cons-

tituida por los agentes

físicos Aeronave, ATC,

Meteorología y Terreno

Figura 2. Esquema general de la aplicación

como órdenes puntuales para lamodificación de la altitud, el rum -bo y/o la velocidad. Estas órde-nes puntales se pueden introdu-cir desde una ventana de controlespecífica para cada aeronave.

• El Agente ATC, que dispone de lainformación sobre la posición yplanes de vuelo de las aeronavesy puede enviar diversos tipos demensajes a las aeronaves. ElAgente ATC dispone de una pan-

talla de visualización gráfica pararepresentar la evolución temporalde las distintas aeronaves (Ven-tana Radar ATC) y de una ven-tana de control a partir de la cualel usuario (controlador ATC) pue -de generar cualquier instrucciónATC dirigida a una aeronave enparticular. Estas instrucciones sonejecutadas por los agentes aero-naves bien de forma automáticaal recibirse el mensaje ATC o bien


32

Ventana control aeronave 1

Ventana control aeronave i Ventana control aeronave n

Ventana vista pseudopiloto

agente configuración

Agente Meteorología

Agente Terreno

• Datos Meteorología

• Datos Terreno

• Datos Aeronave

• Instruccioneso plan de vuelo

• Aviso de conflicto

• Datos Aeronave• Mostrar punto,

plan de vuelo oruta en ventanaradar

• Mostrar ventanacontrol

• Posición click delratón

Los Agentes Aerona-

ves simulan el com-

portamiento de vuelo

de aeronaves reales,

pudiendo ejecutar

tanto planes de vuelos

como órdenes puntua-

les para la modifica-

ción de la altitud, el

rumbo y/o la velocidad

Agente Aeronave

12…i

…n-1n

Agente Pseudopiloto

Agente ATC

Ventana vista ATC

Ventana control ATC

manualmente. En este último ca -so, los mensajes enviados por elATC al Agente Aeronave única-men te se muestran en una pan-talla destinada a tal fin en el Agen-te Aeronave, pero deberá ser elusuario que haga la función depiloto (pseudopiloto) el que intro-duzca los datos del mensaje enla ventana de control de la propiaaeronave para que ésta ejecutelas instrucciones.

• El Agente Meteorología propor-ciona información sobre las con-diciones atmosféricas y de vientoen la región del espacio aéreo es -cogida. Esta información es re-querida por el Agente Aeronavepara calcular en cada instante suestado (posición, velocidad, rum -bo y masa).

• El Agente Terreno dispone de in-formación sobre el conjunto derutas disponibles, una de las cua-les se constituirá en el plan devuelo inicial que deberá seguir laaeronave. Los datos del AgenteTerreno también serán utilizadospor el Agente ATC para represen-tar gráficamente y en formato depantalla radar dichas rutas.

• Además de éstos agentes “físi-cos” se han implementado otrosdos agentes denominados Agen-te Configuración y Agente Pseu-dopiloto. El Agente Configuracióntiene la finalidad de definir y con-trolar los parámetros de la simu-lación. El Agente Pseudopiloto esfundamentalmente un agente in-terfaz-gráfico, a través del cual unúnico usuario pseudopiloto pue-da acceder a una vista 2D del trá-fico que rodea a cada una de lasaeronaves. Para acceder a unaaeronave en particular, es sufi-ciente con pulsar con el ratón so -bre el símbolo que la representaen la ventana gráfica (ventanaradar Pseudopiloto). Una vez se-leccionada la aeronave, esta ocu-pará la posición central de la ven-tana radar pseudopiloto y el mo-vimiento de las demás aeronavesse mostrará en relación a ésta.A la vez se abrirá la ventana de

con trol de la aeronave seleccio-nada. A efectos prácticos el Agen-te Pseudopiloto representa la in-terfaz gráfica CDTI que deberáutilizar la tripulación para conocerel estado del tráfico circundantey sus intenciones. Este interfaz seha implementado como un agen-te aparte (y no como un compo-nente más del Agente Aeronave)para centralizar en un único inter -faz el acceso a todas y cada unade las aeronaves y a la vez dis-poner de un agente específico so-bre el cual realizar futuras pro-puestas orientadas a un mejor di-seño de los dispositivos CDTI pa-ra vuelos free-flight.

aGEntEs aEronaVE: coMPor-taMiEnto Y coMunicacionEs

El estado de cada aeronave se pue -de definir como un vector (vector deestado) con seis componentes queproporcionan la siguiente información:la posición instantánea (coordenadasx, y, z representadas por las varia-bles x1, x2 y x3 del vector de estado),la velocidad respecto al aire x4, el rum-bo x5 y la masa actual x6. Es decir, elvector de estado en cada instanteviene dado por: x(t)=(x1(t), x2(t), x3(t),

x4(t), x5(t), x6(t)).

Para calcular el vector de estado,la aeronave ha sido modelada comoun sistema dinámico descrito por lasecuaciones diferenciales siguientes:

Estas ecuaciones se obtienen co -mo consecuencia de considerar la

33


x

x x u w

x x u w

x

=

++

4 5 3 1

4 5 3 2

4

cos( )cos( )

sin( )cos( )

ssin( )

sin( )

u w

C S x

xg u

xu

C S x

D

L

3 3

4

2

6

3

6

12

1

2

+

− − +ρ

ρ44

6

2

1

xu

u

sin( )

−

η

A efectos prácticos el

agente pseudopiloto re-

presenta la interfaz grá-

fica CDTI que deberá

utilizar la tripulación

para conocer el estado

del tráfico circundante

y sus intenciones

aeronave como una masa puntualsujeta a las leyes de la aerodinámicay representan la variación temporaldel vector de estado. Por tanto el vector de estado, x(t), se obtiene en ca -da instante integrando en el tiempoel sistema de ecuaciones (1).

En dicho sistema u1, u2 y u3 re-presentan la potencia, el ángulo dealabeo y el ángulo de senda respec-tivamente. Asimismo w1, w2, w3 sonlas componentes del vector viento. Elresto de coeficientes que aparecenen la expresión anterior son coeficien -tes aerodinámicos y parámetros carac -terísticos de cada modelo de aero-nave en particular. Dichos coeficien-tes y parámetros están disponiblesen la Base de Datos de Aero naves(BADA) de EUROCONTROL (Eurocon-trol, 2004). BADA está constituida porun conjunto de ficheros ASCII que pro-porcionan información de los pará-metros aerodinámicos y velocidades

operativas estándar de unas 295 ae-ronaves civiles.

El sistema dinámico expresado através de las ecuaciones (1) se pue -

de representar como un sistema cons-tituido por dos bloques principales(Fi gura 3). Un primer bloque denomi-nado Dinámica de Aeronave que mo-dela el comportamiento aerodinámi-co, es decir, el que implementa e in-tegra las ecuaciones (1) y un segun-do bloque, denominado FMS (FlightManagement System), que calculalas entradas de control u1, u2 y u3para que el desplazamiento de la ae-ronave se ajuste a las condicionesimpuestas por el plan de vuelo o porlas instrucciones ATC.

El cálculo de las entradas u1, u2 yu3 depende fundamentalmente delmodo de vuelo. El modo de vuelohace referencia al estado discreto enel que se encuentra la aeronave. Esdecir, indica si ésta se encuentra enascenso, descenso o a nivel de vuelo(Climb Mode) o bien si está acele-rando, desacelerando o a velocidadconstante (Acceleration Mode), etc.

De acuerdo con el trabajo pro-puesto por (Glover et ál., 2004) sehan definido hasta ocho estados dis-cretos distintos. El valor de cada unode los estados discretos se obtiene


34

Viento

Consola de control

Plan de vuelo / Vector de vuelo

InstruccionesATC

w

Vector de control u(t)

Vector de estado u(t)

Figura 3. Diagrama de bloques del modelo de aeronave

FMS

Dinámicade la

Aeronave

Calculavector decontrol

Calculaestados discretos

s

mediante una máquina de estados fi-nitos cuyo valor se obtiene compa-rando el vector de estado actual conlos datos del plan de vuelo o con lasvelocidades que debería llevar la ae-ronave en cada fase del vuelo (velo-cidades operativas).

Así por ejemplo, para determinarel valor del modo Climb Mode (CM)se compara la altitud actual de la ae-ronave, x3, con la altitud correspon-diente al próximo punto del plan devuelo de la aeronave, z (Figura 4). Es-te modo puede tomar tres valoresdiscretos posibles: C para indicar quela aeronave debe ascender, D paraindicar descenso y L para indicar quese debe mantener la altitud.

En nuestro caso el modelo pro-puesto por (Glover et ál., 2004) hasido modificado con el fin de que losestados discretos allí propuestos nosólo vengan determinados por el plande vuelo y las velocidades operativasde la aeronave, sino también por las

instrucciones del ATC. De este modo,y continuando con el ejemplo anterior,la altitud de referencia, z, es la altitudque corresponde al punto del plan devuelo al que se dirige la aero nave, sal -vo que el agente ATC haya dado unainstrucción ordenando a la aerona veque alcance una altitud z diferente.

De manera similar se procederíapara determinar el valor de cada unode los ocho modos discretos.

Por último señalar que el AgenteAeronave, además de calcular su vector de estado en cada instante, lleva acabo otras tareas de navegación o decomunicación con los otros agentes.

Entre las tareas de navegacióndestaca el cálculo del punto inicial dedescenso (Top Of Descent o TOD) yla modificación de las altitudes míni-mas del plan de vuelo inicial para des-cender de forma continua desde sunivel de crucero hasta el aeropuertode destino.

35


Figura 4. Máquina de estados finitos para CM

CM = Dx3 ≥ z

CM = Cx3 ≤ z

CM = L|x3 – z| ≤ 1m

x3 ≤ zx3 ≥ z

x3 ≤ z + 1m x3 ≥ z + 1m

x3 ≤ z + 1m

x3 ≥ z – 1m

La comunicación bidireccional aire-tie rra entre los agentes aeronave y elagente ATC se realiza a través de lossiguientes mensajes:

a) Mensajes enviados por la aero-nave al ATC:• Mensaje para informar sobre

el vector de estado.• Mensaje para informar sobre la

modificación de las altitudesdel plan de vuelo después decalcular el TOD.

b) Mensajes recibidos en la aerona-ve procedentes del ATC:• Mensajes de instrucción.• Mensajes de detección de con-

flicto con otras aeronaves.

A partir de este núcleo de comuni-caciones aire-tierra se pueden imple-mentar nuevos tipos de mensajes enfuturas ampliaciones con el fin de es-tablecer negociaciones más comple-jas entre aeronave y ATC o entre ae-ronaves.

Además de las comunicaciones an-teriores, existen otras comunicacio-nes con el Agente Meteorología (paraobtener información atmosférica) y elAgente Terreno (para solicitar las ru -tas disponibles). También existe unacomunicación entre Agente Aeronavey Agente Pseudopiloto que equivaleal envío de información entre el agen-te físico aeronave a un agente inter-faz hombre-máquina que representaal CDTI.

aGEntE atc: coMPortaMiEn toY coMunicacionEs

El agente ATC se encarga de recibirinformación periódica de todas lasaeronaves y de representarla en laVentana de Radar de ATC. A partir dees tos datos, un algoritmo específicose encarga de detectar un conflictoca da vez que dos aeronaves se apro-ximen entre sí a una distancia inferiora cin co millas náuticas en el planohorizontal y mantengan una diferen-cia de altitud inferior a mil pies. Unavez detectado el conflicto, se activael algoritmo de resolución de conflictoque generará las correspondientes

instrucciones a las aeronaves impli-cadas para resolverlo. El algoritmode resolución de conflicto implemen-tado no pretende ser el más adecuadodes de el punto de vista operacional,si no más bien constituir una acción apartir de la cual generar un compor-tamiento de respuesta del agente ATCa una situación conflictiva entre ae-ronaves. Tanto la detección del con-flic to como las instrucciones ATC pa rasu resolución serán enviadas a tra-vés de sendos mensajes a las aero-naves implicadas.

El comportamiento del ATC con-siste en la recepción de mensajes delas aeronaves (comportamiento cícli -co). Los datos procedentes de estosmensajes son utilizados para pre-sentarlos en la pantalla radar ATC(comportamiento periódico) y paradetectar posibles conflictos entre doso más aeronaves. Los algoritmos dedetección y resolución de conflictosasí como el envío de mensajes a lasaeronaves implicadas, en caso deque éste se produzca, se han imple-mentado dentro de otro comporta-miento periódico.

Además de las comunicaciones conel Agente Aeronave, el Agente ATCse comunica con el Agente Terrenopara obtener datos relativos a lasrutas disponibles. En posteriores am-pliaciones de este trabajo se puedenmejorar las capacidades del AgenteTerreno y la comunicación entre éstey el ATC con el fin de mantener, porejemplo, una información actualizadade la saturación de tráfico aéreo encada ruta.

aPlicacionEs Y rEsultaDos

Para ilustrar algunas de las capaci-dades de la aplicación descrita eneste artículo, se presenta un escena-rio con dos aeronaves: la primera deellas, que denominaremos CESSNA,

se trata de una aeronave del tipoCessna Golden Eagle, que apareceen el instante de tiempo 0 en la rutanúmero 0 con una altura inicial de10,000 pies; la segunda aeronave,


36

que denominaremos A320, es unaaeronave del tipo Airbus 320, queaparece diez segundos después si-guien do la misma ruta 0, con la mis maaltura inicial de 10,000 pies. Debido aque la aeronave A320 vuela a mayorvelocidad, ésta se acercará progresi-vamente a la aeronave CESSNA quevuela por delante, provocando que elagente ATC detecte un conflicto entreambas aeronaves, cuando se incum-pla la distancia mínima de seguridadde 5 millas náuticas.

Seguidamente el agente ATC daráórdenes a cada una de las aerona-ves para intentar resolver el conflicto.A la aeronave de menor velocidad,en este caso la CESSNA, se le añadi -rá un nuevo punto (waypoint) al plande vuelo, que formará un triángulocon el waypoint anterior y posterior,desviándose así de la ruta original eneste tramo pero sin modificar los pos-teriores waypoints del plan de vuelo.Además su altitud se multiplica porun factor de 0.8, disminuyendo portanto a 6,124 pies. Simultáneamentea la aeronave A320 se le añade unnuevo waypoint a mitad de caminoentre la posición actual y el siguiente

waypoint, cuyo único objetivo es mul-tiplicar su altitud en ese tramo por unfactor de 1.2, aumentando por tanto a8,862 pies. Conviene insistir en estepunto, que el criterio de aumentar odisminuir la altitud actual de cualquieraeronave en un factor de su altitudactual no resulta factible desde elpunto de vista operacional de la avia-ción general y comercial (donde seconviene en que las aeronaves au-mente o disminuyan su altitud en ba -se a niveles de vuelo separados milpies entre ellos). Sin embargo, en es-te caso la asignación del nivel de al-titud es secundaria, en tanto que lofundamental es verificar la respuestade la aeronave a la resolución dadapor el algoritmo de detección y reso-lución de conflicto.

En la Figura 5 podemos observarla trayectoria en el plano horizontalde ambas aeronaves, así como losplanes de vuelo iniciales, que en estecaso coinciden. Asimismo en la Fi-gura 6 se muestra la trayectoria ver-tical, es decir la variación de altitudde ambas aeronaves en función deltiempo.

37


Figura 5. Trayectoria horizontal de las aeronaves


38

Figura 7. Captura de pantalla de la aplicación para el escenario descrito

Figura 6. Trayectoria vertical de las aeronaves

De esta forma lo que se consiguees evitar el posible conflicto tanto enel plano horizontal, desviando la aero -nave más lenta (CESSNA) y dejan dopaso a la de mayor velocidad (A320);como en el plano vertical, aumentan -do la altitud de la aeronave A320, a lavez que se disminuye la altitud de laaeronave CESSNA. Estas variacionesde altitud además contribuyen a la re-so lución del conflicto consiguien do quela aeronave que adelanta aumenteaun más su velocidad, y la aero naveque es adelantada la disminuya.

La geometría de la nueva ruta semuestra en la Figura 7, así como lapestaña Órdenes de la Ventana deControl ATC, cuyo contenido se in-cluye en la Tabla 1. En ella podemosver que en el segundo 126 se detectael conflicto entre las aeronaves y semodifican los planes de vuelo comoya se ha descrito. En la Tabla 1 tam-bién se muestra la pestaña Datos dela Ventana de Control del A320, en laque se puede observar la altitud mo-dificada de la aeronave; y la pestañaPlan de Vuelo de la Ventana de Con-trol del CESSNA, en la que podemoscomprobar que se ha añadido elwaypoint para evitar el conflicto (estese muestra con un círculo negro al-rededor).

conclusionEs

En este trabajo se ha llevado a cabola implementación de un simuladorde tráfico aéreo experimental comoun sistema multiagente. La utilidadde este simulador de tráfico aéreo esla de servir de fuente de datos realis-tas para la validación de algoritmos,

interfaces hombre-máquina y proce-dimientos para la navegación y ges-tión del tráfico aéreo en un entornofree-flight.

El modelo incluye a los agentes fí-sicos aeronave, ATC, meteorología yterreno, al agente interfaz pseudopi-loto, y al Agente Configuración.

El núcleo fundamental de la apli-cación desarrollada es el Agente Ae-ronave. Los procesos desarrolladospor el agente aeronave para deter-minar su vector de estado, calcular elTOD durante un descenso continuo,enviar y recibir datos a otros agentesse realizan a través de tres tipos decomportamientos básicos: simple, cí-clico y periódico.

La principal ventaja de su imple-mentación como Sistema Multiagen -te es que su arquitectura permite unaposterior ampliación de las capacida -des y comportamientos de los agen-tes, sobre todo en el aspecto relativoa la negociación entre agentes aero-naves. Por otra parte, el lenguaje ACLutilizado por la plataforma de desa -rrollo de agentes JADE tiene un forma -to similar a la estructura de los pro-tocolos de comunicación en un en-torno de tráfico aéreo, lo cual facilitala implementación de nuevos proto-colos de comunicación y negocia ciónentre agentes.

BiBlioGrafía

Eurocontrol, 2004. EUROCON TROLExperimental Centre. User Manual

For The Base Of Aircraft Data (Ba-

da) - REVISION 3.6, 2004.

39


ATC Orders

T= 126, Detected CONFLICT between aircrafts CESSNA and A320

T= 126, CESSNA → Add WP: 1, x: -103643,46, y: -23062,12, z: 6124,67, arc: No, turn: R

T= 126, A320 → Add WP: 1, x: -93839,64, y: 5000,00, z: 8862,46, arc: No, turn: R

Tabla 1. Contenido del fichero con las órdenes del ATC

BioGrafíasFipa, 2002. Foundation for IntelligentPhysical Agents Specifications,http://www.fipa.org/specifica-tions/index.html (2002).

Glover et ál., 2004. W. Glover y J.Lygeros. A Multi-Aircraft Model for

Conflict Detection and Resolution

Algorithm Evaluation. TechnicalReport WP1, Deliverable D1.3,HYBRIDGE, 2004.

Hoekstra, 2001. Hoekstra, J. M. De-

sig ning for Safety: the Free Flight

Air Traffic Management Concept.Ph. D. Dissertation, Delft Univer-sity of Technology, 2001.

Morales, 2001. Juan de Mata MoralesLópez. CNS/ATM. Cuadernos Aenanº 2. AENA (2001).

Nasa, 1999. NASA. “Concept Defi ni-

tion for Distributed Air/Ground Traf-

fic Management (DAG-TM). V 1.0”NASA Advanced Air Transporta-tion Techno logies Project, 1999.

Oaci, 1998. Planificación de la Nave-gación Aérea para los sistemasCNS/ ATM. OACI, Doc. 9750, 1998.

Perez et ál., 2004. Agentes Softwarey sistemas Multia-agentes; Jo séLuis Pérez de la Cruz, Juan Pa -vón Mestras; Pearson PrenticeHall, 2004.

Rtca, 1997. Proceedings of RTCA, Inc.Annual Symposiums, Free Flight:

New Concepts, A New Architec-

ture, New Opportunities,1997.

Telecom, 2000. Telecom Italia Lab,Java Agent Development Frame-

work (JADE) webpage, http://jade.tilab.com, 2000.

José MiGuEl canino es ProfesorTitular de Escuela Universitaria delDepartamento de Señales y Comuni-caciones de la ULPGC. Es Licenciadoen Ciencias Físicas por la UNED, In-geniero Técnico de Telecomunicación(ULPGC) y está en posesión del Títu -lo de Piloto Comercial de Avión. Ac-tualmente realiza su Tesis Doctoral enel ámbito de los sistemas y procedi-mientos de navegación y gestión deltráfico aéreo en entornos de vuelofree-flight. Ha realizado diversas es-tancias de investigación en la UPMdon de ha trabajado en el seno del Gru -po de Procesado de Datos y Simula-ción del Departamento de Señales,Sistemas y Radiocomunicación dichaUniversidad.

salVaDor Durá BErnal es In-geniero Superior de Telecomunicaciónpor la ULPGC. Actualmente realiza suTesis Doctoral en el Centro de Ne uro-ciencia Teórica y Computacional de laUniversidad de Plymouth (Reino Uni-do), en el ámbito de modelos compu-taciona les del Sistema Visual basa-dos en redes Bayesianas jerárquicas.

luis GóMEz Déniz es Profesor Ti-tular de Universidad del Departamen -to de Ingeniería Electrónica y Auto-mática de la ULPGC, donde impartesu docencia en la Escuela TécnicaSuperior de Ingenieros de Telecomu-nicación desde el año 1991. Licencia -do en Ciencias Físicas por la UNED yDoctor Ingeniero de Telecomunica-ción por la ULPGC. Su campo de tra-bajo e investigación se centra en laoptimización y métodos numéricosaplicados a la ingeniería. Actualmentedesarrolla su investigación en el CTM(Centro de Tecnología Médica) de laULPGC en el campo de la elastografíapor ultrasonidos y en la optimizaciónde algoritmos aplicados a la navega-ción y gestión del tráfico aéreo.


40

Patrocinador de esta investigación:

BElEYMa

Documents

Entorno de simulación de tráfico aéreo experimental basado ... · El simulador ha sido implementado como un sistema Multiagente con el fin de considerar los futuros escenarios