Semi E145

SEMI E145 defines the exact XML symbol set for expressing measurement units — the specific strings, abbreviations, and structured representations an XML document uses to say "this value is in degrees Celsius" or "this value is in standard cubic centimeters per minute," rather than the general notion that a unit-of-measure field exists, which E138's common-component library already establishes. E138 gives every XML-based SEMI standard a shared schema element for carrying a unit of measure, but a schema element is only useful if every document populates it with the same symbol for the same unit — without E145, one tool's XML might express flow rate as "sccm," another as "SCCM," another spelled out as "standard cubic centimeters per minute," and a host trying to parse unit strings across multiple equipment vendors would be back to writing a lookup table of string variants rather than reading a standardized symbol directly.

E138 gives XML documents a shared unit-of-measure field
The field exists, but its actual string content is still unspecified
SEMI E145 — measurement-unit symbols in XMLFixes the exact symbol string for every measurement unit
One canonical symbol per unit — no vendor spelling variants
sccm always means the same thing, written the same way
Structured representation for compound and derived units
W/cm², mTorr, and similar units expressed consistently
Host parses unit symbols directly, no string-variant lookup table needed
The same symbol means the same unit across every equipment vendor's XML

The reason unit symbols needed their own dedicated standard, distinct from E138's general component library, is that "reserve a field for units" and "guarantee every vendor fills that field with the identical string for the identical unit" are two different problems, and only the second one actually prevents parsing errors — a host that receives "Torr" from one tool and "torr" from another, or "sccm" from one and "SCCM/min" from another, has to build exactly the kind of fragile string-matching logic a shared schema was supposed to eliminate. E145 solves this the way any symbol-standardization effort does: by fixing one canonical representation per unit, including structured handling for compound units like power density or derived pressure units, so a host's unit-parsing logic can match against a known, finite vocabulary instead of guessing at every vendor's own spelling convention.

Four Tools, Four Spellings, One Flow Rate a reserved field still needs a fixed vocabulary to be parseable <Flow unit="sccm">80</Flow> <Flow unit="SCCM">80</Flow> <Flow unit="SCCM/min">80</Flow> <Flow unit="std cc/min">80</Flow> 4 identical values, 4 unparseable strings E145 <Flow unit="e145:sccm">80</Flow> <Flow unit="e145:sccm">80</Flow> <Flow unit="e145:sccm">80</Flow> <Flow unit="e145:sccm">80</Flow> one canonical symbol, every vendor Compound units get the same treatment <Power unit="e145:W_cm2">2.3</Power> — never "W/cm2" vs "Watts/cm^2" vs "w per sq cm" structured, not freeform text Without E145, a host still needs a spelling-variant lookup table it was promised it wouldn't

E145 is what makes E138's reserved unit-of-measure field actually trustworthy to parse — by fixing one canonical symbol per measurement unit, including structured handling for compound and derived units, it closes the gap between "a field for units exists" and "every vendor's XML populates that field with the same string," eliminating the fragile spelling-variant lookup logic a host would otherwise need to build just to understand what unit a value is actually in.

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