財務シミュレーション

背景

シミュレーターの一部として、太陽光発電量と市場の予想価格を考慮して、プロジェクトの財務結果を計算する必要があります。全体的な財務実績を計算するために、いくつかの重要な側面があります。

1. 取引シミュレーション
2. PPAのあるプロジェクトのPPA決済の計算
3. 費用（CAPEXとOPEX）の計算
4. 収益の計算

計算ロジック

取引シミュレーション

シミュレーターは、前日のスポット市場と調整力市場の両方への参加をモデル化し、プロジェクトの潜在的な収益機会のより全体像を提供します。

前日市場への参加

「シミュレートされた」予測に基づいて、毎日入札を生成します。予想される実績値を取得し、特定の予想RMSEに基づいてエラーを導入することで、これらの予測を作成します。蓄電池を搭載したプロジェクトの場合、この入札は蓄電池シミュレーションの結果にも依存します。

次に、「実際の」発電量と提出された計画の差に基づいてインバランスを計算します。

note

現在、インバランスを最小限に抑えるためのリアルタイム蓄電池調整の効果はシミュレートされていません。これにより、蓄電池運転からの収益がわずかに過小評価される傾向があります。この側面は将来追加する予定です。

調整力市場への参加

蓄電池を搭載したプロジェクトの場合、シミュレーターは一次オフライン枠への参加もモデル化します。これにより、周波数調整サービスの提供による追加の収益機会を評価できます。

対象プロジェクト

蓄電池容量に関係なく、蓄電池を搭載したすべてのプロジェクトが調整力市場に参加できます。

info

実際には、個別のプロジェクトが市場に参加するには、最低1MWの容量が必要です。容量の小さいプロジェクトは、合計容量が1MW以上になるように集約された場合にのみ参加できます。現在の実装を簡素化するために、蓄電池を搭載したすべてのプロジェクトが参加資格があるものとして扱われます。

取引期間

シミュレーションでは、前日市場への参加が調整力市場より優先されます。前日取引は主に太陽光発電時間帯に行われるため、調整力市場の取引は固定された夜間帯（確保期間）に制限されます。

• 開始:18:00
• 終了:6:00

この期間中、蓄電池は周波数調整サービスを提供しながら、他の時間帯に前日スポット市場取引に参加することができます。

入札計算

シミュレーターは2段階のプロセスに従います。

1. 前日最適化:まず、蓄電池最適化により、太陽光発電量、充電状態(SoC)、および予想されるスポット市場価格に基づいて、1日全体の充放電スケジュールが決定されます。

2. 調整力市場入札:次に、夜間の確保期間(18:00-6:00)について、蓄電池容量に基づいて調整力市場入札が計算されます。調整力市場と前日取引のコミットメントが重複するまれなケースでは、調整力市場の利用可能容量は次のように計算されます。

   • タイムスロットで蓄電池が放電予定の場合:bid_amount = max_discharge_capacity - planned_discharge
   • タイムスロットで蓄電池が充電予定の場合:bid_amount = max_discharge_capacity + planned_charge

このアプローチにより、調整力市場への参加がスポット市場取引と競合するのではなく、補完することが保証されます。場合によっては、計算された入札が定格蓄電池容量を超えることがありますが、これは想定内であり、スポット市場スケジュールを実行しながら調整サービスを提供する蓄電池の能力を考慮しています。

例

前日市場で特定のタイムスロット中に0.5MWで充電するようスケジュールされた1MWの蓄電池を考えてみましょう。そのスロットの調整力市場入札は次のように計算されます。

bid_amount = 1.0 MW + 0.5 MW = 1.5 MW

これにより、蓄電池は計画された充電スケジュールを実行しながら、1.5MWの上げ調整容量を提供できます。

運用上の仮定

• 確保期間中、蓄電池は30分間隔で容量の1.25%で一定の上げ調整(放電)を提供すると仮定されており、12時間で合計30%の放電となります。夜間の調整力市場運用に十分な容量を確保するため、日中の運用では30%の予備が目標とされます。この予備が確保できない場合(例えば、併設システムの太陽光充電が不十分な場合、または系統用蓄電池の系統充電が不十分な場合)、その日の調整力市場への参加はスキップされます。

• 提出されたすべての入札は約定する(市場に受け入れられる)と仮定されます。

収益計算

調整力市場の収益は容量報酬に基づいて計算されます。

