¿Cómo conectar un controlador lógico Siemens S7 a la nube en 2025?

· 15 min de lectura
15 min read
Lucas Moreau
Lucas Moreau
Ingeniero de redes OT/IT

Los controladores lógicos programables (PLC) Siemens S7 equipan decenas de miles de instalaciones industriales en Francia: líneas de producción, plantas de tratamiento e infraestructuras energéticas. Durante años, estos controladores funcionaban de forma aislada, comunicándose únicamente con un sistema de supervisión SCADA local. Hoy en día, existe una fuerte presión para conectarlos a la nube: supervisión remota, mantenimiento predictivo, centralización de los datos de producción y acceso de los equipos de mantenimiento desde cualquier lugar.

Pero conectar un S7 a la nube no es algo que se pueda improvisar. Los protocolos disponibles varían según la generación del controlador, la configuración de red de la planta puede impedir ciertos enfoques, y la seguridad del acceso remoto a un controlador de producción es un tema aparte.

Esta guía detalla tres métodos probados para conectar un controlador lógico Siemens S7 a la nube en 2025, junto con sus ventajas, sus limitaciones y ejemplos concretos de configuración.

¿Por qué conectar un S7 a la nube?​

Antes de entrar en detalles técnicos, veamos los fundamentos del ROI. Las empresas que dan el paso mencionan sistemáticamente tres ventajas principales:

Supervisión remota. Acceder a los valores de proceso, las alarmas y el estado de la línea desde un ordenador o un smartphone, sin necesidad de una VPN compleja configurada por el departamento de TI ni de tener que llamar al jefe de equipo in situ. Para un fabricante de maquinaria, esto supone la capacidad de ver en tiempo real el estado de cada instalación en las instalaciones de sus clientes.

Mantenimiento predictivo. Almacenar los datos del controlador en una base de datos temporal (InfluxDB, TimescaleDB, Azure Time Series Insights) permite detectar anomalías antes de que provoquen una parada. Un motor cuyo consumo aumenta progresivamente a lo largo de tres semanas puede detectarse mucho antes de que se produzca la avería.

Reducción de los desplazamientos. Un diagnóstico a distancia evita tener que desplazarse hasta las instalaciones. En el caso de una instalación situada a 500 km de la oficina técnica, esto supone un ahorro directo e inmediato.

Los protocolos disponibles en un controlador Siemens S7​

El primer paso es saber qué es lo que admite de forma nativa tu controlador lógico programable. La respuesta depende en gran medida de la generación.

ProtocoloS7-300 / S7-400S7-1200 (FW ≥ 4.x)S7-1500
S7COMM (protocolo nativo)Sí (puerto 102/TCP)SíSí
Modbus TCPA través de CP o FB de tercerosSí (FB nativo)Sí (FB nativo)
Servidor OPC-UANo nativoNo (solo cliente en FW 4.x)Sí (servidor nativo)
PUT/GETSíSí (se debe activar)Sí (se debe activar)
MQTTNoNo nativo (a través de una pasarela)A través de LHTTP o una pasarela

S7COMM: el protocolo nativo de Siemens​

S7COMM es el protocolo propio que utiliza TIA Portal para la comunicación entre el PC de programación y el controlador lógico programable. Funciona en el puerto TCP 102 y puede ser utilizado por clientes de terceros (libnodave, python-snap7) para leer y escribir variables. Sin embargo, este protocolo no se recomienda para una exposición en la nube: no admite la autenticación, y exponer el puerto 102 a Internet supone un grave fallo de seguridad.

PUT/GET: lectura directa desde un tercero​

La función PUT/GET permite a un cliente externo leer o escribir bloques de datos en el controlador. Está desactivada por defecto en los modelos S7-1200 y S7-1500 y debe autorizarse explícitamente en las propiedades de la CPU en TIA Portal. Lo mismo se aplica en materia de seguridad: debe utilizarse únicamente a través de una VPN, nunca de forma directa.

OPC-UA y Modbus TCP: los dos protocolos recomendados​

Para una integración segura en la nube, los dos métodos recomendados son OPC-UA (en S7-1500) y Modbus TCP (S7-1200 y S7-1500). Se trata de los protocolos para los que existen bibliotecas, conectores en la nube y soluciones de pasarela de probada eficacia.

Método 1 — A través de OPC-UA (S7-1500)​

OPC-UA es el protocolo de referencia para la interoperabilidad industrial. Desde la versión V2.0 del firmware del S7-1500, el servidor OPC-UA está integrado de forma nativa en la CPU. Es la solución más limpia y duradera para las nuevas instalaciones o para los controladores S7-1500.

