(57)【要約】【課題】ＥＣＵにおける複数ツールからのダイアグ関連処理を簡素化すると共に、ダイアグ用フレームへの使用が定められている識別情報の枯渇を防ぐ。【解決手段】セントラルＧＷは、複数ＬＡＮに接続されたＥＣＵと、該ＥＣＵの故障診断を行う１ｓｔツールとの間のダイアグ用フレームの送受信を中継する。また、センタと無線通信を行う２ｎｄツール（ＤＣＭ）がいずれかのＬＡＮに接続されており、セントラルＧＷは、センタからの指示に応じて故障診断を行う２ｎｄツール（ＤＣＭ）と、各ＥＣＵとの間のダイアグ用フレームの送受信を中継する。そして、該２ｎｄツール（ＤＣＭ）とＥＣＵとの間の中継の際、ダイアグ用フレームのＩＤを、１ｓｔツールによる故障診断で用いられるＩＤに変換する（Ｓ１０５，Ｓ１２５）。【選択図】図３
2014078801.tif 000002
【特許請求の範囲】
【請求項１】
複数のダイアグ用ツール（５２，６０）から、自車両に搭載されたＥＣＵ（３１，３２，４１，４２，５１，５２）の故障診断を行うためのダイアグ要求を受信する要求受信手段（１３，１５）と、
予め定められた前記ダイアグ要求である対象ダイアグ要求の識別情報である第１識別情報と、これに対応する他の識別情報である第２識別情報とを示す要求変換情報を記憶している要求記憶手段（１６）と、
前記要求変換情報に基づき、前記対象ダイアグ要求に含まれる前記第１識別情報を、対応する前記第２識別情報に変換する要求変換手段（Ｓ１０５）と、
前記要求受信手段が受信した前記ダイアグ要求を前記ＥＣＵが接続された車内ＬＡＮ（３０，４０，５０）に送出すると共に、前記対象ダイアグ要求については、前記要求変換手段により前記第１識別情報を前記第２識別情報に変換した後に前記車内ＬＡＮに送出する要求送出手段（１１〜１３）と、
前記ダイアグ要求の応答として前記ＥＣＵにより前記車内ＬＡＮに送出されたダイアグ応答を受信する応答受信手段（１１〜１３）と、
前記対象ダイアグ要求の応答となる前記ダイアグ応答の識別情報である第３識別情報と、これに対応する他の識別情報である第４識別情報とを示す応答変換情報を記憶している応答記憶手段（１６）と、
前記応答変換情報に基づき、前記対象ダイアグ要求の応答となる前記ダイアグ応答に含まれる前記第３識別情報を、対応する前記第４識別情報に変換する応答変換手段（Ｓ１２５）と、
前記応答受信手段が受信した前記ダイアグ応答を、該ダイアグ応答に係る前記ダイアグ要求の送信元に送信すると共に、前記対象ダイアグ要求の応答となる前記ダイアグ応答については、前記応答変換手段により前記第３識別情報を前記第４識別情報に変換した後に該送信元に送信する応答送信手段（１３，１５）と、
を備えることを特徴とする中継装置（１０）。
【請求項２】
請求項１に記載の中継装置において、
前記第１識別情報と前記第４識別情報とは、前記ＥＣＵにおける前記車内ＬＡＮを介した通信に関しての通信プロトコルにより、前記故障診断への使用が定められていない識別情報であると共に、前記第２識別情報と前記第３識別情報とは、前記通信プロトコルにより、前記故障診断への使用が定められた識別情報であること、
を特徴とする中継装置。
【請求項３】
請求項１または請求項２に記載の中継装置において、
前記ダイアグ用ツールのうちの少なくとも一つは、専用の伝送路（２０）により当該中継装置に一時的に接続される外部接続ツール（６０）として構成されていると共に、前記ダイアグ用ツールのうちの少なくとも一つは、外部に設置されたセンタ（７０）または装置と無線通信を行う前記ＥＣＵであり、前記ダイアグ要求として前記対象ダイアグ要求を送信する通信用ＥＣＵ（５２）として構成されており、
前記要求受信手段は、前記伝送路を介して前記外部接続ツールから前記ダイアグ要求を受信すると共に、前記通信用ＥＣＵが前記車内ＬＡＮに送出した前記対象ダイアグ要求を受信し、
前記応答送信手段は、前記外部接続ツールからの前記ダイアグ要求の応答として受信した前記ダイアグ応答を、前記伝送路を介して該外部接続ツールに送信すると共に、前記対象ダイアグ要求の応答として受信した前記ダイアグ応答を前記車内ＬＡＮに送出することで、該ダイアグ応答を、該対象ダイアグ要求の送信元である前記通信用ＥＣＵに送信すること、
を特徴とする中継装置。
【請求項４】
請求項１から請求項３のうちのいずれか１項に記載の中継装置において、
前記要求送出手段により前記ダイアグ要求が前記車内ＬＡＮに先に送出された後、前記応答受信手段が、該ダイアグ要求の応答として前記ダイアグ応答を受信するまでの間に、前記要求受信手段が前記ダイアグ要求を新たに受信すると、前記要求送出手段により新たに送出される該ダイアグ要求に含まれる前記識別情報と、前記要求送出手段により先に送出された前記ダイアグ要求に含まれる前記識別情報とが一致する場合には、新たに受信した前記ダイアグ要求の送信元に対し、予め定められた時間が経過した後に該ダイアグ要求を再送することを要求する再送要求を送信する再送要求手段（Ｓ１６５，Ｓ１７５）をさらに備えること、
を特徴とする中継装置。
【請求項５】
請求項１から請求項４のうちのいずれか１項に記載の中継装置において、
優先度の高い前記故障診断を行う前記ダイアグ用ツールを優先ツールとすると共に、該優先ツール以外の他の前記ダイアグ用ツールを非優先ツールとし、前記非優先ツールから、いずれかの前記ＥＣＵの前記故障診断を行うための前記ダイアグ要求を受信した後、該故障診断が終了する前に、前記優先ツールから、該ＥＣＵの前記故障診断を行う為の前記ダイアグ要求を受信すると、前記要求送出手段による該非優先ツールから受信した前記ダイアグ要求の送出と、前記応答送信手段による該非優先ツールに対する前記ダイアグ応答の送信とを中止させる調停手段（Ｓ２２０）と、
前記非優先ツールから、いずれかの前記ＥＣＵの前記故障診断を行うための前記ダイアグ要求を受信した後、該故障診断が終了する前に、前記優先ツールから、該ＥＣＵの前記故障診断を行う為の前記ダイアグ要求を受信すると、該優先ツールに対し、予め定められた時間が経過した後に該ダイアグ要求を再送することを要求する再送要求を送信する遅延手段（１５，Ｓ２２５）と、
をさらに備えることを特徴とする中継装置。
【請求項６】
請求項５に記載の中継装置において、
前記優先ツールとは前記外部接続ツールであり、前記非優先ツールとは前記通信用ＥＣＵであること、
を特徴とする中継装置。
【請求項７】
請求項５に記載の中継装置において、
前記優先ツールとは前記通信用ＥＣＵであり、前記非優先ツールとは前記外部接続ツールであること、
を特徴とする中継装置。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、ダイアグ用ツールと、ダイアグの対象となるＥＣＵとの間の通信を中継する車載用の中継装置に関する。
【背景技術】
【０００２】
従来、車載システムに用いられる車内ＬＡＮの通信規格としてＣＡＮが知られていると共に、ディーラー等においてＤＬＣコネクタを介してＣＡＮにサービスツールを接続し、該車載システムを構成するＥＣＵの故障診断（ダイアグ）を行うことが知られている。
【０００３】
また、外部と無線通信を行うＥＣＵが知られており、このようなＥＣＵの一例として、携帯装置と無線通信を行い、携帯装置を介したリモート操作を受け付ける遠隔操作装置が知られている（特許文献１）。
【０００４】
また、これ以外にも、無線通信回線網にアクセスするＤＣＭ等が知られており、このようなＥＣＵにより外部に設置されたリモートツールと無線通信を行い、ＣＡＮを経由して車載システムを構成する各ＥＣＵの故障診断を行うことが知られている。
【０００５】
さらに、このようなサービスツールとリモートツールの双方を使用してＥＣＵのダイアグを行うことができる車載システムも知られている。
【先行技術文献】
【特許文献】
【０００６】
【特許文献１】特開２００６−３４７３３３号公報
【発明の概要】
【発明が解決しようとする課題】
【０００７】
ここで、ＣＡＮにおいて送受信されるフレームには、当該フレームの優先順位を示すと共に、当該フレームの用途や種類等を示す１１ビット（或いは２９ビット）のＩＤ（識別情報）が含まれている。そして、ＩＳＯの通信プロトコルでは、ダイアグ用のフレームのＩＤ（１１ビット）として０ｘ７００〜０ｘ７ＦＦを使用することが定められている。
【０００８】
このように、様々な通信規格の通信プロトコルにおいて、ダイアグ用のフレームに用いることができる識別情報に制限が設けられている場合がある。しかしながら、今後、ダイアグ用のツールがさらに多様化することや、車両に搭載されるＥＣＵが増加することが予想され、これにより、このような識別情報が枯渇するおそれがある。
【０００９】
また、各ＥＣＵは、受信したフレームの識別情報の種類に応じて異なる処理を行う必要があり、ダイアグ用のツールの多様化等によりダイアグ用の識別情報が増加すると、ＥＣＵのダイアグ関連処理が複雑化してしまうという問題があった。
【００１０】
本願発明は上記課題に鑑みてなされたものであり、ＥＣＵにおけるダイアグ関連処理を簡素化すると共に、ダイアグ用としての使用が定められている識別情報の枯渇を防ぐことができる中継装置を提供することを目的とする。
【課題を解決するための手段】
【００１１】
上記課題に鑑みてなされた請求項１に係る中継装置は、複数のダイアグ用ツールから、自車両に搭載されたＥＣＵの故障診断を行うためのダイアグ要求を受信する要求受信手段と、予め定められたダイアグ要求である対象ダイアグ要求の識別情報である第１識別情報と、これに対応する他の識別情報である第２識別情報とを示す要求変換情報を記憶している要求記憶手段と、要求変換情報に基づき、対象ダイアグ要求に含まれる第１識別情報を、対応する第２識別情報に変換する要求変換手段と、を備える。
【００１２】
また、要求受信手段が受信したダイアグ要求をＥＣＵが接続された車内ＬＡＮに送出すると共に、対象ダイアグ要求については、要求変換手段により第１識別情報を第２識別情報に変換した後に車内ＬＡＮに送出する要求送出手段と、ダイアグ要求の応答としてＥＣＵにより車内ＬＡＮに送出されたダイアグ応答を受信する応答受信手段と、対象ダイアグ要求の応答となるダイアグ応答の識別情報である第３識別情報と、これに対応する他の識別情報である第４識別情報とを示す応答変換情報を記憶している応答記憶手段と、を備える。
【００１３】
また、応答変換情報に基づき、対象ダイアグ要求の応答となるダイアグ応答に含まれる第３識別情報を、対応する第４識別情報に変換する応答変換手段と、応答受信手段が受信したダイアグ応答を、該ダイアグ応答に係るダイアグ要求の送信元に送信すると共に、対象ダイアグ要求の応答となるダイアグ応答については、応答変換手段により第３識別情報を第４識別情報に変換した後に該送信元に送信する応答送信手段と、を備える。
【００１４】
なお、ダイアグ要求やダイアグ応答とは、例えば、単一のフレームとして構成されていても良いし、複数のフレームから構成されるメッセージとして構成されていても良い。また、フレームとは、１回の送受信において車内ＬＡＮ等に送出されるデータであることを念のため付言しておく。
【００１５】
ＥＣＵに対し故障診断を指示するダイアグ要求のフレーム或いはメッセージ（以後、単にフレーム等と記載）や、ダイアグ要求の応答となるダイアグ応答のフレーム等は、その種類，用途等に応じて定められる識別情報（ＩＤ）を有している。
【００１６】
そして、上述したＩＳＯにおけるＣＡＮの通信プロトコルのように、車内ＬＡＮの通信プロトコル等により、ダイアグ用のフレーム等の識別情報となる値に制限が加えられる場合がある。
【００１７】
これに対し、請求項１に係る中継装置によれば、制限外の識別情報を有するダイアグ要求のフレーム等をＥＣＵに中継する際に、要求変換情報に基づき、該識別情報を、同じ種類，用途等を示す制限内の識別情報に変換することができる。また、識別情報を変換したダイアグ要求のフレーム等の応答として、制限内の識別情報を有するダイアグ応答のフレーム等を受信した場合には、応答変換情報に基づき、該識別情報を、同じ種類，用途等を示す制限外の識別情報に変換し、ダイアグ用ツールに中継することができる。
【００１８】
このため、各ＥＣＵに、制限外の識別情報を有するダイアグ要求やダイアグ応答のフレーム等に対応する処理（換言すれば、複数のダイアグ用ツールに対応するダイアグ用のフレーム等に対応する処理）を設けなくても、これらのフレーム等を用いた故障診断が可能となり、各ＥＣＵにおけるダイアグ関連処理を簡素化することができる。
【００１９】
また、ＥＣＵの構成を改変すること無く、故障診断に用いる制限外の識別情報を有するダイアグ用のフレーム等の種類を増やすことができる。このため、ダイアグ用ツールの新設や、ダイアグ用ツールの改変等に伴いダイアグ用のフレーム等の種類が増加しても、制限外の識別情報を容易に使用することができ、制限内の識別情報が枯渇してしまうことを防ぐことができる。
【００２０】
このように、請求項１に係る中継装置によれば、ＥＣＵにおけるダイアグ関連処理を簡素化すると共に、ダイアグ用のフレーム等への使用が定められている識別情報の枯渇を防ぐことができる。
【００２１】
なお、請求項２に記載されているように、第１識別情報と第４識別情報とは、ＥＣＵにおける車内ＬＡＮを介した通信に関しての通信プロトコルにより、故障診断への使用が定められていない識別情報であると共に、第２識別情報と第３識別情報とは、通信プロトコルにより、故障診断への使用が定められた識別情報であっても良い。
【００２２】
このような構成によれば、ＥＣＵの通信プロトコルで定義されていない識別情報を有するダイアグ用のフレーム等を使用して故障診断を行うダイアグ用ツールが用いられる場合であっても、ＥＣＵにおけるダイアグ関連処理の簡素化することができる。
【００２３】
また、ダイアグ用ツールの種類や故障診断の対象となるＥＣＵが増加し、ダイアグ用のフレーム等の種類が増加した場合であっても、通信プロトコルで定義されていない識別情報を容易に使用することができ、通信プロトコルで定義された識別情報の枯渇を防ぐことができる。
【図面の簡単な説明】
【００２４】
【図１】車載システムの構成を示すブロック図である。
【図２】セントラルＧＷの構成を示すブロック図である。
【図３】ダイアグ用のフレームを中継する際の処理を示すフローチャートである。
【図４】１ｓｔツールによる故障診断を優先させるための調停を行う処理を示すフローチャートである。
【図５】１ｓｔツール，２ｎｄツールの双方による故障診断の同時進行を防ぐための調停を行う処理を示すフローチャートである。
【図６】１ｓｔツールによる故障診断を優先させるための調停を行う処理を示すフローチャートである。
【発明を実施するための形態】
【００２５】
以下、本発明の実施形態について図面を用いて説明する。なお、本発明の実施の形態は、下記の実施形態に何ら限定されることはなく、本発明の技術的範囲に属する限り種々の形態を採りうる。
【００２６】
［構成の説明］
図１は、本実施形態におけるセントラルＧＷ１０等から構成される車載システムの構成を示すブロック図である。
【００２７】
セントラルＧＷ１０は、Ａ，ＢＥＣＵ３１，３２等が接続されている車内ＬＡＮである第１ＬＡＮ３０や、Ｃ，ＤＥＣＵ４１，４２等が接続されている車内ＬＡＮである第２ＬＡＮ４０に接続されている。また、ＥＥＣＵ５１や、無線通信回線網にアクセスするＤＣＭ（Data Communication Module）５２等が接続されている車内ＬＡＮである第３ＬＡＮ５０にも接続されており、異なるＬＡＮに接続されたＥＣＵ間の通信を中継するよう構成されている。
【００２８】
なお、セントラルＧＷ１０は、中継専用のＥＣＵとして構成されていても良いし、ナビゲーション装置やエアコン等、特定の機能を持つＥＣＵとして構成されていても良い。
また、本実施形態では、第１〜第３ＬＡＮ３０〜５０は、一例としてＣＡＮとして構成されている（無論、これらのＬＡＮはＣＡＮ以外の通信規格に準拠していても良い）。
【００２９】
また、セントラルＧＷ１０は、一例としてＣＡＮとして構成され、ＤＬＣコネクタ２１が設けられた伝送路２０に接続されており、このＤＬＣコネクタ２１には、各ＥＣＵの故障診断を行う１ｓｔツール６０が一時的に接続される。なお、この１ｓｔツール６０は、例えば、ディーラー等に設けられたサービスツールや、法規上定められた故障診断を行う法規ツール等として構成されている。
【００３０】
そして、ＤＬＣコネクタ２１に１ｓｔツール６０が接続され、ＥＣＵの故障診断が開始されたとする。このとき、セントラルＧＷ１０は、伝送路２０を介して、１ｓｔツール６０から、ＥＣＵに対し故障診断のための処理を指示するダイアグ要求フレームを受信すると共に、これを第１〜第３ＬＡＮ３０〜５０に送出する。
【００３１】
その後、該ダイアグ要求フレームへの応答として、いずれかのＥＣＵにより第１〜第３ＬＡＮ３０〜５０にダイアグ応答フレームが送出されると、セントラルＧＷ１０は該ダイアグ応答フレームを受信し、伝送路２０を介して１ｓｔツール６０に送信する。
【００３２】
このため、ＤＬＣコネクタ２１に接続された１ｓｔツール６０は、セントラルＧＷ１０を介して車載システムを構成する各ＥＣＵとダイアグ用フレームの送受信を行い、これらのＥＣＵの故障診断を行うことが可能となる。
【００３３】
一方、第３ＬＡＮ５０に接続された２ｎｄツール（ＤＣＭ５２）は、自車両のＥＣＵの故障診断を行うセンタ７０（携帯電話やスマートフォン等であっても良い）と無線通信回線網を介して通信可能に構成されている。そして、センタ７０により故障診断が指示されるか、当該２ｎｄツール（ＤＣＭ５２）において予め定められた駆動条件が満たされると、２ｎｄツール（ＤＣＭ５２）は、第３ＬＡＮ５０にダイアグ要求フレームを送出する。セントラルＧＷ１０は、該ダイアグ要求フレームを受信すると共に、該ダイアグ要求フレームのＩＤを変換し（詳細は後述する）、第１〜第３ＬＡＮ３０〜５０に送出する。
【００３４】
その後、該ダイアグ要求フレームへの応答として、いずれかのＥＣＵにより第１〜第３ＬＡＮ３０〜５０にダイアグ応答フレームが送出されると、セントラルＧＷ１０は、該ダイアグ応答フレームを受信する。そして、該ダイアグ応答フレームのＩＤを変換した後（詳細は後述する）、第３ＬＡＮ５０に送出すると共に、２ｎｄツール（ＤＣＭ５２）は、該ダイアグ応答フレームを受信し、該ダイアグ応答の内容をセンタ７０に送信する。
【００３５】
このようにして、セントラルＧＷ１０は、センタ７０からの指示或いは駆動条件が満たされたことに応じて故障診断を行う２ｎｄツール（ＤＣＭ５２）と、故障診断の対象となるＥＣＵとの間のダイアグ用フレームの送受信を中継する。これにより、センタ７０は、２ｎｄツール（ＤＣＭ５２），セントラルＧＷ１０を介して車載システムを構成する各ＥＣＵと通信を行い、これらのＥＣＵの故障診断を行うことが可能となる。
【００３６】
次に、図２を用いてセントラルＧＷ１０の構成について説明する。セントラルＧＷ１０は、第１ＬＡＮ３０を介した通信を行う第１通信部１１と、第２ＬＡＮ４０を介した通信を行う第２通信部１２と、第３ＬＡＮ５０を介した通信を行う第３通信部１３と、伝送路２０を介した通信を行う第４通信部１５を備える。また、制御部１４と、記憶保持動作が不要なデバイス（例えば、フラッシュメモリ）から構成された記憶部１６を備える。
【００３７】
なお、制御部１４は、ＣＰＵ、ＲＯＭ、ＲＡＭ、Ｉ／Ｏ及びこれらを接続するバスライン等からなる周知のマイクロコンピュータを中心に構成され、ＲＯＭに記憶されたプログラムに従いセントラルＧＷ１０を統括制御する。
【００３８】
［動作の説明］
（１）ダイアグ用フレームの中継について
まず、故障診断の際、セントラルＧＷ１０がダイアグ用フレームを中継する処理について説明する。
【００３９】
ＣＡＮで用いられるフレームには、優先順位を示す１１ビットのＩＤが含まれており（ＩＤの値が小さいほど優先順位が高くなる）、ＩＤは、フレームの種類や、用途や、送信元や、送信先等に応じて定められる。
【００４０】
そして、ＩＳＯにおける通信プロトコルでは、ダイアグ用フレームのＩＤとして、０ｘ７００〜０ｘ７ＦＦを用いることが定められている。
本実施形態の車載システムを構成する各ＥＣＵは、０ｘ７００〜０ｘ７ＦＦのＩＤが用いられたフレームを使用した故障診断に対応しており、１ｓｔツール６０によるＥＣＵの故障診断では、これらのフレームが用いられる。
【００４１】
しかし、センタ７０からの指示に応じて２ｎｄツール（ＤＣＭ５２）により行われる故障診断では、０ｘ７００〜０ｘ７ＦＦではなく、これ以外のＩＤ（例えば、０ｘ０００〜０ｘ６ＦＦのＩＤ）が用いられたフレームが使用される。このため、セントラルＧＷ１０は、２ｎｄツール（ＤＣＭ５２）とＥＣＵとの間の中継を行う際には、フレームのＩＤを、１ｓｔツール６０による故障診断において同様の種類，用途等を示す０ｘ７００〜０ｘ７ＦＦのＩＤに変換する。
【００４２】
以下では、セントラルＧＷ１０が、ダイアグ用フレームを中継する際の処理について、図３を用いて詳しく説明する。
センタ７０からの指示、或いは、駆動条件が満たされたことに応じて、２ｎｄツール（ＤＣＭ５２）が、第３ＬＡＮ５０に、いずれかのＥＣＵに対し故障診断のためのダイアグ処理を指示するダイアグ要求フレーム（ＩＤは０ｘ６０１）を送出したとする（Ｓ１００）。このとき、セントラルＧＷ１０の制御部１４は、第３通信部１３を介して、該ダイアグ要求フレームを受信する。
【００４３】
なお、ダイアグ要求フレームとは、例えば、所定のアドレスのメモリの内容を読み出す指示（データモニタ）が考えられる。また、これ以外にも、異常発生時における車速，エンジン回転数等の車両状態を示すデータであるフリーズドフレームデータ（ＦＦＤ（Freezed Frame Data）とも記載）の送信要求等が考えられる。
【００４４】
そして、セントラルＧＷ１０の制御部１４は、記憶部１６に保存されている変換情報に基づき、受信したダイアグ要求フレームのＩＤを０ｘ７０１に変換する（Ｓ１０５）。
この変換情報とは、２ｎｄツール（ＤＣＭ５２）で使用される各ＩＤ（０ｘ０００〜０ｘ６ＦＦ）と、１ｓｔツール６０で使用される各ＩＤ（０ｘ７００〜０ｘ７ＦＦ）とについて、同様の種類，用途等を示すもの同士の対応関係を示す情報である。変換情報に基づき、２ｎｄツール（ＤＣＭ５２）に対応するダイアグ用フレームのＩＤが、１ｓｔツール６０に対応するダイアグ用フレームのＩＤ（通信プロトコルに定義されたＩＤ）に変換される。
【００４５】
続くＳ１１０では、セントラルＧＷ１０の制御部１４は、第１〜第３通信部１１〜１３を介して、変換後のダイアグ要求フレームを第１〜第３ＬＡＮ３０〜５０に送出する。
そして、例えばＡＥＣＵ３１が該ダイアグ要求フレームを受信すると、これに応じてダイアグ処理を行うと共に（Ｓ１１５）、応答のためのデータフレームであるダイアグ応答フレーム（ＩＤは０ｘ７０９）を生成し、第１ＬＡＮ３０に送出する（Ｓ１２０）。
【００４６】
その後、セントラルＧＷ１０の制御部１４は、第１通信部１１を介してダイアグ応答フレームを受信すると共に、記憶部１６に保存されている変換情報に基づき、該ダイアグ応答フレームのＩＤを０ｘ６０９に変換する（Ｓ１２５）。
【００４７】
続くＳ１３０では、セントラルＧＷ１０の制御部１４は、第３通信部１３を介して、変換後のダイアグ応答フレームを第３ＬＡＮ５０に送出する。２ｎｄツール（ＤＣＭ５２）は該ダイアグ応答フレームを受信し、これにより、２ｎｄツール（ＤＣＭ５２）とＡＥＣＵ３１との間のダイアグ用フレームの送受信が成立する。
【００４８】
一方、１ｓｔツール６０が、伝送路２０にダイアグ要求フレーム（ＩＤは０ｘ７０１）を送出すると（Ｓ１３５）、セントラルＧＷ１０の制御部１４は、第４通信部１５を介して、該ダイアグ要求フレームを受信する。そして、該ダイアグ要求フレームを第１〜第３ＬＡＮ３０〜５０に送出する（Ｓ１４０）。
【００４９】
その後、例えばＡＥＣＵ３１が該ダイアグ要求フレームを受信すると、これに応じてダイアグ処理を行うと共に（Ｓ１４５）、ダイアグ応答フレーム（ＩＤは０ｘ７０９）を生成して第１ＬＡＮ３０に送出する（Ｓ１５０）。
【００５０】
これに対し、セントラルＧＷ１０の制御部１４は、第１ＬＡＮ３０に送出されたダイアグ応答フレームを受信すると共に、第４通信部１５を介して該ダイアグ応答フレームを伝送路２０に送出する。１ｓｔツール６０は該ダイアグ応答フレームを受信し、これにより、１ｓｔツール６０とＡＥＣＵ３１との間のダイアグ用フレームの送受信が成立する。
【００５１】
ここで、セントラルＧＷ１０が、２ｎｄツール（ＤＣＭ５２）からダイアグ要求フレームを受信し、ＩＤを変換して中継した後、応答を受信するまでの期間に、１ｓｔツール６０から、中継したダイアグ要求フレームのＩＤ（変換後のＩＤ）と同一のＩＤを有する新たなダイアグ要求フレームを受信したとする。
【００５２】
このような場合、セントラルＧＷ１０が新たなダイアグ要求フレームを中継してしまうと、セントラルＧＷ１０は、応答としてＥＣＵから受信したダイアグ応答フレームを、１ｓｔツール６０と２ｎｄツール（ＤＣＭ５２）のどちらに中継すべきか判別できなくなる。
【００５３】
このため、セントラルＧＷ１０の制御部１４は、２ｎｄツール（ＤＣＭ５２）からのダイアグ要求フレームを中継した後（Ｓ１１０）、ダイアグ応答フレームを受信する（Ｓ１２０）までの間に、１ｓｔツール６０からＩＤが０ｘ７０１であるダイアグ要求フレームを受信すると（Ｓ１６０）、１ｓｔツール６０に対し、一定時間経過後に同一フレームを再送することを指示するＮＲＣを送信する（Ｓ１６５）。
【００５４】
また、セントラルＧＷ１０が１ｓｔツール６０からのダイアグ要求フレームを中継した後、応答を受信するまでの期間に、２ｎｄツール（ＤＣＭ５２）から、変換後のＩＤが、先に中継したダイアグ要求フレームのＩＤと同一となる新たなダイアグ要求フレームを受信したとする。
【００５５】
このような場合も、セントラルＧＷ１０は、新たなダイアグ要求フレームのＩＤを変換し、該ダイアグ要求フレームを中継してしまうと、応答としてＥＣＵから受信した該ダイアグ応答フレームを、１ｓｔツール６０と２ｎｄツール（ＤＣＭ５２）のどちらに中継すべきか判別できなくなる。
【００５６】
このため、セントラルＧＷ１０の制御部１４は、１ｓｔツール６０からのダイアグ要求フレームを中継した後（Ｓ１４０）、ダイアグ応答フレームを受信する（Ｓ１５０）までの間に、２ｎｄツール（ＤＣＭ５２）からＩＤが０ｘ６０１であるダイアグ要求フレームを受信すると（Ｓ１７０）、２ｎｄツール（ＤＣＭ５２）に対し、一定時間経過後に同一フレームを再送することを指示するＮＲＣを送信する（Ｓ１７５）。
【００５７】
こうすることにより、先に中継したダイアグ要求フレームに対する応答を、確実に、該ダイアグ要求フレームの送信元に中継することができると共に、後に受信するダイアグ要求フレームに対する応答を、確実に、該ダイアグ要求フレームの送信元に中継することができる。
【００５８】
なお、ＡＥＣＵ３１が先優先（詳細は後述する）に従い構成されていた場合、ＡＥＣＵ３１は、ダイアグ要求フレームに基づくダイアグ処理（Ｓ１１５，Ｓ１４５）の実行中に新たなダイアグ要求フレームを受信したとしても、該ダイアグ要求フレームを受け付けず、応答としてＮＲＣを送信すると考えられる。
【００５９】
このため、このような場合には、セントラルＧＷ１０は、Ｓ１６０やＳ１７０においてダイアグ要求フレームを受信すると、該ダイアグ要求フレームを中継しても良い。そして、その後、該ダイアグ要求フレームへの応答として送信されたＮＲＣを受信すると、該ＮＲＣを、ダイアグ要求フレームの送信元に中継しても良い。このような場合であっても、１ｓｔツール６０や２ｎｄツール（ＤＣＭ５２）に対し、ダイアグ要求フレームの再送を指示することができる。
【００６０】
このようなセントラルＧＷ１０を用いることで、各ＥＣＵに、１ｓｔツール６０用のＩＤ以外のダイアグ用ＩＤに対応する処理を設けなくても、センタ７０による故障診断が可能となる。すなわち、各ＥＣＵでは、１ｓｔツール６０用のＩＤ以外のダイアグ用ＩＤを使用する２ｎｄツール（ＤＣＭ５２）が故障診断に用いられることを考慮した処理を行う必要が無く、各ＥＣＵにおけるダイアグ関連処理を簡素化することができる。
【００６１】
また、各ＥＣＵの構成を改変すること無く、２ｎｄツール（ＤＣＭ５２）への対応ができると共に、ダイアグ用ＩＤを無駄なく使用することができる。このため、ＥＣＵの増加による１ｓｔツール６０用のＩＤ確保や、２ｎｄツール（ＤＣＭ５２）の新設等といったツールの増加等に伴い、必要となるダイアグ用のＩＤが増加しても、ダイアグ用フレームのＩＤとして通信プロトコルに定義されていないＩＤを用いることにより容易に対応することができる。これにより、ダイアグ用フレームのＩＤとして通信プロトコルに定義されたＩＤの枯渇を防ぐことができる。
【００６２】
また、セントラルＧＷ１０を用いることで、２ｎｄツール（ＤＣＭ５２）による故障診断を考慮すること無く、各ＥＣＵで用いられる各ダイアグ用フレームのＩＤを、通信プロトコルで定められた範囲内で自由に設定することができる。また、２ｎｄツール（ＤＣＭ５２）以外の新たなツールの新設や改変等により、ダイアグ用フレームのＩＤとして通信プロトコルに定義されていないＩＤの使用状態が変化した場合であっても、ＥＣＵで用いられる既存のダイアグ用フレームのＩＤを変更する必要は無い。
【００６３】
また、既存のＥＣＵは、１ｓｔツール６０による故障診断（通信プロトコルに定義されたＩＤが用いられる故障診断）には対応しているが、２ｎｄツール（ＤＣＭ５２）による故障診断（通信プロトコルに定義されていないＩＤが用いられる故障診断）には対応していないという可能性がある。
【００６４】
これに対し、セントラルＧＷ１０では、２ｎｄツール（ＤＣＭ５２）での故障診断に用いられるダイアグ用フレームのＩＤが、１ｓｔツール６０での故障診断に用いられるダイアグ用フレームのＩＤに変換される。
【００６５】
このため、２ｎｄツール（ＤＣＭ５２）を用いてこのような既存のＥＣＵの故障診断を行うことができ、該ＥＣＵをそのまま車載システムに用いることが可能となる。さらに、２ｎｄツール（ＤＣＭ５２）以外の新たなツールが新設された場合であっても、ＥＣＵにおける既存のダイアグ関連処理を利用して故障診断を行うことができる。
【００６６】
（２）調停について
次に、１ｓｔツール６０による故障診断を２ｎｄツール（ＤＣＭ５２）による故障診断よりも優先させたい場合に、セントラルＧＷ１０が、１ｓｔツール６０による故障診断と２ｎｄツール（ＤＣＭ５２）による故障診断を調停する処理について説明する。
【００６７】
ＣＡＮでは、１つのフレームで転送できる最大データ長は８バイトとなっており、送信したいデータが８バイトを越える場合には、複数回にわたりフレームを送信し、該データをメッセージとして転送する必要がある。
【００６８】
ここで、ＩＳＯ１５７６５の規格上、シングルフレーム（ＳＦ（Single Frame）），ファーストフレーム（ＦＦ（First Frame）），コンゼクティブフレーム（ＣＦ（Consecutive Frame）），フローコントロール（ＦＣ（Flow Control Frame））の４種類のフレームと、ツールとＥＣＵ間のフレーム送受信に関する時間規定が定められている。
【００６９】
また、ＣＡＮのアプリケーションレイヤーの通信プロトコルであるＩＳＯ１４２２９では、フレーム或いはメッセージ（フレーム等と記載）を受信中のＥＣＵは、他のフレーム等を受信してもこれを無視し、先に受信したフレーム等に基づく処理を優先して行うという規則（先優先）が定められている。
【００７０】
一方、ＣＡＮのネットワークレイヤーの通信プロトコルであるＩＳＯ１５７６５では、８バイトを越えるデータの受信中、ＥＣＵは、自装置宛のＳＦやＦＦを受信すると、データの受信を破棄し、新たな受信を受付けるという規則（後優先）が定められている。
【００７１】
そして、本実施形態のＥＣＵのアプリケーションレイヤーが先優先に従って構成されている場合において、２ｎｄツール（ＤＣＭ５２）といずれかのＥＣＵとの間で、セントラルＧＷ１０を介してダイアグデータの送受信が行われていたとする。このとき、１ｓｔツール６０から該ＥＣＵに対しダイアグ要求フレーム等が送信されたとしても、該フレーム等は受け付けられず、１ｓｔツール６０による故障診断は開始されない。
【００７２】
しかしながら、１ｓｔツール６０は、ディーラーで使用されるサービスツール等として構成されており、１ｓｔツール６０による故障診断がすぐに開始されないとなると、ディーラーにて自車両の点検を行う顧客を待たせてしまうという可能性がある。
【００７３】
これに対し、セントラルＧＷ１０では、故障診断のため、２ｎｄツール（ＤＣＭ５２）とＥＣＵとの間でのデータの送受信が行われている際に、１ｓｔツール６０による該ＥＣＵの故障診断が開始された場合には、調停が行われる。そして、２ｎｄツール（ＤＣＭ５２）による故障診断を中断させることにより、ＥＣＵが１ｓｔツール６０による故障診断を受付けられる状態にする。
【００７４】
以下では、１ｓｔツール６０による故障診断を優先させるための調停を行う処理について、図４を用いて説明する。
２ｎｄツール（ＤＣＭ５２）が、第３ＬＡＮ５０に、ＡＥＣＵ３１に対しＦＦＤの提供を指示するＳＦであるＦＦＤ読み出しを送出したとする（Ｓ２００）。このとき、セントラルＧＷ１０の制御部１４は、第３通信部１３を介して、該ＦＦＤ読み出しを受信する。
【００７５】
このＦＦＤ読み出しに用いられるＩＤは０ｘ０００〜０ｘ６ＦＦであり、セントラルＧＷ１０の制御部１４は、記憶部１６に保存されている変換情報に基づき、受信したＦＦＤ読み出しのＩＤを変換する。そして、変換後のＦＦＤ読み出しを第１〜第３ＬＡＮ３０〜５０に送出する（Ｓ２０５）。
【００７６】
そして、ＡＥＣＵ３１は、該ＦＦＤ読み出しを受信すると、ダイアグ処理を開始し（Ｓ２１０）、フラッシュメモリ等に保存されているＦＦＤを読み出す。このＦＦＤは、８バイトを越えるデータサイズを有している場合には、８バイト以下の複数のデータに分割される。
【００７７】
その後、ＡＥＣＵ３１は、分割データのうちの１つを含むＦＦであるＦＦＤ応答を生成して第１ＬＡＮ３０に送出し（Ｓ２３０）、セントラルＧＷ１０の制御部１４は、第１通信部１１を介して該ＦＦＤ応答を受信する。
【００７８】
ここで、セントラルＧＷ１０がＳ２０５にてＦＦＤ読み出しを送出した直後に、１ｓｔツール６０が、伝送路２０に、ＡＥＣＵ３１に対し所定のアドレスのメモリの内容の読み出しを指示するＳＦであるデータモニタを送出したとする（Ｓ２１５）。
【００７９】
このとき、セントラルＧＷ１０の制御部１４は、ＦＦＤ応答を受信する前にデータモニタを受信する。そして、データモニタの受信後、一定期間にわたり、２ｎｄツール（ＤＣＭ５２）による故障診断を中止させ、１ｓｔツール６０による故障診断を優先して開始させる調停処理を実行する（Ｓ２２０）。
【００８０】
この調停処理の実行中は、２ｎｄツール（ＤＣＭ５２）による故障診断のためのダイアグ用フレームの中継（ＡＥＣＵ３１と２ｎｄツール（ＤＣＭ５２）との間のダイアグ用フレームの中継）は中止される。このため、ＡＥＣＵ３１から送出されたＦＦＤ応答（Ｓ２３０）は、２ｎｄツール（ＤＣＭ５２）に中継されない。
【００８１】
また、この調停処理において、制御部１４は、データモニタの応答として、伝送路２０に、１ｓｔツール６０に対し一定時間経過後にデータモニタを再送することを指示するＳＦであるＮＲＣを送信する（Ｓ２２５）。
【００８２】
なお、既に述べたように、ＡＥＣＵ３１が先優先に従って構成されている場合、ＡＥＣＵ３１は、受信したダイアグ要求フレーム等に基づく処理の実行中は、当該ＡＥＣＵ３１宛の新たなダイアグ要求フレーム等を受信すると、例えば、応答として再送を指示するＳＦ（ＮＲＣ）の送出等を行い、新たなダイアグ要求フレーム等を受け付けない。
【００８３】
しかし、ＡＥＣＵ３１が処理を実行している場合には、ダイアグ要求フレーム等を受け取ることができない場合がある。また、既に述べたように、ＡＥＣＵ３１が先に受信したダイアグ要求フレーム等に含まれているＩＤと、中継される新たなダイアグ要求フレーム等のＩＤが同一である場合、該ダイアグ要求フレーム等への応答を受信したセントラルＧＷ１０は、該応答を、１ｓｔツール６０と２ｎｄツール（ＤＣＭ５２）のどちらに中継すべきか判別不能となるため、該新たなダイアグ要求フレーム等を中継することができない。
【００８４】
このため、セントラルＧＷ１０が自発的にＮＲＣを送信する（Ｓ２２５）ことにより、１ｓｔツール６０の処理を待たせるべく一定時間経過後にデータモニタを再送することを指示すると共に、２ｎｄツール（ＤＣＭ５２）の処理を中断させることにより、ＡＥＣＵ３１が１ｓｔツール６０の要求を受付けられる状態にする。
【００８５】
なお、ＡＥＣＵ３１が１ｓｔツール６０から受信するダイアグ要求フレーム等のＩＤと、２ｎｄツール（ＤＣＭ５２）から受信するダイアグ要求フレーム等のＩＤ（セントラルＧＷ１０による変換後のＩＤ）とが分けられており、これらのＩＤが常に異なる場合は、１ｓｔツール６０からのデータモニタを中継すると共に、該データモニタの応答としてＡＥＣＵ３１から送出されるＮＲＣを１ｓｔツール６０に中継しても良い。このような場合であれば、中継したダイアグ要求フレーム等のＩＤが被ることが無いため、１ｓｔツール６０に対し、一定時間経過後にデータモニタを再送することを指示することができる。
【００８６】
ここで、調停処理における２ｎｄツール（ＤＣＭ５２）処理の中断の方法について説明する。
まず、該中断の方法の説明に先立って、セントラルＧＷ１０にて調停処理が行われなかったとした場合に、セントラルＧＷ１０や２ｎｄツール（ＤＣＭ５２）やＡＥＣＵ３１で行われる処理（図４中の点線の矢印に対応する処理）について説明する。
【００８７】
セントラルＧＷ１０の制御部１４は、ＡＥＣＵ３１から第１ＬＡＮ３０に送出されたＦＦＤ応答を受信すると、変換情報に基づき該ＦＦＤ応答のＩＤ（０ｘ７００〜０ｘ７ＦＦ）を変換する。そして、制御部１４は、第３通信部１３を介して、ＩＤを変換したＦＦＤ応答を第３ＬＡＮ５０に送出する（Ｓ２３５）。
【００８８】
一方、２ｎｄツール（ＤＣＭ５２）は、ＦＦＤ応答を受信すると、ＦＦＤ応答の送信手順を指定するＦＣを第３ＬＡＮ５０に送出する（Ｓ２４０）。なお、本実施形態では、該ＦＣは、一例として、ＢＳ＝１に設定されており、該ＦＣに応じて１つのＦＦＤ応答フレームを送信することが指示されるが、無論、このような送信手順に限定されることは無い。
【００８９】
その後、セントラルＧＷ１０の制御部１４は、第３通信部１３を介して、第３ＬＡＮ５０に送出されたＦＣを受信すると、変換情報に基づき該ＦＣのＩＤ（０ｘ０００〜０ｘ６ＦＦ）を変換する。そして、制御部１４は、第１〜第３通信部１１〜１３を介して、ＩＤを変換した該ＦＣを第１〜第３ＬＡＮ３０〜５０に送出する（Ｓ２４５）。
【００９０】
一方、ＡＥＣＵ３１は、該ＦＣを受信すると、応答として、第１ＬＡＮ３０にＦＦＤ応答を送出し（Ｓ２５０）、セントラルＧＷ１０の制御部１４は、第１通信部１１を介して該ＦＦＤ応答を受信する。そして、制御部１４は、変換情報に基づき該ＦＦＤ応答のＩＤ（０ｘ７００〜０ｘ７ＦＦ）を変換し、第３通信部１３を介して、ＩＤを変換したＦＦＤ応答を第３ＬＡＮ５０に送出する（Ｓ２５５）。
【００９１】
しかし、セントラルＧＷ１０は、１ｓｔツール６０からのデータモニタの受信（Ｓ２１５）により調停処理が行われるため、ＡＥＣＵ３１が送信したＦＦＤ応答（Ｓ２３０）を中継しない。このため、Ｓ２３５〜Ｓ２５５の処理は実行されない。
【００９２】
また、仮に、セントラルＧＷ１０が、ＡＥＣＵ３１からＦＦＤ応答を受信し（Ｓ２３０）、これに応じてＦＦＤ応答を送出（Ｓ２３５）した後に、１ｓｔツール６０からデータモニタを受信し、これに起因して調停処理が開始されたとする。このような場合、Ｓ２４０において２ｎｄツール（ＤＣＭ５２）からＦＣが送出されることになるが、セントラルＧＷ１０は、調停処理の実行中であるため、該ＦＣを中継しない。
【００９３】
また、仮に、セントラルＧＷ１０が、ＦＦＤ応答を受信した２ｎｄツール（ＤＣＭ５２）から送出されたＦＣをＡＥＣＵ３１に中継（Ｓ２４５）した後に、１ｓｔツール６０からデータモニタを受信し、これに起因して調停処理が開始されたとする。このような場合、Ｓ２５０においてＡＥＣＵ３１からＦＦＤ応答が送出されることになるが、セントラルＧＷ１０は、調停処理の実行中であるため、該ＦＦＤ応答を中継しない。
【００９４】
また、２ｎｄツール（ＤＣＭ５２）は、ＦＦＤ読出しを送出した後（Ｓ２００）、ＦＦＤ応答の受信を待つが、ＦＦＤ読出しの送出後（Ｓ２００）から、或いは、Ｓ２４０でＦＣを送出した場合であれば該ＦＣの送出後から一定時間が経過した時点で故障診断を終了する。また、ＡＥＣＵ３１においても、ＦＣの受信を待つが、ＦＦＤ応答の送出後（Ｓ２３０）から、或いは、Ｓ２５０でＦＦＤ応答を送出した場合であれば該ＦＦＤ応答の送出後から一定時間が経過した時点でダイアグ処理が終了される。
【００９５】
また、１ｓｔツール６０は、セントラルＧＷ１０からＮＲＣを受信した後、一定時間が経過すると、伝送路２０にデータモニタを再度送出する（Ｓ２６０）。セントラルＧＷ１０の制御部１４は、該データモニタを受信すると共に、第１〜第３ＬＡＮ３０〜５０にこれを送出する（Ｓ２６５）。
【００９６】
そして、ＡＥＣＵ３１は、該データモニタを受信すると、ダイアグ処理を開始し（Ｓ２７０）、該データモニタにより指定されたメモリを読み出すと共に、読み出したデータを含むＳＦであるデータモニタ応答を生成し、第１ＬＡＮ３０に送出する（Ｓ２７５）。セントラルＧＷ１０の制御部１４は、第１ＬＡＮ３０に送出されたデータモニタ応答を受信すると共に、該データモニタ応答を伝送路２０に送出し（Ｓ２８０）、該データモニタ応答を１ｓｔツール６０に中継する。
【００９７】
このようなセントラルＧＷ１０を用いることにより、２ｎｄツール（ＤＣＭ５２）による故障診断中に、同一ＥＣＵを対象として１ｓｔツール６０による故障診断が開始された場合、２ｎｄツール（ＤＣＭ５２）による故障診断を中断させ、１ｓｔツール６０による故障診断を行うことができる。これにより、各ＥＣＵで調停を行うこと無く（換言すれば、各ＥＣＵを先優先に従った構成としたまま）、１ｓｔツール６０による故障診断を優先させることができる。
【００９８】
このため、ディーラー等においてサービスツールを用いた故障診断を確実に行うことができ、各ＥＣＵの処理負荷の増加や、処理の複雑化を防ぎつつ、各ツールによる故障診断を好適に調停することができる。
【００９９】
また、セントラルＧＷ１０によるＩＤの変換により、１ｓｔツール６０と２ｎｄツール（ＤＣＭ５２）のいずれを用いた場合であっても、セントラルＧＷ１０と故障診断の対象ＥＣＵとの間では、通信プロトコルで定義されたＩＤを有するダイアグ用フレームの送受信がなされる。
【０１００】
このため、双方のツールによる故障診断が同時進行し、セントラルＧＷ１０で各ツールのダイアグ用フレームを同時に中継している場合には、故障診断の対象ＥＣＵから受信したダイアグ応答フレームがどちらのツールへの応答か判別不可能となる場合がある。
【０１０１】
これに対し、セントラルＧＷ１０では、１ｓｔツール６０による故障診断を優先させる調停が行われるため、各ＥＣＵの処理負荷の増加や、処理の複雑化を防ぎつつ、双方のツールによる故障診断の同時進行を好適に防ぐことができる。これにより、故障診断の対象ＥＣＵから受信したダイアグ応答フレームがどちらのツールへの応答かを判別できず、処理に異常をきたしてしまうことを防ぐことができる。
【０１０２】
なお、ここでは、１ｓｔツール６０による故障診断を優先させるための調停を行う処理について説明したが、例えば、２ｎｄツール（ＤＣＭ５２）により緊急度の高い故障診断が行われている場合等には、同様の方法により２ｎｄツール（ＤＣＭ５２）による故障診断を優先させても良い。こうすることにより、緊急度の高い故障診断を速やかに行うことができる。
【０１０３】
［変形例１］
ところで、１ｓｔツール６０，２ｎｄツール（ＤＣＭ５２）の双方による故障診断が同時進行した場合には、故障診断の対象ＥＣＵから受信した応答フレームがどちらのツールへの応答か判別不可能となる場合がある。このため、セントラルＧＷ１０にて調停を行い、双方のツールによる故障診断の同時進行を防ぐことが考えられる。以下では、このような調停の一例について、図５を用いて説明する。
【０１０４】
２ｎｄツール（ＤＣＭ５２）が、第３ＬＡＮ５０に、ＡＥＣＵ３１に対するＦＦＤ読み出しを送出したとする（Ｓ３００）。このとき、セントラルＧＷ１０の制御部１４は、第３通信部１３を介して、該ＦＦＤ読み出しを受信する。
【０１０５】
このとき、セントラルＧＷ１０の制御部１４は、各ツールによる故障診断の同時進行を防ぐための調停処理を開始すると共に（Ｓ３０２）、受信したＦＦＤ読み出しのＩＤを変換した後に第１〜第３ＬＡＮ３０〜５０に送出する（Ｓ３０４）。
【０１０６】
そして、ＡＥＣＵ３１は、該ＦＦＤ読み出しを受信すると、ダイアグ処理を開始し（Ｓ３０６）、自装置の不揮発性メモリ等に保存されているＦＦＤを読み出す。このＦＦＤが８バイトを越える場合は、８バイト以下の複数のデータに分割される。
【０１０７】
その後、ＡＥＣＵ３１は、分割データのうちの１つを含むＦＦであるＦＦＤ応答を生成して第１ＬＡＮ３０に送出し（Ｓ３１２）、セントラルＧＷ１０の制御部１４は、第１通信部１１を介して該ＦＦＤ応答を受信する。
【０１０８】
ここで、セントラルＧＷ１０がＳ３０４にてＦＦＤ読み出しを送出した直後に、１ｓｔツール６０が、伝送路２０に、いずれかのＥＣＵに対するデータモニタを送出したとする（Ｓ３０８）。
【０１０９】
このとき、セントラルＧＷ１０の制御部１４は、ＦＦＤ応答の受信前にデータモニタを受信し、これに応じて、伝送路２０に、１ｓｔツール６０に対して一定時間経過後にデータモニタを再送することを指示するＳＦであるＮＲＣを送出する（Ｓ３１０）。
【０１１０】
その後、セントラルＧＷ１０の制御部１４は、ＡＥＣＵ３１からＦＦＤ応答を受信する。そして、変換情報に基づき該ＦＦＤ応答のＩＤを変換し、変換後のＦＦＤ応答を第３ＬＡＮ５０に送出する（Ｓ３１４）。
【０１１１】
ＦＦＤ応答を受信した２ｎｄツール（ＤＣＭ５２）は、これに続くＦＦＤ応答の送信を指示するため、ＦＣを第３ＬＡＮ５０に送出する（Ｓ３１６）。このとき、セントラルＧＷ１０の制御部１４は、第３通信部１３を介して該ＦＣを受信すると共に、変換情報に基づき該ＦＣのＩＤを変換し、第１〜第３ＬＡＮ３０〜５０に送出する（Ｓ３１８）。
【０１１２】
そして、ＡＥＣＵ３１は、該ＦＣを受信すると、次の分割データを含むＣＦであるＦＦＤ応答を生成して第１ＬＡＮ３０に送出し（Ｓ３２０）、セントラルＧＷ１０の制御部１４は、第１通信部１１を介して該ＦＦＤ応答を受信する。
【０１１３】
該ＦＦＤ応答を受信したセントラルＧＷ１０の制御部１４は、該ＦＦＤ応答のＩＤを変換して第３ＬＡＮ５０に送出する（Ｓ３２２）。
２ｎｄツール（ＤＣＭ５２）は、該ＦＦＤ応答を受信すると共に、ＦＣを第３ＬＡＮ５０に送出する（Ｓ３２４）。このとき、セントラルＧＷ１０の制御部１４は、第３通信部１３を介して該ＦＣを受信すると、ＩＤを変換した後に第１〜第３ＬＡＮ３０〜５０に送出する（Ｓ３２６）。
【０１１４】
そして、ＡＥＣＵ３１は、該ＦＣを受信すると、次の分割データを含むＣＦであるＦＦＤ応答を生成して第１ＬＡＮ３０に送出し（Ｓ３２８）、セントラルＧＷ１０の制御部１４は、第１通信部１１を介して該ＦＦＤ応答を受信する。なお、該ＦＦＤ応答の送出によりＦＦＤの提供が終了するため、ＡＥＣＵ３１でのダイアグ処理は終了となる。
【０１１５】
該ＦＦＤ応答を受信したセントラルＧＷ１０の制御部１４は、該ＦＦＤ応答のＩＤを変換して第３ＬＡＮ５０に送出する（Ｓ３３０）。該ＦＦＤ応答を受信した２ｎｄツール（ＤＣＭ５２）は、ＡＥＣＵ３１から受信した全てのＦＦＤ応答に基づきＦＦＤを生成し、無線通信回線網を介してセンタ７０に送信する。
【０１１６】
一方、１ｓｔツール６０は、セントラルＧＷ１０からＮＲＣを受信した後、一定時間が経過すると、伝送路２０にデータモニタを再度送出する（Ｓ３３２）。セントラルＧＷ１０の制御部１４は、伝送路２０に送出されたデータモニタを受信すると共に、第１〜第３ＬＡＮ３０〜５０に該データモニタを送出する（Ｓ３３４）。
【０１１７】
そして、該データモニタに応じていずれかのＥＣＵでダイアグ処理が開始され、セントラルＧＷ１０は、該ＥＣＵと１ｓｔツール６０との間のダイアグ用フレームの中継を行う。
【０１１８】
なお、Ｓ３３２にてセントラルＧＷ１０が１ｓｔツール６０からデータモニタを受信した際、セントラルＧＷ１０での調停処理が終了していない場合には、Ｓ３１０と同様、制御部１４は、伝送路２０にＮＲＣを送出する。
【０１１９】
このような構成によれば、ＥＣＵの処理負荷の増加や処理の複雑化を防ぎつつ、先に開始された２ｎｄツール（ＤＣＭ５２）による故障診断の実行後に、後に開始された１ｓｔツール６０による故障診断を開始させることができる。このため、１ｓｔツール６０による故障診断と、２ｎｄツール（ＤＣＭ５２）による故障診断の同時進行を防ぐことができる。
【０１２０】
［変形例２］
既に述べたように、ＣＡＮのアプリケーションレイヤーの通信プロトコルであるＩＳＯ１４２２９では先優先が定められている。しかし、先のダイアグ要求フレーム等を受信中のＥＣＵに対し、他のツールから後のダイアグ要求フレーム等が送信された場合、該ＥＣＵは、後のダイアグ要求フレーム等を受信すると、先のダイアグ要求フレーム等に基づく処理を中断し、該後のダイアグ要求フレーム等に基づく処理を開始するという規則（後優先）に従いＥＣＵが構成されている場合もある。
【０１２１】
以下では、ＥＣＵが後優先に従って構成されている場合に、１ｓｔツール６０による故障診断を優先させるための調停を行う処理について、図６を用いて説明する。
２ｎｄツール（ＤＣＭ５２）が、第３ＬＡＮ５０に、ＡＥＣＵ３１に対するＦＦＤ読み出しを送出したとする（Ｓ４００）。このとき、セントラルＧＷ１０の制御部１４は、第３通信部１３を介して、該ＦＦＤ読み出しを受信し、ＩＤを変換した後に第１〜第３ＬＡＮ３０〜５０に送出する（Ｓ４０５）。
【０１２２】
そして、ＡＥＣＵ３１は、該ＦＦＤ読み出しを受信すると、該ＦＦＤ読み出しに対応するダイアグ処理を開始し（Ｓ４１０）、自装置の不揮発性メモリ等に保存されているＦＦＤを読み出す。そして、該ＦＦＤが８バイトを越える場合、８バイト以下の複数のデータに分割する。
【０１２３】
その後、１ｓｔツール６０が、伝送路２０に、ＡＥＣＵ３１に対するデータモニタを送出したとする（Ｓ４１５）。セントラルＧＷ１０の制御部１４は、伝送路２０に送出されたデータモニタを受信すると共に、１ｓｔツール６０による故障診断を優先して行うため、２ｎｄツール（ＤＣＭ５２）からのダイアグ要求フレームの中継を中止する調停処理を開始する（Ｓ４２０）。また、制御部１４は、第１〜第３ＬＡＮ３０〜５０に該データモニタを送出する（Ｓ４２５）。
【０１２４】
ＡＥＣＵ３１は、該データモニタを受信すると、ＦＦＤ読み出しの受信により行われているダイアグ処理を中止する（このため、ＦＦＤ応答の送出は行われない）。そして、該データモニタに対応するダイアグ処理を開始し（Ｓ４３０）、該データモニタにより指定されたアドレスのメモリを読み出すと共に、読み出したデータの一部を含むＦＦであるデータモニタ応答を生成し、第１ＬＡＮ３０に送出する（Ｓ４３５）。セントラルＧＷ１０の制御部１４は、第１ＬＡＮ３０に送出されたデータモニタ応答を受信すると共に、２ｎｄツール（ＤＣＭ５２）からのダイアグ要求フレームの中継を中止する調停処理を行っているため、２ｎｄツール（ＤＣＭ５２）が接続された第３ＬＡＮ５０への応答は行わず、該データモニタ応答を伝送路２０に送出する（Ｓ４４０）。
【０１２５】
一方、１ｓｔツール６０は、該データモニタ応答を受信すると共に、これに続くデータモニタ応答の送信を指示するため、ＦＣを伝送路２０に送出する（Ｓ４４５）。このとき、セントラルＧＷ１０の制御部１４は、第４通信部１５を介して該ＦＣを受信し、第１〜第３ＬＡＮ３０〜５０に送出する（Ｓ４５０）。
【０１２６】
ここで、２ｎｄツール（ＤＣＭ５２）が、第３ＬＡＮ５０に、ＡＥＣＵ３１に対するＦＦＤ読み出しを送出したとする（Ｓ４５５）。セントラルＧＷ１０の制御部１４は、該ＦＦＤ読み出しを受信するが、調停処理が行われているため、該ＦＦＤ読み出しは中継されない。
【０１２７】
そして、ＡＥＣＵ３１は、Ｓ４５０で送出されたＦＣを受信すると、先に読み出した未送信のデータの一部を含むＣＦであるデータモニタ応答を生成して第１ＬＡＮ３０に送出する（Ｓ４６０）。セントラルＧＷ１０の制御部１４は、第１通信部１１を介して該データモニタ応答を受信し、伝送路２０に送出する（Ｓ４６５）。
【０１２８】
一方、１ｓｔツール６０は、該データモニタ応答を受信すると共に、これに続くデータモニタ応答の送信を指示するため、ＦＣを伝送路２０に送出する（Ｓ４７０）。このとき、セントラルＧＷ１０の制御部１４は、第４通信部１５を介して該ＦＣを受信し、第１〜第３ＬＡＮ３０〜５０に送出する（Ｓ４７５）。
【０１２９】
そして、ＡＥＣＵ３１は、該ＦＣを受信すると、先に読み出した未送信のデータ全てを含むＣＦであるデータモニタ応答を生成して第１ＬＡＮ３０に送出する（Ｓ４８０）。セントラルＧＷ１０の制御部１４は、第１通信部１１を介して該データモニタ応答を受信すると共に、伝送路２０に送出し（Ｓ４８５）、該データモニタ応答を１ｓｔツール６０に中継する。
【０１３０】
各ＥＣＵが後優先に従って構成されている場合、１ｓｔツール６０による故障診断中に、同一ＥＣＵに対する２ｎｄツール（ＤＣＭ５２）による故障診断が開始されると、１ｓｔツール６０による故障診断に替えて、２ｎｄツール（ＤＣＭ５２）による故障診断が開始される。これに対し、変形例２のセントラルＧＷ１０によれば、各ＥＣＵを後優先に従った構成としたまま、このような場合に１ｓｔツール６０による故障診断を継続させることができる。
【０１３１】
このため、ディーラー等においてサービスツールを用いた故障診断を確実に行うことができ、各ＥＣＵの処理負荷の増加や、処理の複雑化を防ぎつつ、各ツールによる故障診断を好適に調停することができる。
【０１３２】
［他の実施形態］
（１）本実施形態では、第１〜第３ＬＡＮ３０〜５０や伝送路２０は、ＣＡＮとして構成されているが、言うまでも無く、ＣＡＮ以外のイベントドリブン方式の通信規格や、ＦｌｅｘＲａｙ，Ｍｏｓｔ，イーサネット（登録商標）等の通信規格の車内ＬＡＮとして構成されていても良い。このような場合であっても、同様の効果を得ることができる。
【０１３３】
また、第１〜第３車内ＬＡＮ３０〜５０や伝送路２０の通信規格によっては、故障診断の指示や、該指示に対する応答が、複数のフレームからなるメッセージとして送受信され、さらに、該メッセージに対してＩＤが設定されているという場合がある（換言すれば、メッセージを構成する全フレームにＩＤが含まれているのではなく、いずれかのフレームにのみＩＤが含まれているという場合がある）。このような場合においても、セントラルＧＷ１０は、本実施形態と同様にして、メッセージの中継や、ＩＤの変換や、調停処理を行うことで、同様の効果を得ることができる。
【０１３４】
（２）また、本実施形態では、１ｓｔツール６０では通信プロトコルに定義されたダイアグ用フレームが用いられ、２ｎｄツール（ＤＣＭ５２）では通信プロトコルに定義されていないダイアグ用フレームが用いられる。しかしながら、これに限定されること無く、１ｓｔツール６０では通信プロトコルに定義されていないダイアグ用フレームが用いられ、２ｎｄツール（ＤＣＭ５２）では通信プロトコルに定義されたダイアグ用フレームが用いられても良い。このような場合であっても、同様の効果を得ることができる。
【０１３５】
（３）また、本実施形態では、セントラルＧＷ１０に接続する伝送路２０にＤＬＣコネクタ２１を設ける構成を例示したが、これに限らず、第１〜第３ＬＡＮ３０〜５０にＤＬＣコネクタを設けても良い。また、伝送路２０や第１〜第３ＬＡＮ３０〜５０に複数のＤＬＣコネクタを設け、複数の１ｓｔツール６０を同時に接続可能な構成としても良い。
【０１３６】
また、本実施形態では、１つの２ｎｄツール（ＤＣＭ５２）を介してセンタ７０と無線通信を行い、ＥＣＵの故障診断を行う構成を例示した。しかしながら、これに限らず、２ｎｄツール（ＤＣＭ５２）が複数のセンタ７０と無線通信を行い、各センタ７０で個別にＥＣＵの故障診断を行う構成としても良い。
【０１３７】
また、車載システムを構成するＥＣＵとして、２ｎｄツール（ＤＣＭ５２）に相当する新たな無線通信装置をさらに設け、２ｎｄツール（ＤＣＭ５２）や該無線通信装置が別のセンタ７０や端末（携帯電話やスマートフォンなど）と無線通信を行い、個別にＥＣＵの故障診断を行う構成としても良い。
【０１３８】
また、上記２ｎｄツール（ＤＣＭ５２）や該無線通信装置を、まとめて２ｎｄツールとの扱いにしてもよいし、３ｒｄツール、４ｔｈツールのように分けて扱っても良い。
このようにして１または複数の１ｓｔツール６０や、１または複数のツールによる故障診断を行うことができる構成とした場合であっても、同様の効果を得ることができる。
【０１３９】
［特許請求の範囲との対応］
上記実施形態の説明で用いた用語と、特許請求の範囲の記載に用いた用語との対応を示す。
【０１４０】
セントラルＧＷ１０が中継装置に、１ｓｔツール６０が外部接続ツールに、２ｎｄツール（ＤＣＭ５２）が通信用ＥＣＵに、１ｓｔツール６０，２ｎｄツール（ＤＣＭ５２）がダイアグ用ツールに相当する。
【０１４１】
また、２ｎｄツール（ＤＣＭ５２）から送出されるダイアグ要求フレーム，ＦＦＤ読み出し，ＦＣが対象ダイアグ要求に、ＮＲＣが再送要求に相当し、ＩＤが識別情報に、０ｘ０００〜０ｘ６ＦＦのＩＤが第１，第４識別情報に、０ｘ７００〜０ｘ７ＦＦのＩＤが第２，第３識別情報に相当する。
【０１４２】
また、セントラルＧＷ１０の記憶部１６が要求記憶手段，応答記憶手段に、第３通信部１３，第４通信部１５が要求受信手段，応答送信手段に、第１〜第３通信部１１〜１３が要求送出手段，応答受信手段に相当する。
【０１４３】
また、ダイアグ用フレームを中継する際の処理におけるＳ１０５が要求変換手段に、Ｓ１２５が応答変換手段に、Ｓ１６５，Ｓ１７５が再送要求手段に相当する。
また、１ｓｔツール６０による故障診断を優先させるための調停を行う処理におけるＳ２２５、及び、セントラルＧＷ１０における第４通信部１５が遅延手段に、Ｓ２２０が調停手段に相当する。
【符号の説明】
【０１４４】
１０…セントラルＧＷ、１１…第１通信部、１２…第２通信部、１３…第３通信部、１４…制御部、１５…第４通信部、１６…記憶部、２０…伝送路、２１…ＤＬＣコネクタ、３０…第１ＬＡＮ、３１…ＡＥＣＵ、３２…ＢＥＣＵ、４０…第２ＬＡＮ、４１…ＣＥＣＵ、４２…ＤＥＣＵ、５０…第３ＬＡＮ、５１…ＥＥＣＵ、５２…ＤＣＭ、６０…１ｓｔツール、７０…センタ。
【図１】
2014078801.tif 000003
【図２】
2014078801.tif 000004
【図３】
2014078801.tif 000005
【図４】
2014078801.tif 000006
【図５】
2014078801.tif 000007
【図６】
2014078801.tif 000008