WO2020116572A1

WO2020116572A1 - 電動車両の運行管理システム

Info

Publication number: WO2020116572A1
Application number: PCT/JP2019/047654
Authority: WO
Inventors: 頼人中尾; 和教東出; 貴靖鯨井; 正幸小暮
Original assignee: 株式会社エンビジョンＡｅｓｃジャパン
Priority date: 2018-12-06
Filing date: 2019-12-05
Publication date: 2020-06-11
Also published as: JP2022062286A

Abstract

電池ユニットから電力の供給を受ける電動駆動装置で走行する電動車両の運行管理システムは、前記電動車両から前記電池ユニットの状態情報を取得するとともに、前記状態情報に基づく前記電池ユニットの残容量を取得する取得部と、前記電動車両が目的地まで走行するのに必要な第１電池容量を算出する第１電池容量算出部と、前記残容量が前記第１電池容量より少ない電池不足を予測する予測部と、前記予測部が前記電池不足を予測したとき、合流地点で前記電動車両を代替車両と車両交換する指示と、前記合流地点で前記電動車両を電源車両により充電する指示とのうちの少なくとも一方の指示を含む指示情報を生成する指示部とを備える。

Description

電動車両の運行管理システム

　本発明は、電動車両の運行を管理するための運行管理システムに関する。

　特許文献１には、搭載した電池を電源として走行する無人搬送車が電欠した場合、他の無人搬送車から給電されることが記載されている。

日本国特開平１１－２８５１０９号公報

　しかしながら、公共道路を走行する電動車両が電欠した場合、特許文献１の技術を用いて他の電動車両から電欠した電動車両に対して給電を行うことは、長時間の駐車場所を確保する必要性を生じさせ、好ましい解決策ではない。

　本発明の第１の態様によると、電池ユニットから電力の供給を受ける電動駆動装置で走行する電動車両の運行管理システムは、前記電動車両から前記電池ユニットの状態情報を取得するとともに、前記状態情報に基づく前記電池ユニットの残容量を取得する取得部と、前記電動車両が目的地まで走行するのに必要な第１電池容量を算出する第１電池容量算出部と、前記残容量が前記第１電池容量より少ない電池不足を予測する予測部と、前記予測部が前記電池不足を予測したとき、合流地点で前記電動車両を代替車両と車両交換する指示と、前記合流地点で前記電動車両を電源車両により充電する指示とのうちの少なくとも一方の指示を含む指示情報を生成する指示部とを備える。
　本発明の第２の態様によると、第１の態様の電動車両の運行管理システムにおいて、前記電池不足が予測された前記電動車両が前記残容量で走行できる前記合流地点を決定する合流地点決定部をさらに備えるのが好ましい。
　本発明の第３の態様によると、第１の態様の電動車両の運行管理システムにおいて、前記電動車両が前記合流地点に到着する予定時刻、および前記代替車両が前記合流地点に到着するまでに要する予想所要時間に基づいて、前記代替車両の出発予定時刻を算出する時間情報演算部をさらに備えるのが好ましい。
　本発明の第４の態様によると、第３の態様の電動車両の運行管理システムにおいて、前記指示情報は、前記出発予定時刻と、前記代替車両と、前記代替車両の乗務員名とを含むのが好ましい。
　本発明の第５の態様によると、第１から第４までのいずれか１つの態様の電動車両の運行管理システムにおいて、前記合流地点まで前記代替車両が走行するのに必要な第２電池容量を算出する第２電池容量算出部と、前記合流地点から最終地点まで前記代替車両が走行するのに必要な第３電池容量と、前記第２電池容量および前記第３電池容量を加算した第４電池容量とを算出し、前記第４電池容量以上を有する前記代替車両を決定する代替車両決定部とをさらに備えるのが好ましい。
　本発明の第６の態様によると、第１から第５までのいずれか１つの態様の電動車両の運行管理システムにおいて、前記予測部が前記電池不足を予測したとき、前記指示部は、前記合流地点で前記電動車両を救援する救援車両を発進させて前記合流地点に向かわせる救援指示情報を生成するのが好ましい。

　本発明によれば、電動車両が電欠する前に代替車両と合流させて交替可能にしたので、例えば、公共性の高い路線バスとして電動車両を採用した場合には、公共の交通機関に与える影響を低減できる。

図１は、一実施の形態の電動車両の運行管理システムを説明する図である。図２は、図１に示す運行管理システムにより運行管理されるバスに搭載される車載システムを説明する図である。図３は、図２に示す車載システムに含まれる電池ユニットの構成を説明する図である。図４は、図１に示す運行管理システムに含まれる管理センターの装置構成を説明する図である。図５は、図４に示す管理センターのデータベースを構成する運行計画情報テーブルを説明する図である。図６は、図４に示す管理センターのデータベースを構成する電池情報管理テーブルを説明する図である。図７は、電欠時対応テーブルを示す図である。図８は、バス管理テーブルを示す図である。図９は、乗務員管理テーブルを示す図である。図１０は、図１に示す運行管理システムに含まれる車両基地センターを説明する図である。図１１は、図２に示す車載システムに含まれる車両制御装置によって走行駆動されるバスが有する電池ユニットにおける電池制御処理を説明するフローチャートである。図１２は、図２に示す車載システムに含まれる車両制御装置で実行される代替バス管理処理を説明するフローチャートである。図１３（ａ）は、図１に示す運行管理システムに含まれる管理センターで実行される代替車両管理処理を説明するフローチャートであり、図１３（ｂ）は、図１に示す運行管理システムに含まれる車両基地センターで実行される代替バス指示情報処理を説明するフローチャートである。図１４は、路線を運行するバスの電欠を、そのバス自体が予測する場合において、代替バス指示および救援指示を管理センターへ求めるために必要な構成の一例を示す図である。

　以下、図を参照して本発明を実施するための形態について説明する。

（一実施の形態の概略）
　はじめに本発明の一実施の形態の概略を説明する。

　本実施の形態における電動車両は、車載電池ユニットからの電力で電動モータを駆動して走行する路線バス（以下、電動バスあるいは単にバスという）である。電動バスは、複数個の電池パックを交換可能にした電池ユニットを搭載している。電動バスの電池残量が、運行経路途中の停留所から、電池の充電や交換が可能な車両基地センターまで走行するのに必要な電池容量よりも少ない場合、その電動バスは車両基地センターまで運行できない。このように電池容量不足で走行できなくなる現象を電欠と呼ぶ。とくに公共性の高い交通機関で電欠が発生すると、乗客に与える影響が大きい。バス運行会社は、電欠を事前に予測して代替の電動車両（代替バスおよび／または救援車両）を手配して乗客への影響を最小化する。本実施の形態における運行管理システムでは、運行中の電動バスの電欠を運行管理センターが予測したとき、その電動バスに搭載された電池ユニットの残容量で到着可能な停留所を合流地点とし、その運行中の電動バスが合流地点に到着する前に、運行管理センターが代替の電動車両を合流地点の停留所に到着させるように管理する。

　この明細書では、電池パックの電池容量（パック状態情報）および電池ユニットの電池容量（ユニット状態情報）としてＳＯＣ（State of Charge）を用いて説明する。

（電動車両の運行管理システム)
　図１は、本実施の形態の電動車両の運行管理システム１を説明する図である。本実施の形態の電動車両の運行管理システム１は、複数の電動車両を路線バス１０などとして使用するバス運行会社（以下、バス会社と呼ぶ）によって運用され、それら複数の電動車両の運行状態を適切に管理する。電動車両の運行管理システム１は、路線バス（以下、バスと呼ぶ）１０と、バス会社が管理する管理センター２０と、バス会社の車両基地に設置された車両基地センター３０とを有し、これらはネットワーク９６および無線基地局９５で接続されている。バス１０は無線基地局９５、ネットワーク９６を経由して管理センター２０と通信を行う。バス１０は、所定の路線で運行されるバス１０Ａと、バス１０Ａの電欠が予測された場合に、決定された合流地点からバス１０Ａの乗客をバス１０Ａに代わって運ぶ代替バス１０Ｂとを含む。電動車両の運行管理システム１は、電欠が予測されたバス１０Ａを車両基地センター３０に移動させるために合流地点へ派遣される救援車両９を含んでもよい。

　図２は、図１に示す運行管理システム１により運行管理されるバス１０に搭載される車載システム１００を説明する図である。車載システム１００は、バス１０を走行駆動する走行駆動装置１１と、走行駆動装置１１に電力を供給する電池ユニット１２と、統合バッテリマネジメントシステム（以下、統合ＢＭＳという）１３と、切替器１４と、走行駆動装置１１および電池ユニット１２を管理するとともに、車両全体を制御する車両制御装置１５と、車両位置を検出するＧＰＳセンサなどの位置検出装置１６と、無線ネットワークと接続して各種情報を授受するための通信装置１７とを有する。

　図２を参照して車載システム１００を説明する。

（電池ユニット１２）
　電池ユニット１２は、複数の電池パック１２１Ａ，１２１Ｂ，１２１Ｃおよび１２１Ｄ（以下、代表符号を１２１とする）と、複数の電池パック１２１Ａ，１２１Ｂ，１２１Ｃおよび１２１Ｄそれぞれの電池状態を監視して管理する電池パックバッテリマネジメントシステム１２２Ａ，１２２Ｂ，１２２Ｃおよび１２２Ｄ（以下、電池パックＢＭＳと呼び、代表符号１２２で示す）とを含む。

（電池パックＢＭＳ１２２）
　各電池パックＢＭＳ１２２が、対応する各電池パック１２１の電池状態を監視し、管理する。電池パックＢＭＳ１２２は、電池パック１２１内の複数の電池（以下、セルともいう）の電圧、電流、温度などを検出し、それら複数のセルの合計電圧、入出力電流、温度などに基づいて電池パック１２１のＳＯＣを演算する。このＳＯＣは電池パック１２１のＩＤとともに電池パックＢＭＳ１２２によって統合ＢＭＳ１３に出力される。電池パックＢＭＳ１２２は、各セルのＳＯＣを均等化するようなバランシング制御も行う。

　図３は、図２に示す車載システム１００に含まれる電池ユニット１２の構成を説明する図である。図３を参照して電池ユニット１２をさらに説明する。図３（ａ）は、バス１０の背面側から見た電池ユニット１２を示している。複数の電池パック１２１は、電池ユニット１２の筐体１２５内に並置されている。図３（ａ）に示す電池ユニット１２は、一例として、４つの電池パック１２１Ａ，１２１Ｂ，１２１Ｃ，１２１Ｄを有している。図３（ｂ）は、図３（ａ）に示す４つの電池パックのうちの任意の電池パック１２１を、向きを変えずに電池ユニット１２の筐体１２５から取り外した際に観察される、電池パック１２１の正面図を示している。図３（ｃ）は、図３（ｂ）に正面図が表されている電池パック１２１の側面図を示している。各電池パック１２１は、複数のセル１２１０を内蔵し、複数のセル１２１０により、たとえば、定格容量４０ｋＷｈを実現している。本実施の形態では、図３（ａ）に例示される４つの電池パック１２１を含む電池ユニット１２を搭載するバス１０が１つの路線を走行するのに必要な容量を１６０ｋＷｈとする。

　４つの電池パック１２１の各々には識別子（以下、電池パックＩＤと呼ぶ）が割り当てられている。バス会社が保有するすべての電池パック１２１には電池パックＩＤが一意に割り当てられている。したがって、電池パックＩＤにより各電池パック１２１の電池状態を把握することができる。

