特開 2025-87411 支援システム、支援方法、支援プログラム

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

(12)【公報種別】公開特許公報(A)

(11)【公開番号】P2025087411

(43)【公開日】2025-06-10

(54)【発明の名称】支援システム、支援方法、支援プログラム

(51)【国際特許分類】

   G08G 1/00 20060101AFI20250603BHJP

   G08G 1/09 20060101ALI20250603BHJP

   G16Y 10/40 20200101ALI20250603BHJP

   G16Y 20/20 20200101ALI20250603BHJP

   G16Y 40/20 20200101ALI20250603BHJP

【ＦＩ】

G08G1/00 D

G08G1/09 V

G16Y10/40

G16Y20/20

G16Y40/20

【審査請求】未請求

【請求項の数】16

【出願形態】ＯＬ

(21)【出願番号】P 2023202046

(22)【出願日】2023-11-29

(71)【出願人】

【識別番号】000004260

【氏名又は名称】株式会社デンソー

(74)【代理人】

【氏名又は名称】矢作 和行

(74)【代理人】

【識別番号】100121991

【弁理士】

【氏名又は名称】野々部 泰平

(74)【代理人】

【識別番号】100145595

【弁理士】

【氏名又は名称】久保 貴則

(72)【発明者】

【氏名】今井 謙一郎

(72)【発明者】

【氏名】田中 基木

(72)【発明者】

【氏名】平山 泰弘

【テーマコード（参考）】

5H181

【Ｆターム（参考）】

5H181AA01

5H181AA27

5H181BB04

5H181BB20

5H181CC03

5H181CC04

5H181CC11

5H181CC12

5H181CC14

5H181FF04

5H181FF10

5H181FF13

5H181FF22

5H181FF27

5H181FF32

5H181MB01

(57)【要約】

【課題】適切なサポータへサポートを要請可能な支援システム等を、提供する。
【解決手段】支援システムは、プロセッサを有し、自律走行装置を支援する。プロセッサは、自律走行装置の動作履歴データを生成することを実行するように構成される。プロセッサは、自律走行装置の走行が阻害される状態としてのスタックの発生を監視することを実行するように構成される。プロセッサは、リカバリサポートレベルに対してマッチングするサポータへ、サポート要請データを出力することを実行するように構成される。リカバリサポートレベルは、スタックからのリカバリサポートを実行可能なサポータへ要請するスタックからのリカバリサポートのレベルである。リカバリサポートレベルは、スタックの発生タイミングから遡った動作履歴データに応じたレベルである。
【選択図】図４

【特許請求の範囲】

【請求項1】

プロセッサ（５）を有し、自律走行装置（１０）を支援する支援システムであって、
前記プロセッサは、
前記自律走行装置の動作履歴データを生成することと、
前記自律走行装置の走行が阻害される状態としてのスタックの発生を監視することと、
前記スタックからのリカバリサポートを実行可能なサポータ（２０）へ要請する前記スタックからの前記リカバリサポートのレベルであって前記スタックの発生タイミングから遡った前記動作履歴データに応じたレベルであるリカバリサポートレベルに対してマッチングする前記サポータへ、サポート要請データを出力することと、
を実行するように構成される支援システム。

【請求項2】

前記サポート要請データを出力することは、
前記動作履歴データから解析されるスタック要因別の前記リカバリサポートレベルにマッチングする人数の前記サポータへ、少なくとも前記サポート要請データを出力することを含む請求項１に記載の支援システム。

【請求項3】

前記サポート要請データを出力することは、
前記サポータの種別毎に予め設定されるサポート可能な前記リカバリサポートレベルのレベル範囲が、前記動作履歴データに応じた前記リカバリサポートレベルにマッチングする種別の前記サポータへ、前記サポート要請データを出力することを含む請求項１に記載の支援システム。

【請求項4】

前記サポート要請データを出力することは、
前記サポータの種別毎に予め設定されるサポート可能な前記リカバリサポートレベルの前記レベル範囲が、前記動作履歴データから解析されるスタック要因別の前記リカバリサポートレベルにマッチングする種別の前記サポータへ、前記サポート要請データを出力することを含む請求項３に記載の支援システム。

【請求項5】

