JP2007248070A - 車両走行試験装置 - Google Patents

Abstract

【課題】車両走行試験中に不具合が発生した場合、試験を中断するか続行するかを即座に判断することのできる車両走行試験装置を提供する。
【解決手段】データ収集蓄積部１０１が車内ＬＡＮ５１を流れている信号をデータとして収集し、収集したデータからあらかじめ決められた基準により重大な不具合を１次判定する不具合判定部１０２を備える車載端末１０と、不具合事例を記憶したデータベース２０１を参照して車載端末１０から取得したデータを解析し、不具合程度を２次判定する不具合解析部２０２を有する解析サーバ２０からなり、不具合の程度に応じて車両の走行試験を継続するか否かを判断する。
【選択図】図１

Description

本発明は、車両走行試験装置に関する。

車両の走行試験は、車両の開発において重要な試験である。従来、走行試験において、車両内に搭載されている制御装置（ＥＣＵと称されている）から出力される制御信号を記録しておき、後から車両の動作を仮想的に作り出すシミュレータで記録した信号により車両の動きを仮想的に再現することで、実際の車両走行時の挙動、特に不具合発生時の車両の挙動と制御信号の関係を解析する技術がある（特許文献１参照）
特開２００４−１９５０８号公報

しかしながら、従来の車両走行試験では、実車走行によって集めたデータは、後からシミュレーションによって解析を実行するため、走行試験中に不具合が発生した場合、その後、試験走行を続行してよいかどうかその場では判断できない。このため、不具合発生時には、走行試験をやめてデータを持ち帰り、シミュレーションによる解析が終了するまで、走行試験を中止しなければならない。

このため、実車走行試験に際して待ち時間が発生して、試験時間（試験期間）が長くなってしまうという問題があった。

そこで本発明の目的は、車両の走行試験中に不具合が発生した場合でも、試験を中断するか、継続するかを即座に判断することのできる車両走行試験装置を提供することである。

上記目的を達成するための本発明は、車両で使用されている信号をデータとして収集するデータ収集手段と、前記データ収集手段が収集したデータとあらかじめ記憶されている判定基準に基づいて、走行試験を継続するか否かを判定する判定手段と、を有することを特徴とする車両走行試験装置である。

本発明によれば、不具合発生時のデータを収集し、あらかじめ記憶されている判定基準に基づいて、不具合発生時に、それ以後の走行試験を継続するか否かを判定することとしたので、走行試験の現場で即座に、今後走行試験を継続するか否かを判定することが可能となる。

以下、図面を参照して本発明の実施の形態を説明する。

図１は、本発明を適用した車両走行試験装置の構成を説明するブロック図である。

この車両走行試験装置は、車両５０に搭載されている車載端末１０と、車両５０外に設けられている解析サーバ２０からなる。

車載端末１０は車内ＬＡＮ５１に接続されている。そして車載端末１０は車内ＬＡＮ５１を通してさまざまな信号を収集し、不具合の１次判定を行うとともに、収集した信号をデータとして解析サーバ２０へ送信する。一方解析サーバは、車載端末１０から送られてきたデータを解析して不具合の２次判定を行うとともに、外部から電子制御装置のプログラムの書き換えを実行する。

なお、車両５０内にはエンジン、およびそのほかのさまざまな電装品（たとえばエアコン、ライト、カーオーディオ、ブレーキブースターなど）などを制御するために、複数の電子制御装置（以下ＥＣＵ５２と称する）が設けられている。複数のＥＣＵ５２は車内ＬＡＮ５１によって相互に接続されているとともに、各制御対象および車内の各種センサと車内ＬＡＮ５１によって接続されている。

以下各部の主要な機能について詳細に説明する。

