JP2020172200A - 車両検査装置 - Google Patents

Abstract

【課題】複数の電子制御装置が搭載されている車両に関して、従来のダイアグ通信による問題点を回避できるとともに、複数の電子制御装置から得られるデータの取得タイミングをできる限り揃えることができる技術を提供すること。【解決手段】車両検査装置５では、主ＥＣＵ１１は、車両３外の検査ツール７から、複数の副ＥＣＵ１３から得られる各データＡ、Ｂの送信の要求があった場合には、各データＡ、Ｂを含む各定期送信Ａ、Ｂを複数の副ＵＣＵ１３から受信する。そして、各定期送信Ａ、Ｂの受信時刻の差を求め、受信時刻の差が所定値以下の各定期送信Ａ、Ｂに含まれる各データを収集して検査ツール７に送信する。つまり、受信時刻の差が、送信周期が短い定期送信Ａの送信周期以下の範囲における各定期送信Ａ、Ｂを選択し、各定期送信Ａ、Ｂに含まれる各データＡ、Ｂを収集する。【選択図】図７

Description

本開示は、複数の電子制御装置を備えた車両の検査を行うことができる車両検査装置に関する。

従来、車両では、電子制御化の進歩に伴い、エンジンやブレーキ等といった各種の車両構成品が電子部品を介して制御されており、これら電子部品に接続された電子制御装置の数も増加傾向にある。そして、このような電子部品に故障が生じた場合に迅速に対応するために、それぞれの電子制御装置によって、自己の接続先である電子部品の故障有無を診断するための自己故障診断を実行し、その診断結果を保持する構成が知られている。

このような構成の一態様として、全ての自己故障診断結果を、一箇所の電子制御装置に集約する技術が知られている。具体的には、ユーザからの要求、つまり、車両の外部に設けられた車両解析ツール（即ち、検査ツール）からの要求によって、各電子制御装置の診断結果を効率的に出力することを図る車両用故障診断装置が知られている（例えば、特許文献１参照）。

この検査ツールは、自己故障診断結果（例えば、故障コード）に基づいて車両の状態を解析する際に、電子部品などにおける故障箇所を特定することで、車両のメンテナンスに係る効率化を図るツールである。

また、上述した検査ツールには、データモニタ機能やドライブレコーダ機能を有しているものがある。データモニタ機能は、車載の複数の電子制御装置から、一定時間毎にセンサやアクチュエータ等のデータを取得し、検査ツールの画面上にリアルタイムでデータを表示する機能である。ドライブレコーダ機能は、取得したデータの記録を行う機能である。

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

ところで、上述したデータモニタ機能やドライブレコーダ機能で、車両の挙動状態を正確に把握するためには、車両にある挙動を生じさせるためのトリガとなるデータと、その挙動によって生じる結果を示すデータとは、可能な限り同一時刻に取得する必要がある。

なお、このトリガとなるデータ（以下、入力データ）と結果を示すデータ（以下、出力データ）とは、共に電子制御装置から得られるデータ、即ち電子制御装置から出力されるデータである。

しかしながら、車両には、各種のセンサやアクチュエータに接続された複数の電子制御装置が搭載されているので、入力データの取得タイミング（即ち、取得時刻）と出力データの取得タイミングとが大きくずれることがあった。

詳しくは、従来、入力データや出力データを得る場合に、複数の電子制御装置から所定の順番にて順次データを取得するので、その場合には、最初に取得した入力データのタイミングと最後に取得した出力データのタイミングとが大きくずれることがあった。

例えば、５個の電子制御装置がある場合に、各電子制御装置からデータを取得するためにそれぞれ１００ｍｓかかるときには、入力データを最初の電子制御装置から取得し、出力データを最後の電子制御装置から取得すると、入力データの取得から出力データの取得までに４００ｍｓのずれがある。そのため、得られた出力データが入力データに対する応答値として好ましくないことがある。

つまり、入力データの取得タイミングと出力データの取得タイミングが大きくずれる場合には、入力に対する出力の精度が低下し、車両の挙動状態を正確に把握することが難しいことがあった。

ところで、上述した問題の対策として、同一時刻に複数の電子制御装置に対して、機能アドレスを利用したダイアグ通信を行うことが考えられる。なお、ダイアグ通信とは、例えばＩＳＯ規格にて、車載の電子部品等の故障診断に関するデータ（例えば故障診断の結果）を送受信する際に規定されている通信であり、ダイアグとは、周知のダイアグノーシス（即ち、Diagnostics）の略である。

この機能アドレスを使うと、全ての電子制御装置に対して同時刻にデータを要求できるが、機能アドレスだけでは、各電子制御装置から個別のデータを取得することはできない。
これは、検査ツールが電子制御装置からデータを読み出す際は、読み出し対象のデータを、ＤＩＤ（即ち、Data Identifier）と呼ばれるＩＤで指定する必要があるが、機能アドレスでは全電子制御装置が同一のメッセージ（即ち、ＤＩＤ）を受信するため、電子制御装置毎に個別のデータ（即ち、異なるＤＩＤのデータ）を指定できないためである。

この問題の対策として、ＤＩＤを動的に定義するダイアグ通信（即ち、SIDOx2C）を使い、各電子制御装置から読み出したいデータを同一ＤＩＤで定義する方法が考えられる。
しかし、この解決策においては、データの取得対象の全ＥＣＵがSIDOx2Cに対応している必要があり、必ずしも十分ではない。

また、上述した入力データと出力データとのタイミングの問題とは別に、例えば、出力データが複数ある場合に、複数の出力データを取得するタイミングを揃えることが望ましいことがある。

例えばあるトリガ（例えばアクセル開度の変化）が付与された場合に、それに対する例えばエンジン回転数の変化と吸入空気量の変化とのような複数の出力データの関連性を把握したいときには、その複数の出力データの取得するタイミングを揃えたいことがある。

本開示の一つの局面は、複数の電子制御装置が搭載されている車両に関して、従来のダイアグ通信による問題点を回避できるとともに、複数の電子制御装置から得られるデータの取得タイミングをできる限り揃えることができる技術を提供することにある。

＜１＞本開示の一態様は、車両（３）に搭載される複数の電子制御装置（９）を備えた車両検査装置（５）に関するものである。この車両検査装置の複数の電子制御装置は、センサ（５１）及び／又はアクチュエータ（５３）が接続された複数の副電子制御装置（１３）と、複数の副電子制御装置から各データを受信するように構成された主電子制御装置（１１）と、を備えている。

複数の副電子制御装置のそれぞれは、主電子制御装置に対して、センサ及び／又はアクチュエータの動作を示す各データを、定期通信によって周期的に送信する構成を有している。

主電子制御装置は、データ受信部（４１、Ｓ１００）とデータ収集部（４３、Ｓ１１０〜Ｓ１５０）とデータ送信部（４３、Ｓ１６０）とを有している。
データ受信部は、車両検査装置外の検査ツールから、複数の副電子制御装置から出力される各データの送信の要求があった場合には、各データを含む各定期通信を複数の副電子制御装置から受信する。