前記サポータの種別毎に予め設定されるサポート可能な前記リカバリサポートレベルの前記レベル範囲が、前記スタック要因から予測されるサポートリスクに応じた前記リカバリサポートレベルにマッチングする種別の前記サポータへ、前記サポート要請データを出力することを含む請求項４に記載の支援システム。

【請求項6】

前記サポータの種別は、事前登録されてサポートサービスを専門とする、専門スタッフ（２１）を含む請求項３に記載の支援システム。

【請求項7】

前記サポータの種別は、事前登録されて前記自律走行装置の周囲における位置条件を満たす場合にサポートサービスを提供する、臨時スタッフ（２２）を含む請求項３に記載の支援システム。

【請求項8】

前記プロセッサは、
事前登録された前記臨時スタッフによる前記リカバリサポートに対して、インセンティブデータを出力することを実行するように構成される請求項７に記載の支援システム。

【請求項9】

前記サポータの種別は、前記自律走行装置の周囲における未登録の、他道路ユーザ（２３）を含む請求項３に記載の支援システム。

【請求項10】

前記プロセッサは、
前記サポート要請データの出力に応答して前記自律走行装置にアクセスした前記他道路ユーザのユーザ情報を、登録することを実行するように構成される請求項９に記載の支援システム。

【請求項11】

前記プロセッサは、
登録された前記他道路ユーザによる前記リカバリサポートに対して、インセンティブデータを出力することを実行するように構成される請求項１０に記載の支援システム。

【請求項12】

前記サポート要請データを出力することは、
複数種別の前記サポータがマッチングした場合において、前記レベル範囲の上限が最も低い種別の前記サポータに対して、優先的に前記サポート要請データを出力することを含む請求項３に記載の支援システム。

【請求項13】

前記サポート要請データは、前記自律走行装置から通信出力される、通信データを含む請求項１に記載の支援システム。

【請求項14】

前記サポート要請データは、前記自律走行装置の周囲へ報知出力される、報知データを含む請求項１に記載の支援システム。

【請求項15】

自律走行装置（１０）を支援するために、プロセッサ（５）により実行される支援方法であって、
前記自律走行装置の動作履歴データを生成することと、
前記自律走行装置の走行が阻害される状態としてのスタックの発生を監視することと、
前記スタックからのリカバリサポートを実行可能なサポータ（２０）へ要請する前記スタックからの前記リカバリサポートのレベルであって前記スタックの発生タイミングから遡った前記動作履歴データに応じたレベルであるリカバリサポートレベルに対してマッチングする前記サポータへ、サポート要請データを出力することと、
を含む支援方法。

【請求項16】

自律走行装置（１０）を支援するために記憶媒体（４）に記憶され、プロセッサ（５）に実行させる命令を含む支援プログラムであって、
前記命令は、
前記自律走行装置の動作履歴データを生成させることと、
前記自律走行装置の走行が阻害される状態としてのスタックの発生を監視させることと、
前記スタックからのリカバリサポートを実行可能なサポータ（２０）へ要請する前記スタックからの前記リカバリサポートのレベルであって前記スタックの発生タイミングから遡った前記動作履歴データに応じたレベルであるリカバリサポートレベルに対してマッチングする前記サポータへ、サポート要請データを出力させることと、
を含む支援プログラム。

【発明の詳細な説明】

【技術分野】

【0001】

本開示は、ホスト車両及び自動運転可能なターゲット車両の走行を遠隔支援する支援技術に、関する。

【背景技術】

【0002】

特許文献１には、搬送ロボットの運行を管理する管理センタが開示されている。管理センタは、搬送ロボットの走行不能状態からの復帰支援を含むサポート動作を実行した登録ユーザの識別情報と、サポート動作の内容と、を含むサポート情報を取得する。管理センタは、取得したサポート動作の内容に応じて、登録ユーザにポイントを付与する。

【先行技術文献】

【特許文献】

【0003】

【特許文献1】特開２０２１－６４１１９号公報

【発明の概要】

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

【0004】

しかし、搬送ロボットに必要なサポートは状況に応じて異なり、当該サポートを実行するサポータの負担度合もサポートに応じて異なる。特許文献１の技術では、登録ユーザであれば一律サポートを要求するため、状況に応じたサポートを、適切なサポータに対して要請することはできない。

【0005】

本開示の課題は、適切なサポータに対してサポートを要請可能な支援システムを、提供することにある。本開示の別の課題は、適切なサポータに対してサポートを要請可能な支援方法を、提供することにある。本開示のさらに別の課題は、適切なサポータに対してサポートを要請可能な支援プログラムを、提供することにある。

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

