Building the software layer between battery assets and Japan's power markets.

Context

Battery energy storage in Japan earns revenue across several markets at once: spot and intraday trading on JEPX, and balancing products in the EPRX market. The Aggregation Coordinator that operates the batteries has to hold market rules, bid deadlines, settlement intervals, and on-site constraints in one place, and act on them every day. This platform was built to be that place for the operations and market teams.

Approach

I developed the backend and the analytical logic behind bid suggestion, bid-result review, charge/discharge scheduling, and performance reporting for JEPX and EPRX. A large part of the work was translating market rules and operational constraints — state of charge, power limits, availability — into explicit system logic that the team could inspect and challenge. The platform connects to battery sites through the EMS and, below it, the PCS and BMS, so telemetry and schedules travel through the same system as the market data. The user interface is bilingual (JA/EN), so Japanese- and English-speaking staff work from the same screens.

Scope

• Operations dashboard for market and site status
• Bid suggestion and decision support for JEPX and EPRX
• Bid-result review for JEPX and EPRX
• Charge/discharge schedule pages
• Performance reports
• Bilingual (JA/EN) user interface

Outcome

Bids, results, schedules, and performance are visible in one system for the JEPX and EPRX markets. Because market rules and site constraints are encoded in system logic rather than held by individuals, the daily cycle from bid to schedule to review can be repeated consistently from one day to the next.

Context

Prices in the EPRX balancing market differ from one product to the next and across the time blocks of the day, and bidding decisions need them at a finer grain than is practical to read from each publication by hand. Teams preparing bids need a consistent, repeatable view of that price behavior, produced the same way each time.

Approach

I designed and developed the data pipeline that collects and normalizes published price data and the analysis layer that aggregates prices by product and time block; the reporting views for the people who prepare bids are built on that layer. The pipeline keeps source data and transformations separate so results can be re-run and checked.

Scope

• Data pipeline for published balancing-market price data
• Aggregation by product and time block
• Analysis views to support bidding decisions
• Reporting for market understanding and review

Outcome

Bidding discussions can start from a shared picture of recent price behavior. The resulting dataset also serves as a reference for revisiting assumptions when products or market rules change.

Context

Battery revenue depends on dispatch decisions made against prices that are not yet known, and PV generation is one of the main drivers of the daytime price shape on JEPX. The platform brings together realized revenue by site and the forecasts — PV generation and JEPX prices — that feed the next day's dispatch.

Approach

I developed the backend that ingests and stores revenue, price, and generation data per site, together with the forecasting workflows for PV generation and JEPX prices. I also set up routine comparison of forecasts against actuals so that accuracy can be tracked over time. Forecast outputs are served from the same backend rather than kept in notebooks, so dispatch planning and reporting work from the same figures.

Scope

• Revenue monitoring across battery sites
• PV generation forecasting workflow
• JEPX price forecasting workflow
• Forecast evaluation against actuals
• Forecast inputs to daily dispatch planning

Outcome

Revenue by site sits alongside the current forecasts, and forecast accuracy is checked against actual outcomes as part of normal operations. That checking, more than any single model, is what makes the forecasts usable for dispatch decisions.