Modelagem de falhas para sistemas embarcados


10

Eu tenho um circuito de sensor sem fio com um microcontrolador e um módulo transceptor de 2,4 GHz , alguns sensores integrados com interface I²C, uma porta UART e os componentes discretos necessários.

Esta placa foi projetada para extrair energia de um painel solar (PV), com uma bateria LiPo e um carregador de derivação . Isso permite que o sensor seja auto-alimentado e funcione por tempo indeterminado, exigindo a menor manutenção possível.

Eu gostaria de explorar as possíveis falhas que podem ocorrer em um sistema como este e que podem ser causadas pelo envelhecimento, violação de especificações ambientais (temperatura, umidade e assim por diante) ou manutenção incorreta (sem problemas de design / bugs), em para maximizar sua vida útil de operação.

O ambiente em que o nó do sensor opera é um edifício, colado no teto ou nas paredes. Portanto, temperaturas extremas ou chuva não são consideradas.

O que descobri são algumas falhas que tento resumir:

  • Componente quebrado -> aberto \ curto-circuito
  • Sensor com defeito -> valores de saída incorretos (mas quão errado?)
  • Proteger o isolamento devido a poeira \ água -> aumento de vazamento
  • Temperatura fora da faixa -> ???

Como posso estimar como o nó do sensor falhará e por quê?


Não esqueça que o sensor pode ser esmagado por quem quer que seja e que seja quebrado mecanicamente, o que pode causar falhas que você possa imaginar.
Sharptooth

Sim, agora eu também estava negligenciando a adulteração, pois é um caso limite ... mas qualquer sugestão é bem-vinda!
clabacchio

painel solar ficando mole e sem gerar energia suficiente. Tenho certeza que a vida em algum dispositivo MEMS é muito sensível ao meio ambiente ... adivinhando.
Kenny

Qual é o objetivo do seu estudo? Poderia, por exemplo, reduzir a taxa de falhas, reduzir o efeito de falha (falha suave), reduzir o risco (detectar falhas em vez de continuar sem rodeios), etc., que exigem abordagens diferentes.
Wouter van Ooijen

Respostas:


7

Existem muitos graus de liberdade para entender "todas" as possíveis falhas. Existem, no entanto, técnicas para identificar e atenuar falhas no início do ciclo de design (ou seja, antes da liberação ampla).

Atividades em tempo de design (pré-hardware)

A revisão por pares é sempre uma ótima maneira de encontrar bugs. Peça a alguém que analise seu design e esteja preparado para defender-se das perguntas deles (ou reconhecer que encontrou um bug e consertá-lo!) Isso funciona para hardware e software - os esquemas podem ser revisados ​​tão facilmente quanto o código-fonte.

Para o hardware, como outros já disseram, uma DFMEA ( Modo de falha de design e análise de efeitos ) é uma boa recomendação. Para cada componente, pergunte a si mesmo "o que acontece se isso cair" e "o que acontece se isso entrar em circuito aberto" e faça um registro de sua análise. Para os CIs, imagine também o que acontece se os pinos adjacentes estiverem em curto entre si (pontes de solda, etc.)

Para o firmware, ferramentas de análise de código estático (MISRA, fiapos etc.) podem ser usadas para revelar erros ocultos no código. Coisas como ponteiros flutuantes e igualdade em vez de comparação (= vs ==) são 'oopsies' comuns que essas ferramentas não perderão.

Uma teoria escrita da operação também é muito útil, tanto para hardware quanto para software. Uma teoria da operação deve descrever em um nível razoavelmente alto como o sistema funciona, como as proteções funcionam, seqüenciamento, etc. Simplesmente colocar em palavras como a lógica deve fluir geralmente leva a perceber que alguns casos podem ter sido perdidos ("Hum, waitasec, e essa condição? ")

Teste de nível de protótipo

Depois de colocar o hardware em mãos, é hora de "trabalhar".

Após toda a análise teórica, é crucial caracterizar com precisão como o dispositivo opera dentro das especificações. Isso geralmente é chamado de teste ou qualificação de validação. Todos os extremos permitidos precisam ser testados.

Outra atividade importante de qualificação é a análise de estresse por componentes. Cada peça é avaliada em relação à sua tensão / corrente / temperatura máxima, em uma condição operacional definida. Para garantir a robustez, deve-se aplicar uma diretriz de redução adequada (não exceda 80% da tensão, 70% da potência, etc.)