【0006】

以下、課題を解決するための本開示の技術的手段について、説明する。尚、特許請求の範囲及び本欄に記載された括弧内の符号は、後に詳述する実施形態に記載された具体的手段との対応関係を示すものであり、本開示の技術的範囲を限定するものではない。

【0007】

本開示の第一態様は、プロセッサ（５）を有し、自律走行装置（１０）を支援する支援システムであって、
プロセッサは、
自律走行装置の動作履歴データを生成することと、
自律走行装置の走行が阻害される状態としてのスタックの発生を監視することと、
スタックからのリカバリサポートを実行可能なサポータ（２０）へ要請するスタックからのリカバリサポートのレベルであってスタックの発生タイミングから遡った動作履歴データに応じたレベルであるリカバリサポートレベルに対してマッチングするサポータへ、サポート要請データを出力することと、
を実行するように構成される。

【0008】

本開示の第二態様は、自律走行装置（１０）を支援するために、プロセッサ（５）により実行される支援方法であって、
自律走行装置の動作履歴データを生成することと、
自律走行装置の走行が阻害される状態としてのスタックの発生を監視することと、
スタックからのリカバリサポートを実行可能なサポータ（２０）へ要請するスタックからのリカバリサポートのレベルであってスタックの発生タイミングから遡った動作履歴データに応じたレベルであるリカバリサポートレベルに対してマッチングするサポータへ、サポート要請データを出力することと、
を含む。

【0009】

本開示の第三態様は、自律走行装置（１０）を支援するために記憶媒体（４）に記憶され、プロセッサ（５）に実行させる命令を含む支援プログラムであって、
命令は、
自律走行装置の動作履歴データを生成させることと、
自律走行装置の走行が阻害される状態としてのスタックの発生を監視させることと、
スタックからのリカバリサポートを実行可能なサポータ（２０）へ要請するスタックからのリカバリサポートのレベルであってスタックの発生タイミングから遡った動作履歴データに応じたレベルであるリカバリサポートレベルに対してマッチングするサポータへ、サポート要請データを出力させることと、
を含む。

【0010】

これら第一～第三態様によると、自律走行装置のスタックが発生した場合に、スタックの発生タイミングから遡った動作履歴データに応じたリカバリサポートレベルに対してマッチングするサポータへ、サポート要請データが出力される。故に、リカバリサポートレベルに適したサポータに対して、サポートを要請することが可能となり得る。したがって、適切なサポータに対してサポートを要請可能となり得る。

【図面の簡単な説明】

【0011】

【図1】第一実施形態の全体構成を示す概略図である。

【図2】第一実施形態による自律走行装置の機能構成を示すブロック図である。

【図3】第一実施形態による支援システムの機能構成を示すブロック図である。

【図4】第一実施形態による支援フローを示すフローチャートである。

【図5】第一実施形態による支援フローにおけるサポート要請データ出力処理の詳細を示すフローチャートである。

【図6】スタック要因別に設定されるリカバリサポートレベル等の一例を示す表である。

【図7】サポータの種別に応じたサポート可能なレベル範囲等の一例を示す表である。

【図8】第二実施形態による支援フローにおけるサポート要請データ出力処理の詳細を示すフローチャートである。

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

【0012】

以下、本開示の実施形態を図面に基づき複数説明する。尚、各実施形態において対応する構成要素には同一の符号を付すことで、重複する説明を省略する場合がある。又、各実施形態において構成の一部分のみを説明している場合、当該構成の他の部分については、先行して説明した他の実施形態の構成を適用することができる。さらに、各実施形態の説明において明示している構成の組み合わせばかりではなく、特に組み合わせに支障が生じなければ、明示していなくても複数の実施形態の構成同士を部分的に組み合わせることができる。

【0013】

（第一実施形態）
図１に示す第一実施形態の支援システム３は、自動運転可能な自律走行装置１０の外部施設であるリモートセンタ１において構築される。支援システム３は、複数のオペレータにより操作可能に構成されており、自律走行装置１０の自動運転を遠隔支援する。自律走行装置１０は、前後左右の任意方向に自律走行可能な自律装置（autonomous robot）である。尚、自律走行装置１０は、自律走行車（autonomous vehicle）と称することもできる。自律走行装置１０は、例えば自律走行により積載物を搬送する搬送車両である。又は、自律走行装置１０は、積載物の搬送以外の用途（例えば情報収集等）に供されるものであってもよい。

