8 señales de que tu prototipo no tiene fiabilidad industrial (la auditoría completa)

Tu prototipo funciona. Eso no significa que aguante en planta.

Lo escribimos así de directo porque es la lección más cara de aprender por las malas: la mesa del laboratorio es el entorno más amable que tu sistema va a conocer jamás. Temperatura estable, alimentación limpia, cero vibración, distancias de cable de dos metros y tú delante para reiniciarlo cuando algo se tuerce. La planta es exactamente lo contrario en todo — y encima nadie está delante.

Esta es la auditoría completa de 8 señales que usamos para evaluar si un prototipo basado en Arduino, ESP32 o Raspberry Pi está listo para producción. Cada señal incluye cómo comprobarla con una prueba concreta, porque una auditoría sin prueba es una opinión. Regla de decisión: si tu prototipo marca 3 o más señales, no está listo. Ni "casi".

Señal #1 — Solo lo has probado a temperatura de oficina

Dentro de un armario eléctrico en planta, en verano, se alcanzan 45-50 °C con facilidad: suma la temperatura ambiente de la nave, el calor de fuentes, variadores y contactores, y un armario cerrado sin ventilación forzada. La electrónica de consumo se especifica típicamente a 0-70 °C de chip, que no es lo mismo que de equipo: dentro de una caja, el chip trabaja bastante por encima del aire que la rodea.

Los efectos del calor son traicioneros porque son acumulativos y progresivos: deriva de las lecturas analógicas, cuelgues esporádicos, envejecimiento acelerado de condensadores. No falla el día uno; falla en agosto del segundo año.

Cómo comprobarlo: ensayo de 48 horas continuadas a temperatura de armario real. No hace falta cámara climática para una primera criba: mete el prototipo en una caja cerrada con una fuente de calor controlada (o en el propio armario de destino en verano), monitoriza la temperatura interior con un registrador y verifica: ¿las analógicas derivan?, ¿hay reinicios?, ¿algún componente supera su rango de datasheet? Registra lecturas antes y después: la deriva se mide, no se estima.

Señal #2 — Se reinicia "muy de vez en cuando" y lo has normalizado

"A veces se reinicia, pero se recupera solo" es la frase más peligrosa de la automatización. Un reinicio inexplicado al mes en la mesa son docenas al año en planta, cada uno con la máquina en un estado distinto — y alguno pillará a la máquina en el peor estado posible. Los cuelgues aleatorios no se van solos: son ruido eléctrico, alimentación insuficiente o un defecto de software, y en producción los tres factores empeoran.

Cómo comprobarlo: instrumenta un contador de arranques persistente (en EEPROM o memoria no volátil) y un registro de causa de reset — la mayoría de microcontroladores permiten leer si el último reset fue por alimentación, watchdog o software. Déjalo correr 2-4 semanas con carga real. El criterio es binario: cero reinicios inexplicados. Uno solo ya es una investigación pendiente, no una anécdota.

Señal #3 — Recuperarse de un corte de luz requiere tus manos

En planta, los cortes y microcortes de alimentación no son un evento excepcional: son parte del entorno. Si tras un corte tu sistema se queda esperando a que alguien pulse algo, reconfigure una conexión o "le dé al botón", no tienes un sistema industrial: tienes una demo con buena suerte.

Cómo comprobarlo: corta la alimentación en el peor momento del ciclo (actuadores en marcha, comunicación a medias, escritura en memoria en curso) y observa: ¿vuelve solo a un estado seguro?, ¿retoma la operación en el orden correcto?, ¿los esclavos del bus se reenganchan? Repítelo veinte veces, en momentos distintos — un relé temporizado cortando alimentación cada pocos minutos durante una noche es un banco de pruebas barato y demoledor. Aprueba si las veinte veces vuelve solo.

Señal #4 — Sensores conectados con cable "del cajón"

Señales analógicas sin apantallar, buses sin trenzar, manguera de alimentación reutilizada para RS-485… y todo funcionando perfectamente — a dos metros de distancia y sin un variador en la misma provincia. La primera instalación con distancias reales, canaletas compartidas y convertidores de frecuencia te descubrirá lo que el cajón escondía: lecturas que bailan, tramas corruptas, timeouts intermitentes.

Cómo comprobarlo: primero inspección visual contra tres reglas — analógicas en par trenzado y apantallado con malla a tierra en un solo extremo; RS-485 en cable trenzado con sus dos terminaciones de 120 Ω en los extremos físicos del bus; señales y potencia en canaletas separadas. Después, prueba de ruido: alarga el cableado a longitudes realistas y haz funcionar cerca una carga agresiva (un variador con motor, o a falta de él, un taladro conectado en la misma fase). Si las lecturas se mueven o el bus registra errores de CRC, ya sabes lo que la planta te haría a diario.

Señal #5 — El estado seguro no está escrito en ningún sitio

Pregunta simple: si se pierde la comunicación con el sensor de nivel, ¿qué hace la bomba? Si la respuesta empieza por "supongo que…", no hay estado seguro: hay suerte. En un sistema industrial, el comportamiento ante cada fallo — pérdida de sensor, de comunicación, de alimentación — se decide por diseño, salida por salida, y se escribe antes de programarlo.

Cómo comprobarlo: dos pasos. Primero, el documento: una tabla con cada salida física, su estado ante cada modo de fallo y la justificación. Si el documento no existe, la señal está marcada — sin necesidad de probar nada. Segundo, la prueba: desconecta cada sensor en caliente, tira del cable del bus, apaga el esclavo Modbus, y verifica que cada salida hace exactamente lo que dice la tabla. Las sorpresas en esta prueba son oro: cada una es una avería de planta que acabas de evitar.

Señal #6 — Sin watchdog, o desactivado "para depurar"

