Impacto de las revisiones de PCB en su software integrado

En los últimos años, hemos realizado algunas revisiones menores a nuestra PCB, que incluyen

  • Selección de diferentes componentes (resistencias / tapas / ...) en función de la disponibilidad / precio (sin dejar de tener en cuenta sus características originales)
  • Disposición de los componentes en la PCB
  • Traza anchos / largos (como resultado del diseño)

Lo que hemos encontrado a menudo es que, aunque estos cambios no deberían afectar realmente el software integrado, aún necesitábamos modificar nuestro software después de cada una de esas revisiones.

Algunas revisiones de hardware trajeron consigo inestabilidad que solo apareció después de días/semanas/meses (p. ej., la incapacidad de encender y alternar un determinado componente en la placa)

Necesitábamos ajustar las secuencias alta/baja, los tiempos de espera de las líneas seriales

El gran problema es que estos problemas no aparecen de inmediato, sino que a veces tardan semanas o meses antes de que comiencen a aparecer, lo que dificulta la realización de acciones correctivas (especialmente si uno de los problemas es la falla en el interruptor de alimentación del módem necesario para realizar una actualización de firmware).

¿Existen lineamientos/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 tales revisiones?

Estas pautas se denominan pruebas, en algunas empresas tienen cosas como "departamentos de control de calidad".
Y supongo que un diseño inicial adecuado también ayuda... Tanto de HW como de FW. Que se haga a profesionales experimentados, o al menos que sean ellos los que supervisen el proceso.
Somos una pequeña empresa nueva y hacemos pruebas de banco internas y tratamos de hacer pruebas de estrés. Pero estos problemas solo surgen en el campo (y solo después de semanas, a veces meses).
Tienes que realizar pruebas y control de calidad. No existe una receta mágica para producir un producto impecable o no introducir regresiones sobre revisiones.
¿Cuántos miles de dispositivos está produciendo/vendiendo que hacen que la molestia de cambiar el diseño y el software compense la diferencia de precio de los componentes pasivos? Tal vez sería más barato pagar esa diferencia por las piezas en lugar de gastar el tiempo de ingeniería reajustando cosas todo el tiempo.
@ddewaele: Entonces debe averiguar cuáles son las razones de esto y tenerlas en cuenta en sus pruebas.
no está exactamente relacionado con su pregunta, pero un problema que encontré fue mantener la versión de software simultánea con hardware diferente en el campo. Tener 6 versiones de hardware fue una pesadilla de software. Usamos un AT91 que tenía un pin ADC que no estábamos usando. Conectamos el ADC a un divisor de resistencia que cambió entre revisiones. Este cambio de $ 0.01 nos ahorró mucho tiempo en el lado del software porque podríamos tener diferentes secciones de código basadas en la lectura de este divisor de resistencia a través del ADC.
@bdegnan Buen consejo, pero tenga en cuenta que la identificación de HW es solo una pequeña parte del problema con el soporte de varias plataformas de HW. Todavía tiene que probar cada arreglo en todas las versiones de HW, y algunos arreglos requerirán que implemente un código diferente para diferentes HW.

Respuestas (1)

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

  • cubrir la funcionalidad central de todos los componentes de su sistema
  • se puede ejecutar con una 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 está 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 siempre (como fallas en el interruptor de alimentación).

Por lo general, también es una buena idea incluir una prueba de esfuerzo que utilice el máximo tiempo 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 pueda proporcionar un 50-100% de potencia adicional. Si tiene una MCU, asegúrese de que su pila nunca se use en 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.

Muchas gracias por los comentarios. Automatizamos una serie de cosas durante las pruebas, por ejemplo: poner en marcha una plataforma de prueba que manipulaba el dispositivo bajo prueba de varias maneras (cambios de voltaje de entrada, reinicios, forzar el modo de suspensión/activar la activación). Pero es difícil reproducir un problema que solo aparece después de +1 mes. Y aún más difícil de evaluar si está relacionado con el hardware o el software. Intentamos hacerlo tolerante a fallas al proporcionar interruptores de encendido en todos los componentes principales (gprs / gps / ...) Quizás deberíamos haber subcontratado esa parte y trabajar junto con una tienda especializada para eso.
Impacto de las revisiones de PCB en su software integrado
RespuestasAquíPolítica de privacidad1y, 0v