JP7574807B2 - 車両管理装置、及び車両管理方法 - Google Patents

Description

本開示は、車両管理装置及び車両管理方法に関する。

たとえば、国際公開第２０１７／００９９７６号（特許文献１）には、外部電源の調整力として車両を動作させる技術が開示されている。

国際公開第２０１７／００９９７６号

ところで、外部電源の調整力として動作可能に構成される車両も、車両の状況によっては外部電源の調整力として機能しないことがある。たとえば、外部電源と電気的に接続されていない車両は、外部電源の調整力として機能しない。外部電源の調整力として動作させる車両を適切に管理するためには、車両の状況を的確に把握することが求められる。

車両の状況は時々刻々と変化する。そこで、車両を管理するサーバが、車両の状況を把握するために、車両と頻繁に通信を行なって、車両からリアルタイムの状況を逐次取得することが考えられる。しかしながら、車両との通信頻度を高めると、通信コストが上昇する。また、長期間にわたって高い頻度で通信を行なうと、処理負荷及び／又は消費電力の増大につながる可能性がある。このため、長期間にわたって高い通信頻度を維持することは、外部電源の調整力として動作させる車両を管理する上で必ずしも適切ではない。

本開示は、上記課題を解決するためになされたものであり、その目的は、外部電源の調整力として動作させる車両を適切に管理することである。

本開示の第１の観点に係る車両管理装置は、複数の車両を管理するように構成される。車両管理装置は、１つ以上のコンピュータを含む。車両管理装置は、複数の車両に含まれる１台以上の対象車両と周期的に通信を行なうように構成される。対象車両は、外部電源の調整力として動作可能に構成される。車両管理装置は、約定直前の第１期間と、需給計画値提出期限直前の第２期間と、外部電源の調整力の提供が要求される期間に対応する第３期間との少なくとも１つの期間において、第１～第３期間を除いた期間の平均通信頻度よりも高い頻度で対象車両と通信を行なうように構成される。

ユーザは、電力市場で売られている商品（調整力）に入札することができる。しかし、電力市場で落札（約定）した調整力を提供しなかったユーザには、契約不履行によるペナルティが発生する。このため、ユーザは、商品（取引対象）が要求する調整力を提供できるか否かを、約定前に判断することが求められる。また、外部電源の調整力を落札したユーザ、あるいは外部電源の同時同量を達成する責任を負うユーザは、所定の期限までに需給計画値を所定の機関へ提出することが求められる。需給計画値は、需要と供給との少なくとも一方の計画値である。ユーザは、調整力の提供が要求される調整期間において車両を調整力として動作させることによって、要求される調整力を提供することができる。しかし、調整期間において、何らかの不具合により車両が調整力として動作しなくなった場合には、代わりの車両を用意することがユーザに求められる。なお、調整期間は、調整力の提供が要求される期間であり、一般に「提供期間」とも称される。また、調整期間の長さは、一般に「継続時間」とも称される。

上記車両管理装置は、上記の第１～第３期間の少なくとも１つの期間において選択的に通信頻度を高めるように構成される。

車両管理装置は、上記第１期間（すなわち、約定直前の期間）において高い頻度で対象車両と通信を行なうことで、入札時（約定直前）の対象車両の状況（ひいては、対象車両が提供可能な調整力）を正確に把握しやすくなる。これにより、ユーザは、対象車両が提供可能な調整力に応じた商品（調整力）に入札しやすくなる。

車両管理装置は、上記第２期間（すなわち、需給計画値提出期限直前の期間）において高い頻度で対象車両と通信を行なうことで、需給計画値提出期限直前の対象車両の状況（ひいては、対象車両による需給状況）を正確に把握しやすくなる。これにより、ユーザは、より正確な需給計画値を所定の機関に提出しやすくなる。需給計画値を提出したユーザは、その需給計画値を基準にした調整力の提供が要求されるため、需給計画値が正確であるほど、要求される調整力を確保しやすくなる。

車両管理装置は、上記第３期間（調整期間に対応する期間）において高い頻度で対象車両と通信を行なうことで、調整期間における対象車両の状況（ひいては、対象車両が提供可能な調整力）を正確に把握しやすくなる。このため、上記第３期間において何らかの不具合により車両が調整力として動作しなくなったときに、ユーザは、代わりの車両として適切な車両を選びやすくなる。

上記構成では、第１～第３期間の少なくとも１つの期間において選択的に通信頻度が高められることで、通信頻度の上昇は短期間に抑えられる。このため、通信頻度の上昇に伴う不具合（通信コストの上昇など）を抑制することができる。

以上説明したように、上記構成を有する車両管理装置によれば、外部電源の調整力として動作させる車両を適切に管理しやすくなる。

車両管理装置は、１つのコンピュータであってもよいし、相互通信可能な複数のコンピュータで構成されてもよい。以下、車両管理装置に含まれるコンピュータを、「管理コンピュータ」とも称する。対象車両は、管理コンピュータが管理する上記複数の車両の、全部であってもよいし、一部であってもよい。

調整力は、外部電源の電力調整（周波数制御、需給バランス調整など）を行なう能力全般を意味し、予備力も含む。上記外部電源は、電力網（たとえば、マイクログリッド、又はインフラストラクチャとして整備された大規模な電力網）であってもよい。上記外部電源は、交流電力を供給してもよいし、直流電力を供給してもよい。通信頻度は、通信周期（通信の間隔）で表わされてもよい。たとえば、通信周期が３０分であれば通信頻度は４８回／日であり、通信周期が１時間であれば通信頻度は２４回／日である。

以下、第１～第３期間を除いた期間を、「他の期間」と称する。第１期間と第２期間との間の期間を、「第１中間期間」と称する。第２期間と第３期間との間の期間を、「第２中間期間」と称する。第１及び第２中間期間の各々は、他の期間に相当する。管理コンピュータは、第１及び第２中間期間における平均通信頻度を、他の期間の平均通信頻度とみなしてもよい。管理コンピュータは、上記第１～第３期間の少なくとも１つの期間における平均通信頻度を、他の期間の平均通信頻度の１．５倍以上１５倍未満にしてもよい。

車両管理装置は、電力市場で調整力の入札を行なうように構成されてもよい。車両管理装置は、対象車両の中から選ばれた１台以上の車両を、電力市場で約定した調整力として動作させるための通知を行なうように構成されてもよい。第１期間は、約定３時間前から約定タイミングまでの期間の少なくとも一部に相当してもよい。

上記構成によれば、車両管理装置が電力市場で調整力の入札を適切に行ないやすくなる。なお、約定前には入札が行なわれる。第１期間は、入札時（たとえば、入札２時間前から入札タイミングまでの期間の少なくとも一部）に相当してもよい。

車両管理装置は、通信により対象車両から取得した情報を用いて需給計画値を決定するように構成されてもよい。車両管理装置は、決定された需給計画値を需給計画値提出期限までに送信するように構成されてもよい。第２期間は、需給計画値提出期限３時間前から需給計画値提出期限までの期間の少なくとも一部に相当してもよい。

上記構成によれば、車両管理装置が適切な需給計画値を期限までに所定の機関に提出しやすくなる。需給計画値提出期限は、ゲートクローズであってもよい。

第３期間は、外部電源の調整力の提供が要求される期間、又は外部電源の調整力の提供が要求される期間の前後の少なくとも一方に３０分以内の余裕期間を加えた期間であってもよい。車両管理装置は、第３期間において、対象車両の中から選ばれた１台以上の車両の全てが外部電源の調整力として動作するか否かを判断するように構成されてもよい。車両管理装置は、第３期間において、対象車両の中から選ばれた１台以上の車両のいずれかが外部電源の調整力として動作しないと判断される場合には、通信により対象車両から取得した情報を用いて、対象車両の中から代わりの車両を選ぶように構成されてもよい。

上記構成によれば、第３期間において何らかの不具合により車両が調整力として動作しなくなったときに、車両管理装置が、代わりの車両（すなわち、調整力として動作しなくなった車両の代わりに調整力として動作する車両）として適切な車両を選びやすくなる。

車両管理装置は、第１～第３期間の各々において、第１～第３期間を除いた期間の平均通信頻度よりも高い頻度で対象車両と通信を行なうように構成されてもよい。車両管理装置は、第１～第３期間の各々において、通信により対象車両から取得した情報を用いて対象車両の行動予測を行なうように構成されてもよい。

上記構成によれば、車両管理装置が、対象車両の行動予測を適切に行ないやすくなる。そして、車両管理装置は、対象車両の行動に関する予測情報を用いて、対象車両による需給状況と、対象車両が提供可能な調整力との少なくとも１つを適切に求めやすくなる。

車両管理装置は、対象車両との通信により、対象車両に関する車両情報を周期的に取得するように構成されてもよい。車両情報は、対象車両の位置と、対象車両が備える蓄電装置のＳＯＣ（State Of Charge）との少なくとも一方を含んでもよい。

上記構成によれば、車両管理装置が、対象車両による需給状況と、対象車両が提供可能な調整力との少なくとも１つを求めやすくなる。

複数の車両は、外部電源の調整力として動作しない非対象車両を含んでもよい。車両管理装置は、第１～第３期間の少なくとも１つにおいて、非対象車両との通信よりも高い頻度で対象車両と通信を行なうように構成されてもよい。

車両管理装置は、電力調整以外の目的で車両（非対象車両）を管理してもよい。たとえば、車両管理装置は、通信により車両から得た情報を用いて、その車両の状況に合った充電タイミングをユーザに通知するサービスを提供してもよい。ただし、第１～第３期間の各々においては、対象車両に関する情報が特に求められる。そこで、上記の車両管理装置は、第１～第３期間の少なくとも１つにおいて、非対象車両との通信よりも高い頻度で対象車両と通信を行なう。このように優先度の高い対象車両との通信頻度を選択的に高めることで、通信頻度の上昇に伴う不具合（通信コストの上昇など）を抑制することができる。

本開示の第２の観点に係る車両管理方法は、約定直前に設定された第１期間と、需給計画値提出期限直前に設定された第２期間と、外部電源の調整力の提供が要求される期間に対応して設定された第３期間とを含む通信期間において、車両管理装置が１台以上の対象車両と周期的に通信を行なうことと、車両管理装置が、第１期間と第２期間と第３期間との少なくとも１つを含む通信頻度アップ期間内か否かを判断することと、車両管理装置が、通信頻度アップ期間において、第１～第３期間を除いた通信期間の平均通信頻度よりも高い頻度で対象車両と通信を行なうこととを含む。

上記車両管理方法によっても、前述した車両管理装置と同様、外部電源の調整力として動作させる車両を適切に管理することが可能になる。

上記の車両管理方法は、第１期間において、通信により対象車両から取得した情報を用いて、対象車両が提供可能な調整力を予測することと、第２期間において、通信により対象車両から取得した情報を用いて、需給計画値を求めることと、第３期間において、対象車両の中から選ばれた１台以上の車両を外部電源の調整力として動作させることと、第３期間において、対象車両の中から選ばれた１台以上の車両のいずれかが外部電源の調整力として動作していない場合に、通信により対象車両から取得した情報を用いて、対象車両の中から代わりの車両を選ぶこととをさらに含んでもよい。

上記構成によれば、管理される車両によって外部電源の電力調整を適切に行ないやすくなる。

上述したいずれかの装置又は方法によって管理される車両は、蓄電装置を備える電動車（以下、「ｘＥＶ」とも称する）であってもよい。ｘＥＶは、電力を動力源の全て又は一部として利用する車両である。ｘＥＶには、ＢＥＶ（電気自動車）、ＰＨＥＶ（プラグインハイブリッド車）、ＦＣＥＶ（燃料電池車）、及びレンジエクステンダーＥＶが含まれる。

