Una guía práctica para distinguir equipos que pueden parecer similares, pero que fueron diseñados para resolver problemas diferentes de control, adquisición, telemetría, concentración y registro de señales industriales.
Figura 1. Mapa conceptual de las principales familias de equipos abordadas en esta guía. Ilustración conceptual; la apariencia física varía por fabricante y aplicación.
En automatización industrial es común encontrar proyectos en los que un PLC registra datos, una RTU ejecuta lógica, un Data Logger comunica información a la nube o un equipo de adquisición incorpora funciones de control. Esa superposición de capacidades hace que los nombres parezcan intercambiables. Pero No lo son.
La forma más útil de distinguirlos no es preguntar “¿qué puede hacer este equipo?”, sino “¿para qué función fue diseñado principalmente?”. Ese cambio de enfoque permite comparar arquitecturas con mucha más claridad.
| Idea central En equipos modernos las fronteras se traslapan. Un PLC puede almacenar históricos y una RTU puede ejecutar control. La clasificación sigue siendo útil cuando se basa en la función dominante: control, telemetría remota, extensión de I/O, concentración, registro o adquisición de alta velocidad. |
1. El mapa rápido: siete roles que conviene separar
Para esta comparación agruparemos siete conceptos que sí comparten una relación directa con las señales de campo y su uso dentro de una arquitectura de automatización: PLC, PAC, RTU, Remote I/O, concentrador de señales/datos, Data Logger y DAQ.
Figura 2. Una forma práctica de ordenar la familia: control, telemetría remota, adquisición de campo y concentración/registro.
| Equipo | Rol dominante | La pregunta que responde |
| PLC | Control | ¿Qué debe hacer la máquina o el proceso, ahora? |
| PAC | Control avanzado | ¿Cómo integro control, datos y funciones más complejas en una plataforma de mayor escala? |
| RTU | Telemetría + control remoto | ¿Qué ocurre en este sitio remoto y cómo lo superviso o controlo desde otro lugar? |
| Remote I/O | Extensión de entradas/salidas | ¿Cómo llevo las señales del campo al controlador sin cablear todo hasta el tablero central? |
| Concentrador | Agregación | ¿Cómo reúno información de varios equipos y la presento de forma consolidada? |
| Data Logger | Registro histórico | ¿Qué ocurrió, cuándo ocurrió y cómo conservo el histórico? |
| DAQ | Medición / adquisición | ¿Cómo capturo señales con la velocidad, resolución o sincronización que exige el análisis? |
2. PLC: cuando el problema principal es controlar
Un PLC (Programmable Logic Controller) es una computadora industrial diseñada para automatizar maquinaria y procesos. Lee entradas, ejecuta una lógica programada y actualiza salidas para controlar motores, válvulas, alarmas y otros elementos del proceso en tiempo real. [1]
Su fortaleza no es simplemente “leer señales”, sino tomar decisiones de control de manera repetible y determinística. Por eso sigue siendo la referencia natural para secuencias, interlocks, lógica discreta, PID, coordinación de equipos y automatización de máquinas.
| Piensa en PLC cuando… La prioridad sea controlar una máquina o proceso: leer sensores, ejecutar lógica, actuar sobre salidas, mantener interlocks y responder en ciclos previsibles. |
3. PAC: la frontera moderna del PLC
PAC significa Programmable Automation Controller. Tradicionalmente se usa para describir controladores con mayor potencia de procesamiento, escalabilidad, conectividad y capacidad para integrar varias disciplinas —por ejemplo, control de proceso, movimiento, datos y redes— dentro de una misma plataforma. [1][2]
Pero hay que evitar una simplificación: la línea entre PLC y PAC se ha vuelto difusa. Muchos PLC modernos incorporan funciones que hace años se asociaban a un PAC. Por eso, en una arquitectura real conviene comparar desempeño, arquitectura, capacidad de I/O, redundancia, motion, comunicaciones y manejo de datos, no solo la etiqueta comercial.
| Regla práctica PLC y PAC pertenecen a la misma familia de controladores programables. “PAC” sigue siendo útil para describir plataformas de control de mayor alcance o integración, pero no debe interpretarse como una frontera tecnológica absoluta. |
4. RTU: control y datos cuando el proceso está lejos
Una RTU (Remote Terminal Unit) está orientada a conectar el mundo físico con un sistema de supervisión —normalmente SCADA— en instalaciones remotas. Puede adquirir señales, ejecutar lógica local, almacenar información y recibir comandos, pero su diseño pone especial énfasis en la telemetría, las comunicaciones y la autonomía del sitio. [3]
Esto resulta especialmente importante en estaciones de bombeo, pozos, ductos, redes de agua, subestaciones, generación distribuida o infraestructura dispersa, donde la comunicación puede ser de bajo ancho de banda, intermitente o depender de radio, celular o enlaces de larga distancia.
| La diferencia con un PLC Un PLC suele partir de la necesidad de controlar un proceso local. Una RTU suele partir de la necesidad de supervisar y controlar un proceso remoto, manteniendo comunicaciones robustas y operación local aun cuando el enlace con el centro de control no sea perfecto. |
5. Remote I/O: llevar las señales al controlador
Un sistema de Remote I/O distribuye módulos de entradas y salidas cerca de sensores y actuadores y los enlaza por una red industrial con el controlador de nivel superior. Su objetivo es reducir cableado, acercar la adquisición al proceso y simplificar la distribución física de señales. [4]
Aquí está una distinción importante: Remote I/O no equivale a un PLC remoto. Puede incorporar diagnóstico o funciones inteligentes, pero normalmente la lógica principal permanece en el PLC, PAC o sistema de control que consume esas I/O.
| Arquitectura típica Sensor 4–20 mA → módulo de entrada analógica remoto → PROFINET / EtherNet/IP / fieldbus → PLC o PAC. El Remote I/O acerca la señal; el controlador toma la decisión. |
6. Concentrador de señales o datos: reunir antes de entregar
El término “concentrador” no está tan estandarizado comercialmente como PLC o RTU, por lo que conviene definirlo por función. En esta guía lo usamos para describir un equipo cuya tarea principal es recopilar información de múltiples dispositivos o fuentes y presentarla de manera consolidada hacia un sistema superior. En automatización eléctrica y de subestaciones, por ejemplo, un data concentrator puede construir una base de datos local con información dinámica de varios IED y transferir subconjuntos relevantes a un sistema maestro. [5]
Dependiendo del producto, puede recibir datos por serial, Ethernet o buses industriales; puede incorporar almacenamiento o conversión de protocolos; e incluso puede tener I/O local. Sin embargo, su identidad viene de la agregación de información, no del control del proceso.
7. Data Logger: medir y conservar el histórico
Un Data Logger está diseñado para realizar mediciones y almacenar datos asociados a tiempo. El reloj, el intervalo de muestreo y los eventos de almacenamiento forman parte central de su lógica de operación. [6]
Esto cambia la pregunta de diseño. En lugar de “¿qué salida debo activar?”, un Data Logger responde “¿qué valor medí, en qué instante y cómo lo conservaré?”. Por eso es común en monitoreo ambiental, energía, condición de activos, instrumentación distribuida, investigación y aplicaciones en las que el histórico debe sobrevivir aun si la comunicación hacia un sistema central se pierde temporalmente.
| No confundir con historian El Data Logger normalmente captura y conserva datos cerca de la fuente. Un historian industrial es una plataforma de software/base de datos para almacenar y contextualizar grandes volúmenes de información de múltiples sistemas. Pueden trabajar juntos, pero resuelven capas distintas. |
8. DAQ: cuando la calidad de la medición manda
DAQ (Data Acquisition) se refiere al proceso y a los sistemas utilizados para medir fenómenos eléctricos o físicos —por ejemplo voltaje, corriente, temperatura, presión, vibración o sonido— mediante sensores, hardware de medición y software de análisis. [7]
El DAQ cobra especial relevancia cuando importan variables como frecuencia de muestreo, resolución, sincronización entre canales, acondicionamiento de señal y precisión. Por eso aparece con frecuencia en pruebas, validación, vibración, acústica, deformación, análisis eléctrico, bancos de ensayo y diagnóstico de fenómenos rápidos.
| La diferencia con un Data Logger Ambos pueden registrar datos. El Data Logger prioriza la captura autónoma y el histórico a lo largo del tiempo; un sistema DAQ suele priorizar la fidelidad, velocidad, sincronización y análisis de la medición. Hay productos que cubren ambos mundos. |
9. La comparación que realmente importa
La tabla siguiente no pretende definir límites rígidos. Resume el propósito dominante que normalmente guía la selección.
Nota: “posible”, “frecuente” o “depende” reflejan el traslape entre plataformas modernas; la tabla describe el rol dominante, no una limitación universal.
10. Tres arquitecturas para entenderlo mejor
Ver estos equipos dentro de una arquitectura ayuda más que compararlos como productos aislados.
Figura 3. Tres ejemplos conceptuales: control de línea, sitio remoto y monitoreo/pruebas. Las funciones pueden combinarse de formas distintas según la plataforma seleccionada.
Arquitectura A — línea de producción
Sensores y actuadores se conectan directamente o mediante Remote I/O. El PLC/PAC ejecuta la lógica de la máquina o línea. HMI/SCADA permite operar, visualizar estados y gestionar alarmas. Aquí el requisito dominante es el control.
Arquitectura B — sitio remoto
Instrumentos de campo llegan a una RTU que adquiere variables, ejecuta control local y mantiene comunicación con un SCADA central. El diseño debe considerar la calidad del enlace, autonomía del sitio, almacenamiento local y recuperación ante interrupciones.
Arquitectura C — monitoreo y pruebas
Uno o varios Data Loggers o sistemas DAQ capturan variables. Un concentrador puede reunir datos de varios equipos antes de enviarlos a una estación de análisis, historian o plataforma superior. Aquí el requisito dominante es la calidad, continuidad y disponibilidad del dato.
11. ¿Cuál necesito? Empieza por la necesidad, no por el acrónimo
Figura 4. Árbol de decisión simplificado para orientar la primera selección. La ingeniería final debe considerar desempeño, arquitectura, ambiente, ciberseguridad y ciclo de vida.
- Si necesito controlar una máquina o proceso, empiezo por PLC/PAC.
- Si el activo está remoto y la telemetría es crítica, evalúo una RTU.
- Si el problema es la distancia entre señales y controlador, evalúo Remote I/O.
- Si tengo que reunir información de muchos equipos, evalúo un concentrador.
- Si necesito conservar históricos de manera autónoma durante largos periodos, evalúo un Data Logger.
- Si necesito medir señales rápidas, sincronizadas o con alta precisión, evalúo un sistema DAQ.
12. Cinco errores comunes al seleccionar
- Elegir por el número de I/O y no por la función dominante. Dos equipos pueden tener el mismo número de canales y estar optimizados para problemas totalmente distintos.
- Suponer que más capacidad de cómputo significa automáticamente mejor control. En una aplicación industrial también importan determinismo, diagnóstico, disponibilidad, certificaciones y ciclo de vida.
- Usar un PLC como Data Logger sin revisar memoria, retención, timestamps, estrategia de almacenamiento y comportamiento ante pérdida de comunicación.
- Usar un equipo de telemetría como si fuera Remote I/O. La RTU tiene una misión de sitio remoto; Remote I/O tiene una misión de extensión de señales hacia un controlador.
- Comparar un DAQ y un PLC únicamente por velocidad. En medición también cuentan resolución, precisión, acondicionamiento, sincronización, anti-aliasing y trazabilidad de la señal.
13. La pregunta final no es “PLC o RTU”
La selección correcta empieza definiendo qué parte del problema debe resolver el equipo: controlar, extender señales, operar un sitio remoto, concentrar información, guardar históricos o medir con alta velocidad y precisión.
Después vienen las variables de ingeniería: número y tipo de señales, ciclo de control, tasa de muestreo, precisión, distancia, topología, protocolos, disponibilidad, redundancia, ambiente, ciberseguridad, mantenimiento y costo de ciclo de vida. En muchos proyectos la respuesta no será un solo equipo, sino una arquitectura en la que varias de estas funciones conviven.
| En una frase No selecciones por el nombre del equipo. Selecciona primero la función que debe dominar la arquitectura y después valida qué plataforma la ejecuta con el nivel de desempeño, disponibilidad y mantenibilidad que necesita el proceso. |
JAR OT
En JAR OT trabajamos estas decisiones desde la arquitectura: señales de campo, control, conectividad industrial, adquisición de datos, visualización e integración OT/IT. El objetivo no es agregar componentes, sino asignar cada función a la capa correcta y construir una solución mantenible durante todo su ciclo de vida.
Notas editoriales para publicación
| Título SEO sugerido | PLC vs RTU vs PAC vs Remote I/O vs Data Logger vs DAQ: diferencias y cuándo usar cada uno |
| Slug sugerido | /blog/plc-rtu-pac-remote-io-data-logger-daq-diferencias |
| Meta description | Conoce las diferencias entre PLC, PAC, RTU, Remote I/O, concentradores, Data Loggers y sistemas DAQ, y aprende cuándo conviene usar cada uno en automatización industrial. |
| Categoría sugerida | Automatización Industrial |
| Extracto | PLC, RTU, PAC, Remote I/O, Data Logger y DAQ pueden compartir capacidades, pero no fueron diseñados para resolver el mismo problema. Esta guía los compara por función, arquitectura y aplicación. |
Fuentes y referencias técnicas
Las definiciones se redactaron como síntesis editorial. Se utilizaron como referencia técnica materiales de fabricantes y proveedores especializados para validar la función dominante de cada categoría.
[1] Rockwell Automation — Controladores programables / PLC y PAC. Definición de PLC y diferenciación tradicional PLC/PAC. https://www.rockwellautomation.com/es-mx/products/hardware/programmable-controllers.html
[2] Schneider Electric — What’s the difference between a PLC and PAC?. Contexto sobre el traslape y mayor escala/funcionalidad de PAC. https://blog.se.com/industry/machine-and-process-management/2018/12/24/whats-the-difference-between-a-plc-and-pac/
[3] Emerson — OpenEnterprise / RTU terminology. RTU como interfaz entre el mundo físico y un sistema SCADA mediante telemetría y control. https://www.emerson.com/is/content/emerson/en/final-control/documents/d301807x012.pdf
[4] Phoenix Contact — Remote I/O systems. Remote I/O para conectar sensores y actuadores próximos al proceso e integrarlos al sistema de control. https://www.phoenixcontact.com/en-mx/products/plcs-controllers-and-i-os/remote-i-o-systems
[5] Schweitzer Engineering Laboratories — Data Concentrator. Ejemplo de definición funcional de data concentrator en automatización eléctrica. https://cdn.selinc.com/assets/Literature/Publications/White%20Papers/6112.pdf
[6] Campbell Scientific — Understanding the Roles of Data Loggers, RTUs, PLCs, and PACs. Data Logger como equipo que realiza mediciones y almacena datos con timestamp. https://us.campbellsci.com/blog/understanding-dataloggers-rtus-plcs-pacs
[7] NI — Adquisición de datos (DAQ). DAQ como proceso/sistema para medir fenómenos eléctricos y físicos mediante sensores, hardware y software. https://www.ni.com/es/shop/data-acquisition.htmlDocumento editorial preparado para revisión. Las imágenes son ilustraciones conceptuales generadas para esta publicación y no representan modelos específicos ni