En resumen: qué hay que destacar de esta comparativa​

Antes de entrar en detalles, he aquí las principales conclusiones para los responsables de la toma de decisiones que tienen prisa:

• Cobertura: los cuatro operadores (Orange, SFR, Bouygues y Free) ya superan el 99 % de la población con cobertura 4G gracias al New Deal Mobile de 2018. La diferencia radica en las zonas rurales y en la extensión del territorio, donde Orange mantiene una ligera ventaja.
• Precio: Bouygues y SFR suelen ser los más competitivos en cuanto a volumen; Orange aplica un recargo por cobertura.
• Resiliencia: ninguna tarjeta SIM de un solo operador cubre el 100 % de un parque con múltiples ubicaciones. La tarjeta SIM multioperador (multi-IMSI / eUICC) cambia automáticamente a la mejor red y elimina las zonas sin cobertura de un solo operador.
• Urgencia 2026-2028: la 2G se apaga (Orange cerrará la suya entre el 22 de septiembre y el 20 de octubre de 2026) y la 3G le seguirá hacia 2028. Cualquier nuevo despliegue debe ser, como mínimo, LTE-M / NB-IoT / 4G, so pena de quedar rápidamente obsoleto.
• Seguridad: para la industria crítica (NIS2), la APN privada + VPN ya no es una opción, sino un requisito imprescindible.

¿Qué es una tarjeta SIM M2M y en qué se diferencia de una tarjeta SIM para particulares?​

Una SIM M2M (Machine-to-Machine), que hoy en día se conoce más comúnmente como SIM IoT, es una tarjeta SIM diseñada específicamente para equipos industriales y conectados. Se diferencia de una SIM de smartphone en casi todos los aspectos:

Formato de tarjeta SIM industrial: las pasarelas y los routers IoT suelen incorporar una ranura para tarjetas SIM en formato 2FF (mini-SIM, 25×15 mm) o 3FF (micro-SIM), o incluso una eSIM soldada (MFF2) para entornos con fuertes vibraciones. Es imprescindible comprobarlo antes de realizar cualquier pedido, ya que un formato incorrecto paraliza todo el despliegue.

A tener en cuenta: una tarjeta SIM M2M no es solo una «tarifa económica». Es un componente industrial diseñado para durar tanto como la máquina en la que está instalada.

Cobertura móvil en Francia en 2026: lo que revelan los datos de la ARCEP​

La cobertura es el criterio más importante a la hora de elegir una tarjeta SIM M2M. A continuación se presenta la situación real de la red, basada en los datos de la ARCEP correspondientes al cuarto trimestre de 2025 (publicados en marzo de 2026), en lugar de en los argumentos comerciales de los operadores.

4G: todos superan el 99 % de la población​

Gracias a las obligaciones vinculantes del New Deal Mobile de 2018, los cuatro operadores cubren hoy en día más del 99 % de la población francesa con 4G. Por lo tanto, la batalla ya no se libra en torno a la población, sino en torno a:

• La cobertura territorial (zonas rurales, montaña, vías secundarias), donde Orange sigue a la cabeza.
• La cobertura en interiores y la calidad de la señal, que ahora la ARCEP clasifica en tres niveles: muy buena, buena y limitada.
• Las zonas sin cobertura restantes, que se abordan mediante el dispositivo de cobertura específica (varios miles de torres compartidas).

Puesta en común: el acuerdo «Crozon» entre SFR y Bouygues​

Un aspecto importante para la resiliencia de una red: SFR y Bouygues Telecom comparten parte de su red en las zonas menos densas (acuerdo de mutualización conocido como «Crozon»). En la práctica, en estas zonas, elegir SFR o Bouygues puede equivaler a conectarse a la misma antena física, lo que reduce el interés de una conmutación por error entre estas dos operadoras y refuerza el interés de una conmutación que incluya a Orange (red independiente). Free, por su parte, se beneficia de la itinerancia en la red de Orange en las zonas en las que aún no tiene cobertura.

Bandas de frecuencia clave para el IoT​

En el caso de un sensor situado bajo tierra o en una zona rural, lo que importa son las bandas bajas (700/800 MHz), y no el 5G urbano que se promociona en la publicidad.

⚠️ Fin de las redes 2G y 3G: la fecha límite que deja obsoletos los parques​

Es el aspecto más subestimado de una implementación del IoT en 2026, y merece una sección dedicada exclusivamente a él.

• 2G: Orange cerrará su red 2G entre el 22 de septiembre y el 20 de octubre de 2026. El resto de operadores siguen un calendario similar. La ARCEP prevé incluso eliminar la obligación de cartografiar la red 2G, lo que indica que la tecnología está llegando al final de su vida útil.
• 3G: cierre previsto hacia 2028.

Consecuencia directa: cualquier módem o módulo IoT exclusivamente 2G (que todavía es muy habitual en los contadores y alarmas antiguos) dejará de funcionar a partir del otoño de 2026. Un módulo 2G/3G sin compatibilidad con 4G dejará de funcionar hacia 2028.

¿Qué hacer?

• Para cualquier nueva implantación: exigir módulos 4G (LTE Cat-1 / Cat-1 bis) o IoT de bajo consumo LTE-M / NB-IoT, que seguirán siendo compatibles mucho más allá de 2030.
• Para un parque existente en 2G/3G: planificar una sustitución del hardware antes de que caduque. No basta con una tarjeta SIM compatible con LTE-M/NB-IoT si el módem no lo es.
• Dar prioridad a las tarjetas SIM cuyo operador garantice explícitamente la compatibilidad con LTE-M y NB-IoT a largo plazo.

Consejo de Eziwan: las pasarelas y la tarjeta SIM de Eziwan son compatibles con 4G/LTE-M con conmutación automática, diseñadas para superar estas interrupciones sin necesidad de intervención in situ.

Los operadores M2M en Francia: panorama para 2026​

Orange Business (Flux M2M / Orange IoT)​

Orange es el operador histórico con la cobertura más amplia, especialmente en las zonas rurales y en los territorios de ultramar.

Ofertas M2M:

• Flux M2M Lite: solo datos, tarifas de 1 MB a 2 GB al mes
• Flux M2M Pro: datos + SMS + voz, APN privado disponible
• Orange IoT Suite: gestión de flotas de tarjetas SIM + conectividad + API

Puntos fuertes:

• La cobertura 4G más amplia, con ventaja en zonas rurales y extensas
• Red LTE-M desplegada a nivel nacional para el IoT de bajo consumo
• Cobertura en DOM/COM (Reunión, Martinica, Guadalupe, Antillas, etc.)
• Acuerdo de nivel de servicio (SLA) para empresas con hasta un 99,9 % de disponibilidad
• Miembro de la GSMA para perfiles eSIM industriales
• Red independiente (no compartida): adecuada como «segundo operador» en caso de conmutación

Puntos débiles:

• Tarifas premium: a menudo entre un 20 % y un 40 % más caras que las de SFR y Bouygues
• Compromiso de contrato M2M, normalmente de 24 a 36 meses
• Pedido mínimo a veces elevado (≈100 tarjetas SIM)

Tarifas orientativas (solo datos, sin opciones):

SFR Business (SFR IoT)​

SFR ofrece planes M2M competitivos, con una buena relación calidad-precio en implementaciones a gran escala y un sistema de pooling muy valorado.

Ofertas M2M:

• SFR IoT Connect: conectividad de datos M2M
• SFR IoT Platform: gestión de flotas + API + alertas
• Ofertas compartidas (pooling): un volumen global compartido entre todas las tarjetas SIM del contrato

Puntos fuertes:

• Tarifas competitivas (a menudo entre un 15 % y un 25 % más baratas que las de Orange en volúmenes medios)
• Pooling: ideal cuando el consumo varía de una tarjeta SIM a otra
• Red 4G comparable a la de Orange, 5G urbana de alto rendimiento
• API de gestión de flotas bien documentada

Puntos débiles:

• Cobertura ligeramente inferior a la de Orange en zonas muy rurales
• Red compartida con Bouygues («Crozon») en zonas poco pobladas: la conmutación de emergencia entre SFR y Bouygues resulta poco eficaz en estas zonas
• El servicio de asistencia M2M es, en ocasiones, menos receptivo que el del segmento Enterprise

Precios orientativos:

Bouygues Telecom Empresas (IoT)​

Bouygues ha mejorado considerablemente su cobertura y suele ofrecer las tarifas más bajas del mercado en cuanto a volumen.

Ofertas M2M:

• Bouygues Telecom IoT: tarjeta SIM de datos, SMS y voz
• FleetMap: herramienta de gestión de flotas con tarjeta SIM
• Colaboraciones con integradores para las principales plataformas de IoT

Puntos fuertes:

• Precios muy competitivos, a menudo los más bajos para grandes volúmenes
• Cobertura 4G completa, compartición de la red «Crozon» con SFR en zonas poco pobladas
• Ofertas con descuentos progresivos a partir de ~50 tarjetas SIM
• Buen nivel de servicio para pymes y empresas de tamaño medio

Puntos débiles:

• Presencia más limitada en los departamentos y colectividades de ultramar
• Red compartida con SFR en zonas poco pobladas (la misma reserva en cuanto a la conmutación por error)

Precios orientativos:

Objenious / LoRaWAN (Bouygues)​

Para aplicaciones de bajo consumo y bajo caudal (lectura remota de contadores de agua y gas, geolocalización de activos, sensores medioambientales), LoRaWAN es una alternativa a la red móvil:

• Red LoRaWAN nacional que cubre la mayor parte de la población
• Consumo extremadamente bajo: varios años con una sola pila
• Limitación: no es adecuado para vídeo, anchos de banda elevados ni actualizaciones OTA frecuentes

Nota: el ecosistema LoRaWAN está en constante evolución (adquisiciones, reorientaciones de los actores). Comprueba la sostenibilidad de la red y de la oferta comercial antes de comprometerte a largo plazo.

MVNO y operadores especializados en el IoT​

1NCE: la tarjeta SIM «de por vida» con un coste único​

1NCE propone un modelo radical: un pago único de unos 10 $/12 € por 500 MB de datos + 250 SMS válidos durante 10 años, en la red de Deutsche Telekom y sus socios (entre ellos Orange en Francia), con cobertura en más de 170 países. La tarjeta SIM es compatible con 2G, 3G, 4G/LTE-M, NB-IoT y se anuncia como «preparada para 5G».

Para:

• Implementaciones con un consumo muy bajo (sensores, telelectura, seguimiento de activos)
• Presupuesto de gastos operativos (OPEX) prácticamente nulo tras la compra; costes previsibles a lo largo de 10 años
• Túnel OpenVPN incluido, portal y API de gestión
• Versiones Industrial (reforzada) y eSIM/eUICC disponibles (por un ligero sobrecoste)

Contras:

• Límite de 500 MB durante toda la vigencia del contrato: insuficiente para vídeos o actualizaciones OTA frecuentes (recarga de ~12 € por 500 MB)
• Velocidad limitada (hasta 1 Mbit/s)
• No hay una red privada dedicada, como en el caso de los operadores para empresas
• Asistencia principalmente por escrito, salvo en la oferta premium

1NCE es ideal para dispositivos sencillos y básicos. Para la supervisión industrial, el acceso remoto habitual a través de VPN o la transmisión de vídeo, se necesita una oferta de un operador o de varios operadores.

Tele2 IoT / Telenor Connexion​

Operadores europeos especializados en el IoT, con atractivas ofertas en varios países para implementaciones internacionales y una gestión de flotas consolidada.

Arkessa / ZARIOT / Transatel / Onomondo​

Soluciones eUICC / multi-IMSI que permiten cambiar de operador en función de la cobertura, con un núcleo de red unificado — muy adecuadas para implementaciones en varios países y para evitar la dependencia de un único operador (vendor lock-in).

La tarjeta SIM multioperador: la solución para los sectores críticos​

La tarjeta SIM multioperador (multi-IMSI / eUICC) es una tarjeta capaz de conectarse automáticamente al operador que ofrezca la mejor señal en cada ubicación y de cambiar de red en caso de fallo de una de ellas.

¿Cómo funciona?​

Ventajas de la tarjeta SIM multioperador​

Casos de uso ideales: estaciones de bombeo, parques eólicos y solares, explotaciones agrícolas, lectura remota en múltiples emplazamientos, vehículos en movimiento, implementaciones en varios países y cualquier emplazamiento en el que resultara demasiado costoso comprobar la cobertura de cada operador antes de la instalación.

Recordatorio «Crozon»: para que la redundancia sea real, la conmutación debe incluir a Orange (red independiente) y no solo a SFR y Bouygues, que comparten su red en zonas poco densas.

La tarjeta SIM de Eziwan​

La SIM Eziwan es una tarjeta SIM M2M de múltiples operadores incluida en nuestras ofertas:

• Cambio automático entre Orange / SFR / Bouygues según la mejor cobertura
• APN privado seguro (tráfico cifrado entre la pasarela y la nube de Eziwan, centro de datos en Francia)
• Panel de control: RSRP, RSRQ, consumo de datos en tiempo real
• Facturación unificada: un único contrato para toda la flota
• Sin compromiso de volumen mínimo: pide de 1 a 1000 tarjetas SIM
• Compatible con LTE-M y 4G: diseñada para superar el fin de las redes 2G/3G sin interrupciones

APN privado: por qué es esencial en la industria​

El APN privado (Access Point Name) crea una red virtual dedicada entre tus tarjetas SIM y tu infraestructura en la nube, sin pasar por la red pública de Internet.

Ventajas de la red privada APN:

• El tráfico nunca queda expuesto en Internet pública (superficie de ataque reducida)
• Posibilidad de dirección IP fija (la misma IP por SIM, lo que simplifica el acceso remoto)
• Aislamiento total de la red respecto a los demás clientes del operador
• Elemento clave para el cumplimiento de la normativa NIS2 por parte de entidades esenciales e importantes

APN público frente a APN privado:

Disponibilidad: Orange, SFR y Bouygues ofrecen todos APN privados; la tarjeta SIM de Eziwan lo incluye de serie.

Consumo típico de datos por caso de uso​

Calcular el paquete de forma precisa evita pagar de más (o quedarse sin existencias). Órdenes de magnitud observadas:

Optimización mediante el «edge computing»: una pasarela que filtra los datos localmente (banda muerta, agregación, compresión) antes de su transmisión reduce el consumo de 4G entre un 70 % y un 95 %. Una instalación M340 con 30 variables puede pasar de ~150 MB/mes a 15-25 MB/mes — lo que, en 500 emplazamientos, supone pasar de una tarifa de «200 MB» a una de «50 MB» y un ahorro sustancial a nivel de todo el parque.

Itinerancia internacional: aspectos a tener en cuenta​

En el caso de los equipos instalados fuera de Francia:

Unión Europea: atención, las ofertas M2M no se benefician automáticamente del «Roam Like Home», reservado a las tarifas para particulares. El roaming M2M se rige por condiciones contractuales específicas: comprueba siempre las cláusulas M2M de tu operador (volúmenes, duración del roaming permanente autorizada, restricciones del «roaming permanente»).

Fuera de la UE: la facturación por MB puede ser muy elevada (entre 0,5 y 2 €/MB). Para un despliegue internacional, es mejor optar por una SIM local o una SIM global multi-IMSI (Eziwan, Tele2 IoT, Onomondo) que negocia el acceso a las redes país por país.

Roaming permanente: algunos países (y algunos operadores de acogida) limitan o prohíben el roaming permanente de dispositivos fijos. Un despliegue duradero en el extranjero debe basarse en una oferta multi-IMSI o en una tarjeta SIM local, no en un roaming «tolerado».

Tabla comparativa resumida​

★ = valoración orientativa de Eziwan, que debe adaptarse en función de tu ubicación geográfica y tus volúmenes.

Cómo elegir: árbol de decisión rápido​

• Sensores sencillos, consumo muy bajo, presupuesto fijo para 10 años → 1NCE u oferta LTE-M de un operador.
• Parque nacional con múltiples emplazamientos, zonas rurales, alta criticidad → SIM multoperador (Eziwan) con APN privado.
• Grandes volúmenes urbanos, optimización de costes → Bouygues o SFR (pooling).
• Territorios de ultramar, necesidad de cobertura máxima → Orange.
• Despliegue internacional / en varios países → SIM global con varios IMSI (Eziwan, Tele2 IoT, Onomondo).
• Vídeo / acceso remoto frecuente → tarifa de datos generosa de un operador o de varios operadores; sobre todo, nada de una SIM «de por vida» con límite de datos.

En cualquier caso: módulos 4G/LTE-M como mínimo (nunca solo 2G/3G) y APN privado siempre que los datos sean confidenciales.

Preguntas frecuentes — Tarjeta SIM M2M para el IoT industrial​

¿Puedo utilizar una tarjeta SIM de consumo en una pasarela de IoT? Técnicamente sí, pero no es recomendable. Las tarjetas SIM de consumo admiten un rango de temperatura limitado (0-40 °C), tienen una vida útil más corta y no ofrecen APN privado, ni monitorización de flotas, ni SLA industrial. En un parque de dispositivos desplegado sobre el terreno, el sobrecoste de una tarjeta SIM M2M queda ampliamente compensado por la fiabilidad y la gestión centralizada.

¿Seguirán funcionando mis dispositivos 2G o 3G? No, a la larga. Orange cerrará su red 2G entre el 22 de septiembre y el 20 de octubre de 2026; el resto de operadores seguirán sus pasos, y la red 3G dejará de funcionar hacia 2028. Cualquier módulo exclusivamente 2G dejará de funcionar a partir del otoño de 2026; un módulo 2G/3G sin compatibilidad con 4G dejará de funcionar hacia 2028. Para cualquier proyecto nuevo, exige equipos 4G / LTE-M / NB-IoT.

¿Cuál es el consumo mínimo de una tarjeta SIM M2M en modo de espera? Sin tráfico de datos, una tarjeta SIM M2M solo consume las señales de mantenimiento de la red (keep-alive, heartbeat): dependiendo del operador y de la configuración, entre 1 y 10 MB al mes. Con un APN privado y un túnel VPN (OpenVPN/IPSec) mantenido de forma permanente, hay que contar más bien con entre 5 y 15 MB al mes de keep-alive, sin contar los datos de las aplicaciones.

¿Se puede cambiar de operador sin tener que reconfigurarlo todo? Con una tarjeta SIM eUICC (eSIM), sí: el perfil del operador se reconfigura a distancia, sin necesidad de intervención in situ. Con una tarjeta SIM física convencional de un solo operador, hay que cambiar la tarjeta físicamente. La SIM multioperador de Eziwan elimina el problema: una sola SIM gestiona automáticamente las tres redes francesas.

¿Cuál es la diferencia entre LTE-M y NB-IoT? LTE-M ofrece una velocidad de transmisión más alta, una baja latencia y admite la movilidad (objetos en movimiento, posibilidad de transmisión de voz), lo que lo hace adecuado para el seguimiento de activos y la telemetría reactiva. NB-IoT está pensado para objetos estáticos y de muy bajo consumo (contadores en el sótano), con una excelente cobertura, pero con una velocidad de transmisión y una latencia menores. Ambos sobrevivirán al fin de las redes 2G/3G.

¿Cumplen las tarjetas SIM M2M con la normativa francesa? Sí. Las ofertas M2M de los operadores franceses están reguladas por la ARCEP. Las tarjetas SIM de datos IoT no requieren la identificación del usuario final (no se necesita documento de identidad), salvo en el caso de las ofertas que incluyan llamadas de voz o SMS salientes a números de telefonía móvil para particulares.

¿Cómo gestionar 500 tarjetas SIM repartidas en 500 emplazamientos? A través de un portal de gestión de flotas: consumo de datos en tiempo real por tarjeta SIM, detección de tarjetas SIM inactivas o con consumo excesivo, activación/desactivación a distancia, visualización de la señal (RSRP/RSRQ) y alertas por umbrales. El portal de Eziwan integra esta gestión en el mismo panel de control que la supervisión de sus equipos, lo que evita tener que alternar entre varias interfaces.

¿Una tarjeta SIM multioperador es mucho más cara? En general, entre un 10 % y un 20 % más cara que una tarjeta SIM de un solo operador equivalente. En un lugar crítico, este sobrecoste es insignificante comparado con el coste de una interrupción del servicio o de un desplazamiento técnico debido a una zona sin cobertura que no se haya previsto adecuadamente.

Si desea una recomendación personalizada en función de su red y sus zonas geográficas, póngase en contacto con nuestro equipo: realizamos un análisis de cobertura gratuito en sus emplazamientos, operador por operador.

Para profundizar en el tema​

• Blog: conmutación por error LTE con doble SIM — garantizar la conectividad crítica
• Blog: monitorización de RSRP/RSRQ 4G industrial — cómo interpretar las métricas LTE
• Blog: router 4G LTE industrial — migrar desde el ADSL antes de que desaparezca el cobre
• Blog: red privada 5G — casos de uso y ROI para la fábrica
• Blog: comparativa de operadores industriales con doble SIM

Recursos adicionales​

• Conectividad industrial — soluciones de conectividad 4G LTE y M2M para la industria
• Conectividad Eziwan — ofertas de tarjetas SIM M2M y conectividad gestionada para el IoT industrial
• Conexión a Internet para instalaciones industriales aisladas — conectar una instalación sin infraestructura fija a través de 4G/LTE
• Soluciones industriales de Eziwan — gama completa de supervisión y conectividad industrial
• Pasarela de IoT industrial — pasarelas de IoT multoperador con gestión de SIM integrada

¿Por qué Grafana para la supervisión industrial?​

Grafana se ha consolidado en el sector por varias razones:

• Conectores universales: InfluxDB, TimescaleDB, PostgreSQL, Prometheus, MQTT, API REST — una fuente de datos para cada pila tecnológica
• Paneles avanzados: series temporales, indicadores, estadísticas, tablas, mapas de calor, diagramas de flujo (con complementos)
• Alertas integradas: notificaciones por SMS, correo electrónico, Slack, PagerDuty y webhook
• Gestión de accesos: equipos, carpetas y permisos por panel de control
• Complementos industriales: P&ID (diagramas de flujo), diagramas de tuberías y esquemas sinópticos

En comparación con un sistema SCADA tradicional:

Arquitectura: de Modbus a Grafana​

El conjunto completo de herramientas para supervisar controladores Modbus en Grafana:

Alternativa para grandes volúmenes:

Solución Eziwan (todo en uno):

Eziwan integra la pila completa (recogida de datos Modbus/OPC-UA, series temporales en la nube, paneles de Grafana preconfigurados, alertas por SMS/correo electrónico) sin que tengas que instalar ni mantener los componentes por separado.

Instalar Grafana + InfluxDB con Docker​

# docker-compose.yml
version: '3.8'

services:
  influxdb:
    image: influxdb:2.7
    ports:
      - "8086:8086"
    environment:
      DOCKER_INFLUXDB_INIT_MODE: setup
      DOCKER_INFLUXDB_INIT_USERNAME: admin
      DOCKER_INFLUXDB_INIT_PASSWORD: mot_de_passe_securise
      DOCKER_INFLUXDB_INIT_ORG: eziwan
      DOCKER_INFLUXDB_INIT_BUCKET: industrie
      DOCKER_INFLUXDB_INIT_RETENTION: 1825d  # 5 ans
    volumes:
      - influxdb_data:/var/lib/influxdb2

  grafana:
    image: grafana/grafana:10.4.0
    ports:
      - "3000:3000"
    environment:
      GF_SECURITY_ADMIN_PASSWORD: grafana_securise
    volumes:
      - grafana_data:/var/lib/grafana
    depends_on:
      - influxdb

  telegraf:
    image: telegraf:1.29
    volumes:
      - ./telegraf.conf:/etc/telegraf/telegraf.conf:ro
    depends_on:
      - influxdb

volumes:
  influxdb_data:
  grafana_data:

Configuración de Telegraf para MQTT​

# telegraf.conf
[[inputs.mqtt_consumer]]
  servers = ["tcp://localhost:1883"]
  topics = ["usine/#"]
  qos = 1
  data_format = "json"
  
  # Análisis del tema MQTT: fábrica/planta/estación/variable
  [[inputs.mqtt_consumer.topic_parsing]]
    topic = "usine/+/+/+"
    tags = "_/_/station/_"
    fields = "_/_/_/value"

[[outputs.influxdb_v2]]
  urls = ["http://influxdb:8086"]
  token = "votre_token_influxdb"
  organization = "eziwan"
  bucket = "industrie"

Crea tu primer panel de control industrial​

Panel 1: Gráfico de tendencias (series temporales)​

Para visualizar la evolución de la presión de una estación a lo largo del tiempo:

Consulta en InfluxDB (Flux):

from(bucket: "industrie")
  |> range(start: v.timeRangeStart, stop: v.timeRangeStop)
  |> filter(fn: (r) => r["_measurement"] == "mqtt_consumer")
  |> filter(fn: (r) => r["station"] == "station1")
  |> filter(fn: (r) => r["_field"] == "pression")
  |> aggregateWindow(every: v.windowPeriod, fn: mean, createEmpty: false)
  |> yield(name: "mean")

Panel de parámetros:

• Tipo: Time series
• Unidad del eje Y: bar (Presión)
• Ancho de línea: 2
• Opacidad de relleno: 10
• Umbrales: verde < 8 bar, naranja 8-10 bar, rojo > 10 bar

Panel 2: Indicador (valor instantáneo)​

Para mostrar el valor actual de una variable:

Consulta de InfluxDB:

from(bucket: "industrie")
  |> range(start: -1m)
  |> filter(fn: (r) => r["station"] == "station1" and r["_field"] == "pression")
  |> last()

Panel de parámetros:

• Tipo: Gauge
• Mín.: 0, Máx.: 16
• Unidad: bar
• Umbrales: 0 = verde, 10 = naranja, 12 = rojo

Panel 3: Estadísticas (KPI)​

Para visualizar el TRS o un contador de producción:

Consulta de InfluxDB:

from(bucket: "industrie")
  |> range(start: -24h)
  |> filter(fn: (r) => r["_field"] == "pieces_produites")
  |> sum()

Panel de parámetros:

• Tipo: Stat
• Unidad: pcs (personalizada)
• Modo de color: Background (rojo si es < el objetivo)

Panel 4: Tabla multisitio​

Para ver el estado de todas tus páginas web en tiempo real:

from(bucket: "industrie")
  |> range(start: -5m)
  |> filter(fn: (r) => r["_field"] == "pression" or r["_field"] == "debit" or r["_field"] == "etat")
  |> last()
  |> pivot(rowKey: ["_time", "station"], columnKey: ["_field"], valueColumn: "_value")

Resultado: tabla con las columnas «Estación», «Presión», «Caudal» y «Estado», con una fila por emplazamiento.

Configurar las alertas de Grafana​

Alerta por superación del umbral​

En Grafana 10+ (Unified Alerting):

1. Abrir el panel → Edit → Alert
2. Crear una regla:

   Condition: WHEN last() OF query(A, 5m, now) IS ABOVE 10
   

3. Configurar la notificación:
   • Punto de contacto: Correo electrónico → maintenance@usine.fr
   • Punto de contacto: Webhook → SMS a través de Twilio/OVH SMS
4. Silenciamiento automático: 15 minutos tras la confirmación

Agrupación de alertas para sitios múltiples​

Para evitar las «tormentas de alertas» cuando varios sitios web dejan de funcionar al mismo tiempo:

# alertmanager.yml
route:
  group_by: ['alertname', 'site']
  group_wait: 30s
  group_interval: 5m
  repeat_interval: 3h
  receiver: 'maintenance-team'

receivers:
  - name: 'maintenance-team'
    email_configs:
      - to: 'maintenance@usine.fr'
        send_resolved: true
    webhook_configs:
      - url: 'https://api.sms-provider.fr/send'

Anotaciones sobre eventos​

Añadir anotaciones automáticas a los gráficos cuando se activen las alarmas:

// Crear una anotación de InfluxDB cuando se produce un fallo
from(bucket: "industrie")
  |> range(start: v.timeRangeStart)
  |> filter(fn: (r) => r["_field"] == "defaut" and r["_value"] == 1)
  |> map(fn: (r) => ({r with _value: "Défaut détecté sur ${r.station}"}))

Plantillas y variables de Grafana para sitios múltiples​

Las variables de plantilla permiten crear un panel de control genérico que se puede reutilizar en todos tus sitios web.

Crear una variable «site»​

Dashboard Settings → Variables → New Variable:

• Nombre: site
• Tipo: Query
• Fuente de datos: InfluxDB
• Consulta:

  import "influxdata/influxdb/schema"
  schema.tagValues(bucket: "industrie", tag: "station")
  

Utilizar la variable en los paneles​

from(bucket: "industrie")
  |> range(start: v.timeRangeStart)
  |> filter(fn: (r) => r["station"] == "${site}")
  |> filter(fn: (r) => r["_field"] == "pression")

Ahora el operador puede seleccionar la ubicación en un menú desplegable situado en la parte superior del panel de control.

Paneles de control preconfigurados de Grafana para la industria​

Panel de control de la estación de bombeo​

┌─────────────────────────────────────────────────────────────────┐
│  Estación: [menú desplegable]  │  Período: [6 h|24 h|7 días|30 días] │
├──────────────┬──────────────┬──────────────┬────────────────────┤
│  Presión    │   Caudal │  Nivel │  Estado de la bomba │
│  [gauge]     │   [gauge]    │  [gauge]     │  [stat 🟢/🔴]      │
├──────────────┴──────────────┴──────────────┴────────────────────┤
│  Tendencias en las últimas 24 horas: Presión / Caudal / Nivel │
│  [time series graph]                                             │
├─────────────────────────────────────────────────────────────────┤
│  Alarmas activas    │  Últimas intervenciones │
│  [table]            │  [table annotations]                       │
└─────────────────────────────────────────────────────────────────┘

Panel de control de producción multisitio​

┌────────────────────────────────────────────────────────────────────┐
│  Vue globale — 15 sites                                            │
├──────────┬──────────┬──────────┬──────────┬──────────┬────────────┤
│ Site 1   │ Site 2   │ Site 3   │ Site 4   │ Site 5   │ ...        │
│ TRS: 87% │ TRS: 91% │ TRS: 73% │ TRS: 94% │ TRS: 82% │            │
│ 🟢 OK    │ 🟢 OK    │ 🔴 Alrm  │ 🟢 OK    │ 🟡 Warn  │            │
├──────────┴──────────┴──────────┴──────────┴──────────┴────────────┤
│  Producción acumulada en 24 horas: objetivo frente a real [gráfico de barras] │
└────────────────────────────────────────────────────────────────────┘

