Manufacturing OEE Dashboards on Apache Superset: A D23.io Reference

Table of Contents

1. Why OEE Dashboards Matter for Australian Manufacturers
2. Understanding OEE Metrics and Their Components
3. Apache Superset as Your OEE Platform
4. D23.io Managed Stack Architecture
5. Building Your First OEE Dashboard
6. Real-Time Data Integration from SCADA and MES
7. Dashboard Design Patterns for Manufacturing
8. Performance Optimisation and Caching
9. Governance, Security, and Compliance
10. Next Steps and Implementation Timeline

---

Why OEE Dashboards Matter for Australian Manufacturers

Overall Equipment Effectiveness (OEE) is the gold standard for measuring manufacturing productivity. For Australian manufacturers operating in competitive global markets, visibility into equipment performance isn’t optional—it’s survival.

OEE measures three critical dimensions: availability (how long equipment runs), performance (how fast it runs), and quality (how many good parts it produces). A manufacturing facility running at 85% OEE is world-class. Most facilities sit between 60–75%. That gap represents lost revenue, wasted materials, and missed opportunities.

When PADISO works with Australian manufacturers modernising their operations, we’ve seen organisations recover $500K–$2M annually by fixing just the visibility problem. They weren’t necessarily running worse; they simply couldn’t see what was broken until it was too late.

A real-time OEE dashboard surfaces downtime, scrap, changeover delays, and performance bottlenecks as they happen—not in a spreadsheet three days later. This shifts your team from reactive firefighting to predictive action.

Apache Superset, deployed on D23.io’s managed infrastructure, gives you that visibility without the enterprise price tag or the 12-month implementation cycle. You can go from concept to live dashboards in 4–6 weeks, as we’ve delivered in the $50K D23.io consulting engagement for multiple Australian manufacturers.

---

Understanding OEE Metrics and Their Components

The OEE Formula

OEE = Availability × Performance × Quality

Each component is expressed as a percentage (0–100%), so OEE itself ranges from 0–100%.

Availability measures the proportion of scheduled production time the equipment actually runs:

• Availability = (Scheduled Time − Downtime) / Scheduled Time
• Typical downtime sources: unplanned breakdowns, setup/changeover, planned maintenance, material shortages, operator absence

Performance measures how fast the equipment runs relative to its theoretical maximum speed:

• Performance = (Theoretical Cycle Time × Pieces Produced) / Actual Runtime
• Performance loss comes from reduced speed, minor stops, idling

Quality measures the proportion of good parts produced:

• Quality = Good Pieces / Total Pieces Produced
• Quality loss includes scrap, rework, and defects

Why These Three Matter

Separating OEE into three metrics is crucial because they point to different root causes and solutions. A facility with 60% OEE caused by poor availability (equipment breaks constantly) needs different interventions than one with 60% OEE caused by poor quality (too much scrap).

When you surface these metrics separately on a dashboard—updated in real time—operators and supervisors can see which lever to pull. If availability dropped 5% today, someone can investigate immediately. If quality degraded on the second shift, you can correlate it with operator, material batch, or environmental conditions.

Where the Data Lives

OEE data comes from two primary sources:

SCADA systems (Supervisory Control and Data Acquisition) capture machine-level telemetry: cycle times, downtime events, fault codes, temperature, pressure. These are industrial control systems running on legacy protocols (Modbus, OPC-UA, Profibus).

MES platforms (Manufacturing Execution Systems) track production orders, material consumption, labour, quality inspections, and scrap. MES acts as the bridge between ERP and the shop floor.

Neither SCADA nor MES alone gives you complete OEE. You need both, correlated by timestamp and equipment ID. This is where most manufacturers struggle—their SCADA data lives in one silo, MES in another, and reconciling them requires custom ETL (extract, transform, load) work.

---

Apache Superset as Your OEE Platform

Why Superset, Not Tableau or Power BI?

Tableau and Power BI are excellent tools, but they’re expensive and designed for enterprise IT departments with large budgets. A Tableau seat costs $70–$140 USD per month per user. Power BI licensing starts around $10–$20 USD per user but requires significant infrastructure investment.

Apache Superset is open-source and purpose-built for modern data stacks. You own the infrastructure, control the data, and pay nothing for the software. For Australian manufacturers operating on tighter margins, this cost difference matters.