　図３（ａ）に示すように、電池ユニット１２の筐体１２５内部の上部には電磁式拘束部材１２６が設けられ、下部には端子部１２７が設けられている。図３（ｄ）に示すように、電池パック１２１は、その底面に、正極端子１２３Ｐおよび負極端子１２３Ｎと、電池パックＢＭＳ１２２が監視するセル電圧、セル電流、温度などの各種情報を出力するための通信端子１２３Ｉとから構成される端子１２３を備えている。

　図３（ａ）に示すように、電磁式拘束部材１２６は、駆動制御されていないときは筐体１２５の上方に付勢され、収容部１２８内に位置している。電磁式拘束部材１２６は、駆動制御されると、図示しないソレノイドで付勢力に抗して下方に移動し、電池パック１２１を筐体１２５の下方に押圧する。拘束部材１２６の駆動制御、すなわちソレノイドの駆動制御は、電池ユニット１２に外部接続される装置などにより、統合ＢＭＳ１３を経由して行われる。たとえば、電池パック１２１を交換する交換ツールを電池ユニット１２に接続して、このツールの操作により、統合ＢＭＳ１３は、ソレノイドに印加する電圧を制御して拘束部材１２６を押し下げ、または押し上げる指令を出力する。拘束部材１２６が電磁力で下方に押圧されると、電池パック１２１の下面の正負極端子１２３Ｐ，１２３Ｎおよび通信端子１２３Ｉが、入出力用正負極端子１２７Ｐ、１２７Ｎ、通信端子１２７Ｉと電気的に接続される。入出力用正極端子１２７Ｐと、入出力用負極端子１２７Ｎと、通信端子１２７Ｉとから構成される、図３（ｅ）に示す端子部１２７は、筐体１２５内部の底部に設けられている。端子１２３と端子部１２７とは、いずれか一方が凸形状を有し、他方が凹形状を有する。このような端子嵌合構造を採用することにより、拘束部材１２６が電池パック１２１を筐体１２５の底部に押圧しているときは、電池パック１２１の高さ方向と直交する面内での電池パック１２１の移動やずれを防止できる。電池パック１２１の高さ方向は、端子１２３が設けられた電池パック１２１の下面から、駆動制御された電磁式拘束部材１２６によって押圧される電池パック１２１の上面へ向かう方向である。端子部１２７は、筐体１２５の外部でインバータなどに接続されるハーネスが接続されるように構成されている。

　図３（ｂ）の取っ手１２９は、バス１０の背面から挿入される棒状の電池パック着脱治具が通過する大きさに形成されている。フォークリフトのフォークの先端に電池パック着脱治具を装着して電池パック１２１の交換作業を行うことで、重量がある電池パックを取り扱う際に、作業者の負担を軽減できる。

（切替部１４）
　図２に示す切替器１４は、いずれか一つの電池パック１２１を選択的に走行駆動装置１１に接続するものであり、統合ＢＭＳ１３からの指示により切り替え動作する。切替器１４は、たとえばリレースイッチ群であり、図３に示す電池ユニット１２の筐体１２５の入出力端子１２７Ｐ，１２７Ｎと、走行駆動装置１１との間に設けたリレー接点１４Ａ，１４Ｂ，１４Ｃ，１４Ｄを有する。統合ＢＭＳ１３がリレー接点１４Ａ，１４Ｂ，１４Ｃ，１４Ｄをすべて開放すると、電池ユニット１２がインバータ１１２から遮断される。４つのリレー接点１４Ａ，１４Ｂ，１４Ｃ，１４Ｄのうちいずれか一つのリレー接点が閉成されることで一つの電池パック１２が利用される。電池ユニット１２をインバータ１１１から切り離す場合は、統合ＢＭＳ１３がすべてのリレー接点１４Ａ，１４Ｂ，１４Ｃ，１４Ｄを開成する。

（統合ＢＭＳ１３）
　図２に示す統合ＢＭＳ１３は、図示しないプロセッサおよびメモリを有するコンピュータであって、メモリに格納されたコンピュータプログラムをプロセッサが実行することによって、以下の各種処理を実行する。統合ＢＭＳ１３は、４つの電池パック１２１のそれぞれのＳＯＣをパックＳＯＣとして受信し、これら４つのパックＳＯＣを用いて、電池ユニット１２のユニットＳＯＣを演算する。統合ＢＭＳ１３にも一意に識別子（以下、統合ＩＤと呼ぶ）が割り当てられている。統合ＢＭＳ１３は、統合ＢＭＳ１３が演算した電池ユニット１２のユニットＳＯＣを、電池ユニット１２のＩＤとともに、車両制御装置１５および通信装置１７を介して管理センター２０に送信する。また、統合ＢＭＳ１３は、各電池パック１２１から受信した４つのパックＳＯＣをそれら４つの電池パック１２１のＩＤとともに、車両制御装置１５および通信装置１７を介して管理センター２０に送信する。さらに、統合ＢＭＳ１３は、切替器１４により選択されている電池パックのＩＤを、車両制御装置１５および通信装置１７を介して管理センター２０に送信する。管理センター２０で受信されたこれらの情報は、後述する電池情報管理テーブル２２２（図６参照）に書き込まれる。

　通信装置１７が上述した各種情報を管理センター２０に送信するタイミングは、一例として、バス１０が停留所を通過する時点である。バス１０が所定距離（単位距離）を走行するごとに送信するように設定しても良い。

　統合ＢＭＳ１３は、４つの電池パック１２１Ａ，１２１Ｂ，１２１Ｃ，１２１ＤそれぞれのパックＳＯＣを監視し、使用中の電池パック１２１のパックＳＯＣが所定閾値以下に到達したら、あらかじめ定められている電池パック切替え順番にしたがって、切替器１４に切替信号を送信して電池パック１２１を切替える。たとえば、電池パック１２１Ａ、１２１Ｂ、１２１Ｃ、１２１Ｄの順番に切替えられる。

　このように、複数の電池パック１２１を一つずつバス１０の走行駆動電力に利用し、利用中の電池パック１２１のパックＳＯＣが所定閾値以下になるとあらかじめ定められた順番で他の電池パック１２１に切替えられるので、バス１０の運転手は、バス１０が一つの路線を走行中に、バス１０に搭載されたすべての電池パック１２１にどの程度残容量があるかを把握する必要がない。

　なお、バス１０が一つの路線の運行終了時にどの電池パック１２１が使用されているかを予測し、次の路線の運行開始時には、その予測された電池パック１２１が継続して使用され、あらかじめ定められた順番で電池パック１２１が切り替わる。

　電池パック１２１および電池パックＢＭＳ１２２を含む電池ユニット１２と、切替器１４と、統合ＢＭＳ１３とは、モジュール化された電源装置５０として一つの筐体内に実装されるのが好ましい。モジュール化された電源装置５０は、バス１０に搭載される際の組み立て性がよい。

（走行駆動装置１１）
　図２を参照すると、走行駆動装置１１は、走行用電動モータ１１１と、モータ１１１に必要な電力を供給するインバータ１１２と、車両制御装置１５から受信するインバータ駆動信号に応じてインバータ１１２を駆動するモータコントローラ１１３とを有する。図示しない電流センサはモータ１１１のモータ電流を検出して電流検出信号を出力し、図示しない電圧センサはモータ１１１のモータ印加電圧を検出して電圧検出信号を出力する。モータコントローラ１１３は、これらの電流検出信号と電圧検出信号とを車両制御装置1５および統合ＢＭＳ１３に送信する。これらの検出信号に基づいて車両制御装置１５はモータ１１１を駆動制御する。

　なお、電流検出信号の積分値および／または電圧検出信号などに基づいて電池残量（ＳＯＣ）を演算することができる。

（車両制御装置１５）
　図２に示す車両制御装置１５は、アクセルペダル踏み込み量を検出するセンサ、ブレーキペダル踏み込み量を検出するセンサなど図示しない各種センサから走行に関する各種の情報を受信して、バス１０に必要な走行駆動トルクをトルク指令として算出する。車両制御装置１５は、算出したトルク指令をモータコントローラ１１３に供給する。モータコントローラ１１３は、車両制御装置１５から入力されたトルク指令に応じたインバータ駆動信号を生成して、そのインバータ駆動信号によりインバータ１１２を駆動する。モータ１１１は、バス１０に必要な走行駆動トルクを出力するように、インバータ１１２により駆動される。車両制御装置１５は、モータコントローラ１１３から入力されたモータ電流やモータ印加電圧に基づいて、モータ１１１が出力する実トルクを算出し、トルク指令と実トルクとに差分に基づきインバータ１１２を駆動制御する。

　車両制御装置１５には、位置検出装置１６から、バス１０の時々刻々の位置情報が入力される。位置検出装置１６は、たとえば複数のＧＰＳ衛星から受信した複数の信号に基づいて自車位置を演算し、車両制御装置１５に供給する。車両制御装置１５は、通信装置１７により、内部メモリなどに記憶されているバス１０のバスＩＤとともに自車位置を管理センター２０に送信する。管理センター２０に送信されたこれらの情報は、図６の電池情報管理テーブル２２２に書き込まれる。

（管理センター２０）
　図４を参照して、管理センター２０の構成を説明する。図４は、図１に示す運行管理システム１に含まれる管理センター２０の装置構成を説明する図である。

　管理センター２０は、路線バス１０Ａの運行管理のための各種演算処理を行うサーバ２１と、路線バス１０の運行計画情報、電欠時対応情報、バス管理情報、運転手管理情報などのテーブルで構成されるデータベース２２と、通信インターフェース２３とを備えている。

　サーバ２１は、図示しないプロセッサおよびメモリを有するコンピュータであって、メモリに格納されたコンピュータプログラムをプロセッサが実行することによって、論理的かつ機能的に、ＳＯＣ取得部２１Ａと、第１電池容量算出部２１Ｂと、電欠予測部２１Ｃと、合流地点決定部２１Ｄと、代替車両管理部２１Ｅと、代替バス指示部２１Ｆとを有する。さらに、サーバ２１は、メモリに格納されたコンピュータプログラムをプロセッサが実行することによって、通信インターフェース２０を介した情報の送受信処理と、コマンドレスポンス制御を通じたデータベース２２のデータ書き込み処理およびデータ読み出し処理とを行う。

　ＳＯＣ取得部２１Ａは、バス１０Ａの電池ユニット１２のＳＯＣを統合ＢＭＳ１３から受信する。本実施の形態においては、ＳＯＣ取得部２１Ａが統合ＢＭＳ１３から受信するバス１０Ａの電池ユニット１２のユニットＳＯＣおよび電池ユニット１２を構成する４つの電池パック１２１にそれぞれ対応する４つのパックＳＯＣのうち、主に４つのパックＳＯＣが用いられることとするが、ユニットＳＯＣが用いられることとしてもよい。第１電池容量算出部２１Ｂは、運行しているバス１０Ａの路線の最終地点（電池の充電や交換が可能な車両基地センター３０）にバス１０Ａが到着するまでにバス１０Ａの電池ユニット１２に必要な第１電池容量を算出する。電欠予測部２１Ｃは、受信したバス１０Ａの電池ユニット１２のＳＯＣに基づくバス１０Ａの電池残量と、バス１０Ａが最終地点に到着するまでにバス１０Ａの電池ユニット１２に必要な第１電池容量とに基づき電欠を予測する。電欠予測部２１Ｃは、運行中のバス１０Ａを代替バス１０Ｂに交換するバス交換処理を行うことを決定する。

