Cómo mapear un evento operativo entre OT e IT

Un arranque aparece en el controlador a las 06:14, en el historian a las 06:15, en el MES a las 06:17 y en el ERP como una orden liberada a las 06:20. ¿Son cuatro hechos o cuatro vistas de uno? La respuesta no está en el color del cuadro de mando. Hay que conservar el origen, el reloj y el estado de cada representación.

Mapear un evento no significa copiar una fila de un sistema a otro. Significa construir una relación que otra persona pueda repetir. El mapa debe indicar qué registro nació en OT, qué servicio lo transformó, cuándo llegó a IT y qué parte se descartó o quedó pendiente. Si el vínculo no existe, la ausencia se documenta; no se rellena con el evento más cercano.

El método local para mapear un evento entre OT e IT fija un identificador común, una ventana, un estado y una fuente para cada representación. ISA-95 aporta un marco para repartir responsabilidades entre niveles y objetos, pero no prescribe esta ficha ni valida la integración. (ISA-95)

Delimite el evento antes de abrir los sistemas

Empiece con una pregunta que tenga alcance. “¿Por qué el arranque de la línea 2 aparece tarde en el informe de producción del turno A?” permite elegir una ventana y un recurso. “¿Hay problemas de integración?” mezcla demasiados eventos y no ofrece una decisión.

Describa el evento en términos observables: tipo, recurso, orden o lote, inicio esperado, inicio registrado y estado que se quiere explicar. No incluya todavía una causa. Un arranque que se ve tarde puede ser un evento real tardío, un mensaje recibido tarde o una consulta que usa otro huso horario.

La ficha inicial puede contener:

Campo	Pregunta	Ejemplo de valor
Tipo	¿Qué cambio se sigue?	Arranque después de limpieza
Entidad	¿A qué recurso u orden pertenece?	Línea 2, OF-913
Ventana	¿Qué periodo cubre la búsqueda?	06:00–07:00, Europe/Madrid
Estado	¿Qué transición interesa?	Preparada → ejecutando
Decisión	¿Qué se debe resolver?	Aceptar la marca o abrir una investigación

Si un campo no está disponible, anótelo como pendiente. La ficha no es un contrato técnico; es una forma de evitar que el analista cambie de pregunta a mitad del mapa.

Separe cuatro relojes

En una cadena OT-IT suelen convivir la hora del sensor o controlador, la hora en que el historian almacena, la hora en que una interfaz entrega el evento y la hora en que un informe lo consulta. A veces hay una quinta: la fecha de negocio que usa el ERP para agrupar turnos.

Guarde cada una con su zona y precisión. No redondee antes de relacionar. Un registro a las 06:14:59 y otro a las 06:15:01 pueden ser el mismo arranque o dos cambios; la regla local y el identificador deben decidirlo.

Una diferencia de dos minutos no demuestra latencia. Puede deberse a un buffer, a una cola, a un lote de escritura o a la forma en que el informe muestra segundos. Registre la diferencia y pida el log que permita clasificarla.

La ventana debe incluir margen antes y después del evento. Si solo se consulta desde la hora esperada, se puede perder el mensaje que explica por qué la transición llegó tarde. Conserve también los filtros usados: equipo, tag, orden, turno y estado.

Conserve las identidades nativas y una clave de correlación

Un controlador puede usar un tag, el historian un event_id, el MES una actividad y el ERP una orden. No cambie esos identificadores para que parezcan iguales. Cree una clave de correlación separada y mantenga una tabla de relaciones:

Sistema	Identidad nativa	Campo relacionado	Estado	Fuente
OT	Tag y secuencia	Correlación C-2026-0811-07	Ejecutando	Controlador
Historian	event_id	C-2026-0811-07	Almacenado	Historian
MES	Actividad 913-20	C-2026-0811-07	Recibida	Gateway
ERP	Orden OF-913	C-2026-0811-07	Liberada	ERP

La clave C-2026-0811-07 es ilustrativa. Debe generarla el sistema o el procedimiento local, no el analista a posteriori si puede evitarse. Si no existe una correlación automática, indique cómo se estableció y quién la verificó.

