JP5439522B2 - 車両データ収集装置及び車両データ収集方法 - Google Patents

Description

この発明は、車両からデータを収集して記憶する外付け型の車両データ収集装置及び車両データ収集方法に関する。

車両の運転中に異常な症状が発生した場合、インスツルメントパネルに設けられた警告灯を点灯する等の警告によって運転者に知らせることが行われている。異常な症状又はこれに伴う警告に伴ってユーザが販売店又は整備工場に車両を持ち込むと、そこで車両の診断又は修理が行われる。

修理を担当する作業者（テクニシャン等）は、故障車両の電子制御装置（以下「ＥＣＵ」という。）に故障診断機を接続してＥＣＵに記憶された故障発生時の故障コード等の情報を読み出すことにより、比較的容易に異常系統（異常が発生している電気回路）を特定することが可能である。この種の故障診断機は広く普及しており、例えば、特許文献１に記載されている。

ところが、ユーザから異常な症状の訴えは何度もあるものの、故障コードの記録がなく、また、修理担当のテクニシャンが訴えに応じて再現を試みても再現せず、修理が難しい場合（いわゆる難問修理の場合）がある。

このような難問修理に対しては、例えば、特許文献２に記載されるような大容量の記憶装置を対象車両のＥＣＵに一時的に取り付け、数日間に亘ってユーザに運転してもらう。そして、故障診断に必要なデータ（運転パラメータデータ）を記憶装置に収集し、収集したデータを故障診断機又は故障解析装置で検討することにより、詳細な診断を行う。

このような運転パラメータデータの収集は、システム制御用のＥＣＵに対しての内部情報の要求及びＥＣＵからの応答データについて所定周期で連続して行われる。このため、複数のＥＣＵが接続された車内ネットワーク（例えば、ＣＡＮ）を介して故障診断機を１又は複数の特定のＥＣＵと通信させる場合、車内ネットワークの新たな負荷となり、バス使用率を増加させることになる。

このため、車両の運転状態によっては一時的にバス使用率が過度に高くなり、通信が混雑して運転パラメータデータが入手できなくなることも想定される。

運転パラメータデータを入手できないことに対する対応として、特許文献２の車両データ収集装置では、特許文献２の図１３、図１４及び段落［００５０］〜［００５３］に示されるように、データの再送要求で対応する。すなわち、返信が遅れたり行われなかったりしても継続して可能な限りのデータを収集する。また、データの種類や各データのサイズが大きくなる場合には、重要度の低いデータの脱落を許容することで定期的な収集の同期を厳密に守るようにしている。

特開平０５−１７２７０３号公報 特開２００８ー０７０１３３号公報

ところが、上記のような対応では、受信した運転パラメータデータの連続性が失われるおそれがある。また、そのように連続性が失われた場合、欠落しているデータを解析に用いることができないため、解析の精度が低下することも懸念される。

さらに、運転中の車両に対して、車内ネットワークのバス使用率が高まることにより車両運転のためのデータ通信が妨害されることがないような十分な配慮が必要になる。

この発明は、上記のような事情を考慮したものであり、収集する運転パラメータデータの連続性を確保すること及び車両運転のためのデータ通信の混雑を回避し易くすることの少なくとも一方が可能な車両データ収集装置及び車両データ収集方法を提供することを目的する。

この発明に係る車両データ収集装置は、車両における複数の電子制御装置（以下「ＥＣＵ」という。）が接続された車内ネットワークに外部から着脱自在に接続された状態において、前記車両の運転時における各部の動作状態を示す運転パラメータデータを要求するデータ要求信号を前記複数のＥＣＵの少なくとも１つに対して複数回送信し、前記データ要求信号に対応する前記運転パラメータデータを受信して記憶部に記憶する外付け型の車両データ収集装置であって、前記車内ネットワークに接続されて前記車内ネットワークのバス使用率を検出するバス使用率検出手段と、前記複数のＥＣＵの少なくとも１つに対して送信する複数の前記データ要求信号を選択して設定する選択設定手段と、前記選択設定手段で設定した前記データ要求信号の個数に基づいて各データ要求信号について所定周期内での均等な送信間隔を設定する送信間隔設定手段と、前記バス使用率が第１閾値を下回ると判定したとき、前記均等な送信間隔で各データ要求信号を送信する要求信号送信手段とを有することを特徴とする。

この発明によれば、車内ネットワークのバス使用率が第１閾値を下回ると判定したとき、少なくとも１つのＥＣＵに対してデータ要求信号を送信する。このため、車両の運転時におけるＥＣＵ間の通信を制限することなく又はＥＣＵ間の通信に対する制限を抑えた状態で、運転パラメータデータを収集することが可能となる。従って、車両運転時における車両運転のためのデータ通信の混雑を防止し易くなる。

また、この発明によれば、データ要求信号の個数に基づいて設定した均等な間隔で各データ要求信号を送信する。このため、データ要求信号の送信及び運転パラメータデータの出力によるバス使用率の一時的な急増を抑制することが可能となる。従って、バス使用率の一時的な急増に伴う通信の中断を避けることができ、運転パラメータデータの連続性を確保することが容易になる。

前記バス使用率検出手段は、前記車内ネットワークの通信量を、前記均等な送信間隔と同じ間隔で検出して前記バス使用率を算出し、前記要求信号送信手段は、前記バス使用率が前記第１閾値を上回ったと判定したとき、前記データ要求信号の送信を中止し、前記バス使用率が前記第１閾値以下に設定された第２閾値を下回ったか否かを、前記均等な送信間隔で判定し、前記バス使用率が前記第２閾値を下回ったとき、前記均等な送信間隔での前記データ要求信号の送信を再開してもよい。

これにより、バス使用率の増加に伴ってデータ要求信号の送信を中止する前後でデータ要求信号の送信周期を変化させることがない。従って、データ要求信号の送信中止に伴って運転パラメータデータが欠落した場合であっても、欠落したデータの補完が容易になる。

前記選択設定手段は、故障症状毎に運転パラメータデータのデータ要求信号を一括して選択して設定してもよい。これにより、送信すべきデータ要求信号の選定及び送信間隔を簡単に設定することが可能となる。

この発明に係る車両データ収集方法は、車両における複数のＥＣＵが接続された車内ネットワークに外部から車両データ収集装置を接続した状態において、前記車両の運転時における各部の動作状態を示す運転パラメータデータを要求するデータ要求信号を前記車両データ収集装置から前記複数のＥＣＵの少なくとも１つに対して複数回送信し、前記データ要求信号に対応する前記運転パラメータデータを前記車両データ収集装置で受信して記憶部に記憶するものであって、前記車内ネットワークに接続した前記車両データ収集装置により前記車内ネットワークのバス使用率を検出するバス使用率検出ステップと、前記車両データ収集装置から前記複数のＥＣＵの少なくとも１つに対して送信する複数の前記データ要求信号を選択して設定する選択設定ステップと、前記選択設定ステップで設定した前記データ要求信号の個数に基づいて各データ要求信号について所定周期内での均等な送信間隔を設定する送信間隔設定ステップと、前記バス使用率が第１閾値を下回ると判定したとき、前記均等な送信間隔で各データ要求信号を送信する要求信号送信ステップとを有することを特徴とする。