Integración de Eziwan con Grafana​

Eziwan ofrece dos formas de integración con Grafana:

Modo 1: Grafana alojado en Eziwan (recomendado)​

La plataforma Eziwan integra Grafana de forma nativa. Tus datos Modbus/OPC-UA ya se encuentran en nuestra base de datos de series temporales alojada en Francia. Puedes acceder directamente a los paneles de control desde tu navegador, con:

• Paneles de control preconfigurados para los casos de uso más habituales (agua, energía, producción)
• Alertas por SMS/correo electrónico gestionadas
• Historial de 5 años sin necesidad de configuración
• Multisede, multiusuario y gestión de permisos

Modo 2: Exportación a tu Grafana ya existente​

Si ya dispone de un Grafana interno:

• API REST de Eziwan: consulte sus datos a través de GET /api/v1/variables/{id}/history
• Webhook MQTT: Eziwan publica tus datos en tu broker MQTT existente
• Complemento de Grafana para Eziwan (disponible bajo petición): complemento de fuente de datos para conexión directa

Preguntas frecuentes — Grafana para la supervisión industrial​

¿Puede Grafana sustituir a un sistema SCADA en producción? En cuanto a la visualización y las alertas, sí, en muchos casos. Para el control en tiempo real (escritura en el controlador lógico programable, secuencias de comandos), se sigue recomendando un sistema SCADA o un sistema HMI específico. Grafana destaca en el registro histórico, el análisis de tendencias y la supervisión de múltiples emplazamientos.

¿Qué base de datos se debe utilizar para almacenar datos industriales en Grafana? InfluxDB es la opción estándar para las series temporales industriales (alta frecuencia, compresión nativa, potentes consultas Flux). TimescaleDB (una extensión de PostgreSQL) es adecuada si ya dispones de PostgreSQL. Prometheus es adecuado para métricas de infraestructura, pero menos relevante para datos de procesos.

¿Cómo proteger el acceso a Grafana desde Internet? Colocar Grafana detrás de un proxy inverso (Nginx/Traefik) con TLS, activar la autenticación OIDC/LDAP, desactivar el acceso anónimo y configurar alertas ante intentos fallidos de conexión. Nunca exponer InfluxDB directamente a Internet.

¿Puede Grafana gestionar 1 000 sitios y 100 000 variables? Sí, con la arquitectura adecuada. InfluxDB 2.x admite miles de millones de puntos. Grafana Enterprise gestiona la agrupación en clústeres. Para volúmenes muy grandes, se recomienda utilizar Apache Kafka en una fase previa para el streaming, así como políticas de retención diferenciadas (datos de 1 s conservados durante 30 días, datos de 1 min conservados durante 5 años).

¿Puedo tener un esquema P&ID en Grafana? Sí, con el complemento Flowcharting (basado en draw.io). Dibuja tu esquema P&ID, asigna variables de Grafana a cada equipo y los valores se mostrarán en tiempo real en el esquema sinóptico, cambiando de color según el estado.

Para profundizar en el tema​

• Blog: mantenimiento predictivo IIoT — de los datos de los sensores a las alertas sobre el terreno
• Blog: supervisión industrial a distancia — guía completa 2026
• Blog: Modbus TCP frente a RTU — ¿qué protocolo elegir?
• Blog: parque fotovoltaico — supervisión y monitorización IoT
• Documentación: configuración de Modbus RTU en la pasarela Eziwan

¿Te apetece tener paneles de Grafana sin tener que gestionar la infraestructura? Prueba Eziwan gratis durante 30 días: tus datos Modbus en Grafana en menos de una hora.

Recursos adicionales​

• Modbus RTU a la nube — conecta tus equipos RS-485 Modbus RTU a la nube
• Registrador de datos industrial en la nube — historización de tus datos Modbus en la nube
• SCADA en la nube — plataforma SCADA en la nube con paneles de control integrados
• Protocolos industriales — comprender Modbus, MQTT, OPC UA y otros protocolos
• Supervisión y teleasistencia industrial — supervisión multisitio de sus equipos Modbus

¿Qué es OPC-UA y por qué es importante?​

OPC-UA (IEC 62541) es un protocolo de comunicación independiente de la plataforma, diseñado para el intercambio seguro de datos industriales. A diferencia de su predecesor, OPC-DA (solo para Windows, DCOM), OPC-UA funciona en cualquier sistema operativo (Linux, Windows, RTOS embebidos) y en cualquier red (Ethernet, 4G, Wi-Fi).

¿Por qué OPC-UA domina la Industria 4.0?​

• Interoperabilidad: cualquier cliente compatible puede leer un servidor Siemens S7-1500 OPC-UA sin necesidad de un controlador propietario
• Modelo de información: los datos tienen un significado (unidad, descripción, historial), no solo un valor
• Seguridad nativa: cifrado, autenticación y certificados, integrados en el protocolo
• Perfiles de conformidad: un subconjunto ligero para pequeños equipos embebidos
• Pubsub y MQTT: extensión Pub/Sub de OPC-UA para arquitecturas en la nube (IEC 62541-14)

Arquitectura OPC-UA: conceptos fundamentales​

Cliente-servidor​

El modelo básico de OPC-UA es cliente-servidor:

• Servidor OPC-UA: proporcionado por el equipo (PLC, HMI, servidor de datos)
• Cliente OPC-UA: consume los datos (SCADA, pasarela, aplicación en la nube)

Un mismo equipo puede actuar como servidor y como cliente al mismo tiempo (por ejemplo, una pasarela que agrupa varios PLC y muestra los datos consolidados).

Espacio de direcciones y NodeId​

El Address Space es el árbol de información que expone un servidor OPC-UA. Cada nodo tiene un NodeId único:

Formato NodeId:

• ns=2;i=1234 — espacio de nombres 2, identificador entero 1234
• ns=2;s=Station_1.Pression — espacio de nombres 2, identificador de cadena
• ns=0;i=2258 — espacio de nombres 0 (estándar), ServerStatus

Espacios de nombres:

• ns=0: espacio de nombres estándar de OPC-UA (tipos, métodos)
• ns=1: suele ser el espacio de nombres del fabricante
• ns=2+: espacios de nombres de aplicación (tus datos)

Formas de comunicación​

Las suscripciones son el enfoque adecuado para la supervisión en tiempo real: en lugar de realizar consultas cada segundo, el cliente se suscribe a un nodo y recibe una notificación únicamente cuando el valor cambia por encima de un umbral configurable (DeadbandValue).

Seguridad en OPC-UA: la guía completa​

La seguridad es uno de los puntos fuertes de OPC-UA, y también una de las fuentes de complejidad. A continuación se presentan los conceptos fundamentales.

Modos de seguridad​

Certificados X.509​

OPC-UA utiliza certificados X.509 para la autenticación mutua entre cliente y servidor:

Creación de un certificado autofirmado para pruebas:

# Avec OpenSSL
openssl req -x509 -nodes -days 3650 -newkey rsa:2048 \
  -keyout client_key.pem -out client_cert.pem \
  -subj "/CN=EziwanGateway/O=Eziwan/C=FR" \
  -extensions v3_req \
  -config <(cat /etc/ssl/openssl.cnf; echo "[v3_req]"; echo "subjectAltName=URI:urn:eziwan:gateway:client")

En producción: utilizar una PKI interna o una CA reconocida. Los certificados deben intercambiarse manualmente entre el cliente y el servidor la primera vez.

Autenticación de usuario​

Además de los certificados de máquina, OPC-UA gestiona la autenticación de usuario:

• Anónimo: sin autenticación (si lo permite el servidor)
• Nombre de usuario/Contraseña: inicio de sesión en la aplicación
• Certificado: certificado de usuario X.509
• IssuedToken: token JWT o Kerberos

Implementación de OPC-UA en Python​

La biblioteca python-opcua (o su bifurcación asyncua) es la referencia en Python.

Instalación​

pip install asyncua

Cliente OPC-UA en Python: lectura de datos​

import asyncio
from asyncua import Client

async def main():
    url = "opc.tcp://192.168.1.10:4840/freeopcua/server/"
    
    async with Client(url=url) as client:
        # Leer un nodo por NodeId
        node = client.get_node("ns=2;s=Station_1.Pression")
        value = await node.read_value()
        print(f"Pression: {value} bar")
        
        # Leer varios nodos por lotes
        nodes = [
            client.get_node("ns=2;s=Station_1.Pression"),
            client.get_node("ns=2;s=Station_1.Debit"),
            client.get_node("ns=2;s=Station_1.Defaut"),
        ]
        values = await client.read_values(nodes)
        for node, val in zip(nodes, values):
            print(f"  {node}: {val}")

asyncio.run(main())

Cliente OPC-UA para Python — suscripción (Subscription)​

import asyncio
from asyncua import Client
from asyncua.common.subscription import SubHandler

class DataChangeHandler(SubHandler):
    def datachange_notification(self, node, val, data):
        print(f"[CHANGE] {node} = {val}")
    
    def event_notification(self, event):
        print(f"[EVENT] {event}")

async def main():
    url = "opc.tcp://192.168.1.10:4840"
    
    async with Client(url=url) as client:
        handler = DataChangeHandler()
        subscription = await client.create_subscription(500, handler)  # 500ms
        
        nodes = [
            client.get_node("ns=2;s=Station_1.Pression"),
            client.get_node("ns=2;s=Station_1.Debit"),
        ]
        
        monitored_items = await subscription.subscribe_data_change(nodes)
        print("Subscriptions actives, attente changements...")
        
        await asyncio.sleep(30)  # escuchar 30 segundos
        await subscription.unsubscribe(monitored_items)

asyncio.run(main())

Conexión segura con certificado​

from asyncua.crypto.security_policies import SecurityPolicyBasic256Sha256
from asyncua.crypto.cert_man import CertificateManager

async def connect_secure():
    client = Client("opc.tcp://192.168.1.10:4840")
    
    await client.set_security(
        SecurityPolicyBasic256Sha256,
        certificate="./client_cert.der",
        private_key="./client_key.pem",
        server_certificate="./server_cert.der"
    )
    
    await client.connect()
    # ... vuestras operaciones
    await client.disconnect()

Implementar OPC-UA en Node.js​

La biblioteca node-opcua es la referencia en JavaScript/TypeScript.

npm install node-opcua

Lectura de datos​

const opcua = require("node-opcua");

const client = opcua.OPCUAClient.create({
    endpointMustExist: false,
    connectionStrategy: { maxRetry: 5, initialDelay: 2000 }
});

const endpointUrl = "opc.tcp://192.168.1.10:4840";

async function main() {
    await client.connect(endpointUrl);
    const session = await client.createSession();
    
    const nodeToRead = {
        nodeId: "ns=2;s=Station_1.Pression",
        attributeId: opcua.AttributeIds.Value
    };
    
    const dataValue = await session.read(nodeToRead);
    console.log(`Pression: ${dataValue.value.value} bar`);
    console.log(`Timestamp: ${dataValue.serverTimestamp}`);
    
    await session.close();
    await client.disconnect();
}

main().catch(console.error);

OPC-UA en los principales controladores lógicos programables​

Siemens S7-1500 / S7-1200​

El S7-1500 es compatible con el servidor OPC-UA nativo a partir de la versión 2.0 del firmware:

• Puerto: 4840 (TCP)
• Configuración en TIA Portal: Device Configuration → OPC UA → Server
• Activar los nodos deseados en la configuración de acceso
• Autenticación: certificados o nombre de usuario/contraseña

El S7-1200 es compatible con OPC-UA a partir de la versión 4.1 del firmware.

Schneider Electric M580 / M340​

M580: OPC-UA a través del módulo BMENOC0311 (firmware ≥ V2.0) M340: no admite OPC-UA de forma nativa → Se recomienda Modbus TCP o una pasarela de OPC-UA a Modbus (p. ej., Kepware KEPServerEX)

Allen-Bradley / Rockwell (EtherNet/IP)​

Los controladores Rockwell no son compatibles de forma nativa con OPC-UA. Opciones:

• KEPServerEX (Kepware): puente EtherNet/IP → OPC-UA
• FactoryTalk Linx Gateway: servidor OPC-UA para el ecosistema Rockwell
• Eziwan Gateway: conexión directa EtherNet/IP/Modbus, exposición a la API REST

Beckhoff TwinCAT 3​

TwinCAT 3 integra un servidor OPC-UA nativo a través de TF6100 (módulo OPC-UA). La configuración se realiza mediante TwinCAT System Manager.

Wago / Phoenix Contact / Pilz​

La mayoría de los PLC modernos de estos fabricantes son compatibles con OPC-UA. Comprueba el firmware y activa el servidor en la configuración de red.

OPC-UA PubSub: la extensión para la nube​

OPC-UA PubSub (IEC 62541-14) es la extensión que hace que OPC-UA sea compatible con las arquitecturas de IoT en la nube:

• Editor: el equipo publica sus datos en un middleware orientado a mensajes
• Suscriptor: la nube o el sistema SCADA se suscribe al flujo

Protocolos compatibles:

• AMQP (puerto 5672)
• MQTT (puerto 1883 u 8883) — el más utilizado en el IoT
• UDP Multicast (red local)

Formatos de codificación:

• JSON (legible, fácil de depurar)
• UADP (binario, compacto, integrado)

Ejemplo de mensaje OPC-UA PubSub en formato JSON:

{
  "MessageId": "abc123",
  "PublisherId": "urn:station1:plc",
  "DataSetWriterId": 1,
  "MetaDataVersion": {"MajorVersion": 1, "MinorVersion": 0},
  "Timestamp": "2026-08-14T10:30:00.000Z",
  "Payload": {
    "Station_1.Pression": {"Value": 4.2, "StatusCode": 0, "SourceTimestamp": "2026-08-14T10:29:59.950Z"},
    "Station_1.Debit": {"Value": 125.3, "StatusCode": 0, "SourceTimestamp": "2026-08-14T10:29:59.950Z"}
  }
}

Migración de OPC-DA a OPC-UA​

Si dispone de instalaciones bajo OPC-DA (OPC Classic, Windows DCOM), la migración a OPC-UA ofrece:

• Eliminación de la dependencia de Windows/DCOM
• Compatibilidad con Linux, Raspberry Pi y PLC con Linux
• Cifrado (ausente en OPC-DA)
• Acceso directo a Internet (imposible con DCOM sin una VPN compleja)

Herramienta de migración: OPC UA Wrapper (p. ej., Kepware) crea un servidor OPC-UA que expone los datos de un servidor OPC-DA ya existente, lo que permite una migración progresiva.

OPC-UA con el Gateway Eziwan​

El Eziwan Gateway incorpora un cliente OPC-UA capaz de conectarse a los servidores OPC-UA de tus equipos:

• Conexión Siemens S7-1500 OPC-UA (puerto 4840)
• Conexión a cualquier servidor OPC-UA conforme a la norma IEC 62541
• Compatibilidad con los modos de seguridad None, Sign y SignAndEncrypt
• Configuración de los NodeIds en la interfaz en la nube (búsqueda automática del espacio de direcciones)
• Transmisión de datos a la plataforma en la nube Eziwan mediante MQTT/TLS

Ventaja clave: no es necesario que desarrolles tú mismo un cliente OPC-UA. La pasarela se encarga de ello y ofrece una API REST para tu sistema SCADA o ERP.

Preguntas frecuentes — OPC-UA​

¿Es OPC-UA más complejo que Modbus? Sí, pero está justificado en instalaciones con equipos de distintos fabricantes y en proyectos de Industria 4.0. Para una instalación con 2 o 3 controladores del mismo fabricante, Modbus TCP puede ser suficiente. OPC-UA resulta imprescindible cuando se dispone de equipos heterogéneos, se tienen requisitos de seguridad o se necesitan interoperabilidad entre ERP y MES.

¿Debo abrir el puerto 4840 en mi cortafuegos? En una arquitectura «zero-inbound-port» (como Eziwan), la pasarela inicia la conexión con el servidor OPC-UA de forma interna. No hay ningún puerto abierto desde el exterior. El túnel VPN cifrado transporta los datos a la nube.

¿Puede OPC-UA sustituir a MQTT en una arquitectura de IoT? OPC-UA PubSub con transporte MQTT combina lo mejor de ambos: el modelo de información semántica de OPC-UA con la ligereza y la escalabilidad de MQTT. Esta es la dirección que marcan los marcos de referencia de la Industria 4.0 (Industrie 4.0 Architecture Reference Model, IDS-R).

¿Qué rendimiento cabe esperar de un servidor OPC-UA integrado? Una CPU 1515 del Siemens S7-1500 puede procesar unos 10 000 nodos OPC-UA en lectura por segundo. En el caso de los PLC menos potentes (M221, WAGO pequeños), se recomienda limitar el sondeo OPC-UA a entre 100 y 500 nodos por segundo. Las suscripciones (Subscription) son mucho más eficaces que el sondeo cuando se trata de grandes volúmenes.

¿Existen servidores OPC-UA gratuitos para realizar pruebas? Sí: ProsysOPC UA Simulation Server (gratuito, Windows), Node-RED con node-red-contrib-opcua (gratuito, multiplataforma), python-opcua en modo servidor (ejemplo en la documentación de GitHub). Permiten probar un cliente sin necesidad de disponer de un PLC físico.

Para profundizar en el tema​

• Blog: OPC-UA y MQTT — cómo combinar ambos en una pasarela industrial
• Blog: acceso remoto seguro a PLC y SCADA — VPN, «zero-trust» y NIS2
• Blog: cómo conectar un controlador Siemens S7 a la nube — guía técnica
• Blog: IEC 62443 — guía práctica para la ciberseguridad industrial
• Blog: Modbus TCP frente a RTU — comparativa completa para el IoT industrial

¿Necesitas ayuda para conectar tus servidores OPC-UA a la nube? Solicita una demostración gratuita: nuestro equipo te acompañará desde la prueba de concepto hasta la implementación.

Recursos adicionales​

• OPC UA a MQTT — publicar datos OPC UA en un broker MQTT en la nube
• Protocolos industriales — comparación entre OPC UA, Modbus, MQTT y otros protocolos
• Pasarela IoT industrial — cómo elegir una pasarela compatible con OPC UA
• Modbus TCP a la nube — supervisión de controladores lógicos Modbus TCP desde la nube
• SCADA en la nube — arquitectura SCADA moderna con conectividad OPC UA y a la nube

¿Por qué conectar tu M340/M221 a la nube?​

Los controladores Schneider Electric de la gama Modicon están presentes en miles de instalaciones industriales francesas: tratamiento de aguas, estaciones de bombeo, procesos agroalimentarios, líneas de envasado. Robustos y fiables, suelen tener una vida útil de entre 15 y 20 años.

Sin embargo, sus capacidades de comunicación nativas son limitadas:

• No hay conectividad nativa en la nube
• El acceso remoto suele estar limitado a una costosa VPN MPLS
• No hay registro de datos a largo plazo sin un servidor SCADA local
• Las alertas son inexistentes o solo locales (luces indicadoras, sirenas)

La solución: una pasarela IoT industrial que lee los datos Modbus de tu M340/M221 y los envía a la nube, sin modificar el programa del controlador lógico programable.

Compatibilidad con Modbus de los controladores lógicos programables de Schneider Electric​

Modicon M221​

El M221 (TM221CE16R, TM221CE24T, etc.) incorpora un puerto Modbus RTU de forma nativa en su conector RJ45 (RS-485 mediante el adaptador TM3TI4 o un cable específico) y un puerto Modbus TCP en su puerto Ethernet.

Registros accesibles:

• %MW0 a %MW255: palabras de memoria
• %QW: salidas analógicas
• %IW: entradas analógicas
• %M: bits de memoria (bobinas 0-255)

Configuración del esclavo Modbus en el M221:

En EcoStruxure Machine Expert - Basic:

1. Configuration → Modbus Serial o Modbus TCP
2. Dirección de esclavo: 1 (por defecto)
3. Activar «Slave function» → OK

Modicon M340​

El M340 (BMX P34 2020, BMX P34 2030, etc.) cuenta con un puerto serie Modbus RTU (RS-485, conector SUB-D de 9 pines) y un módulo ETH (BMX NOE 0100 o BMX NOC 0401) para Modbus TCP.

Registros accesibles a través de Modbus:

Dirección Modbus → dirección Unity Pro:

• Registro 400001 = %MW0
• Registro 400100 = %MW99
• Registro 400501 = %MW500

Modicon M580 (ePAC)​

El M580 dispone de Modbus TCP nativo en su puerto Ethernet CPU y admite las mismas tablas de registros que el M340, además de:

• Acceso a los módulos de E/S a través de BMENOC0311 (módulo Ethernet)
• Compatibilidad con EtherNet/IP
• Capacidad de intercambio de datos con EcoStruxure Plant

Arquitectura de conexión​

Opción 1: A través de Modbus TCP (Ethernet) — recomendada​

Requisitos previos:

• Módulo ETH instalado en el rack (BMX NOE 0100 para M340)
• Dirección IP del autómata configurada (p. ej., 192.168.1.10)
• Cortafuegos interno que permita el puerto 502 desde la IP de la pasarela

Ventajas:

• No requiere cableado RS-485 adicional
• Mayor velocidad de transmisión (hasta 30 consultas por segundo)
• Compatibilidad con Traffic Unity Pro (lecturas no intrusivas)

Opción 2: A través de Modbus RTU (RS-485)​

Para el M221: utilice el cable TCSMCNAM3M002P (RJ45 a RS-485) o el adaptador VW3A8306, según la gama.

Para el M340: conector SUB-D de 9 pines en el lado del PLC, bornes 3 (+) y 8 (-) para RS-485.

Parámetros serie M221/M340 (por defecto):

• Velocidad: 19 200 bps
• Paridad: ninguna (8N1)
• Dirección de esclavo: 1

Configuración de la pasarela Eziwan para Schneider​

Una vez conectada la pasarela, la configuración se realiza desde la interfaz en la nube de Eziwan con solo unos clics.

Añadir un dispositivo Modbus​

1. Accede a Flotte → Site → + Équipement
2. Selecciona Modbus TCP o Modbus RTU
3. Introducir:
   • IP: 192.168.1.10 (o la dirección de su M340)
   • Puerto: 502
   • ID de esclavo: 1

Configurar las variables que se van a leer​

Ingeniería de conversión: aplicar un factor multiplicador si el controlador devuelve un valor bruto (p. ej., ×0.01 para pasar de 1500 a 15,00 bar).

Periodo de sondeo recomendado​

Lo que obtienes en la nube​

Panel de control en tiempo real​

Desde la primera conexión de la pasarela, los datos se transmiten en tiempo real al panel de control de Eziwan:

• Curvas de tendencia en 1 h, 24 h, 7 días y 30 días
• Medidores e indicadores configurables
• Tablas multisitio para comparar tus instalaciones
• Exportación a CSV/Excel para la elaboración de informes

Sistema de alertas​

Configura alertas precisas para cada variable:

Alerta: Nivel del depósito
  Condition : %MW10 < 10 (niveau bas)
  Canal : SMS + Email
  Destinatarios: equipe@maintenance.fr, astreinte@maintenance.fr
  Acquittement : requis

Alerta: Fallo de la bomba
  Condición: %M5 = 1 (bit de fallo activo)
  Canal: SMS inmediato
  Prioridad: Crítica

Historización a largo plazo​

Todos los datos se archivan durante 5 años de forma estándar, sin coste adicional. Puedes:

• Consultar los historiales de producción de los años N-1 y N-2
• Identificar deterioros progresivos (por ejemplo, una bomba que consume más corriente)
• Generar informes de conformidad (agua, energía, sector farmacéutico)

Caso práctico: estación de bombeo M340​

Contexto: una entidad local gestiona 12 estaciones de bombeo equipadas con M340 BMX P34 2020. Mantenimiento actual: 3 rondas sobre el terreno a la semana, 2 técnicos.

Configuración implementada:

• 12 × Eziwan Gateway (Modbus TCP, SIM de SFR Business)
• Variables leídas por estación: nivel del pozo, caudal, presión de impulsión, corriente del motor, horas de funcionamiento, fallos (12 variables)
• Interrogación: 5 s para caudal/presión/fallos, 1 min para nivel/contadores

Resultados tras 6 meses:

• Rondas de inspección sobre el terreno: 3/semana → 1/semana (-67 %)
• Incidentes detectados antes de una parada: 4 (sobrecalentamiento de la bomba, válvula atascada, flotador atascado)
• Ahorro calculado: 41 000 € al año (gastos de desplazamiento + mantenimiento correctivo evitado)
• Retorno de la inversión en material y suscripción: 5 meses

Migración desde SoMachine / Unity Pro​

Si utilizas SoMachine (M221) o Unity Pro (M340/M580), no es necesario realizar ninguna modificación en el programa del PLC. La pasarela Eziwan se conecta en modo solo lectura de forma predeterminada.

Si también desea escribir instrucciones (puntos de consigna, comandos) desde la nube:

• Utilice los códigos de función FC05 (Write Single Coil) y FC06 (Write Single Register)
• Configura los derechos de acceso en la pasarela Eziwan (autenticación multifactorial)
• Crea rangos de registros específicos para los mandos a distancia (p. ej., %MW200-MW220)

Compatibilidad con EcoStruxure​

La pasarela Eziwan es compatible con EcoStruxure de varias maneras:

En paralelo a EcoStruxure Plant​

La pasarela lee los mismos registros que tu SCADA EcoStruxure, sin interferencias. Ideal para añadir:

• Supervisión centralizada de múltiples emplazamientos
• Acceso móvil para los técnicos de campo
• Alertas por SMS/correo electrónico (que a menudo no están disponibles en la versión básica de EcoStruxure)

Sustitución progresiva​

Si su licencia de EcoStruxure Plant está a punto de caducar, puede realizar la migración de forma progresiva:

1. Implementar la pasarela Eziwan en paralelo
2. Validar los datos durante 4-8 semanas
3. Trasladar la supervisión principal a Eziwan
4. Reducir la licencia de EcoStruxure al ámbito realmente necesario

Comparativa de conexión en la nube: M221, M340 y M580​

Preguntas frecuentes — Conexión del M340/M221 a la nube​

¿Hay que modificar el programa SoMachine/Unity Pro? No. La pasarela Eziwan se conecta como maestro Modbus al controlador esclavo. No se añade ninguna línea de código al PLC. Si el controlador ya está configurado como esclavo Modbus (lo cual es el caso por defecto), la conexión es inmediata.

Mi M340 ya tiene un SCADA Unity Pro, ¿es compatible? Sí. Varios maestros Modbus TCP pueden consultar al mismo esclavo simultáneamente. La pasarela Eziwan y su SCADA coexisten sin problemas, siempre que se configure una frecuencia de sondeo razonable (≥ 1 s).

¿Puedo supervisar módulos de entradas analógicas (BMX AMI 0410)? Sí. Los módulos analógicos se especifican en las tablas %IW (entradas) y %QW (salidas). Consulta la documentación de Unity Pro para conocer la asignación de registros de tus módulos específicos.

¿Funciona la pasarela si se interrumpe la red 4G? Sí. La pasarela Eziwan incorpora una tarjeta SD con memoria intermedia: los datos se siguen recopilando localmente y se transmiten en bloque en cuanto se restablece la conectividad (store-and-forward). Las alertas locales (SMS directo) siguen funcionando sin necesidad de la nube.

¿Es compatible con la gama Zelio Logic? El Zelio Logic Smart Relay admite Modbus RTU de forma limitada. Dependiendo del modelo (SR2/SR3), el acceso a los registros internos puede estar restringido. Ponte en contacto con nosotros para que comprobemos la compatibilidad con tu modelo concreto.

Cómo poner en marcha tu POC​

¿Tienes un M340, un M221 o un M580 en tus instalaciones y quieres comprobar la conexión a la nube?

Eziwan ofrece una prueba gratuita de 30 días que incluye:

• 1 puerta de enlace preconfigurada, enviada en un plazo de 48 horas
• Puesta en marcha guiada por nuestro equipo técnico
• Cuadros de mando configurados según tus parámetros
• Sin compromiso, sin tarjeta de crédito

Iniciar la prueba de concepto gratuita → | Calcular tu ROI →

Para profundizar en el tema​

• Blog: cómo conectar un controlador lógico Siemens S7 a la nube — guía técnica
• Blog: acceso remoto seguro a PLC y SCADA — VPN y NIS2
• Blog: Modbus TCP frente a RTU — ¿qué protocolo elegir?
• Documentación: compatibilidad entre Siemens S7-1200 y S7-1500
• Blog: mantenimiento predictivo en el IIoT — de los datos del sensor a la alerta

¿Utiliza otras gamas de Schneider Electric (Altivar, Easergy, PowerLogic)? Póngase en contacto con nosotros para comprobar la compatibilidad con su equipo específico.

Recursos adicionales​

• Acceso remoto a los controladores Schneider — acceso remoto seguro a los controladores Schneider M340, M221 y M580
• Conectar un controlador a la nube — conectar cualquier controlador industrial a la nube
• Modbus TCP a la nube — supervisión a través de Modbus TCP desde la nube
• Acceso remoto industrial — arquitectura VPN y de confianza cero para instalaciones industriales
• Supervisión y teleasistencia industrial — supervisión centralizada de sus controladores Schneider

Esta guía compara las cuatro principales tecnologías inalámbricas utilizadas en el IoT industrial en Francia, con recomendaciones concretas para cada caso de uso.

Resumen: 4 tecnologías para 4 necesidades diferentes​

Antes de entrar en detalles, aquí tienes lo esencial en una frase por tecnología:

• LoRaWAN: para sensores de bajo consumo alimentados por batería, en entornos abiertos y a grandes distancias (de 1 a 15 km)
• Zigbee: para redes densas de sensores en interiores, con estructura en malla (mesh), a corta distancia (de 10 a 100 m)
• 4G LTE: para emplazamientos aislados, equipos críticos, conexiones WAN de larga distancia y banda ancha
• Wi-Fi: para emplazamientos con infraestructura de red existente, equipos móviles en zonas con cobertura y banda ancha local