本開示によれば、外部電源の調整力として動作させる車両を適切に管理することが可能になる。

本開示の実施の形態に係る電力管理システムの概略的な構成を示す図である。 対象車両の構成の一例を示す図である。 本開示の実施の形態に係る第１及び第２管理コンピュータの詳細構成を示す図である。 図３に示した第１管理コンピュータによって実行される対象車両との通信に係る処理を示すフローチャートである。 本開示の実施の形態に係る車両管理方法における通信頻度の制御について説明するための図である。 本開示の実施の形態に係る電力市場の概要を示す図である。 図３に示した第２管理コンピュータによって実行される市場取引に係る処理を示すフローチャートである。 図３に示した第２管理コンピュータによって実行される計画値提出処理を示すフローチャートである。 図３に示した第２管理コンピュータによって実行される代替車両選定処理を示すフローチャートである。 図１に示したＴＳＯサーバによって実行される電力調整に係る処理を示すフローチャートである。 図５に示した通信態様の第１変形例を示す図である。 図５に示した通信態様の第２変形例を示す図である。 図７に示した処理の変形例を示すフローチャートである。 図４に示した処理の変形例を示すフローチャートである。

本開示の実施の形態について、図面を参照しながら詳細に説明する。図中、同一又は相当部分には同一符号を付してその説明は繰り返さない。

図１は、本開示の実施の形態に係る電力管理システムの概略的な構成を示す図である。図１を参照して、この実施の形態に係る電力管理システムは、車群ＶＧと、サーバ７００と、車両管理装置１０００とを含む。車両管理装置１０００は、サーバ３００及び６００を含む。サーバ３００及び６００の各々は、管理コンピュータに相当する。

電力系統ＰＧは、送配電設備によって構築される電力網である。電力系統ＰＧには、複数の発電所が接続されている。電力系統ＰＧは、それらの発電所から電力の供給を受けている。この実施の形態では、電力会社が、電力系統ＰＧ（商用電源）を保守及び管理する。電力会社は、後述するＴＳＯ（系統運用者）に相当する。電力系統ＰＧは、交流電力（たとえば、三相交流電力）を供給する。サーバ７００は、ＴＳＯに帰属するコンピュータ（以下、「ＴＳＯサーバ」と表記する場合がある）に相当する。サーバ７００は、後述する中給システム及び簡易指令システムを内蔵する。サーバ６００とサーバ７００とは相互に通信可能に構成される。この実施の形態に係る電力系統ＰＧは、本開示に係る「外部電源」の一例に相当する。

サーバ３００は、車群ＶＧを管理するように構成される。以下では、サーバ３００を「車両情報管理サーバ」と表記する場合がある。詳細は後述するが、サーバ３００は、車群ＶＧに含まれる各車両と周期的に通信を行なうように構成される。この実施の形態では、車群ＶＧに含まれる各車両が、本開示に係る「対象車両」の一例に相当する。車群ＶＧに含まれる車両の数は、５台以上３０台未満であってもよいし、３０台以上１００台未満であってもよいし、１００台以上であってもよい。この実施の形態では、車群ＶＧが５０台程度の車両を含むものとする。

車群ＶＧに含まれる各車両は、ｘＥＶであり、電力系統ＰＧの調整力として動作可能に構成される。以下、区別しない場合は、車群ＶＧに含まれる各車両を「車両１００」と称する。図２は、車両１００の構成を示す図である。

図２を参照して、車両１００は、走行用の電力を蓄電するバッテリ１３０を備える。車両１００は、バッテリ１３０に蓄えられた電力を用いて走行可能に構成される。この実施の形態に係る車両１００は、エンジン（内燃機関）を備えない電気自動車（ＢＥＶ）である。バッテリ１３０としては、公知の車両用蓄電装置（たとえば、液式二次電池、全固体二次電池、又は組電池）を採用できる。車両用二次電池の例としては、リチウムイオン電池、ニッケル水素電池が挙げられる。この実施の形態に係るバッテリ１３０は、本開示に係る「蓄電装置」の一例に相当する。

車両１００は、電子制御装置（以下、「ＥＣＵ（Electronic Control Unit）」と称する）１５０を備える。ＥＣＵ１５０は、バッテリ１３０の充電制御及び放電制御を行なうように構成される。車両１００は、バッテリ１３０の状態を監視する監視モジュール１３１をさらに備える。監視モジュール１３１は、バッテリ１３０の状態（たとえば、電圧、電流、及び温度）を検出する各種センサを含み、検出結果をＥＣＵ１５０へ出力する。監視モジュール１３１は、上記センサ機能に加えて、ＳＯＣ（State Of Charge）推定機能、ＳＯＨ（State of Health）推定機能、セル電圧の均等化機能、診断機能、及び通信機能をさらに有するＢＭＳ（Battery Management System）であってもよい。ＥＣＵ１５０は、監視モジュール１３１の出力に基づいてバッテリ１３０の状態（たとえば、温度、電流、電圧、ＳＯＣ、及び内部抵抗）を取得することができる。

車両１００は、たとえば図２に示すＥＶＳＥ（Electric Vehicle Supply Equipment）２００と電気的に接続可能に構成される。ＥＶＳＥ２００は、車両外部の給電設備に相当する。ＥＶＳＥ２００は、電力系統ＰＧと電気的に接続されており、電力系統ＰＧから電力の供給を受けて、給電を行なうように構成される。ＥＶＳＥ２００の本体には、充電ケーブル２１０が接続されている。充電ケーブル２１０は、常にＥＶＳＥ２００の本体に接続されていてもよいし、ＥＶＳＥ２００の本体に対して着脱可能であってもよい。充電ケーブル２１０は、先端にコネクタ２１０ａを有し、内部に通信線及び電力線を含む。１つの電線が通信線及び電力線の両方を兼ねてもよい。ＥＶＳＥ２００は、家庭用のＥＶＳＥであってもよいし、公共のＥＶＳＥであってもよい。

車両１００は、インレット１１０及び充放電器１２０を備える。ＥＶＳＥ２００の本体につながる充電ケーブル２１０のコネクタ２１０ａが車両１００のインレット１１０に接続されることで、車両１００はＥＶＳＥ２００を介して電力系統ＰＧと電気的に接続された状態（以下、「プラグイン状態」とも称する）になる。一方、車両１００の走行中においては、車両１００がＥＶＳＥ２００及び電力系統ＰＧの各々と電気的に接続されていない状態（以下、「プラグアウト状態」とも称する）になる。なお、図２には、ＥＶＳＥ２００の給電方式に対応するインレット１１０及び充放電器１２０のみを示しているが、車両１００は、複数種の給電方式（たとえば、ＡＣ方式及びＤＣ方式）に対応できるように複数のインレットを備えてもよい。

充放電器１２０は、インレット１１０とバッテリ１３０との間に位置する。充放電器１２０は、充放電リレーと電力変換回路と（いずれも図示せず）を含んで構成される。充放電リレーは、インレット１１０からバッテリ１３０までの電力経路の接続／遮断を切り替える。電力変換回路は、たとえば双方向インバータを含む。充放電器１２０に含まれる充放電リレー及び電力変換回路の各々は、ＥＣＵ１５０によって制御される。車両１００は、充放電器１２０の状態を監視する監視モジュール１２１をさらに備える。監視モジュール１２１は、充放電器１２０の状態を検出する各種センサ（たとえば、電流センサ及び電圧センサ）を含み、検出結果をＥＣＵ１５０へ出力する。

プラグイン状態の車両１００では、外部充電（すなわち、車両外部からの電力によるバッテリ１３０の充電）と外部給電（すなわち、バッテリ１３０の電力による車両外部への給電）とが可能になる。車両１００は、外部充電及び外部給電によって電力系統ＰＧの電力調整を行なうことができる。外部充電のための電力は、たとえばＥＶＳＥ２００から充電ケーブル２１０を通じてインレット１１０に供給される。充放電器１２０は、インレット１１０が受電した電力（たとえば、交流電力）をバッテリ１３０の充電に適した電力（たとえば、直流電力）に変換し、変換された電力をバッテリ１３０へ出力するように構成される。外部給電のための電力は、バッテリ１３０から充放電器１２０に供給される。充放電器１２０は、バッテリ１３０から供給される直流電力を外部給電に適した電力（たとえば、交流電力）に変換し、変換された電力をインレット１１０へ出力するように構成される。外部充電及び外部給電のいずれかが実行されるときには充放電器１２０の充放電リレーが閉状態（接続状態）にされ、外部充電及び外部給電のいずれも実行されないときには充放電器１２０の充放電リレーが開状態（遮断状態）にされる。

ＥＣＵ１５０は、プロセッサ１５１、ＲＡＭ（Random Access Memory）１５２、記憶装置１５３、及びタイマ１５４を含んで構成される。ＥＣＵ１５０はコンピュータであってもよい。プロセッサ１５１はＣＰＵ（Central Processing Unit）であってもよい。ＲＡＭ１５２は、プロセッサ１５１によって処理されるデータを一時的に記憶する作業用メモリとして機能する。記憶装置１５３は、格納された情報を保存可能に構成される。記憶装置１５３には、プログラムのほか、プログラムで使用される情報（たとえば、マップ、数式、及び各種パラメータ）が記憶されている。この実施の形態では、記憶装置１５３に記憶されているプログラムをプロセッサ１５１が実行することで、ＥＣＵ１５０における各種制御が実行される。タイマ１５４は、設定時刻の到来をプロセッサ１５１に知らせるように構成される。また、ＥＣＵ１５０は、ＥＣＵ１５０に内蔵されるリアルタイムクロック（ＲＴＣ）回路（図示せず）を利用して現在時刻を取得できる。

車両１００は、走行駆動部１４０と、ＨＭＩ（Human Machine Interface）１６０と、位置センサ１７０と、通信機器１８０と、駆動輪Ｗとをさらに備える。ＨＭＩ１６０は入力装置及び表示装置を含む。ＨＭＩ１６０は、タッチパネルディスプレイを含んでもよい。ＨＭＩ１６０は、音声入力を受け付けるスマートスピーカを含んでもよい。位置センサ１７０は、車両１００の位置を検出して、検出結果をＥＣＵ１５０へ出力するように構成される。位置センサ１７０は、ＧＰＳ（Global Positioning System）を利用したセンサであってもよい。なお、車両１００の駆動方式は、図２に示される前輪駆動に限られず、後輪駆動又は４輪駆動であってもよい。

走行駆動部１４０は、図示しないＰＣＵ（Power Control Unit）とＭＧ（Motor Generator）とを含み、バッテリ１３０に蓄えられた電力を用いて車両１００を走行させるように構成される。ＰＣＵは、たとえば、インバータと、コンバータと、リレー（以下、「ＳＭＲ（System Main Relay）」と称する）とを含んで構成される。ＰＣＵは、ＥＣＵ１５０によって制御される。ＭＧは、たとえば三相交流モータジェネレータである。ＭＧは、ＰＣＵによって駆動され、駆動輪Ｗを回転させるように構成される。ＰＣＵは、バッテリ１３０から供給される電力を用いてＭＧを駆動する。また、ＭＧは、回生発電を行ない、発電した電力をバッテリ１３０に供給するように構成される。走行のためのモータ（ＭＧ）の数は任意であり、１つでも２つでも３つ以上でもよい。走行のためのモータはインホイールモータであってもよい。ＳＭＲは、バッテリ１３０からＰＣＵまでの電力経路の接続／遮断を切り替えるように構成される。ＳＭＲは、車両１００の走行時に閉状態（接続状態）にされる。