　合流地点決定部２１Ｄは、電欠が予測された路線バス１０Ａの電池残量でバス１０Ａが到着可能なバス１０Ａの路線上の停留所の中から、車両基地センター３０に駐車している代替バス１０Ｂが到着できる停留所を選択し、選択した停留所を路線バス１０Ａと代替バス１０Ｂとの合流地点として決定する。代替車両管理部２１Ｅは、車両基地センター３０に駐車している複数の代替車両の中から１台の車両を代替バス１０Ｂとして決定するとともに、合流地点に向けて代替バス１０Ｂを車両基地センター３０から出発させることを決定する。代替バス指示部２１Ｆは、非運行中の複数のバスの中から代替バス１０Ｂとして代替車両管理部２１Ｅにより選択されたバスを合流地点に向けて出発させて合流地点でバス１０Ａと合流させることをバス１０Ａおよび車両基地センター３０に通知するための代替バス指示情報を生成する。代替バス指示部２１Ｆは、通信インターフェース２３を介してバス１０Ａと車両基地センター３０に代替バス指示情報を送信する。

（代替車両管理部２１Ｅ）
　図４（ｂ）を参照して代替車両管理部２１Ｅについて説明する。代替車両管理部２１Ｅは、第１時間情報演算部２１１と、第２時間情報演算部２１２と、第３時間情報演算部２１３と、第２電池容量算出部２１４と、代替バス決定部２１５とを有する。

　第１時間情報演算部２１１は、電欠が予測された路線バス１０Ａが合流地点の停留所に到着する予想時刻を演算する。第２時間情報演算部２１２は、車両基地センター３０から合流地点である停留所までの代替バス１０Ｂの所要時間を演算する。第３時間情報演算部２１３は、路線バス１０Ａの合流地点到着時刻から、車両基地センター３０から合流地点までの代替バス１０Ｂの所要時間を差し引いた値である代替バス出発時刻を演算する。第２電池容量算出部２１４は、代替バス１０Ｂが出発地点である車両基地センター３０から合流地点まで走行するのに必要な第２電池容量を算出する。代替バス決定部２１５は、代替バス１０Ｂが合流地点からバス１０Ａの路線を引き継いで運行し、運行終了後、最終地点である車両基地センター３０へ帰車するまでに必要な第３電池容量を算出する。代替バス決定部２１５は、第２電池容量と第３電池容量とを加算して得られる第４電池容量を有する電池ユニット１２を搭載している代替バス１０Ｂを決定する。

（データベース２２）
　図４（ｃ）を参照してデータベース２２を構成するテーブルについて説明する。データベース２２は、管理センター２０が運行管理する複数の路線バス１０Ａの運行計画情報テーブル２２１（図５参照）と、バスＩＤごとの電池情報管理テーブル２２２（図６参照）と、バスＩＤごとの電欠時対応管理テーブル２２３（図７参照）と、バス会社が保有するすべての電動バス１０を管理するためのバスＩＤごとのバス管理テーブル２２４（図８参照）と、バス会社の乗務員（運転手）に関する情報を格納した乗務員管理テーブル２２５（図９参照）とを有する。データベース２２を構成するこれらのテーブルに記録される値は、サーバ２２によって書き込まれ、更新される。

　図４（ａ）に示す通信インターフェース２３は、バス１０との通信、および車両基地センター３０のサーバ３１（図１０参照）との通信を、通信ネットワークを介して行う。運行計画情報テーブル２２１を図５に、電池情報管理テーブル２２２を図６に、電欠時対応管理テーブル２２３を図７に、バス管理テーブル２２４を図８に、乗務員管理テーブル２２５を図９に示す。

（運行計画情報テーブル２２１）
　図５は、図４に示す管理センター２０のデータベース２２を構成する運行計画情報テーブル２２１を説明する図である。図５に示す運行計画情報テーブル２２１には、管理センター２０が管理する複数の路線のバス運行計画に関する種々の情報が入力されている。たとえば、路線Ｒ１に関して、バス１０Ａが出車する車両基地センター３０の車両基地名「ＰＢ駐車場」、出発地となる停留所Ｎｏ．１から終点までの複数の停留所名、バス１０Ａが帰車する車両基地センター３０の車両基地名「ＰＢ駐車場」、運行するバス１０ＡのバスＩＤ「０００１」が入力されている。路線Ｒ１の、出発地となる停留所Ｎｏ．１の名称「Ｐ１１駅」、行先地となる終点の名称「Ｐ１Ｅ駅」、各停留所および車両基地の各地点への到着予定時刻、隣接する地点間の区間走行負荷も運行計画情報テーブル２２１に格納されている。区間走行負荷は、区間内を走行する際に必要な出力ＷＨの統計値である。出力ＷＨを予想消費量ともいう。

　なお、図５は作図上、図５（ａ）と図５（ｂ）とに分割して示しているが、運行計画情報テーブル２２１としては連続している。

　図５では、４つの路線Ｒ１、Ｒ２、Ｒ３、Ｒ４が示され、路線Ｒ１およびＲ３においてはバスＩＤ０００１のバス１０Ａが運行し、路線Ｒ２およびＲ４においてはバスＩＤ０００２のバスが運行する。バスＩＤ０００１のバス１０Ａが路線Ｒ１を運行中の停留所Ｎｏ．５「Ｐ１５駅」に停車した際にバス１０Ａの車両基地名「ＰＢ駐車場」到着前の電欠が予測され、停留所Ｎｏ．７がバス１０Ａと代替バス１０Ｂとの合流地点として決定され、バス１０Ａが停留所Ｎｏ．７に到着する前に代替バス１０Ｂが合流地点に到着するようにする運行管理処理について、下記の事例で説明する。

　図５において、バス１０Ａの車両基地センター３０への帰車前の電欠（以下、帰車前電欠ともいう）が予測された停留所Ｎｏ．５への到着時刻は予定通りの１０時４０分、合流地点の停留所Ｎｏ．７「Ｐ１７小学校前」への到着予定時刻は１１時２０分、終点で乗客降車後にバス１０Ａが向かうはずの最終地点である車両基地センター３０への帰車予定時刻は１２時００分である。この事例では、合流地点でバス１０Ａから代替バス１０Ｂへの乗客の乗り換え時間を１５分とする。したがって、代替バス１０Ｂの最終地点への到着予定時刻は１２時１５分に変更される。また、代替バス１０Ｂが車両基地センター３０を出発してから合流地点へ到着するまでの予想所要時間を２０分とすると、代替バス１０Ｂの車両基地センター３０の出発予定時刻は１１時００分である。この事例における救援運行時間帯は、１１時００分から１２時１５分である。救援運行時間帯については、後述する。

（電池情報管理テーブル２２２）
　図６は、図４に示す管理センター２０のデータベース２２を構成する電池情報管理テーブル２２２を説明する図である。図６に示す電池情報管理テーブル２２２は、特定のバスＩＤに対応する路線バスごとにつぎのような情報を有する。
(1)バスＩＤ
(2)路線
(3)路線を運行するバスに必要な電池容量
(4)路線運行中のバスの位置情報（たとえば直近に到着した停留所の情報）
(5)位置情報に対応する（たとえば直近に到着した停留所における）各電池パックの残容量を示すパックＳＯＣと、各電池パックの残容量値Ｗｈとを含むＳＯＣ情報
(6)運行開始時に使用されていた電池パックＩＤ
(7)運行終了時に使用されていた電池パックＩＤ

　図６に示す電池情報管理テーブル２２２のＳＯＣ情報は、路線バス１０Ａが所定の地点、たとえば停留所を通過するごとに更新する例で示している。しかし、バス１０Ａが時々刻々通過する路線上の任意の地点の各位置情報とその各地点でのＳＯＣとを対応づけて、バス１０Ａが路線の任意の地点を通過するごとに更新しても良い。

（電欠時対応テーブル２２３）
　図７は、電欠時対応テーブル２２３を示す図である。図７に示す電欠時対応管理テーブル２２３は、各バスＩＤに対応付けられる各バス１０ごとにつぎのような情報を有する。
(1)バスＩＤ
(2)路線
(3)路線を運行するバスに必要な電池容量
(4)路線運行中のバスの位置情報（たとえば直近に到着した停留所の情報）
(5)電欠判定結果
(6)合流停留所
(7)代替バスＩＤ
(8)代替バス発進（出発）完了情報
(9)代替バス引継ぎ完了情報
(10)レスキュー完了情報

　図７の電欠時対応管理テーブル２２３の位置情報欄には、管理センター２０で受信されるバス１０Ａの位置を示す情報、たとえは、停留所名が記録される。電欠判定結果欄には、バス１０Ａの車両基地センター３０への帰車前の電欠が予測された事実を示す情報、たとえば電欠フラグが記録される。合流停留所欄には、帰車前電欠が予測されるバス１０Ａが電池残量に応じて走行可能な範囲に位置する停留所名が記録される。代替バスＩＤ欄には、代替バス１０Ｂとして決定されたバスのＩＤが記録される。代替バス発進完了情報欄には、代替バス１０Ｂが車両基地センター３０を出発した事実を示す情報、たとえば発進フラグが記録される。代替バス引継ぎ完了情報欄には、合流地点の停留所でバス１０Ａの乗客が代替バス１０Ｂに乗り換え、代替バス１０Ｂが路線を引き継いで運行を再開した事実を示す情報、たとえば、引継ぎ完了フラグが記録される。

　帰車前電欠が予測されたバス１０Ａを車両基地センター３０に移動させるために、救援車両９が合流地点へ派遣される。救援車両９が充電装置を搭載した電源車両の場合、電欠時対応管理テーブル２２３のレスキュー完了情報欄には、救援車両９により、合流地点でバス１０Ａの電池ユニット１２の電池容量が増量されたことを示す情報、たとえばレスキュー完了フラグが記録される。管理センター２０において、サーバ２１のＳＯＣ取得部２１Ａが、電欠が予測されたバス１０Ａから受信する電池容量に基づき、バス１０Ａの電池容量の増加を判定し、さらにその判定結果に基づいてレスキュー完了フラグをレスキュー完了情報欄に記録する。合流地点へ派遣された救援車両９の作業者が管理センター２０にバス１０Ａの電池容量の増加を通知してもよい。その場合は、管理センター２０のサーバ２１への、バス１０Ａの電池容量の増加に関する入力情報に基づき、サーバ２１のＳＯＣ取得部２１Ａが、レスキュー完了フラグをレスキュー完了情報欄に記録する。レスキュー完了フラグはバス１０Ａの救援作業が完了した事実を示す情報である。

　救援車両９がレッカー車あるいはバス搬送車両である場合、救援車両９が合流地点を発進したことを管理センター２０のサーバ２１が検出して電欠時対応管理テーブル２２３のレスキュー完了情報欄にレスキュー完了フラグを記録してもよい。救援車両９の作業者が管理センター２０のサーバ２１に対して救援車両９が合流地点を発進したことを通知してもよい。

　図７に例示する電欠時対応管理テーブル２２３は、車両基地センター３０への帰車前のバス１０Ａの電欠予測がサーバ２１の電欠予測部２１Ｃによって肯定判定される前に記録されている情報を示している。バス１０Ａの電欠が予測されると、電欠判定結果欄に電欠が予測される旨を示す情報、例えば電欠フラグが電欠予測部２１Ｃによって記録される。電欠フラグが記録されたとき、サーバ２１の合流地点決定部２１Ｄによって合流停留所が決定されると、合流停留所の欄に停留所名が合流地点決定部２１Ｄにより記録される。サーバ２１の代替車両管理部２１Ｅの代替バス決定部２１５によって代替バス１０Ｂが決定されると、代替バスＩＤの欄に決定された代替バス１０ＢのＩＤが代替バス決定部２１５により記録される。さらに、代替バス１０Ｂは、救援運行計画に従って車両基地センター３０を出発すると、発進したことを管理センター２０に通知するための情報を、代替バス１０Ｂの車両制御装置１５が通信装置１７を介して管理センター２０のサーバ２１へ送信する。代替バス発進完了欄には、車両基地センター３０で代替バス１０Ｂが発進したことを示す情報、例えば発進フラグがサーバ２１によって記録される。代替バス１０Ｂが、車両基地センター３０への帰車前の電欠が予測されたバス１０Ａと交代して路線のバス運行を引き継いだとき、代替バス１０Ｂの運転手は、管理センター２０に引継ぎが完了した事実を通知するための引継ぎ完了情報を、不図示の操作端末を介して代替バス１０Ｂの車両制御装置１５へ入力し、その入力された引継ぎ完了情報を、代替バス１０Ｂの車両制御装置１５が通信装置１７を介して管理センター２０のサーバ２１へ送信する。代替バス引継ぎ完了欄には、路線のバス運行の引継ぎの事実を示す情報、例えば引継ぎフラグがサーバ２１によって記録される。