データ収集部は、データ受信部にて受信された各定期通信の受信時刻の差を求め、受信時刻の差が所定値以下の各定期通信に含まれる各データを収集する。
データ送信部は、データ収集部にて収集された各データを、検査ツールに送信する。

本開示の一態様では、このような構成によって、下記の効果を奏する。
（１）検査ツールからの要求に基づいて、検査ツールに送信する各データの取得タイミング（即ち、取得時刻）のずれを、従来の各電子制御装置から順次取得する方法に比べて、小さくすることができる。

これによって、データの取得時刻の同期性が向上するので、車両挙動をより正確にモニタできるという顕著な効果を奏する。
（２）検査ツールのデータの取得先が、主電子制御装置のみとなるので、データの取得に必要な通信回数が、従来の各電子制御装置から順次取得する方法に比べて少なくなり、車内の各電子制御装置を繋ぐネットワークの通信負荷を低減できる。

つまり、検査ツールは、主電子制御装置に対してデータの要求をするだけで、各副電子制御装置から必要なデータが得られるので、従来に比べて通信負荷が低減するという利点がある。

（３）本開示を実現するためにロジックの追加等が必要な電子制御装置は、主電子制御装置のみとすることができるため、副電子制御装置は従来の構成を採用できる。そのため、車両検査装置を容易に実現することが可能である。

（４）主電子制御装置と副電子制御装置との通信方法として、ダイアグ通信より優先度の高い通信（例えば、制御データの通信）を採用できる。つまり、主電子制御装置は、副電子制御装置からの優先度の高い通信をモニタすることにより、副電子制御装置からのデータを取得できる。

このような場合には、通信バスが高負荷の状況でも、安定してデータを取得して検査ツールに送信することができる。例えば、副電子制御装置から主電子制御装置に送信されるデータに、欠け等が生じ難いという利点がある。

このように、本開示の一態様によれば、従来のダイアグ通信による問題点を回避できるとともに、複数の電子制御装置から得られるデータの取得タイミングをできる限り揃えることができるという顕著な効果を奏する。

また、本開示の一態様は、例えば、１つの副電子制御装置から得られるデータ（例えば、１つのトリガを示すデータ：入力値）を、他の複数の副電子制御装置が参照して出力制御するシステムや、複数の副電子制御装置から得られるデータを１つの副電子制御装置が参照して出力制御するシステムや、複数の副電子制御装置から得られるデータを複数の副電子制御装置が参照して出力制御するシステムに適用できる。

つまり、これらのシステムでは、入力値と出力値（例えば、結果を示すデータ）とをできる限り同じタイミングで取得することが望ましいが、本開示の一態様では、入力値や出力値が複数の場合でも、好適に対応できる。

＜２＞本開示の他の一態様は、車両に搭載される複数の電子制御装置を備えた車両検査装置に関するものである。この車両検査装置の複数の電子制御装置は、センサ及び／又はアクチュエータが接続された複数の副電子制御装置と、複数の副電子制御装置から各データを受信するように構成された主電子制御装置と、を備えている。

複数の副電子制御装置のそれぞれは、主電子制御装置に対して、センサ及び／又はアクチュエータの動作を示す各データを、定期通信によって周期的に送信する構成を有している。

主電子制御装置は、データ受信部とデータ収集部（４３、Ｓ２８０）とデータ送信部とを有している。
データ受信部は、車両検査装置外の検査ツールから、複数の副電子制御装置から出力される各データの送信の要求があった場合には、各データを含む各定期通信を複数の副電子制御装置から受信する。

データ収集部は、データ受信部にて受信された各定期通信のうち、一対の定期通信の受信時刻の差を求め、受信時刻の差が最小となる一対の各定期通信に含まれる各データを収集する。

データ送信部は、データ収集部にて収集された各データを、検査ツールに送信する。
本開示の他の一態様では、このような構成によって、前記一態様と同様な効果を奏する。
なお、この欄及び特許請求の範囲に記載した括弧内の符号は、一つの態様として後述する実施形態に記載の具体的手段との対応関係を示すものであって、本開示の技術的範囲を限定するものではない。

第１実施形態の車両検査システムを示すブロック図。 第１実施形態の主電子制御装置の構成を示すブロック図。 第１実施形態の主電子制御装置の車両側マイコンの構成を示すブロック図。 第１実施形態の検査ツール及びディスプレイの表示の一例を示す説明図。 第１実施形態の検査ツール及びディスプレイの表示の他の例を示す説明図。 第１実施形態の検査ツールと各電子制御装置との間の通信の手順を示すシーケンス図。 第１実施形態の主電子制御装置の処理を示すフローチャート。 第２実施形態の検査ツールと各電子制御装置との間の通信の手順を示すシーケンス図。 第２実施形態の主電子制御装置の処理を示すフローチャート。 第２実施形態の主電子制御装置の処理のうち受信時刻差の計算処理を示すフローチャート。

以下に、本開示の実施形態を、図面を参照しながら説明する。
［１．第１実施形態］
［１−１．全体構成］
まず、本第１実施形態の車両検査装置を備えた全体のシステム（即ち、車両検査システム）について説明する。

図１に示すように、本第１実施形態における車両検査システム１は、車両３に車載された車両検査装置５と、車両検査装置５に電気的に接続される検査ツール７と、を備えている。

車両検査装置５は、複数の電子制御装置（以下、ＥＣＵ）９を備えており、この複数のＥＣＵ９は、１台の主ＥＣＵ１１と、主ＥＣＵ１１以外の複数の副ＥＣＵ１３とを備えている。主ＥＣＵ１１は、いわゆるゲートウェイＥＣＵ（即ち、Ｇ／Ｗ ＥＣＵ）である。なお、主ＥＣＵ１１と副ＥＣＵ１３との共通の構成を説明する際には、単にＥＣＵ９と記載することがある。

主ＥＣＵ１１は、自身と各副ＥＣＵ１３との間のデータの送受信を統括するように構成されている。つまり、主ＥＣＵ１１は、各副ＥＣＵ１３に対してデータの送信が可能であるとともに、各副ＥＣＵ１３から送信されたデータの受信が可能なように構成されている。

また、検査ツール７と主ＥＣＵ１１とは、通信ケーブル１４を介して接続されており、検査ツール７と主ＥＣＵ１１とは、通信ケーブル１４を介して、データの送受信が可能となっている。

［１−２．車両検査装置］
次に、車両検査装置５について、さらに詳しく説明する。
図１に示すように、車両検査装置５は、主ＥＣＵ１１と、複数の副ＥＣＵ１３と、各ＥＣＵ１１、１３間を接続する複数の通信線（即ち、通信バス）１５と、を有する。