Superset also integrates seamlessly with agentic AI tools like Claude, meaning non-technical supervisors can ask natural-language questions: “Why did Line 3 downtime increase 20% this week?” and get instant answers without bothering the data team.

Superset’s Core Strengths for Manufacturing

No-Code Chart Creation: You don’t need SQL expertise to build charts. Superset’s UI lets you select a dataset, choose a metric, add filters, and publish a chart in minutes.

SQL IDE: For power users, Superset includes a full SQL editor with syntax highlighting and query optimisation suggestions. You can write complex queries to calculate OEE from raw SCADA and MES data.

Semantic Layer: Define business metrics (like OEE itself) once, then reuse them across 50 dashboards. If your OEE calculation changes, update it in one place.

Caching and Performance: Superset supports multiple caching backends (Redis, Memcached) and can pre-aggregate data, so even dashboards querying millions of rows load in under 2 seconds.

Alerts and Reporting: Set thresholds (“Alert if OEE < 75%”) and Superset will email stakeholders automatically. You can also schedule PDF reports to be sent daily, weekly, or on-demand.

Role-Based Access Control (RBAC): Different users see different dashboards and data based on their role. A plant manager sees facility-wide OEE; a line operator sees only their line.

---

D23.io Managed Stack Architecture

What D23.io Provides

D23.io is a managed Apache Superset hosting and integration platform built specifically for Australian enterprises. Instead of running Superset yourself (which requires DevOps expertise, infrastructure, patching, backups), D23.io handles all of that.

When PADISO partners with manufacturers on OEE dashboards, we deploy on D23.io’s managed stack. Here’s why:

Turnkey Infrastructure: D23.io provisions Superset, PostgreSQL (metadata database), Redis (caching), and monitoring. You get a production-ready environment in hours, not weeks.

Data Connectors: D23.io pre-builds connectors to common manufacturing data sources—Siemens, Rockwell, SAP, Oracle, Snowflake, Databricks. You don’t have to write custom API integrations.

Semantic Layer Management: D23.io helps you define OEE metrics, downtime categories, quality reasons, and other business logic as governed datasets. This becomes your single source of truth.

Audit Trail and Compliance: D23.io logs all dashboard access, query execution, and data exports. This is critical for SOC 2 and ISO 27001 audit readiness, which we discuss in detail in our security audit and compliance guide.

Australian Data Residency: Your manufacturing data stays in Australian data centres. No data leaves the country unless you explicitly export it.

Architecture Diagram (Conceptual)

┌─────────────────────────────────────────────────────┐
│  SCADA Systems (Siemens, Rockwell, ABB, etc.)       │
│  MES Platforms (Dassault, Apriso, Siemens MES)      │
│  ERP Systems (SAP, Oracle, NetSuite)                │
└────────────────────┬────────────────────────────────┘
                     │
                     │ (OPC-UA, REST API, ODBC)
                     ▼
┌─────────────────────────────────────────────────────┐
│  D23.io Data Ingestion Layer                        │
│  - Connectors (pre-built for common systems)        │
│  - ETL Orchestration (Airflow, dbt)                 │
│  - Data Validation & Quality Checks                 │
└────────────────────┬────────────────────────────────┘
                     │
                     ▼
┌─────────────────────────────────────────────────────┐
│  D23.io Data Warehouse                              │
│  - PostgreSQL (metadata)                            │
│  - Snowflake / Databricks (raw data)                │
│  - Aggregated OEE Tables (pre-calculated)           │
└────────────────────┬────────────────────────────────┘
                     │
                     ▼
┌─────────────────────────────────────────────────────┐
│  Apache Superset (D23.io Managed)                   │
│  - Semantic Layer (OEE metric definitions)          │
│  - Redis Cache (sub-2 second dashboard loads)       │
│  - RBAC (role-based access control)                 │
│  - Alerts & Scheduled Reports                       │
└────────────────────┬────────────────────────────────┘
                     │
                     ▼
┌─────────────────────────────────────────────────────┐
│  User Interfaces                                    │
│  - Superset Web UI (browsers, mobile)               │
│  - Embedded Dashboards (your internal portal)       │
│  - API (for integrations with ERP, MES)             │
│  - AI Query Interface (Claude / agentic AI)         │
└─────────────────────────────────────────────────────┘

