Sistema para sincronização e gerenciamento de fluxo de tráfego aéreo multi-agentes

<jats:p>&lt;p&gt;Nesta pesquisa propõe-se um sistema para sincronização e gerenciamento de fluxo de tráfego aéreo que combina tecnologias de Inteligência Artificial – coordenação de Multi-Agentes, e computação distribuída sobre a Internet – Grid Computacional – cuja finalidade é otimizar o fluxo de tráfego aéreo, prevendo congestionamentos e racionalizando a utilização dos recursos dos aeroportos, sem contudo, ferir os princípios de segurança estabelecidos para a área de transportes aéreos. Para demonstrar o sistema desenvolvido, são descritos sua arquitetura, seus componentes e os relacionamentos entre eles, bem como os mecanismos de negociação necessários às tomadas de decisão. A título ilustrativo, é relatado um estudo de caso de planejamento tático, simulado a partir de informações do Aeroporto Internacional de São Paulo. A combinação das duas tecnologias, coordenação de Multi-Agentes e Grid Computacional, aplicada ao problema de gerenciamento do fluxo de tráfego aéreo apresenta perspectivas de tornar-se um tópico promissor para pesquisas futuras.&lt;/p&gt;</jats:p>

section_content: O Gerenciamento de Fluxo de Tráfego Aéreo (ATFM) é um tipo de problema cuja solução envolve a sincronização do tráfego aéreo em Tempo Real (Stoltz e Ky, 2001; Stoltz e Guerreau, 2002). Desde os anos 70, cientistas de Inteligência Artificial (IA), Pesquisa Operacional e Transportes Aéreos têm unido esforços para desenvolver sistemas de Controle de Tráfego Aéreo (ATC) e Gerenciamento de Tráfego Aéreo (ATM) mais eficientes. As soluções baseadas na computação têm esbarrado num problema crítico comum que é a eficiência da própria computação no atendimento às necessidades críticas desses sistemas -escalabilidade, segurança e sincronização. 

Um sistema de ATM distribuído foi estudado na Austrália (Tidhar et al., 1992) e suas vantagens são: distribuição inerente, autonomia, comunicação e con-fiabilidade. Um Sistema Baseado no Conhecimento, para suporte ao ATM em tempo real foi desenvolvido pela IBM/Suíça (Schlatter, 1994). No Brasil, foi analisado um sistema especialista de Gerenciamento de Fluxo de Tráfego Aéreo (ATFM) para fazer a escala de horários e o controle centralizado do fluxo de tráfego (Weigang et al., 1993 (Weigang et al.,, 1997)). Foi desenvolvida uma ferramenta automatizada de auxílio à alocação de slots (FEAS) como alternativa para o Gerenciamento de Fluxo de Tráfego Aéreo, que propõe uma alteração na programação dos horários de partida dos vôos, de forma a evitar um desbalanceamento entre a demanda e a capacidade nos diversos nós da rede. Esta ferramenta, apesar de muito interessante, apresenta uma deficiência, reside isoladamente em cada aeroporto, e dessa forma, não consegue atuar preventivamente sobre fluxos de origem, causadores do congestionamento (Targa et al., 2001). 

Uma ferramenta poderosa, que implementa uma abordagem distribuída para interface de operador, orientação inteligente de vôo, gerenciamento e suporte à decisão (Prevôt, 2002) está sendo desenvolvida no Centro de Pesquisas Ames na NASA. 

O Eurocontrol apresentou, recentemente, a proposta de uma aplicação que implementa técnicas de coordenação de Multi-Agentes. Essa proposta fundamenta-se na simplicidade e coerência dos comportamentos coletivos dos agentes controladores e nos resultados promissores de pesquisas realizadas nessa área, cujo estado da arte são os fundamentos de ações coordenadas: planejamento distribuído, intenção comum e reação coletiva (Nguyen-Duc et al., 2003). 