Activación del servidor OPC-UA en TIA Portal​

Paso 1 — Abrir las propiedades de la CPU. En el proyecto de TIA Portal, selecciona la CPU S7-1500 y ve a Propriétés > OPC UA > Serveur.

Paso 2 — Activar el servidor. Marca la casilla Activer le serveur OPC UA. Deja el puerto por defecto (4840). Puedes definir un puerto personalizado si tu infraestructura de red lo requiere.

Paso 3 — Configurar la seguridad. Selecciona, como mínimo, el modo de seguridad SignAndEncrypt con Basic256Sha256. Nunca utilices None en producción, ya que equivale a exponer las variables del controlador sin autenticación.

Paso 4 — Crear los nodos OPC-UA. En el bloque de datos (DB), marca las variables que se van a exponer a través de OPC-UA (Accessible depuis OPC UA). Las variables que no estén marcadas no serán visibles desde el exterior; este es un primer nivel de filtrado.

Paso 5 — Implementar y probar. Cargar el proyecto en la CPU. Probarlo con un cliente OPC-UA como UaExpert (gratuito) desde la red local antes de configurar la pasarela en la nube.

Pasarela OPC-UA → Nube​

El servidor OPC-UA del S7-1500 está a la espera de conexiones entrantes. Para enviar los datos a la nube sin abrir un puerto de entrada (recomendación de seguridad), una pasarela IoT local se conecta al servidor OPC-UA como cliente y retransmite los datos a través de una conexión saliente HTTPS/MQTT hacia la nube.

# Ejemplo de configuración de la pasarela Eziwan — fuente OPC-UA
sources:
  - type: opcua
    endpoint: opc.tcp://192.168.1.10:4840
    security_mode: SignAndEncrypt
    security_policy: Basic256Sha256
    certificate: /etc/eziwan/opcua_client.pem
    polling_interval: 5s
    nodes:
      - node_id: "ns=3;s=DB1.temperature_process"
        name: temperature_process
        unit: °C
      - node_id: "ns=3;s=DB1.pression_bar"
        name: pression_bar
        unit: bar
      - node_id: "ns=3;s=DB1.etat_ligne"
        name: etat_ligne

destinations:
  - type: mqtt
    broker: mqtt.eziwan.cloud:8883
    tls: true
    topic_prefix: "usine/ligne1"

Método 2 — A través de Modbus TCP (S7-1200 / S7-1500)​

Modbus TCP es compatible de forma nativa con el S7-1200 (firmware 4.x y superior) y el S7-1500 a través de bloques funcionales (FB) integrados en TIA Portal. Este es el enfoque más recomendable cuando su pasarela IoT o su sistema SCADA utiliza Modbus TCP, o cuando necesita integrarse en un sistema existente que ya admite este protocolo.

Configuración del servidor Modbus TCP en el S7-1200​

Paso 1 — Crear un bloque de datos para los registros. Crea una base de datos Modbus_Holding_Registers con una matriz de tipo WORD del tamaño deseado (por ejemplo, 100 registros). El cliente Modbus podrá acceder a esta matriz en modo de lectura y escritura.

Paso 2 — Crear una instancia del FB MB_SERVER. En el bloque OB1 o en una tarea cíclica, crea una instancia del FB MB_SERVER (disponible en la biblioteca de TIA Portal).

// Exemple d'instanciation MB_SERVER en SCL
#MB_SERVER_Instance(
    EN_R_JMP    := TRUE,
    DISCONNECT  := FALSE,
    MB_HOLD_REG := "Modbus_Holding_Registers".data,
    NDR         := #NDR,
    DR          := #DR,
    ERROR       := #ERROR,
    STATUS      := #STATUS,
    CONNECT     := #TCON_Param
);

Paso 3 — Configurar los parámetros de conexión. En el bloque de datos TCON_Param, especifique:

  • InterfaceId: ID de la interfaz Ethernet de la CPU (normalmente 64)
  • ID: identificador de conexión (p. ej., 1)
  • ActiveEstablished: FALSE (el S7 espera conexiones)
  • RemotePort: 0 (acepta todos los clientes)
  • LocalPort: 502 (puerto Modbus estándar)

Paso 4 — Asignar las variables en la base de datos de registros. Escribir los valores de proceso en la tabla de registros desde el programa del controlador lógico programable. La pasarela IoT lee estos registros en Modbus TCP y los transmite a la nube.

