Protocolos de comunicación compatibles

Modbus (RTU / TCP)

Propósito y descripción

Un protocolo industrial sencillo y ampliamente utilizado para el intercambio de datos de proceso entre controladores, sensores y actuadores. Desarrollado en 1979 por Modicon (hoy Schneider Electric), se ha convertido en el estándar de facto de la automatización industrial. Se emplea en sistemas SCADA, PLC, variadores de frecuencia, instrumentos de medición y sensores. Gracias a la sencillez de su implementación y a sus mínimos requisitos de recursos de cómputo, el protocolo resulta idóneo para sistemas embebidos y dispositivos con memoria limitada.

Arquitectura y modelo de datos

El modelo de datos basado en registros se construye sobre cuatro tipos de espacio de direcciones:

• Coils (0x) — salidas discretas (valores de bit de lectura/escritura)
• Discrete Inputs (1x) — entradas discretas (solo lectura)
• Input Registers (3x) — registros de entrada de 16 bits (solo lectura)
• Holding Registers (4x) — registros de retención de 16 bits (lectura/escritura)

Arquitectura cliente-servidor (maestro-esclavo): el dispositivo maestro inicia las solicitudes y los esclavos responden. Cada dispositivo esclavo tiene una dirección única (1–247). El protocolo no incorpora semántica de datos integrada: la interpretación de los valores de los registros se define en el nivel de aplicación y en la documentación del dispositivo. Admite operaciones de lectura y escritura para registros individuales y múltiples.

Transporte

Modbus RTU:

• Líneas serie RS-485 (hasta 32 dispositivos por bus, distancia de hasta 1200 m) o RS-232 (punto a punto)
• Representación binaria de los datos
• Verificación de integridad mediante CRC-16
• Velocidad de transmisión: de 1200 a 115200 baudios
• Transmisión semidúplex

Modbus TCP:

• Encapsulación de tramas Modbus en TCP/IP (puerto 502)
• Cabecera MBAP (Modbus Application Protocol) para la identificación de transacciones
• Transmisión dúplex completa
• Capacidad de trabajar simultáneamente con varios dispositivos
• No requiere suma de comprobación (la fiabilidad la proporciona TCP)

Funciones principales

• Lectura y escritura de señales discretas (Coils) y registros
• Compatibilidad con los códigos de función estándar (FC 01–06, 15–16, 23)
• Funciones de diagnóstico (FC 08)
• Lectura de los datos de identificación del dispositivo (FC 17, 43)
• Mínimos requisitos de recursos de cómputo para los dispositivos
• Implementación y depuración sencillas
• Bajo coste de implementación
• Gestión de excepciones y códigos de error
• Compatibilidad con mensajes de difusión (dirección 0) en RTU
• Escalabilidad de hasta 247 dispositivos por línea (RTU) o ilimitada mediante TCP

OPC UA

Propósito y descripción

Un estándar universal y multiplataforma (OPC Unified Architecture, IEC 62541) para el intercambio seguro y estructurado de datos industriales, metadatos e información semántica. Desarrollado por la OPC Foundation como sucesor de las especificaciones clásicas OPC DA/AE/HDA, elimina la dependencia de las tecnologías DCOM de Microsoft. Permite la integración vertical y horizontal en sistemas industriales, desde el nivel de campo hasta los sistemas de información corporativos (ERP, MES). Es compatible con los conceptos de Industrie 4.0 y de gemelo digital gracias a sus completas capacidades de modelado de información.

Arquitectura y modelo de datos

Modelo de datos orientado a objetos que representa la información como un espacio de nodos direccionable (Address Space):

• Nodos de diversos tipos: Variable, Object, Method, View, DataType, ReferenceType
• Atributos de los nodos: Value, DataType, AccessLevel, Timestamp, Quality, DisplayName, etc.
• Referencias entre nodos: jerárquicas, asociativas, basadas en componentes
• Tipos de datos: primitivos, estructuras, matrices, enumeraciones

Servicios compatibles:

• Subscription — supervisión de cambios de datos con intervalos de muestreo y filtros configurables
• Events & Alarms — notificaciones asíncronas de eventos, alarmas y estados
• Historical Access — acceso a datos y eventos archivados
• Methods — invocación remota de procedimientos en los dispositivos

