PLC, HMI y SCADA: qué función cumple cada uno en una planta industrial

PLC, HMI y SCADA cumplen funciones relacionadas dentro de un sistema de automatización. Comprender qué controla, qué presenta información al operador y qué reúne datos de varios puntos ayuda a describir la necesidad de una planta antes de elegir equipos o software.

PLC: ejecución del control

Un controlador lógico programable recibe señales, ejecuta la lógica configurada y actualiza salidas hacia los equipos de campo. Puede gestionar secuencias y funciones de control según su programa, entradas, salidas y capacidad. La arquitectura debe responder a los tiempos y a las condiciones del proceso.

La palabra PLC no acredita por sí sola una función de seguridad. Si el proyecto incluye protección de personas o del proceso, esas funciones necesitan requisitos y evaluación específicos. La guía NIST SP 800-82 Rev. 3 describe los componentes de control y la importancia de considerar el impacto de sus fallas.

HMI: interacción con el operador

La interfaz humano-máquina permite visualizar variables, estados y alarmas, y enviar órdenes o consignas cuando el diseño lo habilita. Puede ser un panel local o una aplicación en una estación de operación. Sus permisos y pantallas deben corresponder a las responsabilidades del usuario.

Una orden enviada desde la HMI depende de la lógica y las condiciones de aceptación del sistema. Por ello, el proyecto debe definir qué puede solicitar el operador y cómo responde el control. Una pantalla atractiva no demuestra que esas reglas estén completas.

SCADA: supervisión y adquisición de datos

Un sistema SCADA reúne datos de equipos o puntos distribuidos y facilita su supervisión centralizada. Puede incorporar visualización, alarmas, tendencias y registros según su configuración. Integra comunicaciones y funciones de interfaz; HMI y SCADA no son categorías excluyentes.

El alcance necesario depende de qué puntos se supervisan, dónde están, qué información se conserva y qué disponibilidad se requiere. No toda aplicación necesita la misma combinación de paneles, estaciones y servidores.

Aclare qué debe ocurrir ante una falla

Ejemplo hipotético: un PLC controla una secuencia local, una HMI permite operarla y un SCADA reúne tendencias de varias unidades. Antes de aprobar esa arquitectura, se debe acordar qué sucede si se pierde una pantalla, la comunicación o un servidor. La continuidad del control local depende del diseño y debe probarse; no se deduce únicamente de los nombres de los componentes.

El esquema explicativo propone preguntas de revisión, no una garantía de comportamiento. También conviene definir responsables de configuración, respaldos y cambios para que la información utilizada en operación sea coherente.

Describa primero las funciones que necesita la operación

Antes de decidir cuántos componentes utilizar, conviene describir las funciones: qué variables se adquieren, qué secuencias se ejecutan, quién puede emitir órdenes y qué información debe conservarse. Esta descripción permite evaluar una arquitectura por sus responsabilidades. Una lista de marcas o equipos, sin funciones definidas, deja pendientes las decisiones que afectan el uso cotidiano del sistema.

NIST SP 800-82 Rev. 3 presenta sensores, actuadores, controladores y componentes de supervisión como partes relacionadas de un entorno de tecnología operacional. El diseño necesita considerar las consecuencias físicas de su funcionamiento y sus fallas. La arquitectura concreta depende de la aplicación; los ejemplos de la guía no constituyen una receta para cualquier planta.

Como propuesta de relevamiento, identifique cada función y el componente que debería ejecutarla. Si varias partes participan, describa qué información intercambian. Así puede quedar claro si una secuencia depende solo del controlador local o si requiere también una aplicación de supervisión.

Una orden de operación tiene un recorrido definido

Cuando un operador solicita una acción desde una HMI, la pantalla es el punto de interacción. El proyecto debe definir cómo llega la solicitud al controlador, qué condiciones permiten aceptarla y cómo se informa el resultado. Mostrar un botón no describe las reglas de ejecución. Tampoco confirma que el operador dispone de permiso para utilizarlo en todas las condiciones.

Ejemplo hipotético: una pantalla permite solicitar el arranque de una unidad. El requerimiento funcional deberá indicar quién puede solicitarlo, qué estado necesita la unidad y qué respuesta se mostrará si la solicitud no se acepta. Esta descripción no prescribe una lógica de arranque ni reemplaza el análisis de seguridad del proceso.

La misma claridad se necesita para consignas y selección de modos. Conviene distinguir valor solicitado, valor aceptado y estado efectivo cuando esa diferencia resulte relevante para operar. La revisión de pantallas debería preguntar qué información ayuda al operador a comprender la respuesta del sistema, además de comprobar que la orden llega a su destino.

El dato puede pasar por varias representaciones

