Testes seguros de falhas e recuperação

Uma análise de falhas começa perguntando o que pode deixar de funcionar e o que isso muda no monitor de temperatura. Neste caso didático, o LED é apenas uma indicação: ele não protege pessoas, equipamentos nem processos.

Para cada caso, descreva uma cadeia:

causa possível → modo de falha → efeito local → efeito no sistema → detecção prevista → resposta esperada.

Exemplo: uma leitura que deixa de chegar ao firmware pode resultar em ausência de atualização; o monitor pode manter uma indicação baseada em informação antiga. Se houver diagnóstico de prazo, ele pode reconhecer a falta de atualização e levar o LED ao estado definido para falha.

A cadeia evita duas conclusões apressadas: assumir que toda falha será percebida e assumir que toda leitura estranha prova uma falha específica.

Use perguntas diferentes para cada elo da análise. Elas impedem que “falha detectada” vire uma suposição sem evidência.

A falha pode ocorrer sem gerar efeito observável; pode gerar um efeito observável sem que o diagnóstico o reconheça; ou pode ser reconhecida pelo diagnóstico. Essas três afirmações não são equivalentes.

Priorize qualitativamente os casos que combinam impacto relevante com difícil reconhecimento. Por exemplo, uma leitura constante e plausível pode manter uma indicação aparentemente normal e ser difícil de distinguir de uma temperatura realmente estável.

Não é necessário atribuir uma pontuação. Registre por que o caso merece atenção: efeito potencial, evidência disponível e limitação conhecida.

Associe cada modo de falha à relação que melhor completa sua análise.

Três caminhos, três tipos de evidência

Escolha o método pelo caminho que precisa ser verificado e pelo risco criado pelo próprio teste:

• Injeção por software: substitui ou simula dados em um ponto definido do firmware. É apropriada para exercitar diagnóstico, decisão, indicação e registro sem tocar no circuito.
• Ensaio físico não destrutivo: observa uma condição real do monitor de baixa energia que possa ser criada sem exceder limites nem alterar conexões energizadas.
• Análise sem execução física: usa esquema, limites documentados, caminhos de corrente e cálculos para condições que não devem ser provocadas.

Nenhum método é “melhor” em geral: cada um sustenta uma conclusão diferente.

Para qualquer ensaio físico permitido, mantenha o escopo restrito ao monitor de baixa energia em 5 V, sem cargas externas. Use uma única origem de alimentação e considere que o USB também pode alimentar a placa: não una fontes independentes.

Antes de começar, registre uma condição inicial conhecida. Introduza uma falha por vez, defina o sinal que manda interromper o ensaio e, ao terminar, restaure a configuração normal. Toda alteração de conexão exige desenergizar o circuito primeiro.

Um teste pretende verificar se o firmware entra na resposta de falha quando recebe uma amostra inválida já disponível na lógica, sem modificar o circuito. Qual método fornece evidência mais direta e segura?

Mesma leitura, causas diferentes

Uma sequência analógica estável e dentro da faixa pode ser compatível com pelo menos duas hipóteses:

• H1 — condição normal: a temperatura realmente permaneceu estável.
• H2 — falha: algum defeito mantém a saída do sensor, ou o sinal que chega ao ADC, em um valor plausível.

A leitura, por si só, não informa qual hipótese ocorreu. Portanto, “o valor parece razoável” não é evidência suficiente de que o sensor está íntegro.

Injeção sem alterar o circuito

Neste ensaio, a falha é criada no firmware, depois da aquisição e antes da validação. Assim, os caminhos de diagnóstico, decisão, LED integrado e registro serial são exercitados sem mudar tensão, fios ou conexões.

Use um modo de teste explícito e reversível: sua ativação precisa aparecer no registro e o retorno ao modo normal deve ser conhecido. O firmware de referência deste step é autocontido para o Arduino Uno R3 e usa somente A0, o LED integrado e a porta serial.

A injeção não demonstra o comportamento elétrico do sensor, do condicionamento nem do ADC. Ela demonstra somente os caminhos posteriores ao ponto em que o dado é entregue à validação.

Execute localmente, um caso por vez

