JP7468374B2 - 車両診断システム - Google Patents

Description

この発明は、車両診断システムに関する。

特許文献１に開示された車両の制御装置は、ユーザが車両に何らかの異変を感じた時に車両の故障を診断するための診断処理を実行可能である。制御装置は、ユーザの指示に応じて診断処理を実行する。制御装置は、診断処理を実行すると、故障個所を特定したり、ディーラへの車両の持ち込みを促したりする。

特許第４７０６８９０号公報

故障の内容によっては、ユーザが車両の異変を感じ難いものもある。特許文献１の技術では、ユーザが異変を感じて診断処理の実行を制御装置に指示しない限り、制御装置は診断処理を実行しない。そのため、ユーザが異変を感じないような故障が生じたとしても、その故障を、診断処理を実行して把握することはできない。

上記課題を解決するための車両診断システムは、車両における車室の内部と外部とを隔てている部品の異常を診断する診断装置と、前記車室の外部に位置し、音圧及び周波数のうちの少なくとも一方が予め定められている音を発する音源と、前記車室の内部に位置するマイクとを有し、前記診断装置は、前記音源が音を発したときに、前記マイクが検出する音に関する検出音データを取得する取得処理と、前記検出音データを予め定められた基準音データと比較して前記部品の異常の有無を判定する判定処理とを実行する。

上記構成によれば、診断装置は、マイクが検出した音に基づく検出音データを基準音データと比較することにより、車室の内部と外部とを隔てる部品の異常の有無を判定する。そして、診断装置は、この検出音データを、車両に搭載された音源が音を発したときに取得するため、ユーザが部品の異常を感じた場合でなくても、当該診断装置は検出音データを取得できる。すなわち、上記構成では、ユーザが部品の異常を感じたか否かに拘わらず、部品の異常の有無を判定できる。

車両診断システムにおいて、前記音源が発する音は、音圧が予め定められており、前記診断装置は、前記判定処理において、前記検出音データにおける音圧と前記基準音データにおける音圧との差に基づいて、前記部品の異常の有無を判定してもよい。

車室の内部と外部とを隔てている部品に異常が生じると、音源が発する音が車室の内部に至り易くなることがある。この場合、マイクが検出する音の音圧は大きくなる可能性が高い。上記構成によれば、こうした特性を利用して判定を行うことで、車室の内部と外部とを隔てている部品の異常を適切に判定できる。

車両診断システムにおいて、前記音源が発する音は、周波数が予め定められており、前記音源が音を発し終えてからの音圧の減衰速度を音圧減衰速度としたとき、前記診断装置は、前記判定処理において、前記検出音データにおける音圧減衰速度と前記基準音データにおける音圧減衰速度との差に基づいて、前記部品の異常の有無を判定してもよい。

車室の内部と外部とを隔てている部品に異常が生じると、車室の外部から内部へと至る音が車室の内部で減衰し難くなることがある。この場合、マイクが検出する音の減衰速度は遅くなる可能性が高い。上記構成によれば、こうした特性を利用して判定を行うことで、車室の内部と外部とを隔てている部品の異常を適切に判定できる。

車両診断システムにおいて、前記音源は、前記車両の存在を周囲に報知するための音を発するものであり、前記診断装置は、前記判定処理において、前記車両の走行中、前記音源が発する前記音に関する検出音データを、前記音に係る基準音データと比較して前記部品の異常の有無を判定してもよい。

上記構成のように、車両の存在を周囲に報知するための音を発する音源を利用すれば、診断のためだけに音源を車両に追加する必要はない。また、車両の走行中に上記音源が発する音は、ユーザが部品に何らかの異常を感じたか否かに拠らずに発せられるものである。したがって、ユーザが部品の異常を感じたか否かに拘わらず、部品の異常の有無を判定できる。

車両診断システムにおいて、前記診断装置は、前記車両に搭載されていてもよい。この構成では、車室の内部と外部とを隔てている部品の診断を車両で行うことができる。そのため、診断装置が車両以外の場所に設けられている場合に比べてシステムの構成を簡便にできる。

車両診断システムは、前記車両との間で無線通信可能な外部装置を備え、前記診断装置は、前記外部装置に設けられており、且つ複数の車種についての前記基準音データを前記車種毎に記憶しており、前記診断装置は、前記取得処理において、前記部品の異常を診断する対象となっている車両である診断対象車から前記検出音データと前記診断対象車の車種情報とを取得し、前記判定処理において、前記取得処理で取得した前記検出音データを、前記診断対象車の車種に対応する基準音データと比較してもよい。

上記構成によれば、診断装置を備えた外部装置を複数の車両で共有できるため、診断装置の管理を簡略化できる。また、診断対象の車種に応じた基準音データを用いて異常の有無の判定を行うため、高い異常判定精度を確保できる。

車両診断システムにおいて、前記部品は、前記車両のエンジンルーム又はモータルームと、前記車室とを隔てている部品であってもよい。上記構成によれば、エンジンルーム又はモータルームと、車室とを隔てている部品の異常の有無を判定できる。

車両の共用利用システムの概略構成図。 車両の概略構成図。 診断処理の処理手順を表したフローチャート。 管理サーバ及び車両の概略図。 診断支援処理及びサーバ用診断処理の処理手順を表したフローチャート。

＜第１実施形態＞
以下、車両診断システムの第１実施形態を、図面の図１～図３を参照して説明する。
以下では、車両がドライバの操作を要さずに自律して走行可能であり、且つ不特定多数のユーザが車両を共用して利用する共用利用システムにおける車両を診断対象とした場合を例として、車両診断システムを説明する。

＜共用利用システムの概略構成＞
図１に示すように、車両の共用利用システム１０は、管理サーバ２０、複数の車両３０、及びユーザ端末１４を有する。

ユーザ端末１４は、車両３０を利用するユーザが使う端末である。ユーザ端末１４は、例えばスマートフォンである。ユーザ端末１４は、外部通信回線網１２を介して管理サーバ２０と情報を送受信可能である。ユーザ端末１４は、ユーザからの入力操作に応じて、利用申請情報を管理サーバ２０に送信する。利用申請情報は、例えば、車両３０の利用開始位置、行き先、及び利用開始日時といった情報を含んでいる。利用開始位置は、ユーザが車両３０の配送を要求する地点である。利用開始日時は、ユーザが車両３０の配送を要求する日時である。

管理サーバ２０は、複数の車両３０を管理するサーバである。管理サーバ２０は、コンピュータプログラム（ソフトウェア）に従って各種処理を実行する１つ以上のプロセッサとして構成し得る。なお、管理サーバ２０は、各種処理のうち少なくとも一部の処理を実行する、特定用途向け集積回路（ＡＳＩＣ）等の１つ以上の専用のハードウェア回路、またはそれらの組み合わせを含む回路（ｃｉｒｃｕｉｔｒｙ）として構成してもよい。プロセッサは、ＣＰＵ及び、ＲＡＭ並びにＲＯＭ等のメモリを含む。メモリは、処理をＣＰＵに実行させるように構成されたプログラムコードまたは指令を格納している。メモリすなわちコンピュータ可読媒体は、汎用または専用のコンピュータでアクセスできるあらゆる利用可能な媒体を含む。管理サーバ２０は、電気的に書き換え可能な不揮発性メモリである記憶装置を有する。管理サーバ２０は、外部通信回線網１２を介して外部と接続するための通信機を有する。なお、管理サーバ２０は、車両３０の外部に設けられた処理装置である外部装置を構成する。