Un nombre como “arranque línea 2” no es suficiente. Puede repetirse en varios días, recursos o campañas. Añada fecha de negocio, recurso y secuencia cuando el modelo no tenga una clave global.

Use ISA-95 para repartir preguntas, no para certificar la integración

ISA describe niveles, objetos e intercambios entre control y empresa; usar para mapear responsabilidades, no para afirmar que una integración cumple ISA-95. (resumen oficial de ISA-95) El valor de la referencia está en preguntar quién conserva un objeto y qué intercambio se espera, no en asumir que todos los sistemas tienen el mismo modelo.

El nivel de control puede conocer el estado instantáneo; el MES puede convertir eventos en actividades de fabricación; el ERP puede conservar órdenes y fechas de negocio. La frontera exacta cambia según la arquitectura. Anótela en el mapa.

OPC UA ofrece conceptos de intercambio y modelos de información. Eso no prueba que su gateway conserve la secuencia, que los relojes estén sincronizados o que el mensaje sea completo. Para cada interfaz, documente el perfil, la transformación y la prueba que la planta haya autorizado.

Ordene la revisión para no perder procedencia

En la revisión local del evento, ordene los registros por fecha, entidad, estado, unidad y propietario antes de comparar o explicar la decisión.

ISA-95 ayuda a decidir qué nivel conserva cada objeto, y los principios de gobierno de NIST ayudan a mantener definiciones y procedencia; ninguna fuente sustituye la regla de la planta. (ISA-95; NIST, gobierno de información)

“Entidad” puede ser un tag, una orden o un lote, pero hay que decir qué nivel se eligió. “Propietario” es quien puede aclarar el registro, no el nombre genérico del sistema.

Clasifique cada representación como vinculada, parcial o no comparable. Vinculada significa que la clave y el estado tienen evidencia. Parcial significa que existe una relación probable pero falta un campo, como la hora de recepción. No comparable significa que el periodo, unidad o entidad no permite un cruce responsable.

No use una puntuación de confianza para ocultar la falta de evidencia. Es preferible una etiqueta sencilla con un criterio escrito. La etiqueta puede cambiar cuando aparezca el log, pero conserve la lectura anterior y la fecha del cambio.

Reconstruya el recorrido del dato

Siga el evento desde el origen, sin empezar por el dashboard. Para cada salto, escriba qué campo entró, qué transformación ocurrió y qué salió. Una tabla útil incluye:

1. Origen OT: tag, estado, timestamp y calidad del dato.
2. Almacenamiento: nombre del punto historian, política de retención y marca de escritura.
3. Interfaz: mensaje, cola, reintentos, correlación y hora de recepción.
4. Transformación: conversión de unidad, cambio de estado, agregación o filtrado.
5. Destino MES/ERP: identidad resultante, estado visible y fecha de consulta.

No describa una transformación que no se haya visto en configuración, documentación o prueba. Si el gateway aplica una regla desconocida, escríbala como “transformación pendiente” y detenga la conclusión.

Las conversiones de unidad merecen especial cuidado. Un contador en milisegundos, una duración en segundos y un turno en horas pueden acabar en la misma columna. Guarde la unidad original, el factor y el redondeo. Una cifra equivalente no demuestra que la conversión sea correcta.

Trate estados y calidad como datos

Un evento puede llegar con calidad mala, estado provisional o una marca de sustitución. No lo mezcle con un estado confirmado. La palabra “activo” puede significar que el tag tiene valor, que la orden está liberada o que el mensaje fue aceptado. Consulte el diccionario local.

Registre la transición y no solo el último estado. Para explicar un arranque, la secuencia preparada → ejecutando → detenido puede ser más importante que la fila final. Si un sistema conserva solo el último estado, anote que la historia no está disponible.

La calidad del dato no equivale a la seguridad del proceso. Un tag con buena calidad puede proceder de un sensor mal calibrado. Un mensaje bien transportado puede contener una unidad equivocada. La revisión técnica y la revisión operativa siguen siendo necesarias.

Decida qué representa el mapa

