Red para IoT de fábrica y almacén se dobla primero

26.07.2026

5 min de lectura

El seguimiento de contenedores y activos rara vez fracasa por la capa de la aplicación. Fracasa en los límites de las redes WLAN, de campus y de área amplia entre la planta, el almacén y el transportista. La arquitectura de red empresarial se convierte así en el cuello de botella del caso de uso mucho antes de que los cuadros de mando y los KPI entren en juego.

Lo más importante en resumen

La red es el cuello de botella. El seguimiento falla en los límites de las redes WLAN, de campus y de área amplia entre la planta, el almacén y el transportista, mucho antes de que los cuadros de mando y los KPI entren en juego.
Primero, el perfil de tráfico. Intervalos de hasta 5 segundos, latidos (heartbeats) cada 30 segundos y cargas útiles (payloads) de unos 100 hasta unos pocos cientos de bytes determinan la dimensionamiento de celdas, enlaces ascendentes y operadores.
Las transiciones rompen el seguimiento. El roaming entre la WLAN de la planta, el almacén y la red móvil pública cambia identidades y zonas; un campus aislado solo desplaza el cuello de botella al enlace de retorno (backhaul).
Compartir la operación. Las áreas de red y TI logística gestionan conjuntamente el registro, certificados, alarmas y rutas de incidentes; los pilotos deben probar el roaming, los picos de carga y las caídas del enlace ascendente.

RelacionadoCuando el taller y el centro de datos se convierten en una red / Redes 5G campus: la Bundesnetzagentur asigna 465 frecuencias

Perfiles de tráfico en seguimiento y telemetría

La carga de seguimiento y telemetría no es un tráfico de oficina clásico ni un patrón puro de SCADA. Las actualizaciones de ubicación, los envíos de sensores, los latidos (heartbeats) y los mensajes de estado generan numerosas comunicaciones pequeñas, a menudo periódicas y con prioridades desiguales. Una etiqueta de contenedor que informa cada pocos segundos sobre su posición y estado satura las celdas de radio y los puntos de acceso de manera distinta a una carga por lotes al final del turno.

Por ello, la arquitectura debe aclarar primero el perfil de tráfico: intervalo de actualización, tamaño de la carga útil (payload), comportamiento de envíos masivos (burst), almacenamiento en búfer sin conexión y qué datos deben ser casi en tiempo real. Según los datos de los fabricantes, los rastreadores industriales especifican intervalos de posición configurables a partir de 5 segundos y latidos (heartbeats) cada 30 segundos; el almacenamiento en búfer sin conexión con posterior carga masiva (burst upload) es habitual. Los dispositivos adaptativos reducen la frecuencia en estado de reposo y la aumentan al detectar movimiento. En la práctica, el tamaño de la carga útil por mensaje suele oscilar entre unos 100 y unos pocos cientos de bytes. Sin este perfil, la dimensionamiento de celdas WLAN, enlaces ascendentes de campus y conexiones a operadores sigue siendo una estimación.

Al mismo tiempo, el tráfico ascendente y descendente difieren. El seguimiento envía principalmente datos desde el campo hacia el centro de datos o la nube. La configuración, las actualizaciones de firmware y las políticas se transmiten en sentido inverso. Quien solo planifica el flujo de medición y descuida la vía de control descubre los cuellos de botella en el despliegue. La telemetría sin un canal de retorno controlable es operativamente incompleta.

Campus, redes 5G de campus y conexión a operadores en combinación

