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 conguraçã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 vericasse a inconsistência dos dados através da presença de uma informação

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 notica 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).

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 vericações. Estas vericaçõ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 eciê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 vericaçã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 justiquem, 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

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.