Secs
SECS (SEMI Equipment Communications Standard) is the message format and exchange protocol that equipment and host systems use to talk to each other — SECS-I defines an older point-to-point serial framing, SECS-II defines the actual message structure (the Stream/Function numbering, like S3F5 or S6F11), and HSMS (High-Speed SECS Message Services, SEMI E37) carries those same SECS-II messages over TCP/IP on modern equipment. GEM is the layer built on top of SECS-II that standardizes what those messages mean for equipment behavior; SECS itself just defines how any message gets formatted, sent, and acknowledged.
The Stream.Function numbering is a deliberately small, reusable grammar, not a per-tool vocabulary. Stream 1 covers equipment status, Stream 2 covers equipment control and host commands, Stream 3 covers material/carrier/port actions, Stream 5 covers alarms, and Stream 6 covers data and event collection — every piece of equipment on the fab floor, regardless of vendor or tool type, uses this same numbering scheme, which is what lets one host software stack monitor etch tools, deposition tools, and metrology tools through a single, consistent message interface instead of a different protocol per vendor.
SECS-I versus HSMS is purely a transport choice, and it's almost always already decided by how old the tool is. Older or simpler equipment still ships with SECS-I's serial RS-232 framing, which is slower and strictly point-to-point; virtually all modern equipment uses HSMS over Ethernet instead, because TCP/IP is faster, supports standard network infrastructure, and doesn't require a dedicated serial cable run to every tool. Either way, the SECS-II message content — the Stream, Function, and data items — is identical; HSMS just wraps the same payload in a different network envelope.
SECS, GEM, and E84/E87 form a layered stack, and confusing which layer a question belongs to is the most common mistake when reading equipment documentation. SECS-II is the message grammar (how any message is structured); GEM (SEMI E30) is the behavioral model built on SECS-II (what messages equipment must support and when); E84 and E87 are specific automation standards for carrier handling that happen to use SECS-II/GEM as their communication mechanism. A question like "why does the host need to acknowledge this message" is a SECS question; "why does the equipment report ready-to-load this way" is a GEM question; "why does the AMHS wait for this signal before releasing the FOUP" is an E84 question — same underlying wire protocol, three different standards answering three different questions.
Every piece of fab automation covered elsewhere on this site — load ports, FOUPs, mainframe robots reporting chamber status — ultimately talks to the factory host through this SECS message grammar, which is why understanding Stream.Function numbering is the single most reusable piece of knowledge for reading any tool's equipment interface manual.