Data flows from SCADA and MES systems through D23.io’s ingestion layer, lands in the data warehouse, gets transformed into OEE metrics, and is cached in Redis. Superset queries the cache first (sub-2 second response), then the warehouse if needed. Users access dashboards via the web UI, mobile, or API.

---

Building Your First OEE Dashboard

Step 1: Define Your Data Model

Before you build a single chart, you need clean, trustworthy data. This means:

Equipment Master Data: A table listing every piece of equipment, its location, line, plant, and theoretical cycle time.

Downtime Events: A table recording every downtime occurrence with timestamp, equipment ID, duration (minutes), and reason category (breakdown, changeover, material shortage, maintenance, etc.).

Production Runs: A table tracking each production order: equipment ID, start time, end time, pieces scheduled, pieces produced, pieces scrapped.

Quality Inspections: A table recording quality checks, defect codes, and rework decisions.

Most manufacturers already have this data—it’s scattered across SCADA, MES, and ERP. Your first 2–3 weeks of work is consolidating and cleaning it.

We typically use dbt (data build tool) to define these tables as models, version-control them, and run daily validation tests. This ensures your OEE calculations are consistent and auditable.

Step 2: Calculate OEE Metrics

In your data warehouse, create a table that pre-calculates OEE for each equipment-shift or equipment-day combination. Don’t calculate OEE on-the-fly in Superset; pre-aggregate it.

Here’s a simplified SQL example:

WITH downtime_summary AS (
  SELECT
    equipment_id,
    DATE(event_timestamp) AS event_date,
    SUM(duration_minutes) AS total_downtime_minutes
  FROM downtime_events
  GROUP BY equipment_id, DATE(event_timestamp)
),

production_summary AS (
  SELECT
    equipment_id,
    DATE(production_start_time) AS production_date,
    SUM(pieces_scheduled) AS pieces_scheduled,
    SUM(pieces_produced) AS pieces_produced,
    SUM(pieces_scrapped) AS pieces_scrapped,
    SUM(EXTRACT(EPOCH FROM (production_end_time - production_start_time)) / 60) AS total_runtime_minutes
  FROM production_runs
  GROUP BY equipment_id, DATE(production_start_time)
),

oee_calc AS (
  SELECT
    e.equipment_id,
    e.equipment_name,
    e.line_id,
    ps.production_date,
    -- Availability = (Scheduled Time - Downtime) / Scheduled Time
    ROUND(((480 - COALESCE(ds.total_downtime_minutes, 0)) / 480.0) * 100, 2) AS availability_pct,
    -- Performance = (Theoretical Cycle Time * Pieces Produced) / Actual Runtime
    ROUND((e.theoretical_cycle_time_seconds * ps.pieces_produced / 60.0) / NULLIF(ps.total_runtime_minutes, 0) * 100, 2) AS performance_pct,
    -- Quality = Good Pieces / Total Pieces
    ROUND((ps.pieces_produced - ps.pieces_scrapped) / NULLIF(ps.pieces_produced, 0) * 100, 2) AS quality_pct
  FROM equipment_master e
  LEFT JOIN downtime_summary ds ON e.equipment_id = ds.equipment_id AND ds.event_date = ps.production_date
  LEFT JOIN production_summary ps ON e.equipment_id = ps.equipment_id
)

SELECT
  equipment_id,
  equipment_name,
  line_id,
  production_date,
  availability_pct,
  performance_pct,
  quality_pct,
  ROUND(availability_pct * performance_pct * quality_pct / 10000, 2) AS oee_pct
FROM oee_calc
ORDER BY production_date DESC, equipment_id;

This query calculates OEE for each equipment-day. Run it daily via your orchestration tool (Airflow, dbt Cloud) so Superset always has fresh data.

Step 3: Create the Semantic Layer

In Superset, create a dataset that wraps this OEE table and defines business metrics:

1. Go to Data → Datasets → Create Dataset

2. Select your OEE table from the warehouse

3. Define columns:

   • Equipment ID (dimension)
   • Equipment Name (dimension)
   • Line ID (dimension)
   • Production Date (dimension, time-based)
   • Availability % (metric, aggregation: average)
   • Performance % (metric, aggregation: average)
   • Quality % (metric, aggregation: average)
   • OEE % (metric, aggregation: average)

