El comité abre un informe a las 10:00. La última fila lleva una marca de las 09:58 y se interpreta como estado actual de la línea. Más tarde aparece otra marca: el fichero que contenía esa fila se cargó a las 06:00, y las 09:58 pertenecen al momento en que se regeneró la vista. La cifra puede ser válida para el cierre anterior, pero no para decidir qué ocurre ahora.

Para distinguir una integración por evento de una integración por lotes, siga un registro completo y separe ocurrencia, captura, publicación y disponibilidad. Identifique después qué dispara el envío, cuántos registros agrupa, cómo se ordenan, qué sucede en un reintento y cuándo el consumidor los incorpora. El patrón de transporte no autoriza a llamar “actual” al dato: cada uso necesita una frescura permitida y una prueba local.

OPC UA define un EventNotifier como un atributo que indica que un cliente puede suscribirse a un nodo para recibir notificaciones de eventos. La referencia oficial de OPC UA Part 1 respalda ese mecanismo general. No prueba que una integración local esté suscrita, entregue cada evento, conserve el orden o cumpla una latencia.

Empiece por identificar la fuente autoritativa del KPI y mapear las fuentes del informe de producción. Así podrá ubicar productor y consumidor sin confundir el sistema que entrega con el que gobierna el significado. La guía de acceso a datos IT/OT industriales separa permisos de autoridad. Antes de publicar una etiqueta de actualidad, revise la calidad del dato en la capa de lectura.

Evento, lote y consulta son preguntas distintas

Un evento es una ocurrencia que el sistema decide representar y notificar. Una carga por lotes reúne varios registros y los procesa en una ejecución. Una consulta bajo demanda lee un estado cuando alguien o alguna aplicación la solicita. Los tres patrones pueden coexistir en el mismo recorrido.

Una máquina puede generar un evento de fin de ciclo. Un gateway puede acumular esos eventos durante un minuto. Un proceso puede enviarlos cada cinco minutos y un almacén puede incorporarlos cada hora. Llamar “integración por eventos” a todo el recorrido describe el origen, pero oculta la agrupación posterior.

También ocurre lo contrario. Un fichero horario puede contener eventos individuales con identificador y tiempo de ocurrencia. La entrega es por lote, aunque el contenido conserve semántica de evento. La decisión debe precisar qué capa se está describiendo: generación, transporte, ingestión, transformación o exposición.

“Sincrónica” tampoco significa “rápida”. Una petición que espera una respuesta puede tardar. Una suscripción asíncrona puede entregar en segundos o acumular mensajes. Para el comité, interesa el tiempo extremo a extremo y el corte que representa, no la etiqueta arquitectónica aislada.

La unidad de análisis es una entrega observable

Elija un identificador que pueda seguirse: evento, orden, lote técnico o registro de cambio. Capture su identidad en cada salto. Si un paso sustituye el identificador, guarde la relación entre el original y el nuevo. Sin esa relación, dos marcas de tiempo parecidas no demuestran que se trate del mismo dato.

Anote productor, canal, consumidor y uso. El productor puede ser PLC, servidor, MES o una aplicación. El canal puede ser una suscripción, una cola, un fichero o una API. El consumidor puede guardar, transformar o mostrar. El uso decide qué retraso resulta tolerable.

Pruebe al menos un caso normal, uno tardío y uno repetido. Un recorrido perfecto solo demuestra el camino feliz. Los reintentos y cierres parciales revelan si el consumidor sustituye, duplica, descarta o deja pendiente.

Conserve los logs sin reinterpretarlos. Una marca de “procesado” puede pertenecer al inicio o al final de una tarea. El diccionario local debe aclararlo. Si no puede confirmar la semántica, etiquete la marca como desconocida y no la use para calcular latencia.

Cuatro relojes evitan una falsa actualidad

La marca de ocurrencia indica cuándo sucedió el hecho operativo. La de captura, cuándo lo registró el productor o el primer sistema. La de publicación, cuándo se puso a disposición del canal. La de disponibilidad, cuándo el consumidor pudo usarlo en la vista o decisión.