この発明に係る車両データ収集方法は、複数のＥＣＵが接続された車内ネットワークを有する車両について前記車両の外部において実行する故障診断、健康診断及び運転技能診断の少なくとも１つである車両診断に用いる車内データを収集するものであって、外部診断機において対象となる診断項目を設定する項目設定ステップと、前記診断項目に対応する複数項目の前記車内データを前記複数のＥＣＵのいずれかに対して要求する複数項目のデータ要求信号を特定する要求信号特定ステップと、前記外部診断機から又は前記外部診断機の指令に応じて動作する車載中継機器から前記複数のＥＣＵの少なくとも１つに対して前記複数項目のデータ要求信号を複数回送信するデータ要求ステップと、前記データ要求信号を受信したＥＣＵのそれぞれから前記外部診断機に又は前記車載中継機器に対して前記車内データを複数回送信する車内データ送信ステップと、前記ＥＣＵから直接受信した前記車内データ又は前記車載中継機器を介して受信した前記車内データを前記外部診断機において記憶する車内データ記憶ステップとを備え、前記データ要求ステップは、前記診断項目に応じて特定される前記複数項目の前記データ要求信号の送信間隔を設定する送信間隔設定ステップと、前記車内ネットワークのバス使用率を検出するバス使用率検出ステップと、前記バス使用率が第１閾値を下回るか否かを判定するバス使用状況判定ステップと、前記バス使用率が前記第１閾値を下回ると判定したとき、前記送信間隔で各データ要求信号を送信する要求信号送信ステップとを有し、前記送信間隔設定ステップでは、前記複数項目の前記車内データのそれぞれを１つ取得するために設定された周期であるデータ収集周期内において、前記複数項目のデータ要求信号を均等な間隔で送信するように前記送信間隔を設定することを特徴とする。

この発明によれば、車内ネットワークのバス使用率が第１閾値を下回ると判定したとき、少なくとも１つのＥＣＵに対してデータ要求信号を送信する。このため、車両の運転時におけるＥＣＵ間の通信を制限することなく又はＥＣＵ間の通信に対する制限を抑えた状態で、運転パラメータデータを収集することが可能となる。従って、車両運転時における車両運転のためのデータ通信の混雑を防止し易くなる。

また、この発明によれば、データ要求信号の個数に基づいて設定した均等な間隔で各データ要求信号を送信する。このため、データ要求信号の送信及び運転パラメータデータの出力によるバス使用率の一時的な急増を抑制することが可能となる。従って、バス使用率の一時的な急増に伴う通信の中断を避けることができ、運転パラメータデータの連続性を確保することが容易になる。

この発明の一実施形態に係る車両データ収集装置を含む車両診断システムの概略的な構成を示すブロック図である。 診断機本体及び前記データ収集装置が有する各種機能を示す図である。 運転パラメータデータの収集のための事前準備としての作業者の作業及び前記データ収集装置の処理の一例を示すフローチャートである。 本実施形態で用いる各種の時間、間隔及び周期を説明するための図である。 前記運転パラメータデータの収集時の作業者の作業及び前記データ収集装置の処理の一例を示すフローチャートである。 前記運転パラメータデータの収集時における前記データ収集装置の各種動作及び各種信号を示すタイムチャートである。 バス使用率を算出するための前記データ収集装置の演算部の構成を示す図である。 前記運転パラメータデータの収集後の作業者の作業及び前記データ収集装置の処理の一例を示すフローチャートである。 比較例に係る構成及び制御を用いた場合のバス使用率とネットワークトラフィックの一例を示す図である。 前記実施形態に係る構成及び制御を用いた場合のバス使用率とネットワークトラフィックの一例を示す図である。

Ａ．一実施形態
［１．構成］
（１−１．全体構成）
図１は、この発明の一実施形態に係る車両データ収集装置１８（以下「データ収集装置１８」ともいう。）を含む車両診断システム１０（以下「システム１０」ともいう。）の概略的な構成を示すブロック図である。システム１０は、診断対象としての車両１２と、車両１２外部から車両１２の故障診断を行う外部診断機１４とを有する。外部診断機１４は、診断機本体１６（以下「本体１６」ともいう。）及びデータ収集装置１８（data logger）を有する。

（１−２．車両１２）
本実施形態の車両１２は、駆動用エンジン及び走行モータ（いずれも図示せず）を有するハイブリッド車としての自動四輪車である。或いは、車両１２は、走行モータを有さずエンジンのみを有するガソリン車、電気自動車（燃料電池車を含む。）等の車両であってもよく、また、自動二輪車、自動三輪車等の車両であってもよい。

車両１２は、車両１２を制御するための複数の電子制御装置２０ａ〜２０ｆ（以下「第１〜第６ＥＣＵ２０ａ〜２０ｆ」又は「ＥＣＵ２０ａ〜２０ｆ」といい、「ＥＣＵ２０」と総称する。）を有する。なお、図１では、理解を容易化するため、６つのＥＣＵ２０ａ〜２０ｆのみを示しているが、それ以外のＥＣＵ２０を設けることもできる。ＥＣＵ２０の数としては、例えば、２〜数百個とすることができる。

ＥＣＵ２０の例としては、例えば、エンジン電子制御装置（以下「エンジンＥＣＵ」という。）、モータ電子制御装置（以下「モータＥＣＵ」という。）、車両挙動安定電子制御装置（以下「ＶＳＡ ＥＣＵ」という。）、アンチロックブレーキシステム電子制御装置（以下「ＡＢＳ ＥＣＵ」という。）、電動パワーステアリング電子制御装置（以下「ＥＰＳ ＥＣＵ」という。）、バッテリ電子制御装置（以下「バッテリＥＣＵ」という。）、メータ電子制御装置（以下「メータＥＣＵ」という。）、エアコンディショナ電子制御装置（以下「エアコンＥＣＵ」という。）、補助拘束システム電子制御装置（以下「ＳＲＳ ＥＣＵ」という。）、イモビライザ電子制御装置（以下「イモビライザＥＣＵ」という。）等を挙げることができる。

エンジンＥＣＵは、図示しないエンジンの出力を制御する。モータＥＣＵは、図示しない走行モータの出力を制御する。ＶＳＡ ＥＣＵは、車両挙動安定化（Vehicle Stability Assist）制御を実行する。ＡＢＳ ＥＣＵは、アンチロックブレーキ制御を実行する。ＥＰＳ ＥＣＵは、操舵アシスト制御を実行する。バッテリＥＣＵは、図示しない高圧バッテリ又は低圧バッテリの充放電等を制御する。メータＥＣＵは、図示しないインストルメントパネルに設けられたメータ表示装置（図示せず）を制御する。エアコンＥＣＵは、図示しないエアコンディショナを制御する。ＳＲＳ ＥＣＵは、図示しないエアバッグシステムの制御を行う。イモビライザＥＣＵは、図示しないイモビライザ装置及びスマートキーシステムの制御を行う。

各ＥＣＵ２０は、図示しない入出力部、演算部及び記憶部等を有する。また、各ＥＣＵ２０は、通信バス２２を介して接続され、車内ネットワーク２４を構成する。本実施形態における車内ネットワーク２４は、ＣＡＮ（Controller Area Network）である。或いは、ＬＩＮ（Local Interconnect Network）、ＦｌｅｘＲａｙ等のその他のネットワークに対して本発明を適用することもできる。通信バス２２は、車室内に設けられたデータリンクコネクタ２６（例えば、ＵＳＢコネクタ）を有する。

また、第１ＥＣＵ２０ａには、イグニッションスイッチ２８（以下「ＩＧＳＷ２８」という。）が接続されており、第１ＥＣＵ２０ａは、ＩＧＳＷ２８のオンオフに応じて起動し、その他のＥＣＵ２０ｂ〜２０ｆのオンオフを制御する。

（１−３．外部診断機１４）
上記の通り、外部診断機１４は、診断機本体１６及びデータ収集装置１８を有する。

（１−３−１．診断機本体１６）
（１−３−１―１．概要）
診断機本体１６は、データ収集装置１８の各種設定（動作設定等）を行うと共に、データ収集装置１８が収集した運転パラメータデータＤ（以下「データＤ」ともいう。）を解析して故障診断を行う。故障診断の代わりにその他の診断を行ってもよい（詳細は後述する。）。

図１に示すように、本体１６は、入出力部３０、演算部３２、記憶部３４、表示部３６及びデータリンクコネクタ３８を有する。

本体１６は、例えば、市販のノート型パーソナルコンピュータ、タブレット型コンピュータ又はスマートフォンから構成することができる。本体１６は、必ずしも単一の筐体から構成される必要はなく、例えば、本体としてのパーソナルコンピュータと、データ収集装置１８とのインタフェースとしての子機（中継器）とから構成してもよい。

