tolerância a falhas em sistemas embarcados baseados em ... · 3. microcontroladores - monografia....
TRANSCRIPT
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
Tolerância a Falhas em Sistemas Embarcados
Baseados em Microcontroladores
Wanderson Ricardo de Medeiros
Natal-RN
Junho de 2018
Wanderson Ricardo de Medeiros
Tolerância a Falhas em Sistemas Embarcados Baseados
em Microcontroladores
Monogra�a de Graduação apresentada aoDepartamento de Informática e MatemáticaAplicada do Centro de Ciências Exatas e daTerra da Universidade Federal do Rio Grandedo Norte como requisito parcial para a ob-tenção do grau de bacharel em Ciência daComputaçã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 emmicrocontroladores / Wanderson Ricardo de Medeiros. - 2018. 61f.: il.
Monografia (Graduação) - Universidade Federal do Rio Grandedo Norte, Centro de Ciências Exatas e da Terra, Departamento deInformática e Matemática Aplicada, Bacharelado em Ciência daComputaçã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
Universidade Federal do Rio Grande do Norte - UFRNSistema de Bibliotecas - SISBI
Catalogação de Publicação na Fonte. UFRN - Biblioteca Setorial Prof. Ronaldo Xavier de Arruda - CCET
Elaborado por Joseneide Ferreira Dantas - CRB-15/324
Monogra�a de Graduação sob o título Tolerância a Falhas em Sistemas Embarcados Ba-
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 PereiraOrientador(a)
Departamento de Informática e Matemática Aplicada - DIMAp
Universidade Federal do Rio Grande do Norte - UFRN
Prof. Dr. Edgard de Faria CorrêaDepartamento de Informática e Matemática Aplicada - DIMAp
Universidade Federal do Rio Grande do Norte - UFRN
Prof. Dr. Márcio Eduardo KreutzDepartamento de Informática e Matemática Aplicada - DIMAp
Universidade Federal do Rio Grande do Norte - UFRN
Natal-RN, 22 de Junho de 2018.
À meus pais, Maria Zulmira de Medeiros e Otélio Severiano de Medeiros, pelo apoio e
incentivo que me deram.
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 mundo�com 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.
Tudo é possível para quem tem fé!
Marcos 9,23
Tolerância a Falhas em Sistemas Embarcados Baseadosem 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.
Palavras-chave: Embarcados, Tolerância a Falhas, Microcontroladores.
Fault Tolerance in Microcontroller Based EmbeddedSystem
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 o�ered 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 di�erent 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.
Keywords : Embedded Systems, Fault tolerance, Microcontrollers.
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. 37
4.1.4 Módulo Mobile . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 37
4.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
Referências p. 58
14
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 equipamentos (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 movimentomaker 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
15
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 componentes 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
16
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.
17
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
18
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, televisores, geladeiras, micro-ondas, en�m, podemos encontrá-los em diversos
19
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.
20
(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
21
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 DependabilidadeFonte: 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
22
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 FalhasImpedir 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 FalhasEstimativas 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
23
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
24
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:
25
• 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
26
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 .
A técnica conhecida como TMR objetiva mascarar a falha em um componente tripli-
27
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.
28
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.
29
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écnicas 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 programaçã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õesFonte: Sommerville, 2007.
30
A programação com blocos de recuperação funciona de maneira semelhante a progra-
mação em n-versões. Assim como na programaçã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çãoFonte: Sommerville, 2007.
31
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
32
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.
33
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.
34
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.
35
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 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.
36
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 intervalos 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.
37
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.
38
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,
39
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.
40
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
41
�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 ArduninoNano
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
42
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 .
43
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
44
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.
A primeira mudança no software foi a alteração do protocolo de comunicação. Esta
45
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.
46
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
47
de falhas, o Módulo Embarcado foi escolhido para ser reformulado a �m de implementar
técnicas que garantam o funcionamento deste Módulo, mesmo nas condições adversas do
ambiente onde ele é executado. As próximas seções detalham as alterações feitas e as
justi�cativas para tais alterações.
5.1.1 Novos Componentes
A primeira variação notória do sistema-alvo foi a replicação da plataforma Arduino
Nano, o kernel do Módulo onde se encontra a inteligência da placa. A replicação deste
componente se faz necessário, pois ele é o responsável pela recepção dos dados dos sensores.
A primeira proposta de alteração consistiu na aplicação da técnica de redundância
modular tripla (TMR). Porém, esta solução gera dois custos adicionais relevantes para as
restrições do sistema: 1) Primeiramente, ao replicar o hardware que concentra a inteligên-
cia do sistema de alguma forma deve haver garantias de que os dados sejam replicados
para todos os três Arduinos Nano. Isto gera a necessidade de criação de um barramento
de dados, por onde os dados dos sensores sejam repassados para todos os Arduinos. Esta
solução inclui não apenas a adição de uma maior área do circuito, mas também a adição
de árbitro para este. 2) Um aumento signi�cativo na dissipação de potência do sistema
por existir três Arduinos Nano, o votador, o barramento de dados adicional e seu árbitro.
Por esse motivo, para este trabalho, a solução encontrada foi implementar um sistema de
chaveamento onde apenas um Arduino é acionado por vez e este acionamento é controlado
por um microcontrolador mais simples, o attiny85.
É importante destacar que esta solução traz consigo outro problema: como garantir
que o microcontrolador acionado continue o processamento do ponto onde o anterior
parou? Como garantir a correta troca de contexto? Uma vez que o Connected Garden
armazena em seu microcontrolador um conjunto de variáveis de controle utilizados para a
avaliação dos dados sensores, estas variáveis devem ser replicadas para os demais Arduinos
no momento do chaveamento. Um exemplo são as variáveis de controle utilizadas para
disparar alertas para o usuário. Para realizar esse chaveamento, o sistema, utilizou-se
da comunicação UART (Universal asynchronous receiver-transmitter) (BRAGA, 2010a)
entre os Arduinos e o Attiny85, fazendo com que o Attiny85 persista as con�gurações da
placa. Isso ocasionou a criação de um segundo barramento, uma vez que a comunicação
entre o Arduino ativo e o módulo Bluetooth também se dá por meio de comunicação
UART. Estas e outras adequações no hardware do Módulo Embarcado mostraram que
mesmo buscando uma técnica mais e�ciente em custo, desempenho e energia, o sistema
48
inteiro precisou ser alterado.
No contexto de sistemas cuja produção possui um baixo custo �nanceiro por unidade
ou em sistema onde o grande volume de unidades vendidas proporciona uma redução no
custo de produção, tais alterações são aceitáveis, mas em sistemas maiores deve se avaliar
a relação de custo versus benefícios da técnica.
5.1.2 Área utilizada
Com a adição de novos componentes se fez necessário o aumento da área do sistema
que passou de 63,75 cm2 (7,5 x 8,5), para uma dimensão de 300 cm2 (12 x 25) de compri-
mento, totalizando um aumento de 370% na área. Este aumento é justi�cado não só pelo
aumento no número de componentes do circuito, mas também pelo efeito que isso traz.
Aumentando a quantidade de componentes, aumenta também o número de vias (trilhas)
no circuito e isso pode acarretar novas falhas, uma vez que a proximidade das trilhas
pode gerar interferência entre elas. O aumento na área da placa do Módulo Embarcado
se mostrou não sendo uma alteração muito positiva, pois com esta área maior, o sistema
�ca ainda mais vulnerável, pois possui mais componentes sujeitos a condições adversas e
consequentemente aumentando a chance de falha. Este tipo de problema pode ser ame-
nizado através do uso de componentes de alta qualidade, mas que podem certamente ser
mais caros. No caso de um sistema embarcado em que a área é um requisito fundamental,
como é o caso do sistema de injeção de insulina mencionado anteriormente, o aumento da
área se torna algo inviável de todas as formas, pois pode causar desconforto ao usuário e
até mesmo inviabilizar o uso do sistema pelo usuário. Atualmente existem formas de �con-
tornar� o aumento da área, uma das mais comuns é a utilização de componentes SMD (do
inglês Surface Mount Device ) que são componentes menores, com a mesma capacidade
que os convencionais, mas com custo mais elevado e que exigem técnicas de soldagem
mais avançadas, necessitando de equipamentos especí�cos. Por seu custo elevado e di�-
culdade de aquisição, este trabalho não foi implementado utilizando componentes SMD e
sim componentes mais comuns encontrados no mercado.
5.1.3 Custo Financeiro
Com tantas variações em área e quantidade de componentes, é esperado que o custo
�nal por unidade também aumente. No caso do Connected Garden, o custo do sistema
sem a tolerância a falhas �ca em torno de R$ 107,90 apenas para o Módulo Embarcado.
49
A Tabela 2 descreve os custos dos componentes do Módulo Embarcado.
Tabela 2: Tabela de Custo de componentes (Versão sem tolerância a falhas)
Componente Qtd R$ TotalMódulo RTC 1 12,5 12,50Módulo - Bluetooth hc 05 1 35 35,00Barra de Pinos Fêmea 2 2 4,00Placa de cobre 10x10 100 0,045 4,50CI LM 7805 1 2,5 2,50LDR 1 2 1,00Resitor 10 0,1 1Arduino Nano 1 22 22,00Sensor DHT 1 15 15,00Sensor Umidade do Solo 1 10 10,00Total 107,90
Com a aplicação da tolerância a falha, o Módulo Embarcado pode chegar a R$ 181,8
reais por unidade, um aumento de 70%, conforme detalhado na Tabela 3.
É importante destacar que os custos foram calculados a partir dos preços dos compo-
nentes no ano de 2018 e através de pesquisa de preços nos sites FilipeFlop (FILIPEFLOP,
2018a), Robocore (ROBOCORE, 2018), NatalMakres (NATALMAKRES, 2018) e pesqui-
sas no mercado local. O preço pode variar conforme fornecedor e quantidade de unidades
adquiridas. Com relação à avaliação se o custo adicional da técnica de tolerância a falhas é
aceitável, esta dependerá de diversos fatores, como grau de criticalidade do sistema; quan-
tidade de unidades a ser produzidas e cobertura de falhas. Esta última será analisada mais
adiante.
50
Tabela 3: Tabela de Custo de componentes (Versão com tolerância a falhas)
Componente Qtd R$ TotalMódulo RTC 1 12,5 12,50Módulo - Bluetooth hc 05 1 35 35,00Barra de Pinos Fêmea 1 3 6,00Placa de Cobre 12x30 300 0,0045 16,2CI LM 7805 1 2,5 2,50LDR 1 1 1,00Resitor 15 0,1 1,50Arduino Nano 3 22 66,00Sensor DHT 1 2 2,00Sensor Umidade do Solo 1 10 10,00CI LM 555 1 11 11,00Diodo 1N4148 34 0,15 5,10Trans. 2n2222 5 0,5 2,50Trans. 2n2907 3 0,5 1,50CI 4n25 4 1,2 4,80CI CD4501 1 1 1,00CI CD4502 1 1 1,00ATtiny85 1 12 12,00Total R$181,8
5.1.4 Autonomia do Sistema
Outro ponto bastante importante para um sistema embarcado é a duração da bateria,
que implica na autonomia do sistema. A autonomia é diretamente afetada pelas modi�-
cações que são necessárias para promover a tolerância a falhas. Esta é uma problemática
muito comum no projeto de sistemas computacionais tolerantes a falhas. (MATHEW;
SHAFIK; PRADHAN, 2014) a�rmam que este é um dos maiores desa�os da aplicação de
técnicas de tolerância a falhas, principalmente em sistemas que necessitam de redundância
em hardware. Para se ter uma ideia da variação de consumo utilizou-se a equação:
A =CabatCmedio
Onde A é a autonomia da bateria em horas, Cabat é a capacidade da bateria em mAh
e Cmedio é o consumo médio do sistema em mA, isto é, a média entre o consumo do sistema
em repouso e durante o uso do Bluetooth. A tabela 4 apresenta as leituras de consumo
das duas versões do sistema.
51
Tabela 4: Comprativo de Autonomia do Sistema
Versão Consumo em repousoConsumo durante pareamento(Bluetooth)
Autonomia
Sem TF 20 mA 65 mA 12,2 hCom TF 30 mA 90 mA 8,6 h
De acordo com a Tabela 4 vemos que o consumo do sistema aumenta em cerca de
300% ao acionar a comunicação Bluetooth. Isso acontece porque a comunicação via rádio
exige muita energia, mas este problema pode ser tratado requisitando o Bluetooth apenas
quando realmente for necessário. Deste consumo, cerca de 10mA a 12mA são consumidos
pelo Arduino Nano, enquanto que o restante é divido entre os demais componentes, �cando
o Bluetooth com cerca de 40mA, ou seja, aproximadamente 65% do consumo total.
Vale lembrar que os valores apresentados nas baterias comerciais são puramente no-
minais, além do fato que baterias reais tende a descarregar a medida em que o tempo
passa, o que pode in�uenciar no tempo de autonomia real (BRAGA, 2012b).
Também é possível observar que a adição de novos componentes faz com que o con-
sumo do sistema aumente, porém, se mantendo abaixo dos 100 mA, corrente que poderia
dani�car o Arduino Nano.
Com relação à autonomia, o módulo com tolerância a falhas possui autonomia 30%
menor do que o módulo sem tolerância a falhas. Esse resultado é esperado, considerando
a inclusão de diversos componentes para permitir a detecção e tolerância das falhas. As
seções seguinte apresentam uma análise da cobertura de falhas.
5.2 Experimentos com falhas
Os experimentos realizados no sistema tiveram como objetivo simular a ocorrência de
possíveis falhas que poderiam impedir o funcionamento do Módulo Embarcado.
Para simular as falhas no sistema Connected Garden foram adicionados dois pinos
de con�guração que indicam o tipo de falha a ser simulado. As falhas do tipo stuck-at
fault foram simuladas travando os dados de um dos sensores sempre em um único valor.
O objetivo é fazer com que o módulo concentrador detecte este tipo de falha a partir da
constante repetição do valor. A simulação do modelo transition fault foi feita a partir da
alteração dos dados de um dos sensores antes do envio, onde o objetivo foi fazer com que
o sistema veri�casse a inconsistência dos dados através da presença de uma informação
52
inválida. Por exemplo, um valor de temperatura fora do padrão, muito baixa ou muito
alta. Por último, as falhas por fail-stop foram simuladas através da ausência de um dos
Arduino Nano.
As fases de aplicação das técnicas de tolerância a falhas foram divididas entre o Módulo
Concentrador e o Módulo Embarcado. Para a fase de detecção do erro, utilizou-se de
testes de limites de razoabilidade para os dados. Nestes testes, o Módulo Concentrador
avalia se a informação é válida dentro de limites predeterminados. Uma vez que o Módulo
Concentrador detecta o erro, uma mensagem é enviada ao Módulo Embarcado solicitando
a alteração do Arduino ativo e o novo reenvio dos dados. No Módulo Embarcado ocorre a
fase de isolamento, onde o sistema desabilita o microcontrolador falho e habilita um dos
microcontroladores auxiliares. A fase de recuperação �ca a cargo do Módulo Concentrador
que utiliza a técnica de recuperação por retorno, fazendo novas requisições ao módulo
concentrador. Por �m, o tratamento da falha se dá por parte do usuário removendo
manualmente o componente falho e substituindo-o por outro.
5.2.1 Testes com stuck-at fault
Para este tipo de falha foram feitas cerca de 10 tentativas travando o sensor de tem-
peratura no valor 100. Durante o teste, o sistema devia se comportar da seguinte forma:
o Módulo Concentrador recebe a informação e noti�ca ao Módulo Embarcado para que
este altere o Arduino utilizado para, em seguida, reenviar os dados. Durante a maior parte
dos testes, o sistema conseguiu chavear o microcontrolador e retornar ao estado normal
de funcionamento, mas, em alguns casos, o chaveamento não foi efetuado no momento
correto, pois a comunicação entre os Módulos Embarcados e Módulo Concentrador é feita
por meio de um módulo Bluetooth HC-05 (FILIPEFLOP, 2018b) que, em certo momento,
perde a conexão, impossibilitando o envio da mensagem de erro. Este tipo de problema
está diretamente ligado à qualidade do módulo Bluetooth utilizado e não faz parte do
modelo de falhas proposto, que foi idealizado supondo uma conexão con�ável. Em um
sistema crítico, este tipo de erro tende a ser extremamente prejudicial e, muitas vezes,
pode passar despercebido nas fases de detecção, se manifestando em grandes catástrofes
(HINKEL, 1996).
53
5.2.2 Testes com transition fault
Os testes com falhas de transação foram efetuados adicionando o valor 100 ao valor
da leitura do sensor. Para este tipo de falha foram efetuadas cerca de 15 veri�cações.
Estas veri�cações apresentaram resultados muito parecidos com os dados obtidos com as
stuck-at fault's. Um teste com alterações aleatórias também foi efetuado. Nestes últimos
testes foram adicionados valores aleatórios à leitura do sensor. O resultado foi um grande
número de falso-negativo, ou seja, o sistema não conseguiu detectar boa parte das falhas
injetadas, pois as alterações ainda �zeram com que os dados continuassem na faixa de
valores aceitáveis. Em uma tentativa de garantir maior e�ciência no reconhecimento das
falhas, o sistema supõe que transition fault podem acontecer a qualquer momento e por
isso faz a requisição e veri�cação dos dados 3 vezes antes de realmente sinalizar a detecção
da falha, mas mesmo com este tipo de mecanismo valores ainda dentro da faixa tolerável
não são recnhecidos como falhas. Soluções para este tipo de problema são abordadas na
seção de trabalhos futuros.
5.2.3 Testes com fail-stop
Para este tipo de falhas foram efetuadas remoções nos Arduinos Nano utilizados no
sistema e tinham como objetivo simular a não ativação do Arduino. Este tipo de falha
foi facilmente detectável pelo sistema que rapidamente chaveou o componente ativo sem
perder a conexão Bluetooth. Durante os testes, em pouquíssimas vezes o sistema não
conseguiu chavear a placa por motivos até então desconhecidos, mas certamente ligados
a forma como o circuito elétrico foi montado.
Considerando os resultados dos testes, é possível ver que embora algumas alterações
tenham apresentado um impacto positivo (baixo consumo de energia, recuperação do
estado de erro e indicação de falhas), parte das alterações se mostram prejudiciais ao
sistema (grande aumento da área, refatoração do projeto e etc.) não lhe trazendo vantagens
que lhes justi�quem, comprovando que em sistemas de pequeno porte projetados sem
tolerância a falha a aplicação destas técnicas pode não trazer benefícios.
Para sistemas críticos, é necessário realizar estudos mais aprofundados com o objetivo
de avaliar se a técnica é apropriada. Os estudos permitirão avaliar se é possivel garantir
uma alta taxa de cobertura de falhas. Por outro lado, para sistemas como o Connected
Garden, bem como sistemas de detecção de incêndio em lojas, que atualmente não possuem
nenhum tipo de tolerância a falhas, considera-se que a solução tem potencial para ser
54
utilizada. Isto porque existe de fato um mecanismo de tolerância a falhas com cobertura
relevante e, considera-se que área, custo e autonomia são gerenciáveis. Apesar disso, apenas
uma análise mais aprofundada do custo �nal de produção comercial em larga escala e do
uso de componentes mais apropriados como os SMDs podem dar uma noção mais concreta
sobre a relação de custo versus benefício da técnica.
55
6 Considerações �nais
Este trabalho apresentou uma proposta de implementação de um mecanismo de to-
lerância a falhas para sistemas embarcados baseados em microcontroladores, objetivando
aproveitar as vantagens da replicação em hardware e a votação por software buscando um
equilíbrio entre e�ciência e consumo energético.
O modelo apresentado foi implementado inspirado em técnicas de replicação como
TMR e em modelos mestre-veri�cador bastante presentes na literatura. Na literatura,
pouco se encontra sobre técnicas ou métodos para adicionar tolerância a falhas em um
sistema preexistente, em parte pelo fato de que grande parte dos autores concordam ao
considerar que os uso de tolerância a falhas deve ser uma decisão a ser tomada no início do
projeto. Além disso, também são limitados os trabalhos que propõe tolerância a falhas em
sistemas microcontrolados e, não foi encontrado nenhum trabalho utilizando a plataforma
Arduino. Embora pouco se tenha na literatura, os documentos encontrados serviram como
base para elaboração desta proposta.
Para efetuar os testes de validação da proposta, foi utilizado o sistema Connected Gar-
den. Este sistema embarcado é de coautoria do autor deste trabalho, permitindo assim
as modi�cações necessárias para implementar a tolerância a falhas no sistema. O Con-
nected Garden é um sistema de monitoramento e irrigação de jardins de pequeno porte,
constituído por 4 módulos que se comunicam entre si para permitir ao usuário acessar
informações sobre cada vaso de plantas do seu jardim. Estas informações são colhidas por
meio de sensores presentes no Módulo Embarcado que é acoplado ao vaso da planta. Uma
vez coletada pelo Módulo Embarcado, a informação é enviada ao Módulo Concentrador
para depois ser disponibilizada ao usuário por meio de uma aplicação Android ou através
do Módulo Web. O módulo Embarcado consiste em uma placa de circuito com sensores
e sinais para atuadores, tudo isso ligado a um Arduino Nano que é a �inteligência� do
módulo.
O resultado �nal deste trabalho foi uma versão do Módulo Embarcado com implemen-
56
tação de técnicas de tolerância a falhas. Esta nova versão consiste em um sistema que faz
uso de replicação para garantir o funcionamento do Módulo Embarcado pelo maior tempo
possível. Para isso o hardware do Arduino Nano foi replicado e o Módulo Concentrador
passou a atuar como um avaliador, validando as informações recebidas.
Os teste feitos no módulo consistiram em simular falhas e analisar o comportamento
do sistema observando o consumo de energia, o tempo de recuperação, a área ocupada
com as modi�cações e custo �nal de produção. Os resultados destes testes apontam algo
já esperado como a inviabilidade da aplicação de tolerância a falhas em um projeto de
pequeno porte preexistente e alimentados por uma bateria. Isso porque a aplicação de
técnicas de tolerância sempre envolvem algum tipo de replicação, o que ocasiona aumentos
de área, consumo e consequentemente custo.
Por �m, a ideia de um sistema de monitoramento com garantias de alta disponibilidade
é uma proposta atrativa para projetos de sistemas em ambientes �hostis� como sistemas de
monitoramento de gás em cozinhas industriais, monitoramento de umidade em quadros de
alta tensão e outros sistemas, onde o ambiente tende a fornecer diversas fontes de falhas.
Com relação ao área e consumo energético, estes são problemas contornáveis utilizando
técnicas de produção mais avançadas como o uso de componentes SMD que ajudam a
reduzir o tamanho e o consumo de energia.
6.0.1 Trabalhos Futuros
Os resultados dos testes com o sistema abrem espaço para novas pesquisas e aprimora-
mentos no sistema, a �m de torná-lo cada vez mais próximo de um produto comercializável.
Soluções que promovam a diminuições do consumo de energia, da área ocupada e dos cus-
tos são os objetivos de futuros trabalho. A redução do tamanho do Módulo Embarcado
é uma das principais tarefas futuras e tem como objetivo montar uma versão utilizando
componentes SMD. No consumo energético proposta de remover o Arduino Nano e criar
uma arquitetura própria baseada no atmega328p, com um encapsulamento que permita a
troca do chip, a �m de economizar espaço, diminuir o consumo de energia e possibilitar a
troca do microcontrolador defeituoso sem o desligamento do sistema. No que diz respeito
aos custos, a própria remoção dos Arduinos já causaria uma redução 15% no custo da
placa. Se levar em conta a diminuição da área e a utilização de componentes SMD os
custos da placa com tolerância a falha pode sofrer uma redução de cerca de 25%. Além
disso, versões mais baratas com apenas dois microcontroladores podem baixar ainda mais
o custo tornando-o muito próximo ou até menor que o custo da atual versão sem tolerância
57
a falhas.
No lado do software diversas melhorias podem ser feitas na interface e nas rotinas
internas do sistema. Na interface seria interessante a adição de mais informações como
logs de sincronização e alertas mais detalhados sobre o tipo de falha o que ajudaria os
usuários na manutenção do sistema. Com relação à detecção de falhas, novas formas
e mais e�cientes podem ser implementadas. Soluções baseadas em detecção de valores
discrepantes, análise de histórico de leitura ou até mesmo soluções baseadas em redes
neurais arti�ciais podem apresentar melhores resultados na detecção de erros. En�m, há
um grande número de melhorias que podem ser implementadas nesta técnica que podem
deixá-la ainda mais robusta e con�ável.
58
Referências
AFONSO, F.; SILVA, C.; A., T. Application-level fault tolerance in real-time embeddedsystems. In: Conference: Industrial Embedded Systems. [S.l.]: IEEE Press, 2008. p.126�133.
ANDERSON, T.; LEE, P. A. Fault Tolerant Design: Principles and Practice. 2sd. ed.New York: Springer, 1981.
ANDROID. android. jun. 2018. Jun., 2018. Disponível em: <https://www.android.com/>. Acesso em Junho 15, 2018.
ARDUINO. Arduino Nano. jun. 2018. Disponível em: <https://store.arduino.cc/arduino-nano>. Acesso em Jun 16, 2018.
ARRAIS, R. Após dois anos, mercado de smartphones cresce em 2017 e atingeo segundo melhor desempenho de vendas. mar. 2018. Mar., 2018. Disponível em:<http://br.idclatin.com/releases/news.aspx?id=2312>. Acesso em Janeiro 26,2018.
AVIZIENIS, A.; LAPRIE, J.; RANDELL, B. Fundamental Concepts of Dependability.[S.l.], 2001.
BALASUBRAMANIAN, P. ASIC-based design of NMR system health monitor formission/safety-critical applications. [S.l.], 2016.
BRAGA, N. C. Como funcionam as UARTs. nov. 2010. Nov., 2010. Disponível em:<http://newtoncbraga.com.br/index.php/telecom-artigos/1709-tel006.html>.Acesso em Junho 16, 2018.
BRAGA, N. C. Como funcionam os multiplexadores/demultiplexadores digitais4051/4052/4053. jun. 2010. Jun., 2010. Disponível em: <http://newtoncbraga.com.br/index.php/telecom-artigos/1709-tel006.html>. Acesso em Maio 08, 2018.
BRAGA, N. C. 7805. mar. 2011. Mar., 2011. Disponível em: <http://www.newtoncbraga.com.br/index.php/ideias-dicas-e-informacoes-uteis/
44-circuitos-integrados-lineares/3200-ip307>. Acesso em Maio 08, 2018.
BRAGA, N. C. 2N2222 - Transistor NPN de Comutação. 2012. Out., 2012. Disponível em:<http://newtoncbraga.com.br/index.php/ideias-dicas-e-informacoes-uteis/45-circuitos-integrados-ttl/6158-ip803>. Acesso em Maio 08, 2018.
BRAGA, N. C. Corrente de Pilhas Comuns (DUV373). jun. 2012. Dis-ponível em: <http://www.newtoncbraga.com.br/index.php/duvidas/5723-corrente-de-pilhas-comuns-duv373>. Acesso em Junho 15, 2018.
59
DOBLER, R. J.; CECHIN, S. e. a. A software fault injector to validate implementationsof a safety communication protocol. In: Seventh Latin-American Symposium onDependable Computing. [S.l.]: IEEE Press, 2016. p. 35�42.
DUBROVA, E. Fault Tolerant Design: An Introduction. 1st. ed. Boston: KluwerAcademic Publishers, 2008.
ESP. ESP8266. Junho 2018. Disponível em: <https://www.espressif.com/sites/default/files/documentation/0a-esp8266ex_datasheet_en.pdf>. Acesso em Junho27, 2018.
ESPRESSIF. ESPRESSIF. Junho 2018. Disponível em: <https://www.espressif.com/>. Acesso em Junho 27, 2018.
FILIPEFLOP. Filipe Flop loja virtal. jun. 2018. Jun., 2018. Disponível em:<https://www.filipeflop.com/>. Acesso em Maio 16, 2018.
FILIPEFLOP. Módulo Bluetooth rs232 hc-05. jun. 2018. Jun., 2018. Disponívelem: <https://www.filipeflop.com/produto/modulo-bluetooth-rs232-hc-05/>.Acesso em Junho 17, 2018.
GOMES, I. A. C. Mestrado, Uso de Redundância Modular Tripla Aproximada paraTolerância a Falhas em Circuitos Digitais. Porto Alegre, RS, Brasil: [s.n.], 2014.
GOOGLE, C. GoogleScholar. 2016. Mai., 2016. Disponível em: <https://scholar.google.com.br/>. Acesso em Maio 16, 2016.
HINKEL, J. N. Ariane 5: Um erro numérico (over�ow) levou à falha no primeirolançamento. 1996. Out., 1996. Disponível em: <http://www.sbmac.org.br/bol/bol-2/artigos/ariane5.html>. Acesso em Agosto 16, 2017.
IDC. DC Brasil. mar. 2018. Mar., 2018. Disponível em: <http://br.idclatin.com/about/>. Acesso em Janeiro 26, 2018.
INTEL. Intel Embedded Systems Competition 2015. nov. 2015. Nov., 2015. Disponívelem: <http://sbesc.lisha.ufsc.br/sbesc2015/Intel+Embedded+Systems+Competition>. Acesso em Maio 06, 2018.
INTEL. Intel Cup Undergraduate Eletronic Design Contest - Embedded System DesignInvitation Contest. jul. 2016. Jul., 2016. Disponível em: <http://nuedc.sjtu.edu.cn/EN/Default.aspx>. Acesso em Maio 06, 2018.
INTEL. Introdução as Placas Intel Galileo. jun. 2018. Jun., 2018. Disponível em:<https://www.intel.com.br/content/www/br/pt/support/articles/000005912/boards-and-kits/intel-galileo-boards.html>. Acesso em Junho 16, 2018.
MARWEDEL, P. Embedded System Design. 1st. ed. Netherlands: Springer, 2006.
MATHEW, J.; SHAFIK, R. A.; PRADHAN, D. K. Energy-E�cient Fault-TolerantSystems. 1st. ed. New York: Springer, 2014.
MICROCHIP. ATmega328P: 8-bit AVR Microcontrollers. 2018. 2018. Disponível em:<https://www.microchip.com/wwwproducts/en/ATmega328P>. Acesso em Julho 1,2018.
60
MICROCHIP. ATtiny85. nov. 2018. Nov., 2018. Disponível em: <http://www.microchip.com/wwwproducts/en/ATtiny85/>. Acesso em Abril 10, 2018.
MICROCHIP. Microchip Technology. 2018. 2018. Disponível em: <http://www.microchip.com>. Acesso em Junho 15, 2018.
MICROCHIP. Microcontrollers PIC. 2018. 2018. Disponível em: <http://www.microchip.com/design-centers/microcontrollers>. Acesso em Junho 15, 2018.
MOTA, A. DHT11 e DHT22, Sensor de umidade e Temperatura com Arduino.2018. Mai., 2018. Disponível em: <https://portal.vidadesilicio.com.br/dht11-dht22-sensor-de-umidade-e-temperatura/>. Acesso em Maio 06, 2018.
NATALMAKRES. Natal Makers loja virtal. 2018. 2018. Disponível em: <https://natalmakers.lojaintegrada.com.br>. Acesso em Maio 16, 2018.
NXP. kinetis Série E. 2018. 2018. Disponível em: <https://www.nxp.com/products/processors-and-microcontrollers/arm-based-processors-and-mcus/
kinetis-cortex-m-mcus/e-series5v-robustm0-plus-m4:KINETIS_E_SERIES?fsrch=
1&sr=1&pageNum=1>. Acesso em Junho 14, 2018.
NXP. kinetis Série L. 2018. 2018. Disponível em: <https://www.nxp.com/products/processors-and-microcontrollers/arm-based-processors-and-mcus/
kinetis-cortex-m-mcus/l-seriesultra-low-powerm0-plus:KINETIS_L_SERIES?
fsrch=1&sr=1&pageNum=1>. Acesso em Junho 14, 2018.
NXP. kinetis Série M. 2018. 2018. Disponível em: <https://www.nxp.com/products/processors-and-microcontrollers/arm-based-processors-and-mcus/
kinetis-cortex-m-mcus/m-seriesmetrologym0-plus:KINETIS_M_SERIES?fsrch=1&
sr=1&pageNum=1>. Acesso em Junho 14, 2018.
PASIN, M.; RIVEILL, M.; WEBER, T. S. High-available enterprise javabeans usinggroup communication system support. In: . [S.l.: s.n.], 2001.
PRASAD, K.; MASTORAKIS, N. E. A fault tolerance improved majority voter for tmrsystem architectures. CoRR, abs/1605.03771, n. 1, p. 108�122, 2016.
RASPBERRY. raspberry pi. jun. 2018. Jun., 2018. Disponível em: <https://www.raspberrypi.org/>. Acesso em Junho 16, 2018.
RENNELS, D. A. A Fault-Tolerant Embedded Microcontroller Testbed. jan. 1998. Jan.,2001. Disponível em: <https://www.researchgate.net/publication/3724046_A_fault-tolerant_embedded_microcontroller_testbed>. Acesso em Junho 15, 2018.
ROBOCORE. Robocore loja virtual. 2018. 2018. Disponível em: <https://www.robocore.net>. Acesso em Maio 16, 2018.
SILVA, L. E. R. Monogra�a, Sistema de Tolerância a Falhas baseado em Recon�guraçãoEstática de dispositivos FPGAs. Brasilia, DF, Brasil: [s.n.], nov. 2015.
SOMMERVILLE, I. Engenharia de Software. 8th. ed. São Paulo: Pearson, 2007.
61
VAHID, F.; GIVARGIS, T. Embedded System Design: A Uni�ed Hardware/SoftwareApproach. 1st. ed. California: University of California, 1991.
WEBER, T. S. Tolerância a falhas: conceitos e exemplos. jan. 2001. Jan., 2001.Disponível em: <http://www.inf.ufrgs.br/~taisy/disciplinas/textos/ConceitosDependabilidade.PDF>. Acesso em Agosto 18, 2017.
XMOS. Microprocessadores XCORE-XS1 ANALOG. 2018. 2018. Disponível em:<https://www.xmos.com/support/silicon?product=16681>. Acesso em Junho 14,2018.
XMOS. XMOS. 2018. Disponível em: <http://www.xmos.com/>. Acesso em Junho 14,2018.
ZHENG, B.; ANWAR, S. Fault-Tolerant Control of the Road Wheel Subsystem in aSteer-By-Wire System. jun. 2007. Disponível em: <http://downloads.hindawi.com/archive/2008/859571.pdf>. Acesso em Junho 17, 2018.