El «lado izquierdo» de la V)

Clic para la sección anterior: Etapa 2

La Etapa 3 es donde el diseño se vuelve físico: diseño electrónico y mecánico, que suelen avanzar de la mano. Si has oído hablar del modelo en V en ingeniería (un modelo clásico de proceso de desarrollo), el lado izquierdo de la «V» trata de diseño e implementación, y es exactamente donde estamos ahora. En otras palabras, nos centramos en diseñar el hardware que luego se verificará y validará en el lado derecho de la V. (No te preocupes si no conoces el modelo en V; la idea clave es que el diseño de hardware tiende a ser un proceso secuencial que debes abordar con cuidado. Una vez que imprimes una placa de circuito o moldeas una carcasa de plástico, hacer cambios es complicado —léase: caro.)

La Etapa 3 puede dividirse en algunos subpasos. Lo que es importante: esta es también la etapa donde el desarrollo de hardware y software empiezan a trabajar en paralelo (más sobre el lado del software en la siguiente etapa). En la vía del hardware, así es como suelen desarrollarse las cosas:

Captura del esquemático: el plano electrónico

Todo producto electrónico empieza como un dibujo; no del tipo artístico, sino un esquemático. La captura del esquemático es donde el diseño del circuito eléctrico se esboza en detalle usando herramientas CAD especializadas (como Altium, Eagle o KiCad). Piensa en el esquemático como el plano de tu circuito: muestra cada componente (microcontrolador, sensores, condensadores, conectores y más) y cómo están todos conectados eléctricamente por redes (cables). Es como trazar el mapa de una ciudad de electrónica donde cada componente es un edificio y las redes son las carreteras que los conectan.

Este paso es crucial porque es mucho más fácil (y barato) corregir errores en un diagrama que en una placa física. Una vez redactado el esquemático, una revisión a fondo es obligatoria. Normalmente, el ingeniero exporta el esquemático a PDF y lo hace circular para revisión por pares. Ojos frescos pueden cazar algo que se te escapó: por ejemplo, «¡Ups, el pin de alimentación del sensor de temperatura no está conectado!» o «Ese valor de resistencia parece raro para el limitador de corriente del LED». Cazar estos problemas ahora ahorra muchos dolores de cabeza después.

En esta fase algunos equipos también realizan un FMEA (Failure Modes and Effects Analysis) sobre las partes críticas del diseño, como la fuente de alimentación o los circuitos de seguridad. El FMEA es básicamente una forma estructurada de preguntar «¿de qué maneras podría fallar este circuito, y qué pasa si falla?». Por ejemplo, ¿qué pasa si el sensor de temperatura falla en cortocircuito (es decir, sus dos terminales se conectan internamente por accidente)? ¿Haría eso simplemente que el sensor leyera un valor extremo, o podría dañar toda la placa al tirar de demasiada corriente? Haciendo estas incómodas preguntas de «qué pasaría si» pronto, puedes añadir protecciones o decidir si el riesgo es aceptable. Este tipo de visión de futuro hace el dispositivo más fiable a largo plazo.

Mientras tanto —y aquí es donde entra el trabajo en paralelo—, el equipo de software/firmware no tiene que esperar parado a que el hardware esté terminado. A partir del esquemático, los ingenieros de firmware pueden empezar a crear un HAL (Hardware Abstraction Layer), o al menos un esqueleto de él. Esencialmente, montan las interfaces software para los periféricos del microcontrolador (timers, interfaces de comunicación como I2C o SPI para esos sensores, etc.). Incluso pueden escribir pruebas unitarias o código de simulación para estos drivers en un PC. Imagina un desarrollador escribiendo código que falsifica lecturas de sensores solo para probar la lógica: así, el equipo de firmware ya está construyendo la base. Cuando llegue la placa de circuito real, gran parte de la estructura del código estará lista y esperando probarse en hardware real. Este esfuerzo paralelo significa que la gente de software no se está rascando la barriga; está sentando bases que facilitarán el bring-up del hardware después.

Layout de la PCB: del esquemático a la placa física

Una vez que el diseño del esquemático está cerrado y revisado, es hora de convertir ese plano electrónico en una placa de circuito real. Esta es la fase de layout de la PCB. Usando otro conjunto de herramientas CAD (a menudo la misma suite usada para los esquemáticos, como Altium o KiCad, que pueden cambiar a modo layout), el ingeniero coloca el footprint de cada componente sobre una placa virtual y empieza a enrutar las pistas de cobre que lo conectan todo. Si el esquemático es el plano, el layout de la PCB es el paso donde decides exactamente cómo se verá físicamente esa ciudad de componentes: como decidir dónde se asienta cada edificio y cómo correrán las carreteras (cables) entre ellos sobre el terreno real de la placa.

El resultado del layout de la PCB es un conjunto de archivos (los famosos archivos Gerber) que los fabricantes usan para fabricar la placa. Otra salida útil es un modelo 3D (a menudo un archivo STEP) de la placa. Este modelo 3D es especialmente útil en el lado del diseño mecánico: puedes importarlo en el diseño de tu carcasa para comprobar que la placa y todos sus componentes caben dentro del alojamiento del producto sin colisiones (¡nadie quiere un conector USB asomando donde la carcasa no tiene agujero!).

