Avaliação de Desempenho e Potência de Aplicações Embarcadas em Plataformas Heterogêneas. Alexandre Augusto Giron

Transcrição

1 UNIOESTE Universidade Estadual do Oeste do Paraná CENTRO DE CIÊNCIAS EXATAS E TECNOLÓGICAS Colegiado de Ciência da Computação Curso de Bacharelado em Ciência da Computação Avaliação de Desempenho e Potência de Aplicações Embarcadas em Plataformas Heterogêneas Alexandre Augusto Giron CASCAVEL 202

2 ALEXANDRE AUGUSTO GIRON AVALIAÇÃO DE DESEMPENHO E POTÊNCIA DE APLICAÇÕES EMBARCADAS EM PLATAFORMAS HETEROGÊNEAS Monografia apresentada como requisito parcial para obtenção do grau de Bacharel em Ciência da Computação, do Centro de Ciências Exatas e Tecnológicas da Universidade Estadual do Oeste do Paraná - Campus de Cascavel Orientador: Marcio Seiji Oyamada CASCAVEL 202

3 ALEXANDRE AUGUSTO GIRON AVALIAÇÃO DE DESEMPENHO E POTÊNCIA DE APLICAÇÕES EMBARCADAS EM PLATAFORMAS HETEROGÊNEAS Monografia apresentada como requisito parcial para obtenção do Título de Bacharel em Ciência da Computação, pela Universidade Estadual do Oeste do Paraná, Campus de Cascavel, aprovada pela Comissão formada pelos professores: Prof. Marcio Seiji Oyamada (Orientador) Colegiado de Ciência da Computação, UNIOESTE Prof. Adair Santa Catarina Colegiado de Ciência da Computação, UNIOESTE Prof. Edmar Bellorini Colegiado de Ciência da Computação, UNIOESTE Cascavel, 7 de Outubro de 202.

4 DEDICATÓRIA Dedico este trabalho à minha família, que sempre se fez presente e nunca mediu esforços em me ajudar. Dedico também à minha querida namorada Francielle Soder, sempre muito amável e companheira, e a todos os meus parentes e amigos que contribuiram nesta jornada.

5 Você não é amado porque você é bom, você é bom porque é amado Nelson Mandela Não é preciso que a bondade se mostre; mas sim é preciso que se deixe ver Platão

6 AGRADECIMENTOS Agradeço aos meus pais, Maria Cristina Nedel Giron e Paulo Gilberto Giron, por fornecerem excelentes condições para que eu pudesse realizar este curso. Graças a eles, tive (e ainda tenho!) uma vida ótima, e agradeço ao meu irmão Guilherme Eduardo Giron, pela sua alegria espontânea e pelos bons momentos compartilhados. Agradeço também à minha namorada Francielle Cristina Soder, por todo o amor e carinho que me deu, ajudando-me em vários momentos que precisei. Seu apoio incondicional e principalmente os maravilhosos momentos vividos jamais serão esquecidos. Agradeço aos meus parentes, que sempre acreditaram em mim e também me forneceram auxílio em diversos momentos. Agradeço a todos os meus primos e primas, em especial ao Lucas Henrique Giacomini, por estar sempre por perto, e ao João Carlos Pagnoncelli, pelos bons momentos e festas em que estivemos. Agradeço ao meu amigo Julian Weber, pelas diversas caronas fornecidas em muitas das incontáveis vezes que percorri o trajeto Marechal Cândido Rondon Cascavel. Agradeço de forma especial ao meu orientador, Marcio Seiji Oyamada, por me orientar três anos nos trabalhos de Iniciação Científica, no estágio supervisionado e neste trabalho de conclusão de curso, proporcionando um vasto aprendizado que vou carregar para minha vida profissional. Agradeço a todos os meus amigos e companheiros de curso, em especial aos colegas Cauê Schuch Lopes e Diego Robles Viera Ribeiro por contribuir e ajudar nos trabalhos e por participar dos bons e maus momentos do curso. Além disso, agradeço a todos os demais colegas de turma, amigos e companheiros de curso pelo apoio e pelo companheirismo. Também agradeço à UNIOESTE, com todo o seu corpo docente e técnico-administrativo, pela oportunidade de um curso desta magnitude. Enfim, agradeço a todos os que me auxiliaram a vencer esta longa jornada. Muito obrigado.

7 Lista de Figuras 2.: Funcionalidades Samsung SmartTV ES8000. Extraído de [7] : Diagrama de blocos funcionais do OMAP 3530 [27] : Foto da Placa BeagleBoard-xM, Revisão C. Extraído de [5] : Exemplo do problema de alinhamento de bytes : Etapas do processo da decodificação de vídeos H.264 [43] : Gráfico da utilização do processador ARM, na decodificação H.264 efetuada pelo DSP : Esquemático do circuito de medição de consumo de potência da BeagleBoard-xM [48] : Foto da decolagem do Tiriba [5] : Diagrama de blocos do Tiriba [5] : Foto da placa controladora ATMega2560 [52] : Foto da placa IMU Shield [52] : Esquemático da Arquitetura do ArduPlane-SITL [2] : Screenshot da simulação de um voo através do APM Planner para visualização do voo : APM Planner utilizado para criação de uma rota para um voo simulado : Esquemático da organização do ambiente de simulação : Esquemático do fluxo de execução de uma simulação completa : Planos de voo das missões 2 e 3, utilizadas na análise do funcionamento do ArduPlane : Plano de voo utilizado para as avaliações de desempenho e potência do ArduPlane : Visualização da rota percorrida pelo VANT na simulação da missão : Trecho do código-fonte do ArduPlane : Gráfico da utilização do processador ARM, na execução do ArduPlane na BeagleBoard-xM...46 vi

8 Lista de Tabelas 2. Áreas chave e exemplos de sistemas embarcados Exemplos de Plataformas e suas características Resumo dos componentes da placa de desenvolvimento BeagleBoard-xM [5] Dispositivos que utilizam processador ARM Funcionalidades do processador DSP TMS320C64x+ e descrição Informações sobre o comportamento dos voos simulados das missões de teste...45 vii

9 Lista de Abreviaturas e Siglas MPSoC Multiprocessor System-on-Chip VANT Veículo Aéreo Não Tripulado AGC Apollo Guidance Computer MIT Massachusetts Institute of Tecnology IDC International Data Corporation GPS Global Positioning System USB Universal Serial Bus ARM Advanced Risc Machine DSP Digital Signal Processor VGA Video Graphics Array RISC Reduced Instruction Set Computing DSL Digital Subscriber Loop MIPS Million Instructions Per Second VLIW Very Long Instruction Word MPEG Moving Picture Experts Group QCIF Quarter Commom Intermediate Format HD High Definition CPU Central Processing Unit INCT-SEC Instituto Nacional de Ciência e Tecnologia em Sistemas Embarcados Críticos UDP User Datagram Protocol TCP Transmission Control Protocol viii

10 Sumário Lista de Figuras vi Lista de Tabelas vii Lista de Abreviaturas e Siglas viii Sumário ix Resumo xi Introdução.Sistemas Embarcados....2 Histórico Justificativa, Objetivos e Organização do Texto Características dos Sistemas Embarcados 5 2. Características comuns aos Sistemas Embarcados Áreas chave de utilização de sistemas embarcados Características de Projeto de sistemas embarcados Desenvolvimento em Plataformas Heterogêneas 0 3. Características e Vantagens da utilização de MPSoC Ferramentas Plataforma utilizada: BeagleBoard-xM Processador ARM Cortex-A Processador DSP Portabilidade de aplicações Problemas de alinhamento de bytes em processadores ARM Análise do desempenho do H.264 na BeagleBoard-xM O padrão de vídeos H Resultados Obtidos na análise Estudo de Caso Contextualização: VANTs ArdupilotMega: Plataforma Arduino para VANTs ArduPlane Software In The Loop (SITL) Avaliação do SITL-Arduplane na BeagleBoard-xM) Avaliação do Funcionamento...42 ix

11 4.4.2 Avaliação do Desempenho Avaliação do consumo de Potência Conclusões e Trabalhos Futuros Conclusões Trabalhos Futuros...52 A Arquivos do Planejamento do Voo Simulado 53 B Arquivo resultado GPROF 54 Glossário 7 Referências Bibliográficas 72 x

12 Resumo No desenvolvimento de sistemas embarcados, os requisitos que determinam o seu sucesso no mercado devem ser considerados, tais como desempenho, consumo de potência, custo, design. De modo geral, as arquiteturas MPSoC (Multiprocessor System-on-Chip) heterogêneas, que integram um ou mais processadores de diferentes propósitos, respondem bem aos requisitos desses sistemas, com eficiência no processamento de diversas tarefas, como a decodificação de áudio e vídeo. No entanto, nos sistemas embarcados críticos, outro requisito de fundamental importância é o de tolerância a falhas. Um exemplo de um sistema desse tipo é o VANT (Veículo Aéreo Não Tripulado), onde falhas podem acarretar consequências trágicas. Assim, é importante que sejam feitos processos para validar esses sistemas, como, por exemplo, a avaliação de desempenho. O objetivo desse trabalho foi realizar análises de desempenho e consumo de potência, bem como o funcionamento na simulação de um VANT em operação, através do software ArduPlane. A arquitetura utilizada como base nessa simulação foi a placa de desenvolvimento BeagleBoard-xM, que contém a plataforma MPSoC DM A execução do ArduPlane na simulação de um VANT em missões distintas nesta arquitetura obteve um desempenho satisfatório, em termos de utilização de processador, e o consumo de potência pelo DM3730 da placa, foi estimado em 2,38 W, em média. O comportamento do voo simulado do VANT também foi verificado, com a utilização do software APM Planner. Palavras-chave: Sistemas Embarcados Críticos, Desempenho, Consumo de potência, BeagleBoardxM, MPSoC heterogêneo, simulação, VANT. xi