　なお、引継ぎ完了とは、代替バス１０Ｂが路線の運行を再開したことであり、代替バス１０Ｂが合流停留所を発進したことを管理センター２０のサーバ２１が検出して、電欠時対応管理テーブル２２３の代替バス引継ぎ完了欄に引継ぎ完了フラグを記録してもよい。

　合流地点で救援車両９によるバス１０Ａの救援作業が終了すると、レスキュー完了情報欄にレスキュー完了フラグが管理センター２０のサーバ２１によって記録される。

　合流地点での救援車両９による救援作業が終了したことをもってレスキュー完了としたが、救援車両９が車庫へ帰車した事実を検出したことをレスキュー完了と定義してもよい。この場合、救援車両９の運転手は車庫へ帰車した事実を通知するためのレスキュー完了情報を、不図示の情報通信端末を介して管理センター２０のサーバ２１へ送信し、このレスキュー完了情報を受けた管理センター２０のサーバ２１が、レスキュー完了情報欄にレスキュー完了フラグを記録する。あるいは、車両基地センター３０への帰車前の電欠が予測されてからの救援作業によってバス１０Ａが車両基地センター３０まで移動したことをレスキュー完了と定義してもよい。

　あるいは、車両基地センター３０への帰車前の電欠が予測されてからの救援作業によって車両基地センター３０に到着したバス１０Ａの電池ユニット１２を構成する電池パック１２１に対し、次の運行計画に記録された路線の走行に必要な容量を充電またはパック交換をした事実をレスキュー完了と定義してもよい。

（バス管理テーブル２２４）
　図８は、バス管理テーブル２２４を示す図である。図８に示すように、代替バス１０Ｂを決定するために、管理センター２０のデータベース２２には、車両基地センター３０で管理している複数の電動バス１０のバス管理テーブル２２４が設けられている。

　図８に示すバス管理テーブル２２４は、バス会社が保有するすべてのバス１０のバスＩＤごとに次のような情報を有する。
(1)バスＩＤ
(2)バスの運行中、または非運行中（次の運行待ち）を示す運行状況
(3)バスの位置情報
(4)電池ユニットのＳＯＣ情報（各電池パックの電池容量）
(5)代替車両情報
(6)バスごとの次の運行開始予定時刻
(7)バスごとの運行終了予定時刻

　バス管理テーブル２２４の運行状況欄には、バス１０が運行中であること、または運行中ではないことを示す情報、例えば運行中フラグまたは非運行中フラグが記録される。位置情報欄には、バス１０の現在位置を示す情報が定期的に更新されて記録される。ＳＯＣ情報欄には、電池パック１２１のＳＯＣ情報が記録される。代替車両情報欄には、バス１０が代替バス１０Ｂとして決定されている場合にそれを示す代替車両の情報、たとえば代替バスフラグが記録される。図８に示される例では、バスＩＤ０００３に対応するバスが代替バス１０Ｂとして決定されたことが表されている。運行開始予定時刻欄については、バス１０が運行中の場合は値がクリアされるかまたは不定値が記録され、バス１０が非運行中の場合は次の運行開始予定時刻の値が記録される。運行終了予定時刻欄については、バス１０が運行中の場合は現在の運行が終了する時刻の予定値が記録され、バス１０が非運行中の場合は次の運行開始後の運行終了予定時刻の値が記録される。運行開始予定時刻と運行終了予定時刻との間がバス１０の運行時間帯を示す。

（乗務員管理テーブル２２５）
　図９は、乗務員管理テーブル２２５を示す図である。図９に示す乗務員管理テーブル２２５は、バス会社の乗務員の勤怠管理のテーブルであり、図では、運転手のＩＤごとに次の情報を有するものとして示している。
(1)運転手（乗務員）に割り当てられた乗務員ＩＤ
(2)現在の状況（運転手の業務スケジュール情報）
(3)運転手が運転するバスのバスＩＤ
(4)運転手が運転するバスの出車予定時刻
(5)運転手が運転するバスの帰車予定時刻
(6)代替バス運転手指名情報
(7)救援車両運転手指名情報

　乗務員管理テーブル２２５の乗務員ＩＤ欄には、運転手（乗務員）に割り当てられた乗務員ＩＤが記録される。現在の状況欄には、その運転手がバス１０Ａを運転中であるか待機中であるかの情報が記録される。出車予定時刻欄および帰車予定時刻欄には、サーバ２１が運行計画情報テーブル２２１を参照して、その運転手が運転するバス１０Ａの運行開始時刻および運行終了時刻がそれぞれ記録される。代替バス運転手指名情報欄には、その運転手を代替バス１０Ｂの運転手として指名することが可能であるか否かを示す情報、たとえば、「可」または「不可」という情報が記録される。救援車両運転手指名情報欄には、その運転手を救援車両９の運転手として指名することが可能であるか否かを示す情報、たとえば、「可」または「不可」という情報が記録される。ただし、代替バス運転手指名情報欄および救援車両運転手指名情報欄に記載される情報は、サーバ２１によって得られたら直ちに代替バスおよび救援車両の派遣に利用されるため、乗務員管理テーブル２２５に必須の情報ではない。

　上述したように、この実施の形態での事例の救援運行時間帯は、１１時００分から１２時１５分である。現在時刻は、図５に示されるバスＩＤ０００１に対応する運行中のバス１０Ａの車両基地センター３０への帰車前の電欠が予測された停留所Ｎｏ．５への到着時刻１０時４０分であるものとする。サーバ２１が、図９に示す乗務員管理テーブル２２５を参照して、運行中に電欠が予測されたバス１０Ａと合流地点で合流する代替バス１０Ｂおよび救援車両９の運転手を指名する処理について、以下に説明する。

　図９に示す乗務員管理テーブル２２５によると、乗務員ＩＤ１００１の運転手は、現在、待機中である。乗務員ＩＤ１００１の運転手は、バスＩＤ０００４のバスに乗務する計画であり、出車予定時刻は１１時５０分、帰車予定時刻は１５時１０分である。したがって、出車予定時刻が救援運行時間帯に含まれ、乗務員ＩＤ１００１の運転手は救援運行業務に就くことができないので、代替バス運転手指名情報欄と救援車両運転手指名情報欄とにはいずれも「不可」と記録されている。

　乗務員ＩＤ１００２の運転手は、現在、待機中であるが、１２時００分に運行が開始されるバスＩＤ０００５のバスに乗務予定である。したがって、出車予定時刻が救援運行時間帯に含まれ、乗務員ＩＤ１００２の運転手は救援運行業務に就くことができないので、代替バス運転手指名情報欄と救援車両運転手指名情報欄とにはいずれも「不可」と記録されている。

　乗務員ＩＤ１００３の運転手は、現在、すでに路線運行のためにバスＩＤ０００６のバスを運転している。運行終了時刻である帰車予定時刻は１０時５０分である。したがって、乗務員ＩＤ１００３の運転手は救援運行時間帯には乗務していない。乗務員ＩＤ１００３の運転手を代替バス１０Ｂの運転手としても救援車両９の運転手としても指名することができるので、代替バス運転手指名情報欄と救援車両運転手指名情報欄とにはいずれも「可」と記録されている。

　乗務員ＩＤ１００４の運転手は、現在、待機中であり、１５時００分に運行が開始されるバスＩＤ０００８のバスに乗務予定である。したがって、出車予定時刻が救援運行時間帯よりも後であり、乗務員ＩＤ１００４の運転手は代替バス１０Ｂの運転手としても救援車両９の運転手としても指名することができるので、代替バス運転手指名情報欄と救援車両運転手指名情報欄とにはいずれも「可」と記録されている。

　図９に示す例では、代替バス１０Ｂと救援車両９とに乗務可能な運転手は乗務員ＩＤ１００３の乗務員および乗務員ＩＤ１００４の乗務員である。したがって、図５に示されるバスＩＤ０００１に対応するバス１０Ａの車両基地センター３０への帰車前の電欠が予測されたとき、乗務員ＩＤ１００３の乗務員および乗務員ＩＤ１００４の乗務員のうちのいずれか一方の乗務員が代替バス１０Ｂの運転手として指名され、他方の乗務員が救援車両９の運転手として指名される。これらの運転手が指名されると、図９に示す乗務員管理テーブル２２５の乗務員ＩＤ１００３および乗務員ＩＤ１００４のレコードは、それぞれ代替バス１０Ｂおよび救援車両９の乗務を表す情報に更新される。

　すなわち、運行中のバス１０Ａの電欠が予測されたとき、管理センター２０のサーバ２１は、バス１０Ａを救援するための救援運行時間帯に他の乗務予定がない運転手を、代替バス１０Ｂや救援車両９の運転手として指名することができる。

（車両基地センター３０）
　図１０を参照して、車両基地センター３０の構成を説明する。

　図１０は、図１に示す運行管理システム１に含まれる車両基地センター３０を説明する図である。車両基地センター３０は、サーバ３１と、表示装置３２と、通信インターフェース３３とを有している。サーバ３１は、図示しないプロセッサおよびメモリを有するコンピュータであって、メモリに格納されたコンピュータプログラムをプロセッサが実行することによって、管理センター２０から送信された代替バス指示情報などを受信し、代替バスの出発管理、引継管理に関する処理を実行する。表示装置３２は、サーバ３１から送信された代替バス指示情報を可視化する。通信インターフェース３３は、バス１０と管理センター２０とのいずれとも、図１に示す無線基地局９５およびネットワーク９６を含む通信ネットワークを介して通信を行う。表示装置３２は、バス１０および救援車両９の出車、帰車、保守整備などを行う車両基地センター３０内の、たとえばバス営業所に設置される。作業者は、表示装置３２に表示された代替バス指示情報にしたがい、代替バス１０Ｂおよび／または救援車両９の出発管理、引継管理などを行う。サーバ２１は、メモリに格納されたコンピュータプログラムをプロセッサが実行することによって、通信インターフェース３３を介した情報の送受信処理と、表示装置３２へのメッセージ表示処理とを行う。

　代替バス指示情報に基づき、一例として、「路線Ｒ１を運行中のバスに電欠の発生が予測されました。バスＩＤ０００３のバスを代替バスとして停留所Ｎｏ．７の「Ｐ１７小学校」へ救援に向かわせて下さい。代替バスの出発時刻は１１時００分、運転手は乗務員ＩＤ１００４の乗務員です。」というメッセージが、表示装置３２に表示される。

（代替車両管理処理）
　図４の管理センター２０のサーバ２１は、運行計画情報テーブル２２１と電池情報管理テーブル２２２とを参照して、路線バス１０Ａの電欠を予測する。サーバ２１は、バス１０Ａの電欠を予測すると、運行計画情報テーブル２２１、電欠時対応管理テーブル２２３、バス管理テーブル２２４、および乗務員管理テーブル２２５を参照して、代替バス１０Ｂおよび／または救援車両９を車両基地センター３０から出発させるよう、車両基地センター３０のサーバ３１へ指示する。

