Keep GEM behavior where the fab depends on it; bridge only the semantics another consumer needs.
SECS/GEM and OPC UA solve different integration problems. Keep native SECS/GEM at the equipment–Host boundary when the fab expects GEM communication behavior. Add an OPC UA bridge for MES, analytics or supervisory consumers that need selected equipment information. A bridge is not an automatic one-to-one protocol conversion: its contract must define identifiers, data types, units, events, acknowledgements, commands, states and failure behavior.
Choose one of three boundary decisions
Keep native SECS/GEM
Use the equipment interface directly when the Host must exercise agreed GEM behavior such as communications state, collection events, alarms, variables or remote commands. Confirm the applicable capability set with the fab and equipment supplier.
Add an OPC UA bridge
Keep the SECS/GEM owner intact and expose a governed OPC UA information model for selected upstream consumers. The gateway owns translation, observability and recovery without silently redefining the equipment contract.
Translate selected semantics
Map only the data and commands with a named use case and acceptance owner. Do not imply that every message, state transition or timing expectation has an equivalent representation.
Responsibility boundary
Write down which component owns the equipment session, GEM state, command authorization, retry policy, timestamp source and audit trail. If both the Host and gateway can issue a command, define arbitration and a safe degraded mode before commissioning.
| Contract item | Record before implementation | Acceptance evidence |
|---|---|---|
| Identity and type | SECS variable or event identifier, OPC UA NodeId, data type, unit and null or unavailable meaning | Reviewed mapping samples at nominal and boundary values |
| Events and acknowledgement | Trigger, ordering expectation, duplicate handling and acknowledgement owner | Trace showing expected order, duplicates and recovery |
| Commands and states | Authorization, preconditions, timeout, result mapping and state transition | Scenario replay for accept, reject, timeout and reconnect |
| Time and quality | Timestamp source, clock assumption, freshness and quality representation | Consumer test with stale, delayed and unavailable data |
Bridge acceptance checklist
- Responsibility boundary: name the owner of each session, state, command, acknowledgement, retry and audit record.
- Versioned mapping ledger: version every identifier, data type, unit, event, command and state mapping; record who approves changes.
- Nominal scenarios: prove connect, subscribe or collect, command, acknowledgement and orderly shutdown using representative equipment traces.
- Failure-mode acceptance: test disconnect, reconnect, duplicate, delayed, stale, out-of-order, malformed, unauthorized and partially unavailable cases.
- Observability: retain correlated timestamps and identifiers so an engineer can trace a consumer value or command back across the boundary.
- Rollback: document how to disable the bridge or restore the prior mapping without changing the equipment interface unexpectedly.
Failure modes belong in the design, not only in commissioning
Decide what downstream consumers see when the SECS/GEM session is offline, a value is stale, an acknowledgement is missing or the mapping version is incompatible. Preserve enough correlation to distinguish equipment behavior, gateway behavior and consumer behavior; otherwise the bridge can turn one diagnosable incident into three ambiguous ones.
Security and change control
Limit write paths, authenticate management access, separate configuration authority from runtime operation and log mapping changes. Treat new nodes, changed data types, renamed events and altered command preconditions as interface changes that require review and regression evidence.
What if the equipment is legacy or incomplete?
Start by identifying the interface the equipment actually exposes and the Host behavior the fab actually requires. For retrofit triage, use the existing SECS/GEM for legacy equipment guide; do not assume a gateway can supply missing equipment behavior without a scoped adapter and acceptance plan.
Primary references
- SEMI E30 — Generic Model for Communications and Control of Manufacturing Equipment (GEM): SEMI describes GEM as a standard implementation of SECS-II behavior and communications capabilities for semiconductor manufacturing equipment.
- OPC Unified Architecture, Part 1 — Overview and Concepts: the OPC Foundation reference for the OPC UA architecture and concepts.
Bridge questions
Does an OPC UA bridge replace GEM behavior?
Not by default. A bridge can expose selected information and commands, but GEM behavior at the equipment–Host boundary remains a separate contract unless the parties explicitly redesign and accept that boundary.
Should every SECS/GEM message become an OPC UA node?
No. Start from consumer use cases and map only the semantics that have an owner, version and acceptance test.
What is the minimum commissioning evidence?
A versioned mapping ledger plus correlated traces for nominal, rejected, timeout, disconnect, reconnect, stale and unavailable scenarios is a practical starting set; the project owner must add site-specific requirements.
Review the boundary before implementing the bridge
Share a non-confidential equipment interface, target consumer and representative acceptance scenario. MST will assess whether a bounded mapping and evidence review is appropriate.
Request private bridge assessment →