13 Capítulo Introdução. Sistemas Embarcados Do inglês Embedded Systems, os sistemas embarcados são sistemas computacionais que processam informação e são incorporados em um produto maior []. Uma segunda definição para o termo, mais informal, é a definição de Jakob Engblom, Um computador que não parece ser um computador [2]. Além disso, no passado, tinha-se o conceito de que os sistemas embarcados são utilizados para finalidades específicas. Por exemplo, antigamente os aparelhos celulares eram utilizados apenas para realizar ligações. Com o surgimento dos smartphones, esse conceito se revela obsoleto. Alguns sistemas embarcados atualmente são capazes de realizar diversas tarefas que torna a definição de Engblom, embora confusa, coerente. Vários são os exemplos desses sistemas que estão cada vez mais presentes no cotidiano das pessoas. Os mais comuns são telefones celulares, DVD players, eletrodomésticos como aparelhos micro-ondas, sistemas de controle automotivos (como injeção eletrônica, freios ABS) e sistemas em aviônicos (como sistemas de navegação e comunicação, sistemas de controle de voo). Entretanto, a crescente necessidade de desempenho aliada à limitação no consumo de potência impacta no esforço de desenvolvimento dos sistemas embarcados. Ao contrário dos sistemas para desktop, esses sistemas são construídos pela integração otimizada de hardware e software, fazendo-se necessário considerar os requisitos de consumo de potência bem como o de desempenho da aplicação. Atualmente, encontram-se várias soluções contendo vários processadores em um único chip, denominadas MPSoC (Multiprocessor System-on-Chip) [3]. Muitas aplicações já utilizam estes processadores, principalmente aplicações multimídia, destacando-se a

14 decodificação de vídeos [4]. Como exemplos de arquiteturas de MPSoCs temos: TI OMAP [5], Philips Nexperia [6], Intel IXP2850 Network Processor [7], ST Nova A9500 [8], entre outros..2 Histórico De acordo com [9] podemos resumir o histórico dos sistemas embarcados. Com relação ao surgimento desses sistemas, o dispositivo considerado como o primeiro sistema embarcado foi o Apollo Guidance Computer (AGC), desenvolvido pelo Massachusetts Institute of Tecnology (MIT), no início da década de 960. O AGC foi considerado como primeiro sistema embarcado por ser o primeiro a se utilizar de circuitos integrados, cuja CPU trabalhava a velocidade de,024 MHz (aproximadamente 000 vez mais lento que um computador comum hoje). Esta velocidade era dividida por dois para fazer a comunicação com os outros sistemas da nave Apollo que trabalhavam a 52 KHz. A partir de 960, houve um salto na utilização dos sistemas embarcados, devido principalmente ao barateamento da produção dos circuitos integrados. Entretanto, ainda na década de 980, estes microprocessadores/microcontroladores necessitavam de vários de componentes externos para funcionar. Terminando a década de 980, quando o custo de um microcontrolador caiu abaixo de um dólar americano, os sistemas embarcados começaram a substituir componentes físicos como potenciômetros e capacitores variáveis. Juntamente com a popularização dos telefones celulares, em meados de 990, os sistemas embarcados começaram a fazer parte da vida das pessoas. Em 996 foi estimado que, em média, um cidadão americano entrava em contato com 60 microprocessadores por dia [0]. Um fato que contribuiu significativamente na popularização dos sistemas embarcados foi a cultura da Eletrônica de Consumo. Nos Estados Unidos, de acordo com uma pesquisa realizada pela CEA (Consumer Eletronics Association), as vendas de produtos eletrônicos alcançaram aproximadamente 8 bilhões de dólares, no ano de Além disso, à medida que novos sistemas embarcados eram produzidos, agregando novas e diferentes finalidades, seus lançamentos eram acompanhados de sucessos de venda. Eletrônica de Consumo: é um termo designado a qualquer equipamento eletrônico de uso pessoal, geralmente com intuito de prover entretenimento, comunicações e produtividade de trabalho. Alguns exemplos desses equipamentos são os computadores pessoais, tocadores MP3, calculadoras, GPS, entre outros.. 2

15 Um exemplo disso pode ser visualizado em um estudo do International Data Corporation (IDC), estudo no qual é destacado que as vendas de smartfones no Brasil aumentaram no ano de 20 em torno de 84%, comparado ao ano de 200 []. Nos dias atuais pode-se entrar em contato com diversos sistemas embarcados, como ao realizar uma ligação através de um aparelho celular, ouvir música em um player mp3, cozinhar um alimento em um aparelho micro-ondas, conduzir um carro moderno, viajar de avião, entre outras..3 Justificativa, Objetivos e Organização do Texto Como descrito anteriormente, a importância dos sistemas embarcados aumentou significativamente, tendo em vista sua popularização causada por vários fatores, entre eles a redução de custos de produção e a grande quantidade de áreas chave nas quais podem atuar. Essas áreas são detalhadas na seção 2.3. Com relação ao desenvolvimento desses sistemas, devem ser consideradas as dificuldades no processo de construção de um sistema desse tipo, pois vários são os requisitos a serem atendidos, necessitando integrar de forma otimizada hardware e software. Assim, os objetivos gerais desse trabalho são destinados a mostrar as características dos sistemas embarcados, apresentar os requisitos do desenvolvimento desses sistemas e comparálos com o desenvolvimento para sistemas desktop. Além disso será apresentada uma placa de desenvolvimento para sistemas embarcados, a placa BeagleBoard-xM[5]. Serão apresentadas as formas de desenvolvimento e as ferramentas existentes. Dois estudos de caso distintos foram abordados neste trabalho. A decodificação de vídeos do padrão H.264 [8] foi avaliada na placa de desenvolvimento BeagleBoard-xM, na forma de um estudo de caso inicial deste trabalho, abordando métricas para a avaliação dos requisitos de desempenho e consumo de potência. A avaliação de um VANT (Veículo Aéreo Não Tripulado) [6] em um ambiente de simulação foi desenvolvida neste trabalho, como sendo o principal estudo de caso, porém reutilizando as mesmas métricas usadas no primeiro estudo deste trabalho. O software ArduPlane [2], que permite a criação de rotas e o voo autônomo de aeromodelos, foi utilizado como base desse estudo de caso. O ArduPlane executa originalmente em uma plataforma de hardware Arduino [3] com alguns periféricos como acelerômetros, barômetro e GPS. O ArduPlane foi utilizado neste trabalho com o objetivo específico de simular um voo 3

16 autônomo, através da execução desse software na plataforma BeagleBoard, avaliando o desempenho bem como o comportamento da simulação. Para isso, a compilação Software In The Loop (SITL) do código do ArduPlane foi usada, já que ela simula os periféricos (sensores e atuadores) que seriam utilizados em um VANT real, no nível de registradores. Isso significa que os drivers dos componentes usados em um voo real (como acelerômetros e GPS) funcionam da mesma forma no simulador. A estrutura de capítulos compõem o texto da seguinte forma: o Capítulo 2 apresenta a classificação e as características comuns desses sistemas; já o Capítulo 3 descreve os requisitos e as diferenças sobre o desenvolvimento de sistemas embarcados com relação ao desenvolvimento desktop; o estudo de caso deste trabalho, com a intenção de avaliar a utilização do ArduPlane [2] na plataforma Beagleboard-xM [5], simulando um VANT em operação, está detalhado no quarto capítulo; por fim, os resultados obtidos, conclusões e trabalhos futuros são apresentados no quinto capítulo. 4

17 Capítulo 2 Características dos Sistemas Embarcados 2. Características comuns aos Sistemas Embarcados A vasta gama de aplicações dos sistemas embarcados causa uma série de diferenças entre eles, tanto quanto à finalidade, design, tamanho, entre outros. Entretanto, segundo [], os sistemas embarcados possuem características comuns, as quais são listadas a seguir:. Interação com o meio externo: normalmente os sistemas embarcados interagem com o ambiente físico através de sensores, para coletar informações sobre esse ambiente. Além disso, a maioria desses sistemas se utilizam de uma interface com o usuário diferente das utilizadas em um computador de propósito geral, considerada como interface dedicada. Assim, é incomum um sistema embarcado possuir teclado e uma tela de alta resolução, por exemplo. 2. Segurança/Confiabilidade: é uma característica crucial nos sistemas embarcados críticos, principalmente pelo fato de que esses sistemas possuem um impacto imediato sobre o ambiente externo. Um exemplo clássico são os sistemas que controlam o funcionamento (total ou parcial) das usinas nucleares, na qual uma falha de segurança ou na confiabilidade pode causar uma catástrofe. Inclui-se nesse quesito a tolerância a falhas, na qual um sistema deve continuar funcionando caso algum componente apresente falhas. 3. Eficiência dos sistemas embarcados: geralmente o hardware dos sistemas embarcados é limitado; então seus recursos devem ser usados de maneira eficiente. As métricas para avaliar a eficiência são várias, entre elas: Consumo de Potência: sabe-se da dependência de muitos dispositivos sobre as baterias que os alimentam, mostrando que a energia deve ser usada da melhor forma possível; 5

18 Tamanho de código embarcado: o código a executar em um sistema embarcado deve ser o menor possível, por limitações de memória, visto que esse código deve ser armazenado no dispositivo. Custo: principalmente no ramo de eletrônica de consumo, o custo de produção de um sistema embarcado deve ser reduzido ao máximo, para que este seja competitivo e possa ter sucesso de aceitação pelos utilizadores. Tempo de Execução: deve ser otimizado ao máximo, através da utilização mínima dos recursos de software e hardware, necessários para a implementação de uma determinada funcionalidade. Consequentemente, o consumo de energia é reduzido. 4. Restrições de Tempo Real: um sistema embarcado de tempo real significa que ele deve realizar uma certa tarefa dentro de um limite de tempo. As restrições são de dois tipos: Hard real-time: a perda do intervalo limite de tempo da execução de uma certa tarefa poderá causar uma catástrofe. Exemplos são: sistema de controle de operação de usinas nucleares, software de controle de freios ABS; Soft real-time: são os intervalos de tempo que, caso perdidos, não resultarão em danos sérios ao ambiente externo. Exemplo: software de codificação de vídeo. Obviamente nem todos os sistemas atendem todas as características acima. Alguns sistemas que possuem uma vasta gama de finalidades, como o SmartTV da Samsung [7], perdem o conceito de interface dedicada. Apesar de possuir um controle remoto comum, esse aparelho permite a utilização de uma câmera embutida como sensor de movimento, controle por reconhecimento de faces e voz, ou ainda um smartfone compatível para controlar o seu funcionamento. Na Figura 2., as características do SmartTV podem ser visualizadas: Além disso, de acordo com [9], existem outras características que podem ser levadas em consideração, como o tamanho variado (pequenos aparelhos celulares até grandes equipamentos como aviões e estações espaciais) e conectabilidade (o grau de interação de um dispositivo com uma rede). 6

