JP7081462B2 - 車両電子制御装置及び診断システム - Google Patents

Description

本開示は、車両に搭載された車両電子制御装置と、車両電子制御装置及び検査ツールを備えた診断システムとに関する。

従来、車載の電子制御装置（即ち車両電子制御装置）の機能として、ＯＢＤが知られている。ＯＢＤはOn-board Diagnosticsの略である。このＯＢＤにより、車載の各種のセンサ、アクチュエータなどに何らかの異常が発生したことを検出し、異常に対応する故障コードを記録している。以下、故障コードをＤＴＣともいう。ＤＴＣはDiagnostic Trouble Codeの略である。

また、近年では、ＤＴＣを用いて、車両の整備業務を支援する各種の整備業務支援装置が提案されている。例えば、検査ツール（即ちスキャンツール）を用いて車両からＤＴＣを取得し、そのＤＴＣから車両の状態を診断し、その診断結果に応じて必要な処理を行う装置が知られている。例えば、下記特許文献１参照。

特開２００５－８１８４９号公報

上述したＤＴＣは、車両の過去等の異常を示している。そのため、将来、例えば、自動車検査登録制度（即ち車検）において、このＤＴＣを車両の状態の検査に用いることが考えられるが、十分な検討が必要である。

そこで、下記に示すようにＤＴＣを車検に用いる場合を検討したところ、本願発明者によって、以下に示すような課題があることが見出された。
例えば、ＤＴＣのうち、道路運送車両法の保安基準を満たさない不具合を示す所定のＤＴＣを特定ＤＴＣとして定め、この特定ＤＴＣが検査ツールで読み出されると、車検を不合格にすることが考えられる。つまり、特定ＤＴＣが車両電子制御装置に記憶されている場合には、車検を不合格にすることが考えられる。

そして、上述したように車検を行う場合には、下記のようなシステムが考えられる。
特定ＤＴＣやそのバージョン等の情報（即ち特定ＤＴＣ情報）は、特定ＤＴＣ管理機構の管理サーバに保管される。そして、車検時には、検査ツールから予め管理サーバにアクセスして特定ＤＴＣ情報を取得して更新した上で、検査ツールにて車両に特定ＤＴＣが発生していないかを検査する。

この検査ツールの使用環境としては、例えば小規模な整備工場を想定した場合、前記管理サーバとは常時接続せずに、検査ツール単体で使用する比較的安価な構成で実現できるスタンドアローン型が考えられる。

この検査ツールをスタンドアローン型で使用する場合には、検査ツールに格納される特定ＤＴＣ情報は、管理サーバにアクセスして更新する必要があるため、定期的に更新する作業が必要となる。

しかしながら、何らかの理由で特定ＤＴＣ情報が更新されない場合には、最新の特定ＤＴＣ情報に基づいて精度よく車検が行われない恐れがある。例えば、最新の特定ＤＴＣ情報ではない古い特定ＤＴＣ情報に基づいて車検を行った場合には、本来ならば車検が不合格である車両が合格とされるかも知れない。

本開示の一つの局面は、ＤＴＣを利用して好適に車検等の検査を行うことができる車両用電子制御装置及び診断システムを提供することにある。

ａ）本開示の一つの態様は、車両（３）に搭載された車両電子制御装置（５）であって、記憶部（２３）と取得部（２７）と判定部（２９）と処理部（３１）とを備えている。
記憶部は、車両の異常を示す故障コードであるＤＴＣを記憶する。

取得部は、検査ツール（７）から、ＤＴＣのうち車両の状態の判定に用いる特定の故障コードである特定ＤＴＣの読み出し要求があった場合に、検査ツールから、特定ＤＴＣを含む特定ＤＴＣ情報を管理サーバ（９）から最後に受信した時期を示す第１の時期情報を取得するとともに、読み出し要求の時期を示す第２の時期情報を取得する。

判定部は、第１の時期情報と第２の時期情報とが示す時期を比較し、両時期情報が示す時期の時間間隔である経過時間が、所定の判定時間以上か否かを判定する。
処理部は、判定の結果に応じた処理を行う。

