Introducción
Un gran desafío de IoT es la interoperatividad. Conectar dispositivos industriales con tecnologías de información y plataformas IoT es un tema considerable, y es de donde vienen un montón de abreviaturas. Existen varios protocolos para cumplimentar esto: algunos que son privados y otros que son estándares abiertos.
Todos están compitiendo para convertirse en protocolo único de IoT, pero es claro que eso nunca será una realidad. Estos protocolos coexistirán —cada uno con sus propias fortalezas y debilidades— y es nuestro trabajo entender dónde y cuándo usarlos.
Cliente/servidor vs. publicar/subscribir
A fin de hacer un mejor análisis hemos agrupado los protocolos en dos categorías: cliente/servidor (client/server) y publicar/suscribir (publish/subscribe).
Los protocolos cliente/servidor requieren que el cliente se conecte al servidor y realice solicitudes. En este modelo, el servidor tiene los datos y responde a los pedidos del cliente, por ejemplo, el cliente quizá lee una temperatura, esto requiere que sepa acerca del servidor de antemano y sea capaz de conectarse.
Los protocolos publicar/suscribir requieren que los dispositivos se conecten a un "topic" de un "broker" y publiquen la información. Los consumidores se pueden conectar al "broker" y suscribirse a los datos del "topic". Por ejemplo, un dispositivo puede medir la temperatura cada minuto y publicarlo una vez por hora. Una aplicación suscripta a dicha información recibirá una vez por hora un compendio horario de las muestras tomadas cada minuto. Este modelo desacopla al productor de datos del consumidor de datos.
Los protocolos cliente/servidor se utilizan mejor cuando uno conoce su propia infraestructura. Por ejemplo, uno sabe que su servidor tiene una dirección IP fija, en un puerto especifico. El cliente se puede conectar y realizar requerimientos.
Los protocolos publicar/suscribir son mejores cuando la infraestructura propia es desconocida. Por ejemplo, si un dispositivo remoto cambia de redes o tiene una conectividad intermitente, es más fácil para el dispositivo llamar a casa cuando se pone en línea y publicar su información.
En términos de pros y contras, los protocolos cliente/servidor son más compatibles y seguros porque están basados en conexiones punto a punto. Sin embargo, son menos escalables porque las conexiones punto a punto son más difíciles de manejar y mayor demandantes de recursos.
Por el contrario, los protocolos publicar/suscribir son más escalables porque el separar a productores de consumidores permite que cada uno se agregue y se quite de forma independiente. Por consiguiente, asegurar estos protocolos es más complejo porque involucran más piezas. También pueden aparecer cuestiones de compatibilidad dada la separación entre productor y consumidor. Por ejemplo, cambiar el formato del mensaje que envía el productor requiere que todos los consumidores se adapten al nuevo formato.
Ahora que entendemos las categorías básicas, observemos con un poco más de detalle a los protocolos cliente/servidor y publicar/suscribir.
OPC UA
OPC UA (Unified Architecture, "arquitectura unificada") es el estándar de nueva generación que le sigue a OPC Foundation. OPC clásico es bien conocido en la industria y provee una interfaz estándar para comunicarse con los PLC (Programmable Logic Controller, 'controlador lógico programable'). OPC UA pretende expandir la compatibilidad de OPC al nivel de los dispositivos y de las empresas.
OPC UA es un protocolo cliente/servidor. Los clientes se conectan, navegan, leen y escriben al equipamiento industrial. UA define la comunicación desde la aplicación hacia la capa de transporte, lo que lo hace muy compatible entre vendedores. También es muy seguro, y usa mensajes bidireccionales firmados y encriptación de transporte
Use OPC UA cuando necesite información del sensor y de PLC dentro de las soluciones MES y SCADA ya existentes.
HTTP (REST/JSON)
HTTP (Hypertext Transfer Protocol, "protocolo de transferencia de hipertexto") es un protocolo cliente/servidor. Dado que existen incontables herramientas de código abierto que usan HTTP, y que todo lenguaje de codificación tiene bibliotecas HTTP, es muy accesible.
El foco de HTTP en IoT gira en torno a REST (Representational State Transfer, "transferencia de estado representacional"), que es un modelo sin estados previos donde los clientes pueden acceder a recursos en el servidor a través de pedidos. En la mayoría de los casos, un recurso es un dispositivo y la información que tal dispositivo contiene.
HTTP provee transporte, pero no define la presentación de la información. Así, un requerimiento HTTP puede contener HTML, JavaScript, JSON (JavaScript Object Notation, 'notación de objeto JavaScript'), XML, y demás. En la mayoría de los casos, IoT está estandarizando JSON para HTTP. JSON es similar a XML pero sin la sobrecarga ni esquema de validación por lo que es más liviano y flexible. JSON también es soportado por la mayoría de las herramientas y lenguajes de programación.
La industria cuenta con algo de experiencia usando HTTP para la configuración de productos y dispositivos, pero no para el acceso a datos. De este modo, muchas plataformas TIC e IoT aceptan HTTP para proveer y recibir información, pero no así las plataformas industriales. Esto está cambiando a medida que cada vez más puertos y PLC agregan HTTP nativo.
Use HTTP para enviar grandes cantidades de información, como lecturas de temperatura minuto a minuto cada hora.
No use HTTP para información de video de alta velocidad. HTTP puede operar bajo el segundo, pero actualizaciones de cien milisegundos (100 ms) con HTTP son difíciles. Implica bastante sobrecarga por mensaje, así que enviar mensajes pequeños es ineficiente. Y siempre asegure la comunicación con HTTPS. La sobrecarga es mínima.
MQTT
MQTT (Message Queuing Telemetry Transport, 'Cola de mensajes telemetría y transporte') es un protocolo publicar/suscribir diseñado para SCADA y redes remotas. Se centra en un mínimo encabezado (dos bytes de cabeza) y comunicaciones confiables. También es muy simple. Tal como HTTP, la carga MQTT es específica para la aplicación, y la mayoría de las implementaciones usan un formato JSON personalizado o binario.
MQTT no es tan ampliamente utilizado como HTTP, pero aún tiene una gran participación en el mercado de TIC. Existen muchos ejemplos, proyectos, clientes/productores de código abierto en cada lenguaje. Muchas plataformas IoT soportan HTTP y MQTT como los primeros dos protocolos de entrada de información.
¿La aplicación final no soporta MQTT? Si la respuesta es “no”, existen varias herramientas de código abierto para incluir información de MQTT en las bases de datos y otros formatos como HTTP.
Use MQTT cuando el ancho de banda sea premium y no conozca su infraestructura. Asegúrese de que su vendedor tenga un gestor MQTT a quien le pueda publicar información, y siempre asegure la comunicación con TLS (Transport Layer Security, 'seguridad en la capa de transporte').
Esté atento a cuestiones de compatibilidad similares a HTTP. Que dos aplicaciones soporten MQTT no quiere decir que puedan operar entre sí. El tópico y los formatos JSON quizá necesiten ajustarse para que dos productos puedan operar entre sí.
DDS
DDS (Data Distribution Service, ‘servicio de distribución de datos’) es un protocolo publicar/suscribir que se focaliza en el borde de la comunicación en la red. DDS es un estándar abierto operado por OMG (Object Management Group, "Grupo de Gestión de Objetos"). A diferencia de MQTT, que requiere de un agente centralizado, DDS está descentralizado. Los nodos de DDS se comunican directamente punto a punto a través de UDP/multidifusión (multicast). Esto hace que no sea necesaria una gestión centralizada de la red y que DDS sea un protocolo más veloz, con una resolución por debajo del milisegundo.
DDS es una buena solución para la entrega de información de forma confiable y en tiempo real. Úselo para comunicaciones rápidas M2M (machine to machine, "máquina a máquina").
Conclusión
Cuál de estos protocolos tiene la mayor parte del mercado no está claro, pero cada uno tiene sus pros y sus contras. Es importante elegir el protocolo que mejor se adapte a sus necesidades, y seleccionar los socios tecnológicos que se puedan adaptar a tales protocolos. Esto asegurará el éxito para sus aplicaciones IoT y lo protegerá de las guerras de protocolos.