4. Save the dataset as “OEE by Equipment and Day”

Now any dashboard can use this dataset without needing to write SQL.

Step 4: Build Your First Chart

Let’s create a simple line chart showing OEE trend over the last 30 days:

1. Create a new dashboard: Dashboards → Create Dashboard → Name it “OEE Overview”
2. Add a chart: + Chart
3. Choose dataset: “OEE by Equipment and Day”
4. Chart type: Line Chart
5. X-axis: Production Date
6. Y-axis: OEE % (average)
7. Group by: Equipment Name (so each line is a different piece of equipment)
8. Filters: Production Date (last 30 days)
9. Title: “OEE Trend (Last 30 Days)”
10. Save

You now have a real-time OEE dashboard showing which equipment is performing well and which is trending downward.

Step 5: Add Drill-Down Capabilities

A single OEE number is useful, but you need drill-down to diagnose problems. Add another chart showing availability, performance, and quality as separate metrics:

1. Create a new chart on the same dashboard
2. Chart type: Grouped Bar Chart
3. X-axis: Equipment Name
4. Y-axis: Availability %, Performance %, Quality % (all as separate bars)
5. Filter: Production Date (last 7 days)
6. Title: “OEE Components by Equipment (Last 7 Days)”

Now a supervisor can see that Line 2 has low OEE, drill into the components, and see it’s an availability problem (equipment downtime), not a quality issue.

---

Real-Time Data Integration from SCADA and MES

Connecting SCADA Systems

SCADA systems rarely expose standard SQL databases. Instead, they use proprietary protocols:

OPC-UA (Open Platform Communications Unified Architecture) is the modern standard. Most new SCADA systems (Siemens S7-1200+, Rockwell CompactLogix+, ABB) support OPC-UA.

To ingest OPC-UA data into your warehouse:

1. Deploy an OPC-UA Client: Run a small Python or Node.js application on-site that subscribes to OPC-UA tags (machine status, cycle time, fault codes) and publishes them to a message queue (Kafka, RabbitMQ) or directly to your warehouse.

2. Use a Pre-Built Connector: D23.io partners with vendors like Kepware and Ignition (Inductive Automation) that provide managed OPC-UA bridging. You configure the tags you care about, and they handle the ingestion.

3. Batch Extract: If OPC-UA isn’t available, export SCADA data via CSV or API on a schedule (hourly, every 4 hours) and load it into your warehouse.

The key is frequency. For OEE dashboards, you need data at least hourly, ideally every 15 minutes. This gives you visibility into downtime events as they happen.

Connecting MES Platforms

MES systems are more cooperative. Most expose REST APIs or database connectors.

Dassault Apriso and Siemens MES have REST APIs. You can pull production orders, quality inspections, and labour data via authenticated HTTP requests.

Oracle Manufacturing Cloud and SAP MES expose standard database connections (ODBC, JDBC).

Use a tool like Fivetran, Stitch, or a custom Python script to pull MES data daily (or every 4 hours for real-time dashboards). Store it in your warehouse alongside SCADA data.

Reconciling SCADA and MES

The tricky part: SCADA and MES often disagree. SCADA says equipment ran for 8 hours; MES says the production order was only 6 hours. SCADA reports 100 pieces produced; MES shows 95 pieces received.

This is normal. SCADA is real-time and granular; MES is transactional and sometimes delayed. Here’s how to handle it:

1. Use timestamps as the key: Match SCADA events to MES production orders by timestamp overlap. If a downtime event occurred during a production run, it belongs to that run.

2. Define reconciliation rules: If SCADA and MES disagree on piece count, use MES (it’s the official record). If they disagree on downtime duration, use SCADA (it’s more precise).

3. Flag discrepancies: Create a data quality table that flags mismatches. This helps you identify missing data or system issues.

4. Audit trail: Log every reconciliation decision so you can explain OEE calculations to auditors (important for ISO 27001 compliance).

When we implement OEE dashboards at Australian manufacturers, this reconciliation work typically takes 2–3 weeks. It’s not glamorous, but it’s critical for trust.

---

Dashboard Design Patterns for Manufacturing