通信機器１８０は、各種通信Ｉ／Ｆ（インターフェース）を含んで構成される。ＥＣＵ１５０は、通信機器１８０を通じて車両１００の外部の装置と通信を行なうように構成される。通信機器１８０は、移動体通信網（テレマティクス）にアクセス可能な無線通信機（たとえば、ＤＣＭ（Data Communication Module））を含む。無線通信機は、５Ｇ（第５世代移動通信システム）対応の通信Ｉ／Ｆを含んでもよい。車両１００は、プラグイン状態とプラグアウト状態との両方において、サーバ３００と無線通信を行なってもよい。この実施の形態では、車両１００がＥＶＳＥを経由せずに移動体通信網を通じてサーバ３００と無線通信する。車両１００は、サーバ３００からの指令又は通知を上記無線通信機で受信する。また、車両１００は、プラグイン状態においてサーバ６００及び７００と有線通信（ＥＶＳＥを介した通信）を行なってもよい。

モバイル端末ＵＴは、車両１００のユーザによって携帯される端末である。この実施の形態では、モバイル端末ＵＴとして、タッチパネルディスプレイを具備するスマートフォンを採用する。ただしこれに限られず、モバイル端末ＵＴとしては、任意のモバイル端末を採用可能であり、ラップトップ、タブレット端末、ウェアラブルデバイス（たとえば、スマートウォッチ又はスマートグラス）、又は電子キーなども採用可能である。

モバイル端末ＵＴは、予めサーバ３００に登録され、サーバ３００と無線通信可能に構成される。モバイル端末ＵＴには所定のアプリケーションソフトウェア（以下、単に「アプリ」と称する）がインストールされている。サーバ３００は、モバイル端末との通信を開始する前に所定の認証を行ない、認証に成功したモバイル端末のみと通信を行なうように構成される。これにより、サーバ３００に登録されていないモバイル端末が不正な通信を行なうことを抑制できる。車両１００のユーザは、所定の認証情報（上記認証に成功するための情報）をモバイル端末ＵＴに入力することで、サーバ３００との通信を開始できる。また、上記アプリに所定の認証情報を登録しておくことで、上記認証情報の入力を省略できる。モバイル端末ＵＴは、上記アプリを通じてサーバ３００と情報のやり取りを行なうことができる。

この実施の形態では、モバイル端末ＵＴが位置センサを備える。位置センサは、ＧＰＳを利用したセンサであってもよい。モバイル端末ＵＴは、ユーザの位置を示す情報（以下、「ユーザ位置情報」とも称する）を、定期的に又はサーバ３００からの要求に応じて、サーバ３００へ送信する。

モバイル端末ＵＴは、上記ユーザ位置情報を用いて、車両１００の走行計画を予測する。走行計画の例としては、乗車時刻（又は、発車時刻）、帰宅時刻、目的地（又は、目的地までの走行ルート）が挙げられる。たとえば、モバイル端末ＵＴは、車両１００を降りたユーザの位置の推移に基づいて、ユーザが車両１００に乗車する時刻（以下、「乗車時刻」とも称する）を予測してもよい。モバイル端末ＵＴは、車両１００の電子キーとして機能してもよい。ユーザが、車両１００を降りた後、モバイル端末ＵＴを用いて車両１００のドアをロックすると、降車時のモバイル端末ＵＴの位置が、車両１００の駐車位置としてモバイル端末ＵＴに登録されるとともに、モバイル端末ＵＴによるユーザの位置の追跡（位置センサによる位置検出、及びユーザ位置の記録）が開始されてもよい。モバイル端末ＵＴは、履歴データ（たとえば、気象情報、渋滞情報、及び曜日によって区別して管理される過去の位置データ）からユーザの行動パターンを学習してもよい。

モバイル端末ＵＴは、上記走行計画をサーバ３００へ送信する。さらに、ユーザがモバイル端末ＵＴに設定した走行計画がモバイル端末ＵＴからサーバ３００へ送信されてもよい。モバイル端末ＵＴにインストールされたスケジューラアプリ又は目覚ましアプリに設定された予定が自動的にサーバ３００へ送信されてもよい。また、ユーザが車両１００のナビゲーションシステム（図示せず）に設定した走行計画がサーバ３００へ送信されてもよい。

ＥＣＵ１５０を含む車両システム（車両１００を制御するシステム）のオン（作動）／オフ（停止）は、ユーザが図示しない起動スイッチを操作することによって切り替わる。車両１００の起動スイッチは、車両システムを起動させるためのスイッチであり、起動スイッチがオン操作されることによって車両システム（ＥＣＵ１５０を含む）が起動する。また、車両システムが作動しているときに、起動スイッチがオフ操作されると、車両システムは停止状態になる。ただし、走行中の車両１００においては、起動スイッチのオフ操作が禁止される。一般に、起動スイッチは「パワースイッチ」又は「イグニッションスイッチ」などと称される。

上述した車両１００の構成は一例にすぎない。上記の例では、電力系統ＰＧからＥＶＳＥ２００を経て車両１００に交流電力が供給され、充放電器１２０によって交流電力が直流電力に変換され、直流電力がバッテリ１３０に入力される。しかし、充放電器１２０の機能は、車両ではなくＥＶＳＥに搭載されてもよい。充電ケーブルのコネクタに充放電器が内蔵されてもよい。電力系統から供給される交流電力をＥＶＳＥが直流電力に変換して、ＥＶＳＥから車両へ直流電力が出力されてもよい。

再び図１を参照して、サーバ６００は、アグリゲータに帰属するコンピュータ（以下、「アグリゲータサーバ」と表記する場合がある）に相当する。アグリゲータは、複数の分散型エネルギーリソース（以下、「ＤＥＲ（Distributed Energy Resources）」とも称する）を束ねてエネルギーマネジメントサービスを提供する電気事業者である。車群ＶＧに含まれる各車両は、ＤＥＲとして機能し得る。サーバ６００は、複数のＤＥＲ（車群ＶＧを含む）を遠隔・統合制御することによって、これらのＤＥＲをＶＰＰ（仮想発電所）として機能させてもよい。ＶＰＰは、ＩｏＴ（モノのインターネット）を利用した高度なエネルギーマネジメント技術により多数のＤＥＲを束ね、これらＤＥＲを遠隔・統合制御することによってあたかも１つの発電所のように機能させる仕組みである。サーバ６００は、各ＤＥＲに対してＤＲ（デマンドレスポンス）を実施してもよい。

サーバ６００は、リモート制御により、電力系統ＰＧの電力調整のための充電又は放電をＤＥＲ（たとえば、図２に示したバッテリ１３０）に行なわせることができる。たとえば、後述するインバランスが発生したときに、サーバ６００は、そのインバランスを解消するようにＤＥＲ（たとえば、図２に示した充放電器１２０）を制御する。この実施の形態では、車群ＶＧに含まれる各車両（対象車両）が、サーバ３００及び６００だけでなくサーバ７００とも通信可能に構成される。対象車両は、サーバ６００ではなくサーバ７００によってリモート制御されることもある。

図３は、サーバ３００及び６００の詳細構成を示す図である。図３を参照して、サーバ３００、６００はそれぞれ、プロセッサ３１０、６１０と、記憶装置３２０、６２０と、通信装置３３０、６３０と、ＨＭＩ３４０、６４０とを備える。１つのサーバに搭載されるプロセッサ（たとえば、ＣＰＵ）の数は任意であり、１つでも複数でもよい。記憶装置３２０及び６２０の各々は、各種情報を保存可能に構成される。記憶装置３２０、６２０には、それぞれプロセッサ３１０、６１０に実行されるプログラムのほか、プログラムで使用される情報（たとえば、マップ、数式、及び各種パラメータ）が記憶されている。通信装置３３０及び６３０の各々は、各種通信Ｉ／Ｆ（インターフェース）を含む。ＨＭＩ３４０及び６４０の各々は入力装置及び表示装置を含む。ＨＭＩ３４０及び６４０の各々は、タッチパネルディスプレイを含んでもよい。

サーバ３００は、車群ＶＧに含まれる各車両に関する情報（以下、「車両情報」とも称する）を管理するように構成される。車両情報は、サーバ３００の記憶装置３２０に記憶される。具体的には、車両を識別するための識別情報（車両ＩＤ）が車両ごとに付与されており、サーバ３００は車両情報を車両ＩＤで区別して管理している。車両ＩＤは、車両ごとに固有の番号（たとえば、ＶＩＮ（Vehicle Identification Number））であってもよいし、車両の通信アドレスであってもよい。車両情報には、たとえば、車両の位置と、車両が備える蓄電装置のＳＯＣと、車両の走行計画と、系統接続状態（プラグイン状態／プラグアウト状態）と、車両システムの状態（オン／オフ）とが含まれる。また、車両の仕様（たとえば、充放電に関するスペック）が予めサーバ３００に登録されてもよい。

この実施の形態では、車群ＶＧに含まれる各車両が対象車両に相当する。対象車両においてプラグイン状態とプラグアウト状態とが切り替わったタイミングで、対象車両からサーバ３００へ最新の系統接続状態が送信される。また、対象車両において車両システムのオン／オフが切り替わったタイミングで、対象車両からサーバ３００へ最新の車両システムの状態が送信される。また、対象車両の走行計画が変更されたタイミングで、対象車両のユーザが携帯するモバイル端末から（又は、対象車両から）サーバ３００へ最新の走行計画が送信される。

また、サーバ３００は、各対象車両と周期的に通信を行なうように構成される。具体的には、サーバ３００は、以下に説明する図４に示す処理を繰り返し実行する。こうした周期的な通信によっても、対象車両からサーバ３００へ車両情報が送信される。

図４は、サーバ３００によって実行される対象車両との通信に係る処理を示すフローチャートである。このフローチャートに示される処理は、対象車両ごとに実行される。サーバ３００は、各対象車両について図４に示す処理を繰り返し実行する。この実施の形態では、記憶装置３２０に記憶されているプログラムをプロセッサ３１０が実行することで、図４に示す一連の処理が実行される。記憶装置３２０には、通信頻度アップフラグ（図４に示す処理で使用されるパラメータ）も記憶されている。以下では、フローチャート中の各ステップを、単に「Ｓ」と表記する。

図１～図３とともに図４を参照して、Ｓ１１では、通信頻度アップ期間内か否かを、サーバ３００が判断する。具体的には、サーバ３００は、後述する通信頻度アップフラグの値（図７～図９参照）に基づいて、通信頻度アップ期間内か否かを判断する。この実施の形態では、後述する期間Ｔ１０、Ｔ２０、及びＴ３０が、通信頻度アップ期間に相当する（図５参照）。通信頻度アップフラグがＯＮであることは、通信頻度アップ期間内であることを意味する。通信頻度アップフラグがＯＦＦであることは、通信頻度アップ期間外であることを意味する。

通信頻度アップ期間外である場合（Ｓ１１にてＮＯ）には、サーバ３００は、Ｓ１２において、前回通信から所定の時間Ｔ１が経過したか否かを判断する。時間Ｔ１は、通信頻度アップ期間外（他の期間）における通信周期（通信の間隔）に相当する。この実施の形態では、時間Ｔ１を１時間とする。これにより、通信頻度アップ期間外においては、サーバ３００と対象車両との通信が約１回／時の頻度で行なわれるようになる。ただしこれに限られず、時間Ｔ１は１時間よりも長くてもよい。