なお、複数の副ＥＣＵ１３として、ここでは、第１ＥＣＵ１７、第２ＥＣＵ１９、第３ＥＣＵ２１、第４ＥＣＵ２３を例に挙げるが、特に数に限定はない。また、複数の通信線１５として、第１通信線１５ａ、第２通信線１５ｂを例に挙げるが、特に数に限定はない。

主ＥＣＵ１１は、第１通信線１５ａを介して、第１ＥＣＵ１７及び第３ＥＣＵ２１に接続されるとともに、第２通信線１５ｂを介して、第２ＥＣＵ１９及び第４ＥＣＵ２３に接続されている。

従って、第１ＥＣＵ１７及び第３ＥＣＵ２１から出力されるデータ、例えば、第１ＥＣＵ１７から出力されるデータＡは、第１通信線１５ａを介して、主ＥＣＵ１１などに送信することができる。同様に、第２ＥＣＵ１９及び第４ＥＣＵ２３から出力されるデータ（例えば、データＢ、データＣ）は、第２通信線１５ｂを介して、主ＥＣＵ１１などに送信することができる。

なお、各ＥＣＵ９は、各通信線１５ａ、１５ｂを介して、ＣＡＮ（登録商標）といった通信プロトコルに従って互いに通信可能である。ＣＡＮは、Controller Area Networkの略である。

各ＥＣＵ９は、車両３を制御する機能や、オンボードダイアグノーシス（即ち、ＯＢＤ）の機能（以下、ＯＢＤ機能）を有する。ＯＢＤ機能とは、周知のように、車両３の走行中等に、車載の各種のセンサやアクチュエータなどに何らかの異常が発生したことを検出する故障診断（即ち、自己故障診断）の機能である。

＜主ＥＣＵ＞
図２に示すように、主ＥＣＵ１１は、マイクロコンピュータ（以下、車両側マイコン）２５と、外部通信部２７とを備えている。

車両側マイコン２５は、ＣＰＵ２９、ＲＯＭ３１、ＲＡＭ３３、フラッシュメモリ３５、Ｉ／Ｏ３７等を備えた周知のマイクロコンピュータである。外部通信部２７は、検査ツール７との通信を行う回路である。

車両側マイコン２５は、ＣＰＵ２９がプログラムを実行することで、例えば、車両制御に関する処理、ＯＢＤ機能に関する処理、副ＥＣＵ１３との通信に関する処理、後述する各種の処理などを行う。

車両側マイコン２５は、ＣＰＵ２９がプログラムを実行することで実現される機能的な構成として、図３に示すように、データ受信部４１とデータ収集部４３とデータ送信部４５とを有する。

データ受信部４１は、車両３外の検査ツール７から主ＥＣＵ１１に対して、複数の副ＥＵＣ１３から出力される各データの送信の要求があった場合には、各データを含む各定期通信（即ち、定期送信）を複数の副ＥＣＵ１３から受信する。

ここで、検査ツール７から主ＥＣＵ１１に対して要求されるデータとは、故障診断の結果や故障診断等の車両の検査に必要なデータであるダイアグデータを示しており、このダイアグデータの要求は、ダイアグ通信によって行われる。

なお、ダイアグ通信の内容や通信方法等については、周知のＩＳＯ（例えば、ＩＳＯ １４２２９）により規定されている。また、定期送信とは、後述するように、所定の周期（即ち、送信周期）にて送信が実施される定期的な送信であり、送信周期は、副ＥＣＵ１３によって異なる場合と同じ場合とがある。

データ収集部４３は、データ受信部４１にて受信された各定期送信の受信時刻の差を求め、受信時刻の差が所定値以下の各定期送信に含まれる各データを収集する。
ここで、各定期送信の受信時刻の差とは、後述するように、車両３の挙動を変化させる原因であるトリガを示す起因データの受信時刻と、トリガによって生じる車両３の挙動の変化を示す結果データの受信時刻と、の差を示している。また、所定値以下とは、送信周期の短い定期送信の送信周期以下を示している。

データ送信部４５は、データ収集部４３にて収集された各データを、検査ツール７に送信する。つまり、データ送信部４５は、後述するように、外部通信部２７を介して、前記受信時刻の差が所定値以下の起因データと結果データとを、検査ツール７に送信する。

＜副ＥＣＵ＞
副ＥＣＵ１３は、基本的に、主ＥＣＵ１１とほぼ同様な構成を有する。つまり、副ＥＣＵ１３は、図示しないが、主ＥＣＵ１１と同様に、ＣＰＵ２９、ＲＯＭ３１、ＲＡＭ３３、フラッシュメモリ３５、Ｉ／Ｏ３７等を備えた車両側マイコン２５などを有する。

副ＥＣＵ１３には、図１に示すように、各副ＥＣＵ１３で行われる制御などに必要なセンサ５１やアクチュエータ５３が接続されている。ここで、センサ５１とは、車両３や周囲の環境の状態等を検出する装置であり、アクチュエータ５３は、車両３の挙動を変化させる装置である。

なお、副ＥＣＵ１３には、センサ５１及びアクチュエータ５３の両方が接続されたものや、センサ５１又はアクチュエータ５３の一方のみが接続されたものがある。また、接続されたセンサ５１やアクチュエータ５３については、単数の場合も複数の場合もある。

例えば、副ＥＣＵ１３がエンジン（図示せず）の動作を制御するエンジンＥＣＵである場合には、副ＥＣＵ１３には、例えば、車速センサ、スロットル開度センサ、アクセルペダル開度センサ等のセンサ５１が接続され、インジェクタ、イグナイタ等のアクチュエータ５３が接続されている。

副ＥＣＵ１３は、図１に示すように、自身に接続されているセンサ５１やアクチュエータ５３に関する情報、例えばセンサによって得られた情報を、通信線１５にて接続された他のＥＣＵ９に対して、定期的に送信するように構成されている。

つまり、例えば車両３の走行等の動作を制御するためには、各副ＥＣＵ１３は自身に接続されたセンサ５１等からの情報だけでなく、他の副ＥＣＵ１３に接続されたセンサ５１からの情報を必要とすることが多いので、各副ＥＣＵ１３は、車両３の制御に必要な情報（即ち、制御データ）を、それぞれ所定の周期にて定期的に送信するように構成されている。

この制御データは、ダイアグ通信を利用した故障診断のデータ（即ちダイアグデータ）よりも、速やかに通信されることが望ましいので、制御データの通信の優先度はダイアグ通信の優先度よりも高く設定されている。

なお、各副ＥＣＵ１３から送信される制御データの送信周期は、予め設定されており、各副ＥＣＵ１３の種類に応じて、適切な送信周期に設定されている。つまり、各副ＥＣＵ１３の送信周期は、同一の場合もあるが、異なっている場合もある。

＜ＥＣＵ間等の通信＞
本第１実施形態では、検査ツール７と主ＥＣＵ１１との間では、ダイアグ通信によってデータの送受信が行われる。