（１−３−１―２．各種機能）
図２は、診断機本体１６及びデータ収集装置１８が有する各種機能を示す図である。図２に示すように、診断機本体１６は、収集条件設定機能４０、データ収集装置通信機能４２及びデータ解析機能４４を有する。各機能４０、４２、４４は、記憶部３４に記憶されたプログラムを実行すること等により実現される。

収集条件設定機能４０は、データ収集装置１８がデータＤを収集する条件（例えば、データＤの種類、項目、取得回数、取得時間等）であるデータ収集条件を設定する。

データ収集装置通信機能４２は、データ収集装置１８との間の通信に関連した機能であり、データ収集装置１８に対してデータ収集条件を送信する収集条件送信機能４６と、データ収集装置１８からデータＤを読み出す収集データ読出し機能４８とを有する。

データ解析機能４４は、データ収集装置１８から取得したデータＤを用いて故障診断のためのデータ解析を行う。

（１−３−２．車両データ収集装置１８）
（１−３−２―１．概要）
データ収集装置１８は、車両１２における運転パラメータデータＤを収集する。図１に示すように、データ収集装置１８は、入出力部５０、演算部５２、記憶部５４、表示部５６及びデータリンクケーブル５８を有する。本実施形態の演算部５２は、中央演算装置６０（以下「ＣＰＵ６０」という。）及びプログラマブル・ロジック・デバイス６２（以下「ＰＬＤ６２」という。）を備える。本実施形態のＣＰＵ６０及びＰＬＤ６２は、通信バス２２の使用率（以下「バス使用率Ｒｂｕｓ」という。）［％］の検出に用いるが、詳しい構成については図７を参照して後述する。

（１−３−２―２．各種機能）
図２に示すように、データ収集装置１８は、本体通信機能７０及びデータ収集機能７２を有する。各機能７０、７２は、記憶部５４に記憶されたプログラムを実行すること等により実現される。本体通信機能７０は、診断機本体１６との間の通信に関連した機能であり、データ収集機能７２は、車両１２との間でのデータＤの収集に関連した機能である。

本体通信機能７０は、収集条件読込み機能７４及び収集データ送信機能７６を有する。収集条件読込み機能７４は、データ収集装置１８がデータＤを収集する条件（データ収集条件）を診断機本体１６から読み込む機能である。収集データ送信機能７６は、データ収集装置１８が収集したデータＤを診断機本体１６に送信する機能である。

データ収集機能７２は、要求信号特定機能７８、データ要求機能８０及びデータ受信・記憶機能８２を有する。要求信号特定機能７８は、送信するデータ要求信号Ｓｒｅｑを特定する機能である。データ要求機能８０は、データＤを要求する対象であるＥＣＵ２０（以下「対象ＥＣＵ２０ｔａｒ」という。）に対して、特定項目のデータＤを要求する機能である。データ受信・記憶機能８２は、データ要求信号Ｓｒｅｑに応じて対象ＥＣＵ２０ｔａｒが出力したデータＤを受信し、記憶部５４に記憶する機能である。

図２に示すように、データ要求機能８０は、送信間隔設定機能８４、バス使用率検出機能８６、要求許否判定機能８８及び要求信号送信機能９０を有する。

送信間隔設定機能８４は、データ要求信号Ｓｒｅｑの送信間隔（以下「データ要求信号送信間隔Ｉ１」又は「送信間隔Ｉ１」という。）［ｓｅｃ］を設定する。バス使用率検出機能８６は、通信バス２２の使用率（バス使用率Ｒｂｕｓ）を算出する。要求許否判定機能８８は、バス使用率Ｒｂｕｓに基づいてデータ要求信号Ｓｒｅｑの送信の許否を判定する。要求信号送信機能９０は、データ要求信号Ｓｒｅｑの送信が許可されるとき、データ要求信号Ｓｒｅｑを出力する。

［２．運転パラメータデータＤの内容］
本実施形態における運転パラメータデータＤは、故障診断に用いるものであり、例えば、次のようなものを含むことができる。

例えば、車両１２の駆動状態（エンジン及び走行モータに関するもの）を診断したい場合、前記エンジンＥＣＵ及び前記モータＥＣＵから取得するデータＤを取得する。

この場合、エンジンＥＣＵから取得するデータＤとしては、例えば、図示しない車速センサが検出した車速、図示しない温度センサが検出したエンジン冷却水の温度、図示しないクランク角センサが検出したクランク角に基づきエンジンＥＣＵが算出したエンジン回転数、図示しない吸気圧センサが検出した吸気圧、エンジンＥＣＵにおける各種設定値が含まれる。

モータＥＣＵから取得するデータＤとしては、例えば、図示しないレゾルバからの出力に基づきモータＥＣＵが算出したモータ回転数、駆動モータ用の高圧バッテリの残容量、モータＥＣＵの各種設定値が含まれる。

［３．運転パラメータデータＤの収集］
次に、運転パラメータデータＤの収集に関する各種の作業及び処理について説明する。

（３−１．事前準備）
（３−１−１．事前準備の全体的な流れ）
図３は、運転パラメータデータＤの収集のための事前準備としての作業者の作業及びデータ収集装置１８の処理の一例を示すフローチャートである。ステップＳ１において、作業者（テクニシャン等）は、データ収集装置１８のデータリンクケーブル５８のデータリンクコネクタ６４を診断機本体１６のデータリンクコネクタ３８に接続する。

ステップＳ２において、作業者は、診断機本体１６の入出力部３０（マウス、キーボード等）を操作して、運転パラメータデータＤの収集に用いる診断ソフトウェアを起動する。これに伴い、診断機本体１６は、データＤの収集に関する表示画面（図示せず）を表示部３６に表示する。ステップＳ１、Ｓ２の順番は逆であってもよい。

ステップＳ３において、作業者は、前記表示画面への入力によりデータ収集条件を入力する（詳細は後述する。）。

ステップＳ４において、作業者は、表示画面を介しての入力により診断機本体１６とデータ収集装置１８との間での通信を確立することを要求する。当該要求を受けた本体１６（データ収集装置通信機能４２）は、データ収集装置１８との間で通信を確立する。なお、ステップＳ３、Ｓ４の順番は反対でもよい。

ステップＳ５において、作業者は、表示画面を介しての入力によりデータ収集装置１８のデータ収集条件の変更を本体１６に要求する。当該要求を受けた本体１６（収集条件送信機能４６）は、データ収集装置１８のデータ収集条件を、ステップＳ３で入力されたものに変更する。

ステップＳ６において、作業者は、表示画面を介しての入力により診断機本体１６とデータ収集装置１８との間での通信を切断することを要求する。当該要求を受けた本体１６（データ収集装置通信機能４２）は、データ収集装置１８との間で通信を切断する。

ステップＳ７において、作業者は、データ収集装置１８のデータリンクケーブル５８のデータリンクコネクタ６４を診断機本体１６のデータリンクコネクタ３８から取り外す。

（３−１−２．データ収集条件）
ステップＳ３で入力されるデータ収集条件は、例えば、車種、型式、仕向地、仕様、ネットワークの種類｛ＣＡＮ、ＬＩＮ、ＦｌｅｘＲａｙ等の別及び複数のＣＡＮ（Ｆ−ＣＡＮ、Ｂ−ＣＡＮ等）がある場合、それらの別｝、データ収集装置１８で使用する入力チャンネルの番号、対象となるネットワーク２４のボーレート（以下「ボーレートＲｂｒｔ」という。）［ｂｐｓ］を含む。

さらに、データ収集条件は、データＤの内容（項目）、データＤを要求するＥＣＵ２０（対象ＥＣＵ２０ｔａｒ）、データＤの連続的な取得を行う時間（以下「連続的データ取得時間Ｔｃｏｎｔ」又は「データ取得時間Ｔｃｏｎｔ」という。）、データＤの連続的な取得を行う周期（以下「連続的データ取得周期Ｃｃｏｎｔ」又は「データ取得周期Ｃｃｏｎｔ」という。）、データＤの収集にかける総時間（以下「データ収集総時間Ｔｔｏｔａｌ」又は「総時間Ｔｔｏｔａｌ」という。）を含むことができる。