管理サーバ２０は、複数の車両３０を個別に識別できるように、車両３０毎の固定識別情報を記憶している。個体識別情報は、例えば車両３０の車種、車体製造番号、及び自動車登録番号標といった情報を含んでいる。管理サーバ２０は、外部通信回線網１２を介した無線通信によって様々な情報を各車両３０に送る。例えば、管理サーバ２０は、各車両３０に対して、各々が向かうべき目的地についての情報を送る。目的地は、ユーザが要求する利用開始位置であったり、車両基地であったりする。車両基地は、ユーザによる利用がないときに複数の車両３０を駐車させておく駐車場である。

＜車両の概略構成＞
複数の車両３０は、電気自動車である。複数の車両３０は、車種の違いはあるものの、それぞれの基本的な構成は同じである。以下では、各車両３０の基本的な構成を説明する。

図２に示すように、車両３０は、モータルーム３２、ダッシュパネル３５、及び車室３１を有する。モータルーム３２は、車両３０における前寄りの部分に区画された空間である。ダッシュパネル３５は、モータルーム３２の後ろの端を区画する壁部である。ダッシュパネル３５は板状になっている。車室３１は、ダッシュパネル３５を挟んでモータルーム３２とは反対側に区画された空間である。すなわち、ダッシュパネル３５は、モータルーム３２と車室３１とを隔てている。なお、図示は省略するが、ダッシュパネル３５は、板状のダッシュパネル本体と、ダッシュパネル本体に取り付けられた防音材とを含んで構成されている。ダッシュパネル本体と防音材とには、複数の取り付け具が貫通している。複数の取り付け具は、ダッシュパネル本体と防音材とを一体に固定している。

車両３０は、モータジェネレータ３７、バッテリ３８、及び駆動輪３９を有する。モータジェネレータ３７は、車両３０の駆動源である。モータジェネレータ３７は、電動機及び発電機の双方の機能を有する発電電動機である。モータジェネレータ３７は、インバータを介してバッテリ３８と電気的に接続されている。バッテリ３８は、モータジェネレータ３７に電力を供給したり、モータジェネレータ３７から供給される電力を蓄えたりする。インバータは、直流交流の電力変換を行う。なお、図２では、インバータの図示を省略している。

モータジェネレータ３７は、モータルーム３２の内部に位置している。モータジェネレータ３７の回転軸は、例えば、トルクコンバータ、変速機、クラッチ、及びディファレンシャルといった動力伝達機構を介して駆動輪３９に連結している。なお、図２では動力伝達機構の図示を省略している。

車両３０は、複数のシート４０及び複数の圧力センサ４１を有する。各シート４０は、乗員が着座するシートである。各シート４０は、車室３１の内部に位置している。各圧力センサ４１は、それぞれのシート４０に取り付けられている。各圧力センサ４１は、各シート４０の着座面にかかる圧力であるシート圧力Ｗを検出する。なお、図２では、複数のシート４０のうちの１つのみを示している。また、図２では、複数の圧力センサ４１のうちの１つのみを示している。

車両３０は、報知器３３、警音器３４、及びマイク３６を有する。報知器３３は、音圧及び周波数が予め定められている音を発する音源である。報知器３３は、車両３０の低速走行中に当該車両３０の存在を周囲に報知するための通報音を発する。報知器３３が発する通報音は、例えばモータの作動音を模擬した音であり、騒音にならないような比較的小さい音として設定されている。報知器３３は、モータルーム３２の内部に位置している。警音器３４は、音圧及び周波数が予め定められている音を発する音源である。警音器３４は、車両３０の走行中又は停車中に当該車両３０の存在を周囲に報知するための警笛を発する。警音器３４が発する警笛は、通報音よりも大きな音に設定されている。警音器３４は、モータルーム３２の内部に位置している。マイク３６は、予め定められた周波数帯域の音圧をデシベルに換算した音圧レベルＬを検出する。マイク３６は、車室３１の内部に位置している。なお、報知器３３が発する通報音は、所定の音圧レベルＬに設定されている。警音器３４が発する警笛は、通報音とは異なる所定の音圧レベルＬに設定されている。

車両３０は、ウインカー、ハザードランプ、ワイパー、エアコン、及びパワーウインドウを有する。ウインカーは、方向指示器である。ハザードランプは、非常時点滅灯を点灯させる装置である。ワイパーは、フロントガラス及びリアガラスに付着した雨滴、汚れ、及びごみを除去する装置である。エアコンは、空調装置である。パワーウインドウは、電動式の窓開閉装置である。なお、図２では、これらの各種装置を一まとめにして符号Ｍで示している。

車両３０は、車速センサ４２、ＧＰＳ受信機４３、カメラ４４、及びレーダー４５を有する。車速センサ４２は、車両３０の走行速度である車速ＳＰを検出する。ＧＰＳ受信機４３は、車両３０の現在位置座標Ｇに関する信号をＧＰＳ衛星から受信する。カメラ４４は、車両３０の周囲を撮像する。レーダー４５は、電波を発信するとともに、障害物Ｚで反射された電波を受信することで障害物Ｚを検出する。

＜車両の制御装置の概略構成＞
車両３０は、制御装置５０を有する。制御装置５０は、コンピュータプログラム（ソフトウェア）に従って各種処理を実行する１つ以上のプロセッサとして構成し得る。なお、制御装置５０は、各種処理のうち少なくとも一部の処理を実行する、特定用途向け集積回路（ＡＳＩＣ）等の１つ以上の専用のハードウェア回路、またはそれらの組み合わせを含む回路（ｃｉｒｃｕｉｔｒｙ）として構成してもよい。プロセッサは、ＣＰＵ及び、ＲＡＭ並びにＲＯＭ等のメモリを含む。メモリは、処理をＣＰＵに実行させるように構成されたプログラムコードまたは指令を格納している。メモリすなわちコンピュータ可読媒体は、汎用または専用のコンピュータでアクセスできるあらゆる利用可能な媒体を含む。制御装置５０は、電気的に書き換え可能な不揮発性メモリである記憶装置を有する。制御装置５０は、外部通信回線網１２を介して車両３０の外部と通信するための通信機を有する。なお、制御装置５０は、当該制御装置５０が搭載されている車両３０に関する個体識別情報を記憶している。個体識別情報の内容は、管理サーバ２０が記憶しているものと同じである。

制御装置５０は、オン状態とスタンバイ状態とに切り替わる。オン状態は、車両３０の各種部位を動作させるためのメインシステムが起動された状態である。制御装置５０でメインシステムが起動されると、例えばモータジェネレータ３７及び各種装置Ｍといった車両３０の各種部位に電力が供給される。一方、スタンバイ状態は、メインシステムがシャットダウンされた状態であり、メインシステムの起動指示を受け付けている状態である。スタンバイ状態では、車両３０の各種部位への電力供給は絶たれる。スタンバイ状態では、制御装置５０に対する外部からの電力供給も絶たれるが、制御装置５０は自身が内蔵している電池の電力によって動作可能である。制御装置５０は、管理サーバ２０からの指示に応じてスタンバイ状態とオン状態とに切り替わる。