まずは、車載端末１０は、車内ＬＡＮ５１を流れている信号をデータとして収集、蓄積するデータ収集蓄積部１０１（データ収集手段）と、蓄積したデータから車両５０の不具合の程度を１次判定する不具合判定部１０２（第１判定手段）と、解析サーバ２０とデータの送受信を行う送信処理部１０３および受信処理部１０４と、解析サーバ２０からの指令によりデータを取り出すデータ取得命令部１０５と、ＥＣＵ５２のプログラム更新を行うプログラム更新命令部１０６（プログラム更新手段）と、ＥＣＵ５２とデータの送受信を行うＥＣＵアクセス部１０７と、無線により解析サーバ２０とデータの送受信を行うデータ送受信機１０８と、を有する。また、車載端末１０には、ユーザから各種入力が行われる入力装置１０９と、さまざまな表示を行う表示装置１１０が備えられている。

データ収集蓄積部１０１は、ＥＣＵ５２が出力している信号とＥＣＵ５２に入力される信号を収集している。具体的には、ＥＣＵ５２が各部の制御のために出力する制御信号と車内各部に設けられているセンサから出力されてＥＣＵ５２へ入力される信号である。これらの信号は車内ＬＡＮ５１内を流れている。

収集される信号は、あらかじめ決められたものを収集して蓄積するようにしてもよいが、ここではすべての信号を収集している。つまり、本実施形態において収集している信号は、ＥＣＵ５２から出力された制御信号のすべて、車両内各部に設けられているさまざまなセンサからの信号（たとえばエンジン回転数、車速、ラジエータ水温、ガソリン量、オイル量、排気温、排気ＮＯｘ濃度など車両５０に設けられているさまざまなセンサからの信号である）のすべてである。

これらの信号は、ＬＡＮ５１内を流れているものを直接取得するようにしている。これは、ＥＣＵ５２を制御してＥＣＵ５２からさまざまな信号を取得するようにしてもよいが、そのようにした場合、車両走行中にＥＣＵ５２に余計な負荷がかかるため、本実施形態では、ＬＡＮ５１を流れている信号を直接収集するようにしたものである。もちろん、ＥＣＵ５２自体に、車両５０の制御に対して負荷がかからないように、さまざまなデータを外部に出力する機能があればそれを利用するようにしてもよい。

このようなデータ収集蓄積部１０１は、たとえば、ハードディスクユニットなどの記憶装置を有する。その容量は、１日の走行試験分を蓄積することができる程度あることが好ましい。なお、１日の走行試験をたとえば８〜１０時間程度とすると、その間に収集される制御信号やセンサ信号のデータ量は２〜５ＧＢ（ギガバイト）程度となる。

不具合判定部１０２は、データ収集蓄積部１０１が収集したデータから不具合の発生を検出するとともに、不具合発生時にそのまま試験走行を継続してよいか否かを１次判定する。

不具合発生の検出は、あらかじめ決められた不具合発生基準による判定する。不具合発生基準は、たとえば、エンジン回転数の異常、車速の異常、排気温度の異常、排気ガス中のＮｏｘなどの濃度異常など、さまざまなセンサからの異常値の検出（これらの異常は、たとえばあらかじめ決められたしきい値を超えた場合に異常とする）、ＥＣＵ５２が出力する不具合発生を示す信号（車内パネルの警告ランプを点灯するための信号など）の検出、および入力装置からの不具合発生の入力などである。なお、これらの不具合判定基準は、メモリ１２１に記憶されている。

１次判定は、主に安全性にかかわる不具合発生か否かを判定するする。ここでの判定結果が走行停止となれば、即座にそれ以降の走行試験は行わないと決断することが可能となる。

このために、不具合判定部１０２は、１次判定基準を格納するメモリ１２１（記憶手段）を有している。このメモリ１２１に記憶されている１次判定基準は、過去の不具合事例のうち、即刻走行試験を停止した重大な不具合事例を記憶している。

このような安全に関する重大な判定基準としては、たとえば、制御信号に対してその応答となるセンサ信号が正常に動作していないことを示す場合、すなわち制御不能に陥るような重大な事例である。このような不具合としては、たとえばアクセル開度の制御信号に対して、エンジン回転数が適切に反応しない場合、ブレーキペダルの踏み込みに対して車速が低下しない場合など非常に重要な場合である。より具体的には、エンジン制御の場合、アクセル開度に対してどの程度エンジン回転数が上昇（または減少）するかは、設計段階で決められているため、その値からしきい値を設定して、そのしきい値をメモリ１２１に記憶しておき、しきい値を外れるデータがデータ収集蓄積部１０１によって、収集、蓄積された場合は、走行停止の表示を表示装置１１０に行うようにする。

また、その不具合として、各ＥＣＵへの結線の断線またはショートが発生した場合はその旨を示す異常コードが発生するため、この異常コードをメモリ１２１に記憶しておき、該当異常コードを検出した場合は走行停止の表示を表示装置１１０に行うようにする。

不具合判定部１０２は、１次判定の結果、即座に走行試験を中止する必要はないが、不具合の発生を検知した場合、すなわち、上記不具合発生基準により不具合が検知されたが、その程度を判定する１次判定基準を満たさない不具合発生時には、解析サーバ２０から走行試験を中止するか否かの判定結果を取得して、表示装置１１０にその指示を表示させる。

なお、１次判定基準は、作業者（試験走行の実施者、車両の開発者などの人間）が車載端末１０の記憶容量などに応じて、即刻走行試験をやめるべき不具合の内容として任意に決めるべきものである。

送信処理部１０３は、使用している無線通信プロトコルに合わせて解析サーバ２０へ送信するデータを無線通信に適した形に変更する。

受信処理部１０４は、解析サーバ２０から送られてきたデータを車載端末１０内で処理できる形に変更する。

データ取得命令部１０５は、解析サーバ２０から送られてきた指令に基づいて必要なデータを出力するように、データ収集蓄積部１０１に対し指令する。なお、ここでは、解析サーバ２０が必要としているデータは適宜解析サーバ２０からの指令により解析サーバ２０へ送信するようにしているが、これに代えて、たとえば、不具合発生時から前、あらかじめ決められた時間分のデータを自動的にデータ収集蓄積部１０１から送信するようにしてもよい。

プログラム更新命令部１０６は、ＥＣＵ５２にアクセスして、解析サーバ２０から送られてきたプログラムでＥＣＵ５２内のプログラムを更新する。なお、ＥＣＵ５２は、マイクロコンピュータと必要なメモリからなる小型コンピュータであり、そのプログラムはメモリに格納されているため、そのプログラムを書き換えることでバグの修正や機能の追加などが可能となっている。

ＥＣＵアクセス部１０７は、ＥＣＵ５２とデータのやりとりを行うために、車載端末１０のデータ形式とＥＣＵ５２のデータ形式の変換などを行うインターフェースである。

表示装置１１０は、車載端末１０上でさまざまな情報を表示するためのディスプレイである。

データ送受信機１０８は解析サーバ２０との無線通信を行うために電波の送受信を行う。ここで、解析サーバ２０とのデータの送受信には、素早くかつ多くのデータのやりとりが必要となるため、データ送受信機１０８は複数のチャネルで送受信できることが好ましい。もちろん、解析サーバ２０との間でやりとりされるデータ量に応じて１つのチャネルであってもよい。

入力装置１０９は、たとえば、キーボードやボタン、タッチパッドなどの入力装置１０９である。この入力装置１０９からは、走行試験を行っているドライバーや同乗者などが体感的に不具合を検知したときに、不具合発生を入力できるようになっている。

このように構成された車載端末１０は、具体的には、たとえばポータブルパソコンである。上記各部の機能はこのパソコンに導入されたプログラムにより実行される。

次に、解析サーバ２０について説明する。

解析サーバ２０は、不具合事例を記憶したデータベース２０１（第２記憶手段）と、データベース２０１を参照して車載端末１０から取得したデータを解析し、不具合の程度を２次判定する不具合解析部２０２（第２判定手段）と、車載端末１０とデータのやりとりを行う送受信処理部２０３と、車載端末１０に指令する端末アクセス部２０４（プログラム更新指令手段）と、無線により車載端末１０とデータの送受信を行うデータ送受信機１０８と、外部の機器と接続するためのネットワーク端子２０５とを有する。

なお、本実施形態において判定手段は車載端末１０の１次判定手段（不具合判定部１０２）と解析サーバ２０の２次判定手段（不具合解析部２０２）より構成されている。

データベース２０１は、これまでに、さまざまな車両において行われた走行試験の結果得られた不具合事例を、その不具合が発生したときの対処法とともに記憶している。

記憶されている不具合事例は、
データベース２０１に記憶されている不具合の事例は、走行安全性に関するデータ、乗り心地に関するデータ、環境負荷に関するデータなど、カテゴリー分けした形で記憶されている。そして、カテゴリーごとに、不具合のあったときのデータと、その不具合に対してどのような対処を行ったか（少なくともその不具合発生時に走行試験を中止したか否か）を対応付けして記憶している。

より具体的には、走行安全性に関するものとしては、たとえば、データとしてエンジン回転数が異常値を示し制御信号に対して制御不能の場合、「走行試験は中止」と対応付けされている（ただしこのような制御不能を示す重大な不具合事例は車載端末１０において１次判定基準として記憶されている場合もある）。また、たとえば、データとしてエンジン回転数が異常値を示しているが制御信号に対しては正常に反応する場合、さらにデータを収集するために「エンジン回転数に注視してその後の走行試験は継続」などの対処が対応付けされている。

また、走行性能に関するものとしては、たとえば、データとして燃費があらかじめ決められた設計地から外れた場合、さらにデータを収集するため「燃料噴射量および車速に注視してその後の走行試験を継続」などの対処が対応付けされている。また、別の例として、バッテリ充電率があらかじめ決められたしきい値より低下している場合は、さらにデータを収集するため「エンジン回転数と電装負荷（エアコンなどの使用状況）の関係に注視してその後の走行試験を継続」などの対処が対応付けされている。

また、乗り心地に関するものとしては、たとえば、サスペンションの硬さに異常な値が示された場合は、「走行試験は中止」と対応付けされている。環境負荷に関するものとしては、たとえば、ＮＯｘの値がしきい値を超える場合は「エンジン回転数、冷却水温度、ＮＯｘ値に注視してその後の走行試験は継続」が対応付けされていたり、しきい値に対してあらかじめ決められた許容範囲を超えて非常に高いＮＯｘ値の場合、「走行試験は中止」と対応付けされている。）
このように、データベース２０１にはさまざまな不具合事例ごとに、不具合発生時のデータ値とそのときどのような対処が行われたかが記憶されている。不具合解析部２０２は、このデータベース２０１の不具合事例から今後の試験走行の継続か否かを判断することになる。

不具合解析部２０２は、車載端末１０から送られてきたデータを解析して、データベース２０１を参照し現場において最終的に走行試験継続か否かの判断を行う。

このために不具合解析部２０２は、車載端末１０から送られてきたデータと同じデータがデータベース２０１内に存在するかどうかを検索する。ここで、同じデータがある場合は、そのデータがある過去の不具合事例に則して、走行試験を継続するかどうかを判断する。

具体的には、不具合発生の際に車載端末１０から送られてきたデータと同じデータがデータベース２０１に存在した場合、そのデータのときに過去の事例ではどのような対処をしてかによって、走行試験を継続するか否かを判断する。

端末アクセス部２０４は、車載端末１０に対して、任意に必要なデータを送信させたり、ＥＣＵ５２のプログラム書き換えのためにプログラムを送信するなど、車載端末１０に対するさまざまな指令を行う。

送受信処理部２０３およびデータ送受信機１０８は、車載端末１０と無線によるデータのやりとりを行うためのもので、送受信処理部２０３はデータを送信するために必要な形式に変更し、データ送受信機１０８は電波により車載端末１０と信号のやりとりを行うためのものである。

また、解析サーバ２０はネットワーク端子２０５を介してネットワークに接続されている。したがって、解析サーバ２０は、ネットワークを介して他のコンピュータとデータのやりとりが可能となっている。たとえば、別なコンピュータへデータを送ったり、受け取ったりすることができる。特に、ＥＣＵ５２のプログラムを書き換える際には、別途開発されたプログラムなどがネットワークを介して他のコンピュータから送られてくることになる。

このような機能を有する解析サーバ２０は、コンピュータ（複数のパソコンなどからなる場合も含む）であり、上記各機能は、上記各機能を行うためのプログラムがこのコンピュータで実行されることで実施されることになる。また、図示しないが、解析サーバ２０は、キーボードやマウスなどの入力手段、ディプレイやプリンタなどの出力手段、および必要なデータを一時的にまたは継続的に記憶するための記憶装置などを備える。

そして、解析サーバ２０は走行試験を行う現場近くに設置される。たとえば、試験走行を行うテストコース内（テストコースに付属する施設内などを含む）に設置することが好ましい。これは、不具合発生時に、車載端末１０と無線通信によって可能な限り素早くかつ大容量のデータ通信を行うためである。

次に上述のように構成された車両走行試験装置の作用を説明する。

まず、走行試験中の動作について説明する。図２は、走行試験中における車載端末１０の処理手順を示すフローチャートであり、図３は走行試験中における解析サーバ２０の処理手順を示すフローチャートである。

車載端末１０では、データ収集蓄積部１０１が、車内ＬＡＮ５１を流れている信号を収集して蓄積する（Ｓ１）。収集されたデータは、その場で不具合判定部１０２に送られる。

そして不具合判定部１０２は、収集されているデータを常に監視して不具合発生を検知したなら、それをトリガとして走行試験を継続するかどうかの１次判定を行う（Ｓ２）。

ここで、１次判定基準を満たす不具合があると判断された場合は（Ｓ３：Ｙｅｓ）、表示装置１１０に走行試験中止を指示する表示を行う（Ｓ４）。またこのとき走行試験を中止したことを解析サーバへ伝える。なお、表示装置１１０に走行試験中止を表示する際には、表示とともに警告音を発するようにしてもよい。

一方、ステップＳ３において、１次判定基準を満たさない不具合発生であると判断された場合は（Ｓ３：Ｎｏ）、不具合発生を解析サーバ２０へ送信する（Ｓ５）。

その後、車載端末１０では、データ取得命令部１０５が解析サーバ２０からの指令（後述する解析サーバ２０によるＳ１２の処理）を受け取って、その指令に従いデータ収集蓄積部１０１に対してデータを出力して解析サーバ２０へ送信する（Ｓ６）。

次に、解析サーバ２０では、図３に示すように、車載端末１０から不具合発生を知らせるデータを受信すると（Ｓ１１：Ｙｅｓ）、不具合解析部２０２が、その不具合発生から所定時間前からのデータを送信するように端末アクセス部２０４を介して車載端末１０に指令する（Ｓ１２）。これにより車載端末１０からは不具合解析に必要なデータが送信されてくるので（前述Ｓ６の処理）、不具合解析部２０２はデータ送受信機２０９および送受信処理部２０３を介してこれを受信する（Ｓ１３）。

ここで、不具合発生時の所定時間前からのデータを使用するのは、不具合発生時点より前に、その不具合の兆候となるデータがないかどうかを解析するためである。なお、所定時間は任意でよく、作業者があらかじめこれまでの不具合事例などを考慮して設定しておく。

不具合解析部２０２は、受け取ったデータをデータベース２０１と照らし合わせて過去に同じデータがないかどうかを検索する（Ｓ１４）。このとき、不具合発生時点のデータのみならず要求した数分前からのデータすべてについてデータベース２０１内のデータと照合する。

そして、不具合解析部２０２が、データベース２０１内に、今回不具合発生に際して送られてきたデータと同じデータが存在していることを検知したなら（Ｓ１５：Ｙｅｓ）、データベース２０１からそのデータが発生したときの対処方法をデータベース２０１から取り出す（Ｓ１６）。

取り出しされた結果（対処方法）は、解析サーバ２０から車載端末１０へ送信されて表示装置１１０で表示される（Ｓ１７）。なお、車載端末１０での表示に代えて（または表示とともに）、解析サーバ２０に接続されているモニタ（不図示）などで表示してもよいし、ネットワークを介して他のコンピュータへ送信することも可能である。

これにより、走行試験を行っているドライバ（または同乗者）は、緊急を要する車載端末１０での１次判定のほかに、これまでに蓄積されているデータに基づいた２次判定の結果を受け取ることができる。そして、２次判定の結果から、走行試験の中止または継続を速やかに判断することができる。

なお、ステップＳ１５において、不具合解析部２０２が、今回不具合発生時に送られてきたデータと同じデータをデータベース２０１から検知しなかった場合には、不具合発生時における自動判断ができないので、判断不能の旨を車載端末１０（またはモニタ表示その他のコンピュータ）に伝える（Ｓ１８）。この場合、不具合の解析は、作業者によって行われることになるので、作業者の指示によりネットワークによって接続された他のコンピュータにデータを送信したり、また、不具合解析に必要なデータをさらに車載端末１０から収集するなどの処理が行われることになる。

次に、ＥＣＵ５２のプログラム更新の動作について説明する。図４は、ＥＣＵ５２のプログラム更新における解析サーバ２０の処理手順を示すフローチャートであり、図５はＥＣＵ５２のプログラム更新における車載端末１０の処理手順を示すフローチャートである。

まず、解析サーバ２０は、端末アクセス部２０４が、ＥＣＵ５２のプログラムを書き換えるための新しいプログラムを取得する（Ｓ２１）。このプログラムの取得は、たとえば、不良解析部が解析した結果、不具合発生時にプログラムやパラメータの書き換えがあった事例を取り出した場合に、それに合わせてプログラムやパラメータを書き換えるためのデータをデータベース２０１から取得したり、また、ネットワークを介して（または別途記憶媒体により）開発元のコンピュータからデータとして受け取ったりする。

続いて、端末アクセス部２０４は、取得したプログラムでＥＣＵ５２のプログラムを書き換えるように車載端末１０へ指令するとともに、取得したプログラムを送信する（Ｓ２２）。このとき、車両５０に複数のＥＣＵ５２がある場合には、更新するＥＣＵ５２をプログラム更新指令の中で指定する。

その後、端末アクセス部２０４は、車載端末１０からプログラム書き換え完了の返信を待って、プログラム書き換え完了の返信が来た時点（Ｓ２３：Ｙｅｓ）で処理を終了する。

なお、プログラム書き換え完了の返信が来なかった場合は（Ｓ２３：Ｎｏ）、たとえば、プログラム書き換えが完了しなかった旨を解析サーバ２０の表示手段へ表示する（Ｓ２４）。また、そのほかに、プログラム書き換え完了の返信が来なかったことを、プログラム開発元のコンピュータへ送信するなどの処理を行わせるようにしてもよい。その後処理を終了する。

なお、プログラム書き換え完了の返信が来なかった場合とは、たとえば、プログラム書き換えにかかる時間として想定される時間よりも長い時間経過した場合や、書き換えエラーの返信を受けた場合などである。

一方、車載端末１０では、図５に示すように、プログラム更新命令部１０６が解析サーバ２０からのＥＣＵプログラムの更新指令と新しいプログラムを受け取る（Ｓ３１）。

そして、プログラム更新命令部１０６は、受け取ったプログラム更新指令に基づき、ＥＣＵアクセス部１０７を介してプログラムの書き換えを実行する（Ｓ３２）。プログラムに書き換えは、プログラム更新指令で指定されたＥＣＵ５２のプログラムを書き換えるために、指定されているＥＣＵ５２に対してプログラムの書き換え指令とともに、新しいプログラムデータを送信することで行われる。

これにより、プログラム更新命令部１０６は、ＥＣＵ５２からは書き換え完了の返信が来るのを待って、当該返信が来た時点で（Ｓ３３：Ｙｅｓ）、解析サーバ２０へその旨を送信する（Ｓ３４）。一方、ＥＣＵ５２から、書き換えに要すると予想される時間の間に書き換え完了の返信が来なかった場合、またはＥＣＵ５２からエラーがきた場合には（Ｓ３３：Ｎｏ）、書き換え完了の返信が来なかったこと、またはエラーが来たこと解析サーバ２０へ送信する（Ｓ３５）。

このように、ＥＣＵ５２のプログラム更新機能によって、必要なときに、即座にＥＣＵ５２のプログラムを更新することが可能となる。この機能を使えば、たとえば、不具合発生時にＥＣＵ５２で動作させていたプログラムのパラメータをデータベース２０１から同じ不具合発生のときに変更したパラメータに書き直すなどの処理が簡単にできるようになる。

以上説明したように、本実施形態によれば、不具合発生時に車載端末１０において重大な不具合を１次判定して、即座に走行試験を中止し安全を確保することができ、その他の不具合については、テストコース内またその付近に設けられた解析サーバ２０に不具合発生時とそれ以前の必要なデータを送信して、車載することができないような膨大なデータベース２０１の中から、不具合発生時における過去の対処方法を引き出し、走行試験継続または中止を判断することが可能となる。特に、本実施形態は、車両５０の開発拠点（たとえは車両５０の開発、設計を行う部署）とテストコースが離れているような場合でも、多くの不具合事例について、いちいち遠く離れた車両５０の開発拠点に問い合わせをすることなく、テストを行っている現場で走行試験の継続か否かを判断することが可能となる。

また、本実施形態によれば、解析サーバ２０から車載端末１０に対し、無線通信よってＥＣＵ５２のプログラムの更新を行わせるようにしたので、遠隔操作により車両５０に搭載されているＥＣＵプログラムの更新を行うことができる。特に、解析サーバ２０の機能である不具合発生時におけるデータベース２０１との対照によって、その不具合の発生時に過去の事例としてＥＣＵプログラムやプログラム内パラメータの変更などがあったときには、その過去の事例に基づいて自動的にＥＣＵ５２のプログラムを更新することが可能となる。

以上本発明を適用した実施形態を説明したが、本発明は上述した実施形態に限定されるものではない。たとえば、上述した実施形態では、車載端末１０において急を要するものおよび／または重大な不具合について車載端末１０自身が１次判定として走行試験継続か否かを判定し、それ以外の不具合については解析サーバ２０で行うこととしたが、これに変えて、車載端末１０はあくまでも車両５０内でのデータの取得および不具合発生の検出のみとして、不具合発生時には、その時点およびそれより前の所定時間分のデータを解析サーバ２０へ送信し、解析サーバ２０がすべての判定を行うようにしてもよい。

また逆に、車載端末１０が、直接データベースへアクセスし、不具合発生時には、すべての判断を車載端末１０によって行うようにしてもよい。この場合、車載端末１０およびデータベース２０１は、たとえば、車載端末１０とデータベース２０１との間でデータのやりとりを行うための無線通信設備を有する。

さらに上述した実施形態では、解析サーバ２０はテストコース内または付近の施設に置くこととしているが、これは施設や建物内に固定されている必要はなく、解析サーバ２０としての機能を試験車両とは別の移動体内（例えば試験車両とは別の車両５０）に設置してもよい。このように移動体に解析サーバ２０を設置することで、たとえば、試験車両の近傍を、解析サーバ２０を載せた移動体が一緒に移動しながら走行試験を行うことも可能となる。

本発明は、車両の走行試験、たとえばテストコースを使用するフリート走行試験に好適に用いることができる。

本発明を適用した車両走行試験装置の構成を説明するブロック図である。 走行試験中における車載端末の処理手順を示すフローチャートである。 走行試験中における解析サーバの処理手順を示すフローチャートである。 ＥＣＵプログラム更新における解析サーバの処理手順を示すフローチャートである。 ＥＣＵプログラム更新における車載端末の処理手順を示すフローチャートである。

符号の説明

１０…車載端末、
２０…解析サーバ、
５０…車両、
５１…ＬＡＮ、
５２…ＥＣＵ、
１０１…データ収集蓄積部、
１０２…不具合判定部、
１０３…送信処理部、
１０４…受信処理部、
１０５…データ取得命令部、
１０６…プログラム更新命令部、
１０７…ＥＣＵアクセス部、
１０８…データ送受信機、
１０９…入力装置、
１１０…表示装置、
１２１…メモリ、
２０１…データベース、
２０２…不具合解析部、
２０３…送受信処理部、
２０４…端末アクセス部、
２０５…ネットワーク端子。

Claims (7)

1. 車両で使用されている信号をデータとして収集するデータ収集手段と、
   前記データ収集手段が収集したデータとあらかじめ記憶されている判定基準に基づいて、走行試験を継続するか否かを判定する判定手段と、
   を有することを特徴とする車両走行試験装置。
2. 前記車両で使用されている信号は、少なくとも前記車両内の電子制御装置から出力された信号および前記電子制御装置へ入力される信号であること特徴とする請求項１記載の車両走行試験装置。
3. 前記判定基準は、過去の不具合事例のデータと当該不具合事例発生時の対処法を記憶した記憶手段に記憶されており、
   前記判定手段は、前記記憶手段に記憶された不具合事例のデータと前記データ収集手段が収集したデータとを対比して、前記データ収集手段が収集したデータが、当該不具合事例のデータと同じデータの場合に同じとなった不具合事例の対処法に基づいて走行試験を継続か否かを判定すること特徴とする請求項１または２記載の車両走行試験装置。
4. 前記データ収集手段が収集したデータは、不具合発生時点より前のデータを含むことを特徴とする請求項１〜３のいずれか一つに記載の車両走行試験装置。
5. 前記判定手段は、
   あらかじめ決められた不具合が発生したときのみ走行試験の停止を判定する第１判定手段と、
   過去の不具合事例のデータと当該不具合事例発生時の対処法を記憶した第２記憶手段と、
   前記第２記憶手段に記憶された不具合事例のデータと前記データ収集手段が収集したデータとを対比して、前記データ収集手段が収集したデータが、当該不具合事例のデータと同じデータの場合に同じとなった不具合事例の対処法に基づいて走行試験を継続か否かを判定する第２判定手段と、を有すること特徴とする請求項１〜４のいずれか一つに記載の車両走行試験装置。
6. 前記第１判定手段は、前記車両内に設置される車載端末にあり、
   前記第２記憶手段および前記第２判定手段は、前記車両外に設置される解析サーバにあり、
   前記データ収集手段が収集したデータは、前記車載端末から前記解析サーバへ無線通信によって送信されることを特徴とする請求項５記載の車両走行試験装置。
7. 前記車載端末は、さらに前記車両内の電子制御装置のプログラムを書き換えるプログラム更新手段を有し、
   前記解析サーバは、さらに前記プログラム更新手段に更新するプログラムを送信して、前記電子制御装置の前記プログラムの更新を指令するプログラム更新指令手段を有すること特徴とする請求項５記載の車両走行試験装置。

Images