Modelos de información específicos de cada sector (Companion Specifications): ingeniería mecánica, energía, petróleo y gas, productos farmacéuticos.

Transporte

Protocolo UA Binary sobre TCP/IP:

• Protocolo binario con serialización optimizada (puerto 4840)
• Alto rendimiento y mínima sobrecarga

HTTPS / SOAP:

• Perfil de servicios web para la integración con sistemas empresariales
• Codificación JSON para aplicaciones en la nube

OPC UA PubSub:

• Modelo editor-suscriptor para sistemas distribuidos
• Transporte: UDP Multicast, MQTT, AMQP, Ethernet TSN
• Transmisión determinista para aplicaciones de tiempo crítico

Seguridad:

• Modos de seguridad multinivel (None, Sign, SignAndEncrypt)
• Certificados X.509 para la autenticación
• Cifrado AES, RSA

Funciones principales

• Modelado de información: transmisión no solo de valores «en bruto», sino de datos complejos y estructurados con semántica, tipado y metadatos
• Suscripciones con intervalos de sondeo configurables, filtros de banda muerta y almacenamiento en búfer
• Eventos y sistema de alarmas con filtrado condicional
• Invocación de métodos para el control de dispositivos y la ejecución de operaciones
• Acceso a datos históricos con agregación
• Descubrimiento de servicios en redes locales
• Seguridad integrada: cifrado del canal, autenticación basada en certificados o en nombre de usuario/contraseña, control de acceso a nivel de nodo
• Redundancia y tolerancia a fallos del servidor
• Multiplataforma: Windows, Linux, VxWorks, QNX y otros sistemas operativos
• Escalabilidad: desde microcontroladores hasta sistemas distribuidos

MQTT

Propósito y descripción

Un protocolo de mensajería ligero (Message Queuing Telemetry Transport) para telemetría, supervisión remota y gestión de dispositivos IoT, optimizado para redes poco fiables, ancho de banda limitado y latencia elevada. Desarrollado en 1999 por IBM para la supervisión de oleoductos, fue estandarizado por OASIS e ISO/IEC (20922:2016). Se utiliza ampliamente en el IoT industrial, los hogares inteligentes, la telemática de vehículos y las aplicaciones móviles. El protocolo se centra en minimizar el tráfico de red y el consumo de energía de los dispositivos.

Arquitectura y modelo de datos

Modelo Publish/Subscribe asíncrono con un broker centralizado:

• Publisher — dispositivo o aplicación que publica mensajes en los temas
• Subscriber — dispositivo o aplicación suscrito para recibir mensajes de los temas
• Broker — servidor central de enrutamiento de mensajes (Mosquitto, HiveMQ, EMQ X, etc.)

Temas (Topics) — estructura jerárquica de rutas para la categorización de los mensajes:

• Separadores de nivel: / (p. ej., factory/building1/temperature)
• Comodines: + (un solo nivel), # (varios niveles)
• Ejemplo de suscripción: sensors/+/temperature o factory/#

Formato de datos definido por la aplicación: JSON, Protocol Buffers, XML, datos binarios, texto.
Mensajes retenidos: el broker almacena el último mensaje de un tema y lo entrega a los nuevos suscriptores.
Sesiones persistentes: el broker conserva las suscripciones del cliente tras la desconexión.

Transporte

• Capa de transporte: TCP/IP (puerto 1883 para conexiones no protegidas)
• TLS/SSL (puerto 8883) para el cifrado y la autenticación
• WebSockets para la integración con navegadores y aplicaciones web
• Versiones del protocolo: MQTT 3.1.1 (la más extendida), MQTT 5.0 (funciones ampliadas)
• Tamaño de la cabecera: mínimo 2 bytes (cabecera fija)
• Mecanismo keep-alive: PINGREQ/PINGRESP periódicos para la supervisión de la conexión
• El funcionamiento basado en broker garantiza el desacoplamiento entre editor y suscriptor, el escalado horizontal y la gestión centralizada

Funciones principales

• QoS (Quality of Service), tres niveles de garantía de entrega:
  • QoS 0: como máximo una vez (sin confirmación)
  • QoS 1: al menos una vez (con confirmación)
  • QoS 2: exactamente una vez (negociación de cuatro pasos)
