特許 7597058 サーバ

(19)【発行国】日本国特許庁(JP)

(12)【公報種別】特許公報(B2)

(11)【特許番号】

(24)【登録日】2024-12-02

(45)【発行日】2024-12-10

(54)【発明の名称】サーバ

(51)【国際特許分類】

   G06Q 10/20 20230101AFI20241203BHJP

   G06Q 50/10 20120101ALI20241203BHJP

   G08G 1/00 20060101ALI20241203BHJP

   G08G 1/09 20060101ALI20241203BHJP

   G16Y 10/40 20200101ALI20241203BHJP

   G16Y 40/20 20200101ALI20241203BHJP

【ＦＩ】

G06Q10/20

G06Q50/10

G08G1/00 D

G08G1/09 F

G16Y10/40

G16Y40/20

【請求項の数】 12

(21)【出願番号】P 2022032061

(22)【出願日】2022-03-02

(65)【公開番号】P2023128025

(43)【公開日】2023-09-14

【審査請求日】2023-12-19

(73)【特許権者】

【識別番号】000003207

【氏名又は名称】トヨタ自動車株式会社

(74)【代理人】

【識別番号】110001195

【氏名又は名称】弁理士法人深見特許事務所

(72)【発明者】

【氏名】柏倉 俊樹

(72)【発明者】

【氏名】山田 健一

(72)【発明者】

【氏名】岡 尚哉

(72)【発明者】

【氏名】前田 直子

【審査官】渡邉 加寿磨

(56)【参考文献】

【文献】特開２００３－２１６７５９（ＪＰ，Ａ）

【文献】特開２００３－１６２６６５（ＪＰ，Ａ）

【文献】特開２００３－３４５９２６（ＪＰ，Ａ）

【文献】特開２０２０－８２９１８（ＪＰ，Ａ）

(58)【調査した分野】(Int.Cl.，ＤＢ名)

Ｇ０６Ｑ １０／００－９９／００

Ｇ０８Ｇ １／００

Ｇ０８Ｇ １／０９

Ｇ１６Ｙ １０／４０

Ｇ１６Ｙ ４０／２０

(57)【特許請求の範囲】

【請求項1】

複数の車両の各々を管理するサーバであって、
前記複数の車両の各々と、前記複数の車両のメンテナンスを実施する第１メンテナンス場および第２メンテナンス場と、通信するサーバ側通信部と、
前記複数の車両の各々の状態に関する状態情報が取得されるように、前記サーバ側通信部を制御するサーバ側制御部と、を備え、
前記複数の車両の各々は、
車両本体と、
前記車両本体の運転支援制御および自動運転制御の少なくとも一方を実施するとともに、前記車両本体に取り付けられた搭載制御装置と、
前記サーバ側通信部と通信する車両側通信部と、を含み、
前記第１メンテナンス場は、前記車両本体のメンテナンスが実施可能であり、
前記第２メンテナンス場は、前記搭載制御装置のメンテナンスが実施可能であり、
前記サーバ側制御部は、前記状態情報に基づいて、前記第１メンテナンス場および前記第２メンテナンス場の少なくとも一方における前記車両のメンテナンスの割り当てを決定し、
前記状態情報は、前記搭載制御装置の状態に関する情報と、前記車両本体の状態に関する情報とを含み、
前記第１メンテナンス場は、前記車両本体のメンテナンスが可能な前記車両の第１販売店を含み、
前記第２メンテナンス場は、前記搭載制御装置の制御的なメンテナンスは可能である第１メンテナンスセンタを含み、
前記サーバ側制御部は、前記状態情報に基づいて前記車両本体が異常であると判断した場合に、前記第１販売店において前記車両本体のメンテナンスを行うことを決定する、サーバ。

【請求項2】

前記サーバ側通信部は、前記第１メンテナンス場の第１スケジュール情報、および、前記第２メンテナンス場の第２スケジュール情報を取得可能であり、
前記サーバ側制御部は、前記状態情報と、前記第１スケジュール情報および前記第２スケジュール情報の少なくとも一方とに基づいて、前記第１メンテナンス場および前記第２メンテナンス場の少なくとも一方における前記車両のメンテナンスのスケジュールを決定する、請求項１に記載のサーバ。

【請求項3】

前記状態情報は、前記車両における異常情報を含み、
前記サーバ側制御部は、前記異常情報に基づく前記車両の異常の種類に応じて、前記第１メンテナンス場および前記第２メンテナンス場の少なくとも一方における前記車両のメンテナンスの時間の長さを決定する、請求項２に記載のサーバ。

【請求項4】

前記サーバ側制御部は、前記異常の種類と、前記第１スケジュール情報および前記第２スケジュール情報の前記少なくとも一方とに基づいて、前記第１メンテナンス場および前記第２メンテナンス場の少なくとも一方における前記車両のメンテナンスの時間帯を決定する、請求項３に記載のサーバ。

【請求項5】

前記状態情報は、前記車両における部品の交換を要することを示す情報を含み、
前記異常の種類は、交換を要する前記部品の種類を含み、
前記サーバ側制御部は、前記部品の種類に応じて、前記車両のメンテナンスの時間の長さを決定する、請求項３または４に記載のサーバ。

【請求項6】

前記状態情報は、前記車両における部品の交換を要することを示す情報を含み、
前記異常の種類は、交換を要する前記部品の前記車両における配置位置を含み、
前記サーバ側制御部は、前記配置位置に応じて、前記車両のメンテナンスの時間の長さを決定する、請求項３～５のいずれか１項に記載のサーバ。

【請求項7】

前記状態情報は、前記搭載制御装置の状態に関する情報を含み、
前記第１メンテナンス場は、前記搭載制御装置の制御的なメンテナンスは不可能である一方で前記搭載制御装置の部品交換が可能な、前記車両の第２販売店を含み、
前記第２メンテナンス場は、前記搭載制御装置の制御的なメンテナンスおよび前記搭載制御装置の部品交換が可能な第２メンテナンスセンタを含み、
前記サーバ側制御部は、前記搭載制御装置の状態に関する情報を含む前記状態情報と、前記第１スケジュール情報および前記第２スケジュール情報の少なくとも一方とに基づいて、前記第２販売店および前記第２メンテナンスセンタにおける前記搭載制御装置のメンテナンスのスケジュールを決定する、請求項２～６のいずれか１項に記載のサーバ。

【請求項8】

前記状態情報は、前記搭載制御装置における部品の交換が必要であることを示す情報を含み、
前記第１スケジュール情報は、前記第２販売店における前記部品の在庫によって前記部品の交換を行うことが可能か否かを示す情報を含み、
前記サーバ側制御部は、
前記第１スケジュール情報に基づいて前記第２販売店において前記部品の在庫が不足していないと判断した場合に、前記第２販売店において前記部品の交換を行うことを決定し、
前記第１スケジュール情報に基づいて前記第２販売店において前記部品の在庫が不足していると判断した場合に、前記第２メンテナンスセンタにおいて前記部品の交換を行うことを決定する、請求項７に記載のサーバ。

【請求項9】

前記第２販売店において、前記搭載制御装置の取り外しがさらに可能であり、
前記状態情報は、前記搭載制御装置の制御的な異常を示す情報を含み、
前記第１スケジュール情報は、前記第２販売店における混雑状況に関する情報を含み、
前記サーバ側制御部は、
前記第１スケジュール情報に基づいて前記第２販売店が混雑していないと判断した場合、前記第２販売店において前記搭載制御装置を前記車両から取り外し、前記第２メンテナンスセンタにおいて、取り外された前記搭載制御装置の制御的なメンテナンスを行うことを決定し、
前記第１スケジュール情報に基づいて前記第２販売店が混雑していると判断した場合に、前記第２販売店において前記搭載制御装置を前記車両から取り外さずに、前記第２メンテナンスセンタにおいて、前記搭載制御装置の制御的なメンテナンスを行うことを決定する、請求項７または８に記載のサーバ。

【請求項10】

前記サーバ側制御部は、前記状態情報に基づいて、前記搭載制御装置が異常であり、かつ、前記車両本体が異常である一方で前記車両の走行は可能であると判断した場合に、前記第１販売店において前記車両のメンテナンスを行うことを決定する、請求項１～９のいずれか１項に記載のサーバ。

【請求項11】

