Semi E134.2

SEMI E134.2 defines a Protocol Buffers (protobuf) encoding for Data Collection Management — the same plan-creation, activation, modification, and freeze-protected versioning data E134 defines and E134.1 delivers over SOAP, re-expressed as a compact binary protobuf message a host can parse without SOAP's XML envelope and parsing overhead. E134.1 gives DCM a defined web-service binding inside the existing SOAP-based Interface A ecosystem, but SOAP's XML-over-HTTP overhead is a real cost specifically for DCM, because the whole point of a collection plan is a high-rate data stream — parameters sampled every 100 milliseconds, continuously, for the plan's entire active duration — so every data point paying an XML envelope tax compounds far faster here than in a one-time discovery call. E134.2 is the alternative encoding standard that keeps the same collection-plan content but swaps the stream's wire format for one built for sustained machine-to-machine throughput, the same relationship E125.2's protobuf EqSD encoding has to E125.1's SOAP EqSD binding.

An active collection plan streams data continuously at high rate
Every sampled point pays whatever the wire format's overhead is
SEMI E134.2 — Protocol Buffers DCM encodingSame plan-management content, binary wire format for the stream
Compact binary message defined by a .proto schema
Smaller payload, faster parse than the equivalent SOAP data stream
Field-for-field equivalence with E134.1's SOAP response
No information lost moving between encodings
Host sustains a high-rate collection plan without SOAP overhead compounding
Vendor can publish either binding; DCM content stays identical

The reason DCM needed a second encoding standard rather than staying SOAP-only is a sharper version of the same argument EqSD's E125.2 already made: a web-services binding that's rigorous and tool-friendly for a one-time discovery or plan-setup call is a much worse fit once that call turns into a continuous stream, because the per-message XML parsing cost that was negligible once now repeats at every sample interval for the plan's entire runtime. E134.2 gives equipment vendors and host developers that same choice EqSD's encoding pair already has: manage and receive a collection plan via E134.1's SOAP binding when existing Interface A web-service tooling matters, or via E134.2's protobuf encoding when sustained stream throughput matters more, with both representing identical plan-management and data content either way.

Why Overhead That's Negligible Once Isn't Negligible 36,000 Times a plan sampling every 100ms for an hour makes 36,000 copies of whatever the wire format costs time into an active collection plan (1 hour, sampled every 100ms) cumulative bytes sent E134.1 SOAP: ~480 MB/hr E134.2 protobuf: ~48 MB/hr one sample, SOAP: ~400 bytes (looks fine alone) one sample, protobuf: ~40 bytes (also looks fine alone) × 36,000 samples/hour — that's where the gap opens up Same plan-management content, same data, both encodings The difference only matters once the plan is sustained and high-rate — which is the normal case

E134.2 gives DCM the same dual-encoding flexibility the EqSD pair already established, but the stakes are higher here: E134 defines what a collection plan has to support, and E134.1/E134.2 are two interchangeable wire formats for carrying both the plan-management calls and the resulting data stream, with a fab's choice between them mattering most once a plan's sampling rate and duration turn per-message overhead into a real throughput bottleneck.

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