このような構成によれば、検査ツールから特定ＤＴＣの読み出し要求があった場合に、第１の時期情報と第２の時期情報とを取得し、両時期情報が示す経過時間が、所定の判定時間以上か否かを判定し、判定結果に応じた処理を行う。

従って、管理サーバから受信した特定ＤＴＣ情報が、時間的に考えて過度に古いものであるか否かを判定できるので、その判定結果に応じた適切な処理が可能となる。
例えば、特定ＤＴＣ情報が古い場合には、例えば、検査ツールに対して、最新の特定ＤＴＣ情報への更新を要求する等の対応が可能となる。

その結果、最新の特定ＤＴＣ情報への更新が実施された場合には、車両の状態の判定を確実に行うことができる。よって、車検の合格、不合格の判断を確実に行うことが可能となる。

ｂ）本開示の他の態様は、車両電子制御装置と検査ツールとを備えた診断システム（１３）である。
車両電子制御装置は、車両に搭載され、その車両の異常を示す故障コードであるＤＴＣを記憶する。

検査ツールは、ＤＴＣのうち車両の状態の判定に用いる特定の故障コードである特定ＤＴＣを含む特定ＤＴＣ情報を、管理サーバから受信して記憶し、且つ、管理サーバから特定ＤＴＣ情報を最後に受信した時期を示す第１の時期情報を記憶する。

さらに、前記車両電子制御装置は、取得部と判定部と処理部とを備えている。
取得部は、検査ツールから特定ＤＴＣの読み出し要求があった場合に、検査ツールから第１の時期情報を取得するとともに、読み出し要求の時期を示す第２の時期情報を取得する。

判定部は、第１の時期情報と第２の時期情報とが示す時期を比較し、両時期情報が示す時期の時間間隔である経過時間が、所定の判定時間以上か否かを判定する。
処理部は、判定の結果に応じた処理を行う。

このような構成によれば、上述した本開示の一つの態様と同様な効果を奏する。
なお、この欄及び特許請求の範囲に記載した括弧内の符号は、一つの態様として後述する実施形態に記載の具体的手段との対応関係を示すものであって、本開示の技術的範囲を限定するものではない。

第１実施形態の車検システムを示すブロック図。 第１実施形態の車両電子制御装置を示すブロック図。 第１実施形態の検査ツールを示すブロック図。 第１実施形態の車両電子制御装置と検査ツールとの間の通信の手順を示すシーケンス図。 第１実施形態の管理サーバに対する検査ツールの処理を示すフローチャート。 第１実施形態の車両電子制御装置に対する検査ツールの処理を示すフローチャート。 第１実施形態の検査ツールに対する車両電子制御装置の処理を示すフローチャート。 第２実施形態の車両電子制御装置に対する検査ツールの処理を示すフローチャート。 第２実施形態の検査ツールに対する車両電子制御装置の処理を示すフローチャート。 第２実施形態の車検システムを示すブロック図。

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

図１に示すように、本第１実施形態における車検システム１は、車両３に車載された電子制御装置（即ち車両電子制御装置）５と、車両電子制御装置５に電気的に接続される検査ツール７と、検査ツール７にインターネットを介して接続される管理サーバ９と、を備えている。なお、以下では電子制御装置をＥＣＵと記すこともある。

ここでは、車両ＥＣＵ５と検査ツール７とが、ケーブル１１にて接続されている例を挙げているが、無線にて接続されていてもよい。なお、診断システム１３は、車両ＥＣＵ５と検査ツール７とを備えた構成となっている。

上述した車検システム１では、以下のようにして車検のための処理等が行われる。
まず、車両３の異常を示す故障コードであるＤＴＣのうち、道路運送車両法の保安基準を満たさない不具合を示す所定のＤＴＣを特定ＤＴＣとして定めている。そして、この特定ＤＴＣが車両ＥＣＵ５から検査ツール７で読み出されると、車検を不合格とする。

