Automação, Integração de dados e Intrumentação de um Simulador
Transcrição
Automação, Integração de dados e Intrumentação de um Simulador
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 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 Sistemas de Visualização 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 Características de Software e Modelagem Dinâmica 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 Características de Software e Modelagem Dinâmica 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 Módulo de Sistemas e Modelos Dinâmicos 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 Módulo de Sistemas e Modelos Dinâmicos 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 Módulo de Sistemas e Modelos Dinâmicos 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 Controle Distribuído da Simulação 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 Controle Distribuído da Simulação 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 Controle Distribuído da Simulação 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 Controle Distribuído da Simulação 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 Resultados de Simulação 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 Resultados de Simulação 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 Resultados de Simulação 42 Figura 3.20: Interface da EFIS 2 Figura 3.21: Resposta Dinâmica do Modelo Sora à Entradas do Sistema 3.3 Resultados de Simulação 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.