　以下、バスＩＤ０００１のバス１０Ａが路線Ｒ１を運行中にバス１０Ａの電欠が予測された一例を説明する。たとえば、図５を参照して、停留所Ｎｏ．５のＰ１５駅を通過したときのバス１０Ａの電池ユニット１２の電池残量が、バス１０ＡがＰ１５駅を通過してから最終地点である車両基地センター３０に到着するまでに必要とされる電池容量よりも少ない場合について、詳細に説明する。

（電欠予測処理）
　図４に示す管理センター２０のサーバ２１のＳＯＣ取得部２１Ａは、バス１０Ａが各停留所を通過した際にバス１０Ａから受信するバス１０Ａの電池ユニット１２のユニットＳＯＣと各電池パック１２１のパックＳＯＣとに基づき、各停留所でのバス１０Ａの電池残量を演算する。図５に示す運行計画情報テーブル２２１には、停留所間の予想消費量として、たとえば区間走行負荷の統計値が記録されているので、図４に示すサーバ２１の第１電池容量算出部２１Ｂは、それらの予想消費量を加算すれば、バス１０Ａが各停留所から最終地点の車両基地センター３０まで走行するのに必要な第１電池容量を算出できる。バス１０Ａが各停留所を通過するたびに、ＳＯＣ取得部２１Ａによって演算されたバス１０Ａの電池ユニット１２の電池残量と、第１電池容量算出部２１Ｂによって算出された、バス１０Ａが各停留所から車両基地センター３０まで走行するのに必要な第１電池容量とを、図４に示すサーバ２１の電欠予測部２１Ｃが比較する。電池ユニット１２の電池残量が第１電池容量よりも少ないとき、管理センター２０のサーバ２１の電欠予測部２１Ｃは、バス１０Ａの車両基地センター３０への帰車前の電欠を予測する。

（代替バス管理処理）
　図４に示す管理センター２０のサーバ２１の電欠予測部２１Ｃは、バス１０Ａの電欠を予測すると、代替バス１０Ｂをバス１０Ａとの合流地点に向けて出発させてバス交換処理を行うことを決定し、以降、バス交換のための処理が行われる。まず、管理センター２０のサーバ２１の合流地点決定部２１Ｄは、電欠予測部２１Ｃによって帰車前の電欠が予測された停留所におけるバス１０Ａの電池ユニット１２の電池残量に基づき、その電池残量でバス１０Ａが走行可能な路線Ｒ１上の複数の停留所を合流地点候補として抽出する。合流地点決定部２１Ｄは、バス１０Ａの合流地点への到着予定時刻と代替バス１０Ｂが合流地点に到着するまでの予想時間とに基づき、抽出された複数の停留所のうちのいずれかの停留所を合流地点として決定する。本実施の形態では、合流地点として、図５に示す路線Ｒ１における停留所Ｎｏ．５「Ｐ１５駅」の２つ先の停留所Ｎｏ．７「Ｐ１７小学校前」が選択されるとする。

　図５に示す運行計画情報テーブル２２１を参照すると、路線Ｒ１を走行するバス１０Ａは、停留所Ｎｏ．７「Ｐ１７小学校前」に１１時２０分に到着する予定である。管理センター２０のサーバ２１の代替車両管理部２１Ｅに含まれる第２電池容量算出部２１４は、バス管理テーブル２２４を参照して、代替バス１０Ｂが車両基地センター３０からＰ１７小学校まで走行するのに必要な第２電池容量を算出する。サーバ２１の代替バス決定部２１５は、その算出された第２電池容量と、代替バス１０ＢがＰ１７小学校から車両基地センター３０まで走行するのに必要な第３電池容量とを加算して得た第４電池容量を、代替バス１０Ｂが必要とする電池容量として決定する。代替車両管理部２１Ｅに含まれる代替バス決定部２１５は、計算により得られた第４電池容量以上の電池容量である電池ユニット１２を有し、かつ、車両基地センター３０で待機しているバスを代替バス１０Ｂの候補とし、その候補の中から代替バス１０Ｂを決定する。このように代替バス決定処理は、図４に示した代替バス決定部２１５によって演算される。すなわち、代替バス決定部２１５は、合流地点から最終地点まで代替バス１０Ｂが走行するのに必要な第３電池容量を算出し、第２電池容量算出部２１４により算出された出発地点から合流地点まで代替バス１０Ｂが走行するのに必要な第２電池容量と第３電池容量とを加算した第４電池容量を算出し、複数の電動バスの中から第４電池容量以上を有する代替バス１０Ｂを決定する。代替バス決定部２１５は、実際には、運行計画情報テーブル２２１も参照して、代替バス１０Ｂが車両基地センター３０を出発してＰ１７小学校に向かい、Ｐ１７小学校から路線Ｒ１の運行を開始し、運行終了後に最終地点である車両基地センター３０に帰車する予定時刻を算出し、代替バス１０Ｂとして使用されるバスに計画されている本来の運行を開始する予定時刻よりも十分に余裕が確保されるように、代替バス１０Ｂを選択することが好ましい。

　また、代替バス１０Ｂを運転する乗務員を特定する必要もある。代替バス決定部２１５は、乗務員管理テーブル２２５を参照して、代替バス１０Ｂによるバス１０Ａの救援運行が行われる救援運行時間帯に本来の乗務予定がない運転手を検索して特定する。救援運行時間帯とは、上述したように、代替バス１０Ｂが車両基地センター３０を出発してから救援運行を行って車両基地センター３０へ帰車するまでの時間帯である。

　代替バス１０ＢをＰ１７小学校に向けて出発させるための代替バス指示情報は、サーバ２１の代替バス指示部２１Ｆによって生成されると、通信インターフェース２３およびネットワーク９６を介して車両基地センター３０のサーバ３１へ送信され、サーバ３１によって表示装置３２に表示される。代替バス指示情報には、代替バス１０Ｂとして使用されるバスのバスＩＤ、乗務員名、代替バス１０Ｂによる救援運行計画などが含まれる。救援運行計画とは、車両基地センター３０への帰車前の電欠が予測されたバス１０Ａの乗客を代替バス１０Ｂに乗せ替え、バス１０Ａの路線運行を代替バス１０Ｂによって継続するために編成される、代替バス１０Ｂによる臨時的な運行計画である。

　なお、代替バス１０Ｂによる救援運行が発生した事実を、車両基地センター３０内に音声で報知することによって、確実に代替バス１０Ｂを救援運行のために出発させるのが好ましい。

　代替バス１０Ｂの運転手が携帯する端末機器に、「バスＩＤ００１１のバスを代替バスとしてＰ１７小学校に救援に向かわせます。あなたはそのバスに乗務して下さい。代替バスの出発予定時刻は１１時００分です。確認したら返信して下さい。」といった指令を、たとえば車両基地センター３０のサーバ３１が送信するとさらに確実である。

（救援車両による救援）
　以上説明した代替車両管理処理によって代替バス１０Ｂが決定されたとしても、車両基地センター３０への帰車前の電欠が予測されるバス１０Ａは車両基地センター３０まで自走できない。そこで、この実施の形態では、代替バス１０Ｂとは別に救援車両９をＰ１７小学校に向かわせる必要がある。救援車両９は、電欠が予測されたバス１０Ａを充電する充電装置を搭載した電源車両、電欠が予測されたバス１０Ａが車両基地センター３０まで走行できる電池容量を有する電池ユニット１２を得るために、ひとつ、または複数の電池パック１２１を交換する交換用電池運搬車両、あるいは、バス１０Ａを牽引するレッカー車である。

　たとえば、図４のサーバ２１において、電欠予測部２１Ｃは、バス１０Ａの電欠を予測したとき、合流地点で電欠が予測されたバス１０Ａを救援する救援処理を行うことを決定し、代替車両管理部２１Ｅは、その救援処理を行う救援車両９を決定する。その救援車両９を発進させてバス１０Ａと代替バス１０Ｂとの合流地点に向かわせることを図１０のサーバ３１へ指示するための救援指示情報を、代替バス指示部２１Ｆが生成して出力する。

　救援車両９が上述した電源車両の場合は、救援処理はバス１０Ａの電池ユニット１２を充電する充電処理である。代替バス指示部２１Ｆによる救援指示情報の出力に応じて車両基地センター３０を出発した電源車両によって、合流地点でバス１０Ａに対する充電処理が行われると、バス１０Ａは再び運行に復帰できる。したがって、この場合においては、必ずしも代替バス指示部２１Ｆによって代替バス指示情報が出力されることを要しないが、充電時間を考慮して、代替バス指示部２１Ｆにより救援指示情報に加えて代替バス指示情報が出力されることとしてもよい。

　救援車両９が上述した交換用電池運搬車両の場合は、救援処理はバス１０Ａの電池ユニット１２の電池パック１２１を交換する電池交換処理である。代替バス指示部２１Ｆによる救援指示情報の出力に応じて車両基地センター３０を出発した交換用電池運搬車両によって、合流地点でバス１０Ａに対する電池交換処理が行われると、バス１０Ａは再び運行に復帰できる。したがって、この場合においては、必ずしも代替バス指示部２１Ｆによって代替バス指示情報が出力されることを要しない。

　救援車両９が上述したレッカー車の場合は、救援処理はバス１０Ａを牽引する牽引処理である。バス１０Ａに対するレッカー車の牽引処理によって、バス１０Ａは車両基地センター３０へ帰車することができる。なお、バス１０Ａに対するレッカー車の牽引処理は、必ずしも合流地点決定部２１Ｄによって決定された合流地点と同一地点で開始されることを要しない。合流地点でバス１０Ａの乗客が代替バス１０Ｂへ乗り換えた後、バス１０Ａが電池残量の範囲で他の地点（たとえば路線から外れた私有地）まで移動し、その地点からバス１０Ａに対するレッカー車の牽引処理が開始されてもよい。

　代替バスは決定されたが運転手を確保できない場合にも、同様に救援車両９を救援に向わせることとしてもよい。このとき、電欠が予測されたたバス１０Ａに乗車していた乗客を、同じ路線を運行している後続のバスに乗車させることが、代替バス指示部２１Ｆによって車両基地センター３０のサーバ３１へ指示され、その指示がサーバ３１によってバス１０Ａの運転手へ報知される。

　図１１は、図２に示す車載システム１００に含まれる車両制御装置１５によって走行駆動されるバス１０Ａが有する電池ユニット１２における電池制御処理を説明するフローチャートである。図１１（ａ），図１１（ｂ）および図１１（ｃ)を参照して、走行駆動に関する車両制御装置１５の処理手順、統合ＢＭＳ１３の処理手順、電池パックＢＭＳ１２２の処理手順を説明する。

（車両制御装置１５の手順）
　図１１（ａ）は、たとえば１００ｍｓ間隔で実行される車両制御装置１５のプログラム処理手順を説明する図である。車両制御装置１５は、図示しないプロセッサおよびメモリを有するコンピュータであって、メモリに格納されたコンピュータプログラムをプロセッサが実行することによって、図１１（ａ）に示すプログラム処理手順が実行される。

　車両制御装置１５は、ステップＳ１１において、イグニッションスイッチ(IGN SW)情報、アクセルペダルやブレーキペダルの踏み込み量などの各種センサ情報などを読み込む。ステップＳ１２において、各種センサ情報などに基づきバス１０Ａの走行駆動のための必要トルクを算出する。ステップＳ１３において、必要トルクに基づくインバータ駆動信号をインバータ１１２に出力する。これにより走行用電動モータ１１１が必要トルクでバス１０Ａを走行駆動する。

