Modélisation des défauts pour les systèmes embarqués


10

J'ai un circuit de capteur sans fil avec un microcontrôleur et un module émetteur-récepteur 2,4 GHz , certains capteurs intégrés avec interface I²C, un port UART et les composants discrets nécessaires.

Cette carte est conçue pour éliminer l'énergie d'un panneau solaire (PV), avec une batterie LiPo et un chargeur shunt . Cela permet au capteur d'être auto-alimenté et de fonctionner pendant une durée indéterminée, nécessitant le moins d'entretien possible.

Je voudrais explorer les défauts possibles qui peuvent se produire dans un système comme celui-ci, et qui peuvent être dus au vieillissement, à la violation des spécifications environnementales (température, humidité, etc.) ou à une mauvaise maintenance (pas de problèmes de conception / bogues), dans afin de maximiser sa durée de vie.

L'environnement dans lequel fonctionne le nœud du capteur est un bâtiment, collé au plafond ou aux murs. Les températures extrêmes ou la pluie ne sont donc pas prises en compte.

Ce que j'ai trouvé, ce sont des défauts que j'essaie de résumer:

  • Composant cassé -> ouvert \ court-circuit
  • Capteur défectueux -> valeurs de sortie erronées (mais à quel point?)
  • Isolation défectueuse due à la poussière \ eau -> fuite accrue
  • Température hors plage -> ???

Comment puis-je estimer la défaillance du nœud du capteur et pourquoi?


N'oubliez pas que le capteur peut être simplement écrasé par quiconque / quoi que ce soit et cassé mécaniquement, ce qui peut provoquer des défauts que vous pourriez imaginer.
Dentranchante

Oui, maintenant je négligeais également la falsification, car c'est un cas limite ... mais toute suggestion est la bienvenue!
clabacchio

panneau solaire encrassé et ne produisant pas assez d'électricité. Je suis sûr que la vie sur certains appareils MEMS est très sensible à l'environnement ... deviner.
kenny

Quel est le but de votre étude? Cela pourrait par exemple réduire le taux d'échec, réduire l'effet d'échec (échec doux), réduire le risque (détecter l'échec au lieu de continuer sans ambages), etc., qui nécessitent tous des approches différentes.
Wouter van Ooijen

Réponses:


7

