La programación PLC es el conjunto de técnicas y reglas con las que se diseña, implementa y mantiene el software que ejecuta un controlador lógico programable (PLC) para automatizar máquinas y procesos. En la práctica incluye: elección de lenguaje (IEC 61131-3), arquitectura del proyecto, gestión de E/S, diagnósticos, pruebas (FAT/SAT), puesta en marcha y mantenimiento controlado en entornos OT.
NIST define un PLC como un sistema de control de estado sólido con memoria programable por el usuario para implementar funciones como control de E/S, lógica, temporización, conteo, PID y comunicaciones.
¿Qué es la programación PLC?
La programación PLC es la disciplina de ingeniería que traduce un comportamiento industrial (secuencias, enclavamientos, regulación, recetas, alarmas y diagnósticos) a un proyecto ejecutable en un PLC, con un enfoque prioritario en fiabilidad, mantenibilidad y operación segura. No es solo “escribir lógica”: también es modelar estados, definir fallos, probar escenarios y controlar cambios en producción.
En una automatización real, el software PLC se integra con HMI/SCADA, redes industriales y señales de campo. A nivel de arquitectura de fábrica, ISA-95 sitúa los PLC y otros dispositivos de control en el nivel de supervisión y control del proceso (Nivel 2), conectando operación y sistemas superiores.
Qué incluye (y qué conviene separar)
- Incluye: lógica de control, secuencias, interlocks, escalado de analógicas, alarmas/diagnósticos, modos (auto/manual), gestión de fallos y comunicaciones con periferia y supervisión.
- Conviene separar: historización de largo plazo, analítica y reporting (normalmente SCADA/MES/IT), salvo que el diseño exija funciones locales.
Lenguajes de programación PLC: ¿qué define IEC 61131-3?
Respuesta directa: IEC 61131-3 es el estándar de referencia que especifica la sintaxis y semántica de un conjunto unificado de lenguajes para controladores programables. En la edición IEC 61131-3:2025, el núcleo citado por IEC incluye Structured Text (ST) como lenguaje textual y Ladder Diagram (LD) y Function Block Diagram (FBD) como lenguajes gráficos.
En la práctica industrial, LD, FBD y ST se combinan dentro del mismo proyecto. La elección se hace por mantenibilidad, tipo de control y cultura del equipo (mantenimiento eléctrico, instrumentación, ingeniería). PLCopen recopila referencias y materiales de apoyo sobre IEC 61131-3 para fomentar consistencia en implementaciones y formación.
Cuándo usar LD, FBD o ST
| Lenguaje | Fortalezas | Riesgos típicos | Uso recomendado |
|---|---|---|---|
| LD (Ladder) | Muy legible para lógica discreta e interlocks; familiar para mantenimiento | Escala mal si no se modulariza; “redes infinitas” difíciles de revisar | Señales digitales, enclavamientos, seguridad operativa (no confundir con safety) |
| FBD (Function Block) | Modularidad y reutilización; encaja bien con librerías | Diagramas densos si no hay jerarquía; abuso de bloques sin estándar | Procesos, tratamiento analógico, control con bloques y librerías |
| ST (Structured Text) | Expresivo para cálculos, recetas, parsing y lógica compleja | Puede volverse opaco sin convención de nombres y comentarios | Algoritmos, validaciones, gestión de datos, estados y utilidades |
Cómo “piensa” un PLC: ciclo de scan y tareas
Respuesta directa: La programación PLC debe diseñarse considerando cómo ejecuta el PLC el control: normalmente en ciclos repetitivos (leer entradas, ejecutar programa, actualizar salidas) y/o tareas por prioridad. El tiempo de ciclo, la latencia de red y la actualización de E/S determinan la respuesta real del sistema, por lo que la lógica debe ser determinista y verificable.
- Scan time: afecta a señales rápidas, conteos, motion y sincronismos.
- Eventos e interrupciones: útiles para entradas rápidas o tareas críticas (según plataforma).
- Redes y E/S remotas: añaden tiempos de refresco que deben medirse y documentarse.
Una regla práctica: si un requisito depende de milisegundos, no basta con “que funcione”; hay que medir el comportamiento con carga real, red real y E/S real (o en pruebas equivalentes).
Arquitectura de software PLC: lo que separa un proyecto mantenible de uno frágil
Respuesta directa: En programación PLC, la arquitectura consiste en organizar el proyecto en módulos, bloques y capas (adquisición de señales, lógica de proceso, seguridad operativa, diagnósticos, comunicaciones), evitando que el control sea un “monolito”. PLCopen publica guías de construcción de software orientadas a mejorar consistencia, reutilización y calidad en proyectos IEC 61131-3.
Patrón recomendado por capas
- Capa de E/S: lectura, filtrado, escalado, detección de fallo de señal.
- Capa de lógica: estados, secuencias, interlocks, modos de operación.
- Capa de diagnóstico: códigos claros, causas probables y acciones sugeridas.
- Capa de interfaz: variables expuestas a HMI/SCADA con nombres y unidades coherentes.
Convenciones que reducen incidencias
- Nombres estables: el peor cambio en producción es el que “rompe” tags sin avisar.
- Estado y modo explícitos: auto/manual, local/remoto, marcha/paro, fallo/ack.
- Diagnóstico accionable: “Error 17” no ayuda; “Fallo presión baja en línea X” sí.
Secuencias, estados y modos: el corazón de la programación PLC
Respuesta directa: La parte más crítica de la programación PLC es definir cómo se comporta la máquina/proceso en condiciones normales y anómalas: estados (idle, start, run, stop, fault), transiciones, condiciones de seguridad operativa e interacción con el operador. Diseñar estos estados antes de programar reduce retrabajos y acelera puesta en marcha.
Un enfoque robusto es tratar la lógica como una “máquina de estados” con transiciones verificables. Esto mejora:
- Recuperación ante fallos: volver a un estado seguro sin comportamientos impredecibles.
- Diagnóstico: saber “dónde estaba” el proceso cuando falló.
- Pruebas: enumerar casos por estado y transición (en lugar de probar al azar).
Gestión de E/S: escalado, validación y fallos de señal
Respuesta directa: La programación PLC fiable trata las señales como datos que pueden fallar: analógicas fuera de rango, sensores desconectados, rebotes en digitales o retardos por red. Por eso se implementan filtros, validación, estados por defecto y detección de fallos para que el control no “interprete” basura como realidad.
- Analógicas: escalado con unidades, límites, alarmas por rango y fallos de transductor.
- Digitales: antirrebote, temporizaciones de confirmación y diagnóstico de discrepancias.
- Señales remotas: estado “comms lost” y comportamiento seguro definido.
Pruebas en programación PLC: FAT, SAT y pruebas de borde
Respuesta directa: En programación PLC, las pruebas no son un trámite: son la herramienta para encontrar fallos antes de producción. Una estrategia típica separa pruebas funcionales (secuencias), pruebas de borde (señales fuera de rango, fallos de comunicación) y pruebas de recuperación (cómo vuelve el sistema tras una parada o fallo). En entornos ICS, NIST remarca que la seguridad y fiabilidad deben considerarse en el ciclo de vida del sistema de control.
Checklist mínimo de pruebas (práctico)
- Arranque/parada en todos los modos (auto/manual) y con permisos correctos.
- Interlocks: verificar que bloquean siempre y se liberan con condiciones reales.
- Fallos simulados: sensor roto, valor fijo, pérdida de red, reinicio controlado.
- Registros: confirmar que diagnósticos y estados quedan claros para operación.
Puesta en marcha: por qué “funciona en taller” no garantiza “funciona en planta”
Respuesta directa: La programación PLC suele fallar en puesta en marcha por diferencias entre el entorno de pruebas y la realidad: ruido eléctrico, tiempos de red, tolerancias mecánicas, señales invertidas o secuencias que dependen de procesos físicos. La mitigación es metodología: comisionado por etapas, instrumentación de diagnóstico y control de cambios.
Buenas prácticas típicas:
- Arranque por subsistemas: validar E/S, luego secuencias, luego integración HMI/SCADA.
- Observabilidad: pantallas o trazas de estados/transiciones para depurar rápido.
- Plan de rollback: antes de tocar producción, backup verificado y procedimiento de vuelta atrás.
Mantenimiento y cambios: la regla de oro en programación PLC
Respuesta directa: El riesgo principal en programación PLC a largo plazo no es el “bug original”, sino los cambios sin gobernanza: versiones no trazadas, cambios urgentes sin pruebas y backups que no restauran. Las guías de PLCopen sobre construcción de software se orientan precisamente a mejorar calidad, consistencia y mantenibilidad en proyectos IEC 61131-3.
Qué guardar siempre (mínimos reales)
- Proyecto fuente (no solo “cargado en PLC”).
- Versiones con fecha, autor y motivo.
- Configuración de hardware/red y lista de E/S (aunque sea exportada).
- Procedimiento de restauración probado (backup “verificado”).
Ciberseguridad OT aplicada a programación PLC
Respuesta directa: En programación PLC, la ciberseguridad práctica se traduce en reducir cambios no autorizados, limitar accesos y segmentar la red OT sin romper disponibilidad. NIST SP 800-82 es una guía de referencia para seguridad en ICS (incluye PLC y su entorno) y enfatiza que estos sistemas tienen requisitos particulares de disponibilidad y rendimiento.
- Acceso: roles, mínimos privilegios y cuentas nominales cuando sea viable.
- Red OT: segmentación, rutas controladas y servicios estrictamente necesarios.
- Cambios: aprobación, pruebas, auditoría y backups verificados.
Nota: la seguridad no debe “romper” la operación. En OT, el objetivo es elevar el umbral de ataque y reducir impacto sin comprometer continuidad.
Dónde encaja la programación PLC en un proyecto de integración
Respuesta directa: La programación PLC es el núcleo del control, pero el valor final aparece cuando está alineada con HMI/SCADA, señales reales y procesos de planta. En el marco ISA-95, los PLC son parte de las funciones de control y supervisión en el entorno de fabricación.
Para contexto del enfoque de Electrohine, puedes ver:
Errores comunes en programación PLC (y cómo evitarlos)
Respuesta directa: Los errores más costosos en programación PLC suelen ser de diseño: falta de estados y modos, interlocks “implícitos”, ausencia de diagnóstico accionable y cambios sin control. Corregirlos requiere estándar interno, modularidad y pruebas de borde, no “más líneas de código”.
- Monolitos: todo en un bloque → separar por función y reutilizar.
- Interlocks dispersos: difícil de auditar → centralizar condiciones críticas.
- Sin fallos definidos: el sistema queda “a medias” → estados de fallo y recuperación.
- Tags inconsistentes: rompe HMI/SCADA → convención estable de nombres y unidades.
Preguntas frecuentes sobre programación PLC
Respuesta directa: Esta FAQ resume dudas habituales sobre programación PLC: lenguajes IEC 61131-3, elección por caso de uso, pruebas, mantenimiento y seguridad OT.
¿Qué lenguajes se usan en programación PLC según IEC 61131-3?
IEC 61131-3 define un conjunto de lenguajes para controladores programables. En IEC 61131-3:2025, IEC describe ST (textual) y LD/FBD (gráficos) como parte del conjunto unificado.
¿Es mejor Ladder (LD) o Structured Text (ST)?
Depende del problema: LD suele ser más legible para lógica discreta e interlocks; ST es más eficaz para cálculos, validaciones y lógica compleja. Lo crítico es la arquitectura y los estándares internos.
¿Qué significa “modularizar” un programa PLC?
Separar el control en bloques y funciones reutilizables (por máquina, unidad o función) para facilitar pruebas, cambios y diagnóstico. Las guías de PLCopen promueven prácticas de construcción para mejorar mantenibilidad.
¿Qué es una máquina de estados en PLC?
Un diseño donde el proceso se representa como estados (p. ej., parada, arranque, marcha, fallo) y transiciones con condiciones explícitas. Mejora pruebas y recuperación ante fallos.
¿Qué pruebas mínimas debería pasar un proyecto de programación PLC?
Pruebas de modos, interlocks, fallos de señal, pérdida de comunicación y recuperación (reinicios/paradas). En ICS, NIST subraya el enfoque de ciclo de vida en fiabilidad y seguridad.
¿Cómo se evita que un cambio “rompa” la producción?
Con control de versiones, backups verificados, pruebas y un plan de rollback. La gobernanza de cambios reduce incidencias más que “programar rápido”.
¿Qué relación tiene programación PLC con ISA-95?
ISA-95 describe niveles de integración empresa-control; el nivel 2 incluye PLC y otros dispositivos de control para monitorización y supervisión del proceso. :contentReference[oaicite:20]{index=20}
¿Qué mínimos de ciberseguridad OT aplican a PLC?
Acceso por roles, segmentación de red OT, gestión de cambios y visibilidad razonable. NIST SP 800-82 es una guía de referencia para seguridad en sistemas ICS.
¿Cuándo conviene reescribir un programa PLC en lugar de “parchear”?
Cuando el coste de mantener el monolito supera el coste de refactorizar: falta de documentación, diagnósticos pobres, cambios constantes y riesgo creciente en puesta en marcha. Normalmente se empieza por modularizar y crear estándares.
¿Qué documentación mínima debería acompañar a un PLC programado?
Lista de E/S, arquitectura de red, versiones del proyecto, backups restaurables y un manual operativo básico (modos, estados y diagnósticos).
Dudas o necesidad de ayuda con programación PLC
Respuesta directa: Si necesitas revisar, estandarizar o implementar programación PLC (arquitectura, secuencias, diagnóstico, pruebas o puesta en marcha), el canal oficial para plantearlo es el formulario de contacto. Cuantos más datos aportes (tipo de proceso, número de E/S, criticidad y ventana de parada), más rápida será la orientación inicial. Contacta con Electrohine aquí.
Fuentes consultadas
- IEC — IEC 61131-3:2025 (Programmable controllers – Part 3: Programming languages)
https://webstore.iec.ch/en/publication/68533 - PLCopen — IEC 61131-3 (resumen y ecosistema)
https://www.plcopen.org/standards/logic/iec-61131-3/ - PLCopen — Guidelines / Software Construction Guidelines
https://www.plcopen.org/guidelines/
https://www.plcopen.org/guidelines/software-construction-guidelines/ - NIST CSRC — Glossary: Programmable Logic Controller (PLC)
https://csrc.nist.gov/glossary/term/programmable_logic_controller - NIST — SP 800-82 Rev. 2 (Guide to Industrial Control Systems Security)
https://nvlpubs.nist.gov/nistpubs/specialpublications/nist.sp.800-82r2.pdf - ISA — ISA-95 Standard (Level 2 incluye PLC y otros dispositivos de control)
https://www.isa.org/standards-and-publications/isa-standards/isa-95-standard