Comparativa técnica detallada​

LoRaWAN en detalle​

Cuándo utilizarlo​

LoRaWAN es ideal para situaciones en las que se necesitan distancias muy largas y un consumo muy bajo, pero en las que el caudal de datos es reducido (unos pocos bytes por mensaje cada minuto o cada hora).

Casos de uso industriales ideales para LoRa:

• Lectura de contadores de agua, gas y electricidad en entornos urbanos o periurbanos
• Monitorización de condiciones ambientales en grandes superficies (temperatura, humedad y CO₂ en varios edificios)
• Seguimiento de activos con sensores GPS y de movimiento de larga duración (palés, depósitos móviles)
• Vigilancia de sensores en zonas de difícil acceso (alcantarillado, infraestructuras subterráneas, zonas rurales)
• Detección de apertura/cierre (trampillas, puertas de silos) en amplios perímetros

Ventajas de LoRaWAN:

• Autonomía excepcional de la batería (de 5 a 10 años con una pila AA)
• Infraestructura muy sencilla: un concentrador LoRa cubre un radio de entre 5 y 15 km en zonas rurales
• Redes públicas disponibles en Francia (Bouygues Telecom LoRa, Objenious, Sewan, CityMesh)
• Coste por nodo muy reducido (entre 10 y 50 € por un sensor sencillo)

Limitaciones de LoRaWAN:

• Ancho de banda muy reducido: no es posible enviar imágenes, secuencias de vídeo ni más de unos pocos bytes por mensaje
• Alta latencia: el enlace descendente (nube → sensor) puede tardar entre 5 y 10 segundos, lo que no resulta adecuado para el control en tiempo real
• Limitaciones normativas: la banda de 868 MHz está limitada a un ciclo de trabajo del 1 % (unos 36 segundos de emisión por hora), lo que restringe la frecuencia de los envíos
• En entornos interiores densos (hormigón grueso, sótanos), el alcance se reduce a unas pocas decenas de metros

Arquitectura típica de LoRa industrial:

Zigbee en detalle​

Cuándo utilizarlo​

Zigbee es ideal para redes densas de sensores en interiores de corto alcance, especialmente en edificios (edificios inteligentes) y fábricas, donde las distancias son cortas pero el número de nodos es elevado.

Casos de uso industriales ideales para Zigbee:

• Gestión técnica de edificios (GTB): iluminación, persianas, climatización (HVAC)
• Supervisión de las condiciones ambientales en entornos con alta densidad (almacenes, salas blancas)
• Red de detectores de presencia, apertura de puertas y contadores de energía por zona
• Automatización industrial ligera como alternativa a los sistemas cableados en edificios de uso terciario

Ventajas de Zigbee:

• Arquitectura en malla (mesh): los nodos Zigbee retransmiten los datos de los nodos remotos, lo que elimina las zonas sin cobertura
• Bajo consumo de batería (de 1 a 5 años)
• Amplio ecosistema de sensores estandarizados e interoperables (estándar Matter desde 2022)
• Ancho de banda suficiente para mediciones en tiempo real (alarmas, estados)
• Densidad de nodos muy elevada (miles en una misma red)

Limitaciones de Zigbee:

• Alcance limitado: de 10 a 100 m por salto (la red en malla lo compensa, pero requiere suficientes nodos intermedios)
• Se necesita un coordinador: cada red Zigbee requiere un coordinador (hub o pasarela Zigbee)
• 2,4 GHz = interferencias con Wi-Fi, Bluetooth y hornos microondas en entornos industriales densos
• No es adecuado para conexiones de larga distancia entre edificios alejados

4G LTE en detalle​

Cuándo utilizarlo​

El 4G LTE es la tecnología ideal para las conexiones WAN de larga distancia, los emplazamientos aislados sin infraestructura de red y las aplicaciones que requieren un ancho de banda suficiente para la supervisión y el acceso remoto.

Casos de uso industriales ideales para el 4G:

• Instalaciones aisladas (estaciones de bombeo, cabañas, antenas, sensores meteorológicos) sin conexión por cable
• Conexión de emergencia para instalaciones industriales críticas (conmutación de fibra a 4G)
• Pasarelas de IoT que transmiten datos desde el terreno a la nube (supervisión Modbus, OPC-UA)
• Acceso remoto mediante VPN para el mantenimiento remoto de equipos industriales
• Vehículos y equipos móviles (camiones frigoríficos, maquinaria de obra)
• Implementaciones rápidas en las que la instalación de un cable de red es imposible o demasiado costosa

Ventajas del 4G LTE industrial:

• Cobertura nacional: el 99,2 % de los municipios franceses (incluidas zonas rurales e industriales aisladas)
• Ancho de banda suficiente: entre 5 y 50 Mbps son más que suficientes para la supervisión y el mantenimiento remoto
• Sin infraestructura local: sin cableado, sin conmutadores, sin puntos de acceso que mantener
• Doble SIM: cambio automático entre operadores para maximizar la disponibilidad
• Plug-and-play: una pasarela 4G industrial está operativa en menos de una hora

Limitaciones de la tecnología 4G LTE:

• Mayor coste por nodo: una pasarela industrial 4G cuesta entre 300 y 600 €, y la suscripción a la tarjeta SIM, entre 10 y 20 € al mes
• Consumo eléctrico: requiere alimentación de red (no es adecuado para sensores que funcionan con batería)
• Latencia: de 30 a 100 ms (aceptable para la supervisión, pero no para el control en tiempo real exigente)
• Zonas sin cobertura: algunas zonas rurales muy aisladas sin cobertura (se puede mitigar con una antena externa o por satélite)
• Dependencia del operador: la disponibilidad depende de la red móvil (aceptable con doble SIM)

El Wi-Fi en detalle​

Cuándo utilizarlo​

El Wi-Fi es adecuado para instalaciones con infraestructura de red ya existente, para equipos que requieren un alto ancho de banda y para zonas totalmente cubiertas por puntos de acceso.

Casos de uso industriales ideales para el Wi-Fi:

• Conexión de sensores o equipos industriales en una fábrica que ya cuenta con cobertura Wi-Fi
• Vehículos o equipos móviles en las instalaciones (carretillas elevadoras, AGV) en zonas con cobertura
• Cámaras IP de supervisión (requieren la alta velocidad del Wi-Fi)
• SCADA local en modo de supervisión en tiempo real (latencia < 10 ms)

Ventajas del Wi-Fi industrial:

• Velocidad muy alta (compatible con streaming de vídeo y actualizaciones rápidas de firmware)
• Infraestructura que suele estar ya presente en las fábricas modernas
• Latencia muy baja (de 1 a 10 ms): apta para aplicaciones en tiempo real moderadas
• Numerosos equipos industriales con Wi-Fi integrado (HMI, robots colaborativos)

Limitaciones del Wi-Fi industrial:

• Alcance limitado: de 30 a 150 m por punto de acceso (AP); requiere una red en malla para cubrir zonas extensas
• Interferencias: la banda de 2,4 GHz se satura en entornos industriales densos (motores, frecuencias de radio, máquinas CNC)
• Alto consumo: no es adecuado para sensores que funcionan con batería
• Infraestructura costosa: puntos de acceso industriales (Cisco, Aruba, Extreme Networks) = entre 500 y 3 000 € por punto de acceso
• Gestión de red compleja: la itinerancia (roaming) para los dispositivos móviles requiere conocimientos especializados en Wi-Fi

Guía para tomar decisiones: ¿cómo elegir?​

Árbol de decisión​

Tabla de recomendaciones por sector​

Arquitectura híbrida: lo mejor de ambos mundos​

En la práctica, las implementaciones maduras de IoT industrial utilizan una combinación de varias tecnologías, seleccionadas en función de las características de cada equipo.

Ejemplo de arquitectura híbrida: recinto industrial de 10 hectáreas

La pasarela Eziwan actúa como concentrador multiprotocolo: se comunica mediante Modbus en la red OT local, es compatible con concentradores LoRa y Zigbee para los sensores inalámbricos y transmite todos los datos a la nube a través de 4G LTE. Una sola suscripción, un solo panel de control.

Comparación de costes a lo largo de 5 años (instalación de 100 sensores)​

Nota: el 4G LTE es considerablemente más caro por nodo, pero ofrece una conectividad WAN de larga distancia que ni LoRa ni Zigbee pueden proporcionar. La comparación solo es válida para sensores de recopilación de datos, no para pasarelas industriales que deben garantizar la conexión a Internet.

Conclusión​

No existe una «mejor» tecnología de IoT que sirva para todo. La elección depende de tres criterios fundamentales:

1. La distancia: corta (Zigbee), media-larga (LoRaWAN), muy larga o WAN (4G LTE)
2. El consumo: con batería de larga duración (LoRaWAN > Zigbee > Wi-Fi), con alimentación de red (todas)
3. El caudal: datos de sensores (basta con LoRaWAN y Zigbee), supervisión y acceso remoto (se necesitan 4G LTE y Wi-Fi)

La solución Eziwan está optimizada para 4G LTE como tecnología de conexión WAN industrial, ya que es la más adecuada para las pasarelas que deben conectar redes OT locales (Modbus, OPC-UA) a la nube de supervisión. Se puede complementar con concentradores LoRaWAN o Zigbee para los sensores de bajo consumo.

¿Necesitas ayuda para elegir la arquitectura adecuada para tu proyecto? Ponte en contacto con nuestro equipo de ingenieros para una auditoría gratuita de tu proyecto.

Preguntas frecuentes​

¿Se pueden combinar LoRaWAN y 4G LTE en una misma ubicación? Sí, incluso es recomendable. Los sensores LoRaWAN alimentados por batería (contadores de agua, sondas medioambientales, sensores de nivel) transmiten los datos a través de un concentrador LoRa. La pasarela Eziwan 4G LTE agrupa los datos de los sensores LoRa locales y de los equipos Modbus, y los envía a la nube. La red 4G solo se utiliza para la conexión WAN, no para cada sensor individual.

¿Es LoRaWAN fiable para la supervisión industrial crítica? LoRaWAN es adecuado para la supervisión no crítica (lecturas de contadores, entorno, presencia). Para la supervisión crítica (alarmas de bombas, valores de proceso), es preferible el 4G LTE por su baja latencia y su fiabilidad. A menudo, ambos protocolos coexisten: LoRaWAN para los sensores auxiliares y 4G para los controladores lógicos programables (PLC) y las interfaces hombre-máquina (IHM) críticas.

¿Cuál es la diferencia entre LoRa y LoRaWAN? LoRa es la tecnología de radio (modulación CSS de Semtech). LoRaWAN es el protocolo de red basado en LoRa: define la arquitectura de red (nodos → concentradores → servidor de red → servidor de aplicaciones), la gestión de direcciones, la seguridad (AES-128) y las clases de dispositivos (A, B, C). LoRa sin LoRaWAN puede funcionar en modo punto a punto propietario, lo que ofrece menor interoperabilidad.

¿Se puede utilizar Zigbee en un entorno industrial con interferencias electromagnéticas? Zigbee (2,4 GHz) es sensible a las interferencias de radio industriales (motores, variadores, soldadura). En entornos con muchas interferencias, es recomendable dar prioridad a los canales Zigbee de 915 MHz (disponibles en versión sub-GHz) o utilizar la conexión por cable (RS-485 Modbus) para los equipos más críticos. La red en malla Zigbee mejora la resiliencia, pero no elimina las limitaciones físicas.

¿Es el Wi-Fi industrial adecuado para una máquina en movimiento (AGV, transportador)? El Wi-Fi con roaming 802.11r (Fast Transition) se utiliza para los AGV (vehículos guiados automáticamente) y los transportadores. Una red de puntos de acceso que cubre todo el recorrido permite un traspaso rápido (<50 ms) entre puntos de acceso. Se trata de una implementación más compleja y costosa que una red fija, pero es la solución estándar para máquinas en movimiento en entornos interiores.

Para profundizar en el tema​

• Blog: OPC-UA, MQTT, Modbus — cómo elegir una pasarela industrial
• Blog: Modbus, MQTT, OPC-UA — comparativa completa de protocolos industriales
• Blog: SIM M2M IoT — Comparativa de operadores en Francia 2026
• Blog: Cómo elegir una pasarela industrial IoT — 9 criterios
• Blog: supervisión industrial a distancia — guía completa 2026

Eziwan es especialista en conectividad 4G LTE para el IoT industrial. Nuestra pasarela multiprotocolo (Modbus, OPC-UA, MQTT, LoRaWAN, Zigbee) se adapta a tu arquitectura actual. Descubre la pasarela de Eziwan →

Recursos adicionales​

• Conectividad industrial — soluciones de conectividad multiprotocolo para el IoT industrial
• Protocolos industriales — guía de protocolos de comunicación industriales (Modbus, OPC-UA, MQTT…)
• Pasarela de IoT industrial — pasarelas multiprotocolo, tanto inalámbricas como por cable, para el IIoT
• Conexión a Internet en emplazamientos industriales aislados — cómo elegir el protocolo de radio adecuado para emplazamientos sin cobertura por cable
• Soluciones industriales de Eziwan — gama completa de conectividad y supervisión industrial

Esta guía presenta los principales casos de uso del IoT agrícola en Francia, los equipos compatibles, los costes y el retorno de la inversión, y cómo implementar una solución sólida de supervisión agrícola en zonas rurales, incluso sin conexión de fibra óptica.

La agricultura: un terreno fértil para el IoT industrial​

La agricultura moderna ya utiliza numerosos equipos electrónicos y electromecánicos: sistemas de riego automatizados, ventiladores para naves ganaderas, tanques de enfriamiento de leche, silos de almacenamiento, invernaderos climatizados y bombas de perforación. La gran mayoría de estos equipos cuentan con interfaces de comunicación (Modbus RTU, 4-20 mA, salidas de impulsos) que permiten una conexión al IoT sin necesidad de sustituirlos.

Lo que el IoT aporta a la agricultura:

• Vigilancia las 24 horas del día sin necesidad de que el agricultor esté presente de forma permanente
• Alertas inmediatas en caso de anomalías (avería del equipo, superación de umbrales)
• Historial de datos para la optimización de las prácticas y la trazabilidad
• Reducción de pérdidas (leche no conforme, mal crecimiento, mortalidad animal)
• Cumplimiento normativo más sencillo (bienestar animal, directivas sobre el agua)

Caso de uso 1: Supervisión de instalaciones ganaderas​

Granjas porcinas, gallineros, ganado lechero​

Las instalaciones ganaderas sin suelo (granjas porcinas, avícolas y lecheras) se prestan especialmente a la supervisión mediante el IoT. Los parámetros críticos que hay que supervisar son:

Condiciones climáticas del edificio:

• Temperatura (°C) y humedad relativa (%): las variaciones significativas afectan directamente al crecimiento y la salud de los animales
• Concentración de CO₂ (ppm): indicador de la calidad del aire y de la eficacia de la ventilación
• Concentración de NH₃ (amoníaco, ppm): gas peligroso producido por los excrementos, regulado en aras del bienestar animal

Equipos de ventilación:

• Estado de encendido/apagado de cada ventilador (entrada binaria)
• Velocidad de rotación o posición de las compuertas (salida de 0-10 V o 4-20 mA)
• Consumo eléctrico por circuito (transformador de corriente)

Alimentación y agua:

• Nivel de los silos de pienso (sensor de nivel por ultrasonidos)
• Consumo de agua (caudalímetro de impulsos)
• Estado de los comederos automáticos (TOR)

Sensores compatibles e interfaces:

Umbrales de alerta habituales para las instalaciones ganaderas:

Caso de uso 2: Supervisión de los depósitos de leche​

El enfriamiento de la leche es una obligación reglamentaria (Decreto de 15 de septiembre de 2004, en su versión modificada): la leche de vaca debe enfriarse a 8 °C en las dos horas siguientes al ordeño y mantenerse a una temperatura máxima de 4 °C hasta su recogida.

El incumplimiento de estas temperaturas conlleva:

• Deterioro microbiológico irreversible de la leche
• Denegación de la recogida por parte de la lechería (pérdida económica directa)
• Sanciones contractuales (penalización por calidad)

Supervisión mediante IoT del depósito de leche:

La mayoría de los tanques de leche recientes (Boumatic, Mueller, DeLaval, GEA, Lemmer-Fullwood) disponen de un puerto RS-232 o RS-485 Modbus para su supervisión. Los parámetros a los que se puede acceder incluyen:

• Temperatura de la leche (°C) con una resolución de 0,1 °C
• Estado del compresor de refrigeración
• Volumen de leche (si el depósito dispone de medidor)
• Historial de temperaturas (curva completa desde el último ordeño)

El Gateway Eziwan se conecta al depósito a través de RS-232 o RS-485 y envía los datos a la nube con una frecuencia de sondeo configurable de 5 minutos. Se envía una alerta por SMS si la temperatura supera los 8 °C durante más de 15 minutos.

Caso práctico: un ganadero lechero de Bretaña que gestiona tres depósitos de leche (explotación de 120 vacas) ha evitado dos rechazos de recogida en seis meses gracias a las alertas por SMS nocturnas (se detectó una avería en el compresor a las 2 de la madrugada; la reparación se realizó a las 4, antes de la recogida prevista a las 6). Ahorro: 2 × 800 l × 0,40 €/l = 640 € de pérdidas evitadas, además de las penalizaciones por calidad.

Caso de uso 3: Supervisión de invernaderos hortícolas y de hortalizas​

Los invernaderos hortícolas suponen una inversión importante (entre 50 y 300 €/m²), cuya rentabilidad depende del mantenimiento de unas condiciones climáticas óptimas. La supervisión mediante el Internet de las cosas (IoT) permite detectar averías (fallo de la calefacción, ventilación bloqueada, rotura del plástico) antes de que provoquen daños irreversibles en los cultivos.

Parámetros que hay que controlar en el invernadero:

Equipos de invernadero supervisables:

• Calderas y bombas de calor (calefacción): Bosch, Vaillant, Viessmann — a través de Modbus o relés de estado sólido
• Ventiladores y sistemas de ventilación: control de 0-10 V o relé
• Bombas de riego: variador de frecuencia Modbus
• Unidad de tratamiento de agua (UVA, sistema de ósmosis): entradas digitales de estado de marcha/parada

Retorno de la inversión en la supervisión de un invernadero hortícola: En un invernadero de 5 000 m² dedicado al cultivo de tomates (producción anual de aproximadamente 500 t, precio de venta de aproximadamente 0,80 €/kg = 400 000 € de facturación anual), una avería en el sistema de calefacción que pase desapercibida durante la noche en marzo puede destruir toda la cosecha, lo que supone una pérdida de entre 100 000 y 200 000 €. El coste de un gateway Eziwan con alertas por SMS: 500 € + 100 € al año de suscripción. Retorno de la inversión inmediato.

Caso de uso 4: Gestión del riego​

El riego representa el 45 % del consumo industrial de agua en Francia. La normativa se está endureciendo (decretos de restricción en épocas de estiaje, tasas por el uso del agua), lo que hace imprescindible una gestión precisa del riego.

Supervisión del riego mediante el IoT:

• Medidores de caudal por parcela: medición del volumen de agua aplicado por parcela o por cultivo (Modbus o impulsos)
• Medidores de humedad del suelo (tensiómetros, sensores TDR): medición de la humedad volumétrica y de la succión del suelo — base de datos para determinar la necesidad de riego
• Estaciones meteorológicas integradas: ETP (evapotranspiración potencial) calculada en tiempo real, integración con Météo France para la ETP prevista
• Contadores de agua de pozo: seguimiento de los volúmenes extraídos para la declaración ante la DDT (obligaciones reglamentarias > 1 000 m³/año)
• Bombas de pozo y grupos de riego: supervisión del estado y del consumo eléctrico

Cumplimiento normativo: Las explotaciones que extraigan más de 1 000 m³/año de agua subterránea o superficial deben declarar sus extracciones (artículo L214-1 del Código de Medio Ambiente). Eziwan genera automáticamente los informes mensuales de captación para su envío a la DDT/DREAL.

Caso de uso 5: Silos de almacenamiento​

El almacenamiento de cereales supone un importante reto económico. Unas condiciones de almacenamiento inadecuadas (temperatura, humedad) pueden provocar la aparición de micotoxinas (aflatoxinas, DON) o moho, lo que degrada la mercancía o la hace invendible.

Parámetros que hay que vigilar:

• Temperatura: cadenas de termómetros para silos (Rolfes, GSI) con entre 4 y 8 sondas por silo a diferentes alturas
• Humedad: sensores de humedad del grano en continuo o en la entrada del silo (silo de recepción)
• Nivel: sensores de nivel por ultrasonidos o por presión para conocer el volumen almacenado
• Ventilación: estado de los ventiladores de extracción y refrigeración, caudal (m³/h)
• Consumo eléctrico: control automático de los ventiladores en función de la temperatura

Interfaz: la mayoría de los sistemas modernos de control de silos (Superchief, GSI Fan Controller, Brock NECO) disponen de una salida Modbus RS-485 o de un puerto RS-232.

Conectividad 4G para explotaciones agrícolas​

La gran mayoría de las explotaciones agrícolas francesas no dispone de conexión de fibra óptica. La red 4G LTE cubre el 99,2 % de los municipios franceses (fuente: Arcep 2025), pero la cobertura en el interior de los edificios puede ser escasa.

Soluciones para zonas con poca cobertura:

1. Antena 4G externa direccional: ganancia de 9 a 15 dBi, alcance de hasta 30 km en línea recta, compatible con todos los operadores. Instalación en el extremo del alero del edificio o en un mástil.

2. SIM multioperador Eziwan: comprueba las tres operadoras francesas (Orange, SFR, Bouygues) y se conecta a la mejor señal disponible. Aumenta significativamente la cobertura en zonas rurales.

3. LoRa + Gateway 4G: para sensores de muy bajo consumo y muy alejados (hasta 15 km), una arquitectura LoRaWAN con un concentrador LoRa conectado a la red 4G a través del Eziwan Gateway puede dar cobertura a toda una explotación.

4. Conexión por satélite (último recurso): para las ubicaciones sin cobertura 4G, se puede conectar una opción de satélite (Starlink de baja latencia o Eutelsat ViaSat) a la pasarela Eziwan. Latencia de 20-40 ms con Starlink.

Normativa agrícola e IoT​

Bienestar animal​

La Directiva europea 2008/120/CE (cerdos), 2007/43/CE (pollos de engorde) y 1999/74/CE (gallinas ponedoras) establecen unos niveles mínimos de temperatura, espacio, ventilación e iluminación. La supervisión mediante el IoT permite:

• Documentar de forma continua el cumplimiento de los umbrales reglamentarios
• Aportar pruebas durante las inspecciones de la DDPP (Dirección Departamental de Protección de la Población)
• Alertar inmediatamente si se supera algún límite reglamentario

Directiva sobre nitratos​

Las explotaciones situadas en zonas vulnerables a los nitratos están sujetas al Programa de Acción Regional (PAR). La supervisión de los esparcimientos y de la gestión de los efluentes (medidor de caudal en la barra de esparcimiento, nivel del foso) facilita el cumplimiento de las fechas de prohibición y el cálculo de las dosis.

Trazabilidad de la cadena de suministro​

Numerosas certificaciones (Label Rouge, DOP, IGP, agricultura ecológica) exigen la trazabilidad de las condiciones de cría o cultivo. Los datos de IoT de Eziwan se archivan y pueden exportarse para alimentar las herramientas de trazabilidad (Bluerex, Kite Consulting, OAD-Systèmes).

Costes y retorno de la inversión en una explotación agrícola​

Inversión típica​

Rentabilidad de la inversión en una explotación lechera​

• Coste de una denegación de recogida: de 600 a 2 000 € (según el volumen + sanciones)
• Riesgo anual sin supervisión: de 1 a 2 incidentes por depósito al año durante 5 años de explotación
• Coste anualizado de un incidente: de 600 a 800 € al año
• Coste de la supervisión: de 250 a 400 € al año
• Retorno de la inversión (ROI) neto: de 200 a 550 € al año = amortizado en menos de un año

Ayudas disponibles​

El plan Francia 2030 y las ayudas del PCAE (Plan de Competitividad y Adaptación de las Explotaciones) financian parcialmente los equipos destinados a la modernización digital de la agricultura. Los porcentajes de ayuda varían según las regiones y los programas (entre el 30 % y el 50 % de las inversiones subvencionables). Consulte a su cámara de agricultura o a su asesor de FranceAgriMer para conocer los programas aplicables a su proyecto.

Conclusión​

El IoT industrial ya está al alcance de las explotaciones agrícolas francesas, gracias a la cobertura generalizada de 4G, a los sensores Modbus estandarizados y a plataformas en la nube económicas como Eziwan. Las barreras técnicas y económicas que frenaban su adopción se han reducido considerablemente.

Con una inversión inicial de entre 1 000 y 2 000 € por edificio y una cuota de suscripción inferior a 400 € al año, un agricultor dispone de una supervisión las 24 horas del día de sus equipos críticos, alertas inmediatas por SMS y un historial documentado para cumplir con sus obligaciones normativas.

Próximo paso: ponte en contacto con el equipo de Eziwan para solicitar un estudio de viabilidad gratuito adaptado a tu explotación y a tu tipo de producción.

Preguntas frecuentes​

¿Está disponible la red 4G en las zonas rurales agrícolas francesas? La cobertura 4G en Francia metropolitana supera el 99 % de la población, pero solo abarca aproximadamente el 80 % del territorio en superficie; algunas explotaciones situadas en zonas sin cobertura siguen quedando excluidas. Para estas zonas: la red NB-IoT (NarrowBand-IoT) ofrece una mejor penetración en el interior de los edificios y un mayor alcance, y las soluciones por satélite (Starlink) están cada vez más al alcance de los emplazamientos totalmente aislados. Es imprescindible comprobar previamente la cobertura en el emplazamiento exacto antes de cualquier despliegue.

¿Se puede conectar un silo de almacenamiento o una bodega cooperativa ya existentes sin sustituir los equipos? En la gran mayoría de los casos, sí. Los silos modernos cuentan con sensores de temperatura y humedad con salidas de 4-20 mA o RS485 Modbus, a los que se puede conectar directamente una pasarela IoT. Para los equipos más antiguos que carecen de interfaz digital, hay disponibles sensores de recambio compatibles con Modbus RTU a un precio de entre 50 y 100 € por punto de medición.

¿Qué obligaciones normativas puede ayudar a documentar la supervisión del IoT? En la ganadería: las obligaciones de trazabilidad sanitaria (profilaxis, identificación de los animales, condiciones de transporte —Reglamento (UE) 2016/429—), el bienestar animal (temperaturas, ventilación, densidad) y los controles de DPE/PAC pueden basarse en los historiales de datos del IoT como pruebas. El registro automático de todas las mediciones con marca de tiempo certificada supone una ventaja significativa durante los controles.

Para profundizar en el tema​

• Blog: supervisión del agua y el saneamiento mediante 4G — gestión del agua para las administraciones locales
• Blog: ROI del IoT industrial — cálculo y optimización
• Blog: monitorización de la señal 4G — RSRP, RSRQ y cobertura rural
• Blog: tarjetas SIM M2M para el IoT — comparativa de operadores en Francia 2026

Eziwan ayuda a los agricultores, las cooperativas y las entidades de almacenamiento a supervisar sus instalaciones mediante el IoT. Nuestra solución se adapta a los equipos existentes sin necesidad de sustituirlos, con una conectividad 4G optimizada para zonas rurales. Descubre nuestras soluciones →

Recursos adicionales​

• Supervisión remota del riego — control y supervisión de sistemas de riego a través del IoT
• Conexión a Internet en emplazamientos industriales aislados — conectividad 4G para explotaciones agrícolas en zonas rurales
• Monitorización de equipos industriales — supervisión de equipos agrícolas y de almacenamiento
• Conectividad industrial — soluciones de conectividad robustas para zonas rurales
• Soluciones industriales Eziwan — gama de soluciones de IoT adaptadas a los sectores primarios

Esta guía práctica está dirigida a los responsables técnicos, a los directores de agua y saneamiento y a los directores de sistemas de información de las entidades locales —sindicatos de aguas, empresas municipales, mancomunidades de municipios— que supervisan las redes de agua potable.

Situación actual: el parque de sistemas de telegestión del agua en Francia​

Un parque que se está quedando obsoleto​

La gestión remota de las redes de agua potable en Francia se basa hoy en día, en gran medida, en equipos instalados entre los años 2000 y 2015. Las tecnologías predominantes son:

• Módems SOFREL S4W/S500: implantados de forma masiva por los operadores delegados (Veolia, Suez, Saur) en las redes de agua, estos módems GSM/GPRS utilizan la red 2G/EDGE, que actualmente se está desactivando
• RTU Servelec (antes Sontay) y Lacroix Sofrel: gama de RTU específica para el sector del agua que se utiliza en las estaciones de bombeo y de tratamiento
• Sistemas propios de los concesionarios: cada operador concesionario ha desplegado su propia infraestructura (Veolia Hub Eau, Suez IntelliO) con protocolos propios que limitan la gestión directa por parte de la administración

El cierre de la red 2G: un impulso para la modernización​

Orange ha anunciado oficialmente el cierre de la red 2G en 2026 (tras varios aplazamientos). SFR ya ha cerrado su red 2G en varias zonas. Bouygues Telecom sigue la misma trayectoria.

Los módems SOFREL S4W y otras RTU 2G/GPRS que se utilizan en las torres de agua, estaciones de bombeo y estaciones de elevación dejarán de funcionar tras estos cierres.

Se trata de una gran oportunidad para modernizar el sistema y pasar a soluciones 4G LTE con una plataforma en la nube de supervisión centralizada.

Arquitectura de supervisión moderna para una red de agua potable​

Lugares típicos que hay que supervisar​

Arquitectura recomendada​

Migración desde los sistemas actuales​

Sustitución de un módem SOFREL S4W​

El SOFREL S4W es el módem más extendido en las redes de agua francesas. La migración al Eziwan Gateway está diseñada para que no suponga ninguna interrupción.

Pasos de la migración:

