Skip to content

Aurora Power Supply

Aurora Power Supply is the curated 1D electrical and thermal summary view built from the power Zarr, with optional ASS 48 V DC power from the ASFS logger Zarr and ASS PDU outlet power for station-load context.

Interactive summary layout

The dashboard presents Aurora Power Supply in a deliberately scientific, multi-panel style inspired by the reference plots used during development. The Power view is divided consistently across desktop, phone browser, iPhone, and iPad:

  • Current Conditions is the default and shows observed station electrical and thermal behavior for the selected window.
  • Forecast & Planning loads on demand and groups the 24-hour forecast, ECMWF 96-hour outlook, operating-mode scenarios, custom operating plan, and verification evidence.

The 24-hour card is a near-term slice of the central system-as-is trace in the 96-hour ensemble card. Both therefore use the same SOC anchor, confirmed instrument state, load phase, and forecast issue; only the displayed horizon differs.

This split changes only presentation and bounded API selection. It does not change the forecast calculations or stored products.

Forecast plot information

Every Forecast & Planning plot has an Info control in the desktop browser, mobile browser, and native iOS app. It describes the metric and the exact implementation used at AURORA, so a plot can be interpreted without leaving the dashboard. The key distinctions are:

  • P10, central, and P90 SOC describe the current system as-is. They vary ECMWF solar weather, calibrated battery parameters, and uncertainty learned within the one detected operating state. They are not different instrument schedules, and their load does not change state during the horizon.
  • Operating-mode scenarios are separate advisory simulations. Each includes the DC baseline plus the instruments named in its legend. Shaded intervals on the solar/load panel identify feasible advisory CL61-on periods and do not indicate forecast probability or an automatic PDU command.
  • Hindcasts and verification scores look backwards: archived forecasts are matched to later APS observations. MAE, CRPS, and Brier scores are lower-is- better; P10-P90 coverage targets 0.80.
  • Solar and load verification is versioned with the load model, so a model update begins a comparable new set of evidence rather than mixing scores.

Typical panels include:

  • Renewables
  • Battery Charging
  • Charging Current In
  • Charging Power In
  • Output Power
  • AC output power on the left axis
  • DC inverter power on the right axis
  • ASS 48 V DC Power
  • ASS 48 V DC power from watts_on_48vdc_Avg, when available
  • ASS PDU Outlet Power
  • assigned outlet watt traces: PDUOutlet4Watts = UAS, PDUOutlet5Watts = CL61, PDUOutlet6Watts = Radar, and PDUOutlet8Watts = HATPRO
  • unassigned physical outlets are retained in the data product but are not plotted
  • remains visible when every outlet reports 0 W, so powered-off kit is an explicit operational state rather than a missing panel
  • Cumulative Power & State of Charge
  • State of Charge, from BatterySOC, on the left axis in percent
  • East Solar Generated
  • South Solar Generated
  • West Solar Generated
  • Total Generated
  • Utilised, integrated from AC and DC output power and reset at each UTC midnight
  • cumulative generated and utilised energy traces on the right axis in kWh
  • Output Voltage
  • Thermal State
  • internal temperature
  • heatsink temperature
  • temperature sensors 1-4
  • left and right y-axes both use the same Temperature [C] range
  • SOC 24 h Forecast
  • the first 24 hours of the central system-as-is decision forecast
  • uses the same SOC anchor, detected load state, and solar input as the 96-hour system forecast
  • ends exactly at the SOC anchor plus 24 hours
  • SOC 96 h Forecast
  • ECMWF-informed system-as-is P10, central, and P90 SOC traces
  • probability of falling below the 40% minimum, displayed in percent
  • ends exactly at the SOC anchor plus 96 hours
  • ECMWF Solar & Load Forecast
  • calibrated forecast solar charging and the detected finite load state
  • carries the same 96-hour planning horizon as the SOC and scenario cards
  • Suggested Instrument-Mode SOC Forecasts
  • CL61, CL61 + Radar, CL61 + HATPRO, CL61 + HATPRO + Radar, HATPRO + Radar, Radar, HATPRO, and all instruments + UAS tier 3
  • median SOC for each combination and a 40% minimum operational reference
  • Custom CL61 Operating Plan
  • user-selected UTC start and run duration
  • immediate advisory safety, collection-hour, minimum-P10, and final-P10 results without issuing PDU commands
  • SOC Forecast Skill
  • SOC forecast mean absolute error by lead-time bucket
  • forecast skill sample count
  • recent solar forecast mean absolute error in watts
  • recent load forecast mean absolute error and bias in watts Legends are placed in a consistent right-side gutter rather than collected into one global legend block.

Interactive performance behavior

The interactive view prefers /data/aurora/products/power/power_display_summary.zarr, a compact one-minute display product derived from the raw Power Zarr plus the ASFS logger watts_on_48vdc_Avg context trace. The raw store remains authoritative; the compact product only avoids multi-day one-second reads and source merges when the browser needs the curated APS summary panels. If the broader display summary is missing, the app falls back to the raw Power Zarr and the smaller /data/aurora/products/power/power_display_energy.zarr cumulative-energy product.