19 Figura 2.: Funcionalidades Samsung SmartTV ES8000. Extraído de [7]. 2.2 Áreas chave de utilização de sistemas embarcados As áreas chave nas quais os sistemas embarcados são utilizados podem ser visualizadas na Tabela 2. [], na qual pode-se perceber que as aplicações dos sistemas embarcados são várias e em diferentes áreas de atuação. Além disso, vale ressaltar que as características fundamentais para esses sistemas significam que elas são mais importantes, comparadas com quaisquer outras características que possam ter. Exemplificando, um sistema de automação industrial que falhar na confiabilidade pode acarretar prejuízos sérios à indústria, em termos de lucro, principalmente. Por outro lado, se esse sistema deixar a desejar na eficiência, no quesito de custo do sistema, por exemplo, os prejuízos serão menores ou podem ser sobrepostos ao longo do tempo e até por medidas de redução de outros custos da indústria. Por isso, esse quesito é de menor relevância comparado à confiabilidade. 7

20 Tabela 2.: Áreas chave e exemplos de sistemas embarcados Áreas chave Alguns Exemplos Característica fundamental Eletrônica automotiva: Sistemas de freios ABS, Sistemas Segurança/Confiabilidade, GPS Restrições de tempo real Sistemas anticolisão, de controle de Segurança/Confiabilidade, voo, de navegação. Restrições de tempo real Telefones celulares, TV Digital [8] Eficiência: baixo consumo de Aviônicos Telecomunicações potência, tempo de execução, custo Sistemas Médicos Membros artificiais, Ouvido Eficiência, artificial Segurança/Confiabilidade, Restrições de tempo real Aplicações Militares Sistemas de defesa aérea, de Eficiência, monitoramento [9] Segurança/Confiabilidade Sistemas de Autenticação Sistemas biométricos [20] Segurança/Confiabilidade Eletrônica de Consumo Tablets, Smartfones, players mp3 Eficiência: tempo de execução, custo, baixo consumo de potência Automação Industrial Ambientes inteligentes Controladores de braços mecânicos, Segurança/Confiabilidade, atuadores Restrições de tempo real Casa Inteligente [2], sistemas de Eficiência, reconhecimento de voz para Segurança/Confiabilidade automação residencial Robótica Robôs móveis autônomos Eficiência, Segurança/Confiabilidade 2.3 Características de Projeto de sistemas embarcados Quando se trata do desenvolvimento de sistemas embarcados é necessário levar em conta um conjunto de requisitos que difere em algumas características ao compará-lo com o desenvolvimento de sistemas de propósito geral. Primeiramente deve-se pensar na arquitetura que será utilizada, pois a mesma apresenta requisitos em termos de desempenho e consumo de potência. Além disso faz-se necessário levar em conta a tolerância a falhas (sistemas embarcados críticos), custo de produção, design e tempo de projeto [22]. Um dos principais fatores que tornam mais complexo o processo de desenvolvimento desses sistemas é a relação direta entre o desempenho da aplicação e o consumo de potência, 8

21 o que significa que processadores com maior desempenho tendem a consumir mais energia. Isso prejudica o funcionamento de sistemas que dependem de bateria como fonte de energia. Além disso o desempenho e o consumo de potência, bem como os componentes de hardware utilizados, impactam no custo de produção. Com um custo alto, o preço do sistema embarcado no mercado aumenta, podendo comprometer a aceitação do consumidor. Aceitação esta que também é influenciada pelo design do produto desenvolvido e pelo tempo de projeto, que deve ser o menor possível para ganhar a aceitação do mercado mais rapidamente. Em determinadas áreas, o requisito de tolerância a falhas é de extrema importância no desenvolvimento desses sistemas, principalmente os sistemas embarcados críticos, como sistemas aviônicos e de controle de usinas nucleares. 9

22 Capítulo 3 Desenvolvimento em Plataformas Heterogêneas 3. Características e Vantagens da utilização de MPSoC Em um ambiente heterogêneo o processo de desenvolvimento difere, em muitos aspectos, do processo em um ambiente homogêneo. Nas arquiteturas multiprocessadas heterogêneas é necessário utilizar um compilador específico para cada tipo de processador utilizado, o que quer dizer que o código que será compilado para um processador DSP (Digital Signal Processor) será diferente do código a ser compilado para um processador de arquitetura RISC (Reduced Instruction Set Computing). Assim, o processo de desenvolvimento se torna mais complexo, necessitando tratamentos diferenciados nas etapas de desenvolvimento. Algumas vantagens para utilização de MPSoC são apontadas por [23]. MPSoCs heterogêneos são mais eficientes no requisito de consumo de potência, principalmente por se utilizarem de diferentes conjuntos de instruções para diferentes processadores, tornando a execução de determinadas tarefas mais eficiente. Um exemplo típico é a utilização de processadores de sinais digitais DSP para aplicações multimídia, os quais tendem a consumir menos energia do que processadores de propósito geral neste tipo de tarefa [24]. Outra vantagem desse tipo de arquitetura está sobre o requisito de desempenho em tempo real. A utilização de arquiteturas multiprocessadas heterogêneas permitem reduzir conflitos de acesso e escrita em memória no processamento de informações, melhorando o desempenho quando comparado com as arquiteturas multiprocessadas homogêneas, que precisam resolver esses conflitos via software. Com relação ao desenvolvimento e prototipação de novas aplicações, plataformas para sistemas embarcados podem ser utilizadas com um custo relativamente baixo. A Tabela 3. mostra algumas plataformas de desenvolvimento e suas características: 0

23 Tabela 3. Exemplos de Plataformas e suas características Plataforma Processador(es) Desempenho Custo* BeagleBoard C4 MPSoC OMAP3530 Até 720 MHz $25 BeagleBoard-xM MPSoC DM3730 Até GHz $49 PandaBoard ES OMAP GHz $82 Snowball ARM Dual Cortex-A9, ARM GHz $265 Mali 400- DevKit 8000 OMAP MHz * Custo, em dólares, baseado no site da empresa Digi-Key Corporation [25]. $69** ** Custo, em dólares, baseado no site da empresa Embest Technology Co. [26]. Segundo [23], as situações onde é recomendado o uso de plataformas SoC (System-onChip) são aquelas que apresentam requisitos como consumo de energia reduzido, melhoria de desempenho e também no requisito de área ocupada, pois integram vários componentes (como processadores, memórias, interfaces de teste e de periféricos) dentro de um único chip, reduzindo o espaço ocupado. Na Figura 3. encontra-se o diagrama de blocos da plataforma MPSoC OMAP 3530 [27], que ilustra a série de componentes integrados. Pode-se visualizar na Figura 3. que o OMAP 3530 integra, no seu chip, uma série de componentes além do processador ARM Cortex-A8 (bloco azul, na figura), como o subsistema IVA 2.2, que contém o processador DSP (bloco amarelo, na figura). O OMAP também dispõe do acelerador gráfico POWERVR SGXTM (bloco verde) memórias internas On-chip 2 KB ROM e 64KB RAM (blocos vermelhos), controladores de memória, interfaces de periféricos (blocos marrons), entre outros componentes. Isso mostra a quantidade de componentes de diferentes propósitos integrados dentro de um único chip.

24 Figura 3. Diagrama de blocos funcionais do OMAP 3530 [27] 3.. Ferramentas No desenvolvimento de sistemas embarcados podem ser utilizadas algumas ferramentas que auxiliam o processo, provendo mais recursos ao programador. Como citado anteriormente, podem ser utilizados kits de desenvolvimento contendo processadores embarcados facilitando a validação do software. Em termos de hardware, os kits de desenvolvimento auxiliam no desenvolvimento de protótipos, permitindo a escolha de componentes a serem adicionados (de acordo com o suporte a interfaces e portas USB pelo kit), bem como auxiliando na avaliação de um sistema ou aplicação, com estatísticas do comportamento da execução. O uso de ambientes de desenvolvimento de software em desktop é mais adequado, quando comparado com o desenvolvimento de programas diretamente na placa. Por meio da utilização de cross-compilers, os ambientes de desenvolvimento em desktop aumenta a agilidade desse processo, pelo fato do maior desempenho das arquiteturas desktop. Além disso, esses ambientes de programação podem ser usados em conjunto com a placa de 2

25 desenvolvimento, permitindo maiores capacidades de depuração e solução de problemas de integração. Um exemplo de ferramenta desse tipo é o Code Composer Studio (CCS) [28], disponibilizado pela Texas Instruments Inc [29]. Esse ambiente de programação possui diversas funcionalidades que auxiliam o programador no desenvolvimento de sistemas embarcados: Explorador de Recursos: auxilia na criação de novos projetos e no gerenciamento destes, além de prover rápido acesso às tarefas comuns, como compilação e depuração, bem como utilização de exemplos de código. Integração com o sistema operacional de tempo real SYS/BIOS [30]. Esse sistema pode ser utilizado em uma ampla gama dos processadores DSP da Texas Instruments, microcontroladores e também processadores ARM. Disponibilidade de compiladores C/C++ para várias arquiteturas. É possível construir código para microcontroladores MSP430, para processadores ARM e para processadores DSP da família C5000 e C6000. Depuração de um ou mais processos na arquitetura alvo. Conectando a máquina host (PC) com a placa de desenvolvimento através de um cabo serial ou de rede TCP/IP, é possível realizar uma depuração de código na própria placa. Para terminar uma sessão de depuração, o CCS utiliza um emulador JTAG, permitindo a avaliação do estado do kernel e do processo. Análise de Sistema: provê ao programador estatísticas do desempenho e do comportamento da aplicação em execução. De modo geral, o CCS permite ao programador o monitoramento da utilização de CPU, visualizar carga de rede, grafo de execução, e outras funcionalidades de benchmarking. Depuração via Hardware: para processadores da Texas Instruments, cujas capacidades variam de acordo com o processador, por exemplo acesso não intrusivo a registradores e memória, execução síncrona com processadores Multicore, modo tempo real (permite suspender a execução de códigos sem interromper a execução de tarefas críticas). Analisador de Imagens: permite visualizar graficamente dados e variáveis e fornece a capacidade de analisar frames de vídeo e imagens no seu formato nativo. 3