前記状態情報は、前記搭載制御装置の状態に関する情報と、前記車両本体の状態に関する情報とを含み、
前記サーバ側通信部は、前記複数の車両の各々から直接的に前記車両本体の状態に関する情報を取得するとともに、前記複数の車両の各々と通信する管理サーバを介して前記複数の車両の各々の前記搭載制御装置の状態に関する情報を取得する、請求項１～１０のいずれか１項に記載のサーバ。

【請求項12】

前記状態情報は、前記車両の異常箇所のメンテナンスを要求するメンテナンス要求信号を含み、
前記サーバ側制御部は、前記複数の車両の各々から前記メンテナンス要求信号が取得されるように、前記サーバ側通信部を制御する、請求項１～１１のいずれか１項に記載のサーバ。

【発明の詳細な説明】

【技術分野】

【0001】

本開示は、サーバに関する。

【背景技術】

【0002】

たとえば、特開２０２０－１０７０７４号公報（特許文献１）に記載のサービス提供システムは、ユーザから車両のメンテナンスの依頼を受けた場合に、ユーザ端末に配信した第１鍵情報とは別の第２鍵情報を役務提供者端末に配信する。役務提供者は、第２鍵情報が配信された自身の役務提供者端末を用いて、車両を運転することができる。役務提供者は、車両を自ら運転して整備場まで運んでメンテナンス作業を実施し、メンテナンス完了後、車両を運転して元の駐車位置に戻す。

【先行技術文献】

【特許文献】

【0003】

【文献】特開２０２０－１０７０７４号公報

【発明の概要】

【発明が解決しようとする課題】

【0004】

上記特許文献１に記載のサービス提供システムは、上記のように、ユーザから車両のメンテナンスの依頼を受けた場合に、役務提供者による車両の運転を可能にする第２鍵情報を役務提供者端末に配信する。しかしながら、上記特許文献１には、車両のメンテナンスが行われる場所が複数（第１メンテナンス場および第２メンテナンス場）あることが考慮されていない。この場合、ユーザは、車両の状態（異常状態）に基づいて、第１メンテナンス場および第２メンテナンス場のいずれにおいてメンテナンスを行うかを選択する必要がある。このため、何らかの要因（たとえば第１メンテナンス場および第２メンテナンス場の知名度の差）によってユーザの選択が第１メンテナンス場および第２メンテナンス場の一方に集中することに起因して、上記一方におけるメンテナンスの効率が悪化する場合がある。したがって、第１メンテナンス場および第２メンテナンス場における車両のメンテナンスの効率が悪化するのを抑制することが望まれている。

【0005】

本開示は、かかる課題を解決するためになされたものであり、本開示の目的は、第１メンテナンス場および第２メンテナンス場における車両のメンテナンスの効率が悪化するのを抑制することが可能なサーバを提供することである。

【課題を解決するための手段】

【0006】

本開示の一の局面に従うサーバは、複数の車両の各々を管理するサーバであって、複数の車両の各々と、複数の車両のメンテナンスを実施する第１メンテナンス場および第２メンテナンス場と、通信するサーバ側通信部と、複数の車両の各々の状態に関する状態情報が取得されるように、サーバ側通信部を制御するサーバ側制御部と、を備え、複数の車両の各々は、車両本体と、車両本体の運転支援制御および自動運転制御の少なくとも一方を実施するとともに、車両本体に取り付けられた搭載制御装置と、サーバ側通信部と通信する車両側通信部と、を含み、第１メンテナンス場は、車両本体のメンテナンスが実施可能であり、第２メンテナンス場は、搭載制御装置のメンテナンスが実施可能であり、サーバ側制御部は、上記状態情報に基づいて、第１メンテナンス場および第２メンテナンス場の少なくとも一方における車両のメンテナンスの割り当てを決定する。

【0007】

上記一の局面に従うサーバでは、上記のように、サーバ側制御部は、車両の状態情報に基づいて、第１メンテナンス場および第２メンテナンス場の少なくとも一方における車両のメンテナンスの割り当てを決定する。これにより、サーバ側制御部により自動的にメンテナンス先が決定される。その結果、ユーザによりメンテナンス先が選択されないので、何らかの要因（たとえば第１メンテナンス場および第２メンテナンス場の知名度の差）に起因して、第１メンテナンス場および第２メンテナンス場のいずれか一方に選択が集中するのを抑制することができる。これにより、第１メンテナンス場および第２メンテナンス場における車両のメンテナンスの効率が悪化するのを抑制することができる。

【0008】

上記一の局面に従うサーバにおいて、好ましくは、サーバ側通信部は、第１メンテナンス場の第１スケジュール情報、および、第２メンテナンス場の第２スケジュール情報を取得可能であり、サーバ側制御部は、上記状態情報と、第１スケジュール情報および第２スケジュール情報の少なくとも一方とに基づいて、第１メンテナンス場および第２メンテナンス場の少なくとも一方における車両のメンテナンスのスケジュールを決定する。このように構成すれば、メンテナンスのスケジュールがサーバ側通信部により決定されるので、ユーザがメンテナンスのスケジュールを決定する（メンテナンス時間を決定する）必要がない。その結果、ユーザの手間をより低減することができる。

【0009】

この場合、好ましくは、上記状態情報は、車両における異常情報を含み、サーバ側制御部は、異常情報に基づく車両の異常の種類に応じて、第１メンテナンス場および第２メンテナンス場の少なくとも一方における車両のメンテナンスの時間の長さを決定する。このように構成すれば、異常の種類に応じたメンテナンスの種類ごとに、メンテナンスの時間の長さを適切に設定することができる。その結果、より確実にメンテナンスを予定時間内に完了させることができる。

【0010】

上記サーバ側制御部がメンテナンスの時間の長さを決定するサーバにおいて、好ましくは、サーバ側制御部は、異常の種類と、第１スケジュール情報および第２スケジュール情報の少なくとも一方とに基づいて、第１メンテナンス場および第２メンテナンス場の少なくとも一方における車両のメンテナンスの時間帯を決定する。このように構成すれば、ユーザは、メンテナンスを行う時間帯を決める必要がないので、ユーザの手間をより一層低減することができる。

【0011】

上記サーバ側制御部がメンテナンスの時間の長さを決定するサーバにおいて、好ましくは、上記状態情報は、車両における部品の交換を要することを示す情報を含み、上記異常の種類は、交換を要する部品の種類を含み、サーバ側制御部は、部品の種類に応じて、車両のメンテナンスの時間の長さを決定する。ここで、部品の種類によってメンテナンスに要する時間は互いに異なる。たとえば、車両において重要な部品のメンテナンスには比較的長い時間を要する。したがって、部品の種類に応じてメンテナンスの時間の長さを決定することにより、メンテナンスに要する時間が予定のメンテナンス時間より長くなるのを容易に抑制することができる。

【0012】

上記サーバ側制御部がメンテナンスの時間の長さを決定するサーバにおいて、好ましくは、上記状態情報は、車両における部品の交換を要することを示す情報を含み、異常の種類は、交換を要する部品の車両における配置位置を含み、サーバ側制御部は、配置位置に応じて、車両のメンテナンスの時間の長さを決定する。ここで、部品の配置位置によってメンテナンスに要する時間は互いに異なる。たとえば、車両において重要な部品の近くに配置されている部品のメンテナンスには比較的長い時間を要する。したがって、部品の配置位置に応じてメンテナンスの時間の長さを決定することにより、メンテナンスに要する時間が予定のメンテナンス時間より長くなるのをより一層容易に抑制することができる。

【0013】

上記サーバ側制御部がメンテナンスのスケジュールを決定するサーバにおいて、好ましくは、上記状態情報は、搭載制御装置の状態に関する情報を含み、第１メンテナンス場は、搭載制御装置の制御的なメンテナンスは不可能である一方で搭載制御装置の部品交換が可能な、車両の第１販売店を含み、第２メンテナンス場は、搭載制御装置の制御的なメンテナンスおよび搭載制御装置の部品交換が可能な第１メンテナンスセンタを含み、サーバ側制御部は、搭載制御装置の状態に関する情報を含む状態情報と、第１スケジュール情報および第２スケジュール情報の少なくとも一方とに基づいて、第１販売店および第１メンテナンスセンタにおける搭載制御装置のメンテナンスのスケジュールを決定する。ここで、サーバ側制御部により搭載制御装置のメンテナンスのスケジュールが決定されることにより、ユーザがメンテナンス先を決定する場合に比べて、第１販売店（または第１メンテナンスセンタ）がメンテナンス先として集中的に選択されるのを効果的に抑制することができる。

