JP2021002940A - エネルギマネージメント方法、及びエネルギマネージメント装置 - Google Patents

Abstract

【課題】運行情報に基づき走行する車両において、電力を有効利用することが可能なエネルギマネージメント方法、及びエネルギマネージメント装置の提供。【解決手段】車載コンピュータ１００ａは、エネルギマネージメント装置であり、運行計画に基づいて走行する車両Ａｓにて、複数の消費ドメインＤＥｃによる電力の使用を管理するエネルギマネージャ１００として機能する。エネルギマネージャ１００は、運行計画に加えて、複数の消費ドメインＤＥｃに電力を供給する給電ドメインＤＥｓについての余力情報を取得する。さらにエネルギマネージャ１００は、複数の消費ドメインＤＥｃそれぞれによる電力消費を、運行計画及び余力情報に基づき調停する。【選択図】図５

Description

この明細書による開示は、電力の使用を管理するエネルギマネージメントの技術に関する。

特許文献１には、蓄電池及びオルタネータを含む電源と、当該電源より電力が供給される複数の負荷とを備える構成に適用される電源マネージメントＥＣＵが開示されている。具体的に、特許文献１の電源マネージメントＥＣＵは、各負荷の必要電力と、電源の使用可能電力とに基づいて、各負荷のそれぞれに対する給電タイミングを設定する。

特開２００８−２８９３０２号公報

近年では、例えば運行センタ等にて策定された運行計画に基づき、車両を走行させることが試みられている。こうした運行情報を、車載された複数の負荷による電力消費の管理に用いることは、特許文献１には、何ら開示されていない。そのため、特許文献１では、負荷側が必要とすれば、電源の使用可能電力は、全て使用される状態となってしまう。そのため、電力の有効利用という観点で、特許文献１の電力制御の方法には、改善の余地があった。

本開示は、運行情報に基づき走行する車両において、電力を有効利用することが可能なエネルギマネージメント方法、及びエネルギマネージメント装置の提供を目的とする。

上記目的を達成するため、開示された一つの態様は、コンピュータ（１００ａ，１１０ａ）によって実施され、運行計画に基づいて走行する車両（Ａｓ）にて当該車両に搭載される複数の消費ドメイン（ＤＥｃ）による電力の使用を管理するエネルギマネージメント方法であって、少なくとも一つのプロセッサ（１１，１１１）にて実行される処理に、運行計画を取得し（Ｓ１０１）、複数の消費ドメインに電力を供給する給電ドメイン（ＤＥｓ）についての余力情報を取得し（Ｓ１０２）、複数の消費ドメインそれぞれによる電力消費を、運行計画及び余力情報に基づき調停する（Ｓ１０３）、というステップを含むエネルギマネージメント方法とされる。

また開示された一つの態様は、運行計画に基づいて走行する車両（Ａｓ）において用いられ、車両に搭載される複数の消費ドメイン（ＤＥｃ）による電力の使用を管理するエネルギマネージメント装置であって、運行計画を取得する運行計画取得部（７１）と、複数の消費ドメインに電力を供給する給電ドメイン（ＤＥｓ）についての余力情報を取得する余力情報取得部（７２）と、複数の消費ドメインそれぞれによる電力の消費を、運行計画及び余力情報に基づき調停する電力調停部（７４）と、を備えるエネルギマネージメント装置とされる。

これらの態様では、運行計画に基づき、複数の消費ドメインに許容される電力消費が調停される。故に、余力情報の示す給電ドメインの余力は、これからの車両の走行行動を見越して、各消費ドメインに割り振られ得る。その結果、運行情報に基づき走行する車両において、給電ドメインの電力を有効に使用することが可能になる。

尚、上記括弧内の参照番号は、後述する実施形態における具体的な構成との対応関係の一例を示すものにすぎず、技術的範囲を何ら制限するものではない。

本開示の一実施形態によるモビリティサービスシステムの全体像を模式的に示す図である。 運行マネージャの構成を示すブロック図である。 計画生成部にて実施されるスケジュール策定処理の詳細を示すフローチャートである。 最適解算出部にて実施される最適解算出処理の詳細を示すフローチャートである。 サービス車両に搭載された電気構成を示すブロック図である。 エネルギマネージャの構成を示すブロック図である。 エネルギマネージャにて実施される上限設定処理の詳細を示すフローチャートである。 消費ドメインのドメインマネージャにて実施される上限調停処理の詳細を示すフローチャートである。 エネルギマネージャにて実施される上限調停処理の詳細を示すフローチャートである。

図１に示す本開示の一実施形態によるモビリティサービスシステムは、決済管理センタ、運行管理センタＣＮＴ、多数のサービス車両ＳＶを含んでいる。モビリティサービスシステムは、多数のサービス車両ＳＶの走行を運行管理センタＣＮＴにおいて管理し、サービス車両ＳＶによるユーザＵへの移動空間の提供を可能にする。モビリティサービスシステムは、モビリティサービスの提供の対価を、決算管理システムによって徴収する。決算管理センタ、運行管理センタＣＮＴ及び各サービス車両ＳＶは、それぞれネットワークＮＷに接続されており、相互に通信可能である。

運行管理センタＣＮＴには、図１及び図２に示す運行マネージャ１１０が設置されている。運行マネージャ１１０は、サービス車両ＳＶのユーザＵへの配車を管理する。運行マネージャ１１０は、配車管理のために、個々のサービス車両ＳＶの運行計画を策定する。運行マネージャ１１０は、サービス車両ＳＶのユーザＵへの配車指示として、策定した運行計画を、ネットワークＮＷを通じて、各サービス車両ＳＶに送信する。

運行マネージャ１１０は、少なくとも一台のサーバ装置１１０ａを主体とした演算システムである。サーバ装置１１０ａは、処理部１１１、ＲＡＭ１１２、記憶部１１３、入出力インターフェース１１４、及びこれらを接続するバス等を備え、運行マネージャ１１０として動作する。処理部１１１は、ＲＡＭ１１２と結合された演算処理のためのハードウェアである。処理部１１１は、ＲＡＭ１１２へのアクセスにより、配車管理等に関連する種々の処理を実行する。記憶部１１３は、不揮発性の記憶媒体を含む構成である。記憶部１１３には、処理部１１１によって実行される種々のプログラム（配車管理プログラム等）が格納されている。

運行マネージャ１１０は、記憶部１１３に記憶された配車管理プログラムを処理部１１１によって実行することで、本開示の配車管理方法を実現させる複数の機能部を備える。具体的に、運行マネージャ１１０には、配車管理プログラムに基づき、ユーザ情報取得部１２１、配信情報取得部１２２、ステーション情報取得部１２３、計画提供承認部１２４、及び運行シミュレーション部１４０等の機能部が構築される。

ユーザ情報取得部１２１は、ネットワークＮＷ及び基地局ＢＳを通じて、ユーザ情報を取得する。ユーザ情報は、モビリティサービスの利用を希望するユーザＵにより、ユーザ端末ＵＴに入力された情報である。ユーザ情報には、ユーザＵを識別するＩＤ情報、ユーザＵの乗車場所、降車場所、及び乗車予定時刻（乗車予定時間帯）等が少なくとも含まれている。ユーザＵは、例えばスマートフォン、タブレット端末、及びパーソナルコンピュータ等を、ユーザ端末ＵＴとして、ユーザ情報の入力に使用できる。

尚、ユーザＵは、特定の場所及び時刻に、ヒトではなく集配物Ｐを運ぶ目的で、サービス車両ＳＶを利用できる。またユーザ情報には、乗車予定時刻に替えて、又は乗車予定時刻と共に降車希望時刻（降車希望時間帯）が含まれていてもよい。さらに、一人のユーザＵにより、複数人分の搭乗予約が実施されてもよい。この場合、ユーザ情報には、サービス車両ＳＶに搭乗する搭乗者の人数を示す情報がさらに含まれる。

配信情報取得部１２２は、ネットワークＮＷを通じて、将来情報及び電力情報を取得する。将来情報及び電力情報は、ネットワークＮＷに接続されたクラウドサーバ１９０によって収集され、クラウドサーバ１９０によって配信される。将来情報は、近い将来（半日後から明日程度先）のサービス車両ＳＶの需要予測に用いられる情報である。将来情報には、天気及び気温等の気象予報情報及びヒトが集まるイベント等の近隣での開催予定情報が含まれている。電力情報は、電力に関連する情報であって、特に後述する充電ステーションＣＳへの供給電力に関連する情報である。具体的に、電力情報は、送電網に電力を供給する発電所の電力使用率、太陽光発電システムによる発電量、及び住宅、オフィスビル、商業ビル及び工場等での電力負荷等についての予測情報及び現在情報を含んでいる。

ステーション情報取得部１２３は、ネットワークＮＷを通じて、ステーション情報を取得する。ステーション情報は、特定の地域に設置された充電ステーションＣＳに関連する情報である。ステーション情報には、充電ステーションＣＳの設置場所、使用予定の無い空き時間、充電に伴う電力料金の単価（以下、「電力単価」）、及び充電器の仕様等の情報が含まれている。充電器の仕様情報には、急速充電可能か否か、対応する充電の規格、及び急速充電の最大出力（ｋＷ）等の情報が含まれている。ステーション情報は、各充電ステーションＣＳの各ステーションＥＣＵ１８０により、ステーション情報取得部１２３に提供される。

