JP2023180894A - 車両管理システム - Google Patents

Abstract

【課題】サービスの利用の普及とサービスの品質の維持とを図る。【解決手段】管理サーバは、実行条件が成立すると（Ｓ１００にてＹＥＳ）、運行情報を取得するステップ（Ｓ１０２）と、走行ルートを設定するステップ（Ｓ１０４）と、回送ルートに設定される車両があると（Ｓ１０６にてＹＥＳ）、回送ルートの車両が高負荷状態になる場合に（Ｓ１１０にてＹＥＳ）、利用料金として第１利用料金に設定するステップ（Ｓ１１２）と、回送ルートの車両が低負荷状態になる場合に（Ｓ１１０にてＮＯ）、利用料金として、第１利用料金よりも高額の第２利用料金に設定するステップ（Ｓ１１４）と、通常ルートの車両の利用料金を設定するステップ（Ｓ１１６）と、料金情報を車両に送信するステップ（Ｓ１１８）とを含む、処理を実行する。【選択図】図３

Description

本開示は、車両管理システムに関する。

輸送サービス等の提供に車両を用いる場合には、車両の消耗品の交換や部品の調整等の整備（メンテナンス）が定期的に行なわれるが整備の期間中においてはサービスの提供に用いることができないため、サービスの提供機会を損失する場合がある。そのため、サービス提供の需要状況や、複数の車両を用いてサービスを提供している場合には、複数の車両を用いたサービスの提供状況を考慮して適切なタイミングで車両の整備を行なうことが求められる。

特開２０２０－０１３３７３号公報（特許文献１）は、車両の利用情報を用いてメンテナンスの実施を指示する車両メンテナンス管理システムを開示する。

特開２０２０－０１３３７３号公報

上述のようなサービスの提供に用いられる車両においては、負荷が高い状態での使用が継続すると、次の整備までの期間が短くなるなどして整備費用が増加する場合がある。そのため、このような車両を用いたサービスの利用料金を一律の料金体系とする場合に、増加した整備費用を回収するために利用料金を高く設定すると、サービスの利用の普及が阻害される場合がある。一方、利用料金を低く設定すると、サービスの利用が普及しても整備費用の増加による収益悪化によりサービスの品質を維持できない場合がある。

本開示は、上述した課題を解決するためになされたものであって、その目的は、サービスの利用の普及とサービスの品質の維持とを図る車両管理システムを提供することである。

本開示のある局面に係る車両管理システムは、輸送サービスの提供に用いられる車両と、車両と通信可能なサーバとを備える。サーバは、予め定められた走行ルートでの車両を用いた輸送サービスの提供の要求を含む要求情報を受ける場合には、要求情報を用いて予め定められた走行ルートを走行するときに車両に作用する負荷の程度を示す負荷度を算出する。サーバは、算出された負荷度が高い場合には、負荷度が低い場合と比較して予め定められた走行ルートにおける輸送サービスの提供に対する利用料金が低額になるように利用料金を設定する。

このようにすると、高い負荷度となる車両を用いて予め定められた走行ルートにおいて輸送サービスが提供される場合に、低い負荷度となる車両よりも利用料金が低額になる。これにより、予め定められた走行ルートにおいて高い負荷度となる車両を用いた輸送サービスの利用頻度を高くすることができる。そのため、サービスの利用を普及することができる。さらに、低い負荷度となる車両の利用頻度を相対的に低下させることにより、次の整備までの期間が短くなることを抑制することができるため、サービスの品質を維持することができる。そのため、サービスの利用の普及とサービスの品質の維持とを図ることができる。

ある実施の形態においては、予め定められた走行ルートは、車両の整備が行なわれる場所を含む。

このようにすると、高い負荷度となる車両を用いて車両の整備が行なわれる場所を含む予め定められた走行ルートにおいて輸送サービスが提供される場合に、低い負荷度となる車両よりも利用料金が低額になる。これにより、予め定められた走行ルートにおいて高い負荷度となる車両を用いた輸送サービスの利用頻度を高くすることができる。

さらにある実施の形態においては、要求情報は、車両の走行距離と、乗車人数と、整備対象となる部品とのうちの少なくともいずれかの情報を含む。

このようにすると、車両の走行距離と、乗車人数と、整備対象となる部品とのうちの少なくともいずれかの情報を用いて車両の負荷度を精度高く算出することができる。