つまり、保安基準が設けられたＤＴＣを特定ＤＴＣとして、特定ＤＴＣが車両ＥＣＵ５に記憶されている場合には、車検を不合格にする。
詳しくは、特定ＤＴＣやそのバージョン等の情報、即ち特定ＤＴＣに関する情報である特定ＤＴＣ情報は、特定ＤＴＣ管理機構の管理サーバ９に保管されている。そして、車検時等には、検査ツール７から管理サーバ９にアクセスし、特定ＤＴＣ情報を取得して更新した上で、検査ツール７にて車両３に特定ＤＴＣが発生していないかを検査する。

前記車検システム１での検査ツール７の使用環境は、例えば小規模な整備工場を想定して、管理サーバ９とは常時接続せずに、検査ツール７単体で独立して使用するスタンドアローン型を採用している。

この検査ツール７をスタンドアローン型で使用する場合、即ち、検査ツール７単体にて特定ＤＴＣの発生を検査する場合や、車検の合格、不合格の判定を行う場合には、特定ＤＴＣ情報は検査ツール７に格納されている必要がある。従って、特定ＤＴＣ情報は、後述するように、管理サーバ９にアクセスして更新される必要がある。

［１－２．各構成］
次に、本第１実施形態の診断システム１３等の各構成について詳細に説明する。
＜車両電子制御装置＞
図２に示すように、車両ＥＣＵ５は、車両演算処理部２１を構成するマイコンを中心とする電子制御装置であり、車両３の走行中等に、車載の各種のセンサ、アクチュエータなどに何らかの異常が発生したことを検出するＯＢＤ機能を有している。

具体的には、車両ＥＣＵ５は、各種の演算を行う車両演算処理部２１と、各種のデータを記憶する車両記憶部２３と、外部との接続端子である車両コネクタ２５等を備えている。なお、車両演算処理部２１は、図示しないが、ＣＰＵ、ＲＯＭ、ＲＡＭ等から構成されている。また、車両コネクタ２５には、ケーブル１１の一端の図示しないコネクタが接続される。

前記車両記憶部２３は、フラッシュメモリ等の書き換え可能な不揮発性メモリであり、車両３の異常を検出した場合には、その異常に該当するＤＴＣを記録するように構成されている。

前記車両演算処理部２１は、ＣＰＵがプログラムを実行することで実現される機能的な構成として、車両取得部２７と車両判定部２９と車両処理部３１とを有する。
車両取得部２７は、検査ツール７から、ＤＴＣのうち車両の状態の判定に用いる特定の故障コード（即ち特定ＤＴＣ）の読み出し要求があった場合には、検査ツール７から、特定ＤＴＣを含む特定ＤＴＣ情報を管理サーバ９から最後に受信した時期を示す第１の時期情報（例えば第１のタイムスタンプ）を取得する。それとともに、図示しないタイマによる時間情報に基づいて、読み出し要求の時期を示す第２の時期情報（例えば第２のタイムスタンプ）を取得する。

なお、タイムスタンプとは、周知のように、電子データがある時刻に存在していたこと（ここでは、前記最後に受信した時期や読み出し要求の時期）を示す証明となる記録である。

なお、特定ＤＴＣ情報としては、特定ＤＴＣ以外に、例えば、特定ＤＴＣ情報のバージョン情報、車検の対象となる車両３の種類等に関する車両情報、当該車両３に搭載されたＥＣＵに関するＥＣＵ情報、通信プロトコル、特定ＤＴＣの定義等が挙げられる。

車両判定部２９は、第１の時期情報と第２の時期情報とが示す時期を比較し、両時期情報が示す時期の時間間隔である経過時間が、所定の判定時間以上か否かを判定する。
なお、第１の時期情報や第２の時期情報としては、時刻そのものを示す前記第１のタイムスタンプや第２のスタンプが挙げられる。また、第１の時期情報としては、特定ＤＴＣ情報を更新した更新時期の情報、即ち更新時期を示す第１のタイムスタンプ、および／または、更新時期を特定できる特定ＤＴＣ情報のバージョン情報等の固有情報が挙げられる。

車両処理部３１は、上述した判定の結果に応じて、下記（１）、（２）のような処理を行う。つまり、判定結果に応じて処理内容を変更して、必要な処理を実施する。
（１）例えば、経過時間が判定時間以上の場合には、検査ツール７に対して、特定ＤＴＣ情報の更新を要求する。

