Figura 5.31: Configuração dos níveis de desempenho com perfil de menor consumo de energia: 4 níveis de desempenho com tempo de execução de 30, 15, 5 e 0 minutos,
respectivamente.
5.6
Análise Conclusiva
O trabalho “Suporte ao Projeto de Arquiteturas Harvesting-Aware para Aplicações em FPGA” tem por objetivo reduzir a complexidade de projetos harvesting-aware através da definição e da geração do código sintetizável de arquiteturas harvesting-aware para sistemas computacionais, implementados em FPGA, com a tecnologia de energy harvesting a partir de energia solar. Dessa forma, o objetivo da Arquitetura gerada pela Ferramenta HA-App é tornar harvesting-awareas aplicações implementadas em FPGA.
Para atingir esse objetivo, a estratégia foi definir uma arquitetura capaz de alterar o padrão de dissipação de potência dinâmica em tempo de execução alterando a frequência de clock do sistema. Mudar o padrão de dissipação em função da predição de energia para o próximo intervalo de tempo, por sua vez, tornou o sistema capaz de se adaptar à variação da disponibilidade de energia total para sua execução.
A partir dos resultados apresentados na Figura 5.30, podemos observar que nas configu- rações 3 a 10 do conjunto painel/bateria, o Sistema Harvesting-Aware (Cenário B) manteve-se em execução sem sofrer shut down por falta de energia, e considerou o perfil de desempenho de maior consumo de energia. No entanto, para as configurações 3 a 8, o sistema formado apenas pelo Conversor RGB-YCrCb (Cenário A) ficou inoperante entre 2 e 5 horas. Mesmo nos cenários 1 e 3 onde o Sistema Harvesting-Aware sofreu shut down por falta de energia, a sua eficiência ainda foi melhor do que o Conversor sem controle da Arquitetura. Nesses cenários 1 e 3, o Sistema Harvesting-Aware sofreu shut down 19 horas após o Conversor. Além disso, permaneceu inoperante por 11,5 horas, enquanto o Conversor pemaneceu desligado por um tempo total de 23,5 horas.
5.6. ANÁLISE CONCLUSIVA 93 Como efeito secundário, podemos concluir que sob a perspectiva da configuração do sistema em termos de potência do painel e capacidade da bateria, a Arquitetura consegue tornar harvesting-awarea aplicação do estudo de caso se uma bateria com capacidade a partir de 4Wh for utilizada na configuração de desempenho de maior consumo de energia, enquanto uma bateria de 3Wh já seria suficiente para o perfil de desempenho com menor consumo de energia, vide Figura 5.32. Em termos de capacidade do painel solar, podemos concluir que um painel a partir de 2.4W já seria suficiente para em ambos os perfis de desempenho. A possibilidade de utilizar uma bateria de menor capacidade gera um ganho secundário em termos de redução do custo final do sistema.
Figura 5.32: Impacto da Arquitetura sobre a configuração do sistema em cada perfil de desempenho.
Além de validar o principal objetivo da Arquitetura que é tornar o sistema harvesting- aware, também é necessário avaliar o impacto causado pela inclusão da própria Arquitetura ao sistema. Ou seja, também foi necessário analisar a eficiência da Arquitetura proposta em termos de área ocupada no FPGA, aumento no tempo de execução do sistema e aumento da potência total dissipada. A partir dos resultados apresentados na Figura 5.11 e na Tabela 5.1 para o estudo de caso utilizando a FPGA Altera Cyclone IV GX, podemos concluir que a Arquitetura harvesting-awarecausa baixo impacto na eficiência do sistema como um todo:
9% de área adicional ocupada no FPGA, valor absoluto considerando o FPGA Altera
Cyclone IV GX
16, 94µs de aumento no tempo total de execução do sistema consumo de energia adicional de 2, 71W µs
De acordo com os resultados obtidos podemos concluir que o trabalho atingiu seus objetivos específicos e apresenta diferenciais em relação aos trabalhos anteriores:
5.6. ANÁLISE CONCLUSIVA 94
Tornar aplicações em FPGA Harvesting-Aware: garantir que uma aplicação em FPGA
com energia solar será executada de forma a atingir o “energy neutral operation mode”. Ou seja, a cada intervalo de tempo a execução será no melhor desempenho possível e sem esgotar a bateria, mantendo dessa forma sua execução perene sem shut downpor falta de energia.
Reduzir a complexidade do projeto: a Ferramenta HA-App gera automaticamente
o código sintetizável da Arquitetura harvesting-aware em FPGA, tornando transpa- rente para o projetista a implementação desse conceito. O projetista precisa apenas configurar alguns parâmetros de acordo com as características da sua aplicação, e automaticamente a Arquitetura gerada tornará a aplicação harvesting-aware.
Reduzir o tempo de desenvolvimento: da mesma forma, como a Ferramenta auto-
matiza o processo para tornar aplicações em FPGA harvesting-aware, o tempo de projeto do aspecto harvesting-aware é reduzido consequentemente.
Suporte a sistemas digitais síncronos: a Arquitetura pode ser utilizada para sistemas
síncronos, não estando limitada a um subconjunto específico de aplicações. Atra- vés do controle do sinal de clock, a Arquitetura gerada pela Ferramenta ajusta o desempenho de cada funcionalidade ativando ou desativando sua execução, indepen- dentemente do que a funcionalidade em si representa.
Considerando as características listadas acima, o diferencial da Ferramenta HA-App consiste em tornar transparente para o projetista a codificação do aspecto harvesting-aware da aplicação, uma vez que o ajuste de performance da aplicação, em tempo de execução, é feito pela Arquitetura gerada. A contribuição do trabalho “Suportando o Projeto de Arquiteturas Harvesting-Awarepara Aplicações em FPGA” em relação aos seus antecessores está em criar e disponibilizar uma ferramenta para tornar harvesting-aware aplicações implementadas em hardware, além de poder ser utilizada por aplicações síncronas de uma maneira mais ampla. Até o momento, todos os trabalhos estavam conceitualmente restritos a aplicações do tipo “redes de sensores sem fio”, implementadas em software e sem reusabilidade de código (MEIER, 2011; MOSER; CHEN; THIELE, 2010; HSU et al., 2009; JIANG et al., 2007).
O Capítulo 6 apresenta uma lista de possíveis trabalhos futuros que podem aperfeiçoar a técnica e ampliar o escopo do trabalho já desenvolvido.
95 95 95
6
Trabalhos Futuros
A evolução do trabalho desenvolvido pode seguir algumas direções no sentido de reduzir as limitações da abordagem atual. Nesse sentido, os trabalhos futuros indicados neste capítulo seguem com o objetivo de ampliar o escopo de uso da Arquitetura, aplicar outras técnicas para alterar, por exemplo, o padrão de dissipação de potência estática e/ou suportar a decisão das configurações dos componentes painel solar e bateria em tempo de implementação. As seções a seguir detalham cada um desses aspectos.
6.1
Ampliando o Escopo para Aplicações Assíncronas e Ou-
tras Fontes de Energia
A Arquitetura harvesting-aware definida e implementada nesse trabalho é capaz de tornar harvevsting-aware aplicação síncronas implementadas em FPGA com energia solar. Nesse sentido, uma possível evolução do trabalho seria definir e implementar uma arquitetura capaz de ajustar também aplicações assíncronas. Além disso, outra forma de ampliar o escopo de uso, seria implementar a predição de energia considerando outras fontes de energia, como eólica e cinética. Para adaptar a Arquitetura à outras fontes de energia, o módulo de predição deve ser substituído na íntegra por outra implementação. Por exemplo, caso se deseje utilizar um transdutor piezoelétrico para coletar energia eletrodinâmica, o projetista deve implementar um algoritmo de previsão de frequências vibracionais no componente “Preditor”.
6.2
Suporte ao Dimensionamento dos Componentes Painel
Solar e Bateria
Outra direção no sentido de evoluir o trabalho está relacionada ao aspecto dimensiona- mento dos elementos painel solar e bateria. Aqui o objetivo seria dar suporte ao projetista, em tempo de projeto, na escolha da bateria e do painel solar. Com base em simulações, a ferramenta poderia ajudar a definir qual a capacidade mínima da bateria e qual a potência mínima de saída