XFQ/Platforms/WebGSO
Forecast delivery for large-scale solar, in the grid operator's exact schema.
WebGSO is the service that stands between a 50 MW solar plant and the national grid system operator. It pulls numerical weather forecasts every cycle, stores them as a time series, reshapes them into the operator's required JSON, and serves them over HTTPS as eight documented REST endpoints — while giving the plant owner its own dashboard onto the same data.
A grid operator does not accept "roughly the right numbers".
Under a power purchase agreement, a large-scale solar plant has to tell the system operator what it expects to generate — continuously, at defined horizons, in a defined format, over a defined transport. The specification names the URL paths, the JSON field names, the units, and the plant mnemonic. Anything that does not match is a failed submission.
The plant had a weather-forecast subscription and a database. What it did not have was the service in between, or anyone accountable for keeping that service answering at three in the morning.
- Units reconciled — source data arrives in watts, the operator's schema requires megawatts.
- Mnemonic corrected — lowercase in every URL path, uppercase in every response body, per spec.
- Deduplicated ingestion — repeat cycles upsert on timestamp instead of stacking duplicate rows.
- Horizon gap handled — the forecast provider caps at seven days; days eight and nine are filled from a climatology model rather than left empty.
- Confirmed in writing — the operator has since confirmed both the plant mnemonic and the timestamp convention in writing, closing the two items that could not be settled from the document alone.
One box, two independent consumers.
The compliance feed and the client dashboard read the same database through separate processes. Dashboard traffic can never degrade the feed the grid operator depends on.
Eight endpoints, four horizons, one live data channel.
Every path, field name and casing convention follows the system operator's published specification. The mnemonic in each path is assigned by the operator per plant.
| Endpoint | Horizon | Resolution | Refreshed |
|---|---|---|---|
/<PLANT>/Forecast/Rolling | 6 days rolling | 15 minutes | Every 30 minutes |
/<PLANT>/Forecast/DayAhead | Next day | 15 minutes | Daily, 09:00 MYT |
/<PLANT>/Forecast/WeekAhead | 9 days | 15 minutes | Weekly |
/<PLANT>/Forecast/FourMonthsAhead1…4 | Month 1–4 | Hourly | Monthly |
/<PLANT>/MMF | Current | Live | Continuous |
The plant owner sees the same numbers, in a form they can use.
A separate application on the same box, behind its own subdomain and its own access gate — built so that opening it can never touch the compliance feed.
Rolling forecast with bands
The generation curve plotted against its P10 and P90 confidence band, so an operator can see not just the expectation but the spread around it.
Horizon tabs & KPI cards
Day-ahead and week-ahead views alongside the rolling window, with headline figures for expected peak, daily energy and current conditions.
CSV and XLSX export
Any horizon exported as a spreadsheet for reporting, reconciliation or submission to a third party, straight from the browser.
Meteorological parameters
Live readings from five on-site weather stations — horizontal and inclined irradiance, ambient temperature, wind speed and direction, humidity, pressure and cumulative daily radiation — charted alongside the forecast they are meant to validate.
Access gate
Every route protected, session held in an http-only cookie, isolated behind a single module so it can be swapped for per-user accounts without touching the rest of the app.
Honest empty states
Where no telemetry source exists yet, the dashboard says so rather than inventing a plausible number. Nothing on screen is fabricated.
Where it runs, and how it stays running.
| Concern | How it is handled |
|---|---|
| Hosting | A dedicated server in the Singapore region — lowest latency to a Malaysian grid operator, and fast storage for time-series write and query performance. The host was chosen after reviewing independent uptime data and rejecting a cheaper provider running around 91% availability. |
| Provisioning | A single script takes a fresh instance to a working stack, so the whole environment can be rebuilt from scratch if it ever has to be: non-root operating account, key-only authentication with password login disabled, firewall, and automated brute-force protection. |
| Exposure | Only encrypted web traffic and administrative access reach the server. The database is not reachable from the public internet at all, and only the operator-facing endpoint paths are publicly routed. |
| Certificates | Automatic issuance and renewal for every hostname. No manual certificate rotation, no expiry surprises. |
| Data integrity | Deduplicating upserts keyed on the designated timestamp, so a re-run of any ingestion cycle corrects rows instead of duplicating them. |
| Documentation | A build and migration guide covering every decision, the reasoning behind it, and an explicit list of items still to verify before go-live. |
WebGSO
Running a plant with a feed to deliver?
If you have a compliance obligation, a forecast subscription and no service in between, that gap is exactly what WebGSO was built to close.