(57)【特許請求の範囲】
【請求項１】
通信バスに接続されたノードであって、
前記ノードは、
前記ノードを識別するためのＩＤを取得するＩＤ取得部と、
前記通信バスを介してデータの通信を行う通信部と、
前記データの通信状態を監視する監視部と、
監視した前記データの通信状態に基づいて、取得したＩＤが適正なものか否かを判定するＩＤ判定部と、
を備え、
前記ＩＤ判定部が、前記取得したＩＤが適正なものでないと判定したとき、前記ＩＤ取得部は、前記ＩＤを再取得し、
前記監視部は、前記データの送信が適正に行われているか否かを監視し、
前記ＩＤ判定部は、前記データの送信が適正に行われていない状態が、予め定められた時間を超えて継続したとき、前記取得したＩＤが適正なものでないと判定することを特徴とするノード。
【請求項２】
通信バスに接続されたノードであって、
前記ノードは、
前記ノードを識別するためのＩＤを取得するＩＤ取得部と、
前記通信バスを介してデータの通信を行う通信部と、
前記データの通信状態を監視する監視部と、
監視した前記データの通信状態に基づいて、取得したＩＤが適正なものか否かを判定するＩＤ判定部と、
を備え、
前記ＩＤ判定部が、前記取得したＩＤが適正なものでないと判定したとき、前記ＩＤ取得部は、前記ＩＤを再取得し、
記監視部は、前記データの送信が適正に行われているか否かを監視し、
前記ＩＤ判定部は、判定用カウンタを含み、
前記データの送信が適正に行われなかったときに前記判定用カウンタを加算し、
前記データの送信が適正に行われたときに前記判定用カウンタを減算し、
前記判定用カウンタの値が、予め定められた閾値を超えたとき、前記取得したＩＤが適正なものでないと判定することを特徴とするノード。
【請求項３】
通信バスに接続されたノードであって、
前記ノードは、
前記ノードを識別するためのＩＤを取得するＩＤ取得部と、
前記通信バスを介してデータの通信を行う通信部と、
前記データの通信状態を監視する監視部と、
監視した前記データの通信状態に基づいて、取得したＩＤが適正なものか否かを判定するＩＤ判定部と、
を備え、
前記ＩＤ判定部が、前記取得したＩＤが適正なものでないと判定したとき、前記ＩＤ取得部は、前記ＩＤを再取得し、
前記監視部は、前記データの受信が適正に行われているか否かを監視し、
前記ＩＤ判定部は、前記データの受信が適正に行われていない状態が予め定められた時間を超えて継続したとき、前記取得したＩＤが適正なものでないと判定することを特徴とするノード。
【請求項４】
前記監視部は、前記データの送信が適正に行われているか否かを監視し、
前記ＩＤ判定部は、前記データの送信が適正に行われていない状態が、予め定められた時間を超えて継続したとき、前記取得したＩＤが適正なものでないと判定する請求項３に記載のノード。
【請求項５】
前記監視部は、前記データの送信が適正に行われているか否かを監視し、
前記ＩＤ判定部は、判定用カウンタを含み、
前記データの送信が適正に行われなかったときに前記判定用カウンタを加算し、
前記データの送信が適正に行われたときに前記判定用カウンタを減算し、
前記判定用カウンタの値が、予め定められた閾値を超えたとき、前記取得したＩＤが適正なものでないと判定する請求項３に記載のノード。
【請求項６】
前記通信部は、送信用のデータを格納するデータ格納部を含み、
前記監視部は、データ送信時の前記通信バスの状態と、前記データ格納部に格納された送信用のデータとを比較することで、前記データの送信が適正に行われているか否かを監視する請求項１、２、４、５のいずれか１項に記載のノード。
【請求項７】
前記監視部は、前記データの受信が適正に行われているか否かを監視し、
前記ＩＤ判定部は、前記データの受信が適正に行われていない状態が予め定められた時間を超えて継続したとき、前記取得したＩＤが適正なものでないと判定する請求項１または請求項２に記載のノード。
【請求項８】
前記監視部は、送信先が前記ノードのみであるデータを受信したか否かに基づいて、データの受信が適正に行われているか否かを監視する請求項３または請求項７に記載のノード。
【請求項９】
前記通信バスにはマスタノードが接続され、
前記ノードは、スレーブノードとして動作し、
前記通信部は、ＬＩＮプロトコルにしたがって、前記マスタノードと通信を行う請求項１ないし請求項８のいずれか１項に記載のノード。
【請求項１０】
前記ＩＤ取得部は、前記マスタノードから前記ＩＤを取得する請求項９に記載のノード。
【請求項１１】
前記ＩＤを設定するＩＤ設定部を備え、
前記ＩＤ取得部は、前記ＩＤ設定部から前記ＩＤを取得する請求項１ないし請求項１０のいずれか１項に記載のノード。
【請求項１２】
通信バスに接続されたノードであって、
前記ノードは、
前記ノードを識別するためのＩＤを取得するＩＤ取得部と、
前記通信バスを介してデータの通信を行う通信部と、
前記データの通信状態を監視する監視部と、
監視した前記データの通信状態に基づいて、取得したＩＤが適正なものか否かを判定するＩＤ判定部と、
を備え、
前記ＩＤ判定部が、前記取得したＩＤが適正なものでないと判定したとき、前記ＩＤが適正なものでないと判定された前記ノードの前記ＩＤ取得部のみが前記ＩＤを再取得することを特徴とするノード。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、通信バスに接続されたノードに関する。
【背景技術】
【０００２】
車両の各部に搭載され、車内ＬＡＮなどの通信バスを介して接続されるＥＣＵ（「ノード」ともいう）は、通信管理上の必要から、同じ機能を持つＥＣＵであっても、それぞれ固有のＩＤを付与している。
【０００３】
通信バスに接続される１つのマスタと２つ以上のスレーブとで構成される通信ネットワークシステムにおいて、バスに接続するスレーブの数が増加する場合でも、必要な信号線数を増加させることなく、ネットワーク上で異なるＩＤを確実に付与することを可能とする通信ネットワークシステムのＩＤ割付け方法が考案されている（特許文献１参照）。
【０００４】
また、１つのマスタと複数のスレーブとを、高電位側、低電位側の一対の通信バスでデイジーチェーン接続して構成される通信ネットワークに使用されるスレーブにおいて、高電位側バスの下流側に挿入される抵抗素子の上流側端子と、低電位側バスとの電位差のレベルに応じて、マスタと通信を行うためのＩＤを設定する通信用スレーブが考案されている（特許文献２参照）。
【先行技術文献】
【特許文献】
【０００５】
【特許文献１】特開２００５−２２９５６１号公報
【特許文献２】特開２０１１−１５５３５６号公報
【発明の概要】
【発明が解決しようとする課題】
【０００６】
従来技術では、通信ネットワークシステム内で、ノイズ等の一時的な外乱によって一部のノードのＩＤが異常なものになった場合、該ノードの不作動や、他の正常なノードの動作の支障となる虞がある。また、従来技術では、エンジン始動時など特定の動作時にしか復帰動作を行えず、その場合も正常なＩＤのノードもＩＤの割り振りをし直すので、別のノードのＩＤの異常なものになる可能性もある。
【０００７】
特許文献１、２とも、１つのマスタノードと複数のスレーブノードを有する構成である。しかし、ノードのＩＤをソフトウエア、または接続されるハードウエア（ワイヤハーネス等）で判別・設定するといった、マスタノードの存在しない構成には適用できない。
【０００８】
上記問題点を背景として、本発明は、コスト増大を抑制する簡易な方法でＩＤの自動的な再設定を可能とするノードを提供する。
【課題を解決するための手段】
【０００９】
上記課題を解決するためのノードは、通信バスに接続されたノードであって、ノードを識別するためのＩＤを取得するＩＤ取得部と、通信バスを介してデータの通信を行う通信部と、データの通信状態を監視する監視部と、監視したデータの通信状態に基づいて、取得したＩＤが適正なものか否かを判定するＩＤ判定部と、を備え、ＩＤ判定部が、取得したＩＤが適正なものでないと判定したとき、ＩＤ取得部は、ＩＤを再取得する。
【発明の効果】
【００１０】
ＩＤが異常なものになると、当該ノードの動作が正常でなくなるだけではなく、他の正常なノードへ影響を及ぼすこともある。本発明では、ＩＤが異常なものになることで起こることが予想される通信上のエラーを各ノードで検出することで、ノード単位でＩＤの自動復帰を実施できる。これにより、ＩＤが異常となったノードによる、ＩＤが正常であるノードへの影響を低減でき、通信ネットワークシステム（通信バスと、通信バスに接続されたノードを含んで構成されるもの）の信頼性向上が期待できる。また、ＩＤが異常な状態から復帰させるには、従来ではエンジンの停止やバッテリのつなぎ直しが必要であったが、本発明では自動復帰するのでそれらの操作が不要になる。
【図面の簡単な説明】
【００１１】
【図１】ノードの接続構成例を示す図。
【図２】ノードの接続構成の別例を示す図。
【図３】ノードの構成例を示す図。
【図４】ＩＤ取得処理を示すフロー図。
【図５】ＩＤ取得異常時の例を示す図。
【図６】ＩＤ取得異常時の別例を示す図。
【図７】ＩＤ取得処理の別例を示すフロー図。
【発明を実施するための形態】
【００１２】
図１に、本発明のノードが通信バス６０に接続された、例えば車両における通信ネットワークシステム１を示す。通信バス６０にマスタノード１０、ノード２０、３０、４０、５０が接続されている。ノード（２０、３０、４０、５０の総称、以下同じ）は、スレーブノードに相当する。図１では、各ノードは、ＬＩＮプロトコルにしたがって通信を行う。ノード２０、３０、４０、５０には、それぞれ、ノード識別のためのＩＤとして、Ａ、Ｂ、Ｃ、Ｄが割り当てられている。
【００１３】
ＬＩＮプロトコルでは、マスタノード１０が全体の通信を制御するマスタ−スレーブ方式を用いる。マスタノード１０は、送信するＩＤや送信の順番、送信する時間間隔が定義されたＬＩＮスケジュールに基づいて、ＬＩＮネットワーク全体の通信の制御を行う。マスタノード１０は、ＬＩＮスケジュールに基づいて、通信バス６０に送信要求「トークン」を送信する。ノードは、マスタノード１０から送信されるトークンを監視し、「トークン」にしたがって、データを送信するノードがトークンの後にデータを送信する。
【００１４】
上述の構成が、「通信バスにはマスタノードが接続され、ノードは、スレーブノードとして動作し、通信部は、ＬＩＮプロトコルにしたがって、マスタノードと通信を行う」ものである。本構成によって、ＬＩＮプロトコルを用いたマスタ−スレーブ方式の通信ネットワークシステムにおいても、本発明の構成を適用できる。
【００１５】
図２に、通信ネットワークシステム１の構成の別例を示す。図２の例は、ＣＡＮ（Controller  Area  Network）のような、ライン型構造で通信バス６０に接続されるノード（２０、３０、４０、５０）に、平等なバスアクセスが可能な「マルチマスタ方式」を用いている。また、ＩＤの割り当ては、図１と同様である。本構成が、「ノードと通信バスは、マルチマスタ方式の通信ネットワークシステムを構成する」ものである。本構成によって、マルチマスタ方式の通信ネットワークシステムにおいても、本発明の構成を適用できる。
【００１６】
図３に、ノード２０の構成例を示す。ノード２０は、演算部２１（本発明のＩＤ取得部、監視部、ＩＤ判定部）、入力回路２２、ドライバ回路２３、通信Ｉ／Ｆ２４（本発明の通信部、監視部、ＩＤ取得部）、メモリ２５、ＩＤ設定部２６を含む。
【００１７】
演算部２１は、ＣＰＵおよび周辺回路等を含む構成としてもよいし、論理回路等を含む１つあるいは複数のＩＣあるいはＡＳＩＣ等としてハードウエア的に構成されていてもよい。
【００１８】
入力回路２２は、スイッチ群２７およびセンサ群２８からの入力信号の波形整形やＡ／Ｄ変換等の信号処理を行う。ドライバ回路２３は、アクチュエータ群２９を駆動制御する。通信Ｉ／Ｆ２４は、通信バス６０を介して他のノードとのデータ通信を行うための通信インターフェース回路である。メモリ２５は、例えば、不揮発性記憶媒体であるフラッシュメモリを含み、ノード２０の動作に必要なデータを記憶する。
【００１９】
ＩＤ設定部２６は、ハードウエアの状態に基づいてＩＤを取得するためのもので、例えば、ディップスイッチ群、または、電源側あるいは接地側に接続された抵抗素子を含む。ＩＤ設定部２６は、演算部２１のＩＤ設定用端子に接続され、演算部２１がＩＤ設定部２６の状態を検出することでＩＤを取得する。例えば、ＩＤ設定用端子毎にショート（接地側に接続）またはオープン（電源側に接続）の２通りに切り替え設定するので、ＩＤ設定端子数の２乗分のノードを識別できる。
【００２０】
上述の構成が、「ＩＤを設定するＩＤ設定部を備え、ＩＤ取得部は、ＩＤ設定部からＩＤを取得する」ものである。本構成によって、通信ネットワークシステムの構成形態によらず、また、他のノードの動作状態によらず、確実にＩＤを取得することができる。
【００２１】
ノード２０には、ユーザが操作入力を行うスイッチ群２７、例えば、回転センサ、圧力センサ、温度センサ等を含むセンサ群２８、例えば、モータ，ソレノイド等を含むアクチュエータ群２９が接続される。
【００２２】
上記構成により、ノード２０は、通信バス６０を介して受信したマスタノード１０からの制御指令あるいは他のノードから取得したデータ、入力回路３３を介して取得したスイッチ群２７、センサ群２８、およびアクチュエータ群２９の動作状態に基づいて動作制御指令値を演算し、ドライバ回路２３を介してアクチュエータ群２９の駆動制御を行う。
【００２３】
ノード（３０、４０、５０）も、ノード２０と概ね同様の構成であるが、ノードの実現する機能によって、構成（スイッチ群、センサ群、アクチュエータ群の有無あるいは構成内容）は異なる。
【００２４】
図４に、ノード２０（他のノードも同様）のメモリ２５に記憶された制御プログラムに含まれ、演算部２１で実行するＩＤ取得処理を示す。まず、ノード２０をバッテリに接続したとき、車両の原動機（エンジンまたはモータ）を始動許可状態とするイグニッションスイッチがオン状態に変化したとき、あるいは、ノード２０を通信バス６０に接続したときなど（すなわち、ＩＤ取得タイミング）に、以下のいずれかの方法を用いてＩＤを取得する（Ｓ１１）。取得したＩＤは、メモリ２５の所定領域に記憶する。
【００２５】
（ハードウエアの状態に基づいてＩＤを取得）
・上述したように、演算部２１がＩＤ設定部２６の状態を検出することでＩＤを取得する。
【００２６】
（ソフトウエアによりＩＤを取得）
・メモリ２５に予めＩＤを記憶し、ＩＤ取得タイミングで読み出して取得する。この場合、メモリ２５が、本発明のＩＤ設定部に相当する。
・図１の構成のとき、マスタノード１０に各ノードのＩＤが記憶される。ノード２０は、ＩＤ取得タイミングでマスタノード１０に、ノード情報（例えば、メーカ情報や機能情報）を送信し、マスタノード１０から自ノードのＩＤを受信して取得する。本構成が、「ＩＤ取得部は、マスタノードからＩＤを取得する」ものである。本構成によって、ノード（スレーブノード）は、自らのＩＤを保持する必要がなく、ＩＤ設定部が不要となる。また、通信ネットワークシステム上のノードに対するＩＤ設定の自由度が高くなり、マスタノードが適宜スレーブノードのＩＤを設定（変更を含む）できる。
【００２７】
次に、データ送信状態監視用のタイマＡ、および、データ受信状態監視用のタイマＢをリセット（ゼロクリア）して、計測を開始する（Ｓ１２）。
【００２８】
次に、データ送信状態を監視し、データ送信が正しく行われているか否かを判定する。送信データは通信Ｉ／Ｆ２４に含まれるバッファ２４ａ（本発明のデータ格納部）に格納され、通信バス６０に送信される。通信Ｉ／Ｆ２４あるいは演算部２１は、バッファ２４ａに格納された送信データと、通信バス６０をサンプリングしたデータ（すなわち、実際に送信されたデータ）との相違をチェックし、相違があればデータ送信が正しく行われなかったと判定する。
【００２９】
上述の構成が、「通信部は、送信用のデータを格納するデータ格納部を含み、監視は、データ送信時の通信バスの状態と、データ格納部に格納された送信用のデータとを比較することで、データの送信が適正に行われているか否かを監視する」ものである。本構成によって、いわゆる、通信部がビットモニタリング機能を有するときは、ビットモニタリング機能を用いて、取得したＩＤが適正なものか否かを判定できる。
【００３０】
データ送信が正しく行われたとき（Ｓ１３：ｙｅｓ）、タイマＡをリセットし（Ｓ１４）、ステップＳ１５に進む。タイマＡは、ゼロから計測を再開する。一方、データ送信が正しく行われなかったとき（Ｓ１３：ｎｏ）、何もせずステップＳ１５に進む。
【００３１】
ステップＳ１５では、マスタノード１０あるいは他のノード（３０、４０、５０）からのデータを正しく受信しているか否かを判定する。ＣＲＣチェック、フォームチェック、スタッフチェック等を行って、正常データのみを判定の対象とする。また、ブロードキャストフレームのような、複数のノードを送信先とするデータは判定の対象とせず、自ノードのみを送信先とするデータのみを判定の対象とする。
【００３２】
上述の構成が、「監視部は、送信先がノードのみであるデータを受信したか否かに基づいて、データの受信が適正に行われているか否かを監視する」ものである。複数あるいは不特定のノードを送信先とするデータは、特定のノードを送信先とするデータとでは、データの構成が異なる場合があり、ＩＤが異常となっているノードでも受信できることがある。本構成によって、送信先を自身のみのデータに限定することで、より確実に、データの受信が適正に行われているか否かを監視できる。
【００３３】
データ受信が正しく行われたとき（Ｓ１５：ｙｅｓ）、タイマＢをリセットし（Ｓ１６）、ステップＳ１７に進む。タイマＢは、ゼロから計測を再開する。一方、データ送信が正しく行われなかったとき（Ｓ１５：ｎｏ）、何もせずステップＳ１７に進む。
【００３４】
ステップＳ１７では、タイマＡがタイムアウト（予め定められた時間を経過）したか否かを判定する。タイマＡがタイムアウトしたとき、すなわち、データの送信が適正に行われない状態が予め定められた時間を超えて継続したとき、（Ｓ１７：ｙｅｓ）、ステップＳ１１へ戻り、ＩＤを再度取得する。
【００３５】
上述の構成が、「監視部は、データの送信が適正に行われているか否かを監視し、ＩＤ判定部は、データの送信が適正に行われていない状態が、予め定められた時間を超えて継続したとき、取得したＩＤが適正なものでないと判定する」ものである。本構成によって、別途、監視用の回路等を追加することなく、データ送信の際に、取得したＩＤが適正なものか否かを判定できる。また、判定するための時間を適切に設定することで、ノイズ等による一時的な送信エラーを、ＩＤが適正なものでないことによるものと誤認することを防止できる。
【００３６】
一方、タイマＡがタイムアウトしていないとき（Ｓ１７：ｎｏ）、タイマＢがタイムアウトしたか否かを判定する。タイマＢがタイムアウトしたとき、すなわち、データの受信が適正に行われていない状態が予め定められた時間を超えて継続したとき（Ｓ１８：ｙｅｓ）、ステップＳ１１へ戻り、ＩＤを再度取得する。一方、タイマＢがタイムアウトしていないとき（Ｓ１８：ｎｏ）、ステップＳ１３へ戻る。
【００３７】
上述の構成が、「監視部は、データの受信が適正に行われているか否かを監視し、ＩＤ判定部は、データの受信が適正に行われていない状態が予め定められた時間を超えて継続したとき、取得したＩＤが適正なものでないと判定する」ものである。本構成によって、監視用の回路等を追加することなく、データ受信の際に、取得したＩＤが適正なものか否かを判定できる。また、判定するための時間を適切に設定することで、ノイズ等による一時的な受信エラーを、ＩＤが適正なものでないことによるものと誤認することを防止できる。
【００３８】
タイマＡおよびタイマＢのタイムアウト判定値は、例えば、数秒のような比較的長い値に設定する。これは、ノイズ等の、ＩＤが適正なものでないこと以外の原因で発生する、突発的で継続性のない通信エラーにより、ＩＤを再取得することを防ぐためである。
【００３９】
図５および図６を用いて、ＩＤ取得異常時のＩＤ取得処理の流れを説明する。図５は、マスタ−スレーブ方式で、本来は「Ｂ」であるノード３０のＩＤが、ノード４０と同じ「Ｃ」となった場合、すなわち、通信バス６０に、同一ＩＤのノードが複数接続された状態である。
【００４０】
マスタノード１０からの指令に基づいて、ノード３０がデータを送信しようとすると、同じＩＤのノード４０（こちらが正しいＩＤ）も、概ね同時にデータを送信するので、データの衝突が起き、データを送信できない。よって、上述のビットモニタリングで、送信データと、通信バス６０上をサンプリングしたデータとが異なるので、データ送信に失敗する。図４のＩＤ取得処理では、ステップＳ１３：ｎｏを通り、タイマＡはリセットされない。
【００４１】
図２のような、マスタ−スレーブ方式でないとき、すなわち、各ノードが自発的にデータを送信する場合も、データの衝突が起こりうる、一度データの衝突が発生すると、データの再送を試みるので、さらにデータの衝突の可能性は高くなり、データ送信に失敗する。よって、タイマＡはリセットされない。
【００４２】
一方、ノード３０でのデータの受信は、送信元がノード４０へ向けてデータを送信するので、これを受信するため正常に行われる。この結果、タイマＢはリセットされるが、タイマＡはタイムアウトし、図４のＩＤ取得処理では、ステップＳ１７：ｙｅｓを通り、ＩＤの再取得が行われる。
【００４３】
このとき、ノード４０でも、データ送信に失敗するので、ノード３０と同様に、ＩＤの再取得を行う。ノード２０およびノード５０の動作には影響を及ぼさないので、これら２つのノードは、ＩＤの再取得は行わない。
【００４４】
上述のように、通信ネットワークシステム１の構成が、マスタ−スレーブ方式（図１）、マルチマスタ方式（図２）のいずれであっても、ノードＩＤの重複が発生したとき、重複したＩＤを取得したノードでＩＤの再取得が行われる。
【００４５】
図６は、マスタ−スレーブ方式で、本来は「Ｂ」であるノード３０のＩＤが「Ｅ」となった場合、すなわち、通信バス６０に、存在し得ないＩＤのノードが接続された状態である。
【００４６】
図６では、データ送信時には、以下の２通りの状況が考えられる。
・マスタノード１０からの指令に基づいて、ノード３０がデータを送信する場合、ＩＤ「Ｅ」に対する指令は送信されないので、データを全く送信しない。データを全く送信しないことを、データ送信失敗と判定すれば、タイマＡはリセットされない。
・マスタノード１０から、ＬＩＮで、複数のノードからの送信を処理可能な、発生頻度の少ないイベントに使用するイベントトリガフレームが送信されたときには、データを送信できる。マスタノード１０では、データが適正なものではないと判断するが、データの送信は正常に行われる。このとき、タイマＡはリセットされる。
・図２のように、マスタ−スレーブ方式でないとき、すなわち、各ノードが自発的にデータを送信する場合、他のノードのＩＤと異なっているので、データの送信は正常に行われる可能性がある。このとき、タイマＡはリセットされる。
【００４７】
よって、データ送信時は、ネットワークの構成によって、タイマＡがリセットされる場合と、リセットされない場合がある。
【００４８】
一方、マスタノード１０および他のノードから、ＩＤ「Ｅ」宛のデータは送信されないので、ノード３０でのデータの受信は全く行われない。よって、図４のＩＤ取得処理では、ステップＳ１５：ｎｏを通り、タイマＢはリセットされない。その結果、タイマＢはタイムアウトし、図４のＩＤ取得処理では、ステップＳ１８：ｙｅｓを通り、ノード３０は、ＩＤの再取得を行う、他のノード（２０、４０、５０）は、ＩＤの再取得を行わない。
【００４９】
図７に、ＩＤ取得処理の別例を示す。本処理は、図４の変形例であるため、図４と同様の処理ステップについては同様の符号を付与し、ここでの詳細な説明は割愛する。図４と異なる点は、タイマＡに代えてカウンタＡを用いることである。
【００５０】
ステップＳ１１でＩＤを取得した後、カウンタＡをリセット（ゼロクリア）する（Ｓ１１Ａ）。次に、タイマＢのみ（タイマＡは使用しない）をリセットして、計測を開始する（Ｓ１２Ａ）。
【００５１】
次に、ノードからのデータ送信が成功したとき（Ｓ１３：ｙｅｓ）、カウンタＡをデクリメント（現在のカウンタ値から、１のような所定値を減算）する（Ｓ１４Ａ）。一方、ノードからのデータ送信に失敗したとき（Ｓ１３：ｎｏ）、カウンタＡをインクリメント（現在のカウンタ値に、８のような所定値を加算）する（Ｓ１４Ｂ）。加算値および減算値は、同じ値でも異なる値でもよいが、エラー判定を確実に行うため、加算値を減算値よりも大きくすることが望ましい。
【００５２】
データの受信が成功したか否かの判定（ステップＳ１５、Ｓ１６）の後、ステップＳ１７Ａでは、カウンタＡの値が予め定められた閾値を超えたか否かを判定する。例えば、正常時では起こりえない失敗回数（十数回〜数十回）となるように閾値を定める。
【００５３】
カウンタＡの値が閾値を超えたとき（Ｓ１７Ａ：ｙｅｓ）、ステップＳ１１へ戻り、ＩＤを再取得する。一方、カウンタＡの値が閾値を超えないとき（Ｓ１７Ａ：ｎｏ）、ステップＳ１８へ進み、タイマＢの判定を行う。
【００５４】
上述の構成が、「監視部は、データの送信が適正に行われているか否かを監視し、ＩＤ判定部は、判定用カウンタを含み、データの送信が適正に行われなかったときに判定用カウンタを加算し、データの送信が適正に行われたときに判定用カウンタを減算し、判定用カウンタの値が、予め定められた閾値を超えたとき、取得したＩＤが適正なものでないと判定する」ものである。本構成によっても、別途、監視用の回路等を追加することなく、データ送信の際に、取得したＩＤが適正なものか否かを判定できる。また、判定するための閾値を適切に設定することで、ノイズ等による一時的な送信エラーを、ＩＤが適正なものでないことによるものと誤認することを防止できる。
【００５５】
以上、本発明の実施の形態を説明したが、これらはあくまで例示にすぎず、本発明はこれらに限定されるものではなく、特許請求の範囲の趣旨を逸脱しない限りにおいて、当業者の知識に基づく種々の変更が可能である。
【符号の説明】
【００５６】
１    通信ネットワークシステム
１０    マスタノード
２０、３０、４０、５０    ノード（スレーブノード）
２１    演算部（ＩＤ取得部、監視部、ＩＤ判定部）
２４    通信Ｉ／Ｆ（通信部、監視部、ＩＤ取得部）
２４ａ  バッファ（データ格納部）
２５    メモリ（ＩＤ設定部）
２６    ＩＤ設定部
６０    通信バス
【図１】
0006365876.tif 000002
【図２】
0006365876.tif 000003
【図３】
0006365876.tif 000004
【図４】
0006365876.tif 000005
【図５】
0006365876.tif 000006
【図６】
0006365876.tif 000007
【図７】
0006365876.tif 000008