通信頻度アップ期間内である場合（Ｓ１１にてＹＥＳ）には、サーバ３００は、Ｓ１３において、前回通信から所定の時間Ｔ２が経過したか否かを判断する。時間Ｔ２は、通信頻度アップ期間内（後述する期間Ｔ１０、Ｔ２０、Ｔ３０のいずれかの期間内）における通信周期（通信の間隔）に相当する。時間Ｔ２は、時間Ｔ１よりも短い時間に設定される。この実施の形態では、時間Ｔ２を３０分とする。これにより、通信頻度アップ期間内においては、サーバ３００と対象車両との通信が約２回／時の頻度で行なわれるようになる。ただしこれに限られず、時間Ｔ２は３０分よりも短い時間（たとえば、１０分、１５分、又は２０分）であってもよい。

なお、通信周期が切り替わるときには、サーバ３００は通信周期を徐々に変化させてもよい。たとえば、通信周期が時間Ｔ１から時間Ｔ２に切り替わるときには、プロセッサ３１０の処理負荷が過剰に大きくならないように、サーバ３００が通信周期を時間Ｔ１から時間Ｔ２に徐々に変化させてもよい。通信周期が急激に変化しないように、通信装置３３０において通信周期が調整されてもよい。

Ｓ１２において前回通信からまだ時間Ｔ１が経過していないと判断された場合には（Ｓ１２にてＮＯ）、処理はＳ１１に戻る。また、Ｓ１３において前回通信からまだ時間Ｔ２が経過していないと判断された場合にも（Ｓ１３にてＮＯ）、処理はＳ１１に戻る。Ｓ１２及びＳ１３のいずれかにおいてＮＯと判断されることは、対象車両との通信タイミングではないことを意味する。他方、Ｓ１２及びＳ１３のいずれかにおいてＹＥＳと判断されることは、対象車両との通信タイミングになったことを意味する。

Ｓ１２においてＹＥＳと判断されると、サーバ３００は、Ｓ１４において、対象車両と通信を行ない、対象車両から車両情報を取得する。そして、サーバ３００は、取得した車両情報を記憶装置３２０に保存する。Ｓ１４において対象車両からサーバ３００へ送信される車両情報には、対象車両の位置と、対象車両が備える蓄電装置のＳＯＣとが含まれる。たとえば、図２に示した車両１００において、位置センサ１７０が検出した最新の位置（たとえば、経度及び緯度）と、監視モジュール１３１が検出した最新のＳＯＣとが、サーバ３００へ送信される。ＳＯＣは、蓄電装置の蓄電残量を示し、たとえば満充電容量（満充電状態の蓄電量）に対する現在の蓄電量の割合を０～１００％で表わしたものである。サーバ３００は、Ｓ１４において、モバイル端末ＵＴ（図２）からも、上記対象車両に関する車両情報（たとえば、走行計画）を取得して、対象車両から取得した車両情報とともに記憶装置３２０に保存してもよい。サーバ３００は、記憶装置３２０において、取得した時刻が分かるように取得時刻ごとにデータを区別して管理してもよい。Ｓ１４の処理が実行されると、処理は最初のステップ（Ｓ１１）に戻る。サーバ３００は、サーバ６００からの要求に応じて、自らが保有するデータをサーバ６００へ送信する。

Ｓ１３においてＹＥＳと判断されると、サーバ３００は、Ｓ１５において、上記Ｓ１４と同様に、対象車両と通信を行ない、対象車両から車両情報を取得する。そして、サーバ３００は、取得した車両情報を記憶装置３２０に保存する。また、サーバ３００は、モバイル端末ＵＴからも、上記対象車両に関する車両情報（たとえば、走行計画及びユーザ位置情報）を取得して、対象車両から取得した車両情報とともに記憶装置３２０に保存する。続けて、サーバ３００は、Ｓ１６において、自らが保有する最新のデータをサーバ６００へ送信する。Ｓ１６においてサーバ３００からサーバ６００へ送信される車両情報には、対象車両の位置と、対象車両が備える蓄電装置のＳＯＣと、走行計画と、車両システムの状態と、系統接続状態と、ユーザ位置情報とが含まれる。このように、通信頻度アップ期間内においては、サーバ３００が、サーバ６００からの要求を待たずに、最新の車両情報をサーバ６００へ送信する。Ｓ１６の処理が実行されると、処理は最初のステップ（Ｓ１１）に戻る。

サーバ３００は、上記Ｓ１４及びＳ１５の各々において、たとえば要求信号（ポーリング信号）を対象車両へ送信する。そして、対象車両は、その要求信号に応答してサーバ３００へ車両情報を送信する。通信頻度アップ時には（Ｓ１１にてＹＥＳ）、通常時（Ｓ１１にてＮＯ）よりも上記要求信号の発信間隔を短くする。ただしこれに限られず、対象車両から所定間隔でサーバ３００へ車両情報が送信されるようにしてもよい。そして、通信頻度アップ時（Ｓ１１にてＹＥＳ）にサーバ３００が対象車両へ通信頻度アップ要求を送信してもよい。対象車両は、サーバ３００から通信頻度アップ要求を受けたときに上記所定間隔を短くしてもよい。

図５は、この実施の形態に係る車両管理方法における通信頻度の制御について説明するための図である。

図１～図３とともに図５を参照して、車両管理装置１０００（より特定的には、サーバ３００）は、車群ＶＧに含まれる各車両と周期的に通信を行なうように構成される（図４参照）。そして、車両管理装置１０００は、図５に示す期間Ｔ１０、Ｔ２０、及びＴ３０において、他の期間（期間Ｔ１０、Ｔ２０、及びＴ３０を除いた期間）の平均通信頻度よりも高い頻度で対象車両と通信を行なうように構成される。具体的には、期間Ｔ１０、Ｔ２０、及びＴ３０は、通信頻度アップ期間に相当する。通信頻度アップ期間内に入ると、サーバ６００がサーバ３００に対して通信頻度アップフラグをＯＮにすることを要求する。これにより、サーバ３００と対象車両との通信頻度が通常の通信頻度よりも高くなる（図４参照）。通信頻度アップ期間外に出ると、サーバ６００がサーバ３００に対して通信頻度アップフラグをＯＦＦにすることを要求する。これにより、サーバ３００と対象車両との通信頻度が通常の通信頻度に戻る（図４参照）。上記のような制御により、期間Ｔ１０、Ｔ２０、及びＴ３０の各々において通信頻度のピーク（極大頻度）が形成される。期間Ｔ１０、Ｔ２０、Ｔ３０は、それぞれ本開示に係る「第１期間」、「第２期間」、「第３期間」の一例に相当する。

図５に示すタイミングｔ_Ａ（以下、「ｔ_Ａ」と表記する）は、約定タイミングに相当する。ｔ_Ａ前に、後述する電力市場（図６参照）に対して入札が行なわれ、落札すると、約定に至る。期間Ｔ１０はｔ_Ａ直前の期間に相当する。期間Ｔ１０は、たとえば約定３時間前から約定タイミングまでの期間の少なくとも一部に設定される。この実施の形態では、入札１時間前から入札タイミングまでの期間を、期間Ｔ１０とする。入札から落札（約定）までの時間は、たとえば約１時間である。

図５に示すタイミングｔ_Ｂ（以下、「ｔ_Ｂ」と表記する）は、需給計画値提出期限（たとえば、後述のＧＣ）に相当する。期間Ｔ２０はｔ_Ｂ直前の期間に相当する。期間Ｔ２０は、たとえばｔ_Ｂの３時間前からｔ_Ｂまでの期間の少なくとも一部に設定される。この実施の形態では、ｔ_Ｂの１時間３０分前からｔ_Ｂの３０分前までの期間を、期間Ｔ２０とする。

図５に示すタイミングｔ_Ｃ（以下、「ｔ_Ｃ」と表記する）からタイミングｔ_Ｄ（以下、「ｔ_Ｄ」と表記する）までの期間は、調整期間（調整力の提供が要求される期間）に相当する。期間Ｔ３０は、たとえば調整期間（ｔ_Ｃ～ｔ_Ｄ）の前後の少なくとも一方に余裕期間（３０分以内の期間）を加えた期間内に設定される。この実施の形態では、ｔ_Ｃの３０分前からｔ_Ｄまでの期間を、期間Ｔ３０とする。この実施の形態では、上記入札によって落札された調整力の調整期間の前に３０分の余裕期間を加えた期間が、期間Ｔ３０となる。

この実施の形態では、期間Ｔ１０、Ｔ２０、及びＴ３０の各々において、サーバ３００と対象車両との平均通信頻度（以下、単に「平均通信頻度」と記載する）が上昇する。期間Ｔ１０、Ｔ２０、及びＴ３０の各々の平均通信頻度は約２回／時であり、他の期間（期間Ｔ１０、Ｔ２０、及びＴ３０のいずれでもない期間）の平均通信頻度が約１回／時である。第１中間期間（期間Ｔ１０終了から期間Ｔ２０開始までの期間）と第２中間期間（期間Ｔ２０終了から期間Ｔ３０開始までの期間）との各々の平均通信頻度も約１回／時である。この実施の形態では、約１回／時が通常の平均通信頻度に相当する。サーバ３００は、期間Ｔ１０、Ｔ２０、及びＴ３０の各々における平均通信頻度を、通常の平均通信頻度の２倍にする。

再び図３を参照して、この実施の形態では、サーバ６００が、以下に説明する車両管理部６１１、選定部６１２、需給管理部６１３、取引部６１４、及び調整力算出部６１５を含む。これら各部は、たとえば、プロセッサ６１０と、プロセッサ６１０により実行されるプログラムとによって具現化される。ただしこれに限られず、上記各部は、専用のハードウェア（電子回路）によって具現化されてもよい。

車両管理部６１１は、必要に応じて、サーバ３００が管理するデータを取得するように構成される。また、車両管理部６１１は、サーバ３００から取得したデータに基づいて、車両の今後の行動を予測するように構成される。また、車両管理部６１１は、所定のタイミングで、サーバ３００に対して通信頻度アップフラグの値の変更を要求するように構成される（たとえば、後述する図７～図９参照）。

車両管理部６１１は、選定部６１２によって選定された車両を、リモート制御により電力系統ＰＧの調整力として動作させるように構成される。ただし、選定された車両がサーバ７００によって制御される場合には、車両管理部６１１は、選定部６１２によって選定された車両をサーバ７００に通知する。車両管理部６１１は、サーバ７００からの指令に従って車両を制御してもよい。

需給管理部６１３は、サーバ７００から電力系統ＰＧの需給情報を取得するように構成される。また、需給管理部６１３は、電力系統ＰＧの実需給を監視する。電力系統ＰＧの実需給は、ＤＥＲごとに設けられた電力量計で測定されてもよいし、託送計量器で測定されてもよい。ＤＥＲごとの電力量計は、スマートメータを含んでもよいし、ＥＶＳＥに内蔵された電力量計を含んでもよい。需給管理部６１３は、電力系統ＰＧの同時同量に関してインバランスが生じると、インバランスを解消するための調整力要求を発生させる。

取引部６１４は、電力市場で取引きを行なうように構成される。取引部６１４は、電力市場で入札を実行し、入札結果を需給管理部６１３に連絡する。取引部６１４が電力市場で調整力を落札した場合には、取引部６１４が調整力要求を発生させる。

調整力算出部６１５は、上記調整力要求に対する目標調整力を算出するように構成される。この実施の形態では、調整力算出部６１５が、調整力要求の調整期間において要求される調整力（ｋＷ）に所定の余裕分（ｋＷ）を足した値を、目標調整力として決定する。

