Detectar identificadores inconsistentes entre activos IT/OT

Una línea puede llamarse L-03 en el historian, LINEA_03 en el MES y EQ-1187 en mantenimiento. El parecido visual invita a unir los registros, pero cada sistema puede estar describiendo un activo distinto, una estación dentro de la línea o un nombre que cambió con una reorganización. La identidad necesita evidencia antes de convertirse en una clave común.

La revisión de identificadores no es una migración de datos. Consiste en comparar las claves nativas, los alias y el contexto que acompaña a cada registro. La salida puede ser una correspondencia confirmada, una relación provisional o una duda que debe permanecer abierta. Las tres son resultados útiles si se explican y se conservan.

Para detectar un identificador inconsistente, compare los códigos nativos, el alias, la entidad, la ventana y la evidencia de correspondencia antes de unir registros. NIST describe métodos para caracterizar sistemas y analizar datos operativos; esos métodos ayudan a ordenar la comprobación, pero no deciden qué activos son iguales en una planta concreta.

Identidad, alias y linaje son preguntas distintas

El identificador nativo es la clave que el sistema de origen utiliza para localizar un activo. Puede ser un código de equipo, un tag, un número de inventario o una clave de mantenimiento. Debe conservarse aunque el informe utilice un nombre más cómodo. El alias es una etiqueta de lectura que agrupa o relaciona códigos con un criterio documentado.

El linaje responde a otra pregunta: qué transformaciones sufrió un dato desde su origen hasta una vista. Un registro puede tener una identidad bien resuelta y un linaje incompleto. También puede tener un linaje claro y un código de activo ambiguo. No mezcle ambas revisiones en una sola conclusión, porque cada una necesita evidencias y responsables diferentes.

Un alias revisable puede incluir la fecha de alta, la fuente que lo propone, la persona que lo verificará y la lista de códigos relacionados. No debe borrar los códigos nativos ni afirmar que todos representan la misma capacidad. Si aparece un nuevo código, el alias se revisa en lugar de editar silenciosamente la historia.

Señales de que una identidad necesita revisión

Nombres parecidos con ubicaciones diferentes

La coincidencia de L-03 en dos sistemas pierde fuerza si una tabla sitúa el equipo en la nave norte y otra en la nave sur. Registre la ubicación tal como aparece en cada fuente y la fecha de la consulta. Un cambio de ubicación puede explicar el nombre distinto, pero debe demostrarse con un registro de activos o una orden de mantenimiento.

Un mismo código con unidades o estados incompatibles

Si un código se usa como línea en un sistema y como estación en otro, la unidad de medida y los estados operativos suelen divergir. Un contador de unidades y un estado de mantenimiento no son dos lecturas del mismo campo. La diferencia no implica error, pero sí exige separar el nivel de entidad.

Cambios de nombre sin historial

Una reorganización puede cambiar el nombre visible sin cambiar el equipo físico. Si no existe historial de cambios, no reconstruya la relación por intuición. Marque el alias como pendiente y pida el documento que autoriza el cambio. La fecha del cambio ayuda a delimitar qué periodos pueden compararse.

Identificadores reciclados

Algunas organizaciones reutilizan un código después de retirar un equipo. Un registro antiguo y uno nuevo pueden compartir la clave, pero tener capacidades, ubicaciones o ventanas diferentes. Conserve el periodo de validez y no mezcle series por conveniencia del dashboard.

Alias generados por una interfaz

Un gateway puede recortar ceros, cambiar mayúsculas o añadir un prefijo. El resultado parece un código oficial, aunque sea una transformación. Compare el mensaje original, la regla de conversión y el valor almacenado. La interfaz debe aparecer como fuente del alias, no como autoridad del activo.

La ficha de correspondencia

Una ficha sencilla permite revisar cada relación sin abrir todas las aplicaciones. Incluya al menos:

La ficha no debe contener contraseñas, tokens ni volcados completos de datos. Si un proveedor necesita comprobar una relación, comparta el mínimo necesario y conserve la versión del archivo autorizado. La seguridad del acceso se gestiona con los controles de la organización, no con un alias.

Método de revisión paso a paso

1. Defina la pregunta y el periodo

No empiece buscando todos los códigos de la empresa. Elija una decisión: confirmar la entidad de un KPI de capacidad, reconciliar un inventario o explicar por qué una línea desaparece de un informe. Fije el periodo que debe cubrir la correspondencia. Un alias válido hoy puede no ser válido antes de una ampliación.

2. Recupere los códigos sin normalizarlos

Copie cada valor exactamente como lo entrega su sistema. Mantenga mayúsculas, ceros y separadores. Guarde el nombre de la tabla, tag o pantalla y la fecha de extracción. La normalización para comparar puede hacerse en una columna aparte, nunca sobre el valor original.

3. Añada contexto físico y operativo

Compare ubicación, área, familia de producto, estado y ventana de uso. La familia no identifica por sí sola un equipo, pero puede revelar que un código pertenece a otra célula. El estado también ayuda a detectar que un registro es una orden de mantenimiento y no una línea productiva.

4. Busque evidencia de cambio

Consulte el inventario autorizado, una orden de cambio, la tabla de activos o el registro que la organización haya designado. Anote la referencia concreta, no solo “lo confirmó operaciones”. Si la fuente no muestra fecha o autoridad, trate la relación como provisional.

5. Proponga un alias con alcance limitado

El alias debe decir qué códigos relaciona, en qué periodo y para qué uso. Un alias para una consulta de capacidad no autoriza a unir registros de mantenimiento, seguridad o costes. Si el uso cambia, cree una revisión o un alias separado.

6. Solicite confirmación y conserve la duda

Pida a la autoridad indicada que confirme la correspondencia. Si no responde, el estado sigue siendo pendiente. No convierta la falta de respuesta en aprobación por silencio. La ficha puede emplearse para pedir la evidencia, pero no para cerrar el KPI.

Qué aportan las referencias técnicas

NIST desarrolla métodos, modelos, métricas y datos operativos para caracterizar sistemas de fabricación y analizar mejoras o compromisos. El programa de investigación de NIST sirve como contexto metodológico, no como estadística española ni como garantía de ahorro. La identidad de un activo sigue dependiendo de los registros locales.

NIST desarrolla métodos para caracterizar sistemas, seleccionar métricas y analizar datos operativos para evaluar mejoras y compromisos. Ese alcance no prueba que dos identificadores pertenezcan al mismo activo.

ISA-95 ayuda a describir niveles y objetos entre control, operaciones y negocio. El resumen oficial es útil para ubicar una pregunta en la arquitectura, pero no certifica que dos códigos que aparecen en niveles distintos representen el mismo equipo.

OPC UA define modelos de información y mecanismos de comunicación. Un mensaje bien formado no demuestra que el identificador sea correcto, que el alias se haya validado o que la ubicación esté actualizada. La prueba debe incluir el valor de origen y el registro que autoriza la relación.

NIST también describe principios de gobierno para procesar y usar datos manufactureros de forma consistente y repetible. Esa referencia ayuda a conservar decisiones y procedencia, pero no sustituye un inventario ni asigna una autoridad en la planta.

La hoja de ruta de IA/ML de NIST menciona retos de heterogeneidad, gestión de datos y operación que pueda explicarse. Puede servir para explicar por qué conviene documentar alias y campos de contexto. No autoriza a afirmar que una herramienta de IA detecte automáticamente la identidad correcta o que haya obtenido un resultado en la instalación.

La guía de ENISA contiene ejemplos de evidencias y mapeos técnicos para entidades dentro de su alcance. No es una certificación NIS2, no sustituye la transposición española y no determina qué equipo pertenece a una red. Si se consulta, deja constancia del apartado y de la autoridad que confirma su aplicabilidad.