26 Geração de código para periféricos: no caso dos microcontroladores MSP430, o CCS permite a geração de código C para gerenciar o uso de periféricos. C6EZFlo: essa ferramenta gráfica de desenvolvimento serve para a geração de código para uma ampla gama de processadores DSP a partir de um diagrama de blocos, provendo algoritmos de processamento otimizados e de E/S de periféricos. Esses tipos de ferramentas auxiliam ao programador no desenvolvimento de sistemas embarcados, à medida que há a possibilidade de maior auxílio nas etapas de construção e compilação de código, havendo o suporte da ferramenta com compiladores para diferentes modelos de processadores, além de exemplos (templates). Além disso, auxilia nas etapas de execução e depuração, provendo análises dos recursos por meio de simulação e agilizando na resolução de possíveis erros, através de depuração via hardware da arquitetura alvo. Porém, em alguns casos deve-se considerar o custo de aquisição de uma licença de um ambiente desse tipo. O CCS dispõe de uma licença gratuita para fins acadêmicos, mas uma versão mais completa pode chegar a custar $9, [28]. Somando-se a isso, a utilização dos kits de desenvolvimento auxiliam na prototipação de novos sistemas, permitindo analisar e testar o comportamento da execução da aplicação desenvolvida, aproximando-se da ideia do produto final. Assim, pode-se verificar de maneira mais realista a utilização dos recursos desejados, desde componentes USB, áudio, vídeo, telas sensíveis ao toque, captação de vídeo por câmera, entre outros. 3.2 Plataforma utilizada: BeagleBoard-xM Neste trabalho a placa de desenvolvimento utilizada é a BeagleBoard-xM [5], que utiliza uma arquitetura MPSoC DM3730, composta por dois processadores em um mesmo chip. Algumas características fazem a BeagleBoard-xM torna-se uma boa escolha como plataforma de desenvolvimento. Primeiramente, essa plataforma dispõe de uma arquitetura multiprocessada heterogênea, cujo processador de propósito geral (ARM Cortex-a8) é amplamente utilizado no mercado de embarcados [3]. O segundo processador é um DSP, que permite a execução otimizada de algoritmos de processamento de sinais digitais. Além disso essa plataforma possui interfaces e drivers de vídeo, USB e som, além das dimensões reduzidas (8.5x8.7 cm) e baixo consumo de potência. A BeagleBoard-xM possui 4

27 também uma interface nativa com suporte a câmeras de resolução VGA até 5 MP (Mega Pixel). Outro fator importante é o fato de que a BeagleBoard-xM pode ser adquirida com um custo relativamente baixo, a partir de US$ 49 em lojas dos Estados Unidos [32]. O resumo dos componentes dessa placa de desenvolvimento pode ser visualizado na Tabela 3.2. Tabela 3.2: Resumo dos componentes da placa de desenvolvimento BeagleBoard-xM [5] Plataforma de Desenvolvimento BeagleBoard-xM Processadores - GHz ARM Cortex-A8 (Arquitetura RISC) - TMS320C64x (800 MHz) (Arquitetura DSP) Memória - 52 MB DDR RAM Periféricos e conexões - HDMI/DVI - Porta de interface nativa para Câmera - S-video - HUB USB (4 portas) - Entrada e saída Stereo - Porta RS232 (serial) - Conector JTAG Armazenamento - Slot Cartão SD Na Figura 3.2 encontra-se uma foto da placa, na qual os componentes podem ser visualizados. Como citado anteriormente, a BeagleBoard-xM agrega dois processadores com propósito diferente na plataforma DM3730 [40]. Então, o conjunto de instruções entre eles é diferenciado, pois enquanto o ARM é voltado para propósito geral, possuindo uma arquitetura RISC de 40 registradores (33 de propósito geral e 7 de estado) [3], o DSP possui instruções otimizadas para processamento de imagens e vídeo, com a execução de até 8 instruções por ciclo de processamento e 64 registradores no total [27] [33]. 5

28 Figura 3.2: Foto da Placa BeagleBoard-xM, Revisão C. Extraído de [5]. Esta plataforma suporta diversas distribuições do sistema operacional Linux, como Ubuntu, Android, Debian e Angstrom. Isso torna o desenvolvimento mais flexível, pois várias aplicações e projetos em código aberto, ou livre para uso, estão disponíveis e são compatíveis com essas distribuições. Nesta plataforma, o sistema operacional pode residir em um cartão SD (Secure Digital) ou em um MMC (MultiMedia Card). Para o desenvolvimento de aplicações para a Beagleboard pode-se optar pela codificação, compilação e testes de aplicações diretamente na placa. No entanto, devido aos recursos escassos, uma solução mais adequada é a utilização de um ambiente de desenvolvimento desktop, através de uma IDE (Integrated Development Environment) de programação, com suporte aos cross-compilers para a arquitetura alvo em uso. No desenvolvimento dos módulos DSP é necessário utilizar um compilador específico, disponibilizado pela Texas Instruments, para gerar código compatível com o processador DSP. Esse compilador é gratuito e está disponível para os sistemas operacionais Linux e Windows. Após a compilação do código o mesmo deve ser copiado para o cartão SD. Em termos de desempenho, nessa plataforma há a possibilidade de se utilizar instruções especializadas para determinadas tarefas, tanto no processador ARM quanto no processador DSP, melhorando o desempenho. Para melhorar o desempenho de uma aplicação, pode-se utilizar o paralelismo no nível de threads, onde as tarefas são divididas entre os processadores, ou o paralelismo no nível de instruções, que provê a capacidade para um determinado processador executar várias instruções por ciclo. [36]. Entretanto, cabe ao programador conhecer detalhadamente o conjunto de instruções da arquitetura utilizada, bem 6

29 como arranjar o código de forma que seja possível aproveitar esse paralelismo, aumentando a complexidade do código Processador ARM Cortex-A8 A empresa britânica ARM Holdings [34] é a empresa responsável pelo desenvolvimento da arquitetura ARM (Advanced RISC Machine) e possui os direitos autorais sobre a mesma. Entretanto, ela não produz os processadores; apenas licencia os direitos (de implementação ou de uso da arquitetura compatível com o conjunto de instruções ARM) sobre a arquitetura para outras empresas que desejam produzi-los. De modo geral, os processadores ARM são destinados a dispositivos embarcados, e nos últimos anos são os líderes de venda no mercado. De acordo com um relatório da ARM Holdings, estima-se que mais de 25 bilhões de processadores ARM já foram criados e que, além disso, são despachados cerca de 6 milhões por dia [34]. O MPSoC DM3730 incorpora como processador de propósito geral (GPP General Purpose Processor) o ARM Cortex-A8. Esse processador é muito utilizado no mercado de sistemas embarcados, principalmente pelo fato de aliar bom desempenho a um relativo baixo consumo de potência. Na Tabela 3.3, encontram-se alguns dispositivos que utilizam esse tipo de processador [34]: Tabela 3.3: Dispositivos que utilizam processador ARM Nome do Dispositivo Família da Arquitetura Acer n300 ARM9 Amazon Kindle Wi-Fi ARM Air Hogs Hawk Eye ARM Cortex-A Comfile Technology Cuwin3200 ARM9 Dell Latitude e4200 Laptop ARM Cortex-M Dash Express Navigation ARM9 Baseado na arquitetura ARMv7 de 32 bits, o ARM Cortex-A8 consegue operar em uma frequência de relógio que varia entre 300MHz até GHz. Normalmente, os sistemas operacionais compatíveis com esse processador o mantém trabalhando a 300 MHz, mas podem aumentar a frequência de trabalho do mesmo sob demanda, caso uma aplicação necessitar maior poder de processamento. Dessa forma é possível diminuir o consumo de potência. 7

30 Um fato que contribui para a utilização deste processador nos sistemas embarcados é a possibilidade de se estender o conjunto de instruções da arquitetura ARMv7, utilizando-se de um coprocessador, no caso o NEONTM [35]. Os coprocessadores são processadores de propósito específico, com o objetivo de melhorar o desempenho para determinados grupos de instruções. Essa possibilidade de extensão do conjunto de instruções aumenta a flexibilidade da arquitetura para utilização em grande parte dos sistemas embarcados. Disponível para a série de processadores ARM Cortex-A, o coprocessador NEONTM é composto de uma extensão do conjunto de instruções SIMD (Single Instruction Multiple Data) de 28 bits, chamado de Advanced SIMD, e de uma extensão de suporte à operações em ponto flutuante de precisão simples. Dentre as funcionalidades do coprocessador NEONTM, temos: Instruções de processamento de valores em ponto flutuante de precisão simples; Estrutura SIMD de instruções Load/Store; Transferências entre o processador ARM e os registradores NEON da ordem de 8, 6, 32 e 64-bit. Dessa forma, apesar de ser tratado como um processador de propósito geral por ser o mais atuante em termos de desempenho, na plataforma DM 3730, bem como na OMAP 3530, esse processador acelera processamento de tarefas mais específicas, como o processamento de mídia [22] Processador DSP TMS320C64x+ Em muitos casos, a maioria das informações costuma ser representada por sinais, variações físicas que podem ser mensuradas, como luz e temperatura. Esses sinais são analógicos por natureza e possuem características de serem contínuos ao longo do tempo [36]. A partir do momento que passa a ser necessário ou conveniente tratar esses sinais analógicos computacionalmente, é necessário representá-los em um formato digital. Um sinal digital, nesse caso, nada mais é do que uma sequência discreta de estados que codifica uma mensagem. Um vídeo do padrão H.264, um arquivo de áudio mp3 e um pacote TCP/IP são alguns exemplos de sinais digitais. Assim, para tratar essa classe de processamento, surgiram os processadores de sinais digitais. Projetados para executar com eficiência algoritmos de processamento de sinais digitais, possuem uma arquitetura diferenciada, mas em geral esses processadores possuem vantagens 8