充電ステーションＣＳは、サービス車両ＳＶに搭載された走行用のメインバッテリ２２を充電するインフラ施設である。充電ステーションＣＳは、モビリティサービスの提供対象となる地域において、広範囲に点在するように分散設置されている。充電ステーションＣＳは、例えばショッピングモール、コンビニエンスストア及び公共施設等の各駐車場に設置されている。充電ステーションＣＳは、電力網を通じて発電所から供給される供給電力、又は太陽光発電システム等から供給される供給電力を用いて、メインバッテリ２２を充電する。

ここで、特定地域に設置された多数の充電ステーションＣＳは、ステーションマネージャによって管理されていてもよい。ステーションマネージャは、ネットワークＮＷを通じて、ステーションＥＣＵ１８０と通信可能であり、各充電ステーションＣＳについてのステーション情報を把握している。ステーションマネージャが存在している場合、ステーション情報取得部１２３は、多数の充電ステーションＣＳのステーション情報を、ステーションマネージャから取得できる。

計画提供承認部１２４は、ネットワークＮＷ及び基地局ＢＳ等を通じて、各サービス車両ＳＶと情報をやり取りする。計画提供承認部１２４は、現在位置、ユーザＵ又は集配物Ｐを移送中か否か、及びバッテリ残量等を示す車両ステータス情報を、各サービス車両ＳＶから取得する。計画提供承認部１２４は、運行シミュレーション部１４０にて生成される運行計画を、個々のサービス車両ＳＶに提供する。

加えて計画提供承認部１２４は、サービス車両ＳＶにて修正運行計画（後述する）が生成された場合、この修正運行計画を取得する。サービス車両ＳＶに搭載されたエネルギマネージャ１００は、後述するように、運行マネージャ１１０より提供される運行計画を基準運行計画とし、当該基準運行計画を修正してなる修正運行計画を生成可能である。計画提供承認部１２４は、エネルギマネージャ１００によって提案された修正運行計画を取得した場合、当該修正運行計画を承認するか否かの判断結果を、提案元であるサービス車両ＳＶに通知する。

運行シミュレーション部１４０は、各サービス車両ＳＶの運行計画を生成する。加えて運行シミュレーション部１４０は、各サービス車両ＳＶから送信される修正運行計画について、承認するか否かを判断する。運行シミュレーション部１４０は、運行計画の生成及び修正運行計画の承認可否の判定のために、全サービス車両ＳＶにつての配車スケジュール及び充電スケジュールを組み立てる。

運行シミュレーション部１４０は、各スケジュールの策定のため、地図情報データベース１３１、過去情報データベース１３２、及び運行計画データベース１３３に蓄積された情報を参照可能である。各データベース１３１〜１３３は、それぞれ記憶部１１３に確保された記憶領域である。地図情報データベース１３１は、サービス車両ＳＶの走行ルートの設定に用いられる多数の地図情報を記憶している。過去情報データベース１３２は、サービス車両ＳＶの需要予測に用いられる過去情報が記憶されている。過去情報は、過去の出来事と、そのときの需要傾向との相関を記録した情報である。運行計画データベース１３３は、各サービス車両ＳＶに配信された運行計画を記憶している。

運行シミュレーション部１４０は、配車スケジュール及び充電スケジュールの策定に関連するサブ機能部として、ランニングコスト推定部１４１、ライフサイクルコスト推定部１４２、計画生成部１４３、及び最適解算出部１４４を有している。

ランニングコスト推定部（以下、「ＲＣ推定部」）１４１は、ユーザＵへのサービス提供に応じて発生するランニングコストを算定する。ランニングコストは、メインバッテリ２２への充電に伴う電力単価と、各サービス車両ＳＶにて消費されるエネルギ量（以下、「消費電力量」，単位は「Ｗｈ」又は「ｋＷｈ」）の積となる。ＲＣ推定部１４１は、電力情報及びステーション情報を参照し、電力単価を設定する。電力単価が例えばダイナミックプライシングによって決定される場合、ＲＣ推定部１４１は、電力の需要予測に基づき、電力単価を設定する。さらにＲＣ推定部１４１は、計画生成部１４３にてシミュレートされる運行計画（運行計画案）に基づき、サービス提供に応じて生じるエネルギ消費としての消費電力量を推定する。ＲＣ推定部１４１は、推定した消費電力量に、設定した電力単価を乗算することにより、サービス提供に伴うランニングコストを算出する。

ライフサイクルコスト推定部（以下、「ＬＣＣ推定部」）１４２は、ユーザＵへのサービス提供に伴って発生するライフサイクルコストを算定する。ライフサイクルコストは、実質的に、サービス車両ＳＶに搭載されたメインバッテリ２２のコストである。メインバッテリ２２は、ＳＯＨ（States Of Health）が所定の閾値（以下、「交換判定値」）を下回った場合に、交換される。ＳＯＨは、初期状態の満充電容量（単位は、「Ｗｈ」又は「ｋＷｈ」）に対する劣化状態での満充電容量の割合である。ＬＣＣ推定部１４２は、メインバッテリ２２の交換に必要な所定費用と、交換判定値とから、ＳＯＨについての単位減少量あたりのコスト（以下、「単位劣化コスト」）を設定する。

ＬＣＣ推定部１４２は、運行計画案に基づく走行及び充電により、サービス車両ＳＶのメインバッテリ２２に生じる性能劣化の度合い、即ち、ＳＯＨの減少量を推定する。記憶部１３には、メインバッテリ２２について、どのような使用条件で、どのような充放電を行うと、どの程度ＳＯＨの劣化するのかを示す相関情報が、関数又はテーブル等の形式で予め記憶されている。ＬＣＣ推定部１４２は、相関情報を参照し、運行計画案に基づく使用によるＳＯＨの減少量を算出する。ＬＣＣ推定部１４２は、推定したＳＯＨの減少量に、単位劣化コストを乗算することで、サービス提供に伴うライフサイクルコストを算定する。

計画生成部１４３は、スケジュール策定処理（図３参照）の実施により、複数のサービス車両ＳＶの運用内容を規定する配車スケジュール及び充電スケジュールを組み立てる。計画生成部１４３は、ユーザ情報、車両ステータス情報、ステーション情報、電力情報等に基づき、これらの情報を考慮して、サービス車両ＳＶを電欠させずに、ユーザＵの所望する移動サービスが完遂されるように、各スケジュールを策定する。

配車スケジュールは、どのサービス車両ＳＶを、どのようなタイミングで、どの乗車位置及び降車位置等に、どのような走行ルート及び走行速度で向かわせるかを規定した内容である。計画生成部１４３は、配車スケジュールの生成にあたり、地図情報データベース１３１に格納された地図情報を参照し、各サービス車両ＳＶの走行ルートを設定する。配車スケジュールには、特定の駐車場ＰＳにサービス車両ＳＶを駐車させて、サービス提供を待機させる待機スケジュールも含まれている。

充電スケジュールは、どのサービス車両ＳＶを、どのタイミングで、どの充電ステーションＣＳを使用して、どの程度まで充電させるかを規定した内容である。具体的に、計画生成部１４３は、充電スケジュールの生成にあたり、ステーション情報の示す空き情報を考慮して、サービス車両ＳＶを向かわせる充電ステーションＣＳを決定する。加えて計画生成部１４３は、充電ステーションＣＳにて普通充電及び急速充電のいずれを実施するか、並びに充電目標とするメインバッテリ２２のＳＯＣ（States Of Charge）等をさらに決定する。

ここで、計画生成部１４３は、上述の如く、ユーザ端末ＵＴを通じて受け付けた利用予約の完遂を最優先に、配車スケジュール及び充電スケジュールを策定する。そうしたうえで、計画生成部１４３は、サービス提供による売上の最大化と、サービス提供に伴う経費の最小化とを両立させて、モビリティサービスを提供する事業者の利益を最大化させるような配車スケジュール及び充電スケジュールを探索する。

計画生成部１４３は、売上の最大化を目的とし、機会損失の低減を図るため、ユーザ情報、将来情報及び過去情報等を用いて、サービス車両ＳＶの需要予測を、推定によって取得する。計画生成部１４３は、推定した需要予測を考慮し、予測されるサービス車両ＳＶの需要に最大限対応できるように、充電スケジュールを生成する。

一例として、気温上昇や降雨等の気象予報情報又は近隣でのイベント開催予定情報等が将来情報としてある場合、サービス車両ＳＶの需要増加が見込まれる。この場合、計画生成部１４３は、各サービス車両ＳＶのメインバッテリ２２を、通常よりも満充電に近い状態にする充電スケジュールを生成する。加えて計画生成部１４３は、急速充電が可能な充電ステーションＣＳの優先利用により、非稼動時間（充電時間）を短縮し、稼動時間を最長化する充電スケジュールを生成する。