制御装置５０は、車速センサ４２が検出する車速ＳＰを受信する。制御装置５０は、ＧＰＳ受信機４３が受信した現在位置座標Ｇに関する信号を受信する。制御装置５０は、カメラ４４が撮像した情報である撮像情報Ｊに関する信号を受信する。制御装置５０は、レーダー４５が検出した障害物Ｚに関する信号を受信する。制御装置５０は、圧力センサ４１が検出したシート圧力Ｗに関する信号を受信する。制御装置５０は、マイク３６が検出した音圧レベルＬに関する信号を受信する。

制御装置５０は、車両３０の各種部位を制御する統括制御部５２を有する。統括制御部５２は、メインシステムがオンになっている間、車両３０の自動運転を行うべく車両３０の各種部位を制御する。自動運転とは、ドライバの操作無しで車両３０を自律的に走行させることである。統括制御部５２は、例えばカメラ４４の撮像情報Ｊに基づいて、車線を維持したり前走車との車間距離を保ったりしながら車両３０を走行させる。また、統括制御部５２は、例えばレーダー４５が検出する障害物Ｚの情報に基づいて、障害物Ｚを回避しながら車両３０を走行させる。また、統括制御部５２は、目的地に向けて車両３０が進むべき走行経路を算出する。統括制御部５２は、車両３０の走行経路を算出する上で必要なデータとして地図データを記憶している。地図データは、例えば道路及び建造物といった情報を含んでいる。統括制御部５２は、ＧＰＳ受信機４３から受信した車両３０の現在位置座標Ｇと地図データとに基づいて目的地までの走行経路を算出し、走行経路に従って車両３０を走行させる。なお、目的地は、管理サーバ２０から送信される。目的地は、車室３１内の図示しないディスプレイを通じてユーザによって指示されてもよい。

統括制御部５２は、車両３０の走行中において車速ＳＰが規定車速未満である場合、報知器３３が通報音を発するように報知器３３を制御する。規定車速は、例えばタイヤによるロードノイズのような走行音が比較的小さくて歩行者に自車両の存在を報知する必要がある車速ＳＰとして予め定められている。規定車速は、例えば時速２０ｋｍである。統括制御部５２は、報知器３３から通報音を発しているか否かを示すフラグである通報音発信フラグを設定する。統括制御部５２は、報知器３３から通報音を発している場合、通報音発信フラグをオンにする。一方、統括制御部５２は、報知器３３から通報音を発していない場合、通報音発信フラグをオフにする。

統括制御部５２は、必要に応じてウインカー、ハザードランプ、ワイパー、エアコン、及びパワーウインドウを作動させる。例えば、統括制御部５２は、車両３０の走行中において右左折又は進路変更をする場合、ウインカーを作動させる。統括制御部５２は、ウインカーの作動状態を示すフラグである作動フラグを設定する。統括制御部５２は、ウインカーを作動させている場合、ウインカーの作動フラグをオンにする。一方、統括制御部５２は、ウインカーを作動させていない場合、ウインカーの作動フラグをオフにする。統括制御部５２は、ウインカー以外の他の装置Ｍについても、各装置Ｍの作動状態を示す作動フラグを装置Ｍ毎に設定する。なお、パワーウインドウに関する作動フラグは、単にオン・オフのみならず、窓が開閉動作中である状態と、窓が閉まっている状態と、窓が開いている状態と、の３つの状態を識別できるものになっている。

制御装置５０は、車両３０の各種部位の異常を診断する診断部５４を有する。診断部５４は、診断装置を構成する。診断部５４は、ダッシュパネル３５の異常を診断するための診断処理を実行可能である。診断部５４は、診断処理の一環として、取得処理及び判定処理を行う。診断部５４は、車両３０の走行中及び停車中のそれぞれにおいて、取得処理及び判定処理を行う。

診断部５４は、車両３０の走行中における取得処理では、報知器３３が通報音を発したときに、当該通報音を発したタイミングでマイク３６が検出する音圧レベルＬに関するデータである検出通報音データを取得する。診断部５４は、車両３０の走行中における判定処理では、検出通報音データを基準通報音データと比較することでダッシュパネル３５の異常の有無を判定する。具体的には、診断部５４は、検出通報音データと基準通報音データとで音圧レベルＬの差が通報音規定値以上である場合、ダッシュパネル３５に異常が生じていると判定する。診断部５４は、基準通報音データ及び通報音規定値を予め記憶している。基準通報音データ及び通報音規定値については後述する。

診断部５４は、停車中における取得処理では、警音器３４が警笛を発したときに、当該警笛を発したタイミングでマイク３６が検出する音圧レベルＬに関するデータである検出警笛データを取得する。診断部５４は、停車中における判定処理では、検出警笛データを基準警笛データと比較することでダッシュパネル３５の異常の有無を判定する。具体的には、診断部５４は、検出警笛データと基準警笛データとで音圧レベルＬの差が警笛規定値以上である場合、ダッシュパネル３５に異常が生じていると判定する。診断部５４は、基準警笛データ及び警笛規定値を予め記憶している。基準警笛データ及び警笛規定値については後述する。なお、診断部５４は、車両基地での停車中に取得処理及び判定処理を行う。車両基地は、警笛を鳴らしても近隣への騒音にならない領域であることが好ましい。

＜診断処理の詳細＞
診断部５４は、メインシステムが起動状態である間、診断処理を繰り返し実行する。なお、診断部５４は、診断処理で行う処理の一部で停車時実行フラグを利用する。停車時実行フラグは、停車中における判定処理の実行完了を示すフラグである。停車時実行フラグは、メインシステムがシャットダウンすると、オフにリセットされる。そのため、メインシステムが起動した時点では、停車時実行フラグはオフになっている。

診断部５４は、メインシステムが起動すると、診断処理を開始する。図３に示すように、診断部５４は、診断処理を開始すると、ステップＳ１１０の処理を実行する。ステップＳ１１０において、診断部５４は、診断前提条件が成立しているか否かを判定する。診断前提条件は、次の３つの項目を有する。
（イ）各種装置Ｍが作動していない。
（ロ）窓が閉まっている。
（ハ）乗員が乗車していない。

診断部５４は、各種装置Ｍの作動フラグに基づいて、項目（イ）及び（ロ）が満たされているか否かを判定する。また、診断部５４は、項目（ハ）が満たされているか否かを判定するにあたって、制御装置５０が圧力センサ４１から受信するシート圧力Ｗに関して最新の値を取得する。診断部５４は、取得したシート圧力Ｗを規定圧力と比較する。診断部５４は、規定圧力を予め記憶している。規定圧力は、乗員がシート４０に着座したときにシート４０にかかる圧力の最小値として例えば実験で定められている。診断部５４は、シート圧力Ｗが規定圧力以上の場合には乗員が乗車していると判定し、そうでない場合には乗員は乗車していないと判定する。診断部５４は、診断前提条件の３つの項目のうちの１つでも満たされていないものがある場合、診断前提条件は成立していないと判定する（ステップＳ１１０：ＮＯ）。この場合、診断部５４は、診断処理の一連の処理を一旦終了する。そして、診断部５４は、再度ステップＳ１１０の処理を実行する。

一方、診断部５４は、ステップＳ１１０において、上記の３つの項目の全てが満たされている場合、診断前提条件は成立していると判定する（ステップＳ１１０：ＹＥＳ）。この場合、診断部５４は、処理をステップＳ１２０に進める。