1. Auditoría previa (1 h a distancia): identificación de los registros Modbus configurados en el S4W, mapeo de las E/S utilizadas (entradas digitales, entradas analógicas, salidas de relé), lista de los destinatarios actuales de SMS
2. Entrega del Gateway preconfigurado: el Eziwan Gateway se entrega con su plantilla de configuración (registros Modbus idénticos a los del S4W, mismos umbrales de alarma, mismos destinatarios de SMS)
3. Sustitución física (30-45 minutos por emplazamiento): la pasarela se conecta al mismo cableado RS-485. Se inserta y se activa la tarjeta SIM 4G. La conexión a la nube se establece automáticamente
4. Verificación: un técnico de Eziwan toma el control de forma remota para validar la transmisión de datos y las alertas
5. Puesta en servicio: la instalación aparece en el panel de control en la nube con todos sus datos históricos (a partir de la migración; los historiales de S4W no se transfieren)

Compatibilidad: El Eziwan Gateway lee todos los registros Modbus configurados en tu controlador lógico (Schneider M340, Siemens S7-1200, Lacroix E30...). La migración no requiere ninguna modificación del controlador de campo.

Coste de la migración: El Gateway Eziwan es más barato que un SOFREL S4W nuevo y ofrece más funcionalidades (VPN, multiprotocolo, OTA). Para una flota de 50 estaciones, la amortización de la inversión, en comparación con la compra de S4W nuevos, es inmediata.

Migración desde un sistema subcontratado (fin del DSP)​

Cuando se vuelve a la gestión directa o se cambia de concesionario, la administración local suele perder el acceso al sistema de supervisión propio del operador saliente. La transición puede suponer semanas o meses sin supervisión centralizada.

Enfoque de Eziwan para las transiciones del DSP:

1. Implementación anticipada: instalar las pasarelas Eziwan entre 3 y 6 meses antes de que finalice el contrato DSP, en paralelo al sistema existente
2. Validación paralela: comparar los datos de Eziwan con los del operador anterior para comprobar su coherencia
3. Transición fluida: al finalizar el contrato DSP, la supervisión de Eziwan ya está operativa y validada
4. Continuidad del historial: ya hay disponibles entre 3 y 6 meses de historial en la plataforma de Eziwan

Cumplimiento normativo​

Autocontrol y obligaciones de la ARS​

El decreto de 21 de julio de 2015, por el que se modifica el decreto de 2 de mayo de 2007, establece obligaciones de autocontrol para las EDAR (estaciones depuradoras de aguas residuales) y las UPEP (unidades de producción de agua potable):

Parámetros que deben supervisarse y archivarse (UPEP):

• Caudal de agua producida (m³/h y m³/día)
• Turbidez del agua tratada (NTU) — umbral de alerta: > 1 NTU
• Contenido de cloro residual (mg/L) — umbral de alerta: < 0,1 mg/L
• pH (6,5 a 9,0)
• Conductividad (μS/cm)
• Temperatura (°C)

Requisitos de archivo:

• Conservación durante un mínimo de 5 años
• Marca de tiempo UTC certificada
• Formato de exportación compatible con SANDRE para su transmisión a los organismos estatales
• Posibilidad de acceso a las DDETSPP (antiguas DDASS) previa solicitud

Cómo cumple Eziwan estos requisitos:

• Archivo durante un mínimo de 10 años (más allá de los 5 años exigidos por la normativa)
• Marca de tiempo UTC en cada medición, con firma digital
• Exportación a formatos CSV y JSON según el estándar SANDRE
• API de acceso para los servicios de control
• Informes automáticos diarios y semanales configurables

Directiva NIS2: aplicabilidad al agua potable​

La transposición de la Directiva NIS2 en Francia (ley de 16 de abril de 2024) clasifica a los operadores del sector del agua en categorías según su tamaño:

Entidades esenciales:

• Operadores de agua potable que prestan servicio a más de 50 000 personas O
• Cifra de negocio superior a 50 M€ O
• Designados como OIV (Operadores de Importancia Vital)

Entidades importantes:

• Operadores de agua potable que abastecen a más de 10 000 personas O
• Volumen de negocio superior a 10 M€

Obligaciones de la NIS2 aplicables a la gestión remota del agua:

Caso práctico: consorcio de aguas con 80 estaciones​

Contexto: Una mancomunidad gestiona 80 estaciones de bombeo (de 12 a 350 m³/h) y 6 depósitos de agua en un territorio rural que abarca 45 municipios. Equipamiento actual: módems SOFREL S4W 2G, supervisión local limitada, 3 técnicos.

Problemas:

• El 40 % de las estaciones carecen de alarma automática (las averías se detectan a través de llamadas de los vecinos)
• La red 2G está en proceso de cierre en el territorio
• Obligación NIS2 (mancomunidad que da servicio a más de 15 000 habitantes)
• Contrato de rendimiento que exige una tasa de continuidad del servicio superior al 99,5 %

Implementación de Eziwan:

• 80 pasarelas Eziwan (1 por estación) entregadas preconfiguradas en 3 semanas
• Migración desde los S4W en 6 semanas (13 estaciones por semana, 2 técnicos)
• Configuración: de 8 a 24 registros Modbus por estación, alertas por SMS y correo electrónico
• Panel de control centralizado: vista en tiempo real de las 80 estaciones, cartografía SIG

Resultados a los 6 meses:

• Reducción de las intervenciones no planificadas en un 68 % (de 240 a 77 intervenciones al año)
• Detección de una fuga importante en una tubería de impulsión (caudal nocturno anómalo detectado automáticamente a las 2 de la madrugada, intervención a las 6 de la mañana)
• Cumplimiento de la normativa NIS2 documentado (auditoría externa superada)
• Ahorro estimado: 95 000 € al año (desplazamientos evitados + daños evitados)

Protocolos y equipos compatibles​

Contadores de agua​

Sondas de medición de agua​

Controladores de campo para sistemas de agua​

Cálculo del ROI para una administración local​

Costes evitados gracias a la supervisión mediante el IoT​

Desplazamientos de los técnicos:

• Coste medio de un desplazamiento no programado: entre 180 y 350 € (1 h 30 min de ida y vuelta + diagnóstico)
• Reducción habitual con Eziwan: entre el 60 % y el 75 % de los desplazamientos no programados evitados
• Ejemplo: 80 estaciones, 3 técnicos: 240 desplazamientos/año → 77 desplazamientos/año = 163 desplazamientos evitados × 250 € = 40 750 €/año

Daños evitados (fugas, averías, desbordamientos):

• Fuga en la tubería de impulsión no detectada: entre 5 000 y 50 000 m³ perdidos antes de su detección manual
• Coste por m³ de agua producida: entre 0,80 y 1,20 €
• Ejemplo: 1 fuga de 15 000 m³ evitada = entre 12 000 y 18 000 € al año

Servicios de guardia:

• Reducción de las intervenciones nocturnas de urgencia: entre un 40 % y un 60 %
• Ahorro en primas por guardia y horas extras: entre 10 000 y 25 000 € al año, dependiendo de la flota

Cumplimiento normativo:

• Evitar una notificación de la ARS tras un rebasamiento del umbral no detectado
• Coste estimado de un incumplimiento documentado: entre 15 000 y 50 000 € (obras urgentes + auditoría externa)

Ejemplo de cálculo del ROI para 80 estaciones​

ROI del primer año: 80 750 − 72 000 = +8 750 € desde el primer año ROI a partir del segundo año: 80 750 − (14 400 + 9 600) = +56 750 € al año

Financiación y ayudas disponibles​

FEDER y dotaciones regionales​

Los proyectos de modernización de la gestión remota de las redes de agua potable pueden optar a financiación del FEDER (Fondo Europeo de Desarrollo Regional) en el marco de los programas operativos regionales 2021-2027, dentro del eje «Transición digital de los servicios públicos».

Agencias del agua​

Las seis agencias del agua francesas (Artois-Picardía, Rin-Mosa, Sena-Normandía, Loira-Bretaña, Adour-Garona y Ródano-Mediterráneo-Córcega) ofrecen ayudas para la modernización de la gestión de las redes de agua. Los criterios para recibir estas ayudas incluyen la reducción de las fugas (rendimiento de la red), el cumplimiento de la normativa y la transición digital.

Póngase en contacto con su agencia del agua local para conocer los programas en curso y las ayudas aplicables a su proyecto.

Subvención de apoyo a la inversión local (DSIL) y DETR​

La DSIL y la DETR (Dotación de Equipamiento para los Territorios Rurales) pueden financiar proyectos digitales para las comunidades rurales. Los proyectos de modernización de las redes de agua mediante el Internet de las cosas (IoT) se enmarcan en los objetivos de «servicios de proximidad» y «transición digital» de estas dotaciones.

Preguntas frecuentes​

¿La supervisión del IoT puede acogerse al Plan France Relance o a ayudas regionales? Sí, se pueden aplicar varias medidas. La DSIL (Dotación de Apoyo a la Inversión Local) financia los proyectos digitales de las entidades locales. La DETR (Dotación para el Equipamiento de los Territorios Rurales) cubre a los municipios rurales. Las agencias del agua (Sena-Normandía, Loira-Bretaña, etc.) cuentan con programas específicos para la reducción de pérdidas y la autosupervisión. Por lo general, se requiere un expediente técnico con un retorno de la inversión cuantificado (ahorro por fugas, costes evitados).

¿Es invasiva la migración desde un sistema SOFREL ya existente? No. La pasarela Eziwan se conecta en paralelo a los equipos SOFREL existentes a través de Modbus RTU/TCP o 4-20 mA. No es necesario desconectar el sistema existente durante la transición. La migración puede realizarse por fases: primero, la lectura de datos; después, la conmutación progresiva de las estaciones piloto; y, por último, la sustitución completa según su calendario de renovación de equipos.

¿Cómo cumple la solución con los requisitos del informe de autocontrol de la ARS? La plataforma Eziwan permite exportar los datos de autocontrol en los formatos requeridos (CSV, Excel) con marcas de tiempo certificadas. Los indicadores de rendimiento (índice de pérdidas, caudal nominal frente al real, incidentes de presión) se calculan automáticamente a partir de las lecturas y pueden extraerse para los periodos solicitados por la ARS.

Conclusión y próximos pasos​

La modernización de la gestión remota del agua potable ya no es una opción para las administraciones locales francesas. El cierre de la red 2G, las obligaciones de la Directiva NIS2, los requisitos de autocontrol de la ARS y la presión sobre los costes de explotación se suman para hacer que esta inversión sea imprescindible.

La buena noticia es que el retorno de la inversión es rápido (por lo general, menos de 18 meses), la migración desde los sistemas existentes (SOFREL, etc.) está documentada y no es invasiva, y las soluciones modernas (pasarela 4G + nube) son considerablemente más baratas que los equipos propietarios de primera generación.

Sus próximos pasos:

1. Auditoría de su parque actual: inventario de equipos, identificación de módems 2G, mapeo de los controladores de campo
2. Simulación del ROI: nuestro equipo puede prepararle un cálculo personalizado basado en su parque
3. Proyecto piloto: comenzar con entre 5 y 10 estaciones piloto para validar la solución antes de su implantación a gran escala

Ponte en contacto con el equipo de Eziwan para solicitar una auditoría gratuita de tu infraestructura de telegestión del agua.

Para profundizar en el tema​

• Blog: Supervisión de agua y saneamiento con 4G — Experiencias sobre el terreno
• Blog: Lectura remota de contadores: de GPRS a 4G — Migración práctica
• Blog: Modbus TCP frente a RTU — guía completa para redes de agua
• Blog: Lista de comprobación de NIS2 — 30 puntos de control para las administraciones locales
• Blog: Tarjetas SIM M2M IoT — Comparativa de operadores para redes rurales

Eziwan colabora con las administraciones locales, las empresas de aguas y las empresas municipales para modernizar sus sistemas de telegestión. Acompañamos en las transiciones hacia el modelo DSP y en las migraciones desde los sistemas SOFREL, Lacroix y otros RTU de agua. Descubre nuestra solución para el sector del agua →

Recursos adicionales​

• Solución de agua y saneamiento — supervisión mediante IoT de las redes de agua potable para administraciones locales
• Supervisión de torres de agua — telegestión de torres de agua y depósitos de las administraciones locales
• Lectura remota inalámbrica M-Bus — lectura automática de contadores de agua por radio
• Supervisión de depósitos de agua — supervisión en tiempo real de niveles y presiones
• Solución para estaciones de bombeo — monitorización y control remoto de estaciones de bombeo

Esta guía compara de forma objetiva ambas arquitecturas en función de siete criterios clave —coste total, seguridad, latencia, escalabilidad, cumplimiento normativo, facilidad de mantenimiento y resiliencia— para ayudarte a tomar la decisión más adecuada según tu contexto industrial.

Lo que comparamos​

SCADA local (clásico): Servidor(es) físico(s) instalado(s) en sus instalaciones o en su sala de servidores. Software SCADA instalado localmente (Wonderware InTouch/System Platform, Ignition, PCVue, WinCC). Historial de datos en un servidor SQL local. Acceso desde la red local (LAN) o a través de VPN para el acceso remoto.

SCADA en la nube / IIoT SaaS: Plataforma alojada en la nube (AWS, Azure, GCP o nube soberana francesa). Pasarelas industriales in situ que recogen los datos de campo y los envían a la nube. Panel de control accesible desde cualquier navegador. Historial en la nube. Ejemplos: Eziwan, Axonize, Samsara, Siemens MindSphere, AWS IoT SiteWise.

Criterio 1: Coste total de propiedad (TCO a 3 años)​

SCADA local — Coste total de propiedad (TCO) estimado para 10 centros industriales​

SCADA en la nube (SaaS): coste total de propiedad (TCO) típico para 10 centros industriales​

Conclusión sobre el TCO: El SaaS en la nube es entre 2 y 4 veces más barato a lo largo de 3 años para las implementaciones en múltiples emplazamientos. La ventaja aumenta a medida que crece el número de emplazamientos. En el caso de un único emplazamiento con un sistema SCADA ya amortizado, la solución local puede seguir siendo una opción válida.

Criterio 2: Seguridad​

Este suele ser el argumento principal de los defensores de las soluciones locales. Analicemos qué hay de cierto en ello.

Lo que ocurre con la solución «on-premise»:​

• Datos físicamente en tus instalaciones — sin tránsito hacia el exterior
• Sin dependencia de terceros para acceder a los datos
• Posibilidad de aislamiento de la red de Internet (air gap)

Lo que suele ser falso sobre las soluciones «on-premise»:​

• «On-premise = más seguro» — falso en la mayoría de los casos. Las pymes no suelen contar con un equipo dedicado a la ciberseguridad. Sus servidores locales suelen funcionar con Windows Server 2012/2016 sin parches, sin supervisión de accesos y sin detección de intrusiones. Un proveedor de servicios en la nube con certificación ISO 27001 y un equipo de seguridad dedicado suele ser más seguro que un servidor en una sala de servidores sin supervisión.
• «Mis datos no salen de la fábrica» — cierto solo si realmente has aislado el servidor SCADA. Si accedes al SCADA desde Internet (RDP, VPN), los datos siguen transitando.

Lo que ofrece la nube:​

• Alojamiento certificado según la norma ISO 27001 con un equipo de seguridad disponible las 24 horas del día, los 7 días de la semana
• Cifrado en tránsito y en reposo (TLS 1.3, AES-256)
• Actualizaciones de seguridad automáticas: sin vulnerabilidades CVE sin parchear durante 3 años
• Autenticación MFA nativa en todos los accesos
• Registros de auditoría completos y centralizados

Riesgos reales de la nube:​

• Disponibilidad de Internet: si se interrumpe la conexión a Internet, se pierde el acceso al SCADA remoto (pero no el control local, que sigue estando en los controladores lógicos programables)
• Cumplimiento normativo en materia de soberanía de datos: si se tratan datos sensibles (OIV, datos personales), la elección del proveedor de alojamiento en la nube es fundamental (Francia frente a EE. UU.)

Conclusión sobre seguridad: A igualdad de nivel de madurez, la nube certificada según la norma ISO 27001 y alojada en Francia suele ser más segura que una solución local no gestionada. Para los OIV (operadores de importancia vital) o sectores muy sensibles, se recomienda la nube soberana francesa (SecNumCloud certificada por la ANSSI).

Criterio 3: Latencia y tiempo real​

La verdad sobre la latencia en la nube​

La latencia de ida y vuelta entre una pasarela de campo y un servidor en la nube alojado en París es de entre 50 y 200 ms, dependiendo de la calidad de la conexión 4G o de fibra.

¿Te parece aceptable para tu aplicación?

Regla de oro: el control en tiempo real SIEMPRE se mantiene en el controlador local. La nube se encarga de la supervisión, las alertas, el historial y el mantenimiento a distancia. Esta separación de responsabilidades es la clave para una arquitectura IIoT adecuada.

Conclusión sobre la latencia: La latencia en la nube es perfectamente aceptable en el 95 % de los casos de supervisión industrial. Solo el bucle de control en tiempo real debe permanecer local.

Criterio 4: Escalabilidad​

Soluciones locales: escalabilidad difícil y costosa​

Pasar de 10 a 50 sitios supervisados de forma local requiere:

• Servidores adicionales (o ampliación de la memoria o el almacenamiento)
• Licencias adicionales (a menudo en proporción al número de etiquetas o conexiones)
• Intervención de un integrador para la configuración
• Migración de los datos históricos
• Pruebas y validación antes de la puesta en producción

Plazo habitual: de 4 a 12 semanas. Coste marginal elevado.

La nube: escalabilidad casi instantánea​

Añadir una nueva instalación en la nube SaaS:

1. Pedir una pasarela (entrega en 5-7 días)
2. Instalarla y conectarla a la red OT de la instalación (30-60 minutos)
3. Configurar los puntos de datos desde el panel de control web
4. El sitio aparece en el panel de control centralizado de forma inmediata

Plazo habitual: de 1 a 2 semanas (el plazo depende principalmente del material). Coste marginal reducido.

Conclusión sobre la escalabilidad: La nube gana por goleada. Esto resulta especialmente decisivo para las implementaciones en múltiples sedes o para los integradores que gestionan redes de entre varias decenas y varios cientos de sedes de clientes.

Criterio 5: Cumplimiento normativo y reglamentación​

NIS2 (Directiva europea sobre ciberseguridad)​

Para las entidades esenciales e importantes sujetas a la Directiva NIS2 (agua, energía, industria crítica), los requisitos de ciberseguridad son los mismos independientemente de la arquitectura. La diferencia radica en la capacidad de demostrar el cumplimiento:

• In situ: usted es responsable de toda la cadena (sistema operativo, aplicación, red, accesos). La auditoría NIS2 verificará sus registros, sus procedimientos de actualización y su segmentación de red.
• Nube certificada: el proveedor de servicios en la nube certificado según la norma ISO 27001 cubre parte de los requisitos (infraestructura, alojamiento). Usted sigue siendo responsable de la configuración de las aplicaciones y de los accesos de los usuarios.

El RGPD y los datos personales​

Si su sistema SCADA trata datos personales (horarios de presencia de los operadores, accesos biométricos), la ubicación de los datos es importante:

• Nube de la UE (AWS París, OVHCloud): cumple con el RGPD si el contrato incluye las cláusulas DPA adecuadas
• Nube de EE. UU. (sin SCC): no cumple con la normativa para los datos personales de ciudadanos europeos
• Instalaciones propias en Francia: cumple con la normativa por naturaleza si se controla el acceso

Sectores regulados (farmacéutico, agroalimentario)​

La norma 21 CFR Parte 11 de la FDA (trazabilidad electrónica en el sector farmacéutico) y el Anexo 11 de las BPF de la UE son compatibles con la nube, siempre que se elija un proveedor capaz de presentar los certificados de validación (IQ/OQ/PQ) exigidos por los auditores.

Conclusión sobre el cumplimiento normativo: La nube alojada en Francia por un proveedor con certificación ISO 27001 es compatible con NIS2, el RGPD y las principales normativas del sector. Comprueba los certificados del proveedor.

Criterio 6: Facilidad de mantenimiento​

Infraestructura local: la carga de TI oculta​

Las empresas suelen subestimar la carga de mantenimiento que supone un sistema SCADA local:

• Actualizaciones del sistema operativo (parches mensuales de Windows Server)
• Actualizaciones del antivirus (diarias)
• Gestión de copias de seguridad y pruebas de restauración
• Actualizaciones de la base de datos SQL (PostgreSQL, MS SQL)
• Renovación de certificados SSL
• Gestión de licencias (renovación, auditoría de Microsoft)
• Asistencia a los usuarios internos

En la práctica, un sistema SCADA local requiere entre 0,3 y 0,5 ETC de TI a lo largo de su vida útil (compartido con otros sistemas).

Nube: mantenimiento externalizado​

En una plataforma SaaS en la nube, el proveedor se encarga de:

• Toda la infraestructura (servidores, red, almacenamiento)
• Las actualizaciones de seguridad (sin interrupción del servicio)
• Las copias de seguridad (RTO/RPO garantizados contractualmente)
• La escalabilidad de la infraestructura en función de la carga

Vuestro equipo solo se encarga del mantenimiento de las pasarelas de campo (firmware OTA automatizable) y de la configuración de las aplicaciones.

Conclusión sobre la facilidad de mantenimiento: La nube reduce la carga operativa entre un 70 % y un 80 %. Esto resulta decisivo para las pymes que no cuentan con un equipo de TI propio.

Criterio 7: Resiliencia y disponibilidad​

Infraestructura local: una resiliencia de doble filo​

Puntos fuertes:

• Funciona incluso sin conexión a Internet (supervisión local continua)
• No depende de terceros para el acceso local

Puntos débiles:

• Fallo del servidor = interrupción total de la supervisión
• Requiere redundancia de hardware para garantizar una alta disponibilidad (coste duplicado)
• Recuperación ante desastres compleja (reconstrucción del servidor)
• El SLA real suele ser mediocre (99 % = 3,65 días de inactividad al año)

La nube: alta disponibilidad por diseño​

Las plataformas en la nube industriales de confianza garantizan una disponibilidad del 99,9 % (SLA contractual = < 8,76 horas de inactividad al año) o incluso del 99,95 %.

Arquitectura multi-AZ (multicentro de datos): el fallo de un centro de datos no afecta al servicio. La recuperación ante desastres (DR) es automática.

Principal riesgo relacionado con la nube: si se interrumpe la conexión a Internet o 4G de la instalación, la pasarela pierde la conexión con la nube. Los datos se almacenan temporalmente de forma local (store-and-forward) y se retransmiten una vez restablecida la conexión. La supervisión remota no está disponible durante la interrupción.

Respuesta: en el caso de las instalaciones críticas, implantar una conexión de emergencia (SIM 4G con doble operador en modo de conmutación automática a fibra óptica, o VSAT por satélite como último recurso).

Conclusión sobre la resiliencia: La nube ofrece una mayor disponibilidad de la plataforma. La solución on-premise es más resiliente para la supervisión local sin depender de la red. Una solución híbrida (control local + supervisión en la nube) ofrece lo mejor de ambas.

Arquitectura híbrida: lo mejor de ambos mundos​

La mayoría de las nuevas implantaciones industriales adoptan una arquitectura híbrida:

Ventajas del sistema híbrido:

• El control y las alarmas críticas siguen siendo locales (latencia cero)
• La supervisión, el historial y el acceso remoto se encuentran en la nube
• En caso de corte de Internet, el proceso continúa (controlador) y los datos se almacenan en búfer (pasarela)
• La inteligencia en el borde (reglas de automatización locales) reduce la dependencia de la nube

Esa es precisamente la arquitectura que utiliza Eziwan: una pasarela industrial en cada emplazamiento (periferia) y una plataforma en la nube para la supervisión centralizada.

Tabla resumen​

¿Cuándo elegir qué?​

Elige la nube SaaS si:​

• Gestionas varias sedes (3 o más) y deseas una supervisión centralizada
• No dispones de un equipo de TI dedicado al mantenimiento de los servidores
• Vas a implementar una nueva solución (greenfield) sin un sistema SCADA heredado
• Su presupuesto es limitado y desea minimizar el gasto de capital (capex)
• Necesita un acceso remoto de calidad para sus técnicos o subcontratistas

Elige la opción «on-premise» si:​

• Dispones de un sistema SCADA reciente y ya amortizado (Wonderware, Ignition)
• Es una OIV y tiene restricciones absolutas de aislamiento de red
• Dispone de un equipo informático interno capaz de mantener la infraestructura
• Su centro es único y no necesita supervisión multisitio
• Sus restricciones de latencia son extremas (tiempo real crítico < 10 ms)

Elige la solución híbrida si:​

• Tienes un sistema SCADA ya existente que deseas complementar con acceso remoto
• Quieres obtener el mejor retorno de la inversión sin tener que rediseñar tu arquitectura SCADA local
• Su proceso requiere control local, pero desea la supervisión en la nube
• Es el caso más habitual en los nuevos proyectos de IIoT

Conclusión​

No hay una respuesta válida para todos los casos. La elección depende del número de sedes que tengas, de tu nivel de madurez en materia de TI, de tus restricciones normativas y de tus objetivos de escalabilidad.

Lo que está claro es que: en el caso de las implementaciones en múltiples sedes, la balanza del TCO se inclina claramente hacia la nube SaaS. Y el argumento de la seguridad solo es válido si tu infraestructura local está correctamente mantenida, lo que rara vez ocurre en las pymes que no cuentan con un equipo dedicado a la ciberseguridad.

La arquitectura híbrida «edge + cloud», representada por soluciones como Eziwan, permite hoy en día combinar el control local (latencia cero, funcionamiento sin conexión) con la potencia de la nube (supervisión centralizada, acceso remoto, historial ilimitado), sin tener que elegir.

Preguntas frecuentes​

¿Puede funcionar un SCADA en la nube si se corta la conexión a Internet? Con una arquitectura híbrida (gateway perimetral + nube), el proceso industrial sigue funcionando (el controlador funciona de forma autónoma) y los datos se almacenan temporalmente de forma local en el gateway (store-and-forward). La supervisión en tiempo real se interrumpe durante el corte, pero los datos no se pierden: se transmiten en cuanto se restablece la conexión. Para las alarmas críticas, configura alertas locales (relés, SMS desde la pasarela perimetral) que funcionen sin Internet.

¿Qué sistemas SCADA locales son compatibles con una pasarela IoT en la nube? Wonderware AVEVA, Ignition (Inductive Automation), CODESYS, FactoryTalk (Rockwell), WinCC (Siemens), Citect: todos ellos se integran con pasarelas de IoT en la nube a través de OPC-UA, Modbus TCP o API REST. La arquitectura híbrida consiste en dejar que el sistema SCADA local se encargue del control local y añadir una pasarela de IoT en la nube para la supervisión remota y el acceso remoto de los técnicos.

¿Es la nube SaaS adecuada para los secretos industriales (fórmulas, procesos propios)? Los datos críticos de los procesos (recetas, parámetros propios) pueden excluirse de la transmisión a la nube: solo se transmiten los datos necesarios para la supervisión (temperaturas, presiones, estado de las máquinas). En cuanto a los datos más sensibles, el alojamiento en la nube en Francia (OVHCloud, Scaleway), sujeto a la legislación francesa, ofrece un nivel de protección adicional frente a los proveedores de alojamiento estadounidenses, sujetos a la ley CLOUD Act.

¿Cuánto tiempo lleva la migración de un SCADA local a la nube? En el caso de una instalación con un SCADA ya existente, la implementación de una capa en la nube (acceso remoto, supervisión multisitio) lleva entre 1 y 4 semanas sin afectar al funcionamiento del SCADA local. El SCADA existente permanece en funcionamiento; la pasarela IoT en la nube se añade en paralelo. Una migración completa a un SCADA en la nube (sin SCADA local) tarda entre 2 y 6 meses, dependiendo de la complejidad de la instalación.

Para profundizar en el tema​

• Blog: supervisión industrial a distancia — guía completa 2026
• Blog: edge computing frente a la nube industrial — ¿cuándo utilizar cada una?
• Blog: acceso remoto seguro a PLC y SCADA — VPN y NIS2
• Blog: ROI del IoT industrial — cálculo y optimización
• Documentación: arquitectura de la plataforma Eziwan

¿No sabes si optar por la nube o por una solución local para tu proyecto de supervisión? Ponte en contacto con nuestro equipo para recibir asesoramiento personalizado adaptado a tu contexto industrial.

Recursos adicionales​

• SCADA en la nube — plataforma SCADA en la nube para la supervisión industrial centralizada
• Supervisión y teleasistencia industrial — soluciones de supervisión remota para la industria
• Computación en el borde industrial — procesamiento local de datos para reducir la dependencia de la nube
• Guía: arquitectura SCADA 4G — cómo diseñar una arquitectura SCADA con conectividad 4G

Esta guía presenta las principales amenazas de ciberseguridad identificadas en 2025-2026, los sectores más expuestos en Francia y las medidas concretas para reducir su exposición.

¿Por qué los sistemas OT se han convertido en el objetivo número uno?​

Durante décadas, los sistemas industriales estaban protegidos por el air gap: su aislamiento físico total de las redes informáticas y de Internet. Esta protección natural ha desaparecido con la digitalización industrial.

Los factores que han marcado un antes y un después:

• Convergencia entre TI y TO: los controladores lógicos programables (PLC), los sistemas SCADA y los sensores están ahora conectados a los sistemas ERP, MES y a la nube para la supervisión remota
• Vida útil de los equipos: un controlador lógico programable (PLC) tiene una vida útil de entre 15 y 25 años. Los controladores instalados entre 2005 y 2010 suelen funcionar con sistemas operativos obsoletos (Windows XP, CE) que ya no reciben mantenimiento
• Protocolos sin seguridad nativa: Modbus, DNP3, Profibus y BACnet se diseñaron pensando en la fiabilidad, no en la seguridad. No admiten ni autenticación ni cifrado
• Recursos limitados: un PLC o una RTU no tiene la potencia de cálculo necesaria para ejecutar un antivirus o algoritmos criptográficos modernos
• Ciclo de actualización lento: aplicar un parche a un autómata puede requerir una parada de producción programada; muchas empresas posponen las actualizaciones durante años

Consecuencia: los sistemas de tecnología operativa (OT) acumulan vulnerabilidades sin corregir, protocolos no seguros y una exposición cada vez mayor de la red. Para un atacante, es un objetivo ideal.

