LAD, SCL y los lenguajes IEC 61131-3: cuál usar en cada parte del programa

"¿En qué lenguaje está hecho el programa?" es una de las primeras preguntas que aparecen en cualquier obra. La norma IEC 61131-3 define varios lenguajes para programar PLC, y la tentación es elegir uno y hacer todo con él. Casi siempre es un error. Cada lenguaje resuelve bien un tipo de problema, y la decisión entre LAD o SCL no solo afecta al que programa: afecta al que va a tener que diagnosticar una falla a las tres de la mañana.

Los lenguajes de la norma

• Diagrama de contactos (LAD / LD). Se lee como un esquema eléctrico de relés. Es el lenguaje que la gente de mantenimiento entiende y el que se puede seguir en línea frente a la máquina.
• Diagrama de bloques de funciones (FBD). Lógica representada con compuertas y bloques. Común en control de procesos y en programas de seguridad.
• Texto estructurado (ST, que en Siemens se llama SCL). Parecido a Pascal: condiciones, bucles, cálculos, manejo de textos y arreglos.
• Diagrama de funciones secuenciales (SFC, que en Siemens es GRAPH). Para secuencias por pasos y transiciones.
• Lista de instrucciones (IL, que en Siemens es STL/AWL). Tipo assembler. La tercera edición de la norma, de 2013, la declaró obsoleta.

Qué cambió con S7-1200 y S7-1500

En las CPU S7-300 y S7-400, la herramienta traducía internamente los distintos lenguajes a STL antes de cargarlos, y eso condicionaba el rendimiento. En las S7-1200 y S7-1500, TIA Portal compila LAD, FBD y SCL directamente a código de máquina. Consecuencias prácticas:

• STL ya no conviene en proyectos nuevos. La S7-1200 directamente no lo soporta. La S7-1500 lo ejecuta, pero emulando los acumuladores de las CPU viejas, y Siemens no lo recomienda para desarrollos nuevos. Si migrás un programa S7-300 con mucho STL, es buen momento para reescribir esas partes.
• La elección entre LAD y SCL ya no es por velocidad de ejecución, sino por claridad: qué lenguaje expresa mejor esa parte de la lógica y quién la va a leer.

LAD o SCL: cuándo usar cada uno

LAD para la lógica de máquina. Enclavamientos, permisivos, arranque y parada de motores, señales discretas, alarmas simples. Cuando la máquina se para, el electricista abre el bloque en línea, ve qué contacto no cierra y encuentra el sensor. Ese diagnóstico rápido vale más que cualquier elegancia de código.

SCL para el cálculo y los datos. Recorrer arreglos, ordenar, manejar recetas, procesar textos, escalar y filtrar señales, cálculos con muchas variables. Lo que en LAD ocupa veinte redes difíciles de seguir, en SCL son diez líneas claras. Un ejemplo típico: acceder a un elemento de un arreglo con un índice variable. En SCL es Datos[i]; en LAD obliga a instrucciones de acceso indirecto que hacen el programa más difícil de leer y de mantener.

GRAPH / SFC para secuencias largas. Si el proceso es una secuencia de pasos con condiciones de avance —una limpieza CIP, un ciclo de lote—, una secuencia gráfica muestra en qué paso está la máquina y por qué no avanza.

La combinación que mejor funciona en la práctica es bloques chicos, cada uno en el lenguaje que corresponde (podés ver un ejemplo de lógica de proceso funcionando en nuestras demos SCADA): la lógica de la máquina en LAD, que llama a bloques de cálculo escritos en SCL. En AUTOMYC trabajamos así, con una librería propia de bloques en SCL, validados y versionados, que se reutilizan de una obra a otra.

Programar pensando en que algo va a fallar

El PLC ya no está aislado: recibe datos del SCADA, del HMI, de otros equipos y de sistemas de gestión. Cualquiera de esas fuentes puede mandar un valor fuera de rango, por error o a propósito. La familia de normas IEC 62443 trata la ciberseguridad industrial. La parte 4-1 define cómo deben desarrollar sus productos los fabricantes y la 4-2, qué requisitos técnicos debe cumplir cada componente, pero varias de sus ideas bajan directo al programa del PLC:

• Validar todo lo que entra. Un valor que viene del HMI o de la red se controla contra sus límites antes de usarlo en un cálculo o como índice de un arreglo. Un índice fuera de rango genera un error de programación que, según la CPU y la configuración, termina en el OB de error o en STOP.
• Manejar los errores donde ocurren. En S7-1500 se puede activar el manejo local de errores en el bloque (con GET_ERR_ID) para detectar el problema, usar un valor seguro y avisar, en lugar de que la CPU decida por vos.
• Cuidar el tiempo de ciclo. Un bucle que crece con los datos o una lógica que se dispara en el peor momento puede superar el tiempo de vigilancia del ciclo. Si eso pasa, la CPU llama al OB de error de tiempo y, si se repite, pasa a STOP. Los bucles en SCL tienen que tener un límite conocido.
• Cerrar lo que no se usa. El servidor web de la CPU, los accesos sin contraseña y los servicios de diagnóstico abiertos, si no hacen falta, se desactivan. Y los niveles de protección de la CPU se configuran desde el primer día, no cuando aparece un problema.

En resumen

No hay un lenguaje mejor que otro: hay uno adecuado para cada parte del programa. LAD para lo que mantenimiento necesita leer en la máquina, SCL para el cálculo, secuencias gráficas para los procesos por pasos, y STL solo para lo que todavía hay que mantener. Y sea cual sea el lenguaje, el programa tiene que asumir que los datos pueden llegar mal y seguir funcionando de forma segura cuando eso pase.

Si tenés un programa heredado en STL o S7-300 para migrar, mirá nuestros servicios de revamping y migración o contanos qué tenés. Y si te preguntás qué puede aportar la inteligencia artificial a este trabajo, leé IA para programar PLC: qué hace bien y qué no.

---

📚 Referencias bibliográficas (Formato APA)

1. IEC. (2013). IEC 61131-3: Programmable controllers – Part 3: Programming languages (3.ª ed.). International Electrotechnical Commission.
2. Siemens AG. (2020). Programming Styleguide for SIMATIC S7-1200/S7-1500 (Entry ID 81318674). Siemens Industry Online Support. https://support.industry.siemens.com/cs/ww/en/view/81318674
3. Siemens AG. (2018). Programming Guideline for S7-1200/S7-1500 (Entry ID 90885040). Siemens Industry Online Support. https://support.industry.siemens.com/cs/ww/en/view/90885040
4. IEC. (2013). IEC 62443-3-3: Industrial communication networks – Network and system security – Part 3-3: System security requirements and security levels. International Electrotechnical Commission.
5. IEC. (2018). IEC 62443-4-1: Security for industrial automation and control systems – Part 4-1: Secure product development lifecycle requirements. International Electrotechnical Commission.
6. IEC. (2019). IEC 62443-4-2: Security for industrial automation and control systems – Part 4-2: Technical security requirements for IACS components. International Electrotechnical Commission.