【0014】

自律走行装置１０には、図２に示す通信系１１、センサ系１２、地図データベース１５、情報提示系１６、及び制御システム１７が搭載される。通信系１１は、自律走行装置１０により利用可能な通信情報を、無線通信により取得する。通信系１１は、自律走行装置１０の外界に存在するＶ２Ｘシステムとの間において通信信号を送受信する、Ｖ２Ｘタイプであってもよい。Ｖ２Ｘタイプの通信系１１は、例えばＤＳＲＣ（Dedicated Short Range Communications）通信機、及びセルラＶ２Ｘ（C-V2X）通信機等のうち、少なくとも一種類である。Ｖ２Ｘタイプの通信系１１により、自律走行装置１０は、支援システム３と無線通信可能となる。通信系１１は、自律走行装置１０の周囲に存在する端末との間において通信信号を送受信する、端末通信タイプであってもよい。端末通信タイプの通信系１１は、例えばＢｌｕｅｔｏｏｔｈ（登録商標）機器、Ｗｉ－Ｆｉ（登録商標）機器、及び赤外線通信機器等のうち、少なくとも一種類である。

【0015】

センサ系１２は、制御システム１７又は支援システム３により利用可能なセンサ情報を、自律走行装置１０の外界と内界とに対して取得する。そのためにセンサ系１２は、外界センサ１３と内界センサ１４とを含んで構成される。

【0016】

外界センサ１３は、自律走行装置１０の周辺環境となる外界から、センサ情報としての外界情報を取得する。外界センサ１３は、自律走行装置１０の外界に存在する物標を検知する、物標検知タイプであってもよい。物標検知タイプの外界センサ１３は、例えば外界を撮像するカメラ、照射したレーザ光の反射光を点群画像として検出可能なＬｉＤＡＲ（Light Detection and Ranging / Laser Imaging Detection and Ranging）、レーダ及びソナー等のうち少なくとも一種類を含んでいる。外界センサ１３は、自律走行装置１０の外界に存在するＧＮＳＳ（Global Navigation Satellite System）の人工衛星から測位信号を受信する、測位タイプであってもよい。測位タイプの外界センサ１３は、例えばＧＮＳＳ受信機等である。

【0017】

内界センサ１４は、自律走行装置１０の内部環境となる内界から、センサ情報としての内界情報を取得する。内界センサ１４は、自律走行装置１０の内界において特定の運動物理量を検知する、物理量検知タイプであってもよい。物理量検知タイプの内界センサ１４は、例えば速度センサ、加速度センサ、ジャイロセンサ、車輪回転数センサ、音センサ等のうち、少なくとも一種類である。

【0018】

地図データベース１５は、制御システム１７により利用可能な地図情報を、記憶する。地図データベース１５は、例えば半導体メモリ、磁気媒体、及び光学媒体等のうち、少なくとも一種類の非遷移的実体的記憶媒体（non-transitory tangible storage medium）を含んで構成されている。地図データベース１５は、自律走行装置１０の自己位置を含む自己状態量を推定するロケータの、データベースであってもよい。地図データベース１５は、自律走行装置１０の走行経路をナビゲートするナビゲーションユニットの、データベースであってもよい。地図データベース１５は、これらのデータベース等のうち複数種類の組み合わせにより、構成されていてもよい。

【0019】

地図データベース１５は、例えばＶ２Ｘタイプの通信系１１を介した外部との通信等により、最新の地図情報を取得して記憶する。ここで地図情報は、自律走行装置１０の走行環境を表す情報として、二次元又は三次元にデータ化されている。特に三次元の地図データとしては、高精度地図のデジタルデータが採用されるとよい。地図情報は、例えば道路自体の位置、形状、及び路面状態等のうち、少なくとも一種類を表した道路情報を含んでいてもよい。地図情報は、例えば道路に付属する標識及び区画線の位置並びに形状等のうち、少なくとも一種類を表した標示情報を含んでいてもよい。地図情報は、例えば道路に面する建造物及び信号機の位置並びに形状等のうち、少なくとも一種類を表した構造物情報を含んでいてもよい。