選定部６１２は、上記調整力要求に対して、車群ＶＧからの車両選定を実行するように構成される。車両選定は、車群ＶＧに含まれる複数の車両の中から、調整力として動作させる車両を選ぶ処理である。選定部６１２は、選定した車両を、車両管理部６１１に連絡する。

図６は、この実施の形態に係る電力市場の概要を示す図である。以下、図６を用いて、この実施の形態に係る電力市場について説明する。ただし、以下に説明する電力市場は一例にすぎない。

電力系統ＰＧを使用するＢＧ（バランシンググループ）は、同時同量を達成する責任を負う。ＢＧは、ＢＲＰ（Balance Responsible Party）に相当する。ＢＧの例としては、小売電気事業者、発電事業者、アグリゲータが挙げられる。この実施の形態では、計画値同時同量制度が採用される。ＢＧは、事前に所定の機関にコマごとの計画値を提出する。コマは、単位時間ごとに１日が分割されたフレームである。この実施の形態では、コマの長さ（単位時間）を３０分とする。所定の機関は、電力広域的運営推進機関（ＯＣＣＴＯ）であってもよい。同時同量のインバランス（計画値との不一致分）は、コマごとに評価される。インバランスを発生させたＢＧは、インバランス料金（ペナルティ）を支払う義務を負う。また、インバランスを頻発させるＢＧは、ライセンスを剥奪され得る。

この実施の形態に係る電力市場は、スポット市場（前日市場）と時間前市場（当日市場）と需給調整市場と容量市場とを含む。スポット市場及び時間前市場は、ＪＥＰＸ（日本卸電力取引所）のような卸電力取引所によって開設及び運営される。各市場では、電力を商品とした取引きが行なわれる。各商品は、たとえば入札方式によって売買される。各市場では、コマ単位の商品が取引きされる。卸電力取引所では、１日を３０分単位に区切った４８コマについて取引きが行なわれる。図６中の「ＧＣ」（ゲートクローズ）は、コマごとの市場閉場時刻を示している。また、ＧＣは、計画値同時同量制度における計画値の変更期限（需給計画値提出期限）に相当する。この実施の形態では、コマ開始時刻の１時間前がＧＣである。ＧＣ前においては、ＢＧが市場を利用して、当該コマ（ＧＣに対応するコマ）における計画値と実需給とのずれを調整できる。ＢＧは、インバランスを解消するための調整力をＤＲ（デマンドレスポンス）によって調達してもよい。

需給調整市場は、電力系統ＰＧの運用者（以下、「ＴＳＯ（Transmission System Operator）」と表記する）が調整力を調達するための市場である。ＴＳＯは、一般送配電事業者であってもよい。調整力は、電力系統ＰＧにフレキシビリティ（電力変動に応じて電力の生産又は消費を変更できる能力）を付与する。ＧＣ後においては、ＴＳＯが、需給調整市場を通じて調達した調整力を利用して需要及び供給を調整する。ＴＳＯは、市場で調達した調整力（リソース）を、ＧＦ（Governor Free）、ＬＦＣ（Load Frequency Control）、又はＥＤＣ（Economic load Dispatch Control）によって制御する。これにより、電力系統ＰＧの同時同量が達成される。

需給調整市場で取引きされる調整力は、平常時の調整力と事故時の調整力とに大別される。そして、平常時の調整力は、予測誤差のための調整力と、時間内変動のための調整力とに、さらに分類される。予測誤差は、需要予測誤差と、再エネ予測誤差とを含む。予測誤差は、コマごとの計画値と実績値との平均誤差（３０分平均誤差）である。時間内変動は、コマ内（３０分未満）の変動である。

ＢＧは、需要を予測して、ＧＣ前に需要計画を提出する。しかし、ＧＣ後に予測誤差（電力需要の予測値と実績値との差）が生じ得る。需要予測誤差のための調整力は、ＧＣ後に生じる予測誤差を解消するための調整力である。また、再エネ予測誤差のための調整力は、ＧＣ時点で想定される再エネ予測誤差（再エネ出力の予測値と実績値との差）を解消するための調整力である。ＴＳＯは、主にＬＦＣ及びＥＤＣを用いて、予測誤差のための調整力を制御する。

電力需要及び再エネ出力の各々は、時々刻々と変化する。仮に予測値と実績値とが３０分平均値で一致していたとしても、３０分よりも短い時間では細かな変動が生じている。時間内変動のための調整力は、時間内変動（３０分未満の変動）に対して需要と供給を一致させるように応動する調整力である。時間内変動のための調整力の制御に関して、ＴＳＯは、１分未満の変動にはＧＦで対応し、１分以上の変動にはＬＦＣ又はＥＤＣで対応する。

事故時の調整力は、予測不能なトラブル（たとえば、電源脱落）で生じた需要と供給との差を解消するための調整力である。ＴＳＯは、電源脱落に備えて、バックアップ電源を市場で調達する。バックアップ電源（事故時の調整力）の制御に関して、ＴＳＯは、脱落直後はＧＦで対応し、その後はＬＦＣ、ＥＤＣに順次切り替える。

需要変動は、極短周期成分（サイクリック分）と、短周期成分（フリンジ分）と、長周期成分（サステンド分）とに細分化できる。

需給調整市場では、サイクリック分のための調整力（一次調整力）と、フリンジ分のための調整力（二次調整力－１）とが取引きされる。一次調整力は、「ＦＣＲ」（Frequency Containment Reserve：周波数制御予備力）に相当する。ＦＣＲに関して、応動時間は１０秒以内、継続時間は５分である。二次調整力－１は、「Ｓ－ＦＲＲ」（Synchronized Frequency Restoration Reserve：同期周波数回復予備力）に相当する。Ｓ－ＦＲＲに関して、応動時間は５分以内、継続時間は３０分（１コマ）である。

需給調整市場では、サステンド分のうち直前のコマとの差分に相当する部分のための調整力（二次調整力－２）と、サステンド分のうち直前のコマから継続する部分のための調整力（三次調整力－１）とが、さらに取引きされる。二次調整力－２は、「ＦＲＲ」（Frequency Restoration Reserve：周波数回復予備力）に相当する。ＦＲＲに関して、応動時間は５分以内、継続時間は３０分（１コマ）である。三次調整力－１は、「ＲＲ」（Replacement Reserve：代替予備力）に相当する。ＲＲに関して、応動時間は１５分以内、継続時間は３時間（６コマ）である。

さらに、需給調整市場では、ＦＩＴ（Feed-in Tariff）特例制度のための調整力（三次調整力－２）も取引きされる。ＦＩＴ特例制度では、ＴＳＯが発電計画に対するインバランスの責任を負う。ＴＳＯは、コマの前々日に再エネ出力を予測して発電計画値を決定する。そして、ＴＳＯは、コマの前日に、再エネ予測誤差（前々日からの予測誤差）を解消するための三次調整力－２を調達する。三次調整力－２は、「ＲＲ－ＦＩＴ」（Replacement Reserve for Feed-in Tariff）に相当する。ＲＲ－ＦＩＴに関して、応動時間は４５分以内、継続時間は３時間（６コマ）である。

容量市場では、電源Ｉ’が取引きされる。電源Ｉ’は、主に１０年に１回程度の厳気象（猛暑、厳寒など）に対応するための調整力（予備力）である。電源Ｉ’は、ＴＳＯの専用電源として、所定の期間において常時確保される。電源Ｉ’に関して、応動時間は３時間以内、継続時間は２～４時間（４～８コマ）である。

需給調整市場で調整力を落札した者（落札者）は、基準値（ｋＷ）に対して落札量（ΔｋＷ約定量）の範囲で電力を調整する。落札者は、ＧＣ（落札されたコマの開始時刻１時間前）までに基準値を需給調整市場システムに登録する。需給調整市場において、基準値は需給計画値に相当し、ＧＣは需給計画値提出期限に相当する。落札量は、プラス（上げ調整力）であってもよいし、マイナス（下げ調整力）であってもよい。落札者は、落札した１つ以上のコマ（提供期間）において、ＴＳＯからの指令に従い電力調整を行なう。提供期間において出力指令値が変更された場合、落札者は、商品要件の応動時間内に出力をその値に変化させる。提供期間において出力指令値が同じ値で継続する場合、落札者は、少なくとも商品要件の継続時間はその指令に従って出力を継続する。

落札者は、電力調整に使用するリソース（たとえば、リストパターン）をＴＳＯに通知する。ＴＳＯのサーバ７００は、たとえば中央給電指令所のシステム（中給システム）又は簡易指令システムによって、落札者のリソースに対する指令を送信する。リソースは、専用線オンラインで中給システムと接続されてもよい。たとえば、サーバ７００が上記指令によって車群ＶＧを制御する場合には、サーバ７００は、サーバ６００（アグリゲータ）を介して車両を制御してもよいし、直接的に車両を制御してもよい。落札者は、落札した全てのコマの終了後に、当該コマにおけるリソースの実績データをＴＳＯへ送信する。ＴＳＯは、提供期間（落札された調整力の調整期間）において、ΔｋＷ約定量の供出が可能な状態を落札者が維持していること（ΔｋＷの供出可否）と、ΔｋＷ約定量の範囲内で指令に従って落札者が調整していること（応動実績）とを、コマ（３０分）ごとに確認する。ΔｋＷの供出可否の評価（アセスメントＩ）と応動実績の評価（アセスメントＩＩ）との少なくとも一方において、取引対象のΔｋＷに定める要件の不適合が判明した場合には、落札者に所定のペナルティ料金が科される。

アグリゲータは、サーバ６００を用いて電子商取引を行なう。サーバ６００は、電力市場で調整力の取引きを行なう。市場取引の会計はサーバ６００で管理される。サーバ６００は、電力市場で調整力を落札した場合には、落札された調整力に対応する調整力要求を発生させる。そして、サーバ６００は、その調整力要求に対して、車群ＶＧの中から、調整力として動作させる車両（リソース）を選ぶ。以下では、サーバ６００が需給調整市場で入札を行なう例について説明する。

図７は、サーバ６００によって実行される市場取引に係る処理を示すフローチャートである。このフローチャートに示される処理は、所定の条件が成立すると、実行される。所定の条件は、所定の時刻に成立してもよいし、定期的に成立してもよい。サーバ６００がユーザから入札指示を受けたときに、所定の条件が成立してもよい。サーバ６００は、市場価格と、気象情報（気象予測情報を含む）と、車群ＶＧの需要履歴との少なくとも１つに基づいて、入札に適したタイミングを決定し、入札に適したタイミングに図７に示す処理を実行してもよい。

図１～図３とともに図７を参照して、Ｓ２１では、車両管理部６１１が、サーバ３００と対象車両との通信頻度を上昇させる。具体的には、車両管理部６１１は、サーバ３００に対して通信頻度アップフラグをＯＮにすることを要求する。サーバ３００は、サーバ６００からの要求に応じて通信頻度アップフラグをＯＮにする。これにより、サーバ３００と対象車両との通信頻度が通常の通信頻度よりも高くなる（図４参照）。

Ｓ２２では、車両管理部６１１が、サーバ３００から車両情報を取得し、取得した車両情報を用いて、車群ＶＧに含まれる各車両の今後の行動を予測する。続くＳ２３では、期間Ｔ１０（入札のための行動予測期間に相当）が経過したか否かを、車両管理部６１１が判断する。この実施の形態では、Ｓ２１の処理が実行されてから１時間が経過するまでの期間が、期間Ｔ１０に相当する。Ｓ２１の処理が実行されてから１時間が経過するまでは（Ｓ２３にてＮＯ）、Ｓ２２及びＳ２３の処理が繰り返し実行される。

