MDE and BDE Explained: Machine and Operating Data Acquisition
MDE (Maschinendatenerfassung) is the automatic capture of machine data from the controller, such as run state, spindle activity, cycle times and alarms. BDE (Betriebsdatenerfassung) captures operating data, such as order numbers, part counts, scrap and downtime reasons. Together they feed OEE and your MES with a complete shop-floor picture.
What is MDE (Maschinendatenerfassung)?
MDE is the automatic acquisition of machine data straight from the CNC controller, with no operator typing required. It records when a machine runs, stops, faults or idles, plus signals like spindle load, feed and program state. Because it is captured continuously and objectively, MDE is the trustworthy foundation for runtime, availability and downtime analysis.
The quality of MDE depends entirely on how deep you read the controller. Surface-level standards give you a basic run/stop signal, but controller-level CNC monitoring reads native data directly from Fanuc, Siemens, Heidenhain, Haas, Mazak, DMG Mori and Mitsubishi controls. That depth means accurate cycle times, real alarm codes and precise stop timestamps, not just an estimated heartbeat.
What is BDE (Betriebsdatenerfassung)?
BDE is the acquisition of operating data that surrounds production, such as which order is running, how many good and scrap parts were made, why a machine stopped, and how long an operator spent on a task. Unlike MDE, much of this context cannot be read from the controller, so BDE traditionally relies on operator input at a shop-floor terminal.
BDE answers the questions MDE cannot: a controller knows a machine stopped, but only a person knows it stopped for a tool change, a material shortage or a planned break. BDE turns anonymous downtime into categorized, actionable reasons, and links machine activity to specific jobs, shifts and operators.
How do MDE and BDE feed OEE?
OEE combines Availability, Performance and Quality, and each factor draws on a different data source. MDE supplies machine runtime and stop time for Availability. MDE cycle counts and BDE order targets drive Performance. BDE good and scrap part counts produce Quality. Without both streams, OEE is either missing context or estimated.
A practical split looks like this:
- Availability — MDE: actual run vs. planned production time, plus categorized stops from BDE.
- Performance — MDE cycle times vs. the ideal cycle time for the active BDE order.
- Quality — BDE good-part and scrap counts confirmed by the operator.
This is why OEE built on MDE alone tends to overstate reality: it sees uptime but not scrap or order targets. For a deeper walkthrough of the metric, see OEE tracking. The widely cited world-class benchmark sits around 85 percent, but the honest first step is measuring your own baseline with both data streams.
How is BDE captured without slowing operators down?
The goal is to capture BDE with minimal typing. A modern operator terminal shows the live machine state from MDE and the active order, then lets the operator confirm part counts, log scrap, or pick a stop reason from a short list with one or two taps. Pre-filled context means operators verify data rather than enter it from scratch.
Good BDE capture follows a few principles: keep reason codes short and shop-specific, default to the active job, and tie every entry to the current MDE state so a logged stop lines up with the real machine stop on the timeline. Done well, BDE adds seconds per event, not minutes.
How does a modern system combine MDE and BDE?
A modern monitoring platform collects MDE automatically and BDE from the terminal, then merges both into one timeline per machine and per order. The operator never maintains a parallel paper log, and the office sees runtime, reasons and part counts in a single view. That combined record is what makes OEE, shift reports and order costing reliable.
From there, the unified data stream flows onward. The platform can push combined machine and operating data to your MES or ERP, so production planning and costing run on the same numbers the shop floor sees. Native machine connectors handle the MDE side across mixed controller brands, while the terminal handles BDE — one system, one source of truth.
Why does the depth of data acquisition matter?
Depth determines what you can actually do with the data. Native, controller-level MDE — not just MTConnect surface signals — gives you exact alarm codes, true cycle boundaries and precise stop timestamps, so condition-based alerts can flag developing issues from real spindle and load behavior rather than rough heartbeats. Shallow data produces shallow insight.
Standards such as MTConnect, OPC-UA, FOCAS and Modbus all have a place, and xynLog speaks them, but reading native controller data adds the granularity that surface signals miss. xynLog is EU-hosted with an on-premise option, and its plain-language AI assistant — which can run on OpenAI, Claude, or a fully on-premise Ollama model — lets you ask why a machine stopped or how a shift performed in normal language, blending MDE and BDE into a direct answer. See AI manufacturing assistant and condition-based alerts.
Want to see how MDE and BDE come together on your shop floor? See xynLog on your own CNC brand — book a demo.