Cómo documentar el linaje de una señal OT para un KPI

Un KPI puede mostrar dos decimales y seguir sin tener una procedencia que se pueda explicar. Detrás de una cifra puede haber un tag de PLC, un gateway, una política de retención del historian, una conversión de unidad y una consulta que descarta estados de mala calidad. Si nadie puede señalar esos pasos, la discusión termina girando alrededor del número en vez de alrededor de la señal.

Documentar el linaje no consiste en dibujar flechas bonitas. Consiste en escribir qué entró, qué se transformó y quién puede responder por cada salto. El objetivo es que otra persona reproduzca el valor para una ventana concreta y conozca los casos en que no se debe usar.

El método local para documentar el linaje de una señal OT registra origen, transformación, propietario y comprobación antes de leer el KPI. OPC UA describe mecanismos de interoperabilidad, pero no dicta esta ficha ni concede autoridad al dato. (OPC UA Part 1) La evidencia local debe demostrar cada salto.

Empiece por el uso del KPI

Antes de buscar el tag, escriba qué decisión alimenta el KPI. “Comparar la intensidad de dos líneas durante el turno A” requiere una señal y una unidad distintas de “detectar una parada de más de diez minutos”. El mismo contador puede ser válido para una decisión y no para otra.

Defina la población, el periodo y los filtros. Anote si el KPI incluye muestras de arranque, limpieza, mantenimiento o solo producción estable. Una consulta sin esas condiciones produce un valor que parece universal, aunque responda a una pregunta muy concreta.

La ficha inicial debe incluir:

Campo	Pregunta	Por qué importa
KPI	¿Qué decisión informa?	Evita documentar una señal sin propósito
Ventana	¿Qué inicio y fin se usan?	Separa fecha de evento y fecha de consulta
Unidad	¿Qué se mide y cómo?	Impide comparar segundos con horas o kg con piezas
Estado	¿Qué muestras entran?	Hace visibles valores provisional o malos
Propietario	¿Quién responde?	Permite validar la regla y sus límites

No empiece por el dashboard. El dashboard puede ocultar alias y filtros. El linaje debe comenzar en la fuente original.

Identifique el origen con precisión

El origen puede ser un sensor, un contador de controlador, un registro manual o una señal calculada dentro de OT. Guarde el identificador nativo, el equipo, la ubicación lógica, la frecuencia y la unidad. Un nombre como Speed_Linea2 no dice si la velocidad es instantánea, promedio o el resultado de un bloque de control.

Pregunte dónde se genera el valor. Si el PLC ya aplica un filtro, la señal que llega al historian no es la lectura cruda. Si el gateway hace una conversión, el origen conceptual puede ser el sensor y el origen técnico el gateway. Escriba ambos y la diferencia.

La calidad de la señal también es un campo de origen. Marque si el controlador la considera válida, sustituida, fuera de rango o en mantenimiento. Un valor numérico sin estado no permite saber si entró durante una prueba.

Siga cada salto hasta el KPI

Construya una tabla de nodos, no una lista de productos:

Paso	Entrada	Transformación	Salida	Evidencia
1. Sensor/PLC	Lectura y estado	Filtro local documentado	Tag de proceso	Configuración OT
2. Gateway	Tag y timestamp	Mapeo de nombre	Mensaje	Perfil de interfaz
3. Historian	Mensaje	Retención y compresión	Serie temporal	Punto y política
4. Capa de cálculo	Serie	Conversión y agregación	Métrica intermedia	Consulta versionada
5. KPI	Métrica	Filtros de negocio	Valor visible	Dashboard e informe

Cada fila debe tener un propietario y una fecha de revisión. Si el paso es desconocido, use “pendiente”. No rellene una transformación por intuición porque la cifra final parezca razonable.

Conserve la identidad y la versión de la transformación

Una señal puede conservar el mismo nombre mientras cambia su fórmula. Guarde la versión de la consulta, del mapeo y de la regla de calidad. Si una herramienta no versiona, conserve un hash del archivo o una referencia a la revisión autorizada y explique que es un control técnico.

Las conversiones de unidad deben mostrar el valor original, el factor, la precisión y el redondeo. Por ejemplo, si un contador registra milisegundos y el KPI presenta minutos, conserve la división y la decisión sobre decimales. Un redondeo temprano puede cambiar la lectura de una parada corta.

Las agregaciones necesitan su propia definición. “Promedio horario” puede significar promedio de muestras válidas o total dividido por horas del calendario. Ambas cifras pueden parecer similares, pero no responden a lo mismo. Escriba la fórmula y los valores excluidos.

Use ISA-95 y OPC UA como contexto técnico

ISA-95 ayuda a hablar de niveles, objetos y actividades entre control, operaciones y negocio. La referencia ISA-95 sirve para ubicar responsabilidades y objetos; no prueba que un linaje concreto esté completo. (ISA-95) La planta debe mapear su arquitectura real.

OPC UA describe modelos, mensajes y comunicación. OPC UA especifica modelos de información, mensajes, comunicación y conformidad para interoperabilidad; no prueba calidad ni latencia de una instalación. (OPC UA Part 1) El perfil elegido y las pruebas locales determinan si su señal llega con la cobertura que el KPI necesita.