Las seis principales amenazas de seguridad operativa en 2026​

1. Ransomware industrial (ICS Ransomware)​

El ransomware sigue siendo la amenaza número uno. Pero en 2025-2026, los grupos de ciberdelincuentes han desarrollado variantes específicas para sistemas industriales, capaces de:

• Cifrar los archivos de configuración SCADA (proyectos Wonderware, Ignition, Siemens TIA Portal)
• Modificar los parámetros de los controladores lógicos programables para provocar un fallo físico además del cifrado
• Aprovechar las interfaces OPC-UA y Modbus TCP para propagarse lateralmente por la red OT

Grupos activos en Europa: LockBit 3.0, BlackCat/ALPHV, Play y Cl0p han atacado a empresas francesas en 2024-2025. El sector manufacturero representa el 28 % de las víctimas de ransomware en Europa.

Impacto medio de un ransomware industrial:

• Tiempo de inactividad de la producción: de 12 a 21 días
• Coste total (rescate + restauración + pérdida de ingresos): entre 2,5 y 8 millones de euros para una pyme
• Índice de pago del rescate: el 42 % de las empresas industriales pagan (frente al 30 % en todos los sectores)

Vías de acceso más frecuentes:

1. VPN sin autenticación multifactorial (MFA) comprometida mediante «credential stuffing»
2. Acceso remoto de subcontratistas de mantenimiento (TeamViewer, AnyDesk) con credenciales compartidas
3. Phishing dirigido a ingenieros con acceso a los sistemas OT
4. Aprovechamiento de vulnerabilidades en las interfaces hombre-máquina (IHM) expuestas a Internet

2. Ataques a los controladores lógicos programables (PLC/RTU)​

Los autómatas programables son ahora el objetivo directo de los ataques. Los ataques más sofisticados modifican la lógica del programa (firmware o lógica de escalera) para:

• Provocar paradas de emergencia indebidas
• Forzar a los equipos a funcionar fuera de sus rangos normales de funcionamiento
• Ocultar los valores reales a los operadores (manipulación de los datos de supervisión)

Vulnerabilidades recurrentes identificadas por la ANSSI (2024-2025):

Medida preventiva clave: aislar los controladores en VLAN dedicadas, prohibir las conexiones directas desde la red informática y utilizar DMZ industriales que se ajusten a la arquitectura Purdue.

3. Ataques a protocolos industriales sin medidas de seguridad​

Modbus, DNP3, BACnet y Profinet se diseñaron entre los años 1970 y 1990 con el objetivo de garantizar la fiabilidad y la rapidez. Ninguno de ellos incorpora autenticación nativa. Cualquier equipo conectado a la misma red puede:

• Leer todos los registros de un controlador Modbus sin restricciones
• Escribir valores en las bobinas y los registros sin autenticación
• Enviar comandos DNP3 a equipos de distribución eléctrica o de agua

Tipo de ataque: un atacante que acceda a la red OT (a través de una VPN comprometida, un puesto de mantenimiento infectado o un cable conectado físicamente) puede enviar directamente comandos Modbus al controlador de una bomba o un compresor.

Mitigación:

• Implementar pasarelas industriales con cortafuegos de aplicaciones que bloqueen los comandos Modbus de escritura no autorizados (lista blanca de direcciones IP de origen + códigos de función)
• Implementar la autenticación mutua TLS en las comunicaciones OPC-UA
• Supervisar las comunicaciones Modbus para detectar códigos de función anómalos (FC05/FC06/FC15/FC16 fuera de las ventanas de mantenimiento)

4. Ataques a las interfaces HMI y SCADA​

Las interfaces hombre-máquina (IHM) y los servidores SCADA suelen ser los eslabones débiles porque:

• Funcionan con Windows Server (2012, 2016 o incluso 2008), que rara vez se actualiza
• Se puede acceder a ellos desde las redes informáticas para la supervisión de la producción
• Incorporan servidores web para el acceso remoto (a menudo sin autenticación multifactorial)

Escenario de ataque habitual:

1. El atacante compromete un equipo informático mediante phishing
2. Escaneo de la red → detecta un servidor SCADA Wonderware en el puerto 80
3. Aprovechamiento de una vulnerabilidad web o de credenciales predeterminadas
4. Acceso al sistema de supervisión de la producción → modificación de los umbrales de alarma para ocultar una anomalía
5. Distribución de ransomware desde el SCADA al resto de la red OT

Verificación de datos 2025: La plataforma Shodan recoge más de 15 000 interfaces hombre-máquina (IHM) industriales accesibles directamente desde Internet en Francia, de las cuales unas 3 400 no tienen configurada la autenticación.

5. Ataques a la cadena de suministro (Supply Chain OT)​

La amenaza a la cadena de suministro de TI está aumentando considerablemente. Consiste en comprometer un equipo, un programa informático o un proveedor de servicios antes de que llegue a la víctima final.

Vectores identificados:

• Firmware malicioso en routers industriales o gateways de IoT importados (en su mayoría desde Asia) que incorporan puertas traseras
• Actualizaciones de software comprometidas de programas SCADA o bibliotecas de protocolos industriales
• Proveedores de mantenimiento que acceden a la red OT con sus propias herramientas (memorias USB, ordenadores portátiles) desde otras instalaciones de clientes infectadas
• Integración de componentes de terceros en los controladores lógicos programables (tarjetas de comunicación, módulos industriales) con firmware no verificado

Requisitos de la Directiva NIS2 directamente relacionados: el artículo 21 de la Directiva NIS2 exige explícitamente la gestión de la seguridad de la cadena de suministro para las entidades esenciales e importantes.

6. Amenazas internas (Insiders)​

Las amenazas internas suelen subestimarse en el sector. Afectan a:

• Empleados descontentos con acceso a los sistemas de control
• Subcontratistas con accesos remotos permanentes que no se desactivan una vez finalizada la misión
• Sabotaje intencionado de sistemas críticos (casos documentados en los sectores del agua y la energía)

Estadísticas de 2024 (informe DBIR de Verizon): El 18 % de los incidentes de TI implican a un empleado o a un proveedor de confianza que ha sido comprometido.

Medida clave: Acceso «Zero Trust»: cada acceso debe estar autenticado (MFA), tener una duración limitada y ser auditado. Un subcontratista nunca debe tener un acceso permanente e ilimitado.

Sectores más expuestos en Francia​

1. Agua y saneamiento​

El sector del agua es el objetivo número uno de los ataques OT, según la ANSSI y Europol. Las razones:

• Infraestructura crítica con impacto directo en la salud pública
• Sistemas obsoletos (muchas RTU Sofrel de los años 2000-2010)
• Personal que, a menudo, carece de formación en ciberseguridad
• Presupuestos limitados para TI/OT en las administraciones locales

Incidente de referencia: En febrero de 2021, un atacante modificó el nivel de sosa cáustica en una planta de tratamiento de agua de Florida a través de un acceso no seguro a TeamViewer. Un operador atento detectó la anomalía a tiempo. Este mismo tipo de ataque es posible en cualquier sistema SCADA de agua que no cuente con un control de acceso riguroso.

En Francia, la normativa NIS2 clasifica a los operadores de agua que prestan servicio a más de 10 000 habitantes como entidades esenciales, con obligaciones reforzadas en materia de ciberseguridad desde el 17 de octubre de 2024.

2. Energía y redes eléctricas​

Los ataques contra las infraestructuras energéticas (producción, transporte y distribución) se han triplicado en Europa desde 2022. Los gestores de redes de distribución (GRD), los productores de energías renovables y las instalaciones industriales con subestaciones eléctricas se encuentran expuestos a estos ataques.

Protocolos en cuestión: IEC 60870-5-101/104, IEC 61850 GOOSE, DNP3 — todos ellos sin autenticación nativa en sus versiones básicas.

3. Industria farmacéutica y agroalimentaria​

Estos sectores combinan una normativa estricta (FDA 21 CFR Parte 11, GMP de la UE, Anexo 11) con sistemas de tecnología operativa (OT) críticos. La contaminación de un proceso de fabricación debido a la manipulación de los controladores lógicos programables (PLC) puede tener graves consecuencias para la salud.

Los ataques destinados a paralizar la producción (sabotaje competitivo) se están multiplicando en estos sectores de alto valor añadido.

4. Administraciones locales y ciudades inteligentes​

Las ciudades inteligentes instalan sensores, actuadores y pasarelas de IoT a gran escala, a menudo con presupuestos de seguridad insuficientes. El alumbrado público, la gestión del aparcamiento y los sistemas de transporte urbano están ahora todos conectados —y, potencialmente, son vulnerables—.

Las 10 medidas prioritarias para garantizar la seguridad de tu OT en 2026​

Nivel 1: Conceptos básicos (que hay que hacer de inmediato)​

1. Inventario de todos los activos de TI No se puede proteger lo que no se conoce. Realice un mapeo de todos los controladores lógicos programables (PLC), sistemas SCADA, interfaces hombre-máquina (HMI), pasarelas y equipos de red, incluyendo sus sistemas operativos, firmware, protocolos y conexiones. Utilice herramientas de detección pasivas (Nozomi Networks, Claroty, Dragos) que no perturben la red OT.

2. Segmentación de la red de TI/OT Aísla tu red OT de la red de TI mediante un cortafuegos industrial o una DMZ dedicada. La arquitectura de Purdue (niveles 0 a 5) sigue siendo la referencia. Como mínimo: prohíbe cualquier comunicación directa entre los ordenadores de sobremesa y los controladores de campo.

3. Eliminación de los accesos remotos no seguros Audita todos los accesos remotos existentes (VPN, TeamViewer, AnyDesk, RDP). Desactiva aquellos que no sean estrictamente necesarios. Para los accesos legítimos, implementa la autenticación multifactorial (MFA) y limita los horarios de acceso.

4. Cambio de las credenciales predeterminadas Todos los equipos (controladores lógicos programables, conmutadores, interfaces de usuario, routers) que se entreguen con credenciales predeterminadas (admin/admin, root/root) deben modificarse en la primera puesta en servicio. Anota las credenciales en un gestor de contraseñas seguro (Bitwarden, HashiCorp Vault).

5. Copia de seguridad de las configuraciones de los controladores lógicos programables Exporta y guarda los proyectos de TIA Portal, Unity Pro y Studio 5000 sin conexión, en una ubicación aislada de la red OT. En caso de ataque de ransomware, la restauración a partir de una copia de seguridad limpia debe poder realizarse en cuestión de horas, no de semanas.

Nivel 2: Consolidación (a planificar para un periodo de 6 a 12 meses)​

6. Autenticación fuerte en los accesos remotos Implemente una VPN industrial con autenticación multifactorial (MFA, TOTP o FIDO2) para todos los accesos remotos: técnicos internos, subcontratistas e integradores. Cada sesión debe grabarse (grabación de sesión) para fines de auditoría.

7. Supervisión del comportamiento de la red OT (NDR) Implemente un sensor de supervisión pasiva en su red OT para detectar anomalías en las comunicaciones: nuevos equipos, códigos de función Modbus inusuales, comunicaciones hacia direcciones IP desconocidas, cambios en el firmware. Las soluciones de Nozomi Networks, Claroty y Dragos son líderes del mercado.

8. Gestión de vulnerabilidades OT Suscríbete a los boletines de seguridad de tus fabricantes (Siemens ProductCERT, Schneider Electric PSIRT, Rockwell Automation Security Advisories). Evalúa las CVE críticas (CVSS ≥ 7,0) y planifica las correcciones para las próximas ventanas de mantenimiento.

9. Plan de respuesta ante incidentes de seguridad de las infraestructuras críticas (OT) Documenta el proceso específico de respuesta ante incidentes de seguridad de las infraestructuras críticas (OT): a quién contactar (ANSSI si se trata de una entidad NIS2), cómo aislar un segmento comprometido sin interrumpir la producción y los procedimientos de restauración a partir de las copias de seguridad. Realiza una simulación del plan una vez al año.

10. Formación de los equipos (Concienciación sobre seguridad OT) Los ingenieros de automatización no suelen haber recibido formación en ciberseguridad. Las sesiones de entre 2 y 4 horas sobre amenazas específicas de la OT, el phishing, la gestión de memorias USB y los accesos remotos seguros reducen significativamente el riesgo interno.

Cómo cumple Eziwan con los requisitos de seguridad de OT​

La pasarela y la plataforma Eziwan se diseñaron desde el principio teniendo en cuenta la seguridad operativa (OT) como un requisito no funcional crítico.

Arquitectura Zero Trust:

• Todas las comunicaciones entre la pasarela y la nube están cifradas con TLS 1.3 y cuentan con autenticación mutua mediante certificados X.509
• Cada pasarela dispone de un identificador único no modificable programado de fábrica (Device Identity)
• No hay ningún puerto de entrada abierto en la pasarela: las conexiones se inician exclusivamente desde el OT hacia la nube (modelo «push»)

Control de acceso remoto granular:

• VPN OpenVPN/IPSec con autenticación multifactorial (MFA) obligatoria para todos los accesos remotos
• Sesiones con límite de tiempo (caducidad automática configurable: 1 h, 4 h, 24 h)
• Registro de auditoría completo: quién se ha conectado, desde qué IP, durante cuánto tiempo y qué acciones se han realizado
• Acceso de subcontratistas: restricción por dirección IP de origen, por equipo de destino y por franja horaria

Supervisión OT integrada:

• Detección de anomalías en los valores Modbus (variación fuera de rango, valor estático, comunicación interrumpida)
• Alertas en tiempo real por SMS o correo electrónico ante cualquier anomalía detectada
• Historial completo de los valores para la investigación posterior al incidente

Alojamiento soberano:

• Infraestructura alojada en Francia (AWS París eu-west-3), ISO 27001
• Los datos no se transfieren fuera de la UE
• Cumplimiento del RGPD, la Directiva NIS2 y los requisitos de la ANSSI

Lista de comprobación de seguridad OT 2026​

Utiliza esta lista de comprobación para evaluar tu nivel de madurez en materia de ciberseguridad de la tecnología operativa (OT):

Gobernanza

• Mapa actualizado de los activos de OT (inventario completo)
• Política de seguridad de la OT formalizada y aprobada por la dirección
• Responsable de ciberseguridad de la OT designado (o MSSP especializado)
• Clasificación de los sistemas por nivel de criticidad (niveles de seguridad de la norma IEC 62443)

Arquitectura de red

• Segmentación IT/OT con cortafuegos/DMZ industrial
• VLAN dedicadas por zona Purdue (niveles 0, 1, 2, 3)
• Ningún equipo OT accesible directamente desde Internet
• Sin conexiones directas entre los puestos de trabajo de TI y los controladores de campo

Acceso e identidades

• Eliminación de las credenciales predeterminadas en todos los equipos
• Autenticación multifactorial (MFA) implementada en todos los accesos remotos (VPN, RDP, SCADA web)
• Acceso de los subcontratistas limitado (duración, ámbito, horario)
• Registro de auditoría de los accesos remotos archivado durante ≥ 1 año

Mantenimiento y actualizaciones

• Proceso de gestión de vulnerabilidades de TI documentado
• Copias de seguridad de las configuraciones de los controladores programables comprobadas y almacenadas fuera de la red
• Procedimiento de actualización del firmware planificado durante las ventanas de mantenimiento

Detección y respuesta

• Supervisión del comportamiento de la red OT (NDR o SIEM OT)
• Plan de respuesta ante incidentes de redes OT documentado y probado
• Procedimiento de notificación a la ANSSI (obligatorio para entidades NIS2)
• Contactos de emergencia en materia de ciberseguridad identificados (CERT interno o externo)

Preguntas frecuentes — Ciberseguridad de las tecnologías operativas y amenazas en la industria en 2026​

¿Puede un ransomware que afecte a la red informática llegar a los controladores de la tecnología operativa (OT)?

Sí, si las redes OT e IT están interconectadas sin una segmentación estricta. Ese es precisamente el vector de propagación de NotPetya (2017) y de numerosos incidentes industriales que se han producido desde entonces. El ransomware cifra los servidores de TI, se propaga a través de Active Directory y los recursos compartidos de red, y si la red OT se encuentra en la misma LAN o es accesible a través del mismo dominio de Windows, las estaciones de supervisión SCADA y, en ocasiones, los controladores lógicos programables (PLC) se ven afectados.

¿Pueden los autómatas de Siemens o Schneider infectarse directamente con un malware?

Los autómatas industriales no se «infectan» en el sentido clásico (no tienen un sistema de archivos estándar ni permiten la ejecución de código arbitrario a través de los vectores habituales). Sin embargo, pueden reprogramarse de forma remota si se consigue acceso a ellos (véase Stuxnet). El riesgo real suele ser más bien la paralización o la manipulación de los autómatas a través de un operador comprometido o de un acceso remoto mal protegido, más que una infección directa del firmware.

¿Cuál es la obligación de notificación a la ANSSI en caso de incidente de seguridad operativa (OT) en el marco de la NIS2?

Para las entidades sujetas a la NIS2 (entidades esenciales y entidades importantes), la obligación es la siguiente: notificación preliminar en un plazo de 24 horas si el incidente puede tener un impacto significativo, informe provisional en un plazo de 72 horas e informe final en el plazo de un mes. La notificación a la ANSSI puede realizarse a través del formulario específico disponible en su página web. El incumplimiento de esta obligación conlleva sanciones que pueden ascender a 10 millones de euros o al 2 % de la facturación mundial.

¿Son muy costosas las soluciones de segmentación de redes OT para una PYME?

No. Cualquier pequeña o mediana empresa puede acceder a una segmentación básica (VLAN OT/IT en un conmutador gestionable de entre 200 y 400 €, con reglas restrictivas entre VLAN). Para un nivel superior, los cortafuegos industriales compactos (Stormshield SNi40, Fortinet FortiGate Rugged) tienen un precio inicial de entre 500 y 800 €. La segmentación es la solución más rentable en ciberseguridad OT, ya que contiene los incidentes antes de que se propaguen.

¿Es necesario desactivar los protocolos no seguros, como Modbus TCP, en la red OT?

En la red OT interna, Modbus TCP puede permanecer activo: su falta de autenticación es aceptable en una red físicamente aislada y segmentada. El error crítico es exponer el puerto Modbus (502) en Internet o en la red de TI sin control. La prioridad es garantizar que no se pueda acceder a ningún puerto OT desde el exterior, no necesariamente sustituir Modbus por un protocolo más seguro a corto plazo.

Conclusión​

La ciberseguridad de los sistemas OT ya no es una opción para las empresas industriales francesas. La Directiva NIS2, los requisitos de la norma IEC 62443 y la realidad de los incidentes (ransomware, ataques a las redes de abastecimiento de agua, sabotajes a las infraestructuras energéticas) hacen que la protección de los sistemas OT sea imprescindible.

La buena noticia: al contrario de lo que piensan muchos empresarios, no es necesario replantearlo todo para lograr avances significativos. Las cinco medidas fundamentales que se presentan en esta guía —inventario, segmentación, eliminación de accesos no seguros, credenciales predeterminadas y copias de seguridad— reducen en un 80 % el riesgo de que se produzca un incidente grave, con un coste y una complejidad razonables.

Tu próximo paso: realiza una auditoría de seguridad de tu infraestructura (Eziwan ofrece una auditoría gratuita de tus conexiones remotas) e identifica las tres medidas prioritarias que debes poner en práctica en los próximos 30 días.

Artículo redactado por el equipo de Eziwan. Eziwan es un proveedor de pasarelas IIoT y de plataformas de supervisión industrial para pymes, administraciones públicas e integradores de automatización franceses. Descubre nuestro enfoque de la seguridad OT →

Recursos adicionales​

• Ciberseguridad industrial — panorama general de las soluciones de protección para redes OT
• Ciberseguridad del acceso remoto a OT — proteger las conexiones remotas a los ICS
• NIS2 para la industria — obligaciones normativas y sanciones para las empresas industriales
• VPN industrial — protección de los accesos remotos con cifrado robusto

Sin embargo, la norma tiene fama de ser compleja y extensa. Esta guía práctica recoge lo esencial para las empresas francesas: lo que exige concretamente la norma, cómo cumplirla y las prioridades para 2026.

¿Qué es la norma IEC 62443?​

La norma IEC 62443 (anteriormente ISA-99) es una familia de normas elaboradas por la ISA (Sociedad Internacional de Automatización) y publicadas por la IEC. Abarca la ciberseguridad de los sistemas de automatización y control industrial (IACS).

La estructura de la norma​

La norma se divide en cuatro series:

Para una empresa industrial francesa que desee cumplir con la norma NIS2, las partes más relevantes son:

• IEC 62443-2-1: políticas y procedimientos de seguridad
• IEC 62443-3-3: requisitos de seguridad de los sistemas
• IEC 62443-4-2: requisitos de los componentes (para evaluar sus equipos)

Los niveles de seguridad (SL): entender los niveles de seguridad​

El concepto central de la norma IEC 62443 es el nivel de seguridad, es decir, el nivel de protección requerido en función de la criticidad del sistema.

Los 4 niveles​

Para la gran mayoría de las empresas industriales francesas: el nivel SL 2 es el objetivo adecuado. El SL 3 está reservado a los operadores de importancia vital (OIV) con sistemas muy críticos. El SL 4 se destina casi exclusivamente a las infraestructuras militares y nucleares.

¿Cómo determinar el SL necesario para tu sistema?​

El proceso consta de tres pasos:

1. Identificar las zonas y los conductos (IEC 62443-3-2)

Empieza por dividir tus sistemas OT en zonas de seguridad (Security Zones):

• Zona de producción (controladores lógicos, sensores, interfaces hombre-máquina locales)
• Zona de supervisión (SCADA, servidores de historial)
• Zona DMZ OT (interfaz TI/OT)
• Zona de acceso remoto

A continuación, identifica los conductos (Conduits): las vías de comunicación entre zonas (VPN de acceso remoto, enlaces SCADA, pasarelas IT/OT).

2. Evaluar el nivel de criticidad de cada zona (CASC)

Para cada área, evalúa las consecuencias de una violación de la seguridad según los criterios CASC:

• Confidencialidad: ¿deben mantenerse secretos los datos?
• Integridad: ¿podría causar daños una modificación de los datos o las órdenes?
• Disponibilidad: ¿una interrupción del sistema causaría perjuicios significativos?
• Seguridad: ¿podría un fallo poner en peligro vidas humanas?

3. Definir el SL objetivo por zona

El nivel de criticidad evaluado determina el SL objetivo: una zona con controladores de seguridad (SIL) en una instalación SEVESO tendrá como objetivo el SL 3, mientras que una zona de supervisión de una estación de bombeo de agua potable suele tener como objetivo el SL 2.

Los 7 requisitos fundamentales (Foundational Requirements) de la norma IEC 62443-3-3​

La norma IEC 62443-3-3 define siete requisitos fundamentales (RF) para los sistemas. Cada RF se desglosa en requisitos detallados según el nivel SL.

FR 1 — Control de identificación y autenticación​

Lo que esto significa en la práctica:

• Cada usuario y cada equipo deben identificarse de forma única (no se admiten cuentas compartidas)
• Deben cambiarse las contraseñas predeterminadas de los equipos de tecnología operativa (OT)
• Para el Nivel 2: autenticación de dos factores (MFA) para los accesos remotos

Aplicación Eziwan: cada técnico dispone de una clave VPN OpenVPN/IPSec individual. La autenticación MFA está disponible en la plataforma en la nube.

FR 2 — Control de uso​

Qué significa esto:

• Cada usuario solo tiene acceso a los recursos necesarios para desempeñar sus funciones (principio del mínimo privilegio)
• Las acciones realizadas en los equipos críticos requieren una autorización explícita

Aplicación: el sistema RBAC de Eziwan permite definir derechos de acceso por centro, por equipo y por franja horaria para cada técnico.

FR 3 — Integridad de los datos​

Qué significa esto:

• Los datos transmitidos entre equipos no deben poder modificarse durante la transmisión
• La integridad de las configuraciones de los controladores debe poder verificarse

Aplicación: todas las comunicaciones de Eziwan se cifran mediante OpenVPN (autenticación + cifrado). Las configuraciones están firmadas digitalmente.

FR 4 — Confidencialidad de los datos​

Qué significa esto:

• Los datos sensibles (recetas, parámetros de producción, datos personales) deben cifrarse tanto en tránsito como en reposo

Aplicación: cifrado AES-256-GCM de todas las comunicaciones; datos almacenados cifrados en la infraestructura en la nube francesa.

FR 5 — Flujo de datos restringido​

Qué significa esto:

• Las comunicaciones entre zonas de seguridad deben controlarse y limitarse al mínimo necesario
• No debe haber comunicación directa entre la zona de TI de oficina y los controladores de OT sin una DMZ

Aplicación Eziwan: arquitectura «zero-inbound-port»: la red OT nunca queda expuesta directamente. El tráfico pasa por la nube de Eziwan, que actúa como punto de control centralizado.

FR 6 — Respuesta ante los acontecimientos​

Qué significa esto:

• Los incidentes de seguridad deben detectarse, registrarse y gestionarse
• En el caso de la Directiva NIS2: notificación obligatoria en un plazo de 24 horas para las entidades esenciales

Aplicación: registro completo de todos los eventos de seguridad, alertas configurables sobre anomalías en la conexión, exportación de registros a SIEM.

FR 7 — Disponibilidad de recursos​

Qué significa esto:

• El sistema debe seguir estando disponible incluso en caso de intento de ataque (protección contra ataques DoS)
• Deben existir mecanismos de copia de seguridad y recuperación

Aplicación: Conmutación por error de doble SIM, infraestructura en la nube con varias zonas de disponibilidad (AZ), copias de seguridad automáticas de las configuraciones de la pasarela.

El proceso de cumplimiento de la norma IEC 62443 en 6 pasos​

A continuación se presenta un enfoque pragmático para las empresas industriales francesas que deben cumplir con la normativa NIS2 haciendo referencia a la norma IEC 62443.

Paso 1: Inventario de los activos OT (3-5 días)​

Enumera todos tus sistemas OT:

• Controladores lógicos programables (PLC), sistemas de control distribuido (DCS) y unidades de teleoperación (RTU)
• Interfaces hombre-máquina (IHM) y puestos de operador
• Servidores SCADA y sistemas de registro histórico
• Equipos de red OT (conmutadores, enrutadores, cortafuegos)
• Pasarelas y equipos de conectividad

Para cada activo: versión del firmware/software, conectividad de red, fecha de la última actualización de seguridad y accesos remotos existentes.

Paso 2: Cartografía de las zonas y los conductos (2-3 días)​

Dibuja el esquema de red OT actual con las zonas de seguridad y los flujos de comunicación. Identifica:

• Las interfaces IT/OT existentes
• Los accesos remotos (VPN, RDP, TeamViewer)
• Los equipos con puertos expuestos a Internet (busca tus direcciones IP en Shodan)

Paso 3: Análisis de riesgos simplificado (1 semana)​

Para cada área, evalúa:

• Grado de criticidad (impacto de un ataque: producción, seguridad, medio ambiente)
• Amenaza (¿quién podría querer atacar tu sector?)
• Vulnerabilidad (estado actual de la seguridad de la área)

Prioriza las áreas que deben tratarse en primer lugar: criticidad alta + vulnerabilidad alta = prioridad 1.

Paso 4: Definición del nivel SL objetivo por zona​

Según el análisis de riesgos:

• Zonas de producción estándar → SL 2
• Zonas con controladores de seguridad SIL → SL 3
• Zonas de oficina OT (estaciones de ingeniería) → SL 1 a SL 2

Etapa 5: Plan de corrección (con una duración de entre 6 y 18 meses)​

Para cada área cuyo nivel actual sea inferior al nivel objetivo, define las medidas correctivas:

Medidas prioritarias SL 2:

1. Eliminar todas las contraseñas predeterminadas de los equipos de tecnología operativa (OT).
2. Sustituir los accesos remotos no seguros (RDP expuesto, TeamViewer) por una VPN de confianza cero.
3. Implantar la autenticación multifactorial (MFA) para todos los accesos remotos.
4. Crear cuentas nominativas (sin cuentas genéricas compartidas)
5. Activar el registro de accesos en todos los equipos que lo permitan
6. Segmentar la red OT de la red informática de oficina (DMZ o VLAN con ACL)

Medidas importantes SL 2: 7. Actualizar el firmware de los equipos de TI (pasarelas, conmutadores industriales) 8. Documentar los procedimientos de respuesta ante incidentes 9. Formar a los equipos de mantenimiento sobre los riesgos de ciberseguridad en los sistemas de TI

Paso 6: Evaluación y mejora continua​

El cumplimiento de la norma IEC 62443 no es un proyecto puntual, sino un proceso continuo. Planifica:

• Revisión anual del inventario y del mapeo
• Prueba de penetración anual (o semestral) de los accesos remotos
• Actualización del plan de corrección tras cada incidente o cambio en la infraestructura

IEC 62443 y NIS2: lo que deben hacer las entidades francesas​

La Directiva NIS2 (transpuesta en Francia mediante la ley de 8 de octubre de 2024) no menciona explícitamente la norma IEC 62443, pero las medidas que impone se ajustan directamente a ella.

Las entidades afectadas​

Entidades esenciales: energía (electricidad, gas, petróleo), transporte (aéreo, ferroviario, marítimo, por carretera), banca, infraestructuras financieras, agua (suministro, aguas residuales), sanidad, infraestructuras digitales.

Sectores importantes: servicios postales, gestión de residuos, productos químicos, alimentación, fabricación industrial (dispositivos médicos, equipos electrónicos, mecánica), proveedores digitales.

Las medidas de ciberseguridad exigidas (art. 21 de la Directiva NIS2)​

1. Política de seguridad de los sistemas de información (IEC 62443-2-1)
2. Gestión de incidentes: detección, respuesta y notificación en un plazo de 24 horas (IEC 62443-2-1, FR 6)
3. Continuidad de la actividad: copias de seguridad, planes de recuperación (IEC 62443-3-3 FR 7)
4. Seguridad de la cadena de suministro: seguridad de los subcontratistas con acceso a la red operativa (IEC 62443-2-4)
5. Seguridad en las adquisiciones: evaluación de seguridad antes de la implantación de equipos de TI operativa (IEC 62443-4-2)
6. Formación y sensibilización: todo el personal con acceso a los sistemas de TI operativa
7. Criptografía y cifrado: comunicaciones cifradas, datos sensibles protegidos
8. Control de acceso: autenticación fuerte, RBAC, registro de eventos (IEC 62443-3-3 FR 1, FR 2)
9. Seguridad de los recursos humanos: verificación de antecedentes, procedimientos de cese
10. Evaluación de riesgos: proceso formal documentado (IEC 62443-3-2)