31 sobre os processadores de propósito geral [37,38]. Mesmo com recursos limitados, são capazes de realizar processamento de algoritmos com vantagens em relação ao consumo de energia, desempenho e também com relação ao custo da arquitetura. Na plataforma DM 3730, bem como na plataforma OMAP 3530 [27], o processador DSP é o TMS320C64x+ [39], fabricado pela Texas Instruments. Ele faz parte da família de processadores c64x que possuem um conjunto de instrução (ISA) compatível entre os processadores [4]. A família de processadores TMS320TM consiste em processadores DSP de ponto fixo, ponto flutuante e também de multiprocessadores DSP. A arquitetura desses processadores é designada para tarefas específicas de tempo real, e as áreas de aplicação dos processadores TMS320C6000 incluem [39]:. Redes: Estações base Wireless; Modems cabeados e sistemas DSL (Digital Subscriber Loop); Sistemas de telefonia multicanal; 2. Segurança personalizada: Reconhecimento de face, mão e impressão digital; 3. Áudio Reconhecimento de voz; 4. Processamento de Imagens Ultrassom, gráficos de realidade virtual 3-D 5. Outras: Navegação GPS (Global Positioning Systems) com prevenção de acidentes; Diagnósticos médicos remotos; Radares e modelagens atmosféricas; Indústria automotiva; 9

32 O desempenho desses processadores chega até 8000 MIPS (Million Instructions Per Second) [39], oferecendo diferentes abordagens para tratar problemas de processamento de sinais digitais, incluindo aplicações complexas que possam requerer dos benefícios de desempenho do paralelismo de instruções por ciclo de frequência. O processador TMS320C64x+ pode chegar a trabalhar a uma frequência de relógio de 800 MHz, com a capacidade de executar até oito instruções por ciclo. Sua CPU possui 64 registradores de propósito geral de 32 bits, com seis ULAs (Unidade Lógica e Aritmética) e duas unidades multiplicadoras, totalizando 8 unidades funcionais. As funcionalidades desse processador podem ser vistas na Tabela 3.4. Vale ressaltar que a utilização de paralelismo de instruções que o processador c64x+ proporciona aumenta a complexidade do código. Além disso é muito difícil conseguir paralelizar de maneira total um determinado código, utilizando-se de todas as unidades funcionais, pois isso dependerá do nível de dependência de dados que a aplicação exige. Tabela 3.4: Funcionalidades do processador DSP TMS320C64x+ e descrição Funcionalidade Descrição Empacotamento de Instrução Provê tamanho de código equivalente a 8 instruções, executadas em paralelo ou serial. Reduz o tamanho de código e também consumo de potência. Very Long Instruction Word VLIW CPU Executa até 8 instruções por ciclo. Execução condicional da maioria das instruções Aumenta o nível de paralelismo para manter maior performance. Modo de operação protegido Um sistema de dois níveis que provê execução de programas privilegiados, proteção de partes da memória. Suporte a exceções Para facilitar na detecção de erros e redirecionamento de execução. Operações 6 bit otimizadas Instruções adicionais para suporte a 8 adições/ multiplicações/subtrações de 6 bit por ciclo no máximo. 20

33 3.3 Portabilidade de aplicações Muitas aplicações embarcadas são desenvolvidas com base em aplicações desktop já existentes no mercado, ou seus projetos surgem adaptações para os SEs, com o intuito de se obter as vantagens da utilização dos SEs. Através do código-fonte da aplicação é possível portá-la para outras arquiteturas. Uma forma é se utilizar de um compilador compatível com a arquitetura de destino da aplicação, ou seja, a arquitetura sobre a qual a aplicação vai executar. É necessário que a linguagem possua um compilador para a arquitetura de destino, mas a vantagem está na possibilidade de reuso parcial ou total do código-fonte da aplicação. Além disso, é possível realizar otimizações no código portado, de acordo com a necessidade. Uma das formas de se fazer isso é utilizando otimizações realizadas pelo compilador, de acordo com o objetivo a ser alcançado. Com a utilização do GCC é possível realizar otimizações de desempenho e de tamanho de código gerado, que podem ser úteis tanto para sistemas desktop, quanto para SEs. Em [59], algumas opções e níveis de otimização para a versão do compilador GCC (Gnu Compiler Collection)[58]: Nível : especificando a flag -O na compilação, o código executável será construído tendo como objetivo redução de tamanho de código e aumento de desempenho. Nível 2: neste nível, com a flag -O2 o compilador realiza as mesmas otimizações do nível anterior, além de outras otimizações cujos objetivos não envolvem redução de tamanho de código e desempenho. Nível 3: Nível máximo de otimização, acrescenta otimizações ao Nível 2, colocando ênfase ao desempenho. Normalmente produz código com melhor desempenho, mas com impacto no tamanho do código. Para utilizar este nível, deve-se acrescentar a flag -O3 na compilação. De modo geral é mais viável portar uma aplicação existente e adaptá-la de acordo com os requisitos e necessidades do SE, do que recomeçar o desenvolvimento da mesma. Porém, este processo não é trivial, visto que os requisitos dos SEs a serem atendidos podem impactar no funcionamento normal da aplicação. Um exemplo disso é o padrão de vídeos H.264, que 2

34 possui perfis para melhor atender aos requisitos da arquitetura de destino. Assim, o perfil mais simplificado, destinado a sistemas com recursos computacionais limitados, economiza mais energia, mas possui um desempenho inferior, em termos de resolução e qualidade de imagem, comparado ao perfil mais robusto, destinado a decodificadores de alta definição de imagem Problemas de alinhamento de bytes em processadores ARM Apesar das vantagens que a portabilidade de aplicações podem proporcionar ao desenvolvimento de SEs, um problema de alinhamento de dados na memória pode ocorrer ao se portar uma aplicação para outras arquiteturas. Com base em [57], acessos à memória de forma não alinhada podem ser um problema, visto que processadores ARM mais antigos são mais limitados no acesso a dados, caso estes não estejam alinhados em limites de 4 bytes. Esses acessos não alinhados a memória podem gerar problemas em arquiteturas que são mais restritas no acesso aos dados, como as já mencionadas. Considerando a Figura 3.3, onde é mostrada uma estrutura contendo valores arbitrários, o dado pode ser lido de maneira diferente de acordo com a arquitetura utilizada, caso ela tenha restrições aos acessos desalinhados na memória. Na Figura 3.3, dentro de cada retângulo estão contidos valores numéricos em base hexadecimal. Estes valores são endereçados pelos seus índices, números decimais sobre os retângulos. Considerando que seja feita uma leitura de 32 bits (4 bytes) por um processador little endian, começando pelo índice e de forma contígua, o valor esperado seria o valor 0x0E0D0C0B ( em decimal). É desta forma pois o suposto processador realiza a leitura da direita para a esquerda, na Figura 3.3. Assim, o byte menos significativo é o do índice. Porém o dado efetivamente lido é o valor 0x0D0C0B0A ( em decimal), que é o valor que se encontra dentro dos limites de 32 bits. Isso porque a leitura foi alinhada a partir do índice 0, pois o suposto processador não suporta leituras desalinhadas, e assim o valor lido não será o valor que realmente se encontra a partir do índice especificado. De modo geral, as soluções para este problema se encontram ou na compilação ou em ações do próprio sistema operacional que executa a aplicação. O GCC, por exemplo, realiza adaptações no código de forma a evitar esses problemas. 22

35 Figura 3.3: Exemplo do problema de alinhamento de bytes. No momento em que o compilador identifica problemas de alinhamento, principalmente em estruturas de dados do tipo struct, ele insere padding bytes nas estruturas para que estas residam e estejam alinhadas dentro dos limites que a arquitetura requer. É possível visualizar este comportamento do compilador, no caso do GCC, através de algumas flags de compilação: -Wpadded: notifica quando bytes forem inseridos em uma estrutura, incluídos para alinhar elementos da estrutura ou mesmo para alinhar a estrutura como um todo. 23

36 -Wpacked: Quando a instrução attribute ((packed)) for utilizada para tentar reduzir o espaço em bytes ocupado por uma estrutura na memória, mas a instrução não conseguir o efeito desejado, essa notificação é mostrada. -Wcast-align: notifica quando um ponteiro para um tipo de dado (com um tamanho determinado em bytes), sofre uma conversão de tipo (type casting) para outro de tamanho superior ao primeiro. Por exemplo, considerando um ponteiro para o tipo char, que foi convertido para o tipo int, em uma determinada arquitetura. Se o acesso aos valores deste tipo nesta arquitetura for restrito ao alinhamento em limites de 2 ou 4 bytes, o GCC irá lançar essa notificação ao usuário. O sistema operacional também pode identificar e corrigir estes problemas. No caso do linux, as informações de quantos acessos não alinhados efetuados e a política de resposta a esses acessos podem ser visualizados e configurados no arquivo /proc/cpu/aligment. Neste arquivo, a primeira linha corresponde à quantidade de acessos não alinhados por um processo do usuário que foram detectados pelo sistema operacional. As linhas que se seguem dão informações sobre esses acessos e a última linha mostra a política de resposta do sistema operacional, quando este detectar um problema de alinhamento. Os tipos de resposta são : Ignorar o acesso não alinhado: quando o parâmetro da última linha do arquivo for 0 (zero), o acesso será ignorado, e a única forma de saber se houve um acesso desse tipo é monitorando a quantidade de acessos não alinhados. Notificar: quando o valor do parâmetro for, o sistema operacional irá notificar o usuário a cada acesso não alinhado, com informações referentes ao acesso, permitindo ao programador identificar os problemas de acessos não alinhados realizados pela aplicação, se for o caso. Corrigir: quando o valor do parâmetro for 2, o acesso será corrigido introduzindo bytes de alinhamento, da mesma forma que é realizada pelo compilador, reduzindo o desempenho da aplicação. Corrigir e Notificar: quando o valor do parâmetro for 3, o sistema operacional irá corrigir o acesso não alinhado (equivalente à opção 2 ) e notificará o usuário (equivalente à opção ). 24

