10 votos

Falla de modelado para sistemas embebidos

Tengo un sensor inalámbrico circuito con un microcontrolador y un transceptor de 2,4 GHz módulo, algunos integrado de sensores con interfaz I2C, UART puerto y la necesaria componentes discretos.

Esta placa está diseñada para el borrado de energía de solar (PV) en el panel, con una batería de LiPo y una derivación del cargador. Esto permite que el sensor sea autoamplificados y operar por un tiempo indefinido, la que requiere menos mantenimiento.

Me gustaría explorar los posibles fallos que se pueden producir en un sistema como este, y que puede ser debido al envejecimiento, la violación de las especificaciones ambientales (temperatura, humedad, etc) o un mal mantenimiento (no el diseño de problemas/bugs), con el fin de maximizar su operación de toda la vida.

El entorno en el que el nodo de sensor opera es un edificio, pegada al techo o las paredes. Así, las temperaturas extremas o la lluvia no son considerados.

Lo que me ocurrió con algunos fallos que trataré de resumir:

  • Componente roto -> abrir\cortocircuito
  • Sensor defectuoso -> mal de los valores de salida (pero, ¿cómo de malo?)
  • Desertar de aislamiento debido al polvo\agua -> aumento de la fuga
  • Temperatura fuera de rango -> ???

¿Cómo puedo calcular cómo el nodo de sensor va a fallar, y por qué?

15voto

Armandas Puntos 552

Me sorprende que nadie haya mencionado Accelerated Life Testing y Pruebas de Vida Altamente Acelerada.

Una de las herramientas más importantes que tiene a su disposición es que por cada 10 grados Centígrados de temperatura, aumento de la temperatura, la fiabilidad media se redujo en un 50 por ciento. Usted puede obtener una idea de la vida de su producto por las pruebas en un considerable aumento en la temperatura. Usted no tiene que probar los componentes más allá de su rango de temperatura de tomar ventaja de esto.

9voto

Witek Puntos 116

Algunas obvias:

  • Falla de la batería. Posiblemente la pérdida de electrólito conduce a la contaminación de la electrónica
  • Sobretensión de la instalación fotovoltaica
  • ¿Es móvil o cerca de maquinaria? Luego de choque y vibración
  • Pérdida de comunicación debido a condiciones externas (lluvia/nieve absorbe la señal, etc.).

Si estás haciendo un FMEA necesita primero considerar lo importante el sistema que es antes de que usted puede decidir lo que constituye una falla.

7voto

jason saldo Puntos 5036

Hay demasiados grados de libertad para comprender "todas" las posibles fallas. Hay, sin embargo, las técnicas para identificar y mitigar las fallas tempranas en el ciclo de diseño (es decir, antes del lanzamiento ancho).

En tiempo de diseño de actividades (pre-hardware)

De la revisión de pares es siempre una gran manera de encontrar errores. Tener a alguien más que analizar su diseño, y estar preparado para defenderse de sus preguntas (o reconocer que se ha encontrado un error y solucionarlo!) No hay sustituto para el escrutinio, y los ojos frescos suelen ver cosas que están perdidas por el cansancio. Esto funciona tanto para el hardware y el software - esquemas pueden ser revisados tan fácilmente como código fuente.

Para el hardware, como otros han dicho, un DFMEA (Diseño de Modo de Falla y Análisis de Efectos) es una buena recomendación. Para cada componente, pregúntese "¿qué pasa si esta cortos" y "¿qué pasa si esto va de circuito abierto", y hacer un registro de su análisis. Para ICs, también imaginar lo que sucede si adyacentes pines están en cortocircuito entre otros (soldadura de puentes, etc.)

Para el firmware, análisis de código estático herramientas (MISRA, pelusa, etc.) puede ser utilizado para revelar oculto errores en el código. Cosas como flotando los punteros y la igualdad, en lugar de comparar (= vs ==) son comunes 'oopsies' que estas herramientas no se la pierda.

Un escrito de teoría de la operación es también muy útil, por tanto de hardware como de software. Una teoría de la operación debe describir en un nivel bastante alto de cómo funciona el sistema, cómo las protecciones de trabajo, la secuenciación, etc. Simplemente poner en palabras cómo la lógica del flujo a menudo conduce a uno darse cuenta de que en algunos casos puede que se hayan perdido ("Um, waitasec, ¿qué acerca de esta condición?")

Prototipo de pruebas de nivel

Una vez que usted consigue de hardware en la mano, es el momento para ir a "trabajar".