Una variable de campo puede adquirirse en un PLC, mostrarse en una HMI y conservarse en un registro de supervisión. Para interpretar sus valores, el proyecto debe acordar unidades, nombres y condiciones de actualización. Una tendencia histórica describe los datos que efectivamente se almacenaron; su interpretación depende de cómo se configuró ese registro.

Como ejemplo documental, una lista de variables puede indicar su origen, unidad, componente que la utiliza y finalidad del registro. Si un dato se calcula en otra aplicación, identifique esa relación. No debería confundirse una medición directa con un resultado calculado simplemente porque ambos aparecen con el mismo formato en una pantalla.

El apartado 2.3 de NIST sustenta la relación entre adquisición, control y supervisión. La propuesta de conservar esas referencias en el proyecto es una recomendación original. No obliga a utilizar un software particular ni establece una frecuencia universal de registro para todas las variables industriales.

Alarmas y tendencias responden a necesidades diferentes

Una alarma informa una condición que el diseño considera relevante para la atención del operador. Una tendencia permite observar cómo evolucionó una variable. El proyecto debe definir qué hará con cada función: el hecho de conservar un histórico no asegura que una situación reciba atención, y presentar una alarma no garantiza disponer del registro necesario para revisar su desarrollo.

Antes de elegir una HMI o un SCADA, describa qué eventos necesita reconocer el operador y qué registros necesita consultar mantenimiento. Añada quién revisará esos datos y durante cuánto tiempo deberían estar disponibles según el requerimiento de la planta. No se propone un período de conservación estándar ni se atribuye uno a una norma paraguaya.

También conviene acordar cómo se identifica un dato que dejó de actualizarse. Conservar el último número recibido puede resultar útil como referencia histórica, pero la interfaz debe permitir distinguirlo de una lectura actual si su uso lo requiere. Esta es una decisión de comportamiento y aceptación del proyecto.

Evaluar fallas requiere separar control, operación y registro

La pérdida de un panel puede afectar la capacidad de operar localmente sin tener las mismas consecuencias que la pérdida de un controlador. Una interrupción de comunicaciones también puede impedir el registro remoto. Para evaluar el diseño, prepare una matriz que vincule cada falla considerada con las funciones afectadas y la respuesta requerida.

En el ejemplo de una unidad con control local y supervisión central, las preguntas serían: ¿qué funciones siguen disponibles sin el servidor?, ¿cómo se informa la pérdida de datos?, ¿qué órdenes quedan bloqueadas o disponibles? Las respuestas deben surgir de la especificación y de pruebas acordadas. No pueden deducirse únicamente de que el proyecto incluya un PLC.

NIST destaca las necesidades de disponibilidad y las consecuencias de fallas en OT. El artículo utiliza ese marco para formular preguntas de diseño, sin declarar tolerancia a fallas ni certificación de seguridad. Si se requieren funciones de protección, deberán evaluarse dentro de su alcance específico por personal competente.

Responsabilidades durante el mantenimiento del sistema

Una arquitectura necesita responsables de programa, configuración de pantallas y datos de supervisión. Como criterio documental, conserve la identificación de versiones entregadas y describa quién autoriza sus modificaciones. Un cambio de escala en un controlador puede requerir revisar pantallas o registros asociados; esa relación debe quedar accesible para quienes mantienen el conjunto.

Los respaldos también deben corresponder al alcance del sistema. Un proyecto puede involucrar archivos de programa y configuraciones en varios componentes. La propuesta es identificar qué debe recuperarse y qué evidencia permitirá comprobar que la recuperación conserva las funciones acordadas. No se describe aquí un procedimiento de restauración sobre una planta en servicio.

Para una consulta en Paraguay, resulta útil llevar una descripción de la operación actual y de la necesidad futura: puestos de operación, unidades supervisadas, señales, registros y restricciones de disponibilidad. Esa información permite discutir una arquitectura con alcance concreto, sin suponer que una aplicación pequeña necesita las mismas funciones que un sistema distribuido.

Qué llevar a una consulta

Para un proyecto en Paraguay, describa unidades de proceso, señales, secuencias, puestos de operación y necesidades de registro. Puede consultar Automatización Industrial de TECNICAT y preparar los datos de campo con la guía de selección de instrumentación. El archivo de Automatización industrial reúne contenidos relacionados.

Fuentes técnicas

• NIST — National Institute of Standards and Technology. Guide to Operational Technology (OT) Security — NIST SP 800-82 Rev. 3. Edición final, septiembre de 2023; Rev. 4 en borrador público al consultar, no sustituye esta final. Modelo/alcance: Sin modelo; arquitectura OT. Apartado: §2.3, pp. 10–12; §2.3.2 SCADA Systems; §2.3.4 PLC-Based Topologies; glosario HMI/PLC; §6.2.4.2–6.2.4.3, pp. 111–113 (PDF 128–130), configuración y respaldos. Consulta: 2026-10-02.