Parámetros de configuración importantes​

ParámetroValor recomendadoObservación
Puerto502Modbus TCP estándar
Conexiones simultáneas3 como máximoValor por defecto del S7-1200
Tiempo de espera de conexión30 sA ajustar según la red
RegistrosBase de datos estructuradaEvitar el acceso a la memoria M
Actualización de registrosCíclica (100 ms)Adaptar a la dinámica del proceso

Método 3 — A través de la pasarela IoT RS-485 (todos los controladores lógicos programables)​

Este método se aplica cuando no se puede acceder directamente al controlador S7 desde la red IP (no hay interfaz Ethernet disponible, red OT aislada, un S7-300 antiguo sin módulo de control Ethernet) o cuando ya se dispone de un bus RS-485 Modbus RTU en el que se puede acceder al controlador como esclavo o maestro.

Arquitectura​

En este esquema, una pasarela IoT (por ejemplo, Eziwan Gateway) se conecta físicamente al puerto RS-485 del controlador lógico programable o de la red de campo y se comunica mediante Modbus RTU. La pasarela convierte los datos Modbus RTU a MQTT o HTTP y los transmite a la nube a través de su conexión 4G o Ethernet.

Configuración de Modbus RTU en el S7-300​

En un S7-300 con módulo de comunicación CP 340 o CP 341, la comunicación RS-485 Modbus RTU se configura mediante el software de parametrización de Siemens (protocolo USS o Modbus RTU, según el módulo). Los registros que se van a exponer se definen en la base de datos de comunicación del CP.

Este método presenta una ventaja fundamental: no requiere ninguna modificación del programa del controlador existente si este ya está configurado como maestro o esclavo Modbus RTU. La pasarela IoT es transparente para el controlador.

Proteger el acceso remoto al S7​

La seguridad del acceso a un controlador de producción es un tema crítico. Una configuración incorrecta puede exponer el proceso industrial a accesos no autorizados, o incluso a ataques (véanse los incidentes documentados en instalaciones industriales).

Principio: ningún puerto expuesto a Internet​

Nunca expongas directamente el puerto del autómata (TCP 102, TCP 502, TCP 4840) a Internet, ni siquiera detrás de un NAT. La forma correcta de hacerlo es mediante un túnel VPN saliente.

La pasarela IoT establece una conexión saliente cifrada con un concentrador VPN en la nube. El controlador, por su parte, solo ve la red local. Desde el exterior, el acceso se realiza a través del concentrador VPN, que autentifica y autoriza cada conexión.

Configuración de la VPN OpenVPN​

OpenVPN es el protocolo VPN recomendado para implementaciones industriales de IoT: atraviesa los cortafuegos a través del puerto TCP 443, se vuelve a conectar rápidamente tras una interrupción de la red (algo fundamental en 4G) y se autentica mediante un certificado X.509. IPSec (IKEv2) sigue estando disponible para entornos regulados.

# Configuración de OpenVPN en la pasarela de campo (perfil .ovpn)
client
dev tun
proto udp
remote vpn.eziwan.cloud 1194
remote-cert-tls server
cipher AES-256-GCM
auth SHA256
keepalive 10 60
persist-tun
# rutas de red enviadas por el servidor: 10.10.1.0/24
# Certificado de cliente X.509 insertado automáticamente mediante el aprovisionamiento sin intervención (Zero-Touch Provisioning)

Con esta configuración, la pasarela mantiene un túnel permanente hacia la nube. El controlador S7 permanece en la red local 192.168.x.x, sin quedar nunca expuesto directamente. El ingeniero de mantenimiento se conecta al concentrador VPN en la nube y accede al controlador a través del túnel.

Segmentación de la red​

Separar la red OT (autómatas) de la red IT (ofimática, nube) mediante un cortafuegos industrial o una VLAN dedicada. La pasarela IoT es el único puente autorizado entre ambas zonas, con reglas de tráfico estrictas (solo los protocolos y destinos necesarios).

Ejemplo de implementación completa​

Contexto: una línea de producción equipada con un S7-1500, con unas cien variables de proceso que deben supervisarse desde la sede central (a 300 km) y registrarse en un historial para el análisis del rendimiento.