また、主ＥＣＵ１１と副ＥＣＵ１３との間や、副ＥＣＵ１３間では、ダイアグ通信より優先度の高い制御データの定期的な通信（即ち、定期通信）によって、データの送受信が行われる。

従って、後に詳述するように、定期送信によって、副ＥＣＵ１３から主ＥＣＵ１１に、データ（例えば、データＡ、データＢ、データＣ）が送信される。
そして、主ＥＣＵ１１では、副ＥＣＵ１３から受信したデータのうち、必要なデータ、即ち検査ツール７から要求されたデータ（例えば、データＡ、データＢ）を収集して、検査ツール７に送信する。

［１−３．検査ツール］
次に、検査ツール７について説明する。
図１に示すように、検査ツール７は、車両検査装置５の主ＥＣＵ１１に接続されて使用される装置である。

この検査ツール７は、図４に示すように、各種の表示を行うディスプレイ５４と、検査員等のマニュアルでの操作が可能な操作部５５と、検査ツール７の動作を制御する検査ツール７側のＥＣＵ（以下、ツール側ＥＣＵ）５７と、を備えている。

なお、ツール側ＥＣＵ５７は、周知のマイクロコンピュータを備えた電子制御装置である。
この検査ツール７は、故障診断機能と、データモニタ機能と、ドライブレコーダ機能と、を有している。

このうち、故障診断機能では、主ＥＣＵ１１に対して、車両３の故障を示す故障コード（即ち、ＤＴＣ）の出力を要求することができる。このＤＴＣは、各副ＥＣＵ１３が故障に応じて記憶しているので、各副ＥＣＵ１３から主ＥＣＵ１１を介して、検査ツール７に送信することができる。

なお、ＤＴＣとは、Diagnostic Trouble Codeの略であり、周知のように、ＯＢＤ機能により、車載の各種のセンサ５１やアクチュエータ５３などに何らかの異常が発生したことを検出した場合に記憶される。

従って、この検査ツール７にて、ＤＴＣを参照することにより、車両３の異常に関する情報を得ることができる。なお、故障診断機能を備えていなくともよい。
データモニタ機能は、一定時間毎に、センサ５１やアクチュエータ５３等のデータを、主ＥＣＵ１１を介して、副ＥＣＵ１３から取得する機能である。このデータモニタ機能によって、図４及び図５に示すように、それらのデータの変化を数値やグラフにて、ディスプレイ５４に表示することができる。

また、このデータモニタ機能によって、後述するように、トリガによって車両３の挙動を変化させるテストを実施した場合の車両３の挙動をモニタすることができる。
例えば、検査員が意図的にアクセルペダルを踏み込み、その場合のエンジン回転数の変化をモニタすることができる。また、ヘッドライトの点灯状態を制御（即ち、オートライト制御）する車両において、カメラや照度センサを意図的に覆った場合に、ヘッドライトの点灯状態の状態をモニタすることができる。

なお、ドライブレコーダ機能は、取得したデータを検査ツール７のメモリ（図示せず）に記憶する機能である。
［１−４．各装置間の通信］
まず、車両検査システム１に行われる各装置間の通信等の内容について、その概略を説明する。

図６に示すように、検査ツール７を用いて車両３の状態を検査する場合、例えば、車両３から得られる各種の信号をモニタして記憶するには、まず、検査ツール７から主ＥＣＵ１１に対して、［１］データ要求を行う。

つまり、目的とする検査のために必要な所定のデータ、例えばデータＡ、データＢの要求を行う。このデータ要求は、ＩＳＯの規格に従ったダイアグ通信による要求である。つまり、「ＳＩＤ＄２２」にて示されるダイアグ通信による要求である。

ここでは、周知を監視するカメラから得られた画像の輝度に応じて、ヘッドライトの点灯状態の制御を行う車両３に対して、そのヘッドライトの点灯状態の検査を行う場合を例に挙げる。従って、データＡがカメラの画像の輝度を示すデータ、データＢがヘッドライドの点灯状態を示すデータであるとする。

次に、主ＥＣＵ１１は、［１］データ要求を受けて、［２］定期送信のモニタリングを開始する。つまり、副ＥＣＵ１３から車両３の制御を行うための制御データとして、定期的に送信されるデータを受信する。

ここで、副ＥＣＵ１３として、第１ＥＣＵ１７と第２ＥＣＵ１９とを例示している。
第１ＥＣＵ１７からは、所定の送信周期（例えば、１０ｍｓ）毎に、定期送信Ａによって、データＡを含むデータが主ＥＣＵ１１に送信されるので、主ＥＣＵ１１では、所定の送信周期毎に、データＡを含むデータ（従って、データＡ）を受信する。

詳しくは、第１ＥＣＵ１７では、所定の送信周期毎に、順次、［３］定期送信Ａ＃１、・・［４］定期送信Ａ＃ｎ、［５］定期送信Ａ＃ｎ+１が実施されるので、主ＥＣＵ１１では、各定期送信ＡにおいてデータＡを受信することができる。なお、ｎは整数であり、定期送信Ａの送信の順番を示している。

ここでは、データＡは複数回受信されるので、主ＥＣＵ１１では、最新のデータＡを更新（即ち、上書き）して、ＲＡＭ３３に記憶する。
一方、第２ＥＣＵ１９からは、所定の送信周期（例えば、５０ｍｓ）毎に、［６］定期送信Ｂ＃１が実施される。詳しくは、定期送信Ｂによって、データＢを含むデータ（従って、データＢ）が主ＥＣＵ１１に送信されるので、主ＥＣＵ１１では、所定の送信周期毎に、データＢを受信する。

なお、ここでは、定期送信Ａの送信周期は、定期送信Ｂの送信周期よりも短いとする。
そして、図６に示すように、［６］定期送信Ｂ＃１にてデータＢが受信された場合には、既にＲＡＭ３３に、［６］定期送信Ｂ＃１の直前に［５］定期送信Ａ＃ｎ+１にて受信された最新のデータＡが記憶されているので、［７］要求された全データ（即ち、データＡとデータＢ）の受信が完了することになる。

このように、主ＥＣＵ１１では、データＡを含む定期送信ＡとデータＢを含む定期送信Ｂとのうち、定期送信Ｂを受信した時点以前において、送信間隔（従って、受信間隔）が最も短い定期送信Ａと定期送信Ｂとを確定できる。

従って、この受信間隔が最も短い定期送信Ａと定期送信Ｂから、検査ツール７から要求されたデータＡとデータＢとを取得することができる。つまり、主ＥＣＵ１１では、データＡとデータＢとのうち、受信間隔が最も短いデータＡとデータＢとを取得することができる。

従って、主ＥＣＵ１１は、このようにして収集したデータ、即ち、受信間隔が最も短いデータＡとデータＢとを検査ツール７に送信することができる。
［１−５．制御処理］
次に、主ＥＣＵ１１にて実施される制御処理、即ち、主ＥＣＵ１１側でのデータ取得処理について説明する。

