Los protocolos de comunicación son reglas que definen cómo intercambian datos los equipos de automatización (sensores, actuadores, E/S remotas, PLC, HMI/SCADA). En redes industriales, estos protocolos se eligen por requisitos de tiempo (latencia/jitter), disponibilidad, diagnóstico y ciclo de vida: no solo por “velocidad”. Este artículo resume qué son los protocolos de comunicación industriales, cómo se clasifican (fieldbus, Ethernet industrial y protocolos IIoT), y cómo seleccionar y asegurar un protocolo sin comprometer la operación.
¿Qué son los protocolos de comunicación en automatización industrial?
En automatización, los protocolos de comunicación son especificaciones que definen formato de mensajes, sincronización, confirmaciones, direccionamiento y manejo de errores para que dos o más dispositivos intercambien información de forma interoperable. En redes industriales, el protocolo también suele incorporar diagnóstico y comportamiento temporal (por ejemplo, ciclos de actualización) para sostener control y operación.
En la práctica, cuando se habla de “protocolo” se mezclan tres cosas que conviene separar:
- Medio físico: cobre, fibra, radio; conectores y cableado.
- Capas de red: enlace y transporte (por ejemplo, Ethernet y TCP/IP en ciertos casos).
- Aplicación industrial: el lenguaje de datos del mundo OT: variables, estados, alarmas, servicios y perfiles.
Por eso, el mismo entorno puede usar varios protocolos de comunicación a la vez: uno para E/S de tiempo real, otro para supervisión y otro para integración con capas superiores.
Por qué los protocolos industriales se eligen distinto que en IT
Respuesta directa: En OT, los protocolos de comunicación se seleccionan por continuidad del proceso y previsibilidad temporal: qué pasa cuando hay fallos de red, cuánto tarda en recuperarse, cómo se diagnostica, y si el comportamiento es estable bajo carga. Un enfoque OT debe considerar requisitos de rendimiento, fiabilidad y seguridad específicos del entorno industrial.
Ejemplos de requisitos típicos en planta:
- Determinismo o comportamiento temporal acotado: variación de retardo (jitter) controlada para control/motion.
- Recuperación ante fallos: que la red y el protocolo vuelvan a operar en un tiempo conocido.
- Diagnóstico accionable: identificar qué enlace/nodo degradó la comunicación sin “adivinar”.
- Mantenibilidad: cambios y ampliaciones sin romper el sistema (ciclo de vida).
Cómo se clasifican los protocolos de comunicación industrial
Los protocolos de comunicación en redes industriales suelen agruparse en: (1) protocolos de bus de campo (fieldbus), (2) protocolos sobre Ethernet industrial, y (3) protocolos de mensajería/IIoT (pub/sub) para integración y telemetría. Las series IEC de comunicación industrial (como IEC 61158 e IEC 61784) se usan como marco para familias y perfiles de comunicación en buses de campo y entornos relacionados.
| Familia | Qué prioriza | Ejemplos típicos | Uso habitual |
|---|---|---|---|
| Fieldbus (bus de campo) | Integración de dispositivos de campo, ciclos definidos, ecosistemas maduros | CANopen, PROFIBUS (según entorno), redes incluidas en familias/perfiles | Instrumentación, campo, máquinas con legado o requisitos específicos |
| Ethernet industrial | Escalabilidad, convergencia, ancho de banda y perfiles de tiempo | PROFINET, EtherNet/IP, EtherCAT (Industrial Ethernet) | Fábrica, líneas, motion, integración de celdas/áreas |
| IIoT / Mensajería | Interoperabilidad a nivel de datos, integración y telemetría | OPC UA (incl. PubSub), MQTT, DDS | Integración OT/IT, recopilación contextual, edge–cloud |
Capas (OSI) aplicadas a protocolos de comunicación industrial
Entender en qué “capa” actúa un protocolo evita errores de diseño. En protocolos de comunicación industriales es común combinar: una capa física (cable/radio), una capa de enlace (por ejemplo Ethernet), y una capa de aplicación industrial (servicios y datos). En algunos casos, el protocolo industrial define perfiles estrictos sobre capas inferiores para controlar tiempos, diagnóstico y comportamiento bajo carga.
- Físico/enlace: define cómo circulan tramas y cómo se detectan errores básicos.
- Transporte/red: define encaminamiento y sesiones (cuando aplica).
- Aplicación industrial: define “qué significa” el dato: variable, servicio, estado, alarma.
Protocolos “clásicos” de automatización: Modbus como ejemplo de simplicidad
Algunos protocolos de comunicación se consolidaron por su sencillez de integración y amplia adopción. Modbus, por ejemplo, se describe como un protocolo de aplicación basado en transacciones request/response con códigos de función definidos por su especificación. Este tipo de protocolo puede ser útil para telemetría, integración básica o compatibilidad, siempre que el diseño considere sus límites (diagnóstico, seguridad, tiempos y escalabilidad).
En ingeniería, la pregunta no es “¿se puede leer/escribir?” sino:
- ¿Qué pasa si se pierde un mensaje o se degrada la red?
- ¿Cómo se detecta y registra el fallo?
- ¿Es apropiado para el caso de uso (control vs supervisión vs integración)?
Ethernet industrial: por qué domina y qué exige
Ethernet industrial domina porque permite escalar, segmentar y converger tráfico (control, supervisión e integración) usando infraestructura común. Sin embargo, en protocolos de comunicación sobre Ethernet el éxito depende del diseño: segmentación por celdas/zonas, control de broadcast, priorización (QoS), sincronización temporal cuando aplica y pruebas bajo carga.
Ejemplo: EtherNet/IP y el enfoque CIP
En EtherNet/IP, el modelo se apoya en CIP (Common Industrial Protocol) en capas superiores; CIP se describe como “media independent”, orientado a objetos y con modelo producer–consumer. Esto suele facilitar consistencia de servicios, aunque no elimina la necesidad de dimensionar y validar el comportamiento temporal del sistema.
Ejemplo: PROFINET como protocolo de intercambio controlador–dispositivo
En PROFINET, el foco típico es el intercambio de datos entre controladores (por ejemplo PLC) y dispositivos (E/S, drives, instrumentación). En la práctica, el diseño de topología y diagnóstico es tan relevante como el “protocolo” en sí para mantener disponibilidad.
Ejemplo: EtherCAT para requisitos de tiempo real
EtherCAT se presenta como “Ethernet fieldbus” y se declara estandarizado en IEC 61158. En entornos con requisitos de tiempo real (hard/soft), suele evaluarse por rendimiento cíclico, diagnóstico y comportamiento bajo carga.
Protocolos de sensores inteligentes: IO-Link como punto a punto
Respuesta directa: En el extremo de campo, existen protocolos de comunicación orientados a sensores/actuadores inteligentes con diagnóstico y parametrización. IO-Link se presenta como una tecnología I/O estandarizada (IEC 61131-9) para comunicación punto a punto con intercambio bidireccional de datos, diagnóstico y configuración remota. Esto es especialmente útil cuando se quiere transparencia y mantenimiento más rápido sin “subir” todo a un bus complejo.
Protocolos en máquinas y movilidad: CANopen
En maquinaria, vehículos industriales y sistemas embebidos, CANopen es un ejemplo de protocolos de comunicación ampliamente usados. CANopen CC se describe como basado en una capa de enlace de datos según ISO 11898-1 y contempla parámetros y perfiles (por ejemplo CiA 301). En la práctica se usa cuando el ecosistema, el coste y la integración embebida pesan mucho.
Mensajería y pub/sub: cuando el problema es “integrar datos”
Respuesta directa: En integración OT/IT y IIoT, los protocolos de comunicación pub/sub se eligen por desacoplar productores y consumidores de datos, facilitar escalabilidad y mejorar eficiencia de distribución. MQTT se define como un protocolo de transporte de mensajería publish/subscribe, ligero y simple para M2M/IoT. DDS se describe como un estándar abierto de middleware pub/sub orientado a sistemas en tiempo real y embebidos.
| Protocolo | Patrón | Fortaleza típica | Uso industrial típico |
|---|---|---|---|
| MQTT | Pub/Sub (cliente–servidor con broker) | Ligero, fácil de implementar, ideal para telemetría | Edge–cloud, monitorización, integración de datos no críticos |
| DDS | Pub/Sub (middleware de datos) | Enfoque a tiempo real y sistemas distribuidos | Robótica, sistemas embebidos, distribución de datos en tiempo real |
| OPC UA (incl. PubSub) | Servicios + modelo de información | Interoperabilidad semántica y opciones de seguridad | Integración OT/IT, estandarización de datos y servicios |
OPC UA: un protocolo que aporta modelo de información (no solo “tramas”)
OPC UA suele elegirse cuando se necesita interoperabilidad a nivel de datos y servicios: no solo “leer una variable”, sino exponer un modelo con estructura, tipos y servicios. A nivel de seguridad, la especificación de OPC UA (Parte 2) define objetivos como autenticación, autorización, confidencialidad, integridad y auditabilidad dentro de su arquitectura de seguridad.
En proyectos reales, OPC UA funciona mejor cuando se define claramente:
- Qué datos se exponen y con qué semántica (nombres, unidades, estados y calidad).
- Qué políticas de seguridad aplican (certificados, canales seguros, roles).
- Dónde se sitúan las pasarelas/zonas para no romper la segmentación OT.
Sincronización temporal y determinismo: IEEE 1588 (PTP) y TSN
Respuesta directa: En redes industriales, algunos casos de uso requieren sincronización de tiempo precisa y latencia acotada. IEEE 1588-2019 define PTP para sincronizar relojes de dispositivos en sistemas distribuidos. Por su parte, el grupo IEEE 802.1 TSN define el objetivo de proporcionar conectividad determinista sobre redes IEEE 802, con transporte garantizado y latencia acotada, baja variación de retardo y bajas pérdidas. En combinación, estas tecnologías ayudan a que ciertos protocolos de comunicación puedan cumplir requisitos temporales exigentes (si el diseño completo lo soporta).
Cómo elegir protocolos de comunicación: checklist de ingeniería
Seleccionar protocolos de comunicación industriales no es un ejercicio de “preferencias”: se decide por requisitos medibles y por ciclo de vida. Este checklist resume lo mínimo a cerrar antes de fijar una arquitectura.
- Caso de uso: control cíclico, motion, supervisión, integración, mantenimiento.
- Requisitos temporales: latencia y jitter tolerables; tiempos de recuperación.
- Diagnóstico: qué eventos y métricas se necesitan para operar y mantener.
- Escalabilidad: número de nodos, crecimiento, segmentación por celdas/áreas.
- Entorno físico: distancias, ruido, temperatura, vibración, EMC.
- Interoperabilidad: perfiles, compatibilidad y gobernanza de tags/datos.
- Seguridad OT: zonas y conductos, control de accesos, hardening, cambios.
Seguridad en protocolos de comunicación: lo mínimo para no degradar OT
La seguridad en protocolos de comunicación industriales se aplica con enfoque OT: priorizando disponibilidad y seguridad operacional. Guías OT como NIST SP 800-82 y marcos como ISA/IEC 62443 definen procesos y requisitos para implementar y mantener sistemas de automatización seguros, incluyendo segmentación (zonas y conductos) y gobernanza del ciclo de vida.
- Segmentación: separar control, supervisión, administración y acceso remoto.
- Accesos por rol: mínimos privilegios y trazabilidad cuando aplique.
- Hardening: servicios mínimos en switches/servidores OT y control de configuración.
- Gestión de cambios: versiones, backups verificados, pruebas y plan de rollback.
- Visibilidad: registros y alarmas de eventos relevantes (operables).
Errores comunes al usar protocolos de comunicación en redes industriales
Respuesta directa: En planta, los fallos asociados a protocolos de comunicación suelen venir de diseño y operación: mezclar tráfico sin segmentar, no probar fallos, ignorar la sincronización horaria y no tener estándares de tags/datos. Evitarlos suele costar menos que diagnosticarlos en producción.
- Elegir por “popularidad”: sin requisitos de tiempo ni pruebas bajo carga.
- Red plana: sin zonas → impacto masivo ante incidencias o ataques.
- Sin pruebas de borde: reinicios, caídas y conmutación no ensayadas.
- Diagnóstico pobre: sin KPIs de comunicación (pérdidas, jitter, eventos).
- Tags inconsistentes: rompe HMI/SCADA e integración; falta gobernanza.
Protocolos de comunicación dentro de la programación industrial
En “programación industrial”, los protocolos de comunicación son el puente entre lógica de control y el mundo físico y operativo: determinan cómo llegan las señales al PLC, cómo se publican datos al SCADA y cómo se integran sistemas. Un buen programa PLC no compensa un protocolo mal seleccionado o una arquitectura de red sin pruebas.
Preguntas frecuentes sobre protocolos de comunicación
Esta FAQ resume dudas habituales sobre protocolos de comunicación en redes industriales: clasificación, elección por tiempos, OPC UA, MQTT/DDS, PTP/TSN y seguridad OT.
¿Qué diferencia hay entre “protocolo” y “red”?
La red es el medio y la infraestructura (cableado, switches, topología). El protocolo define las reglas de intercambio de datos (mensajes, servicios, errores). En industria suelen coexistir varios protocolos sobre la misma infraestructura.
¿Modbus sirve para control en tiempo real?
Depende del caso. Modbus es simple e interoperable, pero para control exigente suele ser necesario validar latencia/jitter y comportamiento ante fallos; a menudo se reserva para supervisión o integración básica.
¿Por qué Ethernet industrial requiere más diseño que “poner switches”?
Porque en OT se necesita comportamiento temporal predecible, diagnóstico y disponibilidad: segmentación, control de broadcast, priorización y pruebas bajo carga.
¿Qué aporta OPC UA frente a protocolos “de registro”?
Además de acceso a datos, aporta un modelo de información y servicios. También define objetivos de seguridad (autenticación, autorización, integridad, confidencialidad, auditabilidad) en su arquitectura.
¿Cuándo tiene sentido MQTT en industria?
Cuando el objetivo es telemetría e integración de datos (edge–cloud) con un patrón pub/sub ligero, especialmente en escenarios M2M/IoT.
¿Qué es DDS y en qué se diferencia de MQTT?
DDS se describe como un estándar abierto de middleware pub/sub orientado a tiempo real y sistemas embebidos. Suele evaluarse cuando hay distribución de datos en tiempo real en sistemas distribuidos.
¿Qué es PTP (IEEE 1588) y por qué importa?
PTP define un protocolo para sincronizar relojes en sistemas distribuidos; es útil para correlacionar eventos, historización coherente y ciertos casos de control distribuido.
¿Qué es TSN y qué promete?
TSN es el trabajo de IEEE 802.1 para proporcionar conectividad determinista en redes IEEE 802: transporte garantizado con latencia acotada, baja variación de retardo y bajas pérdidas.
¿Qué significa segmentar por “zonas y conductos”?
Es un enfoque de arquitectura de seguridad OT promovido en la serie ISA/IEC 62443: agrupar activos en zonas y controlar comunicaciones entre zonas mediante conductos, reduciendo impacto y superficie de ataque.
¿Cuál es el error más frecuente al seleccionar un protocolo?
Elegirlo por costumbre sin definir requisitos temporales, diagnóstico y recuperación ante fallos; después aparecen paradas intermitentes difíciles de reproducir.
¿Qué debería documentarse siempre en un proyecto de comunicaciones OT?
Topología, direccionamiento, perfiles/ajustes relevantes, lista de nodos, criterios de diagnóstico, backups de configuración y procedimiento de pruebas y rollback.
Dudas o proyecto de protocolos de comunicación
Si necesitas definir o auditar protocolos de comunicación en redes industriales (selección por requisitos, segmentación OT, integración PLC/SCADA, sincronización, pruebas de borde o mejora de disponibilidad), el canal oficial para plantearlo es el formulario de contacto. Incluye el tipo de proceso, criticidad, número de nodos y ventana de parada para orientar el enfoque técnico. Contacta con Electrohine aquí.
Fuentes consultadas
- NIST — SP 800-82 Rev. 3 (OT Security): https://csrc.nist.gov/pubs/sp/800/82/r3/final
- ISA — ISA/IEC 62443 series: https://www.isa.org/standards-and-publications/isa-standards/isa-iec-62443-series-of-standards
- IEEE 802.1 — TSN Task Group: https://1.ieee802.org/tsn/
- IEEE-SA — IEEE 1588-2019 (PTP): https://standards.ieee.org/standard/1588-2019.html
- OPC Foundation — OPC UA Part 2 Security: https://reference.opcfoundation.org/Core/Part2/v105/docs/
- OASIS — MQTT Version 5.0: https://www.oasis-open.org/standard/mqtt-v5-0-os/
- Modbus — Modbus Application Protocol Specification V1.1b3: https://www.modbus.org/file/secure/modbusprotocolspecification.pdf
- ODVA — CIP on Ethernet / EtherNet/IP overview: https://www.odva.org/wp-content/uploads/2024/04/PUB00138R8_Ethernet.pdf
- PROFIBUS & PROFINET International — PROFINET technology: https://www.profibus.com/profinet-technology
- EtherCAT Technology Group — Technology overview: https://www.ethercat.org/en/technology.html
- CAN in Automation — CANopen CC overview: https://www.can-cia.org/can-knowledge/canopen
- IO-Link — Downloads / overview (IEC 61131-9): https://io-link.com/downloads
- OMG — DDS portal: https://www.omg.org/omg-dds-portal/
Revisión: enero de 2026. Estilo enciclopédico, orientado a perfiles de planta/ingeniería. Sin menciones a competidores ni comparativas comerciales.