Los 5 errores que hay que evitar en un proyecto conforme a la norma IEC 62443​

Error 1: Empezar por la documentación antes del inventario​

Muchas empresas encargan la elaboración de políticas de seguridad antes de haber realizado un inventario real. El resultado: documentos teóricos alejados de la realidad sobre el terreno. Empieza siempre por el inventario y la cartografía.

Error 2: Tratar la norma IEC 62443 como un proyecto de TI​

La seguridad de los sistemas de control industrial (OT) presenta unas limitaciones específicas: los equipos no pueden desconectarse para realizar actualizaciones, los protocolos son antiguos (Modbus de 1979) y los equipos están formados por técnicos en automatización, no por informáticos. Involucra a los equipos de producción desde el principio.

Error 3: Aspirar al nivel SL 3 o SL 4 sin una razón justificada​

Los niveles SL 3 y SL 4 tienen requisitos muy estrictos (autenticación fuerte en los controladores, cifrado de todos los protocolos industriales, incluido Modbus) que a menudo obligan a sustituir los equipos de tecnología operativa (OT). Para la mayoría de las empresas industriales, el nivel SL 2 es el objetivo realista y suficiente.

Error 4: Descuidar la seguridad de los accesos de terceros​

Los incidentes de seguridad informática más habituales están relacionados con los accesos remotos de los subcontratistas de mantenimiento. Hay que dar prioridad a la seguridad de los accesos de terceros (cuentas nominativas, autenticación multifactorial, trazabilidad) antes de abordar los aspectos más técnicos.

Error 5: Pensar que el cumplimiento de la norma NIS2 equivale al cumplimiento de la norma IEC 62443​

La NIS2 impone medidas de seguridad, pero no certifica el cumplimiento de la norma IEC 62443. La certificación según la norma IEC 62443 (por parte de un organismo acreditado) es independiente del cumplimiento de la NIS2. Para la mayoría de las empresas industriales, basta con un cumplimiento documentado de la norma IEC 62443, sin necesidad de una certificación formal, para cumplir con la NIS2.

Preguntas frecuentes​

¿Es obligatorio obtener la certificación IEC 62443 para cumplir con la NIS2? No. La directiva NIS2 impone medidas técnicas y organizativas de seguridad, pero no exige una certificación formal según la norma IEC 62443 (que otorgan organismos acreditados como TÜV, Bureau Veritas, etc.). Sin embargo, documentar que sus prácticas están en consonancia con la norma IEC 62443 es una excelente forma de demostrar su cumplimiento de la NIS2 ante la ANSSI.

¿Por qué parte de la norma IEC 62443 debe empezar una PMI industrial? En el caso de una PMI, hay que empezar por la norma IEC 62443-2-1 (políticas y procedimientos) y la norma IEC 62443-3-3 (requisitos del sistema para los niveles de seguridad 1 y 2). Son las partes más directamente aplicables y las más solicitadas por los clientes. Las partes 4.x (componentes) interesan más bien a los fabricantes de equipos.

¿Qué es una zona de seguridad (Security Zone) según la norma IEC 62443? Una zona de seguridad es un grupo de sistemas que comparten el mismo nivel de seguridad requerido, separados de otras zonas mediante conductos (canales de comunicación controlados). Ejemplo: Zona 1 = controladores de producción (SL2), Zona 2 = SCADA (SL2), Zona 3 = TI (SL1). Las comunicaciones entre zonas deben pasar obligatoriamente por un cortafuegos o una DMZ controlada.

¿Cómo puedo determinar el nivel de seguridad (SL) que debo fijar como objetivo para mi instalación? El SL objetivo depende de las consecuencias de un incidente: SL1 para un riesgo limitado (parada temporal de un proceso no crítico), SL2 para un riesgo significativo (impacto en la producción o en la seguridad de las personas) y SL3 para sistemas críticos (energía, agua, salud). La mayoría de las pymes industriales se fijan como objetivo el SL2 para sus sistemas SCADA y el SL1 para los sistemas de apoyo.

¿Abarca la norma IEC 62443 la seguridad de los accesos remotos mediante VPN? Sí. La norma IEC 62443-3-3 aborda explícitamente la autenticación (SR 1.1, SR 1.2), el cifrado de las comunicaciones (SR 4.1), la gestión de sesiones (SR 1.3) y la trazabilidad (SR 2.8). Una VPN OpenVPN/IPSec con autenticación mediante certificado y registro cumple los requisitos de los niveles de seguridad 1 y 2 en estos aspectos.

Recursos adicionales​

• Guía: NIS2 para la industria — obligaciones, sanciones, plan de acción
• Blog: Lista de verificación de cumplimiento de la NIS2 — 30 puntos de control
• Blog: ciberseguridad OT — amenazas e incidentes en 2026
• Blog: cero puertos de entrada — arquitectura OT segura
• Documentación: seguridad del acceso remoto de Eziwan

Recursos adicionales​

• Ciberseguridad industrial — soluciones de protección para redes OT e ICS
• NIS2 para la industria — obligaciones normativas y plan de cumplimiento
• Ciberseguridad del acceso remoto a la OT — proteger el acceso remoto a los controladores lógicos programables
• Acceso remoto industrial — arquitecturas «zero-trust» conformes con la norma IEC 62443
• Guía para proteger la red OT — segmentación, VPN y cumplimiento de la normativa NIS2

Esta guía ofrece un método estructurado para calcular el retorno de la inversión de un proyecto de supervisión del IoT industrial, con ejemplos cuantificados extraídos de implantaciones reales.

¿Por qué se suele subestimar el ROI del IoT?​

La mayoría de los cálculos del ROI del IoT se centran en los ahorros directos y evidentes. Sin embargo, el IoT industrial genera beneficios en cuatro categorías que a menudo se subestiman:

1. Ahorros directos: costes evitados (desplazamientos, intervenciones de emergencia, averías no planificadas)
2. Aumento de la productividad: tiempo liberado gracias a la automatización de la supervisión
3. Reducción de riesgos: costes de incidentes evitados (sanciones contractuales, multas reglamentarias, daños a la reputación)
4. Valor de los datos: optimizaciones que se hacen posibles gracias a los nuevos datos disponibles

Los proyectos que solo tienen en cuenta la categoría 1 atribuyen sistemáticamente un ROI demasiado bajo al IoT.

La fórmula del ROI del IoT industrial​

El ROI se calcula para un periodo determinado (normalmente 1, 2 o 3 años):

ROI (%) = [(Beneficios totales - Costes totales) / Costes totales] × 100

Costes totales = Inversión inicial + Costes recurrentes

• Inversión inicial: material (pasarelas, sensores), instalación, configuración, formación
• Costes recurrentes: suscripciones a la plataforma, tarjetas SIM M2M, mantenimiento del material

Beneficios totales = suma de los ahorros y las ganancias en las 4 categorías

Categoría 1: Ahorros directos​

Reducción de los desplazamientos de los técnicos​

A menudo es la partida más importante y la más fácil de cuantificar.

Coste real de una visita de un técnico (Francia, 2026):

Cómo la supervisión del IoT reduce los desplazamientos:

• Diagnóstico a distancia: el técnico determina la causa del problema antes de salir → lleva consigo la pieza adecuada en lugar de tener que hacer dos desplazamientos
• Se evitan las falsas alarmas: sin supervisión, cualquier alerta del operador implica un desplazamiento. Con el IoT, el panel de control distingue las averías reales de las señales falsas
• Intervenciones programadas: las alertas predictivas permiten agrupar las intervenciones en una misma instalación en una única visita planificada

Ahorros habituales observados:

• Entidades de suministro de agua: entre 1,5 y 3 desplazamientos evitados por estación de bombeo al año
• Industrias con múltiples centros: entre 2 y 4 intervenciones de emergencia convertidas en mantenimiento planificado por centro al año
• Parques fotovoltaicos: reducción del 60-70 % de las visitas de mantenimiento reactivo

Reducción de las paradas no programadas​

Una avería imprevista cuesta, de media, entre 3 y 5 veces más que una intervención preventiva equivalente.

Coste de una parada no planificada (ejemplo de una pyme industrial):

• Pérdidas de producción: entre 500 y 5 000 €/hora (según el sector)
• Mano de obra de urgencia (+50 % sobre la tarifa de guardia): entre 500 y 1 500 €
• Piezas urgentes (coste × 2 respecto al stock normal): +200-500 €
• Total por parada de 4 horas en una pyme: de 2 500 a 22 000 €

Gracias a la supervisión mediante el Internet de las cosas (IoT) y a las alertas tempranas, los indicadores de anomalías se detectan antes de que se produzca una avería: la vibración aumenta progresivamente, la temperatura supera su umbral o la corriente del motor aumenta de forma anómala. La intervención se planifica durante una parada programada.

Rentabilidad de la inversión en prevención: evitar entre 1 y 2 paradas no planificadas por centro al año suele bastar para amortizar la inversión total en IoT.

Categoría 2: Aumento de la productividad​

Tiempo de trabajo del operario que se libera gracias a la automatización de la supervisión​

Sin la supervisión del IoT, los operadores y técnicos dedican tiempo a:

• Realizar rondas de vigilancia periódicas
• Introducir manualmente las lecturas en hojas de cálculo
• Elaborar informes de rendimiento
• Atender llamadas telefónicas para notificar averías

Estimación del tiempo ahorrado (para 20 equipos supervisados):

14 horas/semana × coste horario total (60 €) = 840 €/semana de ahorro en productividad, lo que supone 43 000 €/año.

Reducción del tiempo de diagnóstico​

Gracias al historial de datos disponible en la nube, el diagnóstico de una avería lleva entre 10 y 15 minutos, en lugar de entre 1 y 2 horas in situ. El técnico consulta la curva de tendencia, identifica la anomalía y planifica una intervención específica.

Categoría 3: Reducción de riesgos​

Incumplimiento normativo evitado​

En los sectores sujetos a la Directiva NIS2 (agua, energía, transporte y sanidad), las multas por incumplimiento pueden alcanzar el 2 % de la facturación anual mundial en el caso de una entidad esencial.

La supervisión del IoT, con registro de accesos, trazabilidad de las intervenciones e informes de auditoría automáticos, reduce significativamente el riesgo de incumplimiento normativo.

Multas por incumplimiento del servicio evitadas​

En el caso de las empresas sujetas a un SLA (proveedores de mantenimiento, operadores de redes), cada hora de indisponibilidad puede dar lugar a sanciones contractuales.

Ejemplo: una empresa gestora de una red de agua con una multa de 2 000 € por cada hora de incumplimiento de los requisitos de presión. Una avería detectada 4 horas antes gracias al IoT = 8 000 € en multas evitadas.

Categoría 4: Valor de los datos​

Optimización del consumo energético​

Los datos sobre el consumo eléctrico recopilados en tiempo real permiten identificar los picos de consumo innecesarios, los equipos que no funcionan de forma óptima y las oportunidades de reducción de la demanda.

Ahorro habitual: entre un 5 % y un 15 % de reducción en la factura eléctrica de los equipos supervisados.

Ejemplo concreto: una estación de bombeo con bombas que funcionan a plena potencia las 24 horas del día. El análisis del IoT revela que la demanda nocturna es un 40 % inferior. Reducción de la velocidad de las bombas mediante un variador de velocidad (ya instalado) → ahorro del 22 % en el consumo eléctrico.

Decisiones basadas en datos frente a la intuición​

Antes del IoT, las decisiones de mantenimiento se basaban en la experiencia y en los registros en papel. Tras la llegada del IoT, se basan en datos reales:

• Frecuencia de mantenimiento adaptada al uso real (en lugar de un calendario fijo)
• Priorización de las inversiones basada en los datos de rendimiento real
• Demostración cuantificada del impacto de las mejoras realizadas

Ejemplos de cálculo del ROI por sector​

Servicio de agua — red de 40 estaciones de bombeo​

Inversión inicial:

• 40 pasarelas IoT: 40 × 400 € = 16 000 €
• Instalación (0,5 días/técnico/emplazamiento): 40 × 200 € = 8 000 €
• Total: 24 000 €

Costes recurrentes anuales:

• Suscripciones a plataformas + tarjetas SIM: 40 × 480 €/año = 19 200 €/año

Ahorro anual:

• Desplazamientos evitados (2 por estación al año × 200 €): 40 × 400 € = 16 000 €
• Guardias evitadas (1 por estación al año × 300 €): 40 × 300 € = 12 000 €
• Paradas no programadas evitadas (0,5 al año × 3 000 €): 20 × 3 000 € = 60 000 €
• Aumento de la productividad de los operarios (5 h/semana liberadas × 60 €): 15 600 €
• Ahorro total: 103 600 €/año

ROI del primer año: (103 600 - 24 000 - 19 200) / 43 200 = 140 % Período de recuperación de la inversión: de 4 a 5 meses

PYME industrial — 3 centros de producción​

Inversión inicial:

• 15 pasarelas (5 por emplazamiento): 15 × 400 € = 6 000 €
• Instalación y configuración: 3 000 €
• Total: 9 000 €

Costes recurrentes anuales:

• Suscripciones + tarjetas SIM: 15 × 480 € = 7 200 € al año

Ahorro anual:

• Desplazamientos entre centros evitados: 24 desplazamientos × 250 € = 6 000 €
• Paradas evitadas (1,5 por centro al año × 8 000 €): 36 000 €
• Reducción del mantenimiento preventivo (20 % de las intervenciones): 12 000 €
• Ahorro total: 54 000 € al año

ROI del primer año: (54 000 - 9 000 - 7 200) / 16 200 = 234 % Período de recuperación de la inversión: 3 meses

Los factores que maximizan el ROI​

1. Empezar por las instalaciones y los equipos más críticos​

El ROI es máximo en los equipos con un alto coste por avería y en las instalaciones más alejadas (alto coste de desplazamiento). Prioriza:

• Bombas críticas para el suministro de agua potable
• Equipos en producción continua (alto coste por hora de parada)
• Instalaciones situadas a más de una hora de desplazamiento del técnico de guardia

2. Integrar la supervisión en los procesos de mantenimiento​

Un sistema de IoT que no esté integrado en los flujos de trabajo de mantenimiento genera poco valor. El retorno de la inversión (ROI) es máximo cuando:

• Las alertas de IoT activan automáticamente órdenes de trabajo en el sistema de gestión de mantenimiento (GMAO)
• Los informes de IoT sustituyen a los informes manuales
• Los técnicos utilizan el acceso remoto antes de cada desplazamiento (para realizar un diagnóstico previo)

3. Medir y optimizar de forma continua​

Establece unos KPI de seguimiento desde el inicio:

• Número de desplazamientos evitados (en comparación con los datos históricos anteriores a la implantación del IoT)
• MTTR (Mean Time To Repair): tiempo medio de resolución de incidencias
• OEE (Overall Equipment Effectiveness) para las líneas de producción
• Número de paradas no planificadas

Compara los resultados trimestralmente para identificar oportunidades de mejora.

Los errores que reducen el ROI​

Subestimar los costes de la implementación inicial​

Una instalación mal hecha conlleva costosas repeticiones del trabajo. Prevé entre el 30 % y el 50 % del coste del material para la instalación, la configuración y la formación.

Descuidar la gestión del cambio​

Para obtener el máximo retorno de la inversión, es necesario que los equipos adopten realmente las nuevas prácticas. Un técnico que no utilice el acceso remoto antes de desplazarse no ahorra nada.

Elegir una plataforma no escalable​

El coste de migrar de una plataforma de IoT a otra suele ser superior al coste inicial. Comprueba la escalabilidad, la API abierta y la sostenibilidad del proveedor antes de comprometerte.

Conclusión​

El retorno de la inversión (ROI) del IoT industrial rara vez es el problema que se suele pensar: en la gran mayoría de las implantaciones industriales, se alcanza en menos de 12 meses, a menudo en un plazo de entre 3 y 6 meses.

La verdadera pregunta no es «¿es rentable?», sino «¿por dónde empezar?». La respuesta: empieza por entre 5 y 10 instalaciones o equipos de alta criticidad, mide el ROI real durante tres meses y, a continuación, implementa la solución a gran escala basándote en datos concretos.

Preguntas frecuentes​

¿Cómo calcular el ROI de un proyecto de IoT industrial sin datos históricos de averías? Utiliza las estimaciones del sector como punto de partida: una avería no planificada cuesta, de media, entre el 5 % y el 15 % del valor anual de producción en la industria manufacturera. En el caso de las empresas de suministro de agua, hay que contar con entre 2 500 y 5 000 € por intervención de emergencia no planificada. Ajuste las estimaciones con sus datos reales tras tres meses de implantación piloto.

¿Es el ROI del IoT industrial el mismo para una pyme que para un gran grupo empresarial? No. Los grandes grupos empresariales se benefician de economías de escala en las pasarelas y las suscripciones, y cuentan con más equipos críticos, por lo que el ROI absoluto es mayor. En cambio, el ROI relativo (% de ahorro frente al presupuesto de mantenimiento) suele ser mejor para las pymes, ya que no cuentan con recursos informáticos dedicados y ahorran proporcionalmente más al automatizar la supervisión.

¿Hay que calcular el ROI antes de poner en marcha una prueba piloto o después? Ambas cosas. Antes: un ROI estimado justifica el presupuesto de la prueba piloto ante la dirección. Después: el ROI medido (con datos reales) justifica el despliegue completo y da credibilidad a las hipótesis iniciales. La experiencia demuestra que el ROI real suele ser superior al estimado, ya que durante el proyecto piloto surgen beneficios inesperados (mejor visibilidad, decisiones más rápidas, etc.).

¿Qué costes hay que tener en cuenta en un proyecto de IoT industrial? Los costes que suelen subestimarse: instalación del cableado RS-485 (prever entre 200 y 500 € por emplazamiento), formación de los equipos de mantenimiento (2 días como mínimo), configuración del SCADA (integración de los nuevos datos en las herramientas existentes) y gestión del cambio (lograr que los técnicos de campo adopten las nuevas herramientas).

Recursos para profundizar en el tema​

• Blog: mantenimiento predictivo IIoT — de los datos de los sensores a la alerta
• Blog: supervisión del agua y el saneamiento — 300 estaciones 4G
• Blog: supervisión industrial a distancia — guía completa 2026
• Blog: SCADA en la nube frente a SCADA local — guía de decisión
• Blog: Zero-Touch Provisioning — implementar 50 routers en 2 horas

Recursos adicionales​

• Calculadora de ROI de Eziwan — calcula el retorno de la inversión de tu proyecto de IoT industrial
• Guía de ROI del IoT industrial — metodología y casos prácticos para calcular el ROI del IIoT
• Mantenimiento predictivo del IIoT — Reducir los costes de mantenimiento gracias al IoT predictivo
• Soluciones industriales de Eziwan — gama completa de soluciones para maximizar el ROI industrial
• Monitorización de equipos industriales — supervisión de activos industriales para optimizar el rendimiento

Esta guía abarca el tema en su totalidad: definiciones, arquitecturas técnicas, elección de protocolos, ciberseguridad y aplicación práctica para implementaciones de entre 1 y 1 000 emplazamientos.

¿Qué es la supervisión industrial a distancia?​

La supervisión industrial a distancia (o telesupervisión industrial) hace referencia al conjunto de tecnologías que permiten:

• Visualizar el estado de los equipos industriales (máquinas, controladores lógicos programables, sensores) desde una ubicación remota
• Recibir alertas en tiempo real en caso de anomalía, superación de umbrales o avería
• Intervenir a distancia en los equipos (modificación de parámetros, reinicio, reconfiguración)
• Analizar los datos históricos para optimizar el rendimiento y anticipar las tareas de mantenimiento

Se aplica a todos los sectores: industria manufacturera, agua y saneamiento, energía, agricultura y edificios técnicos.

Supervisión, SCADA e IIoT: ¿en qué se diferencian?​

Estos términos suelen confundirse. Estas son las diferencias:

En 2026, las fronteras se difuminan: las plataformas modernas de IIoT (entre ellas, Eziwan) ofrecen capacidades SCADA en la nube al tiempo que integran los protocolos industriales tradicionales (Modbus, OPC-UA).

Las arquitecturas de supervisión remota​

Arquitectura 1: supervisión centralizada en la nube (recomendada)​

Ventajas:

• Implementación rápida, sin necesidad de infraestructura de servidores in situ
• Acceso desde cualquier navegador, tableta o smartphone
• Escalabilidad de 1 a miles de sitios web sin necesidad de rediseñar la arquitectura
• Actualizaciones centralizadas sin intervención sobre el terreno

Casos de uso típicos: empresas de suministro de agua, redes de distribución de energía, parques fotovoltaicos, flotas de equipos industriales dispersos geográficamente.

Arquitectura 2: SCADA local con acceso remoto mediante VPN​

Ventajas:

• Los datos permanecen en la infraestructura informática de la empresa
• Compatible con los sistemas SCADA existentes (Wonderware, WinCC, Vijeo Citect)
• Control total sobre el alojamiento y la seguridad

Casos de uso típicos: grandes empresas industriales con un sistema SCADA ya implantado, sectores industriales con restricciones en materia de soberanía de los datos.

Arquitectura 3: computación en el borde + nube híbrida​

En el caso de las instalaciones que generan grandes cantidades de datos (líneas de producción, prensas, máquinas CNC), el «edge computing» permite procesar localmente los datos críticos y enviar a la nube únicamente los datos sintéticos.

Los protocolos industriales de la supervisión remota​

Modbus RTU/TCP: el estándar universal​

Modbus es el protocolo más extendido en la industria. Existe en dos variantes:

• Modbus RTU: a través de un enlace serie RS-485. Hasta 32 equipos en 1 200 m de cable. Velocidad de transmisión de 9 600 a 115 200 bps.
• Modbus TCP: encapsulación Modbus sobre Ethernet/IP. Puerto 502. Velocidad limitada únicamente por la red.

Lo que permite supervisar Modbus: todos los controladores lógicos programables (PLC) modernos (Siemens S7, Schneider Modicon, ABB, Allen Bradley), la gran mayoría de los contadores de energía, variadores de velocidad y sensores industriales.

Limitación: únicamente arquitectura maestro/esclavo. No hay notificación de eventos: el maestro debe consultar (poll) a los esclavos periódicamente.

MQTT: el protocolo del IIoT​

MQTT (Message Queuing Telemetry Transport) es un protocolo ligero de tipo «publicar/suscribirse» diseñado para conexiones con poco ancho de banda.

Ventajas para la supervisión remota:

• Conexión persistente: el cliente MQTT (gateway) se conecta una vez al broker y mantiene la sesión
• QoS configurable: entrega garantizada de los mensajes críticos (QoS 1 o 2)
• Temas jerárquicos: usine/ligne1/pompe3/courant — estructura de datos lógica
• Last Will & Testament: notificación automática si un equipo se desconecta

Integración en la nube: MQTT es compatible de forma nativa con AWS IoT Core, Azure IoT Hub, Google Cloud IoT y HiveMQ.

OPC-UA: para entornos SCADA exigentes​

OPC-UA (Arquitectura Unificada) es el estándar interoperable de la Industria 4.0.

Puntos fuertes:

• Modelo de información orientado a objetos (no solo registros numéricos)
• Seguridad integrada: autenticación, cifrado y firma de mensajes
• Compatible con los principales sistemas SCADA (WinCC, FactoryTalk, Ignition)
• Estándar para aplicaciones MES y ERP

Cuándo optar por OPC-UA: integraciones con sistemas SCADA existentes, MES y ERP de SAP. Entornos en los que la semántica de los datos (no solo los valores brutos) es importante.

La ciberseguridad en la supervisión remota​

La supervisión industrial a distancia constituye una vía de ataque importante si no está bien protegida. En 2024-2025, se produjeron varios incidentes relacionados con accesos remotos no seguros a equipos de tecnología operativa (OT).

Las 5 reglas de oro de la ciberseguridad OT​

1. No hay ningún puerto de entrada abierto en la red industrial

La arquitectura zero-inbound-port es el principio fundamental: son los propios equipos industriales los que inician la conexión con la nube de supervisión. Ningún puerto RDP, VNC o Modbus queda expuesto directamente a Internet.

2. VPN y cifrado obligatorios

Todas las comunicaciones entre las plantas industriales y la plataforma de supervisión deben estar cifradas. OpenVPN con cifrado AES-256-GCM es la recomendación para 2026 en las nuevas implementaciones.

3. Autenticación fuerte para el acceso remoto

Cada técnico que acceda de forma remota debe autenticarse con una clave criptográfica personal (no con una contraseña compartida). La autenticación multifactorial (MFA) es obligatoria para las entidades sujetas a la normativa NIS2.

4. Principio del privilegio mínimo

Un técnico de mantenimiento de un controlador específico solo tiene acceso a ese controlador, no a toda la red OT. La segmentación detallada de los accesos limita la propagación en caso de que se produzca una intrusión.

5. Registro de auditoría completo

Todas las conexiones remotas, los cambios en la configuración y las intervenciones se registran con la fecha y la hora, la identidad y la dirección IP de origen. Estos registros son obligatorios según la Directiva NIS2 para las entidades esenciales e importantes.

NIS2 y supervisión remota​

La Directiva NIS2 (transpuesta al ordenamiento jurídico francés desde octubre de 2024) impone a las entidades esenciales y a las entidades importantes medidas específicas en materia de acceso remoto:

• Control de acceso basado en la identidad (sin cuentas compartidas)
• Cifrado de las comunicaciones
• Registro y supervisión de los accesos
• Gestión de incidencias con notificación en un plazo de 24 horas (entidades esenciales)

Los sectores afectados: agua y saneamiento, energía, transporte, sanidad, gestión de residuos y producción industrial crítica.

Implementación práctica: de 1 a 1 000 emplazamientos​

Para un sitio único (POC o proyecto piloto)​

Material necesario:

• 1 pasarela IoT con conexión 4G e interfaces RS-485
• Suscripción SIM M2M (o utilizar tu propia tarjeta SIM del operador)
• Acceso a la plataforma de supervisión en la nube

Tiempo de implementación: de 2 a 4 horas para un técnico (instalación del hardware + configuración en la nube + validación de los datos Modbus).

Coste orientativo: 300-600 € en material + 30-80 € al mes de suscripción a la plataforma + tarjeta SIM M2M.

Para entre 10 y 50 emplazamientos​

A esta escala, el Zero-Touch Provisioning (ZTP) resulta fundamental para reducir los costes de implementación.

Proceso ZTP de Eziwan:

1. Se prepara una configuración tipo en la nube (protocolos, alertas, VPN)
2. Cada pasarela se entrega preconfigurada de fábrica (o se configura de forma remota)
3. In situ: conexión de alimentación + SIM + RS-485; la pasarela se configura sola
4. Menos de 30 minutos de intervención del técnico por emplazamiento

Ahorro frente a la configuración manual: en 50 sitios, el ZTP suele suponer un ahorro de entre 2 y 3 días-hombre de configuración de red.

Para más de 100 emplazamientos (gestión de flotas)​

En el caso de las grandes flotas, las funciones de gestión centralizada cobran una importancia fundamental:

• Panel de control de la flota: visión general de la conectividad y el estado de cada emplazamiento
• Alertas agregadas: filtrado de falsas alarmas, escalado automático
• Actualizaciones de firmware OTA: implementación de actualizaciones en toda la flota sin necesidad de desplazamientos
• Gestión de tarjetas SIM: consumo de datos por emplazamiento, sustitución de tarjetas SIM con un solo clic
• Informes automatizados: disponibilidad de la red, incidencias, intervenciones — para informes de RSE o contractuales

Casos de uso concretos​

Servicio de agua — red de 80 estaciones de bombeo​

Situación anterior: rondas semanales de supervisión, 2-3 guardias a la semana para intervenciones urgentes.

Solución implementada: 80 pasarelas 4G LTE con Modbus RTU, alertas en tiempo real sobre los niveles y las averías de las bombas, y acceso remoto de los técnicos a través de VPN OpenVPN/IPSec.

Resultados:

• Reducción de las rondas de inspección en un 70 % (de semanales a mensuales para las comprobaciones rutinarias)
• Detección de averías en menos de 30 segundos (frente a las 4-48 horas anteriores)
• Retorno de la inversión alcanzado en 4 meses

Sector agroalimentario — 3 centros de producción​

Situación anterior: cada centro contaba con su propio sistema SCADA local, sin visibilidad consolidada a nivel de grupo.

Solución implementada: 3 pasarelas IoT que consolidan los datos Modbus de cada centro en un único panel de control en la nube. Acceso remoto para el equipo de mantenimiento del grupo.

Resultados:

• Un único panel de control para las tres instalaciones (frente a tres interfaces SCADA independientes)
• Reducción del tiempo de respuesta ante incidencias en un 65 %
• Acceso seguro y trazable para los subcontratistas de mantenimiento

Parque fotovoltaico — 15 centrales de generación​

Situación anterior: registradores de datos propietarios incompatibles entre los distintos fabricantes de inversores.

Solución implementada: pasarelas IoT con un analizador Modbus universal compatible con los protocolos SunSpec, SMA, ABB y Fronius. Panel de control para la supervisión del rendimiento (kWh, índice de rendimiento, disponibilidad).

Resultados:

• Unificación de la supervisión en un único panel de control
• Detección de caídas en el rendimiento de +3 % → intervención preventiva planificada
• Informes automáticos para los inversores y el gestor de la red

Lista de comprobación para la implementación de la supervisión remota​

Antes de poner en marcha tu proyecto de supervisión a distancia, comprueba los siguientes puntos:

Conectividad​

• Cobertura 4G LTE verificada en cada emplazamiento (pruebas de los operadores)
• Opción Dual SIM evaluada para los emplazamientos críticos
• Estimación del consumo de datos por emplazamiento (frecuencia de sondeo Modbus × tamaño de los registros)

Equipos de campo​

