Opciones de protocolo de la capa de aplicación para la funcionalidad M2M e IoT

Con la adopción del Internet de las Cosas (IoT) y las funciones de la Industria 4.0, los dispositivos están cada vez más conectados a través de protocolos industriales. Además, las comunicaciones actuales entre máquinas (M2M) se están estandarizando rápidamente con estos protocolos. Lo que complica las cosas es que los protocolos del IoT no describen un único protocolo de capa de aplicación, ya que hay varios estándares en funcionamiento. Así, mientras que las primeras implementaciones de la IoT utilizaban protocolos estándar de Internet, ahora también hay protocolos específicos de la IoT.

Modelar las estructuras de comunicación e identificar el protocolo adecuado para una aplicación concreta puede resultar desalentador. En este artículo se describen las funciones de los distintos protocolos, así como las opciones disponibles para ellos, de modo que los ingenieros de diseño puedan seleccionar más fácilmente el más adecuado para su integración.

Figura 1: Las funciones de la IIoT en la automatización industrial se basan en dispositivos cada vez más conectados que emplean protocolos industriales para conectarse en red. Las capas abstraídas de estas redes no requieren ningún conocimiento de las funciones de las capas subyacentes... por lo que gran parte de la ingeniería de diseño se centra en la capa superior (de aplicación) de las redes de máquinas. (Fuente de la imagen: Getty Images)

Definición del protocolo de la capa de aplicación para redes industriales

Las estructuras de los protocolos de comunicación para los sistemas digitales M2M e IoT se dividen conceptualmente en capas abstractas, y los modelos más comunes tienen tres, cuatro, cinco o siete capas. Estos marcos conceptuales suponen que cada capa "oculta" esencialmente el funcionamiento detallado de un determinado dispositivo o capa de software de otros dispositivos o algoritmos con los que se comunica. Esto se debe a que las capas se definen para que contengan la información suficiente para los intercambios de datos que se realizan.

Figura 2: Las arquitecturas de sistemas tradicionales son jerárquicas, pero la computación en la nube y la niebla han difuminado las líneas entre las funciones de los componentes. Eso ha impulsado el uso de nuevos modelos de protocolo de red. (Fuente de la imagen: motioncontroltips.com)

Independientemente del modelo utilizado, todos establecen una capa de aplicación como la capa de abstracción más alta entre los dispositivos que se comunican entre sí en una red. Consideremos la capa de aplicación como un concepto del modelo de Interconexión de Sistemas Abiertos (OSI), en el que fue definida por primera vez por la Organización Internacional de Normalización (ISO) hace casi tres décadas para las comunicaciones de red. Este modelo clásico de siete capas es algo excesivamente complicado para describir algunos de los protocolos actuales, pero sigue siendo útil para comprender plenamente el flujo de datos dentro de los sistemas:

La capa física de un protocolo permite la transmisión de datos brutos (bits digitales) en forma de señales eléctricas, radioeléctricas u ópticas. Esta capa especifica la disposición de los pines, los niveles de tensión, la velocidad de los datos y las impedancias de línea de los elementos físicos que transportan los datos. Ethernet es un protocolo de capa física común. Lea el artículo de DigiKey EtherNet/IP versus PROFINET para obtener más información al respecto.

La capa de enlace de datos conecta los nodos de la red para permitir que los dispositivos establezcan conexiones y corrijan errores en la capa física. Dentro del estándar IEEE 802, la capa de enlace de datos se divide en una capa de control de acceso al medio (MAC) (de nuevo, para permitir que los dispositivos se conecten) y una capa de control de enlace lógico (LLC) para identificar la siguiente capa que se utilizará (la capa de red), así como la comprobación de errores y la sincronización. Lea más sobre las funciones de la capa de enlace de datos en el artículo de DigiKey Implementing Industrial Ethernet with 32-bit MCUs (Implementación de Ethernet industrial con MCU de 32 bits). En cambio, la capa de red permite el reenvío de paquetes de datos a direcciones de red. Cuando los protocolos de Internet se refieren al modelo del Protocolo de Control de Transmisión y del Protocolo de Internet (TCP/IP) (que se trata en la siguiente sección de este artículo), hay una capa de Internet entre las capas de enlace de datos y de red. De hecho, la capa de Internet suele considerarse parte de la capa de red.