図７に示すように、ステップ（以下、Ｓと記す）１００にて、検査ツール７からデータの取得要求があったか否かを判定する。つまり、複数の副ＥＣＵ１３にて得られるデータ、例えばデータＡ及びデータＢを求めるための要求があったか否かを判定する。ここで肯定判断されるとＳ１１０に進み、一方否定判断されると一旦本処理を終了する。

Ｓ１１０では、前記取得要求があったので、要求されたデータの中から定期送信の間隔（即ち、定期送信の送信周期）が最大のデータを、基準データとして一つ選択する。ここでは、送信周期が最大のデータＢが基準データである。

続くＳ１２０では、要求されたデータを含む定期送信を受信する。なお、主ＥＣＵ１１には、予め、どの副ＥＣＵ１３からの定期送信に、要求されたデータが含まれているかの情報が記憶されている。

続くＳ１３０では、受信したデータ、例えばデータＡやデータＢをバッファリング（即ち、記憶）する。なお、既にバッファリング済みの場合は、データの上書きを行う。
例えばデータＡを記憶する場合に、既に記憶されたデータＡがある場合には、最新のデータＡによってデータＡの上書きを行う。

続くＳ１４０では、今回受信した受信データが、送信周期が長い基準データであるか否かを判定する。ここで肯定判断されるとＳ１５０に進み、一方否定判断されると前記Ｓ１２０に進む。

例えば、今回受信されたデータが、送信周期の短いデータ（例えば、データＡ）である場合には、前記Ｓ１２０に戻って、再度データを受信する処理を繰り返す。一方、今回受信されたデータが、データＡよりも送信周期の長いデータ（即ち、基準データであるデータＢ）である場合には、次のＳ１５０に進む。

Ｓ１５０では、要求された全データ（即ち、データＡ及びデータＢ）の受信が完了したか否かを判定する。ここで肯定判断されるとＳ１６０に進み、一方否定判断されると前記Ｓ１２０に戻って、再度データを受信する処理を繰り返す。

上述したＳ１００〜Ｓ１５０の処理によって、受信間隔が最も近い定期送信Ａと定期送信Ｂとに含まれるデータＡとデータＢとを取得することができる。
Ｓ１６０では、バッファリングしたデータ、即ち要求に基づいて取得されたデータＡ及びデータＢを、検査ツール７に送信し、一旦本処理を終了する。つまり、上述したＳ１００〜Ｓ１５０の処理によって、受信間隔が最も短いデータＡとデータＢとが得られたので、そのデータＡ及びデータＢを検査ツール７に送信する。

［１−６．効果］
本第１実施形態では、車両検査装置５の主ＥＣＵ１１は、車両３外の検査ツール７から、複数の副ＥＣＵ１３から得られる各データＡ、Ｂの送信の要求があった場合には、各データＡ、Ｂを含む各定期送信Ａ、Ｂを複数の副ＵＣＵ１３から受信する。そして、各定期送信Ａ、Ｂの受信時刻の差を求め、受信時刻の差が所定値以下の各定期送信Ａ、Ｂに含まれる各データを収集して、検査ツール７に送信する。

詳しくは、本第１実施形態では、定期送信Ａの送信周期よりも、定期送信Ｂの送信周期が長く設定されているので、定期送信Ｂを受信した場合に、定期送信Ｂに含まれるデータＢと、定期送信Ｂの受信の直前に受信した定期送信Ａに含まれるデータＡと、を収集する。

つまり、受信時刻の差が、送信周期が短い定期送信Ａの送信周期以下（即ち、所定値以下）の範囲における各定期送信Ａ、Ｂを選択し、各定期送信Ａ、Ｂに含まれる各データＡ、Ｂを収集する。

このような構成によって、本第１実施形態では、下記の効果を奏する。
（１ａ）本第１実施形態では、検査ツール７からの要求に基づいて、検査ツール７に送信する各データＡ、Ｂの取得タイミング（即ち、取得時刻）のずれを、従来の各ＥＵＣ９から順次取得する方法に比べて、小さくすることができる。これによって、各データＡ、Ｂの取得時刻の同期性が向上するので、車両３の挙動をより正確にモニタできるという顕著な効果を奏する。

（１ｂ）本第１実施形態では、検査ツール７の各データＡ、Ｂの取得先が、主ＥＵＣ１１のみとなるので、各データＡ、Ｂの取得に必要な通信回数が、従来の各ＥＣＵ９から順次取得する方法に比べて少なくなり、車両３の各ＥＣＵ９を繋ぐネットワークの通信負荷を低減できる。

つまり、検査ツール７は、主ＥＣＵ１１に対して各データＡ、Ｂの要求をするだけで、各副ＥＣＵ１３から各データＡ、Ｂが得られるので、従来に比べて通信負荷が低減するという利点がある。

（１ｃ）本第１実施形態を実現するためにロジックの追加等が必要なＥＣＵ９は、主ＥＣＵ１１のみで済むので、副ＥＣＵ１３は従来の構成を採用できる。そのため、車両検査装置５を容易に実現することが可能である。

（１ｄ）本第１実施形態では、主ＥＣＵ１１と副ＥＣＵ１３との通信方法として、ダイアグ通信より優先度の高い通信（例えば、制御データの通信）を採用している。つまり、主ＥＣＵ１１は、副ＥＣＵ１３からの優先度の高い通信をモニタすることにより、副ＥＣＵ１３からの各データＡ、Ｂを効率良く取得できる。

このような場合には、通信線１５が高負荷の状況でも、安定して各データＡ、Ｂを取得して検査ツール７に送信することができる。例えば、副ＥＣＵ１３から主ＥＣＵ１１に送信される各データＡ、Ｂに、欠け等が生じ難いという利点がある。また、従来より、高い頻度でモニタリングできるという効果もある。

なお、本第１実施形態では、検査ツール７と主ＥＣＵ１１との間ではダイアグ通信を行うが、検査ツール７と主ＥＣＵ１１との間では通信ケーブル１４での通信負荷は低いため、その通信負荷については、特に問題はない。

このように、本第１実施形態によれば、従来のダイアグ通信による問題点を回避できるとともに、複数の副ＥＣＵ１３から得られる各データＡ、Ｂの取得タイミングをできる限り揃えることができるという顕著な効果を奏する。

なお、前記所定値は、各定期送信Ａ、Ｂの送信周期に基づいて設定された値であり、各定期送信Ａ、Ｂの送信周期のうち、最小の送信周期を採用できる。
また、受信時刻の差が所定値以下の各定期送信Ａ、Ｂに含まれる各データＡ、Ｂとしては、車両３の挙動を変化させるトリガを示す起因データ（例えば、データＡ）と、トリガによって生じる車両３の挙動の変化を示す結果データ（例えば、データＢ）とを採用できる。

さらに、本第１実施形態は、１つの入力値（例えば１つのトリガを示すデータ）を複数のＥＣＵが参照して出力制御するシステムや、複数のＥＣＵからの入力値を１つのＥＣＵが参照して出力制御するシステムに適用できる。