37 Enviar Sinal: com valor do parâmetro igual a 4, o sistema irá enviar um sinal ao(s) processo(s), terminando-o(s). Enviar Sinal com Notificação: com valor do parâmetro igual a 5, o sistema irá enviar um sinal ao(s) processo(s), terminando-o(s) (equivalente ao tipo 4 ), mostrando informações relativas ao acesso não alinhado (equivalente ao tipo ). As consequências dos acessos desse tipo podem ser: dados corrompidos, falhas de segmentação, ou redução de desempenho. Normalmente, o que ocorre é apenas uma redução de desempenho da aplicação, por consequência da necessidade de uma maior quantidade de acessos para obter o dado correto. Entretanto, nos casos em que o comportamento da aplicação portada for diferente do esperado, será necessário a reescrita de partes código, focando nos tamanhos das estruturas utilizadas (struct e estruturas derivadas). 3.4 Análise do desempenho do H.264 na BeagleBoard-xM Uma análise de desempenho e consumo de potência na BeagleBoard-xM, com a execução do decodificador H.264 foi realizada, avaliando as particularidades desse processo com a utilização do processador ARM e do DSP. A motivação para se avaliar o processo da decodificação de vídeos H.264 se dá pela popularidade desse padrão. O fato de que esse padrão tem a capacidade de obter a mesma qualidade de imagem com aproximadamente a metade da taxa de bits utilizada pelo seu antecessor (padrão MPEG-2) [42], e sua gama de aplicações que varia desde dispositivos portáteis até decodificadores de alta definição, justificam a popularidade do H O padrão de vídeos H.264 Desenvolvido a partir dos padrões MPEG-2 e MPEG-4, o padrão H.264 teve seu surgimento em 2003 e é composto de um codificador e de um decodificador. O codificador tem a função de compactar o vídeo digital, economizando espaço de armazenamento e exigindo assim uma menor largura de banda para transmissão. Já o decodificador realiza o processo inverso, ele extrai as informações de um vídeo comprimido, recriando a sequência de imagens para serem exibidas na tela de um computador, por exemplo. 25

38 Pelo fato do H.264 ser dividido em perfis de aplicação, ele tem maior flexibilidade para execução em diversos dispositivos, de acordo com os requisitos destes. Esses perfis são descritos a seguir [42] : Perfil Baseline: criado com o foco em dispositivos com recursos limitados. Não suporta a codificação CABAC (Context-Adaptive Binary Arithmetic Coding) nem partições de quadro do tipo B. Perfil Main: destinado a consumidores finais de eletrônicos, servidores de vídeo e broadcast. Suporta vídeos da resolução QCIF (76x44) até Full HD (920x080). Perfil Extended: criado para aplicações de streaming de vídeo, ele possui ferramentas para facilitar a troca entre diferentes bit streams. Perfil High: Incluído posteriormente aos perfis anteriores, possui codificação com mais eficiência e praticamente substituiu o perfil Main. O Sistema Brasileiro de Televisão Digital SBTVD [8] utiliza este perfil nas suas especificações de compressão de vídeo digital. No H.264 a decodificação é composta de etapas, cada qual com uma função específica sobre a stream de entrada, ou seja, o vídeo compactado. São elas: descompressão (entropy decoder), reordenação, quantização inversa (Q-), transformada inversa (T-), compensação de movimentos (MC), predição Intra e Filtragem [43]. O diagrama das etapas do decodificador H.264 e suas etapas podem ser vistas na Figura 3.4. Figura 3.4: Etapas do processo da decodificação de vídeos H.264 [43] 26

39 Na primeira etapa os bits comprimidos são obtidos da stream de entrada, oriundos de meios como cabo, ar ou internet e encapsulados em pacotes de dados via NAL (Network Abstraction Layer). A segunda etapa produz os elementos de sintaxe através desses bits, cuja codificação pode ser do tipo CAVLC (Context-Adaptive Variable-Length Coding) ou CABAC (ContextAdaptive Binary Aritmetic Coding). Essa etapa é denominada por Decodificação de Entropia, ou Entropy Decoding. Após esta etapa, vem a etapa da reordenação, que se faz necessária pois o H.264 permite o envio dos dados do vídeo desordenados. Então, as etapas denominadas Quantização Inversa (Q-) e Transformada Inversa (T-) são realizadas com o intuito de recuperar os coeficientes truncados durante a codificação e passá-los para o domínio espacial, respectivamente. O H.264 possui dois tipos de predição, a predição Intra e Inter. Na predição Intra, que é um processo de predição espacial, significa que atua apenas em um mesmo quadro. Essa etapa tem a função de reduzir as redundâncias de dados em um bloco, a partir de informações de blocos vizinhos a ele. O outro tipo de predição é denominado Compensação de Movimentos (CM). Com o intuito de detectar semelhanças entre quadros próximos e reduzir essas redundâncias entre os mesmos, a CM torna a decodificação de cenas com características semelhantes (como o fundo da imagem) mais eficiente, utilizando para isso quadros de referência. Os principais tipos de quadros são: I, P, e B. O tipo do quadro define a predição utilizada, sendo que o tipo I é um frame que usa predição Intra, e a sua decodificação é independente dos demais. O tipo P usa predição Intra e Inter, sendo que sua decodificação depende de um ou mais frames anteriores, e o tipo B utiliza predição Intra e a sua predição Inter depende de frames anteriores a ele ou posteriores a ele [44]. A última etapa é denominada Filtragem, com a função de suavizar as bordas entre os blocos vizinhos de um quadro. Essa filtragem é executada de maneira In-loop, e tende a melhorar a qualidade da imagem. Além disso, podem ser utilizados filtros de pósprocessamento, que são opcionais [45]. Os processos da codificação e posterior decodificação, para que o vídeo seja visualizado, possuem custo computacional considerável, principalmente se tratando de vídeos de alta 27

40 definição. Além disso, para dispositivos dependentes de bateria, é necessário realizar um balanço entre os requisitos de desempenho e de gasto de potência Resultados Obtidos na análise Como citado anteriormente, os MPSoCs heterogêneos tem se apresentado como uma boa solução para melhoria de desempenho, considerando requisitos relevantes dos sistemas embarcados, em aplicações desse tipo. Utilizando-se da placa BeagleBoard-xM, foi analisada a decodificação de um vídeo no padrão H.264 perfil Baseline, perfil compatível com os recursos de processamento limitados da placa. O vídeo possui resolução de 854x480 pixels contendo 2000 quadros. Para os experimentos realizados nesse trabalho foi utilizado o Gstreamer [46], na decodificação de vídeo para arquitetura ARM. Para a arquitetura DSP, da mesma forma, mas com a utilização do gst-dsp [47], que utiliza do codec disponibilizado pela Texas Instruments. A análise da utilização de CPU foi realizada para avaliar o desempenho da aplicação nesta arquitetura. Em um primeiro momento foi feita a avaliação da decodificação utilizando apenas o processador ARM e, em um segundo momento, avaliou-se com a utilização em conjunto com o processador DSP. A partir de dados do percentual de utilização da CPU, coletados com o auxílio do aplicativo Vmstat, foi feita a análise em termos de desempenho. Esses dados coletados são compostos por: Percentual de tempo gasto na execução de códigos que não fazem parte do kernel, chamado de user time, ou apenas us; Percentual de tempo gasto na execução de componentes do kernel, chamado de system time, ou sy; Percentual de tempo de ociosidade da CPU. Pode incluir tempo de espera em operações de E/S, se houver, chamado de idle time, ou apenas id. Na decodificação do vídeo H.264 no processador ARM, constatou-se que a utilização da CPU foi total nesse processo, ou seja, 00%. Apesar de estar operando em 800MHz, houve perdas de frames na decodificação do vídeo, fato que pode ser explicado pelo atraso na 28

41 renderização dos quadros na tela, e também pela disputa de outros processos pela CPU, como o servidor gráfico X do Linux. Com relação à decodificação com o uso do DSP, a carga de processamento no ARM diminuiu, com percentual de utilização neste último de 83%, em média (%us + %sy). Não foram constatadas perdas de frames durante a decodificação, e vale ressaltar que a utilização do processador se manteve alta devido a execução de outros componentes relacionados à decodificação, como a leitura de dados e a demultiplexação do arquivo de entrada, conversão do espaço de cores para a apresentação da imagem e também renderização desta, efetuada pelo ARM. Os percentuais de utilização do processador ARM podem ser visualizados na Figura 3.5: Figura 3.5: Gráfico da utilização do processador ARM, na decodificação H.264 efetuada pelo DSP. Estes dados revelam uma vantagem de se utilizar o processador DSP, neste caso diminuindo a carga no processador ARM, deixando-o com um percentual de tempo ocioso e também pela melhoria no desempenho. Em média, a carga no processador DSP foi de 77,5%, durante a decodificação do vídeo. Para a avaliação do consumo de potência, durante a decodificação, foi utilizada a ferramenta I2c-tools para fazer a leitura de dados, via software, da tensão em um subsistema de Monitoramento ADC (Analog-to-Digital Converter) da plataforma. Este subsistema faz 29

42 parte do dispositivo TPS65950 OMAP [48], que permite o controle e gerenciamento de energia da plataforma. Primeiramente, com a a utilização da ferramenta I2c, foi necessário iniciar e configurar o subsistema MADC [48]. Foi especificado a partir de quais componentes ADC seriam feitas as leituras, que correspondem ao ADCIN3 e ADCIN5, de acordo com o esquemático do circuito da plataforma, na Figura 3.6. Figura 3.6: Esquemático do circuito de medição de consumo de potência da BeagleBoard-xM [48]. O ADCIN5 corresponde à tensão de entrada no DM3730 e o ADCIN3 a tensão de saída. Os valores dos ADCs lidos em conjunto com o resistor R3 (ver Figura 3.6), de 0, ohms, são usados para calcular a perda de tensão sobre R3. Como a resistência R3 é de 0. ohms, para cada 00 ma consumido, uma redução de 0,0 V entre o ADCIN3 e ADCIN5 é detectada. A alimentação do circuito é de 4.2V dado pelo pino 4 do CI TL963A, mas com o uso dos resistores R48 e R52 de 2K e 0K Ohms respectivamente, a tensão efetiva da alimentação é de 46% do valor de entrada. Isso equivale a uma tensão de aproximadamente 2V que é efetivamente a tensão utilizada pelo DM3730. Desconsiderando recursos integrados na placa, como HUB USB com teclado e mouse conectados, foi possível realizar uma estimativa do consumo de potência durante a 30

