--- title: "Programación PLC: definición, lenguajes IEC 61131-3 y buenas prácticas de ingeniería" description: "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..." url: https://electrohine.com/uncategorized/programacion-plc/ date: 2026-02-10 modified: 2026-01-14 author: "admin" image: https://electrohine.com/wp-content/uploads/2026/01/istockphoto-1148381702-612x612-1.jpg categories: ["Uncategorized"] type: post lang: es --- # Programación PLC: definición, lenguajes IEC 61131-3 y buenas prácticas de ingeniería 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: - (https://electrohine.com/) - (https://electrohine.com/partner-tecnologico/) - (https://electrohine.com/uncategorized/programacion-industrial/) ## 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{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. (https://electrohine.com/contacta/). ## Fuentes consultadas 1. IEC — IEC 61131-3:2025 (Programmable controllers – Part 3: Programming languages)(https://webstore.iec.ch/en/publication/68533?utm_source=chatgpt.com) 2. PLCopen — IEC 61131-3 (resumen y ecosistema)(https://www.plcopen.org/standards/logic/iec-61131-3/?utm_source=chatgpt.com) 3. PLCopen — Guidelines / Software Construction Guidelines(https://www.plcopen.org/guidelines/?utm_source=chatgpt.com)(https://www.plcopen.org/guidelines/software-construction-guidelines/?utm_source=chatgpt.com) 4. NIST CSRC — Glossary: Programmable Logic Controller (PLC)(https://csrc.nist.gov/glossary/term/programmable_logic_controller?utm_source=chatgpt.com) 5. NIST — SP 800-82 Rev. 2 (Guide to Industrial Control Systems Security)(https://nvlpubs.nist.gov/nistpubs/specialpublications/nist.sp.800-82r2.pdf?utm_source=chatgpt.com) 6. 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?utm_source=chatgpt.com)