sistema de simulação acelerado para análise de fluxo de tráfego
TRANSCRIPT
INPE-8761-TDI/801 SISTEMA DE SIMULAÇÃO A ACELERADO PARA ANÁLISE DE
FLUXO DE TRÁFEGO AÉREO
Alexandre Magno Gonzaga da Silva
Dissertação de Mestrado em Computação Aplicada, orientada pelos Drs. Tatuo Nakanishi e João Bosco Schumann Cunha, aprovada em 27 de abril de 2001.
INPE São José dos Campos
2002
681.3.06:629.7 SILVA, A. M. G.
Sistema de simulação acelerado para análise de fluxo de tráfego aéreo / A. M. G. SILVA - São José dos Campos: INPE, 2001.
205p. – (INPE-8761-TDI/801). 1.Simulação computadorizada. 2.Simulação de vôo.
3.Sistema de simulação por computador. 4.Simuladores. 5.Sistema de simulação I.Título.
O Pai que está nos Céus não o
abandona. Ele o contempla. Você é
pensamento divino feito realidade
humana. Não veio à vida por acaso,
mas por amorosa vontade do criador.
“O Senhor é meu Pastor, Nada me
Faltará”.
J. S. Nobre
“Reflexões”
Edições Paulinas
AGRADECIMENTOS
Dedico este trabalho primeiramente a Deus, ao Sagrado Coração de Jesus e Maria por ter
me dado a oportunidade e o privilégio de poder realizá-lo.
Em memória de minha mãe “Lúcia Cândida da Silva” pelo amor e carinho que sempre
demonstrou por mim em qualquer circunstância.
Agradeço `a minha esposa “Cleonice” e a nossas crianças “Carlos Eduardo e Fernanda” que
souberam entender e compreender o meu esforço para cumprir essa nobre missão.
Ao IPV (Instituto de Proteção ao Vôo) pela oportunidade de crescer profissionalmente e
pessoalmente. Aos amigos da PED, NuATFM e principalmente ao TCel Sérgio de Barros
Pinto pela inestimável colaboração.
Ao meu co-orientador João Bosco pela colaboração.
Finalmente, ao meu orientador Dr. Tatuo pela grata convivência sempre dedicada e segura na
condução desse trabalho.
RESUMO
Esta dissertação tem por objetivo descrever um sistema de software denominado Sistema de Simulação Acelerado para Análise de Fluxo de Tráfego Aéreo, desenvolvido com o propósito de prover informações sobre a demanda futura de tráfego no espaço aéreo e nos aeródromos nacionais aos gerentes do Gerenciamento de Fluxo de Tráfego Aéreo (ATFM), de modo a permitir aos mesmos identificar, por antecipação, a ocorrência de extrapolação da capacidade dos respectivos setores de controle de tráfego aéreo, num determinado período, em um determinado dia. Este trabalho contém a descrição da atividade de Gerenciamento de Fluxo de Tráfego Aéreo (ATFM) no contexto mais amplo que é o Gerenciamento de Tráfego Aéreo (ATM), para situar o problema que foi resolvido pelo Sistema de Simulação Acelerado para Análise de Fluxo de Tráfego Aéreo desenvolvido neste trabalho. Espera-se que este trabalho possa contribuir para dotar os gerentes ATFM brasileiros de uma ferramenta efetiva de suporte à decisão no processo de análise, avaliação e solução dos problemas relacionados ao binômio Capacidade vs. Demanda de Tráfego Aéreo, no contexto do futuro Sistema de Gerenciamento de Fluxo de Tráfego Aéreo do Brasil.
ACCELERATED SIMULATION SYSTEM FOR AIR TRAFFIC FLOW ANALYSIS
ABSTRACT
This dissertation has for objective to describe a software system entitled “Accelerated Simulation System for Air Traffic Flow Analysis”. Such system was developed with the purpose of providing information about air traffic future demand in the national airspace and airports for the Air Traffic Flow Management (ATFM) managers, in order to make possible them to identify, by anticipation, the occurrence of capacity overflowing in the respective air traffic control sectors, in a given period, in a given day. This work contains the description of Air Traffic Flow Management (ATFM) activity, in the context ampler that it is the Air Traffic Management (ATM), to point out the problem that was decided by the Accelerated Simulation System for Air Traffic Flow Analysis developed in this work. It is hoped this work can contribute to provide the Brazilian ATFM managers with an effective decision support tool in the process of analysis, evaluation and solution of the problems related to the Air Traffic Capacity versus Demand, in the context of the future Brazilian Air Traffic Flow Management System.
SUMÁRIO
LISTA DE FIGURAS
LISTA DE TABELAS
LISTA DE SIGLAS E ABREVIATURAS
Pág.
CAPÍTULO 1 - INTRODUÇÃO ...................................................................................29
1.1 CONTEXTO ..................................................................................................................29
1.2 ESCOPO.......................................................................................................................30
1.3 MOTIVAÇÃO E ORIGEM ...............................................................................................31
1.4 ESPECIFICAÇÃO DOS REQUISITOS DE UM SISTEMA COMPUTADORIZADO....................35
1.5 PROPOSTA DE TESE.....................................................................................................37
1.6 SEQUENCIA DE APRESENTAÇÃO..................................................................................38
CAPÍTULO 2 - O GERENCIAMENTO DE FLUXO DE TRÁFEGO AÉREO
(ATFM) NO CONTEXTO DO GERENCIAMENTO DE TRÁFEGO AÉREO
(ATM) ..............................................................................................................................41
2.1 BREVE HISTÓRICO DO ATFM NO CONTEXTO DO IPV ................................................41
2.2 ESCOPO DO P ROBLEMA...............................................................................................45
2.2.1 SUBSISTEMA SGBD ................................................................................................45
2.2.2 SUBSISTEMA DE RECEBIMENTO E TRATAMENTO DE DADOS .................................45
2.2.3 SUBSISTEMA SUPERVISOR ........................................................................................46
2.2.4 SISTEMA DE SIMULAÇÃO ACELERADO PARA ANÁLISE DE F LUXO DE TRÁFEGO
AÉREO - MODELO 1 E MODELO 2 .....................................................................................46
2.2.5 SUBSISTEMA DE APRESENTAÇÃO GRÁFICA DE RESULTADOS DA SIMULAÇÃO -
SAS ..................................................................................................................................46
2.3 GERENCIAMENTO DE TRÁFEGO AÉREO - ATM ..........................................................47
2.4 GERENCIAMENTO DO ESPAÇO AÉREO - ASM .............................................................48
2.4.1 Atingir os Objetivos do ASM .................................................................................48
2.4.2 Considerações Sobre o Gerenciamento do Espaço Aéreo ......................................49
2.4.3 Considerações Sobre o Espaço Aéreo Brasileiro ....................................................50
2.4.4 CLASSIFICAÇÃO DO ESPAÇO AÉREO BRASILEIRO ....................................................53
2.4.4.1 Regiões de Informações de Vôo - FIR ................................................................53
2.4.4.2 Espaços Aéreos Controlados ...............................................................................53
2.4.4.3 Espaços Aéreos Condicionados ...........................................................................54
2.4.4.4 O Serviço de Tráfego Aéreo ................................................................................54
2.4.4.5 Estrutura do Serviço de Tráfego Aéreos..............................................................54
2.5 GERENCIAMENTO DE F LUXO DE TRÁFEGO AÉREO - ATFM.......................................56
2.5.1 Princípio do Gerenciamernto de Fluxo de Tráfego Aéreo ......................................56
2.5.2 Objetivo do Gerenciamernto de Fluxo de Tráfego Aéreo ......................................60
2.5.3 Causas Principais dos Congestionamentos de Tráfego Aéreo ................................61
2.5.4 Considerações Sobre o Controle de Fluxo ..............................................................62
2.5.5 Vôos que Deveriam Ficar Isentos das Medidas de Controle de Fluxo ...................63
2.5.6 O Serviço ATFM e suas atribuições nas Funções Estratégica e Tática ..................63
2.5.7 Medidas de Gerenciamernto de Fluxo de Tráfego Aéreo .......................................66
2.5.8 O Gerenciamento de Fluxo de Tráfego Aéreo no Brasil, Estados Unidos e
Europa......... ............................................................................................................67
2.5.8.1 O Gerenciamernto de Fluxo de Tráfego Aéreo nos Estados Unidos ...................69
2.5.8.2 O Gerenciamernto de Fluxo de Tráfego Aéreo na Europa ..................................70
2.6 CENÁRIO DESEJADO ...................................................................................................72
2.7 SITUAÇÃO ESPECIFICA ................................................................................................73
CAPÍTULO 3 - O MODELO DE CINEMÁTICA DOS SIMULADORES ATC ........75
3.1 INTRODUÇÃO ..............................................................................................................75
3.2 CONSIDERAÇÃO SOBRE O MOVIMENTO DA AERONA VE ................................................78
3.2.1 Cálculo da Velocidade ............................................................................................78
3.2.2 Cálculo de Posição da Aeronave ............................................................................79
3.2.3 Cálculo de Proa .......................................................................................................80
3.2.4 Cálculo de Altitude .................................................................................................80
3.2.5 Cálculo de Interceptação de Baliza .........................................................................81
3.3 CONSIDERAÇÕES FINAIS .............................................................................................81
CAPÍTULO 4 - OS PROCEDIMENTOS AUTOMÁTICOS UTILIZADOS NOS
SIMULADORES DE CONTROLE DE TRÁFEGO AÉREO ........................................83
4.1 Descrição Geral .........................................................................................................83
4.2 Procedimento de Decolagem / Subida .......................................................................86
4.3 Procedimento de Trajetória ........................................................................................87
4.4 Procedimento de Espera ............................................................................................88
4.5 Procedimento de Pouso ..............................................................................................90
CAPÍTULO 5- ESTRUTURAS (EM MEMÓRIA) DE SUPORTE A SIMULAÇÃO ....95
5.1 DESCRIÇÃO GERAL ......................................................................................................95
5.1.1 Modelando o Vôo ...................................................................................................95
5.2 Estrutura de Pontos Característicos ...........................................................................98
5.3 Estrutura de Plano de Vôo .......................................................................................100
5.4 Estrutura de Aeronaves ............................................................................................103
5.5 Estrutura de Aeroportos ...........................................................................................106
5.6 Estrutura de Setores .................................................................................................107
5.7 Estrutura de Eventos (Aeroportos, Fixos e Setores (FIR, TMA e CTR) .................108
5.8 CONSIDERAÇÕES FINAIS ...........................................................................................110
CAPÍTULO 6 - ESPECIFICAÇÃO DO PROTÓTIPO DO SISTEMA DE
SIMULAÇÃO ACELERADO PARA ANÁLISE DE FLUXO DE TRÁFEGO
AÉREO (MODELO 1) NO CONTEXTO DO SISTEMA ATFM ................................111
6.1 PRINCIPAIS ASPECTOS DO PROTÓTIPO ........................................................................111
6.2 REQUISITOS DO PROTÓTIPO .......................................................................................112
6.3 AMBIENTE E PLATAFORMA DE DESENVOLVI MENTO ...................................................116
6.4 ARQUITETURA DO SOFTW ARE....................................................................................117
6.4.1 Subsistema de Recebimento e Tratamento de Dados ...........................................117
6.4.2 Subsistema SGBD - Gerenciador da Base de Dados ATFM ................................121
6.4.2.1 Aspectos Gerais do Subsistema SGBD .............................................................122
6.4.2.1.1 Apresentação das Interfaces dos Arquivos do Subsistema SGBD .................123
6.4.2.2 Menu Principal...................................................................................................124
6.4.2.3 Opções do Menu Principal.................................................................................124
6.4.2.4 Opção Aeródromos ............................................................................................125
6.4.2.5 Opção Aeronaves ...............................................................................................126
6.4.2.6 Opção Aerovias .................................................................................................127
6.4.2.7 Opção Operação Adicionar - Opção Aerovias ..................................................128
6.4.2.8 Opção Caminhos Diretos ...................................................................................129
6.4.2.9 Opção Companhias Aéreas ................................................................................130
6.4.2.10 Opção Corredores ............................................................................................131
6.4.2.11 Opção FIR ........................................................................................................132
6.4.2.12 Opção Pontos Característicos ..........................................................................133
6.4.2.13 Opção TMA .....................................................................................................134
6.4.2.14 Opção Planos de Vôos .....................................................................................135
6.4.2.15 Opção Consulta de Trajetória ..........................................................................136
6.4.2.16 Opção Consulta de Tráfegos............................................................................139
6.4.2.17 Opção Atualização de RPL..............................................................................141
6.4.2.18 Opção Atualização de Trajetórias....................................................................141
6.4.2.19 Opção Atualização de Tráfegos/PLN (Plano de Vôo).....................................142
6.4.2.20 Opção Usuário .................................................................................................143
6.4.2.21 Opção Windows ...............................................................................................144
6.4.2.22 Processo de Conversão e Armazenamento dos Dados ATFM ........................145
6.4.2.23 Processo de Geração dos Arquivos de Planos de Vôos e Tráfegos .................145
6.4.3 Subsistema Supervisor ..........................................................................................150
6.4.3.1 Consideração Sobre a Conversão ......................................................................151
6.4.3.2 Composição da Tela do Supervisor ...................................................................153
6.4.3.2.1 Parâmetros do Sistema ....................................................................................154
6.4.3.2.2 Menu de Opções .............................................................................................155
6.4.3.2.3 Área de Apresentação de Tempo de Simulação .............................................155
6.4.3.2.4 Área de Mensagens .........................................................................................155
6.4.4 Sistema de Simulação Acelerado para Análise de Fluxo de Tráfego Aéreo
(Modelo 1) .....................................................................................................................156
6.4.4.1 Evolução das Aeronaves em suas Trajetórias....................................................157
6.4.4.1.1 Descrição dos Atributos do Arquivo de Trajetória .........................................160
6.4.4.2 Processo de Evolução das Aeronaves ................................................................161
6.4.4.2.1 Adaptação da Fase de Decolagem para o Protótipo .......................................162
6.4.4.2.2 Fase de Subida ................................................................................................163
6.4.4.2.3 Fase de Trajetória ...........................................................................................164
6.4.4.2.4 Fase de Pouso .................................................................................................165
6.4.4.3 Processo de Contabilização eTransferência de Aeronaves entre Setores ..........168
6.4.4.3.1 Fase de Decolagem e Subida ..........................................................................168
6.4.4.3.2 Fase de Trajetória ...........................................................................................169
6.4.4.3.3 Fase de Pouso .................................................................................................169
6.4.4.4 Consideração sobre os Vô os que Entram e Saem do Brasil ..............................170
6.4.4.5 Tempo Total de Processamento deste Modelo ..................................................173
6.4.4.6 Lógica do Módulo Principal do Sistema de Simulação Acelerado para
Análise de Fluxo de Tráfego Aéreo - Modelo 1 ............................................................174
6.4.5 Subsistema de Apresentação Gráfica de Resultado da Simulação ou Sistema
de Análise de Situação - SAS ........................................................................................175
6.4.5.1 Operação Básica do Subsistema SAS ................................................................176
6.4.5.2 Considerações Gerais Sobre a Montagem do Gráfico .......................................180
6.4.5.3 Tipos de Relatórios Gerados pelo SAS .............................................................182
6.4.5.3.1 Relatório de Eventos .......................................................................................184
6.4.5.3.2 Relatório de Alerta ..........................................................................................185
6.4.5.4 Considerações Finais Sobre o SAS ....................................................................186
6.5 ARQUITETURA DO HARDW ARE ..................................................................................186
6.5.1 Descrição do Modelo de Rede ..............................................................................187
6.5.2 Descrição do Servidor de Banco de Dados ATFM ..............................................188
6.5.3 Descrição do Servidor de Processos .....................................................................189
CAPÍTULO 7 - SISTEMA DE SIMULAÇÃO ACELERADO PARA ANÁLISE
DE FLUXO DE TRAFEGO AÉREO (MODELO 2) ....................................................191
7.1 Considerações Gerais ...............................................................................................191
7.2 Modelo de Evolução de Aeronaves (cinemática) Adaptado para o Modelo 2 ........193
7.2.1 Considerações Específicas Sobre o Modelo 1 ......................................................193
7.2.2 Considerações Específicas Sobre o Modelo 2 ......................................................195
7.2.2.1 Fórmula para Cálculo da Distância Linear ........................................................198
7.2.2.2 Considerações Sobre o Processo de Transferência de Setores na Vertical .......198
7.3 Resultados Obtidos ..................................................................................................201
7.3.1 Diagrama de Estrutura do Modelo 2 .....................................................................203
7.3.2 Lógica do Módulo Principal do Sistema de Simulação Acelerado para Análise
de Fluxo de Tráfego Aéreo - Modelo 2 .........................................................................204
7.3.3 Estrutura das Tabelas Vôo e Eventos do Modelo 2 ..............................................205
CAPÍTULO 8 - CONCLUSÃO ....................................................................................207
REFERÊNCIAS BIBLIOGRÁFICAS ..........................................................................213
APÊNDICE A APRESENTA O FLUXOGRAMA ATFM .......................................215
APÊNDICE B DIAGRAMA DO SISTEMA ATFM .................................................219
APÊNDICE C PSEUDOCÓDIGOS DOS MÓDULOS DO SISTEMA DE
SIMULAÇÃO ACELERADO PARA ANÁLISE DE FLUXO DE TRÁFEGO
AÉREO (Modelo 1) .......................................................................................................223
APÊNDICE D PSEUDOCÓDIGOS DOS MÓDULOS DO SISTEMA DE
SIMULAÇÃO ACELERADO PARA ANÁLISE DE FLUXO DE TRÁFEGO
AÉREO (Modelo 2) .......................................................................................................235
GLOSSÁRIOS ...............................................................................................................249
LISTA DE FIGURAS
Pág. 2.1 Arquitetura do Sistema ATFM ................................................................................. 44
2.2 ATM – Gerenciamento de Tráfego Aéreo ................................................................ 47
2.3 Região de Informação de Vôo (FIR) ........................................................................ 50
2.4 Malha de aerovias nacionais e internacionais............................................................51
2.5 Operadores recebendo ligações das companhias aéreas e da aviação geral ..............59
2.6 Operadores recebendo ligações das companhias aéreas e da aviação geral ..............59
2.7 Crescimento de demanda nos aeroportos de Congonhas, Internacional de
São Paulo/ Guarulhos e Marte ...................................................................................68
3.1 Ambiente e Controle de Torre (TWR).......................................................................77
3.2 Ambiente e Controle Radar (APP e ACC) ................................................................77
4.1 Aeronave detectada pelo Sinal do Radar ...................................................................85
4.2 Representação Gráfica 2D da Conole Radar .............................................................85
4.3 fases dos Procedimentos de Decolagem/Subida ........................................................87
4.4 Etapas que compõem o procedimento de Espera ......................................................88
4.5 Maneiras de realizar o procedimento de Espera ........................................................89
4.6 Condições limitantes de curva ...................................................................................91
4.7 Fases do procedimento de Pouso ...............................................................................94
5.1 Crescimento de demanda nos aeroportos de Congonhas, Internacional de São
Paulo/ Guarulhos e Marte ..........................................................................................97
5.2 Representação de Setores ..........................................................................................99
6.1 Representação gráfica da demanda de um determinado setorar..............................114
6.2 Estrutura física (hardware) do subsistema de inclusão de Planos de Vôos e
de Tratamento de Erros............................................................................................120
6.3 Menu Principal do Subsistema SGBD.....................................................................124
6.4 Janela Aeródromos ..................................................................................................126
6.5 Janela Aeronaves .....................................................................................................127
6.6 Janela Aerovias ........................................................................................................128
6.7 Janela de Inclusão de novos pontos na Aerovia ......................................................129
6.8 Janela Caminhos Diretos .........................................................................................130
6.9 Janela Companhia Aéreas ........................................................................................131
6.10 Janela Corredores...................................................................................................132
6.11 Janela FIR/ Setores ................................................................................................133
6.12 Janela Pontos Característicos.................................................................................134
6.13 Janela TMA / Setores.............................................................................................135
6.14 Janela Planos de Vôos ...........................................................................................136
6.15 Janela da opção de Consulta de Trajetórias ...........................................................138
6.16 Janela da opção de Consulta de Tráfegos ..............................................................140
6.17 Janela da opção Atualização do RPL.....................................................................141
6.18 Janela da opção Atualização de Trajetória ............................................................142
6.19 Janela da opção Atualização de Tráfegos/PLN .....................................................143
6.20 Janela da opção Usuário .......................................................................................143
6.21 Janela de confirmação de finalização de Processamento ......................................144
6.22 Visão geral processos de Atualização dos vôos ....................................................148
6.23 Visão geral dos demais processos de Atualização dos vôos..................................149
6.24 Janela de entrada de dados a serem simulados ......................................................153
6.24-a Parâmetros do Sistema – Janela Supervisor ......................................................154
6.24-b Opções e Informações – Janela Supervisor .......................................................155
6.25 Vôo num espaço aéreo fictício ..............................................................................158
6.26 Arquivo de Trajetória ............................................................................................159
6.27 Evolução de uma aeronave nas diversas fases do vôo...........................................163
6.27-a Demonstração do Ponto Ideal de Aproximação (Pouso) ...................................166
6.27-b Fase de Decolagem e Subida .............................................................................168
6.27-c Fase de Trajetória ..............................................................................................169
6.27-d Fase de Pouso ....................................................................................................171
6.27-e Exemplo de Vôo do tipo DCT...........................................................................172
6.27-f Concepção Física do SAS ..................................................................................176
6.28 Tela Principal SAS ................................................................................................177
6.29 Selecionando a Região do Brasil ...........................................................................178
6.30 Selecionando o Setor da Região ............................................................................179
6.31 Apresentação Gráfica do Setor ..............................................................................181
6.32 Preparação para gerar a impressão do Gráfico do Setor ........................................182
6.33 Impressão Gráfica do Setor ...................................................................................183
6.34 Relatório de Eventos ..............................................................................................184
6.35 Relatório de Alerta.................................................................................................185
6.36 Arquitetura do Simulador ......................................................................................188
7.1 Mudança de Setor na Vertical..................................................................................200
7.2 Diagrama de Estrutura do Modelo 2........................................................................203
A.1 Fluxograma ATFM .................................................................................................217
B.1 DFD do Sistema ATFM..........................................................................................221
LISTA DE TABELAS
Pág.
5.1 Ponto Característico on line ..................................................................................... 99
5.2 Exemplo de dados de Ponto Característico ........................................................... 100
5.3 Estrutura de Plano de Vôo on line ...........................................................................101
5.4 Estrutura de Plano de Vôo/Breakpoint ....................................................................102
5.5 Estrutura da Tabela de Plano de Vôo ......................................................................102
5.6 Exemplo de dados da Estrutura de Plano de Vôo ....................................................102
5.7 Estrutura de Aeronaves on line ................................................................................105
5.8 Estrutura da Tabela Eventos de Tráfego ..................................................................106
5.9 Estrutura de Aeroportos on line ...............................................................................106
5.10 Estrutura de Setores on line ...................................................................................107
5.11 Estrutura da Tabela de Setores ..............................................................................107
5.12 Estrutura de Eventos on line ..................................................................................109
5.13 Estrutura da tabela Eventos ...................................................................................110
7.1 Estrutura da tabela Vôo ...........................................................................................205
7.2 Estrutura da tabela Evento .......................................................................................205
LISTA DE SIGLAS E ABREVIATURAS
ACC Centro de Controle de Área
ACC-BS Centro de Controle de Área de Brasília
ACC-CW Centro de Controle de Área de Curitiba
ATC Air Traffic Control
AIS Aeronautical Information Service
APP Centro de Controle de Aproximação
ARTCCs Air Route Traffic Control Centers
ASM Airspace Management
ATC Air Traffic Control
ATCO Controlador de Tráfego Aéreo
ATCSCC Air Traffic Control System Command Center
ATFM Air Traffic Flow Management
ATFM-C Air Traffic Flow Management Center
ATM Air Traffic Management ATS Air Traffic Services ATZ Air Traffic Zone CAR/SAM Região ICAO que compreende Caribe e América do Sul CARF Central Altitude Reservation Function CDM Collaborative Decision Making CFMU Central Flow Management Unit CINDACTA Centro Integrado de Defesa Aérea de Controle de Tráfego Aéreo
CNS Communication/Navigation/Surveillance CPVR Centro de Planos de Vôos Repetitivos do CINDACTA I CTR Control Traffic Zone DAC Departamento de Aviação Civil DCT Vôo Direto DEPV Diretoria de Eletrônica e Proteção ao Vôo DE Diagrama de Estruturas DER Diagrama de Entidade e Relacionamento DFD Diagrama de Fluxo de Dados EAC Espaço Aéreo Condicionado EATMS European Air Traffic Management System ECAC European Civil Aviation Conference EDCT Estimated Departure Clearance Time ETA Estimate Time of Arrival ETE Estimated en rout time ETMS Enhanced Traffic Management System EUROCONTROL European Organization for the Safety of Air Navigation FAA Federal Aviation Administration FANS Comitê sobre Sistemas Futuros de Navegação Aérea FIR Flight Information Region FL Flight Level FMP Posição de Gerenciamento de Fluxo FPL Plano de Vôo Apresentado
FSM Flight Schedule Monitor FT pés GDP Ground Delay Programs GDPE Ground Delay Program Enhancements HOTRAC Horário de Transporte Aéreo Comercial HOTREG Horário de Transporte Regular HOTRAN Horário de Transporte Aéreo IATA International Association Transport Air ICA Instituto de Cartografia Aeronáutica ICAO International Civil Aviation Organization IFPS Integrated Flight Plan Processing System IPV Instituto de Proteção Ao Vôo MAer Ministério da Aeronáutica Mix Tráfego Conjunto de tráfegos de diferentes performance NDB Sinal Transmitido não direcional que é recebido pela aeronave NOTAMs Notice to Airmen NuATFM Núcleo de Gerenciamento de Fluxo de Tráfego Aéreo PAN ROTAS Informação relativas aos vôos comerciais (publicações impressas ou meio digital) QDM Marcação Magnética – Linha que leva à antena transmissora do NDB RPL Plano de Vôo Repetitivo SAS Sistema de Análise de Situação SBGR Aeroporto Internacional de São Paulo - Guarulhos
SBSP Aeroporto de Congonhas - São Paulo SBXP TMA de São Paulo SGBD Sistema de Gerenciamento da Base de Dados ATFM SIASA Sistema de Alocação de Slot de Aeroporto SICONFAC Sistema de Controle e Fiscalização de Aviação Civil SISCEAB Sistema de Controle do Espaço Aéreo Brasileiro SRPV-SP Serviço Regional de Proteção ao Vôo TACT Tactical Computer System (CFMU) TMA Terminal Control Area (ICAO) TMA-SP Terminal Control Area de São Paulo TWR Torre de Controle de Aeródromo
29
CAPÍTULO 1
INTRODUÇÃO
1.1 Contexto:
O Sistema de Controle do Espaço Aéreo Brasileiro (SISCEAB) foi estabelecido no
Comando da Aeronáutica em 1990, com a finalidade de consolidar, formalmente, a
integração dos sistemas de proteção ao vôo, de telecomunicações e de defesa e controle
de tráfego aéreo, sendo um dos seus objetivos principais proporcionar condições
seguras e eficientes para a circulação no espaço aéreo sob a responsabilidade do Brasil.
O SISCEAB vem sofrendo, ao longo dos anos, uma necessidade premente na busca de
qualidade dos serviços prestados à aviação no âmbito do território nacional. A
modernização dos equipamentos de infra-estrutura e a valorização dos recursos
humanos têm sido o objetivo das autoridades de proteção ao vôo.
O Brasil, como ocorre em outros países desenvolvidos, por possuir uma das maiores
frotas de aeronaves do mundo, vem sentindo a responsabilidade de garantir a segurança,
rapidez e economia no transporte aéreo e, para isso, conta com núcleos de pesquisas
voltados para a melhoria das condições de atendimento ao serviço de transporte aéreo, o
qual representa uma parcela significativa de economia do país e para o conforto para os
seus usuários, os passageiros, que se beneficiam tanto para a realização de viagens
profissionais como no turismo e lazer.
A falta de flexibilidade relacionada à atual estrutura de rotas do Serviço de Tráfego
Aéreo (ATS) impedem o uso mais eficiente do espaço aéreo e a realização de operações
aéreas mais econômicas. As deficiências dos atuais Sistemas de Comunicação,
Navegação e Vigilância (CNS), assim como a falta de um desenvolvimento harmônico,
também são considerados como fatores contribuintes para a degradação do atual
sistema.
O nível limitado de planejamento cooperativo tem proporcionado, entre outras coisas, a
duplicação de instalações através de fronteiras nacionais, o compartilhamento deficiente
30
dos dados enviados pelos radares, a aplicação de distintos mínimos de
separação(distância horizontal de 5 Milhas Náuticas entre aeronaves), a existência de
procedimentos diferenciados para coordenação ATC e a utilização de diferentes sistema
de níveis de cruzeiro. Estas deficiências podem apresentar, como resultados, atrasos
para o direcionamento do tráfego aéreo, que afetam negativamente a regularidade e a
economia dos vôos.
A fim de ajustar-se ao crescimento do tráfego aéreo, deve-se estabelecer um plano
apropriado para o Gerenciamento do Tráfego Aéreo (ATM) destinado a otimizar a
utilização do espaço aéreo e manter um fluxo ordenado do tráfego aéreo.
A Diretoria de Eletrônica e Proteção ao Vôo (DEPV), é um órgão do Comando da
Aeronáutica que é responsável pelo Controle de Tráfego Aéreo em todo território
nacional. Para a execução dos objetivos que lhe são pertinentes, cabe-o prevenir as
colisões de aeronaves, bem como manter ordenado o fluxo de aeronaves em todo espaço
aéreo brasileiro.
O Gerenciamento de Fluxo de Tráfego Aéreo (ATFM), é um dos seguimentos da
Gerência de Tráfego Aéreo que visa a complementar o Serviço de Controle de Tráfego
Aéreo, estabelecido com a finalidade de assegurar um ótimo fluxo de tráfego aéreo em
áreas onde a demanda de movimentos aéreos, por vezes, excede a capacidade do espaço
aéreo ou ultrapassam os limites do Sistema de Controle de Tráfego Aéreo Instalado.
Nesse contexto, o ATFM tornou-se um serviço preciosíssimo para estabelecer de modo
antecipado o controle e o equilíbrio de regiões do espaço aéreo brasileiro, onde o
volume de tráfego aéreo muitas vezes excede a capacidade instalada.
1.2 Escopo:
Este trabalho de pesquisa pretende abordar especificamente o que é o Gerenciamento de
Fluxo de Tráfego Aéreo principalmente no Brasil, quais as dificuldades que os gerentes
ATFM encontram para realizarem seus trabalhos, quais são as ferramentas disponíveis
no mercado mundial e por fim o que pretende o protótipo do Sistema de Simulação
31
Acelerado para Análise de Fluxo de Tráfego Aéreo, denominado como uma ferramenta
de Análise de Fluxo Aéreo para auxiliar o trabalho dos gerentes ATFM.
1.3 Motivação e Origem:
Após um declínio nos anos de 1992 e 1993, a partir de 1994 o movimento aéreo no
Brasil teve um substancial aumento, superando todas as expectativas e previsões
existentes, gerando problemas de fluxo de tráfego em algumas regiões, particularmente
naquelas que detêm grandes pólos industriais e turísticos. Este aumento afetou
diretamente a capacidade dos órgãos de Controle de Tráfego Aéreo (ATC) de
desempenhar suas funções.
O incremento verificado no movimento aéreo concentrou-se, em maior volume, no
polígono compreendido pelas cidades de Brasília, Belo Horizonte, Rio de Janeiro, São
Paulo, Curitiba e Porto Alegre.
Entretanto, o maior impacto ocorreu nas operações envolvendo o aeroporto de
“Congonhas - SP”, cuja demanda excessiva do tráfego aéreo em determinados horários,
sobrecarregava o atual sistema de Controle de Aeródromo como também em
determinados setores de controle aéreo da Área de Gerenciamento da Terminal de São
Paulo (TMA-SP) e Regiões de Informação de Vôo (FIR) adjacentes (Brasil, 1999b).
Para manter a segurança das operações, a razão de aceitação do aeródromo é mantida
em valores abaixo da capacidade das pistas, ocasionando número menor de “Slots” de
tempo disponibilizados no período.
A ausência de mecanismos adequados que permitam planejar o controle do movimento
de tráfego aéreo, está entre os principais fatores contribuintes para a ocorrência dessa
situação.
O crescimento da “Aviação Geral e Executiva” e, os vôos surgidos com as novas linhas
regionais para o aeroporto de Congonhas-SP e os vôos internacionais para o aeroporto
de Guarulhos-SP, provocaram um aumento significativo no movimento de tráfegos,
com grande diversidade de categorias de aeronaves e performances variadas.
32
A capacidade de navegação das modernas aeronaves não é plenamente utilizada pelo
ATC, com isso, as aeronaves não podem usufruir das facilidades aviônica disponível,
como conseqüência, a utilização da capacidade aeroportuária atingiu valores
relativamente elevados.
Esses fatores produziram, como conseqüências, esperas excessivas nas saídas e
chegadas para os aeroportos da Área de Controle Terminal de São Paulo(SBXP),
aumento nos tempos dos vôos devido a longas esperas em órbita, excessivo aumento da
carga de trabalho dos controladores que atuam no Controle Radar de Brasília e Curitiba
(ACC BS e ACC CW), Área de Controle de Aproximação Radar de São Paulo(APP SP)
e Controle de Aeródromo de São Paulo (TWR SP), reclamação de companhias de
aviação e insatisfação de passageiros, com seguidas reportagens na mídia local e
nacional (Brasil, 1999b).
A aplicação de medidas restritivas como o Slot de Tempo para o aeroporto de
Congonhas, como ação emergencial, reduziu a carga de trabalho dos controladores e
minimizou os problemas anteriormente descritos. Entretanto, observa-se que existe uma
demanda reprimida para a região devido aos constantes pedidos de novas linhas
sazonais e permanentes, bem como às inúmeras solicitações de vôos da Aviação Geral.
O não atendimento dessas solicitações, embora em pequenas proporções, vem gerando
insatisfação de alguns operadores e exploradores de aeronaves, principalmente devido
ao número de operações de pouso e decolagem ter sido limitado a 35 aeronaves por
período de 60 minutos, assim definido em função da capacidade dos órgãos ATC, da
configuração do Gerenciamento de Área Terminal (TMA) e do MIX de tráfego, em um
ambiente de operação em condições de vôo por instrumento.
Em outros aeródromos brasileiros, a situação vem se configurando de forma semelhante
ao sucedido em Congonhas. Verificam-se, também, impactos decorrentes de movimento
atípico, associado, a grandes eventos comerciais, culturais, esportivos, folclóricos,
religiosos, turísticos etc. Esses movimentos mais intensos vêm interferindo, de forma
marcante, na prestação do serviço de tráfego aéreo, ocasionando inclusive a adoção de
33
medidas unilaterais de controle de fluxo, com predominância de restrições nas
decolagens de aeronaves.
Em meados do ano de 1997 foi concluída a concepção operacional do Centro de
Gerenciamento de Fluxo de Tráfego Aéreo (ATFM-C), do Brasil. Para tanto, vários
ensaios foram realizados, incluindo simulação em tempo real, buscando aprimorar o
modelo e estabelecer requisitos e critérios consistentes com o cenário desejado, o qual
reflete os objetivos do ATFM em suas funções estratégicas e táticas.
Com muita cautela foram conduzidos testes reais, por ocasião do “Carnaval” e da
“Semana Santa”, no 1° trimestre de 1997. Verificou-se que medidas relativamente
tímidas de gerenciamento de fluxo de tráfego aéreo podem resultar em benefícios
mensuráveis para a circulação aérea nacional.
Particularmente compensador foi o fato de que, em ambos eventos, não ter ocorrido um
único incidente de tráfego aéreo, apesar do intenso movimento de aeronaves.
Em seguida, estabeleceu-se o Núcleo do Gerenciamento de Fluxo de Tráfego Aéreo
(NuATFM), nas instalações do Instituto de Proteção ao Vôo (IPV), órgão do Comando
da Aeronáutica subordinado à Diretoria de Eletrônica e Proteção ao Vôo (DEPV) e
sediado na cidade de São José dos Campos - SP. Entre os fatores determinantes para a
escolha desse local está a existência de privilegiadas facilidades para condução de
estudos e projetos, no IPV, que certamente serão fundamentais para consolidação do
ATFM brasileiro.
Os desenvolvimento futuros do Gerenciamento de Fluxo de Tráfego Aéreo, no Brasil,
estão centrados em duas grandes áreas:
A função estratégicas de ATFM deverá estender-se para além das fronteiras
brasileiras, integrando-se às ações regionais relativas ao tema, isto é, na América do Sul
e Caribe, bem como, interligando-se o Centro de Gerenciamento de Fluxo de Tráfego
Aéreo do Brasil com suas congêneres na Europa (CFMU) e nos Estados Unidos da
América (ATCSCC); e
34
A função tática de ATFM deverá ser executada com mais qualidade mediante a
instalação de sistemas de sequenc iamento automático de aeronaves em área de controle
de terminal, nas áreas de maior volume de tráfego.
Adicionalmente, todos esses desenvolvimentos serão apoiados e fundamentados nos
resultados advindos dos ensaios conduzidos no Centro de Simulação em São José dos
Campos - SP, contando com ferramentas de modelagem e capacidade de simulação em
tempo real de todo o sistema, no afã de estabelecer o Centro de ATFM de maneira
oportuna e adequada a todos os usuários.
Em função da atual situação insustentável que passa os aeroportos da região sudeste do
país, o NuATFM tem por objetivo imediato, emitir um parecer favorável ou não das
solicitações advindas das companhias aéreas para inclusão de novas linhas aéreas.
Para analisar esses novos pedidos, o NuATFM, necessita de ferramentas de apoio a
decisão para cumprir sua tarefa de concessão ou não de novas linhas aéreas, como
também, emitir um parecer aos órgãos ATC, quando ocorrer extrapolação na capacidade
de setores de uma determinada região do país.
Como resposta a essas solicitações ficou a seguinte pergunta no ar: As ferramentas de
apoio a decisão (Banco de Dados para manipulação e concessão de novas linhas aéreas
e o Simulador para verificação de desbalanceamento de setores) devemos Comprar ou
Desenvolver ?
Por se tratar de um produto especifico, os simuladores geralmente são produzidos por
demanda, isto provoca:
a) Custo bastante elevado para adquiri- lo;
b) Dependência em relação à manutenção;
c) Possíveis modificações no produto original, para atender as necessidades dos
usuários;
d) Inibição para o desenvolvimento de simuladores similares nacionais.
35
Assim sendo, o NuATFM propôs o desenvolvimento de um simulador de tráfego aéreo
voltado a atender as necessidades dos gerentes ATFM, o qual fornecerá um relatório
completo em questão de minutos ou em poucas horas do que irá ocorrer com o espaço
aéreo e os aeroportos brasileiros obedecendo os seguintes tópicos:
a) Elaboração da situação aérea de uma região num determinado intervalo de
tempo no mesmo dia;
b) Elaboração da situação aérea de uma região num determinado intervalo de
tempo num determinado dia;
c) Elaboração da situação aérea de uma região das próximas 24 horas;
d) Elaboração da situação aérea de uma região das próximas 24 horas num
determinado dia;
e) Elaboração da situação aérea de uma região de um período (data inicial e data
final).
Desta maneira, este trabalho pretende contribuir com uma ferramenta de simulação de
tráfego aéreo para os gerentes ATFM desenvolvida a um custo bastante reduzido, e
proporcionando uma maior adequação à realidade local.
1.4 Especificações dos Requisitos de um Sistema Computadorizado:
No Brasil, a formação dos controladores de tráfego aéreo está sob a responsabilidade
do Comando da Aeronáutica, mas diretamente a DEPV, o qual delega essa tarefa ao
IPV, que tem a missão de formar profissionais nos diversos ramos da proteção ao vôo,
como também, a escola de especialistas da aeronáutica na cidade de Guaratinguetá - SP.
Estes centros de ensino basicamente procuram formar profissionais na área de controle
de tráfego aéreo voltados ao Controle de Aeródromo (TWR), Controle de Aproximação
Radar (APP) e o Controle de Área (ACC).
O Gerenciamento de Fluxo de Tráfego Aéreo, é um termo relativamente novo, toda a
definição dos conceitos empregados pelo ATFM, foram formalizados em meados da
década de 80 pela comissão da Organização de Aviação Civil Internacional (ICAO),
36
que trata do controle de tráfego aéreo. No Brasil, este assunto veio a ser discutido
quando o aeroporto de Congonhas – SP, começou a dar os primeiros sinais de
estrangulamento em determinados horários do dia no início de 1994 (Brasil, 1999b).
Hoje, a ATFM é uma realidade para os especialistas de tráfego aéreo brasileiro, mas
nem todos podem exercer a atividade gerencial. Aqueles que detém algum
conhecimento, foi devido a cursos realizados nos Estados Unidos ou na Europa.
Assim sendo, as autoridades brasileiras (DEPV, DAC e Companhias Aéreas)
propuseram um amplo estudo/debate sobre quais medidas preventivas deveriam ser
tomadas a curto e médio prazo para solucionar este grave problema. Foi então que
surgiu a idéia de gerenciar o fluxo de tráfego aéreo a principio tentando-se antecipar ao
problema, isto é, as companhias aéreas procuravam reescalonar seus horários de vôos e
os órgãos de controle de tráfego aéreo, procurariam disponibilizar de maneira otimizada
seus serviços de modo que, todos, pudessem voar em horários preestabelecidos, em
segurança e de modo ininterrupto.
As ferramentas a serem desenvolvidas permitiriam aos gerentes ATFM, obterem as
seguintes informações:
a) Os vôos que decolam e pousam em todos os aeroportos do Brasil ;
b) As chegadas e partidas de vôos internacionais ;
c) A quantidade de aeronaves num determinado aeroporto ;
d) A quantidade de aeronaves numa determinada região (setores) do espaço aéreo ;
e) Dar parecer favorável ou não a solicitação de inclusão de um novo vôo ; e
f) Obter relatórios estatísticos de vôos num determinado dia.
Portanto, o desenvolvimento do Banco de Dados ATFM e a elaboração de uma
ferramenta de Análise de Situação (simulador) propiciará aos gerentes ATFM, um
ganho considerável na análise dos vôos de todas as regiões do país, bem como
identificar as possíveis situações de desbalanceamento na capacidade dos setores.
37
1.5 Proposta de Tese:
O problema que direciona esta pesquisa, consiste em:
Disponibilizar ao Instituto de Proteção ao Vôo, mais diretamente ao Núcleo de
Gerenciamento de Fluxo de Tráfego Aéreo, em São José dos Campos – SP, uma
ferramenta de apoio aos gerentes ATFM, de modo que eles possam analisar a
capacidade vs. demanda do fluxo de tráfego aéreo em qualquer porção do espaço aéreo
e dos aeródromos brasileiros de maneira a antecipar a solução do problema.
Como citado em tópicos anteriores, o NuATFM tem como objetivo principal apoiar os
órgãos ATC no sentido de alertá-los sobre a possibilidade de “Congestionamento ou
Saturação” de aeronaves em determinados setores do espaço aéreo e dos aeródromos
num determinado período do dia ou de uma data futura. Paralelamente, o NuATFM
gerenciará a concessão ou não de novas linhas aéreas para as companhias aéreas
nacionais e internacionais.
Antes de iniciar este trabalho de pesquisa, os gerentes ATFM desempenhavam suas
atividades, inicialmente, relacionando e organizando os dados de fluxo de tráfego aéreo
em extensas planilhas de vôos de forma “manual”. Ao ser confeccionada a planilha
dava-se início a longa atividade de analisar as ocorrências de extrapolação na
capacidade dos setores do espaço aéreo e dos aeródromos.
O modo de tratamento rudimentar dos dados e o alto volume de informações a serem
analisadas eram prejudicados pela ausência de uma ferramenta adequada de análise de
fluxo. Além de executar um trabalho cansativo e demorado, os gerentes, geralmente,
não conseguiam em tempo adequado emitir um parecer “conclusivo” da situação do
espaço aéreo bem como dos aeródromos.
Para contribuir com a solução do problema, esse trabalho propõe-se, primeiramente,
desenvolver um protótipo de um sistema de simulação de tráfego aéreo denominado
“Sistema de Simulação Acelerado para Análise de Fluxo de Tráfego Aéreo”. Este
sistema apresentará aos gerentes ATFM as possíveis ocorrências de extrapolação na
capacidade dos setores do espaço aéreo e dos aeródromos nacionais de modo
38
antecipado, prevenindo-os do problema. Espera-se que esta dissertação sirva como
referência para suprir uma necessidade documental acadêmico/científico deste protótipo
ao Instituto de Proteção ao Vôo.
1.6 Seqüência de Apresentação:
A seguir são apresentados os 8 capítulos que compõe essa dissertação.
Este Capítulo descreve de modo sucinto o contexto desse trabalho, o escopo, a
motivação e origem, as especificações dos requisitos de um sistema computadorizados,
a proposta de tese que tem o objetivo de apresentar uma solução ao problema descrito, e
por fim apresentaremos a descrição dos demais capítulos.
No Capítulo 2, procurou-se de forma abrangente, descrever as principais partes do
universo do controle de tráfego aéreo, visando hierarquicamente chegar até a ATFM,
que é a porção chave de pesquisa desta dissertação. Em seguida será abordado o
cenário desejado e a situação específica.
O Capítulo 3, apresenta uma descrição do modelo da cinemática adotada pelos
simuladores de ATC.
O Capítulo 4, apresenta os procedimentos automáticos utilizados nos simuladores
Controle de Tráfego Aéreo.
O Capítulo 5, descreveremos de modo sucinto a modelagem de um vôo e a estrutura dos
arquivos utilizados no protótipo do Sistema de Simulação Acelerado para Análise de
Fluxo de Tráfego Aéreo.
O Capítulo 6, descreveremos o protótipo do Sistema de Simulação Acelerado para
Análise de Fluxo de Tráfego Aéreo (Modelo 1) no Contexto do Sistema ATFM em suas
composições software e Hardware, como também a descrição dos outros subsistemas, o
modelo de rede adotado e seus servidores de Processos e de Banco de Dados.
39
O Capítulo 7, apresentaremos o Modelo 2 do Sistema de Simulação Acelerado para
Análise de Fluxo de Tráfego Aéreo, considerando o novo modelo de cálculo da
cinemática.
O Capítulo 8, apresenta a conclusão desse trabalho, os resultados obtidos, e as sugestões
para os trabalhos futuros.
O Apêndice A, apresenta o Fluxograma ATFM.
O Apêndice B, apresenta o Diagrama de Fluxo de Dados (DFD) comum aos modelos 1
e 2 do Sistema de Simulação Acelerado para Análise de Fluxo de Tráfego Aéreo.
O Apêndice C, apresenta uma ilustração dos pseudocódigos adotados para a
entendimento/implementação do Sistema de Simulação Acelerado para Análise de
Fluxo de Tráfego Aéreo - Modelo 1.
O Apêndice D, apresenta uma ilustração dos pseudocódigos adotados para a
entendimento/implementação do Sistema de Simulação Acelerado para Análise de
Fluxo de Tráfego Aéreo - Modelo 2.
41
CAPÍTULO 2
O GERENCIAMENTO DE FLUXO DE TRÁFEGO AÉREO (ATFM) NO CONTEXTO DO GERENCIAMENTO DE TRÁFEGO AÉREO (ATM)
Para que possamos entender a exata dimensão dos problemas que estão relacionados ao
Gerenciamento de Fluxo de Tráfego Aéreo brasileiro, torna-se necessário,
primeiramente registrar um breve histórico do ATFM no contexto do IPV. Em seguida,
descreveremos quais são os subsistemas que integram e auxiliam o desenvolvimento
desse trabalho conforme mostra a Figura 2.1 e, consequentemente, os resultados
pretendidos.
A seguir, descreveremos hierarquicamente os órgãos de controle e gerenciamento de
tráfego aéreo que compartilham este complexo sistema. A Figura 2.2 abaixo mostra a
hierarquia desse sistema. Neste Capítulo apresentaremos a complexa tarefa de
Gerenciamento/Controle de Tráfego Aéreo cujo objetivo é propiciar os meios
adequados aos gerentes ATFM para a agilizar o fluxo de tráfego aéreo em todo território
nacional.
Finalmente, abordaremos a situação atual do ATFM no Brasil, qual seria o cenário
desejado para o fluxo de tráfego aéreo e, por fim, descreveremos também como
funciona o ATFM nos Estados Unidos e Europa.
2.1 Breve histórico do ATFM no contexto do IPV:
A partir de 1994 o movimento aéreo no Brasil teve um crescimento acelerado muito
além das expectativas. Este aumento gerou problemas de fluxo de tráfego aéreo nas
principais cidades das regiões Sudeste e Sul do país, especialmente nos aeródromos da
Área Terminal de São Paulo (TMA-SP). Estes fatores produziram esperas excessivas
tanto nas “Decolagens” quanto nos “Pousos”, provocando aumento nos tempos de vôos
e, consequentemente, um excessivo aumento na carga de trabalho dos “Controladores
de Tráfego Aéreo”.
42
Diante desta situação crítica, a DEPV, órgão do Comando da Aeronáutica, criou em 12
de Março de 1998 em São José dos Campos – SP o NuATFM que tem por objetivo
assessorar o ATC nos casos onde a demanda de tráfego aéreo, por vezes, excede a
capacidade estabelecida nos setores do espaço aéreo e nos aeródromos.
Antes de iniciar esta dissertação em Abril de 1999, o NuATFM não tinha qualquer
ferramenta automatizada que lhe permitisse realizar as atividades de prestação de
serviço ao ATC de maneira computacional. Nesta época todos os trabalhos praticados
pelos gerentes ATFM era baseado na confecção de longas planilhas de planos de vôos
manualmente. Estas planilhas serviam, primeiramente, para dar concessão de novas
linhas aéreas as Companhias Aéreas nacionais e internacionais e, em segundo lugar,
para identificar possíveis problemas de congestionamento ou saturação nos setores e nos
aeródromos do país.
No final de 1999, o NuATFM recebeu a primeira versão do Subsistema de Banco de
Dados ATFM, totalmente desenvolvido no IPV o qual estava sob a responsabilidade de
dois analistas de sistema do Sistema ATFM. Esta ferramenta propiciou aos gerentes
ATFM um ganho de produtividade muito superior comparados aos meios manuais que
até então eram utilizados.
Atualmente o NuATFM dispõe de duas ferramentas de auxilio aos gerentes ATFM, são
elas: uma ferramenta de Banco de Dados que possibilita a realização de consultas e
geração de relatórios em diversos arquivos, tais como: Planos de Vôo, Aerovias,
Aeronaves e Aeródromos nacionais e internacionais. A segunda é uma ferramenta de
simulação denominada de Sistema de Simulação Acelerada para Análise de Fluxo de
Tráfego Aéreo (Modelo I e Modelo II) cuja função é realizar a evolução das aeronaves
desde a decolagem até o pouso, considerando as transferências e a contabilização de
aeronaves entre os setores do espaço aéreo e aeródromos, de maneira que, ao terminar a
simulação, os gerentes ATFM possam visualizar graficamente a demanda de tráfego
aéreo de qualquer região do país e identificar se houve extrapolação na capacidade dos
setores numa data futura.
43
O Subsistema SAS, como veremos com mais detalhes no Capítulo 6, é o responsável
pela visualização gráfica da demanda de tráfego aéreo. Este subsistema foi desenvolvido
por um analista de sistemas que compõe a equipe de desenvolvimento do sistema
ATFM.
Estas ferramentas estão funcionando normalmente no NuATFM numa rede privada do
Comando da Aeronáutica e sendo acessada remotamente nas FMP nas seguintes
localidades: São Paulo, Rio de janeiro, Brasília, Curitiba e Belo Horizonte.
Com extensão para trabalhos futuros prevê-se estudos a partir do segundo semestre de
2001, na criação de algoritmos que possam fornecer opções de melhores horários onde
se constata condições de extrapolação na capacidade de setores numa determinada
região. Este estudo visa distribuir o tráfego aéreo em horários onde não haja a
incidência de extrapolação na capacidade do setor dentre as 24 horas de uma data
preestabelecida.
44
Arquitetura do Sistema ATFM
Intenções de Vôo Dados Radar Espaço Aéreo e Aeródromos
Mensagens ATS/AIS/Meteorologia
Cenário Tráfego
Cenário Tráfego
Cenário
Tráfego Eventos
Medidas ATFM
Fig. 2.1 - Arquitetura do Sistema ATFM.
FONTE: IPV (2000).
Subsistema de Recebimento e Tratamento de Dados Subsistema de Gerenciamento da Base de Dados ATFM
( SGBD )
Subsistema Supervisor
Sistema de Simulação Acelerado para Análise de Fluxo de Tráfego Aéreo
Subsistema de Apresentação Gráfica do Resultado da Simulação ( SAS )
45
2.2 Escopo do Problema :
Para iniciar a descrição do problema ATFM tornou-se necessário dividi- lo em várias
etapas. Primeiramente, procurou-se identificar os tipos de informações que o sistema
necessitaria para atender os requisitos do usuário e também classificar os possíveis
candidatos a fornecê- los. Através de entrevistas com os especialistas de tráfego aéreo
delineamos as fronteiras do sistema principal e seus respectivos subsistemas. O Sistema
ATFM é dividido nos seguintes subsistemas: Subsistema de Gerenciamento da Base de
Dados ATFM (SGBD), Subsistema de Recebimento e Tratamento de Dados,
Subsistema Supervisor, Sistema de Simulação Acelerado para Análise de Fluxo de
Tráfego Aéreo e Subsistema de Apresentação Gráfica de Resultados da Simulação
(SAS). Abaixo apresentaremos uma descrição sucinta de cada subsistema e faremos
menção dos profissionais que os desenvolveram.
2.2.1 Subsistema SGBD :
O subsistema de Gerenciamento da Base de Dados ATFM foi o primeiro módulo a ser
desenvolvido do sistema ATFM de modo a permitir o armazenamento de todas as
informações necessárias para que os gerentes ATFM possam exercer suas atividades
gerenciais e, consequentemente, prover os meios necessários para a realização da
simulação. Este subsistema foi desenvolvido por dois analistas de sistemas que integram
a equipe do Banco de Dados do Sistema ATFM.
2.2.2 Subsistema de Recebimento e Tratamento de Dados :
Este subsistema tem o objetivo converter, verificar e interpretar qualquer incidência de
erro que por ventura seja detectado durante o processo de tratamento dos arquivos
recebidos pelo NuATFM. Uma vez corrigido os arquivos, estes serão armazenados na
Base de Dados ATFM através do subsistema SGBD. Este subsistema foi desenvolvido
pela equipe do Banco de Dados citado no tópico anterior.
46
2.2.3 Subsistema Supervisor :
Este tem a função de receber os parâmetros de entrada (data e hora) fornecidos pelos
gerentes ATFM e, de posse desses dados, iniciar o processo de leitura, interpretação,
conversão e armazenamento dos dados em memória. Estes dados foram extraídos do
Banco de Dados ATFM para serem manipulados durante a fase de simulação. Este
subsistema foi desenvolvido por uma analista de sistemas que integra a equipe de
desenvolvimento do projeto.
2.2.4 Sistema de Simulação Acelerado para Análise de Fluxo de Tráfego Aéreo – Modelo I e Modelo II:
O Modelo I tem a função de evoluir as aeronaves em suas respectivas trajetórias a cada
1(um) segundo, desde a decolagem até pouso, realizando as transferências e as
contabilizações de entrada e saída de aeronaves em setores definidos durante o vôo. Este
modelo processa apenas dados de Planos de Vôos Repetitivos (RPL). Após a simulação,
os gerentes ATFM terão uma informação precisa da demanda de tráfego aéreo de
qualquer porção do espaço aéreo brasileiro, bem como dos aeroportos. Mais detalhes
encontra-se no Capítulo 6 desta dissertação.
O Modelo II tem a função de evoluir as aeronaves em suas respectivas trajetórias ponto
a ponto, desde a decolagem até pouso, ininterruptamente, e só finalizará o
processamento quando pousar a última aeronave. Diferentemente do modelo 1, este
modelo, além de manipular a base de dados repetitiva (RPL), também processará dados
de FPL e dados radares que serão enviados ao NuATFM do maneira “on line”. Mais
detalhes encontra-se no Capítulo 7 desta dissertação. Estes modelos deram origem a
essa dissertação.
2.2.5 Subsistema de Apresentação Gráfica de Resultados da Simulação (SAS):
Este subsistema tem a função de apresentar a demanda de tráfego aéreo de modo gráfico
dos setores do espaço aéreo brasileiro e de qualquer aeroporto nacional. Além da parte
gráfica, o SAS apresenta os dados principais dos tráfegos, suas trajetórias e os dados
47
relativos aos eventos de cada tráfego. Este subsistema foi desenvolvido por um analista
de sistemas que integram a equipe de desenvolvimento do Sistema ATFM.
Fig. 2.2 - Gerenciamento de Tráfego Aéreo - ATM.
FONTE: IPV (1996).
2.3 O Gerenciamento de Tráfego Aéreo - ATM :
Conforme a descrição do Comitê Especial sobre Sistemas de Navegação Aérea do
Futuro (FANS), o ATM tem por objetivo, permitir que os exploradores de aeronaves
possam cumprir com as horas previstas de saídas/chegadas e manter os perfis de vôos
preferidos com o mínimo de limitação sem, contudo afetar, os padrões de segurança.
Compreende uma parte terrestre e uma parte aérea, sendo ambas necessárias para
assegurar o movimento seguro e eficaz das aeronaves durante todas as fases do vôo.
Ainda segundo o FANS, a parte de bordo do ATM compreende a capacidade funcional
de interação com a parte terrestre para obter os objetivos gerais do ATM.
AATTMM GGeerreenncc iiaa mmeennttoo
ddee TTrrááffeeggoo AAéérreeoo
AATTCC
AATTFFMM
GGeerreenncc iiaammeennttoo ddee FFlluuxxoo ddee
TTrráá ffeeggoo AAéérreeoo
CCoonnttrroo llee ddee TTrráá ffeeggoo AAéérreeoo
GGeerreenncc iiaammeennttoo ddoo
EEssppaaççoo AAéérreeoo
AASSMM
48
A parte terrestre do ATM, compreende as funções do Serviço de Tráfego Aéreo (ATS),
considerando o componente primário, do Gerenciamento de Fluxo de Tráfego Aéreo
(ATFM), e do Gerenciamento do Espaço Aéreo (ASM).
A execução do ATM exige uma integração estreita entre a parte terrestre e a parte aérea,
com procedimentos bem definidos conforme consta no documento (ICAO, 1996).
2.4 O Gerenciamento do Espaço Aéreo – ASM :
O objetivo do ASM consiste em alcançar, dentro de determinada estrutura do espaço
aéreo, o maior grau de utilização do espaço aéreo disponível, mediante o
compartilhamento dinâmico no tempo e, às vezes, a divisão do espaço aéreo entre
diversas categorias de usuários para as necessidades a curto prazo.
A estreita colaboração entre as autoridades competentes, no que diz respeito a previsão
e o uso real do espaço aéreo reservado temporariamente, permitirá que a informação
pertinente esteja disponível rapidamente para todas as partes interessadas, isto é, o
transporte aéreo comercial, o tráfego aéreo militar e a aviação geral. O ASM constitui,
assim como o ATFM, um elemento de “apoio” ao ATC (ICAO, 1984).
2.4.1 Para atingir o objetivo do ASM é necessário realizar as seguintes funções:
a) Revisar e avaliar todas as solicitações que impliquem numa reserva temporária
do espaço aéreo;
b) Planejar e dispor o espaço aéreo requerido pelo usuário interessado, quando
necessário aplicar uma restrição;
c) Ativar e desativar o espaço aéreo dentro de uma tolerância de tempo
adequadamente breve, com estreita colaboração do ATC e usuários do espaço
aéreo. O espaço aéreo exclusivamente reservado para atividades militares,
contam com uma coordenação civil e militar mais eficaz, devido ao tráfego de
aeronaves civis nesse espaço aéreo.
49
d) As dimensões, localização, requisitos e uso do espaço aéreo reservado, áreas
perigosas ou restritas devem ser objeto de um estudo profundo e permanente, a
fim de permitir a utilização mais eficiente do espaço aéreo, reduzindo-se, ao
mínimo, o período de ocupação da área.
e) Difundir informação detalhada, tanto por antecipação quanto em tempo real, a
todas as partes interessadas (IPV, 1996).
2.4.2 Considerações sobre o Gerenciamento do Espaço Aéreo – ASM :
Na estruturação e gerenciamento do espaço aéreo, os Estados deveriam incentivar a
segurança dos vôos, oferecendo suficiente capacidade para atender a demanda de
tráfego aéreo, assegurando a máxima utilização do espaço aéreo e estabelecendo um
equilíbrio entre os requisitos legítimos, porém, às vezes, antagônicos dos vários
usuários.
O Gerenciamento do Espaço Aéreo deveria ser orientado para a exploração mais eficaz
do espaço aéreo de acordo com os requisitos dos diversos usuários. Em alguns casos,
nos quais as necessidades são antagônicas, restrições do espaço aéreo podem ser a única
solução viável para o gerenciamento do tráfego aéreo. Neste caso, para obter a
utilização máxima do espaço aéreo, deve-se buscar uma maior coordenação entre os
setores civil e militar, compartilhando o espaço aéreo e os diversos componentes do
ATC.
O fluxo de tráfego aéreo, às vezes, é afetado negativamente por obstáculos do próprio
sistema limitando a capacidade instalada. Por essa razão e para uma utilização mais
eficaz do espaço aéreo disponível, todos os elementos pertinentes do sistema devem ser
considerados durante a etapa de planejamento, aplicando-se um enfoque integrado entre
o sistema aeroportuário e o ATC.
50
2.4.3 Consideração sobre o Espaço Aéreo Brasileiro:
O Brasil tem sob a sua responsabilidade, para fins de gerenciamento de tráfego aéreo,
um espaço aéreo de cerca de 22.000.000 Km². Para possibilitar o efetivo gerenciamento,
esse espaço aéreo está dividido em 6 (seis) Regiões de Info rmação de Vôo (FIR) onde
estão contidos os espaços aéreos de serviço de tráfego aéreo, conforme mostra a Figura
2.3 abaixo.
Fig. 2.3 - Região de Informação de Vôo (FIR).
51
No conjunto Regiões de Informação de Vôo, correspondente ao espaço aéreo
jurisdicional e sob responsabilidade do Brasil, encontra-se uma extensa malha de
aerovias nacionais e internacionais, parte integrante de um sistema maior, denominado
Rede de Rotas ATS das regiões do Caribe e da América do Sul, conforme mostra a
Figura 2.4.
Fig. 2.4 - Malha de aerovias nacionais e internacionais.
52
Essa rede de rotas ATS (aerovias) está sob a responsabilidade do Brasil, estabelecida
nos espaços aéreos inferiores (até 24500 pés) e superior (acima de 24500 pés), possui
uma extensão também equivalente a 111.400 Milhas Náuticas (NM), onde detém a
responsabilidade pelo controle de tráfego aéreo e, também, dos demais espaços aéreo
controlados com cerca de 5,8 milhões de movimentos anuais, através de órgãos de
controle de tráfego aéreo instalados em pontos adequadamente definidos no território
brasileiro.
É atribuído a cada setor do espaço aéreo e aos aeroportos brasileiros, um valor fixo que
determina a quantidade máxima de aeronaves que cada um deverá suportar durante o
dia ou a um determinado período do dia, este valor é conhecido como capacidade . Em
geral o valor da capacidade atribuída aos setores e aos aeroportos são fixos, mas poderá
ocorrer situações em que essa capacidade poderá ser alterada por um determinado
período do dia, de acordo com a análise do Serviço de Tráfego Aéreo (ATS). E logo que
se restabeleça a normalidade no setor, o ATS retornará o valor da capacidade já
preestabelecido.
Se num determinado período do dia, o volume de tráfego (demanda) se aproximar da
capacidade do setor ou do aeroporto, este acontecimento dar-se o nome de Alerta de
congestionamento ou Alerta de saturação. O Alerta de congestionamento ocorre quando
o volume de tráfego aéreo chega a 80% da capacidade do setor e Alerta de saturação é
quando o volume de tráfego aéreo chega a 100% da capacidade do setor. Os gerentes de
ATFM costumam também dar o nome de extrapolação de capacidade do setor ou do
aeroporto. Muito bem, num caso de extrapolação seja num setor ou num aeroporto,
sabemos que, quem pode alterar o valor da capacidade é o ATS, mas quem poderá
alterar a demanda de fluxo tráfego aéreo?
A resposta seria, o ATS e ATFM, porque existe uma estreita cooperação entre ambos. O
ATFM não pode tomar medidas que sejam do desconhecimento do ATS e vice e versa.
Medidas isoladas poderão acarretar sérios riscos à segurança dos vôos. Portanto, nos
casos em que seja necessário alterar os parâmetros de uma determinada região, entenda-
53
se setor e/ou aeroporto, antes de ocorrerem, com certeza o ATS e ATFM já estarão de
pleno acordo com as medidas a serem executadas.
2.4.4 Classificação do Espaço Aéreo Brasileiro :
O espaço aéreo brasileiro é dividido seguindo as áreas do pais de acordo com o seu grau
de desenvolvimento e as reais necessidades de cada região.
2.4.4.1 Regiões de Informações de Vôo (FIR ):
São espaços aéreos não controlados, o qual se destina a prestar serviços de informação
de vôo e serviço de alerta.
2.4.4.2 Espaços Aéreos Controlados:
São espaços aéreos com dimensões bem definidas e destina-se a prestar o serviço de
controle de tráfego aéreo. Os espaços aéreos controlados são divididos em:
a) Áreas Superiores de Controle ( UTA ) – Compreendem as aerovias superiores
e outras partes do espaço aéreo superior que estão definidos nas cartas de rota.
b) Áreas de Controle ( CTA ) – São espaços aéreos controlados constituído das
aerovias inferiores e outras partes do espaço aéreo inferior definidas nas carta de
rota.
c) Áreas de Controle de Terminal ( TMA ) – Compreendem áreas situadas na
confluência de rotas ATS e nas imediações de um ou mais aeródromos.
d) Zonas de Controle ( CTR ) – Compreendem áreas que englobam os aeroportos
e contém as trajetórias de chegada e saída de vôos IFR.
e) Zonas de Tráfego de Aeródromos ( ATZ ) – Compreendem espaço do
aeródromo, no qual as aeronaves evoluem sob condições visuais.
54
2.4.4.3 Espaços Aéreos Condicionados:
São espaços aéreos onde a evolução da aeronave é restringida pela existência de riscos à
navegação aérea. Os espaços aéreos condicionados podem ser classificados em:
a) Área Perigosa – São espaços aéreos de dimensões definidas, no qual existem
riscos potenciais ou atuais para a navegação aérea.
b) Área Proibida – São espaços aéreos de dimensões definidas, no qual o vôo é
proibido.
c) Área Restrita – São espaços aéreos de dimensões definidas, no qual o vôo só
poderá ser realizado sob condições preestabelecidas.
2.4.4.4 O Serviço de Tráfego Aéreo ( ATS ):
O serviço de tráfego aéreo, segundo normas da ICAO, tem por objetivo prevenir colisão
entre aeronaves, acelerar e manter o fluxo do trânsito aéreo, prevenir colisão entre
aeronaves e obstáculos, prover informações úteis à segurança e à condução eficiente dos
vôos e apoiar os órgãos de busca e salvamento (ICAO, 1984).
2.4.4.5 Estrutura do Serviço de Tráfego Aéreo :
O serviços de tráfego aéreo, conforme recomendação da ICAO, estão subdivididos em
três camadas, à saber:
1.) Serviço de Controle de Tráfego Aéreo
Para cumprir a responsabilidade de prover os serviços de tráfego aéreo, o Sistema
Integrado do Controle de Tráfego Aéreo Brasileiro ( SISCEAB ), dispõe de órgãos
de tráfego Aéreo, com áreas de competência definidas e com atribuições
específicas. Estes órgãos compreendem:
1.1) Controle de Área Terminal
Serviço prestado pelo Centro de Controle de Área (ACC), o qual tem por objetivo o
controle das aeronaves em rota.
55
1.2) Controle de Aproximação
Serviço prestado pelo Controle de Aproximação (APP) o qual tem por objetivo o
controle das aeronaves que estão chegando ou saindo nas proximidades dos
aeroportos.
1.3) Controle de Aeródromo
Serviço prestado pela Torre de Controle (TWR), o qual tem por objetivo o controle
das aeronaves durante a aproximação final e na saída imediata do aeródromo.
2.) Serviço de Informação de Vôo
É um serviço que tem por objetivo fornecer informações de pista de pouso,
condições meteorológicas, situações de sistemas de auxílio a navegação e
informações sobre colisões etc.
3.) Serviços de Alerta
Se destina a prestar serviços de acionamento e ao apoio aos órgãos de busca e
salvamento.
56
2.5 Gerenciamento de Fluxo de Tráfego Aéreo - ATFM:
O Gerenciamento de Fluxo de Tráfego Aéreo é um dos seguimentos da Gerência de
Tráfego Aéreo (cujo objetivo é permitir que exploradores de aeronaves cumpram seus
horários de chegada e saída conforme previstos e se utilizem dos perfis de vôo
preferidos, sem comprometer os níveis de segurança da navegação aérea.), que visa a
complementar o Serviço de Tráfego Aéreo em áreas onde a demanda de movimentos de
aéreos, por vezes, excede a capacidade do espaço aéreo ou ultrapassa os limites do
sistema de controle de tráfego aéreo instalada (Brasil, 1996b).
2.5.1 Princípio do Gerenciamento de Fluxo de Tráfego Aéreo :
No decorrer da primeira crise mundial do petróleo em 1976, a Federal Aviation
Administration – ( FAA – USA ), instituiu, medidas para evitar o desperdício de
combustível da aviação, principalmente quando estas se encontravam em condições de
esperas no ar em níveis elevados por muito tempo.
Basicamente a idéia era evitar que o avião ficasse muito tempo em esperas no ar e que
pudessem voar em níveis menos elevados e permitisse que os vôos fossem realizados
da decolagem ao pouso de forma ininterrupta.
Essa iniciativa foi denominada de “Local Flow Traffic Management” , posteriormente
passou a chamar-se “Central Flow Control Facility“ e por fim culminou na origem do
“Air Traffic Control Command Center”, o qual foi concebido para cuidar de toda a
circulação aérea de interesse dos Estados Unidos.
A partir de 1980, os europeus de modo semelhante ao sistema americano, constituíram
várias centrais nacionais de controle de fluxo, de modo que em 1994 consolidaram em
Bruxelas a “Central Flow Management Unit” na agência européia para a segurança da
navegação aérea – EUROCONTROL.
As circunstâncias, propostas e ações que estão associadas às iniciativas norte-
americanas e européias representam importante referência para a condução dos planos
57
de implementação do gerenciamento de fluxo de tráfego aéreo no Brasil, que
começaram a ser desenvolvidas desde 1996.
Para ser mais exato, no final de 1995, observou-se uma grande concentração de tráfego
aéreo em pelo menos um dos aeroportos brasileiro, o de Congonhas em São Paulo. As
esperas tanto no ar como em solo passaram a ser rotina, deram-se então início a
freqüentes discussões sobre as propriedades nas operações e conduções das aeronaves
tanto em solo como no ar neste aeroporto.
Em face do grande volume do tráfego aéreo verificado na Terminal Aérea de São Paulo
(TMA-SP), o risco de colisão de aeronaves ficou bastante evidenciado, o qual chegou a
ser até noticiado pela imprensa. A situação ameaçava a se tornar insustentável, mas em
resposta, os especialistas de tráfego aéreo, decidiram adotar uma medida típica de
controle de fluxo, que é a aplicação do Sistema de Slot de Tempo (Slot de Tempo é uma
medida de controle de fluxo que visa restringir os movimentos de aeronaves em um
determinado horário do dia), para as operações no aeroporto de Congonhas em horários
de maior demanda.
Um aeroporto quando está sob o sistema de slot, as companhias aéreas bem como os
vôos da aviação geral, geralmente só conseguem realizar suas operações de vôo, quando
estão de posse de um horário para realização de pouso e decolagem. Sem o horário elas
não conseguem realizar suas operações, exceto em casos de segurança, ou em vôos com
autoridades presidenciais, governamentais e militares.
Conforme citado anteriormente, medidas de controle de fluxo de tráfego sempre impõe
restrições aos movimentos das aeronaves, tais como esperas no solo ou no ar. A
dificuldade de distribuir as restrições de forma eqüitativa entre todos os usuários, por
sua vez, é outro desafio. Por esses motivos, é imperioso desenvolver mecanismos mais
sensíveis às necessidades, tanto de prestadores de serviço como de usuários, o que é
possível através do sistema de “Gerenciamento de Fluxo de Tráfego Aéreo”.
A Central de Slot de Tempo instalada no Serviço Regional de Proteção ao Vôo de São
Paulo (SRPV-SP), aplica uma das medidas de gerenciamento de fluxo aéreo, que é o
58
controle de fluxo, utilizando um sistema computadorizado denominado “Sistema de
Alocação de Slots de Aeroporto (SIASA)”, este sistema foi desenvolvido pelo Instituto
de Proteção ao Vôo, cujo objetivo é, verificar se dentre às próximas 48 horas é
possível a liberação de horários para as operações de pouso e decolagem no aeródromo
de Congonhas – SP.
Este sistema foi desenvolvido de modo híbrido, onde se utiliza a metodologia
estruturada na implementação do módulo Servidor, e a metodologia Orientada a Objetos
na implementação dos módulos Gerente e Operador.
Aplicou-se os conceitos e padrões da engenharia de software, as linguagens C/C++ e,
utilizou-se os sistemas operacionais Linux e Windows.
O sistema está dividido em 3 módulos basicamente. O primeiro módulo denominado
“Servidor”, é o responsável pela liberação dos horários de vôo para às próximas 48
horas. Este módulo foi desenvolvido sob a plataforma Linux.
O segundo módulo denominado “Gerente”, é responsável pela manutenção de toda a
base de dados do sistema, compreende-se desde o cadastro de usuários, como também
as alterações provenientes dos parâmetros do sistema.
O terceiro e último módulo, denominado “Operador”, é o responsável pelo
recebimento dos horários solicitados pelas companhias aéreas e pela aviação geral, e
repassa ao módulo Servidor o horário solicitado, que por sua vez analisa o horário
recebido e emite um parecer favorável ou não do horário solicitado ao operador. Os
módulos gerente e operador foram desenvolvidos na plataforma Windows e utilizam a
linguagem C++ Builder da Borland.
As Figuras 2.5 e 2.6, apresentam a central de slot instalada no Serviço Regional de
Proteção ao Vôo ( SRPV-SP ) no aeroporto de Congonhas em São Paulo.
59
Fig. 2.5 e 2.6 - Operadores realizando Alocação de horários de slot.
FONTE: SRPV-SP (Serviço Regional de Proteção ao Vôo de São Paulo).
60
2.5.2 Objetivo do Gerenciamento de Fluxo de Tráfego Aéreo :
O serviço ATFM tem por objetivo apoiar o ATC na busca do ótimo fluxo de tráfego
aéreo, em áreas onde a demanda de tráfego aéreo excede, ou se espera que exceda, a
capacidade da infra-estrutura instalada, incluindo-se os aeródromos pertinentes.
O termo ATFM se aplica a toda atividade relacionada com o gerenciamento de fluxo e o
controle de fluxo aéreo, não se limitando a garantir que todos os vôos sejam efetuados
de forma rápida, segura e ordenada mas, também, permitir que a totalidade do tráfego
aéreo controlado em uma determinada área, seja compatível com a capacidade do
sistema ATC.
O termo capacidade do ATC se aplica à possibilidade do sistema ATC, ou de qualquer
um de seus subsistemas, inclusive os postos de ATCO, de proporcionar serviços às
aeronaves em condições normais de operação, e se expressa em função do número de
aeronaves que entram, ou saem, em um determinado setor do espaço aéreo, durante um
período de tempo.
A capacidade máxima que se pode obter durante curtos períodos de tempo poderá ser
bastante superior àquele estabelecido para as condições normais. O ATFM dá suporte
ao ATC para que este possa atingir seus objetivos principais de prevenir colisões entre
aeronaves, acelerar e manter ordenado o fluxo de tráfego aéreo, assim como obter a
utilização mais eficiente do espaço aéreo disponível e da capacidade dos aeroportos.
Para maior eficácia, o serviço ATFM deve contar com uma contínua cooperação e
coordenação com os órgãos ATC envolvidos e com os diversos usuários do espaço
aéreo (Eno, 1997).
Nem sempre é possível obter um fluxo ótimo de tráfego aéreo devido à vários fatores
restritivos, tais como os requisitos antagônicos dos usuários, as limitações dos sistemas
de navegação aérea e as condições imprevistas da meteorologia.
A esse respeito, deverá ser considerado a aplicação de medidas paliativas, como o
controle de fluxo de tráfego aéreo, em particular quando o sistema ATC não pode dar
continuidade ao serviço devido ao volume de tráfego aéreo.
61
O controle de fluxo de tráfego aéreo é aplicado quando o órgão ATC estime que não
será possível atender outros tráfegos além daqueles já aceitos, para um período de
tempo e lugar, ou que somente poderá faze-lo a um determinado ritmo. Neste caso, o
órgão ATC notificará aos demais órgãos interessados, às empresas exploradoras
envolvidas e aos pilotos das aeronaves atingidas pelas restrições, que é provável que os
vôos adicionais estejam sujeitos a esperas excessivas, ou outras restrições por um
determinado tempo.
2.5.3 Causas Principais dos Congestionamentos de Tráfego Aéreo :
a) Aumento do tráfego aéreo durante determinados períodos do ano, horas da
semana devido a viagens de férias e outros efeitos sazonais;
b) Diferentes capacidades dos diversos sistemas ATC;
c) Aviso ao órgão ATC, sem a necessária antecipação, sobre as prováveis demandas
de tráfego aéreo e as possíveis sobrecargas do sistema em determinados setores,
durante certos períodos;
d) Carência de técnicos e procedimentos eficazes, que permitam restabelecer, em
situações críticas, o razoável equilíbrio entre a demanda de tráfego aéreo e a
capacidade ATC, fundamentado em medidas que sejam aceitáveis pelos
exploradores das aeronaves, tanto sob o ponto de vista operacional, quanto
econômico.
Os congestionamentos de tráfego aéreo podem ser creditados aos exploradores quando
adaptam seus serviços à demanda dos clientes e ao fato de que a escolha das rotas e
níveis de vôo sejam limitados devido às necessidades de compartilhar espaço aéreo
com outros usuários, especialmente à aviação militar.
Além disso, os exploradores, às vezes, tem que submeter-se a certas restrições impostas
por razões ambientais, isto é, operação noturna em determinados aeródromos,
procedimentos de atenuação de ruídos, etc., fatos que estimulam a concentração do
tráfego aéreo em breves períodos de tempo.
62
A capacidade de Gerenciamento de Fluxo de Tráfego Aéreo por parte dos sistemas ATC
podem ser inadequados devido a ineficiência de pessoal nos órgãos existentes, tanto a
nível numérico quanto à formação profissional. Por outro lado, procedimentos ATC
ineficientes também podem limitar a capacidade ATC, a insuficiência de equipamentos
ATC, tais como radares primários, secundários e dispositivos eletrônicos de
processamento de dados, também podem provocar dificuldades para atender o
crescimento do tráfego aéreo.
2.5.4 Considerações sobre o Controle de Fluxo:
Em certos casos deverão ser adotados medidas de “controle de fluxo”, o qual tem o
objetivo de assegurar o equilíbrio razoável entre a demanda de tráfego aéreo e a
capacidade ATC para ajustar-se a esse volume.
Considerando que essas medidas são “restritivas”, elas devem ser mantidas nas
condições mínimas e serem aplicadas de forma seletiva, atingindo tão somente a parte
do tráfego aéreo que dá origem ao problema.
O termo seletivo não deve ser interpretado como discriminatório por parte do ATC,
porque, toda distinção entre partes diferentes do tráfego aéreo, deveria basear-se,
exclusivamente, em categorias tais como tráfego aéreo de chegada, saída ou sobrevôo,
sem nenhuma consideração em relação ao tipo de vôo (civil, militar, regular e não
regular).
Quando necessário aplicar medidas de “controle de fluxo”, em certas regiões do espaço
aéreo, estas sim deveriam ser limitadas aos períodos em que haja previsão de que a
demanda de tráfego aéreo extrapolará a capacidade do ATC e medidas deverão ser
tomadas de forma eqüitativa entre todos os vôos.
63
2.5.5 No contexto do ATFM, deveriam ficar isentos das medidas de
“controle de fluxo” os seguintes vôos :
a) Os vôos em situações de emergência, inclusive aqueles que estão sob
interferência ilícita;
b) Os vôos envolvidos em razões humanitárias;
c) Os vôos de caráter médico, declarados especificamente pelas autoridades
médicas;
d) Os vôos em missões de busca e salvamento (SAR);
e) Os vôos classificados como de “Chefes de Estado;”
f) Outros vôos, para os quais as autoridades estatais tenham solicitado
especificamente a isenção.
Em estreita cooperação com o ATC, os exploradores de aeronaves e os administradores
de aeroportos, o serviço ATFM deveria permitir a plena exploração da capacidade ATC
para ajustar-se a demanda de tráfego aéreo, bem como garantir a maior flexibilidade
possível no uso das rotas para assegurar esperas mínimas a todos os vôos.
Além disso, o ATFM deveria fornecer ao ATC e aos exploradores de aeronaves e
administradores de aeroportos informações antecipadas sobre situações de sobrecargas e
preparar dados estatísticos relativos ao tráfego aéreo objetivando identificar,
prontamente, os obstáculos que apareçam no sistema.
Convém lembrar que nesta etapa, que o êxito da implementação do ATFM dependerá da
eficácia das comunicações e da colaboração estabelecida entre as autoridades ATS
nacionais, os exploradores das aeronaves e as autoridades militares.
2.5.6 O serviço ATFM e suas atribuições nas funções Estratégica e
Tática:
a) Rever e repassar os dados sobre a infra-estrutura da navegação aérea, a
capacidade do sistema ATC e de alguns aeródromos situados dentro da área
64
ATFM, compreendendo a capacidade das pistas, pistas de táxi, pátios e terminal
de passageiros;
b) Rever e analisar os dados de todas às operações de vôos controlados previstos e
que envolva a área do ATFM;
c) Estabelecer um quadro coerente da demanda de tráfego aéreo prevista com a
capacidade da infra-estrutura instalada e a determinação de setores e duração de
sobrecargas de tráfego aéreo;
Estabelecer coordenação com as autoridades ATS competentes para realizar tentativas
de incremento da capacidade ATC disponível, quando necessário. Em algumas
situações particulares poderia ser vantajoso estabelecer reuniões de trabalho com
representantes do ATC, autoridades aeroportuárias e exploradores de aeronaves visando
obter contribuições importantes para reduzir o impacto dos períodos de demanda
máxima.
Quando não for possível eliminar as carências em matéria de capacidade ATC,
determinar e aplicar oportunamente medidas táticas adequadas e coordenadas em toda
área ATFM, segundo o necessário e com a participação dos exploradores de aeronaves e
administradores de aeroportos.
Quando necessário aplicar medidas para controlar o fluxo de tráfego aéreo, em forma de
esperas, o ATC deveria aplicá-las no solo e não em vôo. Se a aplicação de tais medidas
forem necessárias às aeronaves em vôo, estas deveriam ser informadas o mais breve
possível. Se necessário esperas em rota, as aeronaves atingidas deveriam manter-se o
mais próximo possível do ponto de ingresso a região que deu origem à restrição.
A introdução das medidas de controle de fluxo exige que a capacidade ATC seja
determinada com precisão e que se efetue uma avaliação do nível de demanda de
tráfego aéreo acima da qual será necessário regular o movimento.
Tendo determinado esse nível, o ATFM deveria proporcionar ao ACC informação
horária (e com a maior precisão possível) relativa às horas previstas de chegada e saída
65
de todas as aeronaves durante cada período (15 a 30 minutos) no qual possam ser
previstas as condições de máximo tráfego.
Preferencialmente, estas previsões devem ser preparadas com uma antecedência de, no
mínimo, 3 horas, com análises e revisões periódicas. Considerando que estas previsões
contam com informações sobre muitas aeronaves, que eventualmente não tenham
decolado ou outras que não sejam do conhecimento do ACC, o ATFM deve adotar
medidas especiais para obter esta informação junto aos ACC adjacentes, aos
exploradores ou outras fontes disponíveis.
A previsão da capacidade do sistema parte do conhecimento da capacidade disponível
em condições ótimas de operação. Assim é necessário considerar as condições
meteorológicas adversas, as configurações das pistas em uso, as conseqüências das
mudanças das previsões dos ventos, a não disponibilidade de pistas, a inoperância de
auxílios à navegação para rota, aproximação e pouso, assim como qualquer outro fator
que possa afetar negativamente a regularidade dos vôos.
Estas informações são avaliadas posteriormente pelo ATFM, em estreita colaboração
com o ATC, de modo a obter um valor correspondente à capacidade provável do
sistema, a qualquer momento (Brasil, 1996b).
As medidas para regular a demanda podem ter várias formas. Nos sistemas mais
simples, os ACC que exercem o controle de fluxo para outros ACC adjacentes difundem
avisos solicitando que as aeronaves afe tadas sejam espaçadas em determinados
intervalos (10 minutos, por exemplo).
O espaçamento das aeronaves com essa finalidade não deve mesclar-se com as
separações, mas sim basear-se em um regime de aceitação, isto é, o número de
aeronaves aceitas em um determinado intervalo de tempo.
Esse método de aplicar o controle de fluxo é utilizado para vários ACC que não
possuem sistemas ATC de auxílio de computadores. Nos sistemas ATC automatizados é
possível aplicar uma forma mais aperfeiçoada e refinada.
66
2.5.7 Medidas de Gerenciamento de Fluxo de Tráfego Aéreo:
A exata capacidade do sistema de controle de tráfego aéreo (ATC) é determinada por
intermédio de cálculos matemáticos que consideram todas as variáveis pertinentes e
poderosos Banco de Dados que permitem que o ATFM conheça perfeitamente a
“demanda esperada”.
Dessa forma, é possível balancear o sistema e obter um fluxo de tráfego aéreo
otimizado, mesmo nas áreas onde a demanda ultrapassa, por vezes, a “capacidade
instalada” do sistema ATC.
Fundamentalmente, as medidas de gerenciamento de fluxo podem ser classificadas
como:
a) Medidas Estratégicas ( poderá ser empregada até 48 horas antes do vôo); e
b) Medidas Táticas (poderá ser empregada no mesmo dia do vôo).
Medidas Estratégicas do ATFM consiste em acomodar os vôos em rotas, níveis e
aeroportos desejados com base em planejamento bastante antecipados. Eventualmente
poderá ser necessário alocar “Slot” para as decolagens de alguns aeroportos. Aponta-se
como exemplo, o sucesso das medidas estratégicas adotadas na região européia.
Medidas Estratégicas:
Obtém de forma antecipada as informações sobre as intenções de todos os vôos de um
determinado período ou data futura, deste modo é possível elaborar uma previsão de
demanda futura, baseado nas seguintes informações:
a) Horário propostos;
b) Rotas;
c) Nível de vôo; e
d) Aeródromos.
67
Medidas Táticas do ATFM trabalha as limitações em bases flexíveis e tempo real, ao
invés dos rígidos parâmetros de aceitação típicos de controle de fluxo. Entre as medidas
Táticas comuns encontramos procedimentos de pequenos ajustes dos horários de
sobrevôo de pontos significativos, na fase de vôo em rota.
Estes ajustes podem consistir tanto em “atraso” como “adiantamento” em alguns
minutos, visando permitir o cumprimento de uma “aproximação ininterrupta” desde os
fixos de sequenciamento até o pouso no aeródromo de destino.
Medidas Táticas:
Os tópicos abaixo representam as principais medidas que podem ser aplicadas em
conjunto com órgãos de controles de tráfego aéreo, o qual visa evitar a sobrecarga nos
aeródromos e nos setores de controle:
a) Utilização do FMS (Sistema de Gerenciamento de Vôo);
b) Vetoração;
c) Ajustes de Velocidade;
d) Espera no Solo; e
e) Espera em Vôo.
2.5.8 O Gerenciamento de Fluxo de Tráfego Aéreo no Brasil, Estados
Unidos e Europa:
No Capítulo 1, tópico 1.3 Motivação e Origem, descreve em detalhes o porque que o
Brasil resolveu adotar as técnicas de gerenciar fluxo de tráfego aéreo em algumas
regiões do país. A Figura 2.7 baixo mostra a real necessidade que o país tem de aplicar
as técnicas de gestão de fluxo de tráfego aéreo, em decorrência do aumento de demanda
de tráfego aéreo em determinadas regiões brasileira.
68
Fig. 2.7 - Crescimento de demanda nos aeroportos de Congonhas,
Internacional de São Paulo/Guarulhos e Marte.
FONTE: SRPV-SP (Serviço Regional de Proteção ao Vôo de São Paulo). Pôr terem passado pela mesma situação, o qual passa o espaço aéreo brasileiro, os
Estados Unidos e Europa, há alguns anos vêem empregando as técnicas do ATFM para
gerenciar, controlar e organizar o tráfego aéreo conforme seja detectado futuras
situações de conflito (demanda x capacidade) no espaço aéreo e nos aeroportos.
Hoje em dia se torna premente uma ferramenta de análise de fluxo aéreo semelhante aos
modelos Americano e Europeu para ser empregada nas regiões que por ora ocorrem
extrapolação na capacidade de setores. Evidentemente, os especialistas de tráfego aéreo
brasileiros, precisam conhecer os dois sistemas para que possam comparar qual deles se
adaptaria a realidade nacional.
Atualmente a única medida ATFM que é empregada no Brasil é o “Controle de Fluxo”,
que além de ser uma medida restritiva, não atende a demanda reprimida que hoje se
tem. Para proteger o Serviço de Tráfego Aéreo nacional, existem medidas que poderiam
ser empregadas a longo, médio e a curto prazo.
1 2 4 5 1 41 0 6 9 8 5
828267 6 2 2 7
1 4 7 5 8 81 3 4 6 3 0
2 1 0 1 8 1
1 8 2 2 3 91 7 3 5 8 4
160202
1 2 6 3 2 71 4 4 6 5 5
1 5 4 2 9 41 7 0 8 3 2
1 9 1 8 1 0
0
5 0 0 0 0
1 0 0 0 0 0
1 5 0 0 0 0
2 0 0 0 0 0
2 5 0 0 0 0
1 9 9 3 1994 1 9 9 5 1996 1 9 9 7 1998 1 9 9 9A N O S
NÚ
ME
RO
DE
MO
VIM
EN
TO
S
C O N G O N H A S
G U A R U L H O S
C A M P O D E M A R T E
69
Medidas a longo prazo (5 a 10 anos) incluem avanços tecnológicos no sistema de
Controle de Tráfego Aéreo (ATC), construção de novas pistas nos aeroportos
congestionados e construção de novos aeroportos para redirecionar o crescente fluxo de
tráfego aéreo nas áreas afetadas.
Medida a Médio prazo (6 meses até 2 anos), prevê, emprego do Slot de Tempo e,
aumento no valor das tarifas em horários considerados de pico.
Medidas a Curto prazo, prevê que os órgãos ATC possam obter de maneira antecipada o
volume de tráfego aéreo para tentar adequar a demanda com a capacidade ao longo do
tempo em todos os componentes do sistema ATC. Esta atitude dar-se-á o nome de
Gerenciamento de Fluxo de Tráfego Aéreo (ATFM).
A criação do Núcleo de Gerenciamento de Fluxo de Tráfego Aéreo (NuATFM), é uma
estrutura fundamental para o aprimoramento contínuo dos estudos de ATFM, como
também, na formação de especialistas de tráfego aéreo em gerentes ATFM com
conhecimentos técnico/científico adequados para promover o melhoramento do Sistema
de Controle de Tráfego Aéreo nacional.
2.5.8.1 O Gerenciamento de Fluxo de Tráfego Aéreo nos Estados Unidos :
Para atender o acréscimo de demanda de tráfego aéreo, os Estados Unidos através da
FAA criou o “Air Traffic Control System Command Center - ATCSCC“, o qual tem o
objetivo de balancear a demanda de tráfego aéreo com a capacidade do ATC. O uso de
ferramentas avançadas de automação e comunicações diretas com os ACC, APP, TWR
e empresas aéreas, tornou o ATCSCC capaz de gerenciar o fluxo de tráfego aéreo tanto
a nível nacional quanto local. (Winter e Nuber, 1994).
Um dos componentes mais importantes do ATCSCC é um sistema computadorizado
denominado Enhanced Traffic Management System (ETMS). Este sistema é interligado
com as bases de dados dos vôos do México, Canadá e Europa, e tem como função,
mostrar, em escala nacional ou local, o tráfego aéreo em evolução, provendo condições
para que os especialistas dos Centros possam adotar ações voltadas para minimizar os
70
atrasos, as esperas no solo ou em vôo, disponibilizar informações de vôos com outros
centros de gerenciamento e principalmente alertar os gerentes ATFM sempre que a
projeção em rota, TMA ou fixo exceder a capacidade do ATC.
O ETMS recebe e processa as informações de posição de aeronaves voando em
qualquer região conforme descrita anteriormente, como também em áreas oceânicas.
Prevê informações e assegura as outras organizações internacionais, usuários do espaço
aéreo e provedores internacionais de serviço, as informações de fluxo aéreo de modo
integrado e centralizado, para poder repassar para os outros Centros de Gerenciamento
do país.
O ATFM Americano trabalha, basicamente, com medidas de gerenciamento Tático,
diferentemente do sistema Europeu, que veremos no tópico “O Gerenciamento de Fluxo
de Tráfego Aéreo na Europa”. Este sistema trata os vôos em tempo real e utiliza um
simulador denominado “Fast Time Simulation” para projetar todo o tráfego aéreo 4
horas a frente do horário real. Desta forma, os gerentes ATFM americanos conseguem
prever qualquer anomalia em qualquer setor do espaço aéreo americano de maneira
antecipada ao surgimento de possíveis problemas de congestionamento e saturação na
capacidade dos setores.
2.5.8.2 O Gerenciamento de Fluxo de Tráfego Aéreo na Europa:
A Central Flow Management Unit - CFMU, com sede em Bruxelas, é o centro de
excelência no tocante ao Gerenciamento de Fluxo de Tráfego Aéreo europeu, tornando-
se inteiramente operacional em 1996, substituindo os 5 centros regionais de
gerenciamento de fluxo, operantes pelas administrações nacionais. Desde então o
CFMU tem proporcionado o serviço de Gerenciamento de Fluxo de Tráfego Aéreo à 35
países membros da Conferência de Aviação Civil Européia (ECAC). Esta aliança é
resultado da cooperação entre a ECAC, países membros, empresas aéreas e o
EUROCONTROL. (Winter e Nuber, 1994).
Para o CFMU gerenciar o fluxo de tráfego aéreo europeu, entende-se que os
gerenciadores de fluxo devem estar capacitados a acessar o banco de dados contendo as
71
informações de planos de vôos de todas as aeronaves que pretendam voar no espaço
aéreo. Para facilitar o trabalho dos gerenciadores, foi criado o “IFPS” (Integrate Initial
Flight Plan Processing), que tem o objetivo de receber e processar de modo
centralizado, todos os planos de vôo de todas as aeronaves que irão voar no espaço
aéreo europeu todos os dias. Este sistema tornou-se inteiramente operacional em março
de 1996. Cada vôo normalmente está sujeito a 3 fases, antes de ser conduzido pelo
ATC, são eles:
ATFM estratégico
Considera-se o modo estratégico, os vôos até 2 dias antes de sua realização. Durante
essa fase o CFMU prepara uma previsão de “demanda de tráfego aéreo” em todos os
setores, portanto, essa medida torna-se obrigatório para todas as aeronaves
envolvidas.
ATFM pré-tático
O modo pré-tático, ocorre durante os 2 dias antes do dia previsto para o vôo.
Baseado na previsão estratégica, nas informações recebidas das FMP, dos ACC e
nos dados estatísticos do CFMU, uma mensagem de notificação ATFM é preparada
para o dia seguinte. A ANM define um plano tático para a operação do próximo dia
e informa os operadores de aeronaves e aos órgãos ATC sobre as medidas ATFM
que serão usadas.
ATFM tático
É a operação realizada no mesmo dia do vôo, incluindo alocação de horas de
decolagem, reorganização das rotas para evitar saturação e trajetórias de vôos
alternativas para atingir a eficiência máxima.
FMP é uma posição remota de recebimento das informações de demanda de tráfego
aéreo de uma determinada região.
72
Como podemos perceber existem diferentes conceitos empregados entre os sistemas
ATFM americano e europeu, porém, a qual desses sistemas o Brasil poderia adapta-se?
É evidente que não é fácil dizer de imediato qual desses seria o ideal, entretanto,
segundo os especialistas brasileiros o caminho mais provável será um sistema híbrido.
Onde numa primeira fase trabalhara-se de maneira “Estratégica” e numa segunda fase
trabalhara-se as duas em conjunto (Estratégico e Tático).
Portanto, o emprego das técnicas gerenciais aplicadas nos Estados Unidos e Europa para
solucionar o problema das esperas seja no solo ou em vôo, é de vital importância
também para solucionar este sério problema no tráfego aéreo brasileiro.
2.6 O Cenário Desejado:
Os órgãos de controle de tráfego aéreo atenderão o crescente número de movimentos de
aeronaves, dentro dos padrões de segurança estabelecidas. Um seguro, ordenado, rápido
e econômico fluxo de tráfego aéreo será mantido continuamente.
O serviço de controle de tráfego aéreo sequenciará o tráfego de maneira a eliminar as
esperas devido ao acúmulo de vôos. Eventuais sobrecargas do sistema de controle de
tráfego aéreo serão tratadas de forma preventiva, com mínimos efeitos adversos para os
operadores de aeronaves.
Caso as esperas sejam inevitáveis, as demoras serão distribuídas uniformemente entre
todos os usuários. Em circunstâncias especiais e com apropriada fundamentação, vôos
cumprindo o Horário de Transporte Aéreo Comercial (HOTRAC) poderão receber um
atendimento prioritário com vistas a fomentar a sua regularidade.
A implantação do Gerenciamento de Fluxo de Tráfego Aéreo, através do emprego das
medidas de gerenciamento, aliviará a sobrecarga que atualmente se verifica e permitirá
aproximar a razão de aceitação do aeródromo à capacidade das pistas para absorver as
operações de pouso e decolagem em SBSP (Aeroporto de Congonhas - São Paulo) e
outros aeródromos com movimento intenso.
73
O aeroporto Internacional de São Paulo – Guarulhos, de forma semelhante ao aeroporto
de Congonhas, também passou a gerar um volume de tráfego elevado, com potencial de
ultrapassar a capacidade da pistas e ou do serviço de ATC.
O mesmo fenômeno está ocorrendo em mais alguns pontos do país, especialmente em
Aeroporto da Pampulha – Belo Horizonte (SBBH) e Aeroporto Internacional de
Brasília (SBBR), que assim se inclui nas áreas de interesse da ATFM.
Com a finalidade de contribuir para a melhor utilização possível do espaço aéreo e da
capacidade das pistas, uma perfeita coordenação entre os usuários, prestadores de
serviço e órgãos normativos do Ministério da Aeronáutica (MAer), ocorrerá de forma
sistemática e regular.
2.7 Situação Específica:
As atividades de gerenciamento de fluxo de tráfego aéreo proverão facilidades
operacionais para a melhoria dos serviços prestados por integrantes de diversos outros
sistemas.
Mediante uma interação direta com o Centro de Gerenciamento de Fluxo de Tráfego
Aéreo (ATFM-C), as Companhias Aéreas poderão aperfeiçoar seu próprio controle
operacional, possibilitando alterações de planejamento de vôos com rapidez e
confiabilidade.
A administração aeroportuária terá acesso a informações valiosas para a alocação de
“gates”(portões de entrada na TMA) e utilização mais efetiva de pátios e áreas de
estacionamento.
O Departamento de Aviação Civil (DAC), além do parecer relativo à concessão de
HOTRAN, terá fácil acesso as informações sobre os vôos efetivamente realizados sobre
o território brasileiro. O Sistema de Controle e Fiscalização de Aviação Civil
(SICONFAC) poderá receber informações de interesse, extraídas da base de dados
ATFM.
74
O relacionamento com sistemas de Gerenciamento de Tráfego Aéreo dos Estados
Unidos da América (ATCSSC) e Europa (CFMU-EUROCONTROL) será uma
necessidade nas atividades do ATFM-C, com benefícios mútuos.
A parceria com o ATCSCC e a CFMU visará a troca de informações, essencialmente
sobre o tratamento inicial de plano vôo. Essa prática eliminará a atual necessidade de
endereçamento múltiplos de mensagens e tende a simplificar o processamento de plano
de vôo pelos órgãos ATC.
A exemplo do ATCSCC, no espaço aéreo norte-americano, e da CFMU da
EUROCONTROL, abrangendo o espaço aéreo de mais de 35 (trinta e cinco) países, a
tendência é de apenas um órgão de Gerenciamento de Fluxo de Tráfego Aéreo
encarrega-se da prestação desse serviço no espaço aéreo sul-americano e partes da
região do Caribe.
Neste caso, com a adequada cooperação internacional, grande parte dos países da região
CAR/SAM poderão se valer das facilidades proporcionadas pelo ATFM brasileira.
Finalmente, a circulação operacional militar e as missões de urgência e emergência
poderão ser atendidas com a máxima prioridade com o mínimo prejuízo, para a
circulação aérea geral.
75
CAPÍTULO 3
O MODELO DE CINEMÁTICA DOS SIMULADORES ATC
3.1 Introdução:
Neste Capítulo conceituaremos o que é a simulação e como será utilizada para o
treinamento dos controladores de tráfego aéreo nos seus diversos ramos de atuação.
Iremos descrever as particularidades de cada ramo do controle de tráfego aéreo e como
cada simulador deverá se comportar para melhor atendê- los. A seguir apresentaremos as
considerações sobre o movimento das aeronaves nos simuladores de tráfego aéreo, e por
fim, apresentaremos as equações de cinemática que são adotadas nos simuladores de
tráfego aéreo do IPV.
A simulação aqui considerada é essencialmente um trabalho com modelos que possuem
algumas características semelhantes à realidade. Tais modelos podem conservar as
caracterís ticas físicas e/ou lógicas do sistema real imitado (Shimizu, 1975.)
Sendo assim, o uso de simuladores no Controle de Tráfego Aéreo é uma prática
mundialmente difundida e utilizada pelos principais centros de formação cujo objetivo é
formar e reciclar os especialistas de tráfego aéreo nos seus diferentes ramos de atuação.
Os simuladores de tráfego aéreo são empregados principalmente na formação do
“Controlador de Tráfego Aéreo” que irá atuar no controle de aeródromo, controle
convencional e controle radar.
O controle de aeródromo compreende o ambiente da torre de controle que fica
localizada nos aeródromos e não conta com o auxílio de radar para o exercício de suas
atividades. Em algumas torres de controle existe um repetidor da visualização radar,
porém o controlador de torre limita-se na observação da visualização radar, passando a
interagir e monitorar uma aeronave até o pouso, somente quando o controle sobre esta
lhe é transferida pelo órgão de Controle de Aproximação(Controle Radar). A Figura 3.1
mostra o ambiente de torre de controle.
76
O controle convencional é um ambiente de comunicação em que não existe a utilização
de radar. Este tipo de controle é utilizado em regiões onde não existem o serviço de
informação/cobertura radar. Os controladores convencionais, após receberem as
informações das aeronaves via rádio, anotam suas posições em formulários e passam a
controlá- las mentalmente como se estivessem vendo-as pela console radar. Nos
simuladores de controle de tráfego aéreo os instrutores muitas vezes durante as aulas
práticas provocam a retirada da imagem das aeronaves para tentar simular uma pane no
radar. Daí em diante os controladores passam a controlar as aeronaves de acordo com a
última posição apresentada na console.
O controle radar é um ambiente onde utilizam-se as consoles de apresentação radar.
Neste tipo de ambiente os controladores de tráfego aéreo controlam as aeronaves que
são detectadas pelo radar nas áreas próximas ao aeródromos que são denominadas APP
e em áreas denominadas ACC, que controlam as aeronaves em rotas. A Figura 3.2
mostra o ambiente de controle radar.
Os simuladores de tráfego aéreo desenvolvidos para os ambientes citados acima
procuram representar fielmente o ambiente de atuação dos controladores de tráfego
aéreo onde, o grau de realismo na execução dessas ferramentas possibilitam estudos
práticos que posteriormente são aplicados em situações reais. Os benefícios advindos do
uso de simuladores são inquestionáveis e são amplamente atestados por experiências
relatadas em diversas publicações especializadas. (Bianco, Dell’Olmo e Odoni, 1997).
Portanto, a cinemática que é aplicada aos simuladores de Controle de Tráfego Aéreo
busca na verdade representar o movimento das aeronaves. A mecânica é
costumeiramente dividida em duas partes: cinética, que descreve como os objetos se
movem, e dinâmica, a qual explica porque os objetos se movem. Baseado nos conceitos
da Mecânica (cinética e dinâmica), iremos apresentar no tópico 3.2 as considerações
sobre o movimento das aeronaves adotadas nos simuladores de Controle de Tráfego
Aéreo desenvolvidos no âmbito do IPV.
77
Fig. 3.1 – Ambiente de Controle de Torre (TWR).
Fig. 3.2 – Ambiente de Controle Radar (APP e ACC).
78
3.2 Consideração Sobre o Movimento da Aeronave:
O modelo de cinemática adotado nos simuladores de tráfego aéreo do IPV tem como
objetivo dar ênfase na representação adequada que resulte em uma boa representação
visual do movimento de aeronaves numa determinada porção do espaço aéreo que será
simulado.
Os parâmetros das aeronaves, por definição, assumem dois valores básicos que
representam o estado inicial e final desses parâmetros. O valor inicial ou atual
representa o estado atual do parâmetro, cujo valor foi atribuído inicialmente advindo da
base de dados de aeronaves, enquanto que o valor final ou de demanda, representa o
estado final desejado para aquele parâmetro. Em geral o valor final ou de demanda de
um parâmetro é atribuído durante o decorrer da simulação e pode ser alterado quantas
vezes forem necessárias.
Todos os parâmetros que descrevem o movimento das aeronaves nos simuladores, como
por exemplo: velocidade, altitude, razão de subida ou descida e aceleração, são
confrontados constantemente com os valores máximos e mínimos correspondentes ao da
tabela de performance. A tabela de performance contém uma descrição completa de
todos os parâmetros das aeronaves a serem simuladas. A atualização dos parâmetros da
aeronave é feita a cada segundo. No caso específico da cinemática dos simuladores do
IPV, o período de atua lização é da ordem de um segundo. (IPV, 1984).
A seguir, apresentaremos as fórmulas aplicadas para cálculo dos parâmetros das
aeronaves a serem simuladas.
3.2.1 Cálculo da Velocidade:
Dada a equação do módulo da velocidade para o movimento retilíneo com aceleração
constante:
V( t ) = Vo + a * t [1]
e considerando conhecida a velocidade em um instante “t” qualquer, para um instante
“t+dt”
79
V( t +dt ) = V( t ) + a * dt, [2]
Sendo “dt” o intervalo de tempo entre iterações(repetição do algoritmo), a equação
anterior poderá ser reescrita da seguinte maneira:
V( i ) = V( i-1 ) + a * dt. [3]
A projeção da velocidade da aeronave no plano YX nos dá a velocidade com relação ao
solo:
Vsolo = V( i ) [4]
Neste caso a velocidade no solo será igual a velocidade final, porque a velocidade final
não está sofrendo variações.
3.2.2 Cálculo da Posição da Aeronave:
O espaço percorrido pela aeronave em um tempo “t” qualquer é dado pela equação:
s( t ) = Vo * t + a . t² / 2 [5]
Para um instante “t+dt” temos:
s( t+dt ) = s( t ) + V( t ) * dt + a * (dt²) / 2 [6]
Portanto, o espaço percorrido entre os instantes “t” e “t+dt” é dado por:
ds = V( t ) * dt + a * (dt²) / 2 [7]
A direção do vôo é dada pela “proa atual” da aeronave graus em relação ao Norte.
Supõe-se que a direção Norte é apontada pelo eixo Y do sistema de referência. Assim as
componentes de “ds” em Y e X são:
dy = ds * cos (proa_atual) [8]
80
dx = - ds * sen (proa_atual) [9]
Fazendo “dt” igual ao intervalo de tempo entre iterações, para a posição da aeronave
relativa ao eixo x no instante t = i * dt, obtemos:
xa( i ) = xa(i-1) + dx(i) [10]
ya( i ) = ya(i-1) + dy(i) [11]
3.2.3 Cálculo da Proa:
A manobra de curva de uma aeronave é modelada como se fosse composta por uma
série de segmentos retilíneos de vôo, cada qual executando em uma nova direção.
Tendo como ponto de partida a proa no início da curva, uma nova proa é calculada a
cada intervalo dt:
Proa_a( i ) = Proa_a (i-1) + Razão_Curva * dt [12]
Proa_a é a proa da aeronave antes do início da curva.
Razão_Curva é a variação da proa no intervalo de tempo dt.
Uma nova posição da aeronave é então calculada. Este processo encerra-se quando a
proa atual da aeronave igualar-se à proa de demanda (proa final na manobra de curva).
3.2.4 Cálculo da Altitude:
Considerando a razão de subida ou descida r_sd podemos calcular o deslocamento da
aeronave em Y, que será dado por:
dy = r_sd * dt [13]
A projeção, no solo, do deslocamento da aeronave será:
dSsolo = sqrt ( ds² - dy² ) [14]
A altitude da aeronave é incrementada a cada intervalo de tempo dt e é dada por:
81
Alt_a( i ) = Alt_a( i -1) + dy [15]
A posição da aeronave a cada iteração é dada pelas equações [10 e 11].
A velocidade é obtida pela equação [1], enquanto que a velocidade no solo é calculada
por:
VSsolo = sqrt ( V² (i) – r_sd² ) [16]
Neste caso calcula-se novamente a velocidade no solo, porque a velocidade final está
sendo variada a cada iteração.
As iterações continuam até que a altitude atual iguale-se à altitude de demanda da
aeronave.
3.2.5 Cálculo de Interceptação de Baliza:
Nesta manobra são confrontados, a cada intervalo de tempo dt, os parâmetros x,y da
aeronave com o x,y da baliza para saber, se a aeronave interceptou a baliza em questão.
As equações a serem consideradas neste procedimento são: [10,11 e 12]. O processo
deverá ser repetido até que as coordenadas da aeronave e as coordenadas da baliza
igualem-se e a proa atual da aeronave seja igual à proa de demanda.
3.3 Considerações Finais:
Neste Capítulo foi apresentado algumas considerações sobre o ambiente de trabalho dos
controladores de tráfego aéreo e a importância que os simuladores de tráfego aéreo têm
para auxiliá- los no treinamento de suas funções. Na seqüência apresentamos a maneira
como a cinemática calcula os parâmetros das aeronaves. Finalmente, apresentamos as
equações de cinemática que atuam diretamente nos parâmetros da base de dados das
aeronaves.
Este Capítulo juntamente com o Capítulo 4 formam uma importante referência para
entendermos em primeiro lugar como são calculados e atualizados os dados dinâmicos
(velocidade, altitude e proa) de cada aeronave selecionada para a simulação. No
82
Capítulo 4 apresentaremos as regras de tráfego aéreo voltados para a execução dos
procedimentos automáticos (Decolagem, Subida, Trajetória, Espera e Pouso),
demonstrando, passo a passo o comportamento que uma aeronave deverá ter desde a
decolagem a té o pouso para cumprir o plano de vôo que foi designado.
83
CAPÍTULO 4
OS PROCEDIMENTOS AUTOMÁTICOS UTILIZADOS NOS SIMULADORES DE CONTROLE DE TRÁFEGO AÉREO
4.1 Descrição Geral:
No simulador de controle de tráfego aéreo os procedimentos automáticos são algoritmos
que têm a função de direcionar as aeronaves durante todas as fases de vôo, desde a
decolagem até o pouso. Na simulação os procedimentos automáticos podem ser
incorporados às aeronaves durante a simulação propriamente dita, ou durante a etapa de
criação das aeronaves onde elas podem ser planejadas com um procedimento
automático predeterminado (IPV, 1984).
Durante a simulação a mudança de procedimento poderá ser feita através da
comunicação via rádio entre o controlador e o piloto. Ao receber as ordens do
controlador o piloto imediatamente comanda a aeronave para realizar o novo
procedimento.
Os procedimentos automáticos podem ser criados e planejados de modo encadeado, isto
é, pode-se associar vários procedimentos automáticos para um único comando de
pilotagem. A aeronave ao receber este comando cumprirá o primeiro até o último
procedimento, ininterruptamente. Mas, para que isso ocorra é necessário que este
comando encadeado esteja anteriormente gravado na base de dados dos procedimentos.
Os procedimentos automáticos mais utilizados nos simuladores de controle de tráfego
aéreo são: Decolagem / Subida, Trajetória, Espera e Pouso.
Os procedimentos são subdivididos em fases. Cada fase representa um trecho bem
definido de cada procedimento. A aeronave permanecerá em uma determinada fase,
enquanto não atingir as condições que foram preestabelecidas para serem cumpridas.
Exemplo: uma aeronave foi programada para cumprir um procedimento de Espera
(ficar em órbita) num determinado fixo em uma determinada altitude. Se a aeronave não
estiver na altitude preestabelecida para chegar naquele fixo, a cada intervalo de tempo
84
“dt” ela executará o algoritmo correspondente àquela fase do procedimento de Espera
até que atinja a altitude programada. Após atingir a altitude preestabelecida a aeronave
poderá cumprir duas situações: ficará em Espera indefinidamente na mesma altitude e,
só abandonará o procedimento depois que receber um novo comando de pilotagem ou
irá cumprir outro procedimento logo que atinja a altitude estabelecida no fixo.
Nos simuladores de controle de tráfego aéreo desenvolvidos no IPV existem duas
entidades através das quais os controladores de tráfego aéreo interagem com o sistema.
Uma das entidades é a posição de Pilotagem, que é representada por uma tela de
pilotagem onde o controlador de tráfego aéreo ou outro operador habilitado pode pilotar
(dar comandos) até 6 aeronaves simultaneamente.
A outra entidade é a posição de Controle ou Console, a ser operada exclusivamente
por um controlador de tráfego aéreo sob treinamento, que tem a função de apresentar na
tela da console radar as aeronaves que serão pilotadas e as que serão conduzidas pelo
próprio sistema. As aeronaves conduzidas pelo próprio sistema não são pilotadas e, tem
apenas o objetivo de retratar em determinadas situações uma demanda de tráfego aéreo
acima do volume normal para treinar os controladores em situações anormais ou de
emergência.
Na posição de Controle tanto são apresentadas as imagens gráficas em 2D dos mapas
(rios, auxílios a navegação, fixos de balizamento e os contornos de setores) da região a
ser simulada como também o controlador poderá manipular comandos tanto para
aeronaves quanto para a própria tela de Controle. A Figura 4.1 mostra um exemplo de
detecção da aeronave pelo sinal radar e a Figura 4.2 mostra um exemplo da imagem
radar que o controlador de tráfego aéreo receberá na tela da Console Radar. A
representação do símbolo da aeronave na console depende da empresa fabricante da
console. Em seguida serão apresentados mais detalhes de cada procedimento
automático.
85
Fig. 4.1 - Aeronave detectada pelo sinal do Radar.
Fig. 4.2 - Representação gráfica 2D da Console Radar.
A Figura 4.2 mostra um cenário fictício onde procurou-se demonstrar os elementos que
compõem a representação gráfica em 2D de um determinado espaço aéreo. Essa
86
representação é composta por Aeronaves, Fixos(pontos) de balizamento, Setores,
Aerovias e Elipses que representam as órbitas que serão utilizadas pelas aeronaves para
o cumprimento do procedimento de Espera. Mais detalhes sobre a Espera está descrita
no tópico 4.4.
4.2 Procedimento de Decolagem / Subida:
Este procedimento representa o início do vôo de uma aeronave, onde serão considerados
os parâmetros de performance da mesma e os parâmetros referentes ao aeródromo para
dar prosseguimento à fase de decolagem. Este procedimento engloba as manobras
necessárias para uma decolagem e está dividido em três fases:
Preparação:
Na preparação é verificada se a aeronave está na pista e identificada a proa de
decolagem. Caso a proa da aeronave seja diferente da proa de decolagem é determinado
o sentido de curva para que a aeronave possa executar a curva pelo menor ângulo. A
velocidade inicial é igual a zero, a velocidade final será igual a velocidade de
decolagem e a altitude inicial e final será igual a altitude (elevação) do aeródromo.
Fase de Alinhamento com a Pista:
Verificada se a aeronave está com a proa de decolagem, se for diferente, a mesma
permanecerá fazendo curva até que atinja a proa de decolagem.
Fase de Corrida na Pista:
Durante esta fase a aeronave é acelerada no sentido da pista de decolagem e continuará
acelerando até que sua velocidade inicial alcance a velocidade de decolagem estipulada
na tabela de performance para cada tipo de aeronave.
Fase de Subida:
Após a aeronave atingir a velocidade de decolagem, ela iniciará uma subida até 500 pés,
no caso de helicópteros; ou 1000 pés, no caso de aeronaves com motor turbo hélice; ou
1500 pés, no caso de aeronaves à jato. Durante a subida será utilizada a razão de subida
na decolagem (pés/minuto) apropriado para a aeronave que estiver executando esta fase.
87
Sua velocidade final será inicializada para velocidade de subida na decolagem. A
aeronave só abandonará a fase de decolagem quando atingir a altitude estabelecida pelo
seu tipo e quando a velocidade final for igual à velocidade de subida na decolagem.
A Figura 4.3 abaixo apresentam as diversas fases dos procedimentos de Decolagem e
Subida.
Fig. 4.3 - Fases dos procedimentos de Decolagem/Subida.
4.3 Procedimento de Trajetória:
Nesta fase a aeronave cumprirá o deslocamento previsto em sua trajetória planejada
ponto a ponto, obedecendo as indicações de velocidades e altitudes programadas em seu
Plano de Vôo. Durante a evolução do vôo, desde a decolagem até o pouso, a aeronave
será conduzida de modo que possa atingir esses parâmetros durante todo o percurso.
Nos pontos que compõem a trajetória vêm descrita as informações de localização
(latitude e longitude), velocidade e altitude. Durante a simulação, quando a aeronave
interceptar um ponto, o piloto tanto poderá obter informações do ponto em questão
88
como também poderá saber qual será o próximo ponto a ser interceptado e qual será o
tempo estimado para o bloqueio (chegada no ponto).
O procedimento de Trajetória também é subdivido em fases. A fase inicial prepara a
aeronave através de rotinas internas a se dirigir ao primeiro ponto da trajetória a ser
interceptado, como também ajustará sua velocidade e altitude para alcançar os mesmos
parâmetros do fixo em questão. A segunda fase verificará a cada intervalo dt se a
aeronave conseguiu interceptar o fixo a ser atingido, caso não tenha conseguido, esta
fase procurará colocar a aeronave na direção correta do fixo até que seja interceptado. A
terceira e última fase verificará se existem mais fixos a serem interceptados, se existir
remete a aeronave a cumprir a segunda fase, caso contrário remeterá a aeronave ao
procedimento de Pouso, e finalizará o procedimento de Trajetória.
4.4 Procedimento de Espera:
Quando um número grande de aeronaves se aproxima de um mesmo aeródromo, pode
haver a necessidade de se efetuarem procedimentos de Espera. Uma Espera é uma
manobra pré determinada que mantém a aeronave dentro de um espaço aéreo
especificado, enquanto esta aguarda autorização para executar um procedimento de
aproximação. Constitui-se das seguintes partes como mostra a Figura 4.4.
Fig. 4.4 - Etapas que compõem o procedimento de Espera.
89
Cada uma dessas etapas dura 1 minuto. As curvas devem ser efetuadas à razão constante
de 1,5 e 3 graus/seg. dependendo da altitude da aeronave. As Esperas são divididas em
setores, porém, para se entrar na Espera, deve-se efetuar o tipo de entrada que esteja de
acordo com o setor da Espera em que se está aproximando. A Figura 4.5 abaixo
demonstra as diversas maneiras de realizar as Esperas.
Fig. 4.5 - Maneiras de realizar o procedimento de Espera.
Este procedimento é bastante utilizado nos seguintes casos:
A aeronave ao bloquear o último ponto da trajetória se estiver com os parâmetros de
velocidade e altitude incompatíveis para o pouso, ficará em órbita (Espera) neste ponto
até que atinja as condições para realizar o pouso;
90
De maneira antecipada o controlador de tráfego aéreo, prevendo que não haverá a
possibilidade para o pouso, comunicará ao piloto para que num determinado ponto da
trajetória a aeronave diminua sua velocidade e permaneça em órbita até que a situação
no aeroporto esteja normalizada. Assim que houver a possibilidade de pouso a aeronave
abandonará a Espera e seguirá para o aeródromo de pouso.
4.5 Procedimento de Pouso:
Este procedimento envolve as manobras necessárias para o pouso de uma aeronave. As
fases do procedimento de pouso estão apresentadas na Figura 4.7. A seguir
apresentaremos os detalhes de cada fase:
Fase de Preparação (fase 0).
Nesta fase é verificada a posição da aeronave em relação à pista de pouso e, em função
desta posição, a mesma é remetida para uma fase posterior. De acordo com a posição da
aeronave temos:
Caso 1:
“Aeronave à uma distância lateral do eixo da pista, maior ou igual à 2 vezes o raio de
curva da aeronave (2R) e à uma distância da cabeceira, maior que 3R+Dist_Rampa1”.
Neste caso, a aeronave iniciará uma curva (aproximando-se da pista) para uma proa
perpendicular ao eixo da pista e será remetida para a fase de interceptação do eixo da
pista (fase 3). As distâncias 2R e 3R + Dist_Rampa são utilizadas para garantir que,
independente da proa da aeronave, esta terá condições de executar as manobras
necessárias para se alinhar com o eixo da pista de pouso antes de atingir o início da
rampa de descida (Figura 4.6).
Caso 2:
“Aeronave à uma distância lateral do eixo da pista maior ou igual a 2 vezes o raio de
curva da aeronave (2R), porém a uma distância da cabeceira menor que
1 Dist_Rampa é a projeção no solo da distância que a aeronave deverá percorrer para descer de sua altitude atual até a altitude da pista de pouso, mantendo a razão de descida e a velocidade.
91
3R+Dist_Rampa”. Estando nessa situação a aeronave iniciará uma curva (afastando-se
da pista) para uma proa defasada de 180° da direção de pouso e será desviada para a
fase 2 do procedimento.
Caso 3:
“Aeronave no eixo da pista e voando na mesma direção do pouso”. Se a distância entre
a aeronave e a cabeceira da pista de pouso for maior que Dist_Rampa a aeronave será
remetida para a fase de interceptação de rampa - fase 5. Caso contrário, a aeronave
iniciará uma curva para a esquerda com proa perpendicular ao eixo da pista e será
remetida para a fase 1 do procedimento - fase de afastamento do eixo. O mesmo deverá
ocorrer caso a aeronave esteja voando no eixo da pista, porém em sentido contrário ao
pouso.
Caso 4:
“Aeronave voando a uma distância lateral do eixo da pista menor que 2R”. Neste caso a
aeronave iniciará uma curva para uma proa perpendicular ao eixo da pista e será
remetida para a fase 1 do procedimento. Se a aeronave estiver à esquerda da pista de
pouso, a nova proa será dada por : rumo da pista - 90°. Caso a aeronave esteja à direita
da pista, a nova proa será: rumo da pista + 90°.
Fig. 4.6 Condições limitantes de curva.
92
Fase de Afastamento do Eixo (fase 1).
Durante esta fase a aeronave voará até atingir uma distância lateral - com relação ao
eixo da pista - maior ou igual a 2R. Ao atingir essa distância a mesma retornará para a
fase de preparação (fase 0).
Fase de Vôo na Perna do Vento (fase 2).
Nesta fase a aeronave voará na perna do vento - rumo oposto ao da pista de pouso - até
afastar-se a uma distância R+Dist_Rampa da cabeceira da pista. Ao atingir essa
distância, iniciará uma curva para uma proa perpendicular ao eixo da pista, de modo a
aproximar-se desse eixo. Após iniciar a curva a aeronave é remetida para a fase 3.
Fase de Interceptação do Eixo da Pista (fase 3).
Durante essa fase a aeronave irá se aproximar do eixo da pista até uma distância R. Ao
atingir essa distância a aeronave iniciará uma curva para alinhar-se com a pista,
ingressando na fase 4.
Fase de Alinhamento com o Eixo da Pista (fase 4).
Nessa fase a aeronave estará fazendo uma curva buscando o alinhamento inicial com o
eixo da pista. Isto ocorrerá quando a proa da aeronave for igual ao rumo da pista de
pouso. Neste instante a aeronave passará para a fase 5.
Fase de Interceptação da Rampa (fase 5).
Se até atingir a cabeceira da pista a aeronave não conseguir interceptar a rampa de
descida prevista, a mesma iniciará uma curva à esquerda para uma proa perpendicular
ao eixo da pista, retornando para a fase 1 do procedimento. Caso consiga interceptar a
rampa, a aeronave começará a descer com uma razão de descida adequada para se
manter nesta rampa. Durante sua permanência nesta fase a aeronave estará corrigindo
seu alinhamento com relação ao eixo da pista. Ao interceptar a rampa a aeronave é
remetida para a fase 6.
93
Fase de Rampa (fase 6).
A aeronave continuará sua descida até atingir a altitude da pista. Ao tocar a pista a
aeronave sofrerá uma desaceleração - aceleração negativa - em seu movimento - e
passará para a fase 7.
Fase de Corrida na Pista (fase 7).
Ao atingir a velocidade de deslocamento no solo, se existir um procedimento de táxi
associado à aeronave, esta abandonará o procedimento de pouso e iniciará o
procedimento de táxi. Caso contrário, continuará correndo na pista até que a sua
velocidade seja igual a zero.
94
Fig. 4.7 - Fases do procedimento de Pouso.
95
CAPÍTULO 5
ESTRUTURAS (EM MEMÓRIA) DE SUPORTE À SIMULAÇÃO
5.1 Descrição Geral:
Neste Capítulo apresentaremos a descrição do comportamento do vôo de uma aeronave
em sua trajetória desde a decolagem até o pouso e, uma descrição dos órgãos de
proteção ao vôo que farão a monitoração e o controle durante todo o seu percurso. Em
seguida será feita uma descrição detalhada de todas as estruturas que serão montadas em
memória “on line” a partir da conversão de diversos arquivos que compõem a Base de
Dados ATFM “off line”, pelo subsistema Supervisor, o qual possibilitará a execução da
simulação. Paralelamente apresentaremos as novas tabelas que serão geradas após a
simulação denominadas de “resultado da simulação” que possibilitarão a apresentação
gráfica da demanda de tráfego aéreo de qualquer região do país, pelo subsistema
Apresentação Gráfica de Resultado da Simulação.
5.1.1 Modelando o Vôo:
Para se entender a exata dimensão do serviço de tráfego aéreo é útil a descrição dos
órgãos ATC envolvidos e das etapas pelas quais passa uma aeronave que, por exemplo,
decola do Aeroporto Internacional Salgado Filho em Porto Alegre com destino ao
aeroporto de Congonhas em São Paulo. Para executar tal viagem, inicialmente é
necessário o fornecimento de informações específicas aos órgãos prestadores de serviço
de tráfego aéreo, relacionadas com o vôo planejado. Tais informações são passadas por
intermédio de um plano de vôo que possui, entre outros detalhes, o nível no qual a
aeronave voará e a rota a ser seguida. Desta maneira o comandante solicita autorização
para realizar o vôo.
O primeiro órgão ATC que entrará em contato com a aeronave é a Torre de Controle
do Aeroporto Salgado Filho. Ela representa o órgão estabelecido para proporcionar
serviço de controle de tráfego aéreo às aeronaves que evoluem nas proximidades do
aeródromo e nas áreas de manobras no solo. Chama-se ATZ a região do espaço aéreo de
96
dimensões definidas, estabelecida em torno de um aeródromo e que fica sob jurisdição
da torre de controle. Em horários de pico, os controladores que trabalham em aeroportos
mais movimentados exercem suas atividades sob forte tensão, ficando, por vezes, no
limite para cometerem erros.
Após sair da ATZ do aeroporto Salgado Filho a aeronave entrará na área de controle
terminal (TMA) Porto Alegre . Uma TMA é situada geralmente na confluência de
Rotas ATS e nas imediações de um ou mais aeródromos, recebendo o nome da principal
cidade nela localizada. As áreas de controle terminal possuem configuração variável
indicada nas publicações da DEPV (Diretoria de Eletrônica e Proteção ao Vôo). A TMA
Porto Alegre, por exemplo, possui formato de um cilindro com 54 milhas náuticas de
raio, elevando-se até o nível de vôo (FL) 195 (aproximadamente 19500 pés de altitude).
Desta forma, uma aeronave pode sair da TMA Porto Alegre quando ultrapassar as 54
milhas ou quando cruzar o FL 195.
Após deixar a TMA Porto Alegre, a aeronave ingressará em uma aerovia sob jurisdição
do Centro de Controle de Área (ACC) Curitiba. O Serviço de Controle de Área é o
serviço de tráfego aéreo prestado especificamente aos tráfegos que evoluem em áreas de
controle (aerovias) com a finalidade de proporcionar separações adequadas.
O Brasil possui atualmente sete Centros de Controle de Área localizados em Curitiba,
Brasília, Recife, Belém, Manaus, Porto Velho e Campo Grande. Antes de chegar à
TMA São Paulo a aeronave proveniente de Porto Alegre deve ainda passar por parte da
aerovia controlada pelo Centro de Controle de Área de Brasília, isto ocorre porque a
aeronave está com a altitude incompatível para entrar na TMA São Paulo. Por fim a
aeronave entrará na TMA São Paulo sendo conduzida até as proximidades do Aeroporto
de Congonhas onde pousará quando autorizada pela Torre de Controle desse aeroporto.
A maioria dos vôos que ocorrem diariamente no Brasil passam por processos
semelhantes. Nos últimos anos o crescimento médio anual de movimentos na área de
controle terminal (TMA) São Paulo foi superior a 13%, considerando-se pousos e
decolagens nos aeroportos Internacional de São Paulo (Guarulhos), Congonhas e Marte.
97
A Figura 5.1 retrata bem esta realidade. Nesta e em outras áreas de controle terminal
do país a demanda de vôos começa a exceder as capacidades de alguns setores do
espaço aéreo e de aeroportos. As autoridades aeronáuticas vêm sendo obrigadas a tomar
medidas consideradas restritivas ao vôo que, por conseguinte, geram um certo nível de
insatisfação aos usuários dos aeroportos, principalmente das companhias aéreas que
dependem diretamente do Serviço de Controle de Tráfego Aéreo.
Fig. 5.1 - Crescimento de demanda nos aeroportos de Congonhas,
Internacional de São Paulo/Guarulhos e Marte.
FONTE: SRPV-SP (Serviço Regional de Proteção ao Vôo de São Paulo).
A explanação do vôo Porto Alegre à São Paulo teve como meta principal descrever em
detalhes todas as etapas que envolvem um vôo e, como são envolvidos os órgãos
operacionais nesse contexto. Porém, este texto teve o objetivo de demonstrar a que nível
de detalhes deverá chegar o Protótipo do Sistema de Simulação Acelerado para Análise
de Fluxo de Tráfego Aéreo para poder cumprir a simulação de diversos vôos em
qualquer região do país.
A seguir apresentaremos todos os detalhes da criação e montagem das estruturas que
ficarão em memória para dar suporte à simulação. Após a simulação os dados dessas
1 2 4 5 1 4
1 0 6 9 8 5
828267 6 2 2 7
1 4 7 5 8 81 3 4 6 3 0
2 1 0 1 8 1
1 8 2 2 3 91 7 3 5 8 4
160202
1 2 6 3 2 71 4 4 6 5 5
1 5 4 2 9 41 7 0 8 3 2
1 9 1 8 1 0
0
5 0 0 0 0
1 0 0 0 0 0
1 5 0 0 0 0
2 0 0 0 0 0
2 5 0 0 0 0
1 9 9 3 1994 1 9 9 5 1996 1 9 9 7 1998 1 9 9 9A N O S
NÚ
ME
RO
DE
MO
VIM
EN
TO
S
C O N G O N H A S
G U A R U L H O S
C A M P O D E M A R T E
98
estruturas serão utilizados pelo Sistema de Simulação Acelerado para Análise de Fluxo
de Tráfego Aéreo para a gerar as tabelas de “resultado da simulação”.
5.2 Estrutura de Pontos Característicos:
Este arquivo é fornecido pelos Centros de Controle de Área (ACC) de cada região de
FIR do Brasil na qual possibilita montar as trajetórias das aeronaves, estabelecer limites
entre os setores da mesma região e de diferentes regiões, bem como estabelecer o
contorno de regiões com os seus diversos setores. Este arquivo, após ser lido pelo
subsistema Supervisor, será convertido e montado em memória cujo objetivo é dar
suporte ao Sistema de Simulação Acelerado para Análise de Fluxo de Tráfego Aéreo
durante os cálculos de transferência e contabilização de setores.
A estrutura de Pontos Característicos são armazenadas as informações de identificação
do ponto, localização e os setores de fronteira que fazem parte daquela porção do
espaço aéreo. Essa estrutura é responsável pelo armazenamento dos dados referentes aos
pontos de balizamento e suas informações são de vital importância para a simulação
porque Sistema de Simulação Acelerado para Análise de Fluxo de Tráfego Aéreo
necessitará única e exclusivamente de seus dados para proceder o deslocamento das
aeronaves nos pontos de cada trajetória bem como para proceder a transferência e a
contabilização entre os setores que estão identificados nesses pontos.
Para a simulação, um ponto é identificado como sendo de fronteira quando os campos
identificadores de setores dessa estrutura (Tabela 5.1) estiverem preenchidos pelo
menos com duas indicações de fronteira. Nessa estrutura os campos de setores podem
ser preenchidos no máximo com 6 indicações de setores de fronteira. Porém, para saber
a disposição dos setores num ponto de fronteira torna-se necessário conhecer através da
carta de vôo da região a distribuição de cada setor envolvido, porque os setores podem
estar distribuídos lado a lado ou em camadas (empilhados), como mostra a Figura 5.2
abaixo representando as duas formas de distribuição de setores numa região fictícia.
99
Ponto Característico
Ponto Característico
Fig. 5.2 - Representação de Setores.
TABELA 5.1 – ESTRUTURAS DE PONTO CARACTERÍSTICOS “ON LINE “
TTii ppoo Nome Tamanho Bytes
Descrição
Character PtoNome 5 Nome do ponto Float PtoX 4 Coordenada X do ponto Float PtoY 4 Coordenada Y do ponto Float PtoRaioCone 4 Raio do cone Integer - Array PtoSetor 6 Índice dos Setores de Fronteira
Os pontos descritos na Tabela 5.2 abaixo, fazem parte da rota São Paulo – Rio de
Janeiro. São identificados por siglas que representam no geral os setores de uma
determinada região do país. Exemplo, a sigla SBXP01 identifica o setor 1 da Área
Terminal (TMA-SP) de São Paulo. SBBS01 identifica o setor 1 da Região de Brasília e
SBWJ05 representa o setor 5 da Área Terminal do Rio de Janeiro (TMA-RJ).
Setorização lado à lado
A
B
C
A
B
C
Setorização lado à lado e em camada
100
TABELA 5.2 – EXEMPLO DE DADOS DE PONTO CARATERÍSTICO
NOME MAVKA EGODO KONKO
Coordenada X 12423527.19219 12423527.19219 12423527.19219
Coordenada Y 12423527.19219 12423527.19219 12423527.19219
SETOR - 1 SBXP01 SBXP06 SBXP06
SETOR - 2 SBXP06 SBWJ05 SBWJ05
SETOR - 3 SBBS01 SBBS11 SBBS11
SETOR - 4 SBBS02 ---- SBWJ01
SETOR - 5 ---- ---- ----
SETOR - 6 ---- ---- ----
5.3 Estrutura de Plano de Vôo:
A estrutura de Plano de Vôo é formado basicamente por dois tipos de vôos: o tipo RPL
e FPL. O Plano de Vôo Repetitivo (RPL) é o plano de vôo relativo a uma série de vôos
regulares, com base em Horários de Transporte (HOTRAN) ou Horário de Transporte
Regional (HOTREG), que se realizam freqüentemente com idênticas características
básicas, apresentado pelos exploradores (Companhia Aéreas) aos órgãos ATS.
Os vôos regulares caracterizam-se por serem na verdade “intenções de vôos”, isto
significa que esses vôos podem ou não acontecer conforme foram planejados. Os
principais motivos que levam à não execução desses vôos, são em geral devidos aos
cancelamentos efetuados pela própria companhia aérea ou por alguma problema interno
no aeroporto por exemplo: baixa visibilidade, chuvas na cabeceira da pista, etc.
Diferentemente dos vôos regulares, os vôos não regulares ou eventuais (FPL) são
aqueles que precisam ter o aval do DAC, mas que sua ocorrência só é registrada no dia
do vôo. Toda as vezes que o piloto ou uma determinada companhia aérea necessita
realizar um vôo, eles precisam dirigir-se a uma sala AIS no local do vôo e preencher um
formulário com o plano de vôo a ser executado. No caso dos vôos regulares estes
formulários de plano de vôo são enviados pelas companhias aéreas a cada 15 dias para
101
apreciação do DAC. A realização ou não dos vôos não regulares ficará condicionada às
condições e restrições do aeroporto, bem como à permissão do serviço de tráfego aéreo.
Esta estrutura (Tabela 5.3 e Tabela 5.4) contém um conjunto de aeronaves de vários
tipos e categorias, porém o Plano de Vôo é exclusivo para cada aeronave. Um plano de
vôo é montado a partir do aeródromo de partida (decolagem), que é extraído do arquivo
de aeródromos. Em seguida montam-se as informações de cada ponto característico,
obedecendo as informações de velocidade, altitude e setorização e, por fim, agrega-se o
aeródromo de chegada, que também será extraído do arquivo de aeródromos.
Durante a modelagem das estruturas “on line” Plano de Vôo e Ponto Característicos
verificou-se que algumas informações ficariam repetidas então, decidiu-se normaliza- las
e atribuir um identificador na estrutura Plano de Vôo para que pudéssemos interliga- las.
Portanto, quando o Sistema de Simulação Acelerado para Análise de Fluxo de Tráfego
Aéreo for verificar se o ponto é de fronteira, ele obterá o índice do ponto que está na
estrutura Plano de Vôo e através dele acessará a estrutura Ponto Característico para
obter outras informações do ponto, por exemplo: as coordenadas do ponto e os setores
de fronteira.
A estrutura Plano de Vôo é subdividida em 2 duas partes: a primeira descreve as
informações referentes ao plano de vôo, a segunda parte descreve as informações
detalhadas de cada ponto característico que compõem o plano de vôo.
A seguir apresentaremos a estrutura do Plano de Vôo que ficará em memória (“on line”)
durante todo o processo de simulação, a tabela de Plano de Vôo (Tabela 5.5) que será
gerada e armazenada no Banco de Dados ATFM no ORACLE após a simulação e por
fim um exemplo dos dados dessa estrutura em memória (Tabela 5.6).
TABELA 5.3 – ESTRUTURA DE PLANO DE VÔO “ON LINE” - PRINCIPAL
TTii ppoo Nome Tamanho Bytes
Descrição
Integer PlnQtdBkp 4 Quantidade de breakpoints (pontos) BREAKPOINT PlnNBkp 100 Descrição dos atributos do breakpoint
102
TABELA 5.4 – ESTRUTURA DE BREAKPOINT “ON LINE” - ASSOCIADO
TTii ppoo Nome Tamanho Bytes
Descrição
Integer BkpIndPto 4 Índice para a estrutura Pontos Característicos Float BkpAlt 4 Altitude do breakpoint Float BkpVel 4 Velocidade do breakpoint Integer BkpHoraBloq 4 Horário de bloqueio
TABELA 5.5 – TABELA DE PLANO DE VÔO
TTii ppoo Nome Tamanho Bytes
Descrição
Integer PLNNumProc 6 Número do procedimento a cumprir Integer PLnNumBKP 6 Número do breakpoint Character PLNData 10 Data de execução da simulação Integer PLNAltitude 6 Altitude do tráfego Integer PLNVelocidade 6 Velocidade do tráfego Character PLNNomePto 5 Nome do Ponto de bloqueio Integer PLNHoraBloq 10 Hora de bloqueio no ponto Integer PLNSetorEnt 4 Índice do Setor de Entrada
TABELA 5.6 – EXEMPLO DE DADOS DA ESTRUTURA DE PLANO DE VÔO
N. Plano Qtd. Pontos DATA
01 3 26/02/2001
Índice do Pto. Altitude (Ft) Velocidade(Kt) HoraBloqueio SetorEntrada
03 19300 230 10:42 10
15 16500 240 10:48 ---
34 10600 330 10:55 22
Descrição sucinta dos campos que compõe a estrutura de um Plano de
Vôo:
N. Plano: identifica o número do Plano de Vôo que será associada a uma aeronave.
Qtd. Pontos: indica a quantidade de pontos que a aeronave deverá seguir.
Data: data que foi realizada a simulação.
103
Índice do Ponto: índice para acessar informações de localização e setores de fronteira
na estrutura de pontos característicos.
Altitude: altitude recomendada para atingir o ponto característico.
Velocidade: velocidade recomendada para atingir o ponto característico.
HoraBloqueio: horário registrado quando a aeronave atingir o ponto característico.
SetorEntrada: índice do setor de entrada quando o ponto for de fronteira.
5.4 Estrutura de Aeronaves:
Esta estrutura (Tabela 5.7) contém todas as informações referentes aos dados dinâmicos
das aeronaves como também os dados de performance e os dados relativos ao seu Plano
de Vôo. Os dados dinâmicos são por definição parâmetros da aeronave como, por
exemplo, velocidade, altitude e proa, que serão alterados pelo Sistema de Simulação
Acelerado para Análise de Fluxo de Tráfego Aéreo a cada delta t (dt) durante a
simulação, diferentemente dos dados estáticos que são aqueles que apenas contribuem
de maneira informativa para a simulação, por exemplo: Identificação do aeroporto de
decolagem, horário de decolagem, tipo da aeronave, etc.
Para montar os dados referentes às aeronaves em memória o Supervisor em primeiro
lugar realiza várias pesquisas em diversas tabelas do Banco de Dados ATFM para
poder extrair os dados necessários para a montagem dessa estrutura. As tabelas a serem
pesquisadas são: Aeródromo, Performance, Setores e Plano de Vôo. Da tabela de
aeródromos são extraídos os indicativos dos aeródromos de partida e chegada, os
horários de pouso e de decolagem. A tabela de performance fornecerá um índice que
fará a ligação entre o tipo de aeronave com a sua respectiva performance. Da tabela de
setores obtém-se os setores atual e anterior. Por fim, a tabela Plano de Vôo fornecerá
um índice (identificador) o qual indicará o número do Plano de Vôo que a aeronave
deverá realizar. Após ter montado esta estrutura em memória, o subsistema Supervisor
ativará o Sistema de Simulação Acelerado para Análise de Fluxo de Tráfego Aéreo para
dar início a dinâmica da simulação.
104
A dinâmica da simulação dar-se-á a partir da primeira aeronave que iniciou o vôo no dia
anterior a data escolhida pelo gerente ATFM e pousará no dia seguinte. Mais
informações sobre a tarefa de simular tráfego está descrito com riqueza de detalhes no
Capítulo 6 dessa dissertação. Portanto, nesse parágrafo, abordaremos de maneira sucinta
como se dá o processo de simulação. As aeronaves serão ativadas na simulação quando
o horário de decolagem for igual ao número de ciclos (repetições) por segundo que
Sistema de Simulação Acelerado para Análise de Fluxo de Tráfego Aéreo estará
realizando para promover a evolução das aeronave em suas trajetórias (plano de vôo),
desde a decolagem até pouso. A finalização da simulação ocorrerá quando o número de
repetições chegar a 86400 ciclos, que representa 1(um) dia simulado.
Finalizada a simulação pelo Sistema de Simulação Acelerado para Análise de Fluxo de
Tráfego Aéreo, os dados desta estrutura serão transformados e carregados em uma nova
tabela que será chamada de Eventos de Tráfegos (Tabela 5.8). Esta tabela fará parte de
um conjunto de tabelas que por definição serão responsáveis pelo “resultado da
simulação”, que por conseguinte, serão utilizadas pelo subsistema Apresentação Gráfica
para realizar as apresentações das demandas de tráfego aéreo de cada região do país. A
seguir apresentaremos a estrutura da Aeronave em memória e a estrutura da tabela de
Eventos de Tráfegos que será gerada após a simulação.
105
TABELA 5.7 – ESTRUTURA DE AERONAVE “ON LINE”
TTii ppoo Nome Tamanho Bytes
Descrição
Character AnvDesignador 4 Designador da aeronave Character AnvIndicativo 8 Indicativo da aeronave Character AnvEsteira 1 Esteira da Aeronave. L (leve) M (Média) e H Integer AnvConsumo 4 Consumo Character AnvOrigem 4 Aeródromo de Origem Character AnvDestino 4 Aeródromo de Destino Integer AnvIndAerArr 4 Índice do aeródromo de chegada Integer AnvHoraDep 4 Hora de Decolagem Integer AnvHoraPouso 4 Hora de Pouso Character AnvEstAtv 1 [A] ativa, [P] Pendente ou [F] Finalizada Character AnvFncOpe 1 Trajetória [T] Integer AnvFase 4 Fase do procedimento Integer AnvNumProc 4 N° do procedimento Integer AnvNumBkp 4 N° do breakpoint (ponto) atual Float AnvTpoAtv 4 Tempo de ativação da Anv – Simulação Real Float AnvIndPreAtv 4 Índice Pré de ativação da aeronave Float AnvIndAteT0 4 Índice até T0 Float AnvX 4 Coordenada X da aeronave Float AnvY 4 Coordenada Y da aeronave Float AnvAltAtu 4 Altitude atual da aeronave Float AnvAltDem 4 Altitude de demanda da aeronave Float AnvProaAtu 4 Proa atual da aeronave Float AnvProaDem 4 Proa de demanda da aeronave Float AnvVelAtu 4 Velocidade atual da aeronave Float AnvVelDem 4 Velocidade de demanda da aeronave Float AnvVelGnd 4 Velocidade de solo da aeronave (ground) Float AnvRazSub 4 Razão de subida e descida da aeronave Float AnvRazCrv 4 Razão de curva da aeronave Float AnvAceleracao 4 Aceleração da aeronave Integer AnvSetorAtu 4 Número do setor atual dentro da FIR Integer AnvSetorAnt 4 Número do setor anterior dentro da FIR Integer AnvIndPerfor 4 Índice para a tabela Performance Integer AnvOrigemVoo 4 [ 1 ] Origem Exterior – [ 0 ] Origem Nacional
106
TABELA 5.8 – TABELA DE EVENTOS DE TRÁFEGO
TTii ppoo Nome Tamanho Bytes
Descrição
Integer TRAIndice 4 Índice de acesso ao tráfego Character TRAData 10 Data de execução da simulação Character TRADesignador 4 Designador do tráfego Character TRAIndicativo 7 Indicativo da tráfego Character TRAAerodDep 4 Aeródromo de Decolagem Character TRAAerodArr 4 Aeródromo de Chegada - Pouso Integer TRAHoraDep 6 Horário de Decolagem Integer TRAHoraArr 6 Horário de Pouso Integer TRANumProc 6 Número do procedimento a cumprir Character TRATipoTrafego 2 Tipo do tráfego – RPL ou FPL
5.5 Estrutura de Aeroportos:
Esta estrutura online (Tabela 5.9) armazenará todas as informações referentes aos
aeroportos nacionais e internacionais que estão cadastrados na tabela de Aeródromos
que pertence à Base de Dados ATFM. Os dados do aeródromo são de vital importância
para a simulação, principalmente no que diz respeito aos movimentos de pouso e
decolagem que serão confrontados com a sua capacidade, como também no tratamento
de vôos que pousam no exterior. No Capítulo 6 apresentaremos mais detalhes desses
tópicos. A seguir apresentaremos a estrutura online dos aeródromos.
TABELA 5.9 – ESTRUTURA DE AEROPORTOS “ON LINE “
TTii ppoo Nome Tamanho Bytes
Descrição
Character AerIndicICAO 4 Indicativo do aeródromo da ICAO Character AerIndicIATA 4 Indicativo do aeródromo da IATA Character AerNome 45 Nome do aeródromo Float AerCapTotal 4 Capacidade total do Aeródromo Float AerCapReg 4 Capacidade de Vôos Regulares do Aeródromo Float AerElevacao 4 Elevação do aeródromo Float AerX 4 Coordenada X do Aeródromo Float AerY 4 Coordenada Y do Aeródromo Float AerRumoDep 4 Rumo da pista de decolagem Integer AerSetor 4 Setor/Região a qual pertence o Aeródromo
107
5.6 Estrutura de Setores:
Essa estrutura “on line” armazenará todas as informações referentes a todos os Setores
de todas as regiões do país. A montagem dos setores em memória obedeceu a relação e
a seqüência de todos os setores de FIR, TMA e CTR do espaço aéreo brasileiro. A
setorização além da fronteira do Brasil, a princípio não será levado em consideração
nessa dissertação. A evolução das aeronaves, bem como sua transferência e
contabilização entre setores dar-se-á apenas no território brasileiro.
Para o objetivo dessa dissertação essa estrutura é de vital importância, porque será
através das suas informações que será possível ao Sistema de Simulação Acelerado para
Análise de Fluxo de Tráfego Aéreo executar a transferência e a contabilização da
demanda de tráfegos em todas as regiões do país, além de servir de base para a estrutura
de Eventos que será apresentada no tópico 5.7. A seguir apresentaremos a estrutura de
Setores em memória (Tabela 5.10) e a tabela de Setores (Tabela 5.11) que será gerada
após a simulação.
TABELA 5.10 – ESTRUTURA DE SETORES “ON LINE “
TTii ppoo Nome Tamanho Bytes
Descrição
Integer SetDemanda 4 Demanda do setor Integer SetCapacidade 4 Capacidade do setor Float SetNivelInf 4 Nível Inferior do Setor da FIR,TMA,CTR Float SetNivelSup 4 Nível Superior do Setor da FIR,TMA,CTR Integer SetPercent 4 Percentual de Alerta no Setor de FIR,TMA,CTR Character SetTipoSetor 1 Tipo do setor - F (FIR), T (TMA), C (CTR)
TABELA 5.11 – TABELA DE SETORES
TTii ppoo Nome Tamanho Bytes
Descrição
Integer SETIndice 3 Índice do Setor Character SETData 10 Data de execução da simulação Integer SETCapacidade 3 Capacidade do Setor Integer SETNivelAlerta 3 Nível de Alerta Character SETIndicativo 6 Indicativo do Setor
108
5.7 Estrutura de Eventos:
Esta estrutura “on line” (Tabela 5.12) armazenará todas as informações referentes a
todos os Eventos que são gerados em decorrência das transferências das aeronaves na
mudança de setores. Durante a simulação o Sistema de Simulação Acelerado para
Análise de Fluxo de Tráfego Aéreo produzirá eventos de entrada e de saída no instante
em que a aeronave interceptar um ponto que seja de fronteira.
Portanto, esta estrutura armazenará o histórico do vôo das aeronaves durante sua
passagem nas regiões, como também fornecerá ao subsistema de Apresentação Gráfica
dos Resultados da Simulação, os dados necessários para a montagem gráfica da
demanda de tráfego aéreo de qualquer região do Brasil que tenha sido selecionada pelo
gerente ATFM.
Os dados da estrutura de Eventos são subdivididos em 3 tipos de categoria de eventos a
saber: eventos de aeroportos ou aeródromos, eventos de Fixos ou de pontos
característicos e eventos de Setores.
Os eventos de aeródromos são produzidos sempre que a aeronave iniciar os
procedimentos de Decolagem e Pouso. No Sistema de Simulação Acelerado para
Análise de Fluxo de Tráfego Aéreo o procedimento de Decolagem provocará a criação
do evento de “entrada no setor” em que se encontra o aeródromo de decolagem. No
procedimento de Pouso é gerado o “evento de saída” do setor em que se encontra o
aeródromo de Pouso (chegada).
Os eventos de Setores são gerados no momento em que a aeronave intercepta um ponto
que seja de fronteira. No instante da interceptação são gerados dois eventos
simultaneamente, um de entrada que representa que a aeronave está entrando num novo
setor e um de saída que representa que a aeronave está deixando o setor anterior.
Semelhantemente ao evento de Setores, os eventos de Fixos são gerados no momento
em que a aeronave intercepta um ponto(fixo), porém, este ponto não precisa,
obrigatoriamente, ser de fronteira. A razão pela qual se decidiu pela geração de eventos
de fixos, foi em decorrência da real necessidade que os órgãos de controle de tráfego
109
aéreo têm de saber o volume de tráfego aéreo que cruza um determinado fixo, num
determinado instante. Essa informação é muito preciosa para os controladores de tráfego
aéreo porque, dependendo do volume de tráfego aéreo nesse fixo, os controladores
poderão redirecionar o trânsito aéreo para outra rota ou para outro fixo menos
congestionado. O objetivo de redirecionar o fluxo aéreo para outra fixo menos
congestionado ou mesmo para outra rota (aerovia), diz respeito a procurar aliviar a
carga de trabalho dos controladores de tráfego aéreo principalmente quando esse fixo
tratar-se de um fixo de entrada na área terminal (TMA). No Capítulo 6 e 7,
apresentaremos mais detalhes sobre a sistemática de transferência e contabilização de
aeronaves entre setores.
A seguir apresentaremos a estrutura de Eventos em memória e a tabela de Eventos
(Tabela 5.13) que será gerada após a simulação.
TABELA 5.12 – ESTRUTURA DE EVENTOS “ON LINE “
TTii ppoo Nome Tamanho Bytes
Descrição
Integer EveIndiceSetorAtual 6 Setor corrente Integer EveHora 6 Horário de entrada setor Character EveData 10 Data de execução da simulação Integer EveQtdAnvSetorAtual 6 Quantidade de aeronaves no setor atual Integer EveIndiceAeronave 6 Índice da aeronave na estrutura Tráfego Character EveTipo_ES 1 Tipo do evento – [E ]Entrada – [S] Saída Integer EveEstado 1 1-Normal, 2-Congestionado, 3-Saturado Character EveNomePto 5 Nome do ponto característico Character EveTipoPto 1 Tipo do Ponto: ‘ ’ – Ponto / ‘A’ - Aeródromo Float EveVelocidade 6 Velocidade da aeronave no ponto Float EveAltitude 6 Altitude da aeronave no ponto
110
TABELA 5.13 – TABELA DE EVENTOS
TTii ppoo Nome Tamanho Bytes
Descrição
Integer EveIndiceSetor 6 Número do Setor Integer EveHora 6 Horário de entrada setor Character EveData 10 Data de execução da simulação Integer EveQtdAnvSetorAtual 6 Quantidade de aeronaves no setor atual Integer EveIndiceAeronave 6 Índice da aeronave na estrutura Tráfego Character EveTipo_ES 1 Tipo do evento – [E ]Entrada – [S] Saída Integer EveEstado 1 1-Normal, 2-Congestionado, 3-Saturado Character EveNomePto 5 Nome do ponto característico Character EveTipoPto 1 Tipo do Ponto: ‘ - ’ Ponto / ‘A’ Aeródromo Float EveVelocidade 6 Velocidade da aeronave no ponto Float EveAltitude 6 Altitude da aeronave no ponto
5.8 Considerações Finais:
Nesse Capítulo procurou-se apresentar com riqueza de detalhes toda a dinâmica de um
vôo de uma aeronave desde a sua decolagem até o pouso ininterruptamente. Desta
maneira achamos ser a melhor forma de descrever como ocorre o comportamento de um
vôo real comparativamente com um vôo simulado decorrente dos modelos que serão
apresentados nos Capítulos 6 e 7 dessa dissertação. Na seqüência apresentamos as
estruturas em memória que foram geradas e montadas pelo subsistema Supervisor para
dar suporte a simulação.
Todas as estruturas que foram geradas em memória pelo subsistema Supervisor serão
utilizadas tanto no Capítulos 6 (Modelo 1) quanto no Capítulo 7 (Modelo 2). Porém, o
ponto que difere entre os modelos é o “resultado da simulação” que cada um irá gerar
após a simulação. Todas as tabelas apresentadas nesse Capítulo serão geradas em sua
plenitude pelo Capítulo 6, entretanto, no Capítulo 7 apenas as tabelas Eventos de
Tráfegos e Eventos é que serão geradas por esse modelo. A diferença entre os modelos
estão descritas com mais detalhes nos Capítulos 6 e Capítulo 7 respectivamente.
111
CAPÍTULO 6
ESPECIFICAÇÃO DO PROTÓTIPO DO SISTEMA DE SIMULAÇÃO
ACELERADO PARA ANÁLISE DE FLUXO DE TRÁFEGO AÉREO
(MODELO 1) NO CONTEXTO DO SISTEMA ATFM
6.1 Principais Aspectos do Protótipo:
O protótipo do Sistema de Simulação Acelerado para Análise de Fluxo de Tráfego
Aéreo tem como propósito disponibilizar aos gerentes ATFM uma ferramenta com a
qual eles possam inserir uma determinada data no sistema e obter, por antecipação e de
maneira simulada, relatórios operacionais, e uma representação gráfica da situação dos
setores que representam todas as regiões do país. O protótipo utilizará rotinas para
cálculos cinemáticos, como cálculo de proa, velocidade e altitude, a fim de simular o
movimento das aeronaves em suas respectivas trajetórias, de modo que, no final da
simulação, os gerentes ATFM possam ter uma visão da situação de todo espaço aéreo
brasileiro, procedendo então a uma análise visando encontrar ocorrências de
congestionamento e saturação de setores no espaço aéreo bem como nos aeroportos
nacionais.
Visando prevenir os órgãos ATC sobre a possível ocorrência desses fatores
(congestionamento ou saturação) em suas áreas de domínio, os gerentes ATFM, através
da simulação, podem detectar de maneira antecipada quaisquer anomalias que venham a
ocorrer nos aeroportos ou em qualquer parte do espaço aéreo brasileiro, bem como
aplicar as medidas de gerenciamento para solucionar esse problema.
O protótipo deverá processar os vôos de aeronaves de diversas categorias e
performances. A base de dados do protótipo é composta de arquivos que delimitam o
espaço aéreo brasileiro em setores e suas fronteiras, conterá todas as rotas nacionais e
internacionais, os aeroportos nacionais e internacionais, bem como os arquivos de
Aeronaves e Planos de Vôos.
112
Para que o resultado gerado pela simulação se aproxime do resultado real, é
fundamental que o protótipo leve em consideração os tipos de vôos que estão descritos
no Capítulo 5 tópico 5.3 dessa dissertação. Só assim os experimentos realizados neste
modelo atenderiam tanto ao gerenciamento estratégico (até 48 horas antes do vôo)
quanto ao gerenciamento tático (no dia do vôo) da ATFM.
Se a simulação fosse implementada utilizando apenas a base de dados de vôos regulares
(RPL), o seu resultado ou melhor, a qualidade da informação gerada por ela não
alcançaria um grau adequado de confiabilidade, tendo em vista que, os vôos regulares
são considerados “intenções de vôo”, e intenção não garante que eles ocorram. O
motivo que impossibilita a realização do vôo RPL ou FPL, é atribuído principalmente
pelas condições do aeroporto ou pelo cancelamento do vôo pela própria companhia
aérea. Por outro lado, o fato do vôo regular ser uma intenção de vôo, não invalida seus
dados, pelo contrário, os vôos com essa característica constituem 70% do total dos vôos
a serem realizados no país, ficando os 30% restantes para os vôos não regulares.
Portanto, para que o resultado da simulação alcance um grau de qualidade satisfatório, é
necessário que os vôos regulares e não regulares façam parte do conjunto de vôos a
serem simulados, permitindo assim aos gerentes ATFM uma análise mais precisa da
situação global do tráfego aéreo no espaço aéreo. A comunhão entre esses tipos de vôos
produzirá, como resultado simulado, uma demanda de tráfego aéreo muito próxima
do que irá realmente ocorrer e propiciará uma análise muito mais coerente do volume de
tráfego aéreo em qualquer parte do espaço aéreo brasileiro.
6.2 Requisitos do Protótipo:
Dentre os requisitos principais que fazem parte do documento de especificações do
projeto ATFM, nos parágrafos abaixo, estão descritos apenas os mais importantes para o
entendimento desta dissertação (Brasil, 1999a).
O protótipo do Sistema de Simulação Acelerado para Análise de Fluxo de Tráfego
Aéreo deverá manipular as seguintes bases de dados: arquivo de Pontos Característicos,
113
arquivo de Setores, arquivo de Planos de Vôos, arquivo de Aeronaves e o arquivo de
Aeroportos, conforme descrito no Capítulo 5 dessa dissertação.
O sistema deverá simular o movimento de aproximadamente 3000 aeronaves por dia,
com tendência desse patamar ir aumentando à medida que a economia do país der sinais
de evolução e as pessoas optarem em viajar mais de avião. Para tal esse conjunto de
aeronaves conterá tanto vôos regulares (RPL) quanto eventuais (FPL). O objetivo é
apresentar aos gerentes ATFM um resultado simulado mais próximo possível da
situação real de forma a permitir, verificar e confrontar a relação capacidade x
demanda de tráfegos nos setores e nos aeroportos nacionais numa determinada data.
Entende-se como fator de Normalidade a ocorrência de tráfego aéreo numa
determinada região do espaço aéreo, num determinado período, cujo volume de tráfego
aéreo não excedeu a capacidade da mesma. Porém, se o volume de tráfego aéreo
exceder 80% da capacidade da região, configurar-se-á uma situação de
Congestionamento e, se exceder 100% da capacidade configurar-se-á uma situação
Saturação.
Após processar a evolução das aeronaves de uma determinada data fornecida pelos
gerentes ATFM, o protótipo deverá gravar no Banco de Dados ATFM o perfil do vôo de
todas as aeronaves envolvidas na simulação. Ao resultado desta gravação dar-se-á o
nome de “resultado da simulação”, que compreende todas as fases que caraterizam o
vôo, conforme descrito no Capítulo 5.
Além de gerar a evolução de todas as aeronaves selecionadas para a simulação, este
protótipo fornecerá aos gerentes ATFM uma representação gráfica da situação do
volume de tráfego aéreo num determinado dia, num intervalo de tempo predeterminado,
em qualquer setor do espaço aéreo brasileiro, bem como em qualquer aeroporto
nacional. Essa representação gráfica permitirá aos gerentes ATFM terem uma visão
geral da situação do espaço aéreo em todo o país, possibilitando- lhes intervirem
antecipadamente tomando de medidas ATFM cabíveis, caso sejam verificada situações
de congestionamento e saturação.
114
A representação gráfica deverá conter no eixo “Y” a representação do volume de
aeronaves a partir da 00:00 hora de uma data selecionada ou o valor da capacidade
atribuída para a região selecionada. O maior valor entre eles deverá ser o valor a ser
apresentado no eixo Y. O eixo “X” conterá as 24:00 horas da data selecionada. Por
“default” o gráfico conterá no eixo X o intervalo de um dia inteiro simulado, mas
permitirá a ativação de qualquer intervalo dentro da data simulada. A Figura 6.1 abaixo
mostra em detalhes a representação gráfica de uma região fictícia. A linha superior
representa a condição de saturação do setor e a inferior representa a condição de
congestionamento.
Fig. 6.1 – Representação gráfica da demanda de um determinado setor.
O protótipo deverá gerar também diversos tipos de relatórios, conforme descrição a
seguir.
115
a) Relatório geral de congestionamentos e saturação: O sistema deverá identificar
no Banco de Dados ATFM, dentre as datas simuladas, as regiões cuja a demanda
nos setores atingiu níveis de congestionamento e saturação;
b) Relatório de congestionamentos e saturação de uma determinada data: O
sistema deverá identificar numa data selecionada, as regiões cuja a demanda nos
setores atingiu níveis de congestionamento e saturação;
c) Relatório Geral de aeronaves que provocaram congestionamentos e
saturação: O sistema deverá identificar dentre as datas simuladas, o conjunto de
aeronaves que provocaram o congestionamento e saturação nos diversos setores
simulados. De posse desse relatório os gerentes ATFM podem negociar com as
Companhias Aéreas melhores horários de partidas e chegadas, com o objetivo de
amenizar o fluxo nos setores prejudicados, e otimizar a segurança dos vôos.
d) Relatório geral dos Eventos de todas as datas simuladas: Este tipo de relatório
visa fornecer aos gerentes de ATFM um histórico completo do vôo de todas as
aeronaves, desde a decolagem, transferência entre setores até o pouso no Brasil
ou no exterior. O histórico de um vôo com pouso no exterior limitar-se-á à
fronteira com o Brasil.
Para representar a transferência entre setores, o sistema verificará se a aeronave
interceptou um determinado ponto na rota. Se o ponto for de fronteira significa que ele
terá associado a si, um ou mais setores do espaço aéreo nacional. O evento de
interceptação pela aeronave a um ponto de fronteira causará uma ação de transferência e
de contabilização entre os setores. Se a aeronave interceptar um ponto de uma rota que
não seja de fronteiras, a transferência não será processada e, por conseguinte, a aeronave
prosseguirá na região em que se encontra.
Para obter-se o conjunto de aeronaves a serem simuladas numa determinada data, serão
utilizados os arquivos de Tráfegos e o arquivo de Planos de Vôos. Através do arquivo
de Planos de Vôos pode-se selecionar o conjunto de aeronaves que irão voar numa data
escolhida pelos gerentes ATFM. A seleção de aeronaves que irão participar da
116
simulação deverá, a princípio, levar em consideração as aeronaves que vão voar na data
escolhida, bem como todas as que iniciaram o vôo no dia anterior e pousarão na data
escolhida. As aeronaves que iniciam o vôo no dia anterior e pousam antes da 00:00 hora
do dia escolhido não interessam à simulação.
Os dados que irão compor a base de dados ATFM virão através dos órgãos operacionais
de Controle de Tráfego Aéreo do Comando da Aeronáutica, ICA, AIS, BDS PEA e do
DAC. Os arquivos de Aeródromos, Pontos Característicos, Aerovias, FIR/Setores e
TMA/Setores, que são os dados base para composição do cenário do espaço aéreo
brasileiro não terão a mesma periodicidade que os dados que compõem o arquivo
Planos de Vôos.
Deste conjunto de dados, apenas os Planos de Vôos Repetitivos ou Regulares deverão
ser enviados ao Núcleo de Gerenciamento de Fluxo de Tráfego Aéreo (NuATFM) a
cada 15 dias.
6.3 Ambiente e Plataforma de Desenvolvimento:
Considerando-se que o Núcleo de Gerenciamento de Fluxo de Tráfego Aéreo
(NuATFM) será futuramente o órgão centralizador na tomada de decisão para os
problemas relacionados ao gerenciamento de fluxo de tráfego aéreo nacional, optou-se
em empregar no desenvolvimento desse protótipo, as seguintes características de
software e hardware:
a) Os processos que estão relacionados diretamente com a simulação como é o caso
do Supervisor, Conversão/Montagem de Dados e Sistema de Simulação
Acelerado para Análise de Fluxo de Tráfego Aéreo, serão desenvolvidos sob a
plataforma UNIX, utilizando técnicas de Engenharia de Software e a linguagem
de programação C. Neste Capítulo trataremos com mais detalhes desses
subsistemas.
b) Todas as informações referentes ao cenário e às aeronaves a serem simuladas,
serão armazenadas numa Sun-UltraSparc 5 com banco de dados Oracle 8i. A
117
utilização do banco de dados Oracle visa o desenvolvimento futuro de novas
tarefas para o NuATFM, principalmente voltadas à Internet.
c) As interfaces (Front-End) para manipulação de cenários, aeronaves e
apresentação gráfica dos resultados da simulação, serão desenvolvidas na
linguagem de programação Borland Delphi 4.0, utilizando o banco de dados
Oracle 8i, e sob a plataforma Windows 9x/2000 ou NT.
d) O protótipo será desenvolvido sob uma configuração de rede, baseado na
tecnologia Cliente/Servidor, e poderá ser acessado remotamente em qualquer
parte do país através da rede “Intraer” (Intraer é a “Intranet” do Comando da
Aeronáutica). Todas as informações referentes ao banco de dados ATFM,
poderão ser acessadas pelos órgãos do Comando da Aeronáutica via rede Intraer,
ou via Dial-Up. As Companhias Aéreas, por enquanto, só terão acessos através
da conexão “Dial-Up” à rede local do IPV. Assim que as autoridades do
Comando da Aeronáutica liberarem o acesso às informações, o sistema poderá
ser acessado através de diversas conexões, tais como: Internet, Intraer ou Dial-
Up, de qualquer órgão operacional do Comando da Aeronáutica ou de empresas
interessadas em obter informações de fluxo de tráfego aéreo no Brasil.
6.4 Arquitetura do Software:
Neste tópico abordaremos a divisão do protótipo em termos de processos (modelo
funcional) descrevendo “o que” o Sistema de Simulação Acelerado para Análise de
Fluxo de Tráfego Aéreo precisará realizar para apresentar as possíveis ocorrências de
problemas de fluxo de tráfego aéreo nas regiões do espaço aéreo e nos aeroportos
brasileiros.
6.4.1 Subsistema de Recebimento e Tratamento de Dados:
Este subsistema tem a tarefa de manter a integridade dos dados recebidos do
CINDACTA I e do DAC, os quais serão submetidos a um rigoroso processo de
118
consistência e validação até que todos estejam em condições de serem armazenados na
Base de Dados ATFM.
No segundo parágrafo do tópico 6.2, foram relacionados os arquivos que farão parte da
Base de Dados ATFM, e no penúltimo parágrafo fazemos um breve comentário sobre as
unidades que fornecerão esses arquivos ao NuATFM. Sendo assim, foi idealizado e
implementado este subsistema que tem a tarefa de ler, interpretar e validar os dados de
maneira a garantir que apenas os dados corretos sejam armazenados, e os incorretos
sejam corrigidos para posterior armazenamento e dependendo do tipo do erro, seja
reportado as Companhias Aéreas. Algumas vezes a correção é feita diretamente pelos
gerentes ATFM, muito embora não lhes caiba essa tarefa, porém após a correção, o
CINDACTA I como também a Companhia Aérea, serão notificados pela ocorrência do
erro, de modo que, possam corrigi- los e quando retornarem ao NuATFM venham sem
falhas.
Diante de diversas falhas encontradas em vários arquivos enviados ao NuATFM, ficou
caracterizado que o sistema de recebimento e tratamento de dados necessita
urgentemente de uma ferramenta de apoio ao preenchimento e validação de Planos de
Vôos em nível nacional.
Isso poderia e deveria ser feito, via Internet, o quanto antes, a exemplo do que ocorre
nos Estados Unidos e Europa.
A instalação de tal subsistema permitiria ao CINDACTA I (órgão central de
processamento de Planos de Vôos no Brasil), um ganho de tempo excepcional na
validação dos Planos de Vôos.
Na fase de implementação do protótipo, foram utilizadas diversas amostras do arquivo
de Plano de Vôos para validar o modelo de cinemática (conforme descrição no Capítulo
3) para este sistema. Observando o comportamento do protótipo nos diversos
experimentos realizados, verificamos que 15% do código desenvolvido era só para
tratamento de exceção, isto é, de erros encontrados no arquivo de Planos de Vôos que
participa da base de dados ATFM. Em função dos erros encontrados neste arquivo, a
119
equipe de Banco de Dados do Sistema ATFM teve a iniciativa de criar este subsistema
de tratamento de erros e retirar do protótipo a tarefa de validação da base de dados
ATFM.
Para melhor atender às Companhias Aéreas e os pilotos da aviação geral (vôo não
regular), apresentamos na Figura 6.2 abaixo a estrutura física (hardware) do subsistema
de inclusão e validação de Plano de Vôos que acreditamos ser uma das maneiras para
melhor atendê- los no preenchimento do Plano de Vôo. Esta arquitetura é uma
concepção física para o desenvolvimento futuro desse subsistema.
A idéia inicial compreende um microcomputador instalado em cada Companhia Aérea e
nos Órgãos Operacionais (salas AIS), conectados a rede Internet, Intraer ou Dial-Up, de
modo que estes órgãos possam preencher os planos de vôos das aeronaves através de
formulário localizado diretamente na home page do CINDACTA I ou do IPV, onde está
centralizado o Banco de Dados ATFM.
A arquitetura de suporte ao banco de dados compreende duas workstation Sun-
UltraSparc-5 ligadas em rede de modo replicado, de forma que, se uma deixar de
funcionar a outra entra em operação automaticamente.
120
* Pc’s conectados a Internet / Intraer para o preenchimento do Plano de Vôo.
* Internet / Intraer
* Servidor 1 * Servidor 2
Internet Intraer
* Rede local IPV / CINDACTA I
* Workstation Sun - Banco de Dados ATFM.
Fig. 6.2 – Estrutura física (hardware) do subsistema de inclusão de Planos de Vôos e de tratamento de erros.
Esta proposta pretende, fundamentalmente, disponibilizar um meio rápido, moderno,
amigável e seguro de preenchimento de Planos de Vôos, de modo que possibilite o
correto preenchimento dos mesmos, e principalmente, permitir o armazenamento das
informações de maneira centralizada.
121
6.4.2 Subsistema de Gerenciamento da Base de Dados ATFM (SGBD):
O subsistema de gerenciamento da base de dados ATFM tem o objetivo de
disponibilizar aos gerentes ATFM, diversas interfaces para que os mesmos possam
manipular todas as informações que são enviadas pelo CINDACTA I e pelo DAC ao
NuATFM, de modo que se possa contar com um Banco de Dados ATFM íntegro e
operacional.
O Subsistema de Tratamento de Dados, assim como o Subsistema SGBD, compartilham
a tarefa de manter o Banco de Dados ATFM funcional, isto é, qualquer manipulação
que venha a ocorrer no Banco, não deverá provocar sua paralisação sob hipótese
alguma. Em geral os software de caráter operacional tem essa característica, isto
significa que a informação a ser transmitida ou recebida não pode ter interrupções, e
quando isto ocorre outro sistema tem que entrar imediatamente em operação. O banco
de dados ATFM terá essa característica porque, além das simulações e visualizações
que serão realizadas no IPV, às Companhias Aéreas e os Órgãos Operacionais estarão
utilizando e disputando acesso às informações no mesmo banco de dados (Brasil, 1998).
Conforme descrito neste Capítulo, no parágrafo 5 do tópico 6.3, o Banco de Dados
ATFM está sendo concebido sob uma arquitetura de rede que possibilitará o acesso às
informações de maneira remota, isto é, os gerentes ATFM e as Companhias Aéreas
poderão acessar de suas localidades as informações no banco de dados através da rede
de comunicação “Intraer”, “Dial-Up” ou “Internet”. O fato de disponibilizar
informações de forma remota, já obriga o subsistema SGBD a ter uma arquitetura
robusta que possa atender os usuários a qualquer momento.
A descrição detalhada de cada arquivo que compõe o subsistema SGBD, bem como a
análise, modelagem e a estruturação das tabelas, não fazem parte dessa dissertação, uma
vez que às informações que o protótipo necessitará para realizar a simulação serão
extraídas, interpretadas, compiladas e montadas em apenas 5 novos arquivos, descritos
no Capítulo 5 dessa dissertação.
122
Para acessar as informações no banco de dados ATFM os usuários (dos órgãos
operacionais e das Companhias Aéreas) receberão uma identificação (nome e senha)
para realizarem suas operações junto ao banco de dados. O subsistema SGBD contém
dois níveis de permissão que possibilitará a manipulação do banco dados ATFM da
seguinte forma:
a) O primeiro nível caracteriza-se por ter apenas o privilégio de consulta, isto é,
não lhe será permitido realizar as operações de Inclusão, Alteração ou Exclusão
no banco de dados. Este privilégio será outorgado apenas aos usuários das
Companhias Aéreas e dos órgãos operacionais.
b) O segundo e último nível, permitirá todo o tipo de manipulação I/O no banco de
dados ATFM, mas, este privilégio é concedido apenas para os gerentes ATFM
localizados no NuATFM, no IPV. Deste modo pretende-se que o Banco de
Dados ATFM seja gerenciado e controlado apenas pelos gerentes ATFM e que
às informações sejam processadas de maneira centralizada.
6.4.2.1 Aspectos Gerais do Subsistema SGBD:
O subsistema de gerenciamento da base de dados ATFM é um sistema automatizado
que tem por objetivo estabelecer uma interface bastante amigável entre os usuários
(gerentes ATFM, Operadores dos Centros Operacionais e Operadores das Companhias
Aéreas) de modo que eles possam manipular as informações que estarão armazenadas
no banco de dados ATFM, o qual permitirá a execução das seguintes operações a saber:
a) Inclusão, Consulta, Alteração e Exclusão de dados nos seguintes arquivos que
compõem o cenário ATFM: Aeródromos, Aeronaves, Aerovias, Caminhos
Diretos, Companhias Aéreas, Corredores, FIR/Setores de FIR, TMA / Setores de
TMA e Pontos Característicos.
b) Atualização automática de Planos de Vôos Repetitivos (RPL), oriundos do
CPVR – Centro de Planos de Vôos Repetitivos do CINDACTA I, localizado em
Brasília;
123
c) Manipulação de Alteração e Exclusão dos RPL;
d) Ativação do Subsistema de Recebimento e Tratamento de Dados. Este
subsistema realizará a análise/crítica das rotas cont idas nos Planos de Vôos
(RPL), bem como terá a função de gerar o arquivo de Trajetórias.
e) Ativação de rotinas que tem a função de gerar os arquivos de PLN e Tráfegos
para posterior processamento da simulação (protótipo).
f) Cadastramento de dados de usuários e suas respectivas categorias de permissão
de acesso ao Banco de Dados ATFM.
6.4.2.1.1 Apresentação das Interfaces dos arquivos do Subsistema
SGBD:
Conforme descrito no tópico 6.4.1 deste Capítulo, a Base de Dados ATFM atualmente
encontra-se centralizada no NuATFM no IPV, cujo objetivo é torná- la íntegra e
operacional para que possa ser compartilhada pelos demais usuários. Mas para isso é
necessário que apenas uma unidade faça as manutenções. Sendo assim foi criado duas
(2) versões deste subsistema que compreende, uma versão apenas de “Consulta”
denominada “versão ATFM” o qual ficará instalada nos centros operacionais e nas
Companhias Aéreas, e a outra denominada “versão Gerente” que terá todos os
privilégios para manipular e dar as manutenções necessárias. Esta ficará instalada no
NuATFM no IPV sob a responsabilidade dos gerentes ATFM.
Os tópicos a seguir serão apresentadas as diversas interfaces dos arquivos que compõem
a Base de Dados ATFM, cujo objetivo é demonstrar visualmente a quantidade de
arquivos que fazem parte deste Banco de Dados, e principalmente ressaltar a árdua
tarefa que os gerentes ATFM tem para mantê- lo sempre ativo e operacional.
Observaremos também que em algumas opções do menu principal se faz necessário
trazer em seu cabeçalho uma breve descrição de sua funcionalidade, enquanto que
outras opções o próprio nome por si já o descrevem.
124
6.4.2.2 Menu Principal:
Após a verificação e validação pelo sistema do nome e senha digitados pelo usuário,
será apresentada a janela ilustrada pela figura abaixo (Figura 6.3), contendo as opções
relativas aos arquivos a serem manipulados no Banco de Dados ATFM (IPV, 2000).
Fig. 6.3 – Menu Principal do Subsistema SGBD.
6.4.2.3 Opções do Menu Principal:
Em cada janela associada a cada uma das opções do “Menu Principal”, existirá um
conjunto de botões que permitirá a ativação de diferentes operações sobre os dados do
arquivo escolhido. Os botões que são comuns a todas essas opções são:
a) Inserir: permite a inclusão de novos registros no arquivo;
b) Alterar: permite a alteração de informações de um determinado registro;
c) Excluir: permite a exclusão de um determinado registro;
125
d) Geral: posiciona o cursor no 1º registro do arquivo, apresentando os respectivos
dados;
e) Relatório: monta e permite visualização e impressão de relatório;
f) Retornar: permite o retorno à janela do “Menu Principal”;
g) Windows : finaliza o sistema (após a confirmação do usuário) e retorna ao
“Windows”.
As operações associadas aos botões exclusivos de uma determinada opção do “Menu
Principal” serão explicadas adiante, dentro do item correspondente.
6.4.2.4 Opção Aeródromos:
Através da opção Aeródromos torna-se possível acessar as informações pertinentes a
todos os aeródromos cadastrados na Base de Dados ATFM, conforme mostraremos na
Figura 6.4 abaixo. É através desta opção que o subsistema Supervisor consegue montar
às Trajetórias das aeronaves utilizando o aeródromo de origem e o aeródromo de
chegada a partir deste arquivo.
Essa opção permite, além das operações de manipulação de dados comuns aos demais
arquivos, realizar pesquisas (consultas) através de dois campos chave Indicativo ICAO
e Indicativo IATA.
126
Fig. 6.4 – Janela Aeródromos.
6.4.2.5 Opção Aeronaves:
Através da opção Aeronaves torna-se possível acessar as informações pertinentes a
todas as aeronaves cadastradas na Base de Dados ATFM (Figura 6.5).
Essa opção permite, além das operações de manipulação de dados comuns aos demais
arquivos, realizar pesquisas (consultas) através do campo chave Designador.
Esta opção descreverá todos os dados relativos a “performance” de cada aeronave
inserida neste arquivo.
127
Fig. 6.5 – Janela Aeronave.
6.4.2.6 Opção Aerovias:
Através da opção Aerovias torna-se possível acessar as informações pertinentes a todas
as aerovias cadastradas na Base de Dados ATFM (Figura 6.6). Essa opção permite,
além das operações de manipulação de dados comuns aos demais arquivos, realizar as
seguintes operações:
a) Pesquisas (consultas) através do campo chave Identificação da Aerovia;
b) Inclusão de novos pontos na Aerovia que podem ser feito através do botão
“Adicionar”.
128
Através desta opção este subsistema montará todas as trajetórias referente as aeronaves
que foram selecionadas para participarem da simulação.
Fig. 6.6 – Janela Aerovias.
6.4.2.7 Operação Adicionar - Opção Aerovias:
Ao ser ativado o botão Adicionar da janela Aerovias, o sistema apresentará a janela
ilustrada pela figura abaixo (Figura 6.7) e ficará aguardando a digitação de um ou mais
pontos da Aerovia.
129
Fig. 6.7 – Janela de Inclusão de Novos Pontos na Aerovias.
6.4.2.8 Opção Caminhos Diretos:
Caminho Direto é o termo utilizado para definir o deslocamento de aeronaves entre dois
pontos quaisquer ou entre dois aeródromos, onde não existe oficialmente uma Aerovia
que ligue esses pontos. O Caminho Direto entre dois aeródromos é utilizado para definir
vôos que irão ocorrer dentro da própria região, em especial em pequenos trechos.
Através da opção Caminho Direto torna-se possível acessar as informações pertinentes a
todos os Caminhos Diretos cadastrados na Base de Dados ATFM (Figura 6.8).
Essa opção permite, além das operações de manipulação de dados comuns aos demais
arquivos, realizar pesquisas (consultas) através de dois campos chave:
a) Número do Caminho Direto;
b) Nome do Ponto.
130
Fig. 6.8 – Janela Caminho Diretos.
6.4.2.9 Opção Companhias Aéreas:
Através da opção Companhias Aéreas torna-se possível acessar as informações
pertinentes a todas as Companhias Aéreas cadastradas na Base de Dados ATFM
(Figura 6.9).
Essa opção permite, além das operações de manipulação de dados comuns aos demais
arquivos, realizar pesquisas (consultas) através de dois campos chave:
a) Código ICAO;
b) Código IATA.
131
Fig. 6.9 – Janela Companhias Aéreas.
6.4.2.10 Opção Corredores:
Corredor é o termo utilizado para definir “os pontos” intermediários entre o aeródromo
de partida e uma aerovia ou entre um ponto de uma aerovia e o aeródromo de chegada.
Por definição, corredores são pontos previamente definidos que tem a função de auxiliar
as aeronaves quando elas necessitam chegar numa aerovia oficial ou pretendem
abandonar a aerovia para dirigir-se ao aeródromo de chegada. Através da opção
Corredores torna-se possível acessar as informações pertinentes a todos os Corredores
cadastrados na Base de Dados ATFM (Figura 6.10).
132
Essa opção permite, além das operações de manipulação de dados comuns aos demais
arquivos, realizar pesquisas (consultas) através de dois campos chave:
a) Nome da Aerovia;
b) Nome do Ponto.
Fig. 6.10 – Janela Corredores.
6.4.2.11 Opção FIR:
As Regiões de Informações de Vôo (FIR ), conforme está descrito no Capítulo 2 tópico
2.4.4.1, são espaços aéreos não controlados, o qual se destina a prestar serviços de
informação de vôo e serviço de alerta.
Através da opção FIR torna-se possível acessar as informações pertinentes a todas as
“FIR” e seus correspondentes “Setores” cadastrados na Base de Dados ATFM (Figura
6.11). Essa opção permite, além das operações de manipulação de dados comuns aos
demais arquivos, realizar pesquisas (consultas) através do campo chave Designador da
FIR.
133
Fig. 6.11 – Janela FIR / Setores.
6.4.2.12 Opção Pontos Característicos:
Ponto característico, baliza ou fixo são localidades ou instrumentos que auxiliam na
navegação das aeronaves o qual tem a finalidade de orientá-las em suas trajetórias
durante o vôo.
Este arquivo além de servir de base para a composição das trajetórias, ele será utilizado
também para indicar os setores de fronteira que estejam associado a um determinado
ponto característico. O preenchimento de pelo menos dois campos de setores é o
bastante para caracterizá- lo como ponto de fronteira.
134
Através da opção Pontos Característicos torna-se possível acessar as informações
pertinentes a todos os Pontos Característicos cadastrados na Base de Dados ATFM
(Figura 6.12). Essa opção permite, além das operações de manipulação de dados
comuns aos demais arquivos, realizar pesquisas (consultas) através do campo chave
Nome do Ponto Característico.
Fig. 6.12 – Janela Pontos Característicos.
6.4.2.13 Opção TMA:
As Áreas de Controle de Terminal ( TMA ), conforme está descrito no Capítulo 2,
tópico 2.4.4 – 2.4.4.2, compreendem áreas situadas na confluência de rotas ATS e nas
imediações de um ou mais aeródromos.
Através da opção TMA torna-se possível acessar as informações pertinentes a todas as
“TMA” e seus correspondentes Setores, cadastrados na Base de Dados ATFM (Figura
6.13). Essa opção permite, além das operações de manipulação de dados comuns aos
135
demais arquivos, realizar pesquisas (consultas) através do campo chave Designador da
TMA.
Fig. 6.13 – Janela TMA / Setores.
6.4.2.14 Opção Planos de Vôos:
Através da opção Planos de Vôos torna-se possível acessar as informações pertinentes a
todos os Planos de Vôos - Periódicos ou Eventuais - cadastrados na Base de Dados
ATFM (Figura 6.14). Essa opção permite, além das operações de manipulação de
dados comuns aos demais arquivos, realizar as seguintes operações:
a) Pesquisas (consultas) através do campo chave Identificação do Vôo;
b) Cópia de um determinado registro indicado pelo usuário.
136
Fig. 6.14 – Janela Planos de Vôos.
Vôos periódicos são aqueles que são preparados pelas companhias aéreas, e a cada 15
dias são enviados através da central de Brasília ao NuATFM.
Os vôos eventuais são aqueles que serão realizados em poucas horas. Eles chegam ao
NuATFM que por sua vez são analisados e cadastrados no Banco de dados ATFM pelos
gerentes ATFM.
6.4.2.15 Opção Consulta de Trajetória:
Através da opção Consulta de Trajetórias torna-se possível acessar as informações de
todas as Trajetórias de Vôos criadas automaticamente pelo sistema (através de ativação
137
da opção Atualização de Trajetórias) e armazenadas na Base de Dados ATFM (Figura
6.15).
Essa opção permite ao usuário obter, simultaneamente, informações sobre as Trajetórias
propriamente ditas (N.º, Aeródromo de Origem, Aeródromo de Destino e Rota), sobre
os Pontos (“break points”), bem como sobre o vôo que a utiliza.
Diferentemente das demais opções do Menu Principal, através desta somente é possível
a realização de consultas propriamente ditas (visualização de informações na tela) ou
obtenção de relatórios.
A realização de consultas poderá ser feita através de dois campos chaves:
a) Identificação do Vôo (pesquisa por Plano de Vôo);
b) Número da Trajetória (pesquisa por Trajetória).
Este arquivo será gerado através do processo de conversão conforme descrito no tópico
6.4.2.22 deste Capítulo.
138
Fig. 6.15 – Janela da Opção Consulta de Trajetórias.
139
6.4.2.16 Opção Consulta de Tráfegos:
Através da opção Consulta de Tráfegos torna-se possível acessar as informações de
todos os Tráfegos (vôos) e “PLNs” associados, criados automaticamente pelo sistema
(através de ativação da opção Atualização de Tráfegos) e armazenados na Base de
Dados ATFM (Figura 6.16).
Assim como na opção Consulta de Trajetórias, através desta somente é possível a
realização de consultas propriamente ditas (visualização de informações na tela) ou
obtenção de relatórios.
A consulta deverá ser feita através do campo chave Identificação do Vôo.
140
Fig. 6.16 – Janela da Opção Consulta de Tráfegos.
141
6.4.2.17 Opção Atualização do RPL:
A opção Atualização do RPL tem por finalidade permitir a atualização automática dos
dados de RPL. Essa atualização normalmente deverá ser feita a cada 15 dias, quando do
recebimento do arquivo “RPLEOBT.DAT”, enviado pelo CPVR do CINDACTA I de
Brasília. Ao ser ativada esta opção será apresentada a janela ilustrada pela figura abaixo.
(Figura 6.17).
Esta opção não faz parte do Menu Principal, ela é executada através de um programa
independente.
Fig. 6.17 – Janela da Opção Atualização do RPL.
6.4.2.18 Opção Atualização de Trajetória:
A opção Atualização de Trajetórias conforme mostra a figura abaixo (Figura 6.18), tem
por finalidade permitir a criação automática de novas Trajetórias, após a operação de
atualização do RPL ou após a inclusão de novos Planos de Vôos “eventuais” na Base de
Dados ATFM.
Esta opção não faz parte do Menu Principal, ela é executada através de um programa
independente.
142
Fig. 6.18 – Janela da Opção Atualização de Trajetória.
6.4.2.19 Opção Atualização de Tráfegos / PLN (Plano de Vôo):
A opção Atualização de Tráfegos / PLN como mostra a figura abaixo (Figura 6.19),
tem por finalidade permitir a criação automática de novos Tráfegos e respectivos PLN’s
(Planos de Vôos) para posterior processamento pelo Sistema Acelerado de Análise de
Fluxo de Tráfego Aéreo (protótipo).
Importante: essa operação só deverá ser ativada após a conclusão da operação de
atualização de Trajetórias, considerando-se um mesmo conjunto de Planos de Vôos
(periódico ou eventual).
Esta opção não faz parte do Menu Principal, ela é executada através de um programa
independente.
143
Fig. 6.19 – Janela da Opção Atualização de Tráfegos / PLN.
6.4.2.20 Opção Usuário:
A opção Usuário conforme mostra a figura abaixo (Figura 6.20) tem por finalidade
permitir o cadastramento de dados de usuários e respectivas categorias de permissões de
acesso aos dados da Base de Dados ATFM.
Fig. 6.20 – Janela da opção Usuário
144
6.4.2.21 Opção Windows:
A opção Windows tem a função de finalizar o processamento do sistema. Ao ser ativado
o botão correspondente a essa opção o sistema apresentará a janela ilustrada pela figura
abaixo (Figura 6.21) e ficará aguardando a resposta do usuário.
Fig. 6.21 – Janela de Confirmação de Finalização de Processamento.
Todos os arquivos que compõem a Base de Dados ATFM tem por objetivo
disponibilizar suas informações para os Órgãos Operacionais do Comando da
Aeronáutica e para as Companhias Aéreas de modo que eles possam saber de maneira
antecipada, qual será a demanda de fluxo de tráfego aéreo que irá ocorrer nos aeroportos
brasileiros no dia corrente ou numa data futura.
Além da prestação desse serviço, o Banco de Dados ATFM também tem a tarefa de
disponibilizar seus dados para a criação e montagem de arquivos que serão utilizados no
processo de simulação, que por fim dar-se-á uma nova base de dados que será utilizada
pelo subsistema de Apresentação Gráfica de Resultados da Simulação, para que os
gerentes ATFM possam analisar as ocorrências de extrapolação de setores em qualquer
região do espaço aéreo brasileiro.
145
6.4.2.22 Processo de Conversão e Armazenamento dos Dados ATFM:
Para que as informações do banco de dados ATFM fossem armazenadas num banco de
dados confiável e robusto decidiu-se adotar o Sistema Gerenciador de Banco de Dados
ORACLE, utilizando a plataforma UNIX, numa Sun-UltraSparc 5 Server. O sistema
operacional UNIX dispensa qualquer comentário sobre sua operacionalidade e robustez
como servidor de aplicações e de banco de dados, tendo sido, por esse motivo, o
escolhido para essa nossa aplicação.
Para facilitar o acesso e manipulação das informações no Banco de Dados ATFM, via
ORACLE, desenvolveu-se, através da linguagem DELPHI 3.0 da Borland, um “front
end mais amigável” do que o oferecido pela ORACLE através do SQLPLUS.
Este subsistema será uma das ferramentas que serão disponibilizadas aos usuários, os
quais poderão, além de consultar as informações do banco de dados ATFM de forma
remota, visualizar graficamente e antecipadamente, a situação de demanda de tráfego
aéreo de qualquer região do país. A ferramenta de visualização gráfica que também será
disponibilizada, está descrita com mais detalhes no tópico 6.4.5 deste Capítulo.
6.4.2.23 Processo de Geração dos Arquivos de Planos de Vôos e
Tráfegos:
A figura abaixo (Figura 6.22 e 6.23) ilustra o processo de atualização de dados de vôos
na Base de Dados ATFM.
O processo de atualização de dados de vôos na Base de Dados ATFM tem o objetivo de
atualizar essas informações a partir dos dados enviados atualmente, periodicamente,
pelo CINDACTA I (RPL) e DAC (HOTRAN). Essa atualização produzirá, como
resultado, os arquivos de Tráfegos e respectivos Planos de Vôos associados. Esses
arquivos serão então, numa 2ª fase (ilustrada pela Figura 6.24), processados juntamente
com outros arquivos do Banco de Dados ATFM, por um processo denominado
Supervisor que fará a conversão e carregamento desses dados na memória de uma
146
“workstation” Sun. Esses dados serão então processados pelo Sistema de Simulação
Acelerado para Análise de Fluxo de Tráfego Aéreo.
Na fase 1 do diagrama apresentado na Figura 6.22, o arquivo RPL (Planos de Vôos
Repetitivos) original (oriundo do CINDACTA I) passará por um processo de leitura e
transformação, resultando num novo arquivo RPL temporário, o qual foi modelado para
atender às necessidades do banco de dados ATFM local.
Posteriormente esse arquivo RPL temporário será submetido a um minucioso processo
de crítica e consistência até que os dados estejam absolutamente sem erros. A maioria
dos erros encontrados são geralmente por falha de preenchimento do campo “Rota” (que
é um campo aberto, com 192 posições) por parte das Companhias Aéreas.
A correção desses erros, apontados pelo programa de crítica e consistência de dados,
não pode ser feita por qualquer pessoa pois depende, e muito, da experiência do
controlador de tráfego aéreo que realizará essa tarefa. Após a eliminação dos erros do
arquivo de RPL temporário, os dados serão armazenados em um arquivo permanente
(denominado na Figura 6.22 como “RPL IPV”), o qual será então processado pelo
programa de Criação de Trajetórias. A cada processamento de atualização de um
arquivo RPL o programa de criação de Trajetórias armazenará, no respectivo arquivo, as
novas Trajetórias que surgirem, conforme ilustrado na fase 2 do diagrama da Figura
6.22.
O sistema permanecerá nessa fase de processamento de Trajetórias enquanto houver
ocorrência de erros, que serão analisados e corrigidos pelos gerentes ATFM. Quando
não houver mais nenhuma incidência de erro nessa fase, o passo seguinte será a ativação
do programa de criação dos arquivos de Tráfegos e de Planos de Vôos, os quais serão a
principal fonte de dados para processamento na fase de simulação. Também nessa fase
de criação dos arquivos de Tráfegos / Planos de Vôos ocorrerá um “loop” do processo
enquanto houver ocorrência de erros, que serão analisados e corrigidos pelos gerentes
ATFM.
147
Os arquivos de Tráfegos e de Planos de Vôos conterão, além dos dados oriundos do
RPL, também uma síntese dos dados de HOTRAN (fase 3 do diagrama da Figura 6.22),
após estes terem sido depurados e comparados com os dados do arquivo permanente de
RPL, num processo bastante semelhante ao executado para o RPL, com geração de
listagem de erros, análise e correção pelos gerentes ATFM até a completa eliminação
dos erros.
Portanto, a divisão em fases 1, 2 e 3, apresentada no diagrama da Figura 6.22, em
última análise, tem o objetivo de gerar e disponibilizar à simulação os arquivos
necessários à execução de suas tarefas.
O diagrama 2 (Figura 6.23) representa a fase de seleção de dados para a simulação, a
simulação propriamente dita através do SAS e a apresentação gráfica desses dados,
conforme explicado mais detalhadamente a seguir:
O subsistema Supervisor extrairá do banco de dados ATFM, a partir de indicação feita
por um gerente ATFM, os dados referentes aos Tráfegos, Plano de Vôos (PLNs)
associados a estes e dados de “cenário” de uma determinada data, que, por sua vez,
serão lidos, convertidos e armazenados na memória de uma workstation Sun. A seguir
será ativado o processo de simulação o qual terá a função de gerar os dados referentes à
evolução das aeronaves em cada setor. O resultado gerado pela simulação será utilizado
pelo subsistema de Apresentação Gráfica (SAS) para representar graficamente a
situação dos setores do espaço aéreo brasileiro no que diz respeito à relação Capacidade
x Demanda.
A última representação mostra a demanda de aeroportos brasileiros, que pode ser
visualizada através de gráficos e relatórios impressos.
148
Fig. 6.22 – Visão Geral dos Processos de Atualização dos vôos.
149
Fig. 6.23 – Visão Geral dos demais Processos de Atualização dos vôos.
A descrição do processo de transformação de dados teve o objetivo de apresentar nessa
dissertação, todos os passos que são executados para obter-se uma base de dados íntegra
e operacional, desde o instante do recebimento até a sua disponibilização técnica para
que os usuários possam desempenhar suas funções na tomada de decisão com base num
banco de dados inteiramente confiável.
150
6.4.3 Subsistema Supervisor:
O subsistema Supervisor tem por objetivo disponibilizar aos gerentes ATFM os
recursos necessários para que os mesmos possam planejar, executar e analisar as
ocorrências do fluxo de tráfego aéreo em qualquer região do espaço aéreo nacional. A
ativação do processo Supervisor implica na escolha pelo gerente ATFM da data e o
período que pretende-se ser analisado.
No Apêndice B, encontra-se o Diagrama de Fluxo de Dados (DFD) do Sis tema ATFM,
o qual tem por objetivo, apresentar a funcionalidade de todos os subsistemas que
integram o modelo lógico do protótipo. Neste modelo descrevem-se os relacionamentos
que o subsistema Supervisor mantém com outros subsistemas.
O Supervisor caracteriza-se por ser o processo que gerencia e controla toda a parte
referente à simulação. É através da digitação dos parâmetros de entrada na tela do
Supervisor (Data Inicial - Data Final e Hora Inicial - Hora Final ), que procede-se todo
o processo de leitura, seleção e conversão dos dados a serem simulados. Após receber
os parâmetros de entrada, o Supervisor inicializa as estruturas em memória para
configurar o cenário a ser simulado. Em seguida ativa o processo de conversão que tem
a função de acessar o banco de dados ATFM e extrai as aeronaves que irão participar da
simulação, bem como suas trajetórias, fixos, setores, aeródromos e todo o complexo de
dados que possibilitam a evolução de cinemática de todas as aeronaves envolvidas na
simulação.
Após realizar o processo de seleção e conversão dos dados (cenários e aeronaves), o
supervisor por fim, ativa o Sistema de Simulação Acelerado para Análise de Fluxo de
Tráfego Aéreo para calcular e contabilizar a evolução das aeronaves nos seus
respectivos setores, desde a decolagem até o pouso. Mais detalhes do Sistema de
Simulação Acelerado para Análise de Fluxo de Tráfego Aéreo, está descrito no tópico
6.4.4.
Dentre outras tarefas que são inerentes ao papel desempenhado pelo Supervisor, cabe-
lhe a tarefa de não permitir que datas repetidas sejam gravadas no banco de dados
151
ATFM, permite que os gerentes de ATFM incluam e excluam qualquer data no sistema,
e para manipular o subsistema Supervisor, os gerentes fazem uso de uma conta e senha
para poder acessá- lo.
O subsistema Supervisor foi modelado e implementado sob o prisma da metodologia
estruturada, utilizou-se a ferramenta PC-Case da empresa IBPI para realizar a
documentação em termos de diagramas DFD, DER e DE, e para complementar a
documentação, utilizou-se o aplicativo Word da Microsoft para gerar os documentos de
Análise, Projetos e Implementação. Na implementação adotou-se a linguagem de
programação C, e na parte de construção de janelas utilizou-se o gerenciador de janelas
gráficas Motif.
O subsistema foi desenvolvido na plataforma UNIX, utilizamos uma Sun Ultra-sparc-5
sistema operacional Solaris versão 5.7 em rede baseado na arquitetura cliente servidor,
acessando as informações do banco de dados ATFM em outra workstation Sun Ultra-
sparc-5 com ORACLE.
Na Figura 6.24 abaixo é apresentada a tela de entrada de dados a serem simulados. Na
tela de entrada de dados, após o usuário clicar na opção “Confirma a Conversão”, é
disparado o processo de leitura, seleção e conversão dos dados, conforme a(s) data(s)
escolhida(s) pelo gerente de ATFM. Por fim ativa-se o Sistema de Simulação Acelerado
para Análise de Fluxo de Tráfego Aéreo que dará inicio ao processo de evolução e
contabilização das aeronaves nas suas respectivas trajetórias e setores.
6.4.3.1 Considerações Sobre a Conversão:
A conversão caracteriza-se por ser o processo que terá a responsabilidade de criar e
montar todos os dados em memória de uma Sun UltraSparc, para dar sustentação ao
processo de simulação. Para armazenar as informações em memória, foi utilizado o
serviço de memória compartilhada (global section) fornecido pela Sistema Operacional
da Sun (Solaris), o qual possibilitou a troca de mensagens entre os subsistemas, como
também facilitou a tarefa do Sistema de Simulação Acelerado para Análise de Fluxo de
Tráfego Aéreo no que diz respeito ao armazenamento dos resultados obtidos durante a
152
realização dos cálculos cinemáticos e contabilização de setores. No término da
simulação, os dados em memória serão transportados para as suas respectivas tabelas no
banco de dados ATFM em ORACLE.
A conversão monta em memória os dados referentes aos seguintes arquivos: Pontos
Característicos, Trajetória, Setores, Aeroportos e Aeronaves. Estes arquivos estão
descritos a partir do tópico 6.4.2.
A conversão é ativada quando o botão de “Confirmar a Conversão “é pressionado. Daí
então é disparado a seleção dos tráfegos que serão escolhidos segundo o seu dia de vôo
e por fim monta-se todo o cenário em memória. A Figura 6.24 abaixo dará mais
detalhes sobre os parâmetros de entrada na janela do supervisor.
153
6.4.3.2 Composição da Tela do Supervisor:
A tela do Supervisor é dividida em quatro áreas, a saber:
a) Parâmetros do sistema;
b) Menu de opções;
c) Área de apresentação de tempo de simulação; e
d) Área de mensagens.
Cada área da tela do Supervisor será explicada nos tópicos a seguir.
Fig. 6.24 – Janela de Entrada de Dados a Serem Simulados.
154
6.4.3.2.1 Parâmetros do Sistema:
Esta área destina-se à entrada, pelo gerente ATFM, dos parâmetros desejados para
iniciar o processo de conversão, preparação e carregamento dos dados em memória, que
posteriormente serão utilizados pelos outros subsistemas (Sistema de Simulação
Acelerado para Análise de Fluxo de Tráfego Aéreo e Apresentação Gráfica), conforme
mostra as Figuras 6.24-a e 6.24-b.
Esses parâmetros são: O período de um dia, limitado pela hora inicial e final ( se nada
for informado nesses campos o sistema assumirá o período de 24 horas);
a) Data Inicial;
b) Data Final.
Fig. 6.24-a – Parâmetros do Sistema - Janela Supervisor.
O usuário tem a opção de indicar uma ou mais datas desejadas ou, se preferir, poderá
optar pela seleção de dia(s ) da semana.
- Pode-se selecionar o dia da semana após o dia corrente.
- Caso selecione o dia corrente, a data a ser convertida será a da próxima semana.
- Caso selecione para toda semana (última opção), o início será a data corrente.
A data final somente deverá ser introduzida se for necessária a conversão de mais de uma data.
Não há necessidade de se introduzir a hora inicial/final. A simulação será a partir de 0 até 24 horas.
Introduzir a data para início da conversão.
155
6.4.3.2.2 Menu do Opções:
- Ao ser acionado apresenta a janela de confirmação abaixo.
Nota: A janela de aviso somente será apresentada nos seguintes casos: - Introdução incorreta de data Introdução de data e seleção do dia da semana.
- Retorna à tela de abertura do sistema .
6.4.3.2.3 Área de Apresentação de Tempo de Simulação:
6.4.3.2.4 Área de Mensagens:
Fig. 6.24-b – Opções e Informações - Janela Supervisor.
Converte os dados referentes à data introduzida.
Apresenta o total de aeronaves convertidas para a data introduzida ou selecionada.
Apresenta a data e hora final da simulação.
Apresenta as mensagens referentes ao estado da conversão e simulação.
156
6.4.4 Sistema de Simulação Acelerado para Análise de Fluxo de Tráfego
Aéreo (Modelo 1):
O Sistema de Simulação Acelerado para Análise de Fluxo de Tráfego Aéreo caracteriza-
se por ser o processo que tem a função de executar a evolução de um conjunto de
aeronaves desde a decolagem até o pouso e realizar a transferência e a contabilização de
todos os setores por onde elas passarem durante o vôo. Para realizar essas tarefas este
sistema gerencia e controla diversos módulos que terão a função de executar o vôo de
todas as aeronaves de maneira ininterrupta, seja um vôo doméstico (decolagem e pouso
no Brasil), ou internacional.
Para exemplificar a evolução das aeronaves bem como o processo de transferência e
contabilização de setores, serão apresentados as lógicas dos módulos no Apêndice C.
No conjunto de aeronaves que foram selecionadas para serem simuladas numa
determinada data, encontram-se aeronaves de diversas situações, tais como:
a) Aeronaves que decolam e pousam no Brasil;
b) Aeronaves que decolam do exterior e pousam no Brasil;
c) Aeronaves que decolam e pousam no exterior (sobrevoam o Brasil);
d) Aeronaves que decolam do Brasil e pousam no exterior;
e) Aeronaves que decolam e pousam no Brasil interceptando apenas um Fixo ou
Auxílio à Navegação; e
f) Aeronaves que decolam e pousam no Brasil com vôos de aeroporto à aeroporto,
isto é, sem interceptação de qualquer fixo (baliza). Estes são os vôos
denominados DCT (Diretos).
Para que se possa compreender como o Sistema de Simulação Acelerado para Análise
de Fluxo de Tráfego Aéreo cumpre suas tarefas é necessário, em primeiro lugar,
157
explicar de que forma ocorre a evolução das aeronaves e como procede-se à
contabilização de setores.
6.4.4.1 Evolução das Aeronaves em suas Trajetórias:
Conforme está descrito no Capítulo 4 tópico 4.3 dessa dissertação, o deslocamento das
aeronaves é baseado no princípio de que, para existir o deslocamento faz-se necessário a
preexistência de um plano de vôo, e neste plano de vôo deverá constar as seguintes
informações: o aeródromo de partida, os pontos intermediários e o aeródromo de
chegada.
Um plano de vôo pode ser composto, além dos aeródromos de partida e chegada, por
um ou mais pontos característicos isolados, por um ou mais pontos de uma mesma
aerovia, ou ainda, por um ou mais pontos de várias aerovias.
Existe um caso particular em que o vôo é realizado apenas entre aeródromos, isto é, este
tipo de vôo ocorrerá apenas entre o aeródromo de partida (origem) e o de chegada
(destino), sem pontos intermediários entre eles. Este tipo recebe o nome de vôo direto
ou DCT.
O vôo DCT caracteriza-se por ser um vôo de curta duração (Vôos com menos de 30
minutos de duração), e não existe oficialmente uma rota predefinida para esse percurso.
Em geral são realizados dentro da própria região a qual pertencem os aeródromos
envolvidos no vôo.
Essa categoria de vôo será também considerada pela simulação porque são vôos que
ocorrem com muita freqüência em Área Terminal (TMA), região aérea mais propicia à
ocorrência de acidentes aéreos devido ao alto volume de tráfego aéreo em determinados
períodos do dia (horários de pico). Todavia, para o controle de Área Terminal estes vôos
devem ser considerados para que se possa “quantificar” e “controlar” as ocorrências de
vôos principalmente nas regiões de terminais (aproximação). Outra característica dos
vôos DCT ou diretos diz respeito ao fato de que eles jamais deverão estar em setores
158
diferentes, e se isto vier a ocorrer o Sistema de Simulação Acelerado para Análise de
Fluxo de Tráfego Aéreo deverá registrar a ocorrência de erro neste vôo.
Se houver um vôo entre os aeródromos e estes aeródromos pertencerem a setores
diferentes mesmo que estejam na mesma região, deverá existir obrigatoriamente um
“ponto de fronteira” para separar as regiões, de modo que Sistema de Simulação
Acelerado para Análise de Fluxo de Tráfego Aéreo possa realizar a transferência entre
os setores. Neste caso fica descaracterizado o vôo DCT.
Para caracterizar-se uma trajetória, o plano de vôo da aeronave deverá conter pelos
menos 1 (um) ponto entre os aeródromos de partida e chegada. A Figura 6.25 abaixo
mostra o perfil de um vôo num espaço aéreo fictício.
Fig. 6.25 – Vôo num espaço aéreo fictício.
A Figura 6.25 apresenta em sua plenitude, vários fatores que iremos considerar para
explicar a sistemática de um vôo e suas relações com outros sistemas e entidades que
compreendem o complexo sistema de gerenciamento e controle de tráfego aéreo.
159
Na figura acima apresentamos dois setores de regiões de FIR (A e B) com os seus
respectivos setores e duas áreas terminais representados pelos números 2 na FIR-A e o
número 3 da FIR-B. No espaço aéreo fictício representamos duas aerovias ou rotas,
onde uma procura descrever uma trajetória de um vôo vindo de um determinado lugar e
pousando na TMA da FIR-B e a outra aerovia procura descrever a trajetória de uma
aeronave realizando o sobrevôo nas diversas FIR. Observando a Figura 6.25 podemos
ter uma idéia de como o Sistema de Simulação Acelerado para Análise de Fluxo de
Tráfego Aéreo deverá realizar a transferência e a contabilização entre os setores. A
política adotada para proceder a transferência é baseada no princípio de que, só haverá
transferência e contabilização de setores se o ponto característico tiver à sua volta mais
de uma região. Os detalhes sobre a transferência e a contabilização entre setores será
melhor explicado no tópico 6.4.4.3.
Na Figura 6.25 poderemos encontrar alguns exemplos de transferências de setores
como é o caso da passagem da aeronave que está saindo do setor 4 da FIR-A e entrando
no setor 5 da FIR-B. Neste exemplo o Sistema de Simulação Acelerado para Análise de
Fluxo de Tráfego Aéreo irá gravar no “arquivo de Eventos” um evento de “Saída do
setor 4 da FIR-A” e um evento de “Entrada no setor 5 da FIR-B”. Esse procedimento
será realizado para todas as aeronaves que estão no conjunto das aeronaves a serem
simuladas numa determinada data e, no final, teremos um histórico completo de todos
os vôos processados para aquela determinada data.
Por diversas vezes nos deparamos com os termos “Plano de Vôo” e “Trajetória” nesta
dissertação, conforme foi descrito no tópico 6.4.2.22 e apresentado nas Figuras 6.22 e
6.23. A princípio pode parecer que os termos acima refiram-se à coisas diferentes, na
verdade não são, a trajetória é o resultado da combinação do plano de vôo com alguns
detalhes a mais que a fazem diferir do plano de vôo. O Capítulo 5, tópico 5.3, apresenta
mais detalhes sobre arquivo plano de vôo, porém, a Figura 6.26 apresenta o resultado
da combinação entre o plano de vôo e a trajetória propriamente dita.
160
N.
Trajetória
N.
Ponto
Nome
Ponto
Altitude
(m)
Velocidade
(m/s)
Coordenada
X (m)
Coordenada
Y (m)
Hora
Bloqueio
Fig. 6.26 – Arquivo de Trajetória.
6.4.4.1.1 Descrição dos Atributos do Arquivo de Trajetória:
Todas as aeronaves, a princípio, deverão ter uma trajetória associada ao seu vôo, exceto
nos casos em que o vôo é do tipo DCT. Essa trajetória poderá ser composta por apenas 3
pontos, onde o primeiro e o último serão os aeródromos de partida e de chegada.
Por convenção, a “Trajetória” é dotada de um identificador o qual descreve a seqüência
de pontos que uma aeronave deverá cumprir para realizar o seu plano de vôo conforme
apresentado no RPL. Portanto, abaixo apresentaremos a descrição de cada campo da
trajetória, a saber:
N. da Trajetória: É o código que identifica a trajetória.
N. do Ponto: Contém o número de cada ponto da trajetória.
Nome do Ponto: Conterá o nome do ponto ou o nome do aeródromo.
Altitude : Contém altitude em metros de cada ponto.
Velocidade : Contém a velocidade em metros/segundo de cada ponto.
Coordenada X: Posição X do ponto ou do aeródromo.
Coordenada Y: Posição Y do ponto ou do aeródromo.
Hora Bloqueio: Contém a hora de chegada no ponto ou no aeródromo.
161
Por convenção assumimos que um ponto é de fronteira quando a ele estiver agregado
mais de um setor de fronteira. Sendo assim, quando o Sistema de Simulação Acelerado
para Análise de Fluxo de Tráfego Aéreo estiver processando a passagem da aeronave
nos diversos pontos da trajetória, o campo “N. do Ponto” é quem determinará se o ponto
é de fronteira ou não. Mais detalhes encontram-se no Capítulo 5 tópico 5.2.
O conteúdo do campo N. do Ponto conterá um “índice” que fará uma ligação
(relacionamento) entre os arquivos Trajetórias e Pontos Característicos para obter os
setores que estarão demarcados pelo ponto. Portanto, quando o Sistema de Simulação
Acelerado para Análise de Fluxo de Tráfego Aéreo identificar que o ponto a ser tratado
é de fronteira, ela registrará o horário de bloqueio que é o instante em que passar pelo
ponto procederá à transferência e à contabilização entre os setores de entrada e saída. Se
o ponto não for de fronteira, o sistema regis trará apenas o horário de bloqueio da
aeronave em relação ao ponto e dará continuidade a evolução da aeronave, buscando os
próximos pontos da trajetória.
6.4.4.2 Processo de Evolução das Aeronaves:
A trajetória da aeronave apenas descreve o caminho a ser seguido e quais são as
condições para se chegar em cada ponto. De posse dessas informações, o processo de
evolução dividirá o percurso nas seguintes fases a saber:
a) Fase de Decolagem;
b) Fase de Subida;
c) Fase de Trajetória; e
d) Fase de Pouso.
Todas essas fases estão descritas em detalhes no Capítulo 4 dessa dissertação.
162
6.4.4.2.1 Adaptação da Fase de Decolagem para o Protótipo:
Esta fase representa o início do vôo de uma aeronave, onde serão considerados os
parâmetros de performance da mesma e os parâmetros referentes ao aeródromo para dar
prosseguimento à fase de decolagem. Para o “protótipo do Sistema de Simulação
Acelerado para Análise de Fluxo de Tráfego Aéreo” este procedimento, extraído do
simulador de Radar, sofreu algumas adaptações devido ao propósito que é dado a este
simulador. No Capítulo 4 tópico 4.2, vimos que este procedimento realiza três (3) fases
para completar sua execução. Neste protótipo, por orientação dos gerentes ATFM, a
fase de decolagem terá apenas 2 etapas representando a fase de “sub ida na decolagem” e
seu “término”.
A fase “rolagem na pista” foi desprezada porque os gerentes ATFM não estão
interessados em saber o tempo que uma aeronave ficou no pátio ou realizou o táxi ou,
quanto tempo levou para realizar a “rolagem na pista” para iniciar a decolagem. Estes
dados são muito importantes para outros tipos de simuladores como o de Área Terminal
e o de Torre. Porém, para este tipo de simulador estão em foco outros tipos de variáveis
que serão mais importantes para a conclusão da análise de fluxo de tráfego aéreo nos
setores. É por este motivo que a fase anterior foi desprezada. O que na verdade os
gerentes ATFM estão interessados em saber é exatamente quanto tempo uma aeronave
permaneceu num setor e se esta permanência trouxe algum tipo de alerta para o setor.
A decolagem adaptada para o protótipo do “Sistema de Simulação Acelerado para
Análise de Fluxo de Tráfego Aéreo” inicia a evolução considerando que a aeronave já
esteja posicionada no aeródromo de partida e com a velocidade de subida na decolagem,
ou seja, assume-se que a aeronave começou a sair da pista e está com os parâmetros de
proa, velocidade, altitude e razão de subida nas condições de ir interceptar o primeiro
ponto de sua trajetória. O término da fase de decolagem é sinalizado quando a aeronave
alcança a altitude de “915 m” ou 3.000 FT (pés) acima do aeródromo. Alcançando esta
altitude, a aeronave será sinalizada para executar a próxima fase que denominamos de
“fase de Subida”. A Figura 6.27 abaixo apresenta todas as fases de um vôo a ser
executado pelas aeronaves.
163
Fig. 6.27 – Evolução de uma aeronave nas diversas fases do vôo.
6.4.4.2.2 Fase de Subida:
A subida compreende a fase que se inicia logo após a fase de decolagem e termina
assim que a aeronave intercepta o “primeiro ponto da trajetória” com a altitude e
velocidade determinada por esse ponto. Para que a aeronave consiga abandonar a fase
de subida, é necessário que ela esteja com a altitude e velocidade indicadas para chegar
no ponto. Se a aeronave não atingir as condições conforme descrita acima, isto significa
que ela ainda não está com a altitude e a velocidade necessária para cumprir as regras do
procedimento de Subida do espaço aéreo em questão. Sendo assim, a aeronave
permanecerá nesta fase até que atinja as condições planejadas no plano de vôo, mesmo
seguindo sua trajetória para interceptar os próximos pontos da mesma.
Pode ocorrer que algumas aeronaves, durante a evolução, não consigam atingir a
velocidade e altitude do ponto conforme planejado no plano de vôo. Isto pode ocorrer
devido às características de performance de cada aeronave. Em geral elas conseguem
atingir as condições antes de interceptar o “segundo ponto”, porém existem aeronaves
que conseguem atingir as condições antes de interceptar o “primeiro ponto”. Se isto vier
a ocorrer os dados de altitude e velocidade permanecerão inalterados até que a aeronave
Decolagem Subida Trajetória
915 m
Pouso
Pto 1
Fase DEP à
Pto 2 Fase SUB à
Pto 1 a 3 - fase TRJ
Pto 3
164
atinja o primeiro ponto e, quando isto acontecer, ela abandonará esta fase. A Figura
6.27 mostra graficamente o início e o término desta fase.
Nesta fase a aeronave estará voando com a razão de subida na decolagem e estará se
dirigindo para alcançar a velocidade de cruzeiro, que é a velocidade a ser atingida
quando ela interceptar o primeiro ponto da trajetória.
6.4.4.2.3 Fase de Trajetória:
A Trajetória compreende a fase que se inicia logo após a fase de subida e termina assim
que a aeronave intercepta o último ponto da trajetória. A evolução entre os pontos dar-
se-á através dos seguintes cálculos:
a) Posicionamento da aeronave (x, y) – Movimento retilíneo;
b) Velocidade da aeronave;
c) Altitude da aeronave;
d) Proa e Curvas;
As equações que descrevem cada operação dos tópicos citados acima, encontram-se
descritas em detalhes no Capítulo 3 no tópico 3.2.
Nesta fase o Sistema de Simulação Acelerado para Análise de Fluxo de Tráfego Aéreo
promoverá a evolução da aeronave a cada 1 segundo orientando-a a chegar nos valores
que foram determinados para interceptar cada ponto de sua trajetória. Os cálculos de
movimento, velocidade, altitude e proa, são sistematicamente voltados para que
aeronave consiga cumprir o planejado de sua trajetória, obedecendo rigorosamente seus
parâmetros de performance. Durante a evolução do vôo o Sistema de Simulação
Acelerado para Análise de Fluxo de Tráfego Aéreo estará a todo instante verificando se
algum cálculo extrapolou os parâmetros de performance da aeronave e se isto ocorrer no
mesmo instante ela procurará corrigir de modo que o vôo fique o ma is próximo possível
do real.
165
A aeronave durante a fase de trajetória voará obedecendo as altitudes e velocidades
conforme estão descritas em cada ponto da trajetória e, durante esta fase, voará com a
velocidade de cruzeiro e razão de subida em cruzeiro.
6.4.4.2.4 Fase de Pouso:
O Pouso compreende a última fase de um vôo e é o procedimento responsável por
colocar a aeronave no solo nas condições ideais. Para se obter as condições ideais de
pouso é necessário que o Sistema de Simulação Acelerado para Análise de Fluxo de
Tráfego Aéreo possa aplicar os requisitos fundamentais para que a aeronave comece o
processo de descida dentro dos padrões de velocidade e altitude coerentes para esta fase.
Esses princípios têm o objetivo de diminuir a velocidade e altitude da aeronave que, no
início da descida, encontra-se com esses parâmetros fora dos padrões normais para se
executar a descida até o aeródromo de destino. Durante a fase de trajetória a aeronave
voa com a velocidade de cruzeiro e altitudes que são determinadas pelos pontos. Ao
iniciar a fase de pouso, ou a descida, a aeronave precisará chegar ao aeródromo com a
“velocidade de aproximação” e com a “altitude do aeródromo”. Deste modo os
seguintes princípios deverão ser aplicados para que tenhamos um pouso próximo do
real.
Princípio 1:
A equação abaixo fornecerá a “distância ideal” para que a aeronave inicie o
procedimento de descida chegando ao aeródromo de destino dentro das condições
ideais de pouso. Chegando nesta distância a velocidade (velocidade de cruzeiro)
permanecerá constante e a altitude de demanda da aeronave apontará para a
elevação do aeródromo de pouso, de modo que o Sistema de Simulação Acelerado
para Análise de Fluxo de Tráfego Aéreo possa evoluir a aeronave até a altitude
determinada, conforme mostra a figura abaixo.
166
Nomenclatura :
AltUltPto = Altitude do último ponto da trajetória.
Pto. 1 = Ponto Ideal de Descida (DPID).
Pto. 2 = Ponto de desaceleração.
Pto. 3 = Ponto Ideal de Aproximação.
AltAerodArr = Altitude do aeródromo de chegada.
20 = 1 / 0.05 (equivalência a uma rampa de 5%)
Fig. 6.27-a – Demonstração do Ponto Ideal na Aproximação (Pouso).
ß Limite do Setor da TMA Setor A
Setor D
Setor C
18300 m
DPID= 20 x (AltUltPto – AltAerodArr)
Último ponto da Trajetória ↓
DPID = 20 x ( AltUltPto – AltAerodArr )
Setor B
1
2
3
167
Princípio 2:
A equação abaixo fornecerá a “distância ideal” para que a aeronave inicie o
procedimento de descida chegando ao aeródromo de destino com a “velocidade de
aproximação”. Chegando nesta distância o Sistema de Simulação Acelerado para
Análise de Fluxo de Tráfego Aéreo continuará a evolução da aeronave até que ela
atinja a altitude do aeródromo de destino e, paralelamente, a velocidade esteja
também dentro das condições ideais de pouso.
Nomenclatura:
VCruz = Velocidade de cruzeiro da aeronave.
VelAPX = Velocidade de Aproximação da aeronave.
DAPX = Distância Ideal do ponto de Aproximação (18300 m – 10 NM)
TDesacel = Tempo de desaceleração (redução para chegar na VelAPX).
DDesacel = Distância de desaceleração (redução para chegar na VelAPX).
DPIND = Ponto Ideal de início de desaceleração
DPID = Ponto Ideal de início de descida.
VCruz = Velocidade indicada no último ponto da trajetória.
DAPX = 18300
Fórmulas:
TDesacel = (VCruz – VelAPX) / Aceleração
DDesacel = VCruz * TDesacel - (Aceleração * (TDesacel ** 2)) / 2
DPIND = DAPX + DDesacel
DPID = 20 x ( AltUltPto – AltAerodArr )
168
6.4.4.3 Processo de Contabilização e Transferência de Aeronaves
entre Setores:
A contabilização e a transferência de controle de aeronave entre setores obedecerá as
regras oficiais de transferência, conforme são praticadas pelos controladores de tráfego
aéreo em Área Terminal (TMA) e nos Centros de Controle -ACC (vôo em rota):
6.4.4.3.1 Fase de Decolagem e Subida:
Só haverá a contabilização no setor em que se encontra a aeronave quando ela for
ativada na simulação, isto é, quando iniciar sua evolução para interceptar o primeiro
ponto da trajetória. Portanto, quando a aeronave decolar o Sistema de Simulação
Acelerado para Análise de Fluxo de Tráfego Aéreo efetuará a contabilização de mais
uma aeronave presente no setor. Logo após a decolagem a transferência de setor poderá
ocorrer de duas maneiras:
a) Quando a aeronave cruzar o nível da TMA para atingir o 1° ponto de fronteira, ou
b) Quando interceptar o primeiro ponto de fronteira.
(a) (b)
Fig. 6.27-b – Fase de Decolagem e Subida.
Decolagem
Limite da TMA à
Setor A Setor B
Setor TMA
169
6.4.4.3.2 Fase de Trajetória:
A fase de trajetória é aquela em que aeronave deverá evoluir interceptando todos os
pontos previstos em seu Plano de Vôo. Sendo assim, ocorrerá a transferência e a
contabilização entre os setores nos seguintes casos:
a) Quando a aeronave interceptar apenas pontos de fronteira entre setores ou,
b) Quando existirem setores em camadas entre dois pontos de fronteira, de modo
que ela possa cruzar os limites de cada setor para chegar ao ponto planejado.
Neste caso cada cruzamento entre os setores em camadas será contabilizado,
verificando-se então a transferência.
(b) (a)
(b) (b) (a)
(a) (a)
Fig. 6.27-c – Fase de Trajetória.
6.4.4.3.3 Fase de Pouso:
A fase de Pouso é aquela em que aeronave finalizará o plano de vôo associado a si,
independente da altitude em que se encontre no momento. Esta fase consistirá de duas
abordagens diferentes devido à existência de pousos que podem acontecer no Brasil ou
no exterior.
Fase de Trajetória
Setor A
Setor D
Setor C
Setor B
Setor E
170
O pouso no Brasil ocorrerá quando a aeronave interceptar um ponto que faça fronteira
com um setor de área terminal (TMA). Durante sua trajetória poderão até existir outros
pontos após o ponto de fronteira, mas a transferência e a contabilização, só ocorrerão
quando a aeronave cruzar o ponto de fronteira com o setor da TMA. Portanto, quando a
aeronave entrar no setor da TMA a quantidade de aeronaves do setor será incrementada
de uma unidade e, quando pousar, a quantidade será decrementada de uma unidade.
O pouso num aeródromo no “exterior” não será processado porque neste simulador
não estamos considerando vôos que seguem além da fronteira do Brasil. Se fôssemos
considerar a evolução das aeronaves até o pouso no exterior, a Base de Dados ATFM
seria gigantesca pois necessitaríamos contar com os dados de todas as inúmeras rotas
estrangeiras a fim de capacitar o simulador a processar esses vôos.
6.4.4.4 Considerações Sobre os Vôos que Entram e Saem do Brasil:
Os vôos que decolam do exterior e pousam num aeródromo brasileiro traz em seu
plano de vôo a hora de decolagem. Para saber em que momento a aeronave entrará no
Brasil, os gerentes ATFM calculam a “distância” que ela deverá percorrer para chegar
ao ponto de fronteira no Brasil e dividem por sua “velocidade”, obtendo assim o valor
do tempo em que a aeronave interceptará um ponto de fronteira do setor de FIR
brasileiro. Daí por diante a simulação fará sua evolução até que ela pouse num
aeródromo brasileiro.
Nos casos em que a aeronave decole de um aeródromo brasileiro e pouse num
aeródromo estrangeiro, aplicamos a seguinte regra para caracterizar o pouso: A
simulação dará por finalizada a evolução dessa aeronave quando ela interceptar o ponto
que faz fronteira com o setor de FIR brasileiro. Esta regra também é aplicada nos casos
em que determinadas aeronaves decolam e pousam fora do Brasil. Estes são os tipos de
vôos que apenas sobrevoam (cruzam) o espaço aéreo brasileiro. As figuras abaixo
mostram os dois tipos de pousos.
171
Pouso no Brasil:
Pouso no Exterior:
Fig. 6.27-d – Fase de Pouso.
Pouso
ß Limite do Setor da TMA
Setor A
Setor C
Setor B
Setor A
Pouso em aeródromos no exterior
Último Pto. Fronteira no Brasil ↓
Setor C
Setor B
172
Exemplo gráfico do Vôo DCT conforme está explicado no tópico 6.4.4.1
desta dissertação.
Após a decolagem de uma aeronave o Sistema de Simulação Acelerado para Análise de
Fluxo de Tráfego Aéreo realizará a contabilização (incremento da demanda) no setor ao
qual pertence o aeródromo de partida e, logo que a aeronave pousar o sistema
decrementará o valor de demanda desse mesmo setor, uma vez que ambos os
aeródromos pertencem ao mesmo setor de controle.
Fig. 6.27-e – Exemplo de Vôo do tipo DCT.
Aeródromo de Partida
Ponto Médio calculado
Aeródromo de Chegada
Vôo DCT: Vôo realizado entre dois aeródromos onde calcula-se e projeta-se um ponto médio para que a aeronave possa realizar os procedimentos de Decolagem, Trajetória e Pouso. No vôo DCT não haverá mudança de setor, uma vez que os dois aeródromos pertencem ao mesmo setor de controle.
173
6.4.4.5 Tempo Total de Processamento deste Modelo:
Para gerar o resultado da simulação este modelo leva em média 3 minutos para ler,
converter e montar os dados de cenário e tráfegos na memória da workstation Sun,
considerando um conjunto de 3000 aeronaves a serem simuladas. Esta função é
realizada pelo subsistema Supervisor. Em seguida o sistema levará mais 7 minutos para
realizar as funções do Sistema de Simulação Acelerado para Análise de Fluxo de
Tráfego Aéreo (evolução de aeronaves, transferências e contabilizações), e por fim mais
15 minutos para realizar a gravação do resultado da simulação nos arquivos conforme
descrito no Capítulo 5 desta dissertação. Portanto, o tempo despendido para gerar as
informações após a simulação é de 25 a 30 minutos.
A seguir apresentaremos o pseudocódigo do módulo principal do Sistema de Simulação
Acelerado para Análise de Fluxo de Tráfego Aéreo e, no Apêndice C encontra-se a
lógica dos demais módulos que compõem este sistema.
174
6.4.4.6 Lógica do Módulo Principal do Sistema de Simulação
Acelerado para Análise de Fluxo de Tráfego Aéreo – Modelo 1:
Lógica do Módulo:
Alocar memória compartilhada para acessar as Estruturas na BDS Online
Realiza a conexão com o Banco de dados ORACLE
Chama a função DelDataTabela (Elimina das tabelas a data fornecida)
iInd // Índice (-) que representa a anv que está no dia anterior TfmIndAteTF // Índice em segundos que representa 24 horas
TfmTotAnv // Total de aeronaves a serem simuladas
iAnv = 1 // Índice p/acessar a estrutura aeronaves
REPETIR_ENQUANTO iInd <=TfmIndAteTF
REPETIR_ENQUANTO iAnv <= TfmTotAnv
Obtém endereço da aeronave corrente
Obtém a performance da aeronave
Obtém o plano de vôo da aeronave
Chama a Função ChecaCondiçãoAnv
iAnv = iAnv + 1
FIM_REPETIR
iInd = iInd + 1
FIM_REPETIR
// Transfere todos os dados que estão em memória (Sun) para o Banco de Dados
// ... ATFM (ORACLE)
Chama função ParSistema
Chama função EveTrafego
Chama função PlanoVoo
Chama função FTC
Chama função EveSetores
Chama função Eventos
Realiza a Desconexão com o Banco de dados ORACLE
Finalizar o processo
175
6.4.5 Subsistema de Apresentação Gráfica dos Resultados da Simulação
/ Sistema de Análise de Situação – SAS:
O Subsistema de Apresentação Gráfica de Resultados da Simulação foi desenvolvido
para permitir a consulta de qualquer cenário do espaço aéreo brasileiro, cuja demanda
de tráfego aéreo esteja associada aos valores de capacidade praticada, para qualquer
setor ATC ou aeródromo constante da Base de Dados ATFM.
A demanda de Tráfego Aéreo para um setor ATC será estabelecida através da
quantidade de aeronaves presentes no setor simultaneamente, isto é, em um determinado
instante.
A demanda de trafego aéreo para um aeroporto será estabelecida através da quantidade
de aeronaves, em um período de tempo.
Além do gráfico que representa a demanda de tráfego aéreo num determinado setor,
pode-se ter acesso aos planos de vôos das aeronaves, às trajetórias percorridas e aos
eventos de entrada e saída dos setores. O SAS também possibilita ao usuário a
impressão dos seguintes tipos de relatórios, à saber:
a) Planos de vôo;
b) Trajetória;
c) Eventos e
d) Gráfico por setor.
Nesta versão, somente foram considerados os tráfegos com origem no sistema de Plano
de Vôos Repetitivos (RPL), com uma correção gráfica decorrente da relação estatística
entre tráfego regular e não regular.
Este subsistema foi desenvolvido na plataforma Windows utiliza a linguagem de
programação Delphi 3.0 da Borland e acessa as informações no Banco de Dados
ATFM, no ORACLE o qual se encontra em uma workstation Sun Ultra Sparc 5 Server.
176
Seguindo o mesmo padrão que foi adotado no subsistema SGBD, o SAS também só
poderá ser acessado mediante a digitação de um nome de usuário e senha. Nos tópicos a
seguir será apresentadas as telas do subsistema SAS, com mais detalhes.
6.4.5.1 Operação Básica do Subsistema SAS:
: : Ê
Fig. 6.27-f – Concepção Física do Sistema ATFM-IPV.
Após a verificação e validação pelo sistema do nome e senha digitados pelo usuário,
será apresentada a janela ilustrada pela figura abaixo (Figura 6.28).
Para iniciar a operação do sistema o usuário deverá entrar em primeiro lugar com a
“Data simulada”, escolhendo uma dentre as apresentadas. Tais datas foram geradas pelo
Sistema de Simulação Acelerado para Análise de Fluxo de Tráfego Aéreo.
Microcomputador executando o SAS
Workstation Sun executando o BD ATFM no Oracle
Rede Intraer
177
Fig. 6.28 – Tela Principal SAS.
178
Depois de selecionada a Data da simulação, o usuário deverá selecionar a região
desejada (FIR ou TMA), no combobox “Região”, como mostra a Figura 6.29 abaixo.
Fig. 6.29 – Selecionando a Região do Brasil.
179
Selecionada a Região (FIR/TMA ), o usuário deverá selecionar o Setor desejado, como
mostrado na Figura 6.30 abaixo:
Fig. 6.30 – Selecionando o Setor da Região.
180
Após o usuário escolher os parâmetros iniciais como a Data, Região e o Setor, o
subsistema SAS automaticamente mostrará graficamente a demanda de tráfego aéreo do
setor selecionado durante o período de um(1) dia, conforme mostra a Figura 6.31
abaixo. O campo Período, conforme mostra a Figura 6.31, apresenta em seu conteúdo
o período de um dia (default), porém, o usuário poderá inserir outro período dentro das
24 horas da data selecionada.
A partir dessas informações (Data, Região e o Setor), o SAS gera um gráfico com os
eventos de entrada e saída do Setor de uma determinada Região, conforme a data
escolhida.
Se o usuário pretender alterar o período ele deverá, após inserir o novo período, clicar
no botão Atualizar para visualizar o novo gráfico.
6.4.5.2 Considerações Gerais Sobre a Montagem do Gráfico:
A unidade de tempo estabelecida nas equações do Sistema de Simulação Acelerado
para Análise de Fluxo de Tráfego Aéreo é o “segundo” para a realização da evolução
das aeronaves, sendo assim, o SAS, de posse das informações iniciais (Data, Região e
Setor selecionado), carrega em memória todas as informações referentes a todos os
eventos de entrada e saída do setor em questão, conforme foram gravados pelo Sistema
de Simulação Acelerado para Análise de Fluxo de Tráfego Aéreo.
Na simulação os eventos representam apenas os momentos em que as aeronaves
mudaram de setor durante sua trajetória. Após o SAS carregar em memória os eventos
lidos da Base de Dados ATFM, ele converte o horário que foi gravado em segundos,
para hora normal, e apresenta-os na tela.
A linha inferior do gráfico conforme mostra a Figura 6.31, representa o instante de
congestionamento do setor num determinado período. O congestionamento é o
primeiro tipo de alerta indica que num determinado instante, a “capacidade do setor” foi
extrapolada em 80% mantendo-se, porém, e inferior a 100%.
181
A linha superior do gráfico representa o instante de saturação do setor num
determinado período. A saturação é o segundo tipo de alerta indica que, num
determinado instante, a capacidade do setor atingiu ou superou a 100%.
As informações adicionais são representadas na parte inferior da tela, onde temos, na
primeira janela, a apresentação dos dados dos Plano de Vôos das aeronaves que voaram
no setor em questão. Na segunda janela são apresentados os dados relativos à trajetória,
onde coloca-se detalhes da hora de bloqueio em cada ponto, o setor de entrada, o nome
do ponto, a velocidade e nível. Por último apresentamos os detalhes referentes aos
eventos no que diz respeito ao horário de entrada e saída no setor, identificação da
aeronave, tipo de evento (entrada/saída), nome do ponto e a quantidade de aeronaves no
num determinado horário.
Fig. 6.31 – Apresentação Gráfica do Setor.
182
6.4.5.3 Tipos de Relatórios Gerados pelo SAS:
O subsistema SAS foi implementado para gerar os seguintes tipos de relatórios, a saber:
a) Impressão do gráfico do SAS, conforme mostra a Figura 6.32 abaixo;
b) Relatório do Plano de Vôo das aeronaves;
c) Relatório das Trajetórias;
d) Relatório de Todos os Eventos ou somente Eventos do setor selecionado;
e) Relatórios de Alerta ( Congestionamento/Saturação ).
Para imprimir o gráfico do SAS, como está exibido na tela abaixo, o usuário deverá
pressionar o botão direito do mouse sobre o gráfico e selecionar a opção “Visualizar
Impressão”. O resultado da impressão será apresentada na Figura 6.33 abaixo.
Fig. 6.32 – Preparação para Gerar a Impressão do Gráfica do Setor.
183
Fig. 6.33 – Impressão do Gráfica do Setor.
Esta figura apresenta o modelo de como ficou a impressão gráfica do setor selecionado.
Para imprimir, basta ter uma impressora conectada ao micro, ou em rede, e clicar no
botão impressora, na barra de tarefas, conforme mostra a Figura 6.33.
Os demais relatórios que serão apresentados abaixo foram gerados seguindo os mesmos
mecanismos conforme descrito para a impressão gráfica do setor, ou seja, para gerar o
relatório de Planos de Vôos, Trajetória e Eventos, o usuário deverá selecionar a janela o
qual pretende-se gerar o relatório e clicar o botão direito da mouse para obter a
visualização do relatório escolhido. Em seguida basta envia-lo para a impressora. As
figuras a baixo apenas exemplificam algumas tipos de relatórios que são possíveis de
serem gerados no SAS.
184
6.4.5.3.1 Relatório de Eventos:
Este relatório apresenta em detalhes todas as informações referentes ao fluxo de tráfego
aéreo que ocorreu numa determinada data, em um determinado setor do espaço aéreo
brasileiro, conforme mostra a Figura 6.34 abaixo. As informações que compõem este
relatório são:
Hora: Em que ocorreu o evento;
Aeronave: Identificação da aeronave;
Evento: Tipo do evento, que pode ser de entrada ou saída no setor;
Estado do Setor: Pode estar Normal, Congestionado ou Saturado no período;
Ponto: Identificação do Ponto ou Aeródromo em que a aeronave mudou de setor;
Qtd de Anv : Quantidade de aeronaves no Setor nesta hora.
Fig. 6.34 – Relatório de Eventos.
185
6.4.5.3.2 Relatório de Alerta:
Este relatório apresenta em detalhes todas as informações referentes ao estado do setor
no que diz respeito ao nível de alerta, conforme mostra a Figura 6.35 abaixo. De posse
desse relatório os gerentes ATFM poderão tomar as medidas cabíveis para solucionar os
problemas de “Congestionamento e Saturação” do setor.
Fig. 6.35 – Relatório de Alerta.
186
6.4.5.4 Considerações Finais Sobre o SAS:
O subsistema SAS tornou-se uma ferramenta fundamental para a execução dos
trabalhos realizados pelos gerentes ATFM no NuATFM. Além de ser uma ferramenta
de fácil manipulação, ele conseguiu na sua amplitude traduzir e auxiliar a real
necessidade dos gerentes ATFM como um produto bastante versátil para a finalidade
proposta. É lógico que muita coisa ainda há de ser feita para melhorá- lo, no que diz
respeito principalmente a performance quando utilizado com a rede Intraer (Rede do
Comando da Aeronáutica).
Hoje o SAS é uma realidade, estando já em utilização nas cidades de Brasília, Rio de
Janeiro, Belo Horizonte, Curitiba e São Paulo. Essas localidades foram escolhidas para
serem “Centros de Gerenciamento de Fluxo de Tráfego Aéreo” pelo Comando da
Aeronáutica. Sendo assim, esses Centros passaram a receber as informações, via rede
Intraer, da situação aérea de suas localidades. Essas informações são geradas pelo
subsistema Supervisor e o Sistema de Simulação Acelerado para Análise de Fluxo de
Tráfego Aéreo nas workstations localizadas no IPV.
Os tempos médios de respostas obtidos pelo SAS via rede Intraer nas cidades de São
Paulo e Rio de Janeiro, foram de 2’45’’ à 3’20’. Nas cidades de Brasília e Belo
Horizonte os tempos médios de respostas ficaram em torno de 4’10’’ à 5’20’’. Os altos
tempos registrados em Brasília e Belo Horizonte devem-se a baixa performance da rede
Intraer nessas localidades.
Sabemos que a curto prazo em algumas localidades como é o caso das citadas acima os
tempos de resposta ficarão com os níveis atuais, mas já existe uma preocupação do
Comando da Aeronáutica em melhorar a performance da rede Intraer a médio prazo.
6.5 Arquitetura do Hardware:
O Sistema de Simulação Acelerado para Análise de Fluxo de Tráfego Aéreo foi
concebido sob as plataformas UNIX e Windows. A escolha do Sistema Operacional
UNIX visou garantir que a parte simulada, isto é, todos os processos e dados ficassem
num sistema operacional mais robusto, de maneira que os processos pudessem ser
187
executados a qualquer hora do dia sem que tivéssemos que reinicializar a máquina por
falta de memória ou algo parecido. Por outro lado utilizamos a plataforma Windows
para desenvolver os programas que dessem suporte ao subsistema SGBD como também
o subsistema SAS. Os outros componentes que integram o sistema em termos de
hardware como a rede de comunicação de dados e os servidores, serão apresentados nos
tópicos a seguir.
6.5.1 Descrição do Modelo de Rede:
O Sistema de Simulação Acelerado para Análise de Fluxo de Tráfego Aéreo foi
desenvolvido e estruturado segundo o modelo de rede adaptado para o Comando da
Aeronáutica denominada “Intraer” ou simplesmente conhecido como a “Intranet do
Comando da Aeronáutico”. A Intraer segue os mesmos princípios funcionais da rede
Internet, mas por enquanto não pode ser aberta ao público devido a fatores de
segurança. Entretanto, à medida que os sistemas de segurança de rede estiverem num
nível confiável de segurança acredito que as autoridades militares não se furtarão de
abrir as informações do ATFM para as empresas aéreas brasileiras, bem como a outros
Centros de Gerenciamento de Fluxo de Tráfego Aéreo mundial como os Estados Unidos
e a Europa.
A rede Intraer foi concebida e configurada para atender apenas os trâmites de dados
referentes aos assuntos de ordem militar e pessoal a nível estritamente interno ao
Comando da Aeronáutica. Porém, para atender as necessidades de cada unidade deste
Comando, os especialistas de rede do Comando da Aeronáutica organizaram os
endereços de IP fixo para cada unidade, de maneira que, a partir desse endereço fixo
cada uma das unidades construíssem suas próprias subredes locais e daí então pudessem
trocar informações. Portanto, baseado nessa idéia, o IPV, que é uma das unidades do
Comando da Aeronáutica procurou dentro dos seus recursos adaptar-se ao serviço da
rede Intraer de modo que tornou-se possível o desenvolvimento deste sistema cujo
objetivo é de fornecer o serviço de ATFM a qualquer unidade do Comando da
Aeronáutica desde que ela esteja cadastrada no banco de dados ATFM, e possua este
188
protótipo para poder visualizar as informações geradas por esse sistema. A Figura 6.36
abaixo apresenta a arquitetura do hardware do simulador.
: : : Ê
: : :
Fig. 6.36 – Arquitetura do Simulador.
6.5.2 Descrição do Servidor de Banco de Dados:
Conforme está representado na Figura 6.36, o servidor de banco de dados ATFM está
estruturado e configurado numa Workstation Sun Ultra Sparc 5 com 128 Mb de
memória RAM, 350 Mhz e 10 GB de disco rígido.
Workstation Sun processando o BD ATFM - IPV
FMP – SJC Executando o SAS no IPV
FMP – RJ Executando o SAS
FMP – BR Executando o SAS
FMP – SP Executando o SAS
Workstation Sun processando a simulação-IPV
Rede INTRAER
189
Este servidor utiliza a segunda Workstation Sun, conforme está representado na Figura
6.36, para replicar (Backup) o banco de dados ATFM, de maneira que, se a primeira
deixar de funcionar a segunda entre em operação imediatamente. Todas as informações
referentes à base de dados estática e simulada são armazenadas em tabelas do banco de
dados ORACLE. Atualmente estamos trabalhando com a versão 7.2 do banco de dados
ORACLE, mas a partir de Março de 2001 iniciaremos os testes do simulador com a
versão 8i. Estes testes possibilitarão a utilização de novos recursos que a versão 8i
dispõe para que possamos dar início aos conceitos do plano de vôo via Internet, já
descrito nesta dissertação.
6.5.3 Descrição do Servidor de Processos:
Como também está representado na Figura 6.36 acima, o servidor de processos da
ATFM utiliza uma Workstation Sun ultra sparc 5 com 128 Mb de memória RAM, 350
Mhz e 10 GB de disco rígido e divide suas tarefas em servidor de processos o qual
entende-se por processos todos os programas e módulos desenvolvidos que tem o
objetivo de realizar a pesquisa de dados, a conversão de dados e, por conseguinte,
realizar a evolução de um conjunto de aeronaves previamente selecionadas por meio de
uma data, de modo que, no final da simulação os gerentes ATFM possam consultar,
através do subsistema SAS, os resultados da simulação gerados pelo Sistema de
Simulação Acelerado para Análise de Fluxo de Tráfego Aéreo.
A segunda tarefa desta Sun diz respeito ao recebimento (Backup) das informações do
Banco de Dados ATFM enviados via rede Intraer pela Workstation Sun servidora de
Banco de Dados ATFM. As Workstation Sun, servidoras de banco de dados e de
processos, são totalmente dedicadas às suas tarefas de servidoras, visando deste modo
garantir que não haverá nenhuma baixa na performance ou sinais de degradação se elas
estiverem executando apenas o que foram programadas e configuradas para fazer.
A arquitetura do simulador, conforme mostra a Figura 6.36, já é uma realidade para o
NuATFM do IPV. Atualmente quem prepara e executa a simulação são os próprios
gerentes ATFM. Entre suas tarefas diárias inclui-se o planejamento das datas a serem
190
geradas pela simulação, bem como reportar ou corrigir qualquer falha que venha ocorrer
no sistema (Banco de Dados).
O protótipo do Sistema do Simulação Acelerado para Análise de Fluxo de Tráfego
Aéreo, deixou de ser um mero experimento de gerenciamento de fluxo de tráfego aéreo,
para se tornar uma ferramenta de alta relevância para a realização dos trabalhos de
“Análise de Situação” realizados pelos gerentes ATFM, tanto no NuATFM no IPV,
como, em todos os Centros de Gerenciamento de Fluxo de Tráfego Aéreo do país, onde
está instalado.
Através da utilização dessa ferramenta, desenvolvida no IPV, foi possível, no mês de
Setembro de 2000, realizar o “primeiro curso de Gerenciamento de Fluxo de Tráfego
Aéreo no IPV”, quando se utilizou o SAS para demonstrar as ocorrências de fluxo de
tráfego aéreo em todas as regiões do espaço aéreo brasileiro. Neste sentido a ferramenta
foi de suma importância para as aulas práticas, porque teve-se a oportunidade de
demonstrar para os alunos as ocorrências(Demanda) de fluxo de tráfego aéreo nas suas
respectivas áreas de atuação, bem como treiná- los para o recebimento do SAS em seus
futuros Centros de Gerenciamento de Fluxo Tráfego Aéreo.
191
CAPÍTULO 7
SISTEMA DE SIMULAÇÃO ACELERADO PARA ANÁLISE DE FLUXO DE
TRÁFEGO AÉREO (MODELO 2)
7.1 Considerações Geral:
O “Modelo 2” do Sistema de Simulação Acelerado para Análise de Fluxo de Tráfego
Aéreo foi modelado e desenvolvido com o intuito de diminuir o tempo de
processamento da “cinemática” de evolução das aeronaves durante a simulação como
também melhorar o tempo de gravação do resultado da simulação no Banco de Dados
ATFM. Este modelo foi modelado e estruturado para atender não só o Gerenciamento
“Estratégico”, mas também os Gerenciamento “Pré-Tático e Tático” do ATFM. As
descrições dos modelos de Gerenciamento encontram-se no Capítulo 2 tópicos 2.5.7 e
2.5.8.
Portanto, este modelo tem a característica de poder atender os gerentes ATFM seja no
âmbito do IPV (local) como também nas FMP (estações remotas) com uma ferramenta
que lhes proporcionará consultas mais rápidas, principalmente quando acessadas via
rede Intraer, além de ser um subsistema que procurará atender os diversos tipos de
gerenciamento que a ATFM necessita.
Outra razão para o desenvolvimento de um novo modelo para Análise de Fluxo de
Tráfego Aéreo, foi o fato de que no modelo 1 utilizava-se as informações de uma tabela
estática denominada Planos de Vôos Repetitivos (RPL), armazenado na Base de Dados
ATFM, enquanto que, neste novo modelo de “cinemática”, o sistema processará tanto
vôos RPL quanto vôos FPL. Os vôos FPL serão enviados de maneira “on line” pelo
CINDACTA I e logo que as mensagens começarem a chegar ao NuATFM, os
subsistemas Supervisor, Conversão e Sistema de Simulação Acelerado para Análise de
Fluxo de Tráfego Aéreo passarão a processar automaticamente estes vôos de modo que,
no final da simulação, os gerentes ATFM tenham uma situação de demanda de tráfego
aéreo mais realista nos setores de cada região do país.
192
A junção dos vôos RPL e FPL atendem a todos os tipos de gerenciamento da ATFM.
No modelo 1 o resultado da simulação não era tão preciso porque a dados de RPL e FPL
(enviados via FAX) representavam apenas uma visão relativa às “intenções de vôos” e,
resultavam no final da simulação em uma demanda “estimada” de tráfego aéreo no
espaço aéreo brasileiro. Considerando que até então não existia no Brasil nenhum tipo
de ferramenta que pudesse auxiliar os gerentes ATFM na elaboração dos seus trabalhos,
o modelo 1 tornou-se uma produto fundamental no apoio as atividades gerenciais,
mesmo tratando a demanda de fluxo de tráfego aéreo baseado em dados repetitivos. A
seguir procuraremos descrever o modelo 2, não como um modelo isolado, mas sim,
como um modelo incremental do modelo 1.
Existem duas diferenças básicas entre os vôos FPL processados no modelo 1 e os vôos
FPL processados neste novo modelo. Essas diferenças serão apresentadas a seguir:
a) No modelo 1 os vôos FPL (ou vôos Eventuais) são enviados pelos Órgãos
Operacionais do Comando da Aeronáutica via Fax ao NuATFM com
antecedência de 12 horas da realização desses vôos. Em seguida os gerentes
ATFM cadastram estas informações no banco de dados, e por fim executam a
simulação conforme a data de realização desses vôos.
b) No modelo 2 o Sistema de Simulação Acelerado para Análise de Fluxo de
Tráfego Aéreo e os demais subsistemas estarão a princípio permanentemente
ativos para receber, tratar e processar as mensagens de vôos tanto dos vôos
regulares (RPL) do dia corrente quanto dos vôos FPL que chegarão ao NuATFM
via meios de comunicação Dial-Up, Intraer, e futuramente Internet.
Por ser um sistema que foi modelado e estruturado para atender apenas a vôos RPL, isto
é, vôos que ocorrem regularmente a cada 15 dias, o modelo 1 até poderia processar os
vôos FPL de maneira “on line”, porém, para adaptá-lo para que pudesse atender esse
novo requisito, teríamos que alterar todo processo atual, desde o subsistema que trata a
base de dados ATFM (estática) até os subsistemas que tratam da simulação. Outro ponto
fundamental seria o tempo despendido para realizar essas mudanças. Sendo assim,
optamos em modelar/implementar um novo modelo de “cinemática”, onde as mudanças
193
apenas ocorressem nos subsistemas ligados a simulação, isto é, preservar-se o
subsistema SGBD (gera a base de dados ATFM) e o subsistema SAS (realiza a
apresentação do resultado da simulação) e modifica o subsistema Supervisor e o Sistema
de Simulação Acelerado para Análise de Fluxo de Tráfego Aéreo.
No modelo 2 estas questões estão praticamente resolvidas tanto em termos de maior
poder de processamento junto aos Planos de Vôos (RPL e FPL “on line”), quanto à
gravação do resultado da simulação no banco de dados, como também na recepção e
execução das informações enviadas de maneira “on line” a NuATFM. Nos tópicos a
seguir apresentaremos mais detalhes sobre a filosofia aplicada no modelo 2.
7.2 Modelo de Evolução de Aeronaves (cinemática) Adaptado para o
Modelo2:
Nos Capítulos 3 e 6 apresentamos o modelo de cinemática adotado nos simuladores de
controle de tráfego aéreo desenvolvidos no IPV, bem como o modelo de cinemática
adaptado para o Sistema de Simulação Acelerado para Análise de Fluxo de Tráfego
Aéreo (modelo 1) descrito nesta dissertação. Para o modelo 2 idealizamos mais uma
adaptação na cinemática esperando que este venha a ser um modelo que suprirá as reais
necessidades de gerenciamento de fluxo de tráfego aéreo, seja de maneira Estratégica,
pré-Tática ou Tática do ATFM.
7.2.1 Considerações Específicas Sobre o Modelo 1:
Para realizar a evolução das aeronaves, transferência e contabilização entre setores,
como também gerar a gravação do resultado da simulação, o Sistema de Simulação
Acelerado para Análise de Fluxo de Tráfego Aéreo do modelo 1 dependerá das
seguintes tarefas a saber:
a) O processo de simulação inicia-se pelo subsistema Supervisor que através dos
parâmetros de entrada digitados pelo gerente ATFM, se encarrega de ler,
interpretar, validar e converter os dados de cenário e de aeronaves que por sua
194
vez serão armazenados em memória para serem processados pelo Sistema de
Simulação Acelerado para Análise de Fluxo de Tráfego Aéreo (modelo 1).
b) Após realizar a conversão e o carregamento dos dados em memória o subsistema
Supervisor ativará o Sistema de Simulação Acelerado para Análise de Fluxo de
Tráfego Aéreo que, por sua vez, mapeará a área de memória comum aos dois
subsistemas, dando início à simulação a partir de aeronaves cujo horário previsto
de decolagem esteja previsto para o dia anterior à data de simulação escolhida
pelos gerentes ATFM e, o horário de pouso esteja previsto para ocorrer na data
escolhida. Deste modo, as demais serão ativadas no instante em que o número
de ciclos realizado pelo Sistema de Simulação Acelerado para Análise de Fluxo
de Tráfego Aéreo seja igual ao horário de sua decolagem. A simulação só
finalizará sua execução no instante em que completar 86400 ciclos, que
corresponde às 24 horas de um dia a ser simulado.
c) Como o processo de evolução das aeronaves é de forma cíclica, isto significa
que a “cada 1 segundo” as aeronaves da base de dados em memória serão
chamadas pelo Sistema de Simulação Acelerado para Análise de Fluxo de
Tráfego Aéreo para realizar mais uma etapa de sua evolução rumo a cumprir o
seu Plano de Vôo preestabelecido. Portanto, neste modelo o Sistema obedecerá
rigorosamente o horário de decolagem de cada aeronave para poder ativar sua
evolução.
d) O término da evolução das aeronaves acontecerá quando, elas chegarem a
cumprir todo o Plano de Vôo e pousarem nos seus respectivos aeródromos no
Brasil ou quando deixarem o país através de um ponto de fronteira com outro
país, momento em que o sistema deixará de considerá- la, uma vez que o
processo de evolução ocorrerá somente até o ponto de fronteira.
e) Outro dado sobre este modelo é que se uma determinada aeronave decolar
próximo das 24 horas do dia selecionado e for pousar no dia seguinte, a Sistema
de Simulação Acelerado para Análise de Fluxo de Tráfego Aéreo registrará sua
evolução no banco de dados até o momento em que ocorrerá o término do
195
processamento, isto é, quando ela chegar a completar os 86400 ciclos. Neste
caso especifico o Sistema de simulação não conseguirá cumprir todo o Plano de
Vôo desta aeronave devido ao limite imposto pelo modelo 1.
7.2.2 Considerações Específicas Sobre o Modelo 2:
Em função dos resultados obtidos pelo modelo 1 e de algumas restrições conforme
estão descritas no tópico 7.2.1 deste Capítulo, como também no Capítulo 6 desta
dissertação, deduzimos que para realizar a evo lução das aeronaves em cada ponto de sua
trajetória bem como processar a parte referente á transferência e a contabilização de
setor, o Sistema de Simulação Acelerado para Análise de Fluxo de Tráfego Aéreo
obrigatoriamente não precisaria processar os vôos a cada um segundo sistematicamente
como faz no modelo 1. Verificamos que aplicando algumas regras, as quais serão
explicadas mais adiante neste Capítulo, e após compararmos os resultados obtidos entre
os modelos, chegamos a conclusão que os tempos obtidos no modelo 2 em comparação
com aqueles obtidos no modelo 1 são realmente muito melhores, não só pelos tempos
de vôos das aeronaves analisados após a simulação, mas também pelo resultado da
transferência entre setores e, consequentemente, pelo melhor resultado obtido na
gravação do resultado da simulação no banco de dados ORACLE.
Sendo assim, projetamos e implementamos o modelo 2 de “cinemática” que tem como
principio básico evoluir as aeronaves uma de cada vez, porém, evoluindo-as em todos
os pontos de sua trajetória desde a Decolagem até o Pouso, sem deixar de registrar os
horários de interceptação em cada ponto da trajetória bem como as transferências e a
contabilização em cada setor ininterruptamente. A outra novidade deste modelo em
relação ao anterior é que, neste, o Sistema de Simulação só “finalizará” a simulação
quando evoluir a “última aeronave” em todos os pontos de sua trajetória, diferentemente
do modelo 1 que era limitado pelo valor de um dia, ou 86400 ciclos.
Neste modelo o Sistema de Simulação Acelerado para Análise de Fluxo de Tráfego
Aéreo cumprirá obrigatoriamente o Plano de Vôo de todas as aeronaves a serem
simuladas e registrará no banco de dados o histórico dos vôos o qual poderão ser
consultados no SAS com intervalo maior que um dia. As informações com mais de um
196
“dia“ poderão ser visualizadas neste modelo principalmente pela sistemática aplicada na
evolução das aeronaves que não se limitará apenas a um dia e, sim após processar o
plano de vôo da última aeronave a ser simulada.
Outra novidade deste modelo em relação ao anterior é que neste calcula-se diretamente
o tempo de interceptação em cada ponto da trajetória levando-se em consideração as
informações de posicionamento, velocidade e altitude que estão inseridas nos pontos
característicos de cada trajetória. Por fim, ocorrerá o processamento de transferência e a
contabilização dos setores caso seja necessário.
Neste modelo é possível saber o instante exato em que a aeronave intercepta cada ponto
da trajetória e quais foram os horários que elas entraram e saíram dos setores durante o
vôo sem precisar simular a cada segundo.
Com relação ao “cálculo do horário de interceptação” em cada ponto da trajetória,
estamos considerando a princípio que os pontos estão agrupados seqüencialmente em
linha reta, mesmo tendo alguns casos em que eles não estejam. Estes Planos de Vôo
chegam em torno de menos de 1% do conjunto de aeronaves a serem simuladas.
Comparando os tempos registrados no modelo 1 em relação aqueles obtidos no modelo
2 para um mesmo conjunto de dados(aeronaves), a diferença registrada nos tempos de
algumas aeronaves foram consideradas praticamente desprezível pelos gerentes ATFM,
mesmo porque as diferenças foram tão pequenas que não chegaram a comprometer em
nada o resultado da simulação.
Em seguida calcula-se a “distância linear” entre o ponto atual e o próximo ponto da
trajetória para poder calcular o “tempo de interceptação” no próximo ponto. Para o
cálculo de interceptação no próximo ponto o sistema realiza a seguinte verificação para
esse cálculo:
Se a velocidade do ponto atual for igual à velocidade do próximo ponto, aplica-se a
seguinte equação para se determinar o tempo de bloqueio no próximo ponto:
Tempo_de_Bloqueio = ( VelocidadeAtualAeronave / Distância dos pontos )
197
Porém se a velocidade do ponto atual for diferente da velocidade do próximo ponto,
aplicam-se as seguintes equações para determinar o tempo de bloqueio no próximo
ponto:
Legenda:
a) D – distância entre os pontos P1 e P2
b) T1 – tempo para atingir a velocidade V2 antes de interceptar P2
c) (*) – ponto fictício para atingir a velocidade V2
d) T2 – tempo a partir de T1 para atingir V2 no ponto P2
e) D1 – distância percorrida para atingir a velocidade V2 antes de interceptar P2
f) D2 – distância percorrida para atingir a velocidade V2 até P2
g) Tf – tempo final para interceptar P2 ou Tempo_de_Bloqueio
T1 (*) T2
V1---------------------------V2-------------------------------------------V2
P1-----------------------------|---------------------------------------------P2
| D1 | D2 = D – D1 |
| ß --------------------------------- D ----------------------------------à |
Vel Prox.Pto – Vel Pto Atual
T1 = ------------------------------------
Aceleração
T1² D1 = Vel Pto Atual – T1 + ----- × Aceleração { Aceleração > 0 à Vpto < Vprox pto } 2
T1² D1 = Vel Pto Atual – T1 - ----- × Aceleração { Aceleração < 0 à Vpto > Vprox pto } 2
198
D2 = D – D1 D2 T2 = ------------------- Vel Prox.Pto Tempo_de_Bloqueio = T1 + T2
7.2.2.1 Fórmula para o cálculo da “Distância Linear”.
Legenda:
a) Dist_Ptos = Distância linear entre dois pontos.
b) AnvX = Coordenada X da aeronave.
c) AnvY = Coordenada Y da aeronave.
d) PtoX = Coordenada X do ponto a ser interceptado.
e) PtoY = Coordenada Y do ponto a ser interceptado.
Dist_Ptos = SQRT ( (AnvX – PtoX)² + (AnvY – PtoY)² )
7.2.2.2 Considerações Sobre o Processo de Transferência de
Setores na Vertical.
Para realizar a mudança de setor no “ponto de fronteira” aplica-se a mesma regra
descrita no modelo 1. Entretanto, para realizar a mudança de setor na vertical, foi
necessário criar um modelo matemático de modo que se possa realizar as possíveis
mudanças nos limites de cada setor em camada (empilhado) entre dois pontos de
fronteira.
Em geral, a mudança de setor na vertical ocorrerá em função de uma variação de
altitude entre dois pontos de fronteira onde durante a evolução do vôo, a aeronave
interceptará um ou mais setores empilhados rumo a atingir a altitude do próximo ponto.
Muitas vezes a variação existe mas não chegará a provocar a mudança de setores. Neste
caso a aeronave permanecerá no setor atual e o Sistema de Simulação Acelerado para
199
Análise de Fluxo de Tráfego Aéreo fará sua evolução para atingir a nova altitude até o
ponto seguinte conforme está estabelecido no seu plano de vôo.
No modelo 1 o Sistema de Simulação Acelerado para Análise de Fluxo de Tráfego
Aéreo encarregava-se de verificar a todo instante (a cada segundo) se uma determinada
aeronave voando entre dois pontos de fronteira com mais de um setor empilhado
deveria ou não mudar de setor na vertical. Durante o vôo de uma aeronave se ela tivesse
que subir ou descer para atingir a altitude do próximo ponto de fronteira e nesta
evolução viesse a cruzar os limites dos setores em camadas, o Sistema de Simulação,
além de evolui- la até a altitude do ponto estabelecido, realizava em paralelo, caso fosse
necessário, a mudança entre os setores em camadas até chegar ao ponto na altitude
desejada.
Porém, no modelo 2, para realizar a transferência em camada foi necessário
implementar uma lógica que utilizasse cálculo geométrico para determinar o instante
exato em que uma aeronave cruzasse os limites de cada setor empilhado, porém, de
maneira calculada, diferentemente do método aplicado no modelo 1 para realização
dessa tarefa. A Figura 7.1 abaixo mostra a representação gráfica da mudança de setor
na vertical (empilhados) e a lógica para realização desta tarefa encontra-se no
Apêndice D.
200
Fig. 7.1 - Mudança de setor na vertical.
Toda a estrutura de hardware, conforme descrita no modelo 1, estão mantidas nesta
nova versão, bem como os detalhes relativos ao subsistema SGBD (Sistema
Gerenciador de Banco de Dados ATFM).
201
7.3 Resultados Obtidos:
O tempo de processamento obtido pelo modelo 2, em relação ao modelo 1, é da ordem
de 45% mais rápido, considerando-se um conjunto de 2500 aeronaves processadas na
simulação.
Nesta versão do protótipo, o subsistema Supervisor foi o único que não alterou o tempo
de processamento conforme descrito no modelo 1. Porém, o Sistema de Simulação
Acelerado para Análise de Fluxo de Tráfego Aéreo e o subsistema Apresentação
Gráfica de Resultados da Simulação, tiveram uma redução significativa nos seus tempos
de processamento.
Uma das principais causas na demora para a geração do resultado da simulação no
modelo 1, era ocasionado pelo tempo significativo de processamento dispendido pelo
Sistema de Simulação na gravação do resultado da simulação em seis(6) tabelas no
Banco de dados ATFM no ORACLE. Sendo assim, para tentar diminuir este tempo, a
princípio procurou-se reduzir o número de tabelas para apenas duas (2), pretendendo-se
ganhar mais rapidez junto ao Sistema de Simulação durante o período de gravação. As
estruturas das tabelas encontram-se descritas no tópico 7.3.3. As tabelas receberam o
nome de “Vôo e Evento”.
A tabela Vôo contém os detalhes referentes aos planos de vôos, apresentando as
informações sobre os aeroportos de origem e destino, os horários de decolagem e de
pouso e um índice para servir de relacionamento com a tabela de Eventos. A tabela
Evento contém todo o histórico da aeronave desde a decolagem até o pouso, além dos
registros de transferência de setores nos pontos de fronteira, bem como a mudança de
setores na vertical.
A modelagem dessas novas tabelas teve como meta principal diminuir o tempo de
gravação dos dados nas tabelas ORACLE pelo Sistema de Simulação durante a
simulação, como também prover ao SAS consultas otimizadas ao Banco de Dados
ATFM, principalmente, quando estiver operando na rede Intraer em locais fora do IPV.
202
Uma pequena mudança foi realizada no SAS para que ele se adaptasse às novas tabelas
implementadas. Porém, nos primeiros testes realizados nesta nova concepção sua
velocidade de processamento ficou mais rápida em relação às consultas realizadas no
modelo anterior.
Esse modelo vem a cada dia se consolidando como uma ferramenta muito importante
principalmente no tocante à fidelidade dos dados e também em relação à rapidez com
que fluem as informações nos diversos equipamentos testados no âmbito do IPV. Além
de estar se consagrando como uma ferramenta realmente veloz, o modelo 2 está
conseguindo fornecer resultados de fluxo de tráfego aéreo e de demanda de tráfego
aéreo de modo que apenas os modelos desenvolvidos nos Estados Unidos e Europa
conseguem fornecer tais informações aos seus gerentes ATFM. Logicamente não está se
comparando este modelo com os encontrados nos países citados acima, mas, estamos a
princípio tentando chegar o mais próximo possível de um modelo que satisfaça
plenamente as necessidades do Gerenciamento de Fluxo de Tráfego Aéreo brasileiro.
A partir do tópico 7.3.1 apresentaremos o Diagrama de Estrutura conforme mostra a
Figura 7.2 deste novo modelo, para que ele possa servir de base para um melhor
entendimento deste novo conceito de “cinemática”. Em seguida mostraremos o
pseudocódigo do módulo principal do sistema e por fim mostraremos a estrutura das
novas tabelas.
Os demais pseudocódigos que complementa a lógica dos módulos deste modelo
encontra-se no Apêndice D desta dissertação.
203
7.3.1 Diagrama de Estrutura do Modelo 2:
Fig. 7.2 - Diagrama de Estrutura do Modelo 2.
Supervisor
Sistema de Simulação Acelerado para Análise de Fluxo de Tráfego Aéreo
DelDataTabela Trajetória Vôo Eventos
Dep/Sub/DirPonto VÔODCT
SalvaEventosMem
SalvaEventosMem
MudancaSetorAlt TransAnvTMA TransAnvSetorAerodChegada ProcessarPouso
ObterSetoresEntrada VerificarSetoresEntrada
Eventos
CalcularDemanda
CalcularDemanda
204
7.3.2 Lógica do Módulo Principal do Sistema de Simulação Acelerado
para Análise de Fluxo de Tráfego Aéreo - Modelo 2:
Lógica do Processo: Alocar memória compartilhada para acessar as Estruturas na BDS On line Realiza a conexão com o Banco de dados ORACLE Chama a função DelDataTabela (Elimina das tabelas a data fornecida) TfmTotAnv // Total de aeronaves a serem simuladas igTotEve = 0 // Índice p/acessar a estrutura eventos iAnv = 1 // Índice p/acessar a estrutura aeronaves REPETIR_ENQUANTO ( iAnv <= TfmTotAnv ) Obtém endereço da aeronave corrente Obtém a performance da aeronave
Obtém o plano de vôo da aeronave Chamar Função Trajetória(...) // Efetua a evolução da aeronave em todos os
// ... pontos da TRJ. iAnv = iAnv + 1 // Aponta para próxima aeronave
FIM_REPETIR // Transfere todos os dados que estão em memória (Sun) para o Banco de dados // ATFM (ORACLE) Chama função Vôo Chama função Eventos Realiza a Desconexão com o Banco de dados ORACLE Finalizar o processo
205
7.3.3 Estrutura das Tabelas de Vôo e Evento do Modelo 2:
TABELA 7.1 – TABELA DE VÔO
Tipo Nome Descrição Number [ 4 ] VooIndiceAnv Índice da aeronave Char [ 7 ] VooIndicativoAnv Indicativo da aeronave Char [ 4 ] VooIndicativoAerodDep Indicativo do Aeródromo de Decolagem Number [ 6 ] VooHoraDep Horário de Decolagem Char [ 4 ] VooIndicativoAerodArr Indicativo do Aeródromo de Chegada Number [ 6 ] VooHoraArr Horário de Chegada (Pouso) Char [ 4 ] VooTipoAnv Tipo da Aeronave Char [ 7 ] VooFrequencia Dias da semana do vôo
TABELA 7.2 – TABELA DE EVENTO
Tipo Nome Descrição Number [ 6 ] EveHoraSeg Horário de interceptação do ponto Number [ 4 ] EveIndiceAnv Índice da aeronave Char [ 7 ] EveIndicativoAnv Indicativo da aeronave Char [ 5 ] EvePonto Indicativo do ponto Char [ 6 ] EveIndicativoSetorE Indicativo do setor de entrada Char [ 6 ] EveIndicativoSetorS Indicativo do setor de saída Number [ 3 ] EveAltitude Altitude da aeronave no ponto Number [ 3 ] EveVelocidade Velocidade da aeronave no ponto Number [ 6 ] EveQuantidade Quantidade de aeronaves no setor Number [ 3 ] EveNivelAlerta Nível de Alerta
207
CAPÍTULO 8
CONCLUSÃO
O crescimento acelerado do movimento aéreo no Brasil nos últimos 8 anos,
principalmente nas regiões de Brasília, Belo Horizonte, São Paulo e Rio de Janeiro,
contribuíram consideravelmente para o atual estado em que se encontra o controle de
tráfego aéreo brasileiro, com o crescente aumento da demanda, sem o correspondente
acréscimo da capacidade de infra-estrutura aeroportuária.
O tráfego aéreo vem aumentando uma média anual de 8%, sendo que, de 1998 a 1999,
subiu para 20,7%. Este aumento produziu, esperas excessivas nas saídas e chegadas
para os aeroportos da Área de Controle da Terminal São Paulo (TMA-SP),
principalmente em horários de pico, aumento nos tempos de vôo devido as longas
esperas em vôo e em solo, provocando excessivo aumento da carga de trabalho dos
controladores nos Centros de Controle de Área ACC Brasília e Curitiba e, no APP e
Torre de Controle de São Paulo.
Os Estados Unidos através do emprego da medida de gerenciamento Tático (considera-
se os vôos que serão realizados no mesmo dia), e a Europa através do emprego da
medida de gerenciamento Estratégico (considera-se os vôos até 2 dias antes de sua
realização), apresentam diferentes maneiras para resolver os problemas relacionados
com a demanda de tráfego aéreo seja nos setores do espaço aéreo, como também em
seus aeroportos. Entretanto, a adoção de aplicativos de outros esquemas de
Gerenciamento de Tráfego Aéreo já em uso por esses países, requer uma análise bem
fundamentada nas especificações de requisitos para saber qual será o tipo de
gerenciamento que mais se aproxima das características do modelo brasileiro, caso
contrário, corre-se o risco de adquirir uma produto que não atende as necessidades
brasileiras.
Portanto, para realizar os primeiros experimentos de ATFM no Brasil os especialistas de
tráfego aéreo adotaram o modelo híbrido de gerenciamento devido as características e
comportamentos do tráfego aéreo no país. Sendo assim, o desenvolvimento dos
208
simuladores propostos no Capítulo 6 (Modelo 1) e Capítulo 7 (Modelo2), foram
elaborados de maneira a atender as especificações dos requisitos que estão descritos no
tópico 6.2 do Capítulo 6 dessa dissertação.
A diferença fundamental entre o comportamento de cada modelo citado acima, está
primeiramente, em relação à forma de cálculo que cada um emprega para evoluir as
aeronaves em suas trajetórias desde a decolagem até o pouso. Em segundo lugar a forma
que é empregada para realizarem a transferência de aeronaves entre os setores,
principalmente os setores que se apresentam em camadas (empilhados) e, finalmente, no
tocante ao tempo de processamento que cada um leva para gerarem as tabelas com os
resultados da simulação que serão utilizadas pelo subsistema SAS para a apresentação
dos dados de aeronaves, trajetórias e o gráfico do setor, que representa a demanda de
tráfego aéreo de um determinado dia daquele setor.
No Modelo 1 a evolução da aeronave ocorre de maneira cíclica, ou seja, a cada segundo
o simulador desloca a aeronave em sua trajetória obedecendo as equações de
cinemática. Durante a evolução da aeronave se a sua altitude neste instante “t” for igual
ao limite superior de um setor em camada, o simulador se encarrega de processar a
transferência da aeronave entre os setores e paralelamente realiza também a
contabilização. Este princípio também aplica-se quando a aeronave intercepta um ponto
de fronteira.
Fundamentalmente no Modelo 2 a evolução da aeronave ocorre de maneira pontual, isto
é, o simulador calcula diretamente o horário de interceptação da aeronave em cada
ponto de sua trajetória através da distância entre os pontos. Se durante a evolução da
aeronave entre dois pontos de fronteira existirem setores empilhados, o simulador
calculará geometricamente o horário exato em que a aeronave cruzará cada limite
superior desses setores. Após o cálculo de interceptação o simulador realizará a
transferência e a contabilização dos Setores.
A forma de cálculo empregada no Modelo 1 segue os conceitos descritos no Capítulo 3
que trata das equações de cinemática, que por sua vez estão associados com o Capítulo
4 que apresenta os procedimentos automáticos que serão empregados durante o vôo das
209
aeronaves. Este modelo trabalha basicamente com Planos de Vôos do tipo RPL (vôos
repetitivos) e evolui as aeronaves a cada período de 1 segundo em suas trajetórias e
encerra o processamento de evolução das aeronaves (cinemática) ao final de 86400
segundos que corresponde a um dia simulado. O tempo total de processamento
considerando as etapas de seleção de aeronaves para simulação, conversão de dados de
aeronaves, simulação e gravação do resultado da simulação será aproximadamente de
25 a 30 minutos, considerando um conjunto de 2500 a 3000 aeronaves.
No Modelo 2 adotamos a forma de cálculo direto para determinar o tempo de bloqueio
das aeronaves em cada ponto (baliza) de suas trajetórias, este encontra-se descrito no
Capítulo 7 tópico 7.2.2. Nesse modelo a evolução é feita desde a decolagem ate o pouso
conforme o plano de vôo, aeronave por aeronave, e os eventos que ocorrem durante a
trajetória são contabilizados. Dessa maneira conseguiu-se determinar o tempo exato dos
vôos, desde a decolagem, passando pelos pontos intermediários até o pouso.
Outra característica desse modelo é que ele trabalha com Planos de Vôos RPL e FPL de
maneira on line, este encontra-se descrito no tópico 7.1 parágrafo 3 do Capítulo 7. A
possibilidade de processar diferentes planos de vôos (RPL e FPL), habilita-o a trabalhar
com os diferentes tipos de gerenciamento, Estratégico, pré-Tático e Tático do ATFM.
A transferência de aeronaves entre setores empilhados estão descritos no tópico 7.2.2.2
do Capítulo 7. O encerramento da simulação só ocorrerá quando o modelo processar a
última aeronave em todos os pontos de sua trajetória, diferentemente do Modelo 1 que
paralisava a simulação após completar os 86400 ciclos. O tempo total de processamento
considerando as etapas de seleção de aeronaves para simulação, conversão de dados de
aeronaves, simulação e gravação do resultado da simulação, será aproximadamente de 7
a 10 minutos, considerando o mesmo conjunto de aeronaves descrita no parágrafo
anterior.
A alteração na forma de processamento do Modelo 1 apresentado no Capítulo 6 em
relação a proposição do Modelo 2 e a implementação de um protótipo para certificação
da viabilidade e de suas vantagens apresentado no Capítulo 7, ilustrou a real
necessidade de modelar e implementar um modelo de cinemática que pudesse ser mais
210
rápido que o modelo 1 de maneira que pudesse alcançar sucesso nos seguintes tópicos:
maior rapidez no processamento dos vôos RPL e FPL “on line”; gravar os dados
oriundos do resultado da simulação de modo que não sobrecarrega-se o processamento
do subsistema SAS sendo operado remotamente e, finalmente, pudesse ser um modelo
que atendesse os três tipos de gerenciamento do ATFM, Estratégico, pré-Tático e Tático
respectivamente. Portanto, todos esses detalhes fazem parte deste novo trabalho.
O Processo de desenvolvimento do Sistema de Simulação Acelerado para Análise de
Fluxo de Tráfego Aéreo nos Modelos 1 e 2 são importantes, pois:
a) Utilizando-se uma base de dados comum aos dois modelos o resultado obtido
atendeu os requisitos de precisão comparados aos dados reais;
b) Contribui com uma ferramenta de Análise de Fluxo de Tráfego Aéreo para o
Núcleo do Gerenciamento de Fluxo de Tráfego Aéreo (NuATFM) a um custo
bastante reduzido, comparativamente ao desenvolvimento de outros sistemas
estrangeiros, bem como, estabelece um compromisso de desenvolvimento de um
software com tecnologia inteiramente nacional, o qual possibilitará aos gerentes
ATFM, a análise e a pesquisa em todas as regiões do país, principalmente
àquelas em que a demanda de tráfego aéreo foram excedidas.
Este protótipo na verdade não tem a pretensão de apresentar a solução dos casos onde
houveram as extrapolações nas capacidades de setores, mesmo porque, não é o foco
dessa dissertação. Porém, ela tem o propósito de simular e gerar o volume de tráfego
aéreo em todos os setores do espaço aéreo brasileiro, no qual compreende-se as regiões
de Controle de Aeródromo, Controle de Aproximação e Controle de Área, sendo que, o
resultado da simulação será apresentado graficamente aos gerentes ATFM, de modo que
possam fazer a análise de situação dos setores afetados e posteriormente tomar as
medidas de gerenciamento para cada caso.
Como extensão para trabalhos futuros prevê-se estudos para implementar o recebimento
das informações de vôos FPL de maneira “on line” ao NuATFM, tendo em vista que,
esses dados sejam processados em tempo real juntamente com o RPL e que possam
211
produzir uma situação de demanda de tráfego mais próxima do real. Melhorar a
sistemática de verificação de erros dos dados de vôos RPL e FPL que são tratados e
processados no CINDACTA I e depois enviados ao NuATFM. Possibilitar a
continuidade dos estudos/pesquisas e o desenvolvimentos de novas tarefas do sistema a
fim de que se possa responder aos novos requisitos determinados pelos especialistas de
tráfego aéreo e gerentes ATFM.
213
REFERÊNCIAS BIBLIOGRÁFICAS
Bianco, L; Dell’Olmo, P; Odoni A. R. Modelling and simulation in air traffic management. Heidelberg: Springer-Verlag, 1997. 201p.
Brasil, Ministério da Aeronáutica. Instituto de Proteção ao Vôo. Especificações preliminares para o desenvolvimento do processo de avaliação da demanda de aeroporto e do processo para análise do fluxo de tráfego aéreo. Rio de Janeiro, 1999a.
Brasil, Ministério da aeronáutica. Diretoria de Eletrônica e Proteção ao Vôo. Concepção Operacional do Centro de Gerenciamento de Fluxo de Tráfego Aéreo do Brasil. Rio de Janeiro, 1999b.
Brasil, Ministério da Aeronáutica. Diretoria de Eletrônica e Proteção ao Vôo. Concepção operacional do banco de dados do gerenciamento de fluxo de tráfego Aéreo do Brasil. Rio de Janeiro, 1998.
Date, J. C. Introdução a sistema de bancos de dados. Rio de Janeiro: Campus, 1991. 674p.
Eno, S. Gerenciamento de fluxo de tráfego aéreo (ATFM ). Encontro Nacional de Navegação Aérea. São Paulo, 1997.
Gane, C. Desenvolvimento rápido de sistemas. Rio de Janeiro: LTC, 1988.
Gane, C.; Sarson, T. Análise estruturada de sistemas. Rio de Janeiro: LTC- Livros Técnicos e Científicos Editora, 1983. 255p.
Houlette, F. Aprendendo windows NT. Rio de Janeiro: Campus, 1994. 300p.
Instituto de Proteção ao Vôo (IPV). EPA: Especificações dos programas de aplicação do sistema de simulação radar de área terminal (SISAT). São José dos Campos, 1984.
Instituto de Proteção ao Vôo (IPV). CNS/ATM: Seminário de comunicação, navegação e vigilância do gerenciamento da tráfego aéreo. São José dos Campos, 1996.
Instituto de Proteção ao Vôo (IPV). SAS: Manual operacional do sistema de análise de situação. São José dos Campos, 2000.
Internacional Civil Aviation Organization (ICAO): Manual de planejamento do serviço de tráfego aéreo. Doc. 9426-NA/924, Montreal, 1984.
214
Internacional Civil Aviation Organization (ICAO): Procedimento para o serviço de navegação aérea. Doc. 4444-RAC/501, Montreal, Thirteenth Edition, 1996
Korth, H. F; Silberschatz,, A. Sistema de bancos de dados. São Paulo: Makron Books, 1995. 753p.
Longman, A. W. Active study. Dictionary of english. Harlow: Longman, 1991. 784p.
Martin, J. Engenharia de informação: Técnicas e abordagens de implementação, São Paulo: Compucenter, 1984.
Mcleod, J. P. E. Simulation. New York: McGraw Hill, 1968.
Mendes, A. Simulador radar no controle de tráfego aéreo: Rio de Janeiro - EAOAr, Monografia, 1987. 63p
Page-Jones, M. Projeto Estruturado de sistemas. São Paulo: Mc Graw-Hill, 1988. 396p.
Pinto, S. B. TWR-3D: Um Simulador para controle de aeródromos com visualização 3 D. São José dos Campos, 143p, Tese de Mestrado em computação. Instituto Tecnológico da Aeronáutica, 1997.
Pressman, R. S. Engenharia de software. São Paulo: Makron Books, 1995. 1056 p.
Rios, A. W. S. SIPAR: Um Sistema computadorizado de baixo custo para treinar controladores em radar de aproximação de precisão. São José dos Campos, 140p, 702245, Tese de Mestrado em computação. Instituto Tecnológico da Aeronáutica, 1992.
Shannon, R. L. System simulation: The art and science. englewood: Pratice Hall, 1975.
Shiller, L. Excelência em software. São Paulo: Makron Books, 1992. 295p.
Shimizu, T. Simulação em computação digital. São Paulo: EDUSP, 1975.
Yourdon, E. Análise estruturada moderna. Rio de Janeiro: Editora Campus, 1990. 836p.
Winter, H; Nuber, H. G. Advanced technologiies for air traffic flow management. Boon: Springer - Verlag, 1994. 224p.
215
APÊNDICE A
Baseado nos modelos de Gerenciamento de Fluxo de Tráfego Aéreo (ATFM) aplicado
nos Estados Unidos e Europa, o Núcleo de Gerenciamento de Fluxo de Tráfego Aéreo
(NuATFM) unidade sediada no Instituto de Proteção Vôo (IPV-CTA), estabeleceu uma
arquitetura para o desenvolvimento das ferramentas de apoio a decisão, conforme
mostra a Figura A.1 abaixo. A seguir apresentaremos uma explicação sucinta de cada
parte que compõe o Fluxograma.
O Processo para determinar Demanda de Tráfego Aéreo caracteriza-se pôr criar e
manter atualizado os Bancos de Dados com as informações dos Plano de Vôo
Repetitivo(RPL) e dos Horário de Transporte (HOTRAN), bem como o armazenamento
dos outros arquivos para prover dados ao Simulador. O objetivo principal a que se
destina esse processo é o de permitir aos gerentes ATFM o acesso aos bancos de dados
o qual possam realizar consultas e obter do sistema relatórios com dados estatísticos ou
de maneira geral poder-se-á obter a demanda de tráfego aéreo, através dos seguintes
situações:
a) Tráfegos decolando ou chegando em qualquer aeródromo;
b) Tráfegos voando em determinado nível de vôo, velocidade ou rota; e
c) Tráfegos decolando de um aeródromo, segundo uma rota e nível de vôo.
O Processo para determinar Capacidade de Tráfego Aéreo é formado pêlos seguintes
tópicos: Capacidade Atribuída, Capacidade Calculada, Análise de Situação e
Simulação.
A Capacidade atribuída é um dos elementos que irá complementar o estudo da Análise
de situação. Este elemento tem pôr objetivo determinar a capacidade (quantidade
máxima de aeronaves) nos setores que compõe um espaço aéreo e nos aeródromos. Esta
informação é adquirida através dos órgãos operacionais (ATC) levando-se em
consideração geralmente experimentos executados pôr controladores de tráfego aéreo
mais experientes.
216
A Capacidade Calculada é um dos elementos que também irá complementar o estudo
da Análise de situação, e tem pôr objetivo determinar a capacidade (quantidade máxima
de aeronaves) nos setores que compõe um espaço aéreo e nos aeródromos. O estudo
cient ífico será baseado nos modelos existentes atualmente, como: IMA 100-18,
Métodos FAA, Harris/IAC e Doratask-Reino Unido/MBB-Alemanha. Em função da
implantação da ATFM brasileira, a Diretoria de Eletrônica e Proteção ao Vôo (DEPV)
nomeou um grupo para realizar este estudo de capacidade de todos os principais
aeroportos e do espaço aéreo brasileiro.
A Análise de Situação e Simulação se fundem porque será através desses dois pólos
que os gerentes de ATFM obterão os resultados do confronto da demanda vs capacidade
de um determinado espaço aéreo ou dos aeródromos em questão. Baseado nisso, será
possível obter os relatórios de uma determinada situação do espaço aéreo brasileiro ou
aeródromo utilizando o módulo Análise de Situação, bem como obter a visualização dos
tráfegos através do módulo Simulação.
O Processo para determinar As Medidas da Gerenciamento de Fluxo de Tráfego
Aéreo (ATFM) forma a terceira e última parte das ferramentas de apoio a decisão do
ATFM. Esta última parte é também conhecida como o processo de “Otimização do
Fluxo de Tráfego Aéreo”. Este tópico compreende um estudo de organizar/sequenciar
os tráfegos desde a saída do aeroporto origem, passando pelo APP e ACC e chegando
ao aeródromo destino de maneira ininterrupta, ou seja, este seria o cenário desejado
tanto para os clientes como para os exploradores de aeronaves. Esta parte não faz parte
do escopo da proposta de tese, principalmente pôr ser um estudo que terá um volume de
material igual ou superior a que se destina a proposta desse trabalho.
Portanto, o propósito a que se destina esse trabalho está baseado exclusivamente na
segunda parte do Fluxograma ATFM, que descreve os tópicos Análise de Situação e
Simulação, conforme mostra figura a seguir.
217
Fig. A.1 – Fluxograma ATFM.
Fluxograma ATFM
VisualizaçãoRelatórios Estatísticas
Tráfegos
AeródromosBalizas
FIR CTA TMA
RotasSetores
DEMANDA
Anuário estatístico
RPL
FPLHOTRAN
AIS
Pan RotasGuia
Aeronáutico
ICA
BDSPEA
Capacidadecalculada
Análise desituação
Capacidadeatribuída
Simulação
RelatóriosEstatísticas
Alocaçãode slot
Slot
MedidasATFM
Msg’s ATFM
219
APÊNDICE B
Este Apêndice descreve a composição funcional de todos os subsistemas (processos)
que interagem com o protótipo, o qual encontra-se descritos nos Capítulos 6 e 7 dessa
dissertação. A Figura B.1 abaixo apresenta o DFD do Sistema ATFM. Em seguida
apresentaremos uma descrição sucinta de cada sistema/subsistema.
Origem dos dados:
As Companhias Aéreas, o Departamento de Aviação Civil (DAC) e os Centros
Integrado de Defesa Aérea e Controle de Tráfego Aéreo (CINDACTA I,II e III), são as
fontes que disponibilizam os dados de cenários, aeronaves, ao NuATFM, para que se
possa realizar o cadastramento e as consultas das informações que irão compor o Banco
de Dados ATFM.
Descrição do Subsistema de Recebimento e Tratamento de Dados:
O NuATFM recebe esses dados via disquete e e-mail das Companhias Aéreas, DAC e
CINDACTAs a cada 15 dias. Logo que os dados chegam ao NuaATFM, os gerentes
ATFM ativam o subsistema para iniciar o processo de leitura, conversão, verificação e
armazenagem dos dados em suas respectivas tabelas no Banco de Dados ATFM. Se
houver alguma incidência de erro durante o processo de tratamento, o arquivo, será
devolvido a quem de direito para proceder as devidas correções.
Descrição do Subsistema de Gerência da Base de Dados do Sistema:
Este subsistema tem a função de apresentar os dados dos arquivos do Banco de Dados
ATFM, a fim de que os gerentes ATFM possam realizar suas atividades de pesquisas e
concessão de novas linhas aéreas para o DAC e Companhias Aéreas.
Descrição do Subsistema de Avaliação e Demanda de Aeroporto:
Este subsistema tem a função apenas de apresentar a demanda de tráfego aéreo de modo
gráfico de qualquer aeroporto nacional. O gráfico será mostrado a partir dos dados de
RPL que representam as intenções de vôos de um determinado período.
220
Descrição do Subsistema Supervisor:
Este tem a função de receber os parâmetros de entrada (data e hora) fornecidos pelos
gerentes ATFM e, de posse desses dados inicia, o processo de leitura, interpretação,
conversão e armazenagem dos dados em memória o qual foram extraídos do Banco de
Dados ATFM para serem manipulados durante a fase de simulação.
Descrição do Sistema Acelerado para Análise de Tráfego Aéreo – Modelo 1:
Este modelo tem a função de evoluir as aeronaves em suas respectivas trajetórias ponto
a ponto, desde a decolagem até pouso, realizando as transferências e as contabilizações
dos setores durante o vôo. Este modelo foi concebido para processar dados estáticos,
isto é, Planos de Vôos repetitivos que serão enviados ao NuATFM a cada 15 dias para
serem simulados. Após a simulação os gerentes ATFM terão um estimado da demanda
de tráfego aéreo em qualquer região (setor) do espaço aéreo brasileiro, bem como dos
aeroportos. Os cálculos que serão utilizados durante o vôo estão descritos no Capítulo 3
e outros detalhes encontra-se no Capítulo 6 desta dissertação.
Descrição do Sistema Acelerado para Análise de Tráfego Aéreo – Modelo 2:
Este modelo tem a função de evoluir as aeronaves em suas respectivas trajetórias ponto
a ponto, desde a decolagem até pouso ininterruptamente e só finalizará o processamento
quando pousar a última aeronave. Diferentemente do modelo 1, que encerrará o
processamento quando atingir 86400 ciclos (24 horas em segundos) ou o equivalente a 1
dia. Além de manipular a base de dados estática (RPL), este modelo processará dados
de FPL e dados radares que serão enviados ao NuATFM do maneira online. No
Capítulo 7 encontra-se mais detalhes deste modelo.
Descrição do Sistema Reprodução dos Resultados da Análise de Fluxo de Tráfego
Aéreo (SAS):
Este subsistema tem a função apenas de apresentar a demanda de tráfego aéreo de modo
gráfico dos setores do espaço aéreo brasileiro e de qualquer aeroporto nacional. O
gráfico será mostrado a partir dos dados de RPL e FPL.
221
Sistema de Simulação
Acelerado para Análise de Fluxo de
Tráfego Aéreo (Modelo 2)
Sistema de Simulação Acelerado
para Análise de Fluxo
de Tráfego Aéreo (Modelo 1)
Sistema de Avaliação
de Demanda em
Aeroportos
BDS ON LINE
CINDACTAs
HOTRANs Aprovadas
DAC
Cias Aéreas
Resultados da Análise SGBD ATFM
BDS OFF LINE
Sistema de Reprodução
dos Resultados da Análise de Fluxo de
Tráfego Aéreo (SAS)
Parecer ATFM
Propostas de HOTRAN
Relatórios
RPLs
Radares
Display
Subsistema Supervisor Cenário e
aeronave
Fig. B.1 – DFD do Sistema ATFM.
Subsistema de Recebimento e Tratamento de dados
Display
Relatórios
Display
Display
FPL online
223
APÊNDICE C
DESCRIÇÃO DOS PSEUDOCÓDIGOS DOS MÓDULOS QUE COMPÕE O MODELO 1
Lógica de Módulo:
- ChecaCondiçãoAnv Entrada: ptTfm - ponteiro para BDS Online paAnv - ponteiro para Aeronave corrente ppPer - ponteiro para performance da Aeronave iIndLoop- índice da iteração (em segundos) Saída: -
Função: Verifica a condição de vôo da Aeronave Descrição: SELECIONA Estado da Aeronave
Caso ‘ATIVA’: Chamar módulo DadosDinâmicos SELECIONA procedimento Caso ‘TRAJETORIA: Chamar módulo Trajetória Caso ‘DEP’: Chamar módulo Decolagem FIM-SELECIONA Caso ‘PENDENTE’: Ativa a aeronave para a simulação FIM-SELECIONA
224
Lógica de Módulo:
- DadosDinâmicos Entrada: ptTfm - ponteiro para BDS Online
paAnv - ponteiro para Aeronave corrente Saída: paAnv - ponteiro para Aeronave corrente
Função: Atualiza os dados dinâmicos (X,Y, Vel, Proa, e Altitude ) da Anv Descrição: SE Velocidade Atual ≠ Velocidade Demanda
Chamar função CR_Vel FIM-SE
SE Proa Atual ≠ Proa Demanda Chamar função CR_Proa
FIM-SE SE Altitude Atual ≠ Altitude Demanda
Chamar função CR_Alt FIM-SE // Atualiza a velocidade de Solo
SE Velocidade Atual = Velocidade Demanda Velocidade Solo = Velocidade Atual
SENAO // Calcula componente horizontal da velocidade
velAnv = ((Velocidade Atual * Velocidade Atual ) - ( RazãoSubida * RazãoSubida )) // Retorna ao vetor velocidade
SE velAnv >= 0 Velocidade Solo = SQRT ( velAnv ) SENAO Velocidade Solo = 0
FIM-SE FIM-SE // Decompõem a velocidade em (x, y) em m/s (passo da aeronave) DEG_RAD = 0.017453292 // Conversão de DEG para RAD DeltaX= (Velocidade Solo x SENO ( Proa Atual x DEG_RAD )) DeltaY= (Velocidade Solo x COS ( Proa Atual x DEG_RAD )) // Verifica se ha variação de velocidade ( aceleração )...
SE Velocidade Atual ≠ Velocidade Demanda // Verifica se acelera ou freia
SE Velocidade Atual < Velocidade Demanda Sinal = 1 SENAO SE Velocidade Atual > Velocidade Demanda Sinal = -1
FIM-SE // Soma a componente de aceleração ( x = Xo + Vot + "1/2 at^2" ) DeltaX= DeltaX + (( Sinal x Aceleração ÷ 2) x SENO(Proa Atual x DEG_RAD))
DeltaY= DeltaY + (( Sinal x Aceleração ÷ 2) x COS(Proa Atual x DEG_RAD))
FIM-SE // Atualiza as coordenadas (x, y) da Aeronave ( x = Xo + Vot + ½ at^2 ) CoordenadaX = CoordenadaX + DeltaX CoordenadaY = CoordenadaY + DeltaY
225
Lógica de Módulo:
- CR_Vel Entrada: ptTfm - ponteiro para BDS Online paAnv - ponteiro para Aeronave corrente Saída: paAnv - ponteiro para Aeronave corrente
Função: Atualiza os dados dinâmicos (X,Y, Vel, Proa, e Altitude ) da Aeronave
Descrição: SE Velocidade Atual > Velocidade Demanda // Diminui a velocidade da aeronave ( v = Vo - at ) Velocidade Atual = Velocidade Atual – Aceleração // Se ultrapassar a demanda, assume a velocidade de demanda SE Velocidade Atual < Velocidade Demanda Velocidade Atual = Velocidade Demanda
FIM-SE SENAO
SE Velocidade Atual < Velocidade Demanda // Aumenta a velocidade da aeronave ( v = Vo + at ) Velocidade Atual = Velocidade Atual + Aceleração // Se ultrapassar a demanda, assume a velocidade de demanda SE Velocidade Atual > Velocidade Demanda Velocidade Atual = Velocidade Demanda
FIM-SE FIM-SE
226
Lógica de Módulo:
- CR_Proa Entrada: ptTfm - ponteiro para BDS Online paAnv - ponteiro para Aeronave corrente Saída: paAnv - ponteiro para Aeronave corrente
Função: Atualiza os dados dinâmicos ( Proa ) da Aeronave Descrição: // Se proa demanda < 0, curva a aeronave indefinidamente
SE Proa Atual < 0 // Curva a aeronave Proa Atual = Proa Atual + RazãoCurva // Normaliza a nova proa SE Proa Atual >= 360
Proa Atual = Proa Atual - 360 SENAO
SE Proa Atual < 0 Proa Atual = Proa Atual + 360 FIM-SE SENAO
SE Proa Atual ≠ Proa Demanda // Calcula diferença entre proas
DifAnter = Abs ( Proa Atual - Proa Demanda ) // Calcula o menor angulo
SE DifAnter > 180 DifAnter = 360 - DifAnter FIM-SE
// Calcula nova proa Proa Atual = Proa Atual + RazãoCurva
SE Proa Atual >= 360 Proa Atual = Proa Atual - 360 SENAO
SE Proa Atual < 0 Proa Atual = Proa Atual + 360 FIM-SE
// Calcula diferença entre proas
DifAtual = Abs ( Proa Atual - Proa Demanda )
// Calcula o menor angulo SE DifAtual > 180
DifAtual = 360 – DifAtual FIM-SE
SE DifAtual < Abs ( RazãoCurva ) SE DifAnter < DifAtual
Proa Atual = Proa Demanda FIM-SE FIM-SE FIM-SE
227
Lógica de Módulo:
- CR_Alt Entrada: ptTfm - ponteiro para BDS Online paAnv - ponteiro para Aeronave corrente Saída: paAnv - ponteiro para Aeronave corrente
Função: Atualiza os dados dinâmicos ( Altitude ) da Aeronave Descrição: SE Altitude Atual > Altitude Demanda
// Diminui a altitude da aeronave ( y = Yo - vt ) altitude Atual = altitude Atual – Aceleração // Se ultrapassar a demanda, assume a altitude de demanda SE altitude Atual < altitude Demanda altitude Atual = altitude Demanda
FIM-SE SENAO
SE altitude Atual < altitude Demanda // Aumenta a altitude da aeronave (y = Yo + vt ) altitude Atual = altitude Atual + RazãoSubida // Se ultrapassar a demanda, assume a velocidade de demanda SE altitude Atual > altitude Demanda altitude Atual = altitude Demanda
FIM-SE FIM-SE
228
Lógica de Módulo:
- Trajetória Entrada: ptTfm - ponteiro para BDS Online paAnv - ponteiro para Aeronave corrente Saída: paAnv - ponteiro para Aeronave corrente
Função: Atualiza os dados dinâmicos ( Altitude ) da Aeronave Descrição: Realiza a passagem da aeronave pôr todos os pontos do plano de vôo
SELECIONA Fase da aeronave Caso ‘ZERO’: Guarda na pilha dados atuais da aeronave Função Operacional = DECOLAGEM Fase = DECOLAGEM Caso ‘DECOLAGEM’: Direciona aeronave ao primeiro ponto da trajetória SE AltitudeAnv = 915m // finalizou a Dep? Fase = SUBIDA FIM-SE Caso ‘SUBIDA’: SE AltitudeAnv = 915m // finalizou a Dep? Fase = DIRPONTO FIM-SE SE AnvX,Y = PtoX,Y // chegou no ponto? Sinalizar na Anv hora de bloqueio
// é ponto de fronteira? SE PtoSetorA ≠ 0 e PtoSetorB ≠ 0 Chamar Função VerificarSetor FIM-SE SE AltitudeAnv = Altitude 1. Ponto Fase = DIRPONTO FIM-SE Fase = SUBIDA FIM-SE Caso ‘DIRPONTO’: SE AnvX,Y = PtoX,Y // chegou no ponto? Sinalizar na Anv hora de bloqueio
// é ponto de fronteira? SE PtoSetorA ≠ 0 e PtoSetorB ≠ 0 Chamar Função VerificarSetor FIM-SE Fase = BREAKPOINT FIM-SE Caso ‘BREAKPOINT’: SE Aeronave Chegou no Último ponto ? SE Pouso é num aeródromo estrangeiro Acessa o setor atual Decrementa o setor atual Chamar Função Eventos Estado da anv = FINALIZADA SENAO
229
Obtém o índice do aeródromo para o pouso
Armazena na pilha X,Y, Alt e Setor do Aeródromo
Acessa o setor atual SE Altitude Aeronave > Nível Superior Setor
Fase = APROXIMACAO SENAO Fase = POUSO FIM-SE
Altitude Demanda = Elevação do Aeródromo
Velocidade Demanda = Vel. Apx. Performance
FIM-SE SENAO Aponta para o próximo ponto SE não existir ponto Estado da anv = FINALIZADA SENAO
Altitude Demanda = Altitude do ponto
Velocidade Demanda = Vel. Do ponto
Fase = DIRPONTO FIM-SE FIM-SE Caso ‘APROXIMACAO’: Obtém da pilha X e Y do aeródromo // chegou no Aeródromo? SE AnvX,Y = AerodX,Y Fase = POUSO SENAO
Obtém da pilha Nível do Setor do aeródromo
SE Altitude Aeronave <= Nível Setor do Aeródromo
Obtém da pilha o Setor do aeródromo
Setor Atual Aeronave = Setor do Aeródromo
Chamar Função VerficarNivAlerta Decrementa Qtd. de aeronaves do
setor Chamar Função Eventos Setor Anterior Aeronave = Setor
Atual Aeronave Fase = POUSO FIM-SE FIM-SE
230
Caso ‘POUSO’: Obtém da pilha X e Y do aeródromo // chegou no Aeródromo? SE AnvX,Y = AerodX,Y Obtém índice do aeródromo para obter setor
de saída Obtém da pilha o Setor do aeródromo Setor Atual Aeronave = Setor do
Aeródromo Decrementa Qtd. de aeronaves do setor Setor Anterior Aeronave = Setor Atual
Aeronave Chamar Função Eventos Estado da aeronave = FINALIZADA FIM-SE
FIM-SELECIONA
231
Lógica de Módulo:
- VerificarSetor Entrada: ptTfm - ponteiro para BDS Online paAnv - ponteiro para Aeronave corrente ppPto - ponteiro para Ponto Característico iTempo - índice de iteração Saída: -
Função: Verificar a entrada e saída da Aeronave nos setores Descrição: Mover os conteúdos dos setores do ponto para um vetor local - iSetor
REPETIR_ENQUANTO i < 7 // É um vôo exterior Brasil ?
SE OrigemVoo = 1 // Seta condição de entrada no Brasil
OrigemVoo = 0 Acessa o setor de entrada no Brasil // Incrementa a demanda do setor e verifica o nível de Alerta chamar função VerificarNivAlerta // Grava o evento de entrada no país
chama função Eventos SENAO
// Verifica se é o mesmo setor da aeronave, se for desconsiderar SE Setor Atual Aeronave = iSetor [ i ] desvia para o REPETIR_ENQUANTO
SENAO // Verifica se o setor é de fronteira
SE iSetor [ i ] = -1 Obtém dados do Plano de Vôo SE é o último ponto ? Interrompe o loop
SENAO desvia para o REPETIR_ENQUANTO SENAO
Obtém o índice do setor através do iSetor [ i ] SE Setor não existe ?
Grava msg. de erro Interrompe o loop
SENAO // Verifica em que nível do setor a aeronave se encontra
SE Nível Inferior Setor <= Altitude da Aeronave <= Nível Superior Setor
Chamar função CalcularDemanda FIM-SE
FIM-REPETIR
232
Lógica de Módulo:
- CalcularDemanda Entrada: ptTfm - ponteiro para BDS Online
paAnv - ponteiro para Aeronave corrente psSet - ponteiro para Ponto Característico iSetor - índice do Setor de entrada iTempo - índice de iteração szPto - nome do Ponto Saída: -
Função: Registra a entrada e saída da Aeronave nos setores Descrição: // Verifica a validade do setor de entrada (iSetor)
SE iSetor <= 0 Grava msg. de erro retorna
FIM-SE Mover iSetor para Setor Atual Aeronave Acessa o setor de entrada através de iSetor
SE Setor de entrada não existe ? Grava msg. de erro retorna
FIM-SE // Incrementa a demanda do setor e verifica o nível de Alerta chamar função VerificarNivAlerta Acessa a posição do setor de saída SE Setor de saída não existe ?
Grava msg. de erro retorna
FIM-SE Decrementa setor de saída
// Grava o evento de entrada e saída nos s etores chama função Eventos
Mover setor atual Aeronave para setor anterior da aeronave Retornar
233
Lógica de Módulo:
- VerificarNivAlerta
Entrada: iSetorEnt - índice para o Setor de Entrada Saída: Nível de alerta – N- normal, C- congestionado , S- saturado
Função: Incrementa demanda do setor de entrada e Verifica se ocorreu extrapolação do setor
Descrição: Acessa o setor de entrada, incrementa e verifica o nível de alerta
Acessa o setor de entrada através do índice iSetorEnt // Incrementa a demanda do setor de entrada DemandaSetorEnt = DemandaSetorEnt + 1 // Sinaliza a condição de normalidade no setor de entrada Setor de entrada dentro da Normalidade // Verifica se houve Alerta de Congestionamento ( 80% ) iTemp = CapacidadeSetorEnt x 0.80 SE DemandaSetorEnt >= iTemp E DemandaSetorEnt < CapacidadeSetorEnt
Sinaliza Alerta de Congestionamento SENAO
// Verifica se houve Alerta de Saturação ( 100% ) SE DemandaSetorEnt >= CapacidadeSetorEnt
Sinaliza Alerta de Saturação FIM-SE
235
APÊNDICE D
DESCRIÇÃO DOS PSEUDOCÓDIGOS DOS MÓDULOS QUE COMPÕE O MODELO 2
Diagrama de Estrutura do modelo 2:
Supervisor
Sistema de Simulação Acelerado para Análise de Fluxo de Tráfego Aéreo
DelDataTabela Trajetória Vôo Eventos
Dep/Sub/DirPonto VÔODCT
SalvaEventosMem
SalvaEventosMem
MudancaSetorAlt TransAnvTMA TransAnvSetorAerodChegada ProcessarPouso
ObterSetoresEntrada VerificarSetoresEntrada
Eventos
CalcularDemanda
CalcularDemanda
236
Lógica do Processo: [Módulo Principal]
Alocar memória compartilhada para acessar as Estruturas na BDS Online Realiza a conexão com o Banco de dados ORACLE Chama a função DelDataTabela (Elimina das tabelas a data fornecida) TfmTotAnv // Total de aeronaves a serem simuladas igTotEve = 0 // Índice p/acessar a estrutura eventos iAnv = 1 // Índice p/acessar a estrutura aeronaves REPETIR_ENQUANTO iAnv <= TfmTotAnv
Obtém endereço da aeronave corrente Obtém a performance da aeronave Obtém o plano de vôo da aeronave
Chamar Função Trajetória(...) // Efetua a evolução da aeronave // em todos os pontos da TRJ.
iAnv = iAnv + 1 // Aponta p/ próxima aeronave FIM_REPETIR // Transfere todos os dados que estão em memória (Sun) para o Banco de
// dados ATFM (ORACLE) Chama função Vôo Chama função Eventos
Realiza a Desconexão com o Banco de dados ORACLE Finalizar o processo
237
Lógica de Módulo:
- Trajetória Entrada: ptTfm - ponteiro para BDS Online paAnv - ponteiro para Aeronave corrente Saída: paAnv - ponteiro para Aeronave corrente
Descrição: Realiza a passagem da aeronave pôr todos os pontos do plano de vôo SELECIONA Fase da aeronave
// AnvVelAtu = Velocidade atual da aeronave (Anv) // PerVelApx = Velocidade de Aproximação performance
// DistAnvPto = Distância da Aeronave ao Ponto // AnvNumBKP = N° do Pto em que a Anv estar
// PlnPtoFrontTMA = Ponto de fronteira com uma TMA Caso ‘ZERO’: Caso ‘SUBIDA’: Caso ‘DIRPONTO’: // Tratamento de vôos com decolagem no Brasil SE vôo é no Brasil // Salva evento de entrada no setor corrente Chamar função SalvaEventosMem Obtém o número de camadas associadas ao
1° ponto de fronteira SE número de camadas >= 2 Chamar função MudancaSetorAlt FIM-SE FIM-SE Obtém horário de decolagem ou o horário de Entrada na FIR Brasil (Hora) i = 1
REPETIR_ENQUANTO i<=PlnQtdPtos Obtém dados do ponto em questão Atribui a Altitude do ponto a aeronave Calcula a distância da aeronave ao ponto Posiciona a aeronave no ponto
SE i = 1 // Calcula a velocidade media no 1° Pto Vel = (AnvVelAtu + VelPto ) / 2 // Calcula o horário de bloqueio HoraCalc = ( DistAnvPto / Vel ) SENAO // Calcula o horário de bloqueio HoraCalc = ( DistAnvPto / AnvVelAtu ) FIM-SE
Atribui a Velocidade do ponto a aeronave // Ajusta o horário de bloqueio no ponto Hora = Hora + HoraCalc // Verifica se o Ponto é de fronteira
SE PlnPtoSetor[1]≠0 E PlnPtoSetor[2] ≠0 // Verifica se Pto faz fronteira com setor
// de TMA SE AnvNumBKP = PlnPtoFrontTMA // Transfere a Anv se o Pouso for no
// Brasil Chama Função TransfAnvTMA
238
// Buscar o próxima ponto Retornar ao loop SENAO // Processar próxima aeronave Retornar ao Cinemática FIM-SE // Verifica se Pto faz fronteira com setor
// do aeródromo de chegada SE AnvNumBKP = PlnPtoFrontAerod // Transfere a Anv se o Pouso for no
// Brasil Chama Função
TransfAnvSetorAerodChegada Chama Função ProcessarPouso
// Processar próxima aeronave Retornar ao Cinemática SENAO // Salva evento de saída setor atual
Chamar função SalvaEventosMem // Processar próxima aeronave
Retornar ao Cinemática FIM-SE // Verifica se é o último Pto da TRJ SE AnvNumBKP = PlnQtdPtos SE Pouso for no Brasil Chama Função ProcessarPouso
// Processar próxima aeronave Retornar ao Cinemática SENAO // Salva evento de saída setor
Chamar função SalvaEventosMem // Processa próxima aeronave
Retornar ao Cinemática FIM-SE FIM-SE Obtém setores em camadas do Pto atual SE N° de camadas > 1
// Obtém setores em camada comuns // entre 2 pontos de fronteira Chama Função ObterSetoresEntrada // Processar transf. de Setores
Chama Função VerficarSetoresEntrada
// Processar transf. de Setores em // camada se necessário
Chama Função MudancaSetorAlt SENAO
// Processar transf. de Setores Chama Função
VerficarSetoresEntrada FIM-SE
239
SENAO // Salva o evento de interceptação do
// Pto sem realizar transf. de setores Chamar função SalvaEventosMem
FIM-SE i = i + 1 AnvNumBKP = AnvNumBKP + 1
FIM_REPETIR // Processa próxima aeronave
Retornar ao Cinemática Caso ‘VOODCT’: Obtém horário de decolagem (Hora) // Salva evento de entrada no setor corrente Chamar função SalvaEventosMem
Atribui a Altitude do Pto Médio a aeronave Calcula a distância da aeronave ao Pto Médio DistAnvPto
// Calcula a velocidade media no Pto Médio Vel = (AnvVelAtu + VelPtoMedio ) / 2 // Calcula o horário de bloqueio HoraCalc = ( DistAnvPto / Vel )
// Ajusta o horário de bloqueio no ponto Hora = Hora + HoraCalc Posiciona a aeronave no ponto Médio
// Salva evento de interceptação no ponto médio Chamar função SalvaEventosMem
Calcula a distância da aeronave ao Aeródromo de chegada DistAnvAerodArr
// Calcula a velocidade media p/o Aeródromo Arr Vel = (AnvVelAtu + PerVelApx ) / 2
// Calcula o horário de bloqueio HoraCalc = (DistAnvAerodArr / Vel )
// Ajusta o horário de bloqueio no ponto Hora = Hora + HoraCalc Atribui a Altitude do Aeródromo a aeronave Posiciona a aeronave no Aeródromo de chegada
// Salva evento de interceptação no ponto médio Chamar função SalvaEventosMem
// Processa próxima aeronave Retornar ao Cinemática
FIM-SELECIONA
240
Lógica de Módulo:
- ProcessarPouso Entrada: ptTfm - ponteiro para BDS Online paAnv - ponteiro para Aeronave corrente Saída: paAnv - ponteiro para Aeronave corrente
Descrição: Realiza o Pouso da aeronave SE Pouso no exterior // Salva evento de saída setor atual
Chamar função SalvaEventosMem // Processar próxima aeronave
Retornar ao Cinemática FIM-SE Obtém as coordenadas do aeródromo de chegada Calcula a distância entre a aeronave e o aeródromo de chegada // Calcula a velocidade média para chegar no aeródromo
Vel = (AnvVelAtu + PerVelApx ) / 2 // Calcula o horário de bloqueio HoraCalc = ( DistAnvAerod / Vel )
// Ajusta o horário de bloqueio para interceptar o aeródromo Hora = Hora + HoraCalc
// Salva evento de saída setor atual Chamar função SalvaEventosMem // Processar próxima aeronave
Retornar ao Cinemática
241
Lógica de Módulo:
- VerificarSetor Entrada: ptTfm - ponteiro para BDS Online paAnv - ponteiro para Aeronave corrente ppPto - ponteiro para Ponto Característico iTempo - índice de iteração Saída: -
Função: Verificar a entrada e saída da Aeronave nos setores Descrição: Mover os conteúdos dos setores do ponto para um vetor local - iSetor
// É um vôo exterior Brasil ? SE OrigemVoo = 1
// Seta condição de entrada no Brasil OrigemVoo = 0 Acessa o setor de entrada no Brasil // Salva o evento de entrada no país
Chama função SalvaEventosMem Retornar a Trajetória
FIM-SE
REPETIR_ENQUANTO i < 7 // Verifica se é o mesmo setor da aeronave, se for desconsiderar SE Setor Atual Aeronave = iSetor [ i ] desvia para o REPETIR_ENQUANTO
SENAO // Verifica se o setor é de fronteira
SE iSetor [ i ] = -1 Obtém dados do Plano de Vôo SE é o último ponto ? Interromper o loop
SENAO Retornar ao loop
SENAO Obtém o índice do setor através do iSetor [ i ]
SE Setor não existe ? Grava msg. de erro Interromper o loop
SENAO // Verifica em que nível do setor a aeronave se encontra
SE Nível Inferior Setor <= Altitude da Aeronave <= Nível Superior Setor
Chamar função CalcularDemanda Interromper o loop
FIM-SE FIM-REPETIR
Retornar a Trajetória
242
Lógica de Módulo:
- SalvaEventosMem Entrada: ptTfm - ponteiro para BDS Online paAnv - ponteiro para Aeronave corrente ppPto - ponteiro para Ponto Característico iTempo - índice de iteração iIndAnv - índice da aeronave Ponto - Nome do Ponto Caraterístico ou Aeródromo iTipoEve - Tipo de Evento – Entrada, Saída ou Pto sem fronteira Saída: -
Função: Armazena em memória os eventos de entrada e saída nos setores e os pontos característicos sem fronteira
Descrição: Incrementa o índice igTotEve // Realiza o swap se necessário ? SE igTotEve = SWAPMAX
// Grava no Banco de dados ATFM os eventos armazenados Chama função Eventos igTotEve = 1
FIM-SE Acessa a estrutura Eventos através do índice igTotEve // Inicializa a estrutura Eventos
EveHoraSeg = iTempo EveIndiceAnv = iIndAnv EveIndicativoAnv = AnvIndicativo EvePonto = Ponto
SELECIONA iTipoEve // Eventos de Entrada e Saída
Caso 0: Acessa a estrutura setor através do setor atual da ..... aeronave Extrai o Indicativo do setor (SetIndicativo)
// Inicializa campo na estrutura Eventos EveIndicativoSetorE = SetIndicativo Acessa a estrutura setor através do setor anterior da ..... aeronave Extrai o Indicativo do setor (SetIndicativo)
// Inicializa campo na estrutura Eventos EveIndicativoSetorS = SetIndicativo Fim-Caso 0
// Evento apenas de Entrada Caso 1:
Acessa a estrutura setor através do setor atual da ..... aeronave Extrai o Indicativo do setor (SetIndicativo)
// Inicializa campo na estrutura Eventos EveIndicativoSetorE = SetIndicativo
// Inicializa campo na estrutura Eventos EveIndicativoSetorS = “ “ Fim-Caso 1
243
// Evento apenas de Saída Caso 2:
Acessa a estrutura setor através do setor anterior da ..... aeronave Extrai o Indicativo do setor (SetIndicativo)
// Inicializa campo na estrutura Eventos EveIndicativoSetorS = SetIndicativo
// Inicializa campo na estrutura Eventos EveIndicativoSetorE = “ “ Fim-Caso 2
// Evento de Ponto sem fronteira Caso 3:
Acessa a estrutura setor através do setor atual da ..... aeronave Extrai o Indicativo do setor (SetIndicativo)
// Inicializa campo na estrutura Eventos EveIndicativoSetorE = SetIndicativo EveIndicativoSetorS = SetIndicativo Fim-Caso 3
FIM-SELECIONA // Converte a velocidade da aeronave de MS para KT (nós) EveVelocidade = AnvVelAtu ÷ ( 1852 ÷ 3600 ) // Converte a altitude de metros para Pés (FT) e depois para // ... centena de Pés (FT) EveAltitude = ( AnvAltAtu x 3.281 ) ÷ 100
Retornar a Trajetória
244
Lógica de Módulo:
- TransfAnvTMA Entrada: ptTfm - ponteiro para BDS Online paAnv - ponteiro para Aeronave corrente ppPto - ponteiro para Ponto Característico iTempo - índice de iteração iIndAnv - índice da aeronave Ponto - Nome do Ponto Caraterístico ou Aeródromo Saída: -
Função: Transferir a aeronave para o setor de fronteira com a TMA Descrição: Acessa a estrutura Plano de Vôo Acessa a estrutura Setor através do índice PlnSetorFrontTMA
// processa a transferência SE AnvSetorAtu ≠ PlnSetorFrontTMA Chamar Função CalcularDemanda(...) FIM-SE
Retornar a Trajetória
Lógica de Módulo:
- TransfAnvSetorAerodChegada Entrada: ptTfm - ponteiro para BDS Online paAnv - ponteiro para Aeronave corrente ppPto - ponteiro para Ponto Característico iTempo - índice de iteração iIndAnv - índice da aeronave Ponto - Nome do Ponto Caraterístico ou Aeródromo Saída: -
Função: Transferir a aeronave para o setor de fronteira com o aeródromo de chegada.
Descrição: Acessa a estrutura Aeródromo Acessa a estrutura Setor através do índice AerSetorEntrada Acessa a estrutura Ponto Característico // Obtém os setores de fronteira do ponto em questão
REPETIR_ENQUANTO i=1, i < 7 SE PlnPtoSetor[ i ] > 0
iSetor [ i ] = PlnPtoSetor[ i ] FIM-SE
FIM-REPETIR // Compara os setores do ponto com o setor AerSetorEntrada REPETIR_ENQUANTO Flag = 0, i=1, i < 7
SE iSetor [ i ] = AerSetorEntrada Flag = 1 Abandonar loop
FIM-SE FIM-REPETIR // Realiza a transferência, se possível
SE Flag = 1 Chamar Função CalcularDemanda(...)
FIM-SE Retornar a Trajetória
245
Lógica de Módulo:
- CalcularDemanda Entrada: ptTfm - ponteiro para BDS Online
paAnv - ponteiro para Aeronave corrente psSet - ponteiro para Ponto Característico iSetor - índice do Setor de entrada iTempo - índice de iteração szPto - nome do Ponto Saída: -
Função: Registra a entrada e saída da Aeronave nos setores Descrição: // Verifica a validade do setor de entrada (iSetor)
SE iSetor <= 0 Grava msg. de erro retorna
FIM-SE Mover iSetor para Setor Atual Aeronave Acessa o setor de entrada através de iSetor
SE Setor de entrada não existe ? Grava msg. de erro retorna
FIM-SE Acessa a posição do setor de saída SE Setor de saída não existe ?
Grava msg. de erro retorna
FIM-SE // Salva os eventos de entrada e saída de setores em memória
Chama função SalvaEventosMem (...) Mover setor atual Aeronave para setor anterior da aeronave Retornar a Trajetória
246
Lógica de Módulo:
- ObterSetoresEntrada Entrada: ptTfm - ponteiro para BDS Online paAnv - ponteiro para Aeronave corrente ppPto - ponteiro para Ponto Característico iTempo - índice de iteração iIndAnv - índice da aeronave Ponto - Nome do Ponto Caraterístico ou Aeródromo Saída: -
Função: Obter setores iguais (em camada) entre dois pontos de fronteira Descrição: Acessa a estrutura Aeródromo Acessa a estrutura Setor através do índice AerSetorEntrada Acessa a estrutura Ponto Característico // Obtém os setores de fronteira do ponto atual
REPETIR_ENQUANTO iTam1=0, i=1, i < 7 SE PlnPtoSetor[ i ] > 0
iSetorAtual [ i ] = PlnPtoSetor[ i ] iTam1= iTam1+1 FIM-SE
FIM-REPETIR Pesquisa o próximo ponto de Fronteira
// Obtém os setores de fronteira do próximo ponto REPETIR_ENQUANTO iTam2=0, i=1, i < 7
SE PlnPtoSetor[ i ] > 0 iSetorProxPto [ i ] = PlnPtoSetor[ i ] iTam2= iTam2+1 FIM-SE
FIM-REPETIR // Compara os setores dos pontos para obter os setores comuns entre // ... eles. Flag = 0 k=1 REPETIR_ENQUANTO i=1, i <= iTam1
REPETIR_ENQUANTO j=1, j <= iTam2 SE iSetorAtual [ i ] = iSetorProxPto [ j ]
iSetorCumuns [ k ] = iSetorProxPto [ j ] k =k+1
Flag = 1 Abandonar loop
FIM-SE FIM-REPETIR
FIM-REPETIR // Realiza a transferência, se possível
SE Flag = 1 // Retorna a função Trajetória os setores comuns entre dois // ... pontos de fronteira
Retornar a Trajetória ( iSetorComuns[] ) SENÃO
// Retorna a função Trajetória a ausência de setores comuns Retornar a Trajetória ( 0 ) FIM-SE
247
Lógica de Módulo:
- MudancaSetorAlt Se P2 é ponto de fronteira Determinar número de setores (ns) entre P2 e P3 Empilhar setores tal que Pilha{Sa,Sb,Sc,Sd} // Determinar setor de entrada em P2 Para j = 0 até ns Se LSj > Alt2 setor_E = j sair_loop FimSe FimPara // Determinar setor de saída em P3 Para j = 0 até ns Se LSj > Alt2 setor_S = j sair_loop FimSe FimPara t = hora de chegada em p2 // em segundos
// Salva o evento de entrada Salvar:hora = t; setor_entrada = setor_E; setor_saida = setor atual; // Calcula a diferença entre altitudes dos pontos
V23 = | Alt3 - Alt2 |
// Verifica se existe mudança de nível com passagem de setor Se (setor_E != setor_S) Se Alt2 > Alt3 // anv descendo step = -1 Senão Se Alt2 < Alt3 // anv subindo step = 1 FimSeSenãoSe Se Alt 2 > Alt3 // ........... anv descendo Para (i = setor_E, i = i + step, até i = setor_S) faça Se i = setor_E // setor inicial V23i = Alt2 - LS(i-1) Senão Se i = setor_S // setor final
248
V23i = LSi - Alt3 Senão // demais setores V23i = LSi - LS(i-1) FimSeSenãoSe
H23i = ( V23i / V23 ) * H23 t = t + ( H23i / Vel) // horario da transferência
Se i != setor_S Salvar: hora = t; setor_entrada = i-1; setor_saida = i FimSe FimPara
Senão // ............ anv subindo Para (i = setor_E, i = i + step, até i = setor_S) faça Se i = setor_E // setor inicial V23i = LSi - Alt2 Senão Se i = setor_S // setor final V23i = Alt3 - LS(i-1) Senão // demais setores V23i = LSi - LS(i-1) FimSeSenãoSe H23i = ( V23i / V23 ) * H23 t = t + ( H23i / Vel) Se i != setor_S Salvar: hora = t; setor_entrada = i+1; setor_saida = i. FimSe FimPara FimSeSenão FimSe // (setor_E != setor_S) FimSe // P2 é ponto de fronteira
Aeronave no ponto P3, iniciar novo tratamento.......
249
GLOSSÁRIO
Gerenciamento de Fluxo de Tráfego Aéreo (ATFM):
Um dos segmentos da gerência de Tráfego Aéreo que visa a complementar o Serviço de
Controle de Tráfego Aéreo, estabelecido com a finalidade de assegurar um ótimo fluxo
de tráfego aéreo em áreas onde a demanda de movimentos aéreos, por vezes, excede a
capacidade do espaço aéreo ou ultrapassa os limites do Sistema de Controle de Tráfego
Aéreo instalado.
Banco de Dados ATFM:
Sistema de manutenção de dados (relativos às informações de vôo e cenário do
ambiente) que interligados oferecem diversos recursos ao ATFM, possibilitando- lhe a
análise de informações significativas para realização das suas tarefas, sendo necessárias
ao processo de tomada de decisão.
Capacidade aeroportuária:
Número máximo de aeronaves que pode operar em um determinado aeroporto no
período de 60 (sessenta) minutos, em função das capacidades das pistas de pouso, pistas
de táxi, pátios de estacionamento, terminal de passageiros e outros serviços congêneres
que afetam à operação das aeronaves.
Capacidade de infra-estrutura instalada:
Número máximo de aeronaves que pode operar em um determinado aeroporto no
período de 60 (sessenta) minutos e resulta da capacidade aeroportuária e do controle de
tráfego aéreo.
Capacidade do ATC:
Habilidade do sistema ATC, ou de qualquer um de seus subsistemas, de proporcionar
serviço às aeronaves em situação normal de atividade, sendo expressa como número de
aeronaves que entram em um setor de controle em um período de tempo especificado.
250
Central Integrada de Slots (CIS):
Órgão do SICEAB responsável pelo atendimento ao usuário quanto às solicitações e
alocações de Slot Time para aeroporto.
Slot Time:
Intervalo de tempo estabelecido durante o qual uma aeronave deverá realizar a operação
de pouso ou decolagem, em um determinado aeródromo, ou o sobrevôo de um ponto
preestabelecido.
Razão de Aceitação de Aeródromo:
Número máximo de operações de pouso e decolagens que a Torre de Controle (TWR)
pode atender num intervalo de 60 (sessenta) minutos, mantidas as exigênc ias de
segurança.
Setor de Controle:
Porção do espaço aéreo sob jurisdição de uma posição operacional de um órgão ATC.
Proa:
Direção segundo a qual é ou deve ser orientado o eixo longitudinal da aeronave.
Exploradores de Aeronaves:
Pessoa, organização ou empresa que se dedica ou se propõe dedicar à exploração de
aeronaves.