FCR
About this page
Pre-qualification is the gate every resource has to clear before it can participate in Japan's balancing markets. This page covers performance data acquisition for FCR on a resource registered for offline monitoring: the run that produces the evidence, which Tensor Energy then submits. For FCR the resource responds to frequency autonomously through its droop setting rather than to a dispatch command, so it is driven with a simulated frequency signal: an on-site transducer injects that signal into the resource's control system, and the resulting power response is judged against the droop curve and offered capacity registered for that resource.
An offline resource qualifies on submitted operating data, not on a test the area TSO witnesses. The submission carries the response over each window and the battery's baseline across it.
This page is for the EMS integrator and the transducer engineer, the person who drives the mock frequency into the control system. That is usually the EPC contractor, but it may be another party such as the battery OEM. Everything facing the area TSO and OCCTO sits with the trading member, which is usually Tensor Energy. Where another aggregator runs its own aggregation operation on the Tensor Cloud platform, that aggregator is the trading member and takes those steps itself, so read "Tensor Energy" below as whoever holds that role. What this page covers is what has to be built and configured beforehand, and what each party does on the day.
The mock frequency profiles for the engineer operating the transducer: fcr-prequalification-mock-frequency.xlsx.
One sheet per run, each pattern expanded to one row per second with the baseline the battery should be holding beside it, and the procedure on the first sheet.
What happens
- Tensor Cloud sets the battery's baseline for each window. A power setpoint schedule goes to the site on the normal command topic, holding one flat value across each window: charging for one run, not charging for another, maximum charge for the third. That schedule is the baseline the response is scored against.
- An engineer injects a mock grid frequency, with the EMS integrator supporting. On the chosen day the transducer drives the profile from the workbook into the resource's control system, in place of the live frequency measurement. The battery responds through its droop setting exactly as it would to a real frequency excursion, on top of whatever the baseline has it doing.
- The EMS collects the battery's response and sends it to Tensor Cloud. The EMS integrator publishes the 1 Hz power response together with the 1 Hz frequency the battery was driven against, on the normal telemetry topics and in the normal schema, flagged
pre_qualification: true. This assumes the EMS provider has already completed integration testing with Tensor Cloud. The run is not the place to discover that telemetry is not arriving. - Tensor Energy handles the pre-qualification. Tensor Energy reconstructs the delivered response from those two series against the baseline it commanded, submits it to the area TSO and takes the resource through pre-qualification.
Who does what
| Stage | Tensor Energy | EMS integrator | Transducer engineer |
|---|---|---|---|
| Registration | Registers the droop, deadband and offered capacity the run is scored against | Reports the values actually configured in the controller | - |
| Scheduling | Picks the day with the site. No slot is agreed with the area TSO | Confirms availability for the proposed day | Confirms availability for the proposed day |
| Beforehand | Schedules charge and discharge so the battery starts at 75 % SoC; sends the baseline setpoint schedule and an FCR schedule covering the hour before and all three windows | Verifies the control system accepts an injected signal; stops anything that would move the battery other than the baseline schedule | Installs and wires the transducer |
| On the day | Not on site | Sets pre_qualification: true, keeps telemetry flowing, stays reachable | Operates the transducer and drives the profile |
| Afterwards | Submits the response, the baseline and the simulated frequency to the area TSO in 様式35 format | - | - |
The baseline
Each window runs on a fixed power setpoint, and that setpoint is what the response is measured against. Tensor Cloud sends it, the site holds it. Three things follow.
- At least one window runs on a charging baseline. Tensor Cloud sends it as a battery power setpoint on
cmd/{siteId}/battery/power, the same command channel used in normal operation. - It has to be flat and held. One value for the whole window, and for the hour before it, which is part of the period submitted. If the baseline moves, the response no longer separates cleanly from it and the window cannot be scored.
- Nothing else may move the battery. The baseline and the injected frequency are the only two things acting on it. Anything else shows up as response that the droop curve does not explain.
Offered capacity
Offered capacity is registered for the resource beforehand, and it becomes the upper limit on what can be bid into FCR. For an offline resource it is the largest output change the resource can reach within 30 seconds of a 0.2 Hz frequency drop, or 0.3 Hz in the Hokkaido Electric Power Network area.
The registered value is used in two ways:
- Test a drives the step for the area and checks that the resource reaches at least the registered value less 10 % within 30 seconds.
- Test b scores every evaluated point against the droop curve with a tolerance of ±10 % of the registered value, so the registered number also sets how tight the staircase tolerance is.
Register a value the battery can actually deliver on the day. Too high and test a fails. Too low and test b is scored against a band tighter than the resource needs.
Output change is measured from the baseline, not from zero. On a charging baseline the swing test a has to demonstrate therefore runs from maximum charge toward discharge, and the registered value has to be reachable across that whole span within 30 seconds.
The staircase drives the battery to charge and discharge in turn, so it needs headroom in both directions for the whole window. Tensor Cloud schedules charge and discharge beforehand so that the battery is at 75 % state of charge when the first window opens. Pick the charging baseline so the battery neither fills nor empties before the window closes.
Duration is not assessed for an offline resource, so the value has to be reachable within 30 seconds, not sustainable for any particular length of time.
Droop response
What the injected frequency is meant to exercise.
| Item | Requirement |
|---|---|
| Deadband | Within ±0.01 Hz (50 Hz areas) or ±0.012 Hz (60 Hz areas) |
| Droop | 5 % or less, and constant regardless of deviation magnitude. The area TSO may permit an exception where equipment characteristics justify it. |
| Response time | 30 s |
| Duration | Not assessed |
Check the registered droop against what the battery actually does before the run. Scoring compares each point to a theoretical value taken from the registered droop, so a battery whose real saturation point differs from the registered one can follow its own curve perfectly and still fall outside the ±10 % band.
Frequency measurement
These apply to the frequency the EMS measures and publishes, and the run exercises them. The EMS senses the injected signal and sends it to Tensor Cloud by the same method it uses in regular FCR operation, so the measurement chain is in the loop throughout. What reaches Tensor Cloud is the simulated value the resource is being driven against, measured and delivered through the normal path.
Delay time is not only a limit, it is also applied as a correction when test b is scored. The area TSO shifts the response back by the 2 s delay time before comparing it to the frequency that caused it, so a response that lags by up to 2 s is not penalised for the lag itself. It is the only correction applied, and it applies to test b alone: test a is judged on the raw 30-second window.
| Item | Requirement |
|---|---|
| Measurement interval | 0.1 s or shorter |
| Measurement error | Within ±0.02 Hz |
| Delay time | 2 s or less |
The two tests
Two standardized frequency patterns are used. Each is driven over a 30-minute window, because scoring is done per window. Which pattern runs on which baseline is set out in the three windows.
| Test a (abnormal conditions) | Test b (normal conditions) | |
|---|---|---|
| Verifies | Response time, offered capacity, delay time | Deadband, droop |
| Shape | One sustained step down | Repeating staircase |
| Length | 660 s | 1,800 s |
| Required offline | Yes, this is the only test that establishes offered capacity | Yes |
Test a, abnormal conditions
Test a holds base frequency for 60 seconds, applies a single step down at t=60 s, and holds it to t=660 s.
The step is set by the area:
| Area | Step | Reach offered capacity within |
|---|---|---|
| Other than Hokkaido | 0.2 Hz | 30 s |
| Hokkaido Electric Power Network | 0.3 Hz | 30 s |
The workbook carries exactly that step. Duration is not assessed, but the test a data is still required to confirm offered capacity.
Test b, normal conditions
Test b steps the frequency through six deviation magnitudes, positive first in each pair, to confirm that output tracks the registered droop curve outside the deadband. Each level is held for 120 seconds, with 30 seconds at base frequency between levels.
| Time (s) | Deviation (Hz) | Hold (s) |
|---|---|---|
| 0 | 0 | 30 |
| 30 / 180 | +0.010 / -0.010 | 120 each |
| 330 / 480 | +0.030 / -0.030 | 120 each |
| 630 / 780 | +0.050 / -0.050 | 120 each |
| 930 / 1080 | +0.080 / -0.080 | 120 each |
| 1230 / 1380 | +0.120 / -0.120 | 120 each |
| 1530 / 1680 | +0.160 / -0.160 | 120 each |
| 1800 | 0 | end |
The deviation is the same in both frequency zones. Inject base frequency plus the deviation: 60.010 Hz at a 60 Hz site, 50.010 Hz at a 50 Hz site.
Scoring covers the response in the 30 seconds after each step, initial transient included. Each evaluated point must fall within the droop-curve theoretical value ±10% of offered capacity, and at least 90% of the points in a 30-minute window must be in band. Samples inside the resource's deadband are excluded from evaluation, so the ±0.01 Hz steps may legitimately produce no response at all.
Test b never reaches the deviation at which offered capacity is defined. Its largest step is 0.16 Hz, below the 0.2 Hz point outside Hokkaido and the 0.3 Hz point in the Hokkaido Electric Power Network area, so it exercises the droop line rather than saturation. Test a covers offered capacity.
The three windows
Two things have to be shown:
- Under normal conditions, that the resource responds properly while charging and while not charging.
- Under abnormal conditions, that it reaches offered capacity within 30 seconds across the full span, from maximum charge to maximum discharge.
Three 30-minute windows cover them, each on its own baseline:
| Window | Pattern | Baseline | Shows |
|---|---|---|---|
| 1 | Test b, staircase | Charging, held flat | Droop and deadband while charging |
| 2 | Test b, staircase | Not charging | Droop and deadband while not charging |
| 3 | Test a, single step | Maximum charge | Offered capacity across the full span |
The windows need not be consecutive, and each carries the hour before it into the submitted period.
The day
Tensor Energy agrees the date with the EMS integrator and the transducer engineer. The area TSO is not involved. What matters is that the site can hold the baselines undisturbed that day.
Beforehand
- Confirmation from the EMS integrator that the controller is running the registered droop and deadband settings.
- The charging baseline for windows 1 and 3, in kW. Tensor Energy determines it from the size of the resource.
On the day
- Tensor Cloud sends the baseline setpoint schedule and an FCR schedule covering the hour before the first window and all three windows. The FCR schedule is what puts the site into 1 Hz publishing, by the same rule as any FCR-awarded slot, so nothing has to be switched on by hand. The hour before is part of the period submitted to the TSO.
- Publish 1 Hz supplied power as 1-second average kW at the sending end, and 1 Hz frequency carrying the simulated value the resource is being driven against rather than the live grid frequency.
- Set
pre_qualification: truefor the windows and clear it afterwards. - The transducer engineer operates it and drives the profile from the workbook linked above. The EMS integrator stays reachable while it runs.
Everything reaches Tensor Cloud over the normal telemetry path. Nothing is sent to Tensor Energy separately, and no TSO form is filled in on site.