Production Data Acquisition: PDA, MDA & Brownfield Reality

What production data acquisition actually is — and why the term is used to mean five completely different things depending on who is speaking

Production Data Acquisition (PDA) is the systematic, near-real-time collection of data from manufacturing processes — machine states, quantities, times, process values, operator confirmations, quality results, energy consumption — together with the context that makes those measurements interpretable: which order, which product variant, which shift, which operator, which tool. The English term is an umbrella; the German terminology it translates is sharper. In German-speaking industry, Produktionsdatenerfassung (PDE) is the deliberate superset of Maschinendatenerfassung (MDE — machine data acquisition), Betriebsdatenerfassung (BDE — operational/personnel data acquisition), and Prozessdatenerfassung (process data acquisition for continuous process values). PDA is what you call the whole, when you want to talk about the whole.

I have spent 35 years building the "whole" — since 1991, when my first job was to make Simatic S5 controllers report warehouse movements to a host system that had never been designed to receive them. Everything that has changed since then — S7, TIA Portal, OPC UA, MQTT Sparkplug B, IoT gateways, cloud MES platforms — has changed the tools, but not the problem. The problem is, and has always been: how do you get data out of a machine that was not designed to give it to you, in a form that downstream systems can actually use, at a rate that is useful, with timestamps you can trust, in a structure that survives when the machine is replaced, without requiring a PLC engineer every time you want a new signal? This article is about the practice of answering that question, from the perspective of someone who has been doing it continuously since before OPC existed.

PDA, MDE, BDE, Process Data — the German terminology tangle, resolved

The terminology confusion is not linguistic; it is historical. Each term was coined when a different technology generation solved a different part of the problem. The result is a vocabulary where every practitioner means something slightly different by the same word. Here is the resolution that has survived contact with 500+ real factories:

The practical rule: if a vendor says "we do MDE" they usually mean automatic counter/state capture from PLCs. If they say "we do BDE" they usually mean operator terminals with reason-code entry. If they say "we do PDA" they mean all of it, done consistently, with the contextual enrichment that makes the raw data useful. The failure mode I have seen most often in mid-market manufacturing is a factory that has "MDE" (from a machine vendor), "BDE" (from an ERP add-on), and "process data" (in a local historian) — three islands, never joined, each correct in isolation and useless in combination. A proper PDA architecture is the discipline of joining them; the data-acquisition technology is the smaller half of the problem.

The ISA-95 equipment hierarchy — the data model that makes PDA survive twenty years

The single most consequential early decision in any PDA project is the asset hierarchy — the way equipment is named, nested, and referenced. Get this right and every subsequent signal has a clean place to live. Get it wrong and you will spend the next ten years debugging why "machine 47" in the MES is a different physical asset than "machine 47" in the CMMS. The ISA-95 (IEC 62264) equipment hierarchy is the canonical model, and it works:

Every signal captured by PDA should be tagged against this hierarchy — not against a free-text machine name. When "Press SC-03" is replaced by a new machine three years later, the historical data stays connected to the logical work unit. When a new signal is added ("hydraulic oil temperature"), it has a structurally correct place to attach. When a CMMS maintenance order is issued, the same asset ID is used. When the ERP reports a production order on work centre "Stamping line 3", the PDA data aggregates correctly. A PDA project that skips ISA-95 hierarchy modelling in week one is a PDA project that will be rebuilt in year three — I have seen this happen often enough that it is no longer surprising. The ISO-equivalent KPI model is VDMA 66412-1; the German VDI 5600 reference architecture references both.

The protocol taxonomy — twelve protocols you will meet in a mid-market plant, and where each one belongs

A modern German Tier-1 or mid-market plant is protocol-heterogeneous in a way that outsiders underestimate. In a single factory I have connected, in one project, fourteen distinct communication protocols. The taxonomy below is what has survived contact with those factories:

The architectural rule I apply on every project: prefer the semantically richest protocol available at each asset. If the machine offers OPC UA with a proper information model, use it. If it offers OPC UA with only raw tags, use it but build the information model in the gateway. If it offers only S7 native or Modbus, use that and add context in the gateway. If it offers nothing — and a surprising number of mid-market machines offer nothing — fall back to digital I/O tapped from the control cabinet, without modifying the PLC. The goal is never protocol purity; the goal is the signal, with correct timestamps and correct asset context.

The brownfield connection matrix — seven strategies for machines that were never designed to give you data