1. Mantenha a montagem e as conexões inalteradas; conecte o Uno ao computador por USB.
2. Cole o código desta tela no Arduino IDE, selecione a placa e a porta corretas e envie-o.
3. Abra o Monitor Serial em 9600 baud e aguarde AMOSTRA_VALIDA.
4. Envie um único caractere: I para inválido, S para antigo ou A para ausente.
5. Registre a transição de falha. Antes de testar outro caso, pressione o botão RESET da placa e aguarde novamente a amostra inicial válida.

Cada caso começa, portanto, com o modo NORMAL, sem falha retida. O LED integrado acende quando a falha é reconhecida e permanece assim até o próximo reinício. A recuperação não é avaliada neste ensaio.

Firmware completo para o Uno R3. A injeção altera apenas a amostra entregue após a aquisição. Reinicie a placa antes de cada caso para obter um estado inicial conhecido.

Três sequências, três evidências

• Inválido (I): entrega uma amostra cujo código viola a faixa aceita pela aplicação: 1100. A validação acusa o valor imediatamente.
• Antigo (S): entrega uma amostra, mas com marca temporal de 2 s no passado. O valor pode continuar plausível; o diagnóstico acusa que a idade excede o prazo.
• Ausente (A): deixa de entregar novas amostras. O loop() continua rodando; por isso, o relógio avança e o diagnóstico consegue reconhecer o vencimento do prazo.

Não use delay() para representar ausência. Uma espera bloqueante pararia justamente o processamento que precisa verificar a passagem do tempo.

Para cada injeção, defina um roteiro observável antes de iniciá-la. Registre a condição inicial, o instante da injeção, a indicação de falha esperada, o estado previsto da saída e o prazo máximo.

No monitor didático, suponha que uma amostra deixa de ser aceita em t = 1300 ms. A última amostra válida foi aceita em t = 1200 ms, e o requisito é reconhecer ausência de amostra em até 1000 ms desde essa última aceitação. Portanto, o vencimento esperado é t = 2200 ms.

O relógio relevante depende do requisito. Aqui, medir 1000 ms desde o clique que ativa a injeção seria incorreto: entre o clique e a última amostra válida ainda pode haver uma amostra já adquirida e aceita.

Este é um exemplo de registro de referência para um caso de ausência de novas amostras. Ele informa o que o firmware declarou e comandou; não é, por si só, uma medição elétrica do LED.

Registro de referência para interpretação

A última amostra válida em 1200 ms fixa o limite em 2200 ms. Em 2190 ms, a idade ainda é 990 ms; não há falha. O reconhecimento em 2210 ms ocorre depois do vencimento, com atraso de 10 ms compatível com um laço que não avalia continuamente.

O registro sustenta que o firmware reconheceu a falha e enviou o comando LOW. Para sustentar o estado elétrico da saída, seria necessária uma observação local apropriada — por exemplo, estado visível do LED integrado ou medição no pino, conforme o critério definido. Não transforme um comando serial em evidência de tensão sem essa observação.

Com a última amostra válida em 1200 ms e prazo de 1000 ms, qual interpretação é correta para um reconhecimento registrado em 2210 ms?

Recuperar não é apenas apagar uma indicação de erro. É autorizar o retorno ao funcionamento porque chegaram evidências novas que satisfazem um critério definido.

No monitor didático, enquanto houver falha confirmada, o LED permanece no estado previsto para falha. Retirar a injeção de teste só inicia a observação da recuperação: ainda é preciso receber dados novos, válidos e estáveis.

Assim, uma única amostra boa não deve liberar a saída automaticamente se o requisito pede confirmação.

Um critério explícito evita uma recuperação prematura. Para este caso didático, defina:

• Validade: a amostra passa pelas verificações da aplicação.
• Atualização: ela é uma entrega nova; reapresentar uma amostra antiga não conta.
• Estabilidade: são necessárias três amostras novas e válidas consecutivas.

Se surgir uma amostra inválida, antiga ou ausente antes da terceira confirmação, o contador volta a zero e o estado de falha continua. O número três é uma decisão do caso didático; outro sistema pode exigir uma sequência maior, um intervalo estável ou autorização explícita do operador.

