Implementar IoT industrial en planta: guía paso a paso

Implementar IoTITérminoIoT (Internet de las cosas)El IoT (Internet of Things) es la red de objetos físicos con sensores, software y conectividad que recogen e intercambian datos y actúan de forma autónoma.Ver perfil industrial en una planta que ya produce sale bien si se respeta un orden: primero el problema, después las señales y al final la tecnología.

Pongamos un caso habitual. Lucía dirige el mantenimiento de una planta de envases de plástico con 38 máquinas y tres turnos. Su director le pide «conectar la fábrica», y el integrador hace exactamente eso: en cinco meses lleva a un panel 1.900 variables de los PLC, de los analizadores de red y de una docena de sensores nuevos.

El panel funciona. Nadie lo abre después de la segunda semana, porque nadie sabe qué pregunta responde.

Lo que atascó el proyecto fue el orden en que se hicieron las cosas, y no tener esa visibilidad sale caro: según el informe The True Cost of Downtime 2024 de Siemens, las 500 mayores empresas del mundo pierden casi 1,4 billones de dólares al año por paradas no planificadas, el 11 % de sus ingresos. El propio informe lo compara con el PIB de España.

Esta guía propone siete pasos para implementar IoT industrial en una planta existente, en el orden en que conviene darlos: la pregunta de negocio y su línea base, el inventario de señales, la conexión sin tocar el control, el modelo de datos, el piloto con criterios de salida, la integración con los sistemas de la planta y el escalado. Está pensada para integradores y fabricantes de equipos que llevan estos proyectos a clientes como la planta de Lucía, y cada paso se puede usar como fase de la oferta. Si antes quieres ver qué casos de uso encajan en cada sector, empieza por las soluciones de IoT industrial por sector.

Paso 1: decide para qué implementar IoT industrial

Un proyecto de IoT industrial necesita una pregunta que alguien de operaciones quiera ver contestada cada semana.

«Digitalizar la planta» no es una pregunta. «¿Por qué la línea 3 pierde 40 horas al mes en paradas no planificadas?» sí lo es.

Las preguntas que mejor arrancan un proyecto afectan a un coste que la dirección ya conoce, se pueden medir con pocas señales y tienen un responsable con nombre en planta. Algunos ejemplos:

• Paradas no planificadas en un grupo concreto de máquinas.
• Consumo eléctrico por unidad producida en una línea.
• Tasa de rechazo en un proceso que depende de temperatura o presión.
• Tiempo que un equipo crítico pasa funcionando fuera de su rango.

Mide la línea base antes de instalar nada

Antes de comprar un solo sensor, apunta cómo está hoy el indicador. Muchas veces el dato ya existe en los partes de turno, en el ERP o en la factura eléctrica. Con dos a cuatro semanas de registros hay un punto de partida.

Si el indicador es la eficiencia general de los equipos (OEE), acuerda la fórmula con operaciones desde el principio: disponibilidad × rendimiento × calidad. Una línea con un 90 % de disponibilidad, un 95 % de rendimiento y un 98 % de calidad tiene un OEE del 83,8 %. Cuando dos departamentos calculan el OEE de forma distinta, acaban discutiendo la cifra en lugar de la línea.

Deja por escrito qué resultado justificaría seguir. Por ejemplo, reducir un 15 % las horas de parada de la línea 3 en tres meses. Sin ese número, el piloto no tiene forma de terminar.

Para ver qué cubre la plataforma dentro de una fábrica antes de preparar la oferta, consulta la página de IoT industrial.

Paso 2: haz el inventario de la planta antes de diseñar

El segundo paso se da recorriendo la planta con una libreta. De esa visita sale una lista de señales: una tabla con cada dato que hace falta para responder a la pregunta del paso 1 y el sitio del que va a salir.

La lista de señales

Cada fila describe una señal. Estas son las columnas que más problemas evitan después:

La columna de responsable es la que más se olvida: dice a quién preguntar cuando un valor no cuadra o cuando hay que pedir acceso a un equipo. La lista crece con el proyecto, pero su primera versión debería caber en una hoja. Si el piloto necesita más de 100 señales para contestar una sola pregunta, la pregunta es demasiado amplia.

Los protocolos que vas a encontrar

En una planta con años de historia conviven varias generaciones de equipos. Estos son los protocolos más frecuentes:

• ModbusMProtocoloModbusEl bus de campo industrial más extendidoVer perfil RTU y Modbus TCP, el protocolo que Modicon publicó en 1979 y que sigue presente en analizadores de red, variadores y PLC de todas las épocas.
• OPC UAOProtocoloOPC UAEstándar de interoperabilidad para la automatización industrialVer perfil, el estándar de la OPC Foundation recogido en la IEC 62541, frecuente en controladores y sistemas SCADA más recientes.
• Los protocolos propios de cada fabricante de PLC, que suelen necesitar un driver específico o una pasarela.
• Las señales analógicas de 4-20 mA y los contactos libres de tensión, en máquinas sin comunicaciones.

Las máquinas sin un PLC accesible no se quedan fuera. Se instrumentan con sensores externos que no tocan el proceso: pinzas amperimétricas para el consumo, sondas de vibración con base magnética en los rodamientos y sondas de temperatura de superficie. La guía de integración de IoT con PLC repasa las opciones de conexión con más detalle.

Lo físico y lo contractual

La lista de señales no está completa sin tres comprobaciones que se olvidan a menudo:

1. Espacio y alimentación en los armarios. Un gateway necesita carril DIN, alimentación a 24 V y sitio para el cableado.
2. Zonas con atmósferas explosivas. Si una parte de la planta está clasificada como zona ATEX, los equipos que se instalen ahí tienen que cumplir la Directiva 2014/34/UE.
3. Condiciones del fabricante de la máquina. Algunos contratos de garantía no permiten conectarse al PLC sin su autorización. Conviene preguntarlo antes de diseñar.

Paso 3: conecta la planta sin tocar el lazo de control

Para implementar IoT industrial sin poner en riesgo la producción, la regla del primer año es sencilla: se lee de la red de planta y no se escribe en ella. La plataforma observa. Las órdenes a máquina, si llegan, llegan cuando el equipo de planta ya confía en los datos.

Un gateway entre la red de planta y la plataforma

La pieza central es un gateway industrial instalado en el borde de la red. Lee los PLC y los medidores por Modbus u OPC UA, traduce las lecturas a MQTTProtocoloMQTTEl protocolo pub/sub estándar del IoTVer perfil y las envía a la plataforma. En su diseño pesan sobre todo tres decisiones:

• Solo abre conexiones salientes. El gateway inicia la conexión hacia la plataforma, por ejemplo con MQTT sobre TLS en el puerto 8883, así que no hay que abrir puertos de entrada en el cortafuegos de la planta.
• Guarda las lecturas en local. Si se cae el enlace, el gateway guarda las lecturas y las reenvía al recuperarlo (store-and-forward). Una caída de la conexión no deja huecos en el histórico.
• Accede en modo de solo lectura. Cuando el controlador lo permite, se usa una cuenta sin permisos de escritura y se leen solo los registros que figuran en la lista de señales.

Si todavía no has decidido cómo recibirá la plataforma los mensajes, la guía sobre qué es un broker MQTT explica el modelo de publicación y suscripción.

Segmentación y normativa

Las redes de planta están separadas de las de oficina por buenos motivos. La serie ISA/IEC 62443 organiza la seguridad de los sistemas de automatización en zonas y conductos: los equipos con requisitos parecidos forman una zona, y el tráfico entre zonas pasa por un conducto controlado. El gateway encaja en ese papel.

La guía NIST SP 800-82 Rev. 3, publicada en 2023, desarrolla las mismas ideas para toda la tecnología operativa.

Además, para muchas empresas hay una obligación legal. La Directiva NIS2 incluye en su anexo II la fabricación de maquinaria, de equipos eléctricos y de vehículos, además de la producción industrial de alimentos y de productos químicos. Las medianas y grandes empresas de esos sectores deben gestionar sus riesgos de ciberseguridad, y la red de planta forma parte de ese perímetro. La guía de ciberseguridad OT para IA industrial e IoT baja estas medidas al terreno.

Falta una decisión de arquitectura: nube o servidores propios. Algunas plantas exigen que los datos no salgan del recinto, por política interna o por latencia. La comparativa entre plataforma IoT on-premise y en la nube ayuda a tomarla.

Paso 4: construye el modelo de datos antes del primer panel

Una señal sin contexto es solo un número. «Registro 40112 = 612» no dice nada. «Temperatura del aceite de la prensa 4, línea 3: 61,2 °C» sí.