なお、本実施形態では、各データ要求信号Ｓｒｅｑの送信間隔（データ要求信号送信間隔Ｉ１）は、データ収集装置１８が自動的に設定する（詳細は後述する。）

図４は、本実施形態で用いる各種の時間、周期及び間隔を説明するための図である。図４に示すように、本実施形態では、１つのデータ要求信号Ｓｒｅｑを送信するための送信間隔Ｉ１が複数集まって、個別データ取得周期Ｃｃｏｌを構成する。個別データ取得周期Ｃｃｏｌは、データ収集条件においてデータＤを取得するものとして選択された項目それぞれについて１つのデータＤを取得するために設定された周期である。例えば、設定された項目が５つある場合、この５つの項目それぞれについて１つのデータＤを取得し、合計５つのデータＤを取得するための周期が個別データ取得周期Ｃｃｏｌである。個別データ取得周期Ｃｃｏｌは、例えば、数十ミリ秒〜数秒のいずれかに設定することが可能である。なお、１つのデータ要求信号Ｓｒｅｑは、１つの送信間隔Ｉ１の中の一部の時間を用いて出力されることに留意されたい（図６及び図１０参照）。

本実施形態では、個別データ取得周期Ｃｃｏｌが固定値とされる一方、送信間隔Ｉ１は可変とされる。但し、個別データ取得周期Ｃｃｏｌは、データ収集条件の設定（図３のＳ３）において変更してもよい。

複数の個別データ取得周期Ｃｃｏｌが集まって連続的データ取得時間Ｔｃｏｎｔを構成する。図４では、１つの連続的データ取得時間Ｔｃｏｎｔ（左端）が５つの個別データ取得周期Ｃｃｏｌを含んでいるが、これはあくまで一例であり、各連続的データ取得時間Ｔｃｏｎｔは、例えば、車両１２の運転時間（例えば、ＩＧＳＷ２８がオンとされている時間）とすることができる。この場合、車両１２を運転している時間帯又は長さが異なれば、連続的データ取得周期Ｃｃｏｎｔにおける連続的データ取得時間Ｔｃｏｎｔの位置又は長さは異なることとなる。例えば、１つの連続的データ取得時間Ｔｃｏｎｔ（例えば、３０分間）において、収集すべき全ての項目について運転パラメータデータＤを複数回（例えば、６０回）取得する。

また、連続的データ取得周期Ｃｃｏｎｔは、ある連続的データ取得時間Ｔｃｏｎｔの開始時点と次の連続的データ取得時間Ｔｃｏｎｔの開始時点の間隔を示す。データ取得周期Ｃｃｏｎｔは、例えば、２４時間（１日）に設定する。その他の長さに設定することも可能である。

連続的データ取得時間Ｔｃｏｎｔとして車両１２の運転時間を設定した場合、連続的データ取得周期Ｃｃｏｎｔ内で車両１２を複数回運転すれば、１つの連続的データ取得周期Ｃｃｏｎｔの中に複数の連続的データ取得時間Ｔｃｏｎｔが存在することとなる。また、連続的データ取得周期Ｃｃｏｎｔにおける連続的データ取得時間Ｔｃｏｎｔ以外の時間は、車両１２が運転されていない時間となる。

データ収集総時間Ｔｔｏｔａｌは、例えば、データ収集装置１８を車両１２に取り付ける日数（例えば、数日間〜３０日間）を設定することが可能であり、データ取得周期Ｃｃｏｎｔ（長さ）にその回数を乗算した値となる。

また、本実施形態では、連続的データ取得時間Ｔｃｏｎｔ、連続的データ取得周期Ｃｃｏｎｔ等を個別に設定する代わりに、不具合症状と、対象ＥＣＵ２０ｔａｒ及びデータＤとを予め関連付けておき、ユーザから訴えのあった不具合症状を入力することで、対象ＥＣＵ２０ｔａｒとデータＤを特定することができる。

すなわち、不具合症状｛例えば、意図しないエンジンストールの発生、加速の不良、エンジンの始動の不良、ノッキングの発生、エンジンの異音の発生等｝の選択肢を表示画面で選択可能にしておく。そして、作業者が選択肢を選択すると、収集すべきデータＤを自動的に特定することができる。

さらに、ステップＳ３での設定内容には、バス使用率Ｒｂｕｓの第１閾値ＴＨ＿Ｒｂｕｓ１及び第２ＴＨ＿Ｒｂｕｓ２（詳細は後述する。）等を含めることができる。

（３−２．運転パラメータデータＤの収集時の作業及び処理）
（３−２−１．運転パラメータデータＤの収集時の全体的な流れ）
図５は、運転パラメータデータＤの収集時の作業者の作業及びデータ収集装置１８の処理の一例を示すフローチャートである。図６は、運転パラメータデータＤの収集時におけるデータ収集装置１８の各種動作及び各種信号を示すタイムチャートである。

図５のステップＳ１１において、作業者（テクニシャン等）は、データ収集装置１８のデータリンクケーブル５８のデータリンクコネクタ６４を車両１２のデータリンクコネクタ２６に接続する。

ステップＳ１２において作業者は、データ収集装置１８の図示しない開始スイッチをオンにして、データ収集装置１８の電源をオンにする（図６の時点ｔ１）。なお、データ収集装置１８を作動させる電力は、車両１２の図示しない低電圧バッテリ（１２Ｖバッテリ）から供給することができる。或いは、データ収集装置１８自体で電源を有していてもよい。また、前記低電圧バッテリからデータ収集装置１８に電力供給する場合又はデータ収集装置１８自体で電源を有する場合のいずれにおいても、車両１２に接続した時点でデータ収集装置１８を自動的にオンさせてもよい（このような構成であれば、前記開始スイッチを省略することができる。）。

ステップＳ１３において、データ収集装置１８は初期化を実行する（図６の時点ｔ１〜ｔ２）。ここでの初期化には、今回のデータＤの収集処理で送信する各データ要求信号Ｓｒｅｑの種類の特定、データ要求信号Ｓｒｅｑの送信間隔Ｉ１の演算の実行及びバス使用率Ｒｂｕｓの検出の初期化が含まれる。各データ要求信号Ｓｒｅｑの種類の特定は、図３のステップＳ３で本体１６において設定され、ステップＳ５でデータ収集装置１８に送信された内容に基づいて要求信号特定機能７８が行う。送信間隔Ｉ１の演算方法については後述する。

ステップＳ１４において、データ収集装置１８（バス使用率検出機能８６）は、バス使用率Ｒｂｕｓの検出を開始する（図６の時点ｔ２）。バス使用率Ｒｂｕｓは、データ収集装置１８の電源がオフにされるまで継続される。バス使用率Ｒｂｕｓの検出方法については後述する。

ステップＳ１５において、データ収集装置１８（データ収集機能７２）は、ＩＧＳＷ２８がオンであるか否かを判定する。ＩＧＳＷ２８がオフである場合（Ｓ１５：ＮＯ）、ステップＳ１５を繰り返す。但し、図５で示していないが、データ収集装置１８の電源がオフにされた場合、データ収集装置１８は、今回の処理を終了する。ＩＧＳＷ２８がオンである場合（Ｓ１５：ＹＥＳ、図６の時点ｔ３）、各ＥＣＵ２０間での通信が開始され（図６の「ＥＣＵ間の通信」参照）、ステップＳ１６において、データ収集装置１８（要求許否判定機能８８）は、データ要求信号Ｓｒｅｑの送信の許否（すなわち、データＤの要求の許否）を判定する。具体的には、バス使用率検出機能８６により検出したバス使用率Ｒｂｕｓが、当該許否を判定するための閾値（以下「データ要求実行判定閾値ＴＨ＿Ｒｂｕｓ１」又は「第１閾値ＴＨ＿Ｒｂｕｓ１」という。）以下であるか否かを判定する。

データ要求信号Ｓｒｅｑの送信を許可する場合（Ｓ１６：ＹＥＳ）、ステップＳ１７において、データ収集装置１８（要求信号送信機能９０）は、必要な運転パラメータデータＤを要求するためにデータ要求信号Ｓｒｅｑを送信する（図６の時点ｔ４等）（詳細は後述する。）。これに対応して、対象ＥＣＵ２０ｔａｒは、運転パラメータデータＤを送信する。ステップＳ１８において、データ収集装置１８（データ受信・記憶機能８２）は、運転パラメータデータＤを受信する。