La primera de las tres capas siguientes del modelo OSI es la capa de transporte, que garantiza la fiabilidad y la seguridad de las comunicaciones durante las transferencias de secuencias de datos. A continuación, la capa de sesión controla cuándo los dispositivos se conectan entre sí y si la conexión es unidireccional (simplex) o en dos direcciones (dúplex). Por último, la capa de presentación permite la traducción de datos para que los dispositivos que utilizan diferentes sintaxis puedan comunicarse.

El objetivo de este artículo -la capa de aplicación- es el nivel más alto de abstracción y con el que interactúan los usuarios y el software del sistema.

Figura 3: Los protocolos de red modernos (y la capa de aplicación) suelen describirse utilizando el modelo OSI clásico de las redes industriales (y comerciales). En cambio, los modelos de arquitectura de IoT de tres capas sitúan la capa de aplicación por encima de las capas de percepción y de red; los modelos de cuatro capas la sitúan por encima de las capas de procesamiento de datos, de red y de detección. Los modelos de protocolo IoT de cinco capas son similares, pero añaden capas de procesamiento y empresariales. (Fuente de la imagen: Design World)

Protocolos de Internet en la automatización industrial

Los protocolos de Internet son sistemas de comunicación de datos llamados así por la forma en que retransmiten los datos entre redes (y normalmente de forma recíproca) para las comunicaciones interfronterizas. Sus funciones suelen describirse con el modelo de cuatro capas de TCP/IP mencionado anteriormente. En este caso, la capa física de red o de enlace es la misma que la capa física del modelo OSI. Por el contrario, la capa de Internet TCP/IP (que se aproxima a una combinación de las funciones de la capa de enlace de datos y de la capa de red del modelo OSI) gestiona tanto las conexiones como los paquetes de datos. En IPv6, esta capa utiliza direcciones IP de 128 bits para identificar hosts en la red, y permite más de 10³⁸ hosts únicos.

La capa de transporte en TCP/IP consiste generalmente en el protocolo de control de transmisión (TCP) o el protocolo de datagramas de usuario (UDP). El TCP se utiliza generalmente para las interacciones humanas, como el correo electrónico y la navegación web. Proporciona conexiones lógicas, acuse de recibo de paquetes transmitidos, retransmisión de paquetes perdidos y control de flujo. Sin embargo, los sistemas embebidos utilizan UDP para obtener una menor sobrecarga y un mejor rendimiento en tiempo real. UDP funciona para los servidores de nombres de dominio (DNS) y el protocolo de configuración dinámica de host (DHCP), así como para las nuevas aplicaciones de IoT.

La capa de aplicación es el nivel más alto del modelo de redes TCP/IP. Las funciones incluyen las asociadas a las capas de sesión y presentación del modelo OSI.

Protocolos genéricos de la capa de aplicación TCP/IP

Los distintos protocolos de la capa de aplicación tienen diferentes anchos de banda de datos, capacidades de tiempo real y requisitos de hardware. Estos factores, junto con la familiaridad de la planta o del equipo OEM con un protocolo, suelen ser un importante criterio de selección. Aunque los primeros protocolos de Internet, como el protocolo de transferencia de hipertexto (HTTP) y el protocolo simple de transferencia de correo (SMTP), se utilizan en gran medida para las comunicaciones dirigidas y consumidas por el ser humano, los protocolos TCP/IP con un sesgo IIoT se centran más en las comunicaciones de máquina a máquina (M2M) y otras comunicaciones industriales.

