Reporting
AuraScore 81/100

Factory Telemetry and Automated OEE Reporting Architecture Specification

Define technical data modeling, metric calculation rules, and visualization specs for automated shopfloor OEE reporting.

Use this specification prompt when architecting unified telemetry and downtime reporting across discrete or continuous manufacturing assets. It bridges shopfloor OT historian tags with executive and shift-level BI reporting layers.

Template

Role: Principal Manufacturing Telemetry & BI Architect with 15+ years designing enterprise industrial reporting systems.

Context

  • Manufacturing site and operational footprint: {{plant_location}}
  • Industrial automation & historian infrastructure: {{scada_historian_stack}}
  • Production lines and machine assets in scope: {{line_equipment_scope}}
  • Required report refresh rates and aggregation levels: {{target_reporting_cadence}}
  • Standard downtime taxonomy & fault tagging schema: {{downtime_categorization_standard}}
  • Target user personas and decision workflows: {{stakeholder_user_groups}}

Task

Generate a comprehensive technical reporting specification for an automated Overall Equipment Effectiveness (OEE) and machine telemetry analytics system, translating raw plant floor sensor data into auditable shift, daily, and executive reports.

Method

  1. Define ingestion pipelines from {{scada_historian_stack}} covering tag validation, deadband filtering, and edge buffering for {{line_equipment_scope}}.
  2. Formulate explicit mathematical logic for Availability, Performance, and Quality components using {{downtime_categorization_standard}}.
  3. Map micro-stoppages, planned maintenance, and unplanned breakdown events into structured reporting dimensional models.
  4. Design aggregation schedules and data roll-up mechanisms matching {{target_reporting_cadence}} for {{plant_location}}.
  5. Specify role-tailored dashboard views, alert thresholds, and anomaly indicators for {{stakeholder_user_groups}}.
  6. Detail data governance, automated sensor drift reconciliation, and missing telemetry imputation protocols.
  7. Outline export schemas, REST query endpoints, and PDF/tabular push notification parameters.

Constraints

  • MUST define exact formulaic boundaries and edge-case behaviors for shift overlaps and unclassified downtime.
  • MUST NOT leave raw OPC-UA/MQTT historian tag names unmapped to standardized semantic business dimensions.
  • Specifications MUST include explicit latency benchmarks from PLC trigger to dashboard visualization.
  • Formulas must account for scheduled unworked periods without distorting net operational availability.

Output format

Provide the specification in 5 structured sections:

  1. Executive Architecture Summary (max 200 words)
  2. Telemetry Ingestion & Metric Calculation Engine (exact mathematical definitions & pseudocode)
  3. Dimensional Data Model & Entity Relationship Schema (markdown data dictionary)
  4. Stakeholder Reporting UX & Visual Wireframe Specifications (3 distinct persona view definitions)
  5. Validation, Auditing & Failover Protocol (data quality SLAs & imputation rules)

Self-review

  • Confirm all variables from {{plant_location}} to {{stakeholder_user_groups}} are explicitly integrated.
  • Verify OEE calculation logic rigorously separates planned exclusions from unplanned availability loss.
  • Ensure reporting refresh rates adhere strictly to {{target_reporting_cadence}} requirements.
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-reporting
manufacturing-industrial
manufacturing
oee-reporting
industrial-iot