Las redes de fábrica y almacén rara vez son un único medio. El WLAN de naves, los segmentos cableados de planta, las redes privadas 5G de campus y la conexión pública a operadores se combinan. Cada capa tiene sus propias condiciones de radio, reglas de roaming y supuestos de calidad de servicio. La guía del Ministerio Federal de Economía y Protección del Clima (BMWK) «Redes 5G de campus» describe las redes privadas de campus como redes de radio geográficamente limitadas y adaptadas localmente para producción y logística, destacando la calidad de servicio controlable en cuanto a latencia, fiabilidad y disponibilidad. La especificación 3GPP TS 22.104 recopila los requisitos de servicio para aplicaciones de control ciberfísicas en dominios verticales, incluyendo el monitoreo de procesos y activos en fábricas. Los acuerdos de Carrier-Ethernet-SLA, especificados por el MEF, definen parámetros como Frame Delay, Frame-Delay-Variation y Frame Loss; los contratos de MPLS y SD-WAN aplican parámetros similares.

El punto crítico se encuentra en las transiciones. Un activo que pasa del WLAN de la fábrica al WLAN del almacén y, más tarde, a través de redes móviles públicas, cambia de identidades, espacios de direcciones y zonas de seguridad. Sin una planificación de ruta continua, el seguimiento se interrumpe exactamente donde la utilidad operativa es mayor: entre la puerta, el patio, el almacén y la cadena de transporte.

Las redes 5G de campus alivian las naves densas y las áreas móviles. Sin embargo, no reemplazan la conexión a los sistemas centrales. El enlace de retorno (backhaul) hacia el centro de datos o la multi-nube suele seguir siendo MPLS, VPN por Internet o Carrier-Ethernet. Quien dimensiona el campus de forma aislada y trata el tráfico de larga distancia como un residual, solo desplaza el cuello de botella una capa más allá.

Segmentación, latencia y escenarios de fallo

Las zonas de OT, IoT y TI empresarial no deben fusionarse en un único dominio de confianza plano. Las identidades de los dispositivos, las zonas de red y las relaciones de comunicación permitidas deben definirse antes de implementar el seguimiento, no después. El compendio de seguridad ICS del BSI en su versión 2.0 (2024) exige una segmentación planificada de la red OT: separación vertical según la jerarquía de producción con una DMZ OT entre TI y OT, así como separación horizontal de instalaciones y máquinas. Hace referencia al modelo Purdue y al concepto de Zonas y Conductos de la norma IEC 62443. Las zonas agrupan activos con necesidades de seguridad similares. Los conductos son los caminos de comunicación controlados entre ellas.

Los requisitos de latencia son específicos según el caso de uso. Para muchos escenarios de seguimiento, bastan intervalos de segundos. Para el control de puertas, la reubicación automatizada o eventos cercanos a la seguridad, pueden aplicarse límites más estrictos. La planificación de red debe separar estas clases. De lo contrario, los picos de telemetría competirán con el tráfico de control y de oficina por los mismos caminos.

Los escenarios de fallo deben formar parte del mismo diseño. ¿Qué ocurre si el WLAN de la nave está saturado, la celda del campus falla o el enlace de subida del operador se ralentiza? El almacenamiento local, el envío y reenvío (store-and-forward), la precisión degradada de la localización y una lógica clara de timeouts son decisiones arquitectónicas. Un seguimiento que solo funciona en una red ideal no es un modelo operativo.

Responsabilidad operativa entre red y TI de logística

Muchos proyectos comienzan como iniciativas de logística o cadena de suministro y tratan la red como una commodity. Esta es la trampa típica: tras el piloto, aparecen lagunas de cobertura, conflictos de VLAN, problemas de certificados y rutas de incidentes poco claras. Por ello, el equipo de red y la TI de logística necesitan compartir la responsabilidad operativa desde el principio.

Esto afecta al registro de dispositivos (onboarding), el ciclo de vida de los certificados, las actualizaciones de firmware, el enrutamiento de alarmas y la gestión de cambios. Quien coloca un dispositivo de seguimiento en la nave sin aclarar quién gestiona la calidad de radio, la identidad y la política, genera TI en la sombra en el entorno OT. La publicación especial NIST 1800-36 describe el registro seguro en la capa de red y la gestión del ciclo de vida para dispositivos IoT: aprovisionar credenciales, proteger dispositivos y redes, automatizar procesos de ciclo de vida. El compendio de seguridad ICS del BSI complementa esto con la necesidad de procesos operativos claros, documentación y la colaboración entre expertos de TI y OT en segmentación de red, monitorización y respuesta a incidentes.