When /data/aurora/products/power/pdu.zarr is available, the display summary also includes ASS PDU outlet watt traces. Those PDU samples are synced from ASS Linux /home/aurora/data/pdu/pdu_DDMMYYYY.csv into /project/aurora/raw/pdu and appended by append_new_pdu_to_zarr.py.

The app opens the Power store with larger read chunks and uses per-trace time downsampling. Display-only sanity limits remove impossible APS values, such as single-sample charging-current/current-power outliers, before plotting. The live latest window is rounded into 5-minute cache buckets, and the Current and Forecast Power figures are prewarmed as Plotly JSON by generate_power_quicklooks.py --prewarm-only after the compact display product refreshes. The browser reads those complete files before it considers a live Zarr render. Their x-axis ends at current UTC time, so an absent tail remains a visible collection gap rather than being hidden by moving the window back to the last observed sample.

Observed panels in that prewarm use the measured APS display window rather than the later timestamp of the 96-hour forecast fields. Power panels reserve a 88-pixel vertical gap for their two-line UTC tick labels and axis titles.

That prewarmed JSON lives under /data/aurora/products/dashboard/prewarm/.

The Battery Charging panel also applies a display-only 30-minute rolling mean to BatteryAmps and BatteryWatts. This keeps isolated charging transients from dominating the visual scale while leaving the stored Power Zarr unchanged.

Per-trace downsampling is important for ASS 48 V DC Power: that line comes from the ASFS logger at about one-minute cadence, while the APS power data are much denser. Downsampling after each trace has dropped merged NaN timestamps preserves the ASFS cadence instead of thinning it on the dense APS time grid.

The ASS 48 V DC Power panel depends on the ASFS slow sci table field watts_on_48vdc_Avg. It can therefore go stale independently of the APS power system. The APS AC/DC output, battery, solar, SOC, and thermal traces come from the Power Zarr and can remain current even when the ASFS sci stream is not producing new files.

The ASS PDU Outlet Power panel depends on the ASS PDU CSV logger. It can go stale independently of both APS and ASFS; operations monitoring tracks its source sync and append timers separately.

Operations monitoring scores APS InternalTemperature on both cold and hot thresholds: green from 10-40 C, amber from 5-10 C or 40-45 C, and red below 5 C or at 45 C or above.

APS internal dew-point monitoring is optional and requires a true APS internal relative-humidity field named InternalHumidity in percent. The dashboard does not substitute ambient HATPRO, Vaisala, or ASFS humidity for internal APS humidity. When InternalHumidity is present, operations snapshots calculate dew point from same-sample InternalTemperature and InternalHumidity, then mark the dew-point margin red when InternalTemperature - dewpoint <= 0 C. When the field is absent, the Operations Dashboard shows internal humidity as unavailable rather than estimating it from site meteorology.

DCInverterWatts is plotted on its own right axis because its raw value is often much smaller than AC output power. The source CSV reports it consistently with DCInverterVolts * DCInverterAmps, so a 53.75 V, 0.17 A sample appears as about 9 W.

The cumulative panel is normalized in the display products. The SolarYield_* counters are converted into positive UTC-day increments, so delayed controller resets just after midnight do not create false drops in the plotted generation lines. The utilised-energy line is integrated from AC+DC output power. BatterySOC is plotted as State of Charge on the left axis. The cumulative generated and utilised energy traces are plotted on the right axis in kWh, so the panel shows generation, use, and battery state without deriving a separate deficit estimate. The daily generated and utilised traces are visually broken at UTC midnight so their resets do not render as false vertical jumps.

The SOC 24 h Forecast panel is a presentation-layer forecast only. It fits recent BatterySOC samples from the latest 30 minutes and latest 2 hours, then extrapolates those fits 24 hours ahead. The default polynomial degree is 1 for stability and can be changed with AURORA_POWER_SOC_PROJECTION_POLY_DEGREE; forecast values are clipped to the physical 0-100 % SOC range.

The existing operational SOC 96 h Forecast panel is generated by generate_power_soc_forecast.py. It retrieves ECMWF ssrd surface solar radiation forecast data, converts the accumulated J m-2 field to interval W m-2, calibrates expected solar charging from recent APS solar production, and derives total station load from solar generation minus signed battery power. This includes the 48 V DC system load that is not represented by the roughly 9 W inverter-idle value. Version 10 identifies the latest finite operating state and holds that state through the horizon. Within that exact state it can represent recurrent startup and low/high fan phases, including their load and duration uncertainty. Startup needs two state-entry episodes and a fan level needs two non-contiguous segments; one-off historical levels are not forecast as repeatable behavior. A new sustained latest level still updates the current steady forecast immediately. Fresh PDU components plus the clean DC-only baseline are preferred; an exact-state learned distribution is the next choice. The latest whole-station balance is used only to bootstrap a state with insufficient direct or learned evidence. When AC kit is switched on, fresh non-zero PDU outlet power names the mode from that kit. Outlet 5 identifies the Ceilometer as DC-Only + CL61; relay state is only used when outlet watts are unavailable. Recognition can update the next forecast immediately, while durable mode learning waits for 30 minutes of stable AC/DC state and at least two aggregated samples. The learner then stores independent hourly load observations and persists the recognised mode's robust level; it does not infer a daily schedule. The mode name is included in the forecast-load legend. This version-10 model refreshes with every 15-minute learning run and uses calibrated battery capacity, directional efficiencies, and power limits for SOC integration. The CL61 can autonomously start its heater/blower without changing its PDU state. This is learned as the high phase inside the same DC-Only + CL61 state, not as an operator-controlled mode. A fresh high-phase detection is shown in Overview as On with Heater/Blower; ordinary powered operation remains On. This product is operational guidance only and is stored separately from model-evaluation products.