或いは、経過時間が判定時間以上の場合には、読み出し要求を拒否する否定応答を送信、又は、無応答としてもよい。
（２）経過時間が判定時間未満の場合には、検査ツール７に対して、特定ＤＴＣ、または、特定ＤＴＣを含むＤＴＣ（例えば全てのＤＴＣ）を送信する。

そして、送信した情報を示す送信情報と、送信した情報の送信時期を示す送信時期情報と、を車両記憶部２３に記憶する。
なお、車両ＥＣＵ５は、送信情報と送信時期情報とについては、例えば検査ツール７のような外部からの要求によって読み出し可能なように構成されている。

＜検査ツール＞
図３に示すように、検査ツール７は、各種の表示を行うディスプレイ３３と、検査ツール７の動作を制御するツール電子制御装置（即ちツールＥＣＵ）３５と、作業者のマニュアルでの操作が可能な操作部３７と、管理サーバ９との通信を行うツール通信部３９と、ケーブル１１の他端のコネクタ１２（図１参照）が接続されるツールコネクタ４１と、を備えている。

ツールＥＣＵ３５は、各種の演算を行うツール演算処理部４３と、各種のデータを記憶するツール記憶部４５とを備えている。
前記ツール演算処理部４３は、図示しないが、ＣＰＵ、ＲＯＭ、ＲＡＭ等から構成されている。このツール演算処理部４３では、例えば、管理サーバ９に対して、特定ＤＴＣ情報の送信を要求して取得したり、車両ＥＣＵ５に対して、特定ＤＴＣの送信を要求して取得する等の制御を行う。

前記ツール記憶部４５は、フラッシュメモリ等の書き換え可能な不揮発性メモリであり、管理サーバ９から取得した特定ＴＤＣ情報や、その特定ＴＤＣ情報を最後に受信した第１の時期情報を記憶するように構成されている。また、車両ＥＣＵ５から取得した特定ＤＴＣを記憶するように構成されている。

ツール通信部３９は、無線にて、インターネットを介して、管理サーバ９との通信を行う通信装置である。このツール通信部３９は、通常は管理サーバ９に接続されておらず、作業者の操作によって、必要な場合に管理サーバ９に接続されて、例えば最新の特定ＤＴＣ情報のダウンロード等が行われる。

つまり、検査ツール７は、スタンドアローン型であり、常時オンラインにて管理サーバ９と接続して使用するのでなく、オフラインにて使用される。
なお、前記車両ＥＣＵ５とツールＥＣＵ３５との各種機能は、ＣＰＵが非遷移的実体的記録媒体に格納されたプログラムを実行することにより実現される。この例では、車両記憶部２３及びツール記憶部４５が、プログラムを格納した非遷移的実体的記録媒体に該当する。また、このプログラムが実行されることで、プログラムに対応する方法が実行される。なお、車両ＥＣＵ５とツールＥＣＵ３５とは、それぞれ１個のマイクロコンピュータで構成されてもよいし、複数のマイクロコンピュータで構成されてもよい。

また、車両ＥＣＵ５とツールＥＣＵ３５とが実行する各処理を実現する手法はソフトウェアに限るものではなく、その１部または全部の機能は、１個あるいは複数のハードウェアを用いて実現してもよい。例えば、上記機能がハードウェアである電子回路によって実現される場合、その電子回路は多数の論理回路を含むデジタル回路、またはアナログ回路、あるいはこれらの組合せによって実現してもよい。

［１－３．制御処理］
まず、車検システム１に行われる処理について、その概略を説明する。
図４に示すように、例えば車検の際に、検査ツール７から車両ＥＣＵ５に対して、（Ａ）特定ＤＴＣの読み出し要求と、（Ｂ）特定ＤＴＣ情報を管理サーバ９から最後に受信した第１の時期情報の送信と、を行う。

車両ＥＣＵ５では、検査ツール７から特定ＤＴＣの読み出し要求を受信すると、検査ツール７から送信された第１の時期情報を取得するとともに、特定ＤＴＣの読み出し要求の時期として、タイマから現在時刻である第２の時期情報を取得する。