Somente depois que você souber como as coisas estão em condições normais, você poderá começar a especular sobre anormalidades externas ou múltiplas anormais que você está descrevendo. Novamente, o modelo DFMEA (o que acontece se X acontecer) é uma boa abordagem. Pense em qualquer coisa possível que um usuário possa fazer com a unidade - saídas curtas, amarre sinais juntos, derrame água nela - experimente-os e veja o que acontece.

Um teste HALT (teste de vida altamente acelerado ) também é útil para esses tipos de sistemas. A unidade é colocada em uma câmara ambiental e exercida da temperatura mínima à máxima, entrada e saída mínima e máxima, com vibração. Isso encontrará todos os tipos de problemas, tanto elétricos quanto mecânicos.

Este também é um bom momento para realizar alguns testes de fuzz incorporados - exercite todas as entradas muito além dos intervalos esperados, envie mensagens sem sentido através de UARTs / I2C, etc., para encontrar falhas na lógica. (As rotinas I2C com interrupção de bits são notórias por bloquear o barramento, por exemplo.)

O teste de conflito é uma boa maneira de demonstrar robustez. Desative todos os recursos de proteção como superaquecimento, sobrecarga etc. e aplique tensão até que algo quebre. Pegue a unidade na temperatura mais alta possível até que algo falhe ou ocorra algum comportamento irregular. Sobrecarregue a unidade até o trem de força falhar. Se algum parâmetro falhar apenas um pouco acima das condições de pior caso, é uma indicação de marginalidade e alguma consideração do projeto pode ter que ser revisada.

Você também pode adotar a abordagem de próximo nível e testar fisicamente algumas de suas conclusões do DFMEA - na verdade, faça os curtas-metragens e as aberturas e os pin-shorts e veja o que explode.

Leitura adicional

Minha formação é em conversão de energia. Temos um padrão do setor chamado IPC-9592A, que é um esforço para padronizar como os produtos devem ser qualificados em termos de quais testes e como devem ser realizados. Muitos dos tipos de testes e metodologias mencionados neste documento podem ser facilmente usados ​​em outras disciplinas elétricas.


6

Com vários dispositivos na interface I2C, você tem a possibilidade do problema de "idiota tagarela" onde um dispositivo falha, monopoliza o I2C e mata todas as outras transmissões I2C.

Os testes de imersão combinados com os testes ambientais forneceriam uma forma diferente de análise de falhas. O uso de componentes marginais, temperaturas máximas / mínimas / flutuantes, diferentes umidade, fontes de alimentação sujas, ambientes barulhentos, etc. durante um período de tempo simula um período muito mais longo de uso normal. O sistema terá falhas reais e as taxas de falha podem ser calculadas.


3

A falha mais provável são os erros de firmware. Tudo o que fiz já teve alguns.

Verifique se você tem um cronômetro de vigilância ativado e exija que todas as funções repetidas críticas ocorram antes de "acariciar o cão". Eu gosto de definir uma bandeira na interrupção do timer e usá-la para limpar o watchdog no loop principal.

Teste a recuperação do firmware também nos ciclos de redefinição.

Como a inicialização ocorre quando ocorrem muitas falhas, eu gosto de ligar um relé e, em seguida, escrevo um script rápido para o ciclo de energia, aguarde o rádio indicar ativação, repita. Em seguida, faça isso por 10000 ciclos ou mais.


Poder muito interessante no teste. Minha última empresa teve um projeto que teve que ser executado por vários anos, permanecendo sincronizado com um transmissor burro e não pôde falhar durante esse período, remover os bugs do firmware foi provavelmente a parte mais difícil.
Kortuk

2

Alguns óbvios:

  • Falha na bateria. Possivelmente perda de eletrólito levando à contaminação dos eletrônicos
  • Sobretensão do sistema fotovoltaico
  • Está se movendo ou próximo a máquinas? Então choque / vibração
  • Perda de comunicação devido ao ambiente externo (chuva / neve absorvendo o sinal, etc).

Se você estiver fazendo um FMEA, primeiro considere a importância do sistema antes de decidir o que constitui uma falha.


2

Estou surpreso que ninguém tenha mencionado o Teste de vida acelerado e o Teste de vida altamente acelerado .

Uma das ferramentas importantes que você tem à sua disposição é que, para cada aumento de temperatura de 10 graus centígrados, a confiabilidade média diminui em 50%. Você pode ter uma idéia da vida útil do seu produto testando-o a uma temperatura muito maior. Você não precisa testar componentes além da temperatura nominal para tirar proveito disso.

Ao utilizar nosso site, você reconhece que leu e compreendeu nossa Política de Cookies e nossa Política de Privacidade.
Licensed under cc by-sa 3.0 with attribution required.