さらにある実施の形態においては、車両は、自動運転車両を含む。
このようにすると、予め定められた走行ルートにおいて高い負荷度となる車両を用いた自動運転による輸送サービスの利用頻度を高くすることができる。

本開示によると、サービスの利用の普及とサービスの品質の維持とを図る車両管理システムを提供することができる。

車両管理システムの全体構成を概略的に示す図である。 ＡＤＫおよびＶＰの構成の一例をより詳細に示す図である。 管理サーバで実行される処理の一例を示すフローチャートである。 通常の走行ルートと回送ルートとを説明するための図である。

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

図１は、車両管理システム１００の全体構成を概略的に示す図である。車両管理システム１００は複数の車両を管理する。実際には多数の車両が車両管理システム１００によって管理され得るが、以下では説明の便宜上、特定の車両１，４が車両管理システム１００によって管理される場合を一例として説明する。車両管理システム１００は、車両１，４と、管理サーバ７とを含む。車両１は、自動運転キット（ＡＤＫ：Autonomous Driving Kit）２と、車両プラットフォーム（ＶＰ：Vehicle Platform）３とを含む。同様に、車両４は、ＡＤＫ５と、ＶＰ６とを含む。

車両１，４のユーザは、たとえば、車両１，４を用いた自動運転による輸送サービスを提供する事業者（バス事業者、タクシー事業者、レンタカー事業者、カーシェア事業者、あるいは、ライドシェアサービス事業者など）であってもよい。本実施の形態において、車両１，４のユーザは、たとえば、複数の車両を保有する、人員の輸送サービスを提供する事業者である場合を想定する。人員の輸送サービスは、たとえば、複数の走行ルート（都市部を通過する走行ルートや山間部を通過する走行ルートなど）に対して車両を走行させて、走行ルート上に設けられた所定の乗降地点に予め定められた設定された時刻に到着するように移動しつつ、乗降地点において人員を乗り降りさせて、利用料金を徴収するサービスを含む。本実施の形態においては、複数の走行ルートは、説明の便宜上、整備工場の場所を含む回送ルートと、整備工場を経由せずに所定の複数の乗降地点を循環する通常ルートとを含むものとする。

以下、車両１を例に自動運転を行なうための構成の一例について説明する。車両１に搭載されるＡＤＫ２は、車両１のＶＰ３に取り付け可能であり、かつ、ＶＰ３から取り外し可能に構成される。ＡＤＫ２は、たとえば、ＶＰ３のルーフトップなどの予め定められた位置に取り付けられる。

ＡＤＫ２は、車両１の自動運転を実施可能に構成される。具体的には、ＡＤＫ２は、車両１の走行計画を作成する。ＡＤＫ２は、走行計画に従って車両１を走行させるための各種制御要求を、制御要求毎に定義されたＡＰＩ（Application Program Interface）に従ってＶＰ３に出力する。また、ＡＤＫ２は、車両状態（ＶＰ３の状態）を示す各種信号を、信号毎に定義されたＡＰＩに従ってＶＰ３から受ける。そして、ＡＤＫ２は、車両状態を走行計画に反映する。なお、ＡＤＫ２は、たとえば、管理サーバ７からの走行計画情報を用いて走行計画を作成してもよい。

ＶＰ３は、ＡＤＫ２からの制御要求に従って自動運転モードによる走行制御を実行する。ＶＰ３からＡＤＫ２が取り外されている場合には、ＶＰ３は、マニュアルモードによる走行制御（ドライバ操作に応じた走行制御）の実行が可能に構成される。

ＶＰ３は、車両管理システム１００内の管理サーバ７に各種情報（後述する運行情報等）を送信する。

管理サーバ７は、事業者の自社サーバであってもよいし、当該事業者を含む複数の事業者で共有されるシェアードサーバであってもよいし、あるいは、クラウドサーバ管理会社により提供されるクラウドサーバであってもよい。

管理サーバ７は、たとえば、車両１を含む複数の車両の保守管理を行なう事業者によって運営されるサーバである。事業者としては、たとえば、ＶＰ３のメーカーであってもよいし、ＡＤＫ２のメーカーであってもよい。さらに、管理サーバ７は、ＶＰ３のメーカーが運営するサーバと、ＡＤＫ２を運営するサーバとを含むように構成されてもよい。以下の説明においては、管理サーバ７は、１つのサーバによって構成される場合を一例として説明する。

管理サーバ７は、車両１，４の各々から運行情報を受信可能に構成される。車両１，４の運行情報は、ナンバープレートに記載の番号や製造暗号等の車両１，４を特定可能な情報（以下、車両ＩＤと記載する）と、走行履歴についての情報（以下、履歴情報と記載する）と、車両１，４の整備に関する情報（以下、整備情報と記載する）とを含む。管理サーバ７は、車両１，４の少なくともいずれかから受信した運行情報を、情報の送信元の車両を特定可能な形式で格納するためのデータベース（図示せず）を含む。管理サーバ７は、受信した運行情報を用いて走行計画情報と、料金情報とを生成し、各車両１，４に送信する。

本開示において、車両の「整備」とは、車両を正常な状態に維持したり、車両を異常な状態から正常な状態に復旧したりするための行為全般を意味する。整備は、車両に設けられるいずれかの部品の検査、修理、調整、交換を含み得る。整備情報は、たとえば、整備対象の部品の整備後の走行距離や、当該部品の次回の整備までの走行距離等の整備が求められる状態であるか否かを診断するための情報を含むようにしてもよいし、整備が求められる状態であるか否かの診断結果を示す情報を含むようにしてもよい。

図２は、ＡＤＫ２およびＶＰ３の構成の一例をより詳細に示す図である。ＡＤＫ２は、コンピュータ２１と、認識用センサ２２と、姿勢用センサ２３と、ＨＭＩ（Human Machine Interface）２５とを含む。

ＶＰ３は、車両制御インターフェースボックス（ＶＣＩＢ：Vehicle Control Interface Box）３１と、ベース車両３２とを含む。ベース車両３２は、セントラルＥＣＵ（Electronic Control Unit）３２１と、ブレーキシステム３２２と、ステアリングシステム３２３と、パワートレーンシステム３２４と、ＤＣＭ（Digital Communication System）３２７とを含む。

パワートレーンシステム３２４は、電動パーキングブレーキ（ＥＰＢ：Electric Parking Brake）システム３２４Ａと、パーキングロック（Ｐロック）システム３２４Ｂと、推進システム３２４Ｃとを含む。

コンピュータ２１は、車両１の自動運転時に認識用センサ２２を用いて車両１の環境に関するデータを取得する。また、コンピュータ２１は、車両１の自動運転時に姿勢用センサ２３を用いて車両１の姿勢、挙動および位置に関するデータを取得する。さらに、コンピュータ２１は、ＶＣＩＢ３１と通信可能に接続されている。コンピュータ２１は、ＶＰ３からＶＣＩＢ３１経由で車両状態を取得して車両１の次の動作（加速する、減速する、曲がる等）を設定する。コンピュータ２１は、次の動作を実現するための各種指令をＶＣＩＢ３１経由でＶＰ３に出力する。

認識用センサ２２は、車両１の環境を認識するためのセンサである。認識用センサ２２は、たとえば、ＬＩＤＡＲ（Laser Imaging Detection and Ranging）と、ミリ波レーダと、カメラ（いずれも図示せず）とのうちの少なくとも一つを含む。ＬＩＤＡＲは、たとえば赤外パルスのレーザ光を発し、そのレーザ光の対象物からの反射光を検出することによって対象物の距離および方向を計測する。ミリ波レーダは、ミリ波を発し、そのミリ波の対象物からの反射波を検出することによって対象物の距離および方向を計測する。カメラは、車両１の周囲の画像を撮影する。

姿勢用センサ２３は、車両１の姿勢、挙動および位置を検出するためのセンサである。姿勢用センサ２３は、たとえば、ＩＭＵ（Inertial Measurement Unit）と、ＧＰＳ（Global Positioning System）（いずれも図示せず）などの位置検出装置とを含む。ＩＭＵは、たとえば、車両１の前後方向、左右方向および上下方向の加速度と、車両１のロール方向、ピッチ方向およびヨー方向の角速度とを検出する。ＧＰＳは、地球の軌道上を周回する複数のＧＰＳ衛星から受信された情報を用いて車両１の位置を特定する。

ＨＭＩ２５は、たとえば、ベース車両３２に設けられたタッチパネルディスプレイ等の入出力装置（図示せず）と接続されるように構成されている。

ＶＣＩＢ３１は、ＣＡＮ（Controller Area Network）等を通じてＡＤＫ２と通信可能に接続されている。ＶＣＩＢ３１は、信号毎に定義された所定のＡＰＩを実行することによって、ＡＤＫ２から各種制御要求を受信したり、車両状態をＡＤＫ２に出力したりする。ＶＣＩＢ３１は、ＡＤＫ２から制御要求を受信すると、その制御要求に対応する制御指令をその制御指令に対応するシステム（たとえば、ブレーキシステム３２２、ステアリングシステム３２３およびパワートレーンシステム３２４）に出力する。また、ＶＣＩＢ３１は、車両状態（ベース車両３２の状態）に関する各種情報を取得し、取得した情報をＡＤＫ２に出力する。