これらのシステムでは、入力値と出力値とをできる限り同じタイミングで取得することが望ましいが、本第１実施形態では、入力値や出力値が複数の場合でも、好適に対応できる。

［１−７．文言の対応関係］
前記第１実施形態において、車両３が車両に対応し、車両検査装置５が車両検査装置に対応し、ＥＣＵ９が電子制御装置に対応し、主ＥＣＵ１１が主電子制御装置に対応し、副ＥＣＵ１３が副電子制御装置に対応し、データ受信部４１がデータ受信部に対応し、データ収集部４３がデータ収集部に対応し、データ送信部４５がデータ送信部に対応し、センサ５１がセンサに対応し、アクチュエータ５３がアクチュエータに対応する。

［２．第２実施形態］
第２実施形態は、基本的な構成は第１実施形態と同様であるため、以下では主として第１実施形態との相違点について説明する。なお、第１実施形態と同じ符号は、同一構成を示すものであって、先行する説明を参照する。

［２−１．各装置間の通信］
まず、本第２実施形態における車両検査システム１に行われる各装置間の通信等の内容について、その概略を説明する。

図８に示すように、検査ツール７を用いて車両３の状態を検査する場合には、まず、検査ツール７から主ＥＣＵ１１に対して、第１実施形態と同様に、ダイアグ通信によって、データＡ及びデータＢを要求する、［１］データ要求を行う。

次に、主ＥＣＵ１１は、第１実施形態と同様に、［１］データ要求を受けて、［２］定期送信のモニタリングを開始する。
詳しくは、第１実施形態と同様に、第１ＥＣＵ１７から、所定の送信周期毎に、順次、［３］定期送信Ａ＃１、・・［４］定期送信Ａ＃ｎ-1、［５］定期送信Ａ＃ｎ、［８］定期送信Ａ＃ｎ+1、が実施されるので、各定期送信Ａによって送信されるデータＡを含むデータを受信する。

一方、第２ＥＣＵ１９からは、所定の送信周期毎に、データＢを含む、［６］定期送信Ｂ＃１が実施される。
なお、定期送信Ａの送信周期は、定期送信Ｂの送信周期よりも短い。

そして、［６］定期送信Ｂ＃１にてデータＢが受信された場合には、［６］定期送信Ｂ＃１の直前の［５］定期送信Ａ＃ｎの受信時刻と、［６］定期送信Ｂ＃１の受信時刻との差Δｔを求める。

次に、前記差Δｔが、データＡを含む定期送信Ａの周期の半分以下であるか否かを判定する。そして、差Δｔが、定期送信Ａの送信周期の半分より大きな場合には、差Δｔが過大であるとして、［５］定期送信Ａ＃ｎに含まれるデータＡを、検査ツール７に送信するデータＡとして採用しない。

この場合には、［６］定期送信Ｂ＃１の受信時刻と、［６］定期送信Ｂ＃１の直後の［８］定期送信Ａ＃ｎ+1の受信時刻との差Δｔが、定期送信Ａの送信周期の半分以下となるので、［８］定期送信Ａ＃ｎ+1に含まれるデータＡを、検査ツール７に送信するデータＡとして確定する。

一方、［５］定期送信Ａ＃ｎの受信時刻と、［６］定期送信Ｂ＃１の受信時刻との差Δｔが、定期送信Ａの周期の半分以下である場合には、［５］定期送信Ａ＃ｎに含まれるデータＡを、検査ツールに送信するデータＡとして確定する。

上述した手順によって、［９］要求された全データの受信が完了することになる。
このように、主ＥＣＵ１１では、データＡを含む定期送信ＡとデータＢを含む定期送信Ｂとのうち、受信間隔が最も短い定期送信Ａと定期送信Ｂとに基づいて、検査ツール７から要求されたデータＡとデータＢとを取得することができる。つまり、主ＥＣＵ１１では、データＡとデータＢとのうち、受信間隔が最も短いデータＡとデータＢとを取得することができる。

従って、主ＥＣＵ１１は、収集したデータ、即ち、受信間隔が最も短いデータＡとデータＢとを検査ツール７に送信することができる。
［２−２．制御処理］
＜主ＥＣＵ１１での処理＞
次に、本第２実施形態における主ＥＣＵ１１にて実施される制御処理、即ち、主ＥＣＵ１１側でのデータ取得処理について説明する。

図９に示すように、Ｓ２００にて、検査ツール７からデータの取得要求があったか否かを判定する。つまり、複数の副ＥＣＵ１３にて得られるデータ、例えばデータＡ及びデータＢを求めるための要求があったか否かを判定する。ここで肯定判断されるとＳ２１０に進み、一方否定判断されると一旦本処理を終了する。

Ｓ２１０では、前記取得要求があったので、要求されたデータＡ、Ｂの中から定期送信の間隔が最大のデータを、基準データとして一つ選択する。ここでは、送信周期が最大のデータＢが基準データである。

続くＳ２２０では、要求されたデータＡ、Ｂを含む定期送信Ａ、Ｂを受信する。
続くＳ２３０では、受信したデータＡ、Ｂが未確定データであるか否かを判定する。ここで肯定判断されるとＳ２５０に進み、一方否定判断されるとＳ２４０に進む。

なお、未確定データとは、検査ツール７に送信するデータとして決定されていない（即ち、確定されていない）データである。
Ｓ２４０では、受信したデータは未確定データではないので、つまり、既に検査ツール７への送信が決められた確定されたデータであるので、再度そのデータを記憶する必要は無いとして破棄し、Ｓ２２０に戻る。

一方、Ｓ２５０では、受信したデータは未確定データであるので、その受信したデータ、例えばデータＡやデータＢをバッファリング（即ち、記憶）する。なお、既にバッファリング済みの場合は、データの上書きを行う。

続くＳ２６０では、今回受信した受信データが、定期送信Ａよりも送信周期が長い定期送信Ｂによって送信されたデータＢ、即ち基準データであるあるか否かを判定する。ここで肯定判断されるとＳ２６５に進み、一方否定判断されるとＳ２９０に進む。

Ｓ２６５では、要求された全てのデータ（即ち、データＡ、データＢ）が受信済みか否か、即ち、バッファリング済みか否かを判定する。ここで肯定判断されると、後述する受信時刻差の計算処理が可能であるのでＳ２７０に進み、一方否定判断されると、前記Ｓ２２０に戻って、再度データを受信する処理を繰り返す。

Ｓ２７０では、受信した基準データを確定データとする。即ち、検査ツール７に送信するデータＢとして確定する。
続くＳ２８０では、後述する受信時刻差の計算処理を行う。

続くＳ２９０では、要求された全データ（即ち、データＡ及びデータＢ）の受信及び確定が完了したか否かを判定する。ここで肯定判断されるとＳ３００に進み、一方否定判断されると前記Ｓ２２０に戻って、再度データを受信する処理を繰り返す。

