Tres sueños para una fábrica diferente

Hay tres cosas que cualquiera que haya puesto en marcha una máquina industrial se ha preguntado al menos una vez. Tres cosas que no se dicen en voz alta porque parecen utopías. Este artículo las enumera.

Una escena, para empezar

Turno de noche, departamento X. Una línea se detiene. El panel HMI muestra un código: E-1423. El manual está en un armario a tres edificios de distancia. El técnico que conoce esa máquina está de vacaciones. El operador tiene dos caminos: llamar al servicio de asistencia —que responderá quizás por la mañana— o adivinar. En todo el mundo industrializado, escenas como esta se repiten cientos de veces por noche.

El problema no es que falte un manual. Hay demasiados manuales. El problema es que la máquina sabe muy bien lo que necesita —el sensor de la presión le está diciendo desde hace treinta segundos que algo va mal— pero no puede hablar un idioma que el operador entienda, y cuando lo consigue, cuenta el problema en lugar de la solución. "Presión fuera de rango" no es una frase útil a las tres de la noche. "Verifique la válvula V12 del circuito de aire, probablemente se ha pegado" lo es.

De aquí parte el trabajo que estamos haciendo. No un nuevo PLC. No una HMI más bonita. Una forma diferente de pensar en lo que debería ser, en 2026, el software que hace mover una máquina. Y tres ideas fijas —llámalas sueños— que estamos intentando mantener unidas.

Sueño número uno: automatizar sin programar

La automatización industrial, tal y como está hecha hoy en día, requiere una figura muy particular: alguien que sepa programar en un lenguaje —la familia IEC 61131-3, con sus dialectos ladder, function block, structured text— que no se usa prácticamente en ningún otro lugar del mundo del software. Quien sabe esos lenguajes es raro, es caro, y casi siempre va con tres semanas de retraso.

La paradoja es que quien conoce realmente la máquina a menudo no es el programador. Es el jefe de departamento, el mantenedor veterano, el integrador que ha instalado veinte instalaciones similares. Estas personas saben qué debe hacer la máquina. No tienen ninguna gana de aprender un lenguaje de programación nacido en los años '90 para explicarlo.

La idea es invertir la cadena. Los desarrolladores de software escriben componentes reutilizables — control de movimiento, gestión de sensores, secuencias operativas — una sola vez, en lenguajes modernos y de propósito general. El integrador de máquinas no los programa: los compone, especificando con voz o por escrito lo que la máquina debe hacer. Un modelo lingüístico de gran tamaño — un LLM — actúa como traductor: toma la especificación funcional del integrador y la transforma en una configuración ejecutable, ensamblando los componentes ya escritos y probados.

No es la fantasía de "la IA que escribe el código por ti". Es algo más modesto y más realista: la IA que lee tu especificación y elige, entre componentes certificados, cómo combinarlos. El código crítico — el que mueve un eje con un ciclo de 5 milisegundos — sigue siendo escrito por un ser humano, en un lenguaje que garantice determinismo y fiabilidad. Pero ese código se escribe una vez para todas y se reutiliza cien veces.

Sueño número dos: la máquina que sabe de sí misma

Hoy las máquinas hablan poco y mal. Una alarma es un código numérico. Un diagnóstico es una serie de LED. Un registro es un archivo binario que solo el fabricante sabe abrir. El conocimiento de cómo funciona esa máquina, con esas tolerancias, después de esos dos mil ciclos, está en la cabeza de una persona, o en un PDF en algún lugar.

El segundo sueño es que sea la máquina la que se conozca a sí misma. No en un sentido místico —en un sentido muy concreto: la documentación técnica, los parámetros de proceso, los casos de fallo típicos, los procedimientos de intervención ya no están en un armario o en un servidor documental separado, sino dentro de la propia máquina, legibles por su propio software. Y cuando algo no va bien, la máquina no dice "error 1423". Dice "la válvula V12 probablemente se ha pegado, deberías verificarla; mientras tanto puedo continuar en modo degradado al 60% de la velocidad".

