Existen varios protocolos de comunicación que se usan para teleoperar un sistema. Cada protocolo posee sus ventajas y desventajas. Además, es importante tomar en cuenta las características del canal de comunicación que usa cada protocolo. A continuación, se detalla primero los tipos de canales de comunicación que existen, y sus características, posteriormente se presenta los protocolos de Internet que se usan netamente para teleoperación.
CANALES DE COMUNICACIÓN [4]
En teleoperación el canal de comunicación es el medio por el cual se transporta la información desde la estación local hacia la estación remota y viceversa, en este proyecto el Internet. No todos los canales tienen la misma capacidad para transmitir información. Se debe garantizar la estabilidad del canal de comunicación y en consecuencia la estabilidad del sistema de teleoperación.
Canales Dedicados
Es un canal de comunicación que se usa específicamente para un propósito. Está disponible a toda hora para su uso por un usuario designado. No comparte nada con otros usuarios. La ventaja de estos canales es la velocidad de movilización de datos y la privacidad que poseen. Este canal se da cuando existe conexión punto a punto entre dispositivos.
Canales No Dedicados
Es un canal de comunicación por el que pasan varios paquetes de información a la vez y es accesible para varios usuarios, un claro ejemplo es el Internet. Este canal existe en la conexión multipunto de dispositivos.
No se debe usar un canal dedicado cuando se tiene los siguientes escenarios:
· Los dispositivos están muy alejados. En este caso no estaría justificado, por
ejemplo, utilizar un enlace dedicado entre dos dispositivos que puedan estar separados por miles de kilómetros.
· Hay un conjunto de dispositivos que necesitan conectarse entre ellos en
instantes de tiempo diferentes. Un ejemplo de esta necesidad es la red de teléfonos mundial o el conjunto de computadores pertenecientes a una compañía. Salvo el caso de que el número de dispositivos sea pequeño, no es práctico utilizar un enlace entre cada dos.
Con la justificación dada se concluye que en teleoperación es conveniente y se debe usar un Canal de Comunicación No Dedicado, en este caso el Internet.
PROTOCOLOS APLICABLES EN INTERNET USADOS EN
TELEOPERACIÓN
Dentro de Internet existe un sin número de protocolos de comunicación que se usan para el intercambio de información. Sin embargo, en teleoperación se hace uso de un número reducido, debido a las características que poseen. A continuación, se detalla varios protocolos usados en teleoperación.
Protocolo de Transferencia de Hipertexto HTTP [4]
El Protocolo de transferencia de hipertexto (HTTP) es el protocolo que se usa la World Wide Web (WWW) y puede ser utilizado en cualquier aplicación con arquitectura cliente/servidor que implique hipertexto. HTTP en realidad no es un protocolo para la transferencia de hipertexto, sino que es un protocolo para transferir información con la eficiencia necesaria para realizar saltos de hipertexto.
El tipo de datos que pueden ser transmitidos por este protocolo son texto claro, hipertexto, audio, imágenes o cualquier información accesible por Internet.
El uso más típico del protocolo HTTP es que soporta el intercambio de información entre buscadores web y servidores web. HTTP utiliza el modelo de comunicación solicitud/respuesta. Además, es un protocolo ‘sin estado’, debido a que no guarda información de conexiones anteriores, es decir, cada conexión se trata de forma independiente, una vez terminada la transferencia de datos la conexión se da por finalizada.
Una característica importante del protocolo HTTP es que es tolerable a varios formatos, es decir, cuando un cliente envía solicitud a un servidor, puede incorporar una lista de formatos preferidos que pueda manejar y el servidor responde con el formato que sea más apropiado. Por ejemplo, si un navegador no puede manejar imágenes, el servidor web no transmitirá ninguna imagen en las páginas web. Esta medida permite que sólo se transmita información netamente necesaria.
Figura 1.8 Operación del protocolo HTTP [4]
En la Figura 1.8 se observa el modo de funcionamiento del protocolo HTTP. El cliente realiza una solicitud al servidor y este le envía una respuesta. La conexión existente entre ambos es TCP (Protocolo de Control de Transmisión), siendo TCP uno de los protocolos fundamentales de Internet.
Protocolo de Transporte en Tiempo Real RTP [4]
Este protocolo, como su nombre lo dice, sirve para transmitir en tiempo real datos multimedia. Aunque cada aplicación en tiempo real podría incluir sus propios mecanismos para soportar el transporte en tiempo real, hay una serie de características que justifican la definición de un protocolo común. Un protocolo diseñado para este propósito es el protocolo de transporte en tiempo real (RTP).
RTP no garantiza en sí la transmisión en tiempo real de los datos multimedia, ya que eso depende netamente de la red, pero si proporciona los medios necesarios para administrar los datos a medida que llegan de manera rápida y eficaz. RTP generalmente funciona sobre el protocolo UDP (Protocolo de Datagrama del Usuario), pero también puede usar otros protocolos como el SIP (Protocolo de Inicio de Sesión).
Protocolo MQTT (Message Queue Telemetry Transport) [16]
MQTT es un protocolo de comunicación con arquitectura publicador/suscriptor. Se caracteriza por ser simple y ligero en el transporte de datos, diseñado para dispositivos restringidos y redes de bajo ancho de banda, de alta latencia o poco fiables. Los principios de diseño son minimizar el ancho de banda de la red y los requerimientos de recursos del dispositivo, a la vez que intenta asegurar la fiabilidad y cierto grado de seguridad en la entrega. Estos principios también se convierten en el protocolo ideal de la emergente “máquina a máquina” (M2M) o “Internet de las cosas”, mundo de dispositivos conectados, y para aplicaciones móviles donde el ancho de banda y la energía de la batería son muy importantes.
Protocolo Websockets [17]
Es un protocolo de comunicación que proporciona una sesión de comunicación interactiva entre el navegador de usuario y un servidor, se puede usar en aplicaciones con arquitectura cliente/servidor. Con este protocolo se puede enviar mensajes al servidor y recibir respuestas controladas por eventos sin necesidad de consultar al servidor por una respuesta, debido a que posee un canal de comunicación bidireccional y full dúplex.
Con las aplicaciones tradicionales de Internet, como la transferencia de archivos, el correo electrónico y las aplicaciones cliente / servidor, incluyendo la Web, las métricas de rendimiento de interés son generalmente el rendimiento y el retardo. También hay una preocupación con la fiabilidad, y se utilizan mecanismos para asegurarse de que los datos no se pierdan, se dañen o se maltratan durante el tránsito. Por el contrario, las aplicaciones en tiempo real se preocupan más por los
problemas de tiempo. En la mayoría de los casos, existe el requisito de que los datos sean entregados a una tasa constante igual a la tasa de envío. En otros casos, se asocia un plazo a cada bloque de datos, de manera que los datos no se pueden utilizar después de que expire el plazo.
ARQUITECTURA DEL PROTOCOLO DE COMUNICACIÓN MQTT
Para este proyecto se escogió el protocolo de comunicación MQTT, porque posee la rapidez para la transmisión de datos, y ha tenido gran desarrollo en tarjetas embebidas. La mayor parte de información de este protocolo se encontró en el proyecto de titulación [18]. El protocolo MQTT trabaja con arquitectura publicador / suscriptor, la cual, se explica en el siguiente punto.
Arquitectura Publicador / Suscriptor
En la arquitectura de comunicación, mostrada en la Figura 1.9, publicador/suscriptor cualquier participante puede tener el papel de publicador o de suscriptor. El agente publicador produce varios paquetes de datos de información denominados “tópicos”. El suscriptor es el agente que consume los tópicos.
Figura 1.9 Arquitectura de comunicación publicador / suscriptor
La principal característica de esta arquitectura de comunicación es la forma en que los tópicos viajan desde el publicador hasta el suscriptor; el suscriptor no está directamente dirigido al publicador, si no que indirectamente se direcciona dependiendo del contenido de cada tópico. Es decir, el suscriptor sólo toma los tópicos a los cuales está suscrito. Además, el suscriptor no anula sus actividades mientras espera la notificación del tópico.
Para evitar que el publicador conozca todas las suscripciones de cada suscriptor, en el proceso de propagación de información desde el publicador hasta el suscriptor se coloca un mediador. Este mediador es un “Servidor de Datos”. [19]
El Servidor de Datos es el único medio por el cual el publicador y suscriptor se comunican. El servidor de datos debe:
· Almacenar todas las suscripciones de cada suscriptor.
· Recibe y almacena los tópicos del publicador, para que los suscriptores
puedan adquirirlos.
SERVIDOR DE DATOS O BRÓKER
El servidor de datos o bróker con el que trabaja el protocolo de comunicación MQTT es “Eclipse Mosquitto”. Eclipse Mosquitto es un bróker de mensajería de código abierto (EPL) que implementa las versiones 3.1 y 3.1.1 del protocolo MQTT, proporciona un método ligero de realizar mensajes usando un modelo de publicador / suscriptor. Esto lo hace adecuado para el "Internet de las cosas" de mensajería, como con sensores de baja potencia o dispositivos móviles como teléfonos, ordenadores integrados o microcontroladores como el Arduino [20].