No siempre están las cuatro. Esa ausencia es parte del diagnóstico. Si solo existe disponibilidad, se puede medir cuándo apareció, pero no cuánto tardó desde la operación. Si solo existe ocurrencia, no se sabe cuándo llegó. Complete el recorrido con evidencia antes de atribuir la brecha a una capa.

Normalice zona horaria, precisión y referencia. Un timestamp local sin offset puede repetirse en un cambio horario. Un sistema puede registrar segundos y otro milisegundos. Otro puede usar el tiempo del dispositivo, no el servidor. Documente la conversión y conserve los originales.

OPC UA explica que un elemento monitorizado puede tomar muestras más rápido que la frecuencia de publicación de la suscripción y configurarse para encolar todas las notificaciones o solo la última. La especificación oficial permite distinguir muestreo, publicación y cola. No demuestra cuál de esas opciones usa una instalación ni que la cola esté completa.

El retraso tiene componentes

Separe captura, espera, transporte, ingestión, transformación y refresco de vista. Una única resta entre ocurrencia y pantalla ofrece el total, pero no señala dónde actuar. Si falta una marca intermedia, mantenga ese tramo agregado en vez de repartirlo por intuición.

Informe percentiles o bandas solo cuando la muestra y el periodo sean comparables. Una media puede ocultar cargas que llegan después del corte. Mantenga máximo, casos fuera de ventana y población excluida. Explique además qué ocurre durante mantenimiento o pérdida de conectividad.

No transforme retraso en frescura sin una regla. Un dato puede llegar rápido y pertenecer a una observación antigua. Otro puede llegar tarde y seguir siendo válido para un cierre mensual. La frescura combina edad del hecho, momento de disponibilidad y uso previsto.

Defina la etiqueta visible. “Actualizado a las 10:00” puede significar vista regenerada, última carga recibida o último evento ocurrido. Use texto específico: “último evento ocurrido a las 09:42; disponible a las 09:47; corte 09:45”.

Señales de una entrega activada por evento

Busque un disparador identificable y una relación entre la ocurrencia y el mensaje. El registro debería conservar un identificador de evento o una clave equivalente, el tiempo de origen, el tipo, la entidad y un estado. El canal debería mostrar publicación o entrega asociada.

Una suscripción no basta como prueba de cobertura completa. Revise filtros, tasa de muestreo, tamaño de cola, política cuando se llena, nueva conexión y retención. Si el cliente recibe solo el último valor, varios cambios intermedios pueden desaparecer sin que exista un fallo del protocolo.

Compruebe el orden. Puede estar definido por secuencia, tiempo de origen, tiempo de recepción o una regla del consumidor. Dos sistemas con relojes desalineados pueden invertir eventos si se ordena por timestamp. Los reintentos también pueden hacer que un mensaje anterior llegue después.

La referencia de OPC UA describe números de secuencia en mensajes de notificación y mecanismos con los que un cliente puede detectar mensajes perdidos y solicitar reenvíos. OPC UA Part 1 aporta esa mecánica. No acredita que un servidor conserve el mensaje, que el cliente recupere todo ni que la prueba local pase.

No convierta el evento en una promesa de entrega inmediata

Defina una ventana de entrega por uso. Una alarma puede requerir segundos; un parte de turno puede aceptar minutos; un cierre diario quizá tolere horas. Son ejemplos de diseño, no umbrales universales. La autoridad operativa debe aprobar la regla y sus excepciones.

Mida desde la ocurrencia, no desde el inicio de la consulta. Si el productor asigna el timestamp al final de una operación, la ventana debe entender esa semántica. No compare eventos con definiciones temporales distintas bajo un mismo indicador.

Incluya eventos que no llegaron y entregas sin origen. El denominador necesita una fuente independiente o una prueba controlada. Si solo se observan los mensajes recibidos, no se puede afirmar completitud.

Pruebe reinicio, desconexión y saturación en un entorno autorizado. Documente lo que sucede con la cola y la recuperación. Una guía documental no autoriza a alterar producción; el responsable técnico define dónde y cuándo probar.

La huella de una carga por lotes