さらに、車両ＥＣＵ５では、第１の時期情報及び第２の時期情報が示す時期の経過時間が判定時間以上か否かを判定する。そして、判定時間以上の場合には、検査ツール７に対して、（Ｃ）特定ＤＴＣ情報の更新の要求を行う。

検査ツール７では、車両ＥＣＵ５から特定ＤＴＣ情報の更新の要求を受信すると、その内容を報知する。例えばディスプレイ３３にその要求があることを表示したり、音や音声等でその要求があることを、作業者に報知する。

作業者は、上述した報知によって、車両ＥＣＵ５から特定ＤＴＣ情報の更新の要求があることを認識した場合には、検査ツール７を操作して、管理サーバ９から最新の特定ＤＴＣ情報をダウンロードし、その特定ＤＴＣ情報を更新して記憶する。

従って、その後は、再度、検査ツール７を用いて、上述した（Ａ）、（Ｂ）の処理を行う。
一方、前記経過時間が判定時間未満の場合には、特定ＤＴＣ情報が最新のものであるとみなして、車両ＥＣＵ５から検査ツール７に対して、例えば、（Ｄ）特定ＤＴＣを含む全ＤＴＣを送信する処理を行う。

従って、特定ＤＴＣを含む全ＤＴＣを受信した検査ツール７では、特定ＤＴＣの有無を検査し、その検査結果を、例えばディスプレイ３３に表示し、ツール記憶部４５に記憶する。

次に、車両ＥＣＵ５と検査ツール７にて行われる処理について、それぞれ具体的に説明する。
＜検査ツールにおける処理＞
（ａ）管理サーバ９に対する検査ツール７の処理
検査ツール７において、図５に示すように、ステップ１００では、操作部３７による操作によって、管理サーバ９に対して、特定ＤＴＣ情報の更新要求を行う。なお、図５では、ステップをＳと記載する。以下、各図において同様である。

続くステップ１１０では、管理サーバ９から、更新された特定ＤＴＣ情報を取得する。即ち、最新の特定ＤＴＣ情報をダウンロードする。
続くステップ１２０では、更新された特定ＤＴＣ情報と、その特定ＤＴＣ情報を受信した時期を示す第１の時期情報（即ち第１のタイムスタンプ）とを、ツール記憶部４５に記憶し、一旦本処理を終了する。

（ｂ）車両ＥＣＵ５に対する検査ツール７の処理
検査ツール７において、図６に示すように、ステップ２００では、車両ＥＣＵ５に対して、特定ＤＴＣの取得要求を行う。

また、ステップ２１０では、車両ＥＣＵ５に対して、第１の時期情報を送信する。
続くステップ２２０では、車両ＥＣＵ５から特定ＤＴＣ情報の更新要求があるか否かを判定する。ここで肯定判断されるとステップ２３０に進み、一方否定判断されるとステップ２４０に進む。

ステップ２３０では、特定ＤＴＣ情報の更新要求があるので、そのことを報知し、一旦本処理を終了する。例えばディスプレイ３３に更新要求があることを表示したり、音声等でその旨を報知する。

一方、ステップ２４０では、特定ＤＴＣ情報の更新要求がないので、特定ＤＴＣ情報が最新のものであるとみなして、車両ＥＣＵ５から送信される特定ＤＴＣを取得する。
なお、ここでは、車両ＥＣＵ５は、特定ＤＴＣの取得要求がなされた場合に、後述する特定ＤＴＣを送信するための判定条件（即ちＳ３３０の判定時間未満の条件）が満たされたときには、特定ＤＴＣを含む全てＤＴＣを送信するが、特定ＤＴＣのみを送信するようにしてもよい。例えば特定ＤＴＣの取得要求を行う際に、「特定ＤＴＣのみ」や「特定ＤＴＣを含む全ＤＴＣ」のように、どのようなＤＴＣを送信するかを指定してもよい。