• Lista de protocolos: ¿Modbus RTU (RS-485), Modbus TCP o protocolo propio?
• Lista de variables que se deben supervisar por equipo (registros Modbus)
• Alimentación disponible en el armario (24 V CC o 230 V CA)

Ciberseguridad​

• Se ha optado por una arquitectura sin puertos de entrada
• Se ha previsto el uso de una VPN OpenVPN/IPSec o IPSec
• Se ha definido una política de acceso para los técnicos (derechos, franjas horarias)
• ¿Es aplicable el NIS2 a su organización? (entidades esenciales/importantes)

Plataforma en la nube​

• Alojamiento de datos en Francia o en la UE (RGPD)
• API disponible para la integración con sistemas SCADA/MES existentes
• Acuerdo de nivel de servicio (SLA) sobre la disponibilidad de la plataforma (mínimo del 99,5 %)

Conclusión​

La supervisión industrial a distancia ya no es una opción en 2026: el fin del GPRS 2G, la Directiva NIS2 y la presión económica sobre los costes de mantenimiento la imponen a todas las empresas industriales que cuentan con instalaciones remotas.

La buena noticia: las soluciones 4G LTE con Zero-Touch Provisioning permiten hoy en día conectar una planta industrial en menos de una hora, por menos de 50 € al mes, todo incluido.

La clave del éxito es elegir una arquitectura nativa de la nube y segura desde el principio, y no añadir una capa de seguridad sobre una arquitectura que no esté diseñada para ello.

Preguntas frecuentes — Supervisión industrial a distancia​

¿Cuál es la diferencia entre SCADA y la supervisión del IoT en la nube?

Un SCADA tradicional es un sistema centralizado (a menudo instalado en las propias instalaciones) con clientes pesados (software específico para PC), un sistema de registro histórico local y una arquitectura en estrella. La supervisión IoT en la nube es una arquitectura distribuida: cada emplazamiento envía sus datos a la nube a través de la pasarela, sin necesidad de un servidor central in situ. La nube ofrece acceso multisitio, acceso móvil y una API REST para la integración, mientras que el SCADA tradicional requiere una VPN de sitio a sitio y una licencia por cliente. Ambos pueden coexistir mediante conectores OPC-UA o Modbus con el SCADA existente.

¿Cuántas variables se pueden supervisar simultáneamente en 100 emplazamientos?

No hay un límite fijo en la nube: las plataformas IIoT modernas están diseñadas para gestionar millones de puntos de medición. El límite práctico viene dado por la pasarela y la red: una pasarela estándar recoge hasta 500 variables Modbus por emplazamiento con un sondeo de 5 s, lo que supone 6 000 valores por minuto por emplazamiento. En 100 emplazamientos, esto supone 600 000 valores por minuto, lo cual es gestionable si la nube está dimensionada adecuadamente (series temporales, partición por emplazamiento).

¿Puede funcionar la supervisión remota si el controlador está en modo STOP (parada del programa)?

Sí, en lo que respecta a la supervisión del estado del autómata (CPU en STOP, hora de la última alarma, estado de las entradas/salidas). No para la recopilación Modbus de las variables de proceso: el servidor Modbus TCP del controlador deja de responder en modo STOP en algunos modelos (el S7-1200 en modo STOP detiene el MB_SERVER). Comprueba el comportamiento específico del controlador en modo STOP antes de confiar en la recopilación de datos Modbus para detectar las paradas de la CPU.

¿Cuál es la latencia mínima entre un cambio de estado en el autómata y su visualización en el panel de control?

Con un sondeo Modbus de 1 s y una nube bien dimensionada, la latencia total suele ser de entre 2 y 5 s (1 s de espera del sondeo + 1 a 2 s de tránsito 4G + 1 a 2 s de procesamiento en la nube). En el caso de alarmas críticas (superación de umbrales), Eziwan puede enviar notificaciones por SMS o correo electrónico en menos de 10 s tras detectar la superación. Para una respuesta en tiempo real (< 100 ms), se necesita una lógica local en el controlador o la pasarela, no en la nube.

¿Se pueden supervisar dispositivos que no sean Ethernet (contadores RS-485, sensores de 4-20 mA)?

Sí, a través del puerto RS-485 de la pasarela para Modbus RTU, y a través de las entradas analógicas para las señales de 4-20 mA o 0-10 V. Los sensores sin protocolo digital (simples contactos secos, interruptores de nivel) se conectan a las entradas digitales de la pasarela o de un módulo de ampliación. El objetivo es supervisar toda la instalación desde una única pasarela, independientemente de la heterogeneidad de los equipos.

Recursos adicionales​

• Guía: acceso remoto seguro a PLC y SCADA — arquitectura VPN
• Guía: router 4G LTE industrial — migrar desde ADSL
• Guía: cómo conectar un controlador Siemens S7 a la nube
• NIS2: obligaciones concretas para las empresas industriales
• Documentación: supervisión multisitio con Eziwan
• Blog: ROI del IoT industrial — cálculo y optimización

Recursos adicionales​

• Supervisión y teleasistencia industrial — soluciones de supervisión y teleasistencia para la industria
• Monitorización de equipos industriales — supervisa tus equipos industriales en tiempo real
• SCADA en la nube — plataforma SCADA en la nube para la supervisión de múltiples emplazamientos
• Telediagnóstico industrial — diagnóstico a distancia de sus instalaciones industriales
• Guía: supervisión de emplazamientos aislados — supervisar emplazamientos sin conexión por cable
• Registrador de datos industrial en la nube — registro y historización de sus datos de proceso

Este artículo aclara sus diferencias fundamentales, sus puntos fuertes y sus limitaciones, y te ofrece una guía para decidir cuál es el protocolo más adecuado según tu caso de uso.

Lo primero es entenderlo: protocolos de naturaleza diferente​

Antes de compararlos, hay que tener en cuenta que Modbus, MQTT y OPC-UA no funcionan al mismo nivel:

Modbus es un protocolo de lectura de datos: permite consultar un equipo para leer sus registros (mediciones, estados). Se trata de un protocolo de campo, de tipo maestro/esclavo, diseñado para la adquisición de datos en equipos industriales.

MQTT es un protocolo de mensajería: permite publicar y suscribirse a flujos de datos a través de un broker centralizado. Se trata de un protocolo de transporte de mensajes, no de adquisición directa en un dispositivo.

OPC-UA es una arquitectura de servicios: combina la adquisición de datos, el acceso al modelo de datos, la seguridad, las alarmas y el historial en un único estándar industrial unificado. Es la solución más completa —y la más compleja—.

En la práctica: La mayoría de las arquitecturas industriales de IoT modernas utilizan las tres. Modbus para leer los equipos de campo. MQTT para transmitir los datos a la nube. OPC-UA para la interoperabilidad entre sistemas complejos.

Modbus RTU y Modbus TCP​

¿Qué es Modbus?​

Modbus fue creado en 1979 por Modicon (hoy Schneider Electric). Es el protocolo industrial más antiguo que sigue en uso —y, con diferencia, el más extendido en el ámbito industrial francés—.

Modbus RTU funciona a través de un enlace serie RS-485 (o RS-232). Es asíncrono, de tipo maestro/esclavo, con una topología de bus lineal (multipunto). Puede haber hasta 247 esclavos en un mismo bus RS-485.

Modbus TCP es Modbus encapsulado en paquetes TCP/IP. Funciona en Ethernet, en el puerto 502. Mantiene el modelo maestro/esclavo, pero permite topologías de red arbitrarias (estrella, árbol). No hay un límite estricto de esclavos en la red.

Qué permite leer Modbus​

Modbus ofrece 4 tipos de datos:

• Coils (0x): salidas digitales de lectura/escritura (booleanos)
• Discrete Inputs (1x): entradas digitales de solo lectura (booleanos)
• Registros de entrada (3x): registros de 16 bits de solo lectura (medidas de sensores)
• Registros de retención (4x): registros de 16 bits de lectura/escritura (puntos de consigna, parámetros)

Para leer un valor de temperatura en un sensor: el maestro envía una solicitud «leer los registros 3x01 a 3x02», y el esclavo responde con los dos registros que contienen el valor (por lo general, un número flotante de 32 bits repartido en dos registros contiguos).

Ventajas de Modbus​

Universalidad absoluta: Si tienes un equipo industrial con un puerto RS-485 o un puerto Ethernet y no sabes qué protocolo utiliza, empieza por probar con Modbus. Es muy probable que sea compatible con Modbus.

Simplicidad: El protocolo es sencillo: registros numerados y funciones estándar de lectura y escritura. Cualquier desarrollador puede implementar un cliente Modbus en unas pocas horas.

Resiliencia: No hay dependencia de ningún intermediario ni de ningún servidor central. El maestro consulta directamente a cada esclavo. Un fallo del maestro no afecta a las relaciones entre los esclavos.

Madurez: 45 años de implantación industrial. Las bibliotecas Modbus están disponibles en todos los lenguajes de programación (Python, C, Java, JavaScript...).

Limitaciones de Modbus​

Arquitectura exclusivamente «pull»: El maestro debe consultar de forma proactiva a cada esclavo. Los dispositivos no envían datos de forma espontánea. En un bus con 50 esclavos consultados cada segundo, la frecuencia real por esclavo puede reducirse a 20 segundos.

Falta de seguridad nativa: Modbus RTU y Modbus TCP no cuentan con ningún mecanismo de autenticación ni de cifrado. Cualquier dispositivo de la red puede leer o escribir en los registros de un equipo Modbus expuesto. La seguridad debe añadirse a nivel de red (VPN, segmentación).

No hay detección automática: No existe ningún mecanismo de detección de dispositivos Modbus en un bus. Debes conocer la dirección de esclavo y las direcciones de los registros de cada dispositivo.

Falta de nomenclatura semántica: El registro 40001 no indica qué contiene; es necesario consultar la documentación del fabricante para saber que se trata de la «temperatura de entrada del agua». No hay autodescripción.

¿Cuándo se debe utilizar Modbus?​

• Lectura de datos en equipos de campo (contadores de energía, sensores de presión, variadores, controladores PLC)
• Redes de campo existentes con cableado RS-485 ya instalado
• Proyectos con equipos heterogéneos de distintos fabricantes (Modbus es el más universal)
• Presupuestos limitados o equipos sin conocimientos especializados

MQTT (Message Queuing Telemetry Transport)​

¿Qué es MQTT?​

MQTT fue creado en 1999 por IBM para la telemetría en enlaces satelitales de baja velocidad. Fue estandarizado por OASIS en 2014 (MQTT 3.1.1) y en 2019 (MQTT 5.0).

MQTT es un protocolo de publicación/suscripción: los emisores envían mensajes a temas, y los suscriptores reciben los mensajes de los temas a los que están suscritos. Un broker MQTT central se encarga de enrutar los mensajes entre emisores y suscriptores.

Arquitectura MQTT​

El broker es el núcleo de la arquitectura MQTT. Los clientes (publishers y subscribers) se conectan al broker; nunca se comunican directamente entre sí.

Ventajas de MQTT​

Arquitectura «push»: Los editores envían datos cuando tienen algo que comunicar. No hay sondeos: el suscriptor recibe los datos inmediatamente tras su publicación. Latencia habitual: 10-50 ms de extremo a extremo.

Ligero: El protocolo se ha diseñado para dispositivos con recursos limitados (microcontroladores, módems 2G). Un mensaje MQTT puede caber en 2 bytes (encabezado mínimo). Consume muy poco ancho de banda.

QoS configurable: Tres niveles de calidad de servicio: QoS 0 (como máximo una vez), QoS 1 (como mínimo una vez), QoS 2 (exactamente una vez). Para las aplicaciones críticas, QoS 2 garantiza la entrega exactamente una vez.

Interoperabilidad en la nube: Todos los principales proveedores de servicios en la nube (AWS IoT Core, Azure IoT Hub, Google Cloud IoT) ofrecen un broker MQTT nativo. MQTT es el protocolo de facto para las arquitecturas de IoT en la nube.

TLS nativo: MQTT es compatible con TLS 1.3 de forma nativa. La seguridad está integrada en el protocolo, no es un complemento.

Limitaciones de MQTT​

No puede leer los dispositivos directamente: Un dispositivo Modbus RTU no es compatible de forma nativa con MQTT. Se necesita una pasarela que lea los datos Modbus y los publique en MQTT. Por eso, Modbus y MQTT suelen utilizarse conjuntamente en las arquitecturas de IoT industrial.

Dependencia del broker: Si el broker MQTT deja de funcionar, toda la arquitectura de mensajería se colapsa. La resiliencia del broker es fundamental. Los brokers gestionados (AWS IoT, HiveMQ Cloud) son muy fiables, pero crean una dependencia de un servicio externo.

No existe un modelo de datos estandarizado: MQTT no define el formato de los mensajes ni la estructura de los temas. Cada implementación es libre, lo que perjudica la interoperabilidad. Dos sistemas MQTT de distintos fabricantes no se comunican necesariamente entre sí sin necesidad de adaptaciones.

No hay un modelo nativo de solicitud/respuesta: MQTT está orientado a eventos unidireccionales. Para implementar un patrón de solicitud/respuesta (por ejemplo, solicitar un parámetro a un dispositivo), hay que utilizar MQTT 5.0 con temas de respuesta correlacionados; es posible, pero más complejo.

¿Cuándo utilizar MQTT?​

• Transporte de datos desde el campo a la nube (Modbus → Pasarela → MQTT → Nube)
• Arquitecturas basadas en eventos en las que los datos cambian de forma irregular
• Implementaciones de IoT integradas en microcontroladores o dispositivos con recursos limitados
• Integración con brokers nativos en la nube (AWS IoT, Azure IoT Hub)

OPC-UA (Arquitectura Unificada OPC)​

¿Qué es OPC-UA?​

OPC-UA (IEC 62541) fue desarrollado por la Fundación OPC a partir de 2006 como sucesor de OPC Classic (basado en COM/DCOM de Windows). Se trata del estándar industrial más ambicioso: combina la adquisición de datos, el modelo semántico, la seguridad, el historial, las alarmas y el acceso a los métodos en un único protocolo.

OPC-UA es hoy en día el protocolo preferido por los fabricantes de controladores lógicos programables (PLC) para las arquitecturas de la Industria 4.0: Siemens TIA Portal (S7-1500), Rockwell ControlLogix, Beckhoff TwinCAT, B&R Automation: todos ellos son compatibles con OPC-UA de forma nativa desde hace entre 5 y 10 años.

Puntos fuertes de OPC-UA​

Modelo de datos semántico: A diferencia de Modbus (registros numerados anónimos), OPC-UA presenta un árbol de objetos con nombre y tipo. El nodo «ns=2;i=1001» puede denominarse «Máquina1/MotorPrincipal/TemperaturaRodamiento» y contar con metadatos (unidad, rango, descripción). La autodescripción es nativa.

Seguridad integrada: Autenticación, autorización, cifrado, integridad de los mensajes… todo está incluido en el protocolo. OPC-UA admite varios perfiles de seguridad (None, Sign, SignAndEncrypt) con algoritmos modernos (AES-256, RSA-2048+).

Publicación/Suscripción desde OPC-UA PubSub (2017): OPC-UA ahora puede funcionar en modo de publicación asíncrona (push), y no solo en modo de solicitud/respuesta (pull). Puede publicar en brokers MQTT, lo que hace que OPC-UA y MQTT sean complementarios en lugar de competidores.

Acceso a los métodos: OPC-UA permite invocar métodos en los equipos, no solo leer valores. El accionamiento de una válvula, el comando de arranque de un motor… todo se modela como un objeto OPC-UA.

Semántica e interoperabilidad: Las «Companion Specifications» de OPC-UA definen modelos estandarizados por sectores: OPC-UA para plásticos, para robótica, para PackML (embalaje), para minería... Un software SCADA compatible con OPC-UA para PackML puede conectarse a cualquier línea de envasado que cumpla con la norma, sin necesidad de una configuración específica.

Limitaciones de OPC-UA​

Complejidad: OPC-UA es el protocolo más complejo de implementar y configurar. Las especificaciones superan las 1000 páginas. La curva de aprendizaje es considerable para los equipos que no cuentan con experiencia previa en OPC-UA.

Recursos necesarios: Un servidor OPC-UA completo requiere más recursos que un esclavo Modbus. Los controladores lógicos programables antiguos o los microcontroladores con recursos limitados no pueden incorporar una pila OPC-UA completa (aunque existen perfiles «nano» más ligeros).

No es universal en el campo: Los equipos antiguos (anteriores a 2010-2015) no son compatibles con OPC-UA. En un parque industrial heterogéneo, encontrarás muchos más equipos Modbus que OPC-UA entre los equipos de campo existentes.

Sobrecarga de red: Los mensajes OPC-UA son más voluminosos que los mensajes Modbus (XML o binarios, según el protocolo de transporte). En conexiones 4G de baja velocidad, esto puede ser un factor a tener en cuenta.

¿Cuándo se debe utilizar OPC-UA?​

• Controladores Siemens S7-1200/1500 recientes con TIA Portal (OPC-UA nativo)
• Arquitecturas de la Industria 4.0 con interoperabilidad SCADA/MES/ERP
• Proyectos que requieren un alto nivel de seguridad y trazabilidad en los accesos
• Entornos con equipos de distintos fabricantes que requieren interoperabilidad semántica

Guía para tomar decisiones: ¿qué combinación elegir para tu proyecto?​

Arquitectura típica sencilla del IoT industrial​

Uso: Supervisión de procesos, alertas, historial. El 80 % de los proyectos de IoT industrial franceses se ajustan a este modelo.

Arquitectura con bus de integración en la nube​

Uso: Proyectos con varios consumidores de datos (SCADA + ERP + BI). MQTT como bus de integración.

Arquitectura de la Industria 4.0 con OPC-UA​

Aplicaciones: Fábricas con controladores lógicos programables (PLC) de última generación, proyectos de Industria 4.0, integración con sistemas MES.

Matriz de decisión​

Cómo gestiona Eziwan los tres protocolos​

La pasarela Eziwan es independiente de los protocolos de campo:

• Modbus RTU: puerto RS-485 nativo, modo maestro, hasta 247 esclavos por bus, sondeo configurable de 1 s a 15 min
• Modbus TCP: cliente Modbus TCP, conexiones simultáneas a varios servidores Modbus
• MQTT: emisor MQTT (publicación de los datos recopilados), posibilidad de suscribirse para recibir comandos
• OPC-UA: cliente OPC-UA (lectura de nodos, suscripción a cambios de valor) — disponible bajo petición para implementaciones OPC-UA

En cuanto a la nube, los datos se normalizan internamente y se exponen a través de:

• API REST (JSON) para aplicaciones en la nube
• Webhooks para eventos en tiempo real
• MQTT saliente para integraciones mediante bus

Puedes combinar Modbus RTU en los dispositivos de campo y MQTT hacia tu nube de AWS/Azure sin tener que modificar nada: la pasarela se encarga de la conversión.

Conclusión​

En 2026, la respuesta a «¿Modbus, MQTT u OPC-UA?» suele ser «los tres juntos»:

• Modbus para leer tus equipos de campo (es el protocolo que utilizan)
• MQTT para transportar los datos a tu nube y distribuirlos a varias aplicaciones
• OPC-UA si tienes controladores lógicos programables (PLC) recientes de Siemens, Rockwell o Beckhoff y necesitas interoperabilidad SCADA/MES

No se trata de una competición, sino de una arquitectura por capas. La elección no es «qué protocolo», sino «qué protocolo en qué capa para qué equipo».

Preguntas frecuentes — Modbus, MQTT y OPC-UA​

¿Se pueden utilizar Modbus y MQTT al mismo tiempo en la misma pasarela?

Sí, y es la arquitectura más habitual en el IIoT. La pasarela recoge los datos de los controladores mediante Modbus TCP o RTU (capa de campo) y los publica en MQTT hacia la nube (capa de transporte). Modbus se detiene en la pasarela; nunca queda expuesto a Internet. MQTT se encarga del transporte hacia la nube, con TLS 1.3 y autenticación.

¿Puede OPC-UA sustituir a Modbus en los controladores lógicos programables existentes (S7-1200, M340)?

En los Siemens S7-1200, el servidor OPC-UA solo está disponible a partir de la versión de firmware V4.4 y requiere una configuración explícita en TIA Portal. En los S7-1500, está integrado de forma nativa desde la versión de firmware V2.0. En los Schneider M340, OPC-UA no está integrado de serie; se necesitaría un módulo adicional. En la práctica, para los parques existentes, Modbus TCP sigue siendo la solución universal; OPC-UA resulta relevante principalmente para los nuevos proyectos con controladores lógicos programables recientes.

MQTT con QoS 0 frente a QoS 1 frente a QoS 2: ¿qué elegir para la supervisión industrial?

Para la supervisión de datos de proceso (temperaturas, presiones), el QoS 1 (Al menos una vez) ofrece el equilibrio adecuado: la entrega está garantizada incluso tras una reconexión, a riesgo de que se produzcan algunas duplicaciones (aceptables para datos de monitorización). El QoS 2 (Exactly Once) es más pesado debido al intercambio de confirmaciones y rara vez es necesario para las mediciones. El QoS 0 (At Most Once) es adecuado para datos muy frecuentes (> 1/s) en los que se acepta una pérdida ocasional.

¿Es suficiente para el sector industrial un broker MQTT público (HiveMQ, EMQX cloud)?

Para proyectos piloto o no críticos, sí. Pero para una producción con restricciones de confidencialidad (datos de procesos, identificaciones de los equipos), es preferible un broker privado alojado en Francia. Los datos MQTT que pasan por brokers públicos estadounidenses pueden estar sujetos a la ley CLOUD Act, lo cual debe evaluarse en función de la sensibilidad de los datos y del sector de actividad.

¿Influye OPC-UA en el rendimiento del controlador en comparación con Modbus?

OPC-UA consume mucho más recursos de CPU y memoria que Modbus TCP. En un S7-1500 con CPU 1511, con un servidor OPC-UA activo y 50 conexiones de clientes, el tiempo de ciclo puede aumentar entre un 5 % y un 15 %. En un S7-1200, los recursos son más limitados: comprueba sistemáticamente el impacto con el programa de producción completo antes de implementar OPC-UA en producción.

Para profundizar en el tema​

• Blog: Modbus TCP frente a RTU: ¿qué protocolo elegir?
• Blog: OPC-UA, MQTT, Modbus: cómo elegir una pasarela industrial
• Blog: guía completa de OPC-UA para la industria
• Blog: MQTT, RS485, Modbus — explicación de los protocolos IoT industriales
• Documentación: configuración de Modbus en la pasarela Eziwan

Recursos adicionales​

• Protocolos industriales — Comparativa completa de Modbus, MQTT, OPC UA y DNP3
• Modbus RTU a la nube — conecta tus equipos RS-485 Modbus RTU a la nube
• OPC UA a MQTT — publica datos OPC UA en un broker MQTT
• RS-485 Modbus 4G — transmisión de datos RS-485 Modbus a través de la red 4G
• Pasarela IIoT — soluciones de pasarela IIoT para la industria
• Guía: Modbus a la nube — guía completa para transmitir tus datos Modbus

Esta guía describe los nueve criterios que permiten distinguir una pasarela realmente adecuada para entornos industriales de un producto de consumo mal reacondicionado. Está dirigida a responsables de mantenimiento, especialistas en automatización y directores de sistemas de información industriales que tengan un proyecto de conexión o supervisión.

Criterio 1: Protocolos industriales compatibles de forma nativa​

Este es el criterio más importante. Si tu puerta de enlace no «habla» el protocolo de tus equipos, todos los demás criterios pasan a un segundo plano.

Los protocolos imprescindibles en Francia en 2026​

Modbus RTU (RS-485) — El estándar por excelencia en la industria francesa. Contadores de energía, controladores de climatización, sensores de medición, variadores de frecuencia: si tu equipo tiene un puerto serie RS-485, es probable que utilice Modbus RTU. Cualquier pasarela industrial que se precie debe ser compatible con este protocolo de forma nativa.

Modbus TCP (Ethernet) — La versión de red de Modbus. Controladores lógicos programables (PLC) recientes, pasarelas Modbus-Ethernet, equipos con interfaz RJ45. A comprobar: ¿la pasarela admite la función de maestro Modbus (sondeo activo) o solo la de servidor (pasivo)?

MQTT — El protocolo de mensajería por excelencia para el IoT. Se utiliza para publicar datos en brokers en la nube (AWS IoT, Azure IoT Hub, MQTT Mosquitto local). Esencial para las arquitecturas nativas de la nube.

OPC-UA — Norma industrial IEC 62541, adoptada por Siemens, Rockwell y Beckhoff para los controladores lógicos programables (PLC) más recientes. Si su sistema de información incluye PLC Siemens S7-1500/1200 o una versión reciente de TIA Portal, compruebe la compatibilidad con OPC-UA.

Protocolos específicos:

• DNP3: redes eléctricas, agua potable, gas (Francia, América del Norte)
• IEC 61850: subestaciones de alta tensión
• M-Bus: contadores de calefacción, agua y gas (edificios, redes de calefacción)
• BACnet: climatización y gestión técnica de edificios (GTB)

Lista de verificación de protocolos:

• Modbus RTU (RS-485) en modo maestro
• Modbus TCP en modo maestro
• MQTT con TLS 1.2/1.3
• Protocolos específicos de su sector

Criterio 2: Conectividad de red y redundancia​

4G LTE: el estándar actual​

Una pasarela industrial en 2026 debe incorporar, como mínimo, un módulo 4G LTE Cat-M1/Cat-4. La red 4G cubre el 97 % del territorio francés en términos de población y es suficiente para el 95 % de las aplicaciones industriales del IoT (supervisión en tiempo real, alertas, acceso remoto).

Aspectos a tener en cuenta:

• ¿El módulo 4G está integrado (SIM M2M interna) o es externo (llave USB)?
• El módulo externo supone una fuente adicional de fallos y de mala gestión térmica
• Algunas pasarelas indican que son «compatibles con 4G», pero requieren un módem externo; hay que tener cuidado

Dual SIM: la verdadera redundancia de red​

Una sola tarjeta SIM = un solo operador = un único punto de fallo. En algunas zonas industriales (zonas con cobertura parcial, túneles, zonas con poca cobertura), es posible que se pierda la señal de un operador mientras que el otro la mantiene.

La función Dual SIM, con dos tarjetas SIM de dos operadores diferentes y con cambio automático, es la solución ideal para aplicaciones críticas. Eziwan incorpora la función Dual SIM de forma nativa.

Preguntas que hay que plantearse:

• ¿Admite el gateway dos tarjetas SIM simultáneamente?
• ¿La conmutación es automática (sin intervención humana)?
• ¿Es aceptable el tiempo de conmutación para su aplicación (objetivo: menos de 30 segundos)?

Conexión por cable como conexión de respaldo​

En las instalaciones que dispongan de fibra óptica o Ethernet, una pasarela con puerto Ethernet WAN permite utilizar la fibra óptica como conexión principal y la 4G como conexión de respaldo. Ambas conexiones deben gestionarse simultáneamente con una conmutación automática y transparente en caso de fallo.

Criterio 3: Seguridad y arquitectura Zero Trust​

La ciberseguridad de las pasarelas de IoT industriales se ha convertido en un requisito imprescindible, un proceso que se ha visto acelerado por la Directiva NIS2, que ahora abarca un amplio abanico de empresas industriales.

Lo que hay que comprobar​

Arquitectura exclusivamente de salida: La pasarela debe establecer únicamente conexiones salientes. No debe abrirse ningún puerto de entrada en tu red OT. Esto elimina la superficie de ataque accesible desde Internet. Se trata de la arquitectura Zero Trust: «Nunca confíes, comprueba siempre».

Protocolo VPN: OpenVPN es hoy en día la referencia: robusto y ampliamente auditado, atraviesa los cortafuegos a través del puerto TCP 443 y se autentica mediante un certificado X.509 (cifrado AES-256-GCM). IPSec (IKEv2) sigue siendo adecuado para entornos regulados por la norma FIPS 140-2.

Cifrado de datos en tránsito: TLS 1.3 como mínimo para las comunicaciones en la nube. Comprueba que la pasarela no se comunique sin cifrar con un broker MQTT sin cifrar.

Autenticación: Claves criptográficas por dispositivo, revocables individualmente. Evita las pasarelas con una contraseña de administrador compartida entre todos los dispositivos.

Actualización segura del firmware (OTA): Las pasarelas que no se actualizan se convierten en vectores de ataque. Comprueba que la pasarela admita actualizaciones OTA firmadas criptográficamente.

NIS2 y responsabilidad​

Desde octubre de 2024, la NIS2 exige a las entidades esenciales e importantes que gestionen la seguridad de su cadena de suministro digital, incluidas las pasarelas de IoT. Una pasarela que abra puertos de entrada en la red OT o que se comunique sin cifrar constituye un incumplimiento de la NIS2.

Criterio 4: Resistencia para entornos industriales​

Una pasarela «industrial» debe ser capaz de soportar las condiciones reales de los entornos industriales. Estas son las certificaciones y especificaciones que hay que comprobar:

Temperatura de funcionamiento​

Una pasarela estándar de TI funciona entre 0 °C y +40 °C. Una pasarela industrial auténtica suele funcionar entre -20 °C y +70 °C.

Índice de protección IP​

IP20: Protección mínima; uso exclusivo en armario cerrado en un local limpio.
IP40: Protección contra cuerpos sólidos de más de 1 mm. Armario técnico estándar.
IP65: Resistente al polvo y a los chorros de agua. Para entornos polvorientos (sector agroalimentario, construcción, exteriores bajo cubierta).
IP67: Inmersión temporal hasta 1 metro. Para entornos muy húmedos.
IP68: Inmersión prolongada. Rara vez es necesaria, pero resulta útil para equipos enterrados.

Vibraciones y golpes​

Para aplicaciones en vehículos industriales, puentes grúa, compresores o entornos con vibraciones: comprueba el cumplimiento de la norma EN 61131-2 o IEC 60068 en lo que respecta a los ensayos mecánicos.

Montaje en carril DIN​

Para una instalación en un armario eléctrico, el montaje en carril DIN de 35 mm es el estándar del sector. Evita los gateways que requieran tornillos de fijación a la pared o un montaje en rack de 19" no estándar para instalaciones industriales.

