MES Write-back: Designing Fields That Stay Useful

There is a plain test for a write-back schema. Suppose a customer returns a batch in three months. Using only these fields, can you identify which shift, which station, which checked item, and what the camera saw at the time? If not, there are too few fields, and the system has quietly become a device that only lights a lamp — it cannot be used for process improvement after the fact. The reverse failure is just as real: every column has to be maintained, stored and read by somebody, and a schema stuffed with unused fields only bloats the database and makes the next person afraid to touch it. The useful starting point is answering six questions: who, when, where, what was checked, what the verdict was, and what the evidence was.

Six questions, six groups of fields

The last two rows are the ones that get dropped. Threshold version and model version look like internal detail, but once a parameter has been changed, historical verdicts can never be reproduced — somebody opens an image from three months ago and asks why it was passed, and nobody can answer. The image reference works the same way. This is not a demand to keep every frame forever; it is a demand for a window of replayability, with an explicit policy after that. How long the window should be depends on the traceability requirement for the product and the storage cost of the images, which is discussed in more depth in building traceability.

Granularity: piece, batch or work order

Granularity is not a question of how advanced the technology is. It is a question of whether the product can be identified at all. Piece-level tracing assumes every item carries something unique — a serial number, a barcode, an RFID tag, or at least a stable position relative to an identifiable carrier. If parts arrive in a loose bin with no identifier, piece-level tracing can only be inferred from time sequence, and a single missed frame or double trigger shifts every subsequent record. That is worse than having no record, because a shifted record still looks credible. In that situation the honest choice is batch-level or work-order-level tracing: record how many alarms occurred in this batch and when, which cannot name the individual piece but is entirely sufficient for process improvement and trend analysis.

• Piece level: for products with a unique identifier and high individual value — semiconductors, medical devices — where the question is which piece.
• Batch level: for unlabelled parts that move in batches, where the question is which batch drifted.
• Work-order level: for high-mix low-volume, where the question is how this order performed, usually paired with first-article confirmation.
• Mixed: the common compromise is work-order level overall with piece level at the few stations where it pays.

When write-back competes with takt

On a tight station, write-back is itself a load. If every verdict waits synchronously for MES to acknowledge, a small network hiccup stalls the line. A sensible layering is to land the key fields — verdict, timestamp, station, check item — locally first, so nothing is lost, then push to MES asynchronously with latency allowed. Large objects like images should never travel the synchronous path at all; they stay local with an index, and only the index reaches MES. The order matters: trading local persistence for real-time synchronisation means that a network outage erases that period permanently, and a missing period cannot be reconstructed later. For how the interface gets agreed across vendors, see integrating with MES vendors.

Fields you should probably drop

Be willing to cut fields as well. Three kinds of redundancy are common. First, pushing entire images or large raw payloads into MES tables — MES is not built to store large objects, and the database swells and slows. Second, writing back values MES can derive itself, such as the shift computed from a timestamp and a shift table; storing a copy only creates a chance for the two to disagree. Third, writing back system health metrics, which belong to equipment management and distort process analysis when they sit in production data. A practical filter is to ask whether process or quality would ever query this field for analysis. If the answer is no, it probably does not belong in the production record.