¿Cómo saber aproximadamente si un esquema electrónico fallará pronto y protegerse de él?

Estoy pensando en un proyecto agrícola que incluya el uso de alguna placa como Arduino , Raspberry Pi o Onion Mega (la lista no es excluyente).

Como el sistema funcionará con sensores y soportará la vida de sus salas, su salud dependerá del trabajo de toda la cadena de componentes.

Seguramente mantendré la placa principal en un lugar seguro, por ejemplo, la pondré en un estuche a prueba de humedad y temperatura, y aislaré los contactos donde sea necesario, pero entiendo que estas placas son más para educación/experimentos que para uso diario real. deber. Además, siempre hay un factor de defecto en la placa proveniente del fabricante.

Entonces, me pregunto si hay información sobre qué tan duraderas son las tablas y si son adecuadas para trabajar 24 horas al día, 7 días a la semana durante semanas/meses.

¿Cómo me aseguro de que ese sistema tiene un margen de seguridad más o menos definido y sé el momento en que debo sustituirlo por uno nuevo?

Bastante seguro de que cualquier buen sistema tiene redundancia incorporada. Es posible que desee buscar mecanismos de seguridad.
Absolutamente, use temporizadores de vigilancia y monitores de fuente de alimentación que apliquen señales de reinicio y asegúrese de que el reinicio apague las salidas que controlan los motores y similares. Es posible que encuentre más información sobre MTBF disponible en módulos industriales en lugar de "aficionados" como Pi y Arduino.
pero entiendo que estas tablas son más para educación/experimentos que para el trabajo diario real. No estoy de acuerdo con eso. Los componentes utilizados en estas placas están diseñados para productos de consumo normales, por lo que a menudo están diseñados para una vida útil (garantizada) de 10 años cuando se usan dentro de las especificaciones para estos, consulte la hoja de datos del fabricante. La confiabilidad estará más determinada por su software y cómo lo use . Maltrata la tabla y fallará antes. Cuándo fallará es extremadamente impredecible.
@FakeMoustache, veo el punto de OP sobre las placas, no los circuitos integrados o el software. Los circuitos integrados grandes deberían ser del mismo estándar, como bien dices. Pero la fabricación, montaje, soldadura, etc. y la inversión en revisión y mejora continua del proceso de fabricación bien pueden no estar ahí. Después de todo, estas son placas producidas en masa de muy bajo costo y están ahorrando dinero siempre que sea posible, en equilibrio con los costos de rechazos y devoluciones si van demasiado lejos, obviamente. No son idiotas, pero tienen diferentes objetivos de confiabilidad. Podemos adivinar y suponer, pero aquí es una incógnita.
Buena pregunta (pero difícil de responder bien) y varios buenos comentarios y respuestas. || R/ El punto clave es que puede tener una idea de las tasas de falla que puede esperar , PERO nunca puede estar seguro y no debe diseñar un sistema basado solo en proyecciones de confiabilidad. | La gente ha mencionado "a prueba de fallas" - ENTIENDELO. Esto NO significa "a salvo de fallas", SINO que CUANDO ocurre una falla, el sistema está diseñado para garantizar que no se produzcan daños como resultado directo Y el sistema se adaptará a la falla de manera que pueda solucionarse sin daños, dado que se diseñó de otra manera adecuada. precauciones.
Para interés: el cohete lunar estadounidense 'Saturn V' tuvo una parte en su ascenso en la que, durante un período muy corto, si hubiera perdido 1 de los motores N, habría sido destruido ya que las fuerzas aerodinámicas no podían ser manejadas por el otros motores. Eso NO fue a prueba de fallas, pero aún se aceptó como un resultado poco probable. - || El otro concepto esencial que la gente ha mencionado es la "redundancia": las funciones de un módulo fallido son replicadas por algún otro módulo. Esto se entrelaza con "a prueba de fallas". ...
... SI las vidas de los animales dependen del sistema y usted desea evitar muertes, DEBE planificar el sistema "a prueba de fallas", y la redundancia ayuda a permitir menos o ningún tiempo de inactividad CUANDO ocurren las fallas. Tenga en cuenta que una falla en un sistema redundante PUEDE eliminar la redundancia pero NO DEBE eliminar el aspecto a prueba de fallas. Además, una falla DEBE señalarse al administrador del sistema y corregirse de inmediato para restaurar el sistema al nivel de seguridad diseñado. || Problemas: Altas temperaturas, condensación, humedad, contaminación conductiva o que promueve el calor, bestias (hormigas, ratones, ratas, ...), secado (adhesivos estructurales que fallan con el tiempo), ...
Mantenga la tabla a una temperatura constante y fresca, baja humedad (lo mejor es seca), sin vibraciones. Permita la circulación de aire alrededor del tablero para ayudar a que se enfríe aún más. Tenga algunas longitudes de cable adicionales donde se conecta a la placa, para evitar tirones en los conectores, soldaduras y rastros. Nunca tuerza ni aplique torsión, incluso durante la instalación. Y mantenga el VDD muy limpio. Ahora bien, ¿cómo gestionar la ESD? ¿Y evitar la caída de rayos, durante el uso diario?
En primer lugar, es probable que deba descartar el pi en función de la tarjeta SD, o al menos analizar la confiabilidad de eso primero, y los medios de almacenamiento y los sistemas de archivos utilizados en cualquier alternativa. A continuación, debe considerar si tiene acceso a las fuentes del sistema para corregir los errores ya conocidos, lo que descarta el Onion Omega2 actualmente disponible...
@RussellMcMahon Sí, muy buenos puntos (por cierto, todos esos comentarios deberían convertirse en una respuesta. Espero que te interese hacerlo). Sobre "a prueba de fallas": es realmente un término engañoso, creo que no debería usarse en ingeniería (aparte de contextos muy específicos y explícitos). Realmente prefiero mejores términos, como tolerancia a fallas .
@LorenzoDonati Me gusta "a prueba de fallas" como término siempre que el significado se entienda correctamente. Tal vez "Fail SAFE!!! " :-). Útil, por ejemplo, en alas delta. La tolerancia a fallas no se siente tan bien en tales casos :-)