Pattern 1: Executive Overview

Target audience: Plant manager, operations director.

Single page, 4–6 charts:

1. KPI Cards (top): Current OEE %, Availability %, Performance %, Quality %, Downtime Hours (Today)
2. OEE Trend (line chart): Last 30 days by facility
3. Equipment Heatmap (heatmap or table): OEE % for each equipment, colour-coded (green > 85%, yellow 70–85%, red < 70%)
4. Top Downtime Reasons (bar chart): Downtime minutes by reason (breakdown, changeover, material shortage, etc.)
5. Quality Issues (bar chart): Scrap count by defect code
6. Shift Performance (table): OEE by shift (first, second, third) to identify which shift is struggling

This dashboard takes 30 seconds to scan and tells you whether operations are healthy.

Pattern 2: Line Operator Dashboard

Target audience: Line operators, shift supervisors.

Focused on their line only:

1. Current Status (large cards): Current OEE %, Equipment Status (Running / Stopped / Error), Pieces Produced (This Shift), Scrap Count (This Shift)
2. Real-Time Production (gauge chart): Pieces produced vs. target for the shift
3. Downtime Events (table): Last 5 downtime events with duration and reason
4. Cycle Time Trend (line chart): Last 100 cycles, flagging cycles slower than normal
5. Quality Alerts (alert section): Any quality issues detected in the last hour

This dashboard is designed to be displayed on a large monitor on the shop floor. Operators glance at it every few minutes.

Pattern 3: Maintenance Engineer Dashboard

Target audience: Maintenance technicians, reliability engineers.

Focused on equipment health and predictive maintenance:

1. Equipment Downtime Breakdown (stacked bar chart): Downtime by reason, last 30 days
2. Mean Time Between Failures (MTBF) (trend chart): MTBF for each equipment, flagging declining trends
3. Maintenance History (table): Last 20 maintenance events with duration and impact on OEE
4. Failure Mode Analysis (scatter plot): Downtime frequency vs. duration, identifying chronic vs. acute issues
5. Parts Inventory (if integrated with ERP): Stock levels for critical spare parts

This dashboard helps maintenance prioritise which equipment to focus on.

Pattern 4: Quality Manager Dashboard

Target audience: Quality engineer, production supervisor.

Focused on quality metrics and traceability:

1. Quality Score (gauge): Overall quality %, target 99%+
2. Defect Trend (line chart): Scrap count and defect rate by day, last 30 days
3. Defect Root Cause (pie chart or bar chart): Scrap count by defect code
4. Equipment Quality Performance (heatmap): Quality % by equipment, identifying chronic quality issues
5. Batch Traceability (table): For a selected production batch, show which equipment processed it and any defects
6. Rework vs. Scrap (bar chart): Rework hours vs. scrap cost, helping decide whether to rework or scrap

This dashboard is critical for root-cause analysis and continuous improvement.

Design Principles

Use colour purposefully: Green (good), yellow (warning), red (critical). Don’t overuse colour; it should draw attention to problems.

Avoid chart junk: Every element should convey information. No 3D effects, unnecessary gridlines, or decorative elements.

Provide context: Show current value, target, and trend. “OEE 78%” is less useful than “OEE 78% (target 85%, down 3% from yesterday)”.

Make drill-down intuitive: Clicking a bar in a chart should filter related charts. If a supervisor clicks “Changeover” in the downtime reasons chart, other charts should filter to show only changeover-related data.

Mobile-friendly: Dashboards should work on tablets and phones. Supervisors check dashboards on the shop floor, not just in an office.

---

Performance Optimisation and Caching

The Problem: Dashboard Lag

When you have millions of SCADA events and production records, querying them on-the-fly is slow. A dashboard querying raw data might take 10–30 seconds to load. On a shop floor, that’s unacceptable.

Solution 1: Pre-Aggregation

Instead of querying raw events, pre-aggregate data into summary tables. We already do this for OEE—we calculate it daily per equipment. Extend this pattern:

Raw tables (high volume, granular):

• downtime_events (1M+ rows/month)
• production_runs (100K+ rows/month)
• quality_inspections (500K+ rows/month)

Aggregated tables (low volume, pre-calculated):

