Databricks manufacturinggids
OEE-analytics bouwen op Databricks voor voedingsproductie
Bouw uitlegbare OEE op vanuit productievensters, machine-events, ideal rates en kwaliteitsoutput — en drill vervolgens vanuit de score naar de onderliggende verliezen.
OEE
73.1%
Grootste verlies
86 min beschikbaarheid
45 min materiaalwachttijd
Machinestatus
06:00 → 14:00
OEE-model
De formule is eenvoudig; het datacontract is moeilijk
OEE wordt pas betrouwbaar wanneer planned time, ideal rate en good output consistent zijn gedefinieerd voor dezelfde productiecontext.
Beschikbaarheid
82%
Draaitijd / geplande tijd
Vereist geplande vensters en betrouwbare stopclassificatie.
Performance
91%
Werkelijke / theoretische output
Vereist een verdedigbare ideale snelheid per product en lijn.
Kwaliteit
98%
Goed / totale output
Vereist consistente scope voor afkeur, rework en output.
OEE
73.1%
Eén governed score
Alleen nuttig wanneer alle drie de inputs dezelfde operationele werkelijkheid beschrijven.
Het belangrijke deel is niet de vermenigvuldiging. Het is overeenstemming bereiken over wat geldt als geplande tijd, ideale performance en goede output voordat de KPI wordt gepubliceerd.
OEE-datamodel
OEE heeft tijd, state, rate en output nodig binnen één runcontext
Bereken OEE niet uit één MES-export wanneer geplande tijd, ideal rate of kwaliteitsdefinities afhangen van ERP en beheerde masterdata.
Productieruncontext
Lijn 4 · Shift A · Order 4711 · Product P-204
Gepland venster
480 geplande min
Machinestatus
Event-timehistorie
Productieorder
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
Ideale snelheid
1,450 kg/h · Line 4 × Product P-204
effective-dated standard
Verliesreden
Material wait → Availability
reason hierarchy and category
Een betrouwbaar runmodel houdt event time, ordercontext, output en ideal rate voldoende gescheiden om te traceren, maar voldoende uitgelijnd om overal dezelfde OEE-definitie te berekenen.
Verliesanalyse
Ga van één score naar de verliezen erachter
OEE wordt actionable wanneer operations de score kan terugvertalen naar minuten, hoeveelheden en verliesredenen.
Lijn 4 · Shift A
Waar geplande productietijd naartoe ging
OEE
73.1%
− 86 min availability
− 35 min performance
− 8 min quality
Beschikbaarheidsverlies
86 minuten om uit te leggen
Drillpad
OEE → Availability → Material wait → MES run R9834 → Order 4711 · Lijn 4 · Shift A
OEE-definities
Stem de operationele regels af voordat je OEE berekent
Reiniging, omstellingen, microstops en rework worden pas OEE-verliezen nadat de operationele definitie is afgestemd.
| Event | OEE-behandeling | Regel om af te spreken |
|---|---|---|
| Reiniging | Geplande uitsluiting of Availability loss | Stond de lijn ingepland om te produceren? |
| Omstelling | Beschikbaarheidsverlies of geplande allowance | Is standaard omsteltijd al opgenomen in geplande capaciteit? |
| Microstop | Beschikbaarheids- of performanceverlies | Welke tijdsdrempel definieert een stop? |
| Rework | Kwaliteitsverlies- of recoveryflow | Wanneer wordt gereworkt materiaal goede output? |
Het doel is geen universele OEE-definitie. Het doel is één expliciete, governed definitie dat ieder dashboard en iedere consumer kan hergebruiken.
Hoe Food For Analytics OEE implementeert
Hoe we OEE in Titan op Azure Databricks implementeren
In Titan scheiden we bronevidence, manufacturing-context en businesslogica. Azure Databricks levert de lakehouse-fundering; Titan zet productiesignalen om in governed OEE-dataproducten die herbruikbaar zijn voor rapportage, analytics en AI.
Leg het productiebewijs vast
Titan ingest de operationele signalen die nodig zijn om productieruns te reconstrueren en OEE te berekenen vanuit bronbewijs.
Titan-principe
Bewaar voldoende bronhistorie om runs, correcties en late productie-events opnieuw af te spelen.
Bouw de manufacturingcontext
Titan verbindt machine-events met productieorder, lijn, product, ploeg, ideale snelheid en governed verliesdefinities die nodig zijn om OEE consistent te berekenen.
Gebouwd op Azure Databricks
Delta Lake · Lakeflow · Unity Catalog
Publiceer een OEE-dataproduct
Titan publiceert OEE op een stabiele productie-run-granulariteit samen met de verliezen die nodig zijn om te verklaren waarom performance veranderde.
Herbruikbare output
Hetzelfde governed OEE-dataproduct kan Power BI, SQL, analytics en Ask Titan bedienen.
Verwerking
Stem latency af op de beslissing
We gebruiken standaard triggered processing en alleen continuous processing wanneer een actualiteit van seconden tot minuten de operationele beslissing daadwerkelijk verandert.
Datamodel
Houd run- en loss-granulariteit expliciet
OEE op runniveau en gedetailleerde verliezen blijven gescheiden zodat downstreamapplicaties raw machine-eventlogica niet opnieuw hoeven op te bouwen.
Semantiek
Definieer OEE één keer
Governed metric-definities houden OEE consistent wanneer dezelfde data wordt gebruikt door dashboards, analytics of AI.
FAQ
Veelgestelde vragen
Praktische antwoorden over het bouwen van governed, uitlegbare OEE-analytics op Databricks.
Hoe wordt OEE berekend?
OEE is Availability × Performance × Quality. De formule is eenvoudig; het moeilijke deel is overeenstemming over planned production time, ideal rate, good output en exclusion rules en die definities consistent toepassen.
Welke systemen zijn nodig voor OEE?
Typische inputs zijn geplande productievensters, MES- of PLC-run/stop-events, productieorders, product-lijn-targetsnelheden en goede of afkeurhoeveelheden. Afhankelijk van de fabriek kunnen die facts uit ERP, MES, PLC, SCADA, kwaliteitssystemen of governed masterdata komen.
Moet geplande downtime worden uitgesloten van OEE?
Alleen wanneer de operationele definitie dit buiten planned production time plaatst. Cleaning, changeovers, pauzes en planned maintenance moeten expliciet worden behandeld omdat inconsistente uitsluitingen OEE onvergelijkbaar maken tussen lijnen en rapporten.
Kan OEE near-real-time op Databricks worden berekend?
Ja. Machine-events kunnen incrementeel of continu worden verwerkt, maar de execution mode moet de beslissing volgen. Geplande of triggered refreshes zijn vaak voldoende voor shift- en managementanalyse, terwijl zichtbaarheid binnen seconden tot minuten continuous processing kan rechtvaardigen.
Waarom kan OEE Performance boven 100 procent uitkomen?
Performance boven 100 procent is vaak een diagnostisch signaal in plaats van iets om te verbergen. Controleer ideal rates, unitconversies, dubbele tellingen en product-lijnmappings voordat u een presentatiecap toepast.
Hoe moeten late machine-events en correcties worden verwerkt?
Bewaar event time apart van ingestion time, houd replaybare bronhistorie en ontwerp het OEE-model zodat late events, gecorrigeerde reason codes en quality postings opnieuw kunnen worden verwerkt zonder traceerbaarheid te verliezen.
Waar moet de OEE-definitie staan in Databricks?
Houd sourcereconciliation en run-level facts in governed dataproducten. Herbruikbare measures zoals Availability, Performance, Quality en OEE kunnen vervolgens via gedeelde semantische definities, zoals Unity Catalog metric views, beschikbaar worden gemaakt wanneer meerdere BI- en AI-consumers dezelfde logica nodig hebben.
Praktische laag
Zet OEE om in een loss model dat operations kan vertrouwen
Start met één lijn of productiegebied, spreek de operating rules af en bouw het drillpad van OEE naar minuten, hoeveelheden en oorzaken.
Alles begint met één concrete businessvraag
Eén lijn
Voldoende om eventdekking en operationele regels te valideren.
Eén governed OEE-contract
Beschikbaarheid, Performance, Kwaliteit en uitsluitingen.
Eén loss-drillpad
Van score naar reden naar productiecontext.