Igualmente clara debe ser la soberanía sobre los datos. La posición y el estado son datos operativos. A menudo afectan a sistemas de inventario, MES y TMS. La red proporciona el transporte y los límites de zona. La TI de logística aporta la lógica especializada. Sin un contrato de interfaz entre ambas partes, los errores siguen sin estar claros: ¿es un problema de radio, enrutamiento, identidad o aplicación?

Revisión de arquitectura antes del despliegue de seguimiento

Antes de proceder con el despliegue masivo, conviene realizar una breve revisión de la arquitectura. En primer lugar, definir clases de tráfico y latencia. A continuación, evaluar la cobertura y la combinación de medios para taller, patio y almacén, incluyendo las transiciones entre operadores. Paralelamente, establecer la segmentación, la identidad de los dispositivos y los flujos permitidos, reflejándolos en los requisitos de seguridad.

En tercer lugar, documentar el modelo operativo y las vías de escalación: quién mide qué, quién aplica parches, quién abre el incidente en caso de fallo. En cuarto lugar, diseñar el piloto para que ponga a prueba los límites críticos: roaming entre naves, picos de carga en los cambios de turno, caída del uplink y renovación de identidad. Un piloto limitado a la mejor celda de la mejor nave demuestra poco.

Quienes inician el seguimiento como un mero proyecto de aplicación descubren demasiado tarde y a un coste elevado las restricciones de red y seguridad. En cambio, quienes planifican las redes empresariales, la conexión del campus y las rutas de los operadores antes del caso de uso convierten la conectividad de la planta y el seguimiento de activos en un proyecto gestionable de Capex y operaciones, en lugar de una sucesión de subsanaciones.

Preguntas frecuentes

¿Por qué dimensionar solo según el ancho de banda pico suele no ser suficiente?

El seguimiento genera numerosos mensajes pequeños y periódicos con prioridades desiguales, en lugar de grandes cargas de datos en lotes. Las celdas de radio y los puntos de acceso reaccionan a intervalos, ráfagas y colas de mensajes pendientes de manera distinta al tráfico de oficina o SCADA puro. Sin definir intervalos de actualización, tamaño de carga útil y clases de prioridad, la WLAN, el uplink del campus y la conexión del operador quedan reducidos a meras estimaciones.

¿Cuándo una red privada 5G en el campus alivia realmente la carga en las naves?

Las redes privadas de campus son útiles en naves densas y áreas móviles con latencia y disponibilidad controlables. No sustituyen la conexión con el centro de datos o la nube múltiple: el backhaul suele seguir siendo MPLS, VPN o Ethernet del operador. Quienes planifican el campus de forma aislada y tratan el tráfico de larga distancia como un factor residual solo trasladan el cuello de botella una capa más allá.

¿Qué segmentación se considera el mínimo indispensable antes del despliegue de seguimiento?

Las zonas OT, IoT y TI empresarial deben permanecer como dominios de confianza separados con identidades y flujos permitidos definidos. El compendio de seguridad ICS del BSI exige una separación vertical con DMZ para OT, así como una separación horizontal de instalaciones; las zonas y conductos según IEC 62443 agrupan necesidades de seguridad similares y rutas controladas. La segmentación y la identidad deben establecerse antes del despliegue, no después.

¿Qué debe cubrir el piloto para anticiparse al entorno de producción?

El piloto evalúa los límites críticos: roaming entre naves, picos de carga en los cambios de turno, caída del uplink del operador y renovación de identidad. Incluye además el almacenamiento local en búfer, el reenvío de mensajes y la lógica de tiempo de espera en caso de sobrecarga de la WLAN o fallo de la celda del campus. Medir solo en la mejor celda de la mejor nave no demuestra la madurez operativa.