Semi E142.3

SEMI E142.3 defines the SOAP web-service binding for substrate mapping — the WSDL-defined operations for requesting a mapping scan and the SOAP envelope carrying E142.1's slot-occupancy XML — as the web-services counterpart to E142.2's SECS-II binding, letting a host trigger and read a mapping result through the same Interface A infrastructure it already uses for EqSD, DCM, and RaP, rather than the classic SECS-II path. E142.2 gives substrate mapping a binding for the installed base of equipment that speaks SECS-II directly; E142.3 gives it the matching binding for host integrations and newer tools built around SOAP-based web services instead, the same relationship E139.3's SOAP binding has to E139.2's SECS-II binding for RaP, so a fab's modern Interface A stack isn't forced onto the older transport just to get a basic, frequent carrier-safety check.

Mapping's lifecycle (E142) and content schema (E142.1) are transport-agnostic
E142.2 already binds them to SECS-II for the classic GEM stack
SEMI E142.3 — web services binding for substrate mappingMatching SOAP/WSDL binding alongside E142.2's SECS-II path
Defined WSDL operations to request a mapping scan
Same call signature pattern as E125.1/E132.1/E134.1/E139.3
SOAP envelope carries E142.1's slot-occupancy XML directly
No re-encoding between the content schema and the transport schema
A fab's SOAP-based Interface A stack gets mapping results without a SECS-II fallback
Substrate mapping now has one binding for each major transport a fab might run

The reason substrate mapping needed both a SECS-II binding and a SOAP binding, rather than treating E142.2 as sufficient on its own, is the same mixed-infrastructure reality that drove E139.3 for RaP: a fab's actual fleet routinely mixes equipment on the classic SECS-II stack with host tooling and newer tools built around the SOAP-based Interface A ecosystem, and a safety-relevant, high-frequency check like mapping can't be left unavailable to whichever half of that fleet happens to run the other transport. E142.3 completes substrate mapping's transport coverage by giving the SOAP side of a fab's infrastructure the same scan-request and result-retrieval operations E142.2 already gives the SECS-II side, with both bindings carrying identical slot-occupancy content defined by E142.1 — which one applies depends only on the transport a given tool or integration already runs.

The WSDL Call E142.3 Fixes for Mapping Over SOAP a safety-relevant check can't be unavailable to the half of the fleet running web services Request — RequestMapScan operation <soap:Envelope> <soap:Body> <RequestMapScan carrierId="FOUP-8821"/> </soap:Body> </soap:Envelope> identical operation name, every vendor Response — carries E142.1's XML directly <soap:Envelope> <soap:Body> <SubstrateMap> <Slot n="2" status="empty"/> <Slot n="4" status="x-slot"/> </SubstrateMap> E142.1 content, unchanged Same E142.1 slot-occupancy content as E142.2's SECS-II path Only the envelope around it changes — SOAP/WSDL here, SECS-II stream/function there — pick by the tool's actual transport

E142.3 is what completes substrate mapping's transport coverage for a mixed-infrastructure fab — by giving the SOAP-based Interface A ecosystem the same mapping-scan request and result-retrieval operations E142.2 already provides for classic SECS-II equipment, it means a fab's choice to modernize part of its host integration never costs it standardized, consistent wafer-mapping safety checks on the equipment still running the older transport.

Take SEMI E142.3 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