General analytics
AuraScore 81/100

OEE Loss Attribution and Telemetry Analytics Framework

Architect a diagnostic analytics framework to decompose OEE degradation into availability, performance, and quality root causes.

Use this template when plant production lines experience recurrent unplanned downtime or micro-stops and require an enterprise analytics framework to isolate root causes across SCADA and MES telemetry. It establishes a multi-tiered diagnostic system to correlate asset health signals with availability loss.

Template

Role: Principal Industrial Data Architect with 15+ years specializing in discrete manufacturing telemetry and asset analytics.

Context

  • Manufacturing Site: {{plant_facility_name}}
  • Focused Production Asset: {{target_production_line}}
  • Current Performance Baseline: {{oee_baseline_metrics}}
  • Connected Telemetry Systems: {{telemetry_data_sources}}
  • Historical Event Log Window: {{unplanned_downtime_logs}}
  • Target Threshold Objective: {{target_availability_threshold}}

Task

Synthesize an advanced industrial analytics framework that ingests heterogeneous operational telemetry to decompose Overall Equipment Effectiveness (OEE) losses into precise, deterministic availability, speed, and quality failure signatures, delivering actionable mitigation pathways for plant engineers.

Method

  1. Map all raw sensor streams from {{telemetry_data_sources}} into unified time-series events aligned with machine states across {{target_production_line}}.
  2. Ingest {{unplanned_downtime_logs}} to classify historical outages into chronic micro-stoppages versus acute catastrophic downtime.
  3. Benchmark current availability, performance, and yield metrics against {{oee_baseline_metrics}} to calculate net loss attribution vectors.
  4. Design a multi-layer analytical data pipeline detailing edge aggregation, event-frame generation, and contextual data-lake modeling.
  5. Establish diagnostic heuristics linking temperature, vibration, and torque spikes to specific mechanical degradation modes.
  6. Formulate a root cause Pareto prioritization logic ranked by financial impact, downtime duration, and recovery complexity.
  7. Construct predictive alert boundary rules designed to reach {{target_availability_threshold}} within {{plant_facility_name}}.
  8. Define verification metrics to audit post-intervention OEE uplift against baseline sensor drift.

Constraints

  • MUST anchor all loss calculations in standard industrial OEE formulas (Availability x Performance x Quality).
  • MUST NOT propose generic software without defining physical sensor integration and edge-to-cloud schemas.
  • Analysis MUST explicitly isolate false alarms caused by sensor noise from genuine mechanical degradation.
  • Operational recommendations must adhere strictly to standard shift handover intervals and maintenance protocols.

Output format

Provide a structured analytics framework document with the following exact markdown sections:

  1. Executive Telemetry & OEE Topology (max 250 words)
  2. Data Ingestion & Event Schema Architecture (tabular overview of streams, frequency, and transformations)
  3. Three-Tier Loss Attribution Logic (step-by-step mathematical and diagnostic rules)
  4. Threshold & Predictive Alerting Matrix (minimum 4 distinct failure signatures with thresholds)
  5. Validation & Governance Protocol (implementation timeline and validation gates)

Self-review

  • Ensure all 6 context variables are actively utilized in analytical equations or architectural stages.
  • Verify that edge-level micro-stops are mathematically distinguished from planned setup downtime.
  • Check that the output provides deterministic rules rather than speculative hypotheses.
AuraScore breakdown
81/100Provisional
Instruction clarity15/15 · Strong

Explicit role, a named task, and discrete steps the model can follow.

Context architecture12/12 · Strong

Background, inputs and variables the model needs before it starts.

Constraint engineering12/12 · Strong

Hard boundaries — what the model must and must not do.

Output specification6/14 · Thin

A named, field-level shape for the response.

Reasoning structure10/10 · Strong

Ordered work items that force analysis before an answer.

Model compatibility10/10 · Strong

Length and structure that travel across frontier models.

Token efficiency5/10 · Thin

Signal density — instruction weight without padding.

Reusability7/7 · Strong

Documented variables so the scaffold adapts to new inputs.

Robustness3/5 · Adequate

Quality bar, assumptions and behaviour when inputs are thin.

Observed performance1/5 · Thin

How much real usage the template has behind it.

data-analytics
data-general
manufacturing-industrial
oee
telemetry
scada