セントラルＥＣＵ３２１は、ＤＣＭ３２７を介して、車両状態を示す様々な情報を管理サーバ７に送信したり、様々な要求を管理サーバ７に送信したりする。また、セントラルＥＣＵ３２１は、管理サーバ７からＤＣＭ３２７を介して指令または通知を受信する。さらに、セントラルＥＣＵ３２１は、ＶＰ３の各システムから取得される車両状態を用いてＶＰ３において整備が求められる状態である否かの診断を行なったり、あるいは、ＶＰ３の各システムにおいて実施された自己診断の診断結果を受信し、受信した診断結果を用いてＶＰ３において整備が求められる状態であるか否かの診断を行なったりする。

本実施の形態においては、セントラルＥＣＵ３２１は、車両１の整備が求められる状態であるか否かを診断する診断処理の実行主体として説明するが、このような機能に加えて各システムに含まれる各種ＥＣＵ間の通信を中継する等の機能（ゲートウエイ機能）を有するものであってもよい。

ブレーキシステム３２２は、ベース車両３２の各車輪に設けられた制動装置（図示せず）を制御するように構成されている。ステアリングシステム３２３は、車両１の操舵輪の操舵角を操舵装置（図示せず）を用いて制御するように構成されている。

ＥＰＢシステム３２４Ａは、ＡＤＫ２からＶＣＩＢ３１を介して伝送された制御要求に従って、複数の車輪のうちの少なくとも１つに設けられたＥＰＢ（図示せず）を制御する。Ｐロックシステム３２４Ｂは、ＡＤＫ２からＶＣＩＢ３１を介して伝送された制御要求に従って、トラッスミッションに設けられたＰロック装置（図示せず）を制御する。推進システム３２４Ｃは、ＡＤＫ２からの制御要求に従って、駆動源（図示しないモータジェネレータ、エンジンなど）からの駆動力を制御する。

ＤＣＭ３２７は車載通信モジュールである。ＤＣＭ３２７は、セントラルＥＣＵ３２１と管理サーバ７との間における双方向のデータ通信が可能に構成されている。

なお、車両４のＡＤＫ５は、車両１のＡＤＫ２と同様の構成を有している。さらに、車両４のＶＰ６は、車両１のＶＰ３と同様の構成を有している。そのため、それらの詳細な説明は繰り返さない。

管理サーバ７は、制御装置８と、記憶装置９と、通信装置１０とを含む。制御装置８と、記憶装置９と、通信装置１０とは、通信バス１１によって互いに通信可能に接続される。

制御装置８は、いずれも図示しないが、ＣＰＵ（Central Processing Unit）、メモリ（ＲＯＭ（Read Only Memory）およびＲＡＭ（Random Access Memory）など）、および、各種信号を入出力するための入出力ポート等を含んで構成されている。制御装置８により実行される各種制御は、ソフトウェア処理、すなわち、メモリに格納されたプログラムがＣＰＵにより読み出されることにより実行される。制御装置８による各種制御は、記憶媒体に記憶されたプログラムを汎用のコンピュータ（図示せず）が実行することによっても実現可能である。制御装置８による各種制御は、ソフトウェア処理に限られず、専用のハードウエア（電子回路）で処理してもよい。

記憶装置９は、管理サーバ７と通信可能に構成される複数の車両１，４から受信した運行情報を記憶する。

通信装置１０は、車両１，４と通信網（図示せず）との間で双方向通信を実現する。管理サーバ７は、通信装置１０を用いて通信網に設けられた基地局（図示せず）等を介して、車両１，４を含む複数の車両と互いに通信を可能とする。

以上のような構成を有する車両管理システム１００においては、たとえば、管理サーバ７は、車両１，４の各々が走行する経路情報を示す走行ルートを設定し、設定された走行ルート上の乗降地点を予め設定された時刻に到着または出発して走行するように走行計画情報を車両１，４の各々に送信する。さらに、管理サーバ７は、設定された走行ルートにおいて車両を利用するための利用料金についての情報を料金情報として車両１，４に送信する。