Un lote técnico suele tener un disparador de tiempo, volumen, cierre o disponibilidad de fichero. Registre identificador de ejecución, ventana cubierta, inicio, fin, estado, recuentos de entrada y salida, versión de transformación y corte de publicación.

No confunda el lote técnico con un lote de fabricación. Pueden compartir nombre, pero representan entidades distintas. Use términos separados y mantenga una relación entre ellos solo cuando exista una correspondencia explícita.

Compruebe si la ventana es cerrada o deslizante. Una carga de 08:00 a 09:00 puede reabrirse por llegadas tardías o quedar inmutable. El consumidor necesita saber si un periodo “cerrado” puede cambiar y cómo se publica la corrección.

Registre solapes. Dos ejecuciones pueden incluir el mismo intervalo para recuperar datos tardíos. Eso puede ser correcto si existe una clave de idempotencia o una regla de sustitución. Sin ella, el reintento puede duplicar filas.

Reconciliar antes de publicar

Compare registros esperados, leídos, aceptados, rechazados y pendientes. No siempre existe un total esperado independiente. En ese caso, publique la limitación y use controles de continuidad, claves o muestras, sin afirmar completitud.

Conserve el manifiesto del lote: origen, archivos u objetos, checksum cuando proceda, intervalo, filtros, versión y resultado. Una captura del mensaje “correcto” no permite reconstruir qué registros entraron.

Trate los rechazos por separado. Un lote puede terminar técnicamente y dejar registros fuera por esquema, estado o unidad. “Ejecución completada” no equivale a población completa para el informe.

Cuando una corrección reprocese el periodo, mantenga versión anterior, nueva y delta. La vista debe indicar cuál rige. No sobrescriba la carga original si sostuvo una decisión que luego debe explicarse.

El contrato de uso une frecuencia y decisión

La documentación técnica dice cómo viaja el dato. El contrato de uso explica para qué puede emplearse. Incluya entidad, medida, corte, frescura máxima, cobertura mínima, tratamiento de pendientes, autoridad y acción cuando el contrato no se cumple.

Un mismo dato puede tener varios usos. La planificación durante el día puede exigir una ventana corta y distinguir pendientes. El análisis mensual puede aceptar correcciones posteriores. No duplique la fuente; documente reglas de uso separadas.

No rellene silenciosamente una carga ausente con el último valor. Si el arrastre está aprobado, muestre la edad y el estado “estimado” o equivalente. Si puede alterar una decisión material, calcule una banda o bloquee la conclusión.

La decisión práctica es identificar frecuencia, evento, retraso y uso permitido, y dejar una siguiente comprobación. Ese criterio es síntesis editorial que debe validarse con registros de la planta. OPC UA no fija la frescura del comité, y ENISA no convierte esa regla operativa en conformidad.

La tabla de decisión cabe en una pantalla

Para cada uso, muestre último hecho ocurrido, última entrega disponible, edad, patrón observado, cobertura, estado y decisión permitida. Añada un enlace al recorrido técnico, no todos los logs en la vista ejecutiva.

Defina salidas sencillas: utilizable, utilizable con condición, pendiente y bloqueado. No promedie frescura y completitud en un índice. Un dato muy reciente pero incompleto puede ser inadecuado; uno más antiguo y cerrado puede servir para otra pregunta.

El propietario del uso decide si la ventana satisface la necesidad. El propietario técnico confirma lo observado en la integración. Si los roles discrepan, conserve ambas posiciones y eleve la decisión; no haga que el dashboard elija.

Revise la regla cuando cambie frecuencia, cola, consumidor, transformación o corte operativo. Una prueba superada antes de una migración no valida el recorrido posterior.

Seguridad y cambio, con el alcance correcto

La guía técnica de ENISA aporta consejos prácticos, ejemplos de evidencias y mapeos para requisitos de ciberseguridad dirigidos a determinados tipos de entidades bajo el reglamento de ejecución relacionado con NIS2. La publicación de ENISA puede orientar controles de cambio y evidencia cuando resulte aplicable. No certifica la integración ni valida evento, lote, sincronización o latencia.

Una modificación de frecuencia o cola puede afectar disponibilidad, capacidad, registros y recuperación. Trátela como cambio controlado: alcance, versión, responsable, prueba, rollback y aprobación. Esa recomendación debe adaptarse al gobierno local y no implica que la guía de ENISA sea ley española o una norma OT de fabricación.