たとえば、初回処理ルーチンでは、車両管理部６１１が、Ｓ２２において、現時点から所定時間前までのデータ（たとえば、サーバ３００に蓄積された直近３時間程度のデータ）を、サーバ３００から取得する。そして、車両管理部６１１は、車両の位置及びＳＯＣの推移と、車両ユーザの位置の推移と、車両の走行計画と、車両システムの状態と、系統接続状態とを用いて、その車両の今後の行動を予測する。車両管理部６１１は、車群ＶＧに含まれる各車両の今後の行動に基づいて、所定の期間（たとえば、各商品に対応するコマ）においてプラグイン状態になっている車両を推定する。また、車両管理部６１１は、その車両がプラグイン状態になったときのＳＯＣも推定する。

２回目以降の処理ルーチンでは、車両管理部６１１は、Ｓ２２において、サーバ３００から最新のデータ（図４のＳ１６参照）を受信したか否かを確認する。そして、サーバ３００から最新のデータを受信した場合には、車両管理部６１１は、その最新のデータを用いて、車群ＶＧに含まれる各車両の今後の行動を予測する。すなわち、サーバ３００は、最新のデータに基づいて前回の予測を修正する。行動予測に最新のデータを用いることで、行動予測の精度が向上する。

Ｓ２１の処理が実行されてから１時間が経過すると（Ｓ２３にてＹＥＳ）、処理はＳ２４に進む。Ｓ２４では、車両管理部６１１が、サーバ３００と対象車両との通信頻度を下げる。具体的には、車両管理部６１１は、サーバ３００に対して通信頻度アップフラグをＯＦＦにすることを要求する。サーバ３００は、サーバ６００からの要求に応じて通信頻度アップフラグをＯＦＦにする。これにより、サーバ３００と対象車両との通信頻度が通常の通信頻度に戻る（図４参照）。

続くＳ２５では、取引部６１４が、上述した行動予測（Ｓ２２）の結果を用いて、取引対象（入札する商品）を選択する。そして、調整力算出部６１５が、その取引対象に対する目標調整力を算出する。また、その取引対象が要求する調整力として動作させる車両を、選定部６１２が選択する。選定部６１２は、上述した行動予測（Ｓ２２）の結果を用いて、取引対象が要求する調整力を調整期間において提供するための１台以上の車両を、車群ＶＧから選択する。選定部６１２は、調整期間の少なくとも一部においてプラグイン状態になっている車両を選択する。選定部６１２は、調整期間において目標調整力が確保されるように車両を選択する。選定部６１２は、上述した行動予測（Ｓ２２）の結果を用いて、車群ＶＧに含まれる各車両が提供可能な調整力を予測する。選定部６１２は、車両がプラグイン状態になったときのＳＯＣを用いて、調整期間において車両が調整力の提供を継続可能な時間（充電可能時間又は放電可能時間）を推定してもよい。取引対象の調整期間の全部を１つの車両で対応できない場合には、その調整期間が分割されて複数の車両に割り当てられる。

続くＳ２６では、取引部６１４が、上記Ｓ２５で選択された取引対象に対して入札を行なう。その後、取引部６１４は、Ｓ２７において、入札した商品（調整力）が落札されたか否かを判断する。落札されなかった場合には（Ｓ２７にてＮＯ）、図７に示す一連の処理が終了する。他方、落札された場合には（Ｓ２７にてＹＥＳ）、処理がＳ２８に進む。

Ｓ２８では、落札された商品を特定する情報（たとえば、商品ＩＤ）とともに、その商品に対して選定部６１２が選定した車両（リストパターン）を、車両管理部６１１がサーバ７００に通知する。車両管理部６１１は、選定された車両の通信アドレス、最大充電電力、充電可能時間、最大放電電力、及び放電可能時間の少なくとも１つを、サーバ７００に通知してもよい。

さらに、車両管理部６１１は、Ｓ２８において、選定部６１２が選定した車両のユーザ端末に、当該車両に割り当てられた期間（調整開始時刻及び調整終了時刻）を通知する。このように、車両管理装置１０００は、電力市場で調整力の入札を行ない（Ｓ２６）、対象車両の中から選ばれた１台以上の車両を、電力市場で約定した調整力として動作させるための通知（Ｓ２８）を行なうように構成される。ユーザ端末は、車両に搭載された端末であってもよいし、車両ユーザによって携帯されるモバイル端末であってもよい。Ｓ２８の処理が実行されると、続くＳ２９においてサーバ６００が計画値提出処理（図８に示す一連の処理）を開始した後、図７に示す一連の処理は終了する。

図８は、電力市場においてアグリゲータが約定したときに、図７のＳ２９においてサーバ６００が開始する計画値提出処理を示すフローチャートである。

図１～図３とともに図８を参照して、Ｓ３１では、期間Ｔ２０（計画値取得のための行動予測期間に相当）内か否かを、車両管理部６１１が判断する。この実施の形態では、約定した商品のＧＣ（需給計画値提出期限）を基準にして期間Ｔ２０が定まる。具体的には、ＧＣの１時間３０分前からＧＣの３０分前までの期間が、期間Ｔ２０に相当する。期間Ｔ２０に入るまでは（Ｓ３１にてＮＯ）、Ｓ３１の判断が繰り返し実行される。期間Ｔ２０に入ると（Ｓ３１にてＹＥＳ）、処理がＳ３２に進む。

Ｓ３２では、車両管理部６１１が、たとえば図７のＳ２１と同様に、サーバ３００と対象車両との通信頻度を上昇させる。続くＳ３３では、車両管理部６１１が、サーバ３００から車両情報を取得し、取得した車両情報を用いて、車群ＶＧに含まれる各車両の今後の行動を予測する。続くＳ３４では、期間Ｔ２０が経過したか否かを、車両管理部６１１が判断する。期間Ｔ２０が経過するまでは（Ｓ３４にてＮＯ）、Ｓ３３及びＳ３４の処理が繰り返し実行される。Ｓ３３における行動予測は、たとえば図７のＳ２２に準ずる態様で行なわれる。

期間Ｔ２０が経過すると（Ｓ３４にてＹＥＳ）、処理がＳ３５に進む。期間Ｔ２０が経過したことは、ＧＣの３０分前になったことを意味する。Ｓ３５では、車両管理部６１１が、たとえば図７のＳ２４と同様に、サーバ３００と対象車両との通信頻度を下げる。

続くＳ３６では、需給管理部６１３が、上述した行動予測（Ｓ３３）の結果を用いて、約定した商品に対する需給計画値（前述した基準値）を決定する。その後、需給管理部６１３は、Ｓ３７において、決定した需給計画値を所定の機関（たとえば、需給調整市場システム）へ送信する。このように、車両管理装置１０００は、通信により対象車両から取得した情報を用いて需給計画値を決定して（Ｓ３６）、決定された需給計画値を需給計画値提出期限までに送信する（Ｓ３７）ように構成される。Ｓ３７の処理が実行されると、続くＳ３８においてサーバ６００が代替車両選定処理（図９に示す一連の処理）を開始した後、図８に示す一連の処理は終了する。

図９は、図８のＳ３８においてサーバ６００が開始する代替車両選定処理を示すフローチャートである。

図１～図３とともに図９を参照して、Ｓ４１では、期間Ｔ３０（代替車両選定のための行動予測期間に相当）内か否かを、車両管理部６１１が判断する。この実施の形態では、約定した商品の調整期間を基準にして期間Ｔ３０が定まる。具体的には、調整期間の前に３０分（余裕期間）を加えた期間が、期間Ｔ３０に相当する。期間Ｔ３０に入るまでは（Ｓ４１にてＮＯ）、Ｓ４１の判断が繰り返し実行される。期間Ｔ３０に入ると（Ｓ４１にてＹＥＳ）、処理がＳ４２に進む。

Ｓ４２では、車両管理部６１１が、たとえば図７のＳ２１と同様に、サーバ３００と対象車両との通信頻度を上昇させる。続くＳ４３では、車両管理部６１１が、サーバ３００から車両情報を取得し、取得した車両情報を用いて、車群ＶＧに含まれる各車両の今後の行動を予測する。続くＳ４４では、期間Ｔ３０が経過したか否かを、車両管理部６１１が判断する。そして、期間Ｔ３０内においては（Ｓ４４にてＮＯ）、処理がＳ４５に進む。

Ｓ４５では、約定した商品について電力調整から離脱した車両が存在するか否かを、車両管理部６１１が判断する。具体的には、車両管理部６１１は、Ｓ４３でサーバ３００から取得した車両情報を用いて、約定した商品に対して選定された車両ごとに、調整期間において予定どおりに調整力として動作できるか否かを判断する。そして、調整期間において予定どおりに調整力として動作できない（又は、すでに調整期間において調整力として動作していない）と判断される車両が存在する場合には、車両管理部６１１は、その車両を、電力調整から離脱した車両として認定する。他方、約定した商品に対して選定された全ての車両が調整期間において予定どおりに調整力として動作できる（又は、全ての車両が現に調整期間において調整力として動作している）と判断される場合には、車両管理部６１１は、電力調整から離脱した車両は存在しないと判断し（Ｓ４５にてＮＯ）、処理をＳ４３に戻す。

選定された車両のいずれかが電力調整から離脱した場合には（Ｓ４５にてＹＥＳ）、選定部６１２が、Ｓ４６において代替車両（すなわち、離脱した車両の代わりの車両）を選定する。選定部６１２は、上記行動予測（Ｓ４３）の結果を用いて、離脱した車両の代わりに調整力として動作可能な車両を選定する。そして、車両管理部６１１が、続くＳ４７において、選定された車両をサーバ７００に通知する。車両管理部６１１は、選定された車両の通信アドレス及び充放電に関するスペックを、サーバ７００へ送信してもよい。また、車両管理部６１１は、選定された車両のユーザ端末に、当該車両に割り当てられた期間を通知する。このように、車両管理装置１０００は、期間Ｔ３０において、対象車両の中から選ばれた１台以上の車両の全てが電力系統ＰＧの調整力として動作するか否かを判断し、対象車両の中から選ばれた１台以上の車両のいずれかが電力系統ＰＧの調整力として動作しないと判断される場合には、通信により対象車両から取得した情報を用いて、対象車両の中から代わりの車両を選ぶように構成される。Ｓ４７の処理後、処理はＳ４３に戻る。

期間Ｔ３０が経過するまでは（Ｓ４４にてＮＯ）、Ｓ４３において行動予測が行なわれる。Ｓ４３における行動予測は、たとえば図７のＳ２２に準ずる態様で行なわれる。そして、期間Ｔ３０が経過すると（Ｓ４４にてＹＥＳ）、処理がＳ４８に進む。期間Ｔ３０が経過したことは、約定した商品の調整期間が終了したことを意味する。Ｓ４８では、車両管理部６１１が、たとえば図７のＳ２４と同様に、サーバ３００と対象車両との通信頻度を下げる。Ｓ４８の処理が実行されると、図９に示す一連の処理は終了する。

サーバ７００（ＴＳＯサーバ）は、需給調整市場で確保した調整力（落札された商品）を利用して、電力系統ＰＧの電力調整を行なう。具体的には、サーバ７００は、サーバ６００からの通知（図７のＳ２８）に基づいて、その商品に対して選定された車両（リソース）を制御する。図１０は、サーバ７００によって実行される電力調整に係る処理を示すフローチャートである。このフローチャートに示される処理は、落札された商品の調整開始時刻（図５に示したｔ_Ｃに相当）が到来すると、開始される。

