JP7400522B2 - 支援管理装置、支援管理方法、及び支援管理プログラム - Google Patents

Description

本開示は、支援管理装置、支援管理方法、及び支援管理プログラムに関する。

自動運転の進展に伴い、自動運転の支援に関する技術が開発されている。

例えば、異常に基づいて走行計画を変更する技術がある（特許文献１参照）。この技術では、車両に異常が発生した場合に、異常の発生原因と異常発生時の車両の周囲の状況に基づいて車両の走行計画を変更する。また、異常として、接触事故、接触事故を除く「災害」、車載システムの「自然故障」、のいずれに該当するかを特定している。

特開２０１８－１８０８４３号公報

特許文献１の技術は、自車両に発生した異常のフェイルセーフのための技術である。一方、自動運転レベルがレベル４以上の自動運転車両では、ドライバが乗車していないことが想定される。レベル４以上の自動運転においてはドライバがいないことを想定して、センサの異常が発生した場合には直ちに原因を特定し適切な支援する必要がある。一方、従来の乗用車ではドライバからの申告などから推定は可能であるが、ドライバがいない場合、どのような原因で異常が発生したのかを判断することが出来ない。よって、自動運転車両の異常を適切に推定したり、異常の発生を未然に防ぐことが望ましい。なお、車両の異常とは、自動運転に影響のある事象を指し、主にセンサの認識に影響のある事象である、センサの汚れ、及び逆光等が挙げられる。

本開示は上記事情を鑑みてなされたものであり、異常の発生を抑止するように、車両の運転の支援を行うことができる支援管理装置、支援管理方法、及び支援管理プログラムを提供することを目的とする。

本開示に係る支援管理装置は、時間及び場所を対応付けた、車両のセンサの異常情報と、前記車両のカメラにより撮影したカメラ画像とを紐づけて蓄積するデータ蓄積部と、前記異常情報と、前記カメラ画像とに基づいて、異常の要因候補を推定する要因推定部と、推定された前記要因候補を時間と場所に紐づけて、異常の発生状況及び要因を示す要因マップを更新する要因マップ更新部と、更新された前記要因マップにより、異常の要因が特定された地点の周辺を走行する車両に対して前記異常要因を配信する走行支援部と、を含む。

本開示の支援管理装置、支援管理方法、及び支援管理プログラムによれば、異常の発生を抑止するように、車両の運転の支援を行うことができる。

各車両から異常フラグの立ったセンサの異常情報を収集するイメージ図である。 各車両から収集される異常情報の一例を示す図である。 更新した要因マップにより走行ルートの変更を提案する場合のイメージ図である。 本開示の実施形態に係る支援管理システムの構成を示すブロック図である。 要因マップ蓄積部に格納されている要因マップのデータ形式の一例を示す図である。 要因マップを地図上にマッピングし、ヒストグラム化した場合のイメージ図である。 注目領域画像の一例を示す図である。 管理センタサーバのハードウェア構成を示すブロック図である。 本開示の実施形態に係る支援管理システムの処理ルーチンを示すフローチャートである。 過去の異常要因の頻度分布と、一般車両から得られた要因が未知の異常種別の頻度分布とを比較した場合の例である。

以下、本開示の実施形態について図面を用いて説明する。

まず本実施形態の概要を説明する。自動運転において時間、場所、及び環境に依存するセンサの異常に対処したい。ここでの異常は、不調及び故障を含む。不調は、一時的に異常が生じているが、正常に戻る状態を指し、例えば汚れ、逆光などである。故障は、異常から正常に戻らない状態であり、例えばセンサの断線、触媒劣化、各種システムの不良などである。そこで、本実施形態では、センサの異常の発生と、異常の発生に合わせてカメラにより取得したカメラ画像（又はカメラ映像）から要因候補を抽出し、場所ごとに抽出した異常の発生状況及び要因を示す要因マップを更新する。要因マップにより、過去のセンサの不調とその要因を場所ごとに管理し、場所ごとに季節、及び環境に起因し発生する特有の異常に即座、又は事前に対処できるようにする。以下、自動運転車両の異常のうち不調が生じた場合に要因マップを更新する場合を例に説明する。

また、季節性のセンサ不調としては、中国からの影響による黄砂が３月から５月頃に発生し、これに起因するセンサの不調が多くなる。また、北の地方では冬の季節に害虫の発生により、これに起因するセンサの不調が多くなる。これらの季節性のセンサの不調は、特に地域ごとに周期性がある。