No publique endpoints, credenciales, configuraciones sensibles o detalles explotables en el informe. La evidencia puede conservarse con acceso restringido mientras la vista ejecutiva muestra resultado, versión y autoridad. El acceso de lectura no debe ampliar permisos operativos.

La guía de ENISA citada se dirige a entidades de infraestructura digital, gestión de servicios TIC y proveedores digitales cubiertos por su marco. ENISA delimita ese ámbito. No se debe inferir que una planta industrial entra automáticamente en ese alcance ni presentar la guía como prueba de conformidad NIS2.

Qué no puede concluir esta revisión

El uso de OPC UA no demuestra integración local, sincronización, latencia, completitud, conformidad, seguridad o rendimiento. La referencia describe mecanismos y conceptos. El perfil, la configuración, los componentes y las pruebas determinan el comportamiento observado.

Una guía de ciberseguridad no prueba que la cola esté completa ni que el orden sea correcto. Sirve para revisar riesgos y evidencias dentro de su ámbito. Mantenga separadas las pruebas funcionales, de rendimiento, de recuperación y de seguridad.

No llame “NIS2 compliant” a un recorrido por haber usado una lista de comprobación. El alcance jurídico y sectorial requiere análisis competente, transposición nacional y evidencia específica. Esta página no ofrece asesoramiento jurídico.

Si faltan logs o tiempos, la conclusión correcta puede ser “patrón no demostrado”. Mantenga la hipótesis abierta, defina una captura acotada y no trate el último valor visible como actual.

Entrega y siguiente prueba

Prepare una ficha del recorrido con diagrama, identificadores, cuatro tiempos, disparadores, frecuencias, colas, reintentos, transformaciones, cortes y usos. Añada tres ejemplos completos: normal, tardío y repetido o perdido. Cada ejemplo debe volver a la evidencia original.

Incluya la versión oficial de la especificación consultada y las configuraciones locales, sin confundirlas. OPC UA Part 1 versión 1.05.06, publicada por OPC Foundation el 22 de octubre de 2025, describe el marco usado aquí; no identifica el perfil ni la implementación de la planta.

Registre una decisión por uso. “Apto para cierre diario con periodo cerrado a las 06:00” es más defendible que “datos en tiempo real”. Añada qué ocurre si la entrega llega tarde y quién puede autorizar una excepción.

Vuelva a mapear las fuentes del informe de producción si el recorrido pierde identidad o una marca temporal. El siguiente paso es capturar un registro durante un ciclo normal y otro durante un reintento antes de etiquetar la integración.

Preguntas frecuentes

¿Un dato enviado por evento siempre está en tiempo real?

No. Puede esperar en una cola, agruparse, pasar por reintentos o transformarse antes de llegar. Mida el recorrido completo con marcas de ocurrencia, captura, publicación y disponibilidad, y defina la frescura que admite el uso.

¿Cada cuánto debe ejecutarse una carga por lotes?

No existe una frecuencia universal. Debe derivarse del uso, del corte operativo, del volumen, de la recuperación ante fallos y del coste de cambio. Un informe diario y una alarma de turno no aceptan la misma ventana.

¿OPC UA demuestra que mi integración no pierde eventos?

No. La especificación describe mecanismos de eventos, suscripciones, colas y recuperación, pero la cobertura depende del perfil, la configuración, la implementación y las pruebas locales de extremo a extremo.

¿Puedo completar un lote tardío con el último valor conocido?

Solo si el uso tiene una regla aprobada que conserva origen, edad y estado del valor. No presente el arrastre como observación actual. Si puede cambiar una decisión, manténgalo separado o bloquee el resultado.

¿La guía de ENISA convierte esta revisión en una comprobación NIS2?

No. La guía citada se dirige a entidades concretas de infraestructura digital, gestión de servicios TIC y proveedores digitales. Puede orientar evidencias de seguridad y cambio cuando resulte pertinente, pero no determina por sí sola el alcance NIS2 de una planta ni acredita cumplimiento.