Arquitectura de Sistemas Embebidos: Cuando Tu Producto Tiene Múltiples PCBs

Los sistemas embebidos están en todas partes en el mundo tecnológico de hoy. Ya sea una afeitadora conectada a Internet o un automóvil complejo, los dispositivos embebidos están en el corazón de la mayoría de los dispositivos electrónicos que utilizamos hoy en día. Compuestos por uno o varios microprocesadores, los sistemas embebidos pueden simplificar la electrónica al trasladar la complejidad para que sea manejada por el software. A medida que los dispositivos embebidos se vuelven más grandes y complejos, también lo hacen las placas de circuito impreso (PCBs). A menudo, estos dispositivos crecen hacia múltiples placas y se convierten en ensamblajes más grandes de lo originalmente previsto.

En este artículo vamos a explorar los compromisos y consideraciones de arquitectura para sistemas embebidos compuestos por múltiples PCBs. Cubriremos los beneficios, consideraciones de diseño y desafíos asociados con sistemas de múltiples PCBs.

¿Por qué usar múltiples PCBs?

Mantener tu dispositivo en una sola PCB es la opción ideal (tanto por simplicidad como por costo), pero a veces tenemos que tomar la decisión de dividir nuestro diseño en dos o más PCBs para alcanzar nuestros objetivos de diseño. Algunas razones por las que querríamos dividir nuestro producto en múltiples placas incluyen:

• Modularidad: Separar un ensamblaje en múltiples placas significa que puedes reemplazar solo una parte del producto si es necesario. Por ejemplo, si una sola PCB falla, se puede reemplazar sin afectar todo el sistema. Esto puede, si se hace correctamente, reducir costos y tiempo para los fabricantes.
• Optimización del Espacio: Al dividir componentes a través de múltiples placas, los diseñadores pueden lograr diseños más compactos y eficientes. Piensa en una placa única muy larga y estrecha versus unas pocas placas cortas y apiladas donde la altura no importa debido al empaque.
• Gestión Térmica: Los componentes que generan mucho calor pueden dividirse en diferentes PCBs para mejorar la disipación térmica. Al distribuir el calor uniformemente a través de todo el ensamblaje puedes mejorar enormemente la fiabilidad del sistema.
• Escalabilidad: Diseñar con múltiples PCBs permite adiciones incrementales de características que pueden ser reemplazadas por una sola placa en vez de un ensamblaje completo. Piensa en un sensor mejorado o una cámara sin reemplazar todo el sistema informático.

Por estas razones (y más) consideramos diseñar un ensamblaje que esté compuesto por múltiples PCBs pero los desafíos con el lado del firmware embebido no están exentos de sus complejidades.

Consideraciones de Diseño Embebido para Ensamblajes de Múltiples PCBs

Ahora que hemos establecido el caso para usar múltiples PCBs (cuando sea aplicable) es importante entender las consideraciones de diseño al arquitectar el sistema embebido. Tanto desde una perspectiva de hardware como de software hay matices que no tendemos a considerar tan cuidadosamente cuando ponemos todo en una sola placa.

La primera consideración que debería venir a nuestra mente es la comunicación entre tarjetas. ¿Cómo se comunicará cada tarjeta con las demás? ¿Qué tipo de capacidad de procesamiento (si es que hay alguno) vive en cada tarjeta? ¿Quizás una tarjeta consiste en el cerebro mientras que las otras consisten en los sensores? A medida que seleccionamos cuidadosamente nuestros protocolos de transmisión, ya sea I2C, SPI, UART, Ethernet, etc., también debemos considerar las líneas de transmisión, la integridad de la señal y, lo más importante, la transferencia de señales a través de conectores entre tarjetas. Lo peor que le puede pasar a un diseñador (y créanme, he estado ahí) es diseñar el sistema completo y recibir tus PCBs del fabricante solo para darte cuenta de que te faltó una señal de reloj o dos. También tendemos a olvidar mantener pines de repuesto en nuestros conectores entre tarjetas, intentando aprovechar al máximo cada conteo de pines. Esto es algo que realmente puede perjudicarnos al final. Diseñar con un proyecto de múltiples tarjetas en mente, como la función de Ensamblaje de Múltiples Tarjetas en Altium Designer, es imprescindible cuando se trazan tantas líneas de comunicación entre PCBs.

También necesitamos pensar en cómo planeamos distribuir la energía, especialmente si vamos a monitorear buses de energía con nuestro microprocesador. Queremos accesibilidad al “cerebro” para permitirle monitorear cualquier evento catastrófico, pero también necesitamos considerar el ruido de la fuente de alimentación conmutada, la distribución de energía para cargas pesadas y si los pines de nuestro conector entre tarjetas están clasificados para ese tipo de energía.

Por último, aunque no esté directamente relacionado con el software en sí del sistema embebido, el diseño mecánico también juega un papel importante. Botones pulsadores, pantallas táctiles y otras interfaces físicas para el usuario aún se conectan al microprocesador y deben ser tomadas en consideración. ¿Se puede enrutar el cableado de tal manera que el microprocesador pueda acceder a sus entradas? ¿Hemos considerado la integridad de la señal de la salida digital de alta velocidad a medida que la pasamos de una tarjeta a otra? Estas son cosas en las que tenemos que pensar al diseñar nuestro dispositivo embebido.

Desafíos y Soluciones

Uno de los desafíos más subestimados que he visto una y otra vez en startups en crecimiento (e incluso en grandes empresas) ha sido la plaga de esquemas de versiones entre software y hardware. Gestionar lanzamientos de software contra revisiones de PCB se ha convertido en la batalla interminable que a menudo lleva a confusión, retrasos e incluso fallos de productos.

Por ejemplo, en una startup con la que trabajé, una pequeña modificación en el PCB requirió un nuevo diseño y, por lo tanto, una actualización del firmware (aunque mínima). Debido al pobre control de versiones, el equipo de ingeniería desplegó el nuevo firmware en versiones antiguas de PCB causando bajadas de tensión inesperadas y una nube periódica de humo. Afortunadamente lo detectamos antes de que el producto se enviara, pero fue una pesadilla absoluta durante días sin fin.

Para evitar estas trampas, es crucial establecer un esquema de versiones sólido como una roca y asegurar una comunicación clara entre los equipos de hardware y software. Incluso un esquema de versiones simple, como un hash de Git (o versión semántica) para el firmware, junto con una tabla de búsqueda básica para las revisiones de hardware, puede ser suficiente para comenzar. A medida que avanza el tiempo, mecanismos más sofisticados como la detección de revisión de hardware en el firmware (comprobando así la compatibilidad) también reducen en gran medida las confusiones.

Además de la versionado de software, también es importante pensar en la modularidad del código. Con código espagueti, cambiar una placa de sensores por una nueva con chips o sensores diferentes podría convertirse en una pesadilla de refactorización. Modularizar tus controladores de dispositivos y crear capas de abstracción de hardware permite intercambiar componentes fácilmente durante años. Esto es algo que se ha vuelto mucho más popular a medida que los sistemas embebidos han aumentado en complejidad con el tiempo.

Conclusión

Cuando pensamos en la arquitectura de sistemas embebidos no siempre tenemos que pensar en pequeño. Las naves espaciales y los automóviles son sistemas embebidos extremadamente complejos, pero también lo son los smartphones. Ya sea que estemos diseñando una cuchara conectada a internet o el próximo satélite, entender los compromisos de la arquitectura de sistemas embebidos es extremadamente importante al diseñar para múltiples PCBs. Hemos explorado muchos conceptos en este artículo pero todavía hay muchos más que, sin duda, encontrarás a lo largo de tu viaje.