図１～図３とともに図１０を参照して、Ｓ１０１では、サーバ７００が、電力系統ＰＧの需給状況に基づいて、ΔｋＷ約定量の範囲内での電力調整を制御対象に要求する指令を生成し、生成された指令を制御対象へ送信する。具体的には、サーバ７００は、電力系統ＰＧの需給状況に応じた充電電力又は放電電力を示す指令を制御対象へ送信する。調整力が不要な状況においては、上記指令が、電力０ｋＷを示す充電停止指令又は放電停止指令になることもある。この指令によって制御される制御対象は、サーバ６００から通知された１つ以上の車両（図７のＳ２８）である。制御対象は途中で変わるかもしれない。たとえば、落札された商品の調整期間が複数の車両に分けて割り当てられた場合には調整期間の途中（詳しくは、先の車両に割り当てられた期間の終了タイミング）で制御対象が交替することになる。先の車両に代わって後の車両が充電又は放電を行なうことで、充電又は放電は継続される。また、予定していた車両（制御対象）が離脱した場合には、図９のＳ４７の処理によって通知された車両（代替車両）が、離脱した車両の代わりに制御対象となる。

サーバ７００は、リモート制御により制御対象を調整力（落札された商品）として動作させる。サーバ７００は、上記指令に基づいて、制御対象の電力変換回路（たとえば、図２に示した充放電器１２０）を制御する。制御対象の充電電力又は放電電力は、需給状況に応じた目標値に追従するように連続的に制御されてもよい。あるいは、上記指令に従うデューティ制御によって制御対象の充電電力又は放電電力が調整されてもよい。制御対象となる車両は、割り当てられた期間において充放電リレーを閉状態（接続状態）に維持する。そして、割り当てられた期間が終了すると、その充放電リレーが開状態（遮断状態）にされる。

続くＳ１０２では、落札された商品の調整期間が終了したか否かを、サーバ７００が判断する。調整期間内においては、Ｓ１０２においてＮＯと判断され、処理がＳ１０１に戻る。そして、Ｓ１０１の処理により、アグリゲータが提供する調整力（選定された１つ以上の車両）によって電力系統ＰＧの電力調整が行なわれる。その後、落札された商品の調整終了時刻が到来すると（Ｓ１０２にてＹＥＳ）、図１０に示す一連の処理は終了する。

上記の例では、サーバ７００が直接的に各車両を制御する。しかし、こうした例に限られず、サーバ７００はサーバ６００を介して車両を制御してもよい。サーバ７００がサーバ６００に指令を送信し、サーバ６００が、サーバ７００からの指令に従って車両をリモート制御してもよい。

アグリゲータは、サーバ６００を用いて、電力系統ＰＧの同時同量に関するインバランスを解消するための調整力を確保する。たとえば、需給管理部６１３が、同時同量の調整期間において、電力系統ＰＧの同時同量に関するインバランス（計画値と実需給との差分）が所定の許容範囲以内であるか否かを逐次判断する。そして、インバランスが許容範囲を超えた場合には、需給管理部６１３が、インバランスを解消するための調整力要求を発生させる。そして、選定部６１２が、その調整力要求に対して、車群ＶＧから１台以上の車両を選ぶ。そして、車両管理部６１１が、選ばれた車両を調整力として動作させる。同時同量の調整期間は３０分（１コマ）である。車両管理部６１１は、たとえば図１０に示した処理に準ずる態様で制御対象（選定部６１２によって選ばれた車両）をリモート制御する。車両管理部６１１は、電力系統ＰＧの実需給に基づいて、インバランスを解消するための指令（充電指令又は放電指令）を生成し、生成された指令を制御対象へ送信する。調整期間における電力系統ＰＧの実需給は、需給管理部６１３によって監視される。

同時同量の需給計画値提出期限、調整期間に対しても、それぞれ期間Ｔ２０、Ｔ３０が設定され、計画値提出処理（図８）、代替車両選定処理（図９）が実行される。インバランス解消のための電力調整に関しては、入札（図７）が行なわれないため、サーバ６００は、所定のタイミング（たとえば、前回の調整期間が終了したタイミング）で図８に示す一連の処理を開始する。市場で落札（約定）した商品に対する計画値提出処理（図８）及び代替車両選定処理（図９）と、同時同量に対する計画値提出処理（図８）及び代替車両選定処理（図９）とは、別々に実行される。落札した商品の期間Ｔ２０，Ｔ３０と、同時同量の期間Ｔ２０，Ｔ３０とは異なってもよい。

以上説明したように、この実施の形態に係る車両管理方法は、図４及び図７～図１０に示した処理を含む。

図４に示した処理では、サーバ３００が、所定の通信期間（この実施の形態では、常時）において車群ＶＧに含まれる各車両（１台以上の対象車両）と周期的に通信を行なう。

図７のＳ２３、図８のＳ３１，Ｓ３４、及び図９のＳ４１，Ｓ４４の各々では、通信頻度アップ期間（期間Ｔ１０、Ｔ２０、及びＴ３０）内か否かを、サーバ６００が判断する。そして、サーバ３００は、通信頻度アップ期間（通信頻度アップフラグ＝ＯＮ）において、期間Ｔ１０、Ｔ２０、及びＴ３０を除いた上記通信期間の平均通信頻度よりも高い頻度で、車群ＶＧに含まれる各車両と通信を行なう（図４参照）。

サーバ６００は、期間Ｔ１０において、車群ＶＧに含まれる各車両から上記通信（図４）により取得した情報を用いて、車群ＶＧに含まれる各車両が提供可能な調整力を予測する（図７のＳ２２及びＳ２５）。サーバ６００は、期間Ｔ２０において、車群ＶＧに含まれる各車両から上記通信（図４）により取得した情報を用いて需給計画値を求める（図８のＳ３３及びＳ３６）。

図１０に示した処理では、サーバ７００が、期間Ｔ３０において、車群ＶＧから選ばれた１台以上の車両を電力系統ＰＧ（外部電源）の調整力として動作させる。サーバ６００は、期間Ｔ３０において、車群ＶＧから選ばれた１台以上の車両のいずれかが電力系統ＰＧ（外部電源）の調整力として動作していない場合に（図９のＳ４５にてＹＥＳ）、車群ＶＧに含まれる各車両から上記通信（図４）により取得した情報を用いて、車群ＶＧから代わりの車両を選ぶ（図９のＳ４６）。

上記実施の形態に係る車両管理方法によれば、外部電源の調整力として動作させる車両を適切に管理することが可能になる。そして、管理される車両によって外部電源の電力調整を適切に行ないやすくなる。

上記実施の形態では、期間Ｔ１０と期間Ｔ２０と期間Ｔ３０とで同じ通信周期（時間Ｔ２＝３０分）を採用している。しかしこれに限られず、期間Ｔ１０と期間Ｔ２０と期間Ｔ３０とで通信周期を変えてもよい。たとえば、期間Ｔ３０の通信頻度を、期間Ｔ１０及びＴ２０の各々の通信頻度よりも高くしてもよい。

図１１は、図５に示した通信態様の第１変形例を示す図である。図１１を参照して、この変形例では、期間Ｔ１０の通信周期を時間Ｔ２１、期間Ｔ２０の通信周期を時間Ｔ２２、期間Ｔ３０の通信周期を時間Ｔ２３、他の期間の通信周期を時間Ｔ１としている。時間Ｔ２１は時間Ｔ１よりも短い。時間Ｔ２２は時間Ｔ２１よりも短い。時間Ｔ２３は時間Ｔ２２よりも短い。期間Ｔ１０、Ｔ２０、Ｔ３０においては、サーバ３００が、図４のＳ１３において、時間Ｔ２に代えて時間Ｔ２１、Ｔ２２、Ｔ２３をそれぞれ採用する。期間Ｔ１０、Ｔ２０、Ｔ３０をサーバ３００が判別できるように、サーバ６００は、図７のＳ２１、図８のＳ３２、図９のＳ４２において、それぞれ「ＯＮ」に代えて「１」、「２」、「３」を通信頻度アップフラグの値としてサーバ３００へ送信してもよい。

第１期間、第２期間、第３期間は、それぞれ上述した期間Ｔ１０、Ｔ２０、Ｔ３０に限られず、適宜変更可能である。図１２は、図５に示した通信態様の第２変形例を示す図である。図１２を参照して、この変形例では、第１期間、第２期間、第３期間として、それぞれ期間Ｔ１０Ａ、Ｔ２０Ａ、Ｔ３０Ａが採用される。期間Ｔ２０Ａは、ｔ_Ｂの１時間３０分前からｔ_Ｂまでの期間である。サーバ６００は、期間Ｔ２０Ａが経過したか否かを、上記実施の形態と同様、たとえば図８のＳ３１，Ｓ３４において判断してもよい。期間Ｔ３０Ａは、調整期間（ｔ_Ｃ～ｔ_Ｄ）である。サーバ６００は、期間Ｔ３０Ａが経過したか否かを、上記実施の形態と同様、たとえば図９のＳ４１，Ｓ４４において判断してもよい。

期間Ｔ１０Ａは、約定３時間前から約定タイミングまでの期間の少なくとも一部に設定される。すなわち、約定したタイミングで期間Ｔ１０Ａは経過したと判断される。ただし、サーバ６００が期間Ｔ１０Ａにおいて入札を行ない、期間Ｔ１０Ａを開始してから約定することなく３時間が経過した場合にも、期間Ｔ１０Ａは経過したとみなされる。図１２に示す第２変形例において、サーバ６００は、図７に示した処理に代えて図１３に示す処理を実行してもよい。

図１３は、図７に示した処理の変形例を示すフローチャートである。このフローチャートに示される処理は、サーバ６００がユーザから入札指示を受けたときに開始されてもよい。図１３に示す処理は、Ｓ２３，Ｓ２４（図７）に代えてＳ２０，Ｓ２４Ａが採用されたこと以外は、図７に示した処理と同じである。以下、主にＳ２０及びＳ２４Ａについて説明する。

図１～図３とともに図１３を参照して、Ｓ２１、Ｓ２２、Ｓ２５、Ｓ２６、Ｓ２７の順に処理が実行される。Ｓ２６で入札した商品（取引対象）が落札（約定）されなかった場合には（Ｓ２７にてＮＯ）、処理がＳ２０に進む。Ｓ２０では、サーバ６００が入札を中止するか否かを判断する。具体的には、Ｓ２１の処理が実行されてから３時間が経過した場合には、入札を中止する（Ｓ２０にてＹＥＳ）と判断する。Ｓ２１の処理が実行されてから３時間が経過していない場合には、入札を中止しない（Ｓ２０にてＮＯ）と判断される。Ｓ２０においてＮＯと判断されると、処理がＳ２２に戻り、Ｓ２６において入札が行なわれる。取引部６１４は、予め設定された条件で、商品の選択及び入札を行なってもよい。また、取引部６１４は、ＡＩ（人工知能）を用いた機械学習により得た学習済みモデルを用いて、商品の選択及び入札を行なってもよい。

Ｓ２６で入札した商品（取引対象）が落札（約定）されると（Ｓ２７にてＹＥＳ）、Ｓ２８、Ｓ２９、Ｓ２４Ａの順に処理が実行された後、図１３に示す一連の処理は終了する。また、Ｓ２０においてＹＥＳと判断された場合には、Ｓ２４Ａの処理が実行された後、図１３に示す一連の処理は終了する。Ｓ２４Ａでは、サーバ６００が、たとえば図７のＳ２４と同様に、サーバ３００と対象車両との通信頻度を下げる。