Every publication about "Industry 4.0 data acquisition" eventually shows the same picture: a modern machine with a neat OPC UA endpoint and a cloud arrow. This is honest for about 20 % of real mid-market production. The other 80 % is brownfield — machines installed between 1985 and 2015 that have either no digital interface, a digital interface the original OEM long stopped supporting, or a PLC program that the original integrator left the country with. The practical question is not "which protocol" but "how do I extract a usable signal from this machine without modifying the PLC, without stopping production, without requiring a PLC engineer, and without voiding the warranty?" There are seven answers that, between them, have covered every brownfield scenario I have encountered in 35 years:

The single most consequential insight from three decades of these projects: option 2 — the passive digital-I/O tap — is almost always available, almost always fast to install, almost always accepted by the maintenance department, and almost always ignored in favour of attempts to use options 1 or 5. A parallel-wire on a 24 V counter output, installed by an electrician in under an hour during a planned shutdown, no PLC change, no OEM involvement, no warranty issues, and the machine is connected. The pattern I call The Ghost-PLC Retrofit is the opposite: a multi-month project to read PLC tags through an OEM that no longer exists, via documentation that was never written down, that ends with option 2 anyway — after six months of wasted effort. If you remember one rule from this article: when in doubt, tap the 24 V.

The edge gateway — the architectural element that separates functional PDA from broken PDA

Whatever protocol is used at the machine side, the data almost always passes through an edge gateway before reaching the MES or cloud. The gateway is not optional infrastructure; it is the element that translates, buffers, enriches, synchronises, and secures the data flow. A PDA architecture without a proper gateway layer will fail in one of five predictable ways: dropped samples when the network hiccups, duplicate events when the MES reconnects, clock drift when the PLC is hours off, context loss when an event arrives without order context, protocol incompatibility when the plant adds a non-conforming machine. The gateway solves all five, and must be architected to solve them explicitly:

The SYMESTIC architecture implements all of this in the edge-gateway layer that feeds the cloud MES; the same architectural pattern is used by every production-grade cloud-MES vendor I respect. The question worth asking during any PDA vendor evaluation is not "what protocols do you support" but "show me the gateway spec: buffering size, time-sync mechanism, Sparkplug-B support, asset-hierarchy model, security posture, update mechanism." The answer separates mature PDA architectures from marketing materials.

Polling, event-driven, subscription — the three timing models, and why picking the wrong one wastes half your bandwidth

The antipattern I call The Polling Trap is the default of polling every tag every 250 ms "because faster is better." The result is 80 % of the traffic being identical repeats of a value that has not changed, and 20 % being real updates — often arriving 125 ms after the event they represent. On an OPC UA server, a properly configured subscription with a 100 ms publish interval and change-of-value deadband delivers every change within milliseconds of its occurrence, with 1/10th the traffic. The only scenario where polling is correct is when the source protocol (Modbus, classical S7, OPC DA without SUBSCRIBE) does not support push — and even then, the polling cadence should be matched to the actual signal dynamics, not to "fast".

Timestamp discipline — the silent killer of PDA data quality

Every event in a PDA system carries at least two timestamps: the source time (when the event occurred, ideally from the PLC clock) and the ingest time (when the cloud MES received it). The two are almost never equal, and confusing them produces errors that compound silently. The source time is the ground truth for OEE calculations — if a downtime event is labelled with ingest time and the gateway was offline for 15 minutes, the OEE for that period will count 15 minutes of availability that did not exist. The ingest time is the ground truth for audit and replay — if you need to reconstruct the exact sequence of cloud-side events, only ingest time is reliable. A mature PDA system stores both, and computes KPIs against source time.

The clock-synchronisation problem is larger than it appears. PLCs that have not been NTP-synchronised against a reliable source drift — I have measured factory PLCs that were 47 minutes off wall clock after three years of uninterrupted operation. A PDA architecture that trusts the PLC clock without periodic re-synchronisation is storing data with systematic time errors that will only be noticed when someone tries to correlate it against an energy meter that was correctly synchronised. The practical rules:

• Every gateway runs NTP against two redundant time servers. Drift tolerance: < 10 ms.
• High-precision applications use PTP (IEEE 1588) — sub-millisecond across the gateway fabric. Required for cycle-time measurements at < 100 ms granularity, acoustic monitoring, or any cross-machine correlation at fine resolution.
• PLC clocks are re-synchronised periodically from the gateway, or the gateway stamps events at ingest and records the PLC-reported time as metadata, not as the canonical source time.
• Every event carries ingest time as well as source time, even if source time is the default for KPI calculations. The ingest-time trail is how you debug data-quality issues later.