【0020】

情報提示系１６は、自律走行装置１０の周囲の人へ向けた報知情報を提示する。情報提示系１６は、視覚を刺激する視覚刺激タイプであってもよい。視覚刺激タイプの情報提示系１６は、例えばディスプレイ及び発光ユニット等のうち、少なくとも一種類である。情報提示系１６は、乗員の聴覚を刺激する、聴覚刺激タイプであってもよい。聴覚刺激タイプの情報提示系１６は、例えばスピーカ、及びブザー等のうち、少なくとも一種類である。

【0021】

制御システム１７は、例えばＬＡＮ（Local Area Network）回線、ワイヤハーネス、内部バス、及び無線通信回線等のうち、少なくとも一種類を介して通信系１１、センサ系１２、地図データベース１５及び情報提示系１６に接続されている。制御システム１７は、少なくとも一つの専用コンピュータを含んで構成されている。

【0022】

制御システム１７を構成する専用コンピュータは、例えば自律走行装置１０の自律走行を制御する、走行制御ＥＣＵ（Electronic Control Unit）である。制御システム１７を構成する専用コンピュータは、メモリ１８とプロセッサ１９とを、少なくとも一つずつ有している。メモリ１８は、コンピュータにより読み取り可能なプログラム及びデータ等を非一時的に記憶する、例えば半導体メモリ、磁気媒体、及び光学媒体等のうち、少なくとも一種類の非遷移的実体的記憶媒体（non-transitory tangible storage medium）である。ここで記憶とは、自律走行装置１０の起動オフによってもデータが保持される蓄積であってもよいし、自律走行装置１０の起動オフによりデータが消去される一時的な格納であってもよい。プロセッサ１９は、例えばＣＰＵ（Central Processing Unit）、ＧＰＵ（Graphics Processing Unit）、ＲＩＳＣ（Reduced Instruction Set Computer）－ＣＰＵ、ＣＩＳＣ（Complex Instruction Set Computer）－ＣＰＵ、ＤＦＰ（Data Flow Processor）、及びＧＳＰ（Graph Streaming Processor）等のうち、少なくとも一種類をコアとして含んでいる。

【0023】

制御システム１７においてプロセッサ１９は、自律走行装置１０の将来経路、将来軌道、将来行動での動的運転タスクを、センサ情報等に基づき計画する。制御システム１７は、例えばシミュレーションモデル又は機械学習モデル等の車両走行モデルを用いて、判断且つ計画を遂行してもよい。

【0024】

さらに、制御システム１７においてプロセッサ１９は、支援システム３へと支援に利用可能な情報を提供するために、メモリ１８に記憶された、制御プログラムに含まれる複数の命令を実行する。これにより制御システム１７は、自律走行装置１０の支援において利用可能な情報を提供するための機能ブロックを、複数構築する。制御システム１７において構築される複数の機能ブロックには、図２に示すように情報収集ブロック１７０、周辺監視ブロック１７１、通信制御ブロック１７２、及び提示制御ブロック１７３が含まれている。

【0025】

情報収集ブロック１７０は、自律走行装置１０の状態に関する状態情報を収集する。情報収集ブロック１７０は、内界センサ１４からの内界情報を、状態情報として収集する。例えば、情報収集ブロック１７０は、速度データ、加速度データ、姿勢データ、音データ、及び車輪回転数データ等を、状態情報として収集する。又、情報収集ブロック１７０は、自律走行装置１０の制御に関連するプロセッサ及びメモリの使用状況に関するデータとして、プロセッサ使用率データ及びメモリ使用率データを、状態情報として収集する。

【0026】

周辺監視ブロック１７１は、自律走行装置１０の周囲の外界を監視する。監視において周辺監視ブロック１７１は、外界センサ１３からの外界情報を収集する。例えば、周辺監視ブロック１７１は、カメラにより外界を撮像した画像データ、及びＬｉＤＡＲやレーダ等により外界をセンシングしたセンシングデータ等を、外界情報として収集する。

【0027】