Durante el layout de la PCB, es crítico tener en mente las guías de Design for Manufacturing (DFM) y Design for Test (DFT). En términos simples, DFM significa diseñar la placa para que pueda fabricarse de forma fiable y rentable, y DFT significa diseñarla para que pueda probarse fácilmente después.

Por ejemplo:

• DFM: evita colocar componentes demasiado cerca del borde de la placa o tan apretados que las máquinas de ensamblaje tengan problemas para soldarlos. Asegúrate de que el layout puede fabricarse sin problemas.
• DFT: añade test pads o un conector especial para poder conectar equipo de pruebas o programadores a la placa en producción. Así, cada unidad que salga de la línea puede comprobarse fácilmente (imagina un enchufe cómodo para programar el firmware o medir señales en cada dispositivo).

¡Es mucho más fácil incluir estas medidas ahora que darte cuenta después de que tienes mil unidades terminadas sin una forma fácil de verificar si son completamente funcionales!

Muchos equipos usan una checklist durante el layout para asegurarse de que nada se olvida: cosas como añadir fiducials (pequeñas marcas que ayudan a las máquinas de ensamblaje automatizadas a saber cómo alinear la placa), mantener las distancias adecuadas entre partes de alto voltaje, etiquetar los conectores importantes, etc.

Mientras el equipo de hardware está ocupado enrutando pistas y sudando los detalles de la placa, el esfuerzo paralelo de software continúa. El equipo de firmware, conociendo los modelos exactos de sensores y componentes del esquemático, puede empezar a escribir el código real de los drivers (o al menos placeholders) contra los datasheets de esos componentes. Pueden usar emuladores de sensores o escribir código ficticio que imite lo que el sensor haría. El equipo de cloud/backend, si tu producto IoT lo tiene, también puede adelantarse: por ejemplo, montando una base de datos cloud básica y endpoints de API para recibir datos del dispositivo. Esencialmente, todos preparan su pieza del puzle para que cuando lleguen las primeras placas físicas, no sea un arranque en frío para el resto del equipo. Cuando el diseño de la PCB se envía a fabricación, tu firmware puede tener ya un «hello world» listo para la placa y tu cloud puede tener un pequeño servidor de pruebas esperando registrar el primer punto de datos del dispositivo. Este desarrollo concurrente realmente acorta el bucle de iteración después.

Construcción del prototipo: dando vida al hardware

Con el layout de la PCB hecho y comprobado, es hora de pasar de archivos digitales a objetos físicos. El primer paso es fabricar las placas. Normalmente envías esos archivos Gerber a una fábrica de PCBs (hay muchos fabricantes de PCB de turno rápido que pueden producir placas en días). En paralelo, querrás asegurarte de tener a mano todos los componentes que van en la placa (el microcontrolador, los sensores, los chips, etc.). Consejo de pro: pide los componentes críticos o de lead time largo en cuanto tengas confianza en tu esquemático y selección de componentes. Durante las escaseces globales de chips, muchos equipos aprendieron esto por las malas: no quieres estar esperando 12 semanas a un sensor o chip de radio concreto mientras tus placas están ahí vacías.

Una vez que tienes las PCBs desnudas y todas las piezas, ensamblas unas pocas unidades prototipo. Esto puede hacerse en casa si tienes un laboratorio bien equipado y pulso firme para soldar, o puedes usar un servicio de ensamblaje para soldar todos esos componentes diminutos. El resultado es un conjunto (a menudo un puñado pequeño, de 1 a 5 placas) de dispositivos prototipo.

Ahora llega uno de los momentos más emocionantes (y angustiosos) del desarrollo de hardware: el bring-up, que es el término sencillo para la primera vez que alimentas la placa y ves si funciona. Es común hacerlo con cuidado: por ejemplo, usando una fuente de alimentación de laboratorio con límite de corriente para evitar freír cosas si hay un cortocircuito en algún sitio. Todo el laboratorio puede contener la respiración cuando accionas el interruptor. ¿Se enciende la placa sin soltar el humo mágico de los componentes quemados? (¡Ojalá que sí!)

Tras el encendido, verificas metódicamente lo básico. ¿Están todos los raíles de alimentación a los voltajes esperados? (Comprueba con un multímetro u osciloscopio). ¿Despierta el microcontrolador (MCU) y ejecuta código? Una primera prueba clásica suele ser comprobar si corre un firmware simple que parpadea un LED o envía un mensaje «Hello, world» por el puerto serie. Si ves ese LED parpadear o recibes ese mensaje en tu ordenador, es un hito genuino: significa que el corazón de tu placa está vivo y coleando.