ステップＳ１９において、データ収集装置１８（データ収集機能７２）は、データ収集装置１８の電源が作業者によりオフにされたか否かを判定する。電源がオフにされていない場合（Ｓ１９：ＮＯ）、ステップＳ１５に戻る。電源がオフにされた場合（Ｓ１９：ＹＥＳ）、データ収集装置１８はデータＤの収集処理を終了し、ステップＳ２４に進む。

ステップＳ１６に戻り、データ要求信号Ｓｒｅｑの送信を許可しない場合（Ｓ１６：ＮＯ）、ステップＳ２０において、データ収集装置１８は、データ要求信号Ｓｒｅｑの送信を中止する（図６の時点ｔ５）。

続くステップＳ２１において、データ収集装置１８（要求許否判定機能８８）は、データ要求信号Ｓｒｅｑの送信（データＤの要求）を再開するか否かを判定する。具体的には、バス使用率検出機能８６により検出したバス使用率Ｒｂｕｓが、送信の再開を判定するための閾値（以下「データ要求再開判定閾値ＴＨ＿Ｒｂｕｓ２」又は「第２閾値ＴＨ＿Ｒｂｕｓ２」という。）以下であるか否かを判定する。

データ要求信号Ｓｒｅｑの送信を再開する場合（Ｓ２１：ＹＥＳ、図６の時点ｔ６）、ステップＳ１７に進み、データ収集装置１８（要求信号送信機能９０）は、データ要求信号Ｓｒｅｑの送信を再開する（図６の時点ｔ７）。この場合、送信を中止した直後に送信するはずであったデータ要求信号Ｓｒｅｑから送信を開始する。

データ要求信号Ｓｒｅｑの送信を再開しない場合（Ｓ２１：ＮＯ）、ステップＳ２２において、データ収集装置１８（データ収集機能７２）は、データ収集装置１８の電源が作業者によりオフにされたか否かを判定する。電源がオフにされていない場合（Ｓ２２：ＮＯ）、ステップＳ２３に進む。電源がオフにされた場合（Ｓ２２：ＹＥＳ）、データ収集装置１８はデータＤの収集処理を終了し、ステップＳ２４に進む。

ステップＳ２３において、データ収集装置１８（データ収集機能７２）は、ＩＧＳＷ２８がオフにされたか否かを判定する。ＩＧＳＷ２８がオフにされていない場合（Ｓ２３：ＮＯ）、ステップＳ２１に戻り、ＩＧＳＷ２８がオフにされた場合（Ｓ２３：ＹＥＳ）、ステップＳ１５に戻る。

なお、ステップＳ２１を繰り返す場合、データ収集装置１８（データ収集機能７２）は、その周期を、送信間隔Ｉ１と等しい間隔にする。そして、バス使用率Ｒｂｕｓが第２閾値ＴＨ＿Ｒｂｕｓ２以下となったとき（Ｓ２１：ＹＥＳ）、データ収集装置１８（データ収集機能７２）は、送信間隔Ｉ１でのデータ要求信号Ｓｒｅｑの送信を再開する。

ステップＳ１９：ＹＥＳ又はＳ２２：ＹＥＳの場合、ステップＳ２４において、作業者は、データ収集装置１８を車両１２から取り外し、データＤの収集を終了する。なお、上記のように、車両１２に接続した時点でデータ収集装置１８を自動的にオンさせる構成であれば、データ収集装置１８を車両１２から取り外した時点でデータ収集装置１８を自動的にオフさせてもよい。換言すると、ステップＳ１９、Ｓ２２における電源オフは、データ収集装置１８を車両１２から取り外すことと同義とすることが可能である。

（３−２−２．データ要求信号Ｓｒｅｑの送信間隔Ｉ１の算出）
次に、データ要求信号Ｓｒｅｑの送信間隔Ｉ１の算出について説明する。

（３−２−２−１．前提事項）
図３のステップＳ３、Ｓ５に関連して説明したように、本実施形態では、データ収集装置１８によるデータ収集条件を設定する。当該データ収集条件の中には、対象ＥＣＵ２０ｔａｒに対して要求する運転パラメータデータＤの設定が含まれる。このため、収集すべきデータＤの項目数（以下「項目数Ｎｉ」）が特定される。

また、本実施形態では、収集すべき全ての項目について１つのデータＤを収集する周期（個別データ取得周期Ｃｃｏｌ）（図４）を設定する。前述の連続的データ取得時間Ｔｃｏｎｔは、データＤの収集を一時的に開始してから中断するまでの長さ（収集すべき全ての項目についてそれぞれ複数個のデータＤを取得する長さ）を示す。これに対し、個別データ取得周期Ｃｃｏｌは、収集すべき全ての項目についてそれぞれ１つのデータＤを取得する長さ（例えば、数十ミリ秒〜数秒のいずれか）を示す。そして、連続的データ取得時間Ｔｃｏｎｔには、複数の個別データ取得周期Ｃｃｏｌが含まれる（図４参照）。さらに、全ての連続的データ取得時間Ｔｃｏｎｔを含むものが、データ収集総時間Ｔｔｏｔａｌとなる。

（３−２−２−２．送信間隔Ｉ１の算出の詳細）
本実施形態では、通信バス２２における混雑を避けるように（バス使用率Ｒｂｕｓを低く抑えるように）、項目数Ｎｉ（収集すべき対象データの項目数）に基づいてデータ要求信号Ｓｒｅｑの送信間隔Ｉ１それぞれを均等な値として設定する。すなわち、個別データ取得周期Ｃｃｏｌを項目数Ｎｉで割ったものを送信間隔Ｉとする（Ｉ１＝Ｃｃｏｌ／Ｎｉ）。

送信間隔Ｉ１を上記のように設定することから、データ要求信号Ｓｒｅｑは均等な間隔で出力されることとなる（図６参照）。

（３−２−３．バス使用率Ｒｂｕｓの算出）
次に、バス使用率Ｒｂｕｓの算出について説明する。

図７は、バス使用率Ｒｂｕｓを算出するためのデータ収集装置１８の演算部５２の構成を示す図である。上記のように、データ収集装置１８の演算部５２は、ＣＰＵ６０及びＰＬＤ６２を有する。

図７に示すように、ＰＬＤ６２は、シリアル／パラレル変換部１００、デコーダ１０２、演算周期カウンタ１０４、トラフィックカウンタ１０６、更新周期カウンタ１０８、データ数カウンタ１１０及びレジスタ１１２を有する。ＣＰＵ６０は、バス使用率算出部１１４を有する。

シリアル／パラレル変換部１００は、通信バス２２を介して車両１２の各ＥＣＵ２０から供給される各種信号（シリアル信号であるネットワーク信号Ｓｎｅｔ）をシリアル／パラレル変換してパラレル信号（例えば、１０ビット）として出力する。

デコーダ１０２は、シリアル／パラレル変換部１００からのネットワーク信号Ｓｎｅｔ（パラレル信号）をデコードしてトラフィックカウンタ１０６に出力する。演算周期カウンタ１０４は、ＣＰＵ６０からのクロック信号Ｓｃｌｋをカウントしてトラフィックカウンタ１０６及び更新周期カウンタ１０８に演算周期（以下「演算周期Ｃｃ」という。）を知らせる。演算周期Ｃｃは、トラフィックカウンタ１０６及び更新周期カウンタ１０８における演算の周期を示す。

トラフィックカウンタ１０６は、デコーダ１０２でデコードされたネットワーク信号Ｓｎｅｔ中における所定のデータ（バス使用率Ｒｂｕｓの算出に用いるもの）の有無を演算周期Ｃｃ毎に判定し、当該所定のデータを検出する度にデータ数カウンタ１１０に出力する。

更新周期カウンタ１０８は、データ数カウンタ１１０に対して出力タイミングＴｏｕｔを通知する。具体的には、更新周期カウンタ１０８には、レジスタ１１２を介してＣＰＵ６０から今回の処理で用いる前記送信間隔Ｉ１が通知される。そして、更新周期カウンタ１０８は、演算周期カウンタ１０４からの演算周期Ｃｃに基づいて送信間隔Ｉ１が経過したことを特定してデータ数カウンタ１１０に出力タイミングＴｏｕｔとして出力する。

データ数カウンタ１１０は、トラフィックカウンタ１０６がデータを検出する毎にカウント値を増加させ、更新周期カウンタ１０８から出力タイミングＴｏｕｔを受信した時点でのカウント値（以下「周期毎データ数Ｎｄａｔａ」又は「データ数Ｎｄａｔａ」という。）をレジスタ１１２に記録すると共に、カウント値をリセットする。上記のように、出力タイミングＴｏｕｔは、送信間隔Ｉ１に基づいて設定される。このため、データ数Ｎｄａｔａは、送信間隔Ｉ１毎の値となる。

レジスタ１１２は、ＣＰＵ６０から更新周期カウンタ１０８への送信間隔Ｉ１と、データ数カウンタ１１０からのデータ数Ｎｄａｔａを一時的に記録する。

ＣＰＵ６０のバス使用率算出部１１４は、レジスタ１１２からデータ数Ｎｄａｔａを読み出し、次の式（１）を用いてバス使用率Ｒｂｕｓを算出する。
Ｒｂｕｓ＝Ｎｄａｔａ×（Ｉ１／Ｒｂｒｔ）×１００ ・・・（１）

上記式（１）において、Ｎｄａｔａは、データ数カウンタ１１０が検出した周期毎データ数である。Ｉ１は、直接的には、データ要求信号Ｓｒｅｑの送信間隔であるが、上記のようにデータ数Ｎｄａｔａの更新周期でもある。Ｒｂｒｔは、図３のステップＳ３で本体１６において設定し、ステップＳ５でデータ収集装置１８に送信した車内ネットワーク２４のボーレートである。

上記式（１）では、データ数Ｎｄａｔａの更新周期として送信間隔Ｉ１を用いる。このため、バス使用率Ｒｂｕｓは、送信間隔Ｉ１毎の値を示すこととなる。

（３−３．運転パラメータデータＤの収集後の作業及び処理）
図８は、運転パラメータデータＤの収集後の作業者の作業及びデータ収集装置１８の処理の一例を示すフローチャートである。ステップＳ３１において、作業者（テクニシャン等）は、データ収集装置１８のデータリンクケーブル５８のデータリンクコネクタ６４を診断機本体１６のデータリンクコネクタ３８に接続する。

ステップＳ３２において、作業者は、診断機本体１６の入出力部３０（マウス、キーボード等）を操作して、運転パラメータデータＤの取得に用いる診断ソフトウェアを起動する。これに伴い、診断機本体１６は、データＤの取得に関する表示画面（図示せず）を表示部３６に表示する。ステップＳ３１、Ｓ３２の順番は逆であってもよい。

ステップＳ３３において、作業者は、表示画面を介しての入力により診断機本体１６とデータ収集装置１８との間での通信を確立することを要求する。当該要求を受けた本体１６（データ収集装置通信機能４２）は、データ収集装置１８との間で通信を確立する。

ステップＳ３４において、作業者は、表示画面を介しての入力により診断機本体１６に対し、収集した運転パラメータデータＤをデータ収集装置１８から取得することを要求する。当該要求を受けた本体１６（収集データ読出し機能４８）は、データ収集装置１８に対し、収集した運転パラメータデータＤを送信することを要求する。当該要求を受けたデータ収集装置１８（収集データ送信機能７６）は、本体１６に対し、収集した運転パラメータデータＤを送信する。データ収集装置１８からデータＤを受信した本体１６（収集データ読出し機能４８）は、当該データＤを記憶部３４に保存する。

ステップＳ３５において、作業者は、本体１６の表示画面を操作して運転パラメータデータＤの解析を行い、故障原因を特定する。

（３−４．本実施形態と比較例との比較）
図９は、比較例に係る構成及び制御を用いた場合のバス使用率Ｒｂｕｓとネットワークトラフィック（信号又はデータのやり取り）の一例を示す図である。図１０は、本実施形態に係る構成及び制御を用いた場合のバス使用率Ｒｂｕｓとネットワークトラフィックの一例を示す図である。

図９の比較例に係るデータ収集装置（図示せず）及び図１０の本実施形態に係るデータ収集装置１８では、同じ長さの個別データ取得周期Ｃｃｏｌ（例えば、１００ｍｓ）を用いると共に、収集すべきデータＤの項目数（項目数Ｎｉ）はいずれも「５」である。

図９の比較例に係るデータ収集装置では、データ要求信号Ｓｒｅｑの送信と運転パラメータデータＤの受信を随時行う。すなわち、比較例に係るデータ収集装置は、時点ｔ１１で１つ目のデータ要求信号Ｓｒｅｑの送信（図９中、左側の「ＲＥＱ１」が対応する。）を行った後、時点ｔ１２でこれに対応する１つ目のデータＤを受信する（図９中、左側の「Ｄ１」が対応する。）。１つ目のデータＤの受信が終了したことを契機として、比較例に係るデータ収集装置は、時点ｔ１３で２つ目のデータ要求信号Ｓｒｅｑの送信（図９中、左側の「ＲＥＱ２」が対応する。）を行った後、時点ｔ１４でこれに対応する２つ目のデータＤを受信する（図９中、左側の「Ｄ２」が対応する。）。３つ目以降のデータ要求信号Ｓｒｅｑの送信及び３つ目以降のデータＤの受信も同様に、データＤを受信したら次のデータ要求信号Ｓｒｅｑを送信する。

また、比較例に係るデータ収集装置では、本実施形態と同様、バス使用率Ｒｂｕｓが第１閾値ＴＨ＿Ｒｂｕｓ１を上回ると、データ要求信号Ｓｒｅｑの送信を中止し、その後、バス使用率Ｒｂｕｓが第２閾値ＴＨ＿Ｒｂｕｓ２以下となると、データ要求信号Ｓｒｅｑの送信を再開する（図５参照）。

図９の例では、３つ目のデータ要求信号Ｓｒｅｑを送信中の時点ｔ１６において、バス使用率Ｒｂｕｓが第１閾値ＴＨ＿Ｒｂｕｓ１を上回る。このため、比較例に係るデータ収集装置では、４つ目以降のデータ要求信号Ｓｒｅｑの送信を中止する。なお、ここでバス使用率Ｒｂｕｓが第１閾値ＴＨ＿Ｒｂｕｓ１を上回ったのは、複数のデータ要求信号ＳｒｅｑとデータＤが集中して通信バス２２を通過したことが一因と考えられる（図９の例では、項目数Ｎｉが比較的小さいが、項目数Ｎｉが大きくなると集中の影響はさらに大きくなる。）。

時点ｔ１７において、バス使用率Ｒｂｕｓが第２閾値ＴＨ＿Ｒｂｕｓ２以下となると、比較例に係るデータ収集装置では、データ要求信号Ｓｒｅｑの送信及びデータＤの受信を再開する。

時点ｔ１８において再びバス使用率Ｒｂｕｓが第１閾値ＴＨＲｂｕｓ１を上回る。このため、比較例に係るデータ収集装置では、その後のデータ要求信号Ｓｒｅｑの送信を中止する。

時点ｔ１９において、１番目の個別データ取得周期Ｃｃｏｌ（図９中の「Ｃｃｏｌ１」）が終了するが、バス使用率Ｒｂｕｓが第２閾値ＴＨ＿Ｒｂｕｓ２を上回ったままであるため、２番目の個別データ取得周期Ｃｃｏｌ（図９中の「Ｃｃｏｌ２」）に入っても１つ目のデータ要求信号Ｓｒｅｑの送信をすることができない。

