Semi E172

SEMI E172 specifies the SECS Equipment Data Dictionary (SEDD), a standardized, machine-readable schema for describing every SECS-II variable ID (VID) a piece of GEM equipment exposes — its name, data type, units, and valid range — covering the classic SECS-II/GEM world the same way E125's Equipment Self Description (EqSD) covers the newer EDA/Interface A world. EqSD answers "what can this tool report over Interface A, and at what resolution"; SEDD answers the equivalent question for SECS-II itself: given a raw VID number like 1012 in a status-variable report, what does that number actually mean, what type of value is it, and what units does it carry — without a host engineer having to look it up by hand in a vendor's paper equipment manual.

Equipment reports status variable 1012 = 847 over SECS-II
A bare VID number and a bare numeric value, nothing else
What SECS-II alone never definesVID numbers are just integers until someone documents what they mean
No standardized way to know VID 1012 means chamber pressure
Each vendor's equipment manual documents its own VID assignments, in its own format
No standardized way to know the units are millitorr, not torr or pascal
A host hardcodes vendor-specific lookup tables, one per tool model
SEMI E172 — SECS Equipment Data Dictionary (SEDD)A standardized, queryable VID-metadata schema
Machine-readable definition of each VID's name, type, units, and valid range
Equipment publishes its own dictionary instead of relying on a paper manual
A host can interpret VID 1012 = 847 correctly without a vendor-specific lookup table
Same interoperability gain EqSD provides for EDA, now for plain SECS-II

A few things are worth knowing about why SECS-II needed a dedicated data-dictionary standard despite having defined VIDs for decades:

SECS-II was built to move numbers efficiently, not to explain what the numbers mean, and that gap has been quietly filled by paper equipment manuals and hand-built lookup tables for as long as the protocol has existed. A status-variable report over SECS-II is, at the wire level, just a VID and a value — the protocol has no built-in mechanism for a tool to tell a host "VID 1012 is chamber pressure, reported as a 4-byte float, in millitorr, valid from 0 to 50." That metadata has always existed somewhere, but historically only in a vendor's printed documentation, which a host-side integration engineer had to read and manually encode into software before any of that VID's data could be interpreted correctly. SEDD exists to move that metadata out of PDF manuals and into a standardized, machine-readable format equipment can publish directly.

VID 1012 = 847 — Two Ways to Find Out What That Means SEMI E172 (SEDD) replaces the paper manual with a queryable dictionary SECS-II status-variable report: VID 1012, value 847 The wire message carries only a number and a number — no meaning attached Before SEDD Engineer opens vendor's PDF manual, finds VID 1012 listed as chamber pressure, manually hardcodes the units (millitorr) Repeated per tool model, per vendor With SEDD Host queries equipment's own published dictionary: VID 1012, chamber pressure, float, millitorr, range 0-50 Standardized, automatic, no manual lookup The VID-847 value never changes — only how a host learns its meaning does SEDD turns tribal integration knowledge into a standard, queryable schema

SEDD matters most in exactly the setting that makes vendor-specific lookup tables most expensive: a fab running mixed equipment from many vendors, each with its own VID numbering and documentation style, where every new tool model historically meant another manual integration pass before host software could interpret its data correctly. A host monitoring dozens of tool types across multiple vendors has, under the old approach, needed a separately maintained lookup table per tool model — a maintenance burden that grows linearly with fleet diversity and breaks silently whenever a vendor revises a VID assignment without updating the host's copy of the manual. A standardized dictionary that equipment publishes itself removes that entire class of integration work and the silent-drift risk that comes with it.

SEDD sits alongside E125's EqSD as the SECS-II-side counterpart to a problem this glossary has already covered from the EDA/Interface A side — both standards exist to let equipment describe its own data instead of requiring a human to encode that description into host software by hand. Where EqSD covers the full EDA/Interface A parameter set, including sampling rates and acquisition modes outside GEM's scope, SEDD is narrower and specific to classic SECS-II: it's the dictionary for the VID-and-value world GEM equipment has used for decades, giving that older protocol the same kind of self-description capability EqSD brought to the newer data-acquisition standards.

Read E172 as the standard that closes the gap SECS-II's bare VID numbering was never built to close: a status-variable report has always carried a number and a value, never what that number means, and SEDD is what actually lets equipment publish that meaning in a standardized, queryable form instead of leaving it buried in a vendor's manual.

Take SEMI E172 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