Los asistentes de IA llegan a los PLC: leen proyectos, escriben ST y lanzan la compilación por su cuenta

La programación de controladores industriales se mantuvo durante mucho tiempo al margen de la ola de asistentes de IA que ya ha pasado por Python, C++ y JavaScript. Ahora eso está cambiando. El análisis de Habr constata que están apareciendo herramientas especializadas que leen proyectos de PLC, explican la lógica de escalera en LAD, generan código en Structured Text (ST) y, en algunos casos, lanzan la compilación por sí mismas. La tarea se parece al desarrollo convencional: hay un lenguaje, variables, condiciones, temporizadores y bloques de función. Pero en la práctica todo depende de los matices.

En qué se diferencia un PLC del código convencional

El estándar IEC 61131-3 describe cinco lenguajes: LD (también conocido como LAD), FBD, ST, SFC e IL. Solo ST parece código de texto al uso, y se asemeja a Pascal. Los demás son, en gran medida, gráficos: un esquema de relés o un diagrama de bloques de función se traducen mal a una secuencia de tokens. Para un modelo de lenguaje, esto es un problema de representación de los datos.

Hay una segunda dificultad. Los proyectos para controladores suelen ser cerrados y están en formatos y entornos de cada fabricante (TIA Portal, Studio 5000, CODESYS y otros), y los ejemplos públicos son bastante menos numerosos que en el desarrollo web. Por eso, un modelo que escribe muy bien un servicio REST puede generar con total seguridad código ST con un bloque inexistente o con una semántica de temporizador incorrecta.

Y la tercera es el coste del error. Un bug en una aplicación se corrige con una nueva versión, pero una lógica incorrecta en una bomba o en una cinta transportadora puede parar la línea o dañar el equipo.

Qué saben hacer hoy las herramientas

Un chat sencillo con un modelo («escribe un algoritmo de control de una bomba») sirve como punto de partida. Las soluciones especializadas van más allá, porque tienen acceso al propio proyecto. Según la descripción del análisis, sus capacidades son estas:

• lectura del proyecto de PLC: análisis de la estructura, los bloques, las etiquetas y las relaciones entre ellos;
• explicación del LAD en lenguaje humano, útil para entender código ajeno o heredado;
• generación de código en ST a partir de una descripción textual del algoritmo;
• lanzamiento de la compilación en algunas herramientas, es decir, el ciclo «escribir, compilar, recibir errores, corregir» sin intervención humana;
• limitaciones: la calidad depende en gran medida del entorno, del formato del proyecto y del lenguaje, y los lenguajes gráficos reciben peor soporte que los de texto.

El ciclo cerrado con el compilador parece el paso más importante. La retroalimentación de la cadena de herramientas reduce la proporción de errores sintácticos y de tipos. Una idea similar se desarrolló en el trabajo de investigación LLM4PLC, donde la generación de código se combinaba con comprobación y verificación. Los grandes fabricantes de automatización también integran asistentes generativos en sus propios entornos de desarrollo. Siemens, por ejemplo, anunció Industrial Copilot junto con Microsoft ya en 2023.

Aun así, que el código compile no dice nada sobre si la lógica es correcta. El código puede compilar y comportarse mal: confundir la condición de arranque, omitir un enclavamiento o no gestionar una señal de alarma.

Hacia dónde va esto

La dirección probable es esta: el asistente deja de ser un generador de fragmentos y pasa a participar en el proceso de ingeniería. Lee el proyecto completo, propone cambios, compila, lo prueba en simulación y muestra el resultado a una persona. La principal limitación no es la capacidad de escribir código, sino comprobar que se ajusta al proceso tecnológico.

Las comparaciones detalladas de herramientas concretas están en el artículo original de Habr. Aquí lo importante es el panorama general: el PLC deja de ser un territorio al que la IA no entra.

Cómo abordar estas herramientas en la práctica

Lo razonable es empezar por ST: es donde los modelos rinden mejor y el resultado resulta más fácil de leer a simple vista. Funcionan bien las tareas de riesgo acotado: analizar código LAD ajeno, documentar bloques, redactar borradores de funciones típicas, como el control de una bomba o los contadores.

Conviene probar en un simulador cualquier código generado antes de conectarlo al hardware y pasarlo por la revisión habitual. Las paradas de emergencia, los enclavamientos y las funciones de protección es mejor escribirlos y comprobarlos a mano. Los proyectos cerrados plantean una cuestión aparte: antes de entregarlos a un asistente en la nube, hay que averiguar adónde van los datos y qué permite la política de seguridad de la empresa.