El modelo de datos hace esa traducción, y conviene fijarlo antes de dibujar el primer gráfico.

Una jerarquía que permita comparar

El estándar ISA-95, recogido en la IEC 62264, propone una jerarquía de equipos que funciona bien como punto de partida: empresa, emplazamiento, área, línea de producción y unidad de trabajo. Debajo de cada unidad cuelgan sus señales. Con esa estructura, comparar la misma máquina en dos plantas se resuelve con una consulta.

Tres reglas ahorran semanas de limpieza de datos:

1. El mismo nombre para la misma señal en todas las máquinas del mismo tipo, con la unidad incluida.
2. La escala se aplica una sola vez, en el gateway o en la plataforma, nunca en los dos sitios.
3. Todas las marcas de tiempo van en UTC, con los relojes de gateways y PLC sincronizados por NTP.

Frecuencia de muestreo y volumen de datos

No todas las señales necesitan la misma frecuencia. El consumo eléctrico se suele leer cada uno o quince minutos. Los estados de máquina (marcha, paro, fallo) conviene enviarlos cuando cambian. Las temperaturas de proceso quedan bien cada 10 o 30 segundos.

La vibración se procesa en el sensor o en el borde, y lo que se envía son indicadores, no la forma de onda completa.

Haz la cuenta antes de dimensionar el almacenamiento. Si 400 señales se envían cada 10 segundos, la plataforma recibe 3.456.000 lecturas al día y más de 100 millones al mes. Para una plataforma preparada no es un problema, pero cambia el presupuesto de conectividad si los datos salen por red móvil.

Un caso real: dos plantas con un solo modelo

CALSA, fabricante de levaduras del grupo AB Mauri, tenía dos plantas en Argentina, en Lanús y en Tucumán, cada una con sus datos guardados en sistemas locales distintos. Comparar la producción de las dos obligaba a consolidar a mano. La solución empezó con un gateway de software que convierte a MQTT las señales Modbus de los PLC existentes, sin cambiar hardware ni reprogramar los controladores, y con un modelo común para ambas plantas.

Sobre esa base se añadieron medidores de energía en las máquinas críticas, seguimiento GPS de la flota y paneles adaptados a cada rol. El caso de CALSA lo cuenta completo.

Paso 5: prueba en una línea con criterios de salida escritos

El piloto sirve para tomar una decisión. Por eso conviene dejar por escrito, antes de empezar, qué tiene que pasar para ampliar el proyecto y qué hará que se detenga.

Un buen piloto de IoT industrial tiene un alcance acotado (una línea o un grupo de máquinas iguales, con la pregunta del paso 1), una duración cerrada y unos criterios de salida acordados con operaciones. Entre ocho y doce semanas suelen bastar para ver varios ciclos de producción y alguna avería.

Los criterios más habituales son cinco:

1. Datos completos. Llega al menos el 98 % de las lecturas esperadas, medido cada semana.
2. Alarmas útiles. Cada alarma tiene un destinatario y una acción. Si una alarma salta diez veces por semana y nadie hace nada, sobra o está mal ajustada.
3. Indicador frente a la línea base. El número del paso 1 se ha movido en la dirección esperada, o se sabe por qué no lo ha hecho.
4. Uso diario. Los jefes de turno consultan el panel sin que nadie se lo recuerde.
5. Responsable y presupuesto para la fase siguiente.

Alarmas que la planta pueda atender

En planta, una alarma útil combina un umbral con una duración. «Temperatura del aceite por encima de 70 °C durante más de cinco minutos» filtra los picos de arranque que una regla simple convertiría en ruido. Conviene añadir un modo mantenimiento, para que una intervención programada no dispare avisos, y vigilar también el silencio: una máquina que deja de enviar datos ya es motivo de aviso.

Que un piloto cumpla sus criterios no significa que el despliegue esté resuelto. Lo que cambia al multiplicar los equipos (altas masivas, actualizaciones remotas, coste por equipo) está en la guía sobre pasar de prototipo IoT a producción.

¿Llevas pilotos industriales para tus clientes y quieres ofrecerlos con tu propia marca? El programa de partners explica cómo trabajamos con integradores.

Paso 6: lleva los datos a donde se trabaja

Un panel que obliga a abrir otra aplicación compite con todo lo demás que pasa en un turno. Los datos de planta rinden más cuando llegan a las personas que pueden actuar y a las herramientas que ya usan.