【0014】

この場合、好ましくは、上記状態情報は、搭載制御装置における部品の交換が必要であることを示す情報を含み、第１スケジュール情報は、第１販売店における部品の在庫によって部品の交換を行うことが可能か否かを示す情報を含み、サーバ側制御部は、第１スケジュール情報に基づいて第１販売店において部品の在庫が不足していないと判断した場合に、第１販売店において部品の交換を行うことを決定し、第１スケジュール情報に基づいて第１販売店において部品の在庫が不足していると判断した場合に、第１メンテナンスセンタにおいて部品の交換を行うことを決定する。このように構成すれば、部品の在庫が不足している第１販売店がメンテナンス先として選択されるのを抑制することができる。また、第１販売店において部品の在庫が不足していないのに第１メンテナンスセンタがメンテナンス先として選択されるのを抑制することができる。

【0015】

上記状態情報が搭載制御装置の状態に関する情報を含むサーバにおいて、好ましくは、第１販売店において、搭載制御装置の取り外しがさらに可能であり、状態情報は、搭載制御装置の制御的な異常を示す情報を含み、第１スケジュール情報は、第１販売店における混雑状況に関する情報を含み、サーバ側制御部は、第１スケジュール情報に基づいて第１販売店が混雑していないと判断した場合、第１販売店において搭載制御装置を車両から取り外し、第１メンテナンスセンタにおいて、取り外された搭載制御装置の制御的なメンテナンスを行うことを決定し、第１スケジュール情報に基づいて第１販売店が混雑していると判断した場合に、第１販売店において搭載制御装置を車両から取り外さずに、第１メンテナンスセンタにおいて、搭載制御装置の制御的なメンテナンスを行うことを決定する。このように構成すれば、混雑している第１販売店がメンテナンス先として選択されるのを抑制することができる。また、第１販売店が混雑していないのに第１メンテナンスセンタがメンテナンス先として選択されるのを抑制することができる。

【0016】

上記一の局面に従うサーバにおいて、好ましくは、上記状態情報は、搭載制御装置の状態に関する情報と、車両本体の状態に関する情報とを含み、第１メンテナンス場は、車両本体のメンテナンスが可能な車両の第２販売店を含み、第２メンテナンス場は、搭載制御装置の制御的なメンテナンスは可能である第２メンテナンスセンタを含み、サーバ側制御部は、状態情報に基づいて車両本体が異常であると判断した場合に、第２販売店において車両本体のメンテナンスを行うことを決定する。このように構成すれば、車両本体が異常である場合に、車両本体のメンテナンスが可能な第２販売店をメンテナンス先として選択することができる。

【0017】

この場合、好ましくは、サーバ側制御部は、上記状態情報に基づいて、搭載制御装置が異常であり、かつ、車両本体が異常である一方で車両の走行は可能であると判断した場合に、第２販売店において車両のメンテナンスを行うことを決定する。このように構成すれば、搭載制御装置が異常であり、かつ、車両本体が異常である一方で走行は可能である車両のメンテナンス先として、第２メンテナンスセンタが選択されるのを抑制することができる。

【0018】

上記一の局面に従うサーバにおいて、好ましくは、上記状態情報は、搭載制御装置の状態に関する情報と、車両本体の状態に関する情報とを含み、サーバ側通信部は、複数の車両の各々から直接的に車両本体の状態に関する情報を取得するとともに、複数の車両の各々と通信する管理サーバを介して複数の車両の各々の搭載制御装置の状態に関する情報を取得する。このように構成すれば、サーバ側通信部は、車両本体の状態に関する情報と、搭載制御装置の状態に関する情報とを、別々の通信相手（車両および管理サーバ）から取得することができる。その結果、車両および管理サーバの一方との通信が途絶えても、車両および管理サーバの他方から情報（車両本体の状態または搭載制御装置の状態の情報）を取得することができる。

【0019】

上記一の局面に従うサーバにおいて、好ましくは、上記状態情報は、車両の異常箇所のメンテナンスを要求するメンテナンス要求信号を含み、サーバ側制御部は、複数の車両の各々からメンテナンス要求信号が取得されるように、サーバ側通信部を制御する。このように構成すれば、取得されるメンテナンス要求信号に基づいて、第１メンテナンス場および第２メンテナンス場の少なくとも一方における車両のメンテナンスの割り当てを容易に決定することができる。

【発明の効果】

【0020】

本開示によれば、第１メンテナンス場および第２メンテナンス場における車両のメンテナンスの効率が悪化するのを抑制することができる。

【図面の簡単な説明】

【0021】

【図1】一実施の形態による運行管理センタを含むＭａａＳシステムを示す図である。

【図2】ＡＤＫの概略的な構成を示す図である。

【図3】ディーラおよびＡＤＫメンテナンスセンタの実施可能なメンテナンスを示す図である。

【図4】車両の異常状態とメンテナンスの時間（時間帯）との関係を示す図である。

【図5】車両（ＡＤＫ）の部品の重要度とメンテナンスの時間との関係を示す図である。

【図6】ＬＩＤＡＲおよび各種部品の間の距離とメンテナンスの時間との関係を示す図である。

【図7】運行管理センタ等の制御シーケンスを示すシーケンス図である。

【図8】運行管理センタのステップＳ１０以降（図７の分岐Ａ）のフローを示すフロー図である。

【図9】運行管理センタのステップＳ２０以降（図７の分岐Ｂ）のフローを示すフロー図である。

【発明を実施するための形態】

【0022】

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

【0023】

図１は、本開示の実施の形態に従う運行管理センタ１００が用いられるＭａａＳ（Mobility as a Service）システムの概要を示す図である。運行管理センタ１００は、複数の車両１０を管理するサーバである。なお、運行管理センタ１００は、本開示の「サーバ」の一例である。

【0024】

図１を参照して、このＭａａＳシステムは、車両１０と、ＡＤＫ（Autonomous Driving Kit）管理サーバ２０と、運行管理センタ１００と、ディーラ３０のサーバ３１と、ＡＤＫメンテナンスセンタ４０のサーバ４１と、を備える。車両１０は、ＡＤＫ１１を備える。なお、ＡＤＫ管理サーバ２０（後述の２０ａ、２０ｂ）は、本開示の「管理サーバ」の一例である。また、ディーラ３０は、本開示の「第１メンテナンス場」、「第１販売店」、および、「第２販売店」の一例である。また、ＡＤＫメンテナンスセンタ４０は、本開示の「第２メンテナンス場」、「第１メンテナンスセンタ」、および、「第２メンテナンスセンタ」の一例である。また、ＡＤＫ１１（後述の１１ａ、１１ｂ）は、本開示の「搭載制御装置」の一例である。

【0025】

複数の車両１０は、複数の車両１０ａと、複数の車両１０ｂとを含む。ＡＤＫ１１は、ＡＤＫ１１ａと、ＡＤＫ１１ｂとを含む。車両１０ａ（１０ｂ）は、ＡＤＫ１１ａ（１１ｂ）と、車両本体１２と、車両制御インターフェース１３と、ＤＣＭ（Data Communication Module）１４とを備える。また、車両本体１２は、車両プラットフォーム（以下、「ＶＰ（Vehicle Platform）」と称する）１２ａを含む。なお、車両１０ａおよび車両１０ｂは、ＡＤＫ１１ａ（１１ｂ）以外の部分同士が互いに異なる構成であってもよい。また、ＤＣＭ１４は、本開示の「車両側通信部」の一例である。

【0026】

なお、以下の説明において、単に「車両１０」と記載されている場合は、車両１０ａおよび車両１０ｂに共通する事項である。また、以下の説明において、単に「ＡＤＫ１１」と記載されている場合は、ＡＤＫ１１ａおよびＡＤＫ１１ｂに共通する事項である。

【0027】

ＡＤＫ１１は、車両本体１２の運転支援制御および自動運転制御を実施する。また、ＡＤＫ１１は、車両本体１２に取り付けられている。具体的には、ＡＤＫ１１は、車両本体１２のルーフトップなどに取り付けられる。

【0028】

車両制御インターフェース１３は、ＣＡＮ（Controller Area Network）等を通じてＡＤＫ１１と通信可能である。車両制御インターフェース１３は、通信される信号毎に定義された所定のＡＰＩ（Application Program Interface）を実行することにより、ＡＤＫ１１から各種コマンドを受信する。また、車両制御インターフェース１３は、車両本体１２の状態をＡＤＫ１１へ出力する。