• oee_daily (equipment × day, ~1K rows/month)
• downtime_summary_daily (equipment × day × reason, ~5K rows/month)
• quality_summary_daily (equipment × day × defect code, ~10K rows/month)

Dashboards query aggregated tables. If a user needs raw data (e.g., “Show me every downtime event for Line 2 last week”), that’s a separate, slower query they explicitly request.

As described in the guide to building lightning-fast Superset dashboards, this approach reduces query time from 20 seconds to under 2 seconds.

Solution 2: Caching

Superset supports multiple caching backends. Configure Redis (in-memory cache) to cache query results for 5–15 minutes.

Configuration (in superset_config.py):

CACHE_CONFIG = {
    'CACHE_TYPE': 'RedisCache',
    'CACHE_REDIS_URL': 'redis://localhost:6379/0',
    'CACHE_DEFAULT_TIMEOUT': 300,  # 5 minutes
}

DATA_CACHE_CONFIG = {
    'CACHE_TYPE': 'RedisCache',
    'CACHE_REDIS_URL': 'redis://localhost:6379/1',
    'CACHE_DEFAULT_TIMEOUT': 900,  # 15 minutes for data queries
}

Now, if two supervisors view the same dashboard within 5 minutes, the second one gets instant results from cache. The cache expires after 5 minutes, so data is always recent.

Solution 3: Virtual Datasets and Materialized Views

For frequently-used aggregations, create materialized views in your warehouse. A materialized view is a pre-calculated table that’s refreshed on a schedule.

Example (PostgreSQL):

CREATE MATERIALIZED VIEW oee_hourly AS
SELECT
  equipment_id,
  equipment_name,
  DATE_TRUNC('hour', production_start_time) AS hour,
  ROUND(AVG(availability_pct), 2) AS avg_availability,
  ROUND(AVG(performance_pct), 2) AS avg_performance,
  ROUND(AVG(quality_pct), 2) AS avg_quality,
  ROUND(AVG(availability_pct * performance_pct * quality_pct / 10000), 2) AS avg_oee
FROM oee_calc
GROUP BY equipment_id, equipment_name, DATE_TRUNC('hour', production_start_time);

CREATE INDEX idx_oee_hourly ON oee_hourly (equipment_id, hour DESC);

REFRESH MATERIALIZED VIEW oee_hourly;

Refresh this view every 15 minutes via a scheduled job. Queries against it are instant.

Solution 4: Query Optimisation

Even with pre-aggregation, some queries are slow. Use these techniques:

Indexes: Create indexes on columns used in WHERE and JOIN clauses.

CREATE INDEX idx_downtime_events_equipment_date ON downtime_events (equipment_id, event_timestamp DESC);
CREATE INDEX idx_production_runs_equipment_date ON production_runs (equipment_id, production_start_time DESC);

Partition large tables: If downtime_events has 50M+ rows, partition by month. Queries filtered to a specific date range will scan only one partition.

CREATE TABLE downtime_events (
  event_id BIGINT,
  equipment_id INT,
  event_timestamp TIMESTAMP,
  duration_minutes INT,
  reason TEXT
) PARTITION BY RANGE (YEAR(event_timestamp), MONTH(event_timestamp));

Use EXPLAIN ANALYZE: Before deploying a query, run EXPLAIN ANALYZE to see the execution plan. Look for sequential scans on large tables (slow) and add indexes to force index scans (fast).

For deep guidance, see the data engineer’s guide to optimising Superset dashboards, which covers caching strategies and virtual dataset creation in detail.

---

Governance, Security, and Compliance

Role-Based Access Control (RBAC)

Not everyone should see all data. A line operator shouldn’t see quality data from competing lines. A contract worker shouldn’t see strategic downtime analysis.

Superset’s RBAC model:

Roles:

• Admin: Full access to all dashboards, datasets, and settings
• Plant Manager: All dashboards and datasets for their plant
• Line Supervisor: Dashboards and data only for their line
• Operator: Real-time status dashboard only
• Maintenance: Equipment health and downtime dashboards
• Quality: Quality and defect dashboards

Datasets: Each dataset can be restricted to specific roles. For example, the “Quality by Defect Code” dataset is visible only to Quality and Admin roles.

Dashboards: Similarly, dashboards are restricted. The “Executive Overview” is visible to Manager and Admin; the “Operator Dashboard” is visible to Operator and Supervisor.