Lo que complica un poco las cosas es el hecho de que muchos de los protocolos de la capa de aplicación establecidos y utilizados en TCP/IP para las interacciones humanas basadas en la web con la información también tienen usos de consumo y de IoT industrial. Eso es cierto para HTTP y SMTP, así como para el shell seguro (SSH) y el protocolo de transferencia de archivos (FTP). La implementación de funciones de IoT con tecnologías web suele ser factible si se utilizan también el lenguaje de marcado eXtensible (XML) y la notación de objetos de JavaScript (JSON). Una advertencia es que el uso de HTTP tiene implicaciones de seguridad. Por eso suele ser mejor que los dispositivos IoT de estos sistemas sólo incluyan un cliente, y no un servidor. Esto evita que el dispositivo reciba solicitudes de conexión que podrían permitir el acceso externo no autorizado a la red. Aquí, el protocolo WebSocket puede establecer una comunicación full-duplex a través de HTTP. De lo contrario, el protocolo de mensajería y presencia extensible (XMPP) puede ser preferible para instalaciones que necesiten dirigirse a un gran número de dispositivos con buena seguridad y comunicaciones de datos en tiempo real.

Cuando los proyectos de IoT son dirigidos por personal con formación en TI, se pueden preferir estos estándares familiares (de la web legible por humanos). Sin embargo, los nuevos protocolos IIoT pueden, en algunos casos, ser más adecuados para las comunicaciones M2M y otras comunicaciones industriales.

MQTT para funciones de transporte de conectividad vertical

El protocolo Message Queuing Telemetry Transport (MQTT) es el que más rápidamente se está adoptando en la IIoT. Se trata de un protocolo ligero pensado inicialmente para dispositivos IoT con memoria limitada. MQTT, que funciona en espacios de procesamiento compactos y requiere un ancho de banda mínimo, fue desarrollado por primera vez por IBM para conectar sensores en oleoductos. A diferencia del protocolo de aplicación restringida (CoAP), MQTT ya está estandarizado según la norma ISO/IEC 20922. MQTT utiliza la capa de transporte TCP, algo más intensiva en recursos, y por tanto consume más energía... pero los mensajes pueden ser de dos bytes, incluso más pequeños que los de CoAP.

Debido a su naturaleza abierta, MQTT también puede ser particularmente fácil de implementar. No es de extrañar que AWS IoT, de Amazon Web Services, emplee MQTT para el transporte de mensajes y (con salvedades) soporte MQTT basado en la especificación v3.1.1.

MQTT tiene algunas limitaciones, que pueden deberse al hecho de que MQTT se concibió inicialmente como un protocolo de telemetría, en contraste con el protocolo Lightweight Machine to Machine (LwM2M) específico del IoT, del que hablaremos en breve. Características como los objetos, la monitorización de la conectividad y las acciones de los dispositivos remotos no están incluidas en el estándar, por lo que su inclusión tiende a ser específica del proveedor, lo que degrada un poco el valor del protocolo estandarizado. MQTT tampoco ofrece capacidades de gestión de errores. Por último, aunque MQTT puede hacerse seguro con un protocolo TLS completo, hacerlo aumenta su sobrecarga.

Principalmente a nivel empresarial: AMQP

Advanced Message Queuing Protocol (AMQP) es otro estándar abierto con algunas similitudes con MQTT. Ofrece funciones avanzadas, como la cola de mensajes. Sin embargo, la sobrecarga de AMQP es mayor que la de MQTT, por lo que es poco adecuada para conectar dispositivos muy limitados. No es de extrañar que su uso en aplicaciones industriales de IoT sea menos común que su uso en la mensajería empresarial de rendimiento.

CoAP para conectar dispositivos sencillos