また別の一例として、過去情報には、平日、休日、及び時間帯等の時間情報、並びに天気及び気温等の気象条件等に関連付けて、これまでの需要傾向が記憶されている。計画生成部１４３は、過去情報を参照し、今後の時間情報及び気象予報情報から、サービス車両ＳＶの需要を予測する。計画生成部１４３は、需要予測に基づき、需要の発生タイミングで、運行可能なサービス車両ＳＶが十分に確保されるように、各サービス車両ＳＶのメインバッテリ２２の充電状態を調整する。

計画生成部１４３は、経費の最小化を目的とし、サービス提供に応じて発生するランニングコストと、サービス提供に伴うサービス車両ＳＶのライフサイクルコストとを考慮し、配車スケジュール及び充電スケジュールを生成する。計画生成部１４３は、ＲＣ推定部１４１にて算定されるランニングコストと、ＬＣＣ推定部１４２にて算定されるライフサイクルコストとが、総合的に最も抑制されるように、コストを共通の指標として、各スケジュールを調整する。計画生成部１４３は、複数のサービス車両ＳＶに発生するランニングコスト及びライフサイクルコストの和がトータルで少なくなるように、配車スケジュール及び充電スケジュールを探索する。

具体的に、計画生成部１４３は、複数のサービス車両ＳＶに発生するランニングコスト（エネルギコスト）の総和が少なくなるように、配車スケジュール及び充電スケジュールを組み立てる。例えば計画生成部１４３は、電力情報に基づき、電力需要がピークとなるような夏季の日中の充電を避け、電力単価が安くなる深夜等の時間帯に、メインバッテリ２２を充電する充電スケジュールを生成する。

計画生成部１４３は、各サービス車両ＳＶの走行ルートについて、全体として短く、低速で走行可能であり、且つ、登坂区間を避けるように、配車スケジュールを策定する。さらに計画生成部１４３は、サービス車両ＳＶが充電ステーションＣＳの近傍に位置するタイミングで、充電を行うような配車スケジュール及び充電スケジュールを組み立てる。

計画生成部１４３は、メインバッテリ２２の性能劣化を許容するか否かを、ライフサイクルコスト及びライフサイクルコストのコストベースの比較に基づき、判断する。ここで、メインバッテリ２２の性能劣化は、高温で充放電するとき、及び満充電の状態で長時間放置するときに、進行し易くなる。故に、計画生成部１４３は、性能劣化の進行を抑えて、ライフサイクルコストを低減させるため、発熱状態での充電を避ける、満充電まで充電することを避ける等の劣化低減対策を組み込んだ充電スケジュールを生成する。加えて計画生成部１４３は、日陰となる充電ステーションＣＳを優先的に使用する、急速充電を避けて普通充電を行う、及び出発時刻に合わせて充電を完了させる等の劣化低減対策を、充電スケジュールに組み込むことができる。さらに計画生成部１４３は、走行負荷の低い状態で走行可能なルートを選択する、充電開始の直前に高負荷での走行を避ける等の劣化低減対策を、配車スケジュールに組み込むことができる。

計画生成部１４３は、サービス車両ＳＶ全体での配車スケジュール及び充電スケジュールを成立させたうえで、これらのスケジュールに基づき、個々のサービス車両ＳＶについての運行計画を生成する。計画生成部１４３は、生成した各運行計画を、計画提供承認部１２４を通じて、対応する個々のサービス車両ＳＶに提供する。加えて計画生成部１４３は、各サービス車両ＳＶに提供した運行計画を、各サービス車両ＳＶを識別するＩＤ情報と紐付けた状態で、運行計画データベース１３３に記憶する。

計画生成部１４３は、修正運行計画に基づくサービス車両ＳＶの運行を承認するか否か判定する。計画生成部１４３は、計画提供承認部１２４にて修正運行計画が取得された場合、運行計画データベース１３３に記憶された当初の基準運行計画を、修正運行計画と比較する。計画生成部１４３は、基準運行計画から修正運行計画への変更により、全体の配車スケジュール及び充電スケジュールの修正の要否を判定する。計画生成部１４３は、全体のスケジュールの修正が実質的に生じない場合、換言すれば、他車両の運行計画に大きな変更がない場合に、基準運行計画から修正運行計画への変更を承認する。この場合、計画生成部１４３は、修正運行計画を承認する旨の通知を、計画提供承認部１２４を通じて、提案元のサービス車両ＳＶに送信する。

以上の計画生成部１４３にて実施されるスケジュール策定処理（図３参照）詳細を、さらに説明する。スケジュール策定処理は、モビリティサービスの提供期間にて、計画生成部１４３により繰り返し実施される。

Ｓ１１では、各サービス車両ＳＶの車両ステータス情報の取得により、各サービス車両ＳＶにて利用可能な電気エネルギ量（以下、「エネルギ利用可能量Ｗ１」）を把握し、Ｓ１２に進む。

Ｓ１２では、今後の需要予測Ｗ２を生成し、Ｓ１３に進む。Ｓ１２では、ユーザ情報、過去情報及び将来情報等を用いて、サービス車両ＳＶの利用に関する需要予測を行う。加えてＳ１２では、電力情報に基づき、電力消費に関する需要予測をさらに行う。これらの需要予測Ｗ２のうちで、サービス車両ＳＶの需要予測は、サービス車両ＳＶにて消費されるエネルギ、換言すれば、サービス車両ＳＶから出ていく分のエネルギに関連する推定情報となる。一方、電力の需要予測は、サービス車両ＳＶに供給されるエネルギ、換言すれば、サービス車両ＳＶに入ってくる分のエネルギに関連する推定情報となる。

Ｓ１３では、Ｓ１１にて把握したエネルギ利用可能量Ｗ１と、Ｓ１２にて生成した需要予測Ｗ２とに基づき、例えば日、時、瞬間等、特定の時間毎について、エネルギ消費及び性能劣化のマトリクスを作成し、Ｓ１４に進む。Ｓ１３では、各サービス車両ＳＶでのエネルギ利用可能量Ｗ１と、サービス車両ＳＶの需要予測とに基づき、各サービス車両ＳＶに供給すべき供給エネルギ量が、特定の時間毎に把握される。この供給エネルギ量に、電力の需要予測を反映した電力単価を乗算することにより、ランニングコストが推定される。加えて、特定の時間毎の供給エネルギ量に基づき、メインバッテリ２２の性能劣化に関連するライフサイクルコストが推定される。

Ｓ１４では、モビリティサービスの事業者及びユーザＵのそれぞれのニーズ毎の要望と、ステーション情報とを用いて、配車スケジュール及び充電スケジュールを策定する。具体的に、Ｓ１４では、事業者及びユーザＵの各ニーズに基づき、エネルギ消費及び性能劣化について、どちらをどの程度優先するのかを設定する。そして、エネルギ消費及び性能劣化の優先度合いと、ステーション情報と、上述のマトリクス化されたコスト関連の情報とに基づき、ランニングコスト及びライフサイクルコストをバランスさせた各スケジュールを生成する。

一例として、計画生成部１４３は、優先度合い、ステーション情報、及びマトリクスに基づくコスト関連の情報をそれぞれパラメータ化し、予め規定された関数に適用する。計画生成部１４３は、こうした関数の値が最小となるような配車スケジュール及び充電スケジュール、換言すれば、事業者及びユーザＵのニーズを満たすような各スケジュールを、採用対象とする。

Ｓ１５では、Ｓ１４にて生成した各スケジュールに基づき、個々のサービス車両ＳＶについての運行計画を生成し、Ｓ１６に進む。Ｓ１６では、Ｓ１５にて生成した運行計画を各サービス車両ＳＶに送信し、一連のスケジュール策定処理を一旦終了する。

最適解算出部１４４は、最適解算出処理（図４参照）により、モビリティサービスの事業の提供者（事業者）が現在よりも効率的に利益を上げることが可能な、充電ステーションＣＳ及びサービス車両ＳＶについての最適解を算出する。この最適解は、エネルギ消費及び性能劣化について、現在よりも最適化された値である。ここでの最適化は、ランニングコスト及びライフサイクルコストの最小化と実質的に同義である。尚、ライフサイクルコストには、サービス車両ＳＶ及び充電ステーションＣＳの投資コストが含まれている。

最適解算出部１４４は、配車スケジュール及び充電スケジュールの生成に使用した各種の蓄積情報を、最適解の算出に用いるため、参照する（図４ Ｓ３１参照）。蓄積情報は、具体的には、エネルギ消費に基づくランニングコスト、メインバッテリ２２の性能劣化に基づくライフサイクルコスト、及び需要予測等である。最適解算出部１４４は、参照した蓄積情報を使用して、特定の地域にて、電力の需要予測を考慮しつつ、ユーザＵの需要を満たすことが可能な運行状態をシミュレーションによって特定する（図４ Ｓ３２参照）。

最適解算出部１４４は、シミュレーション結果に基づき、サービス車両ＳＶについての最適解を算出する（図４ Ｓ３３参照）。具体的に、最適解算出部１４４は、特定の地域にて運用するサービス車両ＳＶの運用台数及び車両仕様等について、望ましい値を算出する。この車両仕様は、例えば搭乗人数及びメインバッテリ２２の容量等である。

加えて最適解算出部１４４は、シミュレーション結果に基づき、充電ステーションＣＳについての最適解を算出する（図４ Ｓ３４参照）。具体的に、最適解算出部１４４は、充電ステーションＣＳの設置数、設置場所、及び急速充電機能の有無等の充電器仕様について、現状を改善可能な最適解を算出する。

