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?
la source
Réponses:
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.
la source
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.
la source
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.
la source
Quelques exemples évidents:
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.
la source
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.
la source