Modellazione dei guasti per sistemi integrati


10

Ho un circuito di sensori wireless con un microcontrollore e un modulo ricetrasmettitore da 2,4 GHz , alcuni sensori integrati con interfaccia I²C, una porta UART e i componenti discreti necessari.

Questa scheda è progettata per assorbire energia da un pannello solare (PV), con una batteria LiPo e un caricatore shunt . Ciò consente al sensore di autoalimentarsi e funzionare per un tempo indefinito, richiedendo la minima manutenzione possibile.

Mi piacerebbe esplorare i possibili guasti che possono verificarsi in un sistema come questo e che possono essere dovuti a invecchiamento, violazione delle specifiche ambientali (temperatura, umidità e così via) o manutenzione errata (non problemi di progettazione / bug), in al fine di massimizzare la sua durata operativa.

L'ambiente in cui opera il nodo sensore è un edificio, attaccato al soffitto o alle pareti. Quindi le temperature estreme o la pioggia non sono considerate.

Quello che mi è venuto in mente sono alcuni difetti che provo a riassumere:

  • Componente rotto -> aperto \ cortocircuito
  • Sensore difettoso -> valori di uscita errati (ma come sbagliato?)
  • Difetto dell'isolamento dovuto a polvere \ acqua -> aumento delle perdite
  • Temperatura fuori range -> ???

Come posso stimare come il nodo del sensore non funzionerà e perché?


Non dimenticare che il sensore può essere semplicemente distrutto da chiunque / qualunque cosa e meccanicamente rotto, il che può causare guasti che potresti immaginare.
sharptooth,

Sì, ormai stavo anche trascurando la manomissione, dato che è un caso limite ... ma ogni suggerimento è il benvenuto!
clabacchio

pannello solare che si sporca e non genera abbastanza energia. Sono sicuro che la vita su alcuni dispositivi MEMS è molto sensibile all'ambiente ... indovinando.
Kenny,

Qual è lo scopo del tuo studio? Potrebbe ad esempio ridurre il tasso di fallimento, ridurre l'effetto del fallimento (fail soft), ridurre il rischio (rilevare il fallimento invece di procedere senza mezzi termini), ecc., Che richiedono tutti approcci diversi.
Wouter van Ooijen,

Risposte:


7

Esistono troppi gradi di libertà per comprendere "tutti" i possibili difetti. Esistono, tuttavia, tecniche per identificare e mitigare i guasti nelle prime fasi del ciclo di progettazione (vale a dire prima del rilascio esteso).

Attività in fase di progettazione (pre-hardware)

La revisione tra pari è sempre un ottimo modo per trovare i bug. Chiedi a qualcun altro di analizzare il tuo progetto ed essere pronto a difenderti dalle loro domande (o riconoscere che hanno trovato un bug e risolverlo!) Non c'è sostituto per il controllo e gli occhi freschi spesso vedono cose che mancano a quelli stanchi. Questo funziona sia per l'hardware che per il software: gli schemi possono essere rivisti facilmente come il codice sorgente.

Per l'hardware, come altri hanno già detto, una DFMEA ( Design Failure Mode and Analysis Analysis ) è una buona raccomandazione. Per ogni componente, chiediti "cosa succede se si cortocircuita" e "cosa succede se questo va in circuito aperto" e registra la tua analisi. Per i circuiti integrati, immagina anche cosa succede se i pin adiacenti sono in corto tra loro (ponti di saldatura, ecc.)

Per il firmware, è possibile utilizzare strumenti di analisi del codice statico (MISRA, lint, ecc.) Per rivelare bug nascosti nel codice. Cose come puntatori mobili e uguaglianza anziché confronto (= vs ==) sono comuni "oopsie" a cui questi strumenti non mancheranno.

Anche una teoria scritta del funzionamento è molto utile, sia per l'hardware che per il software. Una teoria dell'operazione dovrebbe descrivere a un livello abbastanza alto come funziona il sistema, come funzionano le protezioni, il sequenziamento, ecc. Mettere semplicemente a parole come dovrebbe fluire la logica spesso porta a rendersi conto che alcuni casi potrebbero essersi persi ("Uhm, waitasec, che dire di questa condizione? ")

Test a livello di prototipo

Una volta che hai l'hardware in mano, è il momento di "lavorare".

Dopo aver eseguito tutte le analisi teoriche, è fondamentale caratterizzare con precisione il funzionamento del dispositivo in base alle specifiche. Questo è comunemente indicato come test di validazione o qualifica. Tutti gli estremi consentiti devono essere testati.