通信制御ブロック１７２は、通信系１１を介して、制御システム１７と自律走行装置１０の外部との間の通信を制御する。通信制御ブロック１７２は、情報収集ブロック１７０にて収集された状態情報を、支援システム３に対して送信する。通信制御ブロック１７２は、周辺監視ブロック１７１にて収集された外界情報を、支援システム３に対して送信する。又、通信制御ブロック１７２は、他道路ユーザ２３へのサポート要請データ（後述）を、通信系１１を介して支援システム３から受信する。加えて、通信制御ブロック１７２は、サポートの完了後において、後述のインセンティブ付与対象のサポータ２０に対して通信系１１をアクセスポイントとして機能させてもよい。

【0028】

提示制御ブロック１７３は、情報提示系１６を介して自律走行装置１０の周辺に対する情報提示処理を実行する。提示制御ブロック１７３は、他道路ユーザ２３へのサポート要請データの受信に応じて、情報提示系１６を介してサポート要請を報知する。提示制御ブロック１７３は、サポート要請データに含まれる報知指示に応じた内容にて、音声データ及び映像データの少なくとも一種類による報知を実行する。

【0029】

支援システム３は、例えばＬＡＮ回線、ワイヤハーネス、内部バス、及び無線通信回線等のうち、少なくとも一種類を介して通信系２に接続されている。通信系２は、自律走行装置１０及び端末等と無線通信可能に構成されている。支援システム３は、少なくとも一つの専用コンピュータを含んで構成されている。支援システム３を構成する専用コンピュータは、自律走行装置１０の自律走行を監視する監視サーバであってもよい。支援システム３を構成する専用コンピュータは、複数の自律走行装置１０の運行を統合的に管理する管理サーバであってもよい。支援システム３を構成する専用コンピュータは、複数のサーバにより構成されてその機能が分散されていてもよい。

【0030】

支援システム３を構成する専用コンピュータは、メモリ４とプロセッサ５とを、少なくとも一つずつ有している。メモリ４は、コンピュータにより読み取り可能なプログラム及びデータ等を非一時的に記憶する、例えば半導体メモリ、磁気媒体、及び光学媒体等のうち、少なくとも一種類の非遷移的実体的記憶媒体である。ここで記憶とは、支援システム３の起動オフによってもデータが保持される蓄積であってもよいし、支援システム３の起動オフによりデータが消去される一時的な格納であってもよい。プロセッサ５は、例えばＣＰＵ、ＧＰＵ、ＲＩＳＣ－ＣＰＵ、ＣＩＳＣ－ＣＰＵ、ＤＦＰ、及びＧＳＰ等のうち、少なくとも一種類をコアとして含んでいる。

【0031】

支援システム３においてプロセッサ５は、自律走行装置１０の走行を、遠隔支援するためにメモリ４に記憶された、支援プログラムに含まれる複数の命令を実行する。これにより支援システム３は、自律走行装置１０の走行を、遠隔支援するための機能ブロックを、複数構築する。支援システム３において構築される複数の機能ブロックには、図３に示すように履歴生成ブロック１００、スタック監視ブロック１１０、設定ブロック１２０、マッチングブロック１３０、及び出力ブロック１４０が含まれている。

【0032】

これらのブロックの共同により、支援システム３が自律走行装置１０の走行を支援する支援方法は、図４に示す遠隔支援フローに従って実行される。本支援フローは、支援システム３の起動中に繰り返し実行される。尚、本支援フローにおける各「Ｓ」は、支援プログラムに含まれた複数命令によって実行される複数ステップを、それぞれ意味している。

【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】

変形例において支援システム３を構成する専用コンピュータは、デジタル回路及びアナログ回路のうち、少なくとも一方をプロセッサとして有していてもよい。ここでデジタル回路とは、例えばＡＳＩＣ（Application Specific Integrated Circuit）、ＦＰＧＡ（Field Programmable Gate Array）、ＳＯＣ（System on a Chip）、ＰＧＡ（Programmable Gate Array）、及びＣＰＬＤ（Complex Programmable Logic Device）等のうち、少なくとも一種類である。又こうしたデジタル回路は、プログラムを記憶したメモリを、有していてもよい。

【0101】

変形例において、出力ブロック１４０は、スタック要因が不明であった場合は、追加情報の収集を、他道路ユーザ２３に加えて、又は代えて、インフラ設備、周辺の他の自律走行装置等に依頼してもよい。

【0102】

