Agree what a factory event means before another team uses it

Agree the meaning and responsibility around the schema

The Open Data Contract Standard, or ODCS, describes an agreement between data producers and consumers. Its version 3.2.0 includes schema, data-quality information, teams, roles, support and service expectations. Those sections help the parties record more than a list of field types.

For a factory event, the operations owner explains the measurement and its permitted use. The producer owner maintains its source mapping. The consumer owner records which calculations depend on the record. They also agree who reviews a change, who investigates a failed check and when an unresolved issue escalates.

The worksheet records the article’s example agreement and expected checks. It is not a complete ODCS document, an OPC UA encoding or a production enforcement service. It authorizes no control or safety action.

Check what the counter record can tell you

The consumer retains the source and arrival times separately. OPC UA's DataValue definition distinguishes the source timestamp from the server timestamp; an application's arrival record is another declared observation. A receiving application must not replace a missing source time with arrival time and silently call it the original.

The existing illustration omits a calendar date and an agreed freshness limit. The checker can calculate five seconds only under an explicit same-UTC-day assumption. It holds downstream use until the missing freshness rule is agreed. It cannot validate clock accuracy, overnight timing or a real service obligation from these values.

A transport acknowledgment does not settle event meaning

The consumer checks the application identity before adding a record to an analytical calculation. OASIS MQTT permits duplicates with at-least-once delivery and distinguishes the packet DUP flag from repetition of an application message. A transport packet identifier is therefore not a replacement for the event identity the application needs.

In the existing counter example, receiving the same record twice does not add another 412 units. A later cumulative value of 413 indicates one additional accepted unit only if the same counter sequence continues without reset or rollover. Preserve that condition rather than assuming every lower count is an ordinary negative increment.

The checker reports a duplicate separately and adds zero new units for that duplicate. It leaves the production increment unknown for a first snapshot: one total without a valid preceding total cannot establish production during an interval. Counter resets and rollover need their own declared handling before a consumer calculates a difference.

See alsoFactory data quality

Treat a meaning change as a new agreement

A producer can keep an integer field and still break the consumer by changing its meaning from a cumulative accepted count to an increment or a gross count. Renaming a field is easier to detect than that silent change. Version the semantic definition as well as the syntax.

The teaching checker supports schema version 1, unit units, cumulative accepted-count meaning and the declared source identity. Its tests remove a required unit, change the schema version and alter the cumulative flag. These are deliberate mutations of the existing sample for software checks, not observed incidents at a factory.

Before a producer releases a change, both owners compare the old and proposed records against the consumers that rely on them. They decide whether the existing consumer still has the same meaning, needs an explicit adapter or must reject the new version. Keep the change approval, effective point and rollback decision with the agreement.

1. Record the producer's intended change

   The producer owner supplies the old and proposed field meaning, units, identity and time behavior.

2. Check affected consumers

   Each consumer owner names the calculation, assumption and supported version that the change touches.

3. Run the acceptance checks

   The reviewer checks known records, duplicates, missing fields, version changes and declared time limits.

4. Approve the transition and response

   The owners record the effective version, exception route and rollback or quarantine decision.

Reject, quarantine and hold are different outcomes

The receiving team preserves the raw record and its reason when validation fails. A quarantine route keeps it out of the affected analytical result while the responsible owner investigates. Do not repair an event silently, erase the original or convert a missing value into a measured zero.

The checker quarantines missing fields, unsupported meaning or version, invalid numeric values and inconsistent clock order under the same-day assumption. It reports an exact repeated identity as a duplicate. A structurally valid sample with no agreed freshness limit receives hold status, with five seconds recorded as observed transit time.

The example has no real owner names, escalation deadline or measured clock uncertainty. The blank agreement leaves those fields empty. A team must supply and approve them before applying a production rule. Passing this local software check does not establish trusted source measurement, transport security or suitability for a safety decision.

Run the record through the consumer before approving it

The downloadable module contains the existing example, separate blank fields and the checker. It runs locally with a JavaScript runtime and makes no network requests. The output reports the observed counter and hold reason; it does not send commands or modify a factory system.

Use the event-timestamp guide for source time, arrival time and uncertainty. Use the existing protocol comparison for communication choices. This companion adds the producer/consumer ownership, change review and executable rejection behavior rather than another protocol glossary.

For the next real data handoff, ask both owners to identify one dependent calculation and one change that would invalidate it. Preserve the original record, run the agreed checks and record who resolves the first unsupported assumption.