El protocolo de aplicación restringida (CoAP) del Grupo de Trabajo de Ingeniería de Internet (IETF) permite la comunicación en redes de bajo consumo entre dispositivos con un mínimo de memoria y capacidad de procesamiento. Puede funcionar con una sobrecarga muy baja y las peticiones y respuestas pueden ser tan pequeñas como cuatro bytes. CoAP evita el uso de una compleja pila de transporte para utilizar UDP en su lugar. Consulte el artículo de DigiKey sobre EtherNet/IP frente a PROFINET enlazado anteriormente para obtener más información sobre UDP. Al igual que HTTP, CoAP también utiliza el modelo REST: los servidores ponen a disposición los recursos bajo una URL y los clientes acceden a ellos mediante los métodos POST, GET, DELETE y PUT. Además, CoAP puede traducirse fácilmente a HTTP para su integración con otras funciones web... y se integra con XML y JSON. Los ingenieros deberían encontrar que la conexión de dispositivos IoT con CoAP es muy similar a la conexión de dispositivos con la API web.

Figura 4: El SiP de Nordic es una MCU de bajo consumo con un módem LTE-M y de banda estrecha (NB)-IoT integrado, así como GPS. Un kit de desarrollo de software permite configurar CoAP. (Fuente de la imagen: Nordic Semiconductor)

Conexión de dispositivos alimentados por batería con LwM2M

Un protocolo de capa de aplicación de la Open Mobile Alliance es el protocolo LwM2M, construido específicamente para aplicaciones de IoT. Empleado en aplicaciones de ciudades inteligentes, seguimiento de contenedores y cargas, rutinas automatizadas fuera de la carretera y supervisión de servicios públicos, LwM2M se basa en CoAP, por lo que comparte muchos de sus atributos. La norma abarca una amplia gama de objetos estándar claramente definidos y mantenidos, así como acciones de control de la conectividad y de los dispositivos remotos. Las actualizaciones automáticas de firmware también simplifican la gestión de los dispositivos conectados a LwM2M. Aunque la inclusión de módulos como JSON aumenta su sobrecarga, también facilita el trabajo de diseño a los desarrolladores. Dado que LwM2M ha sido diseñado específicamente para aplicaciones de IoT, también puede utilizar un protocolo de seguridad DTLS sólido sin aumentar la sobrecarga.

DDS para aplicaciones distribuidas en tiempo real

El servicio de distribución de datos (DDS) es un poco diferente, y a menudo se clasifica como un middleware M2M en lugar de un protocolo de capa de aplicación. Proporciona conexiones seguras y de alto rendimiento en (entre otras cosas) vehículos autónomos, generación de energía y sistemas de control del tráfico aéreo. En estos entornos, el DDS permite la conexión de sistemas empotrados para un control distribuido que se libera de la dependencia excesiva de las pasarelas. El DDS también gestiona el enrutamiento y la entrega de mensajes sin requerir la intervención de las aplicaciones. Además, los parámetros de calidad del servicio DDS son configurables, por lo que las operaciones de la red pueden optimizarse para que funcionen dentro de las limitaciones del sistema.

Figura 5: El software Connext Drive para vehículos autónomos se basa en el middleware de servicio de distribución de datos (DDS), que forma parte de la base de las arquitecturas de software AUTomotive Open System ARchitecture (AUTOSAR) adaptativa y arquitecturas de software ROS2. Este es solo un ejemplo de cómo DDS apoya la integración de software de IoT. (Fuente de la imagen: Real-Time Innovations)

Conclusión: Protocolos de la capa de aplicación de la IIoT

Todos los protocolos tienen puntos fuertes y débiles, pero las opciones de código abierto que permiten un rápido despliegue y seguridad (preferiblemente con poca sobrecarga) son las más adecuadas para las aplicaciones del IoT. Los sistemas integrados y los dispositivos de sistema en chip (SoC) con capacidades informáticas cada vez mayores siguen impulsando la implementación de la IIoT, y amplían aún más las posibilidades de las distintas capas de aplicación de los protocolos.