Data-quality pathologies — five failure modes that every PDA system encounters, and what they look like

From one of the SYMESTIC retrofit projects in the early 2000s: a medium-size German beverage filler had decided to replace their Simatic S5 line controller, in place since 1993, with S7 on TIA Portal. The migration was straightforward on the PLC side; the interesting part was the data reconciliation. The old S5 program had been reporting production figures to an ERP through a custom serial link, and those figures had been the factory's "official" production record for twelve years. When we installed a fresh S7 program with modern counters, and in parallel installed a passive digital-I/O tap on the bottle-counting photocell as a second independent source of truth, the two numbers diverged on day one by 14 %. The old S5 count was consistently higher. The investigation took about a week. What had happened was this: the S5 cycle-counter routine, written in 1993 by a programmer who had long since left the business, used a software flag that was supposed to reset on emergency-stop. The reset had a subtle logic bug — it cleared the flag but not the associated accumulator, so every emergency stop on that line for twelve years had resulted in the previous cycle's count being added to the accumulator a second time when production resumed. Over twelve years, roughly 80 emergency stops per year, an average of 14 bottles double-counted per stop — that is where the 14 % came from. The plant had been reporting 14 % more output than it had actually produced for over a decade. The sales team had been selling against that phantom capacity. The maintenance budget had been allocated against machine run-times that were systematically overstated. The OEE numbers on the pride-of-the-plant wall chart had been wrong, in the positive direction, for longer than most of the operators had been at the company. Nobody had done anything wrong — the S5 program was operating exactly as written, and nobody had looked at the cycle-count logic since 1993. This is The Lying Counter in its purest form, and it is the reason I tell every new customer the same thing in project kickoff: the first month of PDA data is not for KPI reporting. The first month of PDA data is for discovering what your previous data was wrong about. The OEE numbers will go down — not because the factory got worse, but because you finally know what the factory is actually doing. The companies that understand this and do not fire the first PDA project because "the numbers got worse" are the companies that get real value from PDA. The companies that react to the drop in reported OEE by demanding that the PDA be "recalibrated" to match the old numbers are the companies that will repeat the twelve-year error for another twelve years. This is the single most important cultural discipline for any PDA deployment, and it has nothing to do with the technology.

FAQ

What is production data acquisition in one sentence?
Production data acquisition is the systematic, near-real-time collection of manufacturing data — machine signals, operator confirmations, process values, quality results, energy — together with the order, shift, and product context that makes those measurements interpretable, as the foundation for OEE, traceability, and all downstream MES functions.

What is the difference between PDA, MDA, and BDA?
MDA (Maschinendatenerfassung) is automatic data from machines; BDA (Betriebsdatenerfassung) is manually entered or operator-confirmed data; PDA (Produktionsdatenerfassung) is the superset covering both plus process data, quality data, and energy — with full context enrichment. Most modern implementations simply say "PDA" and include everything under that umbrella.

Do I need PLC programming skills to deploy PDA?
In modern architectures: almost never. The passive digital-I/O tap (strategy 2 in the brownfield matrix above) does not touch the PLC. OPC UA and MQTT Sparkplug B subscriptions are read-only. The common misconception is that PDA requires "opening the PLC" — it almost never does. The few cases where it is required (custom signal generation on a legacy PLC) are edge cases; the 95 % case is read-only, passive, non-invasive.

What is the right polling rate for PDA?
It depends on the protocol. For OPC UA or MQTT: use subscription (change-of-value), not polling. For Modbus or classical protocols where polling is unavoidable: match the cadence to the signal dynamics — cycle counters at 100-500 ms, state signals at 1 s, energy and temperature at 1-10 s, slow process values (tank levels) at 30 s or longer. Polling every signal at 250 ms "to be safe" is The Polling Trap and wastes bandwidth with duplicate values.

What is The Ghost-PLC Retrofit?
The antipattern of spending months attempting to extract signals from an undocumented legacy PLC — reverse-engineering the data blocks, hunting down the original integrator, trying to reconstruct the original TIA Portal project — when a passive 24 V digital-I/O tap on a counter output, installed by an electrician in under an hour, would have produced the same signal on day one. The pattern is eliminated by brownfield-first thinking: before opening the PLC, ask whether the required signal can be extracted electrically without touching the PLC program. In most cases it can.

