¿Qué es un nombre de tag canónico en SCADA?

Volver al glosario

Un nombre autoritativo por encima de muchos nombres fuente

En una sola planta nueva, una buena convención de nomenclatura puede bastar, porque un equipo controla cada nombre. El problema cambia de forma cuando una empresa consolida muchos sitios que nunca se diseñaron juntos. El PLC de un sitio llama a una presión de descarga por una dirección de registro, otro la llama por una abreviatura de proveedor, un tercero usa un código heredado de un sistema que precede al personal actual. Los tres miden la misma cosa, pero nada en sus nombres lo dice. Un nombre de tag canónico es la respuesta: esa medición recibe un identificador único elegido con deliberación que significa lo mismo en todas partes, y cada variante nativa de dispositivo se trata como un alias que apunta a él.

Por eso el nombre canónico a veces se llama el tag dorado: es la versión de verdad que los sistemas de aguas abajo, las pantallas, los reportes y la analítica referencian todos. Los nombres nativos de dispositivo aún existen y aún importan para hablar con el hardware, pero ya no son la identidad que ve el resto de la organización. Al separar el nombre fuente del nombre autoritativo, la operación gana un vocabulario estable que no cambia solo porque un sitio intercambia un PLC o aparece el estilo de nomenclatura de un contratista nuevo.

Vale la pena distinguir esto de una base de tags llana. Una base de tags lista los puntos que un sistema conoce; un esquema canónico agrega una capa de intención encima, declarando qué nombre es autoritativo y mapeando cada nombre alterno hacia él. La diferencia es la reconciliación, el acto deliberado de decir estos cinco puntos con nombres distintos son la misma medición y así es como todos la llamaremos. Sin ese acto, una base de tags multi-sitio es apenas varias bases de sitio apiladas juntas, aún hablando varios dialectos.

La capa de mapeo y cómo se mantiene

El enlace entre los nombres fuente y los nombres canónicos vive en una capa de mapeo, esencialmente una tabla que anota, para cada nombre nativo de dispositivo en cada sitio, a qué tag canónico corresponde. Cuando llegan datos de un dispositivo de campo bajo su nombre nativo, la plataforma lo busca en el mapa y lo archiva bajo la identidad canónica, así que el flujo crudo del PLC de un proveedor y la vista limpia de toda la flota se mantienen conectados pero distintos. El mapa es el único punto donde la diversidad desordenada del campo se traduce al vocabulario ordenado de la empresa.

Construir el mapa es un ejercicio de reconciliación, y es donde se ubica el verdadero trabajo. Alguien tiene que reconocer que un punto direccionado por registro en un sitio y una abreviatura en otro son la misma medición, decidir el nombre canónico, y anotar el alias. Esto es más fácil cuando las mediciones de fondo se entienden bien y más difícil cuando la documentación es escasa, y por eso el mapeo a menudo saca a la luz ambigüedades genuinas que antes estaban ocultas por todos usando sus propios nombres. Resolver esas ambigüedades es parte del valor, no un efecto secundario.

El mapa no es un artefacto de una sola vez; necesita mantenimiento. Los sitios nuevos traen nombres fuente nuevos para aliasar, los intercambios de equipo cambian lo que un dispositivo reporta, y de vez en cuando un nombre canónico en sí necesita agregarse para una medición que nadie había estandarizado aún. Un proceso disciplinado mantiene el mapa autoritativo: las adiciones pasan por la misma reconciliación, y el mapeo, no los dispositivos de campo, es el lugar donde se hacen los cambios. Como la capa canónica absorbe el vaivén del lado fuente, el vocabulario de aguas abajo se mantiene estable aun cuando el campo debajo de él cambia.

Por qué los nombres canónicos importan para consolidar sitios en la nube

Consolidar datos de campo en un SCADA en la nube es justo el escenario para el que se diseñó la nomenclatura canónica. Merobix lee dispositivos de muchos sitios, proveedores y generaciones de hardware en una plataforma, y sin una capa canónica esos flujos seguirían siendo un conjunto de dialectos incompatibles que no se pueden comparar. Aliasar cada nombre fuente hacia un tag dorado es lo que deja a un solo tablero mostrar la misma medición a través de cada sitio, y lo que deja a una consulta de toda la flota devolver los puntos correctos sin importar cómo cada PLC resultó etiquetarlos.

El fruto es más visible en el trabajo entre sitios. Una consolidación que suma o compara una medición a través de sitios solo tiene sentido si la plataforma sabe qué puntos son la misma medición, y ese conocimiento es precisamente lo que codifica el mapeo canónico. Las pantallas y los reportes con plantilla se vuelven portátiles, porque referencian nombres canónicos que existen en todas partes en vez de las etiquetas crudas de un sitio específico. La alternativa, emparejar a mano los nombres de cada sitio cada vez que quiere una vista combinada, no escala más allá de un puñado de sitios.

La nomenclatura canónica también hace la operación resiliente al cambio en el campo. Cuando un sitio reemplaza un controlador y el nuevo reporta nombres nativos distintos, solo la capa de mapeo necesita actualizarse; cada tablero, reporte y cálculo construido sobre el nombre canónico sigue funcionando sin tocarse. Ese desacoplamiento es la fortaleza callada del enfoque. La empresa obtiene un vocabulario duradero, y el vaivén de la planta física se contiene en una sola capa de traducción en vez de repercutir en todo lo de aguas abajo.

Preguntas frecuentes