Why we built edge-first machine connectivity

When we started building Qontiv, we had a choice about how to handle machine connectivity. The obvious path was to follow the established playbook: build the MES core first, worry about machine integration later, and offer a professional services engagement when customers need to connect their equipment.

We didn’t take that path. Here’s why, and what we built instead.

The problem with middleware-first connectivity

Traditional industrial software stacks look like this:

Machine (PLC) → Gateway/SCADA → Historian → MES → ERP

Each layer adds latency, cost, and a new failure point. By the time an OEE event (a machine stops) makes it from the PLC to the MES, it might be 30 seconds old. By the time it shows up in the shift report, it’s hours old.

More practically: each layer is typically a separate product with a separate vendor, separate licensing, and a separate integration project. A mid-size manufacturer wanting to connect 20 machines to a new MES might be looking at a six-figure integration engagement before the MES software itself is configured.

We thought there was a better way.

What “edge-first” means in practice

Qontiv ships an Edge Gateway — a lightweight process (containerized, runs on any Linux box or industrial PC) that lives on the factory network and connects directly to machines via OPC-UA and MQTT.

The Edge Gateway does three things:

1. Subscribes to machine data sources (OPC-UA nodes, MQTT topics)
2. Maps raw signals to Qontiv’s data model using configurable profile rules
3. Publishes processed events to the Qontiv cloud over a secured connection

The configuration happens through an admin UI — not by writing code. An integration engineer can map a new machine in 20 minutes using the topic-pattern matching system, not a multi-week professional services engagement.

The ISA-95 Unified Namespace approach

The MQTT topic architecture follows ISA-95 Unified Namespace (UNS) conventions:

enterprise/site/area/equipment/tag

For example: acme/detroit/line1/weld-station/weld/current

A single profile rule with the pattern +/+/+/+/# captures all ISA-95 UNS topics, extracting the equipment code from segment 4 and the tag address from the remaining tail. This means connecting a new machine that follows UNS conventions is effectively zero configuration — the existing profile rule matches it automatically.

For legacy machines with non-standard topic structures, the profile system supports custom patterns with arbitrary capture groups. Most factories have 80% standard and 20% custom, and the profile system handles both.

Why this matters for OEE

The core insight is that OEE accuracy depends on signal latency. If a machine stops for 8 minutes and your downtime detection has a 5-minute polling interval, you’ll miss events shorter than 5 minutes entirely. Those “invisible” micro-stoppages often account for 10–20% of total availability loss.

With the Edge Gateway subscribing to machine state signals in real time (OPC-UA subscriptions deliver events within milliseconds of the state change), we capture micro-stoppages accurately. We’ve seen plants discover that their real OEE was 12 percentage points lower than their paper-based number — almost entirely from micro-stoppage accumulation that was previously invisible.

What we learned from the first deployments

The biggest surprise was how heterogeneous real factories are. We expected OPC-UA and MQTT — we got those, plus Modbus TCP on some older equipment, direct database reads on some HMIs, and one customer whose machines only had a dry-contact output for “running / not running.”

The architecture needed to be extensible. Today the Edge Gateway ships with OPC-UA, MQTT, and a REST polling adapter. The design makes it straightforward to add new protocols as connectors without changing the core — the connector just needs to produce a normalized event stream that the mapping layer can consume.

The second surprise was the IT/OT boundary. Many factories have strict network segmentation between operational technology (OT, the factory floor network) and information technology (IT, the corporate network where cloud services live). The Edge Gateway’s outbound-only connection model — it initiates connections to the cloud, never the reverse — satisfies most OT security requirements without requiring firewall exceptions for inbound traffic.

The result

A typical Qontiv deployment connects the first machine in less than two hours. For factories with standardized MQTT infrastructure, onboarding an entire line is an afternoon. For legacy equipment requiring custom protocol adapters, we provide a supported extension path that doesn’t require upgrading the core platform.

We think machine connectivity should be a solved problem, not a multi-month integration project. The edge-first architecture is our answer to that.

Want to see the Edge Gateway in action? Request a demo and we’ll show you how it connects to your specific equipment.