Integrating Vision Inspection into Your Fab MES: SECS/GEM Host Communication Explained

SECS/GEM is one of those areas where a surface-level understanding creates more problems than no understanding at all. Process engineers who know the acronym but haven't worked through an ATC qualification in detail often produce integration checklists that look complete but break during bring-up. This article walks through what the communication model actually does, which messages matter for inspection equipment specifically, and what to verify before sign-off. It is written for engineers preparing a first SECS/GEM integration for an inline inspection tool, and for those who have done integrations before and want a structured reference for what typically goes wrong.

What SECS/GEM actually is

SECS (SEMI Equipment Communications Standard) is a message protocol. GEM (Generic Equipment Model) is a behavioral standard built on top of SECS. They are defined separately but almost always deployed together for modern semiconductor equipment integration, which is why "SECS/GEM" is used as a compound term even though the two specifications address different layers of the communication problem.

SECS defines message structure and transport. There are two transport options: SECS-II over RS-232 serial (SEMI E5), and HSMS-SS (High-Speed Message Services) over TCP/IP (SEMI E37). Modern 300mm tools universally use HSMS-SS, which provides the bandwidth and reliability needed for high-volume defect map transfers. Older 200mm fab infrastructure often still uses SECS-II RS-232 — typically for tools that predate the TCP/IP migration in the late 1990s. Lenspathio supports both transport layers, with HSMS-SS as the default and SECS-II available for legacy integration environments on request.

GEM (SEMI E30) defines the equipment behavior model: what states equipment can be in, what events it must report, how the host system can initiate transitions, and the minimum required set of standard variables the equipment must expose. GEM compliance means the equipment correctly implements the required communication states, can receive and respond to remote commands, and sends structured event reports when defined conditions occur. The compliance claim in a vendor's datasheet means the equipment has passed the GEM compliance test suite — it does not mean every optional GEM capability is implemented, and it does not mean the integration to your specific MES will work without configuration work.

A common misconception is that GEM compliance is binary — equipment either has it or doesn't. In practice, SEMI E30 has required capabilities and optional capabilities. An equipment vendor can claim GEM compliance with only the required subset implemented. Optional capabilities include dynamic report configuration (allowing the host to define report contents at runtime), operator-initiated remote commands, and certain alarm management behaviors. When writing integration checklists, you need to verify which optional capabilities your MES depends on and confirm they are implemented in the specific equipment you are integrating — not just that E30 compliance is claimed.

The communication model for inspection equipment

For an inline inspection system like Lenspathio, the host-to-equipment communication flows divide into two directions with different timing and reliability requirements.

Equipment to Host (upstream data flow):
The inspection system sends structured event reports to the MES via S6F11 (Event Report Send). Each event has a Collection Event ID (CEID) that identifies what happened, a Report ID (RPTID) that identifies the data payload structure, and the variable values themselves — the actual inspection data.

For inspection equipment, the critical collection events are:

• InspectionComplete (CEID 201): Fires when each wafer exits inspection. Payload includes WaferID, DefectCount by class, and DefectMap — the full die-level defect classification output with X/Y coordinates and defect type for each flagged event. This is the primary data transfer event; every other integration step is in service of getting this event to the MES reliably.
• DefectThresholdExceeded (CEID 202): Fires when the defect count for any class exceeds the recipe-configured threshold. Used to trigger automatic lot hold in the MES without requiring manual review. The threshold values are configurable per recipe via recipe management commands.
• LotComplete (CEID 203): Fires when the last wafer of a lot exits inspection. Payload includes LotYieldSummary — lot-level defect statistics for SPC and yield reporting. This event must be correctly received before lot tracking in the MES can close the lot at this process step.
• RecipeChange (CEID 204): Fires when the active recipe changes. Required for MES lot tracking to record which process recipe was active for each wafer in the batch history.
• AlarmSet / AlarmClear (CEID 205/206): Alarm state changes. Required for MES-side alert management and maintenance dispatch.

Host to Equipment (downstream control flow):
The MES can send remote commands to the inspection system via S2F41 (Host Command Send) and S2F49 (Enhanced Remote Command with parameters). For inspection equipment, the most common remote command is recipe selection — the MES specifying which recipe to activate for the incoming lot based on the lot's process route definition. The MES typically issues a recipe select command when the lot arrives at the inspection step, before the first wafer is loaded. If the recipe is not pre-selected, the equipment runs its default recipe, which may be incorrect for the incoming process layer.