Respuestas (2)

Hay que buscar información sobre ingeniería RAMS (fiabilidad, disponibilidad, mantenibilidad y seguridad).

Conceptos y técnicas básicas de RAMS

  • Tasa de fallas : número de fallas esperadas de un componente, ensamblaje o producto por unidad de tiempo.
  • MTTF (tiempo medio hasta el fallo) / MTBF (tiempo medio entre fallos) : la inversa de la tasa de fallos. El tiempo esperado en que su componente/ensamblaje/unidad estará funcionando en determinadas condiciones hasta que ocurra una falla.
  • Componentes ER (confiabilidad establecida) frente a componentes que no son ER : los componentes llamados de alta confiabilidad (hi-rel) a menudo se prueban en lotes para establecer su tasa de falla, lo que los hace costosos. Por otro lado, para los componentes que no son ER, se asume una tasa de falla bastante pesimista de acuerdo con los valores tabulados.
  • Análisis de conteo de piezas (PCA) / Análisis de estrés de piezas (PSA) : un método para calcular el valor esperado para la tasa de falla de un ensamblaje/producto, derivándolo de la tasa de falla de cada componente y su estrés asociado (temperatura, humedad, energía /tensión/reducción de corriente, etc.).
  • Reducción de potencia : el % de la potencia máxima/voltaje/corriente nominal a la que opera el componente/conjunto/producto. Cuanto mayor sea la reducción, menor será el estrés y más largo será el MMTF.

  • Curva de bañera : una curva que describe cómo cambia la tasa de fallas a lo largo de la vida útil del componente/conjunto/producto. Ver imagen a continuación.

  • Quemado : una prueba inicial no destructiva a alta temperatura (envejecimiento acelerado) destinada a precipitar fallas tempranas en componentes/ensamblajes/productos ya defectuosos. Es una especie de prueba de detección.
  • Prueba de vida : una prueba destructiva a alta temperatura (envejecimiento acelerado) destinada a establecer la confiabilidad de un lote completo de componentes/conjuntos/productos a partir de una muestra reducida sometida a esta prueba.

Curva de la bañera

Fuente de la imagen .

