¿Qué es el espacio de direcciones de OPC UA y el modelo de información?

Volver al glosario

Nodos y referencias en lugar de una lista plana de registros

El bloque de construcción del espacio de direcciones es el nodo, y OPC UA define varias clases de nodo para distintos propósitos. Los nodos de objeto representan cosas - una bomba, un pozo, un separador - y actúan como contenedores. Los nodos de variable retienen valores reales, como una lectura de presión o un estado de marcha, y por lo general se organizan por debajo de los objetos a los que pertenecen. También hay nodos de método para acciones invocables, y nodos de tipo que definen plantillas reutilizables. Cada nodo tiene atributos como un nombre para mostrar y un NodeId, así que es a la vez direccionable y etiquetado.

Lo que convierte un montón de nodos en una estructura navegable son las referencias. Una referencia es un enlace tipado y dirigido de un nodo a otro, y el tipo de referencia carga significado. Una referencia HasComponent dice que un nodo es un componente de otro - una variable de Presión es un componente de un objeto Cabezal - mientras que las referencias HasProperty, HasTypeDefinition y Organizes expresan otras relaciones. Como las referencias son tipadas, un cliente no solo ve que dos nodos están conectados; ve cómo se relacionan, lo que le permite reconstruir la estructura de la planta en lugar de una red aleatoria de enlaces.

Este modelo de grafo es la antítesis de una lista plana de registros. En Modbus, el registro 40021 está junto al 40022 sin relación implícita y sin jerarquía alguna; la estructura existe solo en la hoja de cálculo del ingeniero. En OPC UA, la presión y la temperatura del mismo cabezal son visiblemente hijas de ese objeto cabezal, y el cabezal es visiblemente parte de un pad, que es parte de un campo. Las relaciones son datos de primera clase dentro del servidor, así que la forma de la planta es algo que una máquina puede leer directamente.

Tipos y un modelo autodescriptivo

El modelo de información obtiene mucho de su poder de las definiciones de tipo. Así como la programación orientada a objetos tiene clases e instancias, OPC UA tiene tipos de objeto e instancias de objeto. Un tipo de objeto como un tipo Bomba declara que cada bomba tiene un estado de marcha, una velocidad y una presión de descarga; cada bomba real en la planta es entonces una instancia de ese tipo, enlazada a él por una referencia HasTypeDefinition. Un cliente que entiende el tipo Bomba sabe de inmediato qué esperar de cualquier instancia de bomba sin inspeccionar cada una individualmente.

Esta tipificación es lo que vuelve al modelo semántico en lugar de meramente estructural. Las especificaciones acompañantes (companion specifications) construyen modelos de información estandarizados para dominios particulares sobre el OPC UA base, y definen tipos acordados para equipo común para que un dispositivo de un fabricante y uno de otro expongan la misma forma. Incluso sin una companion spec formal, los propios tipos de un servidor le dicen a un cliente que estos diez nodos son todos bombas y comparten una estructura común, lo que es mucho más rico que diez grupos de registros no relacionados que por casualidad siguen la misma convención.

Ser autodescriptivo tiene un beneficio concreto: un cliente puede llegar a un servidor que nunca ha visto y averiguar qué hay. Navegando desde la cima del espacio de direcciones hacia abajo y leyendo las definiciones de tipo, puede enumerar los objetos, descubrir sus variables, aprender el tipo de dato y las unidades de cada variable, y entender cómo se organiza todo - todo desde el propio servidor. El modelo lleva su propia documentación, que es precisamente lo que un mapa plano de registros no puede hacer.

Por qué esto importa para el descubrimiento de activos en el SCADA de nube

Tradicionalmente, incorporar una nueva instalación a un sistema SCADA significa construir a mano un mapa de direcciones: alguien lista cada registro o punto, su significado, sus unidades y su escalamiento, y esa lista se transcribe a la configuración del SCADA. Es lento, propenso a errores y se vuelve obsoleto cada vez que el campo cambia. El espacio de direcciones navegable y autodescriptivo de OPC UA cambia la naturaleza de ese trabajo, porque la estructura y el significado ya viven en el servidor y pueden leerse en lugar de reteclearse.

Para un SCADA de nube como Merobix, esto significa conectarse al servidor OPC UA de una instalación y navegar su espacio de direcciones para descubrir qué activos existen - los pozos, separadores, tanques y compresores - y qué mide cada uno, completo con tipos de datos y unidades. En lugar de partir de un mapa en blanco y llenar cada dirección a mano, la plataforma puede presentar la propia jerarquía del servidor y dejar que un ingeniero seleccione los objetos y variables a traer como tags. La estructura de equipo que el servidor publica se vuelve el punto de partida para el propio modelo de activos del SCADA.

El beneficio se acumula a lo largo de la vida de un campo. Cuando una instalación añade un pozo o un patín nuevo, y su servidor OPC UA expone los nuevos objetos y variables, un navegado del espacio de direcciones los saca a la superficie para su inclusión en lugar de requerir que el mapa se reconstruya desde una hoja de cálculo nueva. Como el modelo es tipado, una nueva bomba que es una instancia de un tipo de bomba existente se entiende en el momento en que aparece. Esta es la diferencia práctica entre un protocolo que le entrega una bolsa de números y uno que le entrega una imagen etiquetada y estructurada de la planta que una plataforma de nube puede recorrer por su cuenta.

Preguntas frecuentes