Il y a beaucoup trop de degrés de liberté pour comprendre "tous" les défauts possibles. Il existe cependant des techniques pour identifier et atténuer les défauts au début du cycle de conception (c'est-à-dire avant une large diffusion).

Activités au moment de la conception (pré-matériel)

L'examen par les pairs est toujours un excellent moyen de trouver des bogues. Demandez à quelqu'un d'autre d'analyser votre conception et préparez-vous à vous défendre contre ses questions (ou reconnaissez qu'il a trouvé un bug et corrigez-le!) Cela fonctionne pour le matériel et le logiciel - les schémas peuvent être revus aussi facilement que le code source.

Pour le matériel, comme d'autres l'ont dit, un DFMEA ( Design Failure Mode and Effects Analysis ) est une bonne recommandation. Pour chaque composant, demandez-vous «ce qui se passe si cela court-circuite» et «ce qui se passe si cela passe en circuit ouvert», et enregistrez votre analyse. Pour les CI, imaginez également ce qui se passe si des broches adjacentes sont court-circuitées (ponts de soudure, etc.)

Pour le firmware, des outils d' analyse de code statique (MISRA, lint, etc.) peuvent être utilisés pour révéler des bogues cachés dans le code. Des choses comme les pointeurs flottants et l'égalité au lieu de comparer (= vs ==) sont des «oopsies» courantes que ces outils ne manqueront pas.

Une théorie écrite du fonctionnement est également très utile, tant pour le matériel que pour le logiciel. Une théorie de fonctionnement devrait décrire à un niveau assez élevé le fonctionnement du système, le fonctionnement des protections, le séquençage, etc. La simple mise en mots de la façon dont la logique devrait circuler conduit souvent à se rendre compte que certains cas peuvent avoir été manqués ("Um, waitasec, qu'en est-il de cette condition? ")

Test au niveau du prototype

Une fois le matériel en main, il est temps de "travailler".

Une fois toutes les analyses théoriques effectuées, il est essentiel de caractériser avec précision le fonctionnement de l'appareil dans le cadre des spécifications. Ceci est communément appelé test de validation ou qualification. Tous les extrêmes autorisés doivent être testés.

Une autre activité de qualification importante est l'analyse des contraintes des composants. Chaque pièce est évaluée par rapport à sa tension / courant / température maximale, dans une condition de fonctionnement définie. Afin d'assurer la robustesse, une directive de déclassement appropriée doit être appliquée (ne pas dépasser 80% de la tension, 70% de la puissance, etc.)

Ce n'est qu'une fois que vous savez comment les choses se passent dans des conditions normales que vous pouvez commencer à spéculer sur des anomalies externes ou de multiples anomalies comme vous le décrivez. Encore une fois, le modèle DFMEA (ce qui se passe si X se produit) est une bonne approche. Pensez à tout ce qu'un utilisateur pourrait faire à l'appareil - sorties courtes, relier les signaux ensemble, renverser de l'eau dessus - essayez-les et voyez ce qui se passe.

Un test HALT (test de vie hautement accéléré ) est également utile pour ces types de systèmes. L'unité est placée dans une chambre environnementale et exercée de la température minimale à maximale, l'entrée et la sortie minimale et maximale, avec vibration. Cela trouvera toutes sortes de problèmes, à la fois électriques et mécaniques.

C'est aussi le bon moment pour faire des tests de fuzz intégrés - exercer toutes les entrées bien au-delà de leurs plages attendues, envoyer du charabia via les UART / I2C, etc. pour trouver des trous dans la logique. (Les routines I2C binaires sont connues pour verrouiller le bus, par exemple.)

Les tests de résistance sont un bon moyen de démontrer la robustesse. Désactivez toutes les fonctions de protection comme la surchauffe, la surcharge, etc. et appliquez une tension jusqu'à ce que quelque chose se casse. Montez l'unité à une température aussi élevée que possible jusqu'à ce que quelque chose tombe en panne ou qu'un comportement erratique se produise. Surchargez l'unité jusqu'à ce que le groupe motopropulseur tombe en panne. Si certains paramètres échouent légèrement au-dessus des conditions les plus défavorables, il peut être nécessaire de réexaminer une indication de marginalité et une certaine considération de conception.

Vous pouvez également adopter l'approche de niveau supérieur et tester physiquement certaines de vos conclusions DFMEA - faites en fait les shorts et les ouvertures et les pin-shorts et voyez ce qui explose.

Lectures complémentaires

Mon expérience est dans la conversion de puissance. Nous avons une norme industrielle appelée IPC-9592A qui est un effort pour normaliser la façon dont les produits doivent être qualifiés en termes de quels tests et comment ils doivent être effectués. De nombreux types de tests et de méthodologies mentionnés dans ce document pourraient facilement être utilisés dans d'autres disciplines électriques.


6

Avec plusieurs appareils sur l'interface I2C, vous avez la possibilité du problème "idiot babillant" lorsqu'un appareil tombe en panne, monopolise l'I2C et tue toutes les autres transmissions I2C.

Les tests de trempage combinés aux tests environnementaux fourniraient une forme différente d'analyse des défaillances. L'utilisation de composants marginaux, des températures maximales / minimales / fluctuantes, des humidités différentes, des blocs d'alimentation sales, des environnements RF bruyants, etc. sur une période de temps simule une période beaucoup plus longue d'utilisation normale. Le système connaîtra de véritables défaillances et les taux de défaillance peuvent être calculés.


3

La faute la plus probable est les bogues du firmware. Tout ce que j'ai fait en a eu quelques-uns.

Assurez-vous que la minuterie du chien de garde est activée et que toutes les fonctions critiques répétées doivent se produire avant de «caresser le chien». J'aime mettre un drapeau dans l'interruption du minuteur et l'utiliser pour effacer le chien de garde dans la boucle principale.

Testez également la récupération de votre firmware sur des cycles de réinitialisation.

Étant donné que le démarrage se produit lorsque de nombreuses défaillances se produisent, j'aime alimenter un relais, puis écrire un script rapide pour redémarrer, attendre que la radio indique le réveil, répéter. Ensuite, effectuez cette opération pour environ 10000 cycles.


Puissance très intéressante au test. Ma dernière entreprise avait un projet qui devait fonctionner pendant plusieurs années en restant synchronisé avec un émetteur stupide et qui ne pouvait pas être en panne pendant cette période, la suppression des bogues du micrologiciel était probablement la partie la plus difficile.
Kortuk

2

Quelques exemples évidents:

  • Panne de batterie. Peut-être une perte d'électrolyte entraînant une contamination de l'électronique
  • Surtension du système PV
  • Se déplace-t-il ou à proximité de machines? Puis choc / vibration
  • Perte de communication due à l'environnement extérieur (pluie / neige absorbant le signal, etc.).

Si vous effectuez une FMEA, vous devez d'abord considérer à quel point le système est critique avant de pouvoir déterminer ce qui constitue une erreur.


2

Je suis surpris que personne n'ait mentionné les tests de vie accélérée et les tests de vie hautement accélérés .

L'un des outils importants dont vous disposez est que pour chaque augmentation de température de 10 degrés centigrades, la fiabilité moyenne diminue de 50%. Vous pouvez avoir une idée de la durée de vie de votre produit en le testant à une température considérablement plus élevée. Vous n'avez pas à tester les composants au-delà de leur température nominale pour en profiter.

En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.