Impacto de las revisiones de PCB en su software integrado

2

En los últimos dos años, hemos realizado algunas revisiones menores en nuestro PCB, incluyendo

  • Selección de diferentes componentes (resistencias / tapas / ...) según la disponibilidad / precio (sin dejar de tener en cuenta sus características originales)
  • Diseño de componentes en la PCB
  • Trazar anchos / longitudes (como resultado del diseño)

Lo que hemos encontrado a menudo es que, si bien estos cambios no deberían afectar realmente al software incorporado, todavía necesitábamos modificar nuestro software después de cada una de esas revisiones.

Algunas revisiones de hardware trajeron inestabilidad que solo aparecía después de días / semanas / meses (por ejemplo, la incapacidad de encender y apagar un determinado componente en la placa)

Necesitamos modificar secuencias altas / bajas, tiempos de espera de línea serie

El gran problema es que estos problemas no aparecen de inmediato, pero a veces tardan semanas / meses antes de que empiecen a aparecer, lo que dificulta la realización de acciones correctivas (especialmente si uno de los problemas es la falla de encendido para alternar módem necesario para realizar una actualización de firmware).

¿Existen pautas / mejores prácticas para eliminar ese riesgo? (¿Algún tipo de procedimiento de prueba de estrés / cosas que debemos tener en cuenta al hacer estas revisiones?

    
pregunta ddewaele

1 respuesta

6

La "mejor práctica" aquí se llama pruebas de regresión . En pocas palabras, usted quiere tener un lote de pruebas que

  • cubre la funcionalidad principal de todos los componentes de tu sistema
  • se puede ejecutar con la mínima intervención humana

El segundo requisito es importante si desea detectar problemas intermitentes que surgen solo después de un tiempo. Si la prueba es manual, podrá ejecutarla un par de veces. Si la prueba es altamente automatizada, puede ejecutarla repetidamente durante un par de días las 24 horas del día, los 7 días de la semana, detectando eventos irregulares que no ocurren cada vez (como fallas en el interruptor de alimentación).

También suele ser una buena idea incluir una prueba de esfuerzo que utilice el tiempo máximo de CPU / espacio de memoria / ancho de banda de comunicación / energía eléctrica.

Finalmente, si las pruebas son un problema para su equipo, considere diseñar un sistema con tolerancias más altas. Incluya una fuente de alimentación que sea capaz de proporcionar un 50-100% de energía extra. Si tiene una MCU, asegúrese de que su pila nunca sea utilizada por más del 50% de su capacidad y que la CPU esté inactiva al menos el 50% del tiempo. Por supuesto, esto no eliminará el riesgo, pero lo reducirá significativamente.

    
respondido por el Dmitry Grigoryev

Lea otras preguntas en las etiquetas