Después de todo el análisis teórico, se realiza, es crucial para caracterizar con precisión el modo en que el dispositivo opera dentro de las especificaciones. Esto es comúnmente conocido como la prueba de la validación o certificación. Todos los límites extremos de la necesidad de ser probado.

Otro importante la calificación de la actividad es un componente de análisis de tensión. Cada parte se evalúa en contra de su máxima tensión/corriente/temperatura, en un determinado estado de funcionamiento. Con el fin de garantizar la solidez, adecuado a la reducción de la pauta debe ser aplicado (no superar el 80% de la tensión, el 70% de energía, etc.)

Sólo una vez que sabes cómo son las cosas en condiciones normales se puede empezar a especular acerca de exteriores abnormals, o múltiples abnormals como la que describís. De nuevo, el modelo DFMEA (¿qué sucede si X ocurre) es un buen enfoque. Pensar en cualquier cosa que un usuario podría hacer a la unidad de corta salidas de lazo señales juntas, derrame de agua - por lo pruebe, y a ver qué pasa.

El cese de prueba (prueba de vida altamente acelerada) también es útil para estos tipos de sistemas. La unidad se coloca en una cámara ambiental y ejercido desde la mínima a la temperatura máxima, mínima y máxima de entrada y de salida, con la vibración. Esto encontrará todo tipo de cuestiones, tanto eléctrica como mecánica.

Este es también un buen momento para hacer algunos incorporado las pruebas de confusión - ejercer todas las entradas, más allá de los rangos esperados, enviar un galimatías en medio de UARTs / I2C, etc. para encontrar agujeros en la lógica. (Bit-golpeó I2C rutinas son conocidos por el bloqueo de seguridad del autobús, por ejemplo).

Conflictos de pruebas es una buena manera de demostrar la robustez. Deshabilitar cualquiera de las funciones de protección como de sobretemperatura, sobrecarga, etc. y aplicar la tensión hasta que algo se rompe. Tome la unidad lo más alto en la temperatura, ya que se puede ir hasta que algo falla o algún comportamiento errático se produce. La sobrecarga de la unidad hasta que la falla en el tren motriz. Si algún parámetro no sólo ligeramente por encima de las peores condiciones, es una indicación de la marginalidad y algunos consideración de diseño puede tener que ser revisado.

También puede tomar el siguiente nivel de enfoque y físicamente probar algunos de sus DFMEA conclusiones - en realidad, hacer que los pantalones cortos y se abre y pin-cortos y ver lo que hacía.

Leer más

Mi formación es en la conversión de energía. Tenemos un estándar de la industria llamado IPC-9592A que es un esfuerzo para normalizar el uso de los productos debe ser calificado en términos de lo que las pruebas y cómo se debe hacer. Muchos de los tipos de pruebas y metodologías a que se refiere este documento puede ser fácilmente usado en otras eléctrica disciplinas.

6voto

Eric Allam Puntos 317

Con varios dispositivos de la interfaz I2C usted tiene la posibilidad de que el "balbuceo idiota" problema donde un dispositivo falla, cerdos I2C, y mata a todos los demás I2C transmisiones.

Remojar las pruebas combinadas con pruebas ambientales proporcionaría una forma diferente de análisis de fallas. El uso marginal de los componentes, máximo/mínimo/fluctuación de las temperaturas, diferentes humedades, sucio, fuentes de alimentación, entornos ruidosos rf etc a través de una periodos de tiempo simula un período mucho más largo de lo normal por el uso. El sistema tendrá fracasos reales y las tasas de fracaso puede ser calculado.

3voto

AnonJr Puntos 111

Más probable es que la culpa es del firmware de errores. Todo lo que he hecho ha tenido un par de.

Asegúrese de que usted tiene un temporizador de vigilancia habilitado, y requieren que todos los críticos repetido funciones a suceder antes de "acariciar al perro". Me gusta poner una bandera en el temporizador de interrupción y se usa para limpiar el organismo de control en el bucle principal.

Prueba de su recuperación de firmware más de restablecimiento de los ciclos.

Desde el inicio es cuando una gran cantidad de fallas ocurren, me gusta el poder a través de un relé, a continuación, escriba un breve guión para un ciclo de encendido, espere a que la radio para indicar la activación, de la repetición. Luego de hacer esto para 10000 ciclos o así.

i-Ciencias.com

I-Ciencias es una comunidad de estudiantes y amantes de la ciencia en la que puedes resolver tus problemas y dudas.
Puedes consultar las preguntas de otros usuarios, hacer tus propias preguntas o resolver las de los demás.

Powered by:

X