Semi E160

SEMI E160 specifies the communication of data quality — the protocol-level mechanism for actually transmitting a data-quality assessment from equipment to host, where E151 already defined what data quality means and how to understand it conceptually. E151 gives a fab the vocabulary for describing whether a piece of equipment data is trustworthy; E160 gives a host the standardized message format for actually receiving that assessment alongside the data point it describes, rather than leaving every equipment vendor to bolt a quality flag onto its data stream however it sees fit.

E151 defines what data quality means
Concepts, categories, and criteria for assessing equipment data
What E151 alone doesn't provideA concept isn't a wire format
No standard way to attach a quality assessment to a data point
Every vendor would invent its own flagging convention
SEMI E160 — Communication of data qualityThe GEM-based message format carrying E151's quality assessment
Data point + standardized quality metadata, transmitted together
Host receives both in one consistent protocol structure
Host-side analytics can trust or discount a data point automatically
No per-vendor interpretation layer needed between equipment and analysis

A few things are worth knowing about why data quality needed two separate standards rather than one combined document:

E151 and E160 split the same problem the way a dictionary and a mail protocol split language from transmission. E151 does the conceptual work: what counts as a quality issue, how to categorize sensor drift versus a missing value versus a stale timestamp, how a fab should think about the reliability of a given data point in the first place. None of that conceptual framework says anything about bytes on a wire — and E160 is the part that does, defining the actual message structure a piece of equipment uses to hand a quality-tagged data point to the host. Keeping them separate means E151's quality taxonomy can evolve or get adopted elsewhere without forcing a protocol change, and E160's wire format can be implemented by anyone who already understands E151's concepts without needing to re-derive them.

Anatomy of an E160 Data-Quality Message E151 defines the quality categories — E160 defines exactly where they sit in the message itself SECS-II message body, field by field Stream/Function header (unchanged from base GEM message) Data value field e.g. SVID 2004 = 148.3°C Quality-tag field — added by E160 category: drift | stale | uncal | nominal confidence: 0–100 E151 taxonomy, encoded here Timestamp field (unchanged) Equipment-ID field (unchanged) Vendor A tool writes quality tag into the same field position every time Vendor B tool same field, same position, same encoding rules Host reads one field position for every vendor's tool Without E160: each vendor puts the quality flag somewhere different in the message With E160: one fixed field position, same parser works for every vendor's equipment

The case for standardizing this particular wire format is the same case that justified E53's event-reporting protocol and E147's EDA — a fab's analytics are only as good as the uniformity of the data arriving at the host. Without E160, a host building fab-wide quality-aware analytics would need a per-vendor adapter translating each piece of equipment's ad hoc quality-flagging scheme into something comparable across the fab — exactly the integration-cost problem SEMI's GEM-based standards exist to eliminate everywhere else in the AMHS and equipment-communication stack.

E160's position relative to E151 mirrors how E53's event-reporting protocol relates to the collection-event concepts it transmits, and how E147's EDA relates to the broader equipment-data-acquisition philosophy behind it. In each case, SEMI split the conceptual standard from the transport standard, which is a pattern this whole glossary keeps surfacing: a concept standard tells you what matters, and a protocol standard tells you how that thing actually travels from equipment floor to host software, and conflating the two tends to produce a document that's awkward at both jobs.

Read E160 as the standard that makes E151 operationally real rather than merely descriptive: a fab can adopt E151's data-quality taxonomy perfectly and still have no fab-wide quality-aware analytics without a standard way to transmit that taxonomy's output, and E160 is precisely that transmission layer — the reason a host can treat a sensor reading's trustworthiness as a first-class, automatically available property instead of something an engineer has to chase down vendor by vendor.

Take SEMI E160 further

Ask the copilot about this term, or have our engineers assess it against your process.

Ask CFSGPT about this → Request a technical assessment → Open the CFS app