続くステップ２５０では、車両ＥＣＵ５から取得したＤＴＣに特定ＤＴＣがあるかを検査する。
続くステップ２６０では、検査結果を報知する。例えば、特定ＤＴＣがある場合には、その特定ＤＴＣやその定義をディスプレイ３３に表示したり、音声等で報知する。さらには、車検が不合格であることを報知してもよい。

また、特定ＤＴＣがない場合には、特定ＤＴＣが無いことをディスプレイ３３に表示したり、音声等で報知する。さらには、車検に合格したことを報知してもよい。
＜車両電子制御装置における処理＞
車両ＥＣＵ５において、図７に示すように、ステップ３００では、検査ツール７から、特定ＤＴＣの読み出し要求があるか否かを判定する。ここで肯定判断されるとステップ３１０に進み、一方否定判断されると一旦本処理を終了する。

ステップ３１０では、検査ツール７から、第１の時期情報である第１のタイムスタンプを取得する。
続くステップ３２０では、自身のタイマから、現在時刻である第２の時期情報である第２のタイムスタンプを取得する。

続くステップ３３０では、第１の時期情報が示す時期と第２の時期情報が示す時期との時間間隔である経過時間を求め、この経過時間が所定の判定時間（例えば、１か月）以上か否かを判定する。ここで肯定判断されるとステップ３４０に進み、一方否定判断されるとステップ３５０に進む。

ステップ３４０では、経過時間が長いので、特定ＤＴＣ情報が最新のものでないとみなして、検査ツール７に対して、特定ＤＴＣ情報を更新する要求を行い、一旦本処理を終了する。

一方、ステップ３５０では、経過時間が短いで、特定ＤＴＣ情報が最新のものであるとみなして、検査ツール７に対して、特定ＤＴＣを含む全てのＤＴＣを送信する。なお、特定ＤＴＣのみを送信するようにしてもよい。

続くステップ３６０では、車両記憶部２３に、第１の時期情報、第２の時期情報、検査ツールに送信した情報（即ち送信情報）、送信情報を送信した時期を示す送信時期情報を記憶し、一旦本処理を終了する。

［１－４．効果］
上記第１実施形態では、以下の効果を得ることができる。
（１ａ）本第１実施形態では、スタンドアローン型の検査ツール７から特定ＤＴＣの読み出し要求があった場合に、第１の時期情報と第２の時期情報とを取得し、両時期情報が示す経過時間が、所定の判定時間以上か否かを判定する。

この判定によって、スタンドアローン型の検査ツール７を用いる場合でも、管理サーバ９から受信した特定ＤＴＣ情報が、時間的に考えて古いもの（即ち最新のバージョンではないもの）であるか否かが分かるので、その判定結果に応じた適切な対応が可能となる。

例えば、特定ＤＴＣ情報が古い場合には、検査ツール７に対して、最新の特定ＤＴＣ情報への更新を要求する等の対応が可能となる。
その結果、作業者によって、最新の特定ＤＴＣ情報への更新が実施された場合には、最新の特定ＤＴＣ情報に基づいて、車両３の状態の判定を確実に行うことができる。よって、車検の合格、不合格の判断を確実に行うことが可能となる。

（１ｂ）また、本第１実施形態では、経過時間が判定時間以上の場合には、読み出し要求を拒否する否定応答を送信してもよい。或いは、否定応答を送信することなく無応答としてもよい。

作業者は、このような否定応答や無応答によっても、管理サーバ９から受信した特定ＤＴＣ情報が古いものであるかが分かるので、その後の適切な対応が可能となる。
つまり、否定応答や無応答の場合には、最新の特定ＤＴＣ情報への更新要求と同様とみなして、最新の特定ＤＴＣ情報への更新を実施することができる。

［１－５．文言の対応関係］
前記第１実施形態において、車両３が車両に対応し、車両電子制御装置５が車両電子制御装置に対応し、検査ツール７が検査ツールに対応し、診断システム１３が診断システムに対応し、車両記憶部２３が記憶部に対応し、車両取得部２７が取得部に対応し、車両判定部２９が判定部に対応し、車両処理部３１が処理部に対応している。

