Semi E39

SEMI E39 defines Object Services, the foundational data model that gives every other GEM-family standard a common way to describe "a thing with attributes" — a carrier, a process job, a substrate, a control job — instead of each standard inventing its own ad-hoc structure for representing the objects it tracks. Where SEMI E90 defines what a substrate object's location and state attributes mean, and SEMI E94 defines what a control job object's attributes mean, E39 is what defines the underlying concept of an object itself: a named entity with a set of attributes, each attribute with a defined name and value, that can be created, queried, updated, and deleted through a standardized set of object-service messages built on SECS-II.

A GEM standard needs to track something
A carrier, a job, a substrate, a recipe binding
SEMI E39 object modelShared structure every GEM-family standard builds on
Object type + named attributes
e.g. CarrierObject with CarrierID, SlotCount, ...
Create / Get / Set / Delete via SECS-II
Standardized operations, not vendor-specific ones
E90, E94, E87, and others reuse this model
Each only has to define its own object types and attributes

The payoff of pulling object services out as its own standard is that every higher-level GEM standard built afterward gets to skip reinventing basic plumbing — E90's substrate object, E94's control-job object, and E87's carrier object all look structurally the same from a software-implementation point of view, differing only in which attributes each object type defines, because all three inherit the same create/get/set/delete operations and the same named-attribute structure from E39. This is also what makes GEM software reusable across standards in practice: a host-side library that can create, query, and update an "object" generically, following E39's rules, does not need a separate implementation for every individual GEM standard that happens to define its own object types on top.

SEMI E39 — Shared Object Model Underneath GEM one base model, reused by every higher-level standard SEMI E39 Object Services Object type + named attributes + Create/Get/Set/Delete E87 Carrier object CarrierID, SlotCount, ... E90 Substrate object Location, ProcessState, ... E94 Control-Job object JobState, ProcessJobList, ... Same create/get/set/delete operations underneath all three only the attribute names and meanings differ per object type

SEMI E39 is infrastructure that most equipment engineers never interact with directly — it shows up in practice as the shared behavior underneath E87's carrier management, E90's substrate tracking, and E94's control-job management, which is exactly why it belongs in the same foundational group as GEM (E30) and HSMS (E37) even though none of those higher-level standards mention "object services" by name in day-to-day fab conversation.

Take SEMI E39 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