Deve-se ainda mencionar que, embora as técnicas de coordenação de Multi-Agentes sejam uma estrutura metodológica útil, a pesquisa (Nguyen-Duc et al., 2003) está limitada a uma camada de software (software Shell), e sua implementação na esfera prática seria extremamente complexa, devido ao volume de tráfego processado pelo ATFM. 

O conceito de Grid Computacional tem sido definido como "recursos coordenados compartilhando e resolvendo problemas em organizações multi-institucionais virtuais e dinâmicas" (Foster e Kesselman, 1999). Atualmente, essa tecnologia apresentase como uma perspectiva para a solução de tarefas de computação de larga escala, caso do ATFM (Berman et al., 2003 ; Ferreira et al., 2003; Sotomayor, 2003; Portela e Melo, 2004). 

Os pesquisadores dos centros de pesquisas Ames, Glenn e Langley da NASA desenvolveram um protótipo operacional de um espaço aéreo virtual. O protótipo de simulação do espaço aéreo nacional (VNAS) utilizou recursos em grande escala disponíveis de um Grid Computacional para atacar o problema de melhorar a segurança do transporte aéreo (McDermott, et al., 2003). 

Grids Computacionais são infra-estruturas de hardware e software que possibilitam o acesso seguro, consistente, distribuído e de baixo custo às demandas de alto nível computacional. Um sistema de gerenciamento baseado na tecnologia de Multi-Agentes executado em um Grid computacional mostra a importância da pesquisa em ambos os domínios, Grid Computacional e Multi-Agentes (Cao et al., 2002). 