車両１，４の各々においては、走行計画情報に従って自動運転を実施するとともに、利用者に対して表示装置等を用いて料金情報が提示されたり、利用者による利用時に応じた決済処理が実行されたりする。このようにして、車両１，４の各々においては、乗降地点において利用者を乗降させて、走行ルートを移動する人員の輸送サービスの提供が行なわれる。

車両１，４を含む複数の車両を人員の輸送サービスの提供に用いる場合には、車両１，４の整備が定期的に行なわれる。

たとえば、車両１，４または管理サーバ７において車両１，４の各々において整備が求められる状態であるか否かの診断が行なわれることによって車両１，４の整備の要否が判断される。

車両１において整備が求められる状態であるか否かを診断する場合としては、診断対象となる部品の使用期間が前回の交換時点からしきい値を超える場合、前回の交換時点からの診断対象となる部品の消耗量がしきい値を超える場合、診断対象となる部品のエラーコードが出力される場合あるいは診断対象となる部品の出力値が異常となる場合が含まれる。

たとえば、前回の交換時点からのエンジンやモータジェネレータ等で用いられる各種オイルの使用期間がオイルの種類に応じて設定されるしきい値を超える場合、オイル交換の整備が求められる状態であると診断される。あるいは、制動装置に含まれるブレーキパッドの摩耗量がしきい値を超える場合には、ブレーキパッドの交換の整備が求められる状態であると診断される。あるいは、エンジンやモータジェネレータ等の車両１の駆動動作に関連する機器等において所定のエラーコードが出力される場合には、検査の整備が求められる状態であると診断される。あるいは、各種センサの出力値が通常範囲を超えて出力される場合には、センサの交換あるいは調整等の整備が求められる状態であると診断される。

これらの判定は、車両１において実行される自己診断処理の診断結果を用いて行なわれる。自己診断処理は、たとえば、ＡＤＫ２のコンピュータ２１やＶＰ３のセントラルＥＣＵ３２１において実行される。あるいは、管理サーバ７は、車両１，４の整備履歴についての情報を管理し、管理している情報を用いて診断処理を実行し、診断結果を用いて整備が求められる状態であるか否かを判定してもよい。

しかしながら、上述のように整備が求められる状態であると診断されて、整備が実施されることとなると、整備の期間中においては車両１，４をサービスの提供に用いることができないため、サービスの提供機会を損失する場合がある。そのため、サービスの提供の需要やサービスの提供状況を考慮して適切なタイミングで車両の整備を行なう事が求められる。

上述のような車両１，４において、負荷が高い状態での使用が継続すると、次の整備までの期間が短くなるなどして整備費用が増加する場合がある。そのため、車両１，４を用いたサービスの利用料金を一律の料金体系とする場合に、増加した整備費用を回収するために利用料金を高く設定すると、サービスの利用の普及が阻害される場合がある。一方、利用料金を低く設定すると、サービスの利用が普及しても整備費用の増加による収益悪化によりサービスの品質を維持できない場合がある。

そこで、本実施の形態においては、管理サーバ７が以下のように動作するものとする。すなわち、管理サーバ７は、予め定められた走行ルートでの車両１，４を用いた輸送サービスを提供する要求を含む要求情報を取得する場合には、要求情報を用いて予め定められた走行ルートを走行するときに車両に作用する負荷の程度を示す負荷度を算出する。管理サーバ７は、算出された負荷度が高い場合には、負荷度が低い場合と比較して予め定められた走行ルートにおける輸送サービスの提供に対する利用料金が低額になるように利用料金を設定するものとする。

より具体的には、本実施の形態においては、管理サーバ７は、たとえば、車両１，４のいずれかにおける輸送サービスを提供するための走行ルートを回送ルートに設定するための情報（要求情報）を取得する場合には、当該情報を用いて回送ルートを走行するときの車両の負荷度を算出する。回送ルートは、整備工場の場所を含む予め定められた走行ルートである。管理サーバ７は、回送ルートを走行するときに整備対象の車両が高負荷状態であるか低負荷状態であるかを二段階の負荷度として算出する。管理サーバ７は、高負荷状態であると判定される場合には、低負荷状態であると場合と比較して回送ルートにおける輸送サービスの提供に対する利用料金が低額になるように利用料金を設定する。

このようにすると、回送ルートにおいて整備前の高負荷状態の車両を用いた輸送サービスの利用頻度を高くすることができる。そのため、サービスの利用を普及することができる。さらに低負荷状態となる車両の利用頻度を相対的に低下させることにより、次の整備までの期間が短くなることを抑制することができるため、サービスの品質を維持することができる。そのため、サービスの利用の普及とサービスの品質の維持とを図ることができる。