No confunda interoperabilidad con semántica. Un mensaje puede llegar correctamente y seguir sin aclarar si Run significa ejecutando, preparado o una autorización. La definición de estado pertenece al proceso y al diccionario de la planta.

Ordene la revisión del linaje

En la revisión local del linaje, ordene los registros por fecha, entidad, estado, unidad y propietario antes de comparar o explicar la decisión. NIST aporta principios de gobierno de información y OPC UA describe interoperabilidad; ninguna fuente sustituye la definición ni la comprobación de la planta. (NIST, gobierno de información; OPC UA Part 1) La entidad puede ser un tag, una serie, una consulta o un KPI. El propietario debe poder abrir la evidencia del salto.

Ordene primero por ventana y origen. Después, por estado y unidad. Solo al final compare el número visible. Esta secuencia evita que la diferencia final oculte una señal que dejó de recibirse a mitad del turno.

Clasifique los saltos en confirmados, parciales y no comparables. Un salto parcial puede tener fuente y destino, pero no la regla de compresión. Un salto no comparable puede mezclar muestras de distintas unidades. Conserve la categoría en el ledger del KPI.

Pruebe con un intervalo conocido

Elija una ventana en la que el equipo conozca el comportamiento: un arranque documentado, una orden cerrada o un mantenimiento con marcas autorizadas. Compare el valor original con cada salida del mapa y anote qué pasos reducen la cobertura.

La prueba no necesita un resultado perfecto. Necesita una diferencia explicable. Si el historian entrega menos muestras por compresión, el KPI debe reflejarlo o declarar la limitación. Si el valor cambia por una conversión, compruebe el factor con un caso sencillo.

Repita la prueba en otra ventana. Una transformación que funciona en régimen puede fallar durante arranque o cambio de receta. Si el KPI excluye esos estados, la exclusión debe estar escrita y visible.

Mantenga separados linaje y permisos

Un mapa de linaje no habilita el acceso a un tag. Los permisos responden a quién puede consultar o modificar; el linaje responde a qué significa el dato. Puede compartir una ficha de procedencia sin entregar valores productivos si el control de acceso lo exige.

Registre el propietario de cada salto, no la cuenta técnica que ejecuta una tarea. La cuenta puede ser la misma para varias transformaciones y no conocer la definición de negocio. Cuando el dato salga de OT, anote quién valida su uso en IT.

Decida qué hacer con un hueco

Un hueco puede requerir recuperar la configuración, conservar el KPI como provisional, crear una prueba o bloquear su uso para una decisión concreta. No lo convierta en una orden de cambiar el PLC ni de rehacer la historia.

La salida local debe registrar origen, transformación, propietario y comprobación de la señal antes de leer el KPI; si falta evidencia, mantenga la hipótesis abierta. NIST aporta contexto sobre gobierno de información, pero la autoridad para cerrar el hueco es local. (NIST, gobierno de información) Añada la fecha de la próxima revisión y la autoridad que puede cerrar el hueco.

Si el KPI afecta a seguridad, calidad, producto regulado o compromiso contractual, la función competente decide si se puede usar mientras el linaje está incompleto. La página no sustituye esa aprobación.

Ejemplo: un caudal con dos escalas

Un PLC registra caudal en litros por minuto. El historian guarda la señal cada cinco segundos. Una consulta de turno convierte a litros por hora y calcula un promedio de muestras válidas. El dashboard redondea a un decimal. Durante una limpieza, el estado pasa a “mantenimiento”, pero la consulta solo filtra por valor nulo.

El linaje conserva el factor 60, el intervalo de cinco segundos, el filtro de estado y el redondeo. La revisión descubre que durante la limpieza el PLC sigue enviando valores, por lo que el promedio incluye un flujo que no pertenece a producción. El KPI no se corrige a mano; se abre una decisión sobre el estado que debe excluirse y se repite la prueba.

El ejemplo no fija una regla para todas las fábricas. Muestra por qué la unidad y el estado deben formar parte del linaje, igual que la fórmula.

Mantenga un catálogo de evidencias

El linaje suele fallar cuando solo se documenta la última consulta. Para cada salto, guarde una evidencia que otra persona pueda abrir: configuración del tag, definición del punto historian, contrato del mensaje, versión de la transformación, consulta del KPI o acta de validación. Anote la fecha de captura y el propietario. Si la evidencia vive en un sistema con retención corta, conserve una referencia autorizada y su hash.

Una ficha de evidencia puede usar estas columnas:

Salto	Evidencia mínima	Comprobación
Origen OT	Tag, unidad, estado y configuración	Comparar con un valor conocido
Gateway	Mapeo de nombre y mensaje	Revisar la clave y los reintentos
Historian	Punto, frecuencia y política de retención	Medir cobertura de la ventana
Transformación	Fórmula, factor y versión	Ejecutar un caso de prueba
KPI	Consulta, filtro y propietario	Repetir el resultado

No confunda una captura de pantalla con la definición. La captura muestra cómo se veía la interfaz en un momento; la configuración y la consulta explican por qué el valor se calculó así. Conserve ambas cuando sean necesarias.