（統合ＢＭＳ１３の手順）
　図１１（ｂ）は、たとえば１００ｍｓ間隔で実行される統合ＢＭＳ１３のプログラム処理手順を説明する図である。統合ＢＭＳ１３は、図示しないプロセッサおよびメモリを有するコンピュータであって、メモリに格納されたコンピュータプログラムをプロセッサが実行することによって、図１１（ｂ）に示すプログラム処理手順が実行される。

　統合ＢＭＳ１３は、ステップＳ２１において、あらかじめ設定された電池パック１２１の使用順番（設置位置）に基づき電池パック切替順番を取得する。統合ＢＭＳ１３は、ステップＳ２２において、決定された電池パック切替順番に基づいて切替器１４に切替信号を出力することによりリレー接点の開閉制御を行って電池パック１２１を切替え、使用することが予定されている電池パック１２１を選択する。ステップＳ２１において使用中の電池パック１２１のＳＯＣが所定閾値以下に達したことが検出されると、統合ＢＭＳ１３は、ステップＳ２２において、電池パック切替順番で次に使用される順番が設定されている電池パック１２１を選択するための切替信号を切替器１４に出力する。これにより、現在使用中の電池パック１２１から次の電池パック１２１に切替わる。

　なお、ＳＯＣに代えて、使用中の電池パックの電圧が所定閾値以下に達したことが検出されると次の電池パックに切替わることとしてもよい。

（電池パックＢＭＳ１２２の手順）
　図１１（ｃ）は、たとえば１０ｍｓ間隔で実行される各電池パック１２１に対応して実装された電池パックＢＭＳ１２２のプログラム処理手順を説明する図である。電池パックＢＭＳ１２２は、図示しないプロセッサおよびメモリを有するコンピュータであって、メモリに格納されたコンピュータプログラムをプロセッサが実行することによって、図１１（ｃ）に示すプログラム処理手順が実行される。

　電池パックＢＭＳ１２２は、ステップＳ３１において、電池パック１２１の状態を自己診断する。ステップＳ３２において、電池パック１２１の複数のセルの電圧や温度などの各種センサの検出値を読み込む。ステップＳ３３において、読み込んだセンサ検出値に基づいて電池パック１２１のＳＯＣを算出する。ステップＳ３４において、算出して得られたＳＯＣにその電池パック１２１の電池パックＩＤを付してパックＳＯＣデータを生成し、ＳＯＣデータを統合ＢＭＳ１３に送信する。

　図１２（ａ）、図１２（ｂ）と図１３（ａ）、図１３（ｂ）および図（ｃ）とを参照して、バス１０Ａの電欠が予測された際の車両制御装置１５の処理手順、管理センター２０のサーバ２１の処理手順、車両基地センター３０のサーバ３１の処理手順を説明する。

　図１２は、図２に示す車載システム１００に含まれる車両制御装置１５で実行される代替バス管理処理を説明するフローチャートである。車両制御装置１５においては、メモリに格納されたコンピュータプログラムをプロセッサが実行することによって、図１２に示すプログラム処理手順が実行される。図１２（ａ）は、たとえば１００ｍｓ間隔で実行される車両制御装置１５の処理手順を説明する図である。

　車両制御装置１５は、ステップＳ５１において、内部メモリなどからバス１０ＡのバスＩＤを読み込むとともに、統合ＢＭＳ１３から電池状態情報を読み込む。電池状態情報は、パックＳＯＣとユニットＳＯＣとを含む。ステップＳ５２において、位置検出装置１６によって算出されるバス１０の位置情報を読み込むことにより、バス１０Ａの現在位置を検出する。ステップＳ５３において、バス１０ＡのバスＩＤ、位置情報、および電池状態情報を管理センター２０に向けて通信装置１７を介して送信する。

　図１２（ｂ）は、たとえば１０ｍｓ間隔で実行される車両制御装置１５の処理手順を説明する図である。

　車両制御装置１５は、ステップＳ５４において、管理センター２０から送信されてくる下記（１），（２），（３）および（４）の情報を受信して内部メモリなどの所定の記憶領域に記憶する。
（１）バス１０Ａの電欠予測に起因する合流停留所情報
（２）合流停留所への代替バス１０Ｂの到着予想時刻
（３）合流停留所への救援車両９の到着予想時刻
（４）確認ボタン操作指示の情報

　車両制御装置１５は、ステップＳ５５において、受信した確認ボタンの画面上での、バス１０Ａの乗務員によるオン操作を検出すると、ステップＳ５６において、バス１０ＡのバスＩＤとともに、バス１０Ａの乗務員が了解したことを表す確認信号を管理センター２０に送信する。

　図１３（ａ）は、図１に示す運行管理システム１に含まれる管理センター２０で実行される代替車両管理処理を説明するフローチャートであり、たとえば１０ｍｓ間隔で実行される管理センター２０のサーバ２１の処理手順を説明する図である。サーバ２１においては、メモリに格納されたコンピュータプログラムをプロセッサが実行することによって、図１３（ａ）に示すプログラム処理手順が実行される。

　サーバ２１は、ステップＳ６１において、運行計画情報テーブル２２１から運行計画情報を読み込むとともに、電池情報管理テーブル２２２から電池状態情報を読み込む。電池状態情報は、パックＳＯＣとユニットＳＯＣとを含む。サーバ２１は、ステップＳ６２において、通信装置１７を経由してバス１０Ａの車両制御装置１５と通信し、バスＩＤと位置情報と電池状態情報を受信する。これらの情報をサーバ２１のＳＯＣ取得部２１Ａが取得する。ステップＳ６３において、サーバ２１の電欠予測部２１Ｃはバス１０Ａの電欠予測を行い、バス１０Ａの車両基地センター３０への帰車前の電欠を判定する。肯定判定された場合、電欠予測部２１Ｃはバス１０Ａに対して車両交換および救援作業を行うことを決定する。ステップＳ６４において、サーバ２１の合流地点決定部２１Ｄは、バス１０Ａと代替バス１０とが合流する合流停留所を決定する。ステップＳ６５において、サーバ２１は、通信インターフェース２３を介して、バス１０Ａの電欠の予測と、合流停留所と、代替バス１０Ｂおよび救援車両９との合流予想時刻などの情報をバス１０Ａに送信する。ステップＳ６６において、サーバ２１は、バス１０Ａから、ステップＳ６５で送信された情報を受信して確認した旨を示す確認信号、すなわち、図１２（ｂ）のステップＳ５６においてバス１０Ａの車両制御装置１５が管理センター２０に送信した確認信号を受信する。ステップＳ６７において、サーバ２１の代替車両管理部２１Ｅに含まれる代替バス決定部が代替バス１０Ｂを決定し、サーバ２１の代替バス指示部２１Ｆが代替バス指示情報を生成して車両基地センター３０に送信する。

　図１３（ｂ）は、図１に示す運行管理システム１に含まれる車両基地センター３０で実行される代替バス指示情報処理を説明するフローチャートであり、車両基地センター３０のサーバ３１の処理手順を説明する図である。サーバ３１においては、メモリに格納されたコンピュータプログラムをプロセッサが実行することによって、図１３（ｂ）に示すプログラム処理手順が実行される。

　ステップＳ７１において、サーバ３１は管理センター２０のサーバ２１と通信して、電欠が予測されたバス１０ＡのバスＩＤと、合流停留所情報と、代替バス１０Ｂおよび救援車両９の発進要請と、代替バス１０Ｂおよび救援車両９の乗務員名または乗務員ＩＤとを含む代替バス指示情報を受信する。ステップＳ７２において、サーバ３１は、代替バス指示情報を、車両基地センター３０に設置されている表示装置３２に表示する。代替バス指示情報の内容を、音声により、車両基地センター３０内の作業者に対して、必要な作業内容とともに報知してもよい。

　以上説明した一実施の形態の作用効果をまとめると以下のとおりである。

（１）本実施の形態の電動車両の運行管理システム１は、電池ユニット１２から電力の供給を受ける走行駆動装置１１で走行する電動バス１０Ａの運行管理システムであって、路線Ｒ１を運行中の電動バス１０Ａから電池ユニット１２のＳＯＣを取得するとともに、ＳＯＣに基づく電池ユニット１２の電池残量を取得するサーバ２１のＳＯＣ取得部２１Ａと、電動バス１０Ａが最終地点の車両基地センター３０まで走行するのに必要な第１電池容量を算出するサーバ２１の第１電池容量算出部２１Ｂと、電池残量が第１電池容量より少ない電池不足を予測するサーバ２１の電欠予測部２１Ｃと、電欠予測部２１Ｃが電池不足を予測したとき、路線Ｒ１の合流地点である停留所Ｎｏ．７「Ｐ１７小学校前」にて電動バス１０Ａを代替バス１０Ｂと車両交換する代替指示と、その合流地点で電動バス１０Ａを電源車両により充電する充電指示とのうちの少なくとも一方の指示を含む指示情報を生成する代替バス指示部２１Ｆとを有する。

　このような運行管理システム１によれば、路線バス１０Ａが電欠して路線Ｒ１上で立ち往生することが防止される。また、バス１０Ａから代替バス１０Ｂに乗客が乗り換えることができるので、乗客への影響を抑制できる。

（２）（１）に記載の電動バス１０Ａの運行管理システム１は、さらに、電池不足が予測された電動バス１０Ａが、それ自身が有する電池ユニット１２の電池残量で走行できる路線Ｒ１上の合流地点として停留所Ｎｏ．７を決定する合流地点決定部２１Ｄを有する。

　このような運行管理システム１によれば、電欠予測されたバス１０Ａの乗務員は、自ら合流地点を探す必要がない。

（３）（１）に記載の電動バス１０Ａの運行管理システム１は、電動バス１０Ａが合流地点である停留所Ｎｏ．７に到着する予定時刻、および代替バス１０Ｂが合流地点である停留所Ｎｏ．７に到着するまでに要する予想所要時間に基づいて、代替バス１０Ｂの出発予定時刻を算出する第３時間情報算出部２１３を、さらに有する。

　このように構成したので、代替バス１０Ｂの出発時刻が自動で演算され、運行管理者の工数が低減されるとともに、代替バス１０Ｂの出発時刻が精度よく演算され、運行管理が円滑になる。

（４）（３）に記載の電動バス１０Ａの運行管理システム１は、代替バス１０Ｂの出発予定時刻と、代替バス１０ＢのバスＩＤと、代替バス１０Ｂの乗務員名とを含む指示情報を生成する代替バス指示部２１Ｆを、さらに有する。

　このような運行管理システム１によれば、運行管理者が代替バス１０Ｂの運転手となる乗務員に個別に指示する必要がない。

（５）（１）～（４）までのいずれかの電動バス１０Ａの運行管理システム１は、路線Ｒ１上の合流地点である停留所Ｎｏ．７まで代替バス１０Ｂが走行するのに必要な第２電池容量を算出する第２電池容量算出部２１４と、その合流地点から最終地点である車両基地センター３０まで代替バス１０Ｂが走行するのに必要な第３電池容量と、第２電池容量および第３電池容量を加算した第４電池容量とを算出し、第４電池容量以上を有する代替バス１０Ｂを決定する代替バス決定部２１５とをさらに有する。

　このように構成したので、代替バス１０Ｂの電池ユニット１２に必要な電池容量が自動的に演算され、その容量を有する代替バス１０Ｂが自動選択され、運行管理者や作業者の工数が低減される。

（６）（１）～（５）までのいずれかに記載の電動車両の運行管理システムは、電欠予測部２１Ｃは、電池不足を予測したとき、合流地点で救援車両により電動バス１０Ａを救援する救援処理を行うことを決定する。

　このように構成したので、バス１０Ａが電欠により立ち往生した道路上で長時間駐車することを防止できる。

　上述した一実施の形態の電動車両の運行管理システム１は、次のように変形して実施することもできる。