以下、管理サーバ７において実行される処理の一例について図３を参照しつつ説明する。図３は、管理サーバ７において実行される処理の一例を示すフローチャートである。このフローチャートに示される一連の処理は、管理サーバ７により、所定の周期毎に繰り返し実行される。

ステップ（以下、ステップをＳと記載する）１００にて、管理サーバ７（より具体的には、管理サーバ７の制御装置８）は、利用料金を設定する処理を実行するための実行条件が成立するか否かを判定する。実行条件は、たとえば、前回の利用料金の設定時点から予め定められた時間が経過したという条件を含むようにしてもよいし、あるいは、サービスの提供を行なう時間帯以外の時間帯であるという条件を含むようにしてもよいし、前回の走行ルートの設定が実施された時点から予め定められた時間が経過したという条件を含むようにしてもよい。実行条件が成立していると判定される場合（Ｓ１００にてＹＥＳ）、処理はＳ１０２に移される。

Ｓ１０２にて、管理サーバ７は、運行情報を取得する。管理サーバ７は、車両１，４を含む複数の車両の各々から運行情報を取得する。管理サーバ７は、たとえば、通信装置１０を介して車両１に対して運行情報を要求すると、車両１のセントラルＥＣＵ３２１は、管理サーバ７からの要求信号をＤＣＭ３２を介して受信する。セントラルＥＣＵ３２１は、たとえば、ＡＤＫ２のコンピュータ２１やセントラルＥＣＵ３２１のメモリから運行情報を取得し、取得した運行情報をＤＣＭ３２を介して管理サーバ７に送信する。

Ｓ１０４にて、管理サーバ７は、複数の車両の各々の走行ルートを設定する。管理サーバ７は、たとえば、複数の車両のうちのいずれかの車両の運行情報に整備が求められる状態であることを示す情報が含まれる場合には、当該車両の走行ルートを回送ルートに設定する。管理サーバ７は、回送ルートに設定された車両以外の走行ルートを通常走行ルートに設定する。管理サーバ７は、たとえば、通常走行ルートおよび回送ルートにそれぞれ設定された車両の走行ルート上の乗降地点において発着時刻等を設定する。管理サーバ７は、設定された情報を走行計画情報として複数の車両の各々に送信する。なお、管理サーバ７は、回送ルートが設定された車両に対応づけたフラグをオン状態に設定し、設定されたフラグを車両ＩＤに対応づけて記憶装置９に記憶する。

Ｓ１０６にて、管理サーバ７は、複数の車両のうち回送ルートが設定された車両があるか否かを判定する。管理サーバ７は、複数の車両のうちのフラグがオン状態に設定された車両がある場合には、回送ルートが設定された車両があると判定する。回送ルートが設定された車両があると判定される場合（Ｓ１０６にてＹＥＳ）、処理はＳ１０８に移される。

Ｓ１０８にて、管理サーバ７は、回送ルートが設定された各車両の負荷度を算出する。本実施の形態においては、たとえば、高負荷状態と、低負荷状態との二段階で設定される負荷度を一例として説明する。管理サーバ７は、たとえば、整備対象となる部品が予め定められた部品（たとえば、エンジンやモータジェネレータ等の駆動系の部品）である場合に、高負荷状態であると判定してもよいし、あるいは、回送ルートが設定された車両の現在地点から回送ルートを経由して整備工場の場所までの移動距離が予め定められた走行距離以上となる場合に、高負荷状態であると判定してもよいし、回送ルートを経由して整備工場の場所までの移動の間の乗車人数の予測値がしきい値を超える場合に、高負荷状態であると判定してもよい。なお、管理サーバ７は、整備工場の場所までの移動距離をたとえば、整備工場を含む地図情報を用いて算出してもよい。管理サーバ７は、たとえば、過去の実績を用いて整備工場の場所までの回送ルートにおける乗車人数の予測値を算出してもよいし、あるいは、回送ルートに設定された車両の利用予約等の状況（予約数）を用いて回送ルートにおける乗車人数の予測値を算出してもよい。これらの負荷度の算出方法は、一例であり、上述のような算出方法に限定されるものではない。その後処理はＳ１１０に移される。

Ｓ１１０にて、管理サーバ７は、回送ルートに設定された車両が高負荷状態であるか否かを判定する。高負荷状態であると判定される場合、処理はＳ１１２に移される。

