El envío de datos desde PLC hacia la nube suele tratarse como una tarea sencilla de conectividad. Sin embargo, en entornos industriales reales, este proceso requiere una planificación meticulosa.
Los PLC se encargan principalmente del control local de máquinas, la lógica de procesos, la coordinación en materia de seguridad y la interacción con dispositivos de campo. Por otro lado, las plataformas en la nube se utilizan comúnmente para la supervisión remota, elaboración de informes, análisis de tendencias, planificación del mantenimiento y visibilidad entre sitios. Estas dos capas cumplen funciones distintas y no deben considerarse iguales ni intercambiables.
Por ello, muchas arquitecturas de conexión PLC-nube emplean una edge gateway entre el taller y los sistemas de nivel superior. Esta gateway no sustituye al PLC ni atribuye a la nube la responsabilidad del control en tiempo real. Su función es proporcionar una infraestructura controlada para recopilar datos seleccionados del lado del PLC, procesarlos localmente cuando corresponda y remitirlos a sistemas de supervisión remota o en la nube mediante una ruta de red segura.
Para los equipos que evalúan un gateway para enviar datos PLC a la nube, la cuestión práctica no es solo “¿Puede este dispositivo conectarse a un PLC?” sino: “¿Cómo deben recopilarse, protegerse, organizarse y entregarse los datos del lado del PLC a los sistemas que los requieren?”
¿Por qué los datos de PLC usualmente requieren un gateway antes de llegar a la nube?
Un PLC está diseñado para controlar máquinas y procesos industriales cerca del equipo. Puede intercambiar señales con sensores, variadores, actuadores, medidores, interfaces de operador u otros sistemas de automatización. En muchas instalaciones, el PLC forma parte de una red OT separada de los sistemas IT empresariales por razones de seguridad, confiabilidad y continuidad operativa.
Por este motivo, conectar PLCs directamente a sistemas en la nube no suele ser el punto de partida más práctico.
Existen varias razones para ello.
Primero, los datos del PLC suelen requerir contexto para ser útiles fuera del entorno de control. Un valor de registro bruto o un bit de estado tienen escaso significado para un panel de control en la nube si no se asocian a un estado de máquina, una condición de alarma, un contador de producción o un indicador de mantenimiento.
Segundo, no todos los valores del PLC deben transmitirse hacia arriba. Algunos respaldan la lógica de control local y deben permanecer próximos al sistema de automatización. Otros, como ciertos cambios de estado, alarmas, horas operativas, conteos de producción o lecturas energéticas, pueden ser valiosos para la supervisión remota o el análisis.
Tercero, la seguridad es crucial. Los equipos industriales necesitan métodos controlados para extraer datos seleccionados del entorno OT sin exponer innecesariamente los sistemas de control. Una capa pasarela contribuye a separar la transferencia de datos de la lógica de control, y además facilita medidas de seguridad como conexiones VPN, reglas de firewall y control de accesos.
Por estas razones, una pasarela de adquisición de datos PLC no se emplea simplemente para “conectar PLCs a la nube”, sino para crear un camino de datos más gestionable entre los sistemas locales de automatización y las aplicaciones de nivel superior.
¿Qué datos de PLC se recopilan comúnmente para supervisión remota?
Antes de diseñar un flujo de integración PLC-nube, conviene definir qué datos deben recopilarse realmente. Los datos del PLC pueden respaldar objetivos operativos diversos, y cada tipo debe tratarse de forma diferenciada.
| Tipo de dato PLC | Uso común | Valor para la nube o supervisión remota |
| Estado de la máquina | En operación, detenido, inactivo, fallo | Visibilidad de producción y seguimiento de tiempos de inactividad |
| Señales de alarma | Fallas, advertencias, estados anormales | Respuesta de mantenimiento y análisis histórico |
| Valores de proceso | Temperatura, presión, flujo, velocidad | Análisis de tendencias y monitoreo operacional |
| Datos de ciclo o producción | Conteos, tiempo de operación, estado de ciclo | Informes de rendimiento y productividad |
| Señales de energía o servicios | Consumo eléctrico, mediciones de medidores, estado de servicios | Monitoreo energético y análisis de eficiencia |
| Indicadores de mantenimiento | Horas operativas, indicadores de condición, eventos de servicio | Planificación del mantenimiento y visibilidad de activos |
Esta distinción es crucial porque los datos del PLC no deben considerarse como un flujo continuo que se desplaza en una única dirección.
Una falla de máquina puede requerir envío inmediato a una plataforma remota. Un contador de producción puede ser útil si se reporta periódicamente. Un valor de proceso puede interesar para análisis de tendencias a largo plazo, pero no necesita transmitirse en cada ciclo de escaneo. Valores relacionados con el control deben permanecer en el entorno local de automatización.
Una arquitectura práctica comienza por identificar qué datos del PLC respaldan la supervisión, los informes, el mantenimiento o la visibilidad operacional, en lugar de asumir que toda la información debe enviarse a la nube.
Cómo una pasarela de borde recopila datos del lado PLC
Una pasarela de borde obtiene información del PLC mediante interfaces y protocolos compatibles con la implementación. El método específico depende del tipo de PLC, las interfaces de comunicación disponibles, la configuración del protocolo y el diseño general de la red.
En ciertos entornos, la información del PLC puede estar accesible mediante comunicación serial, habitual en sistemas antiguos o en entornos Modbus RTU. En otros contextos, la comunicación puede basarse en Ethernet, dependiendo del controlador y del protocolo soportado. En escenarios de monitoreo más sencillos, también se pueden emplear señales de entrada digital para capturar cambios de estado seleccionados o eventos discretos.
Es fundamental comprender que la conectividad física no garantiza la usabilidad de los datos.
Una pasarela puede estar físicamente conectada a un sistema del lado del PLC, pero los datos deben ser recopilados mediante un protocolo o flujo de trabajo compatible. Por ejemplo, la información Modbus RTU puede necesitar convertirse o puentease hacia un entorno IP antes de que los sistemas superiores puedan emplearla. En ocasiones, se requiere una aplicación local que lea, analice, mapee o reformatee los datos antes de enviarlos aguas arriba.
Por ello, expresiones como “conectar datos de PLC a la nube” simplifican en exceso el esfuerzo de ingeniería real. Una pasarela no lee automáticamente cada etiqueta de PLC de todos los controladores; debe adaptarse a las interfaces, protocolos, pila de software y requerimientos específicos de cada proyecto.