Un'altra importante attività di qualificazione è l'analisi dello stress dei componenti. Ogni parte viene valutata rispetto alla sua massima tensione / corrente / temperatura, in una condizione operativa definita. Per garantire la robustezza, è necessario applicare una linea guida di declassamento appropriata (non superare l'80% della tensione, il 70% della potenza, ecc.)

Solo una volta che sai come stanno le cose in condizioni normali, puoi iniziare a speculare su anomalie esterne o multiple anomalie come stai descrivendo. Ancora una volta, il modello DFMEA (cosa succede se succede X) è un buon approccio. Pensa a qualsiasi cosa possibile che un utente possa fare all'unità: uscite brevi, collegare segnali, versare acqua su di esso: provali e vedi cosa succede.

Un test HALT (test di vita altamente accelerato ) è utile anche per questi tipi di sistemi. L'unità viene inserita in una camera ambientale ed esercitata dalla temperatura minima a massima, minimo e massimo in ingresso e in uscita, con vibrazione. Questo troverà tutti i tipi di problemi, sia elettrici che meccanici.

Questo è anche un buon momento per fare alcuni test di fuzz integrati : esercita tutti gli input ben oltre i loro range previsti, invia senza senso attraverso UART / I2C, ecc. Per trovare buchi nella logica. (Le routine I2C con bit di bit sono note per bloccare il bus, per esempio.)

I test di sciopero sono un buon modo per dimostrare robustezza. Disabilita qualsiasi funzione di protezione come sovratemperatura, sovraccarico, ecc. E applica lo stress fino a quando qualcosa non si rompe. Portare l'unità alla massima temperatura possibile fino a quando qualcosa non riesce o si verifica un comportamento irregolare. Sovraccaricare l'unità fino a quando la trasmissione non si guasta. Se alcuni parametri falliscono solo leggermente al di sopra delle condizioni peggiori, potrebbe essere necessario rivedere alcune considerazioni sulla progettazione.

Puoi anche adottare l'approccio di livello successivo e testare fisicamente alcune delle tue conclusioni di DFMEA: effettivamente esegui i pantaloncini e le aperture e i pin-pantaloncini e vedi cosa esplode.

Ulteriori letture

Il mio background è nella conversione di potenza. Abbiamo uno standard industriale chiamato IPC-9592A che è uno sforzo per standardizzare come i prodotti dovrebbero essere qualificati in termini di quali test e come dovrebbero essere fatti. Molti dei tipi di test e metodologie citati da questo documento potrebbero essere facilmente utilizzati in altre discipline elettriche.


6

Con più dispositivi sull'interfaccia I2C hai la possibilità del problema "babbling idiot" in cui un dispositivo si guasta, fa da padrone all'I2C e uccide tutte le altre trasmissioni I2C.

I test di immersione combinati con i test ambientali fornirebbero una diversa forma di analisi dei guasti. L'uso di componenti marginali, temperature massime / minime / fluttuanti, umidità diverse, alimentazioni sporche, ambienti rumorosi, ecc. Per un periodo di tempo simula un periodo molto più lungo di normale utilizzo. Il sistema avrà guasti reali e possono essere calcolati i tassi di errore.


3

Molto probabilmente l'errore sono i bug del firmware. Tutto quello che ho fatto ne ha avuti alcuni.

Assicurati di avere un timer watchdog abilitato e di richiedere che tutte le funzioni critiche ripetute si verifichino prima di "accarezzare il cane". Mi piace impostare un flag nell'interrupt del timer e usarlo per cancellare il watchdog nel loop principale.

Verifica anche il ripristino del firmware su cicli di ripristino.

Poiché l'avvio è quando si verificano molti guasti, mi piace alimentare un relè, quindi scrivere uno script rapido per spegnere e riaccendere, attendere che la radio indichi sveglia, ripetere. Quindi eseguire questa operazione per circa 10000 cicli.


Test di accensione molto interessante. La mia ultima azienda aveva un progetto che doveva funzionare per diversi anni rimanendo sincronizzato con un trasmettitore stupido e non poteva criticare durante quel periodo, rimuovere i bug del firmware era probabilmente la parte più difficile.
Kortuk,

2

Alcuni ovvi:

  • Batteria scarica. Possibile perdita di elettrolita che porta alla contaminazione dell'elettronica
  • Sovratensione dall'impianto fotovoltaico
  • Si sta muovendo o vicino a macchinari? Quindi shock / vibrazioni
  • Perdita di comunicazione a causa di ambiente esterno (pioggia / neve che assorbe il segnale, ecc.).

Se stai eseguendo una FMEA, devi prima considerare quanto sia critico il sistema prima di poter decidere cosa costituisce un errore.


2

Sono sorpreso che nessuno abbia menzionato Test di vita accelerati e Test di vita altamente accelerati .

Uno degli strumenti importanti che hai a disposizione è che per ogni aumento di 10 gradi centigradi, l'affidabilità media è ridotta del 50 percento. Puoi avere un'idea della vita del tuo prodotto testandolo a una temperatura notevolmente aumentata. Non è necessario testare i componenti oltre la loro temperatura nominale per trarne vantaggio.

Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.