A continuación, probarás la comunicación con los periféricos clave: ¿puede el MCU hablar con el sensor por I2C o SPI como se planeó? ¿Devuelven los sensores datos razonables? Es en esta fase donde puedes descubrir problemas. Quizá un sensor no lee por un error de cableado o un bug sutil de firmware. El bring-up es un juego de detectives, donde los ingenieros de hardware y firmware trabajan juntos para resolver cualquier problema. Por ejemplo, si la lectura de temperatura es siempre cero, el ingeniero de firmware puede depurar el código mientras el ingeniero de hardware comprueba las conexiones con el multímetro: juntos averiguarán si es un problema de inicialización del software o si las líneas SDA y SCL del sensor se intercambiaron en la PCB.

Durante el bring-up del prototipo, también estás atento a cualquier problema de potencia o térmico. ¿Hay algo que calienta más de lo debido? (Consejo de pro: tocar con cuidado los chips para notar el calor o usar una cámara infrarroja puede cazar puntos calientes). ¿La placa está consumiendo más corriente de lo esperado (lo que podría indicar que algo está mal cableado o que un componente está defectuoso)? Estas pruebas aseguran que tu prototipo no solo funciona, sino que también es seguro y rinde dentro de los parámetros esperados.

Si tu dispositivo está destinado a comunicarse inalámbricamente o a cumplir ciertas normas regulatorias (como las emisiones FCC para gadgets inalámbricos en EE. UU.), esta fase de prototipo es un buen momento para hacer algunas pruebas de pre-cumplimiento. Esto puede significar llevar el dispositivo a un laboratorio para hacer un escaneo preliminar de emisiones de radiofrecuencia y cazar cualquier problema grande pronto. ¡No quieres descubrir en la prueba final de certificación que tu placa actúa como un transmisor de radio accidental en una frecuencia no aprobada!

Mientras el equipo de hardware está ocupado con el bring-up, el equipo de firmware está ahora a pleno rendimiento probando su código en el dispositivo real. Todos esos drivers y componentes del HAL que empezaron antes pueden cargarse en la placa real. Aquí es donde el firmware puede necesitar algo de ajuste: quizá las suposiciones de temporización estaban un poco desviadas, o una interrupción necesita ajuste ahora que está en silicio real. Si usas un RTOS (Real-Time Operating System) en el microcontrolador, este es el momento de empezar a afinar las prioridades o temporizaciones de las tareas, ya que en hardware real puedes observar el rendimiento real. ¡El equipo de cloud también puede ver los primeros datos reales atravesando el sistema! Por ejemplo, el prototipo puede enviar de verdad una lectura de temperatura a un servidor de pruebas, confirmando que todo el flujo de extremo a extremo (dispositivo -> nube -> base de datos) funciona al menos a pequeña escala.

La Etapa 3 suele implicar algunas iteraciones. Es raro conseguir todo perfecto a la primera, y eso es completamente normal. Puedes encontrar un error en la placa (como una pista mal cableada o un error de footprint de componente) que requiera un pequeño arreglo quirúrgico en los prototipos (¡hola, bodge wires y arreglos de patchwork!), o puede ser lo bastante significativo como para justificar una PCB revisada para la siguiente ronda de prototipos. Cada iteración es una oportunidad de mejora: quizá reposicionas un conector difícil de alcanzar, o retocas el circuito para reducir el ruido en la lectura de un sensor, etc. No te desanimes por necesitar iteraciones; es lo esperado en el desarrollo de hardware.

A lo largo de esta etapa, la colaboración estrecha entre los equipos de hardware y software es vital. Cuando surge un problema, ambos lados tienen que ponerse el sombrero de detective y trabajar juntos. ¿El sensor no lee porque el firmware está mal, o hay un puente de soldadura cortocircuitando algo en la PCB? Comunicando hallazgos e hipótesis, el equipo puede acotar el problema más rápido. Esta resolución colaborativa de problemas es una de las partes más educativas del proceso, y a menudo refuerza la comprensión del equipo sobre el producto como un todo.

Además, mantén un ojo en el futuro: si planeas fabricar eventualmente este producto a escala, usa esta fase de prototipo para pensar en la fabricación y las pruebas a largo plazo. ¿Recuerdas DFM y DFT? Ahora es el momento de validar esas decisiones. Por ejemplo, si incluiste un header de programación, prueba a usarlo en una prueba de producción simulada: ¿puedes conectar y programar la placa fácilmente? Si añadiste test pads, ¿son accesibles para un tester bed-of-nails? Es mucho más fácil ajustar tu diseño para testabilidad ahora que cuando tienes una línea de producción en marcha.

Al final de la Etapa 3, deberías tener uno o más dispositivos prototipo funcionando y un conjunto sólido de lecciones aprendidas. Tendrás datos iniciales de rendimiento (¿cuánta energía consume realmente tu dispositivo? ¿El sensor rinde con precisión en condiciones reales?). Probablemente también tendrás una lista de arreglos o mejoras para la siguiente versión. Lo más importante: has construido la base física de tu producto IoT: algo que puedes sostener en las manos y que realmente funciona.

Cuando ese primer prototipo por fin cobra vida y envía datos como se esperaba, una pequeña celebración está bien ganada: la mayoría de los ingenieros de hardware han sentido un destello del «¡Está vivo!» del Dr. Frankenstein en ese momento. Tómatela. El hardware es duro, y acabas de superar un hito mayor en el camino de la idea a la realidad.