Un flujo práctico de datos del PLC a la nube
Un flujo típico de datos desde el PLC hacia la nube puede entenderse como una secuencia de etapas. Los detalles varían según el PLC, la configuración de la pasarela, el protocolo y la plataforma en la nube, pero la trayectoria general de los datos suele seguir un patrón similar.
| Paso | Qué sucede | Por qué importa |
| 1. Se generan datos | El PLC o el sistema de automatización conectado produce datos de estado, alarmas, proceso o producción | Define qué información está realmente disponible |
| 2. Se recolectan datos | La pasarela recopila datos compatibles del lado del PLC mediante comunicación serial, Ethernet, E/S o una capa de aplicación | Establece un puente controlado entre sistemas OT y sistemas de nivel superior |
| 3. Se preparan los datos localmente | Los datos pueden mapearse, filtrarse, almacenarse en búfer, convertirse o formatearse | Contribuye a reducir el ruido y facilita el uso de los datos para sistemas de monitoreo |
| 4. Se transmiten los datos de forma segura | Los datos seleccionados se envían mediante una red cableada o celular | Permite acceso remoto o conectividad en la nube, manteniendo controles de seguridad |
| 5. Los datos se utilizan aguas arriba | Los sistemas en la nube o de monitoreo remoto emplean los datos para paneles de control, informes, alertas, análisis o planificación del mantenimiento | Convierte las señales del PLC en visibilidad operativa |
En la práctica, este flujo se puede describir así:
PLC o dispositivo habilitado para Modbus → interfaz serial o Ethernet compatible → recopilación en la pasarela o capa de aplicación → análisis, filtrado o almacenamiento local → canal de envío seguro → sistema en la nube, empresarial o de monitoreo remoto
Este flujo ilustra por qué la pasarela no es simplemente un dispositivo de paso de red; suele formar parte de la capa de manejo de datos, desempeñando funciones de puenteo de interfaces, preparación local de datos, comunicación segura y gestión remota de dispositivos.
Para proyectos de monitoreo remoto, resulta especialmente útil cuando los equipos requieren información específica de máquinas o procesos sin modificar la lógica de control del PLC ni exponer directamente el PLC a redes externas.
¿Qué debe enviarse a la nube y qué debe mantenerse local?
Una arquitectura confiable de PLC a la nube no exige que cada señal se transmita al sistema superior.
Algunos datos es preferible conservarlos cerca del PLC o del sistema de automatización local. Por lo general, esto incluye la lógica de control, interbloqueos rápidos de la máquina y valores que respaldan la operación inmediata del equipo. Estas tareas están estrechamente vinculadas al proceso físico y no suelen ser adecuadas para decisiones basadas en la nube.
Otros datos son más valiosos cuando se comparten con sistemas en la nube o de monitoreo remoto. Pueden incluir alarmas, estados operativos, contadores de producción, mediciones energéticas, horas de funcionamiento, indicadores de mantenimiento y ciertos valores del proceso. Estos puntos de información ayudan a los equipos de mantenimiento, gerentes de planta o servicios remotos a comprender el comportamiento del equipo sin necesidad de acceso directo a la capa de control.
Un proceso práctico para la selección de datos podría considerar varias interrogantes:
- ¿Esta señal apoya el control local, el monitoreo remoto o ambos?
- ¿Los datos cambian con frecuencia o solo ante eventos específicos?
- ¿Cada valor es útil o son más valiosas las excepciones y resúmenes?
- ¿Es necesario almacenar esta información para análisis a largo plazo?
- ¿Transmitir estos datos continuamente generaría un gasto innecesario de ancho de banda o almacenamiento?
- ¿Los datos contienen información operativa sensible que requiere protección adicional?
Este equilibrio es fundamental en la adquisición de datos de PLC. Los sistemas en la nube aportan valor para la visibilidad y el análisis, pero no es imprescindible que reciban todas las señales del PLC de forma continua. En muchas implementaciones, seleccionar y estructurar adecuadamente los datos resulta más útil que manejar grandes volúmenes de valores sin contexto.
Consideraciones de seguridad al enviar datos de PLC a la nube
La seguridad es uno de los aspectos más cruciales en la integración de PLC con la nube.
En numerosos entornos industriales, no se debe exponer directamente el PLC a internet público. Forma parte del entorno de control y su función primordial es operar máquinas o procesos con seguridad y fiabilidad. El monitoreo remoto debe diseñarse respetando esta delimitación.
Un gateway de borde puede facilitar una separación controlada entre los sistemas del lado del PLC y los sistemas externos o de capas superiores. En lugar de que las plataformas en la nube interactúen directamente con los PLC, dicho gateway recopila datos seleccionados y los transmite mediante una vía de comunicación gestionada.
Por lo general, se consideran varias medidas de seguridad importantes:
- Mantener la lógica de control del PLC separada de los flujos de trabajo de monitoreo remoto
- Utilizar VPN o rutas de red seguras cuando se requiera conectividad remota
- Aplicar reglas de firewall y controles de acceso para limitar exposiciones innecesarias
La seguridad no depende únicamente del gateway. Esta se fundamenta en la configuración, arquitectura de red, políticas de acceso y mantenimiento continuo. Sin embargo, la capa de gateway facilita el diseño de una ruta de datos controlada, a diferencia de conectar dispositivos de control directamente a sistemas externos.
Dónde encaja Robustel EG5120 en los flujos de trabajo de recopilación de datos PLC
En los flujos de trabajo de recopilación de datos PLC, un gateway industrial de borde como el Robustel EG5120 puede actuar como una capa de infraestructura próxima al campo para equipos seriales y Ethernet compatibles, reenvío seguro de datos, aplicaciones locales y gestión remota.
El EG5120 no es un conector universal para PLC, y el método de integración adecuado depende del PLC, protocolo, pila de software y diseño del proyecto. No obstante, varias capacidades del EG5120 son relevantes cuando se requiere recolectar datos del lado PLC o de dispositivos Modbus para trasladar información seleccionada hacia el monitoreo remoto o la nube.
| Requisito de recopilación de datos PLC | Capacidad relevante del EG5120 |
| Conectar equipos PLC con conexión serial o dispositivos Modbus | 2 puertos seriales configurables por software RS-232/RS-485 |
| Trasladar datos Modbus serial a entornos basados en IP | Soporte Modbus RTU a TCP |
| Conexión a redes Ethernet de fábrica | 2 puertos Ethernet RJ45 10/100/1000 Mbps, configurables como LAN o WAN |
| Monitoreo de señales discretas seleccionadas | 2 interfaces DI y 2 interfaces DO de contacto húmedo |
| Soporte para acceso remoto celular o conectividad de respaldo | Compatibilidad celular 5G, 4G/LTE, 3G y 2G con doble Mini SIM |
| Asegurar la comunicación remota | Opciones de túnel VPN, funciones de firewall, control de acceso y mapeo de puertos |
| Gestión de despliegues del gateway | Gestión remota RCMS, Web, CLI y SMS |
| Soporte para aplicaciones locales | RobustOS Pro, entorno basado en Debian, y SDK para desarrollo en C, C++, Python, Java, Node.js y tecnologías relacionadas |
| Despliegue en entornos industriales | Carcasa metálica, entrada de 9–60 VDC, instalación en riel DIN, pared o escritorio, rango operativo de -40 a +70°C |
En implementaciones específicas, el EG5120 también puede soportar diferentes flujos de trabajo basados en software. Por ejemplo, algunos proyectos emplean aplicaciones locales para recopilar datos Modbus, analizarlos y reenviar valores seleccionados mediante flujos MQTT. Otros utilizan software de borde como Ignition Edge o AWS IoT SiteWise Edge, según requisitos de integración y configuración.
Estos ejemplos deben interpretarse como patrones de implementación, no como comportamientos predeterminados automáticos. La arquitectura final depende del entorno PLC, sistema en la nube, diseño de red, requisitos de seguridad y pila de software elegidos.
Explore el Gateway Industrial de Borde Robustel EG5120
Quienes busquen una visión general rápida de la serie EG de Robustel y de cómo este tipo de gateway industrial se posiciona para la conectividad de borde, aplicaciones locales y gestión remota, pueden consultar este breve video explicativo a continuación.
Perspectiva final
Los gateways de borde desempeñan un papel crucial en la integración PLC-a-nube, pues los datos PLC raramente están listos para la nube de forma nativa.
En entornos reales de automatización industrial, los datos del PLC deben recopilarse mediante interfaces soportadas, interpretarse a través del protocolo o capa de aplicación adecuada, prepararse para su uso y transmitirse mediante una ruta de comunicación segura. Paralelamente, la lógica de control y las tareas automáticas sensibles al tiempo permanecen cerca del PLC y el equipo local.
El valor del gateway no radica en conectar cada PLC directamente a la nube, sino en facilitar una ruta de datos controlada y mantenible entre la planta industrial y los sistemas que requieren información operativa seleccionada.
Para la supervisión remota PLC y el flujo de datos en IoT industrial, la arquitectura más práctica suele ser aquella que respeta ambos extremos del sistema: la automatización local se mantiene protegida y operativa, mientras que los datos PLC seleccionados se ponen a disposición para monitoreo, informes, planificación de mantenimiento y mayor visibilidad operacional.
Preguntas frecuentes
P1: ¿Cómo puede enviarse de forma segura la información PLC a la nube?
R1: La información PLC generalmente se transmite a la nube mediante una capa gateway controlada, evitando así la exposición directa del PLC a Internet. El gateway recolecta datos seleccionados del PLC, realiza procesamiento local si es necesario y los reenvía por una ruta de red protegida. Es fundamental considerar VPN, firewall, control de acceso, permisos de usuario y segmentación de la red OT en la arquitectura.
P2: ¿Debería un PLC conectarse directamente a la nube?
R2: En la mayoría de entornos industriales, la exposición directa del PLC a la nube no es la solución óptima. Los PLC suelen manejar tareas de control local y deben permanecer protegidos dentro del entorno OT. Un gateway o capa de integración puede recopilar datos seleccionados y enviarlos aguas arriba, manteniendo la lógica de control cerca de la máquina, proceso o sistema de automatización.
P3: ¿Cómo recopila un gateway de borde los datos PLC?
R3: Un gateway de borde recolecta datos del PLC mediante interfaces y protocolos compatibles, como serial, Ethernet, entradas/salidas digitales o flujos de aplicaciones configuradas. El método exacto depende del PLC, las interfaces disponibles, soporte de protocolo y diseño del proyecto. En ocasiones, los datos deben mapearse, filtrarse, convertirse, almacenarse temporalmente o formatearse antes de su uso en sistemas de monitoreo o nube.
P4: ¿Qué datos PLC son útiles para el monitoreo remoto?
R4: Los datos PLC útiles suelen incluir estado de maquinaria, alarmas, valores de proceso, conteos de producción, tiempo de operación, consumos energéticos e indicadores de mantenimiento. No es necesario enviar todas las señales PLC. Muchos proyectos remotos se enfocan en datos que permiten identificar paros, condiciones anómalas, uso del equipo, necesidades de mantenimiento o tendencias productivas, sin afectar la lógica de control local.
P5: ¿Qué deben considerar los equipos al elegir un gateway para adquisición de datos PLC?
R5: Los equipos deben evaluar interfaces PLC disponibles, protocolos compatibles, requisitos de seguridad, condiciones de red, necesidades de procesamiento local, método de integración con la nube y gestión a largo plazo del dispositivo. También es esencial confirmar que el gateway soporte el flujo de trabajo específico de datos requerido. El gateway debe adaptarse al entorno de automatización real, no solo a la plataforma cloud deseada.
Este artículo ha sido traducido por IA del original en inglés en el Blog de Robustel en How Edge Gateways Collect PLC Data and Send It to the Cloud