図１は、各車両から異常フラグの立ったセンサの異常情報を収集するイメージ図である。各車両で異常を検知すると、センサの異常フラグを立てて管理センタへ異常情報を送信する。図１の例は、ある自動運転の走行区画について、下から上への時系列順に、（１）異常が発生していない正常な状態、（２）異常フラグが立ったセンサの異常状態を送信する状態、（３）異常が終了して正常に戻った状態を示している。管理センタは、異常が生じたセンサの情報を含む異常情報と、異常が発生したセンサと要因に結び付きやすいカメラ画像とを収集し、蓄積する。このように、例えばミリ波センサの状態だけでは発生した状況の判別は困難だが、同時に収集したカメラ画像を解析することで要因候補が抽出できる。

図２は、各車両から収集される異常情報の一例を示す図である。図２に示すように、異常情報は、異常が発生した日付、位置、対象の故障コード、及び部品の情報を含む。位置とは、既定の道路ネットワークの道路リンク、又はノードである。故障コードにはコード及び要因が対応付けて定義されており、図２の例では「汚れ」が要因として示されている。管理センタでは、各車両からこのような異常情報を収集して、不調の発生傾向とその要因を解析し、要因及び発生傾向を地図上にマッピングした要因マップを更新する。これにより、季節、時間、場所、及び走行環境等に応じて、走行ルートの変更を提案し、不調の発生を未然に防止する。

図３は、更新した要因マップにより走行ルートの変更を提案する場合のイメージ図である。管理センタは、要因マップの不調リスク区間がある場合に、ルート変更を提案する。不調リスク区間とは、不調が発生する可能性のある走行ルートの区間である。図１同様に、下から上への時系列順に、（１）不調リスク区間がない正常な状態での走行ルート、（２）不調リスク区間が発生した場合にルート変更を提案した走行ルート、（３）不調リスク区間が終了して正常に戻った状態での走行ルートを示している。（２）のケースは、この場合、季節性、又は周期性のある要因によって、センサの不調が生じることが想定される。例えば、周期性のある要因として逆光が挙げられる。逆光が発生しやすい時間帯及び区間では、当該時間帯及び区間を走行する車両にセンサの不調が発生して、不調リスク区間が検出される。不調リスク区間が検出されている間、又は一定期間の間は、他の車両には、不調リスク区間以外のルートにするようなルート変更を提案する。そして、このような季節性、又は周期性のある要因が時間的な経過に応じて解消された場合には、（３）に示すように不調リスク区間が正常な区間に戻ったことを検出し、元の（１）の走行ルートに戻す。また、ルート変更の提案以外にも、例えばセンサのうちのミリ波が不調の場合、他のセンサで見える範囲に縮退して運転を継続することなども出来る。運転の縮退とは、速度６０ｋｍ／ｈ→３０ｋｍ／ｈに変更する等の速度変更である。

このように、不調発生時期、及びその要因候補を異常要因マップとして蓄積する。これにより季節や環境変化、使い方に応じたセンサの異常の発生頻度を場所ごとに可視化可能となる。ここで、場所とは、ある位置を含む一定範囲を指し、例えば、道路ネットワークであれば、位置に対応するノード及びリンクを場所として扱う。また、新たに異常が発生した場合には、場所、時間、及びカメラ画像に基づく要因候補をオペレータに提示し、要因候補の絞り込みができる。オペレータの操作によって要因マップを更新し、ルート変更を提案できる。

以下、本実施形態の構成及び作用について説明する。

図４を参照して、本開示の実施形態に係る支援管理システム１００の構成について説明する。図４は、本開示の実施形態に係る支援管理システム１００の構成を示すブロック図である。図４に示すように、支援管理システム１００は、車両１１０と、管理センタサーバ１２０と、オペレータ端末１３０とがネットワークＮを介して接続されている。管理センタサーバ１２０が、本開示の支援管理装置の一例である。

車両１１０は、送受信部１１１と、各種センサ１１２と、車載カメラ１１３と、異常検出部１１４と、ルート管理部１１５とを含む。

管理センタサーバ１２０は、送受信部１２１と、データ蓄積部１２２と、要因推定部１２３と、要因通知部１２４と、要因マップ更新部１２５と、要因マップ蓄積部１２６と、走行支援部１２７と、認識モデル１２８と、環境ＤＢ１２９とを含む。

