Entienda qué es IIoT, la arquitectura Industrial Internet of Things, edge, gateways, OPC UA, MQTT, ciberseguridad, analytics, mantenimiento e implantación a escala.
¡Descúbrelo!
IIoT, o Industrial Internet of Things, es el uso de sensores, dispositivos, gateways, redes, edge computing y plataformas de datos para conectar activos y procesos industriales y transformar datos operativos en monitoreo, diagnóstico, análisis y toma de decisiones. A diferencia de la IoT de consumo, IIoT opera en entornos donde disponibilidad, seguridad, ciclo de vida de los activos, interoperabilidad con sistemas legados e impacto físico de las fallas son requisitos de ingeniería. Un proyecto IIoT consistente comienza por el caso de uso y los requisitos del proceso, define dónde se recopilarán y procesarán los datos, establece la integración con automatización y sistemas corporativos y aborda ciberseguridad, gobernanza y operación desde la arquitectura.
Qué es IIoT
Industrial Internet of Things es la aplicación de los principios de Internet de las Cosas al entorno industrial. El objetivo no es simplemente “conectar equipos a internet”, sino obtener datos de activos y procesos de forma controlada para aumentar la visibilidad, apoyar el mantenimiento, mejorar el desempeño, reducir desperdicios, automatizar análisis o habilitar nuevos modelos de operación.
Una solución puede utilizar sensores dedicados, variables ya disponibles en PLC y sistemas SCADA, gateways industriales, servidores edge, brokers de mensajes, historiadores, bases de datos, plataformas analíticas y aplicaciones locales o en la nube. La combinación adecuada depende del caso de uso y de las restricciones de la instalación.
IIoT se conecta directamente con el universo de la automatización industrial, pero no lo sustituye. El control de procesos, la protección y las funciones determinísticas siguen exigiendo arquitecturas apropiadas; IIoT normalmente agrega capacidad de observación, contextualización, integración y análisis.
Cuál es la diferencia entre IoT e IIoT
IoT e IIoT utilizan tecnologías similares de conectividad, procesamiento y datos, pero el contexto de aplicación modifica significativamente los requisitos.
En IoT de consumo, la pérdida temporal de un dispositivo puede ser un inconveniente. En IIoT, una falla de comunicación o un comando inadecuado puede afectar la producción, la calidad, la integridad de un equipo o la seguridad de las personas. Por ello, las decisiones de arquitectura deben considerar las consecuencias físicas y la continuidad operativa.
Disponibilidad y determinismo
No toda aplicación IIoT necesita comunicación determinística. Monitorear vibración cada minuto es diferente de cerrar un lazo de control en milisegundos. El error es colocar funciones críticas en una arquitectura de datos que no fue diseñada para ello.
Una buena separación de responsabilidades mantiene el control crítico cerca del proceso y utiliza IIoT para recopilación, análisis, optimización e integración cuando la latencia y la disponibilidad lo permiten.
Ciclo de vida
Los equipos industriales pueden permanecer en operación durante décadas. Esto contrasta con los ciclos cortos de los dispositivos de consumo y servicios de software. Un proyecto IIoT debe considerar actualización, soporte, certificados, compatibilidad de protocolos y sustitución de gateways a lo largo de su vida útil.
Entorno físico
Temperatura, polvo, vibración, interferencia electromagnética, alimentación, puesta a tierra y disponibilidad de red influyen en la selección del hardware. Un sensor adecuado para laboratorio puede ser inadecuado para un CCM, un patio de subestación o un área de proceso.
Ciberseguridad
IIoT introduce nuevos canales de comunicación entre activos, edge, plataformas locales, servicios en la nube y usuarios remotos. Esto amplía la superficie de ataque y exige una arquitectura de seguridad compatible con el riesgo operacional.
IIoT comienza por el caso de uso, no por la plataforma
IIoT debe comenzar por el problema de ingeniería y por la decisión que mejorará con los datos. Seleccionar una plataforma antes de definir el caso de uso suele generar pilotos técnicamente interesantes, pero sin criterios claros de valor o escalabilidad.
Los proyectos con frecuencia comienzan seleccionando una plataforma IoT y solo después buscan problemas que puedan justificarla. Este camino tiende a producir pilotos interesantes, pero difíciles de escalar o sostener.
La ingeniería debe comenzar por la pregunta: ¿qué decisión o acción mejorará con estos datos?
Un caso de uso debe identificar activo o proceso, variable, frecuencia, calidad del dato, análisis deseado, usuario de la información, decisión asociada y beneficio esperado.
Casos de uso bien definidos
Algunos ejemplos son:
- monitoreo de condición de motores, bombas y ventiladores;
- análisis de vibración y temperatura;
- seguimiento del consumo energético;
- detección de degradación de baterías y UPS;
- monitoreo remoto de activos dispersos;
- indicadores de disponibilidad y utilización;
- seguimiento de calidad del proceso;
- alarmas analíticas basadas en tendencias;
- alimentación de sistemas de mantenimiento;
- soporte a modelos de Digital Twin.
Cada caso tiene requisitos diferentes. Un dashboard mensual de energía no necesita la misma arquitectura que la detección casi en tiempo real de una condición de falla.
Arquitectura IIoT: del campo al uso del dato
La arquitectura debe preservar el origen y el contexto del dato. Entre el sensor y la aplicación final pueden existir varias transformaciones: recopilación, normalización, almacenamiento, agregación, enriquecimiento y análisis.
Si estas etapas no se gobiernan, el usuario final recibe un número sin conocer su origen, unidad, calidad o timestamp.
Sensores y datos existentes
No todo proyecto requiere nuevos sensores. Muchas variables ya están disponibles en PLC, IED, variadores, medidores, SCADA o historiadores. El primer análisis debe verificar si el dato existente es adecuado para el caso de uso.
Agregar sensores puede ser necesario cuando la variable no existe, cuando la resolución es insuficiente o cuando acceder al sistema de control crearía riesgo o complejidad innecesarios.
Gateways industriales
Los gateways conectan dispositivos y plataformas. Pueden convertir protocolos, agregar datos, aplicar filtros, ejecutar lógica local, almacenar información temporalmente y establecer comunicación segura con capas superiores.
La selección debe considerar protocolos, capacidad, sistema operativo, actualización, certificados, almacenamiento local, redundancia, condiciones ambientales y ciclo de soporte.
Edge computing
Edge computing procesa datos cerca de la fuente. Esto reduce la dependencia de conectividad externa, limita el tráfico, permite respuesta local y puede preservar datos sensibles dentro de la instalación.
No existe una regla según la cual “edge es mejor que cloud”. La decisión debe basarse en latencia, volumen, criticidad, conectividad, costo y gobernanza.
Plataforma de datos
La plataforma puede incluir broker, historiador, base de datos de series temporales, data lake, servicios analíticos y APIs. La arquitectura debe definir qué componente es la fuente de verdad para cada tipo de información y cómo se versionan o contextualizan los datos.
Edge, on-premises o nube
Una arquitectura IIoT puede operar completamente de forma local, completamente en la nube o mediante un modelo híbrido. El diseño correcto depende de las necesidades operativas.
Cuándo es importante el procesamiento local
Edge u on-premises suele ser adecuado cuando:
- la decisión debe producirse incluso sin conexión externa;
- existen requisitos de baja latencia;
- el volumen bruto de datos es elevado;
- existen restricciones de confidencialidad;
- la aplicación se integra directamente con sistemas OT;
- la disponibilidad de la conectividad externa no es compatible con el proceso.
Cuándo la nube agrega valor
La nube puede facilitar escalabilidad, consolidación multisite, analytics avanzado, colaboración y mantenimiento de plataformas. Sin embargo, la disponibilidad de la aplicación no debe confundirse con la disponibilidad del proceso.
Una función crítica no debe fallar de forma insegura únicamente porque un servicio externo quede indisponible.
Arquitectura híbrida
Muchos proyectos industriales se benefician de un enfoque híbrido: el control y las funciones esenciales permanecen locales; datos seleccionados se envían a servicios centrales o en la nube para análisis, benchmarking y gestión corporativa.
Integración con sistemas de automatización existentes
OPC UA puede estructurar interoperabilidad y contexto entre sistemas industriales, mientras MQTT puede distribuir datos mediante una arquitectura publish/subscribe. La selección del protocolo debe surgir de los requisitos y no de la tendencia tecnológica del momento.
Profundice en OPC UA y la integración con SCADA, Modbus y MQTT
IIoT rara vez nace en una planta vacía. El proyecto debe coexistir con controladores, SCADA, historiadores, redes industriales, CMMS, sistemas de energía y aplicaciones corporativas.
La integración debe minimizar cambios innecesarios en sistemas estables y evitar crear dependencias entre funciones que antes eran independientes.
OPC UA
OPC UA ofrece mecanismos de interoperabilidad y modelado de información que pueden conectar datos industriales con sistemas superiores. La propia OPC Foundation sitúa la arquitectura en un espectro que va desde sensores y controladores hasta MES, ERP, M2M, IIoT y nube.
Esto no significa que OPC UA sea obligatorio. El protocolo debe seleccionarse según los endpoints, el modelo de comunicación, los requisitos de seguridad y el ecosistema existente.
MQTT
MQTT es un protocolo publish/subscribe ligero y ampliamente utilizado en IoT y M2M. En este modelo, los clientes publican mensajes en topics y otros clientes reciben datos mediante un broker.
Para IIoT, este desacoplamiento puede facilitar la distribución de datos a múltiples aplicaciones. Sin embargo, topics, calidad de servicio, retención, autenticación, autorización y disponibilidad del broker deben diseñarse.
MQTT 5.0 es un estándar OASIS. Su uso en infraestructura industrial debe incluir recursos de seguridad y una arquitectura de red adecuada a la criticidad del entorno.
Protocolos legados
Modbus y otros protocolos existentes pueden seguir siendo fuentes de datos. El gateway o conector debe mapear dirección, escala, tipo, unidad y calidad de forma documentada.
Transformar un registro anónimo en un dato confiable exige contexto de ingeniería.
IIoT y SCADA no son lo mismo
SCADA fue concebido para supervisión y control operacional. IIoT amplía la conectividad y el uso de los datos, conectando con frecuencia activos e información con aplicaciones analíticas, mantenimiento, energía y gestión corporativa.
Existe superposición, pero los objetivos son diferentes. Un SCADA puede ser fuente de datos para IIoT; una plataforma IIoT puede ofrecer dashboards; aun así, no es prudente sustituir automáticamente funciones de supervisión y control sin analizar los requisitos.
Evitar duplicidad de la fuente de verdad
Si SCADA, historiador, plataforma IIoT y data lake almacenan la misma variable, la arquitectura debe definir qué registro tiene carácter oficial para cada finalidad. Diferencias de timestamp, interpolación o tratamiento de calidad pueden producir resultados distintos.
IIoT y mantenimiento predictivo
El mantenimiento predictivo es uno de los casos de uso más asociados a IIoT, pero recopilar datos no crea automáticamente una estrategia predictiva.
Es necesario seleccionar modos de falla relevantes, variables capaces de evidenciar degradación, frecuencia de recopilación, baseline, límites y procedimiento de respuesta.
Del sensor a la orden de mantenimiento
El valor aparece cuando la detección produce una acción. Un flujo puede ser: el sensor identifica una tendencia, un algoritmo o regla genera una condición, un especialista la valida, el sistema de mantenimiento recibe una recomendación y la intervención se planifica.
Sin este cierre, la organización solamente acumula alertas.
Falsos positivos y confianza
El exceso de alertas reduce la confianza de los usuarios. Los modelos deben validarse con suficiente histórico, contexto operacional y tratamiento de los cambios de régimen del equipo.
IIoT no elimina la ingeniería de mantenimiento; aporta nuevas evidencias para ella.
Monitoreo de energía y eficiencia operacional
Los medidores conectados pueden proporcionar demanda, energía, factor de potencia, armónicos y otras magnitudes. Su utilidad depende del objetivo: reparto, gestión de demanda, diagnóstico, eficiencia o correlación con producción.
La arquitectura de medición debe considerar clase de los instrumentos, sincronización, periodicidad y ubicación de los puntos. Sumar datos sin comprender la topología eléctrica puede generar conclusiones equivocadas.
Activos remotos y telemetría
IIoT es especialmente útil en activos dispersos: estaciones de bombeo, subestaciones, unidades remotas, infraestructura de telecomunicaciones y equipos distribuidos.
La conectividad puede utilizar redes privadas, celular, radio, fibra u otras tecnologías. La elección debe considerar cobertura, disponibilidad, latencia, costo, redundancia y seguridad.
La telemetría debe prever buffer local cuando exista pérdida temporal de comunicación, si la continuidad del histórico es relevante.
La calidad del dato es un requisito de ingeniería
Un modelo analítico no puede corregir silenciosamente un sensor mal instalado, una unidad incorrecta o un timestamp inconsistente. Antes de analytics, es necesario garantizar una calidad de datos suficiente.
Las dimensiones importantes incluyen exactitud, completitud, actualidad, consistencia, unidad, resolución y trazabilidad.
Contextualización
Un valor de temperatura adquiere significado cuando está asociado a equipo, TAG, ubicación, condición operativa, unidad y límite. Los sistemas IIoT deben preservar estas relaciones.
Las jerarquías de activos y los modelos semánticos ayudan a evitar bases de datos llenas de tags sin contexto.
Sincronización
La correlación entre eventos de diferentes sistemas depende de relojes coherentes. En análisis de causa, diferencias de segundos pueden alterar la interpretación de la secuencia.
El proyecto debe definir fuentes de tiempo y comportamiento ante pérdida de sincronización cuando sea relevante.
Ciberseguridad en IIoT
IIoT introduce canales, componentes y flujos que pueden atravesar las fronteras tradicionales de OT. Por ello, la ciberseguridad debe formar parte de la arquitectura desde el inicio.
Durante 2025, IEC publicó la IEC PAS 62443-1-6, dedicada a la aplicación de la serie IEC 62443 a IIoT. El documento reconoce que IIoT crea nuevos canales de comunicación, reorganiza funciones e introduce nuevas preocupaciones de seguridad, orientando a asset owners y service providers en el uso de la serie 62443 en este contexto.
Identidad de dispositivos
Cada dispositivo o gateway debe tener una identidad controlable. Las credenciales compartidas dificultan la revocación y la auditoría. Los certificados pueden ser apropiados en determinados escenarios, siempre que exista un proceso para emisión, renovación y sustitución.
Firmware y vulnerabilidades
Los dispositivos IIoT agregan software al entorno operativo. Es necesario definir inventario de versiones, política de actualización y evaluación de vulnerabilidades.
Actualizar automáticamente puede ser inadecuado en producción; no actualizar nunca también lo es. La gobernanza debe establecer pruebas, aprobación y ventanas de intervención.
Acceso remoto
El soporte remoto debe contar con autenticación, autorización, registro y revocación. Las conexiones permanentes configuradas solo por conveniencia aumentan la exposición.
Minimización de flujo
No es necesario permitir comunicación bidireccional cuando el caso de uso es únicamente recopilación. Las arquitecturas unidireccionales o reglas restrictivas pueden reducir el riesgo en determinados escenarios.
Gobernanza de los activos IIoT
Un proyecto puede comenzar con diez gateways y crecer hasta cientos. Sin inventario y estándares, cada piloto se convierte en una excepción operacional.
La organización necesita conocer ubicación, modelo, firmware, responsable, dirección, certificados, protocolos, dependencias, aplicación y criticidad de cada dispositivo.
Estándares de arquitectura
Definir modelos aprobados de gateway, sistema operativo, protocolos, nomenclatura, conectividad y seguridad reduce la variedad y facilita el soporte.
La estandarización debe preservar la flexibilidad necesaria para casos legítimos, pero las excepciones deben ser deliberadas.
Integración con mantenimiento y gestión de activos
IIoT genera más valor cuando los datos llegan al proceso de gestión capaz de actuar sobre ellos. Para mantenimiento, esto significa integrar condición con registro de activos, criticidad, histórico y planificación de órdenes.
La arquitectura no necesita necesariamente una integración directa en tiempo real con el CMMS. Puede existir una capa de analytics o workflow, siempre que el ownership y el cierre del proceso estén claros.
Digital Twin
Digital Twin puede utilizar datos IIoT como una de las fuentes para representar el estado y el desempeño de un activo. Sin embargo, el gemelo digital es un concepto más amplio que la adquisición de telemetría.
Un conjunto de sensores conectado a un dashboard no se convierte automáticamente en Digital Twin. Es necesario un modelo, contexto y una relación consistente con el activo físico.
Integración con MES y sistemas corporativos
ISA-95/IEC 62264 proporciona modelos útiles para discutir fronteras y flujos de información entre control, operaciones de manufactura y funciones corporativas. La edición 2025 de la Parte 1 actualiza esta referencia en un escenario de arquitecturas más modulares y orientadas a datos.
IIoT puede crear caminos adicionales de información. Estos flujos deben respetar ownership, semántica y seguridad en lugar de eludir silenciosamente los sistemas oficiales.
Evitar el exceso de integración punto a punto
Cuando cada aplicación crea su propio conector directamente con cada PLC, la arquitectura se vuelve difícil de mantener. Las capas de interoperabilidad, brokers y APIs pueden reducir el acoplamiento, siempre que no creen un nuevo punto único de falla sin tratamiento.
Cómo diseñar un caso de uso IIoT
Un proceso estructurado ayuda a evitar tecnología sin objetivo.
- Definir el problema y la decisión deseada.
- Identificar activos y variables relevantes.
- Verificar si los datos ya existen.
- Definir calidad, frecuencia y latencia necesarias.
- Seleccionar la arquitectura de recopilación y procesamiento.
- Evaluar ciberseguridad e interfaces.
- Definir KPI y criterio de éxito.
- Implementar un piloto controlado.
- Validar beneficio y operación.
- Estandarizar antes de escalar.
Esta secuencia evita que un piloto sea considerado exitoso únicamente porque la tecnología funcionó.
PoC, piloto y producción son etapas diferentes
Una Proof of Concept demuestra la viabilidad técnica de una hipótesis. Un piloto prueba la solución en un contexto más próximo al real. La producción exige escalabilidad, soporte, seguridad, gestión de activos, monitoreo y procesos operativos.
Muchas iniciativas quedan atrapadas entre piloto y producción porque los requisitos de operación no fueron considerados desde el inicio.
El problema del pilot purgatory
Un piloto puede utilizar una cuenta compartida, un gateway improvisado, una base de datos sin backup y una conexión temporal. Esto puede ser aceptable para probar un concepto, pero no para escalarlo.
Antes de producción, las decisiones temporales deben sustituirse por una arquitectura sostenible.
Cómo medir el resultado de un proyecto IIoT
El KPI debe estar vinculado al caso de uso. La cantidad de sensores instalados o el volumen de datos recopilados son indicadores de implantación, no de valor.
Dependiendo del objetivo, pueden medirse reducción de fallas, tiempo de diagnóstico, consumo, disponibilidad, tiempo de respuesta, reducción de inspecciones manuales o precisión de previsión.
Baseline
Sin una condición de referencia, es difícil demostrar la mejora. El proyecto necesita registrar el desempeño antes de la intervención o crear un grupo comparable cuando sea posible.
Beneficio técnico y beneficio económico
No todos los casos generan un ahorro directo inmediato. Algunos aumentan seguridad, trazabilidad o conocimiento operacional. El business case debe explicitar qué tipo de valor se busca.
Cómo escalar IIoT sin multiplicar la deuda técnica
Escalar significa repetir una arquitectura gobernada, no copiar pilotos indefinidamente.
Antes de ampliar, la organización debe definir catálogo de dispositivos, estándares de conectividad, nomenclatura, onboarding, certificados, observabilidad, actualización, backup, soporte y descomisionamiento.
Multisite
En varias unidades, la arquitectura debe equilibrar la estandarización corporativa con las particularidades locales. Un gateway común puede simplificar el soporte; los protocolos y redes de campo pueden variar según la planta.
La plataforma central debe distinguir claramente activos, unidades, permisos y contextos.
Brownfield: cómo conectar activos legados
Los activos antiguos pueden no disponer de protocolos modernos. Esto no significa que deban sustituirse únicamente para incorporarlos a IIoT.
Los gateways pueden recopilar datos de interfaces existentes, pero la ingeniería debe verificar si el acceso afecta el desempeño del controlador y si la red soporta el nuevo tráfico.
El artículo sobre Proyectos Brownfield aborda levantamiento, validación de la condición existente y estrategia de intervención.
No transformar el monitoreo en riesgo operacional
Una iniciativa de analytics no debe aumentar la probabilidad de indisponibilidad del proceso. Las modificaciones en controladores, switches y firewalls deben seguir gestión de cambios y pruebas.
En algunos escenarios, es preferible realizar la recopilación mediante una interfaz ya existente o infraestructura segregada.
Commissioning de una solución IIoT
Una solución IIoT solo está entregada cuando dispositivos, datos, seguridad, integraciones, backups y documentación pueden verificarse. Comisionar el camino completo del dato reduce la diferencia entre un dashboard funcionando y una solución operacionalmente confiable.
IIoT también necesita commissioning. El hecho de que un sensor aparezca en el dashboard no demuestra calidad, seguridad o integración.
Las pruebas pueden verificar:
- identificación y TAG del dispositivo;
- escala y unidad;
- timestamp;
- pérdida y recuperación de comunicación;
- buffer local;
- autenticación;
- renovación o validez de certificados;
- comportamiento del gateway después de reboot;
- disponibilidad del broker;
- calidad del dato;
- alarmas y reglas;
- integración con aplicaciones de destino;
- backup y restauración;
- logs y auditoría.
El commissioning industrial ofrece una base de gobernanza que puede adaptarse al entorno digital y OT.
Documentación y handover
El paquete final debe permitir que el propietario comprenda y administre la arquitectura. Diagramas, inventario, direccionamiento, reglas de firewall, certificados, credenciales, versiones, backups, modelos de datos, topics MQTT, endpoints OPC UA, APIs y procedimientos de soporte son ejemplos de información relevante.
La documentación es especialmente importante porque IIoT combina ingeniería de campo, redes, software y datos. Sin una visión integrada, la solución puede depender del conocimiento tácito del equipo que la implementó.
Cuándo IIoT no es la mejor solución
No todo problema industrial necesita IIoT. Si el objetivo puede resolverse con el SCADA existente, una mejora de instrumentación o una integración simple, agregar una plataforma distribuida puede aumentar la complejidad sin un beneficio proporcional.
También es inadecuado iniciar IIoT cuando no existe un proceso para actuar sobre la información generada. Detectar una condición sin responsable o workflow solamente transfiere el problema a una cola de alertas.
La decisión debe comparar alternativas técnicas y costo del ciclo de vida.
Cómo contratar un proyecto IIoT
La contratación debe describir caso de uso, activos, variables, integraciones, arquitectura mínima, responsabilidades, ciberseguridad, documentación, pruebas, operación y criterios de éxito.
Cuando el alcance es demasiado abierto, cada proponente puede ofrecer combinaciones diferentes de gateway, plataforma y servicios, dificultando la comparación.
El artículo sobre cómo evaluar empresas de automatización industrial profundiza en calificación de integradores, RFP, TBE, licenciamiento y criterios de aceptación.
Jornada recomendada para implantar IIoT
Un enfoque escalable separa descubrimiento, prueba, piloto e industrialización.
Gate antes de escalar
El proyecto debe verificar si el piloto demostró calidad del dato, seguridad, integración, soporte y valor. Escalar una solución que todavía depende de intervención manual constante solamente amplía el problema.
Operación continua
Después de implantado, IIoT entra en el ciclo de gestión de activos digitales: monitoreo de dispositivos, firmware, certificados, capacidad, logs, costos de nube y evolución de las aplicaciones.
Consideraciones finales
IIoT crea un puente entre activos industriales y aplicaciones de datos, pero su valor depende de una ingeniería disciplinada. El caso de uso debe preceder a la plataforma; las funciones críticas deben permanecer en arquitecturas adecuadas; los datos necesitan contexto y calidad; y la ciberseguridad, la operación y el ciclo de vida deben tratarse desde el diseño.
Cuando está bien estructurado, IIoT puede ampliar la visibilidad del proceso, apoyar mantenimiento basado en condición, conectar activos remotos, mejorar la gestión de energía y alimentar analytics y Digital Twin. Cuando se implanta solamente como una colección de sensores y dashboards, tiende a generar nuevos silos tecnológicos.
La diferencia está en la arquitectura, la gobernanza y la capacidad de transformar datos en decisiones operativas verificables.
Referencias técnicas
[1] 1. INTERNATIONAL ELECTROTECHNICAL COMMISSION. IEC PAS 62443-1-6:2025 — Security for industrial automation and control systems — Part 1-6: Application of the 62443 series to the Industrial Internet of Things (IIoT). Geneva: IEC, 2025. Disponible en: [https://webstore.iec.ch/en/publication/102885](https://webstore.iec.ch/en/publication/102885)
[2] 2. NATIONAL INSTITUTE OF STANDARDS AND TECHNOLOGY. Guide to Operational Technology (OT) Security. NIST SP 800-82 Rev. 3. Gaithersburg: NIST, 2023. Disponible en: [https://csrc.nist.gov/pubs/sp/800/82/r3/final](https://csrc.nist.gov/pubs/sp/800/82/r3/final)
[3] 3. OASIS OPEN. MQTT Version 5.0. OASIS Standard, 7 mar. 2019. Disponible en: [https://docs.oasis-open.org/mqtt/mqtt/v5.0/mqtt-v5.0.html](https://docs.oasis-open.org/mqtt/mqtt/v5.0/mqtt-v5.0.html)
[4] 4. OPC FOUNDATION. OPC Unified Architecture — Part 1: Overview and Concepts. Disponible en: [https://reference.opcfoundation.org/Core/Part1/v105/](https://reference.opcfoundation.org/Core/Part1/v105/)
[5] 5. INTERNATIONAL SOCIETY OF AUTOMATION. ANSI/ISA-95.00.01-2025 (IEC 62264-1 Mod), Enterprise-Control System Integration — Part 1: Models and Terminology. Research Triangle Park: ISA, 2025. Disponible en: [https://www.isa.org/products/ansi-isa-95-00-01-2025-iec-62264-1-mod-enterprise](https://www.isa.org/products/ansi-isa-95-00-01-2025-iec-62264-1-mod-enterprise)
Preguntas frecuentes
IIoT significa Industrial Internet of Things, o Internet Industrial de las Cosas. Es la conexión de activos, sensores y sistemas industriales a una arquitectura de datos para monitoreo, análisis, integración y toma de decisiones.
IIoT opera en entornos industriales, donde las fallas pueden afectar procesos físicos, disponibilidad y seguridad. Por ello, ciclo de vida, interoperabilidad con sistemas legados, ciberseguridad y continuidad operacional tienen mayor peso que en muchas aplicaciones IoT de consumo.
No necesariamente. SCADA está orientado a supervisión y control operacional; IIoT amplía el uso y la integración de los datos. Un SCADA puede ser fuente de datos para una arquitectura IIoT.
Edge computing procesa datos cerca del activo, reduce la dependencia de conectividad externa, disminuye el tráfico y permite decisiones locales cuando la latencia, privacidad o disponibilidad lo exigen.
No. MQTT es un protocolo publish/subscribe muy utilizado, pero la selección debe considerar arquitectura, endpoints, seguridad e integraciones. OPC UA y otros protocolos también pueden formar parte de la solución.
La arquitectura debe tratar zonas, flujos, identidad de dispositivos, autenticación, autorización, firmware, certificados, acceso remoto, inventario y monitoreo. IEC PAS 62443-1-6:2025 orienta la aplicación de la serie IEC 62443 a IIoT.
Defina desde el inicio caso de uso, KPI, requisitos de seguridad y operación, estándares de dispositivos, integración, soporte y criterios para escalar. PoC, piloto y producción deben tratarse como etapas diferentes.
Identificación, escala, unidad, timestamp, comunicación, buffer, autenticación, certificados, comportamiento de gateways, broker, calidad del dato, integración, backup, logs y recuperación ante fallas.
Materiales técnicos complementarios
Soluciones relacionadas
- Sistemas SCADA: supervisión, control, alarmas y datos operativos
- Sistemas Digitales de Supervisión y Control (SDSC): automatización y operación integrada
Servicios relacionados
- Diseño de Automatización Industrial: control, supervisión, redes OT e integración
- Integración de Sistemas: APIs, protocolos, datos e interoperabilidad
Contenidos principales sobre el tema
- Automatización Industrial: qué es, arquitectura, sistemas y aplicaciones en Ingeniería
- Empresa de Automatización Industrial: cómo evaluar, comparar y contratar una integradora
- OPC UA: qué es, cómo funciona, seguridad e integración con SCADA, Modbus y MQTT
Contenidos técnicos relacionados
- Redes industriales: qué son, protocolos, arquitectura, seguridad e integración con SCADA
- Ethernet industrial: qué es, cómo funciona, protocolos, topologías y seguridad
- Digital Twin: qué es, arquitectura, BIM, IoT y gestión de activos
- Commissioning Industrial: precommissioning, start-up, pruebas en frío y en caliente
- Proyectos Brownfield: ingeniería en instalaciones existentes, levantamiento, As-Built y retrofit