¿Dónde empiezo?

  1. Descargar MIL-HDBK-217F, PREDICCIÓN DE FIABILIDAD DE EQUIPOS ELECTRÓNICOS . Allí encontrará casi todos los valores tabulados que necesitará. No necesita implementar todos los métodos descritos en él desde el principio, así que no se asuste por su complejidad.
  2. Cree una hoja de Excel para obtener datos básicos de confiabilidad de su BOM (lista de materiales). Las columnas deben incluir al menos la siguiente información sobre los componentes: P/N, descripción y tasa de falla base. Agregaremos más información más adelante, si es necesario.
  3. Rellene la hoja de Excel con los datos de la tasa de falla base y lleve a cabo un PCA básico para calcular su primera aproximación aproximada a la tasa de falla y el MTTF de su ensamblaje/producto. ¡No olvide incluir las uniones de soldadura en el análisis!
  4. Mire los resultados de su PCA y compárelos con el MTTF requerido por su aplicación:
    • Si el PCA ofrece un MTTF insuficiente, ya está en problemas y debe volver a su diseño, su selección de piezas o sus cálculos para verificar qué es lo que está mal con ellos.
    • Si el PCA ofrece un MTTF muy por encima de su requisito (por un margen de 1000x o más), entonces es posible que desee detenerse aquí. Solo verifique que no haya ningún componente que funcione demasiado cerca de sus valores nominales máximos).
    • Si la PCA ofrece un MTTF por encima de su requisito, pero sin un margen lo suficientemente alto, entonces tendrá que calcular las tensiones reales de los componentes.
  5. Si su PCA no fue concluyente, deberá realizar un PSA con las tensiones reales y las condiciones ambientales (temperatura, humedad) de su ensamblaje/producto:

    • Regrese a su hoja de Excel y agregue más columnas para tener en cuenta los factores pi en MIL-HDBK-217F (temperatura, calidad, medio ambiente, potencia nominal, tensión de tensión, etc.). El factor Pi son modificadores de la tasa de falla base de acuerdo con las condiciones de estrés reales.
    • Complete los nuevos campos en su hoja de Excel con datos para las hojas de datos de los componentes, pero también de su propia simulación y cálculos de circuitos.
    • Vuelva a calcular las tasas de falla modificadas para cada componente de acuerdo con sus factores pi.
    • Vuelva a calcular la tasa total de fallas y el MTTF de su ensamblaje/producto.
    • Mire los resultados de su PSA y compárelos con el MTTF requerido por su aplicación. Si los resultados son buenos, entonces ya está todo listo. De lo contrario, busque los componentes que más contribuyen a la tasa total de fallas y aborde sus problemas individualmente : ¿Se requiere un componente de reemplazo de mayor potencia/voltaje/clasificación de corriente? ¿Se requieren cambios en ciertos valores de diseño para evitar demasiada potencia/voltaje/corriente en el componente problemático? disipador de calor necesario? etc.
  6. Si ha hecho todo lo posible para reducir la tasa total de fallas pero aún no puede obtener un MTTF compatible con sus requisitos, es posible que desee agregar redundancia a su diseño, pero dirigido específicamente a subensamblajes de su producto con alto índices de falla parcial. La redundancia debe introducirse solo cuando los cálculos de MTTF lo exijan, y nunca de forma preventiva. ¿Por qué? Porque la redundancia necesita agregar elementos de conmutación que pueden fallar por sí mismos e introducir también una complejidad innecesaria.

  7. ¡Incluso si su PCA/PSA dice que todo estará bien, tenga en cuenta que eso será cierto solo para fallas aleatorias! El PCA/PSA no se ocupa de las tasas de fallas tempranas de componentes/ensamblajes/productos defectuosos. Por lo tanto, se recomienda encarecidamente quemar su producto antes de implementarlo en el campo.

  8. Si desea tener datos estadísticos reales sobre la vida útil de su ensamblaje/producto, es posible que desee realizar una prueba de vida. Pero eso significa gastar dinero en las muestras que se destruirán o desgastarán durante las pruebas de vida, y tener el tiempo (generalmente alrededor de 1000 horas o más, dependiendo de la temperatura de la prueba) y los medios para llevarlas a cabo.

Notas a continuación:

  1. También existen paquetes de software de predicción de confiabilidad especializados que le facilitarán todos estos cálculos. Solo usted puede decidir si su aplicación y caso de negocios requieren tal inversión.

  2. Aquí hay un software de predicción de confiabilidad gratuito que encontré (divulgación: nunca lo he usado).

  3. He buscado datos de confiabilidad (MTBF) para Raspberry Pi sin ningún éxito...

Vería la redundancia dual: dos placas con cada una monitoreándose a sí misma, la segunda placa y recursos comunes como la fuente de alimentación. La salida debe estar de acuerdo para impulsar cosas críticas y esto se puede hacer con un simple ANDing de diodo. Las cosas críticas pueden incluir habilitar la energía a los motores u otras cosas en movimiento. La implementación real realmente depende de su circuito y aplicación.

Cada placa puede emitir una señal de "señal de vida" a la otra y esto realmente puede ser tan profundo o superficial como desee. Un UART simple a otro, que envía un conteo incremental, es superficial, ya que muestra que el otro está vivo, pero no en qué grado. Un esquema más profundo sería intercambiar un valor de estado para la forma en que cada placa ha respondido a sus entradas y hacer que cada puerta tenga las salidas críticas con AND de diodo desactivadas si no están de acuerdo.

Hice todo esto (diodo-AND, intercambio de estado) para un sistema muy crítico una vez y funcionó bien. Pero debe tener una idea clara de cuáles son los estados antes de comenzar, ya que no es fácil trabajar con ellos en más desarrollos de 'modificar y ajustar'.

También puede incluir un temporizador de vida útil operativa, con cada unidad rastreando la cantidad de segundos/minutos/horas que ha estado funcionando y la cantidad de horas desde el primer encendido. Construir eso en su sistema desde el principio puede ser más revelador ya que su aplicación acumula mucho kilometraje y, a menudo, su implementación es económica.