• Sobrecarga de red mínima: cabecera fija de 2 bytes, codificación binaria eficiente
• LWT (Last Will and Testament): mecanismo de notificación automática ante la desconexión inesperada de un dispositivo — el broker publica un mensaje predefinido si el cliente finaliza la sesión de forma anómala
• Clean Session / Persistent Session: capacidad de restaurar las suscripciones y los mensajes tras la reconexión
• Mensajes retenidos (Retained Messages): disponibilidad del último valor para los nuevos suscriptores
• Bajo consumo de energía: ideal para dispositivos alimentados por batería
• Escalabilidad: compatibilidad con millones de conexiones simultáneas en clústeres de brokers
• Suscripciones con comodines para un filtrado flexible de los temas

DLMS / COSEM (IEC 62056)

Propósito y descripción

Un estándar internacional para el intercambio de datos con contadores de servicios públicos: electricidad, gas, agua y calor (Device Language Message Specification / Companion Specification for Energy Metering). Desarrollado por la DLMS User Association junto con la IEC para garantizar la interoperabilidad de los contadores inteligentes en los sistemas automatizados de medición y facturación (AMBS). Permite la lectura remota de contadores, la supervisión de la calidad del suministro, la gestión de tarifas y la detección de accesos no autorizados. Lo utilizan ampliamente los operadores de redes eléctricas, los proveedores de servicios públicos y los integradores de sistemas Smart Grid.

Arquitectura y modelo de datos

Modelo de objetos COSEM (Companion Specification for Energy Metering):

• Los datos del contador se representan como objetos lógicos (objetos COSEM) con clases de interfaz
• Códigos OBIS (Object Identification System) — identificador de seis bytes para el direccionamiento universal de parámetros: A-B:C.D.E*F
  • A — tipo de energía (1=electricidad, 6=calor, 7=gas, 8=agua)
  • B — canal de medición
  • C — magnitud física (p. ej., 1=energía activa)
  • D — tipo de medición (8=tiempo de integración)
  • E — zona tarifaria
  • F — profundidad histórica

Protocolo DLMS:

• Capa de aplicación según el modelo OSI
• Asociaciones con distintos derechos de acceso: Public, Reader, Manager
• Autenticación: Low Level Security (LLS), High Level Security (HLS) con desafío-respuesta
• Cifrado: compatibilidad con DLMS Security Suite y algoritmos AES-GCM-128
• Load Profiles: objetos de búfer para el almacenamiento de datos de series temporales
• Sistema de scripting: ejecución de secuencias de acciones en el contador

Transporte

Capa física y de enlace de datos:

• Puerto óptico (IEC 62056-21, flag) — conexión directa mediante cabezal infrarrojo para la lectura local
• RS-485 / RS-232 con protocolo HDLC (High-Level Data Link Control) para redes multipunto
• TCP/IP (puerto 4059) — DLMS sobre TCP o encapsulación IP para el acceso remoto
• GSM/GPRS/LTE — transmisión de datos a través de redes móviles (protocolos wrapper)
• PLC (Power Line Communication) — transmisión a través de las líneas eléctricas (PRIME, G3-PLC)
• M-Bus — para la integración con sistemas de medición de agua y calor

Perfiles de transmisión según la implementación del contador:

• IEC 62056-46: COSEM sobre HDLC
• IEC 62056-47: transporte de COSEM sobre TCP-UDP/IP

Funciones principales

• Lectura del contador — valores actuales de consumo de energía, potencia, tensión, corriente y factor de potencia
• Load Profiles — datos detallados con marca de tiempo (intervalos de 15 min, horarios y diarios)
• Registros de eventos — registro de manipulaciones de la tapa, cortes de suministro, sobretensiones y cambios de parámetros
• Autenticación y autorización multinivel: control de acceso basado en roles (acceso público, lectura, configuración)
• Gestión de tarifas — modificación remota de los calendarios y las tarifas
• Sincronización horaria para la precisión de las marcas de tiempo
• Control de relés (conexión/desconexión de carga)
• Supervisión de la calidad del suministro (caídas de tensión, sobretensiones, armónicos)
• Compatibilidad con operaciones de grupo en varios contadores
• Protección criptográfica de los datos e integridad de los mensajes