El watchdog que desactivaste en desarrollo y nunca reactivaste es un clásico silencioso. Sin él, cualquier cuelgue de software — y con años de servicio, alguno habrá — es una parada de máquina hasta que alguien llegue físicamente al cuadro. Con él, es un reinicio automático a estado seguro que quizá nadie llegue a notar.

Cómo comprobarlo: provoca un cuelgue deliberado. Mete en el código una rama de prueba con un bucle infinito (activable por una entrada o un comando) y dispárala con el sistema en marcha. Criterio de aprobado: el equipo se reinicia solo en el tiempo configurado, arranca en estado seguro y lo deja registrado. Si además corre sobre Linux (Raspberry Pi), comprueba también el watchdog de hardware del sistema, no solo el del proceso: un kernel colgado ignora a tu aplicación.

Señal #7 — No existe documentación de conformidad del conjunto

Esta es la única señal de la lista que no te costará una avería: te costará una inspección. Tu prototipo instalado en planta deja de ser un prototipo: es un conjunto puesto en servicio, y le aplican directivas europeas — Baja Tensión, Compatibilidad Electromagnética y, si es una máquina completa, la Directiva de Máquinas. El marcado CE de cada componente no cubre el conjunto que tú has construido: el responsable de la conformidad del conjunto eres tú, con tu firma en la declaración.

Un accidente, una inspección de trabajo, un cliente que pide el expediente técnico o un seguro que investiga un siniestro: cualquiera de esos caminos acaba en la misma pregunta — "¿me enseña la documentación de este cuadro?". Y "funciona desde hace dos años" no es una respuesta admisible.

Cómo comprobarlo: hazte la pregunta del inspector: si mañana te pidieran el expediente, ¿puedes entregar esquema eléctrico actualizado, lista de componentes con sus declaraciones de conformidad reales (no un logo CE serigrafiado), análisis de riesgos si aplica y declaración de conformidad del conjunto? Comprueba especialmente los componentes de origen dudoso: pide a cada proveedor la declaración UE de conformidad; el que no la entrega en días es un agujero en tu expediente. Lo desarrollamos a fondo en nuestra guía de marcado CE para integradores (semana 8 de esta serie).

Señal #8 — Componentes con vida útil consumible que nadie ha dimensionado

La señal más traicionera de las ocho: no aparece en el primer año. Aparece en el tercero, cuando el proyecto ya no tiene presupuesto de mantenimiento, el que lo montó está en otra cosa y nadie recuerda qué hay dentro del cuadro. Hay componentes que no fallan por defecto sino por agotamiento, y en un prototipo casi nunca se han dimensionado:

• La microSD de consumo que escribe logs cada segundo: agota sus ciclos de escritura en meses o pocos años, y no avisa — un día el sistema no arranca.
• Los relés electromecánicos: sus contactos tienen una vida en maniobras (decenas de miles con carga inductiva real, no los millones "mecánicos" del datasheet). Un relé que conmuta cada 30 segundos consume esa vida en cuestión de un par de años.
• Los condensadores electrolíticos de fuentes baratas: su vida se reduce a la mitad por cada 10 °C de más. A temperatura de armario, la fuente de marketplace es una cuenta atrás.

Cómo comprobarlo: haz el presupuesto de vida útil, componente a componente. Maniobras por hora × horas anuales contra la vida eléctrica del relé a su carga real. Escrituras por día contra los ciclos de la SD (y si corre Linux desde SD: tarjeta industrial pSLC/SLC, logs a RAM o a servidor, sistema de ficheros en solo lectura si es viable). Temperatura de trabajo de la fuente contra la vida declarada de sus condensadores. Todo lo que salga con menos de 10 años de vida estimada necesita: sustituirse por su versión industrial, un plan de reemplazo preventivo, o ambas cosas — por escrito.

La auditoría en una tabla

Has marcado 3 o más señales: qué hacer ahora

Primero, la buena noticia: ninguna de las ocho señales exige tirar el trabajo hecho. La lógica, la elección de sensores y el conocimiento del proceso siguen valiendo. Lo que no aguanta es la plataforma física y la disciplina alrededor.

El camino corto, si tu prototipo corre sobre Arduino, ESP32 o Raspberry Pi, es migrar al equivalente industrial de la misma plataforma: mismo entorno de programación, mismas librerías, mismo código en lo esencial — pero con entradas optoacopladas, alimentación protegida de 12-24 Vdc, salidas dimensionadas para cargas reales, carril DIN y documentación de conformidad del equipo incluida en tu expediente. Las señales 1, 4 (en parte), 7 (en la parte del controlador) y 8 (en la parte del equipo) se resuelven en la migración; las señales 2, 3, 5 y 6 son de diseño y disciplina, y esta auditoría es tu lista de tareas.

Y probar el prototipo antes de producción no es un trámite final: es una fase con nombre, duración y presupuesto. De cuánto dura esa fase — y todas las demás, del prototipo funcional al cuadro con CE — hablamos la semana que viene, con la cronología completa.

📥 Descarga la checklist: De prototipo Arduino a instalación industrial

La auditoría de este artículo, más la selección de plataforma, el cableado, las comunicaciones y el marcado CE: la guía completa de la serie "De Prototipo a Planta" en un solo PDF imprimible.

Descargar la guía gratuita →

Si tu prototipo corre sobre una placa Arduino, el salto natural es la familia M-Duino: mismo entorno de programación, hardware endurecido para planta. Empieza por el M-Duino 21+ (https://www.industrialshields.com/shop/is-mduino-21-m-duino-ethernet-plc-arduino-21-3670) o filtra por E/S y comunicaciones con el Buscador Configurable de la tienda: https://www.industrialshields.com/shop