次に、上述の運行マネージャ１１０によって走行を管理されるサービス車両ＳＶの詳細を、図５及び図６に基づき説明する。

多数のサービス車両ＳＶの少なくとも一部は、走行用のメインバッテリ２２を搭載し、メインバッテリ２２の電力で走行するＢＥＶ（Battery Electric Vehicle）である。サービス車両ＳＶは、運転者による運転操作がない状態で自律走行可能な自動運転車である。サービス車両ＳＶは、モビリティサービスに用いられる専用車両であり、事業者によって運用されるフリート車両であってよい。尚、以下の説明では、特定の運行マネージャ１１０の管理下にある多数のサービス車両ＳＶのうちの一台（自車両）を、便宜的に車両Ａｓとする。そして、車両Ａｓを除く他のサービス車両ＳＶを、他車両Ａｘとする。

車両Ａｓには、自律走行を可能にするための構成として、外界センサ９１、ロケータ９２、ＤＣＭ９３、及びＡＤコンピュータ９０が搭載されている。加えて車両Ａｓには、充電システム６０、複数の消費ドメインＤＥｃ、給電ドメインＤＥｓ、及びエネルギマネージャ１００が搭載されている。

外界センサ９１は、歩行者及び他の車両等の移動物体、並びに路上の縁石、道路標識、道路標示、及び区画線等の静止物体を検出する。車両Ａｓには、例えばカメラユニット、ライダ、ミリ波レーダ、及びソナー等が外界センサ９１として搭載されている。

ロケータ９２は、衛星測位システムの複数の測位衛星から、測位信号を受信可能なアンテナを有している。ロケータ９２は、受信した測位信号に基づき、車両Ａｓの位置を計測する。

ＤＣＭ（Data Communication Module）９３は、車両Ａｓに搭載される通信モジュールである。ＤＣＭ９３は、ＬＴＥ（Long Term Evolution）及び５Ｇ等の通信規格に沿った無線通信により、車両Ａｓの周囲の基地局ＢＳ（図１参照）との間で電波を送受信する。ＤＣＭ９３の搭載により、車両Ａｓは、ネットワークＮＷに接続可能なコネクテッドカーとなる。

ＡＤ（Automated Driving）コンピュータ９０は、運行マネージャ１１０と連携し、運行計画に基づく車両Ａｓの自律走行を実現する。ＡＤコンピュータ９０は、処理部、ＲＡＭ、記憶部、入出力インターフェース、及びこれらを接続するバス等を備えた車載コンピュータである。ＡＤコンピュータ９０は、運行マネージャ１１０によって送信された運行計画を、ＤＣＭ９３を通じて取得する。ＡＤコンピュータ９０は、外界センサ９１より取得する物体情報、及びロケータ９２より取得する位置情報等に基づき、車両Ａｓの周囲の走行環境を認識し、車両Ａｓを運行計画に従って走行させるための予定走行経路を生成する。ＡＤコンピュータ９０は、予定走行経路に基づく走行を実現させる駆動、制動及び操舵の各制御量を演算し、各制御量を指示する制御コマンドを生成する。ＡＤコンピュータ９０は、生成した制御コマンドを、運動マネージャ３０（後述する）へ向けて逐次出力する。

消費ドメインＤＥｃは、メインバッテリ２２等の電力の使用により、種々の車両機能を実現する車載機器群である。本実施形態では、少なくとも一つのドメインマネージャを含み、当該ドメインマネージャによって電力の消費を管理されるひと纏まりの車載機器群が、一つの消費ドメインＤＥｃとされる。複数の消費ドメインＤＥｃには、走行制御ドメインＤＤｃ、空調制御ドメイン、ユーザエクスペリエンス（以下、「ＵＸ」）ドメインが含まれている。

走行制御ドメインＤＤｃは、車両Ａｓの走行を制御する消費ドメインＤＥｃである。走行制御ドメインＤＤｃには、モータジェネレータ３１、インバータ３２、ステア制御システム３３、ブレーキ制御システム３４、及び運動マネージャ３０が含まれている。

モータジェネレータ３１は、車両Ａｓを走行させるための駆動力を発生させる駆動源である。インバータ３２は、モータジェネレータ３１による力行及び回生を制御する。インバータ３２は、モータジェネレータ３１による力行時において、メインバッテリ２２より供給される直流電力を三相交流電力に変換し、モータジェネレータ３１に供給する。インバータ３２は、交流電力の周波数、電流、及び電圧を調節可能であり、モータジェネレータ３１の発生駆動力を制御する。一方、モータジェネレータ３１による回生時において、インバータ３２は、交流電力を直流電力に変換し、メインバッテリ２２に供給する。ステア制御システム３３は、車両Ａｓの操舵を制御する。ブレーキ制御システム３４は、車両Ａｓに生じさせる制動力を制御する。

運動マネージャ３０はＡＤコンピュータ９０と電気的に接続された車載コンピュータである。運動マネージャ３０は、駆動、制動及び操舵等の各制御量を示した制御コマンドを、ＡＤコンピュータ９０より取得する。運動マネージャ３０は、制御コマンドに基づき、インバータ３２、ステア制御システム３３、ブレーキ制御システム３４を統合的に制御し、予定走行経路をトレースするように車両Ａｓを自律走行させる。

以上の運動マネージャ３０は、走行制御ドメインＤＤｃのドメインマネージャとして機能し、モータジェネレータ３１、インバータ３２、ステア制御システム３３及びブレーキ制御システム３４のそれぞれによる電力の消費を総合的に管理する。運動マネージャ３０は、走行制御ドメインＤＤｃについて、瞬間的な電力の使用上限と、特定期間での電力量の消費上限とを、エネルギマネージャ１００から取得する。運動マネージャ３０は、使用上限及び消費上限を超えないように、制御対象の各構成にて使用される電力及び電力量を制御する。

空調制御ドメインは、車両Ａｓの居室空間の空気調和と、メインバッテリ２２の温度調整とを実施する消費ドメインＤＥｃである。空調制御ドメインには、ＨＶＡＣ（Heating, Ventilation, and Air Conditioning）４１、温調システム４２、及び熱マネージャ４０が含まれている。尚、ＨＶＡＣ４１は、一台の車両Ａｓに対して、複数設置されていてもよい。

ＨＶＡＣ４１は、メインバッテリ２２からの供給電力を利用して、居室空間の暖房、冷房及び換気等を行う電動式の空調装置である。ＨＶＡＣ４１は、冷凍サイクル装置、送風ファン、ヒータ及びエアミックスダンパ等を備えている。ＨＶＡＣ４１は、冷凍サイクル装置のコンプレッサ、ヒータ及びエアミックスダンパ等を制御し、車両外部の空気又は居室空間内の空気を昇温してなる暖気、或いは冷却してなる冷気を生成する。ＨＶＡＣ４１は、送風ファンの作動により、生成した暖気又は冷気を、空調風として、居室空間に供給する。

温調システム４２は、メインバッテリ２２、モータジェネレータ３１及びインバータ３２等の冷却又は昇温を行うシステムである。温調システム４２は、冷却回路、電動ポンプ及び液温センサを備えている。冷却回路は、メインバッテリ２２、モータジェネレータ３１及びインバータ３２等の電動走行系の各構成を巡るように設置された配管を主体として構成される。電動ポンプは、冷却回路の配管内に充填されたクーラントを循環させる。液温センサは、クーラントの温度を計測する。温調システム４２は、ＨＶＡＣ４１によって昇温又は冷却させたクーラントの循環により、高圧回路を含む電動走行系の温度を所定の温度範囲内に維持させる。

熱マネージャ４０は、ＨＶＡＣ４１及び温調システム４２の作動を制御する車載コンピュータである。熱マネージャ４０は、居室空間の空調設定温度と、居室空間に設置された温度センサの計測温度とを比較し、ＨＶＡＣ４１の空調作動を制御する。熱マネージャ４０は、液温センサによる計測結果を参照し、ＨＶＡＣ４１及び温調システム４２の温調作動を制御する。

以上の熱マネージャ４０は、熱ドメインのドメインマネージャとして機能し、ＨＶＡＣ４１及び温調システム４２のそれぞれによる電力の消費を総合的に管理する。熱マネージャ４０は、熱ドメインについて、瞬間的な電力の使用上限と、特定期間での電力量の消費上限とを、エネルギマネージャ１００から取得する。熱マネージャ４０は、使用上限及び消費上限を超えないように、ＨＶＡＣ４１及び温調システム４２にて使用される電力及び電力量を制御する。

ユーザエクスペリエンス（以下、「ＵＸ」）ドメインは、ユーザＵの搭乗する車室内を快適な状態に保つことにより、モビリティサービスを使用するユーザＵの満足度を向上させる消費ドメインＤＥｃである。ＵＸドメインは、主にＨＭＩ（Human Machine Interface）システムに関連した車載機器群を主体としている。ＵＸドメインには、キャビン操作システム５１、コネクトシステム５２、及びＵＸマネージャ５０が含まれている。