変形例において、設定ブロック１２０は、スタック要因に加えて、スタック要因以外の情報に応じてリカバリサポートレベルを設定してもよい。例えば、設定ブロック１２０は、スタック要因以外にサポートリスクに関連する環境情報がある場合、スタック要因に対応するリカバリサポートレベルを補正して設定してもよい。環境情報は、例えば、自律走行装置１０に関する内部環境情報及び自律走行装置１０の外部に関する外部環境情報の少なくとも一種類を含む。内部環境情報は、例えば、自律走行装置１０の重量、発熱有無等である。外部環境情報は、例えば、スタックしたエリアにおける天候情報等である。

【0103】

変形例において、出力ブロック１４０は、他道路ユーザ２３がサポートを実行しようとした場合、サポート前にユーザ登録を実行するように促す通知の指示を、自律走行装置１０に対して出力してもよい。

【0104】

変形例において、設定ブロック１２０は、リモートセンタ１のオペレータによるスタック要因の判断結果を取得することで、スタック要因を判別してもよい。例えば、設定ブロック１２０は、オペレータが外界画像等から判断したスタック要因の入力を受け付けることで、スタック要因を判別してもよい。又、設定ブロック１２０は、スタック要因が不明であった場合に、オペレータによる判断結果を取得してもよい。

【0105】

変形例において、出力ブロック１４０は、サポート要請データとして、サポータ２０の端末による認証依頼を出力してもよい。出力ブロック１４０は、サポートを実行するサポータ２０の遠隔監視を行ってもよい。

【0106】

変形例において、自律走行装置１０は、サポートにおいて利用可能な装備品を備えていてもよい。例えば、自律走行装置１０は、車体に設けられた格納空間内に、装備品としてのジャッキ等の工具を格納されていてもよい。尚、装備品は、自律走行装置１０に一体的に取り付けられた部品であってもよい。又、支援システム３の出力ブロック１４０は、装備品の存在や使用法等の装備品情報を、サポート要請データに含めて出力してもよい。

【0107】

変形例において、設定ブロック１２０は、自律走行装置１０における装備品に応じたリカバリサポートレベルの設定を行ってもよい。又は、マッチングブロック１３０は、自律走行装置１０における装備品に応じたサポータ２０のマッチングを行ってもよい。

【0108】

変形例において、自律走行装置１０は、スイッチ操作で手動移動可能なインターフェイスを備えていてもよい。又、出力ブロック１４０は、サポータ２０に対して他のサポータ２０のスイッチ操作を許可する監視の役割の依頼をサポート要請データに含めて出力してもよい。又、出力ブロック１４０は、特定のサポータ２０に対して、他のサポータ２０による自律走行装置１０の車体を押す操作を監視する役割の依頼をサポート要請データに含めて出力してもよい。

【0109】

変形例において、出力ブロック１４０は、複数種別のサポータ２０に対してサポート要請データを出力する場合、依頼するサポートの役割を、種別に応じて変更してもよい。例えば、出力ブロック１４０は、リカバリサポートレベルがレベル５～７の場合に、安全確認の役割を専門スタッフ２１又は臨時スタッフ２２のみに依頼し、他道路ユーザ２３には他の役割を依頼するようにしてもよい。

【0110】

変形例において自律走行装置１０は、荷物搬送以外の用途に供されるものであってもよい。例えば、自律走行装置１０は、路面等の清掃を行う清掃ロボットであってもよい。

【0111】

ここまでの説明形態の他に上述の実施形態及び変形例における支援システム３は、プロセッサ５及びメモリ４を少なくとも一つずつ有する制御装置として実施されてもよい。具体的には、支援システム３は、処理回路（例えば処理ＥＣＵ等）又は半導体装置（例えば半導体チップ等）の形態で実施されてもよい。

【0112】

（技術的思想の開示）
この明細書は、以下に列挙する複数の項に記載された複数の技術的思想を開示している。いくつかの項は、後続の項において先行する項を択一的に引用する多項従属形式（a multiple dependent form）により記載されている場合がある。さらに、いくつかの項は、他の多項従属形式の項を引用する多項従属形式（a multiple dependent form referring to another multiple dependent form）により記載されている場合がある。これらの多項従属形式で記載された項は、複数の技術的思想を定義している。

【0113】

