El problema de la semántica

Cuando se transmiten datos, la pregunta que surge siempre enseguida es sobre el formato y el contenido de los datos que el receptor y el emisor de la información pueden acordar para que sea compatible. Con la introducción de los sistemas en la nube, esta cuestión se ha vuelto cada vez más grave: los proveedores de datos (en el caso de la tecnología de automatización, los equipos de la fábrica o las máquinas) casi siempre son independientes de las aplicaciones que utilizan estos datos. Esto hace que sea realmente fundamental especificar un formato fijo que todos puedan aceptar. Sin embargo, el tema es que dicho formato no existe en los sistemas en la nube y es dudoso si alguna vez existirá. Hay múltiples motivos para ello. Uno es que los proveedores de servicios en la nube tienen una gran cantidad de grupos de clientes diferentes: las soluciones en la nube la utilizan departamentos de informática, constructores de máquinas, proveedores de servicios financieros, departamentos de marketing, entre otros. Por lo tanto, la plataforma debe ser lo más flexible posible. No obstante, los formatos de datos estandarizados siempre son una limitación y, por lo tanto, los proveedores continúan conformándose con las soluciones detalladas de cada industria sobre formato de los datos.

El problema para la tecnología de la automatización puede ser el siguiente: la información de la planta, en la mayoría de los casos, se presenta en formato de etiquetas del programa en un controlador. Estas etiquetas son imágenes de los valores de los procesos actuales en tipos de datos específicos como “Real”, “Int” o “Bool”. En el más sencillo de los casos, en el cual un valor de proceso se puede transmitir cíclicamente a un servidor en la nube, se deben codificar, al menos, tres tipos de información en la cadena de carga útil del MQTT:

Además de estas tres, se puede agregar opcionalmente información adicional como código de calidad. Para simplificar la aplicación, los usuarios pueden desarrollar sus propias estructuras para representar el estado de una máquina completa. De nuevo, esto se debe codificar en la carga útil MQTT.
Como aquí no hay un estándar uniforme, en la práctica, casi cada aplicación tiene su propio formato que también necesita su propio analizador sintáctico en el momento de utilizar los datos.
Este hecho es un paso hacia atrás desde la perspectiva de la tecnología de la automatización clásica. En tiempos de OPC UA y especificaciones relacionadas que garantizan la interoperabilidad de diferentes dispositivos de diferentes fabricantes, la interfaz MQTT de un proveedor de servicios en la nube parece disfuncional. Aquí el procesamiento de datos requiere un trabajo adicional innecesario.
Una simplificación inicial y práctica es el formato JSON que provee algunas reglas de representación de datos que facilitan un poco la lectura y el análisis sintáctico de la cadena de carga útil MQTT. Aunque esto simplifica el análisis sintáctico, no lo reemplaza.
Para lograr una solución satisfactoria, los proveedores de servicios en la nube e ingenieros de automatización deben trabajar aún más de cerca y delinear juntos las interfaces futuras.