キャビン操作システム５１は、タッチパネル、プッシュボタン及びダイヤル等の操作部を有し、車室内のユーザＵによる操作部への操作を受け付ける入力インターフェースである。キャビン操作システム５１には、例えば空調の設定を変更するユーザ操作、及びコネクトシステム５２によって提示される情報を切り替えるユーザ操作等が入力される。

コネクトシステム５２は、ディスプレイパネルを有し、車室内のユーザＵに情報を提供する出力インターフェースである。コネクトシステム５２は、ＤＣＭ９３を通じて、ネットワークＮＷからニュース情報、天気情報、交通情報、及び映像コンテンツ等を取得する。コネクトシステム５２は、取得情報をディスプレイパネルに表示することにより、プッシュ型の情報提示を行う。

ＵＸマネージャ５０は、処理部、ＲＡＭ、記憶部、入出力インターフェース、及びこれらを接続するバス等を備えた車載コンピュータである。ＵＸマネージャ５０は、ＵＸドメインのドメインマネージャとして機能し、キャビン操作システム５１及びキャビン操作システム５１のそれぞれによる電力の消費を総合的に管理する。ＵＸマネージャ５０は、ＵＸドメインについて、瞬間的な電力の使用上限と、特定期間での電力量の消費上限とを、エネルギマネージャ１００から取得する。ＵＸマネージャ５０は、各使用上限を超えないように、キャビン操作システム５１及びコネクトシステム５２にて使用される電力及び電力量を制御する。

給電ドメインＤＥｓは、消費ドメインＤＥｃへの電力供給を可能にするための車載機器群である。給電ドメインＤＥｓは、消費ドメインＤＥｃと同様に、少なくとも一つのドメインマネージャを含んでいる。車両Ａｓの給電ドメインＤＥｓは、充電回路２１、メインバッテリ２２、サブバッテリ２３、及びバッテリマネージャ２０を備えている。

充電回路２１は、バッテリマネージャ２０との協働により、各消費ドメインＤＥｃ及び各バッテリ２２，２３間での電力の流れを統合的に制御するジャンクションボックスとして機能する。充電回路２１は、メインバッテリ２２及びサブバッテリ２３からの電力供給と、メインバッテリ２２及びサブバッテリ２３への充電とを実施する。

メインバッテリ２２は、電力を充放電可能な二次電池である。メインバッテリ２２は、多数の電池セルを含む組電池を備えている。電池セルは、例えばニッケル水素電池、リチウムイオン電池、及び全固体電池等のいずれかである。メインバッテリ２２に蓄えられた電力は、主に車両Ａｓの走行、居室空間の空調、及び電動走行系の温調等に用いられる。

サブバッテリ２３は、メインバッテリ２２と同様に、電力を充放電可能な二次電池である。サブバッテリ２３は、例えば鉛蓄電池である。サブバッテリ２３のバッテリ容量は、メインバッテリ２２のバッテリ容量よりも少ない。サブバッテリ２３に蓄えられた電力は、主に車両Ａｓの補機類、具体的には、ＤＣＭ９３、キャビン操作システム５１及びコネクトシステム５２等によって使用される。

バッテリマネージャ２０は、給電ドメインＤＥｓのドメインマネージャとして機能する車載コンピュータである。バッテリマネージャ２０は、充電回路２１から各消費ドメインＤＥｃに供給される電力を管理する。バッテリマネージャ２０は、メインバッテリ２２及びサブバッテリ２３についての残量情報を、エネルギマネージャ１００に通知する。尚、バッテリドメインでは、例えばバッテリマネージャ２０等での電力の消費が発生する。故に、バッテリドメインは、消費ドメインＤＥｃに含まれていてもよい。

充電システム６０は、給電ドメインＤＥｓに電力を供給し、メインバッテリ２２の充電を可能にする。充電システム６０には、充電ステーションＣＳ（図１参照）にて、外部の充電器が電気的に接続される。充電システム６０は、充電ケーブルを通じて供給される充電用の電力を、充電回路２１に出力する。普通充電を行う場合、充電システム６０は、普通充電用の充電器から供給される交流電力を直流電力に変換し、充電回路２１に供給する。一方、急速充電を行う場合、充電システム６０は、急速充電用の充電器から供給される直流電力を、充電回路２１に出力する。充電システム６０は、急速充電用の充電器と通信する機能を有しており、充電器の制御回路と連携して、充電回路２１に供給する電圧を制御する。

尚、充電システム６０は、レンジエクステンダーとしての内燃機関と、発電用のモータジェネレータとを備えていてもよい。こうした充電システム６０は、例えば車両Ａｓの走行中等、充電器と接続されていない状態においても、メインバッテリ２２の残量減少に応じて、充電回路２１に充電用の電力を供給できる。

エネルギマネージャ１００は、各消費ドメインＤＥｃによる電力の使用を統合的に管理する。エネルギマネージャ１００は、処理部１１、ＲＡＭ１２、記憶部１３、入出力インターフェース１４、及びこれらを接続するバス等を備えたコンピュータによって実現されている。処理部１１は、ＲＡＭ１２と結合された演算処理のためのハードウェアである。処理部１１は、ＲＡＭ１２へのアクセスにより、後述する各機能部の機能を実現させる種々の処理を実行する。記憶部１３は、不揮発性の記憶媒体を含む構成である。記憶部１３には、処理部１１によって実行される種々のプログラム（エネルギマネージメントプログラム等）が格納されている。

エネルギマネージャ１００は、記憶部１３に記憶されたプログラムを処理部１１によって実行することにより、本開示のエネルギマネージメント方法を実現させる複数の機能部を備える。具体的に、エネルギマネージャ１００は、計画取得提案部７１、余力情報取得部７２、マネージメント実行部７３、及び調停シミュレーション部７４等の機能部を備える。

計画取得提案部７１は、運行マネージャ１１０より送信される運行計画を取得する。運行計画では、目的地、経由地、及び各地点への到着時間等が指定されている。計画取得提案部７１は、取得した運行計画を調停シミュレーション部７４に通知する。

加えて計画取得提案部７１は、調停シミュレーション部７４にて、修正運行計画が生成された場合、当初の運行計画（上述の「基準運行計画」）から修正運行計画への変更を、運行マネージャ１１０に提案する。修正運行計画は、運行マネージャ１１０より取得した基準運行計画に対して、エネルギ消費及び性能劣化の少なくとも一方を抑制できると推定される運行計画である。但し、基準運行計画から修正運行計画への変更を行うと、車両ＡｓのユーザＵ（図１参照）にデメリットを生じさせる場合がある。この場合、計画取得提案部７１は、ユーザＵのデメリットを、トレードオフ条件として調停シミュレーション部７４よりさらに取得し、修正運行計画と共に、運行マネージャ１１０へ向けて送信する。トレードオフ条件は、例えば目的地又は経由地に到着する時刻が基準運行計画よりも所定時間遅れる、目的地及び経由地を巡る順序が基準運行計画に対して入れ替わる、混雑し易いルートを通過する等である。

計画取得提案部７１は、修正運行計画及びトレードオフ条件を運行マネージャ１１０に提案した場合、運行マネージャ１１０による修正運行計画の承認の可否を、さらに取得する。計画取得提案部７１は、修正運行計画についての承認の可否結果を、調停シミュレーション部７４に通知する。

余力情報取得部７２は、給電ドメインＤＥｓのバッテリマネージャ２０に余力情報の提供を要求する。余力情報取得部７２は、バッテリマネージャ２０より、給電ドメインＤＥｓについての余力情報を取得する。余力情報取得部７２は、電力エネルギについてのストック及びフローの各上限値を、余力情報として取得する。

具体的に、余力情報取得部７２は、給電ドメインＤＥｓの各バッテリ２２，２３によって供給可能な残りの電力量を示す値（以下、「残量電力値」）を取得する。残量電力値は、上述のエネルギ利用可能量Ｗ１（図３ Ｓ１１参照）に相当し、例えば「ｋＷｈ」の単位を示す数値により、バッテリマネージャ２０から余力情報取得部７２に通知される。加えて余力情報取得部７２は、給電ドメインＤＥｓが各消費ドメインＤＥｃに出力可能な最大出力を示す値、（以下、「最大出力値」）を取得する。最大出力値は、例えば「ｋＷ」の単位を示す数値によって、バッテリマネージャ２０から余力情報取得部７２に通知される。

マネージメント実行部７３は、調停シミュレーション部７４にて設定された上限値を、各消費ドメインＤＥｃのドメインマネージャに通知する。上限値には、運行計画に基づく走行を通じて消費する電力量の上限値（以下、「消費上限値」）と、運行中に使用する電力の上限値（以下、「使用上限値」）とが含まれている。マネージメント実行部７３は、各消費ドメインＤＥｃについての消費上限値及び使用上限値を、各ドメインマネージャに通知し、これらの上限値を厳守させる。