（変形例１）
　電池容量、電池残量などの電池状態情報をＳＯＣとして説明したが、電池ユニット１２および／または電池パック１２１の電池容量を示す物理量であれば、ＳＯＣに限定されない。

（変形例２）
　電圧データ、電流データ、および温度データに基づいて電池パック１２１の電池状態情報を算出する方法として、既に公知の如何なる方法をも採ることができる。例えば、電池パック１２１の内部抵抗を、温度データおよび電圧データから算出してもよい。電池パック１２１のＳＯＣ推定値を、電流データと内部抵抗とを掛け算して得られた値を電圧データに対して加減算するなどして算出してもよい。また、いわゆる電流を積算するクローンカウント手法で電池パック１２１のＳＯＣ推定値を算出してもよい。

　さらに、バス１０Ａの電池パック１２１のパックＳＯＣを、バス１０Ａの車両制御装置１５が管理センター２０のサーバ２１に送信し、サーバ２１のＳＯＣ取得部２１Ａが、電池ユニット１２のユニットＳＯＣを、バス１０Ａから受信した電池パック１２１のパックＳＯＣに基づいて演算することにより得てもよい。

（変形例３）
　電欠が予測されたバス１０Ａの車両制御装置１５が、代替バス１０Ｂの確保が難しい状況を、バス１０Ａの電欠予測発生の前に認識しているときは、バス１０Ａの電欠が予測されたとき、バス１０Ａの電池不足を後続のバス１０Ｘに報知して救援を求める。バス１０Ａの車両制御装置１５は、電欠が予測されたバス１０Ａの電池残容量で走行できる運行路線上の停留所を、乗客乗り換え地点として後続バス１０Ｘに報知する。

　電池ユニット１２から電力の供給を受ける電動走行駆動装置１１により駆動されて走行する電動バス１０Ａが目的地まで走行するのに必要な第１電池容量よりも、電池ユニット１２の残容量の方が少ないという電池不足を、電動バス１０Ａの車両制御装置１５が予測したとする。このとき、この変形例における、運行中の電動バス１０Ａの車両制御装置１５は、電動バス１０Ａの電池不足を後続の電動バス１０Ｘに報知して救援を求める。この電欠が予測された電動バス１０Ａの車両制御装置１５は、電動バス１０Ａが電池ユニット１２の残容量で走行して到着できる停留所である電動バス１０Ｘとの合流地点を、乗客乗り換え地点として後続バス１０Ｘに報知する報知部を有する。

　このように構成した変形例によれば、運行管理センター２０の負荷を低減できる。また、管理センター２０で電欠が監視される場合、ネットワーク障害が発生すると電動バス１０Ａに電欠予測が通知されず、路線運行途中で電動バス１０Ａが電欠を起こして乗客に多大な迷惑をかけ得るが、このような問題を回避できる。

　なお、代替バスの確保が難しい状況で電欠発生が予測された電動バス１０Ａの救援を後続バス１０Ｘへ求める処理を管理センター２０のサーバ２１が行う場合は、サーバ２１は後続バス１０Ｘに前を走行する電欠が予測されたバス１０Ａの代替バスとなることを、直接指示し、または車両基地センター３０のサーバ３１を介して指示し、サーバ２１によって決定された合流地点で電欠が予測されたバス１０Ａの乗客が後続バス１０Ｘに乗り換えてバス１０Ａの路線運行計画を続行することができる。サーバ２１は、後続バス１０ＸのバスＩＤを、運行計画情報テーブル２２１のデータから認識できる。

（変形例４）
　上述した実施の形態では、バス１０Ａの電欠を管理センター２０のサーバ２１が予測したが、バス１０Ａ自体が電欠を予測して管理センター２０に救援を求めてもよい。

　図１４は、路線を運行するバス１０Ａの電欠を、そのバス１０Ａ自体が予測する場合において、代替バス指示および救援指示を管理センター２０のサーバ２１に含まれる代替バス指示部２１Ｆへ求めるために必要な構成の例を示す図である。図２に示すバス１０Ａの車載システム１００を構成する部材のうちの、統合ＢＭＳ１３と、車両制御装置１５と、通信装置１７とを用いて本変形例に特有の処理が行われるため、図１４には統合ＢＭＳ１３と、車両制御装置１５と、通信装置１７とが示され、車載システム１００を構成する他の部材の図示は省略される。

　図２に示す電池ユニット１２から電力の供給を受ける走行用電動モータ１１１で路線上を走行する電動バス１０Ａは、図１４（ａ）に示す統合ＢＭＳ１３、車両制御装置１５および通信装置１７を含む。図１４（ａ）に示す構成例によると、車両制御装置１５でバス１０Ａの電欠予測が行われる。

　図１４（ａ）に示す統合ＢＭＳ１３は、図示しないプロセッサおよびメモリを有するコンピュータであって、メモリに格納されたコンピュータプログラムをプロセッサが実行することによって、論理的かつ機能的に、ＳＯＣ監視部１８１と、電池残容量算出部１８２とを有する。車両制御装置１５は、図示しないプロセッサおよびメモリを有するコンピュータであって、メモリに格納されたコンピュータプログラムをプロセッサが実行することによって、論理的かつ機能的に、ＳＯＣおよび電池残容量取得部１８３と、目的地取得部１８４と、自車位置取得部１８５と、センサ情報取得部１８６と、インバータ駆動信号生成部１８７と、第１電池容量算出部１８８と、電欠予測部１８９とを有する。

　統合ＢＭＳ１３のＳＯＣ監視部１８１は、電池ユニット１２のＳＯＣを監視する。電池残容量算出部１８２は、電池ユニット１２のＳＯＣに基づいて電池ユニット１２の残容量を算出する。

　車両制御装置１５のＳＯＣおよび電池残容量取得部１８３は、統合ＢＭＳ１３のＳＯＣ監視部１８１および電池残容量算出部１８２によって算出された電池ユニット１２のＳＯＣおよび残容量を取得する。目的地取得部１８４は、予め定められている電動バス１０Ａの目的地（たとえば車両基地センター３０）の情報を取得する。自車位置取得部１８５は、上述したＧＰＳセンサなどの位置検出装置１６から電動バス１０Ａの自車位置の情報を、時刻情報とともに取得する。センサ情報取得部１８６は、電動バス１０Ａの走行速度などの走行に関する情報を、不図示の各種センサから取得する。インバータ駆動信号生成部１８７は、上述したモータコントローラ１１３に供給されるトルク指令に応じたインバータ駆動信号を生成する。

　第１電池容量算出部１８８は、目的地取得部１８４によって取得された電動バス１０Ａの目的地の情報と、自車位置取得部１８５によって取得された電動バス１０Ａの自車位置の情報および時刻情報と、センサ情報取得部１８６によって取得された電動バス１０Ａの走行に関する情報と、インバータ駆動信号生成部１８７によるインバータ駆動信号生成の際に用いられるモータコントローラ１１３へのトルク指令の情報とに基づき、電動バス１０Ａが目的地まで走行するのに必要な第１電池容量を算出する。

　電欠予測部１８９は、統合ＢＭＳ１３の電池残容量算出部１８２が算出して車両制御装置１５のＳＯＣおよび電池残容量取得部１８３が取得した電池ユニット１２の残容量が、第１電池容量算出部１８８によって算出された第１電池容量より少ない電池不足を予測する。電欠予測部１８９が電池不足を予測したとき、合流地点で電動バス１０Ａの代替または充電が必要である旨のメッセージを、車両制御装置１５が、電動バス１０Ａの運行管理を行う管理センター２０へ通信装置１７を介して送信する。車両制御装置１５により管理センター２０へ送信されるメッセージに、ＳＯＣおよび電池残容量取得部１８３によって取得された電池ユニット１２のＳＯＣおよび残容量も含まれる場合は、管理センター２０のデータベース２２を更新することが可能となる。

　本変形例による運行管理システム１によって運行管理される電動車両は、電池ユニット１２から電力の供給を受ける走行駆動装置１１で走行する路線バス１０Ａであって、電池ユニット１２のＳＯＣを監視するＳＯＣ監視部１８１と、ＳＯＣに基づいて電池ユニット１２の残容量を算出する電池残容量算出部１８２と、路線バス１０Ａが目的地まで走行するのに必要な第１電池容量を算出する第１電池容量算出部１８８と、電池残容量算出部１８２が算出した電池ユニット１２の残容量が第１電池容量より少ない電池不足を予測する電欠予測部１８９と、電欠予測部１８９が電池不足を予測したとき、合流地点で路線バス１０Ａの代替または充電が必要である旨を路線バス１０Ａの運行管理を行う運行管理システム１の管理センター２０に送信する送信部とを備える。

　このように構成した変形例によれば、運行管理センター２０の負荷が低減できる。また、管理センター２０で電欠が監視される場合、ネットワーク障害が発生すると電動バス１０Ａに電欠予測が通知されず、路線運行途中で電動バス１０Ａが電欠を起こして乗客に多大な迷惑をかけるが、このような問題を回避できる。

　なお、本変形例は、図１４（ａ）に示す構成例のほかに、図１４（ｂ）に示す構成例によって実現してもよい。図１４（ｂ）に示す構成例によると、電池ユニット１２の統合ＢＭＳ１３でバス１０Ａの電欠予測が行われる。

　図１４（ｂ）に示す統合ＢＭＳ１３は、図示しないプロセッサおよびメモリを有するコンピュータであって、メモリに格納されたコンピュータプログラムをプロセッサが実行することによって、論理的かつ機能的に、ＳＯＣ監視部１８１および電池残容量算出部１８２を含むＳＯＣおよび電池残容量取得部１９０と、車両情報取得部１９１と、第１電池容量算出部１９２と、電欠予測部１９３と、メッセージ生成部１９４とを有する。車両制御装置１５は、図示しないプロセッサおよびメモリを有するコンピュータであって、メモリに格納されたコンピュータプログラムをプロセッサが実行することによって、論理的かつ機能的に、目的地取得部１８４と、自車位置取得部１８５と、センサ情報取得部１８６と、インバータ駆動信号生成部１８７とを有する。

　統合ＢＭＳ１３のＳＯＣ監視部１８１は、電池ユニット１２のＳＯＣを監視する。電池残容量算出部１８２は、電池ユニット１２のＳＯＣに基づいて電池ユニット１２の残容量を算出する。ＳＯＣおよび電池残容量取得部１９０は、ＳＯＣ監視部１８１および電池残容量算出部１８２によって算出された電池ユニット１２のＳＯＣおよび残容量を取得する。

　統合ＢＭＳ１３の車両情報取得部１９１は、後述する車両制御装置１５の目的地取得部１８４によって取得された電動バス１０Ａの目的地の情報と、自車位置取得部１８５によって取得された電動バス１０Ａの自車位置の情報および時刻情報と、センサ情報取得部１８６によって取得された電動バス１０Ａの走行に関する情報と、インバータ駆動信号生成部１８７によるインバータ駆動信号生成の際に用いられるモータコントローラ１１３へのトルク指令の情報とを含む車両情報を、車両制御装置１５から取得する。第１電池容量算出部１９２は、車両情報取得部１９１によって取得された車両情報に基づき、電動バス１０Ａが目的地まで走行するのに必要な第１電池容量を算出する。

　電欠予測部１９３は、電池残容量算出部１８２が算出した電池ユニット１２の残容量が、第１電池容量算出部１９２によって算出された第１電池容量より少ない電池不足を予測する。メッセージ生成部１９４は、電欠予測部１９３が電池不足を予測したとき、合流地点で電動バス１０Ａの代替または充電が必要である旨のリクエストメッセージを生成する。メッセージ生成部１９４により生成されたリクエストメッセージは、車両制御装置１５によって、電動バス１０Ａの運行管理を行う管理センター２０へ通信装置１７を介して送信される。メッセージ生成部１９４により生成されるリクエストメッセージに、ＳＯＣおよび電池残容量取得部１８３によって取得された電池ユニット１２のＳＯＣおよび残容量も含まれる場合は、管理センター２０のデータベース２２を更新することが可能となる。

