Semi E147

SEMI E147 defines Equipment Data Acquisition (EDA) — the overarching framework, often called Interface A, that establishes equipment self-description, data-collection management, and standardized web-services access as one coherent system, with E125 (EqSD), E134 (DCM), E132 (authentication), and E164 each implementing one specific piece of the framework E147 defines at the architectural level. Earlier SECS/GEM-based data collection worked, but it was built around polling status variables and reacting to collection events one at a time — adequate for moderate data rates, but not designed for the fleet-wide, high-rate, self-describing data access a modern fab's analytics and yield-management systems need. EDA is the architectural answer: equipment publishes what it can measure (EqSD), a host requests exactly the data it wants at the rate it wants (DCM), and the whole exchange happens over authenticated, standardized web services rather than ad hoc per-vendor extensions — E147 is the standard that ties those pieces together into one named framework rather than leaving them as independently-useful but conceptually disconnected specifications.

Classic SECS-II data collection: poll status variables, react to events
Works, but wasn't architected for fleet-wide high-rate self-describing access
SEMI E147 — Equipment Data Acquisition (EDA / Interface A)The architectural framework E125, E132, E134, E164 each implement a piece of
Equipment self-describes its available data (E125/EqSD)
A catalog of what can be collected, not just what's currently reported
Host manages collection plans and authenticates over web services (E134/E132)
Standardized access replacing ad hoc per-vendor data extensions
Fab-wide analytics and yield systems get consistent, high-rate equipment data
One architectural framework, multiple standards implementing its pieces

The reason EDA needed its own named, architectural-level standard rather than letting E125, E132, and E134 stand as independent specifications is that each of those solves one piece of a larger problem — self-description, authentication, data-plan management — and a fab integrator trying to build a coherent host-side EDA client needs to understand how those pieces fit together as a system, not just that three separate standards happen to exist. E147 gives the overall EDA/Interface A concept its own definition: equipment self-describing its data (E125), authenticated access to that equipment (E132), and standardized data-collection management (E134) aren't three unrelated capabilities that happen to use similar SOAP infrastructure — they're the three load-bearing pieces of one coherent architecture E147 names and defines at the level above any single satellite standard.

One EDA Request, Walking Through All Three Pieces E125, E132, and E134 aren't independent — they're one sequence a host actually runs Host Equipment E132: Login(cred) session token issued E125: GetEqSD() catalog: available SVID 2004, 2007, 3012... E134: CreatePlan(2004 @ 100ms) plan active — stream begins Authenticate (E132) → discover what's available (E125) → request it (E134) E147 is the standard that says these three steps are one architecture, not three accidents

E147 is what gives Equipment Data Acquisition its identity as one coherent architecture rather than a loose collection of independently-useful standards — by naming and defining the EDA/Interface A framework at the level above E125's self-description, E132's authentication, and E134's data-collection management, it tells a host integrator how those pieces are meant to work together as a system, which is a different and necessary question from what any single satellite standard answers on its own.

Take SEMI E147 further

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