Industrial Data Acquisition System: What It Is, Architecture and How to Choose One

An industrial data acquisition system (DAQ) is the combination of hardware and software that captures signals from a plant's machines, sensors, meters and controllers and turns them into usable digital data: with a name, a unit, a timestamp and a reliable channel to whoever needs them. It is the first layer of any plant data project: if acquisition fails, everything built on top (dashboards, KPIs, AI models) inherits the failure. In this guide we look at its components, why the decisive requirement is multi-protocol support, which criteria to use when choosing one and how it fits into an industrial data platform.

What an industrial data acquisition system is

On a shop floor, data is born analogue or locked away: a temperature is a voltage across a thermocouple, an electricity consumption is a register inside a meter, a part count is a variable in a PLC's memory. The data acquisition system is the bridge between that physical world and the digital one: it reads each signal over the appropriate medium, digitises it where needed, identifies it and delivers it continuously and in order.

A complete industrial DAQ does four things, always in this order:

Capture. Read the source signal: a Modbus register on a drive, an OPC UA node on a modern machine, a sensor output or the load profile of an electricity meter.
Convert. Move from raw value to engineering magnitude: apply scaling, unit and data type. A register holding 4523 is useless until someone decides it means 45.23 degrees.
Contextualise. Add the capture timestamp and the signal's identifier within an asset hierarchy: plant, line, machine, signal.
Deliver. Publish the data to the system that consumes it (historian, broker, platform) with guarantees that nothing is lost along the way.

The key word is continuous. A manual CSV export every Friday also "acquires data", but it is not an acquisition system: it is a chore. The DAQ turns capture into infrastructure, with the same reliability demanded of the electrical installation.

Laboratory DAQ vs plant DAQ

The term DAQ comes from the world of testing and laboratories: acquisition cards with high-sample-rate analogue inputs, connected to a PC recording an experiment bounded in time. That equipment exists and remains the right tool for a test bench or a one-off measurement campaign.

The plant DAQ solves a different problem. Signals are usually already digitised inside PLCs, drives, meters and SCADA systems; the challenge is not sampling fast but reading many heterogeneous devices, from different manufacturers and different decades, without stopping production and without losing data over years. The priorities shift: multi-protocol support matters more than sample rate, continuous operation matters more than laboratory precision, and tolerance to network outages matters more than bandwidth. This guide covers this second case, which is the one a factory meets when it digitalises.

Architecture: from signal to usable data

A modern plant acquisition system is organised as a chain of four links:

1. Sources. Everything that produces a signal: PLCs and controllers, hardwired or IO-Link sensors, energy meters, scales, power analysers, existing SCADA systems that already concentrate part of the data. Each source speaks its own protocol and is not going to change it; that is precisely the territory of PLC connectivity and sensor connectivity.

2. Acquisition gateway. The device (industrial, usually in the electrical cabinet or the technical room) that runs the protocol drivers, polls the sources at the configured rate and performs conversion and contextualisation. It is the heart of the DAQ and where the data quality of everything downstream is decided.

3. Local buffer. Persistent storage on the gateway itself that retains data when the network or the destination is unavailable and resends it once the connection recovers. Without this link, every network incident opens a permanent gap in the historian; sizing details are in the guide to industrial edge with buffering and QoS.

4. Delivery. Publishing the already normalised data to its consumers: an MQTT broker, a time-series database, an API. From here on the data stops being an acquisition problem and becomes a platform problem.

Multi-protocol acquisition: the real requirement

If there were a single industrial protocol, data acquisition would be an off-the-shelf product. The reality of any plant with more than a decade of history is a mosaic: the new drive speaks Modbus TCP, the nineties line exposes Modbus RTU over RS-485, the recently bought machine ships with an OPC UA server, the fiscal meter answers IEC 870-5-102 and a supplier's software only offers a REST API or a CSV dump.

That is why the requirement that separates a useful plant DAQ from a decorative one is native multi-protocol support: the ability to read all those sources from the same system, with the same naming and unit configuration, without forcing the purchase of intermediate gateways for each equipment family. When the DAQ speaks the language of what is already installed, the machines are not touched and the project demands no new field hardware investment.

The choice of outbound protocol matters as much as the inbound one. The sector's general pattern is to converge on MQTT as the northbound transport, being lightweight and tolerant of imperfect networks; the comparison with the natural alternative is in OPC UA vs MQTT, and the specific case of Modbus sources is developed step by step in how to get Modbus data to the cloud.

