(57)【要約】【課題】通信に不具合が生じた場合に、診断の容易化を図ること。【解決手段】診断情報記録機能を備えた通信装置１は、車載機２と携帯機３とを備える。携帯機３は、錠を操作するための要求を車載機２に送信する。携帯機３は、要求に対応する応答が得られないことを連続性データに基づいて判定する。携帯機３は、応答がない状態を、履歴データによって車載機２に通知する。一方、車載機２は、携帯機３からの要求に対応する応答を送信したか否かを連続性データに基づいて判定する。この構成では、不具合を生じた通信方向が、携帯機３から車載機２へ通知された応答の有無と、車載機２からの応答の送信有無との論理によって示される。そして、車載機２は、不具合を生じた通信方向を示す診断コードと、通信環境を示すデータとを診断情報として記録する。【選択図】図１
2010232873.tif 000002
【特許請求の範囲】
【請求項１】
一方の通信機から送信された要求が他方の通信機に到達し、他方の通信機から送信された前記要求に対応する応答が前記一方の通信機に到達することにより、前記要求と前記応答とを含む往復通信が成立する要求応答型通信装置において、
前記往復通信の成立、不成立を判定する往復判定手段（１２３）、（２４３）と、
前記往復通信の成立、不成立を通信の履歴として送信する履歴送信手段（１２４、１１３）、（２４６、２１３）と、
前記履歴が到達すると、当該履歴により示される前記要求の到達、不到達を判定する要求判定手段（１４３、１４４）、（２２４）と、
通信の不具合を診断するための診断情報を記録する記録手段であって、前記要求の到達、不到達によって示される不具合を生じた通信方向を記録する記録手段（１４６）、（２４９）とを備えることを特徴とする要求応答型通信装置。
【請求項２】
前記履歴送信手段は、後続の要求に、先行の要求における前記履歴を付して送信することを特徴とする請求項１に記載の要求応答型通信装置。
【請求項３】
前記一方の通信機は、車両用リモコンシステムの携帯機（３）であり、
前記他方の通信機は、前記車両用リモコンシステムの車載機（２）であり、
前記往復判定手段（１２３）と前記履歴送信手段（１２４，１１３）とが前記携帯機に設けられ、
前記要求判定手段（１４３、１４４）と前記記録手段（１４６）とが前記車載機に設けられていることを特徴とする請求項１または請求項２に記載の要求応答型通信装置。
【請求項４】
前記一方の通信機は、車両用リモコンシステムの車載機（２）であり、
前記他方の通信機は、前記車両用リモコンシステムの携帯機（３）であり、
前記往復判定手段（２４３）と、前記履歴送信手段（２４６，２１３）と、前記記録手段（２４９）とが前記車載機に設けられ、
前記要求判定手段（２２４）が前記携帯機に設けられ、
前記携帯機は、前記要求判定手段（２２４）により判定された前記要求の到達、不到達を前記車載機に送信する手段（２２５、２２９、２２８）を備えることを特徴とする請求項１または請求項２に記載の要求応答型通信装置。
【請求項５】
一方の通信機から送信された要求が他方の通信機に到達し、他方の通信機から送信された前記要求に対応する応答が前記一方の通信機に到達することにより、前記要求と前記応答とを含む往復通信が成立する要求応答型通信装置において、
前記一方の通信機（２）に設けられ、先行の要求における前記往復通信の成立、不成立を判定する往復判定手段（２４３）と、
前記一方の通信機（２）に設けられ、後続の要求において、前記先行の要求における前記往復通信の成立、不成立を通信の履歴として送信する第１履歴送信手段（２４６、２１３）と、
前記他方の通信機（３）に設けられ、前記履歴が到達すると、当該履歴により示される前記先行の要求の到達、不到達を判定する要求判定手段（２２４）と、
前記他方の通信機（３）に設けられ、前記要求判定手段（２２４）により判定された前記先行の要求の到達、不到達を前記一方の通信機に送信する第２履歴送信手段（２２５、２２９、２２８）と、
通信の不具合を診断するための診断情報を記録する記録手段であって、前記先行の要求の到達、不到達によって示される不具合を生じた通信方向を、前記先行の要求における前記往復通信の不成立に対応する診断情報として記録する記録手段（２４９）とを備えることを特徴とする要求応答型通信装置。
【請求項６】
前記一方の通信機は、車両用リモコンシステムの車載機（２）であり、
前記他方の通信機は、前記車両用リモコンシステムの携帯機（３）であることを特徴とする請求項５に記載の要求応答型通信装置。
【請求項７】
前記第１履歴送信手段は、車両に設けられたスイッチが操作されると、前記履歴を送信することを特徴とする請求項６に記載の要求応答型通信装置。
【請求項８】
前記往復判定手段は、前記要求に付された番号と、前記応答に付された番号とが所定の関係にある場合に、前記往復通信の成立を判定することを特徴とする請求項１から請求項７のいずれかに記載の要求応答型通信装置。
【請求項９】
前記要求判定手段は、複数の要求に付された番号が所定の規則に従って連続している場合に前記要求の到達を判定することを特徴とする請求項１から請求項８のいずれかに記載の要求応答型通信装置。
【請求項１０】
前記記録手段が記録する前記診断情報には、前記通信機（２、３）の間の通信環境を示す情報が含まれていることを特徴とする請求項１から請求項９のいずれかに記載の要求応答型通信装置。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、要求応答型通信装置に関するものである。より詳細には、何らかの通信上の不具合が検出された場合に、その原因究明に資すると考えられる機器の作動状態などの診断情報を記録する診断情報記録機能を備えた要求応答型通信装置に関するものである。
【背景技術】
【０００２】
従来、特許文献１に記載の情報通信装置が知られている。この装置では、通信を行う２つの通信機として、携帯型のトランスミッタと、車載のレシーバとを備えている。これらは、トランスミッタから送信される要求に応じて、レシーバが自動車のドアロックを制御する車両用のキーレスエントリーシステムを構成している。さらに、レシーバには、テスタを接続することができ、テスタには、トランスミッタとレシーバとの間の交信内容などを表示することができる。このテスタにより、不具合の原因を絞り込むことができ、診断にかかる作業を軽減することができる。
【先行技術文献】
【特許文献】
【０００３】
【特許文献１】特開２００３−３７０９号公報
【発明の概要】
【発明が解決しようとする課題】
【０００４】
特許文献１の技術によると、テスタを接続しているときの交信内容などを診断情報として見ることができるが、テスタが接続されていないときには診断情報を得ることができない。これでは、テスタが接続されていないときに情報通信装置に生じた何らかの不具合を診断し、その原因究明あるいは対策立案をすることができないという問題点がある。
【０００５】
また、キーレスエントリシステムのように、通信機が移動局である場合には、故障ではないにもかかわらず、意図された通信が不可能なためにシステムが不作動となる場合があった。例えば、通信機間の距離が通信可能距離を超えた場合に、送信しても受信されない場合である。また、通信機が高速で移動して通信機間に障害物が一時的に位置する場合にも同様の不作動が生じる。このような不作動の場合、システムの構成機器には故障が生じていないにもかかわらず、使用者は所期の機能が提供されないために機器の故障を疑い、場合によっては修理を求めることとなる。よって、何らかの通信上の不具合が生じた場合に、当該不具合が機器の故障によるものであるのか、単に機器の機能上の制限から生じた不作動であるのかを識別することも必要である。
【０００６】
このように、従来の装置では、故障または不作動といった何らかの不具合が生じて修理要請があった場合でも、不具合が生じたときの機器の使用状況を知ることができないため、不具合の診断が困難であるという問題点があった。
【０００７】
本発明の目的は、通信上の不具合が検出された場合に、診断情報を記録することができる情報通信装置を提供することにある。
【０００８】
本発明の他の目的は、通信上の不具合が検出された場合に、不具合を生じた通信方向を特定することができる診断情報を記憶することができる情報通信装置を提供することにある。
【０００９】
本発明のさらに他の目的は、通信上の不具合が検出された場合に、不具合として検出された過去の通信の時点における診断情報を記録することができる情報通信装置を提供することにある。
【課題を解決するための手段】
【００１０】
上記目的を達成するために、下記の技術的手段を採用することができる。なお、特許請求の範囲および上記各手段に記載の括弧内の符号は、ひとつの態様として後述する実施形態に記載の具体的手段との対応関係を示す。
【００１１】
請求項１に記載の発明は、一方の通信機から送信された要求が他方の通信機に到達し、他方の通信機から送信された要求に対応する応答が一方の通信機に到達することにより、要求と応答とを含む往復通信が成立する要求応答型通信装置において、往復通信の成立、不成立を判定する往復判定手段（１２３）、（２４３）と、往復通信の成立、不成立を通信の履歴として送信する履歴送信手段（１２４、１１３）、（２４６、２１３）と、履歴が到達すると、当該履歴により示される要求の到達、不到達を判定する要求判定手段（１４３、１４４）、（２２４）と、通信の不具合を診断するための診断情報を記録する記録手段であって、要求の到達、不到達によって示される不具合を生じた通信方向を記録する記録手段（１４６）、（２４９）とを備えることを特徴とするという技術的手段を採用する。
【００１２】
この発明によると、「要求」を送信した第１通信機において、「要求」と「応答」とを含む往復通信の成立、不成立が判定され、これが履歴として、相手側の第２通信機に送信される。第２通信機では、履歴が到達すると、その履歴により示される「要求」が到達したか、不到達かが判定される。この結果、往復通信の不成立が、「要求」の不到達を伴うのか、あるいは「要求」の到達を伴うのかが示される。往復通信が不成立であり、かつ「要求」が不到達である場合、第１通信機から第２通信機への「要求」の通信方向に不具合があると考えられる。また、往復通信が不成立であり、かつ「要求」が到達である場合、第２通信機から第１通信機への「応答」の通信方向に不具合があると考えられる。第１通信機または第２通信機に設けられる記録手段は、このような不具合を生じた通信方向を含めて、通信の不具合を診断するための診断情報を記録する。この結果、記録内容を参照することで、通信の不具合を診断することが可能となる。
【００１３】
請求項２に記載の発明は、履歴送信手段は、後続の要求に、先行の要求における履歴を付して送信することを特徴とするという技術的手段を採用する。この発明によると、機器に所定の機能を提供させることを要求するために送信される「要求」を用いて、履歴を送信することができる。
【００１４】
請求項３に記載の発明は、一方の通信機は、車両用リモコンシステムの携帯機（３）であり、他方の通信機は、携帯機から送信された要求に応じて所定の機能を提供する車両用リモコンシステムの車載機（２）であり、往復判定手段（１２３）と履歴送信手段（１２４、１１３）とが携帯機に設けられ、要求判定手段（１４３、１４４）と記録手段（１４６）とが車載機に設けられていることを特徴とするという技術的手段を採用する。この発明によると、「要求」は携帯機から送信され、「応答」は車載機から送信される。この構成によると、先の往復通信が不成立であったことが携帯機から車載機に通知される。この履歴が到達すると、車載機は、先の「要求」が到達か、不到達かを判定する。さらに、車載機は、不具合を生じた通信方向を含む診断情報を記録手段によって記録する。
【００１５】
請求項４に記載の発明は、一方の通信機は、要求に応じて所定の機能を提供する車両用リモコンシステムの車載機（２）であり、他方の通信機は、車両用リモコンシステムの携帯機（３）であり、往復判定手段（２４３）と、履歴送信手段（２４６、２１３）と、記録手段（２４９）とが車載機に設けられ、要求判定手段（２２４）が携帯機に設けられ、携帯機は、要求判定手段（２２４）により判定された要求の到達、不到達を車載機に送信する手段（２２５、２２９、２２８）を備えることを特徴とするという技術的手段を採用する。この発明によると、「要求」は車載機から送信され、「応答」は携帯機から送信される。この構成によると、先の往復通信が不成立であったことが車載機から携帯機に通知される。この履歴が到達すると、携帯機は、先の「要求」が到達か、不到達かを判定する。この「要求」の到達、不到達は、携帯機から車載機に送信される。そして、車載機は、不具合を生じた通信方向を含む診断情報を記録手段によって記録する。
【００１６】
請求項５に記載の発明は、一方の通信機から送信された要求が他方の通信機に到達し、他方の通信機から送信された要求に対応する応答が一方の通信機に到達することにより、要求と応答とを含む往復通信が成立する要求応答型通信装置において、
一方の通信機（２）に設けられ、先行の要求における往復通信の成立、不成立を判定する往復判定手段（２４３）と、一方の通信機（２）に設けられ、後続の要求において、先行の要求における往復通信の成立、不成立を通信の履歴として送信する第１履歴送信手段（２４６、２１３）と、他方の通信機（３）に設けられ、履歴が到達すると、当該履歴により示される先行の要求の到達、不到達を判定する要求判定手段（２２４）と、他方の通信機（３）に設けられ、要求判定手段（２２４）により判定された先行の要求の到達、不到達を一方の通信機に送信する第２履歴送信手段（２２５、２２９、２２８）と、通信の不具合を診断するための診断情報を記録する記録手段であって、先行の要求の到達、不到達によって示される不具合を生じた通信方向を、先行の要求における往復通信の不成立に対応する診断情報として記録する記録手段（２４９）とを備えることを特徴とするという技術的手段を採用する。
【００１７】
この発明によると、「要求」を送信した第１通信機において、「要求」と「応答」とを含む往復通信の成立、不成立が判定される。第１通信機は、後続の「要求」において、先行の「要求」における往復通信の成立、不成立を履歴として、相手側の第２通信機に送信する。第２通信機では、履歴が到達すると、その履歴により示される先行の「要求」が到達したか、不到達かが判定される。この結果、先行の「要求」における往復通信の不成立が、先行の「要求」の不到達を伴うのか、あるいは先行の「要求」の到達を伴うのかが示される。往復通信が不成立であり、かつ先行の「要求」が不到達である場合、第１通信機から第２通信機への「要求」の通信方向に不具合があると考えられる。また、往復通信が不成立であり、かつ先行の「要求」が到達である場合、第２通信機から第１通信機への「応答」の通信方向に不具合があると考えられる。第２通信機は、先行の「要求」の到達、不到達を、第１通信機に送信する。第１通信機に設けられた記録手段は、先行の「要求」の到達、不到達によって示される不具合を生じた通信方向を含めて、診断情報を記録する。この結果、先行の「要求」における往復通信の不具合が、いずれの通信方向における不具合に起因するのかを示すことができる。
【００１８】
請求項６に記載の発明は、一方の通信機は、車両用リモコンシステムの車載機（２）であり、他方の通信機は、車両用リモコンシステムの携帯機（３）であることを特徴とするという技術的手段を採用する。この発明によると、車載機から「要求」を送信する車両用リモコンシステムにおいて、車載機に診断情報を記録することができる。
【００１９】
請求項７に記載の発明は、第１履歴送信手段は、車両に設けられたスイッチが操作されると、履歴を送信することを特徴とするという技術的手段を採用する。この発明によると、車両に設けたスイッチが操作されると、車載機から「要求」を送信するとともに、履歴を送信することができる。
【００２０】
請求項８に記載の発明は、往復判定手段は、要求に付された番号と、応答に付された番号とが所定の関係にある場合に、往復通信の成立を判定することを特徴とするという技術的手段を採用する。この発明によると、「要求」の番号と、「応答」の番号とが所定の関係にあるか否かを判定することで、往復通信の成立、不成立を判定することができる。例えば、ひとつの実施態様では、「要求」の番号と、「応答」の番号とが同じ番号である場合に、往復通信の成立が判定される。
【００２１】
請求項９に記載の発明は、要求判定手段は、複数の要求に付された番号が所定の規則に従って連続している場合に要求の到達を判定することを特徴とするという技術的手段を採用する。この発明によると、次々と到達する複数の「要求」が、通信の不具合に起因する抜けなく連続的に到達しているのか否かを、「要求」に付された番号によって判定することができる。例えば、ひとつの実施態様では、「要求」に付された番号が単位数づつ増加することが判定される。
【００２２】
請求項１０に記載の発明は、記録手段が記録する診断情報には、車載機（２）と携帯機（３）との間の通信環境を示す情報が含まれていることを特徴とするという技術的手段を採用する。この発明によると、通信の不具合の診断が容易となる。
【図面の簡単な説明】
【００２３】
【図１】本発明を適用した第１実施形態に係る車両用リモコンシステムを示すブロック図である。
【図２】第１実施形態の通信データの構成を示すブロック図である。
【図３】第１実施形態の携帯機の処理を示すフローチャートである。
【図４】第１実施形態の携帯機の処理を示すフローチャートである。
【図５】第１実施形態の車載機の処理を示すフローチャートである。
【図６】第１実施形態の正常時の通信手順を示すシーケンスチャートである。
【図７】第１実施形態の要求不具合時の通信手順を示すシーケンスチャートである。
【図８】第１実施形態の応答不具合時の通信手順を示すシーケンスチャートである。
【図９】本発明を適用した第２実施形態の車載機の処理を示すフローチャートである。
【図１０】第２実施形態の車載機の処理を示すフローチャートである。
【図１１】第２実施形態の携帯機の処理を示すフローチャートである。
【図１２】第２実施形態の正常時の通信手順を示すシーケンスチャートである。
【図１３】第２実施形態の要求不具合時の通信手順を示すシーケンスチャートである。
【図１４】第２実施形態の応答不具合時の通信手順を示すシーケンスチャートである。
【発明を実施するための形態】
【００２４】
（第１実施形態）
第１実施形態では、本発明は要求応答型通信装置としての車両用リモコンシステム１に適用されている。車両用リモコンシステム１は、車載機器を遠隔操作することを可能とする。車両用リモコンシステム１は、データを交互に送信する半二重通信方式を採用している。車載機２は、携帯機３からの「要求」に従って、車載機器に所定の機能を提供させるように車載機器を制御する。この実施形態では、車載機２が診断情報を記録する記録手段を搭載する記録機とされている。また、携帯機３が、「要求」と「応答」とを含む一組の往復通信を開始するための最初の「要求」を非同期的に発出する開始機とされている。また、車載機３から「応答」が送信される。よって、携帯機３が第１通信機として機能し、車載機２が第２通信機として機能する。
【００２５】
図１において、情報通信装置としての車両用リモコンシステム１は、主局としての車載機２と、端末局としての携帯機３とを有する。車両用リモコンシステム１は、車載機器である車両の錠装置を遠隔操作することを可能とする。車載機２は、携帯機３からの「要求」に従って、車両の錠装置の施錠操作（ＬＫ操作）または開錠操作（ＵＬＫ操作）を実行する。なお、車両用リモコンシステム１は、錠装置に代えて、または加えて、盗難防止装置の機能の遠隔操作、電動ドアの遠隔開閉操作などを実行するよう構成することができる。また、車載のエンジンを始動させる始動装置を遠隔操作するように構成されてもよい。
【００２６】
車載機２は、送受信機２１と、制御装置２２と、診断情報取得装置２３と、スイッチ群２４と、ドアロックアクチュエータ２５とを有する。制御装置２２は、マイクロコンピュータを備える。制御装置２２は、携帯機３からの「要求」に応じて錠装置を操作する制御手段と、通信の不具合を検出する不具合検出手段と、通信の不具合が検出された場合に診断情報を記録する記録手段とを提供する。
【００２７】
制御装置２２は、次々と到達し受信される複数の「要求」の連続性を評価する連続性判定手段２２ａを備える。この連続性判定手段２２ａは、次々と到達する複数の「要求」が所定の規則に従って連続しているか否かを判定する。言い換えると、連続性判定手段２２ａは、すべての「要求」の到達、不到達を判定する要求判定手段でもある。制御装置２２は、通信の履歴に基づいて過去の通信に不具合があったか否かを判定する履歴判定手段２２ｂを有する。さらに、制御装置２２は、通信の不具合が検出された場合に、不具合の原因を究明し、不具合を解決するための診断に有用な情報を取得し、記録する記録手段２２ｃを有している。記録手段２２ｃは、半導体メモリなどの記憶装置によって提供されている。記録手段２２ｃに記録された診断情報は、所定の操作によって読み出され、表示される。診断情報として、車載機２において取得可能な情報と、携帯機３において取得可能な情報とが収集され、記録される。
【００２８】
また、制御装置２２は、半導体メモリなどの記憶装置を備えている。記憶装置には、受信された「要求」の番号、「要求」に付されていた履歴、車載機２としての処理内容などが記憶される。この記憶装置の記憶内容は、「要求」の連続性を判定するために、および「応答」に付される履歴の作成に用いられる。
【００２９】
診断情報取得装置２３は、通信の不具合を診断するために有用と考えられる診断情報を記録手段２２ｃに提供する。診断情報としては、車両の走行状態、スイッチ群の操作状態、電波環境、通信装置の状態、その他通信に影響を及ぼすおそれのある事象を挙げることができる。診断情報取得装置２３は、ノイズ測定装置２３ａと、ＧＰＳ受信装置２３ｂとを備えることができる。ノイズ測定装置２３ａは、送受信機２１の送受信周波数におけるノイズを測定し、ＳＮ比などノイズ量を示すデータを記録手段２２ｃに提供する。ＧＰＳ受信装置２３ｂは、車載機２の位置を示すデータを記録手段２２ｃに提供する。この位置データに基づいて、車両の周辺に位置するビルなどの通信上の障害物の存在を知ることができる。例えば、車載機２が市街地に位置しているときには、不具合が障害物によって生じたことを予測することができる。これらの診断情報は、通信環境の良否を示す情報ともいえる。
【００３０】
スイッチ群２４は、車両に搭載された複数のスイッチ装置を含む。例えば、車両の各座席に設けられた施錠スイッチおよび開錠スイッチが含まれる。また、スイッチ群２４には、車外に設けられたタッチスイッチが含まれる。車載機２は、タッチスイッチが操作され、しかも、認証済みの携帯機３の存在が確認されると、開錠操作または施錠操作を実行する。この操作のために、車載機２は、錠操作などを許容する正規の携帯機として認証済みの携帯機３が、車両から所定範囲内に存在するか否かをポーリング通信によって確認している。ドアロックアクチュエータ２５は、車両のドアに設けられた錠装置を施錠または開錠するモータなどのアクチュエータである。
【００３１】
携帯機３は、送受信機３１と、制御装置３２と、診断情報取得装置３３と、スイッチ群３４とを有する。制御装置３２は、マイクロコンピュータを備える。制御装置３２は、錠装置の操作を要求する錠操作要求手段と、通信の不具合を検出するために貢献する不具合検出手段と、携帯機３において取得される診断情報を車載機２に送信する診断情報送信手段とを提供する。
【００３２】
制御装置３２は、次々と到達し受信される複数の「応答」の連続性を評価する連続性判定手段３２ａを備える。この連続性判定手段３２ａは、次々と到達する複数の「応答」が、所定の規則に従って連続しているか否かを判定する。ここでは、「応答」の連続性は、直前に送信した「要求」に対応する「応答」であるか否かが判定される。言い換えると、連続性判定手段３２ａは、「要求」と「応答」とを含む一組の往復通信の成立、不成立を判定する往復判定手段でもある。制御装置３２は、通信の履歴に基づいて過去の通信に不具合があったか否かを判定する履歴判定手段３２ｂを有する。
【００３３】
また、制御装置３２は、半導体メモリなどの記憶装置を備えている。記憶装置には、受信された「応答」の番号、「応答」に付されていた履歴、「要求」に付される履歴、携帯機３としての処理内容などが記憶される。この記憶装置の記憶内容は、「応答」の連続性を判定するために、および「要求」に付される履歴の作成に用いられる。
【００３４】
診断情報取得装置３３は、通信の不具合を診断するために有用と考えられる診断情報を制御装置３２に提供する。制御装置３２は、診断情報を車載機２に送信する。例えば、診断情報取得装置３３は、携帯機３の電池残量を示す電池電圧を検出する電池電圧検出装置３３ａを備えることができる。電池電圧検出装置３３ａは、電池電圧を測定し、電池電圧を示すデータを制御装置３２に提供する。電池電圧は、送受信機３１の送信出力など携帯機３の機能に影響を与えるから、この診断情報は、通信環境の良否を示す情報ともいえる。
【００３５】
スイッチ群３４は、施錠操作を要求するためのＬＫスイッチ３４ａ、および開錠操作を要求するためのＵＬＫスイッチ３４ｂを含むことができる。スイッチ群３４には、盗難防止装置の操作を示すスイッチ、および電動ドアの操作を示すスイッチをさらに備えることができる。
【００３６】
図２において、車載機２と携帯機３との間で送受信される通信データ１０の例示的な構成が示されている。通信データ１０には、車載機２と携帯機３とが互いを識別する識別データ（ＩＤ）、および通信分野で一般的な付加情報であるヘッダデータ、誤り訂正符号データなどのほかに、図示のデータブロックを含んでいる。
【００３７】
ブロック１１には、連続性データが格納される。連続性データは、車載機２と携帯機３との間で行われる通信が連続しているのか、抜けがあったのかを示すためのデータである。連続性データとして、連続性をもつ数列を用いることができる。この実施形態では、４ビットの二進数が用いられる。車載機２と携帯機３との間の通信は、複数のセッションから構成される。ひとつのセッションは、携帯機３からの「要求」と車載機２からの「応答」とから構成されている。このひとつのセッションにひとつの番号が割り当てられる。
【００３８】
ブロック１２には、今回の処理を示すデータと、診断情報を示すデータとが格納される。例えば、以下のようなデータが格納される。携帯機３からの「要求」においては、今回の処理を示す情報として、「施錠（ＬＫ）」または「開錠（ＵＬＫ）」が格納される。また、携帯機３からの「要求」においては、診断情報として、電池電圧の良否を示す符号、例えば「良」または「不良」が格納される。また、車載機２からの応答においては、今回の処理を示す情報として、「施錠（ＬＫ）」または「開錠（ＵＬＫ）」が格納される。なお、車載機２からの応答においては、診断情報は車載機２で記録されるため、診断情報は格納されない。
【００３９】
ブロック１３には、過去の複数回の通信履歴を示すデータが格納される。図示の例では、過去５回分の通信履歴が格納される。それぞれの履歴には、通信処理の内容を示すデータと、診断情報を示すデータとが格納される。例えば、以下のようなデータが格納される。まず、過去の通信履歴に不具合が生じていない場合には、履歴データは格納されない。携帯機３からの「要求」においては、処理として、携帯機３から「要求」を送信したにもかかわらず車載機２からの応答が受信されていないことを示す「無し」が格納されることがある。また、携帯機３からの「要求」においては、当該過去の通信（「要求」）における診断情報として、電池電圧の良否を示す符号、例えば「良」または「不良」が格納されることがある。また、車載機２からの応答においては、処理として、携帯機３からの「要求」が正常に受信されたことを示す「ＯＫ」が格納される。また、車載機２からの応答においては、診断情報が記録されたことを示す「済」が格納される。
【００４０】
図３ないし図５には、車両用リモコンシステム１において実行されるフローチャートが示されている。これらのフローチャートに示された処理により、機器の故障と機器の不作動との両方を含む通信の不具合を検出する検出手段と、診断情報を記録する診断情報記録手段とが提供される。
【００４１】
図３において、携帯機３における送信処理１１０のフローチャートが示されている。ステップ１１１では、スイッチ群３４のいずれかの操作が検出される。ステップ１１２では、番号に単位数を加算することにより、「要求」の番号が算出され、記憶される。これにより、新たなセッションの開始が携帯機３において記憶される。また、番号により先行の「要求」と後続の「要求」とを識別することが可能となる。ステップ１１３では、「要求」のデータが作成され、送信される。送信データには、連続性データとしての番号と、今回の要求する処理を示す処理データと、診断情報としての電池データと、これまでの履歴データとが含まれる。よって、ステップ１１３が履歴送信手段を提供する。
【００４２】
図４において、携帯機３における受信処理１２０のフローチャートが示されている。ステップ１２１では、車載機２からの「応答」が受信される。ステップ１２２では、「応答」から連続性データと履歴データとが取得される。ステップ１２３では、正規の「応答」が得られたか否かが判定される。ここでは、直前の送信処理１１０において設定された番号をもつ「応答」が、所定のタイムアップ時間の経過前に得られたか否かが判定される。すなわち、連続性データに基づいて、ひとつのセッションが完了したことを判定する。正規の「応答」がない場合、ステップ１２４に進む。
【００４３】
ステップ１２４では、履歴データを蓄積する。この処理では、履歴データに、最新の履歴として「応答なし」を示す「無し」を追加して記憶する。よって、直前の「要求」に付された履歴データを古い履歴として残しながら、新たに直前の「要求」に対応する「応答」が無かったことを示す最新履歴が追加記憶される。さらに、ステップ１２４では、直前の「要求」における診断情報として、直前の先行の「要求」を送信したときの電池データが記憶される。
【００４４】
ステップ１２３において、正規の「応答」があったと判定されると、ステップ１２５へ進む。ステップ１２５では、履歴データを消去した上で、新たに直前の「要求」に対応する「応答」があったことを示す「ＯＫ」の最新履歴が記憶される。ステップ１２４およびステップ１２５では、制御装置３２内の記憶装置に履歴データを記憶する。この履歴データは、次の「要求」を送信する際に、ステップ１１３で参照される。
【００４５】
図５において、車載機２における診断処理１４０のフローチャートが示されている。車載機２は、携帯機３からの「要求」をモニタしており、「要求」を受信すると診断処理１４０を開始する。まず、ステップ１４１では、携帯機３からの「要求」が受信される。ステップ１４２では、「要求」から連続性データと履歴データとが取得される。
【００４６】
ステップ１４３では、連続性データに基づいて、番号に抜けがあるか否かを判定する。ここでは、前回の診断処理において処理した「応答」の番号と、今回受信された「要求」の番号とが比較される。前回受信された「要求」の番号と、今回受信された「要求」の番号とを比較してもよい。番号が連続していれば、通信が不具合なく遂行されていることを示し、番号が飛んでいれば、不具合があったことを示している。番号が連続していれば、ステップ１４４へ進む。
【００４７】
ステップ１４４では、履歴データに異常があるか否かを判定する。いずれかの履歴データに「無し」が含まれている場合、異常ありと判定される。異常がある場合、ステップ１４５へ進む。この場合は、過去の通信に不具合が発生した場合である。ステップ１４３において、番号が飛んでいると判定された場合も、ステップ１４５へ進む。この場合も、少なくとも直前の通信に不具合が発生した場合である。よって、番号抜けがなく、かつ履歴に異常がない場合には、不具合が無いものとして、ステップ１４３およびステップ１４４を経由してステップ１４８へ進む。
【００４８】
ステップ１４５では、番号抜けの有無と、異常履歴の有無とに基づいて通信上の不具合箇所を示す診断コードを決定する。以下の３つの場合の診断コードが設定される。
【００４９】
まず、第１に、番号抜けがなく、かつ履歴に異常がある場合は、車載機２においては番号抜けなく「応答」を送信しているにもかかわらず、携帯機３からの「要求」には通信不具合を示す履歴データが含まれている場合である。この場合、携帯機３から車載機２への通信方向は正常に処理されている。しかし、車載機２から携帯機３への通信方向に不具合が生じていたと考えられる。そこで、「応答」を携帯機３が受信できていないことを示す診断コードを設定する。なお、ここで想定される不具合には、車載機２の送信機能の異常、車載機２から携帯機３への通信環境の悪さ、携帯機３の受信機能の異常などが含まれる。
【００５０】
第２に、番号抜けがあり、かつ履歴に異常がない場合は、車載機２においては受信できていない「要求」があると考えられるにもかかわらず、携帯機３からの「要求」には通信不具合を示す履歴データが含まれていない状態である。この場合、携帯機３から車載機２への通信方向に不具合が生じたことで携帯機３は予定された「応答」を受信していないと考えられるのに、それが携帯機３で認識されていないことが考えられる。この場合、携帯機３における履歴データの処理に異常が発生している可能性が高いことを示す診断コードを設定する。
【００５１】
第３に、番号抜けがあり、かつ履歴に異常がある場合は、車載機２においては受信していない「要求」があり、しかも携帯機３からの「要求」には通信不具合を示す履歴データが含まれている状態である。この場合、携帯機３から車載機２への通信方向に不具合が生じていたと考えられる。そこで、この場合、「要求」を車載機２が受信できていないことを示す診断コードを設定する。なお、ここで想定される不具合には、携帯機３の送信機能の異常、携帯機３から車載機２への通信環境の悪さ、車載機２の受信機能の異常などが含まれる。
【００５２】
ステップ１４６では、診断情報を取得し、記録する。ここでは、不具合を診断するために有効と思われる診断情報として、ステップ１４５で設定された診断コードと、時刻データと、通信環境データとが取得される。時刻データとしては、不具合が生じた処理の時刻、現在の時刻、および前回の処理の時刻など取得可能なものを含むことができる。通信環境データとしては、ノイズ測定装置２３ａから得られるノイズ量データ、ＧＰＳ受信装置２３ｂから得られる位置データ、および携帯機３から得られた電池電圧データなどを含むことができる。さらに、診断情報には、履歴データそのもの、スイッチ群２４またはスイッチ群３４の誤操作または異常操作を示すデータ、車両の運行状態を示す運行データなどを含むことができる。ステップ１４５で設定された診断コードは、主として不具合を生じた通信方向を特定するためのデータである。なお、診断コードに代えて、あるいは加えて、番号抜けの有無と、履歴異常の有無とを記録しても不具合を生じた通信方向を特定するためのデータを記録することができる。
【００５３】
ステップ１４７では、車載機２に記憶された履歴データのうち、異常であると判定された履歴に、診断情報を記録済みであることを示す「済」が記憶される。この履歴データは、後続のステップ１５０の送信処理において参照される。ステップ１４８では、車載機２に記憶された履歴データが蓄積される。ステップ１４８では、少なくとも最新の「要求」が正常に受信されたことを示すために、最新履歴として「ＯＫ」を記憶する。この最新履歴は、図２の第１履歴に相当する。ステップ１４９では、車載機２に記憶された連続性データが更新される。具体的には、番号に単位数を加算することにより、「応答」の番号が算出され、記憶される。これにより、ひとつのセッションが実行されたことが車載機２において記憶される。ステップ１５０では、「応答」のデータが作成され、送信される。送信データには、連続性データとしての番号と、処理を示すデータと、これまでの履歴データとが含まれる。
【００５４】
次に、この実施形態の作動を説明する。図６ないし図８は、車載機２と携帯機３との間の通信手順を示すシーケンスチャートである。図６は、正常な通信がされているときの処理と、通信データ内容を示す。図７は、「要求」に不具合が生じたときの処理と、通信データ内容を示す。図８は、「応答」に不具合が生じたときの処理と、通信データ内容を示す。
【００５５】
（正常時）
図６において、まず、携帯機３において、ＵＬＫスイッチ３４ｂのスイッチ操作１００が実行されると、送信処理１１０が実行される。送信処理１１０により送信される「要求」の送信データ１７１には、番号としての「０００１」と、要求処理としての「ＵＬＫ」と、診断情報としての「良」とが含まれる。ここでは、履歴データがない。
【００５６】
送信データ１７１が車載機２に受信されると、車載機２は錠制御処理１３０を実行する。ここでは、携帯機３と車載機２との識別番号を照合するなどの識別処理により正規の「要求」であることを判定し、正規の「要求」である場合には開錠操作が実行され、不正な「要求」である場合には施錠状態が維持される。錠制御処理１３０は、錠制御手段を提供する。さらに、車載機２では、診断処理１４０が実行される。ここでは、ステップ１４１−１４３、１４４、１４８−１５０の処理が実行される。この結果、「応答」の送信データ１８１には、番号としての「０００１」と、遂行された処理としての「ＵＬＫ」とが含まれる。さらに、送信データ１７１が正常に受信されたことを示す「ＯＫ」が第１履歴に格納される。
【００５７】
送信データ１８１が携帯機３に受信されると、受信処理１２０が実行される。ここでは、ステップ１２１−１２３、１２５の処理が実行される。この処理により、ひとつのセッションが完結する。ステップ１２５において履歴データが消去されるので、次のセッションの「要求」の送信データには、再び履歴データがない。この結果、同様の通信処理が繰り返えされることにより開錠操作（ＵＬＫ）、および施錠操作（ＬＫ）が遠隔的に実行される。
【００５８】
（要求不具合時）
図７において、まず、携帯機３において、ＵＬＫスイッチ３４ｂのスイッチ操作１００が実行されると、送信処理１１０ａが実行される。送信処理１１０ａにより送信される「要求」の送信データ１７１には、番号としての「０００１」と、要求処理としての「ＵＬＫ」と、診断情報としての「良」とが含まれる。ここでは、履歴データがない。
【００５９】
ここで、送信データ１７１が何らかの不具合によって車載機２に受信されない場合を想定する。この場合、携帯機３は、受信処理１２０ａを実行するが、所定のタイムアップ時間を待っても車載機２からは正規の応答が得られない。よって、ステップ１２１−１２３、１２４の処理が実行される。この結果、携帯機３は、２回目の送信処理１１０ｂを実行する。ここでは、２回目の送信処理であるので、番号として「００１０」を付した送信データ１７２が送信される。この送信データ１７２には、送信処理１１０ａにおける不具合を「無し」によって示す第１履歴が含まれている。
【００６０】
ここで、再び、送信データ１７２が何らかの不具合によって車載機２に受信されない場合を想定する。この場合、携帯機３は、受信処理１２０ｂを実行するが、所定のタイムアップ時間を待っても車載機２からは正規の応答が得られない。よって、ステップ１２１−１２３、１２４の処理が再び実行される。この結果、携帯機３は、３回目の送信処理１１０ｃを実行する。ここでは、３回目の送信処理であるので、番号として「００１１」を付した送信データ１７３が送信される。この送信データ１７３には、送信処理１１０ａにおける不具合を「無し」によって示す第２履歴と、送信処理１１０ｂとにおける不具合を「無し」によって示す第１履歴とが含まれている。
【００６１】
この送信データ１７２が車載機２に受信されると、車載機２は錠制御処理１３０を実行する。さらに、車載機２では、診断処理１４０が実行される。ここでは、ステップ１４１−１４３、１４５−１５０の処理が実行される。この結果、携帯機３から車載機２への通信方向に不具合が生じたことを示すように、診断情報が記憶される。
【００６２】
さらに、「応答」の送信データ１８１には、番号としての「００１１」と、遂行された処理としての「ＵＬＫ」とが含まれる。また、送信データ１７１が正常に受信されたことを示す「ＯＫ」が第１履歴に格納されている。さらに、送信処理１１０ａにおける不具合に対応する診断情報が記録されたことを示す「済」が第３履歴に格納され、送信処理１１０ｂにおける不具合に対応する診断情報が記録されたことを示す「済」が第２履歴に格納されている。
【００６３】
送信データ１８１が携帯機３に受信されると、受信処理１２０ｃが実行される。ここでは、ステップ１２１−１２３、１２５の処理が実行される。この処理により、番号「００１１」で示されるひとつのセッションが完結する。ステップ１２５において履歴データが消去されるので、次のセッションの「要求」の送信データでは、履歴データが存在しない。
【００６４】
（応答不具合時）
図８において、まず、携帯機３において、ＵＬＫスイッチ３４ｂのスイッチ操作１００が実行されると、送信処理１１０ａが実行される。送信処理１１０ａにより送信される「要求」の送信データ１７１には、番号としての「０００１」と、要求処理としての「ＵＬＫ」と、診断情報としての「良」とが含まれる。ここでは、履歴データがない。
【００６５】
送信データ１７１が車載機２に受信されると、車載機２は錠制御処理１３０ａを実行する。さらに、車載機２では、診断処理１４０ａが実行される。ここでは、ステップ１４１−１４３、１４４、１４８−１５０の処理が実行される。「応答」の送信データ１８１には、番号としての「０００１」と、遂行された処理としての「ＵＬＫ」とが含まれる。また、送信データ１７１が正常に受信されたことを示す「ＯＫ」が第１履歴に格納されている。この結果、車載機２における処理は正常に終了する。
【００６６】
ここで、「応答」の送信データ１８１が何らかの不具合によって携帯機３に受信されない場合を想定する。この場合、携帯機３は、受信処理１２０ａを実行するが、所定のタイムアップ時間を待っても車載機２からは正規の応答が得られない。よって、ステップ１２１−１２３、１２４の処理が実行される。この結果、携帯機３は、２回目の送信処理１１０ｂを実行する。ここでは、２回目の送信処理であるので、番号として「００１０」を付した送信データ１７２が送信される。この送信データ１７２には、送信処理１１０ａにおける不具合を「無し」によって示す第１履歴が含まれている。
【００６７】
この送信データ１７２が車載機２に受信されると、車載機２は錠制御処理１３０ｂを実行する。さらに、車載機２では、診断処理１４０ｂが実行される。ここでは、ステップ１４１−１４３、１４５−１５０の処理が実行される。この結果、車載機２から携帯機３への通信方向に不具合が生じたことを示すように、診断情報が記憶される。
【００６８】
さらに、「応答」の送信データ１８２には、番号としての「００１０」と、遂行された処理としての「ＵＬＫ」とが含まれる。また、送信データ１７１が正常に受信されたことを示す「ＯＫ」が第１履歴に格納されている。さらに、送信処理１１０ａにおける不具合に対応する診断情報が記録されたことを示す「済」が第２履歴に格納されている。
【００６９】
送信データ１８２が携帯機３に受信されると、受信処理１２０ｂが実行される。ここでは、ステップ１２１−１２３、１２５の処理が実行される。この処理により、番号「００１０」で示されるひとつのセッションが完結する。ステップ１２５において履歴データが消去されるので、次のセッションの「要求」の送信データでは、履歴データが存在しない。
【００７０】
以上に説明した実施形態によると、セッションを開始するための「要求」を送信する携帯機３が「要求」に対応する「応答」が得られないことを連続性データに基づいて判定する。その後、携帯機３は、「応答」がない状態を、履歴データによって車載機２に通知する。一方、車載機２は、携帯機３からの「要求」に対応する「応答」を送信したか否かを連続性データに基づいて判定する。ここで、携帯機３から通知された「応答」の有無と、車載機２からの「応答」の送信有無との論理的な関係により、不具合を生じた通信方向が示される。そして、車載機２は、不具合を生じた通信方向を示す診断コードと、通信環境を示すデータとを診断情報として記録する。さらに、診断情報は、診断機器などに出力可能な態様で車載機２に記録される。これにより、通信の不具合を診断し、原因の特定、対策の立案を遂行することが容易となる。
【００７１】
（第２実施形態）
次に、本発明を適用した第２実施形態を説明する。先行する説明を参照することができる構成要素には、先行実施形態と同一の符号を付した。この実施形態では、車載機２が診断情報を記録する記録手段を搭載する記録機とされ、さらに、車載機２が一組の往復通信を開始するための「要求」を非同期的に発出する開始機とされている。
【００７２】
第２実施形態では、図１に図示された構成を採用し、図２に図示された通信データ１０の構成が採用されている。この実施形態では、認証済みの携帯機３が、車両から所定範囲内に存在するか否かをポーリング通信によって確認している。その上で、車載機２は、車外に設けられたタッチスイッチが操作されると、過去の開錠操作または施錠操作の失敗があったか否かを判定し、必要な診断情報を記録するための通信を携帯機３との間で開始する。この実施形態では、車載機２から「要求」が発出される。また、携帯機３から「応答」が送信される。よって、車載機２が第１通信機として機能し、携帯機３が第２通信機として機能する。
【００７３】
ブロック１１には、連続性データが格納される。ブロック１２には、今回の処理を示すデータと、診断情報を示すデータとが格納される。例えば、以下のようなデータが格納される。車載機２からの「探索要求」においては、「探索要求」を示すコードが格納される。また、携帯機３からの応答においては、応答を示すコードが格納される。さらに、携帯機３からの応答においては、診断情報として、電池電圧の良否を示す符号、例えば「良」または「不良」を示すコードが格納される。なお、車載機２からの「探索要求」においては、診断情報は車載機２で記録されるため、診断情報は格納されない。ブロック１３には、過去の複数回の通信履歴を示すデータが格納される。例えば、以下のようなデータが格納される。まず、過去の通信履歴に不具合が生じていない場合には、履歴データは格納されない。車載機２からの「探索要求」においては、処理として、車載機２から「探索要求」を送信したにもかかわらず携帯機３からの「応答」が受信されていないことを示す「無し」が格納されることがある。また、携帯機３からの応答においては、当該過去の通信（応答）における診断情報として、電池電圧の良否を示す符号、例えば「良」または「不良」が格納されることがある。また、携帯機３からの「応答」においては、処理として、車載機２からの「探索要求」が正常に受信されたことを示す「ＯＫ」が格納されることがある。また、携帯機３からの「応答」においては、車載機２から通知される「無し」に応答して、「探索要求」が受信されていないことを示す「無し」が格納されることがある。この情報に基づき、車載機２では、診断情報の記録処理が実行される。また、車載機２からの「探索要求」においては、診断情報が記録されたことを示す「済」が格納されることがある。
【００７４】
図９ないし図１１には、車両用リモコンシステム１において実行されるフローチャートが示されている。これらのフローチャートに示された処理により、機器の故障と機器の不作動との両方を含む通信の不具合を検出する検出手段と、診断情報を記録する診断情報記録手段とが提供される。
【００７５】
図９において、車載機２における送信処理２１０のフローチャートが示されている。ステップ２１１では、車外のタッチスイッチが操作されたか否かが判定される。ここでは、タッチスイッチが操作されるまで待ち、タッチスイッチが操作されるとステップ２１２へ進む。ステップ２１２では、番号に単位数を加算することにより、「要求」の番号が算出され、記憶される。これにより、新たなセッションの開始が車載機２において記憶される。ステップ２１３では、「探索要求」のデータが作成され、送信される。送信データには、連続性データとしての番号と、これまでの履歴データとが含まれる。よって、ステップ２１３が第１履歴送信手段を提供する。
【００７６】
図１０において、車載機２における診断処理２４０のフローチャートが示されている。車載機２は、携帯機３からの「応答」をモニタしており、「応答」を受信すると診断処理２４０を開始する。まず、ステップ２４１では、携帯機３からの「応答」が受信される。ステップ２４２では、「応答」から連続性データと履歴データとが取得される。
【００７７】
ステップ２４３では、連続性データに基づいて、正規の「応答」が得られたか否かを判定する。ここでは、「探索要求」に付した番号と同じ「応答」が所定時間以内に得られたか否かを判定する。正規の「応答」がない場合、ステップ２４４に進む。ステップ２４４では、車載機２からの探索要求に対する「応答」が何らかの理由により得られないことを示す診断コードを設定する。この時点では、携帯機３が通信可能範囲にあるのに「応答」がないのか、携帯機３が通信可能範囲外にあるから「応答」が得られないのかなどは診断されない。
【００７８】
ステップ２４５では、診断情報を記録する。この時点で得られる診断情報は、正規の応答が得られなかった原因を特定するには、不十分である。そのような診断情報は、次にタッチスイッチが操作され、携帯機３との間で正規の通信が実現されたときに記録される。ステップ２４６では、履歴を蓄積する。ここでは、正規の「応答」が得られていないので、最新履歴に「無し」を記憶する。この履歴は、次回の「探索要求」におけるステップ２１３で参照される。車載機２における処理は、ここで一旦は終了し、次にタッチスイッチが操作されるのを待つこととなる。
【００７９】
一方で、ステップ２４３において、正規の「応答」が得られたと判定すると、ステップ２４７に進む。ステップ２４７では、履歴データに異常があるか否かを判定する。いずれかの履歴データに「無し」または「ＮＧ」が含まれている場合、異常ありと判定され、ステップ２４８に進む。ステップ２４８では、それぞれの履歴の内容に応じた診断コードが設定される。ここでは、以下の２つの場合に応じて診断コードを設定する。
【００８０】
第１に、履歴データが「ＮＧ」である場合は、携帯機３が「応答」を試みた場合である。この場合、携帯機３が送信したはずの「応答」を車載機２が受信できていない状態である。この場合、携帯機３から車載機２への通信方向に不具合が生じていると考えられる。そこで、ステップ２４８では、「応答」を車載機２が受信できていないことを示す診断コードを設定する。なお、ここで想定される不具合には、携帯機３の送信機能の異常、携帯機３から車載機２への通信環境の悪さ、車載機２の受信機能の異常などが含まれる。
【００８１】
第２に、履歴データが「無し」である場合は、携帯機３に「探索要求」が受信されていない場合である。この履歴データは、後述のステップ２２５において設定される。この場合、車載機２から携帯機３への通信方向に不具合が生じていると考えられる。そこで、ステップ２４８では、車載機２が送信した「探索要求」を携帯機３が受信できていないことを示す診断コードを設定する。
【００８２】
ステップ２４９では、診断情報を記録する。ステップ２４９では、先に実行されたステップ２４５での診断情報に、追加して診断情報を記録する。ステップ２４７からステップ２４８を経由する場合は、既に先のタッチスイッチ操作時に正規の「応答」が無かった場合である。よって、先のステップ２４５において、既に診断情報が部分的に記録されている。そこで、ステップ２４９では、ステップ２４５で記録された診断情報に追加して、さらに診断情報を記録する。特に、不具合を生じた通信方向を示す診断コードが記録されることで、先のステップ２４５では得られなかった診断情報を記録することができる。ステップ２５０では、診断情報が記録された履歴に「済」を記憶する。ステップ１５１では、最新履歴に「ＯＫ」を記憶し、履歴を蓄積する。
【００８３】
ステップ２４７において、履歴データに異常がないと判定されると、ステップ２５２に進む。ステップ２４３−２４７−２５２を経由する場合は、通信上の不具合が生じていないと考えられる。そこで、ステップ２５２では、車載機２に記憶されている履歴を消去する。この履歴は、ステップ２１３の送信処理において参照される。
【００８４】
図１１において、携帯機３における応答処理２２０のフローチャートが示されている。ステップ２２１では、車載機２からの「探索要求」が受信される。ステップ２２２では、「探索要求」から連続性データと履歴データとが取得される。ステップ２２３では、「探索要求」に含まれる履歴データに異常があるか否かを判定する。履歴データに「無し」がある場合、異常ありと判定される。ステップ２２４では、連続性データに基づいて、番号に抜けがあるか否かを判定する。ここでは、前回の応答処理において処理した「応答」の番号と、今回受信された「探索要求」の番号とが比較される。番号が飛んでいれば、ステップ２２５へ進む。
【００８５】
ステップ２２５では、履歴データを蓄積する。この処理では、「応答」がなかったことを示す「無し」が記憶された履歴データに、「探索要求」が受信されていないことを示す「無し」を再び記憶する。この「無し」は、車載機２からの前回の「要求」が正常に届いていなかったことを示す情報である。さらに、ステップ２２６では、直前の「探索要求」が正常に受信されたことを示す「ＯＫ」を最新履歴に記憶する。ステップ２２７では、番号処理が実行される。ステップ２２８では、「応答」のデータが作成され送信される。送信データには、連続性データとしての番号と、今回の処理を示す処理データと、携帯機３における診断情報としての電池データと、これまでの履歴データとが含まれる。よって、ステップ２２８が第２履歴送信手段を提供している。
【００８６】
ステップ２２４において番号抜けがないと判定されると、ステップ２２９に進む。ステップ２２９では、履歴データを蓄積する。この処理では、「応答」がなかったことを示す「無し」が記憶された履歴データに、「応答」を送信したことを示す「ＮＧ」を記憶する。この「ＮＧ」は、車載機２からの前回の「要求」が正常に届いていたが、それに対する携帯機３からの「応答」が車載機２に正常に届かなかったことを示す情報である。この後、ステップ２２６へ進む。
【００８７】
ステップ２２３において、履歴データに異常がないと判定されると、ステップ２３０へ進む。ステップ２３０では、履歴データを消去する。この後、ステップ２２６へ進む。
【００８８】
次に、この実施形態の作動を説明する。図１２ないし図１４は、車載機２と携帯機３との間の通信手順を示すシーケンスチャートである。図１２は、正常な通信がされているときの処理と、通信データ内容を示す。図１３は、「探索要求」に不具合が生じたときの処理と、通信データ内容を示す。図１４は、「応答」に不具合が生じたときの処理と、通信データ内容を示す。
【００８９】
（正常時）
図１２において、まず、車載機２において送信処理２１０が実行される。送信処理２１０により送信される「探索要求」の送信データ２７１には、番号としての「０００１」と、要求処理としての「探索要求」とが含まれる。ここでは、履歴データがない。
【００９０】
送信データ２７１が携帯機３に受信されると、携帯機３は応答処理２２０を実行する。「応答」の送信データ２８１には、番号としての「０００１」と、遂行された処理としての「応答」と、診断情報としての電池電圧を示す「良」が含まれる。さらに、送信データ２７１が正常に受信されたことを示す「ＯＫ」が第１履歴に格納される。
【００９１】
送信データ２８１が車載機２に受信されると、診断処理２４０が実行される。この処理により、ひとつのセッションが完結する。同様の通信処理が繰り返えされることにより車載機２から携帯機３を呼び出し、その存在を確認する処理が実行される。
【００９２】
（要求不具合時）
図１３において、まず、タッチスイッチが操作されると、車載機２において、送信処理２１０ａが実行される。ここで、送信データ２７１が何らかの不具合によって携帯機３に受信されない場合を想定する。この場合、車載機２は、診断処理２４０ａを実行するが、所定のタイムアップ時間を待っても携帯機３からは正規の応答が得られない。よって、ステップ２４１−２４３、２４４−２４６の処理が実行される。この結果、番号「０００１」の「探索要求」に対応する診断情報がステップ２４５において記録される。
【００９３】
やがて、再びタッチスイッチが操作されると、車載機２は、２回目の送信処理２１０ｂを実行する。ここでは、２回目の送信処理であるので、番号として「００１０」を付した送信データ２７２が送信される。この送信データ２７２には、送信処理２１０ａにおける不具合を示す第１履歴が含まれている。
【００９４】
ここで、再び、送信データ２７２が何らかの不具合によって携帯機３に受信されない場合を想定する。この場合、車載機２は、診断処理２４０ｂを実行するが、所定のタイムアップ時間を待っても携帯機３からは正規の応答が得られない。よって、ステップ２４１−２４３、２４４−２４６の処理が再び実行される。この結果、番号「００１０」の「探索要求」に対応する診断情報がステップ２４５において記録される。
【００９５】
やがて、さらにタッチスイッチが操作されると、車載機２は、３回目の送信処理２１０ｃを実行する。ここでは、３回目の送信処理であるので、番号として「００１１」を付した送信データ２７３が送信される。この送信データ２７３には、送信処理２１０ａにおける不具合を示す第２履歴と、送信処理２１０ｂにおける不具合を示す第１履歴とが含まれている。
【００９６】
この送信データ２７３が携帯機３に受信されると、携帯機３は応答処理２２０を実行する。「応答」の送信データ２８１には、番号としての「００１１」が含まれる。また、送信データ２７３が正常に受信されたことを示す「ＯＫ」が第１履歴に格納されている。さらに、送信処理２１０ａにおける「応答無し」に対応する「探索要求の受信無し」を示す「無し」が第３履歴に格納され、送信処理１１０ｂにおける「応答無し」に対応する「探索要求の受信無し」を示す「無し」が第２履歴に格納されている。
【００９７】
送信データ２８１が車載機２に受信されると、車載機２では、診断処理２４０ｃが実行される。ここでは、ステップ２４１−２４３、２４７、２４８−２５１の処理が実行される。この結果、車載機２から携帯機３への通信方向に不具合が生じたことを示す診断コードが設定され、診断情報が記憶される。ここで、ステップ２４９では、先のステップ２４５で記録された番号「００１０」の「探索要求」に対応する診断情報に追加して、第２履歴に基づく診断コードを含む診断情報を記録する。さらに、ステップ２４９では、先の先のステップ２４５で記録された番号「０００１」の「探索要求」に対応する診断情報に追加して、第３履歴に基づく診断コードを含む診断情報を記録する。このように、過去の錠操作の失敗ごとに、診断コードを含む診断情報が記録される。この後、再び送信処理が実行されると、履歴データに「済」を格納した送信データ２７４が送信される。
【００９８】
（応答不具合時）
図１４において、まず、タッチスイッチが操作されると、車載機２において送信処理２１０ａが実行される。送信データ２７１が携帯機３に受信されると、携帯機３は応答処理２２０ａを実行する。ここで、「応答」の送信データ２８１が何らかの不具合によって車載機２に受信されない場合を想定する。この場合、車載機２は、診断処理２４０ａを実行するが、所定のタイムアップ時間を待っても携帯機３からは正規の応答が得られない。この結果、番号「０００１」の「探索要求」に対応する診断情報がステップ２４５において記録される。
【００９９】
やがて、さらにタッチスイッチが操作されると、車載機２は、２回目の送信処理２１０ｂを実行する。ここでは、２回目の送信処理であるので、番号として「００１０」を付した送信データ２７２が送信される。この送信データ１７２には、送信処理１１０ａにおける不具合を示す第１履歴が含まれている。
【０１００】
この送信データ２７２が携帯機３に受信されると、携帯機３は応答処理２２０ｂを実行する。ここでは、ステップ２２１−２２３、２２４、２２９、２２６−２２８の処理が実行される。この結果、「応答」の送信データ２８２には、番号としての「００１０」が含まれる。また、第１履歴には、送信データ２７２が正常に受信されたことを示す「ＯＫ」が格納される。さらに、第２履歴には、送信処理２１０ａに対応する「応答」を送信したにもかかわらず、それが車載機２に到達しなかったと思われることを示す「ＮＧ」が格納される。
【０１０１】
この後、送信データ２８２が車載機２に受信されると、診断処理２４０ｂが実行される。この結果、携帯機３から車載機２への通信方向に不具合が生じたことを示す診断コードが設定され、診断情報が記憶される。ここで、ステップ２４９では、先のステップ２４５で記録された番号「０００１」の「探索要求」に対応する診断情報に追加して、第２履歴に基づく診断コードを含む診断情報を記録する。このように、過去の錠操作の失敗ごとに、診断コードを含む診断情報が記録される。
【０１０２】
以上に説明した実施形態によると、セッションを開始するための「要求」を送信する車載機２が「探索要求」に対応する「応答」が得られないことを連続性データに基づいて判定する。その後、車載機２は、「応答」がない状態を、履歴データによって携帯機３に通知する。一方、携帯機３は、車載機２からの「探索要求」に対応する「応答」を送信したか否かを連続性データに基づいて判定する。ここで、車載機２から通知された「応答」の有無と、携帯機３からの「応答」の送信有無との論理的な関係により、不具合を生じた通信方向が示される。そして、車載機２は、不具合を生じた通信方向を示す診断コードと、通信環境を示すデータとを診断情報として記録する。さらに、車載機２は、記録した診断情報を診断機器などに出力する。これにより、通信の不具合を診断し、原因の特定、対策の立案を遂行することが容易となる。
【０１０３】
（他の実施形態）
本発明の技術的範囲は、上述した実施形態にのみ限定されるものではない。上述した実施形態は、本発明の技術的範囲内で、多様な変形、改良、または拡張を伴うことができる。本発明は、少なくとも次のような変形、改良または拡張を伴う実施形態を包含する。
【０１０４】
例えば、第１実施形態の構成と、第２実施形態の構成との両方をひとつのシステムに搭載してもよい。また、携帯機３に記録手段を設けるとともに、携帯機３に診断情報を集めて、携帯機３において診断情報を記録してもよい。また、上記実施形態では、車載機２に診断情報を集めた後に、診断情報を携帯機３に送信して、携帯機３に設けた記録手段に診断情報を記録してもよい。
【符号の説明】
【０１０５】
１  車両用リモコンシステム
２  車載機
３  携帯機
２１  送受信機
２２  制御装置
２２ａ  連続性判定手段
２２ｂ  履歴判定手段
２２ｃ  記録手段
２３  診断情報取得装置
２３ａ  ノイズ測定装置
２３ｂ  受信装置
２４  スイッチ群
２５  ドアロックアクチュエータ
３１  送受信機
３２  制御装置
３３  診断情報取得装置
３４  スイッチ群
３２ａ  連続性判定手段
３２ｂ  履歴判定手段
３３ａ  電池電圧検出装置
３４ａ  ＬＫ（施錠）スイッチ
３４ｂ  ＵＬＫ（開錠）スイッチ
【図１】
2010232873.tif 000003
【図２】
2010232873.tif 000004
【図３】
2010232873.tif 000005
【図４】
2010232873.tif 000006
【図５】
2010232873.tif 000007
【図６】
2010232873.tif 000008
【図７】
2010232873.tif 000009
【図８】
2010232873.tif 000010
【図９】
2010232873.tif 000011
【図１０】
2010232873.tif 000012
【図１１】
2010232873.tif 000013
【図１２】
2010232873.tif 000014
【図１３】
2010232873.tif 000015
【図１４】
2010232873.tif 000016