Skip to content
ML Academy

project-004 · Analytics and statistics · energy

Where does a steel plant's electricity cost exposure concentrate? Load and power-factor profile

A steel plant's energy manager wants to know when consumption peaks, how often the lagging power factor drops below a tariff threshold, and how much reactive energy those intervals carry. The goal is a short list of operating patterns worth changing (for example, shifting a batch or adding compensation), each backed by quantified exposure with honest uncertainty.

Licence
CC BY 4.0 (as stated on the UCI page)
Reference run
none

At a glance

  • Data

    Steel Industry Energy Consumption (UCI 851) (public) · 35,040 rows x 11 columns; Steel_industry_data.csv 2.6 MB

    Details on data

  • Baseline

    Hour-of-day x weekday/weekend means with i.i.d. normal intervals. It gives the right point profile and the wrong uncertainty;

    Details on baseline

  • Validation

    Block-length sensitivity (half day, one day, one week); intervals should stabilise. Stability split: build the profile on the first half of the year and check how well…

    Details on validation

  • Metric

    Interval widths (bootstrap versus i.i.d.), autocorrelation at the daily lag, power-factor recomputation agreement rate, stability of the profile across halves.

    Details on metric

Success criterion

  1. A profile of mean kWh per interval by hour of day x weekday/weekend with 95% moving-block-bootstrap intervals.
  2. The share of intervals with lagging power factor below 90% (a hypothetical tariff threshold) by hour and load type, with block-bootstrap intervals, plus the same at 85% and 95% as sensitivity.
  3. Power factor recomputed from kWh and kVarh agrees with the reported value within 0.5 points for a stated share of intervals, and every disagreement class is documented.
  4. At most three ranked operational hypotheses, each with the exposure it addresses and how it would be tested.

Context

The UCI data come from DAEWOO Steel in Gwangyang, South Korea, sourced from the utility's (KEPCO) website. Each row is a short metering interval with consumption, lagging and leading reactive energy, power factors, CO2, and a provider-assigned load type. Low power factor means the plant draws reactive power that utilities often penalise; the tariff numbers in this project are hypothetical. Interval data are strongly autocorrelated (daily and weekly cycles), so naive i.i.d. intervals are too narrow, which is the statistical point of the project.

Data

Dataset
Steel Industry Energy Consumption (UCI 851) (public)
Licence
CC BY 4.0 (as stated on the UCI page)
Size
35,040 rows x 11 columns; Steel_industry_data.csv 2.6 MB
Verification
identity verified

Access

Direct download from the UCI page (no account), or ucimlrepo.fetch_ucirepo(id=851) as offered on the page. Fallback: none needed for a 2.6 MB file; cache it locally with a checksum.

Grain

One row per metering interval. 35,040 rows equal 365 days x 96 intervals, which suggests 15-minute data for one year; confirm with the date column and NSM (seconds from midnight) before relying on it.

ColumnMeaning
dateInterval timestamp; check the day/month order when parsing
Usage_kWhIndustry energy consumption in the interval (kWh)
Lagging_Current_Reactive.Power_kVarhLagging reactive energy (kVarh)
Leading_Current_Reactive_Power_kVarhLeading reactive energy (kVarh)
CO2(tCO2)CO2; the page lists the unit as ppm although the name says tCO2
Lagging_Current_Power_Factor / Leading_Current_Power_FactorPower factors in percent
NSMNumber of seconds from midnight
WeekStatus / Day_of_weekWeekday or weekend; day name
Load_TypeLight, Medium or Maximum load as assigned by the provider (derivation not documented)

EDA and data-quality rules

  • Timestamps unique and regular; NSM consistent with the time of day; WeekStatus consistent with Day_of_week.

  • Recompute lagging power factor as 100 x kWh / sqrt(kWh^2 + kVarh^2) and compare with the reported value; classify mismatches (zero-consumption intervals, rounding, other).

  • Unit check for CO2: compare its magnitude with kWh to judge whether it is tonnes, ppm or a derived index; document the conclusion.

  • Load_Type: check how it relates to kWh and time of day before using it as an explanatory variable; it may be derived from consumption.

  • Add a Korean public-holiday flag (holidays package) and check whether holidays look like weekends.

  • Zero or near-zero consumption intervals and their power factor values are counted and handled explicitly.

Baseline