Criteria for choosing a data acquisition system

When evaluating options, these are the questions that truly discriminate, in the order worth asking them:

Does it cover the protocols of my current fleet? Not the brochure's: the real inventory's. The list of the plant's devices and protocols is the first deliverable of any acquisition project, before choosing a tool.
What happens when the network drops? If the answer does not include persistent buffering and automatic resending, the historian will have gaps. It is the cheapest criterion to check and the most expensive to discover late.
Where does it normalise? A system that delivers raw values and leaves scaling and naming "for later" shifts the work onto every consumer. Normalisation at the source is done once; normalisation at the destination is repeated forever.
Does it write or only read? For acquisition, a system that only listens is an advantage: it does not interfere with control, the operational risk is minimal and the conversation with the production manager is short.
Where can it be deployed? On-premise, hybrid or cloud according to company policy and data sensitivity. A DAQ that imposes its own deployment architecture ends up clashing with IT or with OT.
What does it tie you to? Open formats, standard protocols and exportable data. Process data belongs to the plant; the acquisition tool is replaceable, and choosing one that accepts this is an insurance policy.

The DAQ within the data platform

An acquisition system is not an end in itself: it is the input layer of an industrial data platform, the architecture that makes data captured once serve every consumer (dashboards, MES, ERP, analytical models) without point-to-point integrations. The DAQ occupies the edge layer of that architecture, and its decisions (names, units, asset hierarchy) condition every layer above. The full picture is in the guide to the industrial data platform and on the industrial data platform hub, where we place each piece of the whole.

The practical consequence of thinking of the DAQ as a platform layer is that it is chosen looking upwards: not "which device reads my PLC" but "which system delivers my data, normalised and complete, to everything that comes next".

How Captia Connect solves it

Captia Connect is Captia's data acquisition layer: an industrial edge that captures signals from PLCs, sensors, machines, meters and existing SCADA systems, normalises them at the source and delivers them securely to the platform. In practice:

Multi-protocol acquisition. Native reading of MQTT, OPC UA, Modbus TCP, Modbus RTU over RS-485, OpenWebNet and IEC 870-5-102, plus sources via REST API, webhooks and CSV files. The existing fleet connects as it is.
Normalisation at the source. Scaling, units and naming are resolved at the edge, so each signal reaches the platform with meaning rather than as a raw register.
Local buffering and persistence without connectivity. If the network goes down, data is retained on the gateway and resent once the connection is restored: the historian has no gaps.
Secure delivery and flexible deployment. Encrypted connectivity to the destination and on-premise, hybrid or cloud deployment according to each company's policy.

On top of that reliable data works Captia.ai, the visualisation and intelligence layer: web SCADA, dashboards, rules, alerts and analytical models. The division of roles is deliberate: Connect guarantees the data; Captia.ai turns it into decisions. The combination of capture, normalisation and delivery is what in our catalogue we call edge ingestion.

Frequently asked questions about data acquisition

What is the difference between a data acquisition system and a SCADA?

The SCADA supervises and controls the process in real time: mimic screens, alarms, setpoints for the operator. The acquisition system captures and delivers data continuously for storage and analysis, without acting on the process. They coexist well: in fact, an existing SCADA is one more source the DAQ can read.

Do PLCs or sensors need replacing to acquire their data?

No, provided the acquisition system is multi-protocol. The gateway reads each device over the protocol it already speaks (Modbus, OPC UA, sensor signal, meter register) without modifying its program or interfering with its operation. The machines are not touched; they are only listened to.

What happens to the data if the cloud connection drops?

In a well-designed DAQ, nothing: the gateway stores data in a persistent local buffer and resends it automatically once the connection is restored. Capture continues during the outage and the historian stays complete. A system without this mechanism loses data with every network incident.

Where does a data acquisition project start?

With the inventory: which machines, sensors and meters exist, which protocol each one speaks and which signals carry business value. With that map, a gateway is deployed on a first line, the data is validated end to end and the rollout scales. Starting with a bounded line reduces risk and shows visible results within weeks.

If you are weighing up how to capture your plant's data without touching the machines and without tying yourself to a single manufacturer, at Captia Connect we build exactly this layer: multi-protocol acquisition, normalisation at the source and reliable delivery to the industrial data platform. The first step is an inventory of sources and signals with value.