Certificaciones reglamentarias​

CE (obligatorio en la UE): El marcado CE es obligatorio para cualquier equipo electrónico que se comercialice en Europa.
ATEX (zonas explosivas): Para instalaciones químicas y petroleras con atmósferas potencialmente explosivas. Zona ATEX 1/2 o zona 21/22, según la aplicación.
EN 61131-2: Norma específica para equipos utilizados con controladores lógicos programables (PLC).

Criterio 5: Aprovisionamiento sin intervención (ZTP)​

El ZTP es un criterio que a menudo se subestima, sobre todo cuando se implementan varias decenas o cientos de gateways.

Sin ZTP: Cada puerta de enlace debe configurarse manualmente antes de su implementación. Un técnico debe conectarse a la interfaz local, introducir la dirección IP del servidor en la nube, las credenciales, los parámetros de red... Para 50 sedes, esto supone 50 intervenciones de 30 minutos como mínimo = 25 horas de trabajo técnico, más los desplazamientos.

Con ZTP: La pasarela se conecta automáticamente a la nube de gestión la primera vez que se enciende (a través de una tarjeta SIM M2M preconfigurada). Descarga su configuración desde el servidor y queda operativa en menos de 5 minutos sin necesidad de intervención local.

Preguntas que hay que plantear al proveedor:

• ¿El ZTP es realmente «zero touch» o requiere, a pesar de todo, una configuración inicial?
• ¿Viene la tarjeta SIM M2M preconfigurada con los parámetros del servidor en la nube?
• En caso de que surja algún problema con el aprovisionamiento, ¿cómo se realiza el diagnóstico a distancia?

Criterio 6: Computación en el borde y lógica local​

Las pasarelas más avanzadas cuentan con potencia de cálculo que permite ejecutar la lógica de forma local, sin depender de la nube:

Agregación local: Calcular medias, valores mínimos y máximos, y sumas a lo largo de un periodo (por ejemplo: energía consumida en kWh por hora) antes de enviarlos a la nube. Reduce el ancho de banda necesario.

Alertas locales: Activar una alarma local (relé, zumbador, SMS directo) sin pasar por la nube. Útil en caso de corte de red: la pasarela sigue supervisando y avisando a nivel local.

Filtrado de datos: Enviar únicamente los datos que hayan variado más allá de un umbral definido. Reduce drásticamente los costes de datos móviles en sitios con gran volumen de tráfico.

Scripts de lógica: En las pasarelas avanzadas (Eziwan, algunos modelos de Teltonika), existe la posibilidad de ejecutar scripts de Python o JavaScript de forma local para aplicar lógica de negocio compleja.

Criterio 7: Gestión y supervisión desde una consola centralizada​

En el caso de los proyectos con varias sedes (a partir de 3 o 4 sedes), la consola de gestión centralizada es un factor diferenciador clave:

Panel de control de la flota: Vista en tiempo real del estado de todas las pasarelas (conectadas/desconectadas, nivel de señal, alertas activas).

Actualizaciones de firmware a distancia: Implementar una actualización de seguridad en 50 puertas de enlace con solo unos clics, sin necesidad de desplazarse al lugar.

Configuración remota: Modificar un umbral de alarma, añadir un nuevo sensor, cambiar un parámetro de red… todo desde la consola web.

Alertas de flota: Recibir una notificación cuando una pasarela pierde la conexión o cuando un dispositivo supera un umbral.

Criterio 8: Alojamiento de datos y soberanía digital​

Este criterio ha adquirido una importancia estratégica para las empresas francesas con la entrada en vigor de la NIS2 y los requisitos de soberanía digital.

Preguntas clave:

• ¿Dónde se alojan los datos recopilados por la pasarela?
• ¿Está la empresa editora sujeta a la ley estadounidense CLOUD Act (filial de una empresa estadounidense)?
• ¿Pueden las autoridades extranjeras acceder a los datos sin previo aviso?
• ¿Cuenta el proveedor con la certificación ISO 27001? ¿SecNumCloud (ANSSI) para las OIV?

Para las entidades esenciales según la Directiva NIS2 y los operadores de importancia vital, el almacenamiento de datos en Francia con un proveedor que no esté sujeto a leyes extraterritoriales extranjeras es un requisito de hecho.

Criterio 9: Asistencia técnica y apoyo​

Ni siquiera la mejor pasarela del mundo sirve de nada sin un servicio de asistencia capaz de responder a tus preguntas técnicas en tiempo real:

SLA de asistencia técnica: ¿Qué plazo de respuesta se garantiza? ¿4 horas, 8 horas, 24 horas? Para aplicaciones industriales críticas, se recomienda un SLA inferior a 4 horas laborables.

Experiencia industrial: ¿Conoce el servicio de asistencia los protocolos industriales Modbus, PROFIBUS y Siemens S7? ¿O se trata de un servicio de asistencia general de TI?

Documentación: ¿API documentada (OpenAPI 3.0)? ¿Ejemplos de código? ¿Bibliotecas de Python/Node?

Asistencia en el proyecto: ¿Ofrece el proveedor asistencia durante la primera implementación?

Lista de verificación resumida: 9 criterios​

□ Protocoles
  □ Modbus RTU (RS-485) maestro
  □ Modbus TCP maestro
  □ MQTT TLS
  □ Protocolos específicos de su sector

□ Connectivité
  □ 4G LTE integrado
  □ Doble SIM con dos operadores
  □ Port Ethernet WAN (optionnel)
  □ Délai failover < 30 secondes

□ Sécurité
  □ Architecture outbound-only (zero inbound port)
  □ VPN OpenVPN/IPSec o equivalente moderno
  □ TLS 1.3 para las comunicaciones en la nube
  □ Autenticación mediante clave criptográfica
  □ Actualización OTA firmada

□ Robustesse
  □ Temperatura: entre -20 °C y +70 °C como mínimo
  □ IP40 como mínimo (IP65 si el entorno es polvoriento)
  □ Montage rail DIN 35mm
  □ Certificaciones CE (+ ATEX si es necesario)

□ ZTP
  □ Implementación sin intervención local
  □ Tarjeta SIM M2M preconfigurada

□ Edge computing
  □ Agregación local
  □ Alertes locales sans cloud
  □ Logique locale configurable

□ Consola centralizada
  □ Panel de control de la flota en tiempo real
  □ Actualizaciones de firmware OTA
  □ Configuración remota

□ Alojamiento de datos
  □ Alojamiento en Francia o en la UE
  □ Non soumis au CLOUD Act
  □ ISO 27001 minimum

□ Support
  □ Acuerdo de nivel de servicio (SLA) documentado
  □ Expertise protocoles industriels
  □ API documentada en OpenAPI

Preguntas frecuentes​

¿En qué se diferencia una pasarela IoT industrial de un router 4G industrial? Un router 4G industrial proporciona conectividad de red IP (enrutamiento, NAT, VPN). Una pasarela IoT industrial añade capacidades de campo: puerto RS-485 para Modbus RTU, computación en el borde e integración nativa en la nube (MQTT, API REST). Algunos productos, como la Eziwan Gateway, combinan ambas funciones en un único dispositivo.

¿Se puede utilizar una pasarela IoT industrial sin una suscripción a la nube de Eziwan? El hardware Eziwan Gateway puede funcionar en modo autónomo con su propio broker MQTT o API. La plataforma en la nube de Eziwan (panel de control, ZTP, gestión de flotas, alertas) es opcional. No obstante, está incluida en la suscripción y elimina la necesidad de gestionar la infraestructura de servidores.

¿Cuántos registros Modbus se pueden recopilar simultáneamente? El Eziwan Gateway puede gestionar hasta 500 registros Modbus (RTU o TCP) por intervalo de sondeo. Para implementaciones con necesidades superiores (contadores de energía multicircuito, líneas con numerosos sensores), el sondeo puede distribuirse en varios intervalos de tiempo configurables.

¿Qué es el «edge computing» en una pasarela industrial y lo necesito? El «edge computing» permite ejecutar lógica directamente en la pasarela (agregación, filtrado, detección de anomalías locales, alertas sin necesidad de la nube). Resulta útil cuando: la conectividad es intermitente (los datos se procesan y se almacenan en búfer localmente), el volumen de datos brutos es demasiado grande para enviarlo a la nube, o se requiere una reacción rápida (<1 s) sin pasar por la nube.

¿Cómo se comprueba que una pasarela cumple con la normativa NIS2? El cumplimiento de la normativa NIS2 para las pasarelas se refiere a: el cifrado de las comunicaciones (TLS 1.3 como mínimo), la autenticación fuerte (certificados X.509, sin contraseñas predeterminadas), la trazabilidad de los accesos (registro de auditoría), las actualizaciones de seguridad (OTA firmadas) y el almacenamiento de datos en la UE (RGPD). Pide a tu proveedor su certificado de conformidad o sus certificaciones ISO 27001.

Para profundizar en el tema​

• Blog: Router 4G industrial frente a router de consumo — 10 diferencias
• Blog: Zero-Touch Provisioning — implementar 50 routers en 2 horas
• Blog: NIS2 y ciberseguridad industrial — obligaciones y plan de acción
• Guía: supervisión industrial remota — arquitectura y seguridad
• Documentación: integración de Modbus RTU en la pasarela Eziwan

Recursos​

• Eziwan Gateway — especificaciones técnicas
• Comparativa: router industrial frente a módem de Internet
• Guía: Modbus RTU frente a Modbus TCP
• VPN industrial frente a Zero Trust
• Calculadora del ROI del IoT industrial
• Alternativa a Ewon — comparativa de soluciones IIoT

Recursos adicionales​

• Pasarela IoT industrial — criterios de elección y comparativa de pasarelas IoT industriales
• Pasarela Eziwan — especificaciones y funcionalidades de la pasarela Eziwan
• Pasarela IIoT — soluciones de pasarela IIoT para la industria
• Pasarela IoT — gama completa de pasarelas IoT Eziwan
• Routers industriales — routers 4G LTE industriales para tus instalaciones remotas
• Conectividad industrial — soluciones de conectividad para la Industria 4.0

Este artículo aclara las definiciones, compara los distintos enfoques basándose en criterios concretos y te ayuda a elegir la estrategia más adecuada para tu contexto en 2026, ya se trate de una pequeña fábrica con 20 equipos o de un gran complejo industrial con más de 500 activos.

Las cuatro estrategias de mantenimiento: definiciones precisas​

1. Mantenimiento correctivo​

Definición: Se interviene una vez que se ha producido la avería. Si el equipo se estropea, lo reparamos.

Variantes:

• Correctiva diferida: se detecta la avería, pero la reparación se programa (equipo no crítico)
• Correctiva de urgencia: avería crítica, se requiere una intervención inmediata

Coste habitual: entre 4 y 5 veces superior al del mantenimiento preventivo equivalente (piezas de recambio urgentes, horas extras, pérdidas de producción).

Cuándo es aceptable: Equipos no críticos y fácilmente sustituibles, cuyo coste de supervisión sea superior al coste de un fallo.

2. Mantenimiento preventivo sistemático​

Definición: Se sustituye o se revisa según un calendario fijo (intervalos de tiempo o de producción), independientemente de su estado real.

Ejemplo: Cambiar el aceite de un reductor cada 2000 horas, aunque todavía esté en buen estado.

Problema principal: Entre el 30 % y el 40 % de las piezas sustituidas durante las revisiones preventivas aún se pueden seguir utilizando. Se desperdician recursos Y componentes.

Coste habitual: entre 2 y 3 veces superior al del mantenimiento condicional bien ajustado.

Cuando sea pertinente: Instalaciones con modos de deterioro bien conocidos y previsibles a lo largo del tiempo, en un contexto normativo que exija revisiones periódicas.

3. Mantenimiento basado en el estado (Condition-Based Maintenance — CBM)​

Definición: Se interviene cuando así lo indica el estado real del equipo, basándose en mediciones físicas continuas (vibración, temperatura, corriente, acústica, etc.).

Principio: Cada dispositivo «habla» a través de sus datos. Lo escuchamos.

Ejemplo: El rodamiento se cambia cuando la vibración supera un umbral crítico establecido durante la puesta en servicio, no en una fecha fija.

Rentabilidad documentada: Reducción del 25 al 55 % de las paradas no planificadas; ahorro del 10 al 30 % en los costes totales de mantenimiento.

Lo que se necesita: Sensores instalados en los equipos, recopilación de datos en tiempo real, umbrales de alerta configurados.

4. Mantenimiento predictivo (Predictive Maintenance — PdM)​

Definición: Se predice la fecha de un fallo futuro mediante un modelo matemático (estadístico o de aprendizaje automático) alimentado con datos históricos y en tiempo real.

Diferencia con el condicional: La CBM dice: «El equipo está en mal estado, intervengan pronto». La PdM dice: «El equipo se averiará en un plazo de 3 a 5 días con una probabilidad del 87 %».

Lo que se necesita: Datos históricos de al menos 12-18 meses por equipo, experiencia en modelización y equipos capaces de aprovechar las predicciones.

Realidad sobre el terreno en 2026: El verdadero mantenimiento predictivo (aprendizaje automático + modelos físicos) está hoy en día al alcance de las grandes empresas y las empresas de tamaño medio que cuentan con equipos de datos. Para las pymes, el mantenimiento condicional ofrece el 80 % de los beneficios con solo el 20 % de la complejidad.

Comparativa basada en 7 criterios​

¿Qué sensores se utilizan para el mantenimiento condicional?​

El mantenimiento condicional se basa en mediciones físicas. Estos son los sensores más utilizados, clasificados por ROI:

1. Vibración (acelerómetro)​

Lo que se detecta: Desequilibrio rotacional, desalineación de ejes, deterioro de los rodamientos, cavitación en las bombas, desgaste de los engranajes.

Aplicaciones: Motores eléctricos, bombas centrífugas, compresores, ventiladores, cintas transportadoras.

Señales precursoras: Aumento del nivel global de vibración (RMS), aparición de frecuencias armónicas características, aumento de la curtosis (impulsividad).

Precio del sensor: de 50 € (básico industrial) a 500 € (banda ancha + ICP).

Plazo antes de la avería: Detección entre 2 y 12 semanas antes de que se produzca la avería del rodamiento.

2. Temperatura infrarroja / térmica​

Lo que se detecta: Calentamiento anormal de motores, transformadores, conexiones eléctricas, cojinetes y frenos.

Aplicaciones: Cuadros eléctricos, motores, rodamientos, circuitos de refrigeración.

Señales de alerta: Aumento de la temperatura de funcionamiento por encima del valor de referencia establecido.

Precio del sensor: de 20 € (sonda de contacto PT100) a 2000 € (cámara térmica fija).

3. Corriente eléctrica (pinza amperimétrica)​

Lo que se detecta: Desequilibrio de carga, deterioro del aislamiento, armónicos anormales, dificultades de arranque.

Aplicaciones: Motores asíncronos, servomotores, sistemas de accionamiento.

Ventaja: No requiere instalación mecánica; la medición es no invasiva. Ideal para equipos de difícil acceso.

4. Acústica / ultrasonidos​

Lo que se detecta: Fugas de gas comprimido, arco eléctrico, deterioro de los rodamientos con carga reducida, defectos de lubricación.

Aplicaciones: Red de aire comprimido, armarios eléctricos de alta tensión, cojinetes de marcha lenta.

Rentabilidad típica: Una auditoría de aire comprimido mediante ultrasonidos suele detectar entre un 15 % y un 30 % de fugas, lo que se traduce en un ahorro inmediato en el consumo eléctrico del compresor.

5. Análisis de aceite (en línea)​

Lo que se detecta: Contaminación por partículas, deterioro de la viscosidad, presencia de agua, metales procedentes del desgaste.

Aplicaciones: Reductores, cajas de cambios, turbinas, compresores.

Sensores en línea: Permiten una monitorización continua sin necesidad de tomar muestras, con alertas automáticas en caso de partículas o dieléctricos.

Puesta en práctica: ¿por dónde empezar?​

Paso 1: Identificar los equipos críticos (análisis FMEA simplificado)​

Elabora una lista de tus equipos y evalúa cada uno de ellos en función de:

• Criticidad (impacto de una avería: parada de la producción, seguridad, medio ambiente)
• Frecuencia de averías (historial del sistema de gestión de mantenimiento, si está disponible)
• Detectabilidad (¿se anuncia la avería o es repentina?)

Concentra los sensores CBM en los equipos con alta criticidad + fallos progresivos.

Paso 2: Definir las métricas clave por equipo​

Para cada equipo crítico, define qué parámetros se deben medir. Ejemplo para una bomba centrífuga:

• Vibración (acelerómetro en el cojinete del lado del motor y del lado de la bomba)
• Temperatura de los cojinetes (PT100 o infrarrojos)
• Corriente del motor (pinza amperimétrica)
• Presión diferencial (si la presión es crítica)

Paso 3: Instalar y conectar los sensores​

Los sensores se conectan a la pasarela Eziwan a través de RS-485/Modbus RTU, en el caso de los sensores industriales estándar, o a través de las salidas de 4-20 mA, en el caso de los transmisores de proceso. La pasarela envía todas las mediciones a la plataforma en la nube en tiempo real.

Paso 4: Establecer los valores de referencia​

Durante la puesta en servicio, registre los valores de referencia de cada parámetro en un equipo nuevo o en buen estado. Estos valores de referencia sirven para:

• Definir los umbrales de alarma (alarma al +20 %, emergencia al +50 % del valor de referencia)
• Detectar una desviación progresiva con respecto a la línea de referencia

Paso 5: Calibrar los umbrales de alarma​

Demasiado sensible = falsas alarmas que desaniman a los equipos. No lo suficientemente sensible = fallos no detectados. La calibración de los umbrales requiere entre 2 y 4 semanas de observación en condiciones normales para perfeccionarla.

Eziwan permite modificar los umbrales desde la plataforma en la nube sin necesidad de intervenir sobre el terreno.

Paso 6: Integrar con el sistema de gestión de mantenimiento (GMAO)​

La alarma CBM solo tiene valor si activa una acción planificada en el sistema de gestión de mantenimiento (GMAO). La API REST de Eziwan permite crear automáticamente una orden de intervención en su sistema de gestión de mantenimiento (SAP PM, Infor EAM, Hive Maintenix) en cuanto se activa una alarma.

Experiencias sobre el terreno​

Fábrica de cemento — reductor principal del molino​

Contexto: Reductor de 800 kW, coste de sustitución: 180 000 €, plazo de entrega: 6 semanas.

Antes de CBM: 2 averías catastróficas en 4 años. Cada avería = 6 semanas de parada parcial = 420 000 € de pérdida de producción.

Tras el análisis CBM (vibración + temperatura + análisis de aceite): Detección de un deterioro progresivo 8 semanas antes de la avería. Intervención planificada durante una parada programada. Coste de la intervención preventiva: 28 000 € frente a los 180 000 € de una sustitución de emergencia.

Retorno de la inversión (ROI): 9 meses.

Fábrica agroalimentaria — línea de envasado​

Contexto: 12 motorreductores en una línea crítica. Mantenimiento preventivo a las 3000 h (cambio de aceite sistemático + inspección).

Tras el CBM (corriente + vibración): De los 12 motorreductores supervisados, el CBM ha permitido:

• Evitar 3 paradas no planificadas
• Reducir en un 40 % las intervenciones preventivas innecesarias (el aceite aún estaba limpio según el análisis)
• Detectar dos problemas de alineación imperceptibles a simple vista

Retorno de la inversión (ROI): 11 meses.

Conclusión: ¿qué estrategia seguir?​

Para una pyme industrial (menos de 50 equipos): Empieza por el mantenimiento condicional de tus 5 a 10 equipos más críticos. La inversión es asequible, el retorno de la inversión es rápido y la complejidad es manejable sin necesidad de un equipo dedicado a los datos.

Para una empresa mediana o grande: El mantenimiento condicional sigue siendo la base. En los equipos más críticos que cuenten con datos históricos suficientes, compleméntelo con modelos predictivos (empezando por 2 o 3 equipos prioritarios).

Lo que se observa en 2026: La mayoría de las empresas industriales francesas que han mejorado realmente su rendimiento en materia de mantenimiento lo han hecho gracias al mantenimiento condicional basado en el IoT, y no mediante proyectos complejos de aprendizaje automático. El retorno de la inversión es cuantificable en menos de un año.

Preguntas frecuentes​

¿Cuál es la diferencia entre el mantenimiento predictivo y el mantenimiento condicional (CBM)? El mantenimiento condicional activa una acción cuando se supera un umbral (por ejemplo: temperatura > 85 °C → alerta inmediata). El mantenimiento predictivo analiza las tendencias a lo largo del tiempo para anticipar el deterioro antes de que se alcance el umbral crítico (p. ej.: la temperatura aumenta 2 °C por semana desde hace tres semanas → planificar una intervención dentro de dos semanas). El mantenimiento condicional es más sencillo de implementar, mientras que el predictivo ofrece un plazo de intervención más largo.

¿Qué tipo de sensor es el más útil para poner en marcha un programa de mantenimiento condicional? Para motores y bombas: el sensor de corriente (transformador de corriente en el cable de alimentación) es el más versátil, ya que detecta sobrecargas, arranques difíciles y deterioro mecánico sin necesidad de modificar el equipo. Para las transmisiones mecánicas (reductores, cojinetes): el sensor de vibraciones acelerómetro. Estos dos tipos de sensores cubren el 80 % de los casos de fallos evitables en la industria.

Para profundizar en el tema​

• Blog: Mantenimiento predictivo en el IIoT: de los datos de los sensores a las alertas en tiempo real
• Blog: Retorno de la inversión (ROI) del IoT industrial: cálculo y optimización
• Blog: Modbus TCP frente a RTU: ¿qué protocolo elegir para la recopilación de datos de sensores?
• Blog: Grafana para la supervisión industrial con Modbus
• Documentación: caso de uso de un fabricante de maquinaria OEM

Recursos adicionales​

• Mantenimiento predictivo IIoT — soluciones de mantenimiento predictivo basadas en el IoT industrial
• Telediagnóstico industrial — diagnóstico a distancia para anticipar averías
• Monitorización de equipos industriales — supervisión continua de sus máquinas industriales
• Supervisión y teleasistencia industrial — supervisión centralizada para gestionar el mantenimiento a distancia
• Guía: reducir los desplazamientos sobre el terreno — optimizar las intervenciones gracias al mantenimiento condicional

Este artículo analiza por qué el alojamiento en Francia se ha convertido en un criterio de selección imprescindible para muchas empresas industriales y qué implica esto, en la práctica, a la hora de elegir una solución de IIoT.

¿Qué es un «dato industrial» y por qué es importante su ubicación?​

Los datos industriales generados por sus pasarelas de IoT, controladores lógicos programables, sensores y sistemas SCADA abarcan un amplio espectro:

• Datos de proceso: temperaturas, presiones, caudales, niveles… las mediciones físicas de su producción
• Datos operativos: estados de alarma, incidencias de las máquinas, registros de mantenimiento
• Datos de topología de red: direcciones IP, esquemas de instalación, versión de firmware de los equipos
• Datos de acceso: quién se ha conectado a qué equipo, cuándo y desde dónde

Estos datos, en su conjunto, constituyen un mapa detallado de su infraestructura industrial: su capacidad de producción, sus vulnerabilidades y sus modos de fallo. Si caen en manos equivocadas —competidores, actores estatales hostiles, ciberdelincuentes—, las consecuencias pueden ser graves.

Por lo tanto, la pregunta no es «¿son mis datos sensibles?», sino «¿quién puede acceder a ellos y bajo qué jurisdicción?».

El problema de la ley estadounidense CLOUD Act​

Desde 2018, la Ley de Aclaración del Uso Lícito de Datos en el Extranjero (CLOUD Act) obliga a las empresas estadounidenses a facilitar a las autoridades federales de Estados Unidos los datos que alojan, incluso si dichos datos se almacenan físicamente en Europa.

En la práctica, esto significa que, si utilizas AWS, Microsoft Azure o Google Cloud, el FBI o la NSA pueden acceder a tus datos industriales, incluso si tus servidores se encuentran en París o Fráncfort, sin que necesariamente se te informe de ello y sin que exista un recurso jurídico europeo efectivo.

En el caso de los datos industriales, este riesgo resulta especialmente preocupante:

• Espionaje industrial: sus parámetros de producción, ritmos de producción y fórmulas pueden ser utilizados por competidores estadounidenses
• Infraestructura crítica: en el caso de los OIV (Operadores de Importancia Vital), la divulgación de datos de supervisión puede suponer un riesgo para la seguridad nacional
• Inteligencia económica: la capacidad de producción real de una fábrica, sus proveedores, sus flujos logísticos… todo ello puede ser de interés para actores estatales

Tanto la Comisión Europea como la ANSSI han recomendado evitar el uso de proveedores sujetos a la Ley CLOUD para los datos sensibles. La Directiva NIS2 refuerza esta recomendación, convirtiéndola en una obligación de facto para las entidades esenciales.

Lo que dice NIS2 sobre la ubicación de los datos​

La NIS2 no establece explícitamente la obligación de alojar todos los datos en Francia o en la UE. Sin embargo, varios de sus requisitos conducen indirectamente a ello:

1. Gestión de la cadena de suministro digital​

El artículo 21 de la NIS2 exige una gestión de los riesgos relacionados con la cadena de suministro, incluidos los proveedores de servicios en la nube. Esto implica una evaluación formal de cada proveedor de servicios en la nube: ¿dónde tiene su sede? ¿Bajo qué jurisdicción pueden ser incautados sus datos? ¿De qué certificaciones de seguridad dispone?

En el caso de las entidades esenciales (EE) —entre las que se incluyen numerosas empresas industriales de los sectores de la energía, el agua, el transporte, la sanidad y las infraestructuras digitales—, esta evaluación debe estar documentada y ser defendible en caso de una auditoría de la ANSSI.

2. Notificación de incidentes y disponibilidad de los datos probatorios​

La NIS2 impone plazos de notificación muy cortos: 24 horas para la alerta inicial y 72 horas para el informe del incidente. Para cumplir estos plazos, debe disponer de acceso inmediato a los registros de auditoría, los registros de conexión y los datos de supervisión. Si estos datos están alojados en un proveedor estadounidense sujeto a procedimientos legales, corre el riesgo de no poder acceder a ellos a tiempo.

3. Continuidad de la actividad y resiliencia​

La normativa NIS2 exige un plan de continuidad de la actividad que incluya la resiliencia de los sistemas de información. Un proveedor de servicios en la nube cuya operatividad pueda verse comprometida por una resolución judicial estadounidense (orden judicial, congelación de activos) supone un riesgo inaceptable para la continuidad de las entidades esenciales.

4. Sanciones​

En el caso de las entidades esenciales, las sanciones previstas en la Directiva NIS2 pueden ascender a 10 millones de euros o el 2 % de la facturación mundial. Los directivos también pueden incurrir en responsabilidad personal. En este contexto, optar por un servicio de alojamiento «barato pero arriesgado» ya no resulta racional desde el punto de vista económico.

El RGPD y los datos industriales​

El RGPD se aplica a los datos de carácter personal, lo que puede incluir datos industriales si permiten identificar a una persona física. Ejemplos típicos:

• Datos de acceso remoto: quién se ha conectado a qué controlador (identificador nominal)
• Registros de producción: datos de productividad por operario/máquina (si están vinculados a una persona)
• Datos de mantenimiento: quién ha realizado qué intervención (técnico identificado)
• Alarmas con asignación: qué persona ha confirmado qué alarma

En el caso de estos datos, el RGPD prohíbe cualquier transferencia fuera del Espacio Económico Europeo sin un mecanismo de protección adecuado (cláusulas contractuales tipo, normas corporativas vinculantes, etc.). Desde la invalidación del Privacy Shield en 2020 (sentencia Schrems II), las transferencias a Estados Unidos son especialmente delicadas desde el punto de vista jurídico.

Alojar en Francia elimina cualquier ambigüedad: los datos permanecen en el EEE, bajo la jurisdicción del RGPD, sin necesidad de justificar ningún mecanismo de transferencia.

Certificaciones importantes para la industria francesa​

No todos los proveedores de alojamiento franceses son iguales. Para una infraestructura de IoT industrial crítica, busca estas certificaciones:

ISO 27001​

Certificación de referencia en materia de seguridad de la información. Imprescindible. Exige un SMSI (Sistema de Gestión de la Seguridad de la Información) documentado y auditado anualmente.

HDS (Proveedor de alojamiento de datos sanitarios)​

Obligatorio para los datos sanitarios (sector farmacéutico, hospitales, productos sanitarios). Referencial ANSSI/MiPih.

SecNumCloud​

La certificación de la ANSSI para servicios en la nube de confianza. El nivel de seguridad más alto disponible para la nube francesa. Recomendado para las OIV y las entidades esenciales NIS2. Proveedores actuales: OVHcloud, Outscale (Dassault Systèmes) y Oodrive.

CSP (proveedor de servicios en la nube) certificado por la ANSSI​

Lista de proveedores certificados para sistemas de información sensibles.

Atención: algunos proveedores anuncian un «alojamiento en Francia», aunque en realidad son filiales de empresas estadounidenses sujetas a la ley CLOUD Act. Exige un certificado que acredite que el proveedor no está sujeto a ninguna ley extraterritorial que permita el acceso a tus datos sin previo aviso.

Casos concretos: ¿a qué empresas les afecta esto?​

Operadores de importancia vital (OIV)​

Los 12 sectores OIV de Francia (energía, agua, transporte, alimentación, finanzas, sanidad, etc.) tienen obligaciones específicas en materia de seguridad digital desde la Ley de Programación Militar (LPM) de 2013. Para ellos, el alojamiento de los datos de supervisión en centros de datos franceses homologados no es una opción, sino un requisito contractual de la ANSSI.

Entidades esenciales e importantes de NIS2​

Con NIS2, el ámbito de aplicación se amplía considerablemente:

• Todas las empresas con más de 250 empleados en los sectores afectados
• Subcontratistas críticos del sector de la defensa
• Operadores de redes locales de agua y energía (incluso de tamaño medio)
• Laboratorios farmacéuticos y fabricantes de productos sanitarios

Pymes industriales que exportan a clientes sensibles​