Desenvolvimento de uma Plataforma
de Software Embarcado para
Aerogeradores com Aerofólios
Cabeados
Monografia submetida à Universidade Federal de Santa Catarina
como requisito para a aprovação na disciplina
DAS 5511: Projeto de Fim de Curso
Matheus Krüger Winter
Desenvolvimento de uma Plataforma de
Software Embarcado para Aerogeradores
com Aerofólios Cabeados
Matheus Krüger Winter
Esta monografia foi julgada no contexto da disciplina
DAS5511: Projeto de Fim de Curso
e aprovada na sua forma final pelo
Curso de Engenharia de Controle e Automação
Prof. Dr. Rômulo Silva de Oliveira
Banca examinadora:
Eng. Eduardo F. Schmidt
Orientador na empresa
Dr. Rômulo Silva de Oliveira
Orientador no curso
Me. Fernando S. Gonçalves
Avaliador
Eng. Gustavo Kerezi
Debatedor
Eng. Leonardo Rubin Quaini
AGRADECIMENTOS
A Deus, que me conduziu até aqui de forma singular.
À minha família, em especial aos meus pais, Milton Winter e Edelgard Eliane Krü-ger Winter, que me ensinaram desde cedo o caminho em que deveria andar, por seu esforço, apoio e amor incondicional durante todos esses anos. E às minhas irmãs, Caroline Krüger Winter e Lauren Krüger Winter, pela companhia, conselhos e compa-nheirismo ao longo desta jornada.
Ao laboratório UFSCkite, pela estrutura e pela oportunidade de fazer parte da equipe. Um agradecimento especial ao coordenador do projeto Prof. Alexandre Tro-fino Neto, e aos engenheiros responsáveis Marcelo De Lellis e Ramiro Saraiva, pela orientação profissional, por todos os ensinamentos e pela confiança em mim deposi-tada.
Ao Prof. Rômulo Silva de Oliveira, pela orientação, pelos conhecimentos transmiti-dos e por todas as contribuições fundamentais à realização e aperfeiçoamento deste trabalho e documento.
Aos meus amigos e colegas de trabalho Eduardo Fensterseifer Schmidt e Lucas Napoleão Coelho, por todo o seu esforço e competência na tomada de decisões du-rante o desenvolvimento deste trabalho, que foram cruciais ao resultado obtido. Assim como pelos momentos de descontração e conversas que certamente moldaram o seu desenvolvimento.
À Universidade Federal de Santa Catarina, ao Departamento de Automação e Sis-temas (DAS), e a todos os professores do curso de graduação em Engenharia de Controle e Automação, que me capacitaram e fomentaram meu interesse pela enge-nharia ao longo da minha formação acadêmica.
Resumo
O grande crescimento da demanda energética global previsto para as próximas décadas tem fomentado cada vez mais o desenvolvimento e aprimoramento de fontes de energias renováveis. Estudos realizados sobre o potencial de extração de energia eólica em altas altitudes apresentaram resultados extremamente promissores quanto ao potencial energético e custos para a produção de energia elétrica, alavancando o desenvolvimento de tecnologias para tal, como a de aerogeradores com aerofólios cabeados (Airborne Wind Energy (AWE), em inglês). Nesse o contexto, o laboratório UFSCkite estuda e desenvolve protótipos visando a extração de energia através desta tecnologia, utilizando sistemas eletro-mecânicos e avançadas técnicas de controle, estimação e instrumentação. Protótipos de sistemas aerogeradores com aerofólios cabeados são dispositivos mecatrônicos complexos, envolvendo aspectos multidisci-plinares, e para os quais ainda não existem diretrizes de projeto estabelecidas. Por-tanto, grupos de pesquisa e empresas novatas no campo são obrigados a comprar soluções genéricas de preço elevado de software e hardware, ou a construir suas pró-prias soluções desde o princípio. Como uma tentativa de mitigar esse problema, este trabalho propõe uma plataforma de software embarcado sobre a qual aplicações de AWE possam ser desenvolvidas. Implementada principalmente na linguagem C de programação e visando inicialmente a sua utilização em computadores de placa única de baixo custo operando com sistemas operacionais Linux, a plataforma proposta foi projetada de forma a permitir a decomposição da aplicação de AWE em módulos funci-onais altamente desacoplados. Estes são executados de maneira distribuída na forma de processos indepedentes, possivelmente sobre múltiplas unidades computacionais, e são capazes de trocar informações através de uma infraestrutura de comunicação padronizada de alta-performance, baseada no padrão publisher-subscriber. Além de fornecer um conjunto cuidadosamente selecionado de dependências, as quais são coletadas e instaladas durante uma etapa de construção automática, a plataforma também oferece uma série de mecanismos ao desenvolvedor, incluindo ferramentas de acionamento remoto, monitoramento em tempo real, registro de dados, depuração e instrumentação de código. Através da sua aplicação no protótipo de AWE do grupo UFSCkite, e da realização de experimentos em laboratório e em campo, onde seus as-pectos funcionais e requisitos impostos foram devidamente testados, concluiu-se que a plataforma proposta é capaz de auxiliar o processo de desenvolvimento e operação de protótipos de AWE.
Palavras-chave: Sistemas de energia renovável. Protótipos de Aergoreradores com Aerofólios cabeados. Sistemas embarcados. Plataformas de Software
Abstract
The increasing global energetic demand forecasted for the next decades has been increasingly promoting the further development and improvement of renewable energy sources. Studies focused on high-altitude wind energy extraction potential report pro-mising results regarding energy production and its costs, leveraging the development of technologies to enable such extractions, such as airborne wind energy (AWE). In this context, the UFSCkite laboratory studies and develops such technologies, by utilizing eletromechanical systems and advanced control, estimation and instrumentation tech-niques. Airborne wind energy prototypes are complex mechatronic devices involving many multidisciplinary aspects and for which there are currently no established design guidelines. Therefore, newcomers to the field are required to either purchase expen-sive software and hardware not specifically designed for AWE applications or build their own solutions from scratch. As an attempt to partially overcome this challenge, this work propoes an embedded software platform on top of which AWE systems can be developed. Written mainly in C, and initially targeting low cost single-board compu-ters running Linux, the proposed platform is designed in such a way that it allows for the AWE system to be split into highly decoupled functional modules. These run in a distri-buted fashion as independent processes, possibly across several computational units, and are capable of exchanging information through a standard, high-performance com-munication infrastructure based on the publisher-subscriber pattern. Besides providing a carefully chosen set of dependencies, which are fetched and installed during an au-tomatic build phase, the platform also provides a series of facilities to the developer, including remote deployment, real-time monitoring, logging, code instrumentation and debug tools. The designed platform is suitable for application in AWE prototypes and could indeed benefit its growing community, especially in what comes to module reuse and sharing. Through its application in an AWE protype developed by the UFSCkite group, and the execution of exeperimental procedures both in a lab environment and in real-world conditions, where all its requirements and functional aspects were properly tested, it was concluded that the proposed software plataform is capabled of aiding the development process and the operation of AWE prototypes.
Keywords: Renewable energy systems. Airborne Wind Energy prototypes. Em-bedded systems. Software platforms
Sumário
1 Introdução 1
1.1 Panorama do cenário energético global . . . 1
1.2 Aerogeradores com aerofólios cabeados . . . 3
1.3 Laboratório UFSCkite . . . 4 1.4 Motivação . . . 5 1.5 Objetivos . . . 7 1.6 Metodologia . . . 8 1.7 Estrutura do documento . . . 8 2 Fundamentação Teórica 10 2.1 Sistemas ciber-físicos . . . 10 2.1.1 Sistemas embarcados . . . 11
2.1.2 Sistemas de tempo real . . . 12
2.2 Sistemas operacionais . . . 12 2.2.1 Linux . . . 14 2.2.1.1 Estrutura geral . . . 14 2.2.1.2 Sistema de arquivos . . . 16 2.2.1.3 Distribuições . . . 16 2.2.2 Processos e threads . . . 17 2.3 Mecanismos de comunicação . . . 18
2.3.1 Comunicação entre processos . . . 18
2.3.1.1 Arquivos . . . 19
2.3.1.2 Soquetes de domínio Unix . . . 19
2.3.1.3 Fila de mensagens . . . 19
2.3.1.4 Pipes . . . 20
2.3.1.5 Memória compartilhada . . . 20
2.3.2 Interfaces de Entrada e Saída . . . 20
2.3.2.1 UDP . . . 21 2.3.2.2 TCP . . . 21 2.3.2.3 WebSocket . . . 21 2.3.2.4 UART . . . 22 2.3.2.5 SPI . . . 22 2.3.2.6 I2C . . . 22
2.4 Arquiteturas de software . . . 23 2.4.1 Estilos e padrões . . . 24 2.4.1.1 Cliente e servidor . . . 24 2.4.1.2 Orientado a objetos . . . 25 2.4.1.3 Baseado em componentes . . . 25 2.4.1.4 Dividido em camadas . . . 26
2.4.1.5 Baseado em barramento de mensagens . . . 27
2.4.1.6 Orientado a serviços . . . 28
2.5 Plataformas de software . . . 29
2.5.1 Frameworks . . . 30
3 Sistemas aerogeradores com aerofólios cabeados 31 3.1 Classificação . . . 32
3.1.1 Quanto ao princípio de funcionamento . . . 32
3.1.2 Quanto à localização da unidade geradora . . . 33
3.1.3 Quanto à estrutura da asa . . . 34
3.2 Configuração pumping kite . . . 34
3.3 Instrumentação . . . 36
3.3.1 Sistemas de medição . . . 36
3.3.2 Sistemas de atuação . . . 37
3.4 Controle . . . 37
4 Análise e identificação de requisitos 40 4.1 Visão geral do sistema aerogerador . . . 40
4.1.1 Protótipo da unidade de controle de voo . . . 40
4.1.1.1 Componentes físicos e de Hardware . . . 41
4.1.1.2 Software embarcado . . . 42 4.1.2 Sistema supervisório . . . 43 4.1.3 Simulador . . . 43 4.2 Requisitos da plataforma . . . 44 4.3 Análise de viabilidade . . . 46 4.4 Decomposição em módulos . . . 46
5 Projeto da plataforma de software 48 5.1 Arquitetura de software . . . 48
5.2 Módulos e submódulos . . . 49
5.3 Funcionamento . . . 51
5.4.1 Configuração dos módulos . . . 51
5.4.2 Parâmetros do sistema . . . 52
5.4.3 Gerenciamento da execução dos módulos . . . 52
5.4.4 Depuração em tempo de execução . . . 53
5.4.5 Registro de dados . . . 53
6 Implementação da plataforma de software 54 6.1 Considerações gerais . . . 54
6.2 Módulos . . . 54
6.2.1 Fluxo de execução . . . 55
6.2.2 Comunicação entre módulos . . . 56
6.2.3 Gerenciamento de parâmetros . . . 58
6.2.4 Configuração estática . . . 58
6.3 Características e dependências de software adicionais . . . 59
6.4 Ferramentas . . . 60
6.4.1 Controle de versão . . . 60
6.4.2 Integração continua . . . 60
6.4.3 Compilação automática . . . 61
6.4.4 Gerenciamento de execução dos módulos . . . 61
6.4.5 Depuração em tempo de execução . . . 62
6.4.6 Registro de dados . . . 63
7 Aplicação e Resultados 65 7.1 Aplicação da plataforma em protótipo de sistema aerogeador . . . 65
7.1.1 Módulos . . . 65
7.2 Testes funcionais . . . 70
7.2.1 Testes em laboratório . . . 70
7.2.1.1 Resultados . . . 71
7.2.2 Teste preliminar em campo . . . 76
7.2.2.1 Resultados . . . 77
7.3 Observações . . . 82
Lista de Figuras
1.1 Capacidade de geração energética global e utilização efetiva das fontes nuclear, eólica e solar em GW nos anos de 2014 e sua previsão para 2040. . . 3 1.2 Exemplos de sistemas aerogeradores com aerofólios cabeados. (a)
Em-presa Enerkite; (b) EmEm-presa Kite Power Systems (KPS); (c) EmEm-presa Makani Power. . . 4 1.3 Disponibilidade e velocidade média dos ventos em (a) 50 m; e (b) 200
m de altitude. Cores mais escuras representam regiões com maior ve-locidade média. . . 5 1.4 Custo nivelado de energia, em ect/kWh, de uma turbina eólica de 100
kW e do sistema AWE EK200 de potência nominal equivalente, con-forme anunciado pela empresa alemã EnerKite. . . 6 2.1 Representação em fluxograma de um sistema ciber-físico, contendo
seus elementos e as relações de troca de informação entre eles. . . 10 2.2 Representação da divisão de um computador em camadas de hardware
e software. . . 13 2.3 Representação da divisão em camadas de um sistema computacional
utilizando o sistema operacional Linux. . . 14 2.4 Representação simplificada do kernel Linux. . . 15 2.5 A abstração de processo de um sistema operacional. . . 17 2.6 Três maneiras básicas de realizar a comunicação entre processos no
sistema Linux. . . 19 3.1 Relação de grupos de pesquisa e empresas envolvidas no
desenvolvi-mento da tecnologia de AWE. . . 31 3.2 Sistema aerogerador estático desenvolvido pela empresa Altaeros
Ener-gies. . . 32 3.3 Sistemas AWE baseados em (b) forças de arrasto e (a) forças de
sus-tentação. . . 33 3.4 Sistema de geração eólica com (a) gerador(es) em solo e sistema de
geração eólica (b) com gerador(es) em voo. . . 34 3.5 Diferentes tipos de dispositvos aéreos em sistemas de geração em solo.
(a) LEI-SLE Kite; (b) LEI-C C kite; (c) Foil Kite; (d) planador; (e) Swept rigid wing; (f) Aerofólio semi-rígido. . . 35
3.6 Representação de sistema de AWE operando na configuração pumping kite. Na etapa de geração – linha contínua – o aerofólio se afasta da unidade de solo descrevendo uma trajetória complexa na forma de lem-niscata, ao passo que na etapa de recolhimento – linha pontilhada – o mesmo se aproxima da unidade de solo descrevendo uma trajetória simples. . . 36 3.7 Exemplos de instrumentos utilizados em sistemas de geração eólica
com aerofólios cabeados: (a) encoder ; (b) IMU; (c) célula de carga. . . 37 3.8 Sistemas de geração eólica com atuação (a) através da unidade de
con-trole de voo; e (b) através da unidade solo. . . 38 3.9 Aerofólio do grupo UFSCkite descrevendo trajetória em formato de
lemn-sicata. . . 39 4.1 Protótipo desenvolvido pelo grupo UFSCkite a fim de testar, aprimorar e
validar as estratégias de controle desenvolvidas. . . 41 4.2 Imagem obtida da tela principal do sistema supervisório. . . 44 4.3 Representação da utilização do sistema em uma configuração de
simu-lação hardware-in-the-loop. . . 44 4.4 Representação modular de um sistema AWE através da divisão em
ca-tegorias funcionais. . . 47 5.1 Representação da composição e interação entre módulos e seus
sub-módulos na perspectiva da plataforma de software. . . 49 5.2 Representação do sistema de comunicação especificado para a
plata-forma de software, (a) estrutura para a troca de mensagens no sistema; e (b) estrutura de cada mensagem. . . 50 5.3 Representação do funcionamento básico de um módulo através de um
diagrama de atividades. . . 52 6.1 Representação gráfica da transmissão de dados entre elementos em
uma rede utilizando (a) Unicast; (b) Broadcast; e (c) Multicast. . . 57 6.2 Interface web para o gerenciamento remoto de processos com o
super-visord. . . 62 6.3 Ferramenta de monitoramento de sondas de depuração dos módulos da
aplicação AWE. (a) Tela inicial da ferramenta, e (b) Tela de monitoramento. 64 7.1 Representação do protótipo da unidade de controle de voo sob a
7.2 Diagrama representando a configuração do sistema utilizada para a rea-lização de testes em laboratório com o protótipo da unidade de controle de voo. . . 71 7.3 Tela de operação do sistema supervisório do protótipo durante sua
ope-ração em laboratório. . . 72 7.4 Trecho da trajetória descrita pelo aerofólio no espaço durante
experi-mento em laboratório, obtida através da ferramenta de log fornecida pela plataforma. (a) Vista frontal; (b) Vista em perspectiva. . . 73 7.5 Ferramenta de supervisão de processos supervisord durante
experi-mento em laboratório. . . 74 7.6 Ferramenta de depuração de sondas em tempo de execução durante
experimento em laboratório. . . 75 7.7 Diagrama representando a configuração do sistema utilizada para a
re-alização do teste em campo com o protótipo da unidade de controle de voo. . . 76 7.8 Tela de operação do sistema supervisório protótipo durante sua
opera-ção em campo. . . 77 7.9 Trecho da trajetória descrita pelo aerofólio no espaço durante
experi-mento em campo, obtida através da ferramenta de log fornecida pela plataforma. (a) Vista frontal; (b) Vista em perspectiva. . . 78 7.10 Imagens do experimento realizado em campo com o protótipo. . . 79 7.11 Ferramenta de supervisão de processos supervisord durante
experi-mento em campo. . . 80 7.12 Ferramenta de depuração de sondas em tempo de execução durante
Lista de Tabelas
7.1 Descrição e restrição temporal estabelecida à cada módulo do conjunto de sensores que integram o sistema embarcado. . . 68 7.2 Descrição e restrição temporal estabelecida à cada módulo do conjunto
de estimadores e algoritmos de filtragem que integram o sistema em-barcado. . . 69 7.3 Descrição e restrição temporal estabelecida à cada módulo do conjunto
de atuadores que integram o sistema embarcado. . . 69 7.4 Descrição e restrição temporal estabelecida à cada módulo do conjunto
de controladores que integram o sistema embarcado. . . 70 7.5 Descrição e restrição temporal estabelecida à cada módulo do conjunto
de interfaces com sistemas externos que integram o sistema embarcado. 70 7.6 Módulos utilizados durante o experimento em laboratório, seus períodos
nominais de ciclo, as médias e desvios padrão observados e o número de amostras que excederam em 5 % ou mais o valor nominal estabelecido. 76 7.7 Módulos utilizados durante o experimento em campo, seus períodos
nominais de ciclo, as médias e desvios padrão observados e o número de amostras que excederam em 5 % ou mais o valor nominal estabelecido. 82
Capítulo 1
Introdução
A expansão econômica e populacional de países emergentes, avanços tecnoló-gicos e questões ambientais são alguns dos fatores que influenciam as presentes mudanças no cenário energético global, principalmente em relação ao aumento da demanda por produção de energia elétrica. A agência internacional de energia (Inter-national energy agency (EIA), em inglês) prevê em sua publicação mais recente [1], considerando seu cenário principal de projeções, que cerca de 60% do crescimento da demanda energética até 2040 será suprido por fontes renováveis de energia, especifi-camente, as fontes hídrica, solar e eólica.
Nesse contexto de expansão destaca-se a tecnologia de energia eólica com ae-rofólios cabeados (Airborne Wind Energy (AWE), em inglês), que visa a extração de energia de ventos em elevadas altitudes a uma fração do custo das turbinas eólicas convencionais. Apesar de promissora, a tecnologia de AWE encontra-se em um está-gio intermediário de desenvolvimento, e diversos desafios devem ser superados para que chegue ao mercado de forma competitiva. Esta monografia apresenta uma contri-buição para um desses desafios, que é o desenvolvimento de software para protótipos AWE de forma eficiente e organizada.
Este capítulo introduz um breve panorama do cenário energético global, incluindo seu estado atual e as perspectivas de transformação para as próximas décadas, se-guido por uma introdução ao conceito de sistemas de AWE e seus desafios, assim como por uma apresentação do laboratório onde este trabalho foi conduzido. Em seguida, o objetivo do trabalho é formalmente descrito ao leitor, em conjunto com a metodologia empregada no seu desenvolvimento. Finalmente, a última seção provê uma visão geral da estrutura do documento e seus capítulos.
1.1
Panorama do cenário energético global
O conjunto de matrizes primárias utilizado para a geração de energia elétrica sofreu grandes transformações ao longo das últimas décadas. Apesar das mudanças em di-reção à utilização de fontes renováveis em decorrência das crescentes preocupações ambientais sobre os efeitos da emissão de gases do efeito estufa, os combustíveis
fósseis continuam sendo a principal fonte da energia primária utilizada no planeta [2]. Segundo um estudo recente [1] publicado pela agência internacional de energia, a demanda energética global deverá crescer cerca de 30% até 2040. Enquanto que a demanda por eletricidade deverá crescer até 65% nesse período, e cerca de 85% desse acréscimo será decorrente da expansão econômica e populacional de países emergentes [3]. Contudo, suprir tal demanda irá requerer grandes esforços no que tange questões ambientais e econômicas relacionadas à produção energética.
O Tratado de Paris, o qual entrou em vigor em novembro de 2016, foi um grande passo em direção a um futuro renovável. Através do estabelecimento da meta de man-ter o aumento da temperatura do planeta abaixo de 2oC em relação ao período
pré-industrial, as entidades governamentais envolvidas devem gradualmente alterar suas políticas de subsídios, a fim de fomentar a utilização e desenvolvimento de fontes com baixa emissão de carbono. Segundo projeções da própria agência internacional de energia, tal cenário irá alavancar a expansão da indústria de energias renováveis, que será responsável por atender cerca de 60% do crescimento da demanda energética até 2040.
Nesse contexto, destacam-se as energias solar e eólica. A Figura 1.1 evidencia o fato de que apesar de utilizar-se apenas uma fração de sua capacidade, a energia eólica possui um enorme potencial energético ainda não explorado, sendo capaz in-clusive de atender a demanda energética global [4]. Contudo, a tecnologia atual de turbinas eólicas possui diversas limitações, tornando-a menos competitiva em relação a usinas termoelétricas, por exemplo. Devido a suas estruturas de grande porte, a sua construção geralmente requer um investimento financeiro considerável, o que eleva diretamente o custo de produção energético de parques eólicos. Além disso, a densi-dade energética por kilômetro quadrado obtida atualmente é cerca de 200–300 vezes menor do que a obtida em grandes usinas termoelétricas de mesma capacidade de geração, resultando em um alto índice de ocupação de terras e impactos ambientais por parte destes parques [4].
Figura 1.1: Capacidade de geração energética global e utilização efetiva das fontes nuclear, eólica e solar em GW nos anos de 2014 e sua previsão para 2040.
Fonte: Adaptado de [3]
1.2
Aerogeradores com aerofólios cabeados
No contexto de fontes renováveis para geração de energia elétrica, o termo Airbone Wind Energy System (AWES) surgiu para descrever uma classe emergente de aero-geradores. Tais sistemas usualmente empregam aeronaves ou aerofólios cabeados a fim de alcançar ventos em camadas atmosféricas inacessíveis às turbinas eólicas, e possuem dois componentes principais, uma estação de solo e um dispositivo aéreo, os quais são mecanicamente ou até mesmo eletricamente conectados através de um ou mais cabos [5]. Dentre as diferentes configurações existentes, podemos distinguir sistemas de geração em solo, onde a conversão da energia mecânica em energia elé-trica ocorre no solo, e sistemas de geração aérea, onde a conversão ocorre na própria aeronave e a eletricidade é transmitida ao solo através de um cabo. A partir desses dois grupos existem muitas outras possíveis ramificações, as quais variam de acordo com o tipo e número de aeronaves, os conceitos de controle, e a presença ou au-sência de movimento na estação de solo. A Figura 1.2 apresenta alguns dispositivos aerogeradores com aerofólios cabeados já desenvolvidos.
Além de alcançar altitudes mais elevadas em comparação à tecnologia eólica tra-dicional, onde o vento é notoriamente mais constante e forte, conforme demonstrado na Figura 1.3, a tecnologia de AWE permite a redução de custos na construção e ins-talação de usinas de energia. Tais características acabam por simplificar a busca por novos locais de instalação, o que a torna ainda mais atraente. A Figura 1.4 apresenta
uma comparação do custo nivelado de energia1com base na velocidade do vento en-tre uma turbina eólica convencional de 100 kW e um sistema de AWE de potencia nominal equivalente, desenvolvido pela empresa alemã EnerKite, evidenciando o seu potencial.
(a) (b)
(c)
Figura 1.2: Exemplos de sistemas aerogeradores com aerofólios cabeados. (a) Empresa Enerkite; (b) Empresa Kite Power Systems (KPS); (c) Empresa Makani Power.
Fonte: Adaptado de [6–8]
1.3
Laboratório UFSCkite
O laboratório UFSCkite, localizado na Universidade Federal de Santa Catarina (UFSC), é voltado ao estudo de tecnologias de AWE como alternativa para geração de energia elétrica. Desde o início de suas atividades, em meados de 2012, o grupo estuda aspectos teóricos e práticos relacionados ao projeto e ao desenvolvimento da
1O custo nivelado de energia (Levelized cost of energy (LCOE), em inglês) é comumente utilizado como uma medida de competitividade entre diferentes tecnologias de geração de energia elétrica. O LCOE representa o custo por KWh da construção e operação de uma usina de energia considerando sua vida útil, incluindo fatores como custos de capital, de combustíveis, de manutenção, de operação, de financiamento, de incentivos, de seguros, assim como impostos e inflação.
(a) 50 m
(b) 200 m
Figura 1.3: Disponibilidade e velocidade média dos ventos em (a) 50 m; e (b) 200 m de altitude. Cores mais escuras representam regiões com maior velocidade média.
Fonte: [9]
tecnologia. A longo prazo, o UFSCkite tem como objetivo torná-la viável a ponto de ser comercializada, contribuindo para a diversificação da matriz energética nacional [10].
O grupo possui hoje mais de sete publicações internacionais de destaque, e sua equipe conta com mais de dez integrantes, entre alunos de graduação e pós-graduação. A infraestrutura do grupo inclui um laboratório equipado com estações de trabalho in-dividuais, instrumentos eletrônicos de bancada, e dois protótipos utilizados para teste das técnicas de estimação e controle desenvolvidas, visando, finalmente, a geração de energia elétrica de forma autônoma.
1.4
Motivação
Conforme supracitado, ventos em elevadas altitudes representam um recurso pro-missor na perspectiva da produção de energia elétrica sustentável. Tal característica estabelece a tecnologia de AWE entre as principais emergentes no ramo de
ener-Figura 1.4: Custo nivelado de energia, em ect/kWh, de uma turbina eólica de 100 kW e
do sistema AWE EK200 de potência nominal equivalente, conforme anunciado pela empresa alemã EnerKite.
Fonte: Adaptado de [6]
gias renováveis, o que é evidenciado pela rápida aceleração do desenvolvimento da mesma. Na última década, o ingresso de diversas empresas ao setor garantiu a cria-ção de patentes, assim como o desenvolvimento de soluções técnicas para a sua im-plementação, em sua maioria na forma de protótipos. Atualmente, empresas e grupos de pesquisa ao redor do mundo estão trabalhando de forma a aperfeiçoar a tecnologia, abordando aspectos como controle, eletrônica e design [5].
Contudo, apesar de promissora em termos de viabilidade econômica, conforme apontado por [11], a tecnologia de aerogeradores com aerofólios cabeados ainda se encontra em estágio de desenvolvimento, com muitos aspectos a serem abordados a fim de torná-la viável comercialmente. Além dos desafios envolvendo o material dos cabos, modelagem aerodinâmica e de aerofólios, instrumentação, atuação e técnicas de controle, uma das grandes dificuldades enfrentadas no seu desenvolvimento é a própria realização de setups experimentais [12].
Os protótipos de sistemas de AWE são dispositivos mecatrônicos complexos en-volvendo noções multidisciplinares [13], para os quais ainda não existem diretrizes de desenvolvimento estabelecidas, obrigando empresas ou grupos de pesquisa que de-sejam ingressar nesse setor a comprar soluções off-the-shelf genéricas de preço ele-vado de software e hardware [14], ou a desenvolver as suas próprias soluções desde o princípio. Dada a importância da prototipagem no ambiente de AWE, esse cenário im-põe uma barreira de entrada não apenas técnica mas também econômica, retardando
resultados experimentais e limitando a cooperação entre diferentes organizações. Ademais, o processo de desenvolvimento de software destas aplicações é com-plexo. Em adição às inúmeras configurações existentes e aos desafios de controle impostos pela natureza dos sistemas, mudanças em requisitos, em características fí-sicas e em condições de operação de protótipos em desenvolvimento são comuns. Assim, exige-se um grande esforço a fim de manter o processo de prototipagem orga-nizado e flexível sem afetar seu tempo ou custo de execução. De maneira análoga ao sistema operacional de robôs (Robot Operating System (ROS), em inglês) [15], o qual surgiu de forma a mitigar problemas de complexidade e grande variedade de confi-gurações no desenvolvimento de aplicações robóticas complexas, a criação de uma plataforma de software padronizada se torna atraente para simplificar e tornar mais eficaz o processo de prototipagem de sistemas AWE, sem torná-lo oneroso economi-camente.
1.5
Objetivos
O objetivo deste trabalho é, portanto, desenvolver uma plataforma de software para sistemas embarcados capaz de simplificar e agilizar o desenvolvimento de protóti-pos para sistemas aerogeradores com aerofólios cabeados do grupo UFSCkite, for-necendo todo o suporte necessário para tal. Além disso, também compõe o escopo deste trabalho a aplicação da plataforma desenvolvida em um dos protótipos do grupo, de forma a avaliar seu desempenho não apenas em tempo de execução, mas também durante o processo de desenvolvimento. De forma mais específica, os propósitos deste trabalho são:
• Estudar a arquitetura de software atual empregada pelo grupo, assim como ar-quiteturas empregadas em aplicações similares;
• Identificar as características desejadas em uma plataforma de software para AWE, levantando requisitos necessários à tecnologia com base nos protótipos do grupo UFSCkite;
• Projetar uma plataforma de software capaz de atender aos requisitos previa-mente estabelecidos;
• Implementar a plataforma de software e aplicá-la no desenvolvimento de soft-ware embarcado para um dos protótipos do grupo UFSCkite;
• Avaliar a performance da plataforma e do software desenvolvido para o protótipo em ambientes simulados e em campo, a fim de estabelecer as próximas etapas
no desenvolvimento da mesma, aferindo sua viabilidade de aplicação em futuros protótipos do grupo;
1.6
Metodologia
Todas as etapas do trabalho foram desenvolvidas com total suporte do UFSCkite. O início das atividades envolveu uma intensa interação com os membros mais antigos do grupo, Marcelo de Lellis Oliveira e Ramiro Saraiva, que puderam fornecer detalhes em relação às características da aplicação e do software já existente. Essas informa-ções foram fundamentais para o processo de análise do problema, permitindo definir com uma maior segurança os objetivos do trabalho e os requisitos do sistema. En-quanto isso, o projeto e o desenvolvimento propriamente ditos foram orientados pelo membro Eduardo Schmidt, e contaram com colaboração dos membros Lucas Coelho e Jean Damke, responsáveis pelo desenvolvimento do ambiente de simulação e pela interface de usuário, respectivamente. A forte interação entre a equipe, facilitada por meio da utilização de ferramentas colaborativas como Slack, Trello, Gitlab, e outras, foi determinante para o resultado do trabalho.
Durante a sua realização, utilizou-se uma metodologia top-down com ênfase no desenvolvimento de sistemas embarcados, conforme descrito em [16]. Essa metodo-logia sugere uma abordagem iterativa, em que o processo de desenvolvimento inicia com a análise de requisitos e restrições do sistema, passa por uma fase de projeto de alto-nível, na qual são construídos modelos abstratos do software, seguida de uma fase de projeto de engenharia, que envolve o detalhamento dos modelos e garante que estão prontos para serem implementados. Na fase de testes, a última etapa do processo de desenvolvimento, avalia-se se o sistema implementado está pronto para produção, ou se ajustes precisam ser realizados, situação em que o fluxo de projeto retorna à etapa inicial.
1.7
Estrutura do documento
Esta monografia é organizada da seguinte maneira. No capítulo 2, a fundamenta-ção teórica de uma série de tópicos fundamentais à compreensão e desenvolvimento do trabalho são apresentados, incluindo conceitos de sistemas embarcados e arquite-turas de software. Em seguida, no capítulo 3, é apresentada ao leitor uma introdução a sistemas de AWE, onde são descritas características construtivas dos mesmos, as-sim como os seus princípios de funcionamento mais usuais. O capítulo 4 expõe a
análise do problema cuja solução é o foco da contribuição deste trabalho, abordando aspectos da arquitetura de software e do sistema de AWE em questão, assim como os requisitos a serem cumpridos pela plataforma de software. No capítulo 5, a plataforma de software é proposta, fornecendo detalhes sobre a etapa de projeto da mesma, na qual a arquitetura básica é apresenta em conjunto com suas características funcionais e ferramentas adicionais. O Capítulo 6 descreve o processo de implementação da pla-taforma, especificando as decisões e ferramentas utilizadas para o cumprimento dos requisitos previamente estabelecidos. No Capítulo 7, a aplicação da plataforma de-senvolvida em um protótipo do grupo UFSCkite é apresentada, explicitando esse pro-cesso e apresentando o resultado de testes em ambiente de laboratório e em campo. Finalmente, o Capítulo 8 relata, de forma sucinta, as conclusões obtidas ao longo do desenvolvimento deste trabalho, descrevendo as tarefas não documentadas que já estão em andamento, e sugerindo possibilidades de trabalhos futuros
Capítulo 2
Fundamentação Teórica
Este capítulo apresenta uma breve introdução aos conceitos essenciais à compre-ensão deste trabalho. São abordados os tópicos estudados durante a sua elaboração, incluindo aspectos de sistemas cíber-físicos, sistemas de tempo real, arquiteturas e plataformas de software e o sistema operacional Linux, assim como comunicação en-tre processos, sistemas e dispositivos periféricos. Aspectos mais específicos serão apresentados com maior detalhe conforme necessário nos capítulos subsequentes.
2.1
Sistemas ciber-físicos
Sistemas ciber-físicos (Cyber-physical systems (CPSs), em inglês) são definidos como a integração de sistemas computacionais com processos físicos, cujo compor-tamento é definido tanto pelas partes cibernéticas quanto físicas do sistema. CPSs tratam da intersecção do físico com o cibernético, assim não é suficiente compreender o funcionamento de cada um desses sistemas de forma individual, pois a sua interação também deve ser estudada [17].
Figura 2.1: Representação em fluxograma de um sistema ciber-físico, contendo seus elemen-tos e as relações de troca de informação entre eles.
Fonte: [17]
com-putação, comunicação e dinâmicas físicas, e são geralmente projetados na forma de uma rede de elementos com saídas e entradas bem definidas, conforme apresen-tado na Figura 2.1. Um dos maiores desafios presentes no desenvolvimento desses sistemas reside justamente na sua heterogeneidade, pois as diferentes áreas de en-genharia envolvidas possuem práticas de projeto e preocupações consideravelmente diferentes. Assim, o projeto de um CPS deve considerar os requisitos impostos pelos diferentes subsistemas que o compõe, e ser capaz de explorar as possibilidades de projeto destes de maneira colaborativa, delegando responsabilidades ao elementos físicos e de software analisando suas relações.
No contexto de AWE, a natureza do processo físico impõe algumas restrições aos seus componentes cibernéticos devido às suas condições de operação, especifica-mente às unidades de computação de controle de voo. Requerimentos em suas di-mensões, peso, consumo de energia, capacidade de processamento e de interação com sistemas periféricos1 são comuns e acabam por tornar usual a utilização de
sis-temas embarcados em aplicações de AWE [18].
2.1.1
Sistemas embarcados
Sistemas embarcados são definidos como dispositivos baseados na utilização de microprocessadores ou microcontroladores que combinam hardware e software vi-sando a realização de tarefas específicas, em contraste ao propósito generalista pre-sente em computadores pessoais [19]. Utilizados para controlar, monitorar ou auxiliar um sistema, seja esse uma máquina, equipamento ou instalação, os mesmos formam uma classe heterogênea com relação suas características construtivas, as quais são fortemente correlacionadas à sua aplicação.
Usualmente, devido a preocupações com a potência consumida, dimensões físi-cas, robustez e custo unitário, os mesmos possuem capacidade de processamento e armazenamento limitadas, o que torna o seu desenvolvimento significativamente mais complexo [20]. Contudo, em casos onde o tamanho ou a eficiência energética não são as preocupações principais, seus componentes podem inclusive ser compatíveis aos utilizados em computadores de propósito geral, como é o caso dos chamados compu-tadores de placa única (Single board computers (SBC), em inglês)2. A vantagem dessa
1Nesse caso, o termo periféricos se refere a todos os componentes do sistema à exceção da uni-dade de computação, como por exemplo sensores, atuadores ou outras uniuni-dades de computação, que embora sejam responsáveis por tarefas distintas também integram o sistema ciber-físico.
2Usualmente SBCs são utilizados de forma embarcada em aplicações de propósito específico, caracterizando-os portanto como sistemas embarcados, apesar de suas características semelhantes a de computadores de propósito geral. São exemplos de SBCs os sistemas Raspberry Pi, Beaglebone ou Arduino [21–23]
abordagem reside justamente na possibilidade da utilização de componentes de hard-ware de baixo custo em conjunto com as mesmas ferramentas de desenvolvimento de software tradicional, característica a qual é valiosa em processos de prototipagem, por exemplo.
2.1.2
Sistemas de tempo real
Em adição às características acima mencionadas, sistemas embarcados também costumam envolver restrições temporais em suas aplicações, o que os caracteriza como sistemas de tempo real [20]. Sistemas de tempo real são definidos como siste-mas onde a exatidão ou correção de uma computação não está relacionada apenas ao seu método de execução, mas também aos tempos que a envolvem. A sua classi-ficação , assim como de seus deadlines temporais, se dá através das consequências do não cumprimento de um deadline. Em sistemas críticos, um único deadline não cumprido significa falha total no sistema, como é o caso de diversas aplicações avi-ônicas ou militares. Em sistemas não-críticos, a utilidade do resultado é degradada com a perda de um deadline, afetando a qualidade do serviço provido, sem causar falhas catastróficas ao sistemas, como é o caso de sistemas telefônicos por exemplo. Uma terceira categoria classifica os sistemas intermediários, onde falhas em deadlines não significam necessariamente uma falha total no sistema, mas sim a inutilidade da operação realizada [24].
2.2
Sistemas operacionais
Computadores modernos, inclusive os que compõem sistemas embarcados, são compostos tanto por elementos de hardware quanto de software. Os elementos de hardware são definidos como sendo os componentes físicos do sistema, como por exemplo processadores, memória de armazenamento, dispositivos de I/O (entrada e saída), interfaces de rede e dispositivos periféricos. Já os elementos de software são definidos como sendo os componentes lógicos do sistema, os quais controlam o fun-cionamento do mesmo e, consequentemente, dos elementos de hardware. Contudo, tais sistemas podem ser extremamente complexos, o que torna árdua a tarefa de ge-renciar o acesso, garantir a correta utilização, e otimizar os recursos de hardware disponíveis. Com o intuito de simplificar tal tarefa, surgiram os chamados sistemas operacionais [25].
Os sistemas operacionais (SO) são a primeira camada de software que opera so-bre o hardware. A Figura 2.2 exemplifica tal definição, representando o computador
em camadas de hardware e software, subdividindo essa em dois modos diferentes. O modo Kernel agrupa os elementos de software que possuem acesso total a todo o hardware do sistema, podendo executar qualquer instrução que a máquina é capaz. O modo de usuário (user mode, em inglês) envolve os demais componentes de software, como por exemplo programas de aplicação desenvolvidos por usuários, onde apenas um subconjunto de instruções está presente. Portanto, o SO é responsável por de-sempenhar duas tarefas distintas: fornecer aos programas de aplicação um conjunto de recursos abstrato, limpo e consistente, ao invés do acesso direto aos recursos de hardware; e realizar o gerenciamento adequado e eficiente dos mesmos, fornecendo de maneira ordenada e controlada a alocação de processadores, de memória e/ou dispositivos I/O aos programas de aplicação em execução [26].
Figura 2.2: Representação da divisão de um computador em camadas de hardware e soft-ware.
Fonte: [26]
Portanto, o sistema operacional opera justamente como a fundação para o de-senvolvimento e execução de aplicações de software, proporcionando ao desenvolver liberdade e todo o suporte necessário para tal através de estruturas definidas por cha-madas de sistema.
2.2.1
Linux
A filosofia Unix3 surgiu com o propósito de definir um conjunto de regras
minima-listas a fim de projetar um sistema operacional compacto e potente com uma interface de serviços simples [26]. Assim, tal filosofia enfatiza a construção de código simples, curto, claro, modular e extensível, o qual pode ser mantido e adaptado por desenvolve-dores que o utilizam, e não apenas seus criadesenvolve-dores. O Linux é um sistema operacional gratuito e de código aberto baseado em Unix que foi desenvolvido com o intuito de proporcionar aos seus usuários um ambiente com maior controle, simples, elegante e consistente, de maneira a facilitar o desenvolvimento de aplicações sofisticadas de software [28].
Figura 2.3: Representação da divisão em camadas de um sistema computacional utilizando o sistema operacional Linux.
Fonte: [26]
2.2.1.1 Estrutura geral
A Figura 2.3 apresenta a estrutura geral de um sistema Linux. A camada de hard-ware contém os elementos físicos do sistema, como processadores e outros disposi-tivos. Interagindo diretamente com tais elementos se encontra a camada do sistema operacional, o núcleo (kernel, em inglês), cuja função é controlar estes elementos e fornecer às camadas superiores uma interface de comunicação que permite aos de-mais programas a criação e gerenciamento de processos, arquivos e outros recursos de baixo nível [25].
3O Unix é uma família de sistemas operacionais multitasking e multiuso para computadores derivada do sistema Unix AT&T, desenvolvido em meados dos anos 1970 [27]
Figura 2.4: Representação simplificada do kernel Linux. Fonte: [26]
O sistema Linux faz uso de um kernel monolítico, o qual está representado na Fi-gura 2.4 e é descrito detalhadamente em [26]. De maneira simplificada, o mesmo pode ser divido em três módulos principais, os quais são divididos em submódulos: Entra-da/Saída(Input/Output (I/O), em inglês), gerenciamento de memória e gerenciamento de processos.
O componente de I/O contém os módulos responsáveis pela interação com ou-tros dispositivos e realização de tarefas de rede e armazenamento. Uma camada de abstração denominada sistema de arquivos virtual é utilizada a fim de padronizar o acesso ao diversos tipos de arquivos presentes. O componente de gerenciamento de memória é responsável por manter o mapeamento entre as memórias física e vir-tual, armazenando e gerenciando de forma eficiente o cache de páginas, neste caso, blocos atômicos de memória virtual. O componente de gerenciamento de processos é responsável basicamente pela criação e término de processos, além do escalona-mento do uso do processador e do trataescalona-mento de sinais, os quais são provenientes de programas das camadas superior do sistema.
O kernel Linux faz uso do tratamento de interrupção para se comunicar diretamente com os dispositivos de hardware, ao passo que a comunicação com as camadas de software de alto nível é realizada através de chamadas de sistema. Outra caracte-rística interessante do kernel é o conceito de módulos capazes de serem carregados
durante a execução do sistema, cujo conteúdo varia desde drivers de dispositivo até sistemas de arquivos ou protocolos de rede.
2.2.1.2 Sistema de arquivos
Fundamental para o sistema Linux, o sistema de arquivos é responsável por im-plementar um recurso em software que não existe no hardware. O hardware fornece simplesmente espaço em disco, na forma de setores que podem ser acessados indi-vidualmente, em uma ordem aleatória. O conceito de arquivo, muito mais útil que um o simples espaço em disco, é uma abstração, um recurso lógico criado pelo sistema operacional a partir dos recursos físicos existentes no sistema computacional [25]. De forma mais específica, sua função é controlar como os dados utilizados pelo sistema são armazenados e acessados.
Arquivos são definidos na literatura como unidades lógicas de informação criadas por processos, ou seja, são mecanismos de abstração que permitem o armazena-mento e acesso organizado às informações presentes na memória [25, 26]. Além dos tipos de arquivos convencionais, como os de texto, imagens ou programa compilados, os diretórios, partições e drivers de dispositivos de hardware também são arquivos no sistema Linux. Os diretórios e arquivos são organizados de maneira hierárquica, formando uma espécie de árvore e para escrever ou ler de arquivos, descritores de ar-quivos são atribuídos a estes. Dispositivos de I/O são acessados através de arar-quivos especiais, contendo as informações necessárias para a identificação dos mesmos.
2.2.1.3 Distribuições
Referenciado como um sistema operacional, o nome Linux tecnicamente faz refe-rência apenas ao seu kernel, mas, popularmente, este nome designa o sistema ope-racional como um todo, ou seja, o kernel, os programas de sistema e aplicações. O conjunto completo de software mais o kernel Linux constitui o que se denomina de distribuição Linux, como por exemplo as distribuições RedHat, Debian, Ubuntu e Suse [25].
Todas essa distribuições fornecem uma versão do kernel Linux, um conjunto de software e uma interface de instalação. A diferença entre elas reside justamente nes-ses dois últimos pontos. O conjunto de software varia de distribuição para distribuição, assim como seus métodos de instalação e manutenção. A escolha da distribuição mais adequada para o desenvolvimento de uma aplicação depende fortemente da experiência da equipe de desenvolvedores assim como dos requisitos do sistema.
2.2.2
Processos e threads
Peças fundamentais para o funcionamento da computação moderna como a co-nhecemos hoje, os processos são geralmente definidos como instâncias de um pro-grama em execução. Esses podem representar tanto a execução de tarefas do próprio sistema operacional (daemons, por exemplo) como tarefas de aplicações, e é através deles que o sistema operacional organiza suas tarefas de gerenciamento [25].
Cada processo é associado ao seu próprio espaço de endereçamento, que nada mais é do que uma lista de endereços na memória disponíveis para serem manipu-lados, e a um conjunto de recursos e informações necessárias para a execução do programa. Enquanto que o programa em si é composto por uma série de instruções a serem realizadas, o processo pode ser visto como a efetiva execução destas. Tal abs-tração é fornecida pelo sistema operacional e permite a realização de operações de maneira pseudoconcorrente, por meio do processo de virtualização da unidade cen-tral de processamento ou CPU (Cencen-tral Processing Unit, em inglês). Através do es-calonamento da execução dos diferentes processos ativos, basicamente executando sequencialmente cada um destes por um pequeno período de tempo, o sistema ope-racional cria a ilusão de que existem CPUs virtuais enquanto que fisicamente existe apenas uma, conforme representado na Figura 2.5. Sistemas que possuem mais de uma CPU são capazes de executar processos de forma verdadeiramente paralela, pois cada CPU processa os dados de forma independente.
Figura 2.5: A abstração de processo de um sistema operacional. Fonte: [25]
Assim como os processos permitem a abstração da CPU, permitindo múltiplas aplicações operarem de maneira quase paralela, as chamadas threads fornecem a mesma funcionalidade ao processo, permitindo com que cada um destes realize múl-tiplas tarefas sem abrir mão de seu pseudoparalelismo. Essencialmente, threads são
subdivisões pertencentes a um processo, as quais compartilham o seu espaço de en-dereçamento e recursos disponíveis, sendo também escalonadas pelo sistema opera-cional. Por serem mais leves que os processos, as threads são mais fáceis de criar e destruir, e em alguns casos o tempo necessário para criar uma thread é na ordem de 10 à 100 vezes menor do que o necessário para a criação de um processo [26].
2.3
Mecanismos de comunicação
Conforme supramencionado, os sistemas ciber-físicos são usualmente compos-tos por uma ou mais unidades computacionais. Nesse âmbito, o termo periférico se refere a qualquer dispositivo que interage de alguma forma com a unidade computa-cional, como por exemplo, outras unidades computacionais que compõem o sistema, ou dispositivos de hardware na forma de sensores ou atuadores. Assim, de forma a desempenhar suas funções específicas, uma unidade computacional, através de mecanismos e interfaces de comunicação, deve ser capaz de garantir a troca de infor-mações de forma organizada e controlada.
De forma análoga ao CPSs, a unidade computacional é composta por diversos processos distintos, os quais possibilitam a realização de tarefas de forma pseudopa-ralela utilizando de fato apenas uma única CPU física. Considerando que a grande maioria das aplicações computacionais não triviais envolve a presença e interação de múltiplos processos, a definição e análise de mecanismos de comunicação entre esses também é de suma importância.
2.3.1
Comunicação entre processos
O termo comunicação entre processos (Interprocess Communication (IPC), em in-glês) tradicionalmente se refere aos diferentes mecanismos para troca de mensagens entre os diferentes processos em execução em algum sistema operacional. A Figura 2.6 apresenta três princípios básicos fornecidos pelo sistema Linux para tal: compar-tilhamento de informação por meio de um arquivo que reside no sistema, o qual é acessado através do kernel; compartilhamento de informação que reside no kernel do sistema; ou uma região de memória compartilhada entre os processos [29].
Os mecanismos de IPC são classificados baseando-se em requerimentos do soft-ware, como performance ou modularidade, e em circunstâncias do sistema, como largura de banda e latência. Entre si, eles diferem-se com base em restrições de comunicação, de manipulação dados e de número de processos suportados pelo me-canismo.
Figura 2.6: Três maneiras básicas de realizar a comunicação entre processos no sistema Linux.
Fonte: [29]
2.3.1.1 Arquivos
Processos podem realizar a troca de informações através do compartilhamento de informações contidas em algum arquivo do sistema de arquivos. Para isso, os dife-rentes processos que desejam acessar e manipular os arquivos utilizam uma interface de comunicação provida pelo kernel do sistema. Contudo, se faz necessária a sin-cronização do acesso ao arquivo compartilhado, de maneira a proteger a integridade dos dados em situações de múltiplos processos realizando ações de escrita, ou de um processo realizando ação de leitura enquanto outro realiza ação de escrita.
2.3.1.2 Soquetes de domínio Unix
Em se tratando do sistema operacional Linux, tais soquetes (sockets, em inglês) são pontos finais de comunicação para a troca de dados localmente entre processos executando no sistema operacional. Além de suportar a transmissão ordenada e se-quencial de um fluxo de dados, sem a garantia de delimitação entre as mensagens, os sockets suportam também a transmissão de datagramas, sem a garantia de sequên-cia ou entrega dos mesmos, porém garantindo a delimitação entre as mensagens. A identificação do socket se dá através de um caminho de diretório, e todas as comuni-cações ocorrem por intermédio do kernel do sistema operacional. Para compartilhar os soquetes e estabelecer a comunicação, os processos se referem aos mesmos atra-vés de inodes, que são estruturas de dados que descrevem um objeto do sistema de arquivos.
2.3.1.3 Fila de mensagens
A fila de mensagens pode ser vista como uma lista encadeada de mensagens, a qual permite a comunicação assíncrona entre múltiplos processos através de ações
de escrita e leitura. Esta oferece espaço dentro do sistema para o armazenamento das mensagens até que o receptor ou receptores estejam prontos para lê-las, sem limitar o tamanho das mensagens a serem transmitidas. Por ser assíncrono, não é necessário aos processos interagir ao mesmo tempo com a fila de mensagens, e a existência da fila permite com que os mesmos não dependam de uma conexão direta para se comunicar.
2.3.1.4 Pipes
Em sistemas Linux, pipes são canais de transmissão de dados unidirecionais os quais utilizam o sistema de entrada e saída de arquivos do sistema operacional. Os pipes são capazes de conectar processos através de suas saídas padrão, pré-conectadas no início da execução dos mesmos. Assim, a conexão é possível ape-nas entre processos diretamente relacionados através de um processo ancestral em comum. Os pipes nomeados, através da utilização caminhos de diretório para sua identificação, possibilitam a comunicação de processos não relacionados. Apesar de serem fundamentalmente unidirecionais, a criação de dois pipes distintos possibilita a comunicação bidirecional entre processos.
2.3.1.5 Memória compartilhada
A comunicação através de memória compartilhada é a forma mais rápida de co-municação entre processos disponível. Uma vez que a memória é mapeada para a região de endereçamento dos processos os quais irão compartilhá-la, o kernel não tem mais papel ativo na troca de informação entre os processos. Contudo, tal mecanismo usualmente exige a presença de alguma forma de sincronização e coordenação entre os processos que estão armazenando e buscando informação na região de memória compartilhada.
2.3.2
Interfaces de Entrada e Saída
As interfaces de entrada e saída de um sistema são responsáveis pela comunica-ção deste com dipositivos periféricos, sejam estes dispositivos de instrumentacomunica-ção ou outras unidades computacionais. Tais interfaces de comunicação geralmente utilizam as camadas de rede ou as camadas físicas do sistema [26]. A seguir são descritos alguns exemplos de protocolos.
2.3.2.1 UDP
O User Datagram Protocol (UDP) é um protocolo simples da camada de transporte o qual permite que a aplicação escreva um datagrama encapsulado num pacote, e então enviado ao destino. Um datagrama é uma entidade de dados completa e inde-pendente que contém informações suficientes para ser roteada da origem ao destino sem precisar confiar em trocas anteriores entre essa fonte, a máquina de destino e a rede de transporte. Mas não há qualquer tipo de garantia que o pacote irá chegar ou não.
Caso garantias sejam necessárias, é preciso implementar uma série de estruturas de controle, tais como timeouts, retransmissões, acknowledgements ou controle de fluxo, etc. Cada datagrama UDP tem um tamanho e pode ser considerado como um registro indivisível. Sendo um serviço sem conexão, não há necessidade de manter um relacionamento longo entre cliente e o servidor. Assim, um cliente UDP pode criar um socket, enviar um datagrama para um servidor e imediatamente enviar outro datagrama com o mesmo socket para um servidor diferente. Da mesma forma, um servidor poderia ler datagramas vindos de diversos clientes, usando um único socket.
2.3.2.2 TCP
O Transmission Control Protocol (TCP) é um protocolo orientado a conexão que provê um fluxo de dados confiável e ordenando entre dois elementos conectados à mesma rede. Para realizar a transmissão entre dois elementos da rede, o protocolo TCP define três etapas durante o processo: estabelecimento de conexão, transferên-cia de dados e término de conexão. Cada etapa é projetada de maneira a garantir a robustez e a confiabilidade do protocolo, seja através de confirmações e autenticações da conexão na etapa de estabelecimento ou através de mecanismos como códigos de-tectores de erros na etapa de transmissão. Assim, o protocolo TCP garante que todos os dados recebidos são idênticos aos enviados, inclusive com relação ao seu orde-namento. Devido à suas características, o protocolo TCP é indicado para aplicações sensíveis a falhas na comunicação, e em situações em que características temporais não são críticas ao seu funcionamento.
2.3.2.3 WebSocket
WebSocket é uma tecnologia que permite a comunicação bidirecional por canais full-duplex sobre um único socket Transmission Control Protocol. Ele é projetado para ser executado em browsers e servidores web que suportem o HTML5, uma linguagem
para estruturação e apresentação de conteúdo para internet, mas pode ser usado por qualquer cliente ou servidor de aplicativos.
2.3.2.4 UART
Um Universal Asynchronous Receiver/Transmitter (UART) é um dispostivo de hard-ware capaz de se realizar comunicação serial assíncrona onde o formato dos dados e as velocidades de transmissão são configuráveis. Em conjuntos com os UARTs geral-mente são utilizados padrões para definir características elétricas de drivers e recepto-res usados na comunicação serial, dado que os UARTs utilizam interfaces separadas para converter seus sinais lógicos de e para os níveis de sinais externos.
Usualmente, UARTs são um, ou parte de um, circuito integrado, e funcionam atra-vés da coleta e transmissão de bytes de dados como bits individuais de forma sequen-cial. Ao chegar no destino, um segundo UART reconstrói os bits recebidos formando os bytes de dados originais.
2.3.2.5 SPI
Serial Peripheral Interface (SPI) é uma especificação de interface de comunicação serial síncrona usada para comunicação de curta distância onde o formato e tamanho das mensagens são configuráveis. Os dispositivos SPI comunicam entre si através de canais full-duplex usando uma arquitetura mestre-escravo com um único mestre. O dispositivo mestre origina o quadro para a leitura e a escrita. Múltiplos dispositivos escravos são suportados através de selecção com linhas de selecção de escravos individuais, denominadas SS.
2.3.2.6 I2C
O Inter-integrated Circuit (I2C) é um barramento serial multimestre para a conexão de periféricos com baixa velocidade comunicação. O I2C faz uso de canais bidireci-onais, uma linha serial de dados e uma linha serial de clock. No I2C são definidos dois papéis para os nós: mestre ou escravo. Os mestres são responsáveis por gerar o sinal de clock e iniciar a comunicação com os escravos, que por sua vez recebem o sinal de clock e respondem quando endereçados por um mestre.
O I2C também define alguns tipos básicos de mensagens, as quais sempre pos-suem um bit de começo e de parada específicos: uma mensagem única onde o mestre envia dados para o escravo, uma mensagem única onde o mestre lê dados do escravo e mensagens combinadas onde o mestre envia pelo menos dois comandos de leitura ou escrita para um ou mais escravos.
2.4
Arquiteturas de software
Conforme apresentando anteriormente, sistemas computacionais tendem a pos-suir estruturas de software complexas, e a concepção e representação dessas não é trivial. A arquitetura de software de um sistema computacional se refere justamente às estruturas fundamentais relacionadas ao software deste, à sua documentação, e ao seu processo de criação. Tais estruturas, essenciais à análise lógica e racional do sistema, consistem dos elementos do software, suas relações, e as propriedades dos elementos e dessas relações, em conjunto com a fundamentação das decisões que envolvem a introdução e a configuração de cada elemento [30]. De forma geral, a arquitetura de software de um programa ou sistema computacional pode ser vista como uma representação ou abstração do mesmo, no sentido de auxiliar e fundamen-tar a compreensão de seu comportamento, excetuando detalhes de sua implementa-ção [31].
Através da definição e estruturação de uma solução que atende os requisitos téc-nicos e operacionais do sistema em desenvolvimento, a arquitetura tem papel funda-mental na otimização de características envolvendo decisões críticas, como questões de segurança, performance, capacidade de gerenciamento, confiabilidade e flexibili-dade. Tais características tendem a ser tão importantes quanto a garantia de que o software é capaz de gerar o resultado correto, e as decisões que as envolvem pos-suem grande impacto na qualidade, manutenção, performance, e por conseguinte, no sucesso da aplicação [32].
Mesmo não tendo relação direta com a funcionalidade da aplicação, essas ques-tões influenciam diretamente a dinâmica da criação e definição da arquitetura do soft-ware do sistema, pois projetá-la de forma eficiente envolve a devida compreensão do problema a ser resolvido em conjunto com suas possíveis soluções [30]. Por exem-plo, caso seja necessário executar em alta performance, o sistema deve ser capaz de explorar a decomposição das tarefas através de processos cooperativos executando de forma paralela, gerenciando mecanismos de comunicação entre estes ou da rede, bem como acessos à memória. Caso seja necessário operar com alta precisão, deve-se considerar a maneira como os dados são tratados e fluem pelo sistema. Caso a segurança seja crítica, o sistema deve possuir relações que permitam a legislação de restrições entre as partes do sistema, identificando seções críticas e o poder de acesso atribuído aos elementos. Caso seja necessário garantir alta flexibilidade e por-tabilidade ao sistema, o sistema deve ser projetado considerando as relações entre as partes e como mudanças individuas podem afetar o desempenho e funcionalidades do sistema. Caso o sistema deva ser implementado de forma incremental, através da publicação de sucessivos subconjuntos, o mesmo deve evitar a presença de
interde-pendências diretas entre unidades.
Portanto, o objetivo da arquitetura de software é identificar os requisitos que afetam a estrutura da aplicação, de forma a reduzir os riscos envolvidos na construção de uma solução técnica. A eficiência do projeto, ou design, está intimamente associada à sua flexibilidade frente às mudanças naturais que ocorrem em tecnologias de hardware e software com o tempo, assim como em seus requisitos [32].
2.4.1
Estilos e padrões
Um estilo de arquitetura, nesse âmbito, pode ser definido como a especificação dos tipos de elementos que compõe a arquitetura e de suas relações, em conjunto com a descrição das propriedades e das restrições que se aplicam aos mesmos [33]. Mui-tas vezes denominados padrões de arquitetura, alguns estilos podem ser aplicados a todo sistema de software, como é o caso da decomposição em módulos, pois todo sistema acaba sendo decomposto em módulos de forma a distribuir as tarefas a serem realizadas. Sob essa perspectiva, apesar da capacidade de alguns estilos de arqui-tetura de software em atender aos requisitos de diferentes sistemas computacionais, a complexidade e pluralidade destes acaba por tornar usual a combinação de esti-los especializados, cada qual é capaz de satisfazer as características e necessidades específicas impostas pelos sistemas.
Contudo, muitos fatores influenciam a escolha dos estilos de arquitetura que me-lhor se adaptam a uma aplicação. Esses fatores geralmente incluem a capacidade de projeto e implementação por parte da equipe de projeto, as competências e expe-riência dos desenvolvedores, assim como as limitações de recursos de infraestrutura disponíveis para o processo de criação e manutenção da aplicação. As subseções a seguir apresentam alguns desses padrões relevantes no contexto deste trabalho e suas características, conforme os conceitos apresentados em [32].
2.4.1.1 Cliente e servidor
O estilo de arquitetura baseado em cliente/servidor é utilizado para caracterizar sistemas distribuídos que envolvem a utilização de sistemas distintos do tipo cliente e servidor, conectados através de uma rede. A forma mais simples desse padrão é composta por uma aplicação servidor a qual é acessada diretamente por múltiplos clientes. Outras variações incluem aplicações Client-Queue-Client, onde o servidor serve apenas como canal de comunicação de dados entre múltiplos clientes distintos, armazenando as informações e gerenciando seu acesso, assim como aplicações peer-to-peer, desenvolvida com base no estilo Client-Queue-Client, permitindo com que
o cliente e o servidor alternem seus papéis a fim de distribuir as informações entre múltiplos clientes.
Suas principais vantagens estão relacionadas a centralização das informações no servidor, que apesar de reduzir a flexibilidade do sistema em comparação a outros estilos, oferece maior segurança, facilidade de gerenciamento da informação, assim como manutenção.
2.4.1.2 Orientado a objetos
O estilo de arquitetura orientado a objetos é um paradigma baseado na divisão de responsabilidades de uma aplicação ou sistema em objetos individuáveis reutilizáveis e auto-suficientes, cada qual contendo os dados e o comportamento relevantes a si. Um projeto baseado em orientação a objetos percebe o sistema como uma série de objetos cooperativos, ao invés de um conjunto de rotinas ou instruções. Além disso, objetos são discretos, independentes e fracamente acoplados; se comunicam através de interfaces , invocando métodos ou acessando propriedades em outros objetos, ou enviando e recebendo mensagens. Dentre as principais características desse estilo, destacam-se:
• Abstração: isso permite a redução da complexidade de uma operação através de uma generalização que retém suas características básicas, por exemplo atra-vés da criação de métodos para o compartilhamento de informações específicas entre objetos;
• Herança: objetos podem herdar de outros objetos, e utilizar tais funcionalidades como suas próprias ou sobrescrevê-las a fim de implementar um novo compor-tamento;
• Polimorfismo: isso permite a substituição de comportamentos de um tipo básico que suporta operações na aplicação através da implementação de novos tipos que são intercambiáveis com o objeto existente;
As principais chamarizes desse padrão de arquitetura são a sua compreensibili-dade, devido ao mapeamento próximo da aplicação à objetos reais; a sua capacidade de reutilização, através da sua abstração e polimorfismo; e sua alta coesão.
2.4.1.3 Baseado em componentes
O estilo de arquitetura baseado em componentes está relacionado com o processo de projeto e desenvolvimento do sistema, no sentido de que seu foco é a decompo-sição do projeto em componentes lógicos ou funcionais individuais, os quais expõe
interfaces de comunicação bem definidas contendo métodos, eventos e propriedades. Assim forncendo um nível maior de abstração em relação aos princípios de projeto orientados a objetos, abstraindo seu foco de questões como protocolos de comuni-cação ou estado compartilhado. Os princípios fundamentais desse estilo residem na utilização de componentes que possuem as seguintes características:
• Reutilização: os componentes são usualmente desenvolvidos de forma a permi-tir sua reutilização em diferentes cenários e diferentes aplicações, sendo possível também o projeto de componentes específicos para algumas tarefas;
• Substituição: os componentes devem ser prontamente capazes de serem subs-tituídos;
• Condições de operação: componentes devem ser projetados a fim de opera-rem em diferentes ambientes e contextos. Informações específicas, como infor-mações de estado do sistema, devem ser passados ao componente ao invés de serem acessadas por ou incluídas neste;
• Extensibilidade: um componente pode ser estendido a partir de componentes existentes a fim de fornecer novas funcionalidades;
• Independência: componentes são projetados de forma a possuir o menor ní-vel de dependência possíní-vel de outros componentes. Assim, eles podem ser utilizados ou alterados sem afetar outros componentes ou sistemas;
Arquiteturas baseadas em componentes comumente gerenciam os mesmos ,e suas interfaces através da troca de mensagens ou comandos entre eles, e em alguns casos mantendo seu estado. As principais vantagens de tal abordagem estão na sua facilidade de implementação, devido a possibilidade de substituição de componentes sem afetar o sistema como um todo; no seu custo reduzido, através da utilização de componentes de terceiros já desenvolvidos; no seu desenvolvimento, pois suas in-terfaces bem definidas auxiliam o processo de desenvolvimento de outras partes do sistema ao fornecer funcionalidades definidas; na sua reutilização, pois múltiplos sis-temas ou aplicações podem reaproveitar uma única implementação; assim como a atenuação da complexidade técnica na detecção de eventuais falhas ou problemas e sua soluções.
2.4.1.4 Dividido em camadas
Arquiteturas dividas em camadas tem seu foco em agrupar funcionalidades rela-cionadas dentro de uma aplicação em camadas distintas que são sobrepostas verti-calmente. As funcionalidades dentro de cada camada se relacionam através de uma
