Semi E134.1

SEMI E134.1 defines the SOAP web-service binding for Data Collection Management — the actual WSDL-defined operations for creating, activating, modifying, and freezing a data-collection plan, plus the SOAP envelope structure and XML schema for the resulting data stream — rather than the general plan-creation/activation/freeze-protection behavior E134 establishes. E134 says a host should be able to request "parameters 3, 7, and 12, sampled every 100 milliseconds" and get back a standardized, version-protected collection plan; E134.1 is the transport-binding companion that fixes precisely how a host actually issues those requests and receives that stream over the web-services infrastructure the EDA/Interface A ecosystem (E125.1, E164, and the rest of that family) already runs on, the same relationship E125.1 has to E125.

SEMI E134 says: create, activate, modify, and freeze a collection plan
Defined behavior, but no fixed wire-level message set
SEMI E134.1 — SOAP binding for DCMFixes the WSDL plan operations and SOAP stream structure
Defined WSDL operations for plan create/activate/modify/freeze
Same web-service call signature across every compliant tool
Fixed SOAP envelope and XML schema for the data stream itself
No vendor-specific interpretation of how collected data comes back
Host's EDA client manages collection plans the same way everywhere
Works alongside existing SOAP-based E125.1/E164 integrations

The reason E134 needed a dedicated transport-binding standard is that the EDA/Interface A ecosystem already runs on web-services infrastructure, and "a host can create and manage a data-collection plan" by itself doesn't specify whether that plan-management happens via SOAP, REST, or some other mechanism — without E134.1, a host integrator writing a DCM client would have to guess or negotiate per vendor how to actually issue a plan request and receive the resulting stream, defeating the point of a collection-management standard that's supposed to make high-rate data acquisition consistent across tools. E134.1 closes that gap by binding plan management and data delivery to the same SOAP/WSDL pattern the rest of the Interface A family already uses, so a host's existing SOAP-based EDA infrastructure can add DCM plan control as one more standard set of calls rather than a bolted-on, vendor-specific mechanism.

The WSDL Operations That Actually Run a Collection Plan "create a plan" still needs a defined call to create, activate, modify, and freeze it No plan nothing collecting CreatePlan() Created params 3,7,12 @ 100ms ActivatePlan() Active streaming SOAP data ModifyPlan(params) FreezePlan() Frozen version-protected, no edits SOAP data-stream envelope <DCMStream planId="7"> <Sample t="0ms"> <P id="3">148.3</P> <P id="7">2.01</P> </Sample> </DCMStream> same schema, every vendor Two E134-compliant tools could still manage plans differently E134.1 fixes these exact WSDL operations and this exact stream schema

E134.1 completes DCM the same way every ".1" protocol binding completes its base standard: E134 defines what a data-collection plan has to support, and E134.1 is the fixed SOAP/WSDL message set that makes creating, activating, modifying, and freezing that plan identical across equipment vendors, so a fab's host software never has to special-case high-rate data acquisition by brand.

Take SEMI E134.1 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