ステップＳ１２０において、診断部５４は、車両３０が走行中であるか否かを判定する。診断部５４は、ステップＳ１２０の処理を実行するにあたって、制御装置５０が車速センサ４２から受信する車速ＳＰに関して最新の値を取得する。そして、診断部５４は、車速ＳＰがゼロよりも大きいか否かを判定する。診断部５４は、車速ＳＰがゼロである場合、車両３０は停車中であると判定する（ステップＳ１２０：ＮＯ）。この場合、診断部５４は、処理をステップＳ２１０に進める。

ステップＳ２１０において、診断部５４は、車両３０が車両基地に位置しているか否かを判定する。診断部５４は、ステップＳ２１０の処理を実行するにあたって、制御装置５０がＧＰＳ受信機４３から受信する現在位置座標Ｇに関して最新の値を取得する。そして、診断部５４は、車両３０の現在位置座標Ｇが、地図データにおける車両基地の領域内であるか否かを判定する。診断部５４は、車両３０の現在位置座標Ｇが車両基地の領域から外れている場合、車両３０は車両基地に位置していないと判定する（ステップ２１０：ＮＯ）。この場合、診断部５４は、診断処理の一連の処理を一旦終了する。そして、診断部５４は、再度ステップＳ１１０の処理を実行する。

一方、ステップＳ２１０において、診断部５４は、車両３０の現在位置座標Ｇが車両基地の領域内である場合、車両３０は車両基地に位置していると判定する（ステップ２１０：ＹＥＳ）。この場合、診断部５４は、処理をステップＳ２２０に進める。

ステップＳ２２０において、診断部５４は、停車中の判定処理が未実行であるか否かを判定する。診断部５４は、停車時実行フラグに基づいてこの判定を行う。診断部５４は、停車時実行フラグがオンである場合、停車中の判定処理は実行済みであると判定する（ステップＳ２２０：ＮＯ）。この場合、診断処理の一連の処理を一旦終了する。そして、診断部５４は、再度ステップＳ１１０の処理を実行する。

一方、診断部５４は、ステップＳ２２０において、停車時実行フラグがオフである場合、停車中の判定処理は未実行であると判定する（ステップＳ２２０：ＹＥＳ）。この場合、診断部５４は、処理をステップＳ２３０に進める。

ステップＳ２３０において、診断部５４は、停車時実行フラグをオンに切り替える。上記のとおり、停車時実行フラグは、メインシステムがシャットダウンされるとオフにリセットされる。診断部５４は、停車時実行フラグをオンにすると、処理をステップＳ２４０に進める。

ステップＳ２４０において、診断部５４は、統括制御部５２に対して、警音器３４による警笛の発信を要求する信号である警笛要求信号の出力を開始する。そして、診断部５４は、処理をステップＳ２５０に進める。なお、統括制御部５２は、警笛要求信号を受信すると、警音器３４が警笛を発するように警音器３４を制御する。

ステップＳ２５０において、診断部５４は、検出警笛データを取得する。具体的には、診断部５４は、制御装置５０がマイク３６から受信する音圧レベルＬに関して最新の値を取得する。そして、診断部５４は、取得した音圧レベルＬを検出警笛データとして取り扱う。診断部５４は、検出警笛データを取得すると、処理をステップＳ２６０に進める。なお、ステップＳ２６０の処理は取得処理である。

ステップＳ２６０において、診断部５４は、警笛要求信号の出力を停止する。そして、診断部５４は、処理をステップＳ２７０に進める。なお、統括制御部５２は、警笛要求信号の出力が停止されると、警音器３４による警笛の発信を停止するように警音器３４を制御する。

ステップＳ２７０において、診断部５４は、検出警笛データを利用してダッシュパネル３５の異常の有無を判定する。診断部５４は、ダッシュパネル３５の異常の有無を判定するにあたって、先ず、検出警笛データから基準警笛データを減算して得られる警笛差分値を算出する。上記のとおり、診断部５４は、基準警笛データを予め記憶している。基準警笛データは、診断前提条件が満たされていることを前提に、ダッシュパネル３５に異常が生じていない状態において警音器３４が警笛を発したと仮定したときにマイク３６が検出する音圧レベルＬである。基準警笛データは、例えばつぎのようにして算出した値とすればよい。すなわち、診断対象となっている車両３０が新品状態であるときに、つぎのような実験を複数回繰り返す。実験の内容は、診断前提条件が満たされている状況下において、警音器３４によって警報を発するとともに、その時にマイク３６が検出する音圧レベルＬを取得する、というものである。このような実験を複数回切り返すことで得られる複数の音圧レベルＬの平均値を基準警笛データとする。

診断部５４は、警笛差分値を算出すると、警笛差分値と警笛規定値とを比較する。上記のとおり、診断部５４は、警笛規定値を予め記憶している。警笛規定値は、ダッシュパネル３５が正常である場合には生じ得ない音圧レベルＬの差が検出警笛データと基準警笛データとに存在していることがわかる値として、例えば実験で定められている。警笛規定値は、例えばマイク３６の検出誤差を考慮して定めればよい。

診断部５４は、警笛差分値が警笛規定値未満の場合、ダッシュパネル３５に異常は生じていないと判定する（ステップＳ２７０：ＮＯ）。この場合、診断部５４は、診断処理の一連の処理を一旦終了する。そして、診断部５４は、再度ステップＳ１１０の処理を実行する。

一方、ステップＳ２７０において、診断部５４は、警笛差分値が警笛規定値以上の場合、ダッシュパネル３５に異常が生じていると判定する（ステップＳ２７０：ＹＥＳ）。この場合、診断部５４は、処理をステップＳ３００に進める。なお、ステップＳ２７０の処理は判定処理である。

ステップＳ３００において、診断部５４は、ダッシュパネル３５に異常が生じている旨を示す情報と、自車両の個体識別情報とを含んだ異常情報を生成する。そして、診断部５４は、異常情報を管理サーバ２０に送信する。この後、診断部５４は、診断処理の一連の処理を一旦終了し、再度ステップＳ１１０の処理を実行する。なお、管理サーバ２０は、異常情報を受信すると、異常情報に含まれている個体識別情報に基づいて該当する車両３０を割り出し、該当する車両３０に関してダッシュパネル３５に異常が判定された旨を記憶する。管理サーバ２０が記憶した情報は、管理サーバ２０の管理者が読み出して車両３０の状態の把握に利用する。

さて、ステップＳ１２０において、診断部５４は、車速ＳＰがゼロよりも大きい場合、車両３０は走行中であると判定する（ステップＳ１２０：ＹＥＳ）。この場合、診断部５４は、処理をステップＳ１３０に進める。

ステップＳ１３０において、診断部５４は、報知器３３が通報音を発信中であるか否かを判定する。診断部５４は、通報音発信フラグに基づいてこの判定を行う。診断部５４は、通報音発信フラグがオフである場合、報知器３３は通報音を発信中でないと判定する（ステップＳ１３０：ＮＯ）。この場合、診断部５４は、診断処理の一連の処理を一旦終了する。そして、診断部５４は再度ステップＳ１１０の処理を行う。

一方、ステップＳ１３０において、診断部５４は、通報音発信フラグがオンである場合、報知器３３が通報音を発信中であると判定する（ステップＳ１３０：ＹＥＳ）。この場合、診断部５４は、処理をステップＳ１４０に進める。