43 decodificação do vídeo, pelo processador ARM e também com o DSP. Com a Equação 3., que traz o valor da potência (P) consumida na placa, através do cálculo da corrente elétrica sobre R3, multiplicado pela voltagem do circuito, correspondente ao valor de ADCIN5. P= ADCIN5 ( ADCIN5 ADCIN3)/ R3 (3.) Na decodificação utilizando-se do processador ARM, com sucessivas leituras a cada 0,5 segundo, a potência média estimada foi de aproximadamente 2,48W. Com a utilização do processador DSP constatou-se que a potência média estimada aumentou cerca de 6,4%, chegando em aproximadamente 2,65W. Esse aumento é relativamente pequeno, em comparação com o ganho de desempenho na utilização do DSP, deixando o processador ARM ocioso em um percentual de tempo (6%), liberando-o para realização de outras tarefas. Além disso, com o uso exclusivo do processador ARM não foi possível decodificar o vídeo sem perdas de quadros. 3

44 Capítulo 4 Estudo de Caso 4. Contextualização: VANTs De modo geral, um Veículo Aéreo Não Tripulado (VANT) é um tipo de sistema embarcado que consiste em uma aeronave que é capaz de realizar diversos tipos de missões, mas que não precisa de uma tripulação para voar. [6]. As principais atividades ou áreas de aplicação dos VANTs, de modo geral, são [49]: Monitoramento agrícola e ambiental; Segurança e setor militar; Defesa Civil; Investigações de fenômenos atmosféricos; Comunicações Apesar de terem áreas variadas, as aplicações de caráter militar ainda são as mais presentes no contexto dos VANTs. A principal vantagem proporcionada por um VANT é a possibilidade da substituição da presença física humana em áreas de potenciais riscos à vida. Assim, normalmente, os VANTs são projetados para realizar tarefas perigosas e repetitivas, nessas áreas de risco. Além disso, os VANTs são considerados como sistemas embarcados críticos, pois caso ocorram falhas nesses sistemas, as consequências podem ser trágicas e perigosas. Considerando um VANT sobrevoando uma área habitada ou inflamável, os riscos de uma falha pode ocasionar uma queda ou colisão, podendo afetar vidas humanas. Um relato de uma colisão entre um VANT e uma aeronave militar, no espaço aéreo do Afeganistão, resultando em um pouso de emergência por parte da aeronave, pode ser visualizado em [50]. 32

45 O INCT-SEC (Instituto Nacional de Ciência e Tecnologia em Sistemas Embarcados Críticos), criado pelo Ministério de Ciência e Tecnologia em parceria com o CNPq (Conselho Nacional de Desenvolvimento Científico e Tecnológico), entre outras instituições, desenvolveram o VANT Tiriba, cujas aplicações se encontram nas áreas de monitoramento ambiental, agrícola e de defesa civil. Ele conta com câmeras fotográficas de alta definição, sensores, câmaras termais e de vídeo nesta tarefa [5]. Na Figura 4. pode ser visualizada a foto do Tiriba. Figura 4.: Foto da decolagem do Tiriba [5]. Internamente, o modo de funcionamento de um VANT se divide em módulos para a realização de determinadas tarefas, para que o voo não tripulado seja possível. Na Figura 4.2 pode ser visualizado o diagrama de blocos do Tiriba, contendo os seus módulos ou unidades de processamento. Figura 4.2: Diagrama de blocos do Tiriba [5]. A descrição das principais unidades do VANT encontra-se a seguir [5]: Unidade de pressão (ou barométrica): é a unidade responsável pelo monitoramento das velocidades vertical, horizontal e também da altitude do avião. Unidade inercial: esse subsistema tem a função de determinar a orientação (posicionamento no espaço) da aeronave. 33

46 Unidade de navegação: realiza o controle, o gerenciamento da missão e principalmente a navegação da aeronave, de acordo com a rota que o avião deve sobrevoar. Unidade de controle: basicamente é responsável pelo controle dos atuadores da aeronave, permitindo o voo da mesma. Para isso, essa unidade recebe os comandos e informações de direção por parte da unidade de navegação. Entretanto, a fase de projeto de um sistema como o Tiriba é complexa, sendo necessário a consideração de alguns aspectos além dos requisitos dos sistemas embarcados em geral. Como se trata de uma aeronave de pequeno porte, a arquitetura utilizada para o processamento das unidades tem impacto no peso da aeronave, fator que determina se a aeronave será capaz ou não de voar. O consumo de energia pela arquitetura utilizada é um fator que também interfere nesse aspecto, pois deve ser utilizada uma bateria para suprimento de energia para as unidades de processamento. Assim, se o consumo for alto, a capacidade da bateria deverá ser maior, e consequentemente as suas dimensões serão maiores. Por outro lado, o sistema deverá ser capaz de processar as informações das unidades corretamente, com requisito de tempo real, para que a aeronave possa ter o controle sobre a dinâmica do seu voo. Assim, é importante que durante essa fase de projeto sejam feitas essas considerações. Outro fator relevante é o custo do sistema final para saber se ele será viável ou não. Dessa forma, a utilização de recursos para simular o funcionamento de sistemas desse tipo tendem a auxiliar no processo do desenvolvimento de protótipos desses sistemas. 4.2 ArduPilotMega: Plataforma Arduino para VANTs Atualmente está disponível no mercado um kit denominado ArduPilotMega (APM) [52], para ser embarcado em um aeromodelo para voo autônomo da mesma, incluindo não somente aeromodelos tradicionais, mas também multicópteros (quadricópteros, hexacópteros e octocópteros, com 4, 6 e 8 hélices respectivamente). Basicamente, esse kit é composto de duas placas, uma é o controlador Arduino Compatible ATMega2560 (na Figura 4.3), e a segunda é a placa Ardupilot Mega IMU Shield (na Figura 4.4). 34

47 Figura 4.3: Foto da placa controladora ATMega2560 [52]. Figura 4.4: Foto da placa IMU Shield [52]. O kit APM está disponível na DIY Drones Store, por $250 (GPS incluso) [53]. As respectivas características das placas, estão descritas a seguir: ATMega2560: baseada no processador Atmega de 6 MHz, com dois processadores com performance de 32 MIPS, é a placa controladora designada para utilização com aeronaves autônomas. Suporta waypoints 3-D, possui um mecanismo de controle de falha de hardware, usando circuito separado, com a capacidade de reiniciar o processador principal (ATMega328) durante o voo. Essa placa pode ser alimentada tanto por bateria ou através do receptor RC. 35

48 IMU Shield: Essa placa provê uma série de sensores necessários para a navegação autônoma da aeronave. Inclui sensores de pressão e temperatura, acelerômetro de 3 eixos, reguladores de voltagem, suporte a um módulo GPS (Global Positioning System) e sensor de velocidade do ar. Dessa forma, de acordo com [53,54], conectando essas placas, juntamente com um módulo GPS incorporado à elas, é possível dar autonomia de voo a um aeromodelo ou a um multicóptero. Entretanto, é necessário que os códigos-fonte dos algoritmos de controle sejam compilados e carregados na ATMega2560. Além disso, pode-se perceber que a capacidade de processamento desta placa é reduzida, principalmente com o intuito de economizar energia. 4.3 ArduPlane Software In The Loop (SITL) O ArduPlane é um software de código aberto de controle de autonomia de voo para pequenas aeronaves [2]. Ele permite que, através da sua compilação SITL, seja realizada uma simulação de um voo autônomo sem se utilizar do hardware físico. A compilação SITL realiza a simulação do hardware que seria utilizado em um VANT real no nível de registradores, e assim o funcionamento dos drivers dos componentes físicos normalmente usados em um voo real ocorrerá de forma semelhante na simulação. O Arduplane se utiliza da biblioteca JSBSim [55], cuja função é de fornecer um modelo para a dinâmica de voo e permitindo a simulação de uma aeronave em operação. Através de diferentes modelos de componentes físicos, essa biblioteca, escrita em código C++, permite coletar dados de altitude, velocidade, coordenadas (latitude e longitude) iniciais e direção da aeronave que está sendo simulada. Opcionalmente, dados como direção e velocidade do vento podem ser adicionados. A simulação SITL, apesar de não executar sobre o processador real, sobrepõe algumas limitações das simulações Hardware In The Loop (HITL), que são: a impossibilidade de se utilizar de recursos como depuração de código e verificações de memória. A organização geral dos componentes e a integração entre eles em um ambiente de simulação ArduPlane-SITL pode ser visto na Figura 4.5: 36

49 Figura 4.5: Esquemático da Arquitetura do ArduPlane-SITL [2]. Para visualização da aeronave e da simulação do voo, pode ser usado o software FlightGear, que recebe as informações do voo emulando uma conexão serial sobre o protocolo UDP do núcleo do JSBSim. Para as trocas de mensagens, como por exemplo na inserção dos pontos (waypoints) da trajetória a ser percorrida pela aeronave, é utilizado o protocolo MAVLink [55]. Além disso, podem ser repassadas as informações da telemetria através do protocolo MAVLink para outros sistemas, como o APM Planner [56], que possui a vantagem de permitir a visualização do voo sobre o globo terrestre a partir das coordenadas do voo recebidas, bem como informações de estado, como altura, dados do acelerômetro, trajetória da rota percorrida, e até mesmo enviar comandos ao ArduPlane. Na Figura 4.6 pode ser visualizado um screenshot do APM Planner recebendo os dados relacionados ao voo simulado, através da execução do ArduPlane, neste caso em uma arquitetura x86. 37

50 Figura 4.6: Screenshot da simulação de um voo através do APM Planner para visualização do voo. Dados como velocidade, altitude das coordenadas do voo simulado são úteis para entender o comportamento do aeromodelo em operação. Esses dados da telemetria são repassados ao APM Planner através de uma conexão TCP com o ArduPlane, pela porta Além disso, pode ser usado o APM Planner no planejamento de rotas para a simulação de um voo, onde os waypoints gerados podem ser carregados no ArduPlane. Na Figura 4.7 essa funcionalidade pode ser visualizada. Assim, a partir da conexão entre o APM Planner e o ArduPlane, é possível visualizar simulações verificando a rota que o VANT percorre com relação ao planejamento do voo, em tempo real. 38