The HSMS-SS connection model

HSMS-SS (Single Session) establishes a persistent TCP/IP connection between the equipment and a single host. One side is "passive" (listens for inbound connections) and one side is "active" (initiates the connection). SEMI E30 convention is that the equipment is the passive side and the host connects to it, but this assignment is configurable for environments where network topology makes equipment-side passive impractical.

Connection establishment sequence:

1. Equipment starts in NOT_CONNECTED state, listening on the configured IP address and port. Lenspathio's default port is 5000; this is configurable.
2. Host sends an HSMS Select.req message to initiate the session.
3. Equipment responds with Select.rsp with a status byte of 0 (accept), confirming session establishment.
4. Session is now in SELECTED state. Normal SECS message exchange begins on this connection.

The T3, T5, and T7 timers govern connection behavior. T3 is the reply timeout — if the host sends a primary message and doesn't receive a reply within T3 seconds, the message is considered failed. T5 is the connect separation time — the minimum interval between connection attempts after a failed connect. T7 is the "not selected" timeout — how long the equipment stays in the NOT_SELECTED state (after TCP connect but before Select.req) before aborting the partial session. The defaults for these timers in SEMI E37 are T3=45s, T5=10s, T7=10s. Modify them only if you understand the operational implication of each change.

The most common connection failures during bring-up are network configuration problems (wrong equipment IP address, port blocked by fab firewall, VLAN routing issue between equipment and MES host), T7 timer expiration before the host sends Select.req, and HSMS header format errors from host-side implementation differences in the SxFy message block header encoding. Check these in order — confirm TCP connectivity before attempting SECS message-level verification.

Collection event subscription

GEM equipment reports events, but the host must subscribe to receive them. The subscription mechanism uses S2F35 (Link Event Report) and S2F37 (Enable/Disable Event Report). Equipment that has not been subscribed for a CEID will not send S6F11 reports for that event, even when it occurs — the event fires internally but is not transmitted because there is no active subscription.

This is one of the most common sources of missing data during ATC qualification, and the failure mode is easy to miss. An integration checklist that says "verify InspectionComplete events are received" without first verifying that the host has sent a valid S2F35/S2F37 subscription for CEID 201 will fail in a non-obvious way. The equipment produces the InspectionComplete event internally on every wafer. The host never receives the S6F11 because no subscription exists. The defect map data appears to be missing from the MES, and debugging typically focuses on message transport issues before anyone realizes the subscription step was skipped.

Correct subscription sequence for InspectionComplete:

1. Host sends S2F35 (Link Event Report) to link RPTID 301 (the DefectReport report definition) to CEID 201 (InspectionComplete event). This establishes the association between the event and the report payload that will be sent with it.
2. Host sends S2F37 (Enable/Disable Event Report) with CEID list containing 201 and enable flag = TRUE.
3. Equipment responds with S2F38 (acknowledgment). A non-zero ACK code indicates the subscription was rejected — check the CEID and RPTID values against the equipment's defined event and report tables.
4. InspectionComplete events now generate S6F11 transmissions with the linked DefectReport payload.

Subscription state is volatile. It resets when the equipment restarts, when the SECS session is re-established, and in some implementations when the equipment transitions to certain GEM states. Your MES integration must issue the subscription sequence after every session establishment, not once during initial setup. If your MES doesn't re-subscribe after reconnection, defect data will be lost silently whenever the connection drops and recovers — a production data loss event that won't generate an alarm and may not be noticed until the yield accounting discrepancy is large enough to investigate.

Recipe management integration

Recipe management is one of the GEM optional capabilities most commonly needed for production inspection integration, and one of the most commonly mis-scoped during planning. The GEM recipe management model (SEMI E30 Section 8) defines how the host sends process programs (recipes) to equipment and how the equipment stores and activates them.

For inspection equipment, recipe management integration has three operational flows: recipe download (host sends a new or updated recipe definition to the equipment), recipe select (host specifies which stored recipe to activate for the incoming lot), and recipe verify (host requests confirmation that the active recipe matches the expected PPID for the current lot). All three should be tested during ATC qualification.

