Databricks manufacturing guide
How to Build OEE Analytics on Databricks for food manufacturing
Build explainable OEE from production windows, machine events, ideal rates and quality output — then drill from the score into the losses behind it.
OEE
73.1%
Largest loss
86 min availability
45 min material wait
Machine state
06:00 → 14:00
OEE model
The formula is easy; the data contract is hard
OEE becomes trustworthy only when planned time, ideal rate and good output are defined consistently for the same production context.
Availability
82%
Run time / planned time
Requires planned windows and reliable stop classification.
Performance
91%
Actual / theoretical output
Requires a defensible ideal rate by product and line.
Quality
98%
Good / total output
Requires consistent reject, rework and output scope.
OEE
73.1%
One governed score
Useful only when all three inputs describe the same operating reality.
The important part is not the multiplication. It is agreeing what counts as planned time, ideal performance and good output before the KPI is published.
OEE data model
OEE needs time, state, rate and output in one run context
Do not calculate OEE from a single MES export when planned time, ideal rate or quality definitions depend on ERP and governed master data.
Production run context
Line 4 · Shift A · Order 4711 · Product P-204
Planned window
480 scheduled min
Machine state
Event-time history
Production order
Order 4711 · Product P-204 · Recipe R-18
planned quantity 12,000 kg
Output
10,796 kg total · 10,580 kg good
216 kg reject / rework basis
Ideal rate
1,450 kg/h · Line 4 × Product P-204
effective-dated standard
Loss reason
Material wait → Availability
reason hierarchy and category
A reliable run model keeps event time, order context, output and ideal rate separate enough to trace, but aligned enough to calculate the same OEE definition everywhere.
Loss analysis
Move from one score to the losses behind it
OEE becomes actionable when operations can convert the score back into minutes, quantities and loss reasons.
Line 4 · Shift A
Where planned production time went
OEE
73.1%
− 86 min availability
− 35 min performance
− 8 min quality
Availability loss
86 minutes to explain
Drill path
OEE → Availability → Material wait → MES run R9834 → Order 4711 · Line 4 · Shift A
OEE definitions
Agree the operating rules before calculating OEE
Cleaning, changeovers, microstops and rework only become OEE losses after the operating definition is agreed.
| Event | OEE treatment | Rule to agree |
|---|---|---|
| Cleaning | Planned exclusion or Availability loss | Was the line scheduled to produce? |
| Changeover | Availability loss or planned allowance | Is standard changeover already included in planned capacity? |
| Microstop | Availability or Performance loss | What duration threshold defines a stop? |
| Rework | Quality loss or recovery flow | When does reworked material become good output? |
The goal is not a universal OEE definition. The goal is one explicit, governed definition that every dashboard and consumer can reuse.
How Food For Analytics implements OEE
How we implement OEE in Titan on Azure Databricks
In Titan, we separate source evidence, manufacturing context and business logic. Azure Databricks provides the lakehouse foundation; Titan turns production signals into governed OEE data products that can be reused across reporting, analytics and AI.
Capture the production evidence
Titan ingests the operational signals required to reconstruct production runs and calculate OEE from source evidence.
Titan principle
Preserve enough source history to replay runs, corrections and late production events.
Build the manufacturing context
Titan connects machine events to the production order, line, product, shift, ideal rate and governed loss definitions needed to calculate OEE consistently.
Built on Azure Databricks
Delta Lake · Lakeflow · Unity Catalog
Publish an OEE data product
Titan publishes OEE at a stable production-run grain together with the losses required to explain why performance changed.
Reusable output
The same governed OEE data product can serve Power BI, SQL, analytics and Ask Titan.
Processing
Match latency to the decision
We use triggered processing by default and continuous processing only where seconds-to-minutes freshness changes the operational decision.
Data model
Keep run and loss grain explicit
Run-level OEE and detailed losses remain separate so downstream applications do not need to reconstruct raw machine-event logic.
Semantics
Define OEE once
Governed metric definitions keep OEE consistent when the same data is consumed by dashboards, analytics or AI.
FAQ
Frequently asked questions
Practical answers about building governed, explainable OEE analytics on Databricks.
How is OEE calculated?
OEE is Availability × Performance × Quality. The formula is straightforward; the difficult part is agreeing planned production time, ideal rate, good output and exclusion rules and applying those definitions consistently.
Which systems are needed for OEE?
Typical inputs are planned production windows, MES or PLC run-stop events, production orders, product-line target rates and good or reject quantities. Depending on the factory, those facts can come from ERP, MES, PLC, SCADA, quality systems or governed master data.
Should planned downtime be excluded from OEE?
Only when the operating definition places it outside planned production time. Cleaning, changeovers, breaks and planned maintenance need explicit treatment because inconsistent exclusions make OEE incomparable across lines and reports.
Can OEE be calculated in near real time on Databricks?
Yes. Machine events can be processed incrementally or continuously, but the execution mode should follow the decision. Scheduled or triggered refreshes are often enough for shift and management analysis, while seconds-to-minutes visibility can justify continuous processing.
Why can OEE Performance exceed 100 percent?
Performance above 100 percent is often a diagnostic signal rather than something to hide. Check ideal rates, unit conversions, duplicate counts and product-line mappings before applying any presentation cap.
How should late machine events and corrections be handled?
Preserve event time separately from ingestion time, keep replayable source history and design the OEE model so late events, corrected reason codes and quality postings can be reprocessed without losing traceability.
Where should the OEE definition live in Databricks?
Keep source reconciliation and run-level facts in governed data products. Reusable measures such as Availability, Performance, Quality and OEE can then be exposed through shared semantic definitions such as Unity Catalog metric views when multiple BI and AI consumers need the same logic.
Practical next step
Turn OEE into a loss model operations can trust
Start with one line or production area, agree the operating rules and build the drill path from OEE to minutes, quantities and causes.
A useful first scope
One line
Enough to validate event coverage and operating rules.
One governed OEE contract
Availability, Performance, Quality and exclusions.
One loss drill path
From score to reason to production context.