Arquitectura implementada:

  1. S7-1500 en línea — servidor OPC-UA activado, 87 variables expuestas en 3 bloques de datos. Seguridad OPC-UA en modo SignAndEncrypt.

  2. Pasarela Eziwan Gateway en el armario de la línea — conectada por Ethernet local al S7-1500. Cliente OPC-UA que consulta las variables cada 5 segundos. Conexión VPN OpenVPN/IPSec permanente a la nube de Eziwan. Conmutación por error con doble SIM en caso de que falle la conexión Ethernet de la fábrica.

  3. Cloud Eziwan: recepción de datos mediante MQTT, almacenamiento en una base de datos temporal, agregación por hora y por día. API REST disponible para sistemas de terceros.

  4. Panel de control de Grafana en la sede: conexión a la API en la nube de Eziwan, visualización de los KPI de producción (TRS, cadencia, OEE), alertas por correo electrónico y SMS en caso de superación de los umbrales.

  5. Acceso remoto para mantenimiento: los ingenieros de mantenimiento se conectan a la VPN de Eziwan desde su ordenador. Ven el S7-1500 como si estuvieran en la red local de la fábrica, con acceso directo a TIA Portal para realizar el diagnóstico.

Resultado: puesta en marcha en 4 horas. Sin modificaciones en el programa del controlador lógico existente. Sin puertos abiertos en el cortafuegos del cliente.

Errores frecuentes​

  1. Activar PUT/GET sin VPN. La función PUT/GET permite el acceso directo a las bases de datos del controlador. Sin VPN, cualquier persona que pueda acceder a la red OT puede leer y escribir en las variables de producción. Esta es la configuración más peligrosa que se ha observado en la práctica.

  2. Utilizar S7COMM desde la nube. El protocolo nativo de Siemens (puerto 102) no está diseñado para su exposición externa. Las bibliotecas de terceros que lo implementan no son compatibles con los mecanismos de seguridad modernos.

  3. Descuidar el flujo de retorno. Una supervisión en la nube que envía comandos al controlador (puntos de consigna, comandos de arranque) requiere un análisis de seguridad más riguroso. Hay que definir claramente las variables de solo lectura y las de lectura/escritura en el servidor OPC-UA o en la asignación Modbus.

  4. Tener en cuenta la versión del firmware del S7. El servidor OPC-UA integrado solo está disponible a partir de una determinada versión de firmware, dependiendo del modelo. En el S7-1500, comprueba que el firmware sea ≥ V2.0 antes de planificar una integración OPC-UA.

  5. Subdimensionar la pasarela. Una pasarela que consulta 500 variables OPC-UA cada segundo, al tiempo que mantiene un túnel VPN y gestiona una conexión 4G, necesita recursos suficientes de CPU y memoria. Comprueba el rendimiento con una prueba de carga antes de la implementación en producción.

Preguntas frecuentes​

¿Se puede conectar mi S7-300 con CP Ethernet a la nube? Sí, pero las opciones son más limitadas. El S7-300 no es compatible de forma nativa con OPC-UA. Las opciones posibles son: Modbus TCP a través de un controlador de campo de terceros o un controlador de campo dedicado, S7COMM a través de una biblioteca de terceros (que solo debe utilizarse detrás de una VPN) o Modbus RTU RS-485 con una pasarela de IoT (método 3).

¿Se puede conectar un S7 a la nube sin modificar el programa del controlador lógico? A menudo sí, sobre todo mediante el método RS-485/pasarela (si el controlador ya dispone de un puerto RS-485 Modbus) o mediante OPC-UA en modo de solo lectura (las variables existentes se exponen sin modificar el programa). El método Modbus TCP servidor requiere modificaciones limitadas (añadir el FB MB_SERVER y una base de datos de registros).

¿Cuál es la latencia entre un valor de proceso y su visualización en el panel de control en la nube? Con un sondeo OPC-UA cada 5 segundos, una transmisión MQTT y una actualización del panel de control cada 5 segundos, la latencia total es de entre 5 y 15 segundos en condiciones normales. Esto no es adecuado para la regulación en tiempo real (que sigue siendo función del controlador lógico), pero es perfectamente suficiente para la supervisión y el mantenimiento.

¿Es necesario tener TIA Portal instalado en el ordenador del ingeniero para acceder de forma remota a través de una VPN? Sí, para acceder al programa del controlador lógico con fines de modificación (lo cual requiere TIA Portal). No, para la supervisión de variables, que se puede realizar a través del panel de control en la nube sin necesidad de tener instalado ningún software de Siemens.

Para profundizar en el tema​

¿Quieres conectar tus controladores Siemens S7 a la nube sin abrir puertos ni modificar tu programa? Ponte en contacto con nuestro equipo — diagnóstico de compatibilidad gratuito en 48 horas.

Recursos adicionales​