Cómo distinguir una coincidencia de una confirmación

Una coincidencia es una señal: mismo texto, misma ubicación o una hora parecida. Una confirmación combina varias señales con una fuente autorizada y un periodo de vigencia. El registro debe decir qué evidencia se usó y quién puede impugnarla.

Por ejemplo, LINEA_03 y L-03 coinciden en ubicación y familia durante enero, pero el inventario muestra una ampliación en febrero. La salida prudente es un alias con vigencia de enero y una revisión para febrero. No hay base para unir toda la serie anual.

En otro caso, EQ-1187 aparece en mantenimiento con una orden de calibración y en el historian como un tag. La descripción y la ubicación coinciden. Aun así, falta saber si el tag representa el equipo completo o un sensor concreto. El alias debe indicar ese nivel, no borrar la distinción.

Cuando un código no aparece en un sistema, no deduzca que el activo no existe. Puede estar fuera del alcance de la interfaz, retirado durante la ventana o registrado con otra clave. Marque la cobertura de cada fuente y pida la consulta que pueda resolver la ausencia.

Auditoría de una correspondencia propuesta

Antes de aceptar un alias, lea la relación de izquierda a derecha. Comience por el código nativo y pregunte qué sistema lo creó. Después compruebe si el alias mantiene el mismo nivel de entidad. Un nombre de línea no debe apuntar sin explicación a un sensor individual, aunque el sensor esté instalado en esa línea.

Revise la vigencia. El alias puede ser correcto para una ventana de producción y dejar de serlo después de una ampliación, un cambio de proveedor o un cambio de layout. Escriba inicio y fin cuando se conozcan; si solo existe una fecha de revisión, no la presente como fecha de alta del activo.

Compare la evidencia con una segunda fuente independiente. Un inventario y una orden de mantenimiento pueden confirmar ubicación y número de equipo, mientras el historian aporta el tag que se observó. Dos vistas del mismo sistema no cuentan como confirmación independiente si comparten la misma tabla transformada.

Compruebe las excepciones que afectan a la identidad. Un reinicio de un controlador puede reciclar una secuencia. Una migración puede añadir ceros a la izquierda. Un gateway puede truncar caracteres. Cada excepción debe quedar en la ficha con la regla y el periodo en que se aplicó.

Registre el resultado como una relación, no como una sustitución. La tabla puede tener una fila para L-03, otra para LINEA_03 y otra para EQ-1187, unidas por un alias provisional. Si después aparece evidencia de que EQ-1187 es una estación y no la línea completa, se corrige la relación sin borrar los valores nativos.

La revisión debe poder repetirse con una consulta documentada. Anote filtros, fecha de extracción y versión del inventario. Si la evidencia se obtuvo en una reunión, solicite el documento o el registro que la persona usó. Una frase como “operaciones lo confirmó” no permite verificar qué se confirmó ni para qué periodo.

Cuando el alias se use en un KPI, copie su versión en la ficha del indicador. Así, un lector puede saber si el valor se calculó antes o después del cambio de identidad. No vuelvas a calcular una serie histórica con el alias nuevo sin declarar la ruptura; la continuidad aparente podría ser una mezcla de activos.

Si el equipo trabaja con proveedores, acuerde qué código se comparte y cuál se conserva internamente. El proveedor puede recibir un alias limitado para resolver una incidencia, pero no debería recibir un inventario completo por comodidad. La relación de identidad y el control de acceso se documentan por separado.

Una correspondencia sólida no necesita una puntuación misteriosa. Necesita criterios visibles: misma entidad, ubicación compatible, periodo sin conflicto, fuente autorizada y revisión de una función responsable. Si uno de esos criterios falta, cambia el estado a provisional o pendiente y conserva la razón.

Evite un alias que oculte cambios

Un alias útil es reversible. Guarda los códigos nativos, la versión, el periodo y la razón. Si la organización cambia la nomenclatura, se añade una relación nueva y se conserva la anterior. El historial permite explicar por qué un informe antiguo no coincide con el actual.

