Protocolos de comunicaciones
La información que se aporta a continuación pretende ser complementaria al guion del proyecto y no es de lectura obligatoria.
Motivación
Un protocolo de comunicaciones consiste en unas reglas a las que deben ajustarse el emisor de un mensaje y su receptor para poder comunicarse. A la práctica, en cada capa del nivel del modelo OSI se establecen unas reglas concretas (que pueden referirse a aspectos como el empaquetado de la información, el formato de la trama de datos, su longitud o como se gestiona el control de errores) y queda definido un protocolo para cada capa.
La figura siguiente muestra un esquema de comunicaciones entre dos equipos (Host A y Host B) y la correspondencia de protocolos para cada capa. Las anotaciones a la derecha (APDU, PPDU, SPDU, etc.) indican que nombre reciben las unidades de comunicación en cada capa.
En cualquier aplicación en la que sea necesario un flujo de comunicaciones entre equipos y aplicaciones se utilizan uno o varios protocolos de comunicaciones. Es necesario conocer las características más importantes de dichos protocolos para identificar los parámetros que se les debe proporcionar (direcciones IP, direcciones de mapas de memoria, códigos de lectura/escritura).
En la segunda parte del proyecto, la que consiste en implementar la arquitectura CPS, trabajaréis directamente con el protocolo Modbus a la hora de realizar la lectura de datos de un PLC. Por otro lado, observaréis que alguno de los softwares que se va a utilizar admiten peticiones codificadas según el protocolo HTTP.
A continuación, os presentamos algunos protocolos comunicaciones de la capa de aplicación que se utilizan en el ámbito de la automatización industrial:
- Modbus.
- Hypertext Trasnfer Protocol o HTTP.
- Message Queuing Telemetry Transport o MQTT.
Como ejemplo, en una aplicación sobre los protocolos TCP para la capa de transporte, IP para la capa de red y Ethernet para la capa de interfaz de red, las capas se distribuyen de la siguiente forma:
Modbus
Modbus es un protocolo de comunicaciones industriales, creado por MODICON en 1979 y abierto, desarrollado para hacer posible la transmisión de información entre sus PLCs. Modbus es un protocolo de aplicación, lo que significa que puede implementarse sobre diferentes capas físicas (con sus respectivos protocolos). Existen versiones del protocolo para puerto serie y Ethernet (Modbus TCP/IP), y otros protocolos que derivan de TCP/IP. En automatización industrial es muy común el uso del modelo Modbus TCP/IP.
Las redes Modbus utilizan una arquitectura maestro-esclavo (o cliente-servidor). El maestro inicia las comunicaciones (e.g. un SCADA) mediante un código de función que solicita datos a un esclavo (e.g. un PLC), que devuelve una respuesta en función del código que ha recibido. El puerto reservado para el protocolo Modbus es el puerto 502.
Modelo de datos de Modbus
Originalmente, Modbus soporta dos tipos de datos: un valor booleano y un entero sin signo de 16 bits. En muchos casos los sensores y otros dispositivos generan datos en tipos diferentes (e.g. valores con punto flotante). Es común para los dispositivos esclavos convertir estos tipos de datos más grandes a registros. Como ejemplo, un sensor de presión puede dividir un valor de punto flotante de 32 bits entre dos registros de 16 bits.
En los sistemas SCADA, es común para los dispositivos embebidos tener ciertos valores definidos como entradas (e.g. ganancias o parámetros PID), mientras que otros valores son salidas (e.g. la posición de una válvula). Los valores de datos de Modbus son divididos en cuatro rangos:
| Bloque de memoria | Tipo de datos | Acceso de maestro | Acceso de esclavo |
|---|---|---|---|
| Bobinas | Booleano | Lectura/Escritura | Lectura/Escritura |
| Entradas discretas | Booleano | Solo lectura | Lectura/Escritura |
| Registros de retención | Palabra de 16 bits sin signo | Lectura/Escritura | Lectura/Escritura |
| Registros de entrada | Palabra de 16 bits sin signo | Solo lectura | Lectura/Escritura |
Códigos de función de Modbus
Los códigos de función determinan cómo el maestro tiene acceso y modifica los datos. Cuando a un esclavo se le pide realizar un código de función, utiliza los parámetros de la función que ha recibido del maestro para ejecutar unas acciones concretas.
Los códigos de función más comunes llevan el nombre del rango de datos que modifican o al que tienen acceso. A continuación, se muestran algunos ejemplos:
| Código | Función |
|---|---|
| Decimal | Hexadecimal |
| 02 | 0x02 |
| 06 | 0x06 |
| 16 | 0x10 |
El siguiente enlace conduce a la página web oficial de los desarrolladores del protocolo Modbus:
En el siguiente enlace podéis encontrar las especificaciones técnicas del protocolo Modbus, que ofrecen información detallada acerca de:
- El formato de datos reconocidos por Modbus.
- Las direcciones empleadas por Modbus.
- Las categorías de códigos de función.
- Las descripciones de cada código de función.
- Las excepciones generadas por Modbus.
https://www.modbus.org/docs/Modbus_Application_Protocol_V1_1b3.pdf
Compatibilidad con Node-RED
Dentro de la paleta de Node-RED se pueden encontrar varias librerías que permiten emitir y recibir comunicaciones en formato Modbus. La librería utilizada en el proyecto que desarrollaréis es la siguiente:
https://flows.nodered.org/node/node-red-contrib-modbus
HTTP
La característica que define el protocolo HTTP es su capacidad de transmitir información con el formato hipertexto, lo que permite que en la información codificada se puedan incluir otros recursos como vídeos, gráficos, audios… Los enlaces que pueden formar parte de un mensaje en formato hipertexto reciben el nombre de hipervínculos.
Como es el caso con Modbus, HTTP se basa en una arquitectura cliente-servidor. El cliente emite peticiones HTTP y el servidor devuelve una respuesta HTTP con un código de respuesta, que puede venir acompañado de información adicional si la petición lo requiere. Como ejemplo, un navegador web puede ejercer como cliente y una aplicación que se ejecuta en un servidor que aloja una página web puede ejercer como servidor.
El formato que tienen las peticiones y las respuestas HTTP es muy similar y está predefinido. Conocer el tipo de peticiones que espera recibir un servidor y las respuestas que genera permite, des del punto de vista de un cliente:
- Generar peticiones que se ajusten al formato de peticiones que puede recibir el servidor con el que se quiere trabajar.
- Adaptar la aplicación cliente para que sea capaz de recibir las respuestas HTTP que devolverá el servidor.
Las peticiones y respuestas HTTP se codifican como una string en formato ASCII, lo que permite que los datos se envíen en forma de trama codificada en formato hexadecimal. A continuación, podéis ver un ejemplo de respuesta HTTP y su equivalencia como una trama de datos hexadecimal:
En Atenea podéis acceder a dos vídeos que hemos generado específicamente para presentar el protocolo HTTP:
- El vídeo Video1_HTTP.mp4 trata las características más importantes del protocolo HTTP, así como los formatos de las peticiones y respuestas HTTP.
- El vídeo Video2_HTTP.mp4 presenta ejemplos prácticos de comunicaciones mediante el protocolo HTTP implementados sobre la herramienta Node-RED. En este segundo vídeo se dan por conocidos los conceptos presentados en el primer vídeo.
MQTT
MQTT es un protocolo que está basado en relaciones publish-subscribe y gracias a ello aligera enormemente las comunicaciones entre dispositivos, ya que solo se envía información cuando suceden eventos concretos y por tanto los recursos necesarios en cuanto a anchos de banda son mucho menores. Esta información se encapsula en forma de objetos que reciben el nombre de messages. Las relaciones publish-subsrcribe quedan definidas cuando se defina un árbol jerárquico de topics, en los que algunos dispositivos (que reciben el nombre de nodos) pueden subscribirse o publicar. Por otro lado, todas las comunicaciones son gestionadas por un nodo central (que recibe el nombre de broker).
Este modo de funcionamiento permite aislar las aplicaciones que publican en un topic de las que están subscritas al mismo. Algunas implicaciones de ello son las siguientes:
- Las aplicaciones no necesitan compartir ningún parámetro entre ellas ni tener constancia de la existencia de las otras.
- No es necesario que las aplicaciones se encuentren sincronizadas.
- No es necesario que las aplicaciones estén conectadas a la vez. Es posible que una aplicación publique un message, en un topic concreto, con un parámetro que indica al nodo central que lo retenga, para que lo reciban las aplicaciones subscritas cuando estén conectadas.
Todo ello facilita enormemente la escalabilidad del sistema ya que en cualquier momento se puede modificar la jerarquía de topics y declarar nuevos nodos publicadores/subscriptores.
El siguiente enlace conduce a la página web oficial de los desarrolladores del protocolo MQTT, donde podéis encontrar toda la información técnica:
Concretamente, en el siguiente enlace podéis encontrar las especificaciones técnicas del protocolo:
https://mqtt.org/mqtt-specification/
En Atenea podéis acceder a dos vídeos que hemos generado específicamente para presentar el protocolo MQTT:
- El vídeo Video1_MQTT.mp4 introduce el protocolo MQTT y desarrolla un ejemplo teórico muy simple con el objetivo de dar contexto a los conceptos teóricos más importantes: nodos, topics, etc.
- El vídeo Video2_MQTT.mp4 implementa sobre la herramienta Node-RED el ejemplo teórico presentado en el primer vídeo.