Industrial Protocols Explained Simply: OPC UA, MQTT, Modbus, FOCAS2, MTConnect & S7

The moment you start an industrial data project, you hit an alphabet soup — FOCAS2, MTConnect, Modbus, OPC UA, MQTT, S7 — and a lot of confident-but-conflicting advice about which one you "should" use. Much of the confusion comes from treating them as interchangeable. They're not; they do different jobs.

A plain-language map

It helps to group them.

CNC-oriented protocols — talking to machine tools:

• FOCAS2 — FANUC's API for FANUC CNCs over Ethernet. A supported way to read available CNC data such as spindle speed, run state, part counts, and alarms, depending on controller configuration and exposed functions.
• MTConnect — an open manufacturing standard. Machines, or an adapter, publish data in a common XML format over HTTP. Available on a range of newer multi-vendor CNCs.
• Brother HTTP — Brother machines can expose data through their own HTTP interface; useful if you run Brother CNCs.

General industrial protocols — broader equipment:

• Modbus TCP — simple and widely used, supported by many PLCs, meters, and older machines fronted by a controller. Limited structure, but very widely supported.
• Siemens S7 — the protocol for communicating with Siemens PLCs, common on automated lines.
• OPC UA — more than a protocol: a standardized information model that carries structure and metadata Modbus does not. In EdgeConnect, OPC UA is supported in both directions: as an OPC UA Client to consume data from OPC UA-enabled systems, and as an OPC UA Server to expose mapped data to SCADA, MES, HMI, historians, or other OPC UA clients.

Transport — moving data onward:

• MQTT — a lightweight publish/subscribe transport. This is a common point of confusion: OPC UA and MQTT are not direct competitors. OPC UA is about modelling and accessing device data; MQTT is about moving data efficiently to subscribers. A real architecture often uses both.

Where each applies

Match the protocol to the machine: FANUC → FOCAS2; newer multi-vendor CNC → MTConnect; Brother → Brother HTTP; Siemens PLC → S7; meters and legacy equipment → Modbus TCP; structured device servers → OPC UA; and MQTT to publish the result onward.

Protocol selection checklist

When deciding how to connect a given machine, work through:

• Controller type — make, model, and generation.
• Available interface — what the controller physically and logically exposes (and which options are enabled).
• Required data — the specific values you need from it.
• Polling / update rate — how often those values must be read.
• Data model needs — do you need rich structure and metadata, or just raw values?
• Destination system — where the data goes next, and what it expects.
• Supportability — whether the interface is something you can rely on and maintain over time.

Common mistakes

• Believing one protocol fits the whole floor. A real plant usually needs several. The goal isn't picking "the" protocol — it's handling the mix.
• The "OPC UA vs MQTT" trap. Asking which to choose is usually the wrong question; they solve different layers.
• Assuming newer means better. An older machine on Modbus still has valuable data; the job is to collect it, not to replace the machine.

How Elpis approaches it

Rather than forcing one protocol, EdgeConnect speaks the native protocol of each controller — FANUC FOCAS2, MTConnect, Brother HTTP, Modbus TCP, Siemens S7, and OPC UA Client today — and maps supported readings into a canonical vocabulary where the required values are available. It can then publish onward through MQTT or expose mapped data through OPC UA Server, so protocol diversity is handled once, at the edge, instead of leaking into every downstream system. FANUC MT-LINKi REST is on the roadmap.

Inventory your controllers by type; three or four protocols often cover a large part of the floor. See the Connectivity & Edge capability overview for more.

Elpis IT Solutions builds an Industrial Intelligence Ecosystem — from shop-floor signal to enterprise decision. Operating across India and the Middle East.