Es importante agrupar los protocolos IoT en dos categorías: cliente/servidor y publicación/ suscripción. Los primeros requieren que el cliente se conecte y realice solicitudes al servidor (que contiene los datos). Por ejemplo, la lectura de una temperatura requiere que el cliente conozca de antemano el servidor (y sus datos de acceso, como dirección IP o puerto de escucha) y se pueda conectar a él.

En tanto, los protocolos de publicación/ suscripción requieren que los dispositivos publiquen datos en un intermediario, al que se suscriben los consumidores. Por ejemplo, un dispositivo puede registrar la temperatura cada minuto y publicarla una vez cada hora. Una aplicación suscrita al flujo de datos recibe cada hora sesenta registros de un minuto. Este modelo desacopla el productor de los datos del consumidor de los datos, y es la mejor opción cuando se desconoce la infraestructura.

Ahora que comprendemos las categorías básicas, veamos los protocolos de cliente/ servidor y de publicación/suscripción.

Los protocolos de los que hablaremos tienen el potencial de conectar dispositivos industriales con plataformas de IoT.

• OPC UA (OPC Unified Architecture) es el estándar de próxima generación de OPC Foundation, y tiene como objetivo ampliar la interoperabilidad de OPC a los niveles de dispositivo y empresa. Es un protocolo de cliente/servidor, muy seguro y usa firma bidireccional de mensajes y encriptación de transmisión. OPC UA tiene una amplia base de instalación en el ámbito industrial. Es una buena solución para vincular PLC y los datos del sensor en aplicaciones industriales existentes como sistemas SCADA y MES, donde OPC y la conectividad OPC UA ya están disponibles. Sin embargo, OPC UA es nuevo en el ámbito de TI, donde algunos usuarios pueden sentirse intimidados por su complejidad.

Por ahora, use este protocolo cuando tenga que introducir PLCs y datos del sensor en las soluciones SCADA y MES existentes, y no pierda de vista la adopción de OPC UA por los proveedores de plataformas de IoT y la comunidad de código abierto.

• HTTP (REST/JSON) es un protocolo de cliente/servidor sin conexión, omnipresente en TI y la Web. En IoT, el enfoque en HTTP se realiza en torno a REST (transferencia de estado representacional), que es un modelo sin estado en el que los clientes pueden acceder a recursos en el servidor mediante solicitudes. En la mayoría de los casos, un recurso es un dispositivo y los datos que contiene.

HTTP proporciona un transporte, pero no define la presentación de los datos. En la mayoría de los casos, IoT se estandariza en torno a JSON (JavaScript Object Notation) sobre HTTP. JSON es similar a XML, sin toda la sobrecarga y validación de esquemas, lo que lo hace más ligero y flexible.

Muchas plataformas de IoT y TI admiten el consumo y el suministro de datos en formato HTTP, pero pocas plataformas industriales lo hacen. Esto está cambiando, ya que más pasarelas y PLC comienzan a añadir soporte HTTP nativo.

Utilice HTTP para enviar segmentos de datos, como lecturas de temperatura de un minuto cada hora. No lo utilice para la transmisión de datos de alta velocidad. Además, proteja siempre las comunicaciones con HTTPS (la sobrecarga es mínima).

Cuidado: Solo porque dos productos admitan HTTP/REST/JSON no significa que funcionarán sin necesidad de configuración. A menudo, los formatos JSON son diferentes y requieren integración mínima para que las cosas funcionen.

• MQTT (Message Queuing Telemetry Transport, transporte de telemetría de colas de mensajes) es un protocolo de publicación/suscripción diseñado para SCADA y redes remotas. Se centra en la sobrecarga mínima (encabezado de 2 bytes) y en comunicaciones confiables. Además, es muy sencillo. Como HTTP, la carga útil de MQTT es específica de la aplicación y la mayoría de las implementaciones utiliza un formato JSON o binario personalizado. Si bien no se utiliza tan ampliamente como HTTP, MQTT sigue teniendo una gran cuota de mercado en TI. Utilice MQTT cuando el ancho de banda sea limitado y cuando no conoce la infraestructura. Asegúrese de que el distribuidor tiene un intermediario MQTT en el que puede publicar datos y proteja siempre la comunicación mediante la Seguridad de la Capa de Transporte (TLS). Además, el solo hecho de que dos aplicaciones admitan MQTT no significa que sean interoperables, y es posible que se tengan que ajustar el tema y los formatos JSON.

• CoAP (Constrained Application Protocol, protocolo de aplicación restringida) se creó para proporcionar la interoperabilidad de HTTP con una sobrecarga mínima. CoAP es similar a HTTP, pero utiliza UDP/multidifusión en lugar de TCP. También simplifica la cabecera HTTP y reduce el tamaño de cada solicitud. CoAP se emplea en dispositivos perimetrales donde HTTP consumiría demasiados recursos y a menudo es el tercer protocolo admitido por plataformas de IoT después de HTTP y MQTT.

Utilice CoAP cuando HTTP consuma demasiado ancho de banda. Tenga en cuenta que la adopción del mercado de CoAP no es tan amplia como HTTP, por lo que puede limitar las opciones de software y hardware.

• DDS (Data Distribution Service, servicio de distribución de datos) es un protocolo de publicación/suscripción que se centra en la comunicación en el perímetro de la red. A diferencia de MQTT que requiere un intermediario centralizado, DDS es descentralizado: los nodos DDS se comunican directamente entre pares con multidifusión UDP, eliminando la necesidad de una gestión de red centralizada y haciendo de DDS un protocolo más rápido, alcanzando una resolución de milisegundos.

DDS es una buena solución para la entrega de datos confiable en tiempo real en el perímetro. Úselo para comunicaciones M2M rápidas.

• AMQP (Advanced Message Queuing Protocol, protocolo avanzando de colas de mensajes) es otro protocolo de publicación/ suscripción que procede del sector de los servicios financieros. Tiene una presencia en TI, pero una presencia limitada en la industria. El mayor beneficio de AMQP es su sólido modelo de comunicaciones que admite transacciones. A diferencia de MQTT, AMQP puede garantizar transacciones completas que, aunque resultan útiles, no siempre se requieren por las aplicaciones de IoT. Su principal inconveniente es que es un protocolo pesado, pensado principalmente para sistemas de TI de back-end y no para el perímetro de la red.

No está claro qué protocolos tienen la mayor cuota del mercado, pero cada uno de ellos tiene sus pro y sus contra. Es importante elegir el protocolo que mejor se adapte a sus necesidades y seleccionar los socios de tecnología que puedan adaptarse a estos protocolos. De esta manera se garantizará el éxito de las aplicaciones de IoT y se protegerá de las guerras de protocolos.