ステップＳ１４０において、診断部５４は、検出通報音データを取得する。具体的には、診断部５４は、制御装置５０がマイク３６から受信する音圧レベルＬに関して最新の値を取得する。そして、診断部５４は、取得した音圧レベルＬを検出通報音データとして取り扱う。診断部５４は、検出通報音データを取得すると、処理をステップＳ１５０に進める。なお、ステップＳ１４０の処理は取得処理である。

ステップＳ１５０において、診断部５４は、検出通報音データを利用して、ダッシュパネル３５の異常の有無を判定する。診断部５４は、ダッシュパネル３５の異常の有無を判定するにあたって、先ず、検出通報音データから基準通報音データを減算して得られる通報音差分値を算出する。上記のとおり、診断部５４は、基準通報音データを予め記憶している。基準通報音データは、診断前提条件が満たされていることを前提に、ダッシュパネル３５に異常が生じていない状態において報知器３３が通報音を発したと仮定したときにマイク３６が検出する音圧レベルＬである。基準通報音データは、基準警報データと同様の手法を通報音に適用して算出した値とすればよい。

診断部５４は、通報音差分値を算出すると、通報音差分値と通報音規定値とを比較する。上記のとおり、診断部５４は、通報音規定値を予め記憶している。通報音規定値は、警笛規定値と同様の観点で定められている。

診断部５４は、通報音差分値が通報音規定値未満の場合、ダッシュパネル３５に異常は生じていないと判定する（ステップＳ１５０：ＮＯ）。この場合、診断部５４は、診断処理の一連の処理を一旦終了する。そして、診断部５４は、再度ステップＳ１１０の処理を実行する。

一方、ステップＳ１５０において、診断部５４は、通報音差分値が通報音規定値以上の場合、ダッシュパネル３５に異常が生じていると判定する（ステップＳ１５０：ＹＥＳ）。この場合、診断部５４は、処理をステップＳ３００に進める。ステップＳ３００の処理の内容は既に説明したとおりである。なお、ステップＳ１５０の処理は判定処理である。

＜第１実施形態の作用＞
ダッシュパネル３５の防音材が劣化してひび割れが生じることがある。この場合、モータルーム３２の内部で報知器３３又は警音器３４が発する音が車室３１の内部に至り易くなる。また、ダッシュパネル本体と防音材とを一体にしている取り付け具が抜け外れてしまうことがある。この場合、ダッシュパネル本体及び防音材においては、取り付け具を取り付けていた貫通孔が解放される。この貫通孔を通じて、モータルーム３２の内部で報知器３３又は警音器３４が発する音が車室３１の内部に至り易くなる。こうした因果関係があることから、モータルーム３２の内部で報知器３３又は警音器３４が音を発したときに車室３１の内部のマイク３６が検出する音圧レベルＬを分析することで、ダッシュパネル３５の異常を診断することが可能である。

モータルーム３２の内部で報知器３３又は警音器３４が発する音を利用してダッシュパネル３５の異常を診断するにあたって、これら報知器３３又は警音器３４が音を発したときにマイク３６が通報音又は警笛とは別の音を含んだ音圧レベルＬを検出してしまうと、診断の精度が低下する。マイク３６が検出し得る上記別の音としては、各種装置Ｍが作動しているときの作動音、窓が開いている場合における車室３１の外部の音、乗員が乗車している場合における乗員の声といったものが挙げられる。そこで、診断処理では、検出通報音データ又は検出警笛データを取得するにあたって、診断前提条件を設けている。

そして、診断部５４は、診断処理では、診断前提条件が成立していることを条件に、車両３０の走行中に報知器３３が通報音を発したときに検出通報音データを取得する。また、診断部５４は、診断前提条件が成立していることを条件に、車両３０が車両基地に停車している状態で警音器３４から警笛を発したときに検出警笛データを取得する。そして、診断部５４は、これら検出通報音データ及び検出警笛データを利用してダッシュパネル３５の異常の有無を判定する。

＜第１実施形態の効果＞
（１－１）ダッシュパネル３５は、その配置上、乗員が外観を見難い位置に配置されていることに加え、動作したり音を発したりする部品ではないので、例えば防音材が劣化するといった異常が生じたとしても、ユーザはその異常に気付き難い。その上、共用利用システム１０では、ユーザは毎回違う車両３０を利用する可能性が高い。そのため、ユーザが特定の車両３０についてのダッシュパネル３５の異常に気付くことは、なお一層難しい。

本実施形態において、診断部５４は、報知器３３又は警音器３４が音を発したときに、当該音を発したタイミングでマイク３６が検出する音圧レベルＬを検出通報音データ又は検出警笛データとして取得する。そのため、ユーザがダッシュパネル３５の異常を感じた場合ではなくても、診断部５４はダッシュパネル３５の診断に必要なデータを取得できる。そして、診断部５４は、これらのデータを取得すると、それらを利用してダッシュパネル３５の異常の有無を判定する。したがって、診断部５４は、ユーザがダッシュパネル３５の異常を感じたか否かに拘わらず、ダッシュパネル３５の異常を診断できる。

（１－２）上記作用に記載したとおり、ダッシュパネル３５に異常が生じていると、モータルーム３２の内部で報知器３３又は警音器３４が発した音が車室３１の内部に至り易くなる。この場合、マイク３６が検出する音圧レベルＬが高くなる可能性が高い。したがって、本実施形態のように、検出通報音データが基準通報音データに比べて高いか否か、又は検出警笛データが基準警笛データに比べて高いか否かを判定することで、ダッシュパネル３５の異常の有無を適切に判定することができる。

（１－３）上記作用に記載したとおり、本実施形態では、診断前提条件が成立している状況下でのみ検出通報音データまたは検出警笛データを取得する。したがって、ダッシュパネル３５の異常の診断において必要となる音以外を排除したデータ取得できる。こうしたデータを利用することで、高い診断精度を担保できる。

（１－４）本実施形態では、報知器３３が発する通報音をダッシュパネル３５の異常の診断に利用する。報知器３３は、電気自動車に一般的に搭載される既存の装置である。こうした既存の装置が発する音を利用すれば、診断のためだけに音源を車両３０に追加する必要はない。また、報知器３３の通報音は、ユーザが何らかの異常を感じたか否かに拠らずに発せられるものである。したがって、ユーザが何らかの操作を行わなくても、検出通報音データを取得してダッシュパネル３５の異常を診断できる。

（１－５）本実施形態では、警音器３４が発する警笛をダッシュパネル３５の異常の診断に利用する。警音器３４は、自動車に一般的に搭載される既存の装置である。こうした既存の装置が発する音を利用すれば、診断のためだけに音源を車両３０に追加する必要はない。ここで、車両３０の走行中に警笛を鳴らす機会は限られる。そこで、本実施形態では、車両基地という、特定の場所で警笛を発して検出警笛データを取得するようにしている。このことにより、不用意に警笛を発することなくダッシュパネル３５の診断機会を増やすことができる。また、警音器３４が警笛を発する際、ユーザの操作ではなく、診断部５４の制御によって警笛を発するため、ユーザが何らかの操作を行わなくても、検出警笛データを取得してダッシュパネル３５の異常を診断できる。

（１－６）本実施形態では、取得処理及び判定処理を車両３０の制御装置５０で行う。そのため、ダッシュパネル３５の診断専用の処理装置を別途設ける必要がない。また、そうした処理装置と車両３０とで診断に必要な情報を送受信する必要もない。したがって、そうした情報の送受信に応じた処理の負担も生じない。