上述したＳ２００〜Ｓ２９０の処理によって、受信間隔が最も近い定期送信Ａと定期送信Ｂとに含まれるデータＡとデータＢとを取得することができる。
Ｓ３００では、バッファリングしたデータ（従って、確定データ）、即ち要求されたデータＡ及びデータＢを、検査ツール７に送信し、一旦本処理を終了する。つまり、上述したＳ２００〜Ｓ２９０の処理によって、受信間隔が最も短いデータＡとデータＢとが得られたので、そのデータを検査ツール７に送信する。

＜受信時間差の計算処理＞
次に、前記Ｓ２８０にて実施される、定期送信Ａと定期送信Ｂとの受信時間差の計算処理について説明する。

図１０に示すように、本処理では、Ｓ４００〜Ｓ４５０の間の処理を繰り返して実施する。つまり、基準データ（即ち、データＢ）ではない全てのバッファリング済みのデータ（即ち、比較対象データであるデータＡ）分に関して、Ｓ４１０〜４４０の処理を繰り返して実施する。

具体的には、Ｓ４１０では、基準データと比較対象データとの受信時刻の差Δｔを計算する。
続くＳ４２０では、前記差Δｔが、比較対象データの定期送信の送信周期の半分以下であるか否か、即ち、基準データと比較対象データとの受信時刻の差Δｔが最小であるか否かを判定する。ここで肯定判断されるとＳ４３０に進み、一方否定判断されるとＳ４４０に進む。

Ｓ４３０では、比較対象データを確定データとする。
一方、Ｓ４４０では、前記差Δｔが、比較対象データの定期送信の送信周期の半分以下でないため、この比較対象データは確定データとしない。

この場合、次回受信する比較対象データの定期送信、即ち、次回受信する比較対象データを含む定期通信Ａで、前記差Δｔが、比較対象データの定期送信の半分以下となる。そのため、Ｓ４４０では、次回受信する比較対象データを、Ｓ２５０でバッファリングした時点で確定データとするための処理を行う。

つまり、このＳ４４０を経て、前記Ｓ２８０のルーチンを抜けた後は、次回Ｓ２５０でデータＡをバッファリングした時点で、そのデータＡを確定データとするため、Ｓ４４０では、例えばフラグをセットする等のように、その後の処理を規定するための処理を行う。従って、例えば、Ｓ２５０の処理の際に、前記フラグがセットされていた場合には、前記データＡを確定データとする。

そして、前記Ｓ４００〜Ｓ４５０の間の処理の終了後に、一旦本処理を終了する。
［２−３．効果］
本第２実施形態では、第１実施形態と同様な効果を奏する。

また、本第２実施形態では、定期送信Ｂを受信した場合に、その定期通信Ｂに含まれるデータＢを、検査ツール７に送信するデータＢとして採用している。それとともに、定期送信Ｂを受信した場合に、定期送信Ｂの受信の直前及び直後に受信した定期送信Ａのうち、前記受信時刻の差が定期送信Ａの送信周期の半分以下であった定期送信Ａを求め、その定期通信Ａに含まれるデータＡを、検査ツール７に送信するデータＡとして採用している。

従って、検査ツール７に送信する各データＡ、Ｂの取得タイミング（即ち、取得時刻）のずれを、一層小さくすることができる。よって、各データＡ、Ｂの取得時刻の同期性が一層向上するので、車両３の挙動をより正確にモニタできるという顕著な効果を奏する。

［３．第３実施形態］
第３実施形態は、基本的な構成は第１実施形態と同様であるため、以下では主として第１実施形態との相違点について説明する。なお、第１実施形態と同じ符号は、同一構成を示すものであって、先行する説明を参照する。

本第３実施形態では、例えば、各定期送信Ａ、Ｂが、データＡを含む定期送信ＡとデータＢを含む定期送信Ｂとである場合を例に挙げる。
本第３実施形態では、１又は複数回の定期送信Ａと１又は複数回の定期送信Ｂとを受信した場合には、定期送信Ａの受信時刻と定期送信Ｂの受信時刻とを比較して、定期送信Ａの受信時刻と定期送信Ｂの受信時刻とが最も短い定期送信Ａと定期送信Ｂとを選択する。そして、当該選択された定期送信Ａに含まれるデータＡと定期送信Ｂに含まれるデータＢとを、検査ツール７に送信するデータとして決定する。

なお、この場合、定期送信Ａと定期送信Ｂとの送信周期は、異なっていても同一であってもよい。
本第３実施形態は、第１、第２実施形態と同様な効果を奏する。

［４．他の実施形態］
以上、本開示の実施形態について説明したが、本開示は上述の実施形態に限定されることなく、種々変形して実施することができる。

（４ａ）前記各実施形態では、トリガとなるデータＡと結果を示すデータＢとの２種類のデータの受信時刻の差を例に挙げて説明したが、本開示は、例えば、結果を示すデータが複数種類ある場合（例えばデータＢ、Ｃ）に、結果を示すデータ間の時間差を小さくする場合にも適用できる。

例えばデータＡ、Ｂの受信時刻差を求める方法を、結果を示すデータであるデータＢ、Ｃに適用してもよい。
（４ｂ）また、本開示は、１つの副ＥＣＵから得られるデータ（例えば、１つのトリガを示すデータ：入力値）を複数の副ＥＣＵが参照して出力制御する第１システムや、複数の副ＥＣＵからの入力値を１つの副ＥＣＵが参照して出力制御する第２システムや、複数の副ＥＣＵからの入力値を複数の副ＥＣＵが参照して出力制御する第３システムに適用できる。

例えば、第１システムとしては、内燃機関とモータとを備えたハイブリッド自動車の回生制御を行うシステムが挙げられる。
この場合には、例えば、入力値として、ブレーキペダル開度が挙げられ、出力制御を行うＥＣＵとして、ブレーキの制御を行うブレーキＥＣＵ、エンジンの制御を行うエンジンＥＣＵ、モータの制御を行うモータＥＣＵが挙げられる。

なお、ブレーキＥＣＵからは例えば油圧のデータ、エンジンＥＣＵからは例えばエンジンの回転数のデータ、モータＥＣＵからは例えば回生ブレーキのデータなどが出力される。
また、第２システムとしては、ヘッドライト等の制御（即ち、オートライト制御）を行うシステムが挙げられる。

この場合には、例えば、入力値として、照度センサの輝度、カメラ画像の輝度が挙げられ、出力制御を行うＥＣＵとして、ヘッドライトの点灯状態を制御するＥＣＵが挙げられる。なお、ヘッドライドを制御するＥＣＵからは、ヘッドライトの点滅等のデータが出力される。

さらに、第３システムとしては、自動ブレーキ制御を行うシステムが挙げられる。
この場合には、例えば、入力値として、ミリ波レーダの受信データ、カメラ画像のデータが挙げられ、出力制御を行うＥＣＵとして、ブレーキの制御を行うブレーキＥＣＵ、ステアリングの制御を行うステアリングＥＣが挙げられる。