Hour-of-day x weekday/weekend means with i.i.d. normal intervals. It gives the right point profile and the wrong uncertainty; comparing its interval widths with the block bootstrap is part of the deliverable.

Features

Hour of day, weekday/weekend, month, holiday flag, load type (after the derivation check), power-factor bands, and run-length features for low-power-factor episodes (consecutive intervals below the threshold) to separate brief spikes from sustained operation.

Candidate methods

  • Descriptive profile with moving-block bootstrap intervals

    Keeps within-day dependence by resampling blocks (for example one day), giving honest intervals without a model.

  • Regression of kWh on hour x weekstatus and month with HAC (Newey-West) standard errors

    Estimates profile contrasts with a model and autocorrelation-robust errors; a cross-check on the bootstrap.

  • Episode analysis of low-power-factor runs

    Exposure under penalties depends on sustained episodes; run-length distributions point to specific operations.

Validation design

  • Block-length sensitivity (half day, one day, one week); intervals should stabilise.
  • Stability split: build the profile on the first half of the year and check how well it describes the second half.
  • Agreement between HAC regression contrasts and bootstrap differences.

Leakage checks

Not a predictive task. The analogue is circular explanation: explaining consumption with Load_Type is circular if the provider derived Load_Type from consumption.

Bias and representativeness

One plant and one year; production mix and maintenance shutdowns are unobserved; holidays and weekends may hide planned outages; the tariff rule is hypothetical.

Robustness checks

Thresholds of 85/90/95%; with and without holidays; block lengths; exclusion of zero-consumption intervals.

Technical metrics

Interval widths (bootstrap versus i.i.d.), autocorrelation at the daily lag, power-factor recomputation agreement rate, stability of the profile across halves.

Business interpretation

Share of annual kWh in the top-load windows, share of intervals and reactive energy below the threshold, and a hypothetical penalty exposure with its sensitivity to the threshold and price.

Error slices

  • Weekday versus weekend and holidays.

  • Hour-of-day bands (night, shift changes, daytime).

  • Load type, after checking its derivation.

  • Months or seasons with different production patterns.

Implementation steps

  • Download, checksum and parse; assert interval regularity and the 365 x 96 structure.

  • Run the EDA rules, including the power-factor recomputation and the CO2 unit check.

  • Build the baseline profile, then the block-bootstrap profile; compare interval widths.

  • Fit the HAC regression as a cross-check; run the episode analysis.

  • Rank up to three operational hypotheses with exposure and a proposed test (for example a one-week trial of shifting one batch).

  • Write a one-page memo with small multiples by weekday/weekend and an insight-led title.

Reproduction

Learner-built. One command rebuilds tables and charts from the cached CSV; pin dependencies with uv.lock, fix bootstrap seeds and block length in a config file, and store the file checksum.

Limitations

  • Single plant, single year; profiles may not hold after production changes.

  • Tariff threshold and prices are hypothetical; real tariffs define power-factor penalties in their own terms.

  • Load_Type and CO2 definitions are not fully documented by the provider.

Production and monitoring

An automated monthly energy report from the metering feed with a data contract (interval regularity, unit checks), and an alert when lagging power factor stays below the threshold for a sustained run. Changes such as batch shifting are evaluated with before/after comparisons that account for weekly cycles.

Interview questions

  • Why are i.i.d. confidence intervals too narrow for 15-minute load data, and what do you use instead?

  • Your recomputed power factor disagrees with the reported one in a few percent of intervals. What do you do before analysing?

  • Would you use the provider's Load_Type to explain consumption? Why or why not?

Postmortem and alternatives

If the question were forecasting next week's peaks, this becomes a forecasting project with seasonal baselines and backtests; here the deliverable is a descriptive exposure analysis. With equipment-level metering, attribution to specific lines would replace the hour-of-day proxy.

Rubric3 criteria

CriterionMeetsExceeds
Data validationConfirms interval regularity and runs the power-factor recomputation check.Resolves the CO2 unit question and the Load_Type derivation with evidence.
Uncertainty under dependenceUses block bootstrap or HAC errors instead of i.i.d. intervals.Shows block-length sensitivity and quantifies how much i.i.d. intervals understate uncertainty.
ActionabilityRanks up to three hypotheses with quantified exposure.Pairs each hypothesis with a concrete test design and the decision it informs.

References4