La diferencia está entre un objeto pasivo que señala y un objeto activo que propone. El primero deja el problema al operador. El segundo lo afronta junto con él.

Esto requiere dos cosas poco comunes. Primero, que el conocimiento de la máquina —históricamente custodiado en manuales, esquemas eléctricos, dibujos CAD y en la experiencia de los técnicos— se formalice e integre en el sistema. Segundo, que el sistema tenga un interlocutor capaz de mantener una conversación: de nuevo, un LLM, usado aquí no para generar código sino para traducir síntomas en acciones comprensibles, en el lenguaje de quien está frente al panel.

Una vez más, no es magia. Es documentación escrita mejor, indexada mejor, y una interfaz conversacional por encima. Pero cambia todo para quien hace el turno de noche.

Sueño número tres: el software que funciona en todas partes

El tercer sueño es el más técnico y, paradójicamente, el más político. Hoy la automatización industrial es un mundo de ecosistemas cerrados. Cada gran fabricante de PLC tiene su lenguaje, su entorno de desarrollo, su hardware, sus drivers, su red de revendedores. Cambiar de proveedor significa reescribirlo todo.

La ambición aquí es construir un sistema de software que se ejecute en hardware genérico — un mini-PC industrial, un controlador embebido, un servidor en el sótano — eligiendo el hardware en función del presupuesto y el rendimiento necesario, no en función de qué marca de PLC ha ganado la negociación. Un sistema operativo Linux en versión real-time, tarjetas de comunicación basadas en estándares abiertos (EtherCAT en todas), componentes de software en lenguajes modernos para las partes deterministas y en lenguajes más ágiles para las que no lo son.

La regla, y aquí es donde la utopía se hace concreta: el hardware debe incidir en el rendimiento, nunca en la fiabilidad. La misma lógica, en una máquina menos potente, debe funcionar de forma idéntica — solo más lentamente. Si el tiempo de ciclo pasa de 5 a 10 milisegundos, el eje se mueve con la misma precisión pero a la mitad de velocidad. Nunca "casi igual". Nunca "funciona excepto en ese caso". Mismo sistema, las mismas decisiones, las mismas garantías.

Esta es la parte en la que los ingenieros experimentados se echan a reír. Saben muy bien que el tiempo real es difícil, que Linux no nació como un sistema de tiempo real, que los LLM no se ejecutan en una Raspberry Pi, que mezclar diferentes lenguajes en la misma pila tiene más trampas de las que prometen los tutoriales. Tienen razón. Pero la dirección es esa, y los ladrillos para construirla — las extensiones de tiempo real del kernel Linux, pilas EtherCAT de código abierto maduras, LLM que empiezan a ejecutarse en hardware modesto — existen, hoy, por primera vez todos juntos.

¿Por qué "utopía"

Utopía es una palabra honesta. Ninguna de estas tres cosas es, hoy, un producto terminado. La primera requiere LLM lo suficientemente fiables como para ser utilizados en un contexto productivo, y estamos en los primeros pasos. La segunda requiere un enorme trabajo de formalización del conocimiento industrial, que hoy es casi todo informal. La tercera requiere construir alternativas abiertas contra ecosistemas cerrados que tienen veinte años de ventaja.

Pero los tres sueños juntos, si se ponen en fila, dibujan una dirección precisa: una automatización en la que el hardware es un producto básico, el software es reutilizable, el conocimiento está integrado en la máquina, y la figura del programador de PLC — hoy cuello de botella de toda una industria — no desaparece, sino que se desplaza donde realmente se necesita, es decir, a escribir los componentes básicos una vez por todas.

En los artículos que seguirán, contaremos las piezas que estamos construyendo de este rompecabezas. Una por una, sin prometer que el rompecabezas esté completo. No lo está. Pero el dibujo comienza a ser visible.