(57)【特許請求の範囲】
【請求項１】
複数のタイムスロットが設定され、各ノードは、割り当てられたタイムスロットにて、周期的にフレームを送信するタイム・トリガ型の時分割多重通信システムであって、前記各ノードから送信されるフレームには、フレームが送信されるタイムスロットの識別コードが記される時分割多重通信システム
の通信バスに接続されて、前記時分割多重通信システムを診断する診断装置であって、
前記通信バスから入力される通信信号のエッジを検出して、エッジ間の時間長さを計測することにより、前記通信バスを介してノード間で行われている通信のビット長を特定するビット長計測手段と、
前記ビット長計測手段により特定されたビット長に合わせて、前記通信バスから入力される通信信号をデコードし、前記通信信号に含まれるフレームに記された前記識別コード、及び、前記フレームの受信時刻を特定する信号処理手段と、
前記信号処理手段により特定された受信時刻及び識別コードを、記憶する受信履歴記憶手段と、
前記受信履歴記憶手段が記憶する受信時刻及び識別コードに基づき、予め定められた診断対象のタイムスロットにて、送信されているフレームの送信周期を、推定する送信周期推定手段と、
前記送信周期推定手段による送信周期の推定後、前記診断対象のタイムスロットにおいて、前記送信周期推定手段により推定された送信周期で、フレームが送信されているか否かを、前記信号処理手段により特定されるフレームの受信時刻及び識別コードの情報に基づき、判定する送信周期異常判定手段と、
前記送信周期異常判定手段により、前記推定された送信周期でフレームが送信されていないと判定されると、通信の異常を報知する報知手段と、
を備えると共に、
予め設定された通信スケジュールを表す通信パラメータに基づき動作して、前記通信バスを流れる通信信号から、前記各ノードが、割り当てられたタイムスロット内で、正常にフレームを送信しているか否かを判定するフレーム異常判定手段と、
前記通信バスから入力され前記信号処理手段によりデコードされた通信信号に基づき、前記フレーム異常判定手段に設定すべき前記通信パラメータを導出し、前記導出した通信パラメータを、前記フレーム異常判定手段に設定するパラメータ設定手段と、
を備え、
前記報知手段は、更に、前記フレーム異常判定手段により、正常にフレームを送信していないと判定されると、通信の異常を報知する構成にされていること
を特徴とする診断装置。
【請求項２】
前記送信周期異常判定手段は、
前記診断対象のタイムスロットにて送信されたフレームを自装置が受信すると、前記信号処理手段にて特定された当該フレームの受信時刻と、前記送信周期推定手段により推定された当該フレームの送信周期と、に基づき、当該フレームと同一のタイムスロットにて送信されるフレームの次回受信時刻を予測する予測手段と、
前記診断対象のタイムスロットにて送信されたフレームを自装置が受信すると、前記信号処理手段にて特定された当該フレームの受信時刻と、このフレームについて前記予測手段により前回予測された受信時刻との誤差を算出する誤差算出手段と、
を備え、
前記誤差算出手段により算出された誤差に基づき、前記診断対象のタイムスロットにおいて、前記送信周期推定手段により推定された送信周期で、フレームが送信されているか否かを判定する構成にされていること
を特徴とする請求項１記載の診断装置。
【請求項３】
前記送信周期異常判定手段は、前記誤差算出手段により算出された誤差が所定の基準値を超えている場合、前記送信周期推定手段により推定された送信周期でフレームが送信されていないと判定し、前記誤差算出手段により算出された誤差が前記基準値以下である場合、前記送信周期推定手段により推定された送信周期でフレームが送信されていると判定する構成にされていること
を特徴とする請求項２記載の診断装置。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、時分割多重通信システムの通信バスに接続され、通信バスを流れる通信信号から、システムを診断する診断装置に関する。
【背景技術】
【０００２】
従来、時分割多重通信システムとしては、イベント・トリガ型の通信システム、及び、タイム・トリガ型の通信システムが知られている（例えば、特許文献１参照）。
イベント・トリガ型の通信システムは、各ノードが、イベントの発生に伴って、通信要求を発し、送信権を獲得することができた場合に限って、送信対象のデータを送信し、各ノード間でデータの送受を行うものである。
【０００３】
一方、タイム・トリガ型の通信システムは、一定時間を複数のタイムスロットに分割して、各ノードに、個別のタイムスロットを割り当て、各ノードが、他のノードとは重複しない個別の時間帯に、データを送信するようにしたシステムである。
【０００４】
タイム・トリガ型の通信システムでは、タイムスロット数、ビット長、スロット長、フレーム長等の種々の通信パラメータを通じて、各ノードに、通信スケジュールを設定する必要がある。また、これらの通信パラメータは、クロック精度やバス遅延を考慮して、決定する必要がある。このため、この種の通信システムでは、設計者の意図した通りに、システムが動作しない場合がある。
【０００５】
また、タイム・トリガ型の通信システムでは、各ノードからのデータ送信タイミングがタイムスロットで規定されているため、アプリケーションプログラムの実行遅延等で、送信タイミングまでに、送信対象のデータの生成が間に合わないと、このノードからは、送信対象のデータを送信することができず、データの送信抜けが生じる。
【０００６】
このように、タイム・トリガ型の通信システムでは、種々の原因により、システムが、正常に動作しない場合がある。このため、従来では、診断装置にて、正しく通信が行われているかどうかを検査して、システムを診断することが行われている。
【０００７】
従来の診断方法としては、例えば、通信信号をデコードして、これを記録し、設計者が、この記録内容を、コンピュータ等を通じて解析することで、システムを診断する方法が知られている。また、別の診断方法としては、診断装置に、通信スケジュールを設定することで、診断装置をシステムに同期させ、この状態で、システムを診断する方法が知られている。
【特許文献１】特開２００６−３１９３９４号公報
【発明の開示】
【発明が解決しようとする課題】
【０００８】
しかしながら、従来の診断方法では、次のような問題があった。例えば、通信信号をデコードして、これを記録し、設計者が、この記録内容を、コンピュータ等を解析することで、システムを診断する方法では、通信信号の内容（「０」「１」）を把握することができる程度で、フレームの送信動作に係る挙動を、時間的な視点から、把握することができないといった問題があった。また、この診断方法では、所定時間、通信信号をデコードした結果を記録して、記録内容を、コンピュータ等で解析する程度であるため、リアルタイムに、システムを診断することができないといった問題があった。
【０００９】
その他、診断装置をシステムに同期させる方法では、診断装置に、誤った通信パラメータが設定されてしまうと、適切な診断を行うことができないといった問題があった。また、通信パラメータの設定ミスについては、気づきにくいため、設計者が、システムの異常を解消するのに、無駄な考察をしてしまう可能性があった。
【００１０】
また、特許文献１には、診断装置に自動で通信スケジュールを設定する技術が開示されているが、この技法は、診断対象であるタイム・トリガ型の通信システムとは別に、通信システムが併設された環境で、これらのネットワークを結ぶゲートウェイ装置から、通信スケジュールを取得して、診断装置をシステムに同期させるものであるため、複数の通信システムが併設された環境以外では、利用することができないといった問題があった。
【００１１】
本発明は、こうした問題に鑑みなされたものであり、タイム・トリガ型の時分割多重通信システムにおいて、各ノードから適切にデータの送信動作がなされているか否かを、簡便に診断可能な技術を提供することを目的とする。
【課題を解決するための手段】
【００１２】
かかる目的を達成するためになされた本発明（請求項１記載）の診断装置は、各ノードが、予め割り当てられたタイムスロットにて、周期的にフレームを送信するタイム・トリガ型の時分割多重通信システムであって、各ノードから送信されるフレームには、フレームが送信されるタイムスロットの識別コードが記される時分割多重通信システム、の通信バスに接続されて、使用されるものである。この診断装置は、上記種類の時分割多重通信システムを診断するのに用いられる。
【００１３】
この診断装置は、通信バスから入力される通信信号のエッジを検出して、エッジ間の時間長さを計測することにより、通信バスを介してノード間で行われている通信のビット長を特定するビット長計測手段と、ビット長計測手段により特定されたビット長に合わせて、通信バスから入力される通信信号をデコードし、この通信信号に含まれるフレームに記された識別コード及びフレームの受信時刻を特定する信号処理手段と、を備え、信号処理手段にて特定されたフレームの受信時刻及び識別コードを、受信履歴記憶手段により記憶する。
【００１４】
また、診断装置は、受信履歴記憶手段が記憶する受信時刻及び識別コードの情報に基づき、診断対象のタイムスロットにて送信されるフレームの送信周期を推定する送信周期推定手段を備え、送信周期推定手段による送信周期の推定後、診断対象のタイムスロットにおいて、上記推定された送信周期で、フレームが送信されているか否かを、信号処理手段にて特定されるフレームの受信時刻及び識別コードの情報に基づき、送信周期異常判定手段により判定する。そして、送信周期異常判定手段により、上記推定された送信周期でフレームが送信されていないと判定されると、通信の異常を、報知手段により報知する。
【００１５】
この他、本発明の診断装置は、予め設定された通信スケジュールを表す通信パラメータに基づき動作して、通信バスを流れる通信信号から、各ノードが、割り当てられたタイムスロット内で、正常にフレームを送信しているか否かを判定するフレーム異常判定手段と、通信バスから入力され信号処理手段によりデコードされた通信信号に基づき、フレーム異常判定手段に設定すべき上記通信パラメータを導出し、導出した通信パラメータを、フレーム異常判定手段に設定するパラメータ設定手段と、を備え、フレーム異常判定手段により、正常にフレームを送信していないと判定されると、通信の異常を報知する構成にされている。
【００１６】
このように構成された診断装置では、作業者が当該診断装置を通信バスに接続すると、作業者が診断装置にビット長等を設定しなくとも、通信信号がデコードされて、診断対象のタイムスロットにて一定周期でフレームが送信されているか否かが検査される。即ち、本発明の診断装置によれば、作業者は、診断装置にビット長等を設定せずに、簡単な作業で、システムの診断を行うことができ、一定周期でフレームが送信されているかを検査することができる。
【００１７】
従って、作業者は、簡単な作業で、各ノードから適切な周期で、送信漏れなく、フレームが送信されているか否かを検査することができ、各ノードにて、アプリケーションプログラムが遅延なく正常にデータを生成しているか否か等、システムが正常動作しているか否かを診断することができる。即ち、この発明によれば、簡便に、各ノードから適切にデータの送信動作がなされているか否かを、時間的な視点で検査して、システムを診断することができる。
また、診断装置に、スロット長等の通信スケジュールを表す通信パラメータを設定して、診断装置を、通信システムに同期させれば、フレームが定期的に送信されているか否かに加えて、例えば、タイムスロット内に、正常にフレームが納まっているか否か等の検査を行うことができるが、従来のように、通信パラメータの入力を作業者から受け付けて、診断装置に通信スケジュールを設定し、診断装置を通信システムに同期させる場合には、作業者の入力ミス等により、診断装置に正しい通信スケジュールが設定されない場合があり、この場合には、誤った診断が行われることになる。
そこで、本発明では、上述したように、通信バスから入力される通信信号に基づき、通信パラメータを設定する手段を設けている。
従って、本発明の診断装置によれば、作業者に対し通信パラメータの入力を求めることなく、システムに同期して通信信号を監視することができ、フレームの送信抜け等に加えて、フレームがタイムスロットからはみ出すように送信されていないかどうか等の詳細な検査を行うことができ、詳細にシステムを診断することができる。即ち、この診断装置によれば、簡便に、システムの詳細な診断を行うことができる。
【００１８】
尚、診断装置は、診断対象のタイムスロットを、入力手段を通じて入力されるユーザからの指令に従って、定める構成にすることができる。また、診断対象のタイムスロットは、設計段階で、予め定められても良い。例えば、全タイムスロットを診断対象のタイムスロットとすれば、当該診断装置で、全タイムスロットの診断を行うことができる。
【００１９】
また、上述の診断装置には、診断対象のタイムスロットにて送信されたフレームを自装置が受信すると、当該フレームについての受信時刻と、送信周期推定手段により推定された当該フレームの送信周期と、に基づき、当該フレームと同一のタイムスロットにて送信されるフレームの次回受信時刻を予測する予測手段を設けるとよい。
【００２０】
また、この診断装置には、診断対象のタイムスロットにて送信されたフレームを受信すると、当該フレームについての受信時刻と、このフレームについて予測手段により前回予測された受信時刻との誤差を算出する誤差算出手段を設け、送信周期異常判定手段は、誤差算出手段により算出された誤差に基づき、診断対象のタイムスロットにおいて、送信周期推定手段により推定された送信周期で、フレームが送信されているか否かを判定する構成にされるとよい（請求項２）。
【００２１】
このように、フレームの受信時点で、次回のフレームの受信時刻を予測し、診断対象のタイムスロットにおいて、送信周期推定手段により推定された送信周期で、フレームが送信されているか否かを判定するようにすれば、リアルタイムに、適切な送信周期でフレームが送信されているか否かを判定することができて、通信の異常を、迅速に報知することができる。従って、作業者は、異常が報知された時点で、直ちに、異常の発生原因を究明することができ、迅速に、システムを修正することができる。
【００２２】
また、送信周期異常判定手段は、具体的に、上記誤差が所定の基準値を超えている場合、フレームが送信周期推定手段により推定された送信周期で送信されていないと判定し、上記誤差が基準値以下である場合、フレームが送信周期推定手段により推定された送信周期で送信されていると判定する構成にすることができる（請求項３）。
【発明を実施するための最良の形態】
【００２９】
以下に本発明の実施例について、図面と共に説明する。
図１は、本発明が適用された診断装置１０の構成を表すブロック図である。本実施例の診断装置１０は、診断対象の通信システム３０において通信信号の伝送に用いられる通信バス３１に接続され、診断対象の通信システム３０を診断するものである。
【００３０】
本実施例の診断装置１０が診断対象とする通信システム３０は、タイム・トリガ型の時分割多重通信システムである。この通信システム３０を構成する各ノード３３は、タイム・トリガ方式にて、通信バス３１を通じ、通信信号を伝送し、他のノード３３と通信を行う。
【００３１】
具体的に、この通信システム３０では、一定時間が通信サイクルとして定められており、当該一定時間が、定期送信セグメントと、イベント送信セグメントと、ネットワークアイドル時間と、に分割されている。図２は、１通信サイクル内での通信の態様を示した説明図である。
【００３２】
図２に示すように、定期送信セグメントは、複数のタイムスロットの集合からなり、定期送信セグメントの時間長さは、定期送信セグメントを構成するタイムスロットのスロット長とスロット数との積で規定されている。以下では、定期送信セグメントを構成するタイムスロットのことを、特に、定期送信スロットと表現する。
【００３３】
定期送信セグメントにおける定期送信スロットのスロット長及びスロット数は、システムの設計時に設計者により定められるが、各定期送信スロットのスロット長は、定期送信セグメントにおいて同じ値に設定される。
【００３４】
各定期送信スロットは、通信システム３０を構成する複数のノード３３のいずれか一つに対し割り当てられており、各ノード３３は、定期送信セグメントにおいて、自ノードに割り当てられた定期送信スロットの到来時に、送信待ちのフレームを、通信バス３１に送出する。以下では、定期送信スロットにて送信されるフレームのことを、特に、定期送信フレームと表現する。
【００３５】
図２下段には、定期送信スロットのビットストリームを表す。図２下段に示すように、定期送信スロットでは、アイドル時間の経過後、フレームの送信に先立つスタートシーケンスが伝送され、その後、フレームが伝送され、フレームの伝送後には、エンドシーケンスが伝送される。尚、スタートシーケンスのビット数、及び、エンドシーケンスのビット数は、プロトコルにより、固定値に定められている。
【００３６】
定期送信フレームは、ヘッダ・セグメントと、ペイロード・セグメントと、トレーラ・セグメントと、からなり、ヘッダ・セグメントには、フレームＩＤ、ペイロード長、サイクル・カウンタ等の情報が記述される。尚、フレームＩＤは、タイムスロットの識別コードを表すものである。
【００３７】
即ち、本実施例の通信システム３０において、フレームのヘッダ・セグメントには、当該フレームが送信されるタイムスロットの識別コードが記述される。通信システム３０において、各タイムスロットには、タイムスロットの識別コードとして、通信サイクルの先頭から、順にスロット番号が連番で割り当てられており、ヘッダ・セグメントには、フレームＩＤとして、このスロット番号が記述される。
【００３８】
また、サイクル・カウンタは、通信サイクルの到来回数を表すものである。この通信システム３０では、１通信サイクルがα回繰り返されると、サイクル・カウンタがリセットされるように、各ノード３３が構成されている。また、ヘッダ・セグメントに記述されるペイロード長は、ペイロード・セグメントの長さを表すものである。
【００３９】
この他、ペイロード・セグメントには、送信対象のデータ本体が記述され、トレーラ・セグメントには、ＣＲＣ値が記述される。尚、ヘッダ・セグメント及びトレーラ・セグメントは、プロトコルで長さが固定値に定められており、本実施例が診断対象とする通信システム３０では、設計者が設定するペイロード長によりフレーム長が規定される。
【００４０】
また、イベント送信セグメントは、可変長のタイムスロットの集合からなる。このイベント送信セグメントでは、フレームの送信に伴って、スロット長が、最小単位の整数倍に拡張される。以下では、このイベント送信セグメントを構成するタイムスロットを、イベント送信スロットと表現し、このイベント送信スロットを通じて送信されるフレームのことを、イベント送信フレームと表現する。
【００４１】
このイベント送信セグメントにおいて、フレームの送信を伴わないイベント送信スロットは、そのスロット長が、最小単位に設定されるが、このイベント送信セグメント自体の長さは、各スロット長が変化しても変化することなく、固定で維持される。
【００４２】
このように、イベント送信セグメントでは、フレームの送信有無によってスロット長が可変であるため、イベント送信セグメントは、各ノード３３から非定期のデータを送信するのに用いられる。一方、定期送信セグメントは、定期的なデータの送信に用いられる。
【００４３】
即ち、本実施例が診断対象とする通信システム３０では、正常な通信が行われている場合、各定期送信スロットにて、通信サイクルの整数倍の周期で、フレームが送信される。例えば、スロット番号５の定期送信スロットでは、通信サイクルの１倍の周期で、フレームが送信され、スロット番号６の定期送信スロットでは、通信サイクルの２倍の周期で、フレームが送信される（図１０参照）。
【００４４】
但し、通信システム３０が正常に動作していない場合には、一部フレームの送信抜けが発生して、定期送信スロットから一定周期でフレームが送信されないことになる。このような事象が発生する原因としては、該当するノードで、送信対象のデータの生成が円滑に行われず、割り当てられたタイムスロットの到来時までに、データの生成が間に合わないことなどが挙げられる。この場合には、ノードから、送信されるべきサイクルで、フレームが送信されず、対応するフレームが、次サイクルで送信されることになる。
【００４５】
また、通信システム３０が車両に搭載されるシステムである場合には、バッテリの消耗による電圧低下などで、ノード３３の動作が不安定になり、上述の送信抜けが生じることもある。
【００４６】
本実施例の診断装置１０は、このような送信抜けを検知して、システムの正常／異常を診断する機能を有し、これを、作業者に対して、細やかな通信パラメータの入力を求めることなく、実現する。
【００４７】
続いて、この機能を有する本実施例の診断装置１０の構成について、具体的に説明する。本実施例の診断装置１０は、図１に示すように、制御部１１と、記憶部１３と、インタフェース（Ｉ／Ｆ）部１５と、表示部１７と、入力部１９と、通信部２１と、速度計測部２３と、を備える。
【００４８】
制御部１１は、マイクロコンピュータを備え、マイクロコンピュータにて各種演算処理を実行し、診断装置１０各部を統括制御するものである。一方、記憶部１３は、半導体製メモリで構成され、制御部１１による演算処理の結果得られたデータ等を記憶するために用いられる。また、インタフェース部１５は、外部装置と通信可能に構成されたものであり、外部装置が接続されると、外部装置と通信し、例えば、制御部１１に制御されて、記憶部１３に記憶されたデータ（例えば、後述するログファイル等）を外部装置に出力する。
【００４９】
また、入力部１９は、操作キーやポインティングデバイス等で構成され、ユーザインタフェースとして機能するものである。
この他、表示部１７は、液晶ディスプレイやスピーカ等から構成され、制御部１１に制御されて、制御部１１から入力された画像データに基づく画像を、液晶ディスプレイの画面上に表示すると共に、スピーカから各種音声を出力する。
【００５０】
また、通信部２１は、コネクタＣＮＴを通じて、通信システム３０の通信バス３１に接続され、通信バス３１を流れる通信信号をデコードして、デコード結果、即ち、通信信号を「０」「１」に置換して得られるビット列を、制御部１１に入力するものである。図３は、この通信部２１の詳細構成を表すブロック図である。
【００５１】
本実施例の通信部２１は、通信システム３０に採用された通信プロトコルにおけるデータリンク層・物理層レベルの通信処理を行うものであり、図３に示すように、デコード処理部２１１と、受信時刻検出部２１３と、ヘッダ解読部２１５と、エラー判定部２１７と、を備える。
【００５２】
デコード処理部２１１は、通信バス３１から入力される通信信号をデコードして、そのデコード結果を出力するものである。このデコード処理部２１１の起動に先駆けては、通信部２１に、デコード対象の通信信号のビット長（１ビット当たりの伝送時間）を設定する必要があるが、本実施例では、後述する速度計測部２３の計測結果に従って、制御部１１が、通信部２１に対して、このビット長を設定する。デコード処理部２１１は、このようにしてビット長が設定されると、設定されたビット長に合わせて、通信バス３１から入力される通信信号をデコードする。
【００５３】
一方、受信時刻検出部２１３は、デコード処理部２１１によるデコード結果に従って、フレームの受信を検知し、内蔵のタイマの値に基づき、フレームの受信時刻を検出するものである。例えば、受信時刻検出部２１３は、デコード結果からスタートシーケンスを検知した時点で、この時点でのタイマ値を、受信時刻として検出する。そして、検出した受信時刻を、制御部１１に入力する。
【００５４】
この他、ヘッダ解読部２１５は、上記デコード結果としてのビット列を解析し、スタートシーケンス以降に現れる受信フレームのヘッド・セグメントから、ヘッド・セグメントに記述された受信フレームのフレームＩＤ、ペイロード長、サイクル・カウンタの各値を抽出するものである。このヘッダ解読部２１５は、抽出したこれらの情報（フレームＩＤ、ペイロード長、及び、サイクル・カウンタの各値）を、ヘッダ情報として、制御部１１に入力する。
【００５５】
また、エラー判定部２１７は、予め設定された通信パラメータに従って、デコード処理部２１１から入力される上記ビット列を解析し、定期送信スロットにて送信されたフレームが、定期送信スロット内に納まっているか否かを判定して、フレームの送信異常を検知するものである。
【００５６】
図４は、エラー判定部２１７によるエラー判定の手法を示した説明図である。エラー判定部２１７は、受信フレームのヘッダ・セグメントに記載されたフレームＩＤから、受信フレームが定期送信フレームであるか否かを判定し、受信フレームが定期送信フレームである場合には、予め通信パラメータとして設定されたスロット長及びペイロード長の情報に従って、スタートシーケンス以降に現れるフレームの終端、及び、フレームの終端に続くエンドシーケンスの終端、並びに、タイムスロットの終端を特定する。
【００５７】
そして、エンドシーケンスの終端が、タイムスロットの終端より、時間的に後ろに位置すると、受信フレームが、定期送信スロット内に納まっていないと判定し、エンドシーケンスの終端が、タイムスロットの終端と一致又は時間的に前に位置すると、受信フレームが、定期送信スロット内に納まっていると判定する。図４（ａ）は、定期送信スロット内にフレームが納まっている状態を示す図であり、図４（ｂ）は、定期送信スロット内にフレームが納まっていない状態を示す図である。
【００５８】
エラー判定部２１７は、このようにして、受信フレームについて判定を行うと、この判定結果を表すエラー判定情報を、制御部１１に入力する。即ち、エラー判定部２１７は、受信フレームが、定期送信スロット内に納まっていると判定した場合、「正常」の旨のエラー判定情報を、制御部１１に入力し、受信フレームが定期送信スロット内に納まっていないと判定した場合、「フレームはみだしエラー有」の旨のエラー判定情報を制御部１１に入力する。
【００５９】
尚、エラー判定部２１７は、上述したように動作するため、本実施例の診断装置１０では、通信部２１に、ビット長と、定期送信スロットのペイロード長及びスロット長とを、設定しなければ、エラー判定部２１７を起動させることはできない。従って、本実施例では、これらの通信パラメータを、後述する処理（第二診断処理）にて求め、通信部２１に設定する。
【００６０】
また、本実施例の診断装置１０が備える速度計測部２３は、コネクタＣＮＴを通じて、通信バス３１に接続されており、通信バス３１から入力される通信信号のエッジを検出して、ノード３３間で行われている通信の通信速度を、計測する。具体的に、本実施例の速度計測部２３は、通信速度と等価なビット長を計測して、この計測結果を、制御部１１に入力する。尚、通信速度は、ビット長の逆数に一致する。
【００６１】
図５（ａ）は、速度計測部２３にて行われるビット長の計測手法を示した説明図であり、図５（ｂ）は、速度計測部２３が実行するビット長計測処理を表すフローチャートである。
【００６２】
図５（ａ）に示すように、本実施例の速度計測部２３は、通信信号のエッジを検出して、エッジ間の時間長さδＴを計測し、所定期間でのδＴの最小値を、ビット長として検出する。但し、通信信号にはノイズ成分が含まれるので、正確にビット長を計測するために、本実施例では、通信システム３０が採り得るビット長の最小値より十分小さいサンプリング周期で、複数回、通信信号の電圧値を検出し、ハイ又はロウへの切り替わり後、複数回、電圧値がハイ又はロウで維持された場合に限って、これをエッジとして検出する。
【００６３】
具体的に、速度計測部２３は、図５（ｂ）に示す手順でビット長を検出する。速度計測部２３は、制御部１１に制御されて、図５（ｂ）に示すビット長計測処理を開始すると、まず初期化処理を実行する（Ｓ１１０）。ここでは、診断対象の通信システム３０が規格上採り得るビット長の最大値を、ビット長推定値Ｇｇに設定する。また、エッジ検出時刻が設定されるパラメータＴｐ，Ｔｎの値をゼロに初期化する。
【００６４】
また、この処理を終えると、速度計測部２３は、通信バス３１より入力される通信信号からエッジを検出するまで待機し（Ｓ１２０）、エッジを検出すると（Ｓ１２０でＹｅｓ）、内蔵のカウンタをスタートさせる（Ｓ１３０）。但し、カウンタは、通信システム３０が規格上採り得る最小のビット長よりも十分短い単位で、時間をカウント可能な構成にされているものとする。
【００６５】
Ｓ１３０での処理を終えると、速度計測部２３は、次のエッジを検出するか、当該ビット長計測処理の終了条件が満足されるまで待機する（Ｓ１４０，Ｓ１４５）。具体的に、本実施例では、ビット長計測処理の開始後、所定時間が経過すると、ビット長計測処理の終了条件が満足されたとして（Ｓ１４５でＹｅｓ）、Ｓ２２０に移行する。
【００６６】
ここで、次のエッジを検出すると（Ｓ１４０でＹｅｓ）、速度計測部２３は、上記カウンタの値Ｔｃを読み出し（Ｓ１５０）、パラメータＴｐの値を、現在設定されているパラメータＴｎの値に更新すると共に、パラメータＴｎの値を、今回読み出したカウンタ値Ｔｃに更新する（Ｓ１６０）。ビット長計測処理開始後の初回エッジ検出時には（Ｓ１７０でＹｅｓ）、その後、Ｓ１４０に移行し、次のエッジを検出するか、ビット長計測処理の終了条件が満足されるまで待機する（Ｓ１４０，Ｓ１４５）。
【００６７】
そして、新たなエッジが検出されると（Ｓ１４０でＹｅｓ）、上記カウンタから、カウンタ値Ｔｃを読み出し（Ｓ１５０）、パラメータＴｐ，Ｔｎの値を、上述した手法で更新する（Ｓ１６０）。即ち、速度計測部２３は、パラメータＴｐに、前回エッジ検出時のカウンタ値を設定し、パラメータＴｎに、今回エッジ検出時のカウンタ値Ｔｃを設定する。その後、速度計測部２３は、エッジ検出が初回ではないと判断し（Ｓ１７０でＮｏ）、差分δＴを算出する（Ｓ１８０）。
【００６８】
δＴ＝Ｔｎ−Ｔｐ
また、この処理を終えると、速度計測部２３は、算出した差分δＴと、現在設定されているビット長推定値Ｇｇとを比較する（Ｓ１９０）。そして、差分δＴがビット長推定値Ｇｇ未満であると判断すると（Ｓ２００でＹｅｓ）、ビット長推定値Ｇｇを、差分δＴの値に更新する（Ｓ２１０）。その後、Ｓ１４０に移行する。
【００６９】
一方、算出した差分δＴがビット長推定値Ｇｇ以上である場合（Ｓ２００でＮｏ）、速度計測部２３は、ビット長推定値Ｇｇを更新することなく、Ｓ１４０に移行する。そして、Ｓ１４０〜Ｓ２１０の処理を、終了条件が満足されるまで繰返し実行する。
【００７０】
また、終了条件が満足されると（Ｓ１４５でＹｅｓ）、速度計測部２３は、Ｓ２２０に移行し、現在設定されているビット長推定値Ｇｇを、通信システム３０のビット長Ｇｂとして、制御部１１に入力する。その後、当該ビット長計測処理を終了する。
【００７１】
続いて、制御部１１が通信システム３０の診断のために実行する処理について、図６〜図１０を用いて説明する。本実施例の診断装置１０は、二種類の診断を行うことが可能な構成にされており、通信システム３０の通信バス３１に接続された状態で、入力部１９を通じて、外部（作業者）から第一診断処理の実行指令が入力されると、制御部１１にて、第一診断処理を実行する。図６は、制御部１１が実行する第一診断処理を表すフローチャートである。
【００７２】
第一診断処理を開始すると、制御部１１は、まず、診断対象の通信システム３０における定期送信スロット数を作業者に入力させるための定期送信スロット数入力画面を表示部１７に表示させ（Ｓ３１０）、入力部１９を通じて外部から定期送信スロット数の情報を取得する（Ｓ３２０）。
【００７３】
また、この処理を終えると、制御部１１は、表示部１７に、検査対象フレームＩＤ及び送信周期を作業者に入力させるための入力画面を表示させる（Ｓ３３０）。第一診断処理では、定期送信スロットにて一定周期でフレームが送信されているか否かを検査するが、診断装置１０は、一定周期でフレームが送信されているか否かを検査する対象の定期送信スロットを、定期送信セグメントを構成する定期送信スロット群の内の一部に限定可能な構成にされている。ここでは、上記入力画面にて、検査する対象の定期送信スロットに対応するフレームＩＤの入力を、入力画面を通じて作業者に求める。
【００７４】
また、診断装置１０は、通信バス３１を流れる通信信号から、上記検査の基準となるフレームの送信周期を検出することが可能な構成にされているが、作業者から入力部１９を通じて入力された送信周期の情報を用いて、検査を行うことも可能な構成にされている。ここでは、上記入力画面にて、検査する対象の定期送信スロットにて送信されるフレームの送信周期の入力を、入力画面を通じて作業者に求める。
【００７５】
但し、入力は、任意であるため、Ｓ３３０では、検査対象フレームＩＤの入力欄毎に、送信周期の入力欄を備えるＧＵＩ構成の入力画面であって、入力完了の旨の指令を入力するための入力完了ボタン（入力オブジェクト）を更に備える入力画面を表示し、検査対象フレームＩＤ及び送信周期が入力されていなくとも、入力完了ボタンが押下操作された時点で、次ステップに移行する。
【００７６】
即ち、制御部１１は、上記入力完了ボタンが押下操作されると、Ｓ３４０に移行して、入力画面を通じフレームＩＤが入力されたか否かを判断し、フレームＩＤが入力されたと判断すると（Ｓ３４０でＹｅｓ）、入力画面を通じて入力されたフレームＩＤを検査対象フレームＩＤに設定する（Ｓ３５０）。
【００７７】
また、この処理を終えると、制御部１１は、入力画面を通じて送信周期が入力されたか否かを判断し（Ｓ３６０）、送信周期が入力されたと判断すると（Ｓ３６０でＹｅｓ）、入力画面を通じて入力された送信周期を、当該送信周期の入力欄と対応付けられた検査対象フレームＩＤの入力欄に入力されたフレームＩＤの送信周期Ｔｓとして、設定する（Ｓ３７０）。その後、Ｓ３８０に移行する。
【００７８】
一方、フレームＩＤが入力されなかったと判断すると（Ｓ３４０でＮｏ）、制御部１１は、Ｓ３５０〜Ｓ３７０の処理を実行せずに、Ｓ３８０に移行する。この他、入力画面を通じて送信周期が入力されなかった場合、制御部１１は、Ｓ３６０でＮｏと判断し、Ｓ３７０の処理を実行せずに、Ｓ３８０に移行する。
【００７９】
また、Ｓ３８０に移行すると、制御部１１は、速度計測部２３を起動して、速度計測部２３から通信システム３０のビット長Ｇｂを取得し、取得したビット長Ｇｂを、通信部２１に設定して、デコード処理部２１１を起動させる（Ｓ３９０）。このようにして、デコード処理部２１１を起動させると、通信部２１から制御部１１へは、通信部２１にてフレームが受信される度、フレームの受信時刻Ｔｆの情報及びヘッダ情報を含むフレーム受信情報が入力される。
【００８０】
制御部１１は、Ｓ３９０での処理を終えると、上記フレーム受信情報が入力されるか、入力部１９を通じて外部から診断終了指令が入力されるまで待機する（Ｓ４００〜Ｓ４０５）。そして、通信部２１からフレーム受信情報が入力されると（Ｓ４００でＹｅｓ）、このフレーム受信情報に基づき、フレームの受信時刻Ｔｆの情報及びフレームＩＤの情報を関連付けてなる受信履歴情報を、記憶部１３が記憶するログファイルに記録する（Ｓ４１０）。
【００８１】
この後、制御部１１は、フレーム受信情報が入力される契機となった受信フレームが定期送信フレームであるか否かを、フレーム受信情報として入力されたフレームＩＤの情報に基づき判断する（Ｓ４２０）。
【００８２】
尚、本実施例が診断対象とする通信システム３０では、通信サイクルの先頭から各タイムスロットに対して順に、初期値（例えば値「１」）から始まるスロット番号が連番で割り当てられている（図２参照）。従って、この規則を前提として、Ｓ４２０では、（フレームＩＤ−初期値）が、Ｓ３２０で取得した定期送信スロット数よりも小さい値を採る場合、対応する受信フレームが定期送信スロットであると判断し、そうでない場合、対応する受信フレームが定期送信スロットではないと判断する。
【００８３】
そして、受信フレームが定期送信フレームであると判断すると（Ｓ４２０でＹｅｓ）、制御部１１は、Ｓ４３０に移行し、図７に示す送信異常判定処理を実行する。その後、Ｓ４００に移行する。
【００８４】
一方、受信フレームが定期送信フレームではないと判断すると（Ｓ４２０でＮｏ）、制御部１１は、Ｓ４３０の処理を実行することなく、Ｓ４００に移行する。そして、新たなフレーム受信情報が通信部２１から入力されるか、入力部１９を通じて診断終了指令が入力されるまで待機し（Ｓ４００〜Ｓ４０５）、入力部１９を通じて診断終了指令が入力されると、第一診断処理を終了する。
【００８５】
続いて、制御部１１がＳ４３０にて実行する送信異常判定処理について説明する。図７は、制御部１１が実行する送信異常判定処理を表すフローチャートである。
送信異常判定処理を開始すると、制御部１１は、当該送信異常判定処理を実行する契機となった受信フレームとフレームＩＤが同一のフレームを、過去に受信し、このフレームＩＤについての次フレーム受信時刻を既に予測しているか否かを判断する。そして、次フレーム受信時刻を予測していると判断すると（Ｓ５１０でＹｅｓ）、Ｓ５５０に移行し、次フレーム受信時刻を予測していないと判断すると（Ｓ５１０でＮｏ）、Ｓ５２０に移行する。
【００８６】
Ｓ５２０に移行すると、制御部１１は、受信フレームに対応するフレームＩＤに関して、送信周期の入力が入力画面を通じて行われたか否かを判断し、送信周期の入力が行われたと判断すると（Ｓ５２０でＹｅｓ）、Ｓ６００に移行し、送信周期の入力が行われていないと判断すると（Ｓ５２０でＮｏ）、Ｓ５３０に移行する。
【００８７】
また、Ｓ５３０に移行すると、制御部１１は、今回の受信フレームが送信されたタイムスロットと同一のタイムスロットにて所定回フレームを受信しているか否かを判断する。
そして、所定回フレームを受信していないと判断すると（Ｓ５３０でＮｏ）、制御部１１は、Ｓ５４０以降の処理を実行することなく、当該送信異常判定処理を終了する。一方、所定回フレームを受信していると判断すると（Ｓ５３０でＹｅｓ）、制御部１１は、Ｓ５４０に移行し、今回受信したフレームの受信時刻Ｔｆと、ログファイルに記録されている当該フレームと同一タイムスロットにて過去に送信されたフレームの受信時刻と、から、今回受信したフレームのタイムスロットと同一のタイムスロットで送信されるフレームの送信周期Ｔｓを算出する。
【００８８】
Ｓ５４０では、例えば、今回受信したフレームの受信時刻Ｔｆと、前回同一タイムスロットにて送信されたフレームの受信時刻との差（即ち、フレーム受信間隔）を、フレームの送信周期Ｔｓとして算出する。この他、同一タイムスロットでのフレーム受信間隔を、今回の受信時刻と、ログファイルに記録されたｎ回前までのフレーム受信時刻の情報と、に基づき、ｎ個算出し、この平均を、フレームの送信周期Ｔｓとして算出してもよい。また、算出したｎ個のフレーム受信間隔の内、値が大きいものからｎ１個、値が小さいものからｎ２個を取り除き、残りの（ｎ−ｎ１−ｎ２）個のフレーム受信間隔の平均を、フレームの送信周期Ｔｓとして算出してもよい。
【００８９】
また、Ｓ５４０での処理を終えると、制御部１１は、Ｓ６００に移行し、今回受信したフレームと同一のタイムスロットにて送信されるフレームについての次回受信時刻（即ち、次フレーム受信時刻）Ｔｍを、上記算出した送信周期Ｔｓに基づいて、予測する。具体的には、今回受信したフレームの受信時刻Ｔｆに送信周期Ｔｓを加算して、次フレーム受信時刻Ｔｍを算出する（Ｓ６００）。その後、当該送信異常判定処理を終了する。
【００９０】
一方、Ｓ５２０でＹｅｓと判断して、Ｓ６００に移行すると、制御部１１は、今回の受信フレームに対応するフレームＩＤに設定した送信周期Ｔｓ（Ｓ３７０）に基づいて、今回受信したフレームと同一のタイムスロットにて送信されるフレームについての次回受信時刻（即ち、次フレーム受信時刻）Ｔｍを、上述した手法で算出（予測）する。その後、当該送信異常判定処理を終了する。
【００９１】
一方、Ｓ５１０でＹｅｓと判断して、Ｓ５５０に移行すると、制御部１１は、今回の受信フレームの受信時刻Ｔｆと、今回の受信フレームと同一タイムスロットにて前回送信されたフレームの受信時に予測した次フレーム受信時刻Ｔｍとの誤差εを算出する。
【００９２】
ε＝｜Ｔｆ−Ｔｍ｜
また、この処理を終えると、制御部１１は、Ｓ５６０に移行し、誤差εが、予め設定された閾値より大きいか否かを判断する。そして、誤差ε＞閾値であると判断すると（Ｓ５６０でＹｅｓ）、送信異常が発生しているとして、Ｓ５７０に移行する。一方、誤差ε≦閾値であると判断すると（Ｓ５６０でＮｏ）、送信異常が発生していないとして、Ｓ５７０〜Ｓ５９０の処理を実行することなく、Ｓ６００に移行し、上述した手法で、次フレーム受信時刻Ｔｍを予測する。尚、本実施例では、フレームの送信抜けを検知するため、通信システム３０が採り得る通信サイクルの最小時間よりも、小さい値に、上記閾値を予め定める。
【００９３】
この他、Ｓ５７０に移行すると、制御部１１は、検査対象フレームＩＤの設定が、Ｓ３５０にてなされているか否かを判断し、なされていると判断すると（Ｓ５７０でＹｅｓ）、受信フレームのフレームＩＤが検査対象フレームＩＤであるか否かを判断する（Ｓ５８０）。
【００９４】
そして、受信フレームのフレームＩＤが検査対象フレームＩＤではないと判断すると（Ｓ５８０でＮｏ）、Ｓ５９０の処理を実行せずに、Ｓ６００に移行し、受信フレームのフレームＩＤが検査対象フレームＩＤであると判断すると（Ｓ５８０でＹｅｓ）、Ｓ５９０に移行して、当該フレームＩＤに対応するタイムスロットにて送信異常が発生している旨の文字情報を記した異常報知画面を、表示部１７に表示させ、送信異常が発生している旨を作業者に報知する（Ｓ５９０）。
【００９５】
その後、制御部１１は、Ｓ６００に移行し、受信フレームと同一タイムスロットにて送信されるフレームの次回受信時刻（次フレーム受信時刻）Ｔｍを、予測する。その後、当該送信異常判定処理を終了する。
【００９６】
一方、Ｓ５７０にて、検査対象フレームＩＤの設定がなされていないと判断すると（Ｓ５７０でＮｏ）、制御部１１は、Ｓ５８０の処理を実行せずに、Ｓ５９０に移行する。即ち、受信フレームのフレームＩＤに拘らず、当該フレームＩＤに対応するタイムスロットにて送信異常が発生している旨の文字情報を記した上記異常報知画面を、表示部１７に表示させる。その後、Ｓ６００に移行する。
【００９７】
第一診断処理では、このようにして、送信異常判定処理を、フレームを受信する度に実行することで、一定周期でフレームが送信されていないタイムスロットを検出し、当該タイムスロットが検出された場合には、通信システム３０の異常を、表示部１７を通じて作業者に報知する。
【００９８】
例えば、フレームＩＤ＝１に対応する定期送信スロットが割り当てられたノードが、通信サイクルの２倍の周期でフレームを送信する構成にされている場合には、正常時、フレームＩＤ＝１のフレームが、通信サイクルの２倍の周期で、診断装置１０により受信されることになる。
【００９９】
しかしながら、ノードが、フレームを送信すべきタイムスロットの到来時に、データの生成遅れ等でフレームを送信することができなかった場合には、予め予測した次フレーム受信時刻になっても、診断装置１０で、該当するフレームを受信することができない。そして、次フレームの受信時には、当初の次フレーム受信時刻を、大幅に経過しているため、誤差ε＞閾値となる。
【０１００】
診断装置１０では、このような誤差εが検出された場合に、上記手法で異常報知画面を表示することにより、フレームの送信抜け等が発生していることを、作業者に対し、報知する。
【０１０１】
続いて、制御部１１が実行する第二診断処理について、図８及び図９を用いて説明する。図８及び図９は、入力部１９を通じ、外部（作業者）から第二診断処理の実行指令が入力されると、制御部１１が実行する第二診断処理を表すフローチャートである。
【０１０２】
第二診断処理を開始すると、制御部１１は、まず、診断対象の通信システム３０における通信サイクルの時間長さ（以下、「サイクル時間」という。）を、作業者に入力させるためのサイクル時間入力画面を、表示部１７に表示させ（Ｓ６１０）、入力部１９を通じて外部（作業者）からサイクル時間の情報を取得する（Ｓ６２０）。
【０１０３】
また、この処理を終えると、制御部１１は、通信システム３０の定期送信スロット数及びイベント送信スロット数を、作業者に入力させるためのスロット数入力画面を、表示部１７に表示させ（Ｓ６３０）、入力部１９を通じて外部から定期送信スロット数及びイベント送信スロット数の情報を取得する（Ｓ６４０）。
【０１０４】
また、この処理を終えると、制御部１１は、速度計測部２３を起動して、速度計測部２３から通信システム３０のビット長Ｇｂを取得し（Ｓ６５０）、取得したビット長Ｇｂを、通信部２１に設定して、デコード処理部２１１を起動させる（Ｓ６６０）。
【０１０５】
このようにデコード処理部２１１を起動させると、通信部２１からは、フレーム受信の度、上述のフレーム受信情報が制御部１１に入力される。従って、Ｓ６６０の処理後、制御部１１は、通信部２１からフレーム受信情報が入力されるか、外部から診断終了指令が入力されるまで待機する（Ｓ６７０〜Ｓ６７５）。
【０１０６】
そして、通信部２１からフレーム受信情報が入力されると（Ｓ６７０でＹｅｓ）、このフレーム受信情報に基づき、フレームの受信時刻Ｔｆの情報、及び、当該フレームのヘッダ情報（フレームＩＤ、及び、ペイロード長、及び、サイクル・カウンタの情報）を関連付けてなる受信履歴情報を、ログファイルに記録する（Ｓ６８０）。
【０１０７】
また、この処理を終えると、制御部１１は、Ｓ６９０に移行し、初回にフレーム受信情報が入力された後、サイクル時間のα倍の時間が経過したか否かを判断する。そして、α倍の時間が経過していないと判断すると（Ｓ６９０でＮｏ）、Ｓ６７０に移行し、診断終了指令が入力されない限りは、サイクル時間のα倍の時間が経過するまで、通信部２１が受信したフレームについての受信履歴情報をログファイルに記録する動作を繰返し実行する（Ｓ６７０〜Ｓ６９０）。そして、サイクル時間のα倍の時間が経過すると（Ｓ６９０でＹｅｓ）、Ｓ７００に移行する。一方、入力部１９を通じて診断終了指令が入力された場合には、Ｓ６７５でＹｅｓと判断して、当該第二診断処理を終了する。
【０１０８】
また、Ｓ７００に移行すると、制御部１１は、記憶部１３が記憶するログファイルの内容に基づき、図１０に示す構成のフレーム送信テーブルを生成し、これを記憶部１３に記憶すると共に、表示部１７に表示させる。尚、図１０は、フレーム送信テーブルの構成を表す説明図である。
【０１０９】
図１０に示すように、フレーム送信テーブルは、サイクル・カウンタの各値毎、及び、フレームＩＤ毎に、この値がヘッダ・セグメントに記されたフレーム、が送信されてきたか否かを、記したものである。具体的に、フレーム送信テーブルは、定期送信フレーム数及びイベント送信フレーム数の合計値に対応する数の「列」、サイクル・カウンタが採り得る値の総数αに対応する数の「行」を有する碁盤形状の画像として、表示部１７に表示され、受信したフレームに対応するマス目を塗りつぶし表現して、当該フレームが送信されてきたことを表示する。
【０１１０】
その他、Ｓ７００での処理を終えると、制御部１１は、Ｓ７１０に移行して、記憶部１３が記憶するログファイルの内容に基づき、診断対象の通信システム３０における定期送信スロットのスロット長を算出する。具体的には、隣接する定期送信スロットのフレーム受信時刻の差を、スロット長として算出する。
【０１１１】
例えば、Ｓ７１０では、ログファイルに記録された受信履歴情報を、一つ処理対象に選択する。そして、処理対象の受信履歴情報が示すフレームＩＤが定期送信スロットのフレームＩＤであるか否かを判断し、定期送信スロットのフレームＩＤであると判断すると、当該フレームＩＤの次のフレームＩＤを示す受信履歴情報であって、処理対象の受信履歴情報と同一のサイクル・カウンタ値を示す受信履歴情報を、比較対象の受信履歴情報として、ログファイル内で検索する。そして、比較対象の受信履歴情報がログファイル内で発見されると、処理対象の受信履歴情報が示すフレーム受信時刻と、比較対象の受信履歴情報が示すフレーム受信時刻との差の絶対値Δを算出する。但し、比較対象の受信履歴情報が示すフレームＩＤがイベント送信スロットのフレームＩＤである場合には、上記値Δを算出しないようにする。
【０１１２】
そして、このような動作を、ログファイル内に記録された受信履歴情報毎に、実行することにより、複数の値Δを算出し、これらの値Δに基づいて、通信システム３０での定期送信スロットのスロット長を算出する。例えば、これらの各値Δの平均値を、スロット長として算出する。また、別例としては、算出した値Δの内、大きい値を示すΔの何割か、小さい値を示すΔの何割かを除外して、残りの値Δの平均値を、スロット長として算出する。
【０１１３】
また、この処理を終えると、制御部１１は、Ｓ７２０に移行し、ログファイル内に記録された定期送信スロットの受信履歴情報に基づき、定期送信スロットのペイロード長を特定する。例えば、各受信履歴情報が示すペイロード長の内、ログファイル内に絶対多数記録されているペイロード長を、通信システム３０における定期送信スロットのペイロード長として特定する。
【０１１４】
そして、これらの処理を終えると、制御部１１は、Ｓ７３０に移行し、Ｓ７１０で算出したスロット長、及び、Ｓ７２０で特定したペイロード長を、通信部２１に設定する。Ｓ７３０では、他に、Ｓ６２０で取得したサイクル時間、Ｓ６４０で取得した定期送信スロット数及びイベント送信スロット数を通信部２１に設定して、通信部２１に通信スケジュールを設定する。
【０１１５】
このようにして、通信部２１にスロット長及びペイロード長を設定すると、通信部２１では、エラー判定部２１７が動作可能となり、エラー判定部２１７が起動する。また、エラー判定部２１７が起動すると、通信部２１からは、フレーム受信時刻Ｔｆの情報、及び、ヘッダ情報、及び、エラー判定部２１７での判定結果を表すエラー判定情報を含むフレーム受信情報が、制御部１１に入力される。
【０１１６】
制御部１１は、Ｓ７３０での処理を終えると、上記フレーム受信情報が通信部２１から入力されるか、入力部１９を通じて外部から診断終了指令が入力されるまで待機する（Ｓ７４０〜Ｓ７４５）。そして、通信部２１からフレーム受信情報が入力されると（Ｓ７４０でＹｅｓ）、フレーム受信情報が入力される契機となった受信フレームが定期送信フレームであるか否かを、フレーム受信情報として入力されたフレームＩＤの情報に基づき判断する（Ｓ７５０）。
【０１１７】
そして、受信フレームが定期送信フレームではないと判断すると（Ｓ７５０でＮｏ）、Ｓ７６０，Ｓ７７０の処理を実行することなく、Ｓ７４０に移行し、次のフレーム受信情報が入力されるか、診断終了指令が入力されるまで待機する。
【０１１８】
一方、受信フレームが定期送信フレームであると判断すると（Ｓ７５０でＹｅｓ）、制御部１１は、Ｓ７６０に移行し、フレーム受信情報に含まれるエラー判定情報が、「フレームはみだしエラー有」の旨のエラー判定情報であるか否かを判断する。
【０１１９】
そして、「フレームはみだしエラー有」の旨のエラー判定情報であると判断すると（Ｓ７６０でＹｅｓ）、制御部１１は、フレームはみだしエラーが発生している旨の文字情報を受信フレームのフレームＩＤと共に記した異常報知画面を表示部１７に表示させ、フレームはみだしエラーが発生している旨を作業者に報知する（Ｓ７７０）。その後、Ｓ７４０に移行する。
【０１２０】
これに対し、フレーム受信情報に含まれるエラー判定情報が「正常」の旨のエラー判定情報である場合、制御部１１は、Ｓ７６０でＮｏと判断し、Ｓ７７０の処理を実行することなく、Ｓ７４０に移行する。
【０１２１】
そして、新たにフレーム受信情報が入力された場合には、Ｓ７５０以降の処理を実行し、入力部１９を通じて、診断終了指令が入力された場合には、Ｓ７４５でＹｅｓと判断して、第二診断処理を終了する。
【０１２２】
このようにして、第二診断処理では、各ノードから送信されるフレームが正しくタイムスロット内に納まっているか否かを検査し、フレームが正しくタイムスロット内に納まっていない場合には、異常報知画面を通じて、送信異常を作業者に報知する。
【０１２３】
以上、本実施例の診断装置１０について説明したが、この診断装置１０を通信バス３１に接続し、診断装置１０に第一診断処理を実行させれば、作業者は、通信システム３０の通信速度（ビット長）や各ノードのフレーム送信周期Ｔｓの情報を、診断装置１０に入力しなくても、各ノードから一定周期でフレームが適切に送信されているか否かを検査することができる。
【０１２４】
即ち、本実施例の診断装置１０を用いれば、作業者は、診断装置１０に、種々の通信パラメータを設定しなくても、簡単な作業で、各ノード３３から適切な周期で、送信漏れなく、フレームが送信されているか否かを検査することができ、各ノード３３にて、アプリケーションプログラムが遅延なく正常にデータを生成しているか否か等、システムが正常動作しているか否かを診断することができる。要するに、本実施例によれば、簡便に、各ノード３３から適切にデータの送信動作がなされているか否かを検査して、システムを診断することができる。
【０１２５】
特に、本実施例では、フレームを受信する度に、次フレーム受信時刻を予測して、前回予測した次フレーム受信時刻と、今回受信したフレームの受信時刻との誤差εから、送信異常をリアルタイムに検知するので、通信の異常を、迅速にユーザに向けて報知することができる。即ち、作業者は、異常が報知された時点で、直ちに、異常の発生原因を究明することができ、迅速に、システムを修正することができる。
【０１２６】
また、本実施例では、通信バス３１を流れる通信信号から、エラー判定部２１７の動作に必要なスロット長及びペイロード長を特定し、これを通信部２１に設定することで、エラー判定部２１７を通信システム３０に同期動作させ、作業者から、スロット長及びペイロード長の入力を求めることなく、タイムスロット内にフレームが納まっているか否か（即ち、ノード３３がタイムスロット内で、正常にフレームを送信しているか否か）を検査できるようにした。従って、この診断装置１０によれば、簡便に、システムの詳細な診断を行うことができる。
【０１２７】
尚、本発明のビット長計測手段は、上記実施例において、速度計測部２３に対応する。また、信号処理手段は、制御部１１が実行するＳ３９０，Ｓ６６０の処理、及び、デコード処理部２１１及び受信時刻検出部２１３及びヘッダ解読部２１５の処理にて実現されている。また、受信履歴記憶手段は、記憶部１３及び制御部１１が実行するＳ４１０，Ｓ６８０の処理にて実現され、送信周期推定手段は、Ｓ５４０の処理にて実現されている。
【０１２８】
この他、送信周期異常判定手段は、Ｓ５５０，Ｓ５６０，Ｓ６００の処理にて実現され、予測手段は、Ｓ６００の処理にて実現され、誤差算出手段は、Ｓ５５０の処理にて実現されている。また、報知手段は、Ｓ５９０，Ｓ７７０の処理にて実現されている。また、フレーム異常判定手段は、エラー判定部２１７に対応し、パラメータ設定手段は、制御部１１が実行するＳ７１０〜Ｓ７３０の処理にて実現されている。
【０１２９】
また、本発明は、上記実施例に限定されるものではなく、種々の態様を採ることができる。例えば、上記実施例では、通信システム３０のビット長を、通信バス３１を流れる通信信号から求めるようにしたが、制御部１１は、Ｓ３８０やＳ６５０にて、ビット長入力画面を表示部１７に表示させ、入力部１９を通じて外部（作業者）からビット長の情報を取得する構成にされてもよい。
【図面の簡単な説明】
【０１３０】
【図１】診断装置１０の構成を表すブロック図である。
【図２】通信システム３０における通信の態様を示す説明図である。
【図３】通信部２１の詳細構成を表すブロック図である。
【図４】エラー判定部２１７によるエラー判定の手法を示す説明図である。
【図５】ビット長の計測手法を示す説明図（ａ）及び速度計測部２３が実行するビット長計測処理を表すフローチャート（ｂ）である。
【図６】制御部１１が実行する第一診断処理を表すフローチャートである。
【図７】制御部１１が実行する送信異常判定処理を表すフローチャートである。
【図８】制御部１１が実行する第二診断処理を表すフローチャートである。
【図９】制御部１１が実行する第二診断処理を表すフローチャートである。
【図１０】フレーム送信テーブルの構成を表す説明図である。
【符号の説明】
【０１３１】
１０…診断装置、１１…制御部、１３…記憶部、１５…インタフェース部、１７…表示部、１９…入力部、２１…通信部、２３…速度計測部、３０…通信システム、３１…通信バス、３３…ノード、２１１…デコード処理部、２１３…受信時刻検出部、２１５…ヘッダ解読部、２１７…エラー判定部、ＣＮＴ…コネクタ
【図１】
0004396740.tif 000002
【図２】
0004396740.tif 000003
【図３】
0004396740.tif 000004
【図４】
0004396740.tif 000005
【図５】
0004396740.tif 000006
【図６】
0004396740.tif 000007
【図７】
0004396740.tif 000008
【図８】
0004396740.tif 000009
【図９】
0004396740.tif 000010
【図１０】
0004396740.tif 000011