＜第２実施形態＞
以下、車両診断システムの第２実施形態を、図４及び図５を参照して説明する。第２実施形態では、管理サーバ２０及び車両３０の制御装置５０の構成のみが第１実施形態とは異なる。以下では、これら第１実施形態とは異なる部分を主として説明し、第１実施形態と重複した内容については説明を簡略、又は割愛する。なお、図４では、図１で説明した共用利用システム１０のうち、管理サーバ２０と１つの車両３０のみを示している。また、図４では、車両３０に関して、図２で示した部材のうちの一部のみを示し、他の部材については図示を省略している。

図４に示すように、管理サーバ２０は、ダッシュパネル３５の異常を診断するためのサーバ診断部２２を有する。サーバ診断部２２は、診断装置を構成する。サーバ診断部２２は、ダッシュパネル３５の異常を診断するためのサーバ用診断処理を実行可能である。サーバ診断部２２は、取得処理及び判定処理を行う。サーバ診断部２２は、取得処理において、ダッシュパネル３５の診断の対象となっている車両３０である診断対象車から、検出音データを取得する。また、サーバ診断部２２は、取得処理において、診断対象車から、当該診断対象車の車種情報を取得する。サーバ診断部２２は、判定処理において、上記実施形態と同様、検出音データを基準音データと比較することでダッシュパネル３５の異常の有無を判定する。なお、サーバ診断部２２は、車種毎の基準通報音データを記憶している。各基準通報音データは、上記第１実施形態で説明した手法で車種毎に算出されたものである。また、サーバ診断部２２は、車種毎の通報音規定値を記憶している。通報音規定値は、例えば車種毎のマイク３６の種類を考慮しつつ上記実施形態と同様の観点で定めたものである。

車両３０の制御装置５０は、第１実施形態で説明した診断部に代えて、診断支援部５６を有する。診断支援部５６は、ダッシュパネル３５の異常の診断に必要な情報を管理サーバ２０に送信するための診断支援処理を実行可能である。診断支援部５６は、メインシステムが起動すると、診断支援処理を開始する。

図５に示すように、診断支援部５６は、診断支援処理を開始すると、ステップＳ５１０の処理を実行する。ステップＳ５１０において、診断支援部５６は、診断前提条件が成立しているか否かを判定する。ステップＳ５１０の処理の内容は、第１実施形態のステップＳ１１０の処理の内容と同じである。そのため、ステップＳ５１０の処理の内容の説明は割愛する。診断支援部５６は、診断前提条件が成立していない場合、再度ステップＳ５１０の処理を実行する（ステップＳ５１０：ＮＯ）。診断支援部５６は、診断前提条件が成立するまでステップＳ５１０の処理を繰り返す。そして、診断支援部５６は、診断前提条件が成立すると、処理をステップＳ５２０に進める（ステップＳ５１０：ＹＥＳ）。

ステップＳ５２０において、診断支援部５６は、報知器３３が通報音を発信中であるか否かを判定する。ステップＳ５２０の処理の内容は、第１実施形態のステップＳ１３０の処理の内容と同じである。そのため、ステップＳ５１０の処理の内容の説明は割愛する。診断支援部５６は、報知器３３が通報音を発信していない場合、ステップＳ５１０の処理に戻る（ステップＳ５２０：ＮＯ）。診断支援部５６は、診断前提条件が成立している状況下で報知器３３が通報音を発するまで、ステップＳ５１０及びステップＳ５２０の処理を繰り返す。そして、診断支援部５６は、診断前提条件が成立している状況下で報知器３３が通報音を発すると、処理をステップＳ５３０に進める（ステップＳ５２０：ＹＥＳ）。

ステップＳ５３０において、診断支援部５６は、制御装置５０がマイク３６から受信する音圧レベルＬに関して最新の値を取得する。そして、診断支援部５６は、取得した音圧レベルＬと、自車両の個体識別情報とを含む診断用情報を生成する。そして、診断支援部５６は、診断用情報を管理サーバ２０に送信する。診断支援部５６は、ステップＳ５３０の処理を実行すると、診断支援処理の一連の処理を終了する。なお、ステップＳ５１０及びステップＳ５２０の判定次第では、診断支援処理の一連の処理が終了する前にメインシステムがシャットダウンされてしまうこともある。

管理サーバ２０のサーバ診断部２２は、診断支援部５６が送信した診断用情報を受信すると、サーバ用診断処理を開始する。サーバ診断部２２は、サーバ用診断処理を開始すると、ステップＳ６１０の処理を行う。ステップＳ６１０において、サーバ診断部２２は、検出通報音データ及び車種情報を取得する。具体的には、サーバ診断部２２は、受信した診断用情報から音圧レベルＬを読み出す。サーバ診断部２２は、読み出した値を検出通報音データとして取り扱う。また、サーバ診断部２２は、受信した診断用情報から診断対象車の車種を読み取る。サーバ診断部２２は、以上の処理を実行すると、ステップＳ６２０に進める。なお、ステップＳ６１０の処理は取得処理である。

ステップＳ６２０において、サーバ診断部２２は、ダッシュパネル３５に異常が生じているか否かを判定する。サーバ診断部２２は、ダッシュパネル３５の異常の有無を判定するにあたって、先ず、車種毎の基準通報音データの中から、診断対象車の車種に対応する基準通報音データを選択する。そして、サーバ診断部２２は、選択した基準通報音データをステップＳ６１０で取得した検出通報音データから減算して得られる通報音差分値を算出する。

サーバ診断部２２は、通報音差分値を算出すると、通報音差分値と通報音規定値とを比較する。サーバ診断部２２は、この比較を行うにあたって、先ず、車種毎の通報音規定値の中から、診断対象車の車種に対応する通報音規定値を選択する。そして、サーバ診断部２２は、選択した通報音差分値と通報音規定値とを比較する。サーバ診断部２２は、通報音差分値が通報音規定値未満の場合、ダッシュパネル３５に異常は生じていないと判定する（ステップＳ６３０：ＮＯ）。この場合、サーバ診断部２２は、サーバ用診断処理の一連の処理を終了する。

一方、ステップＳ６３０において、サーバ診断部２２は、通報音差分値が通報音規定値以上の場合、ダッシュパネル３５に異常が生じていると判定する（ステップＳ６３０：ＹＥＳ）。この場合、サーバ診断部２２は、処理をステップＳ６３０に進める。なお、ステップＳ６２０の処理は判定処理である。

ステップＳ６３０において、サーバ診断部２２は、診断対象車のダッシュパネル３５に関して異常が判定された旨を記憶する。この後、サーバ診断部２２は、サーバ用診断処理の一連の処理を終了する。なお、ダッシュパネル３５に関する異常の情報は、管理サーバ２０の管理者が読み出して車両３０の状態の把握に利用する。

＜第２実施形態の作用＞
車両３０の診断支援部５６は、診断前提条件が成立していることを条件に、車両３０の走行中に報知器３３が通報音を発したときに診断用情報を管理サーバ２０に送信する。管理サーバ２０のサーバ診断部２２は、診断用処理情報を受信すると、検出通報音データを取得してダッシュパネル３５の異常の有無を判定する。

＜第２実施形態の効果＞
本実施形態によれば、上記（１－１）～（１－４）と同様の効果に加え、次の（２－１）の効果を得ることができる。