Row-Level Security (RLS): For advanced use cases, implement RLS so a supervisor sees only their line’s data. This requires custom SQL in Superset’s RLS rules.

Audit Logging

For SOC 2 and ISO 27001 compliance, you need an audit trail: who accessed what data, when, and what they did with it.

D23.io (and Superset Enterprise) logs:

• Dashboard views (user, timestamp, dashboard name)
• Query executions (user, query, execution time, rows returned)
• Data exports (user, dataset, timestamp, row count)
• Configuration changes (user, change description, timestamp)

These logs are stored in PostgreSQL and can be queried for compliance reports. For example:

SELECT
  username,
  action,
  object_type,
  object_name,
  action_timestamp,
  COUNT(*) AS count
FROM audit_log
WHERE action_timestamp >= NOW() - INTERVAL '30 days'
GROUP BY username, action, object_type, object_name, DATE(action_timestamp)
ORDER BY action_timestamp DESC;

This shows all data access in the last 30 days, useful for demonstrating compliance to auditors.

Data Encryption

In Transit: Superset should be accessed via HTTPS only. D23.io enforces this by default. Configure HSTS (HTTP Strict Transport Security) to prevent downgrade attacks.

At Rest: Your warehouse (PostgreSQL, Snowflake, Databricks) should encrypt data at rest. Most cloud providers offer transparent encryption.

Credentials: Database connection strings, API keys, and passwords should be stored in a secrets manager (AWS Secrets Manager, HashiCorp Vault) and rotated regularly. Never hardcode credentials in Superset configuration.

Single Sign-On (SSO)

Don’t manage Superset passwords separately. Integrate with your identity provider (Azure AD, Okta, Google Workspace) via SAML or OAuth2.

When a user logs into Superset, they authenticate against your corporate directory. If they leave the company, their AD account is disabled, and they automatically lose Superset access.

D23.io supports SSO configuration. See the $50K D23.io engagement guide for SSO setup details.

Data Residency and Compliance

For Australian manufacturers, data residency is often a regulatory requirement. Your production data must stay in Australia.

D23.io hosts Superset and data warehouses in Australian data centres (Sydney, Melbourne). Your SCADA and MES data never leaves the country. This is critical for compliance with Privacy Act 1988 and industry-specific regulations (e.g., Critical Infrastructure Centre of Excellence requirements for essential services).

Integrating with Vanta for Compliance

When pursuing SOC 2 Type II or ISO 27001 certification, you need to demonstrate controls across your entire tech stack. Superset and D23.io are part of that stack.

Vanta is a compliance automation platform that integrates with cloud services to collect evidence of security controls. If you use Vanta (which we help clients implement), it can:

• Monitor Superset access logs for unauthorised activity
• Verify that all data connections use encryption
• Confirm that audit logging is enabled
• Generate compliance reports for your auditor

We’ve helped multiple Australian manufacturers pass SOC 2 audits with Superset and D23.io as part of their data infrastructure. The key is treating dashboards and data access as a security control, not an afterthought.

---

Next Steps and Implementation Timeline

Phase 1: Discovery and Planning (Weeks 1–2)

Deliverables:

• Data audit: Map all SCADA, MES, and ERP systems
• OEE requirements: Define which metrics matter (availability, performance, quality, or more granular breakdown)
• Stakeholder interviews: Understand what dashboards each role needs
• Compliance assessment: Identify SOC 2 / ISO 27001 requirements

Effort: 40–60 hours (PADISO + your team)

Cost: Included in a typical $50K engagement or billed separately at $200–300/hour

Phase 2: Data Integration (Weeks 3–5)

Deliverables:

• SCADA connector: OPC-UA client or Kepware integration running
• MES API integration: Pulling production orders and quality data
• ETL pipeline: dbt models to calculate OEE, reconcile SCADA/MES, and validate data quality
• Warehouse schema: Tables for equipment, downtime, production, quality

Effort: 120–200 hours (mostly PADISO, some your team for system access)

Cost: $50K–80K (or part of a larger engagement)

Phase 3: Dashboard Development (Weeks 6–8)

Deliverables:

• Semantic layer: OEE metrics and dimensions defined in Superset
• Executive dashboard: OEE overview, top downtime reasons, quality summary
• Operator dashboard: Real-time status, production targets, downtime alerts
• Maintenance dashboard: Equipment health, MTBF trends, failure analysis
• Quality dashboard: Defect analysis, batch traceability, rework vs. scrap
• Role-based access: RBAC configured, users assigned to roles

Effort: 160–240 hours (PADISO)

Cost: $50K–80K (or part of a larger engagement)

Phase 4: Security and Compliance (Weeks 9–10)

Deliverables:

• SSO integration: Azure AD or Okta configured
• Audit logging: Enabled and tested
• Encryption: Data in transit and at rest
• Vanta integration: Compliance automation connected
• Documentation: SOC 2 / ISO 27001 controls documented

Effort: 40–80 hours (PADISO + your security team)

Cost: $20K–40K (or part of a larger engagement)

Phase 5: Training and Handoff (Week 11)

Deliverables:

• User training: Operators, supervisors, managers trained on their dashboards
• Admin training: Your team trained to manage Superset, add new dashboards, maintain data quality
• Documentation: Dashboard user guides, troubleshooting, escalation procedures
• Support plan: 30–90 days of post-launch support from PADISO

Effort: 40–60 hours (PADISO + your team)

Cost: $20K–30K (or included in support plan)

Total Timeline: 11 Weeks (2.5 Months)

Total Cost: $150K–$350K depending on complexity, number of SCADA systems, and compliance requirements.

This aligns with the typical $50K D23.io engagement, which delivers a complete OEE dashboard rollout in 6 weeks for a single facility. Multi-facility deployments or complex integrations take longer and cost more.

Why Partner with PADISO?

Building OEE dashboards in-house is possible but risky. You need expertise in:

• Manufacturing operations: Understanding what OEE really means and how to calculate it correctly
• Data engineering: Building reliable ETL pipelines that reconcile SCADA and MES data
• Apache Superset: Optimising dashboards for performance and usability
• Security and compliance: Implementing RBAC, audit logging, and encryption

Most Australian manufacturers don’t have this expertise in-house. Hiring contractors to do it piecemeal often results in siloed work, poor documentation, and technical debt.

When you partner with PADISO, you get:

1. Proven methodology: We’ve deployed OEE dashboards for 50+ manufacturers. We know what works.
2. Fractional CTO leadership: Our senior engineers guide your team, building capability alongside delivery.
3. Turnkey infrastructure: We deploy on D23.io, so you don’t manage servers, patching, or backups.
4. Compliance-ready: We build with SOC 2 and ISO 27001 in mind from day one.
5. Long-term support: We don’t hand off and disappear. We stay engaged, optimising dashboards and adding features as your business evolves.

If you’re a Sydney-based manufacturer or a private equity firm acquiring manufacturing assets, contact PADISO to discuss your OEE dashboard roadmap. We can typically scope and start within 2 weeks.

Key Takeaways

• OEE is the universal manufacturing metric: Availability × Performance × Quality. Real-time visibility drives $500K–$2M in annual value recovery.
• Apache Superset is the right tool: Open-source, cost-effective, and purpose-built for modern data stacks. No vendor lock-in.
• D23.io managed infrastructure removes operational burden: You focus on dashboards and insights, not infrastructure.
• Data integration is the hard part: Reconciling SCADA and MES data takes weeks. Plan for it.
• Pre-aggregation and caching make dashboards fast: Sub-2-second load times are achievable with proper architecture.
• RBAC and audit logging are non-negotiable: If you’re pursuing SOC 2 or ISO 27001, build these in from day one.
• Phased implementation reduces risk: Discovery → Integration → Dashboards → Security → Training is a proven sequence.

OEE dashboards aren’t a nice-to-have. They’re a competitive necessity. Australian manufacturers competing globally need real-time visibility into equipment performance. Apache Superset and D23.io make it affordable and achievable.

The manufacturers we work with see results within weeks: downtime drops 10–20%, quality improves 5–15%, and operators shift from reactive to predictive. That’s the power of visibility.

Start with a single production line. Build one dashboard. Prove the value. Then scale to your entire facility. Within 3 months, you’ll have a competitive advantage your competitors don’t have.

Ready to build? Let’s talk.