Departamento de Informática e Matemática Aplicada Bacharelado em Ciência da Computação
Tolerância a Falhas em Sistemas Embarcados
Baseados em Microcontroladores
Wanderson Ricardo de Medeiros
Natal-RN Junho de 2018
Tolerância a Falhas em Sistemas Embarcados Baseados
em Microcontroladores
Monogra a de Graduação apresentada ao Departamento de Informática e Matemática Aplicada do Centro de Ciências Exatas e da Terra da Universidade Federal do Rio Grande do Norte como requisito parcial para a ob-tenção do grau de bacharel em Ciência da Computação.
Orientador(a)
Profa. Dra. Monica Magalhães Pereira
Universidade Federal do Rio Grande do Norte UFRN Departamento de Informática e Matemática Aplicada DIMAp
Natal-RN Junho de 2018
Medeiros, Wanderson Ricardo de.
Tolerância a falhas em sistemas embarcados baseados em microcontroladores / Wanderson Ricardo de Medeiros. - 2018. 61f.: il.
Monografia (Graduação) - Universidade Federal do Rio Grande do Norte, Centro de Ciências Exatas e da Terra, Departamento de Informática e Matemática Aplicada, Bacharelado em Ciência da Computação. Natal, 2018.
Orientador: Monica Magalhães Pereira.
1. Sistemas embarcados Monografia. 2. Tolerância a falhas -Monografia. 3. Microcontroladores - -Monografia. I. Pereira, Monica Magalhães. II. Título.
RN/UF/CCET CDU 004.031.6
Catalogação de Publicação na Fonte. UFRN - Biblioteca Setorial Prof. Ronaldo Xavier de Arruda - CCET
seados em Microcontroladores apresentada por Wanderson Ricardo de Medeiros e aceita pelo Departamento de Informática e Matemática Aplicada do Centro de Ciências Exatas e da Terra da Universidade Federal do Rio Grande do Norte, sendo aprovada por todos os membros da banca examinadora abaixo especi cada:
Profa. Dra. Monica Magalhães Pereira
Orientador(a)
Departamento de Informática e Matemática Aplicada - DIMAp Universidade Federal do Rio Grande do Norte - UFRN
Prof. Dr. Edgard de Faria Corrêa
Departamento de Informática e Matemática Aplicada - DIMAp Universidade Federal do Rio Grande do Norte - UFRN
Prof. Dr. Márcio Eduardo Kreutz
Departamento de Informática e Matemática Aplicada - DIMAp Universidade Federal do Rio Grande do Norte - UFRN
Agradecimentos
Agradeço primeiramente a Deus e a Virgem Maria por me concederem a graça de realizar este sonho. Agradeço também a meus pais que sempre me apoiaram e não me deixaram desistir mesmo quando tudo parecia perdido. Também gostaria de agradecer ao pessoal do LABISIC, em especial à Professora Monica, por ter me orientado e oferecido a oportunidade de trabalhar no laboratório, e a Raul Silveira, meu companheiro de projeto que me ajudou a descobrir o mundocom o Connected Garden. Por m, gostaria de agradecer a todos os meus amigos que me ajudaram a seguir na minha graduação em especial à Leandro Ferreira, que me acompanha desde o ensino fundamental, a Douglas Braz e Erikson Silacier dois grande amigos que z durante minha graduação, a Judson Soares que sempre me socorreu nas principais di culdades deste trabalho e a Isabel Vieira, minha namorada e sem dúvida o maior presente que ganhei durante a minha graduação.
em Microcontroladores
Autor: Wanderson Ricardo de Medeiros Orientador(a): Profa. Dra. Monica Magalhães Pereira
Resumo
É cada vez maior o número de sistemas computacionais que nos rodeiam, deixando nossa sociedade praticamente dependente das facilidades por eles oferecidos. Sistemas Em-barcados em hardwares cada vez menores e mais compactos, presentes nos mais diversos tipos de equipamentos e utensílios, desde roupas a smartphones de última geração. Esta miniaturização só é possível graças aos avanços nas tecnologias de produção de chips, permitindo a fabricação de componentes cada vez menores como chamados microcon-troladores, que são sistemas computacionais completos encapsulados em um único chip, tão presentes no hardware dos sistema computacionais modernos. Dentre os diversos ti-pos de sistemas computacionais destacam-se os chamados sistemas críticos onde o menor erro pode causar graves prejuízos para seus usuários. Dentre os diversos tipos de sistemas computacionais destacam-se os chamados sistemas críticos onde o menor erro pode causar graves prejuízos para seus usuários como nanceiros, e, até mesmo, risco de vida. O uso de tolerância a falhas em projetos de sistemas computacionais consiste na aplicação de métodos e técnicas que visam garantir que o sistema se mantenha funcional mesmo em situações inesperadas, aumentando a con abilidade e robustez ao sistema. Este trabalho tem como objetivo a aplicação de técnicas de tolerância a falhas em sistemas embarcados baseados em microcontroladores com restrições de área, energia e custo, apresentando o impacto da aplicação destas técnicas.
System
Author: Wanderson Ricardo de Medeiros Advisor: Profa. Dra. Monica Magalhães Pereira
Abstract
The number of computing systems around us is increasing in a daily basis, turning our society more dependent of the facilities oered by them. Embedded systems are produced in even more reduced components, and found in several types of equipments and uten-sils, from clothes to last generation smartphones. This miniaturization is possible due to the advances in chip manufacture techonology. Allowing the fabrication of reduced com-ponents, such as microcontrollers, which are entire computing systems embedded in one single chip. Among the dierent types of computing systems, it is important to highlight critical systems. In theses systems, the slightest mistake can cause catastrophic conse-quences for the users. The use of fault tolerance in computing system design consists in the application of methods and techniques that aim to keep the system workng correctly even in unexpeted situations, cosenquetly, increasing reliability and system robustness. This work aims to include fault tolerance in microcontroller based embedded systems, taking into consideration area restrictions, energy and cost, demosntrating the impact on thoses aspects caused by the techniques.
Lista de guras
1 Exemplos de Placas Arduino baseadas no microcontrolador atmega328p p. 20 2 Fundamentos da Dependabilidade . . . p. 21 3 Relação entre falha, erro e defeito . . . p. 24 4 TMR simples . . . p. 27 5 TMR com replicação do votador . . . p. 28 6 Modelo Mestre-Veri cador . . . p. 28 7 Programação em n-versões . . . p. 29 8 Programação em blocos de recuperação . . . p. 30 9 Diagrama de blocos do sistema Connected Garden . . . p. 34 10 Diagrama de blocos do Módulo Embarcado . . . p. 35 11 Diagrama de uxo de dados do Módulo Embarcado . . . p. 35 12 Diagrama de blocos do Módulo Concentrador . . . p. 36 13 Diagrama de blocos do Módulo Web . . . p. 37 14 Diagrama de blocos do Módulo Embarcado com a replicação do Ardunino
Nano . . . p. 41 15 Diagrama de blocos do Módulo Embarcado com o tolerância a falhas . p. 42 16 Esquema elétrico simpli cado do Módulo Embarcado . . . p. 43
Lista de tabelas
1 Técnicas para alcançar dependabilidade . . . p. 22 2 Tabela de Custo de componentes (Versão sem tolerância a falhas) . . . p. 49 3 Tabela de Custo de componentes (Versão com tolerância a falhas) . . . p. 50 4 Comprativo de Autonomia do Sistema . . . p. 51
Lista de abreviaturas e siglas
IoT - Internet of Things
UTI - Unidade de Terapia Intensiva PC - Personal Computer
CPU - Central Processing Unit RAM - Random Aleatory Memory ROM - Read-Only Memory
RISC - Reduced Instruction Set Computer DFD - Diagrama de Fluxo de Dados
SGBD - Sistema Gerenciador de Banco de Dados TMR - Triple Modular Redundancy
NMR - N-Modular Redundancy LDR - Light Dependent Resistor RTC - Real Time Clock
UART - Universal Asynchrounous Receiver/Transmiter SDM - Surface Mount Device
Sumário
1 Introdução p. 14 1.1 Organização do trabalho . . . p. 16 2 Instrumentação Teórica p. 17 2.1 Sistemas Embarcados . . . p. 17 2.2 Microcontroladores . . . p. 18 2.2.1 O atmega328p e o Arduino . . . p. 19 2.3 Sistemas Críticos . . . p. 20 2.4 Tolerância a Falhas . . . p. 22 2.4.1 Falha, Erro e Defeito . . . p. 23 2.4.2 Tipos de Falhas . . . p. 24 2.4.3 Fases da tolerância a falhas . . . p. 24 2.4.4 Principais Técnicas . . . p. 26 2.4.4.1 Redundância em Hardware . . . p. 26 2.4.4.2 Redundância em Software . . . p. 29 3 Trabalhos relacionados p. 31 4 Metodologia p. 33 4.1 Connected Garden . . . p. 33 4.1.1 Módulo Embarcado . . . p. 34 4.1.2 Módulo Concentrador . . . p. 36 4.1.3 Módulo WEB . . . p. 374.2 Mecanismo de Tolerância a Falhas . . . p. 38 4.3 Modelo e Injeção de Falhas . . . p. 38 4.4 Mecanismo Proposto . . . p. 40 4.4.1 Implementação . . . p. 41 4.4.2 Esquemático do Hardware Embarcado . . . p. 43 4.4.3 Alterações no Módulo Concentrador . . . p. 44
5 Resultados obtidos p. 46
5.1 Alterações no projeto original . . . p. 46 5.1.1 Novos Componentes . . . p. 47 5.1.2 Área utilizada . . . p. 48 5.1.3 Custo Financeiro . . . p. 48 5.1.4 Autonomia do Sistema . . . p. 50 5.2 Experimentos com falhas . . . p. 51 5.2.1 Testes com stuck-at fault . . . p. 52 5.2.2 Testes com transition fault . . . p. 53 5.2.3 Testes com fail-stop . . . p. 53
6 Considerações nais p. 55
6.0.1 Trabalhos Futuros . . . p. 56
1 Introdução
Atualmente, vivemos em meio a uma verdadeira "inundação tecnológica"onde é cada vez maior o número de sistemas computacionais operando em nossa volta. Carros inte-ligentes que se guiam sozinhos, aspiradores de pó robóticos que limpam sua sala inteira sem que você intervenha, smartphones com processadores cada vez mais poderosos, en- m, somos frequentemente apresentados a novos e revolucionários produtos cujo cerne são sistemas computacionais.
Um dos maiores fatores para essa inundação foram os avanços na tecnologia de mi-niaturização de transistores que proporcionou um grande aumento no poder de processa-mento a nossa disposição, barateando os custo dos equipaprocessa-mentos (MATHEW; SHAFIK; PRADHAN, 2014). Frente a estes avanços, surgiu o conceito de Internet das Coisas (do inglês IoT - Internet of Things ), cujo o principal objetivo é permitir a interconexão do maior número de dispositivos fazendo com que eles se comuniquem entre si e trabalhem de forma conjunta. A possibilidade de interconectar diversos dispositivos, juntamente com a queda no preço de equipamentos como sensores, atuadores e componentes eletrônicos, atraiu a atenção de curiosos que, entusiasmados pela ideia de poder criar seus próprios sistemas e comercializá-los, deram origem ao chamado movimento maker.
Os princípios do movimento maker norteiam a ideia do faça você mesmo (do inglês do it yourself - DIY ), onde todos podem criar seus produtos, comercializá-los ou distribuí-los. Assim, basta ter uma boa ideia e implementar. Isso alavancou bastante o desenvolvimento de novos sistemas principalmente na área de sistema embarcados.
Dentre os diferentes tipos de sistemas computacionais existentes destacam-se os cha-mados sistemas críticos ou sistemas de missão crítica. Sistema crítico é todo sistema que atua sobre determinado nicho onde qualquer mal funcionamento pode acarretar em gra-ves prejuízos de natureza nanceira ou até mesmo um risco para a saúde de quem dele depende. Sistemas como o conjunto de equipamentos de uma sala de UTI - Unidade de Terapia Intensiva - ou o sistema que controla a dosagem de coquetéis químicos injetados
na corrente sanguínea de pacientes em tratamentos de quimioterapia, são exemplos de sistemas onde um único erro pode por em risco a vida humana. Um outro exemplo clás-sico é o ocorrido com o foguete Ariane 501 (HINKEL, 1996) em 1996, que se autodestruiu em menos de um minuto após o seu lançamento, e tudo por causa de um simples erro de representação numérica. Nota-se que em sistemas como este, precisamos garantir que a resposta do sistema é con ável. É neste ponto onde as técnicas de tolerância a falhas são aplicadas, com o objetivo de aumentar a con abilidade do sistema e garantir o seu correto funcionamento. Segundo (WEBER, 2001), a tolerância a falha vem com a pro-posta de garantir maior con abilidade aos sistemas computacionais, a partir de técnicas e estratégias de projeto que visam a construção de sistemas mais con áveis e robustos.
Diante da dependência que nossa sociedade tem dos sistemas computacionais, é cada vez maior o número de trabalhos que abordam o uso de técnicas de tolerância a falhas. Esse fato pode ser comprovado com uma simples pesquisa no mecanismo de busca de trabalhos acadêmicos Google Schoolar (GOOGLE, 2016) pelo termo fault tolerance. Segundo o site, em 2013, existiam aproximadamente 23.000 publicações que abordavam o tema, em 2015 esse número saltou para aproximadamente 24.500 e, em 2017, o número tornou a subir alcançando aproximadamente 33.000 publicações! Isso acontece porque, nenhum sistema computacional está livre de falhas e a garantia de que o sistema continuará a funcionar mesmo que uma falha ocorra agrega valor e con abilidade a esse sistema, o que justi ca os investimentos em pesquisas (WEBER, 2001).
Mesmo com grandes benefícios, o uso de técnicas de tolerância a falhas possui um custo. Dependendo da técnica utilizada, pode se fazer necessária a replicação de compo-nentes (de hardware e/ou software) e o uso de compocompo-nentes especí cos para tolerar as falhas, o que gera aumento no consumo energético ou ainda grandes alterações no projeto original do sistema. Todos estes ônus devem ser cuidadosamente estudados antes de se escolher a técnica de tolerância a falhas, para que se encontre um equilíbrio entre custo e benefício. Tais cuidados são ainda maiores quando se trata de sistemas embarcados mi-crocontrolados, que em geral são sistemas de baixo custo e normalmente são alimentados por baterias, o que aumenta ainda mais a di culdade na escolha da técnica a se utilizar. Para estes sistemas, a técnica escolhida deve levar em consideração sérias restrições de consumo de energia, área, e custo, dentre outras, a m de viabilizar a sua implementação (MARWEDEL, 2006). Assim, este trabalho tem como objetivo propor um mecanismo de tolerância a falhas que possa ser aplicado em sistemas embarcados baseados em micro-controladores. O mecanismo proposto deverá levar em consideração restrições de consumo de energia, área e custo. A escolha de utilizar um sistema microcontrolado se deu pelo
fato de que este tipo de sistema vem ganhando cada vez mais espaço graças às ideias do movimento maker e os conceitos por trás do IoT. Além disso, este tipo de sistema possui um custo de manutenção em geral mais baixo que sistemas com baseado em microproces-sadores, permitindo mais liberdade para fazer experimentos com replicação, que é o cerne da tolerância a falhas.
1.1 Organização do trabalho
No capítulo 2, Instrumentação Teórica, são abordados os conceitos básicos que nor-teiam os experimentos aqui apresentados. São apresentados os conceitos de sistemas crí-ticos, principais motivadores para o uso de tolerância a falhas, conceito de microcontro-ladores, pequenos elementos de processamento tão presentes em hardwares dos sistemas computacionais modernos e, nalmente, o conceito de tolerância a falhas apresentando as principais técnicas utilizadas. O terceiro capítulo apresenta um conjunto de trabalhos relacionados, aprensentando soluções presentes na literatura para problemas semelhantes. O quarto capítulo aborda metodologia utilizada para elaboração deste trabalho. Nele é apresentado o Connected Garden, um sistema que foi utilizado como plataforma de teste das técnicas propostas neste trabalho. Ao nal do quarto capítulo é apresentada uma versão do sistema de Connected Garden com suporte a tolerância a falhas, além de justi- cativas para as técnicas utilizadas. O capítulo 5 aborda os resultados dos experimentos feitos com a versão tolerante a falhas e uma análise dos resultados obtidos. Por m, o último capítulo apresenta as conclusões.
2 Instrumentação Teórica
2.1 Sistemas Embarcados
É cada vez mais comum o surgimento de novos produtos e sistemas eletrônicos a nossa disposição que proveem facilidade para os usuários ou auxiliam em rotinas do dia-a-dia. Carros inteligentes, smart tvs, câmeras digitais de última geração, fornos microondas e etc, são exemplos de dispositivos bastante utilizados. Além disso, temos o mercado de telefonia que a cada ano lança novos e mais modernos dispositivos. Segundo as previsões de (MATHEW; SHAFIK; PRADHAN, 2014), a tendência é que o mercado destes dis-positivos presencie um crescimento entre os anos de 2013 a 2018. Tais previsões podem ser con rmadas através dos resultados de um estudo publicado pela IDC (IDC, 2018) em Janeiro de 2017, onde prevê um crescimento de cerca de 2,5% no mercado brasileiro de tecnologia da informação e telecomunicações até o nal do ano (ARRAIS, 2018). Este mesmo estudo aponta que tanto o mercado de smartphone quanto IoT e Cloud também registrarão crescimento no mesmo período. IoT, Cloud, Computação Ubíqua, Computação Pervasiva, são termos que estão cando cada vez mais comuns hoje em dia. Além disso, é cada vez maior o número de pesquisas e investimentos nestas áreas por parte de grandes empresas como a Intel, Microsoft, Motorola e outras, que consideram estes termos como integrantes do que já chamam de 4a Revolução Industrial. Todos estes termos apontam
para uma classe especial de sistemas: os sistemas embarcados.
Segundo (MARWEDEL, 2006), classi cam-se como sistemas embarcados:
Sistemas de processamento de informações incorporados a produtos como carros, ce-lulares ou na fabricação de equipamentos. Tais sistemas contam com um grande número de características comuns como, restrições em tempo-real, con abilidade e restrições de requisitos
Diferente dos sistemas projetados para computadores pessoais (PC - Personal Com-puter ), os sistemas embarcados em geral são normalmente projetados com missões bem
de nidas o que impõe severas restrições de projeto. Segundo (VAHID; GIVARGIS, 1991) as principais métricas utilizadas em um projeto de sistema embarcado são:
• Custo unitário: o custo nal para a manufatura de uma unidade do sistema sem contabilizar o custo de projeto;
• Custo de Engenharia: o custo para realizar todo o projeto do sistema;
• Área ocupada: a área física ocupada pelo sistema, deve ser controlada e geralmente deve ser minimizada. Da mesma forma devem ser mensurados os recursos computa-cionais (memória de programa e de armazenamento) necessários, uma vez que eles também podem in uenciar no tamanho físico do sistema;
• Desempenho: tempo de retorno do sistema;
• Potência: energia necessária para alimentar o sistema, determinante da vida útil de uma bateria e/ou a energia necessária para resfriamento do sistema, uma vez que quanto maior a potência dissipada, maior a dissipação de calor;
• Flexibilidade: capacidade de permitir alterações no projeto sem causar grandes au-mentos no custo de projeto;
• Tempo de produção: tempo necessário para projetar e produzir o sistema deixando-o pronto para ser utilizado pelo usuário nal;
• Tempo de prototipagem: tempo necessário para produzir uma versão funcional do projeto. Pode inclusive ser mais caro que a produção de uma versão nal, mas permite testes e avaliações que resultam em melhorias para o produto nal.
• Corretude: garantia de que as funcionalidades do sistema foram implementadas cor-retamente, ou seja, as funcionalidades executam o que o cliente realmente pediu. • Segurança no funcionamento: garantia de que o sistema estará funcionando
corre-tamente e não provocará danos ou prejuízos a outros sistemas.
2.2 Microcontroladores
Microcontroladores estão presentes nos diversos sistemas de nosso dia-a-dia. Celula-res, Tablets, televisoCelula-res, geladeiras, micro-ondas, en m, podemos encontrá-los em diversos
aparelhos eletrônicos modernos. Um microcontrolador é um sistema computacional inte-grado em um único chip, contendo CPU (Central Processing Unit ), RAM (Random Access Memory ), ROM (Read-Only Memory ), periféricos de entradas e saídas, incluindo con-versores A / D e controladores de barramento (RENNELS, 1998). O fato de possuir tudo em um único chip confere grandes vantagens no uso de microcontroladores em projetos. Com eles é possível conseguir ganhos signi cativos como:
• Melhor aproveitamento de área: uma vez que os microcontroladores em geral ocupam uma área menor que a área de um processador, que possui os componentes como memória e entrada/saída separados;
• Menor consumo energético: em geral o consumo de energia de um microcontrolador é muito mais baixo;
• Menor custo de produção: essa vantagem, além de permitir a elaboração de projetos de baixo custo, possibilita o uso não só por indústrias, mas também por pro ssionais independentes e hobistas;
2.2.1 O atmega328p e o Arduino
Durante muito tempo, um dos fabricantes de microcontroladores mais famosos foi a Microchip Technology(MICROCHIP, 2018c), empresa que se popularizou com a venda dos famosos microcontroladores da família PIC(MICROCHIP, 2018d) muito usados até os dias de hoje. Recentemente, outra família de microcontroladores vem ganhando espaço principalmente, entre os estudantes e hobistas que se aventuram a fazer seus próprios produtos. São os microcontroladores da família AVR, produzidos pela ATMEL (que hoje tornou-se propriedade da Microchip). Esse crescimento da família AVR foi amplamente impulsionado pelo surgimento da plataforma Arduino, que são placas de prototipagem baseadas no microcontrolador Atmega328p (MICROCHIP, 2018a).
Entre as principais vantagens do Atmega328p estão:
• Facilidade de Implementação: Ao contrário da família PIC, os microprocessadores da família AVR não precisam de hardwares complexos para a gravação do código. • Menor Consumo: Os microcontroladores da família AVR utilizam instruções RISC
(Reduced Instruction Set Computer ), o que signi ca instruções mais simples e me-nores, o que otimiza o uso da memória e, consequentemente, o consumo de energia.
(a) Arduino Uno (b) Arduino Mini (c) Arduino Nano
Figura 1: Exemplos de Placas Arduino baseadas no microcontrolador atmega328p • Comunidade Ativa: Pelo fato do Arduino possuir muitos entusiastas existe muito
material disponível na Internet, o que diminui a curva de aprendizado e possibilita a elaboração de protótipos em um curto espaço de tempo.
Por estes e outros motivos que o sistema utilizado como alvo deste trabalho faz uso do microcontrolador atmega328p, através de placas Arduino Nano (Figura 1c), já que seu baixo custo permite teste com replicação de componentes, técnica muito utilizada em tolerância a falhas.
Além dos microcontroladores mensionados, temos diversos outros exemplos como os microcontroladores das famílias Kinetis E(NXP, 2018a), L(NXP, 2018b), M (NXP, 2018c), produzidos pela Freescale (adiquirida pela NXP Semiconductors) sendo a série E destinada a equipamentos que operam em ambientes industriais sujeito a grandes fontes de ruído; a linha xCORE-XS1-ANALOG (XMOS, 2018a) da XMOS (XMOS, 2018b) que faz uso de processadores multicores. En m, existe uma grande variedade de microcontroladores disponíveis no mercado onde a escolha de qual usar vai depender muito do projeto onde será utilizado. Um exemplo de microcontrolador que vem ganhando muito espaço em projetos envolvendo IoT é o ESP8266 (ESP, 2018) da Espressif (ESPRESSIF, 2018), isso porque ele possui bem mais recurssos que os encapsulados em um único chip: WI-FI nativo, comunicação UART, sensor de temperatura, saídas PWM, além da possibilidade de programá-lo utilizando a mesma interface do arduino e tudo isso a um baixo custo.
2.3 Sistemas Críticos
Em nossa sociedade moderna, somos extremamente dependentes de sistema computa-cionais, sendo praticamente impossível nos imaginar sem as facilidades que estes sistemas trazem para o nosso cotidiano. Imagine o que aconteceria se o sistema de um banco pa-rasse de funcionar? E se o sistema da operadora de telefonia casse um dia inteiro sem
funcionar? Sistemas como estes são de grande importância não só para grandes empresas, mas também para a sociedade como um todo. Sendo assim, torna-se vital manter estes sistemas funcionando e, no caso de uma parada não programada, garantir que o mesmo consiga se restabelecer no menor tempo possível. Sistemas como este onde uma simples paralisação ou mal funcionamento pode acarretar em imensos prejuízos para os usuários são conhecidos como sistemas críticos.
Segundo (SOMMERVILLE, 2007), um sistema crítico é aquele onde:
[...] as falhas podem resultar em perdas econômicas signi cativas, danos físicos ou ameaças à vida humana. [...]
Falhas em softwares são muito comuns e elas se originam das mais variadas fontes (erro de projeto, erro de implementação, erros de uso e etc...), por isso, quando se trata de sistemas críticos, a propriedade mais importante que se deve garantir é a dependabilidade. Essa garantia que a dependabilidade traz para os usuários se deve a suas 4 principais métricas: Disponibilidade, con abilidade, segurança e proteção. A Figura 2 foi extraída de (SOMMERVILLE, 2007) e traz as principais métricas de dependabilidade.
Figura 2: Fundamentos da Dependabilidade Fonte: Sommerville, 2007.
Tais métricas tornaram-se requisitos indispensáveis para um sistema crítico, visto que neste tipo de sistema os danos causados por uma falha ocasionam prejuízos que podem chegar a várias vezes o valor do software em si.
Diante destes requisitos o uso de técnicas de tolerância a falhas torna-se indispensável no projeto de sistemas críticos, uma vez que elas ajudam a garantir alta con abilidade através da especi cação de métricas, rearranjo de componentes do sistema e demais outras
técnicas que serão estudadas nas próximas seções.
2.4 Tolerância a Falhas
Sistemas computacionais estão inevitavelmente fadados a falhar em algum momento durante seu tempo de operação. Dependendo do sistema, as falhas podem até ser inofen-sivas, por exemplo, uma falha que gerou um erro de arredondamento de 0,001 centavos no cálculo de um sistema de venda em uma padaria. A situação se torna muito mais perigosa quando estamos falando de um sistema crítico. Basta imaginar que a mesma falha (o arredondamento 0,001 no cálculo) se deu em um sistema responsável pela injeção de combustível de um foguete espacial. Este pequeno erro pode fazer com que o sistema de injete uma quantidade de combustível maior do que a suportada pelo propulsor, fa-zendo com que ele exploda (HINKEL, 1996). Assim, falhas podem até ser inevitáveis, mas suas consequências precisam e podem ser evitadas. É para este propósito que existem as técnicas de tolerância a falhas.
O conceito de tolerância a falha é apenas uma das propriedades necessárias para se alcançar o que hoje em dia é conhecido por Dependabilidade (do inglês dependability). A dependabilidade, segundo (WEBER, 2001), é a propriedade que indica a qualidade do serviço fornecido por um dado sistema e a con ança no serviço fornecido. Esta propriedade é especialmente importante em sistemas críticos, a m de prevenir defeitos de modo transparente para o usuário ou até mesmo garantir a rápida recuperação do sistema. A Tabela 1 extraída de (WEBER, 2001), apresenta as principais técnicas para se alcançar a dependabilidade.
Tabela 1: Técnicas para alcançar dependabilidade
Prevenção de Falhas Impedir a introdução de falhas. Envolve a seleção demetodologias de projetos e de tecnologias para seus componentes Tolerância a Falhas
Fornecer o serviço esperado mesmo na presença de falhas. Técnicas comuns: mascaramento de falhas, detecção de falhas, localização, con namento, recuperação, recon guração,
tratamento
Validação Remoção de falhas, veri cação da presença de falhas Previsão de Falhas Estimativas sobre presença de falhas e estimativas sobreconsequência de falhas
É possível ver que o principal objetivo da tolerância a falhas é garantir que o sistema mantenha seu funcionamento, mesmo na ocorrência de falhas. Como este trabalho tem
foco no uso destas técnicas, as próximas seções serão dedicadas a explicar melhor cada um dos conceitos necessário para o entendimento do que é tolerância a falhas.
2.4.1 Falha, Erro e Defeito
Antes de conceituar as principais técnicas de tolerância a falhas, é necessário entender melhor a relação entre os conceitos de falha, erro e defeito.
Falhas estão ligadas a algum mau funcionamento no hardware ou má implementa-ção de algum algoritmo, sendo assim elas podem acontecer pelos mais variados fatores (WEBER, 2001), (AVIZIENIS; LAPRIE; RANDELL, 2001):
• Envelhecimento dos componentes : componentes eletrônicos não são eternos e per-dem suas propriedades com o passar do tempo.
• Deterioração dos componentes : componentes eletrônicos podem se deteriorar devido a in uência de fatores como umidade, maresia, temperatura e etc, que pouco a pouco vão desgastando-os.
• Erro de Manufatura : componentes podem apresentar erro de fabricação. • Erro durante a implementação : erro de implementação de algoritmos.
• Interferência : alguns equipamentos podem sofrer interferência eletromagnética por parte de outros equipamentos.
Por estes e outro motivos, (WEBER, 2001) a rma que nenhum sistema está totalmente livre de falhas. Sistemas projetados para atuar em ambientes hostis geralmente sofrem com diversos fatores. Um exemplo é o sistema de controle de naves espaciais, que estão sempre sujeitos a interferências dos mais diversos tipos de radiação, variações de pressão, temperatura e etc, que podem ocasionar mau funcionamento. Quando uma falha ocorre, o sistema é levado ao que chamamos de estado de erro, pois o processamento a partir deste ponto levará a uma resposta diferente da esperada, logo o termo erro se refere a um estado do sistema. Finalmente um defeito é um desvio da especi cação do sistema, ou seja, dizemos que um sistema tem um defeito quando o processamento de uma informação leva a uma resposta diferente do que foi especi cado no projeto do sistema. A Figura 3 apresenta a relação existente entre falha, erro e defeito.
Pela Figura 3 é possivel se observar bem a relação existente entre falha, erro e defeito. Uma falha ocorre por causas físicas ou algorítmicas levando o sistema a um estado de erro
Figura 3: Relação entre falha, erro e defeito
e se manifesta na forma de uma defeito, que é um desvio do que foi especi cado no projeto do sistema. A importância destes conceitos está na forma como a tolerância a falhas age em cada um deles. Assim as falhas até podem ser toleradas, mas o mesmo não se pode dizer de suas consequências pois levam o sistema a retornar informações diferentes das esperadas pelos clientes deste sistema.
2.4.2 Tipos de Falhas
De acordo com (DUBROVA, 2008) as falhas originadas em hardware são classi cadas de acordo com seu tempo de duração em Falhas permanentes e falhas transitórias. Uma falha é dita permanente quando permanece ativa até que algo seja feito para corrigi-la. Este tipo de falha tende a ser causado por defeitos em hardware como rompimentos de trilhas, curto-circuitos, componentes desgastados e são facilmente reconhecidos por rotinas de veri cação que funcionam em conjunto com o sistema.
As falhas chamadas de transitórias são assim chamadas porque ocorrem em curtos períodos de tempo, o que as tornam mais difíceis de detectar. As principais fontes deste tipo de falha estão relacionadas ao ambiente onde o hardware se encontra, por exemplo, interferências por radiação (comum em veículos espaciais e equipamentos utilizados em monitoramento de reatores nucleares), por descargas elétricas (muito comuns em aerona-ves que voam em grandes altitudes) ou ainda interferência eletromagnética causada pelas próprias vias de transmissão presentes na placa. É interessante ao projetista de um sis-tema crítico o conhecimento desta classi cação de falhas, para auxilia-lo na escolha da técnica que melhor se adequa a sua necessidade reduzindo futuros gastos com correções e adequações do sistema.
2.4.3 Fases da tolerância a falhas
Segundo (WEBER, 2001) a implementação da técnica de tolerância a falhas passa por quatro fases:
• Detecção do erro: detectar onde a falha ocorreu;
• Con namento e avaliação: Isolar o componente onde a falha ocorreu para não pre-judicar o sistema;
• Recuperação de erros: levar o sistema de um estado de erro para um estado seguro; • Tratamento das falhas: efetuar o reparo ou recon guração do sistema a m de
eli-minar a falha.
A primeira etapa da tolerância a falhas consiste em detectar se o sistema está em estado de erro ou se o processamento posterior levará a um estado de erro. Uma falha normalmente é identi cada ao se manifestar como um erro, pois, como já foi visto, esta situação iria gerar um desvio do que foi especi cado. Se a falha não se manifesta como erro, é dito que ela está latente (WEBER, 2001) e pode permanecer assim por toda a vida do sistema. Uma vez que se manifesta, a falha pode ser detectada por diversas técnicas: replicação, códigos de detecção de erro, dígito veri cador, bit de paridade, e demais outras técnicas que no geral se baseiam em de nir limites toleráveis para valores das variáveis, uma vez que esse limite é quebrado, a falha é detectada.
Depois de detectada a falha, esta precisa ser isolada para prevenir a disseminação de dados inválidos e avaliar os danos, é nisso que consiste a fase de con namento e avaliação. O con namento se faz por meio de desvio no uxo de dados da aplicação garantindo o isolamento das informações provenientes da unidade com falha, mas isto só é possível se estes desvios de dados forem parte do projeto do sistema. Assim o uso ou não de tolerância a falhas é uma decisão de projeto extremamente importante e que pode modi car toda a arquitetura projetada. Nesta fase de projeto uma boa estratégia é a análise de diagramas como DFD - Diagrama de Fluxo de Dados , Rede de Petri e outros, no qual é possível veri car como os dados e informações trafegam pelos componentes do sistema e assim decidir como fazer os desvios de uxo necessários para implementar o con namento.
Uma vez que a falha foi con nada, torna-se necessária a recuperação do erro para tirar os sistemas do estado errôneo. Essa troca de estado consiste em fazer o sistema passar para um estado livre de falhas, podendo ser feita de duas formas: recuperação por retorno e recuperação por avanço. Na recuperação por retorno, o sistema é conduzido para um estado anterior a ocorrência da falha. Esta técnica é muito utilizada em sistemas de banco de dados baseados em transações. Durante uma operação em um banco de dados o SGBD - Sistema Gerenciador de Banco de Dados inicia uma transação e começa as suas operações e quando um erro é detectado, todas as operações são desfeitas (processo
conhecido como rollback) e o banco volta ao estado em que se encontrava antes do início da transação. Já a recuperação por avanço leva o sistema a um estado posterior livre de falhas, corrigindo o estado de erro e criando o estado desejado. Este tipo de técnica é mais utilizada em sistemas de tempo real, onde retornar a informação do estado anterior já é um erro. Este tipo de tratamento geralmente utiliza redundância para evitar armazenar estado do sistema.
Por m, a última fase: o tratamento da falha. Nesta fase o objetivo é corrigir falha para que não volte a injetar informações erradas no sistema. Esta correção pode acontecer de duas formas: manual ou automatizada. Na forma manual o operador efetua troca do componente falho. Um exemplo disso pode ser visto em sistemas como os grandes datacenters, super computadores que possuem grandes pentes onde se encontram um processador e várias memórias. Ocorrendo falhas em um ou mais pentes, simplesmente se faz a troca por outro em perfeito estado sem a necessidade de parar o sistema. A troca automatizada, por sua vez é um mecanismo mais custoso e complicado, utilizado em sistemas onde a manutenção por parte de um operador é muitas vezes impossível. Neste caso se encaixam os sistemas de estações e aparatos espaciais que possuem seus próprios sistemas de reparo automatizados, mas além destes, temos ainda soluções baseadas em FPGA's (SILVA, 2015) que podem se recon gurar para resolver o problema.
2.4.4 Principais Técnicas
Aplicar uma técnica de tolerância a falha geralmente implica na replicação de um ou mais componentes do sistema. Esta redundância pode se dar tanto em software quanto em hardware, mas a ideia básica é utilizar a replicação e descobrir se houve a falha e mascará-la, fazendo com que a resposta retornada pelo componente falho seja substituída pela resposta do componente funcional.
2.4.4.1 Redundância em Hardware
A redundância em hardware é a mais comum e também a mais intuitiva técnica de tolerância a falhas. Neste tipo de técnica um componente é replicado com o objetivo de efetuar a comparação das saídas e veri car se ocorreu ou não a falha. Dentre as mais conhecidas técnicas de replicação em hardware temos: TMR - do inglês triple modular redundancy e a NMR - do inglês N-modular redundancy .
tripli-cando o hardware a ser protegido. Uma vez que o hardware foi triplicado, a saída de cada um dos componentes é ligado a um votador, que por meio de uma comparação, decide qual a saída correta. A Figura 4 apresenta a con guração mais básica do TMR, nela é possível ter uma ideia da e ciência desta técnica.
Figura 4: TMR simples
A saída de todas as entradas é mandada para o votador e, uma vez comparadas é possível detectar o componente com falha, pois sua saída é diferente da saída dos demais. Desta forma, o TMR não só mascara a falha como também pode indicar em que com-ponente ela ocorreu. Essa é uma grande vantagem da técnica, pois auxilia na correção da falha. Ainda observando a Figura 4, é possível notar que o centro dessa técnica está no votador. No TMR, o votador é quem seleciona a saída correta e (em muitos casos) é ele quem informa qual o componente deve ser substituído. Logo, percebemos que o TMR apenas muda o ponto de risco, se outrora o perigo da falha ocorria em um determinado componente, agora este risco foi transferido para o votador. Assim para que o uso do TMR seja e caz, é necessário que o votador possua uma alta con abilidade, pois quanto maior a con abilidade do votador, maior será a con abilidade do sistema. Uma das ma-neiras de alcançar alta con abilidade em um votador é a chamada votação por software, onde o votador deixa de ser um hardware e passa a ser um software remoto que recebe como entrada as saídas das unidades replicadas. Associado a essa técnica, pode-se ainda fazer a triplicação do votador em hardware e levar suas saídas a um votador por software, aumentando a con abilidade do sistema. A Figura 5 mostra a representação de um TMR com replicação do votador.
Figura 5: TMR com replicação do votador
Uma vez explicado o TMR, torna-se fácil entender o NMR, no qual, em vez de tri-plicação (como no TMR), ocorre a redundância múltipla dos componentes. Nesta técnica os componentes podem ser replicados n vezes a m de garantir a con abilidade. Vale observar que o uso do NMR pode vir a ser mais caro do que o uso do TMR, pois cada componente replicado é um acréscimo no custo nal do sistema, por isso, é importante se fazer um estudo para se veri car a viabilidade de uma ou de outra técnica.
Outra técnica também bastante utilizada se baseia em um modelo mestre-veri cador, na qual se tem dois componentes sendo que um gera a informação (o mestre) e outro veri ca se a informação está correta (veri cador), sinalizando a ocorrência do erro, como ilustrado na Figura 6. Esta técnica, diferente do TMR, não mascara a falha restringindo-se a sinalizar a ocorrência do erro.
Figura 6: Modelo Mestre-Veri cador
Os dados são replicados e utilizados como entradas para os dois componentes. Após o processamento dos dados, as saídas do componente mestre são redirecionados como entradas para o componente veri cador que compara o resultados de sua própria saída com os dados vindos do componente mestre, havendo divergência, um sinal de erro é disparado. Embora esta técnica não exija um consumo de energia tão grande quanto o TMR, ela pode se mostrar ine caz em sistemas de tempo real onde o mascaramento é mais importante.
2.4.4.2 Redundância em Software
Além das técnicas de tolerância a falhas baseadas em hardware, existem ainda téc-nicas que se baseiam em redundância por software. Diferente das téctéc-nicas utilizadas em hardware, a redundância por software não segue a ideia da replicação, pois um compo-nente de software replicado certamente irá apresentar o mesmo erro. No caso de software, as técnicas mais comuns são programação em n-versões e blocos de veri cação.
A programação em n-versões é um técnica que se utiliza de uma especi cação comum para a implementação de n-versões diferentes do mesmo componente por equipes (e mui-tas vezes até linguagens) diferentes. Assim como em um esquema de NMR, a programação em n-versões utiliza um votador para selecionar a saída correta. A utilização consiste em executar as mesmas entradas em versões diferentes do software rodando em diferentes má-quinas, estas saídas são levadas a um votador que as compara e indica qual das entradas está com a falha. Embora muito usada, a programação em n-versões possui vários fatores que in uenciam diretamente na sua e ciência (WEBER, 2001): a troca de informações entre as equipes, a busca por suporte nas mesmas fontes, adoção de métodos de progra-mação semelhantes e etc. Outro problema no uso da prograprogra-mação em n-versões é o custo de produção, uma vez que equipes diferentes devem ser contratadas para a implementação juntamente com o custo de manutenção, pois uma simples alteração deve ser replicada em cada uma das n-versões. Desta forma, deve se ter um certo cuidado ao utilizar essa técnica para evitar gastos desnecessários. A Figura 7 foi extraída de (SOMMERVILLE, 2007) e apresenta um esquema de programação em n-versões mostrando o uxo dos dados através dos componentes.
Figura 7: Programação em n-versões Fonte: Sommerville, 2007.
A programação com blocos de recuperação funciona de maneira semelhante a progra-mação em n-versões. Assim como na prograprogra-mação em n-versões, são produzidas n-versões do componente as ser protegido, mas as saídas destes componentes são submetidas a um teste de aceitação. A primeira versão é testada, se o teste identi car uma falha, a próxima versão é testada e assim por diante até que uma das versões passe no teste. Se por um lado a programação em blocos de recuperação exige menos do hardware - pois os blocos são testados em série - ela apresenta-se mais lenta que a programação em n-versões. No-vamente o uso desta técnica depende muito do problema que se quer resolver. A Figura 8 foi extraída de (SOMMERVILLE, 2007) e ilustra a estrutura de um esquema utilizando blocos de recuperação.
Figura 8: Programação em blocos de recuperação Fonte: Sommerville, 2007.
3 Trabalhos relacionados
Este trabalho tem como objetivo a aplicação de técnicas de tolerância a falhas em sistemas baseados em microcontroladores, visto que grande parte dos sistemas compu-tacionais modernos se utilizam destes componentes em suas arquiteturas. Considerando as restrições e limitações do projeto de sistemas embarcados, as técnicas de tolerância a falhas pesquisadas se baseiam tanto em software como em hardware.
Na literatura é possível observar que a grande maioria das aplicações estão voltadas para sistemas críticos e fazem grande uso de estratégias de replicação em hardware: (BA-LASUBRAMANIAN, 2016), (GOMES, 2014), (PRASAD; MASTORAKIS, 2016). Este autores apresentam soluções baseadas em TMR a nível de circuitos lógicos, objetivando o mascaramento de falhas. Em especial os trabalhos de (GOMES, 2014) e (PRASAD; MAS-TORAKIS, 2016) visam alcançar meios para reduzir o consumo de energia causado pelo uso de TMR. A um nível mais alto, temos os trabalhos de (ZHENG; ANWAR, 2007) onde é utilizado um sistema de mestre-escravo para tratar falhas em sistemas de Steer-By-Wire em veículos automotivos. Neste modelo a queda de um dos microcontroladores faz com que o outro assuma controle do sistema mascarando a falha. Esta proposta se assemelha muito com a ideia utilizada neste trabalho, mas sem a preocupação com o consumo ener-gético, visto que em (ZHENG; ANWAR, 2007) ambos os microcontroladores estão ativos. Já no âmbito de softwares, a maioria dos trabalhos se concentram em sistemas distribuídos e protocolos de comunicação:(DOBLER; CECHIN, 2016), (PASIN; RIVEILL; WEBER, 2001) e (AFONSO; SILVA; A., 2008). De modo especial em (AFONSO; SILVA; A., 2008), onde o autor apresenta uma proposta de framework para implementar soluções tolerantes a falhas baseado no uso de threads que constantemente veri cam dados de componentes do sistema.
De um modo geral a literatura corrente possui poucos textos que tratam sobre a apli-cação de tolerância a falhas em sistemas baseados em microcontroladores, concentrando-se em resolver o problema em um nível lógico ou a nível de comunicação entre sistemas, mas as ideias expostas podem ser modi cadas e levadas a um nível mais alto, permitindo seu
reuso. Nesse contexto, este trabalho buscou aliar soluções de hardware e software, con-siderando as soluções existentes e tratando o desa o de lidar com os custos adicionais de área, energia e nanceiro que a solução poderia trazer. Vale salientar que, conforme as pesquisas realizadas pelo autor, este é o primeiro trabalho que propõe uma solução de tolerância a falhas utilizando a plataforma Arduino e atuando em nível de circuito e software. Outra contribuição do trabalho proposto pouco explorada no estado da arte é a implementação de mecanismos de injeção de falhas para realizar as simulações e ava-liar a solução proposta. Neste trabalho, foram implementados três mecanismos de injeção de falhas, para os teste considerando os modelos de falha stuck-at, transition e fail-stop. Mais detalhes sobre o mecanismo de tolerância a falhas proposto podem ser encontrados no Capítulo 4.
4 Metodologia
A proposta deste trabalho é aplicar técnicas de tolerância a falhas em um sistema baseado em microcontroladores, a m de se fazer um estudo sobre o impacto da aplicação destas técnicas em um sistema pré-existente. Para possibilitar os testes e as validações é necessário um sistema funcional e com código aberto para permitir as alterações ne-cessárias para aplicação das técnicas de tolerância a falhas. Para suprir esta necessidade, foi utilizado um sistema de controle eletrônico de jardins previamente desenvolvido e de coautoria do autor deste trabalho, intitulado Connected Garden.
Neste capítulo serão detalhados o sistema Connected Garden, bem como o mecanismo de tolerância a falhas proposto e implementado no sistema.
4.1 Connected Garden
O Connected Garden é um sistema de monitoramento e controle de jardins indoors, isto é, jardins de pequeno porte normalmente cultivados em espaços internos de aparta-mentos ou casas, com pouca iluminação. A proposta do sistema é auxiliar a pessoa que deseja cultivar um jardim, mas que não possui conhecimento ou tempo necessário para esta prática. Assim, o sistema se encarrega de monitorar cada uma dos vasos de planta do jardim, armazenando e disponibilizando informações sobre a umidade do solo, lumino-sidade, umidade do ar e temperatura ambiente. Além destes indicadores, o sistema ainda conta com um mecanismo de irrigação automática que é acionado mediante as leituras de umidade do solo e con gurações feitas pelo usuário. Toda interação do usuário com o sistema é feita através de um aplicativo mobile e uma aplicação web. Através de ambos, o usuário pode veri car as informações dos sensores e ajustar a irrigação. Também é possível incluir novos vasos e remover vasos cadastrados. Bem como obter relatórios periódicos das informações monitoradas. Ao todo, o sistema é formado por 4 módulos: Módulo WEB, Módulo Mobile, Módulo Concentrador e Módulo Embarcado, ilustrados na Figura 9.
Figura 9: Diagrama de blocos do sistema Connected Garden
O Módulo Embarcado é acoplado no vaso da planta e recolhe os dados de umidade do solo, luminosidade, umidade do ar e temperatura ambiente por meio de um conjunto de sensores. Junto a estes sensores, o módulo dispõe de um atuador para acionar a irrigação automática. Depois de recolhidos, os dados são enviados para o Módulo Concentrador por meio de uma comunicação Bluetooth. O Módulo Concentrador armazena estes dados localmente e, por meio de acesso à Internet, os replica para um servidor online onde o Módulo Web está instalado, o que permite o acesso por meio de um navegador ou através do Módulo Mobile.
4.1.1 Módulo Embarcado
O Módulo Embarcado é responsável por coletar os dados das plantas através de sen-sores e enviá-los ao Módulo Concentrador para que sejam replicados e assim acessados remotamente. Este módulo consiste de uma placa de circuito impresso baseada na placa de prototipagem Arduino Nano (ARDUINO, 2018). A placa conta com uma entrada para um sensor DHT-11 (MOTA, 2018) utilizado para medir a umidade do ar e temperatura, um sensor LDR (Light Dependent Resistor) para registrar a incidência de luz, e um sensor de umidade do solo. Além destes sensores a placa ainda possui um sinal de saída para um atuador, destinado a acionar uma mini bomba d'água utilizada na irrigação automática.
A Figura 10 mostra o diagrama de blocos do Módulo Embarcado. Ao centro tem-se a placa Arduino Nano responsável pelo controle dos tem-sensores e atuadores. A placa obtém os dados dos sensores, faz um pré-processamento e os envia através de um canal de comunicação Bluetooth. O mesmo canal Bluetooth que envia os dados é utilizado para receber as instruções de controle que são enviadas pelo concentrador.
Figura 10: Diagrama de blocos do Módulo Embarcado
Devido a questões de economia de energia, foi adicionado um módulo RTC (Real Time Clock) para controlar o acionamento do Bluetooth, uma vez que este era o principal responsável pelo consumo de energia. Este módulo RTC funciona como um alarme que, de tempos em tempos, faz com que o sistema faça uma captura de dados e os envie para o concentrador, feito isso o Bluetooth é desligado.
A Figura 11 apresenta o diagrama de uxo de dados do Módulo Embarcado.
Figura 11: Diagrama de uxo de dados do Módulo Embarcado
Os dados são obtidos pelos sensores e armazenados em variáveis internas e depois são enviados para armazenamento no Módulo Concentrador. Por sua vez o Módulo Con-centrador envia dados de controle para o Módulo Embarcado onde são armazenados em outras variáveis utilizadas para a tomada de decisões como o acionamento da bomba.
4.1.2 Módulo Concentrador
O Módulo Concentrador tem este nome porque concentra todas as informações envi-adas por cada um dos módulos embarcados presentes no jardim. Este é um dos módulos mais importantes do sistema, pois além de enviar informações para o Módulo WEB, é responsável por repassar os comandos enviados aos Módulos Embarcados. Fisicamente o Módulo Concentrador trata-se de um minicomputador - Raspberry Pi(RASPBERRY, 2018), Galileo Gen 2 (INTEL, 2018), dentre outros - que executa um conjunto de serviços destinados ao controle e troca de informações entre o Módulo Embarcado e o resto do sistema. A Figura 12 apresenta o diagrama de blocos que representa a arquitetura do software presente no Módulo Concentrador.
Figura 12: Diagrama de blocos do Módulo Concentrador
A interface de acesso local permite que os usuários acessem o sistema via IP, seme-lhante ao que ocorre com roteadores domésticos. O serviço de acesso local permite que o Módulo Mobile se conecte diretamente com o Módulo Concentrador (modo o-line), possibilitando um acesso quase que em tempo real aos dados dos vasos. O serviço de comunicação Bluetooth é responsável pela comunicação entre o concentrador e os Módu-los Embarcados. Por último, observa-se o serviço de atualização que, em intervaMódu-los de tempo pré-estabelecidos envia dados ao Módulo Web. Todos estes três serviços acessam uma base de dados local que persiste os dados mais recentes de cada vaso bem como as con gurações destinadas a cada um dos Módulos Embarcados.
4.1.3 Módulo WEB
Este módulo garante ao usuário o acesso online aos dados de cada vaso, permitindo ainda a con guração do modo de operação de cada um dos Módulos Embarcados remo-tamente. É basicamente uma extensão do Módulo Concentrador, mas com um conjunto maior de funcionalidades como relatórios, grá co e con gurações cadastradas. O diagrama de blocos da Figura 13 mostra a arquitetura do Módulo Web.
Figura 13: Diagrama de blocos do Módulo Web
Basicamente, o módulo é composto por um serviço web (web service) utilizado para comunicação com o Módulo Concentrador e com o Módulo Mobile, e uma interface de acesso via navegador web do usuário.
4.1.4 Módulo Mobile
O Módulo Mobile consiste em uma aplicação Android (ANDROID, 2018) que pode se comunicar com os Módulos Web e Concentrador. Este módulo é uma cópia mais sim-pli cada do módulo web tendo as mesmas funções de con guração e exibição básica dos dados, porém, em uma versão para dispositivos móveis com algumas funcionalidades ex-tras que a plataforma Android permite, tais como, cadastro de alertas e lembretes. É um módulo relativamente simples cujo principal objetivo é alertar ao usuário caso alguma coisa esteja errada com o jardim e exibir de forma resumida a situação de cada um dos vasos do jardim.
4.2 Mecanismo de Tolerância a Falhas
O Connected Garden foi implementado em sua totalidade, concorrendo e ganhando dois prêmios em competições de sistemas embarcados: Intel Embedded Systems Competi-tion 2015 (INTEL, 2015) e Intel Cup (INTEL, 2016), provando ser um sistema completo e funcional. O sistema é projetado para monitorar jardins à distância de modo que uma falha pode levar a perda da planta monitorada. A princípio, isso não representa uma perda muito grande se estivermos falando de uma simples roseira, mas a situação pode ser mais crítica se a planta monitorada for uma orquídea ou um conjunto de plantas com custo mais elevado. Além disso, o monitoramento do Connected Garden se assemelha a vários outros sistemas, como sistemas de monitoramento de vazamento de gás, controle de caixas d'água, sinais vitais em UTI portátil, o que o deixa muito parecido com estes sistemas críticos. Por causa dessa característica, podemos considerar o Connected Garden como um sistema crítico, onde uma falha pode levar prejuízos aos usuários. Assim, neste trabalho, optou-se por utilizar o Connected Garden como sistema para a validação, estudo e aplicação de técnicas de tolerância a falhas, objetivo deste trabalho.
Uma vez aplicadas as técnicas, o novo sistema tolerante a falhas foi comparado com o modelo original, a m de estudar os impactos causados em termos de área ocupada, custo, desempenho, tempo médio de recuperação após a falha e outras métricas utilizadas em projetos de aplicações tolerantes a falha. Considerando que o sistema possui diferentes módulos e alguns deles são plataformas comerciais cujas especi cações e detalhes técnicos são proprietários, as técnicas de tolerância a falhas foram propostas nos módulos proje-tados e fabricados pelo autor, o hardware do Módulo Embarcado e o software do Módulo Concentrador. Apesar disso, considerações sobre técnicas de tolerância a falhas nos outros módulos também foram feitas.
4.3 Modelo e Injeção de Falhas
Uma das premissas básicas para a tolerância a falhas no que diz respeito a compo-nentes elétricos é que todo componente pode falhar. Isso acontece por diversos motivos: interferência devido a proximidade com outros componentes, oxidação e, é claro, o próprio tempo. Não há como escapar! Os componentes envelhecem e aos poucos vão perdendo suas propriedades até que nalmente param de funcionar ou não funcionam como deveriam. Assim ao se elaborar um projeto tolerante a falhas deve se ter em mente o que realmente é importante proteger, e mesmo assim nada garante que um projeto esteja livre de falhas,
uma vez que até os componentes usados para a proteção irão envelhecer e eventualmente falharão. Assim, os modelos de falhas adotados neste projeto consideram falhas permanen-tes com diversas causas, como migração de elétrons (electromigration), pico de voltagem, pico de temperatura, dentre outros fenômenos físicos ((DUBROVA, 2008),(ANDERSON; LEE, 1981),(AVIZIENIS; LAPRIE; RANDELL, 2001)). Tais falhas afetam os componen-tes do sistema, fazendo com que os valores obtidos durante a captura dos dados não sejam con áveis.
Foram utilizados 3 modelos de Falhas:
• Falha por valor xo (stuck-at fault): ocorre quando um determinado componente do sistema tem seu valor travado permanecendo xo em um único valor. (DUBROVA, 2008)
• Falha em transação (transition fault): ocorre quando um determinado componente tem seu resultado alterado durante a transmissão dos dados. Esse tipo de falha é bastante comum em sistema sujeitos a interferências eletromagnéticas. (DUBROVA, 2008)
• Falha por queda do sistema (fail-stop): ocorre quando algum componente do sistema não responde a requisições feita.
Além disso, como mencionado anteriormente, o elemento a ser tratado neste trabalho é o Módulo Embarcado, pois é ele quem fornece os dados de monitoramento para a aplicação inteira. Uma falha neste dispositivo e todos os demais módulos seriam prejudicados. Uma das principais decisões de projeto foi escolher o que realmente se deveria tratar: as falhas no microcontrolador ou nos sensores? Como os sensores do sistema são de custo negligenciável e podem ser facilmente trocados, decidiu-se tratar as falhas do microcontrolador.
Uma vez implementado, o modelo necessitou de uma forma de simular as falhas que podem ocorrer nos microcontroladores. Para esta simulação foram implementadas funções que geram alterações nos valores dos sensores antes de enviá-los ao concentrador. Estas funções utilizam pinos do próprio microcontrolador para desviar o uxo de execução e alterar os valores captados pelos sensores. Ao gerar valores incorretos, para ns de simulação, assume-se que o erro está no microcontrolador, acionando o mecanismo de tolerância a falhas. Outra forma de simulação de falha implementada foi a ausência do microcontrolador, que foi implementada removeno o Arduino Nano do circuito, impedindo seu acionamento.
4.4 Mecanismo Proposto
O mecanismo de tolerância a falhas proposto alia técnicas de hardware e software. As técnicas implementadas no hardware envolvem a adição de componentes replicados, bem como componentes utilizados para comparação e multiplexação. Para manter o mecanismo com custo baixo, a detecção de erro no valor dos sensores recebidos pelo microcontrolador é feita em software.
Para implementação da tolerância a falhas no Módulo Embarcado do Connected Gar-den, foi levado em consideração três fatores: o consumo de energia, a detecção do erro e o mascaramento do erro. O consumo de energia é um dos principais fatores, pois o Módulo Embarcado funciona de maneira autônoma, alimentado por uma bateria. Por este motivo é que um TMR simples pode se tornar problemático, uma vez que irá aumentar muito o consumo de energia do Módulo.
Observando o diagrama de blocos da Figura 10, os dados se concentram especi ca-mente na Placa Arduino Nano e como é preciso garantir a entrega dos dados, será feita a replicação deste componente utilizando um esquema semelhate ao TMR. Como já foi dito, o TMR consome uma quantidade maior de energia, para tentar aproveitar as vantagens do TMR e atenuar as suas desvantagens, foi proposto um modelo que reúne os concei-tos das duas técnicas: TMR e Mestre-Escravo. A estratégia é replicar os Arduinos Nano deixando um ativo e outros dois na reserva. Para tanto é necessário a implementação em dois passos: decidir qual Arduino Nano cará ativo e decidir se a informação está correta ou não. A tarefa de acionar apenas um dos microcontroladores cou a cargo de um Attiny85 (MICROCHIP, 2018b), um microcontrolador menor e mais simples, apenas para acionar o Arduino Nano que cará ativo, este irá processar informação e enviá-la ao concentrador. O concentrador será responsável por decidir se informação é válida ou não. Se a informação for considerada uma falha, o controlador enviará uma mensagem solicitando ao módulo embarcado que troque de microcontrolador e reenvie os dados. A Figura 14 apresenta a solução proposta para implementar tolerância a falhas no Módulo Embarcado.
Pela Figura 14, nota-se que os sensores e os demais componentes que antes se ligavam num único Arduino Nano agora se ligam aos 3 Arduinos Nano. Esta ligação é feita por meio de uma multiplexador que recebe os dados dos sensores e tem sua saída ligada a cada Arduino Nano. Como apenas um Arduino Nano é acionado por vez não há a ocorrência de con ito nos dados. O microcontrolador Attiny85 é quem decide qual dos 3 Arduinos
cará ativo, este acionamento é feito a partir de um demultiplexador que tem suas saídas ligada a um circuito que efetua o acionamento de um dos Arduinos Nano.
Figura 14: Diagrama de blocos do Módulo Embarcado com a replicação do Ardunino Nano
4.4.1 Implementação
A implementação das técnicas de tolerância a falhas exigiu alterações na organização de todos módulos. Inicialmente os Módulos Web e Mobile precisaram ser alterados para noti car o usuário sobre a ocorrência da falha. Estas mudanças vão desde a base de dados até a forma como a informação é repassada ao usuário (interface com o usuário). O Concentrador, por sua vez, foi modi cado para assumir a função de veri car e decidir a validade das informações passadas. O Módulo Embarcado foi o que mais sofreu alterações. A primeira alteração a ser feita no Módulo Embarcado foi a triplicação dos Arduinos Nano e a adição de um Attiny85 para selecionar o Arduino Nano ativo. Para isso foram adicionados multiplexadores e transistores para efetuar o chaveamento entre os compo-nentes. Toda essa estrutura se mostrou operante nas simulações em ambientes virtuais, mas durante a implementação física, alguns problemas foram encontrados. O maior destes problemas estava ligado ao funcionamento real da placa Arduino que diferiu dos ambi-entes virtuais. Enquanto que no ambiente virtual o Arduino Nano poderia ser acionado
utilizando um par de pinos especí cos, no plano físico se aciona a placa com qualquer par de pinos positivos e negativos. Dessa forma o sistema não conseguia manter apenas um dos microcontroladores ativo já que cada sensor possuía um pino positivo e negativo. Para resolver este problema, adicionou-se um multiplexador, juntamente com trasistores e alguns diodos. O multiplexador foi utilizado para receber os sinais vindos de cada sensor deixando que o Arduino ativo selecione o sensor que deseja acessar. Já os trasistores e os diodos foram utilizados para isolar eletricamente cada um dos Arduino Nano, de modo que o sinal dos sensores não os ative, eliminando o problema. A Figura 15 traz o diagrama de blocos da versão tolerante a falhas.
Figura 15: Diagrama de blocos do Módulo Embarcado com o tolerância a falhas Os Arduinos Nano conseguem enviar e receber informações através do barramento de dados. O Attiny85 também está conectado aos demais Arduinos e se comunica com eles segundo um sistema de cliente-servidor. Ao ser iniciado, o Arduino Nano ao faz uma requisição ao Attiny85 (servidor) solicitando os dados de con guração e ele responde com a informação desejada. Esta comunicação entre os Arduinos Nano e o Attiny85 é feita por meio do protocolo UART .
4.4.2 Esquemático do Hardware Embarcado
Figura 16: Esquema elétrico simpli cado do Módulo Embarcado
A Figura 16 apresenta o esquema elétrico da solução tolerante à falhas. A solução apresentada considera que o ponto mais importante a ser preservado é o componente responsável pelo processamento e envio dos dados, no caso é a plataforma Arduino Nano, que no esquema está representado como "MIC". Esta plataforma é o centro de todo o sistema e para tanto é necessário garantir seu funcionamento. Neste trabalho, a solução adotada para este m foi replicar o componente mantendo um ativo e outros dois como reservas, a m de que caso seja detectada uma falha no componente ativo um dos reservas tome seu lugar. Uma vez que o Arduino Nano foi triplicado, os sinais dos sensores (SMOS, DHT, LDR, LW) têm que ser repassados para cada um dos Arduinos. Adicionou-se um multiplexador que concentra os sinais dos sensores e os repassa aos Arduinos, diminuindo o número de trilhas e reduzindo a área ocupada pelo circuito e evitando a interferência gerada pelas trilhas em paralelo e ativação indevida de algum dos Arduinos Reservas. Para este projeto optou-se pelo CI CD4051 (BRAGA, 2010b), um circuito integrado que comporta um multiplexador de 8 entradas e uma saída. Deste modo os pinos de dados de cada sensor são ligados nas entradas do CI CD4051 e a sua saída é replicada para os Arduinos. A escolha de qual Arduino Nano deve ser ativado se dá por meio de um microcontrolador chamado Attiny85. O Attiny85 é um microcontrolador da mesma família que o Atmega328p, mas com tamanho e capacidade mais reduzidos. A escolha do Attiny85
como controlador se deu por sua fácil codi cação, baixo consumo de energia e seu tamanho (cerca de terço do tamanho do atmeg328p). Attiny85 serve ainda como backup dos dados de con guração dos Arduinos armazenando os valores de referência recebidos do Módulo Concentrador. O gerenciamento feito pelo Attiny85 é bastante simples, ele se comunica com cada um dos Arduinos Nano por meio de comunicação UART (BRAGA, 2010a) juntamente com um protocolo de comunicação de 2 bytes desenvolvido especialmente para a placa. Este protocolo contempla as mensagens de con guração e chaveamento dos componentes. O chaveamento utilizando três de suas portas cada uma ligada a um demultiplexador (CI 4502) que tem cada uma de suas saídas ligadas a um transistor NPN con gurado como emissor comum em série com cada um dos Arduinos. O Transistor escolhido foi o 2N2222 (BRAGA, 2012a), um transistor NPN muito comum no mercado e que trabalha bem em circuitos de baixa potência. Vale lembrar que este transistor poderia ser substituído por um modelo da família TIP, que são transistores com grandes dissipadores de calor o que adicionaria uma maior proteção contra aquecimento, mas que de modo geral não seria de grande in uência para este tipo de aplicação. Outro ponto importante é que a adição do Attiny85 ocasiona um segundo ponto crítico de falha, mas como já foi especi cado, o foco da proteção está no Arduino Nano, que é o componente a sofrer maior "estresse"no circuito. Para dar uma maior segurança no caso do próprio attiny85 parar de funcionar, a arquitetura do hardware garante que mesmo na ausência do attiny85, um dos Arduinos continue ativo.
Um outro problema a ser resolvido pelo modelo apresentado é a estabilização da alimentação do circuito. Por ser alimentado por uma bateria o circuito tende a sofrer com baixas de tensão à medida em que a bateria vai descarregando. Para resolver este problema decidiu-se por alimentar os Arduinos Nano, diretamente na bateria, visto que na placa existe um regulador de tensão que baixa a tensão de alimentação para 5v. Inspirado neste mecanismo da placa de prototipagem utilizou-se do mesmo artifício para a solução proposta optando-se pelo CI LM7805 (BRAGA, 2011), um regulador de tensão muito utilizado e que vem a ajudar no aumento da vida útil da bateria.
4.4.3 Alterações no Módulo Concentrador
Enquanto as alterações no Módulo Embarcado foram feitas com o objetivo de imple-mentar a tolerância a falhas, o software do Módulo Concentrador precisou ser alterado para dar suporte a detecção das falhas.
alteração foi necessária para que as mensagens enviadas pelo Módulo Embarcado pas-sassem a conter o identi cador do Arduino Nano que enviou a mensagem. A segunda modi cação foi a adição de uma rotina para validação dos dados durante a recepção dos dados. Esta validação compara os dados enviados pelo Módulo Embarcado com limites previamente cadastrados, uma vez que o sistema detecta um valor fora destes limites a falha é detectada. Esta rotina assume que os dados podem sofrer interferências ou erro durante a leitura do sensor e que estas falhas podem ocorrer momentaneamente (falhas transitórias). Para diminuir a possibilidade de falsos positivos, ao encontrar uma possível falha o sistema faz uma segunda requisição para veri car se a falha persiste. Se mesmo após a segunda requisição ainda se detectar a falha, mais uma requisição é feita para con- rmar a existência desta e só após esta con rmação é que o Módulo Concentrador emite a mensagem para o Módulo Embarcado informado o erro e solicitando o chaveamento dos Arduinos. Uma vez que a mensagem é enviada para o Módulo Embarcado, o Concentra-dor aguarda três segundos e tenta uma nova requisição solicitando os dados novamente. A origem da resposta é analisada com o intuído de veri car se houve o chaveamento entre os Arduinos Nano. Caso seja identi cado que a mensagem partiu do mesmo Arduino, o sistema tenta mais duas vezes requisitar os dados. Caso o chaveamento não tenha sido con rmado o sistema passa a assumir que o Módulo Embarcado está com falha e cessa as tentativas de comunicação e envia uma mensagem na tela. Uma vez que os dados estão validados, podem ser salvos no banco de dados e replicados para o sistema Web.
5 Resultados obtidos
5.1 Alterações no projeto original
No projeto original do Connected Garden não foram levadas em consideração preo-cupações com falhas tornando necessário realizar diversas alterações no sistema como um todo, desde o projeto do hardware até as camadas de software. Segundo (WEBER, 2001), a aplicação de tolerância a falhas em um sistema já em produção tem um custo muito alto, por isso é necessário um estudo para decidir se vale ou não a pena aplicar alguma técnica e escolher qual técnica causará menor impacto no sistema.
No caso do Connected Garden por ser um sistema de monitoramento remoto, a prin-cipal preocupação está em garantir o recebimento dos dados vindos dos sensores das plantas.
Observando novamente o diagrama de uxo de dados da Figura 11 , é possível ver que o Módulo Embarcado é a principal fonte de dados do sistema, pois serve como porta de entrada dos dados. Uma falha nas informações fornecidas por ele põe a perder todo o processamento seguinte, pois os atuadores não serão acionados no momento certo, o que pode acarretar em prejuízos. Pode se fazer um comparativo com um sistema automático de injeção de insulina, onde um sensor é inserido no corpo do paciente e, frequentemente veri ca a sua taxa de glicose. Enviando os dados para uma central que decide a quantidade de insulina a ser injetada. Uma falha neste sensor que é a fonte de dados do sistema pode levar o usuário à morte por excesso de insulina. No caso do Connected Garden, erros nas leituras dos sensores podem ocasionar um excesso de irrigação o que pode levar ao apodrecimento das raízes, matando a planta. Outro fato a ser observado no sistema é o fato de que o Módulo Embarcado ser o elo mais fraco. Isso acontece porque este módulo está constantemente sob in uência de fatores ambientais como umidade, exposição ao sol, água, variações de temperatura e diversos outros que, pouco a pouco, vão deteriorando os componentes do sistema. Por ser um Módulo de extrema importância para o sistema e como funciona em um ambiente - de certa forma hostil - que favorece a ocorrência