Un alias revisable debe conservar cada código nativo, su periodo de vigencia y la evidencia que permite confirmarlo. Los principios de gobierno de NIST recomiendan mantener decisiones y procedencia, pero no asignan una identidad por sí solos.

La normalización de texto puede ayudar a localizar candidatos, pero no debe decidir por sí sola. Quitar guiones o ceros puede unir códigos diferentes. Use la normalización como filtro de búsqueda y vuelva a los valores originales para confirmar.

El alias tampoco debe utilizarse para resolver una transformación de datos. Si un gateway convierte un tag en una métrica, el linaje debe documentar la fórmula, la unidad y el filtro. La ficha de identidad solo dice qué activo representa el tag y durante qué periodo.

Decisión y siguiente paso

La decisión correcta suele tener tres estados: confirmado, provisional y pendiente. Confirmado exige una fuente autorizada y un alcance escrito. Provisional permite usar el alias para una consulta limitada, pero obliga a mostrar la advertencia. Pendiente significa que los registros permanecen separados.

La salida de identidad debe conservar el código nativo, el alias, el periodo y la evidencia; si falta confirmación, no una los registros. El marco ISA ayuda a ubicar qué sistema puede responder, no a inventar una correspondencia.

La decisión operativa debe ser crear un alias revisable y no unir registros sin confirmación. ISA orienta la relación entre niveles, mientras la autoridad local verifica el activo.

NIST recomienda analizar datos operativos con el contexto suficiente para interpretar una medida. Esa idea se aplica aquí como disciplina: el alias debe permitir repetir la pregunta y encontrar la fuente. No convierte una comparación preliminar en un hecho sobre capacidad, calidad o rendimiento.

Límites de la revisión

Un alias no prueba que dos activos tengan la misma capacidad, estado de seguridad, mantenimiento o consumo. Tampoco demuestra que una interfaz conserve todos los eventos. Para esas preguntas se necesitan contratos y evidencias específicas.

Las referencias internacionales aportan marcos y métodos, pero no sustituyen el inventario español ni las reglas de la planta. La encuesta TIC del INE describe empresas agregadas y no identifica códigos MES, historian o mantenimiento. Su alcance no permite completar una correspondencia local.

Una especificación técnica no garantiza interoperabilidad, seguridad, latencia ni una implementación conforme; exige perfil, pruebas y revisión locales. OPC UA delimita su propia especificación. Si la evidencia no llega, mantenga la hipótesis abierta y programe la comprobación.

Para empezar por la procedencia, consulta mapear fuentes de datos para un informe de producción. Si necesitas seleccionar una autoridad de KPI, revisa identificar la fuente autoritativa para un KPI.

Para comprobar campos y cobertura, consulta revisar calidad de datos antes de la capa de lectura. El hub IT/OT de datos industriales y la guía de acceso a datos IT/OT industriales completan el contexto operativo.

Preguntas frecuentes

¿Qué es un identificador nativo?

Es la clave que el sistema de origen usa para localizar un activo, como un código de equipo, un tag o un identificador de mantenimiento.

¿Puedo sustituir todos los códigos por un alias común?

No. Conserve cada código nativo y use el alias como relación revisable. Sustituirlos puede ocultar cambios, duplicados o activos distintos.

¿Qué evidencia confirma que dos códigos apuntan al mismo activo?

La combinación de ubicación, descripción, historial, ventana operativa y una fuente autorizada. Un nombre parecido por sí solo no basta.

¿Esta revisión crea un linaje de datos?

No. La revisión establece identidad de activo. El linaje documenta transformaciones y recorridos del dato, que requieren otra ficha.

¿Qué hago cuando la correspondencia sigue dudosa?

Mantén los registros separados, marca el alias como pendiente y pide una comprobación a la autoridad de operaciones, mantenimiento o IT/OT.