Ｓ１１２にて、管理サーバ７は、回送ルートの車両の利用料金を第１利用料金に設定する。第１利用料金は、たとえば、整備工場の場所まで移動するための一律の利用料金を含むようにしてもよいし、あるいは、予め定められた距離当たりの利用料金を含むようにしてもよいし、あるいは、予め定められた時間当たりの利用料金を含むようにしてもよい。その後処理はＳ１１６に移される。なお、回送ルートに設定された高負荷状態でないと判定される場合（Ｓ１１０にてＮＯ）、処理はＳ１１４に移される。

Ｓ１１４にて、管理サーバ７は、回送ルートの車両の利用料金を第２利用料金に設定する。第２利用料金は、第１利用料金よりも高額に設定される（すなわち、第１利用料金は、第２利用料金よりも低額に設定される）。その後処理はＳ１１６に移される。

Ｓ１１６にて、管理サーバ７は、通常走行ルートを走行する車両において利用料金を設定する。その後処理はＳ１１８に移される。

Ｓ１１８にて、管理サーバ７は、設定された利用料金を用いて料金情報を生成し、複数の車両の各々に生成した料金情報を送信する。管理サーバ７は、たとえば、車両１に料金情報を通信装置１０を介して送信する。車両１のセントラルＥＣＵ３２１は、ＤＣＭ３２７を介して料金情報を受信すると、たとえば、受信した料金情報を用いて乗員に報知してもよい。セントラルＥＣＵ３２１は、たとえば、車両１の室内に設置される表示装置に料金を表示してもよい。セントラルＥＣＵ３２１は、たとえば、車両１の室内に乗員がいる場合には、表示装置や音声発生装置を用いて料金の案内を示す音声情報を出力することにより乗員に報知してもよい。

以上のような構造およびフローチャートに基づく管理サーバ７の動作の一例について図４を参照しつつ説明する。

図４は、通常の走行ルートと回送ルートとを説明するための図である。図４に示すように、回送ルートは、整備工場の場所を含む。図４の（Ａ）～（Ｆ）は、乗降地点を示す。

たとえば、複数の車両のうちの車両１における自己診断処理により整備が求められる状態であると判定される場合を想定する。

このとき、管理サーバ７においては、前回の走行ルートの設定から予め定められた時間が経過していると実行条件が成立すると判定される（Ｓ１００にてＹＥＳ）。

そのため、複数の車両の各々から運行情報が取得される（Ｓ１０２）。取得された運行情報を用いて走行ルートが設定される（Ｓ１０４）。このとき、車両１においては、回送ルートが走行ルートとして設定され、対応するフラグがオン状態に設定される。

複数の車両のうちの車両１に対応するフラグがオン状態に設定されているため、回送ルートの車両があると判定される（S１０６にてＹＥＳ）。そのため、回送ルートにおける車両１の負荷度が算出され、（Ｓ１０８）、回送ルートにおける車両１が高負荷状態になる場合には（Ｓ１１０にてＹＥＳ）、回送ルートにおける車両１の利用料金として第１利用料金が設定されることとなる（Ｓ１１２）。そして、回送ルート以外の走行ルートが設定された車両に対しての利用料金が設定され（Ｓ１１６）、料金情報が複数の車両の各々に送信される（Ｓ１１８）。

図４に示すように、回送ルート以外の走行ルート（通常ルート）が設定された車両は、図４の（Ｂ）、（Ｃ）、（Ｄ）、（Ｅ）および（Ｆ）の順序で各乗降地点間を移動し、（Ｂ）に戻り、循環する。すなわち、通常ルートは、図４の（Ｂ）～（Ｆ）を循環するルートである。

一方、回送ルートが設定された車両は、図４の（Ｆ）の乗降地点から（Ａ）の整備工場の場所に設定された乗降地点まで移動することとなる。すなわち、回送ルートは、図４の（Ａ）を終点とするルートである。回送ルートは、少なくとも図４の（Ｆ）から（Ａ）までの移動経路を含む。回送ルートの始点としては、図４の（Ｂ）から（Ｆ）のいずれかであってもよい。図４の（Ａ）までの車両１が移動する際に提供される輸送サービスの利用料金は、低負荷状態である場合よりも低額に設定されることとなる。なお、車両１が整備工場において整備された後においては、図４の（Ａ）から（Ｂ）まで移動した後に通常ルートを走行することとなる。