Un panel por rol

Cada perfil necesita ver algo distinto:

Cuando un mismo panel intenta servir a todos, cada perfil tiene que buscar su dato entre los de los demás. En el proyecto de CALSA, los paneles por rol fueron una de las piezas de la solución.

Integración con mantenimiento, ERP y BI

La integración que antes se amortiza suele ser la de mantenimiento. Cuando una bomba supera las horas de funcionamiento previstas, o su vibración sube de forma sostenida, la plataforma puede abrir una orden de trabajo en el programa de gestión del mantenimiento (GMAO) mediante un webhook o la API. El dato se convierte en tarea sin que nadie copie números a mano. A partir de ahí, el mantenimiento predictivo con IoT e IA es el siguiente escalón.

Con el ERP se cruzan los datos de máquina con las órdenes de fabricación, para saber qué producto se estaba haciendo cuando hubo una parada. A las herramientas de BI se les envían agregados por hora o por turno, no lecturas en bruto.

Paso 7: amplía el proyecto a más líneas y plantas

Al pasar de una línea a toda la planta se gana o se pierde el retorno de la inversión. Un piloto montado a mano cuesta mucho repetirlo; si se montó con plantillas, se puede copiar a las máquinas siguientes.

Plantillas por tipo de activo

Cada tipo de máquina (prensa, compresor, bomba, horno) debería tener su plantilla, con sus señales, unidades, reglas de alarma y panel. Así, añadir la prensa número doce consiste en aplicar la plantilla y asignar direcciones, sin rediseñar nada.

Despliegue por oleadas

Volvamos a la planta de Lucía, esta vez con el orden correcto. El piloto en las cuatro prensas de inyección cumple sus criterios en diez semanas: las horas de parada de esas prensas bajan un 18 % y los jefes de turno usan el panel a diario.

El despliegue se hace en tres oleadas. Primero, el resto de prensas, con la misma plantilla. Después, compresores y enfriadoras, que comparten el objetivo de consumo. Por último, las extrusoras, que necesitan sensores nuevos. Cada oleada empieza con su lista de señales y termina con la misma revisión de criterios que el piloto.

Quién opera el sistema

Quien vaya a implementar IoT industrial en varias plantas necesita decidir quién se ocupa del sistema cuando termina el proyecto. Estas preguntas deberían estar contestadas antes de la última oleada:

• Quién da de alta un equipo nuevo y quién lo retira.
• Quién actualiza los gateways y cada cuánto.
• Quién revisa las reglas de alarma cuando cambia un proceso.
• Cuántos gateways de repuesto hay en almacén.
• Cada cuánto se compara el indicador con la línea base.

Para un integrador, estas preguntas también son una oportunidad. Operar el sistema es un servicio recurrente que el cliente necesita y que rara vez quiere asumir solo. Con una plataforma multi-tenant, cada cliente tiene su espacio aislado y el integrador los gestiona todos desde una sola instancia.

Conclusiones

• Implementar IoT industrial empieza por una pregunta con un coste conocido, una línea base medida y un responsable en planta.
• La lista de señales, con origen, protocolo, unidad y frecuencia, evita la mayoría de las sorpresas del despliegue.
• El primer año se lee de la planta y no se escribe en ella. Un gateway con conexiones salientes y almacenamiento local conecta sin abrir puertos y encaja con la segmentación de la IEC 62443 y con las obligaciones de NIS2.
• El modelo de datos, con su jerarquía, nombres, unidades y horas en UTC, decide si se podrán comparar máquinas y plantas.
• El piloto termina con criterios escritos, y la ampliación se hace con plantillas y por oleadas.

Cloud Studio IoT da a integradores y fabricantes la plataforma para llevar estos proyectos con su propia marca: conversión de protocolos industriales como Modbus u OPC UA a MQTT, broker MQTTBTérminoBroker MQTTUn broker MQTT es el servidor central que recibe los mensajes de los publishers y los distribuye a los subscribers según los temas. Ejemplos: Mosquitto, EMQX, HiveMQ.Ver perfil integrado, alarmas por reglas con avisos por correo, SMS, notificación push y webhook, paneles por rol, API y despliegue en la nube o en los servidores del cliente. Si tienes una planta a punto de empezar, solicita una demo y trae la lista de señales. Con ella delante, la primera llamada ya puede hablar de números.