Choosing the Right Data Collection Path: Drivers, OPC UA and MQTT

There is no single right answer to "how do we move plant data to the cloud?" Device diversity, distance, bandwidth and the question of who consumes the data all shape the architecture. This article compares the three main collection paths, their strengths and typical use cases.

1. Direct Drivers: One Platform for a Heterogeneous Field

When Siemens, Allen-Bradley, Mitsubishi, Modbus-compatible devices and CNC machines share the same floor, building a separate solution per vendor protocol is unsustainable. Kepware Server connects through 150+ drivers on one platform and translates the data into open standards such as OPC UA.

  • Best when: heterogeneous device park, many local protocols, feeding SCADA and MES from a single point.
  • Strengths: breadth of local protocol support and centralized configuration.

2. OPC UA: Standardized, Meaningful Access

OPC UA carries not just values but their meaning through information models. It works in a client-server model and standardizes certificate-based security. It is the de facto bridge between OT and IT.

  • Best when: a common language is required between systems of different vendors, and secure access is mandatory.
  • Strengths: vendor neutrality, security model, rich data modelling.

3. MQTT and Sparkplug B: Lightweight Publish/Subscribe

When the consumer lives in the cloud or the network is constrained, publish/subscribe fits better than client-server. MQTT is lightweight and naturally suited to streaming; Sparkplug B adds a common data model on top. The IoT Gateway plug-in of Kepware Server publishes collected field data through a broker.

  • Best when: remote sites, limited bandwidth, cloud analytics, many subscribers.
  • Strengths: bandwidth efficiency, loosely coupled architecture, scalability.

Decision Criteria

  • Device diversity: many different protocols → start with the driver layer (Kepware Server).
  • Distance and network: local network → client-server (OPC UA); WAN and cloud → MQTT.
  • Data model needs: if consumers cannot resolve meaning (context, units, state) themselves, Sparkplug B or an OPC UA information model is required.
  • Security requirements: OPC UA brings certificate-based security as standard; on the MQTT side configure TLS and authentication.
  • Enterprise systems: OPC Router bridges SQL, MES and ERP without code.

In practice the most common healthy outcome is a hybrid architecture: field data is collected by Kepware Server, enterprise systems are fed over OPC UA, and the cloud and analytics stream is published over MQTT. For Sparkplug B details see our article.

To discuss your architecture contact us; see the Kepware Server and OPC Router pages for product details.

Sources