オペレータ端末１３０は、表示及び入出力のインタフェースを備えている（図示省略）。管理センタサーバ１２０から要因候補と、注目領域画像とを受信して表示する。また、選択した要因候補を管理センタサーバ１２０に送信する。

車両１１０の各部について説明する。送受信部１１１は、管理センタサーバ１２０と各種データを送受信する。本実施形態では、送受信部１１１では、位置情報を含む運転状況の送信、異常情報の送信、異常要因の受信、及び走行ルートの変更後の変更ルート候補の受信が行われる。

各種センサ１１２は、ミリ波センサ、雨滴センサ、及び衝突センサ等の車載センサである。また、各種センサ１１２は、位置情報、時間情報、走行ルート、及び運転挙動等の運転状況を取得する計測センサを有する。運転挙動には、自動運転中か否かを示す状態のほか、車速、加速度、ステアリング、アクセル、及びブレーキの踏み込みなどが含まれる。運転状況は定期的に管理センタサーバ１２０に送信する。

車載カメラ１１３は、車両の走行中の映像を撮影するカメラである。車載カメラ１１３に撮影したカメラ画像（又はカメラ映像）を、異常情報を送信するタイミングで管理センタサーバ１２０に送信する。なお、カメラ画像は定期的に送信してもよい。

異常検出部１１４は、各種センサ１１２の状態を監視し、異常が生じたセンサを検出する。異常検出部１１４は、異常が生じた場合にはセンサの異常フラグを立て、異常情報を管理センタサーバ１２０に送信する。また、異常が解消した場合には、異常が終了したことを示す通知を管理センタサーバ１２０に送信する。

ルート管理部１１５は、異常要因を受信すると、現在走行中の走行ルートから他の走行ルートへの変更を実行する。このように管理センタサーバ１２０から異常要因が送信されてきた場合には車両１１０側の内部で異常要因の内容を元にルート変更を判断する。一方、管理センタサーバ１２０側で、車両１１０から送信した異常情報を元に変更ルート候補を算出してルート変更を判断する場合は、ルート管理部１１５は、変更ルート候補を受信して、運転状況に応じて、走行ルートの変更を実行する。このように車両１１０はフィードバックされた変更ルート候補に従って、ルート変更を行えばよい。

管理センタサーバ１２０の各部について説明する。送受信部１２１は、車両１１０、及びオペレータ端末１３０と各種データを送受信する。本実施形態では、送受信部１２１では、車両１１０に対しては、位置情報を含む運転状況の受信、異常情報の受信、異常要因の送信、及び走行ルートの変更後の変更ルート候補の送信が行われる。オペレータ端末１３０に対しては、要因候補と、注目領域画像との送信が行われる。

データ蓄積部１２２には、各車両から受信した異常情報、及びカメラで撮影されたカメラ画像が蓄積される。異常情報には、時間及び場所を含む。カメラ画像には、時間及び場所が対応付けられている。

認識モデル１２８は、予め学習された異常の要因候補、及び注目領域画像を出力するためのモデルである。認識モデル１２８の学習では、異常情報、カメラ画像、及び環境ＤＢ１２９の環境データを学習データとして、異常の要因候補、及び注目領域画像を出力するように学習しておく。なお、要因候補によっては、必ずしも注目領域画像が生成されるわけではない。

環境ＤＢ１２９は、過去、及び現時点で予測されている天候状況を環境データとして格納したデータベースである。天候状況は雨、雪といった天候とその量である。また、環境データには、地域特性、及び渋滞状況等を含んでもよい。地域特性とは、例えば、傾斜、森等である。渋滞状況は、交通区画の混雑状況である。このような環境データを用いることで外部要因を考慮して要因候補を出力できる。

要因推定部１２３は、異常情報と、カメラ画像とに基づいて、異常の要因候補を推定する。また、要因推定部１２３は、要因候補となる注目領域をカメラ画像に重畳した注目領域画像を生成する。注目領域画像とはカメラ画像に要因候補を重畳した画像である。