マネージメント実行部７３は、一旦通知した消費上限値及び使用上限値を修正する要求、即ち、消費上限値又は使用上限値を上げる要求（以下、「再調停要求」）を、各消費ドメインＤＥｃから取得する。マネージメント実行部７３は、要求元となる消費ドメインＤＥｃにて、必要としている電力量及び電力の少なくとも一方の値を、再調停要求に付随する要求情報として、ドメインマネージャから取得する。要求情報として取得される電力量の値は、各ドメインマネージャに通知される消費上限値、及び余力情報取得部７２に取得される残量電力値と実質的に同一の単位（例えば「ｋＷｈ」）で生成された数値情報である。同様に、要求情報として取得される電力の値は、各ドメインマネージャに通知される使用上限値、及び余力情報取得部７２に取得される最大出力値と実質的に同一の単位（例えば「ｋＷ」）で生成された数値情報となる。複数のドメインマネージャによって出力される各要求情報において、電力量の値及び電力の値は、互いに実質的に同一の単位で生成されている。マネージメント実行部７３は、上限緩和の再調停要求を取得する場合、上限緩和が必要となった理由を、ドメインマネージャからさらに取得する。

調停シミュレーション部７４は、複数の消費ドメインＤＥｃそれぞれによる電力消費を、運行計画及び余力情報に基づき調停する。調停シミュレーション部７４は、運行計画に基づく走行で各消費ドメインＤＥｃの消費する電力量の総和が、上述の残量電力値を超えないように、各消費ドメインＤＥｃの消費上限値を個別に設定し、各消費ドメインＤＥｃによる電力の消費を制限する。加えて調停シミュレーション部７４は、各消費ドメインＤＥｃにて使用される電力の総和が最大出力値を超えないように、各消費ドメインＤＥｃの使用上限値を個別に設定し、各消費ドメインＤＥｃによる電力の消費を制限する。

調停シミュレーション部７４は、基準運行計画に基づく走行によって各消費ドメインＤＥｃが消費する基準総電力量を算出する。加えて調停シミュレーション部７４は、基準運行計画に基づく走行によってメインバッテリ２２に引き起こされる性能劣化の程度（以下、「基準性能劣化」）を算出する。調停シミュレーション部７４は、各消費ドメインＤＥｃにて消費される総電力量が基準総電力量よりも少なくなるか、又はメインバッテリ２２に生じる性能劣化が基準性能劣化よりも低減できると推定される修正運行計画の生成を試みる。調停シミュレーション部７４は、修正運行計画が作成できた場合、基準運行計画から修正運行計画への変更に伴い悪化するトレードオフ条件をさらに生成する。調停シミュレーション部７４は、修正運行計画にトレードオフ条件を関連付けて、基準運行計画の提供元である運行マネージャ１１０に通知する。

調停シミュレーション部７４は、マネージメント実行部７３にて取得される消費ドメインＤＥｃからの再調停要求に基づき、各消費ドメインＤＥｃに対し設定した消費上限値及び使用上限値を調整する再調停シミュレーションを実施する。調停シミュレーション部７４は、マネージメント実行部７３にて取得される要求理由の内容に応じて、再調停の実施の要否を判定する。調停シミュレーション部７４は、要求理由の重要度及び緊急度と、メインバッテリ２２の余力情報とに基づき、上限を調整するか否かを決定する。

一例として、走行制御ドメインＤＤｃは、車両Ａｓに緊急回避行動を実施させる場合に、再調停要求としての緊急時要求を出力する。緊急時要求には、使用上限値の一時的な撤廃を求める要求情報が関連付けられている。調停シミュレーション部７４は、緊急時要求がマネージメント実行部７３によって取得されると、緊急回避行動のための運動マネージャ３０の制御が供給電力の制限によって妨げられないように、走行制御ドメインＤＤｃの使用上限値を最大まで引き上げる。以上により、複数の消費ドメインＤＥｃのうちで走行制御ドメインＤＤｃへの給電が優先され、運動マネージャ３０は、緊急回避行動を確実に遂行可能となる。この場合、走行制御ドメインＤＤｃを除く他の消費ドメインＤＥｃの使用上限値は、通常よりも引き下げられる。

次に、エネルギマネージャ１００にて実施される上限設定処理の詳細を、図７に基づき、図５及び図６を参照しつつ、さらに説明する。図７に示す上限設定処理は、新規の運行計画が車両Ａｓ側で受信された場合に開始される。

上限設定処理のＳ１０１では、運行マネージャ１１０によって送信された最新の運行計画を取得し、Ｓ１０２に進む。Ｓ１０２では、最新の余力情報をバッテリマネージャ２０から取得し、Ｓ１０３に進む。Ｓ１０３では、Ｓ１０１にて取得した運行計画と、Ｓ１０２にて取得した余力情報とを用いて、調停シミュレーションを実施し、Ｓ１０４に進む。

Ｓ１０４では、Ｓ１０３での調停シミュレーションにて、エネルギ消費及び性能劣化の少なくとも一方について、Ｓ１０１にて取得した運行計画よりも抑制可能な修正運行計画が生成されたか否かを判定する。Ｓ１０４にて、修正運行計画の生成がないと判定した場合、Ｓ１０８に進む。この場合、車両Ａｓの運行は、運行マネージャ１１０より通知された運行計画に基づいて実施される。一方、Ｓ１０４にて、修正運行計画の生成があると判定した場合、Ｓ１０５に進む。

Ｓ１０５では、Ｓ１０３にて生成された修正運行計画及びそのトレードオフ条件を、運行マネージャ１１０に提案し、Ｓ１０６に進む。Ｓ１０６では、Ｓ１０５にて提案した修正運行計画が運行マネージャ１１０にて承認されたか否かを判定する。一例として、修正運行計画の送信後、所定時間以内に、運行計画の変更を承認する通知を受信した場合、Ｓ１０６では、修正運行計画が承認されたと判定し、Ｓ１０７に進む。Ｓ１０７では、基準運行計画から修正運行計画へと運行計画を差し替えて、Ｓ１０８に進む。

一方、運行計画の変更を否認する通知を受信した場合、又は認否の通知が所定時間以内に受信されなかった場合、Ｓ１０６では、修正運行計画が承認されなかったと判定し、Ｓ１０８に進む。

Ｓ１０８では、基準運行計画及び修正運行計画のうちで、採用対象とされた運行計画に基づき、各消費ドメインＤＥｃについての消費上限値及び使用上限値を設定する。そして、対応するドメインマネージャに各上限値を通知し、一連の上限設定処理を終了する。

次に、各ドメインマネージャ及びエネルギマネージャ１００の連携により実施される上限調停処理の詳細を、図８及び図９に基づき、図５及び図６を参照しつつ、さらに説明する。図８及び図９に示す各上限調停処理は、運行計画に基づく車両運行が実施される期間中、各マネージャにて繰り返し開始される。

図８に示す上限調停処理は、各ドメインマネージャによって実施される。この上限調停処理のＳ１２１では、各消費ドメインＤＥｃに関連する入力情報を参照し、Ｓ１２２に進む。入力情報は、消費ドメインＤＥｃ毎に異なっている。一例として、走行制御ドメインＤＤｃでは、ＡＤコンピュータ９０にて生成される制御コマンドが入力情報となる。走行制御ドメインＤＤｃの入力情報には、緊急回避行動の作動指令も含まれている。さらに、空調制御ドメインでは、居室空間の空調の設定温度等を変更する操作指令が入力情報となる。

Ｓ１２２では、Ｓ１２１の入力情報に応答する制御が、エネルギマネージャ１００によって設定された現在の消費上限値及び使用上限値を超えない範囲で実行可能か否かを判定する。Ｓ１２２にて、各上限内で対応可能であると判定した場合、今回の上限調停処理を終了する。この場合、消費ドメインＤＥｃでは、現在の上限の範囲内で、入力情報に対応する制御が実行される。

一方、Ｓ１２２にて、消費上限値及び使用上限値の少なくとも一方を超える可能性があると判定した場合、Ｓ１２３に進む。Ｓ１２３では、制御に必要な電力量又は電力を要求する要求情報と、上限緩和を要求する要求理由とを生成し、Ｓ１２４に進む。一例として、緊急回避行動の作動指令を受けた運動マネージャ３０は、使用上限値を超える可能性があると判定する。この場合、運動マネージャ３０は、使用上限値を最大限引き上げるように、要求情報を生成する。

Ｓ１２４では、Ｓ１２３にて生成した要求情報及び要求理由を含む再調停要求を、エネルギマネージャ１００に送信し、Ｓ１２５に進む。Ｓ１２５では、Ｓ１２４にて送信した再調停要求がエネルギマネージャ１００にて承認されたか否かを判定する。一例として、再調停要求の送信後、所定時間以内に、上限緩和を承認する通知を取得した場合、Ｓ１２５では、再調停要求が承認されたと判定し、Ｓ１２６に進む。Ｓ１２６では、エネルギマネージャ１００にて承認された内容で、消費上限値及び使用上限値の少なくとも一方を緩和し、今回の上限調停処理を終了する。この場合、消費ドメインＤＥｃでは、緩和された上限の範囲内で、入力情報に対応する制御が実行される。

一方、上限緩和を否認する通知を受信した場合、又は認否の通知が所定時間以内に受信されなかった場合、Ｓ１２５では、再調停要求が承認されなかったと判定し、今回の上限調停処理を終了する。この場合、消費ドメインＤＥｃでは、制限された上限の範囲内で、入力情報に対応する制御が実行される。この場合、走行能力及び空調能力等の不足が生じ得る。