時点ｔ２０において、バス使用率Ｒｂｕｓが第２閾値ＴＨ＿Ｒｂｕｓ２以下となると、比較例に係るデータ収集装置では、データ要求信号Ｓｒｅｑの送信（図９中、右側の「ＲＥＱ１」が対応する。）及びデータＤの受信（図９中、右側の「Ｄ１」が対応する。）を再開する。従って、時点ｔ１９と時点ｔ２０の間のデータ要求信号Ｓｒｅｑの送信遅れが発生する。

一方、図１０の本実施形態に係るデータ収集装置１８では、項目数Ｎｉに基づいてデータ要求信号Ｓｒｅｑの送信間隔Ｉ１それぞれを均等な値として設定する。すなわち、個別データ取得周期Ｃｃｏｌを項目数Ｎｉ（＝５）で割った値（例えば、個別データ取得周期Ｃｃｏｌが１００ｍｓである場合、２０ｍｓ）を送信間隔Ｉ１として設定する。

このため、本実施形態のデータ収集装置１８では、バス使用率Ｒｂｕｓの急激な上昇を回避することが可能となり、１つ目の個別データ取得周期Ｃｃｏｌ１全体（図１０の時点ｔ３１〜ｔ３２）において、バス使用率Ｒｂｕｓが第１閾値ＴＨ＿Ｒｂｕｓ１以下となる。従って、データ要求信号Ｓｒｅｑの送信を中止することなく、次の個別データ取得周期Ｃｃｏｌ２に移ることができる。よって、図９の比較例のようなデータ要求信号Ｓｒｅｑの送信遅れは発生しない。

［４．本実施形態の効果］
以上のように、本実施形態によれば、車内ネットワーク２４のバス使用率Ｒｂｕｓが第１閾値ＴＨ＿Ｒｂｕｓ１を下回ると判定したとき（図５のＳ１６：ＹＥＳ）、対象ＥＣＵ２０ｔａｒに対してデータ要求信号Ｓｒｅｑを送信する（Ｓ１７）。このため、車両１２の運転時におけるＥＣＵ２０間の通信を制限することなく又はＥＣＵ２０間の通信に対する制限を抑えた状態で、運転パラメータデータＤを収集することが可能となる。従って、車両運転時における車両運転のためのデータ通信の混雑を防止し易くなる。

また、本実施形態によれば、データ要求信号Ｓｒｅｑの項目数Ｎｉに基づいて設定した均等な送信間隔Ｉ１で各データ要求信号Ｓｒｅｑを送信する（図６及び図１０参照）。このため、データ要求信号Ｓｒｅｑの送信及び運転パラメータデータＤの出力によるバス使用率Ｒｂｕｓの一時的な急増を抑制することが可能となる。従って、バス使用率Ｒｂｕｓの一時的な急増に伴う通信の中断を避けることができ、運転パラメータデータＤの連続性を確保することが容易になる。

本実施形態において、データ収集装置１８（バス使用率検出機能８６）は、データ数カウンタ１１０のカウント値を、送信間隔Ｉ１と同じ間隔で検出した周期毎データ数Ｎｄａｔａ（車内ネットワーク２４における通信量）を用いてバス使用率Ｒｂｕｓを算出する。また、データ収集装置１８（データ要求機能８０）は、バス使用率Ｒｂｕｓが第１閾値ＴＨ＿Ｒｂｕｓ１を上回ったと判定したとき、データ要求信号Ｓｒｅｑの送信を中止し、バス使用率Ｒｂｕｓが第２閾値ＴＨ＿Ｒｂｕｓ２を下回ったか否かを、送信間隔Ｉ１と等しい間隔で判定し、バス使用率Ｒｂｕｓが第２閾値ＴＨ＿Ｒｂｕｓ２を下回ったとき、送信間隔Ｉ１でのデータ要求信号Ｓｒｅｑの送信を再開する。

これにより、バス使用率Ｒｂｕｓの増加に伴ってデータ要求信号Ｓｒｅｑの送信を中止する前後でデータ要求信号Ｓｒｅｑの送信周期（送信間隔Ｉ１）を変化させることがない。従って、データ要求信号Ｓｒｅｑの送信中止に伴って運転パラメータデータＤが欠落した場合であっても、欠落したデータＤの補完が容易になる。ここにいうデータＤの補完とは、例えば、欠落したデータＤの前後の内容のデータＤ（但し、項目が同じもの）から欠落したデータＤの内容を推定する処理（例えば、データＤが数値であれば、前後の値による平均化）、データＤが欠落している時間については画面に表示せず、その前後のデータＤ（但し、項目が同じもの）を連続的に画面に表示すること等の処理を示す。

本実施形態において、診断機本体１６（収集条件設定機能４０）は、故障症状毎に運転パラメータデータＤのデータ要求信号Ｓｒｅｑを一括して選択して設定することができる。これにより、送信すべきデータ要求信号Ｓｒｅｑの選定及び送信間隔Ｉ１を簡単に設定することが可能となる。

Ｂ．変形例
なお、この発明は、上記実施形態に限らず、この明細書の記載内容に基づき、種々の構成を採り得ることはもちろんである。例えば、以下に示す構成を採ることができる。

［１．適用対象］
上記実施形態では、外部診断機１４を車両１２に用いたが、これに限らず、例えば、複数の電子制御装置が接続されたローカルネットワークを備えるスタンドアロン型の機器（例えば、船舶、航空機等の移動体、各種の製造装置）に用いることもできる。

［２．車両１２］
上記実施形態では、車内ネットワーク２４としてＣＡＮを用いたが、これに限らず、ＬＩＮ、ＦｌｅｘＲａｙ等のネットワークであってもよい。

［３．外部診断機１４］
（３−１．診断目的）
上記実施形態では、車両１２の故障診断を行うものであったが、データ収集装置１８により運転パラメータデータＤを収集する観点からずれば、その他の車両診断を行うものであってもよい。例えば、外部診断機１４は、各車載機器の劣化状態又は動作状態を確認する健康診断や、運転者の運転技能（例えば、アクセル操作、ブレーキ操作）を診断する運転技能診断を行うものであってもよい。このため、運転パラメータデータＤも故障診断を目的するデータに限らず、その他の診断で用いるデータであってもよい。

（３−２．診断機本体１６）
上記実施形態では、診断機本体１６は、例えば、市販のノート型パーソナルコンピュータ、タブレット型コンピュータ又はスマートフォンから構成し、単一のものとしたが、これに限らない。例えば、本体１６は、本体としてのパーソナルコンピュータと、データ収集装置１８とのインタフェースとしての子機（中継器）とから構成してもよい。

上記実施形態では、診断機本体１６で用いる診断ソフトウェアは、記憶部３４に予め記録されていたが、これに限らず、外部（例えば、公衆ネットワークを介して通信可能な外部サーバ）からダウンロードしたもの、又はダウンロードを伴わないいわゆるＡＳＰ（Application Service Provider）型で実行するものであってもよい。

（３−３．データ収集装置１８）
（３−３−１．構成）
上記実施形態では、データ収集装置１８は、診断機本体１６とは別体のものとして構成したが、本体１６内にデータ収集装置１８の機能を持たせることもできる。

上記実施形態では、データ収集装置１８は、車両１２の外部から車内ネットワーク２４に接続するもの（いわゆる外付け型）であったが、これに限らず、車両１２に備え付けのものであってもよい。

上記実施形態では、診断機本体１６とデータ収集装置１８との間の通信及び車両１２とデータ収集装置１８との間の通信はいずれも有線通信であったが、一部に無線通信を介することも可能である。例えば、診断機本体１６とデータ収集装置１８との間を無線通信で行うこともできる。或いは、車内ネットワーク２４に接続された無線通信機（図示せず）を車両１２に設けておき、データ収集装置１８と当該無線通信機との間で無線通信を行うと共に、当該無線通信機を介してデータ収集装置１８が各ＥＣＵ２０と通信することも可能である。

（３−３−２．送信間隔Ｉ１）
上記実施形態では、データ要求信号Ｓｒｅｑの送信間隔Ｉ１を、個別データ収集周期Ｃｃｏｌを項目数Ｎｉ（すなわち、個別データ収集周期Ｃｃｏｌに割り当てられるデータＤの個数）で割った値とした。しかしながら、バス使用率Ｒｂｕｓの急増を防ぐ（又は通信バス２２のトラフィックを均等化する）観点に着目したものであれば、これに限らない。例えば、連続的データ収集時間Ｔｃｏｎｔ（図４参照）を、連続的データ取得時間Ｔｃｏｎｔで収集するデータＤの個数で割ってもよい。

