Automação, Integração de dados e Intrumentação de um Simulador

Transcrição

Universidade Federal de Minas Gerais
Curso de Graduação em Engenharia de Controle e Automação
Projeto de Fim de Curso
Automação, Integração de dados e
Intrumentação de um Simulador de Voo
Diego Rocha Rebelo
Orientador: Guilherme A. S. Pereira
Supervisor: Paulo Henriques Iscold Andrade de Oliveira
Junho de 2010
Monografia
Automação, Integração de dados e Instrumentação de um
Simulador de Voo
Monografia submetida à banca examinadora para avaliação curricular da disciplina PFC II, para obtenção do grau de Engenheiro
de Controle e Automação.
Belo Horizonte, Junho de 2010
i
Abstract
Flight Simulators have contributed to the aviation development since the
first prototypes were built. Nowadays, they are very sophisticated hardware
and software systems and their capabilities turned them into essential tools
for aviation development. Specially dealing with pilot trainning and control
systems, flight simulators may offer substantial contribution, supporting to
develop new techniques and models to assist pilots during flights.
This work describes the development of a flight Simulator considering its
automation, data integration and instrumentation. It is proposed a distributed architecture based on personal computers for simulation processing. In
this architecture, graphic modules, data acquisition systems and simulation
models developed in Matlab/Simulink communicate each other using a Fast
Ethernet network, composing the flight Simulator.
During the development of this work, systems have been built to integrate
Matlab/Simulink with other softwares and middlewares, such as Microsoft
Flight Simulator X, FSUPIC, WideView and WideFS, which enable realistic image rendering. These images are based on airplane dynamic provided
by Matlab/Simulink models. It is also described the development of a software responsible for distributed simulation control (control of the simulink
models), which enables controling the whole simulation through a single interface. In order to achieve a realistic simulation enviroment, some airplane
controls and instruments were integrated to simulation models such as stick,
pedals, power lever, EFIS (Electronic Flight Information System).
The final result of this work is a flight simulator that may be easily
operated, both for a pilot in trainning and for an aeronautical enginner, who
may modify simulation models using simple graphic interfaces.
ii
Resumo
Simuladores de Voo têm dado uma grande contribuição para a aviação
desde que os primeiros protótipos foram desenvolvidos. Atualmente, eles são
sistemas de hardware e software sofisticados que os tornaram uma ferramenta
essencial para o desenvolvimento da aviação. Especialmente em se tratando
de treinamento de pilotos e estudos de sistemas de controle, simuladores
de voo podem oferecer uma contribuição substancial no desenvolvimento de
novas técnicas e modelos para assistência à pilotagem durante voos.
Este trabalho descreve o desenvolvimento de um simulador de voo sob
os aspectos de sua automação, integração de dados e instrumentação. É
proposta uma arquitetura distribuída, baseada em computadores pessoais,
para processamento da simulação. Nesta arquitetura, módulos gráficos, sistemas de aquisição de dados e modelos de simulação desenvolvidos em Matlab/Simulink se comunicam através de uma rede Fast Ethernet, compondo
o simulador de voo.
Durante o desenvolvimento do trabalho, foram construídos sistemas que
integram o Matlab/Simulink com outros softwares e middlewares, como Microsoft Flight Simulator X, FSUIPC, WideView e WideFS, que possibilitam
a geração realística de imagens de simulação. Estas imagens são baseadas na
dinâmica da aeronave gerada pelos modelos do Simulink. Foi também desenvolvido um software para o controle distribuído da simulação (controle dos
modelos em Simulink) que possibilita controlar toda a simulação por meio de
uma única interface gráfica. Para atuação realística com o simulador foram
integrados aos modelos de simulação alguns controles e instrumentos do simulador como manche, pedais, manete de potência, EFIS (Electronic Flight
Information System).
O resultado final do trabalho é um simulador de voo que pode ser operado
com facilidade, tanto por um piloto em treinamento, como também por um
engenheiro aeronáutico, que pode fazer alterações no modelo de simulação
por meio de simples interfaces gráficas.
iii
Agradecimentos
Agradeço primeiramente a Deus por mostrar os melhores caminhos nos
momentos de indecisão. Agradeço a meus pais pelo apoio incondicional fornecido durante toda essa jornada. Agradeço à Natália que com muito amor e
paciência soube compreender os finais de semana dedicados ao curso. Agradeço também a toda equipe do CEA e do CORO, principalmente aos Professores Paulo Henriques Iscold e Guilherme A. S. Pereira pela oportunidade
de desenvolver o projeto.
Sumário
Abstract
i
Resumo
ii
Agradecimentos
iii
Tabela de Conteudo
v
Lista de Figuras
vii
Lista de Siglas
viii
1 Introdução
1.1 Apresentação . . . . . . . . . . . . . . . . . . . .
1.2 A Instituição . . . . . . . . . . . . . . . . . . . .
1.2.1 A UFMG . . . . . . . . . . . . . . . . . .
1.2.2 O Centro de Estudos Aeronáuticos - CEA
1.3 Motivação . . . . . . . . . . . . . . . . . . . . . .
1.4 Objetivos . . . . . . . . . . . . . . . . . . . . . .
1.5 Estrutura da Monografia . . . . . . . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
2 Revisão Bibliográfica
2.1 O Que São Simuladores de Voo ? . . . . . . . . . . . . . . .
2.2 Histórico . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
2.2.1 Primeiros Simuladores . . . . . . . . . . . . . . . . .
2.2.2 Adicionando Funcionalidades ao Simulador . . . . . .
2.2.3 Sistemas de Visualização . . . . . . . . . . . . . . . .
2.2.4 O Simulador de Voo Moderno . . . . . . . . . . . . .
2.2.4.1 Características de Hardware . . . . . . . . .
2.2.4.2 Características de Software e Modelagem Dinâmica . . . . . . . . . . . . . . . . . . . .
iv
.
.
.
.
.
.
.
1
1
1
2
2
3
5
7
.
.
.
.
.
.
.
8
8
9
9
11
12
14
15
. 16
SUMÁRIO
v
3 Desenvolvimento do Simulador de Voo
3.1 Visão Geral da Estrutura física e da Arquitetura Computacional do Simulador . . . . . . . . . . . . . . . . . . . . . . . . .
3.2 Definição e Configuração de plataformas e Ambientes de desenvolvimento . . . . . . . . . . . . . . . . . . . . . . . . . . .
3.2.1 Sistemas Operacionais . . . . . . . . . . . . . . . . . .
3.2.2 O ambiente de desenvolvimento MatLab/Simulink . . .
3.2.3 xPC Target . . . . . . . . . . . . . . . . . . . . . . . .
3.2.4 MatLab Aerospace Blockset . . . . . . . . . . . . . . .
3.2.5 Matlab AeroSim BlockSet . . . . . . . . . . . . . . . .
3.2.6 Instalação e Configuração de Softwares de Comunicação e integração . . . . . . . . . . . . . . . . . . . . . .
3.2.6.1 FSUPIC (Flight Simulator Universal Inter Process Communication) . . . . . . . . . . . . . .
3.2.6.2 WideFS . . . . . . . . . . . . . . . . . . . . .
3.2.6.3 WideView . . . . . . . . . . . . . . . . . . . .
3.3 Implementação . . . . . . . . . . . . . . . . . . . . . . . . . .
3.3.1 Módulos de Simulação . . . . . . . . . . . . . . . . . .
3.3.2 Controle Distribuído da Simulação . . . . . . . . . . .
3.3.3 Instrumentação Virtual . . . . . . . . . . . . . . . . . .
3.3.4 Resultados de Simulação . . . . . . . . . . . . . . . . .
18
4 Conclusão
44
Referências Bibliográficas
46
18
21
21
22
23
23
23
24
24
25
25
27
29
35
39
40
Lista de Figuras
1.1
1.2
1.3
1.4
2.1
2.2
2.3
2.4
2.5
3.1
3.2
3.3
3.4
3.5
3.6
3.7
3.8
3.9
3.10
3.11
3.12
Laboratório do CEA no Campus Pampulha da UFMG . . . .
Hangar do CEA no Aeroporto de Conselheiro Lafaiete [Fonte
Fig.1.1 e 1.2: www.demec.ufmg.br/cea] . . . . . . . . . . . . .
Projeto de um simulador de uma aeronave Cessna C-172 [Fonte:
www.wideview.it/my_cockpit.htm] . . . . . . . . . . . . . .
Exemplo de simulador implementado usando soluções comerciais [Fonte: www.wideview.it/pictures.htm] . . . . . . . .
Dispositivo para treinamento de piloto em terra - Catálogo
Antoinette, 1910. Retirada de [Page, 2009]. . . . . . . . . . . .
Piloto sendo treinado na escola de voo da empresa de E.Link.
Retirada de [Page, 2009]. . . . . . . . . . . . . . . . . . . . . .
Sistema de visualização baseado na filmagem de mapas girantes. Retirada de [Page, 2009]. . . . . . . . . . . . . . . . . . .
Sistema de visualização baseado em circuito interno de TV e
maquetes de superfícies. Retirada de [Page, 2009]. . . . . . . .
Sistema de visualização baseado em junção de televisores [Fonte:
www.wideview.it/my_cockpit.htm] . . . . . . . . . . . . . .
Arquitetura Física e Computacional do Simulador
Esquema elétrico de conexão dos potenciômetros .
Inter Process Communication usando FSUPIC . .
Configuração de parâmetros WideClient . . . . .
Modelo WV_Dummy selecionado . . . . . . . . .
Diagrama de Instalação do Simulador . . . . . . .
Criando Visões no MFSX . . . . . . . . . . . . .
Menu do FSUPIC e WideView no MFSX . . . . .
Visões salvas . . . . . . . . . . . . . . . . . . . . .
Módulo de Sistemas e Modelos Dinâmicos . . . .
Interior do Bloco Inputs Simulador . . . . . . . .
Interior do Bloco Flight Simulator . . . . . . . .
vi
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
3
4
6
6
10
11
13
13
14
19
22
25
26
27
28
28
29
29
31
32
32
LISTA DE FIGURAS
3.13
3.14
3.15
3.16
3.17
3.18
3.19
3.20
3.21
3.22
3.23
Interior do Bloco EFIS 1 . . . . . . . . . . . . . . . . . . .
Interior do Bloco EFIS 2 . . . . . . . . . . . . . . . . . . .
Mapeamento dos Intervalos . . . . . . . . . . . . . . . . . .
Módulo de Aquisição, Acionamento e Instrumentação . . . .
Interior do Bloco Profundor . . . . . . . . . . . . . . . . . .
Interface de Controle da Simulação . . . . . . . . . . . . . .
Interface da EFIS 1 . . . . . . . . . . . . . . . . . . . . . . .
Interface da EFIS 2 . . . . . . . . . . . . . . . . . . . . . . .
Resposta Dinâmica do Modelo Sora à Entradas do Sistema .
Entradas do Sistema Dinâmico Sora . . . . . . . . . . . . . .
As Três visões geradas pelo MFSX correspondentes aos momentos A, B e C . . . . . . . . . . . . . . . . . . . . . . . .
vii
.
.
.
.
.
.
.
.
.
.
33
34
35
36
36
40
41
42
42
43
. 43
Lista de Siglas e Abreviações
CEA
CORO
DEE
DELT
DEMEC
Centro de Estudos Aeronáuticos da UFMG,
viii
Laboratório de Sistemas de Computação e Robótica da UFMG, viii
Departamento de Engenharia Elétrica da
UFMG, viii
Departamento de Engenharia Eletrônica da
UFMG, viii
Departamento de Engenharia Mecânica da
UFMG, viii
FSUIPC
Flight Simulator Universal Inter Process Communication, viii
MFSX
Microsoft Flight Simulator X, viii
PDVA
Grupo de Pesquisa e Desenvolvimento de Veículos Autônomos da UFMG, viii
UFMG
UMG
Universidade Federal de Minas Gerais, viii
Universidade de Minas Gerais, viii
viii
Capítulo 1
Introdução
Este capítulo aborda aspectos introdutórios acerca do trabalho desenvolvido e discutido ao longo dos demais capítulos desta monografia. A Seção 1.1
destaca o tema principal abordado neste trabalho. A Seção 1.2 apresenta a
instituição onde foi desenvolvido o projeto, mostrando aspectos históricos e
organizacionais da instuição. Já a Seção 1.3 trata de aspectos motivacionais
que justificaram o desenvolvimento do projeto. Os objetivos iniciais traçados a serem alcançados durante a execução do projeto são descritos na Seção
1.4. Finalmente, a Seção 1.5 traz a descrição estrutural dos capítulos desta
monografia destacando o assunto e a importância de cada um.
1.1
Apresentação
O projeto final de curso descrito nesta monografia visou o desenvolvimento de um simulador de voo que tornasse possível o desenvolvimento de
novas técnicas e modelos que auxiliassem a pilotagem de aeronaves. Ao longo
to texto serão descritas as características técnicas deste simulador tais como
aspectos de hardware, software, instrumentação e modelos dinâmicos adotados. Será mostrado também como todos os subsistemas do simulador são
integrados de modo a proporcionar um ambiente de simulação único. Serão
discutidos os testes realizados no simulador de modo a validar todo o sistema
projetado. Na parte final da monografia serão discutidos as contribuições
trazidas pelo trabalho.
1.2
A Instituição
O projeto final de curso descrito nesta monografia foi realizado nas dependências da Universidade Federal de Minas Gerais (UFMG), especificamente
1
1.2
A UFMG
2
dentro do seu Centro de Estudos Aeronáuticos, vinculado ao Departamento
de Engenharia Mecânica da universidade.
1.2.1
A UFMG
A criação de uma universidade no estado de Minas Gerais já era parte do
projeto político dos inconfidentes. Este ideal, porém, só veio a concretizar-se
em 1927, com a fundação da Universidade de Minas Gerais (UMG), uma
instituição privada, subsidiada pelo estado, que reunia as quatro escolas de
nível superior então existentes em Belo Horizonte. A UMG permaneceu na
esfera estadual até 1949, quando foi federalizada. O nome atual - UFMG só foi adotado em 1965. Em 1968, a reforma universitária impôs profunda
alteração à estrutura orgânica da UFMG, promovendo o desdobramento de
antigas faculdades em novas faculdades e institutos.
A UFMG é divida em diversos departamentos, sendo que três desses tiveram participação no desenvolvimento deste projeto, sendo estes: Departamento de Engenharia Elétrica (DEE), Departamento de Engenharia Eletrônica (DELT) e o Departamento de Engenharia Mecânica (DEMEC).
1.2.2
O Centro de Estudos Aeronáuticos - CEA
A UFMG, desde 1975, oferece aos seus alunos do curso de graduação
em Engenharia Mecânica a opção pela ênfase em Engenharia Aeronáutica.
Seguindo esta opção, os alunos aprovados em todas as disciplinas oferidas
na ênfase obterão o título de Engenheiro Mecânico Aeronáutico, podendo
exercer todas as funções atribuídas pelo Conselho Federal de Engenharia à
este tipo de engenheiro.
Desde sua criação, este curso já formou mais de 250 engenheiros, dos
quais a maior parte se encontra trabalhando na Embraer e em empresas de
transporte aéreo no Brasil.
O CEA tem a função de apoiar e reunir todas as atividades de pesquisa
e ensino desenvolvidas pelos professores e alunos da ênfase em Engenharia
Aeronáutica da UFMG. Dentre as diversas atividades a de maior destaque é
a de desenvolvimento e operação de protótipos de aeronaves.
Atualmente já são 5 protótipos completamente desenvolvidos no CEA.
Esta prática de sucesso adotada pelo CEA acontece em diversas instituições
de ensino no mundo e apresenta diversas vantagens como capacidade de concretização de idéias, criatividade e a ligação entre o projeto e a construção.
No ano de 2009, a Engenharia Aeroespacial surgiu como curso de graduação na UFMG, tendo como referência a habilitação em Engenharia Aeronáutica, aproximando a universidade de uma indústria com grande potencial
1.3
Motivação
3
de expansão no país. Este setor envolve atividades de projeto, construção
e manutenção de aviões, helicópteros, foguetes, satélites, sondas espaciais,
enfim, de todo tipo de veículo aéreo ou espacial, tripulado ou não-tripulado.
O CEA é uma instituição comprometida com o desenvolvimento da engenharia aeronáutica nacional, contribuindo com atividades de ensino, pesquisa, desenvolvimento e inovação. O desenvolvimento de um simulador de
vôo foi mais uma iniciativa adota pelo CEA de modo a contribuir com o
desenvolvimento da aviação nacional.
Todo o projeto do simulador foi desenvolvido dentro do laboratório do
CEA localizado na UFMG através de recursos de pesquisa. O projeto teve
como colaboladores estudantes de graduação em Engenharia Mecânica e de
Controle e Automação, alunos de mestrado e de doutorado do DEMEC e
de professores do DEE, DELT e DEMEC. A Figura 1.1 mostra o interior
laboratório do CEA localizado no Campus Pampulha da UFMG.
Em 2008 foi inaugurado um hangar do CEA, no Aeroporto de Conselheiro
Lafaiete, a 96 km de Belo Horizonte, permitindo atualmente um acesso mais
facilitado a testes de voo. A Figura 1.2 mostra o hangar externamente.
Figura 1.1: Laboratório do CEA no Campus Pampulha da UFMG
1.3
Motivação
A aviação mundial tem enfrentado uma demanda cada vez mais freqüente
por um transporte aéreo mais seguro e rápido, que demande reduzidos tempos
de translado em terra e espera para operações em solo, garantindo um tempo
total de voo mínimo.
1.3
Motivação
4
Figura 1.2: Hangar do CEA no Aeroporto de Conselheiro Lafaiete [Fonte
Fig.1.1 e 1.2: www.demec.ufmg.br/cea]
Este aspecto se torna mais crítico quando se trata do transporte aéreo
pessoal ou empresarial. Porém, o que se tem verificado mundialmente, é que
a efetiva redução desse tempo de viagem não será obtida com o aumento da
velocidade das aeronaves, mas sim com o aumento e a otimização da malha
aeroviária, da construção de aeroportos secundários em cidades periféricas
(principalmente em centros industriais) ou mesmo em aeroportos particulares
localizados dentro de grandes empresas.
Evidentemente, para que este objetivo possa ser alcançado, será necessário adaptar as aeronaves para que essas possam atender à nova demanda:
voos que tipicamente não deverão mais ser feitos em massa, mas sim para
atender à necessidade de um pequeno grupo de pessoas. Sendo assim, novos desafios deverão ser vencidos para que se possa, de fato, implementar
esta "aviação pessoal". Podemos citar, por exemplo, a modernização dos
sistemas de comunicação e auxílio à navegação provavelmente através de sua
automatização e a introdução de sistemas assistidos a pilotagem, por meio de
comandos fly-by-wire, que venha permitir a redução do tempo de treinamento
para operação da aeronave.
Acredita-se que as experiências anteriores do CEA juntamente com as do
PDVA (Grupo de Pesquisa e Desenvolvimento de Veículos Autônomos) da
UFMG possam contribuir para o desenvolvimento de tecnologias no Brasil
que possam ser empregadas nesta nova geração de aeronaves.
Desta forma, o que se pretende é desenvolver sistemas de auxílio à pilotagem que permitam que a aeronave seja controlada por trajetória, ao invés
de ser controlada por atitude, como é feito hoje em dia. Atualmente, para
se controlar uma aeronave é preciso aprender a controlar determinados parâmetros de voo para que se tenha controle sobre a trajetória da aeronave.
1.4
Objetivos
5
Estes parâmetros (velocidade de voo, velocidade vertical, inclinação das asas
e aceleração lateral), determinam a trajetória indiretamente e possuem comandos de controle acoplados, o que torna a prática da pilotagem uma tarefa
não trivial para o ser humano, exigindo grande treinamento e contínuo aperfeiçoamento.
Com a adoção de sistemas de controle assistidos por computador, em
especial os sistemas fly-by-wire, é possível estabelecer previamente leis de
controle que podem permitir que o piloto controle diretamente a trajetória
da aeronave, ao invés de sua atitude.
Considerando a grande relevância do tema e sua importância e impacto
na aviação nacional, o CEA acredita que o primeiro passo a ser tomado é a
construção de um simulador de voo que sirva de plataforma de testes para o
desenvolvimento e a implementação de novas técnicas e modelos que auxiliem
à pilotagem e às técnicas de voo baseadas em trajetória.
A evolução de softwares comerciais que possibilitam alta fidelidade gráfica
em simulações, como o Microsoft Flight Simulator X (MFSX), a evolução de
ambientes que proporcionam rápido desenvolvimento de modelos dinâmicos
e integração como outros sistemas, como o MatLab/Simulink, bem como
a grande disponibilidade de sistemas computacionais de grande capacidade
de processamento e de memória, atualmente disponíveis para computadores
pessoais, vêm incentivando a pesquisa e o desenvolvimento de simuladores
de voo em diversas instituições, soluções que até alguns anos atrás eram
essencialmente implementadas em empresas especializadas, devido a questões
como custo e disponibilidade tecnológica.
Temos como exemplo dessa nova tendência em projetos de simuladores,
o projeto de um simulador de uma aeronave Cessna C-172, mostrado na
Figura 1.3, desenvolvido utilizando o MFSX 2004 e diversas outras soluções
comerciais. A Figura 1.4 mostra outro exemplo de simulador implementado
sob essa perspectiva.
1.4
Objetivos
Tendo em vista o exposto acima, este projeto tem por objetivos:
• Desenvolver um ambiente computacional distribuído a partir do software MatLab/Simulink, utilizando algumas de suas ferramentas como
o AeroSim Block Set, xPC Target e Data Acquisition Tool Box;
• O desenvolvimento de um módulo de software que seja a interface do
usuário com o sistema e integre todos os demais subsistemas;
1.4
Objetivos
6
Figura 1.3: Projeto de um simulador de uma aeronave Cessna C-172 [Fonte:
www.wideview.it/my_cockpit.htm]
Figura 1.4: Exemplo de simulador implementado usando soluções comerciais
[Fonte: www.wideview.it/pictures.htm]
• A Realização de parte da instrumentação necessária para o simulador
(conexão de instrumentos, condicionamento de sinais e aquisição de
dados);
• A Definição de um ou mais padrões de comunicação entre os instrumentos, softwares e subsistemas do simulador;
• A Realização da integração dos softwares (MatLab, Microsoft Flight
1.5
Estrutura da Monografia
7
Simulator X, FSUIPC, WideView e WideFS) que serão usados no simulador de modo a torná-lo um ambiente integrado de simulação;
• A Realização de testes no sistema integrado, monitorando variáveis
dinâmicas do modelo do simulador.
1.5
Estrutura da Monografia
O trabalho está dividido em 4 capítulos. Este Capítulo apresentou uma
introdução ao projeto a ser descrito nesta monografia, a instituição onde o
trabalho foi realizado, bem como os objetivos que nortearam a execução do
mesmo.
O Capítulo 2 traz uma revisão bibliográfica a respeito do tema desenvolvido no projeto. Traz alguns casos de uso realizados ao redor do mundo,
como uma tentativa de embasar e justificar o desenvolvimento deste tipo de
simulador.
O Capítulo 3 descreve as principais características do simulador como
estrutura física, subsistemas, equipamentos utilizados, instrumentos, arquitetura de comunicação entre os subsistemas adotada e uma breve descrição
dos softwares utilizados, abrangendo todos os conceitos necessários para um
melhor entendimento do projeto e mostrando as etapas de desenvolvimento
do mesmo. Traz também resultados obtidos em uma simulação específica.
Finalmente no Capítulo 4 tem-se a conclusão da monografia e algumas
sugestões e dificuldades encontradas na realização do projeto. É sugerido
também possíveis trabalhos futuros a serem desenvolvidos no simulador.
Capítulo 2
Revisão Bibliográfica
Este Capítulo descreve as origens do simulador de voo e sua evolução até
os dias de hoje. Trata das tecnologias mais atuais de hardware e software
usadas nos simuladores baseados em PCs e traz algumas referências de trabalhos de desenvolvimento de simuladores usando essa tecnologia. Além disso,
discute algumas aplicações atuais dos simuladores e as atuais tendências tecnológicas.
2.1
O Que São Simuladores de Voo ?
De acordo com [Mac, 2009] um simulador de voo é uma máquina usada
para treinamento de pilotos que fornece um ambiente e uma experiência de
como voar uma aeronave.
De maneira mais técnica [Bab, 2009] faz a seguinte definição para simulador de voo:
"Um simulador de voo é um sistema de aparelhos ou um software que
pretende recriar o voo de uma aeronave da maneira mais realística possível."
De toda maneira, um simulador de voo é um dispositivo de treinamento
em terra que produz exatamente as condições experimentadas na cabine de
voo de uma aeronave.[Col, 2003].
Podemos perceber por estas definiçoes, que um simulador de voo pode ser
um software, um sistema de aparelhos ou um dispositivo de treinamento, com
o intuito de auxiliar um piloto na experiência de voo. Atualmente, devido
principalmente aos avanços nas tecnologias de hardware e de software, os
simuladores têm adquirido cada vez mais funcionalidades.
Essas por sua vez têm sido implementadas em uma variedade de sistemas diferentes e integradas de modo a fornecer um ambiente de simulação
único. Sendo assim, atualmente, talvez, uma das melhores maneiras de se
8
2.2
Histórico
9
descrever um simulador é analisando-o sob uma perspectiva de sistemas.
Quando tratamos um simulador como sendo um ambiente de integração de
diferentes sistemas, conseguimos entender melhor seus propósitos e funcionalidades. Simuladores são tratados sob essa perspectiva em [Lei et al., 2007],
[Zheng et al., 2009c], [Shutao et al., 2008] e [Jin et al., 2009].
Existem muitas justificativas que motivam o desenvolvimento de simuladores de voo. Nos primórdios da aviação, a grande preocupação era ensinar
os comandos básicos das ”novas máquinas” aos interessados. Estes comandos eram passados através de ”simuladores mecânicos” em terra, de modo a
capacitar os pilotos e diminuir os acidentes aéreos.
Ao passar dos anos, as aeronaves foram se tornando cada vez mais complexas, integrando novos sistemas de voo. Surgiu daí a necessidade de se
aprimorar as técnicas e as tecnologias de simulação de modo a construir
simuladores cada vez mais realísticos.
Atualmente, desenvolver ambientes de simulação e treinar pilotos nesses
sistemas se tornou uma obrigatoriedade em determinados setores da aviação
pessoal.
Um outro campo que tem usado bastante os simuladores de voo é a engenharia, principalmente aeronáutica e aeroespacial. Essas áreas vem usando
simuladores de voo para servirem de plataforma de desenvolvimento e de
testes de novas soluções, sistemas, técnicas e equipamentos de voo. O objetivo macro deste trabalho é desenvolver um simulador que possa servir de
plataforma para alcançar esses objetivos.
Além de possibilitar um ambiente de treinamento, os simuladores também demostram um papel importante na indústria de entreterimento, cujo
principal objetivo é entreter o tripulante transmitindo um certo grau de realismo através do simulador. A pesquisa e desenvolvimento de softwares de
simulação na áerea de entreterimento tem contribuído muito para a evolução
dos simuladores de voo.
2.2
2.2.1
Histórico
Primeiros Simuladores
A história da simulação de voo é descrita em detalhes em [Page, 2009].
Sendo assim, o desenvolvimento deste tópico será fortemente embasado neste
trabalho. Os pilotos das primeiras aeronaves motorizadas aprenderam a voar
realizando exercícios sequenciais em aeronaves reais. Primeiramente, aprendiam os comandos básicos em terra com a aeronave em movimento. À medida
que iam evoluindo, passavam a executar pequenos voos entre dois pontos até
2.2
Primeiros Simuladores
10
Figura 2.1: Dispositivo para treinamento de piloto em terra - Catálogo Antoinette, 1910. Retirada de [Page, 2009].
conseguirem voar distâncias maiores. Acidentes eram frequentes nesta estratégia de treinamento.
Paralelamente, os construtores começaram a criar réplicas des aeronaves
em terra com o objetivo de inicialmente treinar os pilotos sem a necessidade
de realizar e de se arriscar em voos reais.
Por volta de 1910, começaram a surgir os primeiros dispositivos de voo
sintéticos. A Figura 2.1 retirada de [Page, 2009] mostra uma fotografia publicada no Catálogo Antoinette em 1910.
A necessidade de treinamento de um grande número de aviadores na
Primeira Guerra Mundial encorajou o desenvolvimento da nova disciplina
de psicologia de voo. Testes também foram introduzidos para a seleção de
pilotos. Como a Figura 2.1 mostra, nos primeiros dispositivos o movimento
de rotação era realizado manualmente por operadores humanos.
O segundo passo no desenvolvimento destes dispositivos foi a substituição do operador humano por atuadores elétricos e mecânicos conectados aos
controles do dispositivo do simulador. O objetivo destes atuadores era rotacionar a fuselagem do dispositivo numa atitude correspondente a das aeronaves
reais em resposta às entradas de controle. Uma série de dispositivos foram
construídos baseando-se nesse princípio. O mais conhecido desses dispositivos foi o desenvolvido por Edwin Link, o "Link trainner", criando um padrão
para futuros desenvolvimentos.
2.2
Adicionando Funcionalidades ao Simulador
11
Figura 2.2: Piloto sendo treinado na escola de voo da empresa de E.Link.
Retirada de [Page, 2009].
A década de 1920 marcou uma nova tendência de treinamento em simuladores: o treinamento baseado em instrumentos. Esta nova técnica foi iniciada
pela empresa de Edwin Link na escola de voo da empresa no início da década
de 30. A importância desse novo tipo de treinamento foi reconhecido pela
US Army Air Corps. A Figura 2.2 mostra um piloto sendo treinado por esta
técnica.
Na década de 30 Link trainners foram vendidos para vários países no
mundo. Em 1937 a empresa American Airlines se tornou a primeira do
mundo a comprar um Link trainner para treinamento de seus pilotos.
2.2.2
Adicionando Funcionalidades ao Simulador
A Segunda Guerra Mundial trouxe o desenvolvimento de novos dispositivos a serem integrados aos simuladores. Dentre eles podemos citar: adoção
de simuladores com sistemas de áudio, introdução de sistemas de radares na
simulação e introdução de exibição visual. Nesta época, a exibição visual era
2.2
Sistemas de Visualização
12
baseada em filmes que mostravam terrenos durante a simulação.
Os avanços na eletrônica proporcionados pelos anos de guerra e o desenvolvimento do computador analógico tornavam agora possível a resolução de
equações de movimento das aeronaves, permitindo simulações de resposta a
forças aerodinâmicas.
A primeira discussão conhecida de métodos de simulação basedas em
computador é feita em Roeder, em sua especificação de patente alemã em
1929 [Roeder, 1929].
O desenvolvimento de novas e complexas aeronaves exigia que o desenvolvimento dos simuladores acompanhassem em mesma proporção. Isso exigiu
o desenvolvimento de hardware analógico mais complexo, fornecendo maior
poder de processamento e precisão aos simuladores.
Mesmo com o melhoramento do hardware e dos projetos, a confiabilidade
dos dispendiosos simuladores analógicos já deixava muito a desejar, sem contar com as horas de manutenção gastas por dia.
Nesta época, já existiam os computadores pessoais digitais de propósito
geral, mas estes ainda não eram capazes de satisfazer uma grande demanda
por cálculos de ponto flutuante.
A demanda por uma tecnologia que suportasse o processamento de muitas
operações envolvendo cálculo numérico veio a ser suporatada por uma nova
geração de computadores que suportavam processamento digital e paralelo.
Era a era da simulação digital.
2.2.3
Sistemas de visualização de voo foram propostos desde os primeiros desenvolvimentos com simuladores. Como exemplo, podemos citar a técnica de
captura e projeção de imagens de mapas que giravam continuamente durante
a simulação. Um exemplo deste tipo de sistema pode ser visto na Figura 2.3.
Como é mostrado na figura, uma câmera filmava imagens de mapas que giravam em uma esteira. O controle de velocidade dessa esteira era realizado
por controladores que geravam ações de controle para servomotores atuarem
no sistema. As imagens capturadas eram transmitidas através de uma rede
e projetadas na tela do simulador.
O avanço na tecnologia de circuitos internos de TV na década de 50
proporcionou filmar cenários maiores, fornecendo a sensação de movimento
ao longo de uma superfície. Várias câmeras em movimento filmavam grandes
maquetes de superfície, fornecendo as imagens para as simulações. A Figura
2.4 retrata essa técnica.
A primeira geração de imagem por computador foi realizada pela General
Electric Company para o programa espacial americano na década de 70.
2.2
13
Figura 2.3: Sistema de visualização baseado na filmagem de mapas girantes.
Retirada de [Page, 2009].
Figura 2.4: Sistema de visualização baseado em circuito interno de TV e
maquetes de superfícies. Retirada de [Page, 2009].
Como a qualidade dos monitores não proporcionava exibir grandes imagens,
eles começaram a usar vários monitores dispostos em 180o .
Atualmente são usadas técnicas de projeção em superfícies contínuas co-
2.2
O Simulador de Võo Moderno
14
Figura 2.5: Sistema de visualização baseado em junção de televisores [Fonte:
www.wideview.it/my_cockpit.htm]
brindo 180o ou até áreas maiores. É também usado atualmente a junção de
vários televisores de grande resolução para gerar a tela de visualização. A
Figura 2.5 mostra um exmplo de simulador moderno com sistema de visualização baseado na junção de televisores.
2.2.4
O Simulador de Voo Moderno
Como discutido na Seção 2.2.3 os simuladores evoluíram muito desde as
primeiras concepções mecânicas propostas no início do século XX. Atualmente existem diversas tecnologias disponíveis para se implementar simuladores de voo.
A variedade dessas tecnologias é aparente tanto em termos de hardware
quanto de software. A Seção 2.2.3 menciona que em determinado momento
da história dos simuladores pensou-se em utilizar computadores pessoais de
modo a permitir a implementação de simulações. Naquela época não foi possível devido a limitações de hardware (e também de software). Atualmente
isso já não é mais uma barreira.
Hoje é possível implementar um sistema de simulação usando basicamente
computadores pessoais de alto desempenho, softwares comerciais e algum
hardware auxiliar para entrada e saída de informações.
Essa é a tecnologia de implementação de simuladores que iremos discutir
2.2
Características de Hardware
15
no decorrer deste trabalho e que foi usada no desenvolvimento do simulador
proposto. Os subtópicos a seguir irão exemplificar o que há de mais novo no
desenvolvimento de simuladores de voo baseados em tecnologia de computadores pessoais diante da perspectiva de Hardware, Software e Modelagem
Dinâmica de Simulação.
2.2.4.1
Características de Hardware
O desenvolvimento de softwares de simulação que possibilitam visualização gráfica de alta definição e realismo tem demandado uma capacidade de
processamento e uma capacidade de memória cada vez maior dos computadores.
Isso tem levado os desenvolvedores de sistemas de simulação a adotarem
estratégias de computação distribuída para alcançarem um maior desempenho do sistema, alcaçarem requisitos de tempo real ou conseguirem um menor
nível de acoplamento e uma maior coesão de todo o sistema. Uma das técnicas mais usadas é a de computação baseada em Clusters. Uma discução
detalhada sobre as diversas formas de se alcançar a computação distribuída
pode ser encontrado em [Tanenbaum, 2006].
Em [Zheng et al., 2009c] é proposto o desenvolvimento de uma interface
de simulação de voo usando-se a técnica de computação distribuída. O sistema desenvolvido usa unidades de interface PC-104 para proporcionar a
troca de informações com os instrumentos do simulador e a unidade central
de simulação.
Todas as unidades se integram através de uma rede CAN Bus. Inserida na
rede CAN Bus se encontra um controlador CAN para realizar a arbitragem
de comunicação. Neste trabalho é proposto a divisão das diversas funcionalidades de simulador em módulos que executam em diferentes PCs. Temos,
por exemplo, unicamente uma máquina para executar o modelo, outra para
executar o software gráfico de visualização e outra para a interface com uma
Plataforma Stewart (para proporcionar movimento de rotação do mock-up
do simulador). Estratégias semelhantes a essa podem ser encontradas em
[Zheng et al., 2009a] e [Shutao et al., 2008].
O uso da Ethernet como tecnologia de camada física e de enlace de dados
em sistemas de simulação de voo pode ser encontrada em [Zheng et al., 2009b].
Uma extensa discussão de como integrar instrumentos de voo através da tecnologia Ethernet é feita em [Allerton, 2009].
Além disso, no campo da visualização de simulações, é frequente o uso
cada vez maior de conjunto de televisores de alta definição dispostos lado a
lado de modo a formar um único meio de visualização.
2.2
Características de Software e Modelagem Dinâmica
2.2.4.2
16
Os simuladores de voo modernos utilizam diversos módulos de softwares para proporcionar, por exemplo, modelagem dos modelos dinâmicos das
aeronaves, geração de imagem para visualização gráfica, aquisição de dados, comunicação entre os diversos subsitemas do simulador e simulação em
tempo-real.
Como discutido na Subseção 2.2.4.1, em termos de hardware é sempre
interessante termos um nível de desacoplamento. Isto permite uma maior
flexibilidade para mudanças no sistema e uma manutenção mais facilitada do
simulador. No campo de software isso também é uma realidade. Nos diversos
trabalhos presentes na literatura, existe uma preocupação cada vez maior
em desacoplar os diversos módulos de software presentes nos sistemas de
simulação. É possível ver isso em [Zheng et al., 2009c], [Zheng et al., 2009a],
[Shutao et al., 2008] e em [Lei et al., 2007].
Dentre as possíveis maneiras de se criar camadas de abstração de modo
a desacoplar os módulos de software está a separação entre o módulo de
visualização gráfica (geração de imagens) dos diversos subsistemas.
Na literatura são descritos diversos exemplos de módulos de geração de
imagem que foram construídos de maneira dedicada, de modo a atender
determinadas aplicações. Neste trabalho usaremos um software de geração
de imagens e visualização gráfica comercial, de modo a alcançarmos alta
qualidade de imagem e um menor tempo de implementação do projeto.
Existem diversos softwares desse tipo no mercado. Podemos citar, por
exemplo, o Flight Gear (um software livre) e o Microsoft Flight Simulator (comercial). Neste trabalho usaremos o Microsoft Flight Simulator X
(MFSX). O MFS é um software de simulação de voo que está no mercado há
29 anos e tem contribuído para o desenvolvimento de diversos simuladores.
Na versão X desse simulador é possível usar os protocolos de comunicação
TCP/IP para enviar dados de dinâmica de voo para o simulador de modo que
o MFSX se torne um ambiente puramente de visualização gráfica enquanto
todas as variáveis dinâmicas são geradas por outro módulo de software. Usaremos essa estratégia neste trabalho. Maiores detalhes serão descritos nos
próximos capítulos.
A camada de aquisição de dados, comunicação e simulação em temporeal podem ser desenvolvidas usando linguagens de programação procedurais
clássicas como C ou Pascal, ou até mesmo as orientadas a objetos (mais
adequadas para esste tipo de aplicação) como C++,C Sharp ou Java.
Do ponto de vista de desenvolvimento, desenvolver estas camadas usando
linguagens deste tipo implicarão em uma maior complexidade dos sistemas,
maior tempo de desenvolvimento, testes e integração. Por outro lado, as
2.2
17
aplicações apresentarão uma maior flexibilidade do ponto de vista da interação com o hardware do simulador, proporcionando um nível de interação
que linguagens de mais alto nível não são capazes de fornecer.
Atualmente, percebe-se em alguns trabalhos o uso de linguagens de blocos
no desenvolvimento deste tipo de sistemas, usando principalmente a plataforma MatLab/Simulink como ferramenta para a criação dessas camadas e
também para a modelagem dinâmica do simulador. Essa ferramenta proporciona um rápido desenvolvimento, flexibilidade e fácil integração com
diversos sistemas. Por outro lado, perde-se na questão da flexibilidade no
nível de interação software/hardware, devido a utilização de pacotes de soluções prontas. Neste trabalho usaremos o ambiente MatLab/Simulink para
o desenvolvimento do simulador. Maiores detalhes serão descritos nos próximos capítulos. Alguns projetos que utilizam a plataforma MatLab/Simulink
para o desenvolvimento de simuladores de voo são descritos em detalhes em
[Zheng et al., 2009a], [Shutao et al., 2008] e [Zheng et al., 2009b].
Analisando tudo o que foi discutido neste capítulo percebemos que o
simulador de voo terá um futuro promissor. Seja contribuindo para o entreterimento, para o treinamento de pilotos ou para a engenharia essa será uma
aplicação muito importante. Os programas espaciais estão cada vez mais
voltados para a busca de recursos em outros planetas. O desenvolvimento
de novos simuladores de voo serão essenciais se novas aeronaves tripuladas
forem necessárias para explorações futuras.
Capítulo 3
Desenvolvimento do Simulador de
Voo
Neste Capítulo será descrito todo o desenvolvimento do Simulador de Voo.
Serão dados detalhes de implementação de software, hardware e instrumentação, descrevendo a automação e a integração de dados no simulador. Não
será dado detalhes de implementação mecânica do simulador, nem detalhes
do modelo dinâmico da aeronave usado no simulador para o desenvolvimento
deste trabalho, uma vez que fogem do escopo desta monografia.
3.1
Visão Geral da Estrutura física e da Arquitetura Computacional do Simulador
Nesta seção será feita uma descrição da estrutura física e da arquitetura
computacional do simulador, descrevendo cada uma de suas partes. A figura
3.1 ilustra a Arquitetura física e Computacional do Simulador.
O simulador desenvolvido neste trabalho é composto por um cockpit de
uma aeronave real, modelo ACS-100 Sora. Esse cockpit foi doado ao CEA
pela empresa ACS-Advanced Composites Solutions, localizada em São José
dos Campos. O ACS-100 Sora, originalmente chamado Triathlon, foi um
projeto desenvolvido pelo projetista Claudio Barros na Universidade Federal de Minas Gerais. O cockpit possui dois lugares. Esse cockpit, durante a
execução deste projeto, foi adaptado para fazer parte do simulador, de modo
que no painel do cockpit foram instaladas duas telas de LCD de 10 polegadas. Essas telas são responsáveis por exibir instrumentos de voo virtuais do
simulador.
Dentro do cockpit foi instalado também um manche de uma aronave real
ACS-100 Sora, de modo que o piloto do simulador possa enviar comandos
18
3.1
Estrutura física do Simulador
19
Figura 3.1: Arquitetura Física e Computacional do Simulador
e interagir durante a simulação. Futuramente, será instalado um sistema
de force-feedback que atuará sobre o mache simulando esforço de comando.
Além disso, dentro do cockpit, foram instalados dois pedais (comandos de
leme da aeronave) e uma manete para enviar sinal de setpoint de potência
do motor da aeronave que estiver sendo simulada.
Como foi discutido no Capítulo 2 (Revisão Bibliográfica), usaremos a
técnica de computação distribuída conhecida como Cluster, com o uso de
computadores pessoais, para realizar a computação da simulação. Sendo
assim, como mostrado na Figura 3.1, o simulador também é composto por
três computadores de uso pessoal, instalados durante a execução do projeto,
sendo responsáveis por hospedar instâncias de modelos do software Simulink que processam a simulação. Esses modelos estão designados na Figura
3.1 como Módulo de Aquisição, Acionamento e Instrumentação, Módulo de
Sistemas e Modelos Dinâmicos e Módulo de Visualização Gráfica.
De modo a proporcionar comunicação em rede dessas máquinas, foi ins-
3.1
Estrutura física do Simulador
20
talada uma Rede Ethernet 100Base-T (Fast Ethernet) conectando-as através
de um roteador, proporcionando uso de protocolos das camadas de rede e de
transporte da pilha de protocolos TCP/IP.
Próximo ao cockpit encontram-se três televisores de 50 polegadas destinados a exibir graficamente a simulação. Para proporcionar a exibição de imagens em três televisores de forma independente, isto é, através de três saídas
Video Graphics Array (VGA), partindo de uma única saída de vídeo VGA
vinda de um PC, foi necessário instalar um componente de hardware adicional. Esse componente é uma placa gráfica, o produto MatroxTripleHead2GO
do fabricante Matrox (www.matrox.com). Através deste dispositivo é possível
exibir três pontos de vista diferentes do cockpit do simulador durante uma
simulação: vista frontal, janela esquerda e janela direita.
Na máquina onde se localiza o Módulo de visualização gráfica foi instalado o software Microsoft Flight Simulator X (MFSX), responsável por
gerar as imagens gráficas da simulação exibidas nos televisores. Toda a dinâmica de voo é gerada por meio do software Matlab/Simulink e enviada
ao MFSX através da Rede Ethernet. Na máquina hospedeira do sistema
de visualização gráfica também foram instalados dois softwares, na verdade
dois Middlewares, um responsável por possibilitar a comunicação entre os
softwares Matlab/Simulink e o MFSX e o outro responsável por extender as
funcionalidades do MFSX para possibilitar sincronização de diferentes pontos de vista do cockpit gerados pelo MFSX. Esses softwares são o Flight
Simulator Universal Interprocess Communication (FSUPIC) e o WideView,
respectivamente.
Na máquina que hospeda o Módulo de Sistema e Modelos Dinâmicos foi
instalado o middleware WideFS. Os middlewares FSUIPC e WideFS formam uma aplicação do tipo Cliente/Servidor, sendo o WideFS o Cliente e o
FSUIPC o Servidor. O WideFS é dividido em dois módulos, WideFS Client
e WideFS Server. O WideFS Server se localiza na máquina do Módulo de
Visualização Gráfica e o WideFS Client na Máquina do Módulo de Sistemas e Modelos Dinâmicos. Mais detalhes da composição do WideFS serão
apresentados nas próximas seções. Desta forma, o WideFS comunica-se com
o software Matlab/Simulink e só depois envia as informações obtidas desse
software a seu Servidor FSUIPC. Nesta mesma máquina foi instalado um
Eletrocnic Flight Information System (EFIS), responsável por exibir, através de uma interface, gráfica dados de variáveis de voo. Esse EFIS é um
software desenvolvido na linguagem C++ (não desenvolvido dentro deste
projeto) e foi adaptado neste projeto para receber dados vindo do software
MatLab/Simulink. Esse software foi desenvolvido pelo aluno Armando Alves
e seu trabalho é descrito em [Iscold et al., 2007].
Na máquina que hospeda o módulo de Aquisição, Acionamento e Ins-
3.2 Definição e Configuração de plataformas e Ambientes de desenvolvimento21
trumentação foi instalado um sistema de aquisição de dados do fabricante
Advantech (www.advantech.com.br), o produto PCI-1710. Esse sistema usa
o barramento PCI do PC. Esse sistema de aquisição ilustrado na Figura 3.1
é o responsável por coletar os dados vindo de potenciômetros lineares, que
estão instalados na parte traseira do cockpit. Estes sensores se acoplam ao
sistema mecânico de comando do simulador (manche, pedais e manete) através de um sistema de cabos de aço e roldanas. Como os potenciômetros
resistivos são elementos passivos, foi necessário construir um circuito eletrônico para alimentar e condicionar os sinais dos sensores antes de enviá-los ao
sistema de aquisição. Esse circuito foi desenvolvido pelo aluno de Doutorado
Igor Machado Malaquias, do DEMEC. Esse circuito foi montado em uma
placa e instalado na traseira do cockpit do simulador. O esquema elétrico
mostrando a conexão dos potenciômetros com a placa de condicionamento
dos sinais e com a placa de aquisição de dados é mostrado na Figura 3.2.
Através do sistema de aquisição também é possivel enviar dados do software
MatLab/Simulink para o meio externo, possibilitando atuar no simulador
através de um sistema de force-feedback, possibilitando fechar uma malha de
controle completa.
Nesta mesma máquina foi também instalada um outro EFIS, que é exibida
na segunda tela de LCD de 10 polegadas, mostrando variáveis como nível de
combustível, potência do motor e outras variáveis periféricas. A Figura 3.3.4
mostra uma imagem de como se encontra o simulador atualmente.
É Importante salientar que durante este projeto, o autor teve uma participação mínima durante a elaboração dos modelos dinâmicos das aeronaves
a serem utilizados, dando maior foco à integração dos diversos sistemas do
simulador.
3.2
Definição e Configuração de plataformas e
Ambientes de desenvolvimento
Nesta seção serão descritas as plataformas de software, os ambientes de
desenvolvimento e as ferramentas de software usadas durante o desenvolvimento do simulador.
3.2.1
Sistemas Operacionais
Durante o desenvolvimento do simulador decidiu-se usar os sistemas operacionais Windows XP 32 bits e Windows Vista 64 bits pela razão de facilidade de uso que proporcionaria para diferentes tipos de usuários que usassem
o simulador no futuro. Sendo assim, nas máquinas que hospedam os Módulos
3.2
O ambiente de desenvolvimento MatLab/Simulink
22
Figura 3.2: Esquema elétrico de conexão dos potenciômetros
de Sistema e Modelos Dinâmicos e de Aquisição, Acionamento e Instrumentação decidiu-se usar Windows XP 32 bits. A razão de se usar 32 bits e
não 64 bits está relacionado à questões de possíveis incompatibilidades que
pudessem aparecer usando Matlab/Simulink. Já a razão de se usar Windows
Vista 64 no sistema de visualização em vez de Windows XP 64 foi devido
ao fato da literatura descrever um problema de falta de memória (Out Of
Memory) que aparece ao se usar o MFSX no Windows XP 64, sendo que
esse problema ainda não foi percebido no Windows Vista 64.
3.2.2
O ambiente de desenvolvimento MatLab/Simulink
Como discutido, decidiu-se usar o ambiente de desenvolvimento Matlab/Simulink como sendo o principal ambiente de desenvolvimento desse
projeto. Ele é a ferramenta de modelagem de todos os módulos do simulador
e é integrado aos demais softwares, usando ou não middlewares.
O MatLab é um ambiente de desenvolvimento que, para extender suas
funcionalidades básicas, necessita de bibliotecas conhecidas como Toolboxes
(caixas de ferramenta), sendo específicas para determinado tipo de desenvolvimento a ser realizado. Neste projeto em especial, foram usados os Toolboxes
xPC Target, MatLab Aerospace Blockset e Matlab AeroSim BlockSet, além
dos blocos básicos de construção de modelos disponíveis na biblioteca do
Simulink. Nas próximas Subsessões serão explorados brevemente as caracte-
3.2
xPC Target
23
rísticas de cada uma dessas ferramentas.
O Simulink é um ambiente para simulação multidomínio e projeto baseado em modelos para sistemas embutidos e dinâmicos. Fornece um ambiente
gráfico interativo e um conjunto de bibliotecas configuráveis (Toolboxes) que
permitem projetar, simular, implementar e testar uma variedade de sistemas variantes no tempo, incluindo comunicações, controle, processamento
de sinais, processamento de vídeo e processamento de imagem.
3.2.3
xPC Target
O Toolbox xPC Target fornece um ambiente de desenvolvimento que permite conectar modelos feitos em Simulink a sistemas físicos e executá-los em
tempo real usando para isso um hardware de baixo custo. xPC target ainda
inclui ferramentas para prototipagem rápida e construção de malhas de controle completas usando sistemas físicos e hardware externo. Neste projeto
em especial foram usados os blocos Pack e UDP Send Binary desse Toolbox.
3.2.4
MatLab Aerospace Blockset
O Toolbox Aerospace fornece padrões de referência, modelos de ambiente
e importação de coeficientes aerodinâmicos para permitir análises aeroespaciais para desenvolver e avaliar projetos. Opções para visualização de veículos
dinâmicos inclui um objeto de animação de seis graus de liberdade e interfaces para os softwares FlightGear Simulator e Simulink 3D Animation. Essas
opções permitem visualizar dados de voo em um ambiente tridimensional e
reconstruir anomalias de comportamento em resultados de testes de voos. O
Aerospace é usado neste projeto basicamente durante as etapas de encapsulamento de pacote de dados e comunicação com o EFIS, sendo o bloco Pack
net_fdm Packet for FlighGear um dos usados.
3.2.5
Matlab AeroSim BlockSet
O AeroSim Blockset é uma blblioteca de blocos do Simulink que fornece componentes para o rápido desenvolvimento de modelos dinâmicos nãolineares de aeronaves de seis graus de liberdade. Além disso, a biblioteca
também inclui modelos de ambiente tais como atmosfera padrão, vento, turbulência e modelos terrestres (referência geóide, gravidade e campo magnético da terra). Ele é uma das principais bibliotecas usadas na modelagem
dinâmica dos modelos das aeronaves nesse simulador. Um modelo de uma
aeronave Sora foi desenvolvido usando-se os blocos fornecidos por esse Tool-
3.2
Instalação e Configuração de Softwares de Comunicação e integração24
Box. O bloco FS Interface está sendo usado para proporcionar comunicação
entre o Matlab/Simulink e MFSX.
3.2.6
Instalação e Configuração de Softwares de Comunicação e integração
Nesta seção serão apresentados mais detalhes em relação aos softwares de
comunicação e middlewares usados neste projeto.
3.2.6.1
FSUPIC (Flight Simulator Universal Inter Process Communication)
O FSUIPC é um Add-On comercial que é instalado junto ao Microsoft
Flight Simulator e permite que um processo externo se comunique com o
Microsoft Flight Simulator utilizando a técnica de Inter Process Communication (Comunicação entre processos). A versão deste programa usada
neste projeto é o FSUIPC 4.3. Esta versão foi construída utilizando a nova
interface da Microsoft conhecida como SimConnect que é usada quase que
exclusivamente para interações com o MFSX.
O FSUPIC 4.3 é uma solução fechada, de modo que não é possível o acesso
ao código-fonte. Porém, é possível programar usando as funções do FSUIPC
se for adquirida a versão FSUPIC 4.3 Developer Kit (SDK). Até este momomento ainda não foi necessário programar usando esse Kit. O FSUPIC 4.3
foi apenas instalado não sendo realizada até o momento nenhuma configuração mais avançada, já que fornece as funcionalidades que permitem que se
possa comunicar com o MFSX através do Matlab/Simulink. É importante
salientar aqui que essa comunicação é apenas SIMPLEX (unidirecional), ou
seja, os pacotes de informação são enviados apenas do Matlab/Simulink para
o MFSX. O FSUPIC quando instalado é localizado dentro da pasta Modules
dentro do diretório principal do MFSX.
O FSUIPC 4.3 foi instalado na máquina que contém o Módulo de Visualização Gráfica e traz consigo o software WideFS Server 7.0, que é o servidor
necessário para se estabelecer uma conexão TCP entre este e o WideFS Client, instalado ná máquina que contém o Módulo de Sistemas e Modelos
Dinâmicos. A partir dessa conexão é usado o bloco FS Interface do AeroSim
Blockset para se estabelecer uma comunicação entre processos sobre o protocolo TCP até o FSUPIC, instalado no Módulo de Visualização Gráfica. O
bloco FS Interface é implementado com a tecnologia CMEX S-Function do
Matlab. A Figura 3.3 mostra esse processo descrito graficamente.
Ao se estabelecer essa conexão, o MFSX está pronto para receber dados
do MatLab/Simulink. Através das funções descritas no arquivo IPCUser.C
3.2
FSUPIC (Flight Simulator Universal Inter Process Communication)25
Figura 3.3: Inter Process Communication usando FSUPIC
as variáveis de estado do MFSX são acessadas e modificadas durante a simulação. Os endereços de memória dessas variáveis são descritas no arquivo
FSUPIC_User.h. O bloco FS Interface é inserido dentro do modelo do
Módulo de Sistemas e Modelos Dinâmicos. É importante salientar que é
o FSUPIC quem acessa diretamente as variáveis de estado do MFSX através da interface SimConnect, sob o comando do bloco FS Interface, que está
remotamente conectado ao FSUPIC.
3.2.6.2
WideFS
Como mencionado, o WideFS divide-se entre WideFs Server e WideFS
Client. Na máquina onde foi instalado o WideFS Client foi necessário configurar um arquivo de parâmetros associado ao WideFS Client. Esse arquivo
é o WideClient.txt. Os parâmetros Protocol e ServerIPAddr foram acrescentados a esse arquivo de modo a definir o IP da máquina destino e o
protocolo da camada de transporte a ser usado. No nosso caso foi escolhido
IP = 192.168.1.100 e Protocol = TCP, como pode ser visto na Figura 3.4.
Configurações mais avançadas ainda não foram necessárias.
3.2.6.3
WideView
WideView é um módulo plug-in, instalado dentro do menu de Add-Ons
do MFSX. Ele pode ser usado para criar cockpits de simuladores com visões
panorâmicas externas com múltiplos computadores (cada um rodando uma
visão) conectados através de uma Local Área Network (LAN). Ele mantém
todas as visões perfeitamente sincronizadas durante a simulação de voo. Cada
computador rodando MFSX pode ser configurado para mostrar uma direção
particular através de uma visão definida pelo usuário. Também é possível
3.2
WideView
26
Figura 3.4: Configuração de parâmetros WideClient
usar apenas um computador rodando MFSX e criar várias visões em um
único computador. Esta é a técnica que foi empregada neste projeto. Logo,
foi instalado na máquina que contém o Módulo de Visualização Gráfica o
WideView 3.1.
O WideView 3.1 traz consigo um modelo gráfico de uma aeronave sem
painel, conhecido como WV_Dummy. Esse modelo gráfico é interessante
pois, pelo fato de não possuir painel (objetos gráficos pesados), torna o desempenho gráfico da simulação melhor. O WV_Dummy é carregado para
o MFSX através de um menu de carregamento de modelos do mesmo. A
figura 3.5 mostra esse menu e o modelo selecionado na parte inferior direita
da figura. Como já mencionado, o painel do cockpit desse simulador será
composto por duas telas de LCD, exibindo uma instrumentação virtual.
Através do WideView foram criadas três visões: frontal, janela esquerda e
janela direita. Essas visões podem ser vistas na Figura 3.3.4. Já a Figura 3.7
mostra o menu no MFSX para se criar as visões. Podemos ver nesse menu
as três visões criadas. Para criar as visões podemos configurar as mesmas
manualmente ou inserindo a angulação e a posição da visão como parâmetros
no menu do WideView. Foi realizada uma configuração manual das visões,
porque esta configuração forneceu uma configuração gráfica melhor. As visões das janelas esquerda e direita foram posicionadas a +225 graus e -45
graus, respectivamente, considerando o eixo de 0 graus paralelo à visão fron-
3.3
Implementação
27
Figura 3.5: Modelo WV_Dummy selecionado
tal. Após essa configuração essas visões foram salvas em um arquivo chamado
Simulador_regulado_telas_baixas para serem o default para toda simulação,
como pode ser visto na Figura 3.9, com esse arquivo selecionado. A Figura
3.8 mostra o menu de acesso às configurações do FSUPIC e WideView no
MFSX.
Para se ter uma melhor idéia de como e onde todos esses softwares foram
instalados, a Figura 3.6 mostra um Diagrama de Instalação, inspirado na
Unified Modeling Language 2.0 (UML 2.0), que mostra a localização de cada
um dos softwares dentro das máquinas do simulador. A figura também mostra as comunicações que existem entre esses softwares. Além desses softwares
já descritos é mostrado também na figura os softwares que compõem o Controle Distribuído da Simulação que será descrito na Seção 3.3.2.
3.3
Implementação
Nesta seção serão descritos os módulos implementados em Simulink que
compõem o simulador. Será descrito também detalhes da instrumentação
implementada no simulador. Por fim, será apresentada a descrição do desenvolvimento e implementação do software que realiza o controle distribuído da
simulação, ou seja, o software que controla remotamente a abertura, inicialização, parada e fechamento dos módulos Simulink do simulador, bem como
3.3
Implementação
Figura 3.6: Diagrama de Instalação do Simulador
Figura 3.7: Criando Visões no MFSX
28
3.3
Módulos de Simulação
29
Figura 3.8: Menu do FSUPIC e WideView no MFSX
Figura 3.9: Visões salvas
a abertura e fechamento do MFSX e dos instrumentos virtuais.
3.3.1
Módulos de Simulação
Esta seção descreve os módulos de simulação implementados.
3.3.1.1
Módulo de Sistemas e Modelos Dinâmicos
O Módulo de Sistemas e Modelos Dinâmicos desenvolvido durante este
trabalho é mostrado na Figura 3.10. Atualmente este módulo consiste basicamente do modelo dinâmico da aeronave Sora. Futuramente, serão incorporados outros sistemas aeronáuticos a este módulo. É neste modelo que é
gerada toda a dinâmica de voo da aeronave. O modelo consiste de um bloco
de entrada, chamado Inputs Simulador. Este bloco corresponde ao conjunto
3.3
30
de inputs que são gerados no cockpit do simulador através de 3 atuadores: o
mache (sinais de profundor e aileron), os pedais (sinal de leme) e a manete
de potência (sinal de potência do motor).
Os sinais do manche e pedais chegam no bloco Inputs Simulador normalizados no intervalo de [-1 1]. Já o sinal de manete de potência chega normalizado no intervalo de [0 1]. Desta forma, existe um potenciômetro para
cada um destes sinais. De fato, o bloco Inputs Simulador recebe do Módulo
de Aquisição e Instrumentação estes sinais via datagramas UDP usando a
rede Ethernet disponível. É no módulo de aquisição e Instrumentação que
os sinais de tensão elétrica obtidos dos sensores são convertidos em valores
normalizados. O interior do bloco Inputs Simulador pode ser visto na Figura
3.11. O bloco Inputs Simulador é composto de um bloco de recebimento de
datagramas UDP, o UDP Receive Binary. Ao receber o datagrama o mesmo
é desencapsulado através do bloco Unpack. O resultado deste processo é a
entrega das 4 variáveis de input ao modelo dinâmico da aeronave.
Seguindo o modelo de Sistemas e Modelos Dinâmicos, os 4 sinais de input
entram no bloco Trata Entrada, onde são aplicadas algumas operações a estes
sinais de modo a compatibilizá-los com o próximo bloco, o 6-DOF Aircraft
Model mod, onde é realizada toda a dinâmica de voo. Esse bloco produz
algumas saídas, que são entradas do bloco Flight Simulator. O interior deste
bloco pode ser visto na Figura 3.12. É dentro deste bloco que o conjunto
de variáveis Position, Euler e Airspeed são enviadas para o MFSX através
do bloco de envio de dados FSInterface. Position corresponde ao vetor das
variáveis [latitude longitude altitude]. Euler corresponde ao vetor de variáveis [ângulo de arfagem ângulo de rolagem âgulo de guinada]. Finalmente, a
variável Airspeed corresponde à velocidade da aeronave em relação ao vento.
Dentro do bloco Flight Simulator, como pode ser visto, também estão localizados dois blocos: EFIS 1 e EFIS 2. Estes são os blocos que enviam as
variáveis de voo para os instrumentos virtuais.
A Figura 3.13 mostra o interior do bloco EFIS1. A EFIS 1 é a responsável
por exibir uma horizonte artificial. Dentro deste bloco entram as variáveis
Position, Euler, Airspeed e Aceleração Lateral. Algumas dessas variáveis
sofrem algumas conversões de tipo de variáveis para compatibilizar os sinais
com as entradas do bloco Pack net fdm packet for FlightGear. Este bloco é
o responsável por encapsular as variáveis de voo em um pacote do tipo net
fdm, sendo este o tipo de arquivo que a EFIS 1 está preparada para receber.
Finalmente, é usado o bloco Send fdm net packet to FlighGear para enviar
o pacote encapsulado sob a forma de datagramas UDP até a EFIS 1. É
Importante lembrar que a EFIS 1 roda na máquina que hospeda o Módulo
de Sistemas Dinâmicos.
Já a Figura 3.14 mostra o interior do bloco da EFIS 2. A EFIS 2 roda na
3.3
31
Figura 3.10: Módulo de Sistemas e Modelos Dinâmicos
máquina que hospeda o Módulo de Instrumentação. A EFIS 2 foi desenvolvida durante este projeto usando o ToolBox Gauges Blockset do Simulink. A
EFIS 2 é um modelo de simulação em Simulink que apresenta diversos medidores mostrando variáveis relacionadas ao motor da aeronave que está sendo
simulada. Como mostra a Figura 3.14 o bloco EFIS 2 recebe um vetor de 20
variáveis. Estas variáveis alimentam os medidores e são encapsuladas através
do bloco Pack e enviadas como datagrams UDP através do bloco UDP Send
Binary até a máquina que hospeda o Módulo de Instrumentação, onde se
encontra o modelo em Simulink da EFIS 2. Neste modelo encontra-se um
bloco UDP Receive Binary que recebe os datagramas UDP e um outro que
desencapsula as variáveis, o Unpack. Após os dados serem desencapsulados,
cada uma das variáveis são conectadas aos medidores.
Ainda não existe no modelo da aeronave do simulador um bloco (modelo
dinâmico) que gere os sinais de motor da aeronave. Eles estão sendo desenvolvidos por outros alunos de graduação e mestrado do DEMEC e no futuro
irão integrar o simulador. Atualmente, como forma de ilustrar o funcionamento da EFIS 2 existe um bloco chamado Motor que alimenta o bloco EFIS
2 com sinais senoidais. No futuro o bloco Motor será composto por novos
modelos dinâmicos.
3.3
Figura 3.11: Interior do Bloco Inputs Simulador
Figura 3.12: Interior do Bloco Flight Simulator
32
3.3 Comunicação entre Computadores Em Rede Usando Ambiente de Simulação33
Figura 3.13: Interior do Bloco EFIS 1
3.3.1.2
Modelo de Aquisição, Acionamento e Instrumentação
A Figura 3.16 mostra o Módulo de Aquisição, Acionamento e Instrumentação. Neste módulo atualmente realiza-se apenas a aquisição de dados,
conversão em valores normalizados das variáveis e envio destas variáveis para
o Módulo de Sistemas e Modelos Dinâmicos via datagrams UDP pela rede.
Como pode-se ver, o bloco Analog Input do ToolBox Data Acquisition ToolBox realiza a aquisição de dados da placa de aquisição da Advantech, a
PCI-1710. Essa placa possui 16 entradas analógicas, sendo que atualmente
apenas 4 são usadas, para se obter os inputs do cockpit do Simulador. Após
a aquisição, cada um dos sinais entram em um bloco de conversão (calibração), onde os valores de tensão correspondentes ao início e fim do curso do
poteciômetro são convertidos em valores normalizados.
Todos os 4 blocos Profundor, Aileron, Leme e Potência são praticamente
idênticos, exceto pelo fato dos valores limites de tensão obtidos em cada
potenciômetro serem diferentes. Além disso, no caso do sinal da manete de
potência a equação a ser aplicada para a conversão de valores é ligeiramente
diferente pois neste caso os valores normalizados variam no intervalo de [0
1].
Analisando um dos blocos como exemplo, tomemos o bloco Profundor
3.3 Comunicação entre Computadores Em Rede Usando Ambiente de Simulação34
Figura 3.14: Interior do Bloco EFIS 2
para a análise, cujo interior é mostrado na figura 3.17. Dentro desse bloco a
Equação (1) é aplicada ao sinal de entrada do bloco:
Out1 = (2.In1 - (3,975 + 1,246)) / (3,975 - 1,246) (1)
Onde:
In1 é o sinal de entrada em volts;
3,975 e 1,246, são respectivamente os limites máximo e mínimo de tensão
obtidos no curso do potenciômetro;
E Out1 é o sinal de saída normalizado entre o intervalo de [-1 1].
Para um melhor entendimento de como a Equação (1) é obtida, a Figura
3.15 mostra como o intervalo [1,246 3,975] é mapeado no intervalo [-1 1].
Esta equação realiza o mapeamento do intervalo [1,246 3,975] para o
intervalo [-1 1]. Como os potenciômetros são lineares, podemos assumir que
a curva de calibração será praticamente uma reta, permitindo representála pela Equação (1). De modo similar, para os demais blocos é usada esta
equação obtendo-se os valores normalizados para todos os sinais. Além disso,
em cada um dos blocos é usado um saturador, limitado no intervalo de [-1
1] de modo que, variações nos valores limites de tensão dos potênciômetros
não possam gerar valores fora desse intervalo até uma próxima calibração.
3.3
Controle Distribuído da Simulação
35
Figura 3.15: Mapeamento dos Intervalos
Após os sinais serem normalizados, são encapsulados em datagramas UDP
através do bloco Pack e são enviados ao Módulo de Sistemas e Modelos
Dinâmicos através do bloco UDP Send Binary.
Nos modelos em Simulink mostrados aparece também um bloco chamado
Sfun_time conectado a outro bloco de Clock. Esse bloco é o responsável por
possibilitar uma simulação em Pseudo Real-time. O que o bloco faz é atrasar
o passo de integração dos modelos para que ocorra no instante em que ocorre
o Tick (pulso) do Clock do processador. Em uma simulação em Real-time,
ao contrário, aos processos em execução (modelos) seria dada a máxima
prioridade de execução em relação às outras prioridades dadas aos demais
processos. Como as simulações descritas aqui não ocorrem em Real-time,
foi usado o bloco de Pseudo Real-time para possibilitar uma performance
próxima à fornecida em simulações de Real-time.
3.3.2
Como podemos perceber, o simulador proposto neste trabalho inclui vários softwares e modelos de simulação que precisam ser abertos, inicializados,
eventualmente parados e inicializados novamente e finalmente finalizados.
Executar todas estas tarefas manualmente para cada software do simulador
é uma tarefa que diminui a praticidade e usabilidade do simulador. Com
o intuito de automatizar estas tarefas, foi desenvolvido um software para o
controle distribuído da simulação. Isto quer dizer que através de uma única
interface, instalada em um notebook por exemplo, é possível controlar toda
3.3
36
Figura 3.16: Módulo de Aquisição, Acionamento e Instrumentação
Figura 3.17: Interior do Bloco Profundor
a simulação, através do controle individual dos softwares envolvidos ou do
controle dos mesmos conjuntamente.
3.3
37
A Figura 3.6 mostra o Diagrama de Instalação do Simulador. Na parte
inferior deste diagrama é possível ver os softwares que compõem o controle
distribuído da simulação. O controle Distribuído da Simulação é composto
pela Interface de Simulação, com a qual o usuário interage, conhecida como
MDLControlClient.exe. Este é de fato um Cliente UDP. É composto também
por servidores UDP instalados em cada uma das máquinas do simulador, conhecidos como MDLControlServer.exe. Esses servidores recebem mesnsagens
do MDLControlClient.exe, bem como enviam mensagens para ele. Sendo assim, a comunicação entre eles é bidirecional. O MDLControlClient.exe foi desenvolvido em C++ no ambiente Microsoft Visual C++ 9.0 Express Edition.
Já os servidores MDLControlServer.exe foram desenvolvidos em C usando o
ambiente Dev C++.
O código do Servidor MDLControlServer.exe é genérico. Sendo assim,
para que o comportamento esperado seja alcançado, é necessário configurar
o arquivo MDLControlServer.txt, configurando o parâmetro Modulo para
um dos seguintes valores: MI (Módulo de Instrumentação), MV (Módulo
de visualização Gráfica) ou MD (Módulo de Sistemas Dinâmicos). Configurando esse parâmetro, o servidor saberá em qual máquina está instalado e
se comportará de maneira adequada. Nas máquinas hospedeiras dos Módulos de Instrumentação e de Sistemas dinâmicos o MDLControlServer chama
um outro aplicativo, em determinadas situações, dependendo da mensagem
recebida do MDLControlClient. Esse aplicativo é o MDLCommand.exe, o
responsável por interagir diretamente com o Matlab/Simulink, enviando comandos para o Command Window do Matlab, permitindo abrir, inicializar,
parar e fechar os modelos em Simulink. Este software foi escrito na linguagem
C e compilado usando o compilador LCC do próprio Matlab.
Quando qualquer umas das máquinas é ligada, os servidores MDLControlServer são inicializados automaticamente, estando contidos na pasta Inicializar dos sistemas operacionais. Eles então, ficam no estado de espera,
aguardando alguma mensagem chegar do MDLControlClient para que possam executar alguma tarefa. Se a tarefa em questão se relacionar com interação com algum dos modelos em Simulink o MDLCommand.exe é então
chamado via linha de comando pelo MDLControlServer. O papel do MDLCommand.exe é então, estabelecer uma conexão com o Command Window do
Matlab via pipes (túneis de comunicação) e anexar o comando que se necessita executar. Entre os comandos possíveis pode-se abrir, fechar, inicializar
e parar a simulação de um modelo. Quando os computadores são ligados
e os servidores são executados, eles chamam uma instância do Command
Window do MatLab que fica minimizada na tela. Cada vez que o MDLCommand.exe é chamado pelo servidor, é anexada (enviada) uma mensagem para
esse CommandWindow.
3.3
38
Para possibilitar que cada chamada ao MDLCommand.exe do Matlab não
precise iniciar uma nova instância do Command Window foi usada a técnica
Automation, fornecida pelo Matlab, que permite que uma única instância
do Command Window receba conexões de vários aplicativos diferentes e que
esses aplicativos se desconectem desse Command Window, sem que se precise
fechar o command Window e abrí-lo novamente para uma nova conexão.
Sendo assim, no inicio da execução de um servidor MDLControlServer é
feita uma chamada ao Command Window do Matlab da seguinte forma:
WinExec("C:/Program Files/MATLAB/R2009b/bin/win32/MATLAB.exe
/Automation",SW_NORMAL);
O comando WinExec permite executar um aplicativo de dentro do servidor MDLControlServer. Desta forma, o Command Window do Matlab (Matlab.exe) está sendo chamado através do comando /Automation, o que permitirá ao MDLCommand.exe posteriormente enviar comandos de sintaxe da
linguagem Matlab para o mesmo, sem que seja necessário abrir um novo Command Window a cada vez que um comando for ser enviado. SW_NORMAL
indica uma abertura do programa no modo padrão. Um comando que poderia ser enviado ao Matlab pelo MDLCommand.exe poderia ser o seguinte:
engEvalString(ep,"set_param(’Sora’,’SimulationCommand’,’start’);")
engEvalString é a função da biblioteca Engine.h do Matlab usada para
enviar comandos. Toda a String dentro das aspas duplas será enviada para o
Commando Window do Matlab. Set_param é a função da linguagem Matlab
usada para se enviar um comando para um modelo em Simulink em forma de
uma String. Sora é o nome do modelo Simulink que está sendo controlado.
SimulationCommand é o tipo de comando que está sendo enviado. Finalmente, start é o comando propriamente dito, ou seja, o modelo Sora será
inicializado.
Para que estes comandos, parte do código do MDLCommand.exe, possam
ser enviados é necessário que se estabeleça dentro do MDLCommand.exe
uma conexão com o Command Window do Matlab inicialmente aberto pelo
servidor MDLControlServer. A conexão se dá da seguinte forma:
Engine *ep;
if (!(ep = engOpen("/0"))) {
fprintf(stderr, "Can’t start MATLAB engine");
return EXIT_FAILURE;
}
3.3
Instrumentação Virtual
39
O ponteiro ep é o nome da conexão estabelecida. Os comandos dentro do
If abrem a conexão ou imprimem uma mensagem de erro caso esta conexão
não possa ser aberta.
Já na máquina de visualização gráfica não existe o software MDLCommand.exe, pois nessa máquina não se controla modelos de simulação em Simulink. Apenas contrala-se a abertura e fechamento do MFSX. O MFSX foi
configurado para que ao ser executado abra um voo especifico, com as três
visões já configuradas, como mencionado na Seção que trata do WideView.
Sendo assim, nesta máquina só existe o MDLControlServer.
A Figura 3.18 mostra a Interface de controle da Simulação. Essa interface
é dividida em duas partes: simulação individual e simulação automática. A
simulação individual permite controlar cada um dos Módulos em Simulink
separadamente, controlar abertura e finalização do MFSX, abertura e finalização da EFIS 1 e abertura, inicialização, parada e finalização da EFIS 2. Já
a simulação automática permite inicializar e parar uma simulção de maneira
automática, ou seja, uma sequência de comandos será disparada pela interface, endereçados para os servidores, de modo que todos os softwares sejam
inicializados automaticamente, na sequência correta. Tanto na simulação individual, quanto na simulação automática, a interface estará se comunicando
com os servidores instalados em cada máquina.
Para que essa comunicação seja possível, é necessário que o usuário conecte a interface aos servidores, clicando no botão Conectar a escravos MDL.
Caso deseje encerrar as conexões o usuário deve clicar em Fechar Conexão.
Para o controle individual dos módulos existem botões para abrir, fechar,
inicializar e parar os mesmos. Na interface é possível configuar também os
endereços de rede (IP) e as portas de comunicação que serão usadas com
cada um dos servidores UDP instalados nas máquinas. A interface também
possui uma janela de log de mensagens que informa o estado das operações
que estão sendo realizadas, ou seja, na interação da inteface com um servidor,
que informa à inteface conlusão de operações, bem como possíveis erros.
3.3.3
Instrumentação Virtual
Como mencionado o simulador usa duas EFIS para exibir diversas variáveis do modelo da aeronave. A Figura 3.19 mostra a interface da EFIS 1. Já
a Figura 3.20 mostra a interface da EFIS 2. A EFIS 2 apresenta medidores
para diversas variáveis como pressão e temperatura de óleo, rotações por minuto (RPM) e volume de combustível. Já a EFIS 1 mostra variáveis como
altitude, horizonte virtual, velocidade e aceleração lateral.
3.3
Resultados de Simulação
40
Figura 3.18: Interface de Controle da Simulação
3.3.4
Com o intuito de mostrar como o Sistema Dinâmico da Aeronave Sora,
modelado no Módulo de Sistemas Dinâmicos, responde à entradas do sistema,
a Figura 3.21 mostra as variáveis de reposta (ângulos de Euler), ou seja,
os ângulos de arfagem(theta), rolagem(phi) e guinada(psi), às Entradas de
Profundor, Aileron e Leme, Figura 3.22, em uma simulação específica. A
potência foi deixada a 100% nesta simulação, como pode ser observado pelo
sinal de manete de potência(throttle). As varíaveis de entrada variam de -30
a 30 graus. Já as variáveis de saída variam de -180 a 180 graus.
A linhas verticais pontilhadas como A, B e C nas figuras 3.21 e 3.22 são
momentos específicos da simulação em que foram tiradas fotografias das imagens geradas pelo MFSX, mostrando as três visões do piloto. Essas fotografias são mostradas na Figura 3.23. Repare que as imagens correnspondentes
as visões para um dado momento estão desalinhadas, pois, como a Figura
3.3.4 mostra, os televisores foram montados de modo que o televisor do meio
3.3
41
Figura 3.19: Interface da EFIS 1
ficasse mais alto que os demais, para proporcionar maior realismo ao piloto.
Naturalmente, as visões são projetas alinhadas para o piloto, como mostra a
figura .
3.3
42
Figura 3.20: Interface da EFIS 2
Figura 3.21: Resposta Dinâmica do Modelo Sora à Entradas do Sistema
3.3
43
Figura 3.22: Entradas do Sistema Dinâmico Sora
Figura 3.23: As Três visões geradas pelo MFSX correspondentes aos momentos A, B e C
Capítulo 4
Conclusão
Este trabalho mostrou o desenvolvimento de um simulador de voo baseado em uma arquitetura computacional de computadores pessoais, sob os
aspectos de sua automação, integração de dados e instrumentação.
Os objetivos almejados no Capítulo 1 foram alcançados no decorrer do
desenvolvimento deste simulador de voo. Através do uso de diversos softwares e middlewares, o trabalhou mostrou a integração destes diversos sistemas e como estes trabalham conjuntamente durante uma simulação. O
trabalho usou como principal plataforma de desenvolvimento o ambiente
Matlab/Simulink que possibilitou, com o uso de seus diversos ToolBoxes,
o desenvolvimento de modelos de simulação que se comunicam através de
uma rede Ethernet e se integram aos demais softwares descritos. O uso de
Matlab/Simulink possibilita uma rápida modelagem e matunenabilidade dos
modelos, bem como facilidade de configuração dos parâmetros envolvidos em
uma simulação. O trabalho também mostrou a integração de alguns instrumentos de voo e sua instrumentação através do uso de potenciômetros
lineares e do uso de uma placa de aquisição de dados, além da integração
destes instrumentos ao ambiente Matlab/Simulink.
Através do uso de um software de controle, construído durante o desenvolvimento deste trabalho, é possível controlar os modelos de simulação de
forma distribuída, fornecendo uma interface única de controle. É possível,
futuramente, tornar essa interface uma ferramenta de monitoração, de modo
que seja possível analisar diversas variáveis envolvidas na simulação.
Apesar de o trabalho ter trazido resultados positivos, contribuindo para o
desenvolvimento de novas pesquisas a serem realizadas no CEA e com outros
grupos de pesquisa, é importante ressaltar algumas dificuldades encontradas
durante o desenvolvimento. Inicialmente pretendia-se desenvolver todos os
modelos de simulação de modo que os mesmos executassem em tempo-real. A
estratégia inicial era desenvolver os modelos em Simulink e depois convertê44
CAPÍTULO 4. CONCLUSÃO
45
los para softwares executáveis de tempo-real, podendo executá-los em ambientes preparados para trabalhar com processos em tempo-real. A conversão
dos modelos para código executável de tempo-real é possível usando um ToolBox do Matlab conhecido como Real Time Workshop. A execução destes
executáveis em ambiente Windows é possível usando um outro ToolBox do
Matlab: o Real-Time Windows Target. Este ToolBox fornece um Kernel de
tempo-real que é instalado no ambiente Windows possibilitando executar os
softwares com prioridade máxima, alcançando assim um melhor desempenho.
Porém, foi usado o ToolBox AeroSim Blockset para a construção do modelo dinâmico da aeronave Sora. O AeroSim é um ToolBox relativamente
antigo, desenvolvido em 2004, e para que seus blocos funcionem com o Realtime Worshop é necessário usar versões dos blocos em formatos de arquivos
DLL. Os softwares Matlab mais novos usam uma nova tecnologia para isso,
conhecida como CMEX-files. Sendo assim, apesar de se ter investido um bom
tempo tentando converter e integrar os blocos do AeroSim aos modelos de
simulação, para trabalharem em tempo-real, essa tentativa se mostrou frustrada. Apesar disso, atualmente os modelos trabalham em Pseudo real-time
e satisfazem as necessidades atuais de simulação.
O Matlab traz um ToolBox conhecido como AeroSpace Blockset. Esse
ToolBox é completamente compatível com as novas versões do Matlab e o
processo de transformação de seus blocos para tempo-real é menos custoso,
pois o ToolBox é fornecido pela MathWorks (empresa que produz o Matlab),
fornecendo assim um maior suporte de documentação para essas tarefas mais
específicas. Logo, uma das sugestões para trabalhos futuros seria desenvolver
novos modelos usando o AeroSpace Blockset e trabalhar em tempo-real, caso
essa seja uma necessidade da equipe do CEA. Como pretende-se integrar um
sistema de force-feedback ao simulador e levando em conta que nesse caso
específico tem-se um sistema de controle completo, com uma planta física,
apresentando muitas das vezes requisitos de tempo de resposta do sistema,
seria interessante pensar em controle em tempo-real. Nesse caso também,
seria necessário usar as 4 saídas analógicas disponíveis na placa de aquisição
de dados atualmente instalada.
Sendo assim, conclui-se que o simulador é uma ferramenta pronta para
o desenvolvimento de estratégias de auxílio à pilotagem, bem como uma
plataforma de testes para se desenvolver diversas tecnologias e pesquisas na
área de sistemas aeronáuticos.
Referências Bibliográficas
[Col, 2003] (2003). Collins English Dictionary Complete and Unabridged http://www.thefreedictionary.com/flight+simulator. HarperCollins, 6rd edition.
[Bab, 2009] (2009). Dicionário babylon - http://www.babylon.com.
[Mac, 2009] (2009).
Dicionário
Macmillian
http://www.macmillandictionary.com/dictionary/british/flight-simulator.
-
[Allerton, 2009] Allerton, D. J. (2009). A distributed architecture of pcs for rapid
prototyping. College of Aeronautics, Cranfield University, BEDFORD MK43
0AL, UK.
[Iscold et al., 2007] Iscold, P., Oliveira, G., Neto, A. A., Pereira, G. A., and Torres,
L. A. (2007). Desenvolvimento de horizonte artificial para aviação geral baseado
em sensores mems. In Anais V Congresso Brasileiro de Engenharia Inercial
(SBEIN’07.
[Jin et al., 2009] Jin, J., Han, J., Zheng, S., and He, J. (2009). Dds based high
fidelity flight simulator. In Information Engineering, 2009. ICIE ’09. WASE
International Conference on, volume 1, pages 548–551.
[Lei et al., 2007] Lei, Z., Hongzhou, J., and Hongren, L. (2007). Pc based high
quality and low cost flight simulator. In Automation and Logistics, 2007 IEEE
International Conference on, pages 1017–1022.
[Page, 2009] Page, R. L. (2009). Brief history of flight simulation. R.L. Page and
Associates.
[Roeder, 1929] Roeder (1929). H.a. german patent 568,731.
[Shutao et al., 2008] Shutao, Z., Jingfeng, H., Qitao, H., and Junwei, H. (2008).
A low-cost pc-based flight simulator development. In Systems and Control in
Aerospace and Astronautics, 2008. ISSCAA 2008. 2nd International Symposium
on, pages 1–5.
[Tanenbaum, 2006] Tanenbaum, A. S. (2006). Organização Estruturada de Computadores. Prentice-Hall.
46
REFERÊNCIAS BIBLIOGRÁFICAS
47
[Zheng et al., 2009a] Zheng, S., Huang, Q., Jin, J., and Han, J. (2009a). Flight
simulator architecture development and implementation. Measuring Technology
and Mechatronics Automation, International Conference on, 2:230–233.
[Zheng et al., 2009b] Zheng, S., Zheng, S., He, J., and Han, J. (2009b). An optimized distributed real-time simulation framework for high fidelity flight simulator
research. In Information and Automation, 2009. ICIA ’09. International Conference on, pages 1597–1601.
[Zheng et al., 2009c] Zheng, S., Zheng, S., He, J., Liu, G., and Han, J. (2009c). An
optimized avionics interface system for high fidelity flight simulator research. In
Mechatronics and Automation, 2009. ICMA 2009. International Conference on,
pages 4040–4044.

Automação, Integração de dados e Intrumentação de um Simulador

Transcrição

Documentos relacionados

CRIAÇÃO DE UMA FERRAMENTA 3D PARA SIMULAÇÃO

Simulador de Ambientes

Roteiro

simulador para o aprendizado de sistemas operacionais

Simuladores

Apresentação FETEC

Segurança e Treinamento

Instalação e Configuração do Squawkbox

piloto privado de aviões

Portaria nº 1.377, de 9 de novembro de 2015 Dispõe