（技術的思想１）
プロセッサ（５）を有し、自律走行装置（１０）を支援する支援システムであって、
前記プロセッサは、
前記自律走行装置の動作履歴データを生成することと、
前記自律走行装置の走行が阻害される状態としてのスタックの発生を監視することと、
前記スタックからのリカバリサポートを実行可能なサポータ（２０）へ要請する前記スタックからのリカバリサポートのレベルであって前記スタックの発生タイミングから遡った前記動作履歴データに応じたレベルであるリカバリサポートレベルに対してマッチングする前記サポータへ、サポート要請データを出力することと、
を実行するように構成される支援システム。

【0114】

（技術的思想２）
前記サポート要請データを出力することは、
前記動作履歴データから解析されるスタック要因別の前記リカバリサポートレベルにマッチングする人数の前記サポータへ、少なくとも前記サポート要請データを出力することを含む技術的思想１に記載の支援システム。

【0115】

（技術的思想３）
前記サポート要請データを出力することは、
前記サポータの種別毎に予め設定されるサポート可能な前記リカバリサポートレベルのレベル範囲が、前記動作履歴データに応じた前記リカバリサポートレベルにマッチングする種別の前記サポータへ、前記サポート要請データを出力することを含む技術的思想１又は技術的思想２に記載の支援システム。

【0116】

（技術的思想４）
前記サポート要請データを出力することは、
前記サポータの種別毎に予め設定されるサポート可能な前記リカバリサポートレベルのレベル範囲が、前記動作履歴データから解析されるスタック要因別の前記リカバリサポートレベルにマッチングする種別の前記サポータへ、前記サポート要請データを出力することを含む技術的思想３に記載の支援システム。

【0117】

（技術的思想５）
前記サポータの種別毎に予め設定されるサポート可能な前記リカバリサポートレベルのレベル範囲が、前記スタック要因から予測されるサポートリスクに応じた前記リカバリサポートレベルにマッチングする種別の前記サポータへ、前記サポート要請データを出力することを含む技術的思想４に記載の支援システム。

【0118】

（技術的思想６）
前記サポータの種別は、事前登録されてサポートサービスを専門とする、専門スタッフ（２１）を含む技術的思想３から技術的思想５のいずれか１項に記載の支援システム。

【0119】

（技術的思想７）
前記サポータの種別は、事前登録されて前記自律走行装置の周囲における位置条件を満たす場合にサポートサービスを提供する、臨時スタッフ（２２）を含む技術的思想３から技術的思想６のいずれか１項に記載の支援システム。

【0120】

（技術的思想８）
前記プロセッサは、
事前登録された前記臨時スタッフによるリカバリサポートに対して、インセンティブデータを出力することを実行するように構成される技術的思想７に記載の支援システム。

【0121】

（技術的思想９）
前記サポータの種別は、前記自律走行装置の周囲における未登録の、他道路ユーザ（２３）を含む技術的思想３から技術的思想８のいずれか１項に記載の支援システム。

【0122】

（技術的思想１０）
前記プロセッサは、
前記サポート要請データの出力に応答して前記自律走行装置にアクセスした前記他道路ユーザのユーザ情報を、登録することを実行するように構成される技術的思想９に記載の支援システム。

【0123】

（技術的思想１１）
前記プロセッサは、
登録された前記他道路ユーザによる前記リカバリサポートに対して、インセンティブデータを出力することを実行するように構成される技術的思想１０に記載の支援システム。

【0124】

（技術的思想１２）
前記サポート要請データを出力することは、
複数種別のサポータがマッチングした場合において、前記レベル範囲の上限が最も低い種別の前記サポータに対して、優先的に前記サポート要請データを出力することを含む技術的思想３から技術的思想１１のいずれか１項に記載の支援システム。

【0125】

（技術的思想１３）
前記サポート要請データは、前記自律走行装置から通信出力される、通信データを含む技術的思想１から技術的思想１２のいずれか１項に記載の支援システム。

【0126】

（技術的思想１４）
前記サポート要請データは、前記自律走行装置の周囲へ報知出力される、報知データを含む技術的思想１から技術的思想１３のいずれか１項に記載の支援システム。

【0127】

尚、以上の技術的思想１～１４は、支援方法及び支援プログラムの形態で、実施されてもよい。

【符号の説明】

【0128】

３：支援システム、４：メモリ（記憶媒体）、５：プロセッサ、１０：自律走行装置、２０：サポータ、２１：専門スタッフ、２２：臨時スタッフ、２３：他道路ユーザ

【図1】

【図2】

【図3】

【図4】

【図5】

【図6】

【図7】

【図8】