図９に示す上限調停処理は、エネルギマネージャ１００によって実施される。この上限調停処理のＳ１４１では、最新の余力情報をバッテリマネージャ２０から取得し、Ｓ１４２に進む。Ｓ１４２では、ドメインマネージャから送信される再調停要求（図８ Ｓ１２４参照）を取得し、要求情報の示す上限値及び要求理由を把握して、Ｓ１４３に進む。尚、ドメインマネージャからの要求情報の送信がない場合、今回の上限調停処理は終了される。

Ｓ１４３では、Ｓ１４２にて取得した要求情報及び要求理由を参照し、消費上限値及び使用上限値の少なくとも一方について、再調停を実施するか否かを判定する。一例として、緊急回避等の緊急性の高い要求理由が通知されている場合、Ｓ１４３では、再調停が必要と判定する。また別の一例として、余力情報の示す余力が要求された上限に対し十分に余裕がある場合、Ｓ１４３は、再調停を実施（許容）すると判定する。Ｓ１４３にて、再調停を実施すると判定した場合、Ｓ１４４に進む。

Ｓ１４４では、要求理由に基づき、電力供給の優先度を調整したうえで、再調停のシミュレーションを実行し、Ｓ１４５に進む。Ｓ１４５では、Ｓ１４４のシミュレーション結果に基づき、再調停結果に基づき消費上限値及び使用上限値の少なくとも一方を設定する。そして、再調停要求を承認する通知として新たな上限値を要求元のドメインマネージャに送信し、今回の上限調停処理を終了する。

一方、Ｓ１４３にて、再調停を実施しないと判定した場合、Ｓ１４６に進む。Ｓ１４６では、再調停要求を否認する旨の通知を要求元のドメインマネージャに送信し、今回の上限調停処理を終了する。

＜効果のまとめ＞
ここまで説明した本実施形態では、運行計画に基づき、複数の消費ドメインＤＥｃに許容される電力消費が調停される。故に、余力情報の示す給電ドメインＤＥｓの余力は、これからの車両Ａｓの走行行動を見越して、各消費ドメインＤＥｃに割り振られ得る。その結果、運行情報に基づいて走行する車両Ａｓにおいて、給電ドメインＤＥｓの電力を有効に使用することが可能になる。

加えて本実施形態では、基準運行計画に基づく走行によって各消費ドメインＤＥｃにて消費される基準総電力量が算出されたうえで、基準総電力量よりも消費される総電力量を低減できる修正運行計画が生成される。

また本実施形態では、基準運行計画に基づく走行によってメインバッテリ２２に生じる性能劣化が推定されたうえで、メインバッテリ２２の性能劣化を低減できる修正運行計画が生成される。そして、修正運行計画は、基準運行計画の提供元である運行マネージャ１１０に提案される。

これらの修正運行計画は、基準運行計画の提供元である運行マネージャ１１０に提案される。以上のように、エネルギマネージャ１００と運行マネージャ１１０との間で、運行計画についての調停が実施されれば、車両Ａｓは、エネルギ消費及び性能劣化をより低減できる運行計画を採用できる。

さらに本実施形態では、当初運行計画から修正運行計画への変更に伴い悪化するトレードオフ条件が纏められる。そして、トレードオフ条件は、修正運行計画に関連付けて、運行マネージャ１１０に通知される。以上のように、トレードオフ条件が通知されれば、運行マネージャ１１０は、管理下にある多数の車両Ａｓの運行状況を総合的に考慮したうえで、トレードオフ条件が許容できる内容か否かを迅速に判断できる。したがって、運行計画を調停する処理が実施されても、サービス車両ＳＶの運行は、円滑に実施される。

加えて本実施形態では、給電ドメインＤＥｓが供給可能な電力量を示す残量電力値が、余力情報に含まれている。そして、運行計画に基づく走行により各消費ドメインＤＥｃにて消費される電力量の総和が残量電力値を超えないように、各消費ドメインＤＥｃでの電力消費が制限される。以上によれば、運行計画の示す目的地までの走行を完遂できずに、車両Ａｓが電欠となる事態は、高い確実性をもって回避可能となる。

また本実施形態では、給電ドメインＤＥｓから各消費ドメインＤＥｃに出力可能な最大出力値が、余力情報に含まれている。そして、各消費ドメインＤＥｃにて使用される電力の総和が最大出力値を超えないように、各消費ドメインＤＥｃによる電力の使用が制限される。以上によれば、充電回路２１の出力不足によってドライバビリティの悪化が引き起こされる事態は、回避可能となる。加えて、高負荷での使用に起因して、メインバッテリ２２の性能劣化が急速に進行する事態も、回避可能となる。

さらに本実施形態の各ドメインマネージャは、エネルギマネージャ１００によって割り当てられた消費上限値又は使用上限値の緩和を、エネルギマネージャ１００に対して要求できる。そして、エネルギマネージャ１００は、消費ドメインＤＥｃから取得した要求に基づき、各消費ドメインＤＥｃに対し設定した上限を調整する。以上によれば、エネルギマネージャ１００と各ドメインマネージャとの調停が継続的に実施される。故に、エネルギマネージャ１００は、走行中の状況変化に対応して、融通の効いた電力量及び電力の再配分を行うことができる。

加えて本実施形態では、各消費ドメインＤＥｃは、消費電力の上限緩和が必要となった要求理由を、エネルギマネージャ１００に対し通知する。そして、エネルギマネージャ１００は、消費ドメインＤＥｃから取得した要求理由の内容に応じて、消費電力の上限の調整を行うか否かを決定する。こうした上限調停処理によれば、エネルギマネージャ１００は、緊急性又は重要性の低いエネルギ消費を抑制しつつ、ユーザＵに有益となるようなエネルギ消費を各消費ドメインＤＥｃに実施させることができる。

また本実施形態の走行制御ドメインＤＤｃは、車両Ａｓに緊急回避行動を実施させる場合において、緊急時要求をエネルギマネージャ１００に出力する。エネルギマネージャ１００は、緊急時要求の取得により、走行制御ドメインＤＤｃへの給電を、他の消費ドメインＤＥｃに対して優先させる。こうした緊急時の上限調停処理によれば、走行制御ドメインＤＤｃは、給電ドメインＤＥｓより供給される電力を使用して、最善の緊急回避行動を実施できる。

さらに本実施形態では、要求情報における各上限値は、余力情報に数値情報として含まれる各上限値と実質的に同一の単位となるように生成されている。以上のように、要求側の情報と、供給側の情報とが、例えば「ｋＷｈ」又は「ｋＷ」等の特定の単位に統一された値であれば、取得情報を処理する演算負荷が軽減される。その結果、エネルギマネージャ１００は、上限の再調停を高速に処理可能となる。

加えて本実施形態では、複数のドメインマネージャから出力される各要求情報においても、緩和後の上限を示す数値情報は、実質的に同一の単位となるように、互いに揃えられている。故に、エネルギマネージャ１００は、複数のドメインマネージャから再調停要求があった場合でも、上限の再調停を高速に処理可能となる。

尚、上記実施形態では、車載コンピュータ１００ａが「コンピュータ」に相当し、車載コンピュータ１００ａ又はエネルギマネージャ１００が「エネルギマネージメント装置」に相当する。また、処理部１１が「プロセッサ」に相当し、計画取得提案部７１が「運行計画取得部」に相当し、調停シミュレーション部７４が「電力調停部」に相当し、運行マネージャ１１０が「（運行計画の）提供元」に相当する。

（他の実施形態）
以上、本開示の一実施形態について説明したが、本開示は、上記実施形態に限定して解釈されるものではなく、本開示の要旨を逸脱しない範囲内において種々の実施形態及び組み合わせに適用することができる。

上記実施形態のエネルギマネージャ１００は、サービス車両ＳＶの車載コンピュータ１００ａによって実現されていた。しかし、エネルギマネージャ１００の機能は、エッジ側の車載コンピュータ１００ａだけでなく、ネットワークＮＷ側又はクラウド側に設けられたコンピュータによって実現されてもよい。

例えば上記実施形態の変形例１では、エネルギマネージャ１００の機能は、車載コンピュータ１００ａ及びサーバ装置１１０ａに分散実装されている。こうした変形例１では、車載コンピュータ１００ａ及びサーバ装置１１０ａが「コンピュータ」及び「エネルギマネージメント装置」に相当し、これらの各処理部１１，１１１が「プロセッサ」に相当する。また上記実施形態の変形例２では、エネルギマネージャ１００の機能は、サーバ装置１１０ａによって実現されている。以上のような変形例２では、サーバ装置１１０ａが「コンピュータ」及び「エネルギマネージメント装置」に相当し、処理部１１１が「プロセッサ」に相当する。

上記実施形態の変形例３では、エネルギマネージャ１００及び運行マネージャ１１０の間における調停処理が実施されない。故に、エネルギマネージャ１００からは、修正運行計画の提案機能が省略されている。また上記実施形態の変形例４のエネルギマネージャ１００は、修正運行計画の提案機能を備える一方で、トレードオフ条件を通知する機能を備えない。