［２．第２実施形態］
［２－１．第１実施形態との相違点］
第２実施形態の第１実施形態との相違点について以下に説明する。なお、相違点以外は第１実施形態と同様である。また、第１実施形態と同様な構成には同一の符号を付す。

本第２実施形態は、検査ツール７によって、車両ＥＣＵ５に記憶されている特定ＤＴＣ関連情報を読み出し、ＯＢＤ検査の正当性を検証するものである。
ここで、特定ＤＴＣ関連情報とは、検査ツール７に対して過去に応答したＤＴＣの情報（即ち送信情報）と、そのときのタイムスタンプ（即ち送信時期情報）である。また、ＯＢＤ検査の正当性とは、特定ＤＴＣを用いた検査の正当性のことである。つまり、特定ＤＴＣを用いた車検の正当性のことである。

以下、詳細に説明する。
＜検査ツールの処理＞
検査ツール７において、図８に示すように、ステップ４００では、車両ＥＣＵ５に対して、車両記憶部２３に記憶されている特定ＤＴＣ関連情報を要求する。

続くステップ４１０では、特定ＤＴＣ関連情報の要求に応じて車両ＥＣＵ５から送信された特定ＤＴＣ関連情報を取得する。
続くステップ４２０では、ＯＢＤ検査の正当性を検証し、一旦本処理を行う。

このＯＢＤ検査の正当性の検証の内容として、例えば、特定ＤＴＣの有無を確認して、確認結果を表示することが挙げられる。なお、マニュアルにて、ＯＢＤ検査の正当性を検証してもよい。

＜車両電子制御装置の処理＞
車両ＥＣＵ５において、図９に示すように、ステップ５００では、検査ツール７から、特定ＤＴＣ関連情報の要求があるか否かを判定する。ここで肯定判断されるとステップ５１０に進み、一方否定判断されると一旦本処理を終了する。

ステップ５１０では、検査ツール７に特定ＤＴＣ関連情報を送信して、一旦本処理を終了する。
［２－２．効果］
第２実施形態では、第１実施形態の効果（１ａ）、（１ｂ）に加え、検査ツール７を用いて実施した車検が適切であったか否かを、後日検証することができるという利点がある。

［３．第３実施形態］
本第３実施形態は、基本的には第１実施形態と同様であるので、主に相違点について以下に説明する。なお、相違点以外は第１実施形態と同様である。また、第１実施形態と同様な構成には同一の符号を付す。

図１０に示すように、本第３実施形態の車検システム１は、検査ツール７と車両電子制御装置５とパソコン５１と管理サーバ９とを備えている。
検査ツール７は、第１実施形態のようなツール通信部を備えておらず、ケーブル５３と接続されるコネクタ５５を備えている。なお、ケーブル５３は、パソコン５１と検査ツール７とを有線にて接続するものであるが、無線にて接続するようにしてもよい。

パソコン５１は、インターネットを介して管理サーバ９に接続するように構成されている。従って、パソコン５１を操作することにより、管理サーバ９から特定ＤＴＣ情報をパソコン５１にダウンロードすることができる。さらに、パソコン５１から検査ツール７に特定ＤＴＣ情報を送信して、特定ＤＴＣ情報を検査ツール７に記憶させることができる。

このように、本第３実施形態では、検査ツール７にツール通信部を設けずに、ツール通信部の機能を有する外部の通信装置（即ちパソコン５１）を用いて、管理サーバ９と通信を行う。つまり、外部の通信装置と検査ツール７とを、有線又は無線にて接続して、前記第１実施形態の検査ツール７と同様に機能するように構成している。

本第３実施形態は、第１実施形態と同様な効果を奏する。また、検査ツール７を簡易化できるという利点がある。
なお、パソコン５１に代えて、例えばスマートフォン等のインターネットに接続可能な端末を採用することもできる。つまり、外部の通信装置としては、スマートフォン等の通信端末を採用できる。

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

（１）前記実施形態では、検査ツールを用いて、特定ＤＴＣの検査や車検の合否判定などを行ったが、スマートフォン等の通信端末やパソコン等に、検査ツールと同様な機能を実現できるアプリケーションを格納して、スマートフォン等の通信端末やパソコン等に、前記実施形態の検査ツールと同様な機能を持たせてもよい。