或いは、バス使用率Ｒｂｕｓに応じて送信間隔Ｉ１を可変とすることも可能である。例えば、バス使用率Ｒｂｕｓが上昇してきたとき（例えば、所定の閾値を上回ったとき）、送信間隔Ｉ１を長くし、バス使用率Ｒｂｕｓが減少してきたとき（例えば、所定の閾値を下回ったとき）、送信間隔Ｉ１を短くしてもよい。

（３−３−３．バス使用率Ｒｂｕｓの検出）
上記実施形態では、バス使用率Ｒｂｕｓを算出する間隔を、送信間隔Ｉ１と等しくしたが、これに限らず、送信間隔Ｉ１よりも長い間隔又は短い間隔とすることも可能である。

上記実施形態では、バス使用率Ｒｂｕｓの検出に用いる周期毎データ数Ｎｄａｔａ（車内ネットワーク２４の通信量）は、データ数カウンタ１１０のカウント値を、送信間隔Ｉ１と同じ間隔で検出したものとした。しかしながら、周期毎データ数Ｎｄａｔａをそれ以外の間隔で検出してもよい。例えば、送信間隔Ｉ１よりも短い間隔で周期毎データ数Ｎｄａｔａを検出することもできる。この場合、上記式（１）における送信間隔Ｉ１の代わりに、当該間隔（送信間隔Ｉ１よりも短い間隔）を用いることとなる。

（３−３−４．データ要求信号Ｓｒｅｑの中止・再開）
上記実施形態では、バス使用率Ｒｂｕｓの第２閾値ＴＨ＿Ｒｂｕｓ２は、第１閾値ＴＨ＿Ｒｂｕｓ１未満の値としたが、同じ値としてもよい。換言すると、第１閾値ＴＨ＿Ｒｂｕｓ１のみを用いて、データ要求信号Ｓｒｅｑの中止及び再開を判定することもできる。

１２…車両 １４…外部診断機
１８…車両データ収集装置 ２０ａ〜２０ｆ…ＥＣＵ
２４…車内ネットワーク ５４…車両データ収集装置の記憶部
７８…要求信号特定機能（選択設定手段）
８４…送信間隔設定機能（送信間隔設定手段）
８６…バス使用率検出機能（バス使用率検出手段）
９０…要求信号送信機能（要求信号送信手段）
Ｃｃｏｌ…個別データ取得周期（所定周期）
Ｄ…運転パラメータデータ Ｉ１…データ要求信号送信間隔（送信間隔）
Ｎｉ…項目数（データ要求信号の個数） Ｒｂｕｓ…バス使用率
Ｓｒｅｑ…データ要求信号 ＴＨ＿Ｒｂｕｓ１…第１閾値
ＴＨ＿Ｒｂｕｓ２…第２閾値

Claims (5)

1. 車両における複数の電子制御装置（以下「ＥＣＵ」という。）が接続された車内ネットワークに外部から着脱自在に接続された状態において、前記車両の運転時における各部の動作状態を示す運転パラメータデータを要求するデータ要求信号を前記複数のＥＣＵの少なくとも１つに対して複数回送信し、前記データ要求信号に対応する前記運転パラメータデータを受信して記憶部に記憶する外付け型の車両データ収集装置であって、
   前記車内ネットワークに接続されて前記車内ネットワークのバス使用率を検出するバス使用率検出手段と、
   前記複数のＥＣＵの少なくとも１つに対して送信する複数の前記データ要求信号を選択して設定する選択設定手段と、
   前記選択設定手段で設定した前記データ要求信号の個数に基づいて各データ要求信号について所定周期内での均等な送信間隔を設定する送信間隔設定手段と、
   前記バス使用率が第１閾値を下回ると判定したとき、前記均等な送信間隔で各データ要求信号を送信する要求信号送信手段と
   を有することを特徴とする車両データ収集装置。
2. 請求項１記載の車両データ収集装置において、
   前記バス使用率検出手段は、前記車内ネットワークの通信量を、前記均等な送信間隔と同じ間隔で検出して前記バス使用率を算出し、
   前記要求信号送信手段は、
   前記バス使用率が前記第１閾値を上回ったと判定したとき、前記データ要求信号の送信を中止し、
   前記バス使用率が前記第１閾値以下に設定された第２閾値を下回ったか否かを、前記均等な送信間隔で判定し、
   前記バス使用率が前記第２閾値を下回ったとき、前記均等な送信間隔での前記データ要求信号の送信を再開する
   ことを特徴とする車両データ収集装置。
3. 請求項１又は２記載の車両データ収集装置において、
   前記選択設定手段は、故障症状毎に運転パラメータデータのデータ要求信号を一括して選択して設定する
   ことを特徴とする車両データ収集装置。
4. 車両における複数の電子制御装置（以下「ＥＣＵ」という。）が接続された車内ネットワークに外部から車両データ収集装置を接続した状態において、前記車両の運転時における各部の動作状態を示す運転パラメータデータを要求するデータ要求信号を前記車両データ収集装置から前記複数のＥＣＵの少なくとも１つに対して複数回送信し、前記データ要求信号に対応する前記運転パラメータデータを前記車両データ収集装置で受信して記憶部に記憶する車両データ収集方法であって、
   前記車内ネットワークに接続した前記車両データ収集装置により前記車内ネットワークのバス使用率を検出するバス使用率検出ステップと、
   前記車両データ収集装置から前記複数のＥＣＵの少なくとも１つに対して送信する複数の前記データ要求信号を選択して設定する選択設定ステップと、
   前記選択設定ステップで設定した前記データ要求信号の個数に基づいて各データ要求信号について所定周期内での均等な送信間隔を設定する送信間隔設定ステップと、
   前記バス使用率が第１閾値を下回ると判定したとき、前記均等な送信間隔で各データ要求信号を送信する要求信号送信ステップと
   を有することを特徴とする車両データ収集方法。
5. 複数の電子制御装置（以下「ＥＣＵ」という。）が接続された車内ネットワークを有する車両について前記車両の外部において実行する故障診断、健康診断及び運転技能診断の少なくとも１つである車両診断に用いる車内データを収集する車両データ収集方法であって、
   外部診断機において対象となる診断項目を設定する項目設定ステップと、
   前記診断項目に対応する複数項目の前記車内データを前記複数のＥＣＵのいずれかに対して要求する複数項目のデータ要求信号を特定する要求信号特定ステップと、
   前記外部診断機から又は前記外部診断機の指令に応じて動作する車載中継機器から前記複数のＥＣＵの少なくとも１つに対して前記複数項目のデータ要求信号を複数回送信するデータ要求ステップと、
   前記データ要求信号を受信したＥＣＵのそれぞれから前記外部診断機に又は前記車載中継機器に対して前記車内データを複数回送信する車内データ送信ステップと、
   前記ＥＣＵから直接受信した前記車内データ又は前記車載中継機器を介して受信した前記車内データを前記外部診断機において記憶する車内データ記憶ステップと
   を備え、
   前記データ要求ステップは、
   前記診断項目に応じて特定される前記複数項目の前記データ要求信号の送信間隔を設定する送信間隔設定ステップと、
   前記車内ネットワークのバス使用率を検出するバス使用率検出ステップと、
   前記バス使用率が第１閾値を下回るか否かを判定するバス使用状況判定ステップと、
   前記バス使用率が前記第１閾値を下回ると判定したとき、前記送信間隔で各データ要求信号を送信する要求信号送信ステップと
   を有し、
   前記送信間隔設定ステップでは、前記複数項目の前記車内データのそれぞれを１つ取得するために設定された周期であるデータ収集周期内において、前記複数項目のデータ要求信号を均等な間隔で送信するように前記送信間隔を設定する
   ことを特徴とする車両データ収集方法。

Images