【0029】

車両制御インターフェース１３は、ＡＤＫ１１からコマンドを受信すると、そのコマンドに対応する制御コマンドをＶＰ１２ａへ出力する。また、車両制御インターフェース１３は、車両本体１２の各種情報をＶＰ１２ａから取得し、車両本体１２の状態をＡＤＫ１１へ出力する。

【0030】

ＶＰ１２ａは、車両本体１２を制御するための各種システムおよび各種センサを含む。ＶＰ１２ａは、ＡＤＫ１１から車両制御インターフェース１３を通じて指示されるコマンドに従って各種車両制御を実行する。すなわち、ＡＤＫ１１からのコマンドに従ってＶＰ１２ａが各種車両制御を実行することにより、車両１０の自動運転および運転支援が行われる。

【0031】

ＡＤＫ１１は、車両１０の走行計画を作成する。ＡＤＫ１１は、走行計画に従って車両１０を走行させるための各種制御要求を、制御要求毎に定義されたＡＰＩに従ってＶＰ１２ａに出力する。また、ＡＤＫ１１は、車両状態（ＶＰ１２ａの状態）を示す各種信号を、信号毎に定義されたＡＰＩに従ってＶＰ１２ａから受ける。そして、ＡＤＫ１１は、車両状態を走行計画に反映する。ＡＤＫ１１は、上記走行計画や走行情報等を、ＡＤＫ管理サーバ２０に送信する。また、ＡＤＫ１１をＶＰ１２ａから取り外すことも可能である。

【0032】

図２は、ＡＤＫ１１の概略的な構成を示す図である。図２に示すように、ＡＤＫ１１は、２つの制御モジュール１１０と、ＬＩＤＡＲ（（Laser Imaging Detection and Ranging）１１１と、カメラ１１２と、センサ１１３とを含む。２つの制御モジュール１１０のうちの一方は、冗長用（予備用）のモジュールである。なお、ＬＩＤＡＲ１１１、カメラ１１２、および、センサ１１３の各々は、本開示の「部品」の一例である。

【0033】

ＬＩＤＡＲ１１１は、たとえば赤外パルスのレーザ光を発し、そのレーザ光の対象物からの反射光を検出することによって対象物の距離および方向を計測する。なお、ＬＩＤＡＲ１１１の代わりに（または加えて）ミリ波レーダが設けられていてもよい。制御モジュール１１０は、ＬＩＤＡＲ１１１により計測された上記距離および方向に基づいて、車両１０の走行を制御する。

【0034】

カメラ１１２は、車外の画像を撮像するために設けられている。制御モジュール１１０は、カメラ１１２により撮像された画像と、予め記憶されている各地点に対応する画像との一致度に基づいて、車両１０の走行している位置を把握し、車両１０の走行を制御する。

【0035】

センサ１１３は、車両の姿勢、挙動あるいは位置を検出する姿勢用センサ等を含む。なお、センサ１１３が他の種類のセンサを含んでいてもよい。

【0036】

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

【0037】

車両１０のユーザは、典型的には個人ユーザであるが、これに限定されない。ユーザは、車両１０を用いた自動運転サービスを提供する事業者（タクシー事業者、レンタカー事業者、カーシェア事業者、ライドシェアサービス事業者など）であってもよい。

【0038】

ＡＤＫ管理サーバ２０は、ＡＤＫ１１のメーカによって運営されるサーバである。ＡＤＫ管理サーバ２０は、ＡＤＫ管理サーバ２０ａと、ＡＤＫ管理サーバ２０ｂとを含む。ＡＤＫ管理サーバ２０ａおよびＡＤＫ管理サーバ２０ｂは、互いに異なるメーカによって運営されている。

【0039】

ＡＤＫ管理サーバ２０ａは、複数の車両１０ａの各々のＡＤＫ１１ａと通信可能である。また、ＡＤＫ管理サーバ２０ｂは、複数の車両１０ｂの各々のＡＤＫ１１ｂと通信可能である。なお、以下の説明において、単に「ＡＤＫ管理サーバ２０」と記載されている場合は、ＡＤＫ管理サーバ２０ａおよびＡＤＫ管理サーバ２０ｂに共通する事項である。ＡＤＫ管理サーバ２０は、ＡＤＫ１１から、ＡＤＫ１１の状態（異常状態）に関する情報を収集する。

【0040】

運行管理センタ１００は、プロセッサ１０１と、記憶装置１０２と、通信部１０３とを備える。プロセッサ１０１は、所定の情報処理を行う。記憶装置１０２は、各種情報を保存可能に構成される。記憶装置１０２には、プロセッサ１０１により実行されるプログラムのほか、プログラムにおいて使用される情報（たとえば、マップ、数式、および各種パラメータ）が記憶されている。通信部１０３は、各種通信Ｉ／Ｆを含む。なお、プロセッサ１０１および通信部１０３は、それぞれ、本開示の「サーバ側制御部」および「サーバ側通信部」の一例である。

【0041】

通信部１０３は、複数の車両１０の各々のＤＣＭ１４と、ＡＤＫ管理サーバ２０（２０ａ、２０ｂ）の各々と通信する。また、通信部１０３は、ディーラ３０およびＡＤＫメンテナンスセンタ４０の各々と通信する。具体的には、通信部１０３は、ディーラ３０を管理するサーバ３１およびＡＤＫメンテナンスセンタ４０を管理するサーバ４１の各々と通信する。

【0042】

サーバ３１は、ディーラ３０のスケジュール等を管理している。また、サーバ４１は、ＡＤＫメンテナンスセンタ４０のスケジュール等を管理している。通信部１０３は、サーバ３１からディーラ３０のスケジュール情報を取得可能であるとともに、サーバ４１からＡＤＫメンテナンスセンタ４０のスケジュール情報を取得可能である。なお、ディーラ３０のスケジュール情報、および、ＡＤＫメンテナンスセンタ４０のスケジュール情報は、それぞれ、本開示の「第１スケジュール情報」および「第２スケジュール情報」の一例である。

【0043】

図１では、簡略化のため、ディーラ３０およびＡＤＫメンテナンスセンタ４０の各々は１つずつしか図示されていないが、ディーラ３０およびＡＤＫメンテナンスセンタ４０の各々が複数設けられていてもよい。複数のディーラ３０（ＡＤＫメンテナンスセンタ４０）の各々に対してサーバ３１（サーバ４１）が１つずつ設けられていてもよいし、複数のディーラ３０（ＡＤＫメンテナンスセンタ４０）に対して１つのサーバ３１（サーバ４１）が設けられていてもよい。

【0044】

ディーラ３０およびＡＤＫメンテナンスセンタ４０の各々は、複数の車両１０のメンテナンスを実施する。具体的には、図３に示すように、ディーラ３０において、車両本体１２のメンテンナスが実施可能である。また、ディーラ３０において、ＡＤＫ１１の部品交換が可能である。なお、ディーラ３０において、ＡＤＫ１１の制御的なメンテナンスは不可能である。また、ディーラ３０において、ＡＤＫ１１の取り外しが可能である。

【0045】

また、ＡＤＫメンテナンスセンタ４０において、ＡＤＫ１１のメンテナンスが実施可能である。具体的には、ＡＤＫメンテナンスセンタ４０において、ＡＤＫ１１の制御的なメンテナンスが可能である。また、ＡＤＫメンテナンスセンタ４０において、ＡＤＫ１１の部品交換が可能である。なお、ＡＤＫメンテナンスセンタ４０において、車両本体１２のメンテナンスは不可能である。

【0046】

また、運行管理センタ１００は、登録された複数の車両１０の情報（以下、「車両情報」とも称する）と、登録された各ユーザの情報（以下、「ユーザ情報」とも称する）と、登録された各ＡＤＫの情報（以下、「車両情報」とも称する）と、を管理するように構成される。ユーザ情報、車両情報、および、ＡＤＫ情報は、識別情報（ＩＤ）で区別されて記憶装置１０２に記憶されている。

【0047】