サーバ６００は、上記図１３に示した処理により、図１２に示した期間Ｔ１０Ａが経過したか否かを判断してもよい。上記図１３に示した処理では、期間Ｔ１０Ａを開始してから約定することなく３時間が経過した場合にも（Ｓ２０にてＹＥＳ）、期間Ｔ１０Ａは経過したとみなされ、Ｓ２４Ａにおいてサーバ３００と対象車両との通信頻度が通常の通信頻度に戻される。

上記実施の形態では、車群ＶＧに含まれる各車両を、対象車両としている。しかしこれに限られず、車両管理装置１０００が管理する車群ＶＧは、電力系統ＰＧの調整力として動作する対象車両と、電力系統ＰＧの調整力として動作しない非対象車両との両方を含んでもよい。車群ＶＧのうち、アグリゲータとの間で電力調整の契約（たとえば、ＶＰＰ契約）を締結したユーザに帰属する車両が、対象車両であり、電力調整の契約を締結していないユーザに帰属する車両が、非対象車両であってもよい。あるいは、車群ＶＧのうち、電力調整に使用するリソースとして予めＴＳＯサーバに登録された需要家リストパターンに含まれる車両が、対象車両であり、需要家リストパターンに含まれない車両が、非対象車両であってもよい。車両管理装置１０００は、第１～第３期間の少なくとも１つにおいて、非対象車両との通信よりも高い頻度で対象車両と通信を行なうように構成されてもよい。サーバ３００は、図４に示した処理に代えて図１４に示す処理を実行してもよい。

図１４は、図４に示した処理の変形例を示すフローチャートである。このフローチャートに示される処理は、車群ＶＧに含まれる車両ごとに実行される。以下では、処理の対象となる車両を、「管理車両」と称する。サーバ３００は、管理車両について図１４に示す処理を繰り返し実行する。図１４に示す処理は、Ｓ１７及びＳ１８を追加したこと以外は、図４に示した処理と同じである。以下、主にＳ１７及びＳ１８について説明する。

図１～図３とともに図１４を参照して、通信頻度アップ期間内である場合（Ｓ１１にてＹＥＳ）には、処理がＳ１７に進む。Ｓ１７では、管理車両が対象車両であるか否かを判断する。管理車両が対象車両である場合には（Ｓ１７にてＹＥＳ）、処理がＳ１３に進む。Ｓ１３以降の処理は、図４に示した処理と同じである。

管理車両が非対象車両である場合には（Ｓ１７にてＮＯ）、処理がＳ１８に進む。Ｓ１８では、サーバ３００が、前回通信から所定の時間Ｔ３が経過したか否かを判断する。時間Ｔ３は、非対象車両の通信頻度アップ期間内における通信周期（通信の間隔）に相当する。時間Ｔ３は、時間Ｔ１よりも長い時間に設定される。時間Ｔ３は、２時間であってもよい。これにより、通信頻度アップ期間内においては、サーバ３００と非対象車両との通信が約０．５回／時の頻度で行なわれるようになる。

管理車両が非対象車両である場合、通信頻度アップ期間内において前回通信から時間Ｔ３が経過するまでは、Ｓ１８においてＮＯと判断され、処理がＳ１１に戻る。そして、前回通信から時間Ｔ３が経過した場合には（Ｓ１８にてＹＥＳ）、処理がＳ１４に進む。

上記図１４に示した処理では、通信頻度アップ期間内において、サーバ３００と対象車両との通信頻度を上げ（Ｓ１３）、サーバ３００と非対象車両との通信頻度を下げる（Ｓ１８）。サーバ３００と非対象車両との通信頻度を下げることで、通信頻度の上昇に伴う不具合（通信コストの上昇など）が抑制される。通信頻度アップ期間内においては、サーバ３００と非対象車両との通信を停止してもよい。

上記実施の形態では、市場で約定した商品のための調整力の提供に関しては、期間Ｔ１０、Ｔ２０、及びＴ３０を通信頻度アップ期間としている。しかしこれに限られず、期間Ｔ１０、Ｔ２０、Ｔ３０のいずれか１つのみ又は任意の２つを、通信頻度アップ期間としてもよい。また、同時同量のための調整力の提供に関しては、期間Ｔ２０及びＴ３０を通信頻度アップ期間としている。しかしこれに限られず、期間Ｔ２０、Ｔ３０のいずれか一方のみを通信頻度アップ期間としてもよい。

上記実施の形態及び各変形例において、リソースによる電力調整がリモート制御で実行されることは必須ではない。選定されたリソースは、予めサーバから受け取った指令に基づくローカル制御で電力調整を実行してもよい。

電力管理システムの構成は、図１に示した構成に限られない。サーバ７００とサーバ６００との間に他のサーバ（たとえば、上位アグリゲータのサーバ）が設けられてもよい。サーバ６００は、他のサーバを介してサーバ７００と通信を行なってもよい。また、サーバ３００の機能がサーバ６００に実装され、サーバ３００が割愛されてもよい。サーバ６００が車群ＶＧと直接的に無線通信を行なってもよい。上記実施の形態では、オンプレミスサーバ（図１に示したサーバ３００及び６００）が管理コンピュータとして機能する。しかしこれに限られず、クラウドコンピューティングによってクラウド上にサーバ３００及び６００の機能（特に、車両管理に係る機能）が実装されてもよい。

電力系統ＰＧは、電力会社が提供する大規模な交流グリッドに限られず、マイクログリッドであってもよいし、ＤＣ（直流）グリッドであってもよい。対象車両の構成は、前述した構成（図２参照）に限られない。対象車両は、充放電器の代わりに充電器を備えてもよい。また、対象車両は、充放電器の代わりに放電器を備えて、車載バッテリから放電される電力をＥＶＳＥの代わりに放電コネクタを介して外部電源（たとえば、電力系統ＰＧ）へ出力してもよい。車載バッテリは、交換式であってもよい。ＢＥＶ以外のｘＥＶ（ＰＨＥＶ、ＦＣＥＶ、レンジエクステンダーＥＶなど）が対象車両として採用されてもよい。

対象車両はソーラーパネルを備えてもよい。対象車両は非接触充電可能に構成されてもよい。対象車両は、自動運転可能に構成されてもよいし、飛行機能を備えてもよい。対象車両は、乗用車に限られず、バス又はトラックであってもよい。対象車両は、無人で走行可能な車両（たとえば、ロボタクシー、無人搬送車（ＡＧＶ）、又は農業機械）であってもよい。対象車両は、無人又は１人乗りの小型ＢＥＶ（たとえば、マイクロパレット）であってもよい。対象車両は、個人が所有する車両（ＰＯＶ）であってもよいし、ＭａａＳ（Mobility as a Service）車両であってもよい。ＭａａＳ車両は、ＭａａＳ事業者が管理する車両である。

上記の各種変形例は任意に組み合わせて実施されてもよい。
今回開示された実施の形態は、すべての点で例示であって制限的なものではないと考えられるべきである。本発明の範囲は、上記した実施の形態の説明ではなくて特許請求の範囲によって示され、特許請求の範囲と均等の意味及び範囲内でのすべての変更が含まれることが意図される。

１００ 車両、１２０ 充放電器、１３０ バッテリ、１５０ ＥＣＵ、２００ ＥＶＳＥ、３００，６００，７００ サーバ、６１１ 車両管理部、６１２ 選定部、６１３ 需給管理部、６１４ 取引部、６１５ 調整力算出部、１０００ 車両管理装置、ＰＧ 電力系統、ＵＴ モバイル端末、ＶＧ 車群。

Claims (8)

1. 複数の車両を管理する車両管理装置であって、
   前記車両管理装置は、１つ以上のコンピュータを含み、
   前記車両管理装置は、前記複数の車両に含まれる１台以上の対象車両と周期的に通信を行なうように構成され、
   前記対象車両は、外部電源の調整力として動作可能に構成され、
   前記車両管理装置は、
   約定直前の第１期間と、
   需給計画値提出期限直前の第２期間と、
   前記外部電源の調整力の提供が要求される期間に対応する第３期間と、
   の少なくとも１つの期間において、前記第１～第３期間を除いた期間の平均通信頻度よりも高い頻度で前記対象車両と通信を行なう、車両管理装置。
2. 前記車両管理装置は、電力市場で調整力の入札を行ない、前記対象車両の中から選ばれた１台以上の車両を、前記電力市場で約定した調整力として動作させるための通知を行なうように構成され、
   前記第１期間は、約定３時間前から約定タイミングまでの期間の少なくとも一部に相当する、請求項１に記載の車両管理装置。
3. 前記車両管理装置は、通信により前記対象車両から取得した情報を用いて需給計画値を決定して、決定された需給計画値を前記需給計画値提出期限までに送信するように構成され、
   前記第２期間は、前記需給計画値提出期限３時間前から前記需給計画値提出期限までの期間の少なくとも一部に相当する、請求項１又は２に記載の車両管理装置。
4. 前記車両管理装置は、前記第１～第３期間の各々において、前記第１～第３期間を除いた期間の平均通信頻度よりも高い頻度で前記対象車両と通信を行なうように構成され、
   前記車両管理装置は、前記第１～第３期間の各々において、通信により前記対象車両から取得した情報を用いて前記対象車両の行動予測を行なうように構成される、請求項１～３のいずれか一項に記載の車両管理装置。
5. 前記車両管理装置は、前記対象車両との通信により、前記対象車両に関する車両情報を周期的に取得するように構成され、
   前記車両情報は、前記対象車両の位置と、前記対象車両が備える蓄電装置のＳＯＣとの少なくとも一方を含む、請求項１～４のいずれか一項に記載の車両管理装置。
6. 前記複数の車両は、前記外部電源の調整力として動作しない非対象車両を含み、
   前記車両管理装置は、前記第１～第３期間の少なくとも１つにおいて、前記非対象車両との通信よりも高い頻度で前記対象車両と通信を行なう、請求項１～５のいずれか一項に記載の車両管理装置。
7. １つ以上のコンピュータを含む車両管理装置が、約定直前に設定された第１期間と、需給計画値提出期限直前に設定された第２期間と、外部電源の調整力の提供が要求される期間に対応して設定された第３期間とを含む通信期間において、１台以上の対象車両と周期的に通信を行なうことと、
   前記車両管理装置が、前記第１期間と前記第２期間と前記第３期間との少なくとも１つを含む通信頻度アップ期間内か否かを判断することと、
   前記車両管理装置が、前記通信頻度アップ期間において、前記第１～第３期間を除いた前記通信期間の平均通信頻度よりも高い頻度で前記対象車両と通信を行なうことと、
   を含む、車両管理方法。
8. 前記車両管理装置が、前記第１期間において、通信により前記対象車両から取得した情報を用いて、前記対象車両が提供可能な調整力を予測することと、
   前記車両管理装置が、前記第２期間において、通信により前記対象車両から取得した情報を用いて、需給計画値を求めることと、
   前記車両管理装置が、前記第３期間において、前記対象車両の中から選ばれた１台以上の車両を前記外部電源の調整力として動作させるための通知を行なうことと、
   前記車両管理装置が、前記第３期間において、前記対象車両の中から選ばれた前記１台以上の車両のいずれかが前記外部電源の調整力として動作していない場合に、通信により前記対象車両から取得した情報を用いて、前記対象車両の中から代わりの車両を選ぶことと、
   をさらに含む、請求項７に記載の車両管理方法。

Images