上記実施形態の変形例５では、エネルギマネージャ１００及び各ドメインマネージャの間において、電力の使用上限及び電力量の消費上限のうちの一方のみが調停される。故に、エネルギマネージャ１００は、残量電力値及び最大出力値のうちで、調停対象に対応する一方のみを、余力情報として、バッテリマネージャ２０から取得する。

上記実施形態では、エネルギマネージャ１００及び各ドメインマネージャの間にてやり取りされる情報において、電力及び電力量の各単位は、揃えられていた。しかし、変形例６では、電力及び電力量の各単位は、それぞれ互いに異なっていてもよい。

サービス車両ＳＶは、ユーザＵを搭乗させる居室空間を備えない貨物専用車両であってもよい。また、サービス車両ＳＶは、居室空間とは別に、集配物Ｐ等のみを収容する貨物空間を備える車両であってもよい。さらに、サービス車両ＳＶは、自動運転車でなくてもよく、特定条件下において、運行管理センタＣＴｏに駐在するオペレータによって遠隔操作される半自動運転車であってよい。加えてサービス車両ＳＶは、上述のようなフリート車両ではなく、運行マネージャ１１０に登録された個人所有のＰＯＶ（Personally owned Vehicle）であってもよい。こうしたサービス車両ＳＶでは、運行マネージャ１１０によって送信される運行計画に基づき、ドライバが車両を走行させる。

サービス車両ＳＶのサイズ及び乗車定員等の車両仕様は、適宜変更されてよい。また、異なる仕様のサービス車両ＳＶが、一つの運行マネージャ１１０によって運用されてよい。さらに、サービス車両ＳＶは、メインバッテリ２２の容量や乗車定員を増やすため、例えば八輪車及び六輪車等の大型車両であってよい。

上記実施形態にて、車載コンピュータ１００ａ又はサーバ装置１１０ａ等によって提供されていた各機能は、ソフトウェア及びそれを実行するハードウェア、ソフトウェアのみ、ハードウェアのみ、あるいはそれらの複合的な組合せによっても提供可能である。さらに、こうした機能がハードウェアとしての電子回路によって提供される場合、各機能は、多数の論理回路を含むデジタル回路、又はアナログ回路によっても提供可能である。

上記実施形態の各処理部１１，１１１は、ＣＰＵ（Central Processing Unit）及びＧＰＵ（Graphics Processing Unit）等の演算コアを少なくとも一つ含む構成であってよい。さらに、処理部１１，１１１は、ＦＰＧＡ（Field-Programmable Gate Array）及び他の専用機能を備えたＩＰコア等をさらに含む構成であってよい。

上記実施形態の各記憶部１３，１１３として採用され、本開示の充電マネージメント方法を実現させるプログラムを記憶する記憶媒体の形態は、適宜変更されてよい。例えば記憶媒体は、回路基板上に設けられた構成に限定されず、メモリカード等の形態で提供され、スロット部に挿入されて、コンピュータのバスに電気的に接続される構成であってよい。さらに、記憶媒体は、コンピュータへのプログラムのコピー基となる光学ディスク及びのハードディスクドライブ等であってもよい。

本開示に記載の制御部及びその手法は、コンピュータプログラムにより具体化された一つ乃至は複数の機能を実行するようにプログラムされたプロセッサを構成する専用コンピュータにより、実現されてもよい。あるいは、本開示に記載の装置及びその手法は、専用ハードウェア論理回路により、実現されてもよい。もしくは、本開示に記載の装置及びその手法は、コンピュータプログラムを実行するプロセッサと一つ以上のハードウェア論理回路との組み合わせにより構成された一つ以上の専用コンピュータにより、実現されてもよい。また、コンピュータプログラムは、コンピュータにより実行されるインストラクションとして、コンピュータ読み取り可能な非遷移有形記録媒体に記憶されていてもよい。

Ａｓ 車両、ＤＤｃ 走行制御ドメイン、ＤＥｃ 消費ドメイン、ＤＥｓ 給電ドメイン、１１，１１１ 処理部（プロセッサ）、７１ 計画取得提案部（運行計画取得部）、７２ 余力情報取得部、７４ 調停シミュレーション部（電力調停部）、１００ エネルギマネージャ（エネルギマネージメント装置）、１００ａ 車載コンピュータ（コンピュータ，エネルギマネージメント装置）、１１０ 運行マネージャ（提供元，エネルギマネージメント装置）、１１０ａ サーバ装置（コンピュータ，エネルギマネージメント装置）

Claims (12)

1. コンピュータ（１００ａ，１１０ａ）によって実施され、運行計画に基づいて走行する車両（Ａｓ）にて当該車両に搭載される複数の消費ドメイン（ＤＥｃ）による電力の使用を管理するエネルギマネージメント方法であって、
   少なくとも一つのプロセッサ（１１，１１１）にて実行される処理に、
   前記運行計画を取得し（Ｓ１０１）、
   複数の前記消費ドメインに電力を供給する給電ドメイン（ＤＥｓ）についての余力情報を取得し（Ｓ１０２）、
   複数の前記消費ドメインそれぞれによる電力消費を、前記運行計画及び前記余力情報に基づき調停する（Ｓ１０３）、
   というステップを含むエネルギマネージメント方法。
2. 前記運行計画としての基準運行計画に基づく走行によって各前記消費ドメインが消費する基準総電力量を算出し、
   各前記消費ドメインにて消費される総電力量が前記基準総電力量よりも少なくなる修正運行計画を生成し、
   前記修正運行計画への変更を前記基準運行計画の提供元（１１０）に提案する（Ｓ１０５）、
   というステップを含む請求項１に記載のエネルギマネージメント方法。
3. 前記運行計画としての基準運行計画に基づく走行によって前記車両に生じる性能劣化を推定し、
   前記性能劣化が前記基準運行計画よりも少なくなる修正運行計画を生成し、
   前記修正運行計画への変更を前記基準運行計画の提供元（１１０）に提案する（Ｓ１０５）、
   というステップを含む請求項１に記載のエネルギマネージメント方法。
4. 前記修正運行計画を提案するステップでは、前記基準運行計画から前記修正運行計画への変更に伴い悪化するトレードオフ条件を、前記修正運行計画に関連付けて前記提供元に通知する請求項２又は３に記載のエネルギマネージメント方法。
5. 前記余力情報を取得するステップでは、前記給電ドメインが供給可能な電力量を示す残量電力値を含む前記余力情報を取得し、
   前記電力消費を調停するステップでは、前記運行計画に基づく走行で各前記消費ドメインの消費する電力量の総和が前記残量電力値を超えないように、各前記消費ドメインによる電力の消費を制限する請求項１〜４のいずれか一項に記載のエネルギマネージメント方法。
6. 前記余力情報を取得するステップでは、前記給電ドメインが各前記消費ドメインに出力可能な最大出力値を含む前記余力情報を取得し、
   前記電力消費を調停するステップでは、各前記消費ドメインにて使用される電力の総和が前記最大出力値を超えないように、前記消費ドメインによる電力の使用を制限する請求項１〜５のいずれか一項に記載のエネルギマネージメント方法。
7. 各前記消費ドメインに割り当てられた電力の上限を上げる要求を、前記消費ドメインから取得し（Ｓ１４２）、
   前記消費ドメインからの前記要求に基づき、各前記消費ドメインに対し設定した前記上限を調整する（Ｓ１４４）、というステップをさらに含む請求項１〜６のいずれか一項に記載のエネルギマネージメント方法。
8. 前記要求を取得するステップでは、前記上限の緩和が必要となった理由を前記消費ドメインから取得し、
   前記理由の内容に応じて前記上限の調整を行うか否かを決定する（Ｓ１４３）、というステップをさらに含む請求項７に記載のエネルギマネージメント方法。
9. 複数の前記消費ドメインには、前記車両の走行を制御する走行制御ドメイン（ＤＤｃ）が含まれており、
   前記要求には、前記車両に緊急回避行動を実施させる場合に前記走行制御ドメインが出力する緊急時要求が含まれており、
   前記上限を調整するステップでは、前記緊急時要求が取得された場合に、複数の前記消費ドメインのうちで前記走行制御ドメインへの給電を優先させる請求項７又は８に記載のエネルギマネージメント方法。
10. 前記要求を取得するステップでは、前記消費ドメインが必要とする電力の値を要求情報として取得し、
    前記余力情報には、前記要求情報と実質的に同一の単位で生成された数値情報が含まれている請求項７〜９のいずれか一項に記載のエネルギマネージメント方法。
11. 複数の前記消費ドメインによって出力される各前記要求情報は、互いに実質的に同一の単位で生成される請求項１０に記載のエネルギマネージメント方法。
12. 運行計画に基づいて走行する車両（Ａｓ）において用いられ、前記車両に搭載される複数の消費ドメイン（ＤＥｃ）による電力の使用を管理するエネルギマネージメント装置であって、
    前記運行計画を取得する運行計画取得部（７１）と、
    複数の前記消費ドメインに電力を供給する給電ドメイン（ＤＥｓ）についての余力情報を取得する余力情報取得部（７２）と、
    複数の前記消費ドメインそれぞれによる電力の消費を、前記運行計画及び前記余力情報に基づき調停する電力調停部（７４）と、
    を備えるエネルギマネージメント装置。

Images