要因推定部１２３の処理では、具体的には、２つの要因候補を抽出し、これらを統合する。まず、異常情報の場所、かつ、現在時刻の時間帯に関連するＮ件の異常要因を要因候補（第１の要因候補）として抽出する。ここでは、過去のその場所の同一時間帯で発生したＮ件の要因候補を要因マップ蓄積部１２６から抽出すればよく、例えばＮ件は現在時刻から直近のＮ件とすればよい。同一時間帯の幅は、１時間ごと、３時間ごと等、任意の時間帯を設定しておけばよい。要因推定部１２３は、抽出したＮ件の要因候補と、予め学習した認識モデル１２８から出力された要因候補（第２の要因候補）とを統合することにより、要因候補を推定する。統合手法は、例えば、第１の要因候補と、第２の要因候補とのいずれにもマッチする要因候補を推定結果として統合すればよい。また、件数が多ければ絞り込みをしてもよい。なお、第１の要因候補を抽出する場合に、環境データを用いて、要因マップ蓄積部１２６に天候状況を格納しておき、同一の天候状況の要因候補に絞り込めるようにしてもよい。

要因推定部１２３の認識モデル１２８を用いる具体的処理の一例を説明する。要因推定部１２３は、異常情報に含まれる時間及び場所に対応する、環境ＤＢ１２９の環境データを取得する。異常情報、カメラ画像、及び環境データを認識モデル１２８への入力として、認識モデル１２８の出力により、要因候補、及び注目領域画像を推定する。

ここで要因マップについて説明する。図５は、要因マップ蓄積部１２６に格納されている要因マップのデータ形式の一例を示す図である。図６は、要因マップを地図上にマッピングし、ヒストグラム化した場合のイメージ図である。図５に示すように、要因マップは、テーブルデータとして時刻ごとに、道路リンク、車両ＩＤ、ＤＴＣ（故障コード）、要因候補（例としては雨、虫、及び雪等が挙げられる）等の情報が格納されている。要因マップ蓄積部１２６に格納されている要因候補は、要因推定部１２３で推定された要因候補であり、かつ、過去の要因マップの更新で異常要因と扱われた要因候補である。この要因マップは、図６に示すように、地図上にマッピングすると不調リスク区間として表現される。また、図６に示すように、要因マップはヒストグラムとしても表現される。

要因通知部１２４は、要因推定部１２３より推定された要因候補をオペレータ端末１３０に通知するように制御する。また、要因通知部１２４は、注目領域画像が生成されている場合には、要因候補と共にオペレータ端末１３０に通知するように制御する。図７は、注目領域画像の一例を示す図である。図７に示すように、注目領域画像は、汚れ要因候補の領域を示す囲みがカメラ画像に重畳されている。オペレータ端末１３０では、理由となる要因候補の一覧が表示され、選択できるようになっている。図７の例では、オペレータがオペレータ端末１３０に表示されている要因候補の中から雪（シャーベット付着）を異常要因として選択していることを示している。また、オペレータ端末１３０には、要因候補と共に、上記図６に示した地図上のマッピング及びヒストグラムを同時に表示してもよい。オペレータ端末１３０は、オペレータが選択した要因候補、すなわち異常要因として管理センタサーバ１２０に送信する。

要因マップ更新部１２５は、オペレータ端末１３０で選択された要因候補を受信すると、当該選択された要因候補を現在発生している異常要因として決定して、要因マップ蓄積部１２６の要因マップを更新する。なお、オペレータ端末１３０により選択された要因候補が送信されてこない場合には、尤もらしい要因候補を異常要因として決定してもよい。

走行支援部１２７は、更新された要因マップにより、異常の要因が特定された地点の周辺を走行する車両に対して異常要因を配信する。また、走行支援部１２７は、車両の各々の走行ルートを受信し、車両の各々について、更新された要因マップに基づいて、異常要因が走行ルートの経路にある場合に、変更後の変更ルート候補を当該車両に送信するようにしてもよい。また、走行支援部１２７は、要因マップの現在発生している異常要因の更新対象となった車両１１０から異常が終了したことを示す通知を受信した場合には、異常要因の配信、又は変更ルート候補の送信を終了する。

図８は、管理センタサーバ１２０のハードウェア構成を示すブロック図である。図８に示すように、管理センタサーバ１２０は、ＣＰＵ（Ｃｅｎｔｒａｌ Ｐｒｏｃｅｓｓｉｎｇ Ｕｎｉｔ）１１、ＲＯＭ（Ｒｅａｄ Ｏｎｌｙ Ｍｅｍｏｒｙ）１２、ＲＡＭ（Ｒａｎｄｏｍ Ａｃｃｅｓｓ Ｍｅｍｏｒｙ）１３、ストレージ１４、入力部１５、表示部１６及び通信インタフェース（Ｉ／Ｆ）１７を有する。各構成は、バス１９を介して相互に通信可能に接続されている。