• シナリオの仮定の一部として、予想される年間価格を円/kWで入力できます
• シミュレーターは、総入札量とこの価格から報酬を計算します
• 決済は、取引と同じ月内に発生すると仮定されます

蓄電池は確保期間中に放電すると仮定されていますが、モデルは実際の周波数応動の発動による報酬は考慮していないことに注意してください。

info

簡素化のため、現在の実装は前日市場と調整力市場に焦点を当てています。時間前市場や二次/三次調整力などの他の補助サービスはシミュレートしていません。これらは将来のバージョンで追加される予定です。

取引手数料 取引手数料はEPRXによって毎年設定され、30分間隔あたり円/kWで計算されます。総参加費用は最新の公表料金に基づいており、シミュレーション結果にOPEX項目として記録されます。将来の年度については、最新の手数料が一定のままであると仮定されます。最新の手数料については、このリンクを参照してください。

PPA決済計算

PPAの一部のプロジェクトについては、IPPとオフテイカー間の決済も計算します。この計算は総収益に影響します。

ストライク価格の計算

ストライク価格は、PPAスキームによって異なります。

• 固定：固定PPA価格になります。
• インフレエスカレーションによる固定：PPA契約の最初の年のPPA価格に等しく、シナリオのインフレ仮定に従って毎年増加します。
• エスカレーションによる固定：PPA契約の最初の年のPPA価格に等しく、契約のエスカレーションファクターに従って毎年増加します。
• 割引フロア/カラー：市場価格に割引率（$<=1$）を掛けたものに等しく、オプションのフロア価格および/または上限価格によって制限されます。

決済額の計算

PPAには、主にフィジカルおよびバーチャルの2つのタイプがあります。フィジカルPPA（オフサイト、オンサイト、セルフホイーリングPPAを含む）の場合、PPA契約の有効期間中にプラントで生成されたエネルギーは市場で取引されないため、これらのケースでの取引シミュレーションはPPA期間中は実行されません。生成された全てのエネルギーはオフテイカーが直接購入し、ストライク価格で支払われます。これがIPPの主な収益となります。

バーチャルPPAの場合、エネルギーは市場に販売されますが、後で決済額が計算され、市場の状況に応じてIPPとオフテイカー間で資金の移動が発生する可能性があります。この場合の決済額$S$は、次のように計算されます。

$S = P_{strike}(t) - P(t)$

$S$は、オフテイカーがIPPに支払う必要のある価格（kWhあたり）、または値が負の場合はその逆です。

例

特定の時間帯に$S$=4.5円/kWhであり、発電量が400 kWhの場合、オフテイカーはその時間帯に対してIPPに1,800円を支払う必要があります。

費用計算

資本支出（CAPEX）および運用支出（OPEX）を含む、各プロジェクトの費用を計算します。CAPEXはインプットのCAPEX支払いに依存します。

OPEX費用には以下が含まれます。

• 運用および管理（O&M）：月の最終日に割り当てられます。
• アセットマネジメント：月の最終日に割り当てられます。
• 土地リース：年の最終日に割り当てられます。
• 保険：年の最終日に割り当てられます。
• 廃棄費用引当金：これは11年目からのみ支払われ、プロジェクトのCOD日に割り当てられます。
• インバーターの交換：これは、プロジェクトの同じCOD日に割り当てられ、インバーターの保証期間の終了時に課金されます。したがって、CODが2020年4月1日で、保証期間が10年の場合、最初の支払いは2030年4月1日に行われます。
• 固定資産税：これは、入力で設定できる税率に依存します。費用は、元の課税対象CAPEX費用の17年間の減価償却を仮定して、各年の5月末に割り当てられます。
• その他のOPEX：雑費等の支出です。年の最終日に割り当てられます。

収益計算

収益は、市場(前日取引)からの収益、調整力市場の収益、インバランスキャッシュフロー、補助金キャッシュフロー、およびPPA決済などの全ての異なる要素を合計して計算されます。

総キャッシュフローは、収益から全ての費用を差し引くことで計算できます。

IRR計算

年間内部収益率（IRR）を月単位で計算します。まず、毎月のIRRを計算し、次に次の式で年間のIRRに変換します。

$\text{IRR} = (1 + \text{IRR}_{\text{monthly}})^{12} - 1$

info

IRRを計算できない場合があります。これは、データが欠落しているか不完全である（CAPEX情報がないなど）、または計算されたIRRが極端な値を生成するためである可能性があります。これは通常、入力データに問題があることを示します。