Tengo un circuito sensor inalámbrico con un microcontrolador y un módulo transceptor de 2,4 GHz , unos sensores integrados con interfaz I²C, un puerto UART y los componentes discretos necesarios.
Esta placa está diseñada para extraer energía de un panel solar (PV), con una batería LiPo y un cargador de derivación . Esto permite que el sensor sea autoalimentado y esté operando por un tiempo indefinido, requiriendo el menor mantenimiento posible.
Me gustaría explorar las posibles fallas que pueden ocurrir en un sistema como este, y que pueden deberse al envejecimiento, la violación de las especificaciones ambientales (temperatura, humedad, etc.) o un mantenimiento incorrecto (no problemas de diseño/errores), en para maximizar su vida útil de operación.
El entorno en el que opera el nodo sensor es un edificio, pegado al techo oa las paredes. Por lo que no se consideran temperaturas extremas ni lluvias.
Lo que se me ocurrió son algunas fallas que trato de resumir:
¿Cómo puedo estimar cómo fallará el nodo sensor y por qué?
Hay demasiados grados de libertad para comprender "todas" las fallas posibles. Sin embargo, existen técnicas para identificar y mitigar las fallas en las primeras etapas del ciclo de diseño (es decir, antes del lanzamiento general).
Actividades en tiempo de diseño (pre-hardware)
La revisión por pares siempre es una excelente manera de encontrar errores. Pídale a otra persona que analice su diseño y prepárese para defenderse de sus preguntas (¡o reconozca que encontraron un error y lo solucionen!) No hay sustituto para el escrutinio, y los ojos frescos a menudo ven cosas que los cansados no ven. Esto funciona tanto para hardware como para software: los esquemas se pueden revisar tan fácilmente como el código fuente.
Para el hardware, como han dicho otros, un DFMEA ( Modo de falla de diseño y análisis de efectos ) es una buena recomendación. Para cada componente, pregúntese "qué sucede si se produce un cortocircuito" y "qué sucede si se abre un circuito", y anote su análisis. Para los circuitos integrados, imagine también lo que sucede si los pines adyacentes se cortocircuitan entre sí (puentes de soldadura, etc.)
Para el firmware, se pueden usar herramientas de análisis de código estático (MISRA, lint, etc.) para revelar errores ocultos en el código. Cosas como los punteros flotantes y la igualdad en lugar de comparar (= vs ==) son 'vaya' comunes que estas herramientas no perderán.
Una teoría escrita de la operación también es muy útil, tanto para el hardware como para el software. Una teoría de operación debe describir en un nivel bastante alto cómo funciona el sistema, cómo funcionan las protecciones, la secuencia, etc. Simplemente poner en palabras cómo debe fluir la lógica a menudo lleva a uno a darse cuenta de que algunos casos pueden haberse pasado por alto ("Um, waitasec, ¿qué pasa con esta condición?")
Pruebas de nivel de prototipo
Una vez que tenga el hardware a mano, es hora de ponerse a "trabajar".
Después de realizar todo el análisis teórico, es crucial caracterizar con precisión cómo funciona el dispositivo dentro de las especificaciones. Esto se conoce comúnmente como prueba de validación o calificación. Todos los extremos permitidos necesitan ser probados.
Otra actividad de cualificación importante es el análisis de tensión de los componentes. Cada pieza se evalúa frente a su tensión/corriente/temperatura máxima, en una condición de funcionamiento definida. Para garantizar la robustez, se debe aplicar una directriz de reducción adecuada (no superar el 80 % de la tensión, el 70 % de la potencia, etc.)
Solo una vez que sepa cómo son las cosas en condiciones normales, puede comenzar a especular sobre anomalías externas o anomalías múltiples como las que está describiendo. Nuevamente, el modelo DFMEA (qué sucede si sucede X) es un buen enfoque. Piense en cualquier cosa posible que un usuario podría hacerle a la unidad: salidas cortas, unir señales, derramar agua sobre ella, pruébelas y vea qué sucede.
Una prueba HALT (prueba de vida altamente acelerada ) también es útil para este tipo de sistemas. La unidad se coloca en una cámara ambiental y se ejercita de temperatura mínima a máxima, entrada y salida mínima y máxima, con vibración. Esto encontrará todo tipo de problemas, tanto eléctricos como mecánicos.
Este también es un buen momento para hacer algunas pruebas integradas de fuzz : ejercitar todas las entradas mucho más allá de sus rangos esperados, enviar galimatías a través de UART / I2C, etc. para encontrar agujeros en la lógica. (Las rutinas I2C de Bit-banged son notorias por bloquear el bus, por ejemplo).
Las pruebas de conflictos son una buena manera de demostrar robustez. Deshabilite cualquier función de protección como sobrecalentamiento, sobrecarga, etc. y aplique tensión hasta que algo se rompa. Lleve la unidad a la temperatura más alta posible hasta que algo falle o se produzca algún comportamiento errático. Sobrecargue la unidad hasta que falle el tren motriz. Si algún parámetro falla solo ligeramente por encima de las condiciones del peor de los casos, es una indicación de marginalidad y es posible que se deba revisar alguna consideración de diseño.
También puede tomar el enfoque del siguiente nivel y probar físicamente algunas de sus conclusiones DFMEA: en realidad, haga los cortos, abiertos y pin-shorts y vea qué explota.
Otras lecturas
Mi experiencia es en conversión de energía. Tenemos un estándar de la industria llamado IPC-9592A que es un esfuerzo por estandarizar cómo se deben calificar los productos en términos de qué pruebas y cómo se deben realizar. Muchos de los tipos de pruebas y metodologías mencionadas en este documento podrían usarse fácilmente en otras disciplinas eléctricas.
Con múltiples dispositivos en la interfaz I2C, existe la posibilidad del problema del "idiota balbuceante" en el que un dispositivo falla, acapara el I2C y elimina todas las demás transmisiones I2C.
Las pruebas de remojo combinadas con las pruebas ambientales proporcionarían una forma diferente de análisis de fallas. El uso de componentes marginales, temperaturas máximas/mínimas/fluctuantes, diferentes humedades, fuentes de alimentación sucias, entornos de radiofrecuencia ruidosos, etc. durante períodos de tiempo simula un período mucho más largo de uso normal. El sistema tendrá fallas reales y se pueden calcular las tasas de falla.
Lo más probable es que la falla sea un error de firmware. Todo lo que he hecho ha tenido unos cuantos.
Asegúrese de tener habilitado un temporizador de vigilancia y requiera que todas las funciones críticas repetidas sucedan antes de "acariciar al perro". Me gusta establecer una bandera en la interrupción del temporizador y usarla para borrar el perro guardián en el ciclo principal.
Pruebe también la recuperación de su firmware durante los ciclos de reinicio.
Dado que el inicio es cuando ocurren muchas fallas, me gusta alimentar a través de un relé, luego escribir un script rápido para reiniciar, esperar a que la radio indique que se activa, repetir. Luego haga esto durante 10000 ciclos más o menos.
Algunas obvias:
Si está haciendo un FMEA, primero debe considerar qué tan crítico es el sistema antes de poder decidir qué constituye una falla.
Me sorprende que nadie haya mencionado la prueba de vida acelerada y la prueba de vida altamente acelerada .
Una de las herramientas importantes que tiene a su disposición es que por cada aumento de temperatura de 10 grados centígrados, la confiabilidad promedio se reduce en un 50 por ciento. Puede hacerse una idea de la vida útil de su producto probándolo a una temperatura mucho mayor. No tiene que probar los componentes más allá de su temperatura nominal para aprovechar esto.
diente filoso
clabacchio
kenny
Wouter van Ooijen