（２）また、車両ＥＣＵのコネクタのポートに、周知のＶＣＩを接続する場合には、ＶＣＩと通信するように、検査ツール、スマートフォン等の通信端末、パソコン等を構成することにより、前記実施形態と同様な効果を得ることができる。なお、ＶＣＩは、Vehicle Communication Interfaceの略である。

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

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

３：車両、５：車両電子制御装置、７：検査ツール、１３：診断システム、２３：車両記憶部、２７：車両取得部、２９：車両判定部、３１：車両処理部

Claims (8)

1. 車両（３）に搭載された車両電子制御装置（５）であって、
   前記車両の異常を示す故障コードであるＤＴＣを記憶するように構成された記憶部（２３）と、
   検査ツール（７）から、前記ＤＴＣのうち前記車両の状態の判定に用いる特定の故障コードである特定ＤＴＣの読み出し要求があった場合に、前記検査ツールから、前記特定ＤＴＣを含む特定ＤＴＣ情報を管理サーバ（９）から最後に受信した時期を示す第１の時期情報を取得するとともに、前記読み出し要求の時期を示す第２の時期情報を取得するように構成された取得部（２７）と、
   前記第１の時期情報と前記第２の時期情報とが示す時期を比較し、両時期情報が示す時期の時間間隔である経過時間が、所定の判定時間以上か否かを判定するように構成された判定部（２９）と、
   前記判定の結果に応じた処理を行う処理部（３１）と、
   を備えた、車両電子制御装置。
2. 請求項１に記載の車両電子制御装置であって、
   前記経過時間が前記判定時間以上の場合には、前記検査ツールに対して、前記特定ＤＴＣ情報の更新を要求するように構成された、
   車両電子制御装置。
3. 請求項１に記載の車両電子制御装置であって、
   前記経過時間が前記判定時間以上の場合には、前記読み出し要求を拒否する否定応答を送信、又は、無応答とするように構成された、
   車両電子制御装置。
4. 請求項１から３のいずれか１項に記載の車両電子制御装置であって、
   前記経過時間が前記判定時間未満の場合には、前記検査ツールに対して、前記特定ＤＴＣ、または、前記特定ＤＴＣを含む前記ＤＴＣを送信するように構成された、
   車両電子制御装置。
5. 請求項４に記載の車両電子制御装置であって、
   前記送信した情報を示す送信情報と、前記送信した情報の送信時期を示す送信時期情報と、を記憶するように構成された、
   車両電子制御装置。
6. 請求項５に記載の車両電子制御装置であって、
   前記送信情報と前記送信時期情報とが、外部からの要求によって読み出し可能なように構成された、
   車両電子制御装置。
7. 請求項１から６のいずれか１項に記載の車両電子制御装置であって、
   前記第１の時期情報として、前記特定ＤＴＣ情報を更新した更新時期の情報、および／または、前記更新時期を特定できる固有情報を用いる、
   車両電子制御装置。
8. 車両に搭載され、該車両の異常を示す故障コードであるＤＴＣを記憶するように構成された、車両電子制御装置と、
   前記ＤＴＣのうち前記車両の状態の判定に用いる特定の故障コードである特定ＤＴＣを含む特定ＤＴＣ情報を管理サーバから受信して記憶し、且つ、前記管理サーバから前記特定ＤＴＣ情報を最後に受信した時期を示す第１の時期情報を記憶するように構成された、検査ツールと、
   を備えており、
   前記車両電子制御装置は、
   前記検査ツールから前記特定ＤＴＣの読み出し要求があった場合に、前記検査ツールから前記第１の時期情報を取得するとともに、前記読み出し要求の時期を示す第２の時期情報を取得するように構成された取得部と、
   前記第１の時期情報と前記第２の時期情報とが示す時期を比較し、両時期情報が示す時期の時間間隔である経過時間が、所定の判定時間以上か否かを判定するように構成された判定部と、
   前記判定の結果に応じた処理を行う処理部と、
   を備えた、診断システム。

Images