　車両制御装置１５の目的地取得部１８４は、予め定められている電動バス１０Ａの目的地（たとえば車両基地センター３０）の情報を取得する。自車位置取得部１８５は、上述したＧＰＳセンサなどの位置検出装置１６から電動バス１０Ａの自車位置の情報を、時刻情報とともに取得する。センサ情報取得部１８６は、電動バス１０Ａの走行速度などの走行に関する情報を、不図示の各種センサから取得する。インバータ駆動信号生成部１８７は、上述したモータコントローラ１１３に供給されるトルク指令に応じたインバータ駆動信号を生成する。これらの情報が、上述したように統合ＢＭＳ１３の車両情報取得部１９１によって取得される。

　本変形例による運行管理システム１によって運行管理される電動車両に搭載される電池ユニットのマネジメントシステムは、路線バス１０Ａを走行駆動する走行駆動装置１１に電力を供給する電池ユニット１２の統合ＢＭＳ１３であって、電池ユニット１２のＳＯＣを監視するＳＯＣ監視部１８１と、ＳＯＣに基づいて電池ユニット１２の残容量を算出する電池残容量算出部１８２と、路線バス１０Ａが目的地まで走行するのに必要な第１電池容量を算出する第１電池容量算出部１９２と、電池残容量算出部１８２が算出した電池ユニット１２の残容量が第１電池容量より少ない電池不足を予測する電欠予測部１９３と、電欠予測部１９３が電池不足を予測したとき、合流地点で路線バス１０Ａの代替または充電が必要である旨を路線バス１０Ａまたは路線バス１０Ａの運行を管理する運行管理システム１の管理センター２０に送信するためのメッセージを生成するメッセージ生成部１９４とを備える。

（変形例５）
　４つの電池パック１２１Ａ，１２１Ｂ，１２１Ｃおよび１２１Ｄが電池ユニット１２を構成したが、５以上の電池パックが電池ユニット１２を構成してもよい。

（変形例６）
　通信装置１７が各種情報を管理センター２０に送信するタイミングは、一例として運行中のバス１０Ａが路線上の停留所を通過する時点としたが、バス１０Ａが所定距離を走行するごとに送信されるようにしても良い。あるいは、バス１０Ａが終点の停留所を通過する時点を各種情報の送信タイミングとしても良い。バス１０Ａが車両基地センター３０に所定距離まで接近したときに通信装置１７が各種情報を送信するようにしても良い。各種情報の送信タイミングを所定時刻ごととしてもよい。

（変形例７）
　上述した実施の形態では、公共の交通機関である路線バス１０Ａの電欠が予測された場合を一例として説明したが、たとえば、大型娯楽施設や大学等の民間敷地内で運行する循環バスが電動バスである場合にも、本発明を適用することができる。したがって、本発明は、公共に与える影響を低減することにのみ着目してはいない。私有地内で複数の電動車両を運行する場合には、民間施設を利用する多数の利用客に与える影響が低減される。

（変形例８）
　上述した実施の形態では、電欠が予測された電動バス１０Ａが合流地点に到達する前に代替バス１０Ｂが到着しているものとした。しかし、運行間隔が大きいために合流地点での停車時間に余裕がある場合には、電動バス１０Ａが合流地点に到着した後に代替バス１０Ｂが到着するようにしてもよい。すなわち、代替バス１０Ｂが合流地点に到着する時刻は、電動バス１０Ａの到着予定時刻の前後の時間帯に設定されることとしてもよい。

（変形例９）
　上述した実施の形態では、代替バス１０Ｂは複数の電動バスのうちから選択されることとした。しかし、電動バス以外の車両、たとえばガソリン車両が、代替バス１０Ｂとして選択されることとしてもよい。

（変形例１０）
　上述した実施の形態では、路線を運行中のバス１０Ａと代替バス１０Ｂとの合流地点として、その路線上の停留所が決定されることとした。しかし、路線が非有料道路上に設けられている場合、路線に沿って位置する商業施設の駐車場或いは観光施設の駐車場が合流地点として決定されることとしてもよい。路線が有料道路上に設けられている場合、路線に沿って位置する休憩施設の駐車場が合流地点として決定されることとしてもよい。

（変形例１１）
　上述した実施の形態において、図５に示す運行計画情報テーブル２２１には、停留所間の予想消費量として、たとえば区間走行負荷の統計値が記録されていることとした。こうした区間走行負荷の統計値は、乗客の乗降時間や乗降者数もまた消費電力に影響を及ぼし得る点を考慮に入れて、予め定められているのが好ましい。

（変形例１２）
　上述した実施の形態において、電欠が予測された車両を、定められた路線を運行する電動バス１０Ａとしたが、定められた路線を運行する他の車両であってもよい。定められた路線を運行する他の車両には、観光用バス、および配送用トラックが含まれる。定められた路線を運行する配送用トラックに本発明を適用する場合、図５に示す運行計画情報テーブル２２１には、停留所間の予想消費量に代えて、配送地点間の予想消費量の統計値が記録される。こうした統計値は、荷下ろし時間や荷物数もまた消費電力に影響を及ぼし得る点を考慮に入れて、予め定められているのが好ましい。

（変形例１３）
　上述した実施の形態では、図６に示す電池情報管理テーブル２２２および図８に示すバス管理テーブル２２４において、電池パック１２１のパックＳＯＣが記録されている。上述したように、バス１０Ａの車載システム１００に含まれる統合ＢＭＳ１３は、統合ＢＭＳ１３が演算した電池ユニット１２のユニットＳＯＣを、電池パック１２１のパックＳＯＣとともに、車両制御装置１５および通信装置１７を介して管理センター２０に送信する。そこで、管理センター２０のサーバ２１に含まれるＳＯＣ取得部２１Ａは、バス１０Ａに搭載される電池ユニット１２を構成する電池パック１２１のパックＳＯＣおよび／または電池ユニット１２のユニットＳＯＣを取得し、パックＳＯＣおよび／またはユニットＳＯＣが電池情報管理テーブル２２２および／またはバス管理テーブル２２４に記録されることとしてもよい。その場合、サーバ２１に含まれる電欠予測部２１Ｃは、電池情報管理テーブル２２２および／またはバス管理テーブル２２４に記録された電池ユニット１２のユニットＳＯＣと、第１電池容量算出部２１Ｂによって算出される第１電池容量とに基づいて、バス１０Ａの電欠予測を行ってもよい。

　本発明は上記実施の形態の内容に限定されるものではない。本発明の技術的思想の範囲内で考えられるその他の態様も本発明の範囲内に含まれる。

　次の優先権基礎出願の開示内容は引用文としてここに組み込まれる。
　日本国特願２０１８－２２８６３８号（２０１８年１２月６日出願）

　　１…電動車両の運行管理システム　　　９…救援車両
　　１０…バス　　　１１…走行駆動装置　　１２…電池ユニット
　　１３…統合バッテリマネジメントシステム　　１４…切替器
　　１５…車両制御装置　　１６…位置検出装置　　１７…通信装置
　　２０…管理センター　　２１…サーバ
　　２１Ａ…ＳＯＣ取得部　　２１Ｂ…第１電池容量算出部
　　２１Ｃ…電欠予測部　　２１Ｄ…合流地点決定部
　　２１Ｅ…代替車両管理部　　２１Ｆ…代替バス指示部　　２２…データベース
　　２３…通信インターフェース　　３０…車両基地センター
　　３１…サーバ　　３２…表示装置　　３３…通信インターフェース
　　５０…電源装置
　　９５…無線基地局　　９６…ネットワーク　　１００…車載システム
　　１１１…走行用電動モータ　　１１２…インバータ
　　１１３…モータコントローラ
　　１２１，１２１Ａ，１２１Ｂ，１２１Ｃ，１２１Ｄ…電池パック
　　１２２…電池パックバッテリマネジメントシステム　　１２３…端子
　　１２５…筐体　　１２６…拘束部材　　１２７…端子部
　　１２８…収容部　　１２９…取っ手　　
　　１８１…ＳＯＣ監視部　　１８２…電池残容量算出部
　　１８３…電池残容量取得部　　１８４…目的地取得部
　　１８５…自車位置取得部　　１８６…センサ情報取得部
　　１８７…インバータ駆動信号生成部　　１８８…第１電池容量算出部
　　１８９…電欠予測部　　１９０…メッセージ生成部
　　１９１…ＳＯＣ監視部　　１９２…電池残容量算出部
　　１９３…車両情報取得部　　１９４…第１電池容量算出部
　　１９５…電欠予測部　　１９６…センサ情報取得部
　　１９７…インバータ駆動信号生成部　　１９８…目的地取得部
　　１９９…自車位置取得部　　２１１…第１時間情報演算部
　　２１２…第２時間情報演算部　　２１３…第３時間情報演算部
　　２１４…第２電池容量算出部　　２１５…代替バス決定部
　　２２１…運行計画情報テーブル
　　２２２…電池情報管理テーブル　　２２３…電欠時対応管理テーブル
　　２２４…バス管理テーブル　　　２２５…乗務員管理テーブル
　　１２１０…セル

Claims

　電池ユニットから電力の供給を受ける電動駆動装置で走行する電動車両の運行管理システムであって、
　前記電動車両から前記電池ユニットの状態情報を取得するとともに、前記状態情報に基づく前記電池ユニットの残容量を取得する取得部と、
　前記電動車両が目的地まで走行するのに必要な第１電池容量を算出する第１電池容量算出部と、
　前記残容量が前記第１電池容量より少ない電池不足を予測する予測部と、
　前記予測部が前記電池不足を予測したとき、合流地点で前記電動車両を代替車両と車両交換する指示と、前記合流地点で前記電動車両を電源車両により充電する指示とのうちの少なくとも一方の指示を含む指示情報を生成する指示部とを備える電動車両の運行管理システム。
　請求項１に記載の電動車両の運行管理システムにおいて、
　前記電池不足が予測された前記電動車両が前記残容量で走行できる前記合流地点を決定する合流地点決定部をさらに備える電動車両の運行管理システム。
　請求項１に記載の電動車両の運行管理システムにおいて、
　前記電動車両が前記合流地点に到着する予定時刻、および前記代替車両が前記合流地点に到着するまでに要する予想所要時間に基づいて、前記代替車両の出発予定時刻を算出する時間情報演算部をさらに備える電動車両の運行管理システム。
　請求項３に記載の電動車両の運行管理システムにおいて、
　前記指示情報は、前記出発予定時刻と、前記代替車両と、前記代替車両の乗務員名とを含む、
　電動車両の運行管理システム。
　請求項１から請求項４までのいずれか１項に記載の電動車両の運行管理システムにおいて、
　前記合流地点まで前記代替車両が走行するのに必要な第２電池容量を算出する第２電池容量算出部と、
　前記合流地点から最終地点まで前記代替車両が走行するのに必要な第３電池容量と、前記第２電池容量および前記第３電池容量を加算した第４電池容量とを算出し、前記第４電池容量以上を有する前記代替車両を決定する代替車両決定部とをさらに備える電動車両の運行管理システム。
　請求項１から請求項５までのいずれか１項に記載の電動車両の運行管理システムにおいて、
　前記予測部が前記電池不足を予測したとき、前記指示部は、前記合流地点で前記電動車両を救援する救援車両を発進させて前記合流地点に向かわせる救援指示情報を生成する、
　電動車両の運行管理システム。