What is The Lying Counter?
The failure mode in which a cycle counter reports incorrect counts — because it rolls over at a smaller integer than expected, resets on PLC restart without notifying the consumer, increments during non-productive modes (CIP, test runs, emergency-stop recovery), or contains a logic bug in the underlying PLC program that has been silently corrupting production figures for years. Detected by independent cross-check (a second independent counter source — typically a photocell tap) at every new PDA deployment; corrected by computing deltas in the gateway, combining cycle signals with running-state signals, and always auditing new PDA data against old "official" figures in the first month.

How does PDA relate to OEE?
PDA is the data foundation; OEE is the calculation that sits on top of it. Availability requires run-time and planned-production-time signals; performance requires cycle counts and cycle-time baselines; quality requires good-part counts and scrap counts. Without reliable PDA, OEE numbers are either manually estimated (wrong) or automated on top of The Lying Counter (confidently wrong). A proper OEE implementation is always a proper PDA implementation first.

Do I need an MES for PDA?
Strictly speaking, no — standalone PDA/historian systems exist. But as soon as the data needs to be linked with order context (ERP), quality context, traceability, shift structure, or cross-site aggregation, an MES is the more efficient path because data acquisition and application logic live in the same system. For most mid-market manufacturers, the practical answer is: deploy PDA and MES together, from the same vendor, with the PDA layer engineered as an integrated capability rather than a bolted-on data feed.

How does PDA fit with audit trail and regulatory requirements?
Complementary. PDA captures what happened on the shop floor; the audit trail captures every change to the PDA configuration (which tags are captured, against which asset, with which calculation). For regulated industries (pharma packaging, automotive quality) both are required: PDA provides the manufacturing record, the audit trail provides the evidence that the record itself has integrity. For a deeper treatment see the dedicated audit-trail article.

Which PDA protocols should a greenfield factory standardize on?
OPC UA at the machine side, MQTT Sparkplug B at the cloud-ingest side, Euromap 77 for plastics, MTConnect for CNC where available. All four use OPC UA information models as their backbone (Euromap 77 explicitly; MQTT Sparkplug B structurally). A greenfield PDA architecture that standardizes on OPC UA + Sparkplug B will not be replaced in the next fifteen years; everything else is either legacy (polling protocols) or still maturing (specialist protocols in niche industries).

Related: MES: definition, functions & benefits · MDE (Maschinendatenerfassung) · BDE (Betriebsdatenerfassung) · OEE · MES software compared · MES requirements specification · MES RFP · Audit trail · E2E traceability · Industrial data historian · Control plan in automotive · Finite scheduling vs. APS · Change control · Downtime reason catalog · Schedule adherence · Shop floor control · Composable MES · MESA-11 · Alarm management · Recipe management · Digital shift log · A3 problem solving · Process documentation · Process data · Production metrics · Alarms · Production control · For production managers · For maintenance managers. External references: ISA-95 / IEC 62264 (Enterprise-Control System Integration) · OPC Foundation — OPC UA · Eclipse Sparkplug B specification · Euromap 77 (OPC UA for injection moulding) · MTConnect Institute · VDMA 66412-1 (MES KPIs) · VDI 5600 (MES reference architecture).

About the author

Martin Brandel

MES Consultant at SYMESTIC. 35+ years in industrial automation and machine data acquisition. Dipl.-Ing. Nachrichtentechnik. Connecting machines to higher-level systems since 1991 — from Simatic S5 warehouse-management projects at Ing.-Büro Jürgen Albert (1991–1995), through paint-line commissioning in Eastern Europe and China at Hermos AG (1995–2000), to fifteen years as Head of Automation Engineering at SYMESTIC (formerly ODEVIS) where the Siemens S5→S7/TIA retrofit practice and the process-control standards for the German beverage and wood industries were built. Since 2019: MES Consultant leading end-to-end projects from first call to go-live across mixed-vintage plants with machines from the 1980s next to 2020s OPC UA servers. Expertise: MDE / BDE / PDA, brownfield machine integration, PLC programming (Simatic S5, S7, TIA Portal), Simatic S5→S7 retrofit without production interruption, OPC UA, MQTT Sparkplug B, IoT-gateway architecture, process control systems, material-flow control, industrial automation, MES project management, process engineering, CE conformity. · LinkedIn