（２－１）本実施形態では、複数の車両３０の診断を１つの診断装置で行っている。こうした構成を採用するにあたって、車種毎の基準通報音データ及び通報音規定値を利用することで、高い判定精度を確保している。ここで、例えば車種毎の通報音規定値をアップデートする必要が生じることがあり得る。第１実施形態のように各車両３０の制御装置５０に診断装置を設ける構成において上記のアップデートを行う場合、各車両３０の制御装置５０のそれぞれについて車種を確かめつつ通報音基準値をアップデートしていかねばならず、手間がかかる。この点、本実施形態のように、１つの診断装置を複数の車両３０で共用する構成とすれば、当該１つの診断装置である管理サーバ２０に対してのみ、情報を変更する処理を行えばよく、且つ、その際、車種の数の分のみ通報音規定値を変更すればよい。したがって、アップデータの処理は非常に簡便になる。このように、本実施形態では、診断装置の管理を簡略化できる。

＜変更例＞
第１実施形態及び第２実施形態は、以下のように変更して実施することができる。第１実施形態、第２実施形態、及び以下の変更例は、技術的に矛盾しない範囲で互いに組み合わせて実施することができる。

・第１実施形態に関して、通報音と警笛とのいずれか一方のみを利用してダッシュパネル３５の異常の診断を行ってもよい。また、第２実施形態に関して、通報音に代えて、又は加えて、警笛を利用してダッシュパネル３５の異常を診断してもよい。第２実施形態に関して警笛を利用してダッシュパネル３５の異常を診断する場合、第１実施形態と同様にして車両基地に車両３０が駐車したときに警笛を発すればよい。そして、警笛を発した時にマイク３６が検出した音圧レベルＬを診断用情報として管理サーバ２０に送ればよい。

・警笛を発する領域は、車両基地に限定されない。警笛を発する領域は、例えば、警笛鳴らせの標識がある地点でもよい。なお、警笛を発する領域は近隣への騒音を考慮して定めることが好ましい。

・車両３０の走行中に警笛を発してダッシュパネル３５の診断を行ってもよい。
・診断実行条件の内容は、第１実施形態及び第２実施形態に示したものに限定されない。ダッシュパネル３５の異常を診断する上で適切なデータを得ることができるのであれば、診断前提条件の項目の内容及び数は問わない。

・第１実施形態及び第２実施形態における診断前提条件の内容は、検出対象の音以外の音を排除することを意図したものだった。しかし、ある特定の音が存在するという項目を診断実行条件に含めてもよい。例えば、乗員が乗車している、という項目を含めてもよい。また、例えば、ある特定の装置Ｍの作動音が存在している、という項目を含めてもよい。これらの項目を含む診断前提条件を採用する場合でも、当該診断前提条件が成立した状況下であることを前提に基準通報音データ及び基準警笛データを定めておけば、適切な診断を行うことができる。

・基準通報音データは、第１実施形態及び第２実施形態に示したものに限定されない。基準通報音データは、判定処理での判定を適切に行うことができるものでればよい。ダッシュパネル３５に異常が生じているときの音を基準通報音データとして採用してもよい。そして、例えば検出音データと基準通報音データとが同程度であるときにダッシュパネル３５に異常が生じていると判定してもよい。また、この後の変更例で説明する通り、判定処理で利用する判定の手法によっては、第１実施形態のように音圧レベルＬを統計処理することによって基準音データを算出するのではなく、音圧レベルＬの瞬時値を基準通報音データとして取り扱ってもよい。基準警笛データについても同様である。

・判定処理で利用する判定の手法、及び取得処理における検出音データの取得の態様は、第１実施形態及び第２実施形態に示したものに限定されない。判定処理で利用する判定の手法は、ダッシュパネル３５の異常の有無を適切に判定できるものであればよい。そして、取得処理では、判定処理で必要となるデータを取得できればよい。例えば、判定処理では、報知器３３が通報音を発し終えてからの音圧レベルＬの減衰速度を指標として判定を行ってもよい。この場合、取得処理では、報知器３３が通報音を発し終えたタイミングから、予め定められた規定期間が経過するまで、マイク３６が検出する音圧レベルＬを検出通報音データとして連続して取得する。すなわち、検出通報音データの時系列を取得する。なお、この時系列は、診断前提条件が成立し続けている状況下で取得するものとする。判定処理では、上記時系列を利用して検出通報音データに関する減衰速度である検出減衰速度を算出する。例えば、上記時系列の最初の値から最後の値を減算して得られる値を規定期間で除すことで検出減衰速度を算出する。そして、算出した検出減衰速度を基準減衰速度と比較し、前者が後者に比べて規定速度以上小さい場合に、ダッシュパネル３５に異常が生じていると判定する。すなわち、基準減衰速度から検出減衰速度を減算して得られる値が、規定速度以上である場合に、ダッシュパネル３５に異常が生じていると判定する。

基準減衰速度は、ダッシュパネル３５に異常が生じていない状態において報知器３３が通報音を発したと仮定したときに、報知器３３が通報音を発し終えてからの音圧レベルＬの減衰速度である。基準減衰速度は、例えばつぎのようにして予め算出しておく。先ず、診断対象とする車両３０が新品状態であるときに、報知器３３が通報音を発し終えてから規定期間が経過するまで、マイク３６が検出する音圧レベルＬを基準通報音データとして連続して取得する。すなわち、基準通報音データの時系列を取得する。検出通報音データを取得する場合と同様、基準通報音データの時系列は、診断前提条件が成立し続けている状況下で取得する。基準通報音データの時系列を取得したら、その時系列に基づいて音圧レベルＬの減衰速度を算出する。こうした算出手法を利用して、複数の時系列に関して減衰速度を算出し、複数個の減衰速度の平均値を基準減衰速度とする。なお、判定処理で利用する規定速度は、ダッシュパネル３５が正常である場合には生じ得ない減衰速度の差が検出減衰速度と基準減衰速度とに存在していることがわかる値として定めればよい。また、規定期間は、音圧レベルＬの減衰速度を算出するのに適した長さとして定めればよい。

ダッシュパネル３５において防音材が劣化したり取り付け具が外れたりした場合、報知器３３が発する通報音が車室３１の内部で減衰し難くなることがある。この場合、マイク３６で検出する音圧レベルＬの減衰速度は遅くなる可能性が高い。上記の判定手法では、こうした特性を利用してダッシュパネル３５の異常を判定することで、異常の有無を適切に判定できる。

・判定処理では、報知器３３が通報音を発している期間における音圧レベルＬの時系列を周波数解析して得られるパワースペクトルを利用してもよい。パワースペクトルは、音圧レベルＬのエネルギーを単位周波数毎に表したグラフである。パワースペクトルを利用して判定を行う場合、取得処理では、報知器３３が通報音を発しているある一定期間に関して、マイク３６で検出した音圧レベルＬを検出通報音データとして連続して取得する。すなわち、検出通報音データの時系列を取得する。判定処理では、この時系列に基づくパワースペクトルである検出パワースペクトルを、基準パワースペクトルと比較する。そして、ある特定の周波数において、検出パワースペクトルにおける音圧レベルＬのエネルギーが、基準パワースペクトルにおける音圧レベルＬのエネルギーに比べて、規定エネルギー以上大きい場合に、ダッシュパネル３５に異常が生じていると判定する。

