The “unusual” protocols in SMT/electronics plants — and how Ignition connects them

An SMT / electronics assembly plant has its own “protocol ecosystem”, quite different from a typical process plant: pick-and-place machines, reflow ovens, AOI, solder-paste printers… talk to each other and to the MES via SECS/GEM, IPC-CFX, IPC-Hermes, SMEMA. Every machine vendor does it differently → integration gets messy. Ignition (Inductive Automation) is the platform that ties it all into one — SCADA/MES/UNS.

The protocols, one by one

1. SECS/GEM (SEMI, since the 80s–90s) — the machine ↔ host standard from semiconductors, also widely used in SMT. Modern equipment runs HSMS (SECS over TCP/IP) instead of SECS-I (RS-232). GEM = a standard equipment behavior model (states, alarms, recipes, data collection).
2. IPC-CFX (Connected Factory Exchange) — an OPEN IPC standard (2018), “plug-and-play” for electronics assembly. Transport over AMQP 1.0 + JSON encoding, via a pub/sub broker; covers both M2M and machine↔MES. The most modern direction.
3. IPC-Hermes-9852 (The Hermes Standard) — handshake & board transfer machine ↔ machine on the SMT line, over TCP/IP + XML. Replaces SMEMA, carrying board data (barcode, orientation) not just signals. CFX integrates bi-directionally with Hermes.
4. SMEMA (IPC-SMEMA-9851) — the legacy electrical/digital I/O handshake between conveyor machines (board ready / machine ready). Simple, signal-only, no data — still very common on older lines.
5. IPC-CAMX — the older XML-based predecessor to CFX (legacy, fading). MQTT/Sparkplug B — IIoT pub/sub, the core of a UNS. OPC UA — the common standard, the most universal bridge.

Quick comparison

How Ignition ties these together

1. OPC UA (native) Ignition is a built-in OPC UA client/server → connects anything speaking OPC UA. Many SMT machines/PLCs already expose OPC UA.
2. MQTT / Sparkplug B (a strength) Via the Cirrus Link modules, Ignition is the #1 platform for MQTT/Sparkplug → build a UNS, unifying line data into one namespace.
3. IPC-CFX (AMQP) Ignition consumes AMQP via Python scripting (an AMQP library) or an AMQP ↔ MQTT bridge → mapping CFX messages into tags/UNS.
4. SECS/GEM Via a SECS/GEM ↔ OPC UA gateway or a third-party SECS/GEM module for Ignition → Ignition reads the semiconductor/SMT equipment's states/alarms/recipes.
5. Hermes / SMEMA Hermes: open a TCP socket + parse XML in Ignition scripting. SMEMA: read the digital signals via PLC/IO into Ignition → monitor handshakes & line blocking.
6. Roll up into MES/OEE/traceability Once machine data is in Ignition: build OEE, downtime, board traceability by barcode, line dashboards — all on one platform.

Common integration mistakes

1. Confusing horizontal (M2M) with vertical — picking the wrong protocol, e.g. using SMEMA to report to the MES.
2. Thinking SMEMA “carries data” — it's only an I/O ready signal; for board traceability you need Hermes/CFX.
3. Forgetting byte order / encoding when mapping AMQP/JSON (CFX) or registers into tags → garbage values.
4. Ignoring the GEM state model — misreading SECS/GEM equipment states/recipes by not following the state model.
5. Wiring every machine straight into SCADA, skipping a UNS — works at first but gets hard to scale & maintain.

How DeepDebug helps

We advise the SMT line connectivity architecture (choosing CFX/SECS-GEM/Hermes/SMEMA per machine) + build the bridges into Ignition (OPC UA, MQTT/Sparkplug, AMQP, scripting) → one clean UNS/MES.

FAQ