Buenas prácticas de programación de PLC

Respuesta corta

Un programa de PLC se escribe una vez y se modifica durante años, casi siempre por personas distintas de su autor y bajo presión de producción. Las buenas prácticas tienen un solo objetivo: que quien lo abra a las tres de la mañana con una máquina detenida entienda qué ocurre y qué puede tocar sin riesgo. Se resumen en estructura, nombres, fallas, modos, documentación y control de cambios. Son criterios generales de ingeniería, aplicables a cualquier marca y a cualquiera de los lenguajes de la IEC 61131-3.

1. Estructura: de lo general a lo particular

Un programa legible tiene capas:

Separar la lectura de señales de la lógica evita que un cambio de borne obligue a tocar diez lugares: se modifica la capa de entradas y el resto sigue igual. Y poner la escritura de salidas en un solo lugar impide que dos partes del programa se disputen la misma salida.

2. Un bloque por tipo de equipo

La lógica de un motor tiene siempre las mismas partes: orden de marcha, paro, protección, realimentación del contactor, tiempo de vigilancia, alarma y estado. Se escribe una vez como bloque de función (ver function block diagram) y cada motor de la planta es una instancia. Las ventajas son concretas: una corrección se hace una vez, las pruebas se hacen una vez, y la HMI y el SCADA reutilizan el mismo conjunto de datos (direccionamiento y tipos de datos). La sintaxis de Structured Text (IF, CASE, FOR) y sus ejemplos están en Structured Text (ST) en PLC.

Ejemplo ilustrativo: el bloque del motor de 15 kW

Datos supuestos: motor de 15 kW, 400 V, corriente nominal del orden de 28 A, contactor con contacto auxiliar de realimentación.

Con este bloque, un CCM de cuarenta motores es cuarenta instancias con sus parámetros. La protección de motor de baja tensión se mantiene en su equipo; el bloque solo vigila y señaliza.

3. Nombres y convenciones

• Un nombre dice qué es y dónde está: P101_MARCHA, no M23.
• La misma convención en programa, esquema, HMI y lista de cables.
• Mayúsculas, minúsculas y separadores uniformes.
• Prefijos que indiquen tipo (entrada, salida, parámetro, estado) si el entorno no lo muestra.
• Evitar abreviaturas que solo conoce el autor.

4. Fallas: diseñar el camino seguro

Cada equipo debe tener definido qué hace ante una falla y qué estado toma:

• Entradas de paro y protecciones normalmente cerradas, para que una rotura de cable se vea como disparo (ver ladder).
• Realimentación en cada orden: el contactor cerró o el actuador llegó a su posición; si no, se declara falla tras un tiempo.
• Señales analógicas con rango: por debajo del mínimo válido, cable roto; el valor se marca como inválido en vez de usarse.
• Estado de las salidas ante parada del PLC, decidido por proceso.
• Falla de comunicación con equipos que gobiernan variables críticas: valor seguro o último válido, con alarma.
• Reinicio manual tras una falla importante: la máquina no continúa sola.

La protección de personas no se resuelve en un programa estándar; se resuelve con circuitos y dispositivos de seguridad que cumplan las normas aplicables.

5. Modos de marcha

Manual, automático, mantenimiento y local suelen coexistir. Hay que definir quién manda en cada modo, qué enclavamientos siguen activos en manual (casi todos los de protección) y cómo se pasa de un modo a otro sin saltos. Un selector en el campo que contradice al programa sin que este se entere es una causa clásica de accidentes y confusiones.

6. Comentarios y documentación

Comentar el propósito, las decisiones y las suposiciones: «espera a que el nivel supere el límite porque el sensor oscila al llenar». Entregar con el programa:

• lista de señales con dirección, símbolo, descripción y plano;
• descripción funcional de cada secuencia y modo;
• matriz de causas y efectos de alarmas y disparos;
• esquema de comunicaciones y mapas de datos;
• registro de ajustes (tiempos, límites, escalas).

Esa documentación es también lo que piden las auditorías de clientes y de calidad. Vea SCADA y HMI de subestación para la parte de supervisión.

7. Control de cambios y respaldos