基準パワースペクトルは、ダッシュパネル３５に異常が生じていない状態においてある一定期間に亘って報知器３３が通報音を発したと仮定したときにマイク３６が検出する音圧レベルＬの時系列に関するパワースペクトルである。基準パワースペクトルは、上記の減衰速度の変更例と同様、例えば診断対象とする車両３０が新品状態であるときの音圧レベルＬを基準通報音データとして取得して算出ればよい。また、規定エネルギーは、ダッシュパネル３５が正常である場合には生じ得ないエネルギーの差が検出パワースペクトルと基準パワースペクトルとに存在していることがわかる値として定めればよい。

パワースペクトルを用いて判定を行う場合、複数の音源が発する音を、周波数によって切り分けることができる。そのため、検出対象としている音以外の音の影響を排除して異常の有無を判定するのに好適である。また、パワースペクトルを用いる場合、音源を切り分けることができるため、取得処理で検出音データを取得する際に必ずしも診断前提条件を要さない。このことは、ダッシュパネル３５の診断機会を増やす上で好適である。

・上記変更例に記載したとおり、診断前提条件を設定することは必須ではない。
・車両３０は、自動運転のみを行うものに限定されない。すなわち、車両３０は、自動運転とドライバの操作による運転とを切り替えることができるように構成されていてもよいし、ドライバの操作による運転のみが可能に構成されていてもよい。

・ドライバの操作による運転が可能な車両３０の場合、ドライバの操作に伴って警音器３４から警笛を発したときにダッシュパネル３５の異常の診断を行ってもよい。
・車両３０の構成部品は、上記実施形態に示したものに限定されない。例えば、車両３０は、モータルーム３２の内部に、モータジェネレータ３７に加えて内燃機関を該車両３０の駆動源として有していてもよい。車両３０が内燃機関を有する場合、モータルーム３２はエンジンルームと呼称されてもよい。

・ダッシュパネル３５の診断に利用する音源は、報知器３３又は警音器３４に限定されない。ダッシュパネル３５を挟んで車室３１とは反対側に位置している音源を利用すれば、ダッシュパネル３５の異常の診断を適切に行うことができる。例えば、上記変更例のように、車両３０が内燃機関を有するのであれば、内燃機関を音源として利用してもよい。そして、内燃機関の作動音を利用したダッシュパネル３５の異常の診断を行ってもよい。

・ダッシュパネル３５の診断に利用する音源が発する音は、音圧及び周波数のうちの少なくとも一方が予め定められていればよい。音源が発する音に関して、定められている音の要素に応じて適切な診断手法を採用すればよい。例えば、音源が発する音の音圧が定められている場合、上記実施形態と同様、音圧の大小を利用した診断手法を採用すれば、ダッシュパネル３５の異常を適切に診断できる。また、例えば、音源が発する音の周波数が定められている場合、上記変更例に記載したように音圧の減衰速度を利用した診断手法を採用すれば、ダッシュパネル３５の異常を適切に診断できる。

・ダッシュパネル３５の診断に利用する音源として、報知器３３及び警音器３４とは別の音源を設ける場合、その音源が発する音の周波数は、可聴域の周波数に限られない。この場合の音源は、音を他者に知覚させることを目的としていないので、可聴域外の周波数の音でも、診断に差支えはない。

・診断対象とする車両は、共用利用システム１０のものに限定されない。例えば、自家用車を診断対象としてもよい。
・診断対象とする部品は、ダッシュパネル３５に限定されない。診断対象とする部品は、車室３１の内部と外部とを隔てているものであればよい。音源が、診断対象となる部品を挟んで車室３１とは反対側に位置していれば、ダッシュパネル３５を診断した場合と同様にして適切に診断を行うことができる。診断対象とする部品は、例えば車両のドアでもよい。また、診断対象とする部品は、例えば車両のルーフでもよい。例えば広報車のように車両のルーフにスピーカを取り付けている車両であれば、当該スピーカを音源として利用できる。そして、スピーカが発する音を利用してルーフを含む周辺部品の異常を診断できる。

・外部装置は、共用利用システム１０の管理サーバ２０に限定されない。外部装置は、例えば、車両整備工場で利用されている処理装置でもよい。
・マイク３６で検出する物理量は、音圧レベルＬに限定されない。マイク３６で検出する物理量は、音圧そのものでもよい。マイク３６で検出する物理量に合わせて、取得処理で検出音データとして取り扱う物理量を変更すればよいし、それに合わせて例えば基準通報音データ及び通報音規定値といった、診断に利用するデータの物理量を変更すればよい。

１０…共用利用システム
３０…車両
３１…車室
３２…モータルーム
３３…報知器
３４…警音器
３５…ダッシュパネル
３６…マイク
５０…制御装置
５４…診断部

Claims (6)

1. 車両における車室の内部と外部とを隔てている部品の異常を診断する診断装置と、
   前記車室の外部に位置し、音圧及び周波数のうちの少なくとも一方が予め定められているとともに前記車両の存在を周囲に報知するための音を発する音源と、
   前記車室の内部に位置するマイクと
   を有し、
   前記診断装置は、
   前記音源が前記音を発したときに、前記マイクが検出する前記音に関する検出音データを取得する取得処理と、
   前記車両の走行中、前記音源が発する前記音に関する前記検出音データを、前記音に係る予め定められた基準音データと比較して前記部品の異常の有無を判定する判定処理と
   を実行する
   車両診断システム。
2. 前記音源が発する前記音は、音圧が予め定められており、
   前記診断装置は、前記判定処理において、前記検出音データにおける音圧と前記基準音データにおける音圧との差に基づいて、前記部品の異常の有無を判定する
   請求項１に記載の車両診断システム。
3. 前記音源が発する前記音は、周波数が予め定められており、
   前記音源が前記音を発し終えてからの音圧の減衰速度を音圧減衰速度としたとき、
   前記診断装置は、前記判定処理において、前記検出音データにおける音圧減衰速度と前記基準音データにおける音圧減衰速度との差に基づいて、前記部品の異常の有無を判定する
   請求項１に記載の車両診断システム。
4. 前記診断装置は、前記車両に搭載されている
   請求項１～３のいずれか一項に記載の車両診断システム。
5. 車両との間で無線通信可能な外部装置と、
   前記外部装置に設けられており、前記車両における車室の内部と外部とを隔てている部品の異常を診断する診断装置と、
   前記車室の外部に位置し、音圧及び周波数のうちの少なくとも一方が予め定められている音を発する音源と、
   前記車室の内部に位置するマイクと
   を有し、
   前記診断装置は、
   複数の車種についての予め定められた基準音データを前記車種毎に記憶しており、
   前記部品の異常を診断する対象となっている車両である診断対象車から、前記音源が音を発したときに前記マイクが検出する音に関する検出音データ、及び前記診断対象車の車種情報を取得する取得処理と、
   前記取得処理で取得した前記検出音データを、前記診断対象車の車種に対応する基準音データと比較して前記部品の異常の有無を判定する判定処理と
   を実行する
   車両診断システム。
6. 車両のエンジンルーム又はモータルームと車室とを隔てている部品の異常を診断する診断装置と、
   前記車両における前記車室の外部に位置し、音圧及び周波数のうちの少なくとも一方が予め定められている音を発する音源と、
   前記車室の内部に位置するマイクと
   を有し、
   前記診断装置は、
   前記音源が音を発したときに、前記マイクが検出する音に関する検出音データを取得する取得処理と、
   前記検出音データを予め定められた基準音データと比較して前記部品の異常の有無を判定する判定処理と
   を実行する
   車両診断システム。