Este estudo propõe um Sistema para Sincronização e Gerenciamento de Fluxo de Tráfego Aéreo, denominado de ATFM_MAS (Air Traffic Flow Management Multi-Agents System), utilizando as tecnologias de Multi-Agentes e Grid Computacional, tendo sido baseado nas pesquisas mencionadas, especialmente nos trabalhos publicados em decorrên-cia delas (Weigang et al., 1993 (Weigang et al.,, 1997;; Tidhar et al., 1992; Prevôt, 2002; Nguyen-Duc et al., 2003). 

O protótipo do ATFM_MAS foi implementado em uma rede composta por quatro computadores, cada um simulando um aeroporto, para que fosse possível ilustrar um estudo de caso de planejamento tático de fluxos destinados a esses aeroportos. A intenção deste artigo é mostrar que a investigação de sistemas Multi-Agentes utilizando Grid de Computacional não é apenas uma simples aplicação, mas também, um tópico de estudo importante próprio do tema Transporte. 

As seções seguintes estão organizadas em seis partes: a seção 2 introduz os conceitos básicos e características do ATFM; a seção 3 descreve os modelos funcionais dos agentes, incluindo os mecanismos de negociação entre eles; a seção 4 apresenta a arquitetura e os componentes do ATFM; a seção 5 discorre sobre a implementação do sistema, seus agentes e o processo de inferência; a seção 6 ilustra o estudo de caso; a seção 7 encerra as conclusões.
section_name: INTRODUÇÃO

section_content: O ATFM é desenvolvido para assegurar um fluxo otimizado de tráfego aéreo para ou através de áreas nas quais as demandas de tráfego excedem, em certos períodos, a capacidade disponível do sistema ATC (Weigang et al., 1993). 

As principais funções do ATFM são: Planejamento estratégico (envolvendo período longo: dias a anos), Planejamento Pré-Tático e Tático (envolvendo períodos médios, de 1 hora a dias) e Monitoramento/ Controle (operação On-Line). O cenário geral de ATFM é mostrado na Figura 1. Conforme mencionado por Stoltz e Guerreau (2002), o sistema ATFM possui duas propriedades especiais:

• Sincronização de Tráfego Aéreo em Tempo Real, que consiste na implementação de ações corretivas aplicadas ao tráfego, até que este seja realmente recebido pelos controladores, para serem monitorados. 

• Tomada de decisão colaborativa dinâmica, que realiza a execução imediata de acordos dinâmicos entre os Gerentes de Tráfego, co-envolvidos na implementação de ações corretivas na transição do tráfego de um setor a outro. 

Neste estudo, o escopo é limitado ao planejamento tático do ATFM. As principais funções são consideradas conforme se segue (Tidhar et al., 1992; Weigang et al., 1997) :

• Criar uma programação de horário para todas as decolagens e aterrissagens no aeroporto, enquanto maximiza a utilização da pista e do terminal;

• Identificar áreas de congestionamento com relação ao espaço aéreo e pistas;

• Negociar com outros agentes a expectativa de fluxo de tráfego do aeroporto e para o aeroporto;

• Re-programar os vôos de acordo com o resultado da negociação; e

• Comunicar os novos horários a outros agentes afetados.
section_name: PROBLEMA DE SINCRONIZAÇÃO DE TRÁFEGO AÉREO

section_content: A partir da identificação da demanda esperada, resultante da análise das informações disponíveis dos horários de pousos e decolagens, havendo previsão de um congestionamento, os agentes entrarão em negociação do fluxo aéreo com os aeroportos envolvidos. A idéia é, baseando-se na previsão de se efetuar possíveis atrasos de determinados vôos, habilitar a concordância entre os aeroportos para que seus agentes possam realizar a reprogramação dos horários, a fim de gerar soluções que reduzam o congestionamento, distribuindo o tráfego mais uniformemente entre os aeroportos. Modelos da demanda esperada e dos recursos disponíveis são constantemente gerados, monitorados e atualizados pelo sistema. É importante ressaltar que, quando nos referimos simplesmente à negociação de fluxo entre aeroportos, remetemos a um sistema complexo que envolve os aeroportos, atra-tivadas, e propagam essas escalas para os demais agentes envolvidos. 

Para negociar o fluxo para um aeroporto, foi necessário definir uma medida do fluxo e do congestionamento na utilização dos recursos. Essa quantia abstrata, denominada Atraso Total de Peso Combinado (ATPC), é uma função do tempo de atraso de cada vôo e do peso (fator de importância) a ele associado, simplificada de (Tidhar et al., 1992), mostrada abaixo:

em que:

ATPC (t 1, t 2 ): Atraso Total de Peso Combinado entre os instantes t 1 e t 2 n: número de vôos entre os instantes t 1 e t 2 ƒ: vôo em análise

se ƒ i = pouso ou decolagem O ATPC foi escolhido como uma função do tempo de atraso porque quando um aeroporto está congestionado alguns dos vôos são atrasados e a extensão do tempo de atraso é proporcional à severidade do congestionamento. Mas, os vôos não têm as mesmas importâncias e o atraso de um vôo pode ter um custo maior do que o atraso de outro. Assim, combinando-se o tempo de atraso com o peso (fator de importância) do vôo atrasado tem-se a indicação da carga do aeroporto. 

São calculados ATPC distintos para as aterrissagens e decolagens das aeronaves. Considerando que um dos objetivos do ATFM é minimizar a retenção de aeronaves no ar, nesta pesquisa a função de custo do atraso foi simplificada para a multiplicação de cada minuto de atraso por um peso. Realizadas várias simulações, chegou-se a um peso igual a 5 para aterrissagem e peso igual a 1 para decolagem: esses fatores produzem uma avaliação compatível com a observação de um especialista.
section_name: MODELO FUNCIONAL DOS AGENTES

section_content: A criação da escala de horários (schedule) e o cálculo do ATPC são feitos localmente em cada aeroporto. A escala de horários é gerada, para um determinado período de tempo TS (Time Slice), considerando-se as saídas previamente agendadas e o tempo estimado de chegada dos vôos de entrada. O TS é um intervalo de tempo variável, isto é, pode ser reduzido ou aumentado quando a carga do aeroporto estiver alta ou baixa, respectivamente.
section_name: Criação da Escala de Horários

section_content: Um congestionamento será identificado quando, num intervalo de tempo analisado, a demanda para um aeroporto (pousos/decolagens) superar sua capacidade de vazão. Como essa é uma situação que não pode ocorrer na prática, alguns vôos deverão ser atrasados ou retidos no ar. Quanto maior o congestionamento, maior será o atraso. 

Numa situação ideal não deveria haver nenhum atraso. No mundo real devem-se manter pequenas filas para as pistas dos aeroportos, de forma a maximizar sua utilização. Neste estudo, após várias simulações, chegou-se a um valor de ATPC definido como aceitável, para cada aeroporto, que maximiza a utilização das pistas de forma segura e mantém administrável a sobrecarga sobre o ATC. 

Qualquer ATPC de valor maior que o aceitável indica um congestionamento de pista. A situação é identificada analisando-se a escala de horários e verificando-se o ATPC em diferentes pontos do tempo. O ATPC, que dá a medida de congestionamento, deve ser reduzido pelo ATPC excedente (i. e., a diferença entre o ATPC calculado e o ATPC aceitável). Uma vez que o objetivo é minimizar a retenção das aeronaves no ar, a negociação do ATPC é executada apenas para vôos de entrada.
section_name: Identificando o Congestionamento

section_content: Uma vez que o fluxo de entrada de um aeroporto é influenciado pelo fluxo de saída de outros aeroportos, várias horas antes, os agentes precisam interagir para determinar níveis de fluxo e resolver congestionamentos. 

As negociações para serem realizadas utilizam a infra-estrutura implementada pelo Grid Computacional. Os agentes negociam usando uma medida concreta, isto é, o tempo de atraso por vôo, derivado do cálculo do ATPC. Em seguida, cada agente dos aeroportos de origem absorverá o ATPC relativo ao vôo que ele aceitar atrasar. Sob solicitação, pode ser requerida a interação do usuário (controlador de fluxo de tráfego aéreo) no protocolo de negociação na confirmação das mensagens. 

Por exemplo, assumindo-se que o Aeroporto Internacional de São Paulo (GRU) está congestionado, devido a pousos programados para um mesmo horário, oriundos dos Aeroportos Internacionais do Rio de Janeiro (GIG) e de Porto Alegre (POA), seria iniciada a seqüência de ações descritas a seguir:

1. GRU, que esta com ATPC alto, iniciará a negociação com agentes do GIG e de POA, a fim de reduzir seu ATPC e, conseqüentemente, seu congestionamento. 2. GRU enviará uma mensagem de requisição pedindo para GIG e POA atrasarem os vôos indicados, pelos tempos indicados. 3. Cada um dos Agentes Pré-ATC, dos aeroportos acionados, calcularão o montante de ATPC que poderá ser absorvido. 4. Se efetivarem os atrasos solicitados, GIG e POA enviarão respostas a GRU com a aceitação. 5. O aeroporto que não efetivar os atrasos solicitados informará GRU da não aceitação. 6. Ao receber as respostas das solicitações efetuadas (ou um timeout), GRU enviará mensagem de decisão para o(s) agente(s) apropriado(s), comunicando-o(s) da situação final. 

Os modelos funcionais apresentados acima descrevem como os agentes geram os modelos de demanda prevista e de capacidade disponível e criam uma solução usando escalonamento de horários e negociação. Esses modelos são continuamente monitorados e atualizados quando da entrada de informações referentes a novos vôos, mudanças nos vôos, mudanças climáticas (meteorologia), mudanças de recursos, ou resultados de negociações entre agentes.
section_name: Negociando ATPC adequados

section_content: Para construir a solução ATFM_MAS foi necessário combinar vários componentes de hardware e software os quais são descritos abaixo em maiores detalhes.
section_name: ARQUITETURA E COMPONENTES DO ATFM_MAS

section_content: O sistema ATFM_MAS é proposto para dar suporte ao compartilhamento e uso coordenado de recursos diversos dos sistemas brasileiros de controle de fluxo de tráfego aéreo. Como os aeroportos são geograficamente distribuídos, algumas vezes os controladores de ATFM operam seus componentes de forma distintas, inclusive adotando políticas diferentes. O sistema ATFM_MAS implementa, via web services, agentes de software escritos em linguagem Java executados sobre um Grid Computacional, o que possibilitará o sincronismo de ações entre os aeroportos envolvidos na solução. Trata-se de um framework Java utilizando-se das funcionalidades de Grid Computacional definidas pela OGSI -Open Grid Services Infrastructure (Ferreira et al., 2003). 

O conceito de Grid Computacional, conforme Foster e Kesselman (1999), proporciona a infra-estrutura integrada necessária para o gerenciamento de recursos compartilhados e soluções de problemas em ambientes distribuídos. Tal conceito encaixa-se perfeitamente à solução aqui proposta. A ferramenta Globus Toolkit (Globus, 2004) implementa o Grid aplicando o conceito de Grid de Serviços, o qual é considerado como a próxima geração das aplicações baseadas nessa tecnologia (Sotomayor, 2003). 

A arquitetura do ATFM_MAS é composta de cinco componentes: Interface, Contêiner OGSA -Open Grid Service Architecture e Tomcat, Web Services, servidor de aplicações e base de dados. Esses componentes e seus relacionamentos são apresentados na Figura 2 4. 2 Componentes Básicos do ATFM_MAS
section_name: Arquitetura

section_content: A função da interface é possibilitar ao controlador de fluxo de tráfego aéreo interagir de forma amigável com o ATFM_MAS. Supondo-se que cada aeroporto tenha seu próprio sistema operacional, com sua própria interface, o controlador envia as solicitações e recebe as respostas dos aeroportos relacionados, por meio de notificações de serviços específicos do grid de serviços.
section_name: A Interface

section_content: O Tomcat é um contêiner (servidor) Web Java mantido pelo Apache Jakarta Project (Apache, 2004). No sistema, sua responsabilidade é abrigar as aplicações web que implementam a arquitetura aberta de serviços de Grid, a OGSA. O Globus é o software usado para implementar o que o OGSA define e o que o OGSI especifica, além de prover vários outros programas, utilitários e serviços. Na OGSA-Globus residem os agentes, suas regras de negociações e de comunicações. Os agentes comunicam-se entre si, com as regras negociais e controle de persistências via Web Services.
section_name: O Contêiner OGSA e Tomcat

section_content: De acordo com o descrito por Foster e Kesselman (1999) e Sotomayor ( 2003 ), os Web Services são a base para os grid de Serviços, sendo, portanto, componentes essenciais da ferramenta Globus Toolkit 3. 

Desde que sejam utilizadas mensagens padrão XML, os Web Services são, ao mesmo tempo, independentes de linguagens e plataformas. Considerando-se, ainda, o fato de que a maior parte dos Web Services utilizam o protocolo HTTP para a transmissão de mensagens isto representa uma vantagem importante para se construir, num futuro próximo, uma aplicação ATFM baseada na internet. 

Os Web Services direcionam a computação heterogênea distribuída, através da definição de técnicas para a descrição de componentes de software, métodos de acesso a esses componentes e a identificação de relevantes provedores de serviços de Web Servi-ces. A principal vantagem do uso de Web Services é que eles permitem às aplicações o compartilhamento de dados independentemente de quais linguagens foram utilizadas para construção dessas aplicações e em qual sistema operacional ou plataforma elas são executadas. 

Figura 2: Arquitetura do sistema ATFMGC
section_name: Os Web Services

section_content: O JBoss, servidor de aplicações Java mantido pelo JBoss Group, foi o servidor de aplicações escolhido. Nele, estão contidos todos os contêineres (servidores) J2EE esperados em um servidor de aplicações (Servidor Web, Servidor EJB, Servidor JNDI, Controle de Transações, etc. ). As regras de negócios e os controles de persistência residem em uma aplicação hospedada nesse servidor e são publicadas automaticamente pelos Web Services.
section_name: O Servidor de Aplicações

section_content: Devido às necessidades de sincronização do fluxo de tráfego aéreo em tempo real, o acesso aos dados deve ser fácil e rápido, razão pela qual foi utilizado o sistema de gerenciamento de banco de dados relacional MySQL, mantido pelo MySQL AB (MySQL, 2004). O mapeamento objeto-relacional é feito pelo framework Hibernate (Hibernate, 2004) que é uma API/framework Java residida no servidor de aplicações.
section_name: A Base de Dados

section_content: Neste estudo, os agentes ATC, Pré-ATC e Planejamento Tático (PT) foram desenvolvidos para o ATFM_MAS em linguagem Java. A Figura 3 mostra a forma de comunicação e negociação entre agentes no sistema ATFM_MAS.
section_name: PROCESSO DE IMPLEMENTAÇÃO E INFERÊNCIA

section_content: Esse agente possui um módulo denominado Monitor ATC que é o responsável por implementar a interface de comunicação com o "mundo real do ATC". Ele recebe informações de vôos que tiveram seus horários modificados por motivos diversos (clima, incidente, fechamento de aeroporto etc) e envia para o "mundo ATC" informações de vôos cujos horários foram modificados devido à re-escalonamentos feitos pelo agente PT.
section_name: Agente ATC

section_content: O Agente Pré-ATC foi desenvolvido de acordo com as regras de ATC/ATM, as quais têm sido definidas pelo Departamento de Aviação Civil -DAC (Weigang et al., 1997; DEPV, 1999). Este agente possui dois módulos:

1. Scheduler -responsável por re-escalonar os vôos em conflitos, obedecendo a regras pré-estabelecidas, dentro de um determinado período de tempo; e 2. Diagnosticador -responsável por receber a tabela de vôos re-escalonada e calcular o ATPC. Com o ATPC calculado, este módulo aciona o agente TP para entrar em negociação com outros agentes, de outros aeroportos. Este monitor também recebe solicitações de vôos do agente Pré-ATC, a serem negociadas com outros agentes de outros aeroportos; 2. Negociador -responsável por efetuar a negociação de re-escalonamento de vôos com outros agentes PT. Este módulo recebe e responde a uma determinada solicitação de re-escalonamento de vôos. Além de receber, efetua uma solicitação de re-escalonamento para um outro agente PT; e 3. Executor -responsável por receber do módulo

Negociador as solicitações de mudanças de dados de vôo já validados e re-agendados.
section_name: Agente Pré-ATC

section_content: Para esta simulação, iniciada às 7:00 da manhã (horário corrente), foram usadas informações dos vôos agendados para o período de 9:00 às 10:00 da manhã, de 16 de fevereiro de 2004 (Panrotas, 2004). O agente Pré-ATC no Aeroporto Internacional de Guarulhos (GRU) começou a detectar o congestionamento de tráfego para um período de tempo ∆t 2, de t 1 a t 2, onde t 1 = Hora corrente + ∆t 1, t 2 = t 1 + ∆t 2. Definindo ∆t 1 = 2 horas e ∆t 2 = 1 hora, o agente Pré-ATC considerou o período t 1 =9:00 e t 2 =10:00 horas. O Pré-ATC foi utilizado para calcular o ATPC para os vôos no intervalo das 9:00 às 10:00. No intervalo das 9:20 às 9:25, o ATPC foi maior que o valor aceitável, o que era de se esperar, visto existirem 5 (cinco) chegadas de vôos às 9:20 da manhã: PU222 vindo de Montevidéu (MVD), RG 2308 de Porto Alegre (POA), RG8902 e RG 8936 do Galeão (GIG) e AA995 de Miami (MIA), conforme mostrado nas colunas de 1 a 5 da Tabela 1 abaixo. 

Para efeito desta análise, definiu-se como parâmetro o intervalo mínimo de 2 minutos entre pousos sucessivos, logo os atrasos serão 0, 2, 4, 6 e 8 minutos. O agente Pré-ATC, com base nas regras de ATC/ATM e nas prioridades definidas em DEPV (1999) estabeleceu a seguinte seqüência, em ordem de prioridade, para os pousos: 1) AA995 -mantido no horário; 2) PU222 -pouso retardado em 2 minutos; 3) RG2308 pouso retardado em 4 minutos; 4) RG8936 pouso retardado em 6 minutos; e 5) RG8902 pouso retardado em 8 minutos. Os resultados são mostrados nas colunas 6 e 7 da Tabela 1. 

