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 verica 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 inuê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

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 justicativas 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 signicativo 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 conguraçõ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 eciente em custo, desempenho e energia, o sistema

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 é justicado 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.

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$ Total

Módulo RTC 1 12,5 12,50 Módulo - Bluetooth hc 05 1 35 35,00 Barra de Pinos Fêmea 2 2 4,00 Placa de cobre 10x10 100 0,045 4,50 CI LM 7805 1 2,5 2,50 LDR 1 2 1,00 Resitor 10 0,1 1 Arduino Nano 1 22 22,00 Sensor DHT 1 15 15,00 Sensor Umidade do Solo 1 10 10,00

Total 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.

Tabela 3: Tabela de Custo de componentes (Versão com tolerância a falhas) Componente Qtd R$ Total

Módulo RTC 1 12,5 12,50 Módulo - Bluetooth hc 05 1 35 35,00 Barra de Pinos Fêmea 1 3 6,00 Placa de Cobre 12x30 300 0,0045 16,2 CI LM 7805 1 2,5 2,50 LDR 1 1 1,00 Resitor 15 0,1 1,50 Arduino Nano 3 22 66,00 Sensor DHT 1 2 2,00 Sensor Umidade do Solo 1 10 10,00 CI LM 555 1 11 11,00 Diodo 1N4148 34 0,15 5,10 Trans. 2n2222 5 0,5 2,50 Trans. 2n2907 3 0,5 1,50 CI 4n25 4 1,2 4,80 CI CD4501 1 1 1,00 CI CD4502 1 1 1,00 ATtiny85 1 12 12,00 Total 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) armam que este é um dos maiores desaos 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 = Cabat Cmedio

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.

Tabela 4: Comprativo de Autonomia do Sistema

Versão Consumo em repouso Consumo durante pareamento_(Bluetooth) Autonomia

Sem TF 20 mA 65 mA 12,2 h

Com 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 inuenciar 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 danicar 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.