なお、ブレーキＥＣＵからは例えば油圧のデータ、ステアリングＥＣＵからは例えば操舵角のデータなどが出力される。
（４ｃ）本開示に記載のＥＣＵ及びその手法は、コンピュータプログラムにより具体化された一つ乃至は複数の機能を実行するようにプログラムされたプロセッサ及びメモリを構成することによって提供された専用コンピュータにより、実現されてもよい。あるいは、本開示に記載のＥＣＵ及びその手法は、一つ以上の専用ハードウェア論理回路によってプロセッサを構成することによって提供された専用コンピュータにより、実現されてもよい。

もしくは、本開示に記載のＥＣＵ及びその手法は、一つ乃至は複数の機能を実行するようにプログラムされたプロセッサ及びメモリと一つ以上のハードウェア論理回路によって構成されたプロセッサとの組み合わせにより構成された一つ以上の専用コンピュータにより、実現されてもよい。また、コンピュータプログラムは、コンピュータにより実行されるインストラクションとして、コンピュータ読み取り可能な非遷移有形記録媒体に記憶されてもよい。

また、ＥＣＵに含まれる各部の機能を実現する手法には、必ずしもソフトウェアが含まれている必要はなく、その全部の機能が、一つあるいは複数のハードウェアを用いて実現されてもよい。

（４ｄ）前記実施形態における１つの構成要素が有する複数の機能を、複数の構成要素によって実現したり、１つの構成要素が有する１つの機能を、複数の構成要素によって実現したりしてもよい。また、複数の構成要素が有する複数の機能を、１つの構成要素によって実現したり、複数の構成要素によって実現される１つの機能を、１つの構成要素によって実現したりしてもよい。また、上記実施形態の構成の一部を省略してもよい。また、上記実施形態の構成の少なくとも一部を、他の上記実施形態の構成に対して付加又は置換してもよい。

（４ｅ）また、上述したＥＣＵの他、当該ＥＣＵを構成要素とするシステム、当該ＥＣＵとしてコンピュータを機能させるためのプログラム、このプログラムを記録した半導体メモリ等の非遷移的実態的記録媒体など、種々の形態で本開示を実現することもできる。

３：車両、５：車両検査装置 ７：検査ツール、９：ＥＣＵ １１：主ＥＣＵ、１３：副ＥＣＵ、４１：データ受信部、４３：データ収集部、４５：データ送信部、５１：センサ、５３：アクチュエータ

Claims (8)

1. 車両（３）に搭載される複数の電子制御装置（９）を備えた車両検査装置（５）であって、
   前記複数の電子制御装置（９）は、センサ（５１）及び／又はアクチュエータ（５３）が接続された複数の副電子制御装置（１３）と、前記複数の副電子制御装置から各データを受信するように構成された主電子制御装置（１１）と、を備えており、
   前記複数の副電子制御装置のそれぞれは、
   前記主電子制御装置に対して、前記センサ及び／又はアクチュエータの動作を示す前記各データを、定期通信によって周期的に送信する構成を有し、
   前記主電子制御装置は、
   前記車両検査装置外の検査ツール（７）から、前記複数の副電子制御装置から出力される前記各データの送信の要求があった場合には、前記各データを含む前記各定期通信を前記複数の副電子制御装置から受信するように構成されたデータ受信部（４１、Ｓ１００）と、
   前記データ受信部にて受信された前記各定期通信の受信時刻の差を求め、前記受信時刻の差が所定値以下の前記各定期通信に含まれる前記各データを収集するように構成されたデータ収集部（４３、Ｓ１１０〜Ｓ１５０）と、
   前記データ収集部にて収集された前記各データを、前記検査ツールに送信するように構成されたデータ送信部（４５、Ｓ１６０）と、
   を備えた車両検査装置。
2. 請求項１に記載の車両検査装置であって、
   前記所定値は、前記各定期通信の通信周期に基づいて設定された値である、車両検査装置。
3. 請求項１または２に記載の車両検査装置であって、
   前記受信時刻の差が前記所定値以下の前記各定期通信に含まれる各データは、前記車両の挙動を変化させるトリガを示す起因データと、前記トリガによって生じる前記車両の挙動の変化を示す結果データと、である、車両検査装置。
4. 請求項１から３のいずれか１項に記載の車両検査装置であって、
   前記所定値は、前記各定期通信の通信周期のうち、最小の周期である、車両検査装置。
5. 請求項４に記載の車両検査装置であって、
   前記各定期通信が、第１定期通信と、前記第１定期通信の通信周期より長い通信周期を有する第２定期通信と、であるときに、
   前記第２定期通信を受信した場合に、前記データ収集部によって、前記第２定期通信に含まれる第２データと、前記第２定期通信の受信の直前に受信した前記第１定期通信に含まれる第１データと、を収集するように構成された、車両検査装置。
6. 請求項１から３のいずれか１項に記載の車両検査装置であって、
   前記所定値は、前記各定期通信の通信周期のうち、最小の周期の半分である、車両検査装置。
7. 請求項６に記載の車両検査装置であって、
   前記各定期通信が、前記第１定期通信と、前記第１定期通信の通信周期より長い通信周期を有する第２定期通信と、であるときに、
   前記第２定期通信を受信した場合に、前記データ収集部によって、前記第２定期通信に含まれる第２データと、前記第２定期通信の受信の直前及び直後に受信した前記第１定期通信のうち、前記第１定期通信と前記第２定期通信との受信時刻の差が前記第１定期通信の通信周期の半分以下の前記第１定期通信に含まれる第１データと、を収集するように構成された、車両検査装置。
8. 車両に搭載される複数の電子制御装置を備えた車両検査装置であって、
   前記複数の電子制御装置は、センサ及び／又はアクチュエータが接続された複数の副電子制御装置と、前記複数の副電子制御装置から各データを受信するように構成された主電子制御装置と、を備えており、
   前記複数の副電子制御装置のそれぞれは、
   前記主電子制御装置に対して、前記センサ及び／又はアクチュエータの動作を示す前記各データを、定期通信によって周期的に送信する構成を有し、
   前記主電子制御装置は、
   前記車両検査装置外の検査ツールから、前記複数の副電子制御装置から出力される各データの送信の要求があった場合には、前記各データを含む前記各定期通信を前記複数の副電子制御装置から受信するように構成されたデータ受信部と、
   前記データ受信部にて受信された前記各定期通信のうち、一対の前記定期通信の受信時刻の差を求め、前記受信時刻の差が最小となる一対の前記各定期通信に含まれる各データを収集するように構成されたデータ収集部（４３、Ｓ２８０）と、
   前記データ収集部にて収集された前記各データを、前記検査ツールに送信するように構成されたデータ送信部と、
   を備えた車両検査装置。

Images