運行管理センタ１００は、複数の車両１０の各々の状態に関する状態情報が取得されるように、通信部１０３を制御する。具体的には、運行管理センタ１００の通信部１０３は、複数の車両１０（ＤＣＭ１４）の各々から直接的に車両本体１２（ＶＰ１２ａ）の状態に関する情報を取得する。以下、この情報を「車両本体状態情報」とも記載する。運行管理センタ１００は、複数の車両１０から取得された車両本体状態情報を記憶装置１０２に格納する。なお、通信部１０３は、ＡＤＫ管理サーバ２０を介して間接的に、複数の車両１０の各々から車両本体状態情報を取得してもよい。

【0048】

また、運行管理センタ１００の通信部１０３は、複数の車両１０の各々と通信するＡＤＫ管理サーバ２０を介して、複数の車両１０の各々のＡＤＫ１１の状態に関する情報を取得する。以下、この情報を「ＡＤＫ状態情報」とも記載する。運行管理センタ１００は、複数の車両１０から取得されたＡＤＫ状態情報を記憶装置１０２に格納する。なお、通信部１０３は、複数の車両１０（ＡＤＫ１１）の各々から直接的にＡＤＫ状態情報を取得してもよい。

【0049】

また、上記状態情報（車両本体状態情報およびＡＤＫ状態情報）は、車両１０（ＡＤＫ１１および車両本体１２）の異常個所のメンテナンスを要求するメンテナンス要求信号を含む。したがって、プロセッサ１０１は、複数の車両１０の各々からメンテナンス要求信号が取得されるように、通信部１０３を制御する。

【0050】

また、運行管理センタ１００の通信部１０３は、取得された状態情報（車両本体状態情報およびＡＤＫ状態情報）をディーラ３０のサーバ３１およびＡＤＫメンテナンスセンタ４０のサーバ４１の少なくとも一方に送信する。通信部１０３は、ディーラ３０のサーバ３１に上記状態情報を送信することにより、サーバ３１からディーラ３０のスケジュール情報を取得する。また、通信部１０３は、ＡＤＫメンテナンスセンタ４０のサーバ４１に上記状態情報を送信することにより、サーバ４１からＡＤＫメンテナンスセンタ４０のスケジュール情報を取得する。

【0051】

ここで、従来のシステムでは、ユーザは、第１メンテナンス場（ディーラ）および第２メンテナンス場（ＡＤＫメンテナンスセンタ）のいずれにおいてメンテナンスを行うかを選択する（メンテナンスのスケジュールを考える）必要がある。このため、何らかの要因（たとえば第１メンテナンス場および第２メンテナンス場の知名度の差）によってユーザの選択が第１メンテナンス場および第２メンテナンス場の一方に集中することに起因して、上記一方におけるメンテナンスの効率が悪化する場合がある。したがって、第１メンテナンス場および第２メンテナンス場における車両のメンテナンスの効率が悪化するのを抑制することが望まれている。

【0052】

そこで、本実施の形態では、プロセッサ１０１は、上記状態情報（メンテナンス要求信号）に基づいて、ディーラ３０およびＡＤＫメンテナンスセンタ４０の少なくとも一方における車両１０のメンテナンスの割り当てを決定する。具体的には、プロセッサ１０１は、上記状態情報に基づいて検知されたＡＤＫ１１および車両本体１２の少なくとも一方の状態（異常状態）に対応するメンテナンスを実施するためのメンテナンス先（メンテナンス実施場所）を決定する。

【0053】

たとえば、上記状態情報が、車両本体１２の異常を示す情報を含んでいる場合、車両本体１２のメンテナンスが可能なディーラ３０に、メンテナンスが割り当てられる。また、上記状態情報が、ＡＤＫ１１の制御的な異常を示す情報を含んでいる場合、ＡＤＫ１１の制御的なメンテナンスが可能なＡＤＫメンテナンスセンタ４０に、メンテナンスが割り当てられる。なお、上記状態情報が、車両本体１２の異常を示す情報およびＡＤＫ１１の制御的な異常を示す情報の両方を含んでいる場合、ディーラ３０およびＡＤＫメンテナンスセンタ４０の両方に、メンテナンスが割り当てられる。

【0054】

また、プロセッサ１０１は、上記状態情報と、ディーラ３０のスケジュール情報およびＡＤＫメンテナンスセンタ４０のスケジュール情報の少なくとも一方とに基づいて、ディーラ３０およびＡＤＫメンテナンスセンタ４０の少なくとも一方における車両１０のメンテナンスのスケジュールを決定する。プロセッサ１０１は、上記状態情報に基づいて検知された車両１０の異常に対応するメンテナンス先において、メンテナンスが実施可能な時間帯にメンテナンスを行うことを決定する。ディーラ３０およびＡＤＫメンテナンスセンタ４０の少なくとも一方において上記時間帯にメンテナンスの予約がされるように、プロセッサ１０１は通信部１０３を制御してもよい。

【0055】

ここで、上記状態情報は、車両１０における異常情報を含んでいる。この場合、プロセッサ１０１は、上記異常情報に基づく車両１０の異常の種類に応じて、ディーラ３０およびＡＤＫメンテナンスセンタ４０の少なくとも一方における車両１０のメンテナンスの時間の長さを決定する。

【0056】

たとえば、プロセッサ１０１は、ＡＤＫ１１の異常内容に基づいて、メンテナンスの重要度を判別する。図４に示すように、プロセッサ１０１は、ＡＤＫ１１の２つの制御モジュール１１０（図２参照）が両方とも異常である場合、メンテナンスの重要度が重度であると判別する。また、プロセッサ１０１は、ＡＤＫ１１の２つの制御モジュール１１０のうち１つが異常である場合、メンテナンスの重要度が中度であると判別する。また、カメラ１１２（図２参照）の画像が乱れている場合、カメラ１１２のレンズを拭くだけで異常が解消される可能性が大きい。したがって、この場合、プロセッサ１０１は、メンテナンスの重要度が低度であると判別する。なお、上記の重要度の判別の例は、あくまで一例であり、これに限られない。

【0057】

また、上記のメンテナンスの重要度は、ディーラ３０のサーバ３１およびＡＤＫメンテナンスセンタ４０のサーバ４１によって判別されてもよい。この場合、サーバ３１（４１）は、スケジュール情報と共に上記重要度に関する情報を運行管理センタ１００に送信する。

【0058】

そして、プロセッサ１０１は、判別されたメンテナンスの重要度に基づいて、メンテナンスの時間の長さを決定する。プロセッサ１０１は、メンテナンスの重要度が高度、中度、および、低度の場合に、それぞれ、メンテナンス時間を長時間（たとえば５時間）、中時間（たとえば３時間）、および、短時間（たとえば１時間）に決定する。なお、上記の例では、メンテナンスの重要度（メンテナンス時間）が３段階に分けられているが、これに限られない。メンテナンスの重要度（メンテナンス時間）が２段階、または、４段階以上に分けられていてもよい。

【0059】

また、プロセッサ１０１は、上記異常の種類と、ディーラ３０のスケジュール情報およびＡＤＫメンテナンスセンタ４０のスケジュール情報の少なくとも一方とに基づいて、ディーラ３０およびＡＤＫメンテナンスセンタ４０の少なくとも一方における車両１０のメンテナンスの時間帯を決定する。具体的には、プロセッサ１０１は、メンテナンスの重要度に基づいて決定されたメンテナンスの時間と、ディーラ３０およびＡＤＫメンテナンスセンタ４０の各々におけるメンテナンスが可能な時間帯（予約の空き時間）とに基づいて、メンテナンスを行う時間帯を決定する。

【0060】

たとえば、２つの制御モジュール１１０が異常の場合、プロセッサ１０１は、ＡＤＫ１１の制御的なメンテナンスが可能なＡＤＫメンテナンスセンタ４０において上記長時間のメンテナンスが可能な時間帯（たとえば１２：００～１７：００）を、メンテナンスを行う時間帯に決定する。また、１つの制御モジュール１１０が異常の場合、プロセッサ１０１は、ＡＤＫメンテナンスセンタ４０において上記中時間のメンテナンスが可能な時間帯（たとえば１５：００～１８：００）を、メンテナンスを行う時間帯に決定する。

【0061】

また、カメラ１１２の画像が乱れている場合、プロセッサ１０１は、ディーラ３０またはＡＤＫメンテナンスセンタ４０において上記短時間のメンテナンスが可能な時間帯（たとえばディーラ３０の１０：００～１１：００）を、メンテナンスを行う時間帯に決定する。

【0062】