以上のように、本実施の形態に係る車両管理システムによると、回送ルートにおいて整備前の高負荷状態の車両を用いた輸送サービスの利用頻度を高くすることができる。そのため、サービスの利用を普及することができる。さらに低負荷状態となる車両の利用頻度を相対的に低下させることにより、次の整備までの期間が短くなることを抑制することができるため、サービスの品質を維持することができる。そのため、サービスの利用の普及とサービスの品質の維持とを図ることができる。したがって、サービスの利用の普及とサービスの品質の維持とを図る車両管理システムを提供することができる。

さらに、管理サーバ７は、車両の走行距離と、乗車人数と、整備対象となる部品とのうちの少なくともいずれかの情報を含む要求情報を用いて負荷度を算出することにより、負荷度を精度高く算出することができる。

以下、変形例について記載する。
上述の実施の形態では、管理サーバ７は、整備工場の場所を終点として含む回送ルートに設定される車両が回送ルートにおいて高負荷状態になる場合に、低負荷状態になる場合よりも利用料金を低額に設定する場合を一例として説明したが、少なくとも整備工場の場所を含むルートであればよく、特に整備工場の場所を終点とするものに限定されるものではない。

さらに上述の実施の形態では、管理サーバ７は、回送ルートに設定される車両が回送ルートにおいて高負荷状態になる場合に、低負荷状態になる場合よりも利用料金を低額に設定する場合を一例として説明したが、高負荷状態になる場合に、低負荷状態になる場合よりも利用料金を低額に設定する走行ルートとしては、上述の回送ルートと異なる予め定められた走行ルートであってもよい。たとえば、予め定められた走行ルートは、たとえば、通常ルート上の整備工場の場所に最寄りの乗降地点を終点とする走行ルートを含むようにしてもよい。

さらに上述の実施の形態では、車両１の位置検出装置は、ＡＤＫ２に設けられる場合を一例として説明したが、位置検出装置は、ＶＰ３に設けられるようにしてもよい。

さらに上述の実施の形態では、乗車人数の予測値を用いて高負荷状態であるか否かを判定する場合を一例として説明したが、たとえば、車内に設けられるカメラなどの撮影装置を用いて車内の画像を取得し、管理サーバ７からの要求に応じて取得した画像を管理サーバ７に送信し、管理サーバ７において画像から乗車人数を取得してもよい。

さらに上述の実施の形態では、負荷度は、高負荷状態と低負荷状態との二段階である場合を一例として説明したが、三段階以上に区分してもよいし、あるいは、乗車人数と、移動距離と、整備対象となる部品とを用いて定量化してもよい。この場合、管理サーバ７は、負荷度がしきい値以上であるときに高負荷状態であると判定してもよい。

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

１，４ 車両、２，５ ＡＤＫ、３，６ ＶＰ、７ 管理サーバ、８ 制御装置、９ 記憶装置、１０ 通信装置、１１ 通信バス、２１ コンピュータ、２２ 認識用センサ、２３ 姿勢用センサ、２５ ＨＭＩ、３１ ＶＣＩＢ、３２ ベース車両、１００ 車両管理システム、３２１ セントラルＥＣＵ、３２２ ブレーキシステム、３２３ ステアリングシステム、３２４ パワートレーンシステム、３２４Ａ ＥＰＢシステム、３２４Ｂ Ｐロックシステム、３２４Ｃ 推進システム、３２７ ＤＣＭ。

Claims (4)

1. 輸送サービスの提供に用いられる車両と、
   前記車両と通信可能なサーバとを備え、
   前記サーバは、
   予め定められた走行ルートでの前記車両を用いた前記輸送サービスの提供の要求を含む要求情報を取得する場合には、前記要求情報を用いて前記予め定められた走行ルートを走行するときに前記車両に作用する負荷の程度を示す負荷度を算出し、
   算出された前記負荷度が高い場合には、前記負荷度が低い場合と比較して前記予め定められた走行ルートにおける前記輸送サービスの提供に対する利用料金が低額になるように前記利用料金を設定する、車両管理システム。
2. 前記予め定められた走行ルートは、前記車両の整備が行なわれる場所を含む、請求項１に記載の車両管理システム。
3. 前記要求情報は、前記車両の走行距離と、乗車人数と、整備対象となる部品とのうちの少なくともいずれかの情報を含む、請求項１に記載の車両管理システム。
4. 前記車両は、自動運転車両を含む、請求項１～３のいずれかに記載の車両管理システム。

Images