El mapa puede cerrar una pregunta de trazabilidad, pedir una corrección de interfaz o abrir una investigación de proceso. No decide si una parada fue causada por mantenimiento, ni si una orden debe reabrirse. Esa autoridad pertenece a operaciones, mantenimiento, calidad o seguridad según el caso.

La salida local debe acordar un identificador, una ventana, un estado y una fuente para cada representación; si falta evidencia, mantenga la hipótesis abierta. ISA-95 aporta un lenguaje para describir niveles y objetos, pero la autoridad y la comprobación son de la planta. (ISA-95) Añada el propietario de la siguiente comprobación y la fecha de revisión. Si la diferencia afecta a un producto regulado o a una condición de seguridad, aplique el procedimiento específico antes de modificar datos.

Ejemplo: el cambio de receta que parece un arranque nuevo

El controlador registra un cambio de receta a las 14:03. El historian escribe un evento de configuración a las 14:04. El MES crea una actividad de preparación a las 14:04, pero el ERP muestra la orden liberada a las 14:08. Un informe de turno parece indicar dos arranques porque la actividad de preparación no comparte el identificador de la orden.

El mapa conserva los dos identificadores nativos y crea una correlación basada en recurso, secuencia y ventana. La revisión descubre que el MES representa preparación y el ERP liberación. No hay dos arranques; hay dos estados con distinta granularidad. La conclusión se limita a esa orden y periodo. Para generalizar, habría que comprobar otra receta y revisar la regla de correlación.

Si el evento de preparación no tiene hora de recepción, el mapa no puede afirmar que la interfaz tardó cuatro minutos. Marca la evidencia pendiente y pide el log. El total del informe puede mantenerse, pero la explicación no debe atribuir una causa.

Revise las excepciones que rompen una correlación

La clave de correlación puede fallar de maneras previsibles. Un controlador puede reiniciar su contador, un gateway puede reenviar un mensaje y un MES puede crear una actividad manual cuando se pierde la orden original. Trate cada caso como una excepción con su propia evidencia.

Un reinicio de contador no significa que el evento sea nuevo. Guarde el reinicio, la última secuencia conocida y el intervalo en el que la relación puede estar incompleta. Si el gateway reenvía, conserve ambos mensajes y la regla de deduplicación. Si el MES crea una actividad manual, registre quién la creó y qué fuente la respalda.

Los nombres de recurso también pueden cambiar. Un alias de la línea 2 en el historian puede ser L2 y LINEA_02 en el MES. El mapa necesita la tabla de alias con su versión. No sustituya el nombre en los datos originales, porque después no se podrá saber qué vio cada sistema.

Cuando una correlación se establece por proximidad temporal, escriba el umbral y su justificación. Una ventana de treinta segundos puede ser útil para un pulso rápido y demasiado estrecha para una operación que se confirma por lote. La proximidad es una hipótesis hasta que la autoridad del proceso la valide.

La excepción no debe desaparecer del mapa final. Incluya una columna de cobertura y un enlace a la comprobación pendiente. Así, el siguiente turno sabrá qué parte del evento está confirmada y qué parte requiere una consulta adicional.

Antes de presentar el mapa, lea una fila completa en voz alta. Debería poder decir qué ocurrió, dónde se registró, cuándo llegó a cada sistema y quién puede confirmar la relación. Si una fila solo se entiende porque el autor recuerda la arquitectura, todavía no es una evidencia transferible. Haga la misma prueba con una persona de operaciones y otra de IT/OT; sus preguntas suelen descubrir alias o estados que la tabla no explica.

Si la fila se comparte en una reunión, conserve el enlace al registro original y la versión de la consulta. Una corrección posterior debe actualizar el mapa y registrar por qué cambió la relación, no reemplazarla sin explicación.

Ese control evita que el mapa se convierta en una captura aislada sin contexto.

La versión de la ficha y la fecha de revisión deben acompañar al enlace, sobre todo cuando una misma línea cambia de turno.

Proteja el mapa y los datos originales

Los eventos OT pueden revelar identificadores de equipos, horarios y condiciones de proceso. Guarde la ficha en el repositorio autorizado y limite el detalle que se comparte fuera del equipo. No copie credenciales ni cambie la configuración para producir una prueba.