なお、メンテナンスが実施可能な時間帯が複数ある場合は、プロセッサ１０１は、そのうちの最も早い時間帯を選択してもよいし、車両１０の走行予定に基づいて時間帯を選択してもよい。また、プロセッサ１０１は、ディーラ３０およびＡＤＫメンテナンスセンタ４０のどちらでもメンテナンスが可能な場合は、ディーラ３０およびＡＤＫメンテナンスセンタ４０の各々の混雑状況に基づいて上記時間帯を選択してもよい。

【0063】

なお、上記のメンテナンスの時間（時間帯）の例はあくまで一例であり、これらに限られない。また、車両本体１２の異常についても、上記と同様に、異常の種類（メンテナンスの重要度）に基づいてメンテナンスの時間（時間帯）が決定されてもよい。

【0064】

また、上記状態情報が、車両１０における部品の交換を要することを示す情報を含むとする。この場合、上記異常の種類は、交換を要する部品の種類を含む。

【0065】

ここで、本実施の形態では、プロセッサ１０１は、上記交換を要する部品の種類に応じて、車両１０のメンテナンスの時間の長さを決定する。具体的には、各種部品には、個別に重要度が設定されている。たとえば、図５に示すように、ＬＩＤＡＲ１１１、カメラ１１２、センサ１１３の順に重要度が高く設定されている。そして、プロセッサ１０１は、重要度が高い部品の交換ほど、作業時間（メンテナンス時間）を長くしてもよい。なお、上記ではＡＤＫ１１の部品を例に挙げたが、車両本体１２の部品についても同様にメンテナンス時間が決定されてもよい。

【0066】

また、上記異常の種類は、交換を要する部品の車両１０における配置位置を含んでいてもよい。この場合、プロセッサ１０１は、上記配置位置に応じて、車両１０のメンテナンスの時間の長さを決定してもよい。たとえば、図６に示すように、プロセッサ１０１は、ＬＩＤＡＲ１１１との間の距離が比較的小さい部品の交換に要するメンテンナスの時間を、比較的長くしてもよい。

【0067】

図２に示す例では、カメラ１１２とＬＩＤＡＲ１１１との間の距離Ｌ１がセンサ１１３とＬＩＤＡＲ１１１との間の距離Ｌ２よりも小さいので、カメラ１１２の交換時間（メンテナンス時間）をセンサ１１３の交換時間（メンテナンス時間）よりも長く設定してもよい。なお、上記ではＡＤＫ１１の部品を例に挙げたが、車両本体１２の部品についても同様の制御が行われてもよい。

【0068】

また、同種の部品同士の間においても、ＬＩＤＡＲ１１１との距離に応じてメンテナンス時間を互いに異ならせてもよい。なお、記憶装置１０２には、各部品とＬＩＤＡＲ１１１との間の距離の情報が格納されていてもよい。また、ＬＩＤＡＲ１１１以外の部分を距離の基準としてもよい。

【0069】

そして、プロセッサ１０１は、各部品ごとに決定されたメンテナンス時間の長さと、ディーラ３０およびＡＤＫメンテナンスセンタ４０の各々のスケジュール情報とに基づいて、メンテナンスを行う時間帯を決定する。

【0070】

なお、プロセッサ１０１は、上記の部品ごとに予め設定された重要度、および、ＬＩＤＡＲ１１１との間の距離の両方を考慮して、メンテナンスの時間帯を決定してもよい。また、プロセッサ１０１は、上記の部品ごとに予め設定された重要度、および、ＬＩＤＡＲ１１１との間の距離のいずれか一方のみを考慮して、メンテナンスの時間帯を決定してもよい。

【0071】

（スケジュール決定のシーケンス制御）
次に、図７～図９を参照して、運行管理センタ１００（プロセッサ１０１）によるメンテナンスのスケジュール決定のシーケンス制御について説明する。

【0072】

図７に示すように、まず、ステップＳ１において、車両１０のＡＤＫ１１は、ＡＤＫ管理サーバ２０にＡＤＫ状態情報を送信する。また、ステップＳ２では、ＡＤＫ管理サーバ２０は、ステップＳ１において取得されたＡＤＫ状態情報を運行管理センタ１００の通信部１０３に送信する。また、ステップＳ３では、車両１０は、ＤＣＭ１４（図１参照）を通じて運行管理センタ１００の通信部１０３に、車両本体状態情報を送信する。なお、ステップＳ１およびＳ３の順番は、いずれが先でもよいし、互いに同じタイミングであってもよい。

【0073】

次に、ステップＳ４では、運行管理センタ１００の通信部１０３は、ディーラ３０（サーバ３１）に、ステップＳ２およびＳ３において取得されたＡＤＫ状態情報および車両本体状態情報の少なくとも一方を送信する。ステップＳ５では、ディーラ３０（サーバ３１）は、ステップＳ４において上記状態情報が取得されたことに基づいて、ディーラ３０のスケジュール情報を運行管理センタ１００の通信部１０３に送信する。

【0074】

また、ステップＳ６では、運行管理センタ１００の通信部１０３は、ＡＤＫメンテナンスセンタ４０（サーバ４１）に、ステップＳ２およびＳ３において取得されたＡＤＫ状態情報および車両本体状態情報の少なくとも一方を送信する。ステップＳ７では、ＡＤＫメンテナンスセンタ４０（サーバ４１）は、ステップＳ６において上記状態情報が取得されたことに基づいて、ＡＤＫメンテナンスセンタ４０のスケジュール情報を運行管理センタ１００の通信部１０３に送信する。なお、ステップＳ４およびＳ５と、ステップＳ６およびＳ７との順番は、いずれが先でもよいし、互いに同じタイミングであってもよい。

【0075】

次に、ステップＳ８では、運行管理センタ１００（プロセッサ１０１）は、ステップＳ２およびＳ３において取得された状態情報（ＡＤＫ状態情報および車両本体状態情報）に基づいて、車両本体１２に異常があるか否かを判定する。上記状態情報が車両本体１２の異常を示す情報を含まないことにより車両本体１２に異常がないと判定された場合（Ｓ８においてＮｏ）、処理はステップＳ１０（図８参照）（分岐Ａ）に進む。上記状態情報が車両本体１２の異常を示す情報を含むことにより車両本体１２に異常があると判定された場合（Ｓ８においてＹｅｓ）、処理はステップＳ２０（図９参照）（分岐Ｂ）に進む。なお、ステップＳ８では、車両本体１２の異常の判定よりも先にＡＤＫ１１の異常の判定（後述のステップＳ１０およびＳ２１）が行われてもよい。

【0076】

図８に示すように、ステップＳ１０では、運行管理センタ１００（プロセッサ１０１）は、ＡＤＫ１１に異常があるか否かを判定する。上記状態情報がＡＤＫ１１の異常を示す情報を含むことによりＡＤＫ１１に異常があると判定された場合（Ｓ１０においてＹｅｓ）、処理はステップＳ１１に進む。上記状態情報がＡＤＫ１１の異常を示す情報を含まないことによりＡＤＫ１１に異常がないと判定された場合（Ｓ１０においてＮｏ）、処理は終了する。

【0077】

次に、ステップＳ１１では、運行管理センタ１００（プロセッサ１０１）は、ＡＤＫ１１の制御的なメンテナンス（たとえば制御モジュール１１０（図２参照）のメンテナンス）が必要か否かを判定する。上記状態情報がＡＤＫ１１の制御的な異常を示す情報を含むことによりＡＤＫ１１の制御的なメンテナンスが必要であると判定された場合（Ｓ１１においてＹｅｓ）、処理はステップＳ１２に進む。上記状態情報がＡＤＫ１１の制御的な異常を示す情報を含まないことによりＡＤＫ１１の制御的なメンテナンスは必要ないと判定された場合（Ｓ１１においてＮｏ）、処理はステップＳ１３に進む。なお、処理がステップＳ１３に進む場合、上記状態情報は、ＡＤＫ１１における部品の交換が必要であることを示す情報を含んでいる。

【0078】

