¿Qué es un Node ID de OPC UA?

Volver al glosario

Índice de espacio de nombres más identificador

Un NodeId se escribe en dos piezas porque OPC UA permite que muchos esquemas de nomenclatura independientes coexistan en un servidor. El índice de espacio de nombres, mostrado como ns=, elige a qué espacio de nombres pertenece un identificador. El índice de espacio de nombres 0 está reservado para las definiciones base de la propia OPC Foundation, y los espacios de nombres de proveedor o de aplicación obtienen índices más altos como 1, 2 y superiores. El mismo valor de identificador puede aparecer en dos espacios de nombres distintos y significar dos nodos distintos, así que el índice de espacio de nombres es lo que los desambigua: el identificador por sí solo no basta.

La segunda pieza es el identificador, y OPC UA soporta varios tipos. Los más comunes son los identificadores de cadena, mostrados con s= y que a menudo reflejan la ruta de tag de un controlador como ns=2;s=Pump1.RunStatus, y los identificadores numéricos, mostrados con i= como en ns=0;i=2258 para un nodo estándar. También hay identificadores GUID para claves globalmente únicas e identificadores de cadena de bytes opacos para servidores que usan claves binarias internamente. Qué tipo usa un servidor es su propia elección; un cliente simplemente tiene que referenciar el NodeId exactamente como el servidor lo define, carácter por carácter.

Una sutileza que hace tropezar a los integradores es que el índice de espacio de nombres no está garantizado a ser permanente entre servidores ni siquiera entre reinicios de algunos servidores, porque es apenas una posición en el arreglo de espacios de nombres del servidor. Lo estable es la URI del espacio de nombres - el nombre único completo del espacio de nombres. Los clientes cuidadosos leen la tabla de espacios de nombres del servidor, encuentran la URI que les interesa, y aprenden su índice actual en lugar de codificar en duro ns=2, para que un servidor que reordene sus espacios de nombres no rompa cada referencia. El identificador dentro de un espacio de nombres, en cambio, está pensado para ser estable.

En qué difiere un NodeId de un registro Modbus

Un registro Modbus es un número pelado en una tabla plana - la dirección 40021, digamos - sin nombre, tipo de dato, unidades ni contexto integrados. Para usarlo hace falta un mapa externo que diga que 40021 contiene una presión de cabezal de pozo como un entero de 16 bits escalado por diez. La dirección del registro es puramente una ubicación; todo el significado vive fuera del protocolo en un documento que usted mantiene a mano. Hay exactamente un espacio plano de registros, y cualquier estructura es una convención que usted impone encima.

Un NodeId es fundamentalmente distinto porque direcciona un nodo en un espacio de direcciones estructurado y autodescriptivo en lugar de una celda en una tabla plana. El nodo al que apunta el NodeId carga sus propios metadatos: un nombre para mostrar, un tipo de dato, y atributos que describen si es legible, escribible o historizado. Un NodeId de cadena como ns=2;s=Well12.Casing.Pressure a menudo se lee como una ruta a través de la estructura de la planta, y el cliente puede preguntar al servidor qué tipo de dato y unidades tiene ese nodo en lugar de depender de una hoja de cálculo externa. La dirección y la descripción viajan juntas.

Por eso la integración con OPC UA se siente menos como decodificar y más como navegar. Con Modbus usted parte de una lista de registros y espera que sea precisa; con OPC UA puede navegar el espacio de direcciones del servidor, encontrar el nodo que quiere, anotar su NodeId, y confirmar su tipo desde el propio servidor. El NodeId sigue siendo una dirección que finalmente referencia de forma explícita - es el asa durable que almacena y reutiliza - pero es una dirección hacia un modelo etiquetado y tipado en lugar de hacia una cuadrícula anónima de registros.

Leer un valor de cabezal de pozo con un NodeId

Para leer un valor, un cliente emite una solicitud nombrando el NodeId y el atributo que quiere - típicamente el atributo Value de un nodo variable. Si el cliente quiere la presión de revestimiento actual en el pozo 12, referencia ns=2;s=Well12.Casing.Pressure y pide el valor de ese nodo; el servidor devuelve el valor junto con un estado de calidad y una marca de tiempo de origen que indica cuándo se tomó la lectura. En lugar de leer repetidamente, un cliente más a menudo crea una suscripción sobre ese NodeId para que el servidor empuje los cambios, pero toda operación de ese tipo aún comienza identificando el nodo por su NodeId.

Como el NodeId es el asa para todo esto, obtenerlo de forma correcta es el meollo de montar cualquier lectura. Un cliente o bien navega el espacio de direcciones del servidor para descubrir el NodeId del punto que necesita, o se le da el NodeId en la documentación del servidor. Una vez capturado, ese NodeId se almacena en la configuración del cliente y se reutiliza para cada lectura, escritura o suscripción posterior - es la referencia persistente que ata el tag lógico del cliente a la variable física del servidor.

Para un SCADA en la nube como Merobix que se conecta a un servidor OPC UA en una instalación, los NodeId son cómo los valores de campo se vuelven tags de plataforma. Merobix navega el servidor, resuelve la URI del espacio de nombres a su índice actual para que las referencias sigan siendo válidas, y registra el NodeId de cada variable que necesita - una presión de cabezal, un nivel de separador, un estado de bomba. De ahí en adelante esos NodeId llevan los valores en vivo, con su calidad y marcas de tiempo provistas por el servidor, hacia tendencias y alarmas en el navegador. Almacenar la URI del espacio de nombres en lugar de un índice codificado en duro, y mantener la lista de NodeId bajo control de configuración a medida que la instalación crece, es lo que mantiene robusta la conexión cuando un servidor se actualiza o su espacio de direcciones se reorganiza.

Preguntas frecuentes