51 Figura 4.7: APM Planner utilizado para criação de uma rota para um voo simulado. 4.4 Avaliação do SITL-ArduPlane na BeagleBoard-xM A compilação SITL do software ArduPlane, com a intenção de simular um voo autônomo de um VANT foi avaliada nos seguintes termos: Funcionamento: avaliou-se o comportamento da simulação do ArduPlane adaptada para a placa BeagleBoard-xM. Desempenho: avaliou-se o desempenho da execução do ArduPlane na BeagleBoardxM; Potência: foi avaliado o consumo de potência por parte do DM3730, na execução do ArduPlane na mesma placa de desenvolvimento; Porém é necessário que o código do ArduPlane seja compilado para a placa BeagleBoardxM, modificando os parâmetros no código do SITL para que a comunicação entre o ArduPlane (executado na placa) e os demais componentes da estrutura, como o simulador físico (JSBSim), telemetria e o APM Planner, executados no host PC, seja realizada através da interface de rede escolhida. 39

52 A Figura 4.8 mostra o esquemático do ambiente de simulação utilizado para realizar as avaliações. A estrutura para execução em um ambiente desktop (Figura 4.5) foi modificada e adaptada para permitir a execução do ArduPlane na BeagleBoard-xM. No entanto foi utilizado um ambiente desktop, que atua como uma Estação Base da simulação, pois os comandos para o ArduPlane são dados pela estação. Figura 4.8: Esquemático da organização do ambiente de simulação Os componentes executados na Estação Base que se comunicam com o ArduPlane na BeagleBoard-xM são: JSBSim: fornece um modelo para a dinâmica de voo, permitindo a simulação do modelo físico de um VANT. Envia pacotes com informações de estado da aeronave ao ArduPlane através da porta UDP 550, e recebe valores relacionados aos atuadores simulados através da porta UDP MAVProxy [60]: é a GCS (Ground Control Station) propriamente dita, permite o envio de comandos e recebimento de dados para VANTs em geral. Utiliza o protocolo MAVLink para o envio dos pacotes. Se conecta com o ArduPlane através da porta TCP 5760, para as informações da telemetria, e envia os comandos relacionados ao voo pela porta UDP

53 APM Planner: possui diversas funcionalidades, desde permitir a visualização do voo simulado sobre o globo, como permitir uma conexão com o ArduPlane através da porta TCP Esta conexão permite que o APM Planner envie comandos (e receba dados do voo) ao VANT simulado. As conexões entre os componentes executados na Estação e na BeagleBoard-xM podem ser emuladas sobre um cabo USB OTG, que fornece energia e permite uma conexão IP com a BeagleBoard-xM. A distribuição Linux Ubuntu foi utilizada tanto na BeagleBoard-xM, quanto na Estação Base. Neste contexto, uma simulação completa de uma missão, a partir do executável Arduplane.elf (bloco vermelho, na Figura 4.8), tem o início no momento em que a conexão entre o ArduPlane e os componentes da Estação Base for completada. O fluxo de execução de uma simulação completa de uma missão pode ser visualizado na Figura 4.9. Figura 4.9: Esquemático do fluxo de execução de uma simulação completa Primeiramente, o ArduPlane espera por uma conexão com uma Estação Base. Após a inicialização dos componentes lógicos (calibrar atuadores, definir altitude inicial do VANT, entre outros), é possível enviar comandos de entrada ao ArduPlane através do MAVProxy ou através de outra GCS. É necessário em seguida repassar uma missão ao ArduPlane, com waypoints e seus respectivos comandos associados. Assim, através do comando 'auto' do MAVProxy, a simulação do voo é iniciada. 4

54 4.4. Avaliação do Funcionamento A avaliação do funcionamento do ArduPlane na BeagleBoard-xM foi realizada com o intuito de validar o uso do ambiente de simulação adaptado para a execução do ArduPlane na placa. Nesta avaliação foram utilizadas três missões de teste (missao_.txt, missao_2.txt e missao_3.txt, cuja lista de waypoints se encontra no Apêndice A) para o plano de voo do VANT simulado. As missões possuem quantidade de waypoints variável, e foram elaboradas através do APM Planner. As missões 2 e 3, juntamente com a missão, foram utilizadas na avaliação do funcionamento do ArduPlane na placa, e as duas missões podem ser vistas na Figura 4.0, onde a missão 2 se refere à Figura 4.0 a) e a missão 3 à Figura 4.0 b). A missão foi escolhida para as análises de desempenho e consumo de potência, cujo plano de voo pode ser visualizado na Figura 4.. Na Figura 4., o waypoint Home é a posição inicial do VANT, cujas coordenadas geográficas, para a missão (em amarelo) são: latitude -24, ; longitude: -53, A altitude inicial foi especificada em 756 metros, com relação ao nível do mar. Figura 4.0: Planos de voo das missões 2 e 3, utilizadas na análise do funcionamento do ArduPlane 42

55 Figura 4.: Plano de voo utilizado para as avaliações de desempenho e potência do ArduPlane A altitude e a direção (heading) são repassadas ao ArduPlane através do JSBSim, durante a inicialização da simulação. Ainda na inicialização, opcionalmente pode ser repassado também através do JSBSim parâmetros relacionados ao vento, para tornar a simulação mais realista. Esses parâmetros são divididos em velocidade, direção e nível de turbulência. Neste caso os valores 5 m/s, 80 graus e 0.2 de turbulência foram definidos para a missão. A velocidade média do VANT também é especificada na inicialização, porém ela varia durante a simulação. O tempo médio de inicialização, avaliando-se 3 simulações da missão, foi de segundos. A partir disso, a missão pode ser carregada, e então a simulação do voo pode ser iniciada, normalmente, através de um comando auto, enviado pelo console do MAVProxy. A partir disso, o ArduPlane realiza os cálculos para buscar uma trajetória até o próximo waypoint, um a um, até cumprir a missão repassada a ele. Na Figura 4.2, pode ser visualizada a trajetória percorrida pelo VANT simulado. Pode-se perceber que a rota percorrida (linha em azul) não corresponde exatamente ao planejamento (linhas amarelas), devido aos cálculos aproximados realizados pelo ArduPlane. Porém esse comportamento também é verificado em simulações do ArduPlane-SITL padrão para desktop. 43

56 Figura 4.2: Visualização da rota percorrida pelo VANT na simulação da missão Ao alcançar o waypoint 3 (Figura 4.2), o avião entra em modo RTL (Return to Launch), que significa que o mesmo irá retornar ao ponto de origem, ou seja, o waypoint Home. O tempo médio entre as 3 simulações avaliadas para cumprir a missão, desde a decolagem até o VANT entrar em modo RTL, foi de 230 segundos aproximadamente. As simulações das missões 2 e 3 foram executadas com o intuito de validar o comportamento do VANT simulado, ou seja, se a rota percorrida com relação ao plano de voo foi satisfatória. A Tabela 4. traz informações sobre a execução de 3 simulações para cada uma das 3 missões utilizadas neste estudo. A Tabela 4. mostra informações de 3 simulações para cada uma das 3 missões de teste, em relação aos waypoints do planejamento da missão e também o tempo aproximado de duração do voo. Nas simulações da missão, todos os waypoints foram percorridos pelo VANT e então o mesmo passou a atuar no modo RTL (Return to Launch), dirigindo-se para o ponto inicial (waypoint Home ) da simulação. 44

57 Tabela 4.: Informações sobre o comportamento dos voos simulados das missões de teste Wayponts percorridos Simulações Missão Simulações Missão 2 Simulações Missão 3 Home OK OK OK Home OK OK OK Home OK OK OK 2 OK OK OK 2 OK OK OK 2 OK OK OK 3 OK OK OK 3 OK Perdeu Perdeu 3 Perdeu OK Perdeu OK OK OK 4 OK OK OK RTL OK OK OK RTL OK OK OK RTL OK OK OK Tempo de voo Simulações Missão Tempo: 237s 246s 207s Simulações Missão 2 Tempo: 93s 75s 59s Simulações Missão 3 Tempo: 74s 72s 89s Entretanto, nas simulações das missões 2 e 3, constatou-se que o waypoint 3 não foi percorrido corretamente pelo VANT, em duas das três simulações avaliadas. A verificação de que houve perda de um waypoint ocorre quando o VANT circundar o waypoint de destino em mais de 300 graus. A partir disso, o VANT desiste deste waypoint e segue para o próximo. No trecho do código-fonte do ArduPlane, localizado na Figura 4.3, é possível visualizar esta verificação, realizada através da variável loiter_sum. Porém esse comportamento avaliado nas missões 2 e 3 não afetou o restante da simulação, pois os waypoints seguintes foram percorridos corretamente. Figura 4.3: Trecho do código-fonte do ArduPlane Já com relação ao tempo de voo, o mesmo foi variável entre as simulações de todas as missões avaliadas. O tempo foi medido a partir do envio do comando 'auto' do MAVProxy 45

58 para o ArduPlane, porém a decolagem não é imediata e esse atraso de tempo foi considerado na avaliação, fato que contribuiu para variar o tempo de voo simulado Avaliação do Desempenho De maneira semelhante à análise de desempenho do H.264 na BeagleBoard-xM (Seção 3.3.2), avaliou-se o desempenho do ArduPlane em execução na mesma placa de desenvolvimento. O desempenho foi analisado em termos de utilização de CPU, neste caso o processador ARM da placa. Novamente, o aplicativo Vmstat foi utilizado para a análise de utilização de CPU. A análise de desempenho foi dividida em duas partes: a análise da inicialização do ArduPlane e a da missão propriemente dita (voo simulado). Esta análise foi comparada com uma outra compilação do ArduPlane, na qual foi utilizada uma flag de otimização do GCC (flag O3). Foram realizados três testes para as duas partes de cada análise, para se obter uma média do desempenho. Na parte da simulação do voo, a missão (missao_.txt) foi utilizada. A Figura 4.4 mostra o gráfico da média de utilização de CPU, onde pode-se comparar a análise do desempenho do ArduPlane compilado de forma padrão com a análise do ArduPlane otimizado. A versão do GCC utilizada nas compilações foi a versão 4.6., para a arquitetura destino arm-linux-gnueabi para a família de arquiteturas armv7. Na avaliação constatou-se que houve um pequeno ganho de desempenho por parte da compilação otimizada, 3,84% na inicialização e 0,585% durante a execução da missão. Figura 4.4: Gráfico da utilização do processador ARM, na execução do ArduPlane na BeagleBoard-xM 46