Recipe download uses S7F3 (Process Program Send) with the PPID (process program ID) and recipe body. The recipe body format for inspection equipment is vendor-specific — for Lenspathio, it is a structured XML document defining detection thresholds, model version, die map configuration, and defect class hold limits. Recipe select uses S2F41 with the START remote command and PPID parameter. Recipe verify uses S7F5 (Process Program Request) with PPID — the equipment returns the stored recipe body, which the MES can checksum against the intended version.

The most common recipe management failure mode is not in the protocol mechanics — it is in the lot tracking integration. When the MES issues a recipe select command and the equipment confirms receipt, the MES records that the recipe change was requested. If the equipment's recipe change is delayed by a few seconds (due to in-progress wafer handling), and the MES checks the active recipe immediately after the acknowledgment, it may see the previous recipe still active. The RecipeChange event (CEID 204) is the correct signal for confirming that the recipe is actively running — not the S2F41 acknowledgment. This distinction matters for the MES audit trail.

ATC qualification checklist structure

The Automated Test Checklist used to qualify new equipment varies by facility, but the structure for inspection equipment should cover these categories in order:

Common failure modes and structured debug approach

S6F11 events arriving but MES shows no defect data: The event is firing and reaching the host, but the RPTID subscription is missing or the report content is empty. Verify S2F35 was sent after the current session establishment (not from a previous session). Check that the RPTID value in S2F35 matches the DefectReport ID in the equipment's report definition table.

DefectMap payload truncated or containing zero coordinates: The DefectMap is a variable-length list encoded as an S-E (array of structures) data type. Host-side parsers with fixed-length buffer assumptions will silently truncate on large maps — typically those from high-defect-density wafers or large-die configurations. Verify the host parser handles variable-length S-E data types. Test explicitly with synthetic high-defect-count maps before production deployment.

Recipe change command acknowledged but previous recipe still active: S2F41 returns ACKC5 = 0 (success acknowledge), but the equipment continues running the previous recipe through subsequent wafers. This pattern indicates the remote command capability is structurally implemented (required by GEM), but the recipe activation handler has a sequencing bug. The RecipeChange event (CEID 204) should fire within 1–2 seconds of a successful S2F41 recipe select. If CEID 204 does not fire, the recipe is not active despite the positive acknowledgment.

T7 timeout causing session drop during low-throughput periods: T7 is the "not selected" timeout. If the MES is not sending periodic S1F1 (Are You There) messages and production is in a low-wafer-rate period, the equipment may drop the session due to T7 expiration. Either extend T7 (understanding that this increases recovery time after genuine connection failures), or implement a keepalive mechanism in the MES host — S1F1 with no data payload sent every 30–60 seconds is the standard approach.

Prerequisites for a clean ATC qualification

Our ATC qualification typically completes in 2–3 days with your integration engineer on-site, provided the prerequisites are in place before the qualification begins. The items that consistently determine whether ATC runs on schedule:

• Network connectivity established and verified to the point of successful TCP connect to the equipment's HSMS-SS port — not just to the equipment's management interface. Firewall rules for the SECS port specifically must be in place.
• HSMS-SS connection parameters confirmed in writing: equipment IP, port, passive/active assignment, T3/T5/T7 timer configuration. These should be resolved before on-site arrival, not during the qualification.
• MES CEID/RPTID subscription configuration prepared. The list of CEIDs the MES needs, the RPTID-to-CEID link definitions, and the subscription message sequence should be scripted and ready to execute from the MES host.
• Remote command handler on MES side tested with at least one S2F41 round-trip to any equipment. If your MES has never issued a GEM remote command, that is not a test to run for the first time during the inspection tool ATC.
• MES variable-length data parser verified for the S-E data type. If your MES integration team is not certain their parser handles variable-length lists, generate a test payload with 1,000 synthetic defect entries and verify the parser output before qualification begins.

Integration problems that surface during evaluation are nearly always traceable to one of the items above — connection mode misconfiguration, subscription sequence not re-issued after reconnect, or a variable-length parser assumption that was never tested against a realistic payload. If these items are resolved before our engineers arrive on-site, the ATC proceeds on schedule. The full qualification procedure, including the complete CEID/RPTID table for Lenspathio's inspection platform, is documented in Application Note AN-001. Request access via the contact form and we will share it before any formal engagement begins.