Cuando participe un proveedor, comparta el identificador y la ventana necesarios, no un volcado completo por comodidad. Mantenga el registro de quién recibió el archivo y qué versión se revisó. La trazabilidad también tiene un componente de acceso.

Compruebe otra muestra antes de cerrar

Repita el mapa con un evento de otro turno o recurso. Compruebe si las claves, estados y relojes se comportan igual. Una única correlación puede ser una excepción de la orden o del gateway.

La segunda muestra no convierte el patrón en garantía. Solo revela si la documentación permite que otra persona reproduzca el cruce. Si vuelve a faltar un campo, conviértalo en una acción de observabilidad con propietario y fecha.

Documente el contrato de correspondencia

Cuando el evento cruza una interfaz, escriba qué entra y qué sale antes de abrir el informe. La frase “se sincroniza con MES” no permite revisar nada: indique el campo de origen, el campo de destino, la transformación, la regla temporal y quién puede confirmar el resultado. Esa ficha evita que una relación provisional termine tratándose como una integración completa.

Salto	Qué debe quedar escrito	Prueba mínima
OT → historian	Tag, secuencia, calidad y marca de escritura	Un evento con registro de origen y de almacenamiento
Historian → gateway	Filtro, unidad, zona horaria y política de reintento	Mensaje original y mensaje recibido
Gateway → MES	Clave de correlación, estado y actividad creada	Consulta de la cola y actividad resultante
MES → ERP	Regla de agrupación, orden y fecha de negocio	La misma orden vista en ambos sistemas

Si la interfaz descarta estados o redondea la hora, anote el comportamiento y su versión. No lo esconda detrás de una etiqueta como “normalizado”. Una persona que no conoce la arquitectura debe poder tomar un registro, aplicar la regla y obtener la misma relación. Si no puede hacerlo, la salida es “correspondencia pendiente”, con el log o la configuración que falta.

También conviene fijar qué ocurre cuando llegan dos mensajes para la misma clave. Defina si se conserva el primero, el último o ambos, y quién revisa el duplicado. La decisión puede depender del procedimiento local, pero debe estar escrita junto al mapa. Así se evita interpretar un reintento como un segundo arranque o borrar una excepción que explica la diferencia entre sistemas.

Límites de las referencias

La página resumen ISA no garantiza interoperabilidad, seguridad, latencia ni una implementación conforme; requiere revisión del perfil local y pruebas autorizadas. (ISA-95) La norma completa puede tener un alcance y unas condiciones de acceso distintos de su resumen público. OPC UA tampoco acredita su gateway.

Este método no certifica una arquitectura, no prueba cumplimiento NIS2 y no atribuye causalidad. Las fuentes internacionales aportan contexto; los datos de su planta, sus responsables y sus controles deciden el resultado. Si falta una evidencia esencial, se bloquea la explicación, no se rellena.

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

Preguntas frecuentes

¿Qué se considera un evento operativo?

Es un hecho con un inicio, un cambio o un estado que interesa seguir, como un arranque, una parada o una modificación de receta. La definición concreta depende del proceso y del sistema que lo registra.

¿Debo usar el mismo identificador en OT, MES y ERP?

No siempre es posible. Puede conservar una clave de correlación y, junto a ella, el identificador nativo de cada sistema. Lo importante es documentar la relación y no sustituir una clave por un nombre ambiguo.

¿Cómo se comparan relojes distintos?

Guarde la hora del evento, la hora de recepción y la hora de consulta, con zona horaria y precisión. Aplique una regla local para la fecha de negocio y conserve el valor original.

¿Un evento ausente en MES demuestra un fallo OT?

No por sí solo. Puede existir un filtro, una cola de interfaz o una diferencia de granularidad. Revise la cobertura y los logs antes de atribuir una causa.

¿Qué evidencia debe acompañar al mapa?

El identificador de correlación, las fuentes, las transformaciones, los estados, las ventanas, los responsables, las excepciones de reloj y la comprobación posterior sobre otra muestra.