• Respaldo del programa antes de cada modificación, con fecha y versión.
• Registro de cambios: qué, quién, cuándo, por qué.
• Programa en el controlador igual al respaldo oficial; se compara antes y después.
• Copias fuera del equipo, en un lugar protegido.
• Acceso al controlador con contraseña y cuentas por persona, como parte de la ciberseguridad industrial.
• Los forzados se registran y se retiran.

Revisión de un programa antes de la puesta en servicio

Un programa se revisa como se revisa un plano. Una revisión entre pares, con una lista corta, detecta la mayoría de los defectos antes de energizar:

La revisión se registra, y las observaciones cerradas quedan como evidencia. En proyectos con cliente auditado, ese registro forma parte del expediente del sistema de control.

Cuándo refactorizar

Un programa que lleva años en servicio acumula parches. Se justifica ordenarlo cuando una modificación sencilla obliga a tocar muchos lugares, cuando nadie se atreve a cambiar una parte, o cuando las fallas se repiten por la misma causa. La refactorización se hace por partes, con respaldo previo, pruebas antes y después, y en una parada programada. Primero se extrae la lógica repetida a bloques, luego se unifican nombres y por último se limpia la lógica muerta. Un programa que se puede ordenar sin cambiar su comportamiento es señal de que estaba bien estructurado desde el inicio. Para probar un programa sin PLC físico, con OpenPLC y otros simuladores, vea simulación y herramientas gratuitas de PLC.

Errores frecuentes

• Un único programa gigante sin estructura.
• Lógica copiada y pegada por equipo, con pequeñas diferencias.
• Salidas escritas en varios lugares.
• Números mágicos en lugar de constantes con nombre.
• Sin vigilancia de realimentación, y fallas que se descubren por el proceso.
• Modificar el programa en línea sin respaldo.
• Comentarios que repiten el código o que quedaron desactualizados.
• Forzados olvidados.
• Contraseñas compartidas o sin cambiar desde el montaje.
• Documentación que no coincide con el programa en servicio.

Lista de verificación

• Programa por capas, con una sola escritura por salida.
• Bloques de función por tipo de equipo.
• Convención de nombres escrita y aplicada.
• Estado seguro definido para cada equipo y para la parada del PLC.
• Vigilancia de realimentación y de señales analógicas.
• Modos de marcha definidos y probados.
• Lista de señales, descripción funcional y matriz de causas y efectos al día.
• Respaldo versionado y registro de cambios.
• Contraseñas y cuentas gestionadas.
• Pruebas de fallas documentadas.

Dudas técnicas frecuentes

• ¿Cuánto tiempo debe tener el tiempo de vigilancia?: depende del equipo: se mide su tiempo de respuesta real en campo y se fija un margen sobre ese valor.
• ¿Se pueden usar los mismos bloques en distintos proyectos?: sí, con una biblioteca propia versionada y probada.
• ¿Es necesario un estándar de programación?: conviene tenerlo por empresa o por proyecto, aunque sea breve.
• ¿Cómo se prueba un bloque nuevo?: en simulación, con todos sus casos de falla, antes de usarlo en campo; vea simulación y herramientas de PLC.

Cómo le ayudamos

Un programa bien estructurado y documentado hace más corta la puesta en servicio y más fácil la auditoría. En Tiza Group hacemos la ingeniería del control, preparamos los protocolos de pruebas y dejamos el sistema listo para operar con la documentación trazable. Vea diseño de ingeniería y estudios y pruebas y puesta en servicio, o escríbanos por contacto.

Guías relacionadas

• CCM inteligente
• Protección de motor BT
• PLC y automatización de subestaciones
• IEC 62443 en subestaciones
• SCADA y HMI de subestación
• Enclavamiento mecánico y eléctrico
• Equivalencias entre marcas de PLC: conceptos y nombres

Referencias

• IEC 61131-3, estructura de programas (norma de pago).
• Hugh Jack, Automating Manufacturing Systems with PLCs (CC BY-NC-SA 3.0 US).
• Siemens SCE, documentos de formación (acceso con cuenta).
• PLCopen, guías de estilo y buenas prácticas.

Preguntas frecuentes