ここで、ステップＳ５において取得されたディーラ３０のスケジュール情報は、ディーラ３０における混雑状況に関する情報を含む。ステップＳ１２では、運行管理センタ１００（プロセッサ１０１）は、ディーラ３０のスケジュール情報（混雑状況の情報）に基づき、ディーラ３０が混雑している否かを判定する。ディーラ３０が混雑していると判定（判断）された場合（Ｓ１２においてＹｅｓ）、処理はステップＳ１４に進む。ディーラ３０が混雑していないと判定（判断）された場合（Ｓ１２においてＮｏ）、処理はステップＳ１５に進む。なお、プロセッサ１０１は、所定の期間内（たとえば判定時から７日以内）においてディーラ３０におけるメンテナンスの予約が埋まっている場合に、ディーラ３０が混雑していると判定してもよい。

【0079】

なお、車両１０のメンテナンスに対応可能なディーラ３０が複数ある場合、ディーラ３０が混雑しているとは、複数のディーラ３０の全てが混雑していることにより、いずれのディーラ３０でもメンテナンスが不可能な状態を意味する。

【0080】

ステップＳ１４では、運行管理センタ１００（プロセッサ１０１）は、ディーラ３０においてＡＤＫ１１を車両１０（車両本体１２）から取り外さずに、ＡＤＫメンテナンスセンタ４０において、ＡＤＫ１１の制御的なメンテナンスを行うことを決定する。すなわち、プロセッサ１０１は、ＡＤＫ１１が車両本体１２に取り付けられた状態の車両１０を、ＡＤＫメンテナンスセンタ４０においてメンテナンスすることを決定する。

【0081】

また、ステップＳ１５では、運行管理センタ１００（プロセッサ１０１）は、ディーラ３０においてＡＤＫ１１を車両１０（車両本体１２）から取り外し、ＡＤＫメンテナンスセンタ４０において、取り外されたＡＤＫ１１の制御的なメンテナンスを行うことを決定する。この場合、ディーラ３０において取り外されたＡＤＫ１１は、ディーラ３０によってＡＤＫメンテナンスセンタ４０まで郵送されてもよい。

【0082】

また、ステップＳ５において取得されたディーラ３０のスケジュール情報は、ディーラ３０におけるＡＤＫ１１の部品の在庫によって部品の交換を行うことが可能か否かを示す情報を含む。ステップＳ１３では、運行管理センタ１００（プロセッサ１０１）は、ディーラ３０のスケジュール情報（在庫状況）に基づき、ディーラ３０の部品の在庫が不足しているか否かを判定する。ディーラ３０においてＡＤＫ１１の部品の在庫が不足していないと判定（判断）された場合（Ｓ１３においてＮｏ）、処理はステップＳ１６に進む。ディーラ３０においてＡＤＫ１１の部品の在庫が不足していると判定（判断）された場合（Ｓ１３においてＹｅｓ）、処理はステップＳ１７に進む。なお、プロセッサ１０１は、ディーラ３０において部品の在庫が所定数（たとえば０～４つ）以下の場合に、ディーラ３０の部品の在庫が不足していると判定してもよい。

【0083】

なお、車両１０のメンテナンスに対応可能なディーラ３０が複数ある場合、ディーラ３０の部品の在庫が不足しているとは、複数のディーラ３０の全てにおいて在庫が不足していることにより、いずれのディーラ３０でもメンテナンスが不可能な状態を意味する。

【0084】

ステップＳ１６では、運行管理センタ１００（プロセッサ１０１）は、ディーラ３０においてメンテナンス（ＡＤＫ１１の部品の交換）を行うことを決定する。

【0085】

また、ステップＳ１７では、運行管理センタ１００（プロセッサ１０１）は、ＡＤＫメンテナンスセンタ４０においてメンテナンス（ＡＤＫ１１の部品の交換）を行うことを決定する。この場合、プロセッサ１０１は、ＡＤＫ１１が車両本体１２に取り付けられた状態の車両１０を、ＡＤＫメンテナンスセンタ４０においてメンテナンスすることを決定する。

【0086】

そして、ステップＳ１４～Ｓ１７の各々の後のステップＳ１８では、運行管理センタ１００（プロセッサ１０１）は、車両１０のメンテナンスのスケジュールを決定する。具体的には、プロセッサ１０１は、上記状態情報と、ステップＳ５において取得されたディーラ３０のスケジュール情報と、ステップＳ７において取得されたＡＤＫメンテナンスセンタ４０のスケジュール情報とに基づいて、車両１０のメンテナンスのスケジュールを決定する。スケジュールの決定方法の詳細な説明は、上述した通りであるので、説明は繰り返さない。

【0087】

なお、ステップＳ１５では、ディーラ３０およびＡＤＫメンテナンスセンタ４０の各々においてメンテナンス（ＡＤＫ１１の取り外しとＡＤＫ１１の制御的なメンテナンス）が行われる。この場合、ディーラ３０およびＡＤＫメンテナンスセンタ４０の各々においてメンテナンスの予約がされてもよい。具体的には、プロセッサ１０１は、１０：００～１１：００にディーラ３０においてＡＤＫ１１の取り外しを行い、１２：００～１７：００にＡＤＫメンテナンスセンタ４０においてＡＤＫ１１の制御的なメンテナンスを行うようにスケジュールを決定してもよい。

【0088】

一方、図９に示すように、ステップＳ２０では、運行管理センタ１００（プロセッサ１０１）は、車両１０の走行が可能か否を判定する。たとえば、プロセッサ１０１は、ＡＤＫ状態情報および車両本体状態情報の少なくとも一方に基づいて、車両１０の走行が可能か否を判定する。走行が可能と判定された場合（Ｓ２０においてＹｅｓ）、処理はステップＳ２１に進む。走行が不可能であると判定された場合（Ｓ２０においてＮｏ）、処理はステップＳ２２に進む。なお、走行が不可能であると判定された場合（Ｓ２０においてＮｏ）、プロセッサ１０１は、車両１０の運搬のためのレッカー車等を手配するように通信部１０３を制御してもよい。

【0089】

次に、ステップＳ２１では、運行管理センタ１００（プロセッサ１０１）は、ＡＤＫ１１に異常があるか否かを判定する。上記状態情報がＡＤＫ１１の異常を示す情報を含むことによりＡＤＫ１１に異常があると判定された場合（Ｓ２１においてＹｅｓ）、処理はステップＳ２３に進む。上記状態情報がＡＤＫ１１の異常を示す情報を含まないことによりＡＤＫ１１に異常がないと判定された場合（Ｓ２１においてＮｏ）、処理はステップＳ２２に進む。

【0090】

ステップＳ２２では、運行管理センタ１００（プロセッサ１０１）は、ディーラ３０において車両本体１２のメンテナンスを行うことを決定する。なお、ステップＳ２０において、車両１０の走行が不可能であると判定された場合（Ｓ２０においてＮｏ）、プロセッサ１０１は、図示しない車両整備工場において車両１０のメンテナンスを行うことを決定してもよい。

【0091】

ステップＳ２３では、運行管理センタ１００（プロセッサ１０１）は、ＡＤＫ１１の制御的なメンテナンスが必要か否かを判定する。上記状態情報がＡＤＫ１１の制御的な異常を示す情報を含むことによりＡＤＫ１１の制御的なメンテナンスが必要であると判定された場合（Ｓ２３においてＹｅｓ）、処理はステップＳ２４に進む。上記状態情報がＡＤＫ１１の制御的な異常を示す情報を含まないことによりＡＤＫ１１の制御的なメンテナンスは必要ないと判定された場合（Ｓ２３においてＮｏ）、処理はステップＳ２５に進む。なお、処理がステップＳ２５に進む場合、上記状態情報は、ＡＤＫ１１における部品の交換が必要であることを示す情報を含んでいる。

【0092】

ステップＳ２４では、運行管理センタ１００（プロセッサ１０１）は、ディーラ３０のスケジュール情報に基づき、ディーラ３０が混雑している否かを判定する。ディーラ３０が混雑していると判定（判断）された場合（Ｓ２４においてＹｅｓ）、処理はステップＳ２６に進む。ディーラ３０が混雑していないと判定（判断）された場合（Ｓ２４においてＮｏ）、処理はステップＳ２７に進む。

【0093】

ステップＳ２６では、運行管理センタ１００（プロセッサ１０１）は、ディーラ３０において車両本体１２のメンテナンスを行うともに、ＡＤＫメンテナンスセンタ４０においてＡＤＫ１１の制御的なメンテナンスを行うことを決定する。具体的には、プロセッサ１０１は、ディーラ３０においてＡＤＫ１１を車両１０（車両本体１２）から取り外さずに、ＡＤＫメンテナンスセンタ４０においてＡＤＫ１１の制御的なメンテナンスを行うことを決定する。この場合、プロセッサ１０１は、ディーラ３０に対して、車両本体１２のメンテナンスを他の車両１０のメンテナンス（たとえば緊急性が比較的低いメンテナンス）よりも優先するように依頼をしてもよい。