Para uma melhor compreensão do processo de inferência que originou o resultado acima, este será analisado passo a passo. O sistema ATFM_MAS realizou essa análise no tempo corrente igual a 07:00 horas (tempo real). Nesse instante, o vôo PU222 acabava de decolar de Montevidéu, o vôo AA995 já se encontrava voando há sete horas e quarenta minutos e os três vôos restantes ainda se encontravam no solo. Como um dos principais objetivos do ATFM é evitar a retenção de aeronaves no ar, as duas aeronaves que já estavam voando tiveram prioridades sobre as demais. Estabelecido este primeiro marco, PU222 e AA995 chegariam, ambos, para pouso às 9:20 horas (neste modelo estamos desconsiderando a influência de ventos Porém, teria sido possível que os agentes Pré-ATC, nos aeroportos do Galeão e Porto Alegre, chegassem a outra configuração de escala de vôo, ou seja, a outro valor de tempo de atraso, para o pedido feito. Por exemplo, a solicitação de atraso da decolagem do RG8936 para 8:26 horas, poderia ter conflitado com algum vôo já programado para pouso nesse horário. Logo, o que Guarulhos poderia ter oferecido seria a próxima janela, isto é 8:28 horas. Esta proposta de 8 minutos seria retornada ao agente PT de Guarulhos que a repassaria para o seu agente Pré-ATC para análise. Esse processo de negociação avançaria até que os agentes TP entrassem em acordo. O acordo não significa, necessariamente, a obrigação de terem de aceitar uma oferta qualquer: ou seja, a inviabilidade de atraso também é um acordo. Conforme mencionado, no item 3. 3, a negociação tem um tempo para ser concluída. Findado este prazo (timeout), o agente PT que solicita a negociação assume como negativo seus pedidos e procede de acordo como tal. 

O agente PT no aeroporto de Guarulhos também se comunicou com os agentes PT dos aeroportos de destino, informando os novos horários de decolagens de seus vôos, que foram atrasados devido à resolução dos conflitos de pousos e decolagens. 

Assim, os agentes PT dos diferentes aeroportos envolvidos neste estudo coordenaram seus processos até que a rede ATFM_MAS tivesse atingido o sincronismo.
section_name: UM EXEMPLO ILUSTRATIVO

section_content: A utilização de Multi-Agentes com Grid Computacional para a solução do problema de sincronização de fluxo de tráfego em tempo real foi proposta nesta pesquisa. O ATFM é um domínio interessante para aplicação dessas duas tecnologias. (Cao et al., 2002; Weiss, 1999). 

Não foi registrado, até o momento, nenhum estudo sobre o uso combinado das referidas tecnologias para a solução do problema de sincronização de fluxo tráfego aéreo. Tendo-se em mente as vantagens do Grid Computacional, esta proposta também apresenta uma solução para o transporte aéreo, visto que a plataforma utilizada é um eficaz meio de integração de dados e sistemas legados (Lavery, 2002). 

Os resultados obtidos neste trabalho podem representar uma significativa contribuição para a pesquisa de tecnologias em transportes aéreos. Para estudos posteriores, os seguintes aspectos devem ser levados em consideração:

• Construção de um Grid computacional especial para ATFM, para estudar os principais componentes (hardware e software), bem como sua capacidade para atender às altas demandas geradas pelo controle de fluxo de tráfego aéreo; • Os parâmetros para organizar o re-escalonamento entre os nós do Grid (aeroportos) ainda estão em desenvolvimento. Eles ainda são importantes para avaliação posterior do sistema; • Implementação do ATFM_MAS num ambiente real de ATC/ATM, a fim de fazer o planejamento tático de ATFM e controle em tempo real.
section_name: CONCLUSÕES