ＣＰＵ１１は、中央演算処理ユニットであり、各種プログラムを実行したり、各部を制御したりする。すなわち、ＣＰＵ１１は、ＲＯＭ１２又はストレージ１４からプログラムを読み出し、ＲＡＭ１３を作業領域としてプログラムを実行する。ＣＰＵ１１は、ＲＯＭ１２又はストレージ１４に記憶されているプログラムに従って、上記各構成の制御及び各種の演算処理を行う。本実施形態では、ＲＯＭ１２又はストレージ１４には、支援管理処理プログラムが格納されている。

ＲＯＭ１２は、各種プログラム及び各種データを格納する。ＲＡＭ１３は、作業領域として一時的にプログラム又はデータを記憶する。ストレージ１４は、ＨＤＤ（Ｈａｒｄ Ｄｉｓｋ Ｄｒｉｖｅ）又はＳＳＤ（Ｓｏｌｉｄ Ｓｔａｔｅ Ｄｒｉｖｅ）等の記憶装置により構成され、オペレーティングシステムを含む各種プログラム、及び各種データを格納する。

入力部１５は、マウス等のポインティングデバイス、及びキーボードを含み、各種の入力を行うために使用される。

表示部１６は、例えば、液晶ディスプレイであり、各種の情報を表示する。表示部１６は、タッチパネル方式を採用して、入力部１５として機能してもよい。

通信インタフェース１７は、端末等の他の機器と通信するためのインタフェースであり、例えば、イーサネット（登録商標）、ＦＤＤＩ、Ｗｉ－Ｆｉ（登録商標）等の規格が用いられる。

以上が管理センタサーバ１２０のハードウェア構成の一例の説明である。

図９は、本開示の実施形態に係る支援管理システム１００の処理ルーチンを示すシーケンス図である。

ステップＳ１００では、異常検出部１１４が、各種センサ１１２のセンサの異常を検出する。異常を検出した場合には、異常が検出されたセンサについて異常フラグを立てる。

ステップＳ１０２では、異常検出部１１４が、異常フラグの立ったセンサについて、異常の発生を起点として、時間窓ｔを設定する。

ステップＳ１０４では、異常検出部１１４が、時間窓ｔに応じたセンサデータを抽出し、異常情報を作成する。

ステップＳ１０６では、送受信部１１１が、異常情報と、車載カメラ撮影されたカメラ画像とを管理センタサーバ１２０に送信する。

ステップＳ１０８では、送受信部１２１が、異常情報と、カメラ画像とを受信し、データ蓄積部１２２に蓄積する。

ステップＳ１１０では、要因推定部１２３が、異常情報の場所、かつ、現在時刻の時間帯に関連するＮ件の異常要因を要因候補（第１の要因候補）として抽出する。ここでは、過去のその場所の同一時間帯で発生した直近のＮ件の要因候補を要因マップ蓄積部１２６から抽出する。

ステップＳ１１２では、要因推定部１２３が、異常情報、カメラ画像、及び環境データを認識モデル１２８への入力として、認識モデル１２８の出力により、要因候補（第２の要因候補）、及び注目領域画像を推定する。

ステップＳ１１４では、要因推定部１２３が、第１の要因候補と、第２の要因候補とのいずれにもマッチする要因候補を推定結果として統合する。

ステップＳ１１６では、要因通知部１２４が、ステップＳ１１４で推定された要因候補及び注目領域画像をオペレータ端末１３０に通知するように制御する。要因候補及び注目領域画像は、送受信部１２１が送信する。

ステップＳ１１８では、オペレータ端末１３０が、要因候補及び注目領域画像を受信し、表示する。オペレータは、表示された要因候補の中から異常要因とする要因を選択する。

ステップＳ１２０では、オペレータ端末１３０が、オペレータが選択した要因候補を管理センタサーバ１２０に送信する。

ステップＳ１２２では、送受信部１２１が、オペレータ端末１３０で選択された要因候補を受信する。

ステップＳ１２４では、要因マップ更新部１２５は、オペレータ端末１３０から選択された要因候補を受信すると、当該選択された要因候補を異常要因として決定して、要因マップ蓄積部１２６の要因マップを更新する。

ステップＳ１２６では、走行支援部１２７が、更新された要因マップにより、異常の要因が特定された地点の周辺を走行する該当車両に対して異常要因を配信する。以下、当該車両を該当車両の各々とする。

ステップＳ１２８では、該当車両の各々の送受信部１１１が、異常要因を受信する。

ステップＳ１３０では、該当車両の各々のルート管理部１１５が、異常要因を受信すると、現在走行中の走行ルートから他の走行ルートへ変更する。

以上説明したように、本開示の実施形態に係る支援管理システム１００によれば、異常の発生を抑止するように、車両の運転の支援を行うことができる。

また、異常情報は自動運転車両からのみならず、同種のセンサを搭載した一般の乗用車（以下、一般車両とする）などからの異常情報も収集することができる。図１０は、過去の異常要因の頻度分布と、一般車両から得られた要因が未知の異常種別の頻度分布とを比較した場合の例である。図１０の例では、一般車両のセンサデータから得られる情報は、センサの異常の故障コードの異常種別（ＤＴＣ）の「汚れ」のみで、異常要因は未知である。このように一般車両からは、異常種別「汚れ」が多発していることだけが分かる。一方、過去の異常要因の頻度分布は、異常種別ごとの異常要因が特定されている。データ蓄積部１２２には、自動運転を行う車両１１０と同種のセンサを搭載した一般車両から得られる要因が未知の異常種別の頻度分布を蓄積する。また、過去の異常要因の頻度分布は、１０月－１２月の環境データを入力にした認識モデル１２８を用いて求めた要因候補（第２の要因候補）の頻度分布、又は第１の要因候補と第２の要因候補とを統合した要因候補の頻度分布を用いる。要因推定部１２３は、データ蓄積部１２２に蓄積された未知の異常種別の頻度分布と、過去の要因マップの異常要因の頻度分布を比較することで要因候補を推定する。図１０の例では、頻度分布を比較すると、同じ異常種別の頻度が多く、結果、当該異常種別の異常要因は「雪」と推定される。つまり、この場合、一般車両のセンサデータ（Ｒａｗ）は収集出来ないが、一般車両の異常情報の頻度分布と自動運転車両の異常情報（要因付け済み）の頻度分布との分布間距離（Ｍａｘｉｍｕｍ Ｍｅａｎ Ｄｉｓｃｒｅｐａｎｃｙ）などを用いて比較する。分布間距離の比較によって場所ごとの分布が似ていると判断されれば同様の要因で異常が発生していると判断できる。このような分布間距離の比較も要因マップとして蓄積する。このように、一般の乗用車の情報も活用することで、より多くの車両の情報を活用した異常の発生傾向の解析が可能になる。また、発生頻度分布を出力する時間間隔を短くすることで周期性の無い短期的な不調に対しても対処ができる。また、上記の例では、季節性があると仮定して、冬の期間（１０月－１２月）の環境データを入力とした認識モデル１２８の出力と比較して異常要因を雪とする場合だった。これが夏の期間であれば、夏の期間の環境データを入力として認識モデル１２８の出力と比較すれば要因が雪から虫など、季節性に応じた要因に変わる。また、一般車両のセンサデータだけでなく、ドライバからの聞き取り、ドライブレコーダの映像からの推定等により、の要因候補を推定してもよい。

なお、本開示は、上述した実施形態に限定されるものではなく、この発明の要旨を逸脱しない範囲内で様々な変形や応用が可能である。

また、本願明細書中において、プログラムが予めインストールされている実施形態として説明したが、当該プログラムを、コンピュータ読み取り可能な記録媒体に格納して提供することも可能である。

１００ 支援管理システム
１１０ 車両
１１１ 送受信部
１１２ 各種センサ
１１３ 車載カメラ
１１４ 異常検出部
１１５ ルート管理部
１２０ 管理センタサーバ
１２１ 送受信部
１２２ データ蓄積部
１２３ 要因推定部
１２４ 要因通知部
１２５ 要因マップ更新部
１２６ 要因マップ蓄積部
１２７ 走行支援部
１２８ 認識モデル
１２９ 環境ＤＢ
１３０ オペレータ端末

Claims (8)

1. 時間及び場所を対応付けた、車両のセンサの異常情報と、前記車両のカメラにより撮影したカメラ画像とを紐づけて蓄積するデータ蓄積部と、
   前記異常情報と、前記カメラ画像とに基づいて、異常の要因候補を推定する要因推定部と、
   推定された所定の前記要因候補を異常要因として時間及び場所に紐づけて、異常の発生状況及び要因を示す要因マップを更新する要因マップ更新部と、
   更新された前記要因マップにより、異常の要因が特定された地点の周辺を走行する車両に対して前記異常要因を配信する走行支援部と、
   オペレータ端末への通知を制御する要因通知部と、を含み、
   前記要因推定部は、前記要因候補となる注目領域を前記カメラ画像に重畳した注目領域画像を生成し、
   更新された過去の前記要因マップを、地図上にマッピングする不調リスク区間及び前記要因候補ごとのヒストグラムとして表現し、
   前記要因通知部は、前記要因候補と、前記注目領域画像と、過去の更新により推定された前記要因候補を含む前記要因マップとを、前記オペレータ端末に通知するように制御する、
   支援管理装置。
2. 前記要因推定部は、前記場所に対応する過去に発生した異常要因を前記要因候補として抽出し、予め学習した認識モデルから出力された前記要因候補と統合することにより、前記要因候補を推定する請求項１に記載の支援管理装置。
3. 前記要因推定部は、現在時刻の時間帯に関連する異常要因を前記要因候補として抽出する請求項２に記載の支援管理装置。
4. 前記データ蓄積部には、前記車両と同種のセンサを搭載した所定の車両から得られる要因が未知の異常種別の頻度分布を蓄積し、
   前記要因推定部は、前記データ蓄積部に蓄積された前記異常種別の頻度分布と、予め学習した認識モデルを用いて求めた過去の異常要因の発生の頻度分布とを比較することで要因候補を推定する請求項１～請求項３の何れか１項に記載の支援管理装置。
5. 前記走行支援部は、前記車両の各々の走行ルートを受信すると、前記車両の各々について、更新された前記要因マップに基づいて、発生している前記異常要因が前記走行ルートにある場合に、変更後の変更ルート候補を送信する請求項１～請求項４の何れか１項に記載の支援管理装置。
6. 前記要因マップ更新部は、オペレータ端末から選択された要因候補を受け付けると、当該選択された要因候補を異常要因として前記要因マップを更新する請求項１～請求項５の何れか１項に記載の支援管理装置。
7. データ蓄積部に、時間及び場所を対応付けた、車両のセンサの異常情報と、前記車両のカメラにより撮影したカメラ画像とが紐づけて蓄積されており、
   前記異常情報と、前記カメラ画像とに基づいて、異常の要因候補を推定し、
   推定された所定の前記要因候補を異常要因として時間及び場所に紐づけて、異常の発生状況及び要因を示す要因マップを更新し、
   更新された前記要因マップにより、異常の要因が特定された地点の周辺を走行する車両に対して前記異常要因を配信し、
   前記推定において、前記要因候補となる注目領域を前記カメラ画像に重畳した注目領域画像を生成し、
   更新された過去の前記要因マップを、地図上にマッピングする不調リスク区間及び前記要因候補ごとのヒストグラムとして表現し、
   オペレータ端末への通知の制御において、前記要因候補と、前記注目領域画像と、更新された過去の前記要因マップとを、前記オペレータ端末に通知するように制御する、
   処理をコンピュータが実行する支援管理方法。
8. データ蓄積部に、時間及び場所を対応付けた、車両のセンサの異常情報と、前記車両のカメラにより撮影したカメラ画像とが紐づけて蓄積されており、
   前記異常情報と、前記カメラ画像とに基づいて、異常の要因候補を推定し、
   推定された所定の前記要因候補を異常要因として時間及び場所に紐づけて、異常の発生状況及び要因を示す要因マップを更新し、
   更新された前記要因マップにより、異常の要因が特定された地点の周辺を走行する車両に対して前記異常要因を配信し、
   前記推定において、前記要因候補となる注目領域を前記カメラ画像に重畳した注目領域画像を生成し、
   更新された過去の前記要因マップを、地図上にマッピングする不調リスク区間及び前記要因候補ごとのヒストグラムとして表現し、
   オペレータ端末への通知の制御において、前記要因候補と、前記注目領域画像と、更新された過去の前記要因マップとを、前記オペレータ端末に通知するように制御する、
   処理をコンピュータに実行させる支援管理プログラム。