【0094】

また、ステップＳ２７では、運行管理センタ１００（プロセッサ１０１）は、ディーラ３０において車両本体１２のメンテナンスを行うことを決定する。さらに、プロセッサ１０１は、ディーラ３０においてＡＤＫ１１を車両１０（車両本体１２）から取り外し、ＡＤＫメンテナンスセンタ４０において、取り外されたＡＤＫ１１の制御的なメンテナンスを行うことを決定する。この場合、ディーラ３０において取り外されたＡＤＫ１１は、ディーラ３０によってＡＤＫメンテナンスセンタ４０まで郵送されてもよい。

【0095】

また、ステップＳ２５では、運行管理センタ１００（プロセッサ１０１）は、ディーラ３０のスケジュール情報（在庫状況）に基づき、ディーラ３０におけるＡＤＫ１１の部品の在庫が不足しているか否かを判定する。ディーラ３０においてＡＤＫ１１の部品の在庫が不足していないと判定（判断）された場合（Ｓ２５においてＮｏ）、処理はステップＳ２８に進む。ディーラ３０においてＡＤＫ１１の部品の在庫が不足していると判定（判断）された場合（Ｓ２５においてＹｅｓ）、処理はステップＳ２９に進む。なお、プロセッサ１０１は、所定の期間内（たとえば判定時から３日以内）の在庫状況を判定してもよい。

【0096】

ステップＳ２８では、運行管理センタ１００（プロセッサ１０１）は、ディーラ３０において車両本体１２のメンテナンスおよびＡＤＫ１１の部品交換を行うことを決定する。

【0097】

また、ステップＳ２９では、運行管理センタ１００（プロセッサ１０１）は、ディーラ３０において車両本体１２のメンテナンスを行うとともに、ＡＤＫメンテナンスセンタ４０においてＡＤＫ１１の部品交換を行うことを決定する。この場合、プロセッサ１０１は、ＡＤＫ１１が車両本体１２に取り付けられた状態の車両１０を、ＡＤＫメンテナンスセンタ４０においてメンテナンスすることを決定する。

【0098】

そして、ステップＳ２２、および、ステップＳ２６～Ｓ２９の各々の後のステップＳ３０では、運行管理センタ１００（プロセッサ１０１）は、車両１０のメンテナンスのスケジュールを決定する。具体的には、プロセッサ１０１は、上記状態情報と、ステップＳ５において取得されたディーラ３０のスケジュール情報と、ステップＳ７において取得されたＡＤＫメンテナンスセンタ４０のスケジュール情報とに基づいて、車両１０のメンテナンスのスケジュールを決定する。スケジュールの決定方法の詳細な説明は、上述した通りであるので、説明は繰り返さない。

【0099】

以上のように、本実施の形態においては、プロセッサ１０１は、車両１０の状態情報に基づいて、ディーラ３０およびＡＤＫメンテナンスセンタ４０の少なくとも一方における車両１０のメンテナンスの割り当てを決定する。これにより、プロセッサ１０１によりメンテナンス先が決定される。その結果、ユーザがメンテナンス先を選択する必要がないので、ユーザの手間を低減することができる。また、メンテナンス先が車両１０の状態に基づいてプロセッサ１０１により決定されるので、上記メンテナンス先において、車両１０の状態に応じた適切なメンテナンスを確実に行うことができる。その結果、車両１０の状態（異常状態）を、すみやかに改善することができる。

【0100】

また、本実施の形態においては、プロセッサ１０１は、上記状態情報と、ディーラ３０のスケジュール情報およびＡＤＫメンテナンスセンタ４０のスケジュール情報とに基づいて、ディーラ３０およびＡＤＫメンテナンスセンタ４０の少なくとも一方における車両１０のメンテナンスのスケジュールを決定する。

【0101】

これにより、プロセッサ１０１は、ディーラ３０のスケジュール情報およびＡＤＫメンテナンスセンタ４０のスケジュール情報の両方に基づいて、車両１０のメンテナンスのスケジュールを決定することができる。その結果、たとえば車両１０がディーラ３０およびＡＤＫメンテナンスセンタ４０のいずれにおいてもメンテナンスが可能な状態である場合、より早くメンテナンスが可能なメンテナンス先においてメンテナンスを行うことを決定することができる。また、車両１０がディーラ３０およびＡＤＫメンテナンスセンタ４０の各々においてメンテナンスが必要な場合、プロセッサ１０１は、ディーラ３０およびＡＤＫメンテナンスセンタ４０の各々のスケジュールに基づいて、適切なスケジュールを作成することができる。たとえば、ディーラ３０およびＡＤＫメンテナンスセンタ４０の各々におけるメンテナンス同士の間の時間が適度な長さになるように調整することができる。また、上記メンテナンス同士が行われる時間帯が互いに重なるのを防止することができる。

【0102】

また、上記実施の形態では、プロセッサ１０１は、ディーラ３０のスケジュール情報およびＡＤＫメンテナンスセンタ４０のスケジュール情報の少なくとも一方に基づいて、メンテナンスのスケジュールを決定する例を示したが、本開示はこれに限られない。プロセッサ１０１は、上記スケジュール情報に基づかずに（車両１０の状態情報のみに基づいて）、ディーラ３０およびＡＤＫメンテナンスセンタ４０の少なくとも一方におけるメンテナンスの割り当てを決定してもいい。

【0103】

また、上記実施の形態では、ディーラ３０の混雑状況および在庫状況に基づいてメンテナンスのスケジュールを決定する例を示したが、本開示はこれに限られない。プロセッサ１０１は、ＡＤＫメンテナンスセンタ４０の混雑状況および在庫状況に基づいてメンテナンスのスケジュールを決定してもよい。

【0104】

また、上記実施の形態では、車両１０のメンテナンス先としてディーラ３０とＡＤＫメンテナンスセンタ４０とを例に挙げたが、本開示はこれに限られない。ディーラ３０およびＡＤＫメンテナンスセンタ４０以外（たとえば車両整備工場等）においてもメンテナンスが行われてもよい。

【0105】

また、上記実施の形態では、運行管理センタ１００（プロセッサ１０１）は、ディーラ３０のスケジュールおよびＡＤＫメンテナンスセンタ４０のスケジュールの両方に基づいて、メンテナンスを決定する例を示したが、本開示はこれに限られない。プロセッサ１０１は、ディーラ３０のスケジュールおよびＡＤＫメンテナンスセンタ４０のスケジュールの一方に基づいて、メンテナンスを決してもよい。たとえば、プロセッサ１０１は、取得された状態情報に基づいて、ディーラ３０およびＡＤＫメンテナンスセンタ４０の一方のメンテナンスが不要であると判断した場合に、メンテナンスが不要な上記一方のスケジュール情報を取得しなくてもよい。

【0106】

また、上記実施の形態では、運転支援制御および自動運転制御を実施するＡＤＫ（搭載制御装置）が車両１０に搭載されている例を示したが、本開示はこれに限られない。運転支援制御および自動運転制御のうちの一方を実施する搭載制御装置が車両１０に搭載されていてもよい。

【0107】

なお、上記実施の形態に記載されている構成、および、上記の各種変形例は、任意に組み合わされて実施されてもよい。

【0108】

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

【符号の説明】

【0109】

１０、１０ａ、１０ｂ 車両，１１、１１ａ、１１ｂ ＡＤＫ（搭載制御装置），１２ 車両本体，１４ ＤＣＭ（車両側通信部），２０、２０ａ、２０ｂ ＡＤＫ管理サーバ（管理サーバ），３０ ディーラ（第１メンテナンス場）（第１販売店）（第２販売店），４０ ＡＤＫメンテナンスセンタ（第２メンテナンス場）（第１メンテナンスセンタ）（第２メンテナンスセンタ），１００ 運行管理センタ（サーバ），１０１ プロセッサ（サーバ側制御部），１０３ 通信部（サーバ側通信部），１１１ ＬＩＤＡＲ（部品），１１２ カメラ（部品），１１３ センサ（部品）。

【図1】

【図2】

【図3】

【図4】

【図5】

【図6】

【図7】

【図8】

【図9】