Trecho ilustrativo da decisão de recuperação no firmware.

Complete a condição que só contabiliza evidência de recuperação quando a amostra é válida e recém-entregue ao sistema.

Dois procedimentos, duas perguntas

Reinicializar pelo recurso previsto da placa reinicia o firmware enquanto a alimentação permanece presente. Isso exercita a partida lógica: estados iniciais, mensagens de partida e a exigência de novas amostras.

Desligar normalmente a alimentação interrompe a energia e depois permite uma nova partida. Isso exercita também o comportamento associado à perda e ao retorno normais da alimentação.

Não trate os dois como equivalentes. Um reinício bem-sucedido não demonstra o comportamento após desligamento; um ciclo normal de alimentação não prova todos os detalhes temporais do reinício do firmware.

Antes de uma prática física, confirme que há um meio apropriado de desligamento e identifique todas as fontes que podem manter a placa energizada — inclusive o USB.

Mantenha cabos e conexões fixos. Faça apenas desligamento e religamento normais, com tempo suficiente para observar a partida. Se não for possível garantir uma interrupção adequada de todas as fontes, não improvise: use a análise de registros apresentada mais adiante.

Coloque as ações na ordem de um procedimento seguro de desligamento e reinicialização. Considere que a configuração normal já está montada e que existe um meio apropriado para desligar todas as fontes.

Organize o procedimento.

Na partida, registre pelo menos: procedimento usado, estado inicial esperado da saída, indicação de falha, instante da primeira nova amostra válida e condição para retomar o funcionamento.

Uma leitura que existia antes do reinício não deve autorizar retomada depois dele. Reiniciar remove a execução anterior; não demonstra que a causa de uma falha desapareceu. A recuperação depende de evidências novas e válidas que satisfaçam o critério definido.

Condições que ficam na análise

Curto-circuito, inversão de alimentação, sobrecarga e sobretemperatura não são casos para provocar na montagem didática. Eles podem ser estudados por um esquema equivalente, cálculos e registros numéricos.

A pergunta útil não é “o que acontece se eu fizer o defeito?”, mas: por qual caminho a corrente poderia circular, quais impedâncias a limitariam e quais componentes ficariam expostos?

Uma fonte com limite de corrente também faz parte do modelo, mas seu limite não torna seguro criar um curto, inverter a polaridade ou aquecer componentes deliberadamente.

Uma matriz de falhas e recuperação registra o que foi examinado, em qual configuração e com qual evidência. Ela não é uma lista de garantias.

Para cada caso, registre a configuração de hardware e firmware, o modo de falha, o método, o ponto de injeção, a resposta esperada e o prazo. Depois, registre separadamente a evidência obtida, o resultado da resposta à falha, o resultado da recuperação e qualquer limitação de detecção.

O ponto de injeção delimita a conclusão. Uma injeção entre aquisição e validação exercita o diagnóstico, a decisão, a indicação e a recuperação posteriores a esse ponto; ela não demonstra o comportamento elétrico do sensor ou do condicionamento.

Associe cada registro à classificação mais honesta. Considere que o critério exige comprovar o estado da saída, não apenas registrar um comando no firmware.

Fechamento aplicado

A matriz final liga cada modo de falha ao método, à evidência, ao critério e a uma conclusão proporcional. No firmware de referência do step de injeção, a falha é injetada depois da aquisição: isso exercita validação, diagnóstico, decisão e registro, mas não comprova a integridade elétrica do sensor, do condicionamento ou do ADC.

“Executado” significa que um procedimento foi aplicado. Não significa que todas as falhas possíveis foram cobertas.

Considere o registro numérico abaixo, fornecido para a configuração de avaliação CFG-R3. Ela não é o firmware de referência do step 4. Para este caso, CFG-R3 foi definida com estas regras: considera falha quando a idade da última amostra válida é maior ou igual a 1000 ms; mantém a saída no estado de falha; e só autoriza a retomada após três amostras novas e válidas consecutivas.

As reapresentações antigas não renovam a marca temporal. O registro é evidência da execução de CFG-R3 e de suas transições declaradas; sozinho, ele não mede eletricamente o estado do LED.