Los cambios de configuración requieren una relación temporal. Si una fórmula cambió el 11 de agosto, indique desde qué ventana se aplica y qué KPI anteriores siguen usando la versión vieja. Un informe mensual que mezcle versiones debe declarar el corte. No reescriba el histórico para que todos parezcan calculados con la regla actual.

También conviene registrar las ausencias. Un tag que no se puede consultar, una consulta que no tiene propietario o una política de retención desconocida son huecos del linaje. Marque el hueco y asigne una acción; no lo sustituya con el nombre del dashboard.

Un catálogo pequeño es más sostenible que un diagrama que nadie actualiza. Defina qué cambios obligan a revisar el linaje: alta de un tag, cambio de unidad, modificación de la consulta, nueva política de retención o cambio de propietario. Para cada cambio, anote la ventana a partir de la cual el KPI usa la nueva versión. Así se puede explicar una diferencia histórica sin volver a reconstruir toda la arquitectura.

El propietario confirma el cambio, pero la persona que consume el KPI debe comprobar que la decisión sigue siendo válida.

Detecte transformaciones silenciosas

Algunas capas cambian el dato sin mostrarlo en el nombre. Un historian puede comprimir puntos, un gateway puede redondear y una consulta puede rellenar un valor nulo con el último dato válido. Busque estas reglas en configuración y documentación. Si no se pueden recuperar, el KPI queda condicionado.

Una regla de relleno merece especial cuidado. El último valor conocido puede mantener un gráfico estable mientras el equipo está detenido. Si el KPI usa esa serie para medir producción, el resultado puede parecer mejor de lo que la cobertura permite. La guía no dice que la regla sea incorrecta; exige declarar dónde se aplica y qué decisión puede soportar.

La frecuencia también es semántica. Una muestra cada cinco segundos puede perder un pulso de un segundo. Una agregación por minuto puede ocultar dos arranques. El linaje debe indicar la resolución original y la resolución que llega al KPI. Si la resolución no basta para la decisión, se solicita otra fuente o se limita el uso.

Finalmente, revise la calidad asociada. Un estado “sustituido” no se trata igual que “válido”. Un valor fuera de rango puede ser un evento de calibración o una condición real. El propietario de la señal y el propietario del KPI deben acordar cómo se clasifican esos casos.

Cuide retención y privacidad

La política de retención puede eliminar valores crudos antes de que alguien revise un KPI mensual. Registre cuánto tiempo se conservan y qué agregados sobreviven. Si el dato no se puede recuperar, escriba la limitación y no prometa una auditoría que no es posible.

No incluya credenciales, nombres personales o información de cliente en una ficha compartida. Use identificadores internos y un repositorio con acceso controlado. Un linaje útil también protege el dato que describe.

Compruebe la reproducibilidad

Pida a otra persona que ejecute la consulta con la misma versión, ventana y filtros. Si obtiene otro valor, compare el origen y el estado antes de corregir. La diferencia puede venir de una actualización del dashboard o de una consulta no versionada.

NIST relaciona gobierno de información con usos consistentes, repetibles y confiables. El enfoque no crea una certificación automática: exige que la organización defina propietarios y controles que pueda mantener.

Límites de las referencias

Una especificación o protocolo no es diseño de planta ni garantía de seguridad; requiere perfil, implementación y pruebas de conformidad locales. (OPC UA Part 1) La referencia técnica no certifica su sensor, historian, consulta ni KPI.

Esta guía tampoco decide la fuente autoritativa de todos los indicadores, ni sustituye permisos, validación de calidad o controles de seguridad. Si un salto no se puede demostrar, el KPI debe llevar el límite y la decisión pendiente.

Para partir del contexto de integración, consulte cómo mapear fuentes de datos para un informe de producción. Para elegir una fuente autoritativa, revise identificar la fuente autoritativa para un KPI. Si necesita revisar calidad antes de publicar, consulte revisar calidad de datos antes de la capa de lectura. La guía de acceso a datos IT/OT ayuda a separar linaje y permisos.

Preguntas frecuentes

¿Qué datos componen el linaje de una señal OT?

Como mínimo, origen, identificador nativo, punto de almacenamiento, transformaciones, unidad, frecuencia, estados de calidad, propietario y destino que usa el KPI.

¿Linaje y permisos de lectura son lo mismo?

No. El linaje explica la procedencia y las transformaciones; los permisos determinan quién puede consultar o modificar datos. Mantenga ambos controles separados.

¿Cómo valido una transformación de unidad?

Conserve la unidad original, el factor y el redondeo, y pruebe el resultado con un intervalo conocido. Documente quién revisó la regla y cuándo.

¿Qué hago si el historian pierde muestras?

Registre la política de retención y la cobertura real. El KPI debe mostrar el hueco o quedar pendiente; no interpole sin una regla aprobada.

¿Cuándo puedo considerar fiable el linaje?

Cuando cada salto tiene una fuente identificada, la transformación está versionada, el propietario la revisó y una muestra reproducible produce el mismo resultado dentro de sus límites.