Equipment purchasing conversations are dominated by process performance — throughput, uniformity, particle counts, uptime commitments. Connectivity comes up late, if at all, and usually as a single line item asserting the tool is "SEMI SECS/GEM compliant".
That line is nearly content-free. Below are twelve questions that are not. Each takes a minute to ask, and each one you skip becomes a discovery during tool qualification, when the cost of an answer you do not like is at its highest.
Use them as-is. You do not need us to ask them.
1. Which transport does the tool use — HSMS over TCP/IP, or SECS-I over RS-232?
This determines whether the tool plugs into your network or needs a converter, a serial run, and a different class of integration effort. Do not assume a recently manufactured tool is on Ethernet; some tool families kept serial interfaces long after it stopped being necessary.
2. If HSMS: is the tool active or passive, and is that configurable?
Passive means the tool listens and your host connects. Active means the reverse. If the tool is fixed to active mode, your host has to listen on a known address, which changes your network design and your firewall rules. Ask for the default and whether it can be changed.
3. Can I have the SECS/GEM interface manual — before the PO?
The most important question on this list. The interface manual lists the actual SVIDs, CEIDs, alarms and remote commands the tool implements. Without it, every statement about what the tool can report is a promise rather than a fact.
A vendor who provides it readily is telling you something. So is one who cannot, or who will only release it after purchase.
4. Which GEM300 standards are implemented, specifically?
Not "GEM300 compliant". Ask for each one by number: E40 process jobs, E87 carrier management, E90 substrate tracking, E94 control jobs, E116 equipment performance tracking. Partial implementations are normal and perfectly workable — but you need to know which parts, because it determines what your MES can and cannot orchestrate.
5. Are remote commands enabled, and are any of them a licensed option?
Some vendors ship the GEM interface with remote control gated behind a separate automation licence. Finding this out during qualification, when the licence has a lead time and a price, is a bad afternoon.
6. Does the tool support recipe upload and download, and will it accept a recipe it did not create?
These are two different questions. A tool may let you retrieve its recipes for backup while refusing to accept an externally authored one. If your recipe management strategy assumes central control, confirm this explicitly.
7. Is trace data collection implemented?
Periodic sampling — the host arms the tool to report selected variables on a fixed interval — is an optional GEM capability. If your fault detection or process control strategy depends on time-series data from the tool, and the tool does not implement trace, you will be polling instead, which is not the same thing and does not scale.
8. What is the maximum event and data rate the interface will sustain?
The GEM interface on a tool is usually running on the tool controller alongside everything else it has to do. There is a practical ceiling on how much it will report before it starts to lag or drop. Ask the vendor for their number, in writing.
9. Is EDA / Interface A available?
The E120 to E134 family is a separate, higher-bandwidth data collection interface used for fault detection and advanced process control. It is common on modern 300mm tools and absent on most others. If your roadmap includes FDC, this question determines whether it is possible at all on that tool.
10. Does the tool ship with a simulator, and can I have it?
Some equipment vendors provide a simulator of their own tool. Where one exists it is far and away the best integration target, because it models that specific tool including its optional fields rather than a generic one. Ask early — it lets your integration work start before the tool physically arrives, which can pull weeks out of the schedule.
11. Who is responsible for the connection, contractually?
The tool vendor delivers a GEM interface. Your MES vendor delivers an MES. The gap between them is frequently unowned, and it is discovered at the worst possible moment. Establish in the contract whose scope includes making the tool actually talk to your systems, and what "done" means.
12. For a multi-chamber tool: how many logical GEM entities does it present?
A cluster tool may appear as one SECS/GEM entity or as several — one per chamber or module. This affects your host architecture, your addressing, and, if you are buying integration services, the price, because effort scales with entities rather than with mainframes.
A note on how to use these
You will not get clean answers to all twelve, and that is fine. The point is not to score the vendor. It is to surface the unknowns while you still have commercial leverage and schedule flexibility, which is to say before the PO rather than during qualification.
Write down the answers. Six months later, when a tool is not reporting something you assumed it would, the record of what was said during purchasing is worth having.
If you would rather not do this alone
Working through this across an entire tool set, and turning the answers into an architecture, is what a connectivity readiness assessment is. We run those as a fixed-scope, fixed-fee engagement, and the output is yours whether or not you ever buy anything else from us.
But the questions above are not proprietary and you lose nothing by asking them yourself first.