Acuerda qué significa un evento de fábrica antes de que otro equipo lo use

Acuerda el significado y las responsabilidades además del esquema

Open Data Contract Standard, u ODCS, describe un acuerdo entre productores y consumidores de datos. Su versión 3.2.0 incluye esquema, información de calidad de datos, equipos, funciones, soporte y expectativas de servicio. Esos apartados ayudan a registrar más que una lista de tipos de campos.

Para un evento de fábrica, el responsable de operaciones explica la medición y su uso permitido. El responsable del productor mantiene la correspondencia con el origen. El responsable del consumidor registra qué cálculos dependen del registro. También acuerdan quién revisa un cambio, quién investiga una comprobación fallida y cuándo se escala un asunto pendiente.

La hoja registra el acuerdo del ejemplo y las comprobaciones esperadas. No es un documento ODCS completo, una codificación OPC UA ni un servicio de control en producción. No autoriza acciones de control ni de seguridad.

Qué puedes comprobar con el registro del contador

El consumidor conserva por separado las horas de origen y llegada. La definición de DataValue de OPC UA distingue la marca temporal de origen de la del servidor; el registro de llegada de una aplicación es otra observación declarada. Una aplicación receptora no debe sustituir una hora de origen ausente por la de llegada y presentarla sin advertencia como si fuera la original.

El ejemplo existente omite la fecha y un límite acordado de antigüedad admisible. El comprobador solo puede calcular cinco segundos bajo el supuesto explícito de que ambas horas pertenecen al mismo día UTC. Deja en espera el uso posterior hasta que se acuerde la regla de antigüedad que falta. Estos valores no permiten validar la exactitud de los relojes, un intervalo que cruce la medianoche ni una obligación real de servicio.

Un acuse de transporte no determina el significado del evento

El consumidor comprueba la identidad en la aplicación antes de añadir un registro a un cálculo analítico. OASIS MQTT permite duplicados con entrega al menos una vez y distingue el indicador DUP del paquete de la repetición de un mensaje de aplicación. Por tanto, el identificador de un paquete de transporte no sustituye la identidad del evento que necesita la aplicación.

En el ejemplo existente del contador, recibir el mismo registro dos veces no añade otras 412 unidades. Un valor acumulado posterior de 413 indica una unidad aceptada adicional solo si continúa la misma secuencia del contador sin reinicio ni desbordamiento. Conserva esa condición en vez de suponer que todo recuento menor es un incremento negativo normal.

El comprobador informa del duplicado por separado y añade cero unidades nuevas por él. Deja desconocido el incremento de producción de una primera lectura: un total sin un total previo válido no permite determinar la producción de un intervalo. Los reinicios y desbordamientos del contador necesitan reglas propias declaradas antes de que el consumidor calcule una diferencia.

Ver tambiénCalidad de datos de planta

Trata un cambio de significado como un acuerdo nuevo

Un productor puede conservar un campo entero y aun así invalidar el cálculo del consumidor si cambia su significado de recuento acumulado de unidades aceptadas a incremento o recuento bruto. Renombrar un campo es más fácil de detectar que ese cambio silencioso. Asigna versiones a la definición semántica además de a la sintaxis.

El comprobador didáctico admite la versión de esquema 1, la unidad units, el significado de accepted-count acumulado y la identidad de origen declarada. Sus pruebas eliminan una unidad obligatoria, cambian la versión del esquema y alteran el indicador de acumulación. Son modificaciones deliberadas del ejemplo existente para probar el software, no incidentes observados en una fábrica.

Antes de publicar un cambio, ambos responsables comparan los registros anteriores y propuestos frente a los consumidores que dependen de ellos. Deciden si el consumidor existente conserva el mismo significado, necesita un adaptador explícito o debe rechazar la versión nueva. Conserva con el acuerdo la aprobación del cambio, su momento de entrada en vigor y la decisión sobre reversión.

1. Registra el cambio que propone el productor

   El responsable del productor aporta el significado, las unidades, la identidad y el comportamiento temporal anteriores y propuestos.

2. Comprueba los consumidores afectados

   Cada responsable del consumidor identifica el cálculo, el supuesto y la versión admitida a los que afecta el cambio.

3. Ejecuta las pruebas de aceptación

   El revisor comprueba registros conocidos, duplicados, campos ausentes, cambios de versión y límites temporales declarados.

4. Aprueba la transición y la respuesta

   Los responsables registran la versión que entra en vigor, la vía para excepciones y la decisión de reversión o cuarentena.

Rechazar, poner en cuarentena y dejar en espera son resultados distintos

El equipo receptor conserva el registro original y el motivo cuando falla la validación. Una vía de cuarentena lo excluye del resultado analítico afectado mientras investiga el responsable. No corrijas un evento sin dejar constancia, borres el original ni conviertas un valor ausente en un cero medido.

El comprobador pone en cuarentena los campos ausentes, el significado o la versión no admitidos, los valores numéricos no válidos y el orden incoherente de los relojes bajo el supuesto del mismo día. Informa como duplicada una identidad exactamente repetida. Un ejemplo con estructura válida pero sin límite acordado de antigüedad recibe el estado hold, en espera, y registra cinco segundos como tiempo de tránsito observado.

El ejemplo no contiene nombres reales de responsables, plazo de escalado ni incertidumbre medida de los relojes. El acuerdo vacío deja esos campos en blanco. El equipo debe aportarlos y aprobarlos antes de aplicar una regla en producción. Superar esta prueba local de software no demuestra que la medición de origen sea fiable, que el transporte sea seguro ni que los datos sean adecuados para una decisión de seguridad.

Prueba el registro en el consumidor antes de aprobarlo

El módulo descargable contiene el ejemplo existente, campos vacíos separados y el comprobador. Se ejecuta localmente con un entorno JavaScript y no realiza solicitudes de red. La salida informa del contador observado y del motivo de espera; no envía órdenes ni modifica un sistema de fábrica.

Consulta la guía de marcas temporales de eventos para la hora de origen, la de llegada y la incertidumbre. Usa la comparación existente de protocolos para elegir cómo comunicar. Este artículo complementario añade responsabilidades del productor y del consumidor, revisión de cambios y rechazo ejecutable, en lugar de otro glosario de protocolos.

Para el próximo traspaso real de datos, pide a ambos responsables que identifiquen un cálculo dependiente y un cambio que lo invalidaría. Conserva el registro original, ejecuta las comprobaciones acordadas y registra quién resuelve el primer supuesto no respaldado.