The Suggested Instrument-Mode SOC Forecasts panel uses the same ECMWF solar input and latest BatterySOC anchor for all eight fixed combinations. Each scenario includes the DC baseline and load distributions learned for its named instruments. Its current-mode trace is rebuilt by the frequent operating-state job from the latest exact state and automatic phase; it does not reuse a stale load phase from the twice-daily planning cycle. The eighth scenario keeps CL61, Radar, HATPRO, and UAS on with UAS effective tier 3. It remains explicitly provisional until tier 3 has at least three independent episodes and six observed hours; its fallback P10/P50/P90 UAS loads are 55/108/302 W. The separate advisory scheduler proposes CL61, Radar, and HATPRO states in that strict priority order. It maximizes each instrument's collection hours over 96 hours without reducing a higher-priority result, while keeping the DC baseline and current UAS state fixed. Every controlled instrument requires a 12-hour minimum run and permits at most one planned start per UTC day. P10 SOC must remain at or above 40% through the complete 240-hour forecast, including a reserve tail with all three controlled instruments off. If even that reserve case is unsafe, the dashboard reports No Feasible Instrument Schedule; zero traces are diagnostic, not PDU instructions. The custom CL61 plan editor evaluates a selected start and duration against the stored ensembles immediately. All plans are advisory only.

The hybrid learner combines a finite-state/HMM-like mode classifier with robust Kalman updates for the DC and kit load components. It saves the full component covariance and only learns from observations newer than its persisted cursor, so repeated five-minute runs do not count the same evidence again.

The development planning forecast retrieves eligible ECMWF 00/12 UTC output twice daily and extends to 240 hours. A five-minute operating-state refresh reuses that solar forecast, re-anchors every plan to the latest actual BatterySOC, recognises mode changes, and incrementally updates component loads. The existing operational deterministic forecast continues its own three-hour/15-minute cadence until the development model is promoted. The Forecast Verification panel is past-facing. It reads power_soc_forecast_skill.zarr, which matches archived forecast valid times to observed APS SOC, solar charging, and power-balance total load. It reports rolling 24-hour SOC MAE by 0-6 h, 6-24 h, 24-48 h, and 48-96 h lead buckets, plus recent solar/load MAE and load bias. Skill scores are computed relative to persistence and kept in the same verification product for diagnostics. Load metrics are scored only against archive rows from the current load-model version so a model change starts a new, comparable verification record.

The Power summary also includes a seven-day fixed-lead SOC hindcast, comparing observations with forecasts issued 6, 24, 48, and 72 hours earlier. A separate 50-member ECMWF IFS ensemble supplies P10-P90 SOC uncertainty and the forecast probability of crossing below the 40% minimum operational threshold. Every member represents the detected current PDU/APS system mode, while uncertainty also samples that exact state's learned startup duration, steady/fan phase occupancy and dwell time, load distribution, and calibrated battery parameters. These load changes remain inside the confirmed instrument state; they do not represent uncommanded instrument switching. Exact-state phase learning requires direct evidence for all four assigned PDU outlets at the observation time. Deliberate instrument-on schedules are evaluated solely in the separate operating-mode plans. Ensemble CRPS, interval coverage, and threshold Brier score remain pending until verifying observations have arrived.

These are display-time optimizations and derived operational forecasts. Raw APS ingest and backup are unchanged: production copies APS Power data additively to both GWS and object storage, but APS is explicitly non-prunable until a separate source-retention policy is approved.

Quicklooks

  • science quicklooks show the curated APS summary
  • housekeeping quicklooks show HK_APS

Backing data product

Zarr path:

  • /data/aurora/products/power/power.zarr

Derived display product:

  • /data/aurora/products/power/power_display_summary.zarr
  • /data/aurora/products/power/power_display_energy.zarr
  • /data/aurora/products/power/pdu.zarr
  • /data/aurora/products/power/power_soc_forecast.zarr
  • /data/aurora/dev-products/power/power_soc_planning_forecast.zarr
  • /data/aurora/dev-products/power/power_operating_state.zarr
  • /data/aurora/dev-products/power/power_operating_scenarios.zarr

Presentation-layer overlay:

  • /data/aurora/products/asfs_logger/asfs_logger.zarr
  • watts_on_48vdc_Avg supplies the optional ASS 48 V DC Power panel

Detailed schema: