JP2021163072A - 情報処理方法、情報処理装置、及びプログラム - Google Patents

Abstract

【課題】簡易的に事故を検知すること、又は網羅的に事故を検知すること。
【解決手段】情報処理方法は、１又は複数の情報処理装置が、車両に搭載される各機器から取得された１又は複数のデータのうち、選択された少なくとも１つのデータに基づいて所定機器の故障が判定された場合、前記所定機器の故障情報を前記車両から取得し、前記故障情報に基づき事故を判定し、前記事故に関するレポートを出力する、処理を実行する。
【選択図】図１

Description

開示技術は、情報処理装置、情報処理方法、及びプログラムに関する。

従来、加速度センサを用いて車両の事故を検知するシステムが知られている（例えば特許文献１参照）。また、近年、車両に搭載されるセンサやデバイスなどの機器が増え、車両から取得できるデータの数が増えている。

特開２００８−１１７４２３号公報

しかしながら、車両から取得されるデータを用いて車両事故を検知する際、車両に搭載される各機器から取得されるデータの数は膨大であり、事故を検知するセンターにおいて、全てのデータを収集し、解析することになる。ここで、従来、事故検知を行うための手法は様々あるが、簡易的に事故を検知する手法、又は網羅的に事故を検知する手法は確立されていない。

開示技術は、以上説明した事情に鑑みてなされたものであり、簡易的に事故を検知すること、又は網羅的に事故を検知することを目的とする。

開示技術の一態様である情報処理方法は、１又は複数の情報処理装置が、車両に搭載される各機器から取得された１又は複数のデータのうち、選択された少なくとも１つのデータに基づいて所定機器の故障が判定された場合、前記所定機器の故障情報を前記車両から取得し、前記故障情報に基づき事故を判定し、前記事故に関するレポートを出力する、処理を実行する。

開示技術によれば、簡易的に事故を検知すること、又は網羅的に事故を検知することができる。

本開示の事故検知システムの概要を説明するための図である。 実施形態における車両の構成の一例を示す図である。 実施形態における事故検知サーバの構成の一例を示す図である。 実施形態に係る事故検知の概要の一例を示す図である。 実施形態に係る車両で取得されるデータの一例を示す図である。 実施形態に係る確信度の一例を示す図である。 実施形態に係る確信度の分類例を示す図である。 実施形態に係る事故の規模の分類例を示す図である。 実施形態に係る事故の類型の分類例を示す図である。 実施形態に係る分類判定情報の一例を示す図である。 実施形態に係るセンサの位置と事故位置との関係を示す図である。 実施形態に係る車両の処理の一例を示すフローチャートである。 実施形態に係る事故検知サーバの処理の一例を示すフローチャートである。

以下、本開示の実施形態について図面を参照しつつ詳細に説明する。なお、同一の要素には同一の符号を付し、重複する説明を省略する。

＜システム概要＞
図１は、本開示の事故検知システム１の概要を説明するための図である。図１に示す例において、事故検知システム１は、各車両１０Ａ、１０Ｂ、１０Ｃと、第１情報処理装置２０と、第２情報処理装置３０とがネットワークＮを介して接続されている。

各車両１０Ａ、１０Ｂ、１０Ｃは、個別に区別されない場合は車両１０と称す。車両１０は、二輪車や自律走行車両などを含み、ネットワークＮを介して他の装置と通信可能な車両である。車両は、コネクティッドカー、ドライブレコーダー搭載車に限らず、車両に関するデータを送信する機能を有していればよい。

車両１０は、デバイスやセンサなどの各機器を搭載する。デバイスは、例えば車両に後付け等で搭載されるデバイスであり、加速度センサ、マイク、ドライブレコーダー、カメラなどの録画機器などを含む。センサは、例えば、車両に予め搭載されるセンサであり、ミリ波、ライダー（ＬｉＤＡＲ）、ソナー、赤外線、エアバッグ、タイヤ空気圧などのセンシングするセンサを含む。車両に搭載される各機器は、随時もしくは、所定の状態が発生した時いずれかのタイミングで各機器により取得された情報（以下、機器データともいう）を、通信機能を利用して、直接的又は間接的に第１情報処理装置２０に送信する。

第１情報処理装置２０は、例えば事故検知を行うサーバであり、車両から取得されたデータを受信することで、車両事故が起きたか否かを判定する。以下、第１情報処理装置２０は、事故検知サーバとも称する。事故検知サーバ２０は、車両から取得したデータに基づき事故を検知すると、事故に関するレポートを第２情報処理装置３０に通知する。

第２情報処理装置３０は、例えば保険会社のオペレータ端末であり、事故検知サーバ２０からレポートを取得すると、レポート内容に基づいてその後の処理を実行する。

ネットワークＮは、例えば、インターネット、ＬＡＮ、専用線、電話回線、企業内ネットワーク、移動体通信網、ブルートゥース（登録商標）、ＷｉＦｉ（登録商標）（Wireless Fidelity）、その他の通信回線、それらの組み合わせ等のいずれであってもよく、有線であるか無線であるかを問わない。

＜車両の構成例＞
図２は、実施形態における車両１０の構成の一例を示す図である。図２に示すように、車両１０は、通信インタフェース１１と、記憶部１２と、プロセッサ１３と、各機器１５とを備える。

通信インタフェース１１は、車両１０をネットワークＮに接続し、ネットワークＮ上の他の端末や装置と通信をするためのハードウェアモジュールである。

記憶部１２は、例えば、ディスクドライブ又は半導体メモリ（ＲＯＭ、ＲＡＭなど）等のコンピュータ読み取り可能な記録媒体からなる物理デバイスの記憶領域が提供する論理デバイスである。記憶部１２は、複数の物理デバイスを１つの論理デバイスにマッピングして構築してもよいし、１つの物理デバイスを複数の論理デバイスにマッピングして構築してもよい。

記憶部１２は、オペレーティングシステムプログラムやドライバプログラムを含む各種プログラム及びこれらのプログラムの実行中に使用される各種データを格納する。具体的には、記憶部１２は、プロセッサ１３に実行させる各種のプログラムＰ１０と、各機器１５から取得した機器データＤ１０と、事故の分類に応じたデータ選択又は事故判定を行うための条件を含む条件情報Ｄ１２とを格納してもよい。

プロセッサ１３は、算術演算、論理演算、ビット演算等を処理する算術論理演算ユニット（ＣＰＵなど）及び各種レジスタから構成され、記憶部１２に格納されている各種プログラムを実行することで車両１０の各部を中枢的に制御する。各種レジスタは、例えば、プログラムカウンタ、データレジスタ、命令レジスタ、汎用レジスタ等である。

また、プロセッサ１３は、プログラムＰ１０を実行することにより、事故の発生を検知し、必要な通報を行う事故検知機能を実現する。プロセッサ１３がプログラムＰ１０を実行することにより実現される機能部には、取得部１３１と、判定部１３２と、選択部１３３と、出力部１３４とが含まれる。

取得部１３１は、車両１０に搭載される各機器１５から１又は複数のデータを取得する。例えば、取得部１３１は、加速度センサ、カメラ、マイク、車両センサなどの各機器１５から、加速度データ、画像（静止画像、及び／又は動画像）データ、音声データ、ミリ波データ、赤外線データ、エアバッグの発動を示すデータ、経度、緯度、ブレーキ作動状況を示すデータ、安全運転支援システムから取得されるデータ、ＡＣＣ電源に関するデータなどを取得する。

判定部１３２は、取得部１３１により取得された１又は複数のデータのうち、少なくとも１つのデータに基づいて、事故の可能性を判定する。例えば、判定部１３２は、予め定めされたデータを用いて簡易的に事故の可能性を判定する。一例として、判定部１３２は、加速度データ、音声データを用いて、各データが閾値を超えた場合に、事故の可能性ありと判定する。以下、この判定を、事故疑義トランザクションの判定などとも称する。

また、判定部１３２は、事故の分類に応じた事故の有無の判定を行ってもよい。例えば、判定部１３２は、取得部１３１により取得された全てのデータのうちの一部のデータを用いて、予め決められた事故の分類に含まれる事故が発生したか否かを判定する。一例として、判定部１３２は、エアバッグの発動を示すデータを取得した場合、大事故が発生したと判定する。

なお、事故の分類は、例えば大、中、小などの複数の分類を含む。判定部１３２は、各データに対して閾値を保持し、閾値を超えた場合に事故が発生したと判定してもよい。また、判定部１３２は、閾値を超えたデータの種類に応じて、事故の分類を判定してもよい。なお、事故の分類は、事故の規模の分類や、事故の類型の分類を含んでもよい。

選択部１３３は、判定部１３２により判定された事故の可能性に応じて、取得部１３１により取得された１又は複数のデータの中から送信対象のデータを選択する。例えば、選択部１３３は、取得部１３１により取得された全てのデータを事故検知サーバ２０に送信するのではなく、事故の可能性（例えば、確信度など）に応じて事故検知サーバ２０で必要となるデータを選択する。一例として、選択部１３３は、事故の可能性判定に用いたデータ以外にも、その他のデータを選択して事故検知サーバ２０に送信する。

また、選択部１３３は、判定部１３２に判定された事故の分類に応じて、取得部１３１により取得された１又は複数のデータの中から送信対象のデータを選択してもよい。例えば、選択部１３３は、取得部１３１により取得された全てのデータを事故検知サーバ２０に送信するのではなく、事故の分類（例えば時期の規模及び／又は事故の類型）に応じて事故検知サーバ２０で必要となるデータを選択する。なお、選択部１３３は、場合によっては全てのデータを選択してもよい。

出力部１３４は、選択部１３３により選択された送信対象のデータを他の情報処理装置（例えば事故検知サーバ２０）に出力するよう制御する。例えば、出力部１３４は、選択された１又は複数のデータを、通信インタフェース１１を介して、事故検知サーバ２０に送信する。

これにより、車両側で判定した事故の可能性又は事故の分類に応じて、適切なデータをサーバ側に送信することができる。また、適切なデータをサーバ側に送信することにより、通信帯域に負荷をかけずにすむ。

また、判定部１３２は、事故の箇所を推定することを含んでもよい。また、選択部１３３は、推定された事故の箇所に応じて、１又は複数のデータの中から送信対象のデータを選択することを含んでもよい。

例えば、判定部１３２は、事故の分類によっては、事故の分類の判定に用いたデータが車両のどの位置の機器であるかを特定し、特定された機器の位置に対応する車両の箇所において事故が発生したと判定してもよい。この場合、判定部１３２は、各機器が搭載された車両の位置の情報を保持しておけばよい。また、選択部１３３は、推定された車両の箇所に対応する機器から取得されるデータを少なくとも選択してもよい。

これにより、事故の箇所を推定することで、サーバ側に送信するデータの数をより絞ることが可能になり、通信帯域の負荷軽減、サーバ側の処理負荷軽減に寄与することができる。また、事故判定においても、推定された箇所を用いて事故の判定をすることで、事故判定の確信度を向上させることができる。

また、判定部１３２は、複数の事故の分類を段階的に判定することを含んでもよい。また、選択部１３３は、判定された事故の分類の段階数に応じて、送信対象のデータ数を変更することを含んでもよい。例えば、判定部１３２は、事故判定を多段階に分け、選択部１３３は、判定された段階に応じて、送信対象のデータ数を選択してもよい。

これにより、車両側から送信されるデータを多段階に分けることができ、サーバ側では、段階的な事故検知を行うことができる。また、段階的な事故検知により、初期段階で事故の検知が確定した場合は、サーバ側は、データ送信を停止するための通知を車両側に送信することができる。よって、車両側及びサーバ側双方の処理負荷軽減に寄与することができる。

判定部１３２は、１又は複数のデータの中の第１データが、事故の分類に含まれる車両が走行困難な第１事故（例えば大規模事故）について、この第１事故に関する第１所定条件を満たすか否かを、第１段階で判定することを含んでもよい。このとき、判定部１３２は、１又は複数のデータの中の第２データが、事故の分類に含まれる第１事故以外の第２事故（例えば中、小規模）について、この第２事故に関する第２所定条件を満たすか否かを、第２段階で判定してもよい。

例えば、第１条件は、エアバッグの発動を示すデータがあることを含み、判定部１３２は、エアバッグの発動に基づいて大規模の事故を、第１段階として判定するようにしてもよい。また、第１条件には、安全運転支援システムの作動を示すデータがあることなどを含んでもよい。第２条件は、例えば、加速度センサのセンサデータが閾値を超えること、音声データのデータが閾値の音量を超えること、画像データが所定の画像を示すことなどを含み、判定部１３２は、これらの条件を満たすか否かを、第２段階として判定してもよい。

これにより、確信度の高い事故判定を第１段階にすることで、その後の車両側からサーバ側へのデータ送信を行わなくて済み、確信度が高くない事故判定を第２段階以降にすることで、この段階で必要なデータをサーバ側に送信することができる。よって、車両側で取得されるデータ全てを、事故検知のためにサーバ側に送信するのではなく、効率的にデータを送信することが可能になる。

また、判定部１３２は、第２段階で判定する第２事故として複数の事故を含む場合、この第２段階の複数の事故それぞれに対応する所定条件を満たすか否かを判定してもよい。例えば、第２段階で判定する事故として、中規模の事故、小規模の事故の２つの分類の事故を判定してもよく、この場合、判定部１３２は、中規模及び小規模それぞれの条件を満たすか否かを判定してもよい。

これにより、事故の分類数に応じて段階数を増やすことで、事故検知やデータ送信のバリエーションを増やすことができる。さらに、段階数が増えるにつれ、送信するデータ数が増えるようにすると、初期段階の方で事故が検知されれば、送信するデータ数を減らすことに寄与することができ、通信帯域の負荷減少、処理負荷軽減に貢献することができる。

また、判定部１３２は、各種センサの故障に関する条件を満たすか否かを判定してもよい。各種センサの故障に関する条件は、例えば、異常値が所定時間続く、又はセンサからの信号を所定時間検知できないなどである。判定部１３２により故障が判定されると、出力部１３４は、故障を示す情報を、通信インタフェース１１を介して事故検知サーバ２０に出力してもよい。

＜事故検知サーバの構成例＞
図３は、実施形態における事故検知サーバ２０の構成の一例を示す図である。図３に示すように、事故検知サーバ２０は、通信インタフェース２１と、記憶部２２と、プロセッサ２３とを備える。

通信インタフェース２１は、車両１０をネットワークＮに接続し、ネットワークＮ上の他の端末と通信をするためのハードウェアモジュールである。

記憶部２２は、例えば、ディスクドライブ又は半導体メモリ（ＲＯＭ、ＲＡＭなど）等のコンピュータ読み取り可能な記録媒体からなる物理デバイスの記憶領域が提供する論理デバイスである。記憶部２２は、複数の物理デバイスを１つの論理デバイスにマッピングして構築してもよいし、１つの物理デバイスを複数の論理デバイスにマッピングして構築してもよい。

記憶部２２は、オペレーティングシステムプログラムやドライバプログラムを含む各種プログラム及びこれらのプログラムの実行中に使用される各種データを格納する。具体的には、記憶部２２は、プロセッサ２３に実行させる各種のプログラムＰ２０と、車両１０から取得した機器データＤ２０と、事故検知に用いる条件情報Ｄ２２と、事故検知に関するレポートを含む結果情報Ｄ２４とを格納する。

プロセッサ２３は、算術演算、論理演算、ビット演算等を処理する算術論理演算ユニット（ＣＰＵなど）及び各種レジスタから構成され、記憶部２２に格納されている各種プログラムを実行することで事故検知サーバ２０の各部を中枢的に制御する。各種レジスタは、例えば、プログラムカウンタ、データレジスタ、命令レジスタ、汎用レジスタ等である。

また、プロセッサ２３は、プログラムＰ２０を実行することにより、事故の発生を検知し、必要な通報を行う事故検知機能を実現する。プロセッサ２３がプログラムＰ２０を実行することにより実現される機能部には、取得部２３１と、判定部２３２と、出力部２３７とが含まれる。

取得部２３１は、車両１０に搭載される各機器１５から取得された１又は複数のデータのうち、選択された少なくとも１つのデータを車両１０から取得する。例えば、取得部２３１は、通信インタフェース２１を介して、車両１０から送信されたデータを取得する。このとき、車両１０からは、取得可能なデータ全てが毎回送信されるのではなく、選択されたデータが送信されるため、サーバ側のメモリ量を削減したり、処理負荷を軽減したりすることが可能になる。

判定部２３２は、取得部２３１により取得された少なくとも１つのデータに基づいて、事故の有無を総合的に判定する。判定部２３２は、総合的に事故を判定するため、事故判定部２３４と、事故分類部２３５と、確信度分類部２３６とを有する。

事故判定部２３４は、取得部２３１により取得されたデータを用いて、総合的に事故が起きたか否かを判定するための所定条件に基づき、事故を判定する。例えば、事故判定部２３４は、各種データの閾値を保持し、各種データが閾値を超えたか否かに基づいて、事故の可能性があるか否かを判定するための判定情報を保持してもよい。判定情報については、図１０を用いて後述する。

事故分類部２３５は、事故の可能性があると判定された場合、この事故の種類を分類する。例えば、事故分類部２３５は、上述した判定情報に含まれる、又は別途の分類情報を用いて、事故の分類を行ってもよい。また、事故分類部２３５は、事故の規模と、事故の類型とを分類してもよい。

確信度分類部２３６は、事故の判定に関する確信度を分類する。事故判定に寄与したデータ又は閾値との差分値等に応じて、事故判定に対する確信度を分類する。例えば、確信度分類部２３６は、上述した判定情報に含まれる、又は別途の判定情報を用いて、確信度の分類を行ってもよい。

出力部２３７は、事故に関し、分類された結果を含むレポートを出力する。例えば、出力部２３７は、判定部２３２から判定結果、及び／又は分類結果を取得し、事故検知の有無、発生した事故の確信度の程度（分類）、発生した事故の規模（分類）、事故の類型（分類）を含むレポートを作成して出力する。出力先は、例えば、第２情報処理装置（オペレータ端末）３０等である。

これにより、サーバ側は、適切なデータに基づいて事故検知を行うことができ、サーバ側の処理負荷を軽減することができる。また、事故を検知する目的は、事業者によってさまざまであり、一概にすべての事故を検知するのではなく、その目的に沿って「どのような事故か」を検知することではじめて、ビジネスニーズに答えることができる。例えば、レッカー手配を目的とした事故検知であれば、大規模の事故を検知する必要があり、小規模事故は検知する必要はない、などである。

次に、事故検知の効率化を含む総合的な事故検知について説明する。以下では、センサからのデータに基づいて機器の故障情報（故障データ）を車両から取得し、故障情報に基づいて事故を判定する実施形態や、故障情報に基づく事故判定を含む総合的な事故検知を行う実施形態について説明する。

ここで、事故を検知する手法は、従来には様々な手法があるが、全てを網羅的に判断して事故を検知する手法は確立されていない。ここで、事故検知に使用可能な、車両１０から取得されるデータの特徴を以下に記載する。
・加速度：一定の規模以上の事故であれば相応の衝撃が発生し、検知することも可能であるが、小規模事故の検知には不向き
・動画：ＡＩ（Artificial Intelligence）等を用いることで、軽微な事故も検知可能だがカメラの視野に応じて検知できる範囲は限定的
・音声：大・小規模を問わず事故時には音が発生するため、網羅的に検知できる可能性はあるが、社内には様々な音が発生するため精度に難
・車両データ(エアバッグ等)：大規模な事故を目的とした機能及びその発動結果のデータであり、小規模事故の検知には不向き
・ミリ波レーダー等：周辺物との距離測定が可能であり、物体との衝突を検知できる可能性はあるが、センサの方向・検知可能な物体が限定的
・センサ故障情報：衝突によるものか経年劣化か、等の特定が不可能。ただし、他の情報と組み合わせることで精度向上に寄与

本実施形態では、上述されたデータのうち、少なくとも１つ以上のデータを用いて、車両側及び／又はサーバ側で網羅的な事故検知を行う。

事故検知サーバ２０の取得部２３１は、車両１０に搭載される各機器１５から取得された１又は複数のデータのうち、選択された少なくとも１つのデータに基づいて所定機器の故障が判定された場合、所定機器の故障情報を車両１０から取得する。

例えば、車両１０は、センサデータを取得できない場合、または異常値を所定時間以上取得し続ける場合、その車両センサの故障を検知し、故障情報を事故検知サーバ２０に送信してもよい。車両センサの例としては、ミリ波センサ、ライダーセンサ、ソナーセンサ、赤外線センサ、エアバッグの発動センサ、タイヤ空気圧を検査するセンサなどがあげられる。

判定部２３２は、故障情報に基づき事故を判定してもよい。この場合、出力部２３７は、事故に関するレポートを出力する。例えば、判定部２３２は、センサに故障情報があると簡易的に事故と判定して、出力部２３７は、故障と判定されたセンサと、例えば小規模の事故であることとを含むレポートを作成して出力する。出力先は、例えば、オペレータ端末３０等である。

これにより、車両側やサーバ側で、センサの故障情報を用いて簡易的に車両の事故を検知することができる。また、検知結果を保険会社のオペレータ端末３０等に送信することができ、オペレータは、レポートの内容に応じて、その後の事故処理を行うことができる。

また、判定部２３２は、各機器１５の中の所定機器から取得されるデータが車両１０から取得されない場合に、車両１０の事故を判定してもよい。また、車両側において、所定機器からデータが取得できない場合に、故障と判定し、故障であることを含む故障情報が事故検知サーバ２０に送信されてもよい。

これにより、事故検知サーバ２０は、データを出力できない、故障したセンサの位置に、何らかの事故が起きたと判定することができる。

取得部２３１は、１又は複数のデータのうちの所定データを車両１０から取得することを含んでもよく、判定部２３２は、所定データ及び故障情報に基づいて、事故を判定することを含んでもよい。例えば、判定部２３２は、故障情報と、他のデータとを総合的に用いて事故を判定してもよい。このとき、判定部２３２は、事故の分類を判定可能な条件に基づいて、事故の分類を判定してもよい。

これにより、車両１０から取得される各データを網羅的に用いて、総合的に事故を判定（事故検知）することができる。従来、それぞれのデータに対して事故検知をすることができたが、本実施形態では、車両１０から取得される、故障情報を含む各種データに基づいて事故検知をすることができる。

車両１０から取得される所定データは、画像データ、音声データ、加速度データ、緯度及び／又は経度データ及び車両１０のセンサから取得されるセンサデータを含んでもよい。これにより、車両１０に搭載される主要なデータを総合的に用いて事故検知を行うことができる。

判定部２３２は、各機器１５から取得される事故時の１又は複数のデータを学習データに用いて学習された学習済モデルを保持する。この場合、判定部２３２は、この学習済モデルに基づき、事故の判定を行うことを含んでもよい。学習は、教師データあり、教師データなしの学習いずれでもよい。例えば、判定部２３２は、取得された１又は複数のデータを学習済モデルの関数に入力することで、事故の可能性を出力すればよい。

これにより、車両１０から取得可能な各種データを網羅的に用いて、確度の高い事故検知処理を実行することができるようになる。なお、検知対象の車両１０は、コネクティッドカーやドライブレコーダー搭載車に限られない。

また、判定部２３２は、上述したように、事故が判定された場合、事故分類部２３５により事故を分類し、確信度分類部２３６により、事故の確信度を分類することを含んでもよい。この場合、出力部２３７は、事故に関し、分類された結果を含むレポートを出力することを含んでもよい。

これにより、総合的に判断された結果をレポートとして、表示装置に表示したり、オペレータ端末３０に送信したりすることができる。

以上、上述した実施形態における車両１０によれば、上述の各種データの複数種類のデータを用いて、一定の条件を満たすか否かの判定結果に基づいて、事故疑義事案をピックアップし、疑義がある事故の分類を実施することができる。また、車両１０は、事故疑義事案の分類に応じて、必要となるデータを抽出し、サーバ側にデータを送信し、サーバ側は、取得したデータに基づいて、総合的に事故か否かの判定を行ってもよい。

また、事故検知システム１は、車両側での処理と、サーバ側での処理とを分担することにより、通信データ量の最適化と事故検知にかかるレスポンスへの遅延回避を実現することができる。また、事故検知システム１は、取得したデータを用いて、その後のビジネス、及び業務目的に応じた事故分類結果を活用することができる。

＜事故検知の概要＞
図４は、実施形態に係る事故検知の概要の一例を示す図である。図４に示すように、事故検知は、車両側とサーバ側とに分けられる。まず、車両側の処理の概要に説明する。車両側は、事故疑義検知の処理と、データの収集、送信の処理とを有する。

事故疑義検知の処理は、第１所定データに対して常時監視する処理を含む。例えば、取得部１３１は、加速度データ及び音声データを取得すると、判定部１３２は、加速度データが所定値を超えるか否かを判定し、音声データが所定の音量（デシベル）を超えるか否かを判定し、かつ、周波数帯域の音を検知する。これは、車両１０が、加速度データ、音声データなどの第１所定データを常時監視して、事故と思われるトランザクション（事故疑義トランザクション）を広めに検知することを目的とする。

事故疑義検知の処理は、追加情報収集、チェックの処理を含む。例えば、取得部１３１は、常時監視で用いた第１所定データ以外の第２所定データを取得し、判定部１３２は、常時監視により事故疑義トランザクションがあれば、追加で第２所定データを用いて故障個所を推定する。第２所定データは、例えばミリ波データなどに関する機器故障情報であり、機器の故障が判定されれば、その機器の搭載位置が故障個所であると推定される。これにより、検知した事故疑義トランザクションの信頼度を確認するため、他の情報をチェックすることができる。

データの収集、送信の処理は、選択部１３３が、サーバ側で事故か否かを判定する際に必要な情報を収集するための処理を含む。選択部１３３は、第１所定データ及び第２所定データに加え、車両センサから取得されるデータ（ミリ波データ、ライダーデータなど）を選択する。出力部１３４は、選択されたデータを事故検知サーバ２０に送信する。

次に、サーバ（センター）側の処理の概要について説明する。サーバ側の処理は、事故総合判定処理と、確信度分類処理と、事故分類処理とを含む。

事故総合判定処理は、取得部２３１が、車両側から送信されたデータを取得し、事故判定部２３４が、取得されたデータを総合的に判断し、事故の判定処理を行う処理を含む。事故判定部２３４は、例えば、人口知能（ＡＩ）を使用して事故を総合的に判定してもよい。

確信度分類処理は、確信度分類部２３６が、事故の総合判定処理の結果に基づいて確信度を分類する処理を含む。確信度分類部２３６は、事故総合判定結果に起因したデータ（例えば閾値を超えたデータ）等を用いて、判定された結果の確信度を分類する。例えば、確信度分類部２３６は、以下の分類を行う。
確信度１：事故確率０％
確信度２：事故確率２５％
確信度３：事故確率５０％
確信度４：事故確率７５％
確信度５：事故確率１００％
なお、確信度分類部２３６による分類は上記例に限られない。

事故分類処理は、事故分類部２３５が、事故総合判定結果に基づいて、事故を複数のレベルに分類する処理を含む。例えば、事故分類部２３５は、事故の規模と、事故の類型とを分類するとする。
（事故の規模）
レベル１：小規模事故、自走可能
レベル２：中規模事故、レッカー手配およびケガの可能性がある
レベル３：大規模事項、レッカー手配およびケガの可能性が高い
（事故の類型）
類型１：人対車両
類型２：車両対車両（正面衝突、側面衝突等）
類型３：車両単独事故（道路外逸脱、構造物衝突等）
なお、事故分類部２３５による分類は上記例に限られない。

＜データ例＞
次に、図５〜１０を用いて事故検知システム１で使用されるデータについて説明する。図５は、実施形態に係る車両１０で取得されるデータの一例を示す図である。図５に示す例では、車両１０が取得するデータが、デバイス、車両、機器故障の３つのカテゴリに分類される。なお、図５に示すデータは、機器データＤ１０として記憶部１２に記憶されてもよい。また、図５に示す＊印が付与されたデータは、例えば車両１０がコネクティッドカーの場合に取得可能なデータである。

デバイスのデータは、一例として、加速度センサから取得される加速度データ、マイクから取得される音声データ、カメラから取得される画像データ、ＧＰＳ等の位置計測器から取得される緯度、経度データを含む。このうち、加速度データ及び音声データは、常時監視データとして用いられ、車両側での事故疑義トランザクションの判定に用いられる。また、デバイスデータは、事故検知サーバ２０に送信される対象となるデータである。

車両のデータは、車両センサから取得されるデータであり、一例として、エアバッグのセンサから取得されるエアバッグの発動データ、タイヤ空気圧のセンサから取得されるタイヤ空気圧データ、ミリ波センサから取得されるミリ波データ、ライダーから取得されるライダーデータ、ソナーセンサから取得されるソナーデータ、赤外線センサから取得される赤外線データ、ブレーキ作動状況を示すデータ、安全運転支援システムから取得されるデータ、ＡＣＣ電源に関するデータを含む。このうち、エアバッグの発動データ、タイヤ空気圧データは、車両側での事故疑義トランザクションの判定に用いられる。また、車両データは、事故検知サーバ２０に送信される対象となるデータである。

機器故障情報は、機器が故障したか否かを示す情報であり、判定に用いられるデータは、ミリ波センサから取得されるミリ波データ、ライダーから取得されるライダーデータ、ソナーセンサから取得されるソナーデータ、赤外線センサから取得される赤外線データ、その他の機器から取得されるデータである。判定部１３２は、機器が故障したと判定される条件として、例えば、データが所定期間取得されない、又は所定値を超える異常値データが所定期間継続しているなどを含む。

図６は、実施形態に係るデータの信頼度の一例を示す図である。図６に示す例では、各データに関連付けて、信頼度が付与される。例えば、加速度データの信頼度は、Ｃ（信頼度小）であり、ミリ波データの信頼度は、Ｂ（信頼度中）であり、エアバッグの発動データの信頼度は、Ａ（信頼度大）である。

確信度分類部２３６は、例えば図６に示すデータを用いて、事故の判定において、判定結果に寄与したデータの信頼度を用いて、事故の判定結果の確信度を分類してもよい。例えば、確信度分類部２３６は、事故の判定に用いたデータと、確信度の分類条件とに基づいて確信度を分類する。確信度の分類条件の具体例は、事故の判定に用いたデータの信頼度Ａ、Ｂ、Ｃの割合に応じて、確信度１〜５に分類する条件を含む。例えば、確信度分類部２３６は、事故の判定に用いたデータのうち、信頼度Ａが１つでもあれば、確信度５に分類したり、データの信頼度Ｂ、Ｃのうち、Ｂが多ければ確信度３にしたりする。なお、図６に示すデータは、条件情報Ｄ２２として記憶部２２に記憶されてもよい。

図７は、実施形態に係る確信度の分類例を示す図である。図７に示す例では、上述したとおり、以下の分類条件が示される。
確信度１：事故確率０％
確信度２：事故確率２５％
確信度３：事故確率５０％
確信度４：事故確率７５％
確信度５：事故確率１００％
なお、図７に示すデータは、条件情報Ｄ２２として記憶部２２に記憶されてもよい。

図８は、実施形態に係る事故の規模の分類例を示す図である。図８に示す例では、上述したとおり、以下の分類条件が示される。
レベル１：小規模事故、自走可能
レベル２：中規模事故、レッカー手配およびケガの可能性がある
レベル３：大規模事項、レッカー手配およびケガの可能性が高い
なお、図８に示すデータは、条件情報Ｄ２２として記憶部２２に記憶されてもよい。

図９は、実施形態に係る事故の類型の分類例を示す図である。図９に示す例では、上述したとおり、以下の分類条件が示される。
類型１：人対車両
類型２：車両対車両（正面衝突、側面衝突等）
類型３：車両単独事故（道路外逸脱、構造物衝突等）
なお、図９に示すデータは、条件情報Ｄ２２として記憶部２２に記憶されてもよい。

図１０は、実施形態に係る分類判定情報の一例を示す図である。図１０に示す分類判定情報（例えば分類判定テーブル）は、判定部２３２により用いられ、総合判定、確信度の分類、事故の分類が可能である。また、分類判定情報は、確信度と、事故の規模とを分類するための分類情報と、事故の可能性を判定するための判定情報とを含んでもよい。

例えば、各種データは、加速度データ、音声データ、画像データ、センサゼロ距離データ、センサ対象物との距離データ、故障情報などである。これらのデータが異常を示せば「１」、異常なしであれば「０」となる。また、移動判定データは、移動可能であれば「１」、移動不可能であれば「０」とし、ＡＣＣ電源データは、電源のＯＮ／ＯＦＦに異常がなければ「１」であり、異常があれば「０」とする。これらの値に基づいて、判定部２３２は、確信度を分類し、事故の規模を分類し、判定理由により事故総合判定の結果を把握する。なお、分類判定テーブルは、機械学習を用いて、各種データの生のデータを利用して学習させた学習済モデルに代替可能である。つまり、判定部２３２は、加速度データからＡＣＣ電源データまでを入力データとし、学習済みモデルに入力データを入力することで、確信度と事故の規模とを出力することが可能である。

＜事故位置の推定＞
図１１は、実施形態に係るセンサの位置と事故位置との関係を示す図である。図１１に示す領域ＡＲは、各センサにより検知される領域を示す。各センサは、車両１０のどの位置に搭載されたかが特定できるため、例えば、判定部１３２は、所定センサからデータを取得できない場合、その所定センサに関連付けられた車両１０の位置を特定し、その位置において事故の可能性があることを推定することが可能になる。

＜動作処理＞
次に、事故検知システム１の処理について説明する。図１２は、実施形態に係る車両１０の処理の一例を示すフローチャートである。図１２に示す例では、ステップＳ１０２で、取得部１３１は、車両１０に搭載された各機器１５からのデータを取得する。取得するタイミングは各機器１５に応じたタイミングでよい。

ステップＳ１０４で、判定部１３２は、取得部１３１により取得された１又は複数のデータのうち、少なくとも１つのデータに基づいて、事故の可能性を判定する。例えば、判定部１３２は、所定データに基づいて事故があるか否かを判定する。一例として、判定部１３２は、エアバッグの発動信号を取得すれば、重大事故（例えば事故分類Ａ）があると判定する。重大事故があると判定されれば（ステップＳ１０４−ＹＥＳ）、処理はステップＳ１０６に進み、重大事故がないと判定されれば（ステップＳ１０４−ＮＯ）、処理はステップＳ１０８に進む。

ステップＳ１０６で、選択部１３３は、事故の可能性に応じて、送信対象のデータを選択する。例えば選択部１３３は、エアバッグの発動信号を選択する。このとき、出力部１３４は、通信インタフェース１１を介して、選択されたエアバッグの発動信号を事故検知サーバ２０に送信する。

ステップＳ１０８で、判定部１３２は、加速度データが閾値を超えたか否かを判定する。加速度データが閾値を超えれば（ステップＳ１０８−ＹＥＳ）、処理はステップＳ１１０に進み、加速度データが閾値を超えなければ（ステップＳ１０８−ＮＯ）、処理はステップＳ１１２に進む。

ステップＳ１１０で、選択部１３３は、事故の可能性（例えば事故の箇所）に応じて、必要なデータを選択し、出力部１３４は、選択されたデータを、通信インタフェース１１を介して事故検知サーバ２０に送信する。例えば、選択部１３３は、加速度データにおいて閾値を超えたデータを用いて衝撃の方向を特定し、その方向に対応するデータを選択してもよい。

ステップＳ１１２で、判定部１３２は、音声データが閾値を超えたか否かを判定する。音声データが閾値を超えれば（ステップＳ１１２−ＹＥＳ）、処理はステップＳ１１４に進み、音声データが閾値を超えなければ（ステップＳ１１２−ＮＯ）、処理はステップＳ１１６に進む。音声データが閾値を超えるとは、例えば、音量が閾値を超えたり、音声を周波数変換して、周波数変換後のパワースペクトルが閾値を超えたりすることを含む。

ステップＳ１１４で、選択部１３３は、事故の可能性（例えば事故の箇所）に応じて、必要なデータを選択し、出力部１３４は、選択されたデータを、通信インタフェース１１を介して事故検知サーバ２０に送信する。例えば、選択部１３３は、音声データにおいて音の音源の方向が推定できる場合は、その方向に対応するデータを選択してもよく、音声に対して音声認識を行って、方向に対応する音声が含まれていれば、その方向に対応するデータを選択してもよい。

ステップＳ１１６で、判定部１３２は、車両１０がコネクティッドカー以外か否かを判定する。車両１０がコネクティッドカーでなければ（ステップＳ１１６−ＹＥＳ）、処理はステップＳ１１８に進み、車両１０がコネクティッドカーであれば（ステップＳ１１６−ＮＯ）、処理はステップＳ１２０に進む。

ステップＳ１１８で、選択部１３３は、事故の可能性（例えば事故の箇所）に応じて、必要なデータを選択し、出力部１３４は、選択されたデータを、通信インタフェース１１を介して事故検知サーバ２０に送信する。例えば、選択部１３３は、サーバ側で事故を詳細に判定させるため、図５に示すカテゴリが「デバイス」および「車両」に関する全てのデータを選択してもよい。

ステップＳ１２０で、取得部１３１は、機器の故障データを取得する。なお、取得部１３１において故障データを取得するタイミングは、このタイミングでなくてもよく、各機器１５から送信されるタイミングで取得部１３１が取得すればよい。

ステップＳ１２２で、判定部１３２は、機器の故障を示す故障データがあるか否かを判定する。例えば、判定部１３２は、異常値が所定期間の間何度も計測されたり、データが取得されなかったりした場合に、機器に故障ありと判定してもよい。故障が判定されれば（ステップＳ２２−ＹＥＳ）、処理はステップＳ１２４に進み、故障が判定されなければ（ステップＳ１２２−ＮＯ）、処理はステップＳ１２６に進む。

ステップＳ１２４で、選択部１３３は、事故の可能性（例えば事故の箇所）に応じて、必要なデータを選択し、出力部１３４は、選択されたデータを、通信インタフェース１１を介して事故検知サーバ２０に送信する。例えば、選択部１３３は、故障データに対応する機器の位置（故障部位）を用いて、その位置に対応するデータを選択してもよい。

ステップＳ１２６で、判定部１３２は、事故の可能性なしと判定する。この後、ステップＳ１０２に戻り、取得部１３１は、次のデータを取得する。

以上の処理により、車両１０は、事故判定を行うためのデータを選択して送信することで、データを効率よく用いて事故判定（事故検知）を行うことができる。また、車両側で取得されるデータ全てを、毎回送信しなくてもよく、通信帯域の負荷軽減、事故検知サーバ２０の処理負荷軽減に寄与することができる。

図１３は、実施形態に係る事故検知サーバ２０の処理の一例を示すフローチャートである。図１３に示す例では、ステップＳ２０２で、取得部２３１は、車両１０から送信されたデータを取得する。車両１０は、送信対象のデータを適宜選択するが、取得可能なデータを全て選択してもよい。

ステップＳ２０４で、事故判定部２３４は、取得された各データを用いて、総合的な事故判定を行う。例えば、事故判定部２３４は、各種データに対応して、事故判定に関する各所定条件を保持しておき、取得された各データに対する判定結果に基づき、総合的な事故判定を行う。一例としては、事故判定部２３４は、図１０に示す分類判定情報を用いて、総合的な事故判定を行ってもよい。

ステップＳ２０６で、確信度分類部２３６は、取得された各データに基づいて、事故判定に関する確信度を分類する。例えば、確信度分類部２３６は、図１０に示す分類判定情報を用いて、確信度を分類してもよい。

ステップＳ２０８で、事故分類部２３５は、取得された各データに基づいて、事故判定された事故の規模を分類する。例えば、事故分類部２３５は、図１０に示す分類判定情報を用いて、事故の規模を分類してもよい。

ステップＳ２１０で、事故分類部２３５は、取得された各データに基づいて、事故判定された事故の類型を分類する。例えば、事故分類部２３５は、加速度データ、画像、音声データ等に基づいて、事故の類型を分類する。例えば、加速度データに基づく衝突箇所、画像に車両又は人物が写っているか、音声により所定の単語（例えば「ぶつかる」）が発声されたか等が用いられ、事故の類型が分類される。

ステップＳ２１２で、判定部２３２は、分類された事故の規模、確信度、事故の総合的判定に基づいて、事故があったか否かを判定する。例えば、判定部２３２は、確信度が高いものは、事故の分類や総合判定に関わらず事故があったと判定してもよく、また、確信度が低くても、総合判定の結果によって事故の可能性有と判定してもよい。

ステップＳ２１４で、出力部２３７は、分類された結果を含むレポートを出力する。例えば、出力部２３７は、オペレータ端末３０にレポートを送信する。また、レポートは、総合判定の内容、分類された確信度、分類された事故の規模、分類された事故の類型の少なくとも１つを含んでもよい。この後、処理はステップＳ２０２に戻る。

ステップＳ２１６で、判定部２３２は、事故は発生していないと判定した場合、処理はステップＳ２０２に戻る。

以上の処理により、事故検知サーバ２０は、車両側で選択されたデータを用いて効率よく事故判定を行うことができる。また、事故検知サーバ２０は、車両側で取得可能な全てのデータを毎度記憶する必要がないため、メモリ量を削減することができ、処理するデータ量を減らすことができるため、処理負荷を軽減することができる。また、事故検知サーバ２０は、取得したデータを用いて、その後のビジネス及び業務目的に応じた事故分類結果等を出力することができる。

＜変形例＞
以上、実施形態について詳述したが、上記実施形態に限定されるものではなく、特許請求の範囲に記載された範囲内において、上記実施形態以外にも種々の変形及び変更が可能である。

上述した処理のフローに含まれる各処理ステップは、処理内容に矛盾を生じない範囲で、任意に順番を変更して又は並列に実行することができるとともに、各処理ステップ間に他のステップを追加してもよい。また、便宜上１ステップとして記載されているステップは、複数ステップに分けて実行することができる一方、便宜上複数ステップに分けて記載されているものは、１ステップとして把握することができる。

また、上述した各処理は、コンピュータにより実行されるプログラムとして実装されてもよい。このプログラムは、コンピュータにインストールされたり、コンピュータに読み取り可能な記録媒体（例えば非一時的な記録媒体）に記憶されたりし、コンピュータの制御部（例えばプロセッサなど）により実行されることで、上記処理が実現されてもよい。

１…事故検知システム
１０…車両
２０…第１情報処理装置（事故検知サーバ）
３０…第２情報処理装置（オペレータ端末）
１１、２１…通信インタフェース
１２、２２…記憶部
１３、２３…プロセッサ
１５…各機器
１３１、２３１…取得部
１３２、２３２…判定部
１３３…選択部
１３４、２３７…出力部
２３４…事故判定部
２３５…事故分類部
２３６…確信度分類部

Claims (8)

1. １又は複数の情報処理装置が、
   車両に搭載される各機器から取得された１又は複数のデータのうち、選択された少なくとも１つのデータに基づいて所定機器の故障が判定された場合、前記所定機器の故障情報を前記車両から取得し、
   前記故障情報に基づき事故を判定し、
   前記事故に関するレポートを出力する、処理を実行する情報処理方法。
2. 前記判定することは、
   所定機器から取得されるデータが取得されない場合に、前記車両の事故を判定することを含む、請求項１に記載の情報処理方法。
3. 前記取得することは、
   前記１又は複数のデータのうちの所定データを前記車両から取得することを含み、
   前記事故を判定することは、
   前記所定データ及び前記故障情報に基づき事故を判定することを含む、請求項１又は２に記載の情報処理方法。
4. 前記所定データは、画像データ、音声データ、加速度データ、及び前記車両のセンサから取得されるセンサデータを含む、請求項１乃至３いずれか一項に記載の情報処理方法。
5. 前記判定することは、
   前記機器から取得される事故時の１又は複数のデータを学習データに用いて学習された学習済モデルに基づき、事故の判定を行うことを含む、請求項１乃至４いずれか一項に記載の情報処理方法。
6. 前記判定することは、
   前記事故が判定された場合、前記事故を分類すること、
   前記事故に関する確信度を分類すること、を含み、
   前記出力することは、
   前記事故に関し、分類された結果を含むレポートを出力することを含む、請求項１乃至５いずれか一項に記載の情報処理方法。
7. １又は複数の情報処理装置に、
   車両に搭載される各機器から取得された１又は複数のデータのうち、選択された少なくとも１つのデータに基づいて所定機器の故障が判定された場合、前記所定機器の故障情報を前記車両から取得し、
   前記故障情報に基づき事故を判定し、
   前記事故に関するレポートを出力する、処理を実行させるプログラム。
8. 車両に搭載される各機器から取得された１又は複数のデータのうち、選択された少なくとも１つのデータに基づいて所定機器の故障が判定された場合、前記所定機器の故障情報を前記車両から取得する取得部と、
   前記故障情報に基づき事故を判定する判定部と、
   前記事故に関するレポートを出力する出力部と、を備える情報処理装置。

Images