JP4715802B2 - 通信システム - Google Patents

Description

本発明は、リングトポロジー構成の通信システムに関する。

従来より、通信システムとしては、ＭＯＳＴ（Ｍｅｄｉａ Ｏｒｉｅｎｔｅｄ Ｓｙｓｔｅｍｓ Ｔｒａｎｓｆｅｒ：登録商標）通信プロトコルが採用された通信システムが知られている。また、この種の通信システムとしては、複数ノードが環状に接続されてなるリングトポロジー構成の通信システムが知られている（例えば、特許文献１参照）。

ＭＯＳＴ（登録商標）通信技術は、オーディオ装置やナビゲーション装置、移動電話端末等の連携動作が必要な装置間で、大容量データを高速伝送するために有用な技術として、広く知られており、カーオーディオ装置やカーナビゲーション装置等の車載装置からなる車内ＬＡＮシステムに応用されている。

ここで、ＭＯＳＴ（登録商標）通信プロトコルが採用された通信システムの構成について簡単に説明すると、この通信システムでは、システムを構成する複数ノードの内の一つが、タイミングマスタ（以下、単に「マスタ」と称する。）として機能し、システムを構成する他の全てのノードは、このマスタのクロック・ソースに同期して動作する。

ＭＯＳＴ（登録商標）フレームは、マスタから、クロック・ソースに同期して送出され、環状に接続されたノード間を、一定方向に周回する。即ち、マスタから送出されたフレームは、隣接するノードにて受信されると、そのノードから更に次のノードへと、順に、上記クロック・ソースに同期して転送され、環状に接続されたノード間を周回する。

このフレームは、ストリーム・チャネル、パケット・チャネル、及び、制御チャネルを有し、ストリーム・チャネルは、オーディオデータやビデオデータなどのリアルタイムデータの伝送に使用される。また、パケット・チャネルは、非同期データの伝送に使用され、制御チャネルは、各ノードが有するアプリケーション・プログラムを制御するためのアプリケーション・メッセージや、システムのオペレーションに必要なネットワーク管理情報等のコントロール・メッセージの伝送に使用される。

各ノードは、ストリーム・チャネルを通じてデータを伝送する場合、予約（アロケーション）された帯域に、データを格納して、他ノードへとデータを伝送する。また、各ノードは、マスタから提供されたアロケーションテーブルに従って、ストリーム・チャネルから必要なデータを取得する。このようにして、ストリーミングデータは、ノード間で送受信される。

一方、パケット・チャネルを通じたデータ伝送は、トークンリング方式で行われる。パケット・チャネルには、宛先を付したデータが送信元ノードにより格納され、これが宛先ノードにより取り込まれる。これにより、非同期データは、ノード間で送受信される。

また、上記通信システムにおいて、各ノードが有するアプリケーション・プログラム間の通信は、ファンクションブロックＩＤを用いて行われる。
ＭＯＳＴ（登録商標）通信プロトコルでは、アプリケーション・プログラムの設計方法についても規定されており、アプリケーション・プログラムは、ファンクションブロックを単位として構成される。ファンクションブロックは、複数のファンクションからなり、ファンクションブロックを構成するファンクションは、メソッドとプロパティの２クラスに大別される。メソッドは、処理の内容が記述されたものであり、スタートすると所定の処理を実行する。一方、プロパティは、ファンクションブロックの性質を表す変数を保持するファンクションである。

システムを構成する各ノードが有するファンクションブロックのリストは、起動時に、マスタにより収集され、収集されたリストはまとめられて、各ノードに配布される。即ち、マスタは、各ノードが有するファンクションブロックのＩＤを、当該ファンクションブロックを有するノードのアドレスに関連付けて記述してなるネットワーク構成データを、マスタ以外の各ノード（以下、単に「スレーブ」と称する。）に送信する。

各スレーブは、このデータの受信により、システムを構成する各ノードのファンクションブロックにアクセス可能に構成される。即ち、アプリケーション・プログラムからは、ファンクションブロックＩＤを宛先として、他のファンクションブロックに対するデータの出力がなされるが、各ノードは、上記ネットワーク構成データに基づき、アプリケーション・プログラムより下層の通信プログラムによって、ファンクションブロックＩＤに対応するノードアドレスを識別し、上記データを、対応するノードに送信する。この動作により、上記の通信システムでは、アプリケーションレベルでノードアドレスを意識することなく、他ノードのファンクションブロックにアクセスすることができる。

この他、ＭＯＳＴ（登録商標）通信プロトコルには、状態通知に関する規定があり、各ノードは、他ノードから状態通知要求（Ｎｏｔｉｆｉｃａｔｉｏｎ．Ｓｅｔ）を受けた場合、以後、要求されたファンクションブロックのプロパティで変数の変化が生じる度に、変化の報告を、要求元ノードに対して行う。この機能により、上記通信プロトコルが採用された通信システムでは、異なるノードのアプリケーション・プログラム間で、効率的で良好な通信を実行することができる。
特開２００５−０６５２１８号公報

ところで、上記通信プロトコルが採用されたリングトポロジー構成の通信システムでは、周知のように、マスタが、データリンク層レベルで、ネットワーク制御用の通信信号（以下、「制御通信信号」と称する。）を、隣接するスレーブに送信して、スレーブが、隣接するノードに対し、受信した制御通信信号を転送することにより、マスタとの同期が確立され、システムを構成するノード間でフレームの送受が可能となり、システムが正常動作する。

具体的に、マスタ及びスレーブは、図３に示す処理を実行して、制御通信信号をネットワークに送出・転送する。図３（ｂ）に示すように、スレーブは、マスタから送信される制御通信信号の受信待機を実行し、制御通信信号を一定時間内に受信することができた場合には（Ｓ１１１０でＹｅｓ）、隣接する次ノードに対して制御通信信号を送信することで（Ｓ１１２０）、マスタから送信された制御通信信号を、隣接するノードに対して転送する。一方、制御通信信号をマスタから一定時間内に受信することができなかった場合には（Ｓ１１３０でＹｅｓ）、エラー処理を実行する（Ｓ１１４０）。このエラー処理により、スレーブは、自己の装置全体をリセットして、自ノードを再起動する。

また、マスタは、制御通信信号をネットワークに送出して（Ｓ１０１０）、受信待機状態に移行し、当該制御通信信号を一定時間内に受信することができた場合には（Ｓ１０２０でＹｅｓ）、制御通信信号が一定時間内にネットワークを正常に周回しているとして、制御通信信号のネットワークへの送出（Ｓ１０１０）を繰り返すが、一定時間内に、制御通信信号を受信することができなかった場合には（Ｓ１０３０でＹｅｓ）、エラー処理を実行する（Ｓ１０４０）。このエラー処理により、マスタは、システムに異常が生じた場合、自己の装置全体をリセットし再起動する。このようにして、上記の通信システムは、伝送経路途中で、制御通信信号の伝送が遮断されると、異常又はノードのネットワークからの離脱が生じたとして、システム全体を再起動し、システムを再構築する。

しかしながら、従来システムでは、システムが上記のように構成されているにも拘わらず、システムを構成するノードのいずれかが、エラーにより通信を継続できなくなると、エラーの生じたノードが、エラーの種類に依らずに、自己の装置全体をリセットして再起動するため、ノードが立ち上がるまでの期間に制御通信信号の伝送が途絶え、ノード単体で解決することのできるエラーが生じた程度でも、このエラーがシステム全体の再起動に発展するといった問題があった。即ち、従来システムでは、システムの規模が大きくなるほど、システム再起動の発生頻度が高くなり、安定的に、通信を行うことができないといった問題があった。

ＭＯＳＴ（登録商標）通信装置では、制御通信信号の送受信処理を含むデータリンク層以下の処理を、ＮＩＣ（Ｎｅｔｗｏｒｋ Ｉｎｔｅｒｆａｃｅ Ｃｏｎｔｒｏｌｌｅｒ）と呼ばれるハードウェアが実行し、ネットワーク層以上の処理を、ＮＩＣに接続されたマイクロコンピュータがプログラムにより実行する。

このため、マイクロコンピュータ上でプログラムエラーが発生した程度であれば、ＮＩＣをリセットせず、マイクロコンピュータのみを再起動することで、データリンク層レベルの制御通信信号の転送動作を継続しつつ、エラーを解消し、ノードを通信可能な状態にすることができる。

しかしながら、上記プログラムエラーが生じた場合に、マイクロコンピュータを再起動させる程度であると、上述した状態通知要求などの設定情報がマイクロコンピュータのリセットと共に喪失してしまうため、マイクロコンピュータのみを再起動する程度では、ノードの状態を、エラー前の状態に復帰させることができないといった問題があった。

即ち、各ノードは、状態通知要求を受けて、受動的に、要求に応じた設定を行う程度であるため、状態通知要求を受けたノードにてマイクロコンピュータの再起動がなされて設定情報が喪失すると、当該ノードの動作では、当該設定を復元することができないといった問題があった。従って、従来システムでは、理論上ではマイクロコンピュータのみを再起動させることで、システム全体の再起動を抑制することができるものの、設定情報を復元する手段がないため、実質的に、この手法を採用することができず、結果として、システム全体の再起動の発生頻度を抑えることができないといった問題があった。

本発明は、こうした問題に鑑みなされたものであり、上述したリングトポロジー構成の通信システムにおいて、アプリケーション・エラー等の軽微なエラーが、システム全体の再起動に発展するのを抑制し、従来よりも安定的に通信ができるようにすることを目的とする。

かかる目的を達成するためになされた本発明の通信システム（請求項１）は、複数ノードが環状に接続され、所定プロトコルに従って、ノードから出力される通信信号が、隣接するノードへと一定方向に順に転送され、ノード間の通信が実現されるリングトポロジー構成の通信システムであって、各ノードが次のように構成されたものである。

具体的に、上記通信システムを構成する各ノードは、通信処理ユニットと、通信制御ユニットとを備え、これらのユニットにより、上記プロトコルに基づく通信を実現する。通信処理ユニットは、上記プロトコルに従って、ネットワーク層及びそれより上位の層に属する処理を実行し、通信制御ユニットは、上記プロトコルに従って、データリンク層及び物理層に属する処理を実行する。

この通信制御ユニットは、隣接するノードと伝送ケーブルを介して接続され、上記データリンク層及び物理層に属する処理を実行して、伝送ケーブルを介して送信されてきた通信信号を受信し、受信した通信信号から抽出した受信データを、通信処理ユニットに入力すると共に、通信処理ユニットから入力された送信データに基づき、転送用の通信信号を生成し、生成した通信信号を次ノードへ送信する。

例えば、各ノードが光ファイバーケーブルにより接続された通信システムの場合、通信制御ユニットは、光ファイバーケーブルを通じて伝送されてくる上記通信信号としての光信号を電気信号に変換して、この電気信号に重畳されたフレーム内のデータを受信データとして通信処理ユニットに入力すると共に、通信処理ユニットから入力された送信データを格納したフレームを、光信号に変換して、これを次ノードへと伝送する。

また、この通信システムにおいては、通信処理ユニットが、判定手段、リセット手段、リセット通知手段、及び、要求処理実行手段を備える。判定手段は、自ノードの再起動が必要なエラーが発生すると、エラーの種類に応じて、通信制御ユニットの再起動が必要であるか否かを判定し、リセット手段は、上記エラーが発生した場合、次のリセット処理を実行して、自ノードを再起動する。

具体的に、リセット手段は、判定手段により通信制御ユニットの再起動が必要であると判定された場合、通信制御ユニット及び通信処理ユニットをリセットする第一のリセット処理を実行して、自ノードを再起動し、判定手段により通信制御ユニットの再起動が不要であると判定された場合には、通信制御ユニットをリセットせずに、当該通信処理ユニットをリセットする第二のリセット処理を実行して、自ノードを再起動する。

一方、リセット通知手段は、リセット手段により上記第二のリセット処理が実行されると、リセットの実行を通知するためのリセット通知データを、当該通信システムを構成する他のノードに対し、通信制御ユニットを介して、送信する。また、通信処理ユニットは、通信制御ユニットを介して、他ノードから所定の処理要求を受信すると、要求処理実行手段にて、要求された処理を、繰返し実行する。

また、複数ノードの内、少なくとも一つのノードは、上記処理要求を送信する要求手段を通信処理ユニットに備える。具体的に、要求手段は、複数ノードの内、特定のノードに対し、上記処理要求を、通信制御ユニットを介して送信する構成にされ、更に、通信制御ユニットを介して、特定のノードからリセット通知データを受信すると、上記特定のノードに対しリセット前に送信した処理要求を、再度、特定のノードに対し送信する構成にされている。

従って、本発明の通信システムによれば、システム内の一のノードにて通信処理ユニットのリセットが行われ、処理要求に係る設定情報が通信処理ユニットから喪失した場合でも、リセット前の処理要求に係る設定情報を通信処理ユニットにて復元することができる。よって、本発明によれば、通信処理ユニットにエラーが生じた程度であれば、ノード全体をリセットして、システム全体をリセットしなくても、通信処理ユニットのエラーを解消しつつ、処理要求の設定状態をリセット前の状態に戻すことができ、システム全体をエラー前の状態に、適切に復元することができる。

従って、この発明によれば、リングトポロジー構成の通信システムにおいて、ノード数が増加して、エラーの発生頻度が高くなった場合でも、エラーを、個別のノードにて解消することができ、エラーの発生がシステム全体のリセットに繋がるのを抑えることができて、安定した通信を実現することができる。

尚、上述の通信処理ユニットは、マイクロコンピュータにて構成することができ、各手段としての機能は、マイクロコンピュータが、例えば、内蔵メモリに記録されたプログラムを実行することにより、マイクロコンピュータ上で実現することができる。また、上記プロトコルとしては、ＭＯＳＴ（登録商標）通信プロトコルを挙げることができる。

この他、判定手段は、具体的に、上記発生したエラーが通信制御ユニットで発生したエラーである場合、通信制御ユニットの再起動が必要であると判定し、上記発生したエラーが通信制御ユニットで発生したエラーではなく、通信処理ユニットで発生したエラーである場合には、通信制御ユニットの再起動が不要であると判定する構成にすることができる（請求項２）。このようにすれば、上述したように、通信処理ユニットで発生したエラーが、システム全体の再起動に発展することがなく、本発明によれば、従来よりも安定な通信を実現することができる。

また、上述の通信システムにおいて、要求処理実行手段は、他ノードから状態通知要求を受信すると、要求された状態が変化する度、状態変化を表すデータを、通信制御ユニットを介して、要求元のノードに対し送信する処理を実行し、要求手段は、上記処理要求として、特定のノードに対し、状態通知要求を送信する構成にすることができる（請求項３）。

ＭＯＳＴ（登録商標）通信プロトコルでは、他ノードから状態通知要求（Ｎｏｔｉｆｉｃａｔｉｏｎ．Ｓｅｔ）を受けたノードが、以後、要求されたプロパティで変数の変化が生じた場合に、変化の報告を、要求元ノードに対して行うといった規定があるが、このようなプロトコルが採用された通信システムに、本発明を適用すれば、通信処理ユニットでエラーが生じた場合に、通信処理ユニット単体をリセットする程度で、エラーを解消しつつ、状態通知要求の設定を復元することができる。

即ち、このように通信システムを構成すれば、アプリケーション・エラー等の軽微なエラーが、システム全体の再起動に発展するのを抑制することができ、システム全体を再起動させなくても、エラーを解消しつつ、処理要求に関する設定を復元して、良好にノード間で通信を行うことができる。

以下、本発明の実施例について、図面と共に説明する。
図１は、本発明が適用された通信システム１の構成を表すブロック図である。本実施例の通信システム１は、複数のノードが環状に接続されてなるリングトポロジー構成のネットワークである。

この通信システム１は、車内ＬＡＮ（ローカルエリアネットワーク）として構成されており、上記ノードとして、複数の電子制御装置（ＥＣＵ）１０が、環状に接続され、各ＥＣＵ１０が、ＭＯＳＴ（登録商標）通信プロトコルに従って動作する構成にされている。即ち、この通信システム１では、各ＥＣＵ１０が、上記通信プロトコルに従って動作し、一定方向に通信信号を転送することにより、任意のＥＣＵ１０間での通信が実現される。

具体的に、本実施例の通信システム１は、車両情報ＥＣＵ１０ａ、電話ＥＣＵ１０ｂ、オーディオＥＣＵ１０ｃ、オーディオアンプＥＣＵ１０ｄ、及び、ナビゲーションＥＣＵ１０ｅを備え、この通信システム１では、車両情報ＥＣＵ１０ａが、タイミングマスタとして機能する。換言すると、この通信システム１では、車両情報ＥＣＵ１０ａのクロック・ソースに同期して、各ＥＣＵ１０ｂ〜１０ｅが動作し、データを搬送するフレームは、車両情報ＥＣＵ１０ａから、クロック・ソースに同期して送出され、ＥＣＵ１０（ＥＣＵ１０ａ〜１０ｅ）間を、一定方向に周回する。

例えば、車両情報ＥＣＵ１０ａから送出されたフレームは、隣接する電話ＥＣＵ１０ｂにて受信され、電話ＥＣＵ１０ｂからオーディオＥＣＵ１０ｃへ、上記クロック・ソースに同期して転送される。また、オーディオＥＣＵ１０ｃにて受信されたフレームは、オーディオアンプＥＣＵ１０ｄへ転送され、更には、ナビゲーションＥＣＵ１０ｅへと転送される。そして、最終的に、上記フレームは、車両情報ＥＣＵ１０ａに到達する。このようにして、通信システム１では、車両情報ＥＣＵ１０ａから送出されたフレームが、隣接するＥＣＵ１０へ、順に上記クロック・ソースに同期して転送される。

また、上記通信プロトコルが規定するフレームは、図２に示すように、同期データ伝送用のストリーム・チャネルと、非同期データ伝送用のパケット・チャネルと、アプリケーション・メッセージやコントロール・メッセージの伝送用の制御チャネルと、を備え、各ＥＣＵ１０で生成された送信対象のデータは、これらのチャネルのいずれかを通じて、他のＥＣＵ１０へと送信される。尚、図２は、本実施例の通信システム１において伝送されるフレームの構成及び通信システム１を構成する各ＥＣＵ１０（ＥＣＵ１０ａ〜１０ｅ）の基本構成を表したブロック図である。

図２に示すように、通信システム１を構成する各ＥＣＵ１０は、ＦＯＴ（Ｆｉｂｅｒ Ｏｐｔｉｃａｌ Ｔｒａｎｓｃｅｉｖｅｒ）１１、ＮＩＣ（Ｎｅｔｗｏｒｋ Ｉｎｔｅｒｆａｃｅ Ｃｏｎｔｒｏｌｌｅｒ）１３、及び、マイクロコンピュータ（以下、単に「マイコン」と称する。）１５を備え、上記通信プロトコルに基づく処理として、ＦＯＴ１１で物理層に対応する処理を実行し、ＮＩＣ１３でデータリンク層に対応する処理を実行し、マイコン１５でネットワーク層より上位層の処理を実行する。

ＦＯＴ１１は、光信号を電気信号に、電気信号を光信号に変換可能な光トランシーバとして機能し、ＥＣＵ１０間を結ぶＰＯＦ（Ｐｌａｓｔｉｃ Ｏｐｔｉｃａｌ Ｆｉｂｅｒ）ケーブルＬＮから入力される光信号の形態の通信信号を、電気信号に変換して、これをＮＩＣ１３に入力すると共に、ＮＩＣ１３から入力される電気信号の形態の通信信号を、光信号に変換して、これをＰＯＦケーブルＬＮに送出する。

具体的に、ＦＯＴ１１は、フレーム周回方向の上流側に位置するＰＯＦケーブルＬＮに接続される受信用の光コネクタ１１ａと、フレーム周回方向の下流側に位置するＰＯＦケーブルＬＮに接続される送信用の光コネクタ１１ｂとを有し、受信用の光コネクタ１１ａから入力された光信号を電気信号に変換して、これをＮＩＣ１３に入力すると共に、ＮＩＣ１３から入力された電気信号の形態の通信信号を、光信号に変換して、これを送信用の光コネクタ１１ｂを通じ、フレーム周回方向の下流側に位置するＰＯＦケーブルＬＮに送出する。

また、ＮＩＣ１３は、ＭＯＳＴ（登録商標）プロトコルＩＣとも呼ばれ、上述したように、データリンク層に対応する処理を実行する。データリンク層では、ＥＣＵ１０間で制御通信信号の送受が行われて、マスタ（車両情報ＥＣＵ１０ａ）との同期確立が行われる。ＮＩＣ１３は、隣接するＥＣＵ１０と制御通信信号の送受を行うことで、上記同期確立処理を実行し、更には、制御通信信号を介して、再送要求や誤り訂正などの処理を実行することによって、ＥＣＵ１０間での正常なフレームの送受信を実現する。

尚、スレーブとして機能する各ＥＣＵ１０ｂ〜１０ｅのＮＩＣ１３は、従来装置と同様、図３（ｂ）に示す通信制御処理を実行して、上流のＥＣＵ１０から送信されてくる制御通信信号を、下流のＥＣＵ１０に転送する。また、マスタとして機能する車両情報ＥＣＵ１０ａのＮＩＣ１３は、図３（ａ）に示す通信制御処理を実行して、制御通信信号を定期的に送出する。本実施例では、このようにして、通信システム１を、任意のＥＣＵ１０間で通信可能な環境に維持する。

具体的に、スレーブとして機能する各ＥＣＵ１０ｂ〜１０ｅのＮＩＣ１３は、前回受信時点から一定時間内に、制御通信信号を、上流のＥＣＵ１０から受信した場合（Ｓ１１１０でＹｅｓ）、下流のＥＣＵ１０に対して制御通信信号を送信することで（Ｓ１１２０）、制御通信信号を、次ノードに転送する。

一方、制御通信信号を一定時間内に受信することができなかった場合（Ｓ１１３０でＹｅｓ）、ＥＣＵ１０ｂ〜１０ｅのＮＩＣ１３は、エラー処理を実行し（Ｓ１１４０）、マイコン１５と協働して、自装置を再起動する。具体的に、マイコン１５は、自装置のＮＩＣ１３からエラー通知を受けると、当該マイコン１５をリセットし、再起動後の処理で、ＮＩＣ１３をリセットする（詳細後述）。ＮＩＣ１３は、Ｓ１１４０で、自装置のマイコン１５に対してエラーを通知することにより、自装置を再起動し、エラーを解消する。

この他、マスタとして機能する車両情報ＥＣＵ１０ａのＮＩＣ１３は、制御通信信号を、下流のＥＣＵ１０（電話ＥＣＵ１０ｂ）に送信し（Ｓ１０１０）、当該制御通信信号を一定時間内に、上流のＥＣＵ１０（ナビゲーションＥＣＵ１０ｅ）から受信することができた場合には（Ｓ１０２０でＹｅｓ）、制御通信信号がネットワークを正常に周回しているとして、Ｓ１０１０に移行し、制御通信信号がネットワークを正常に周回している期間、制御通信信号のネットワークへの送出（Ｓ１０１０）を、一定周期で繰り返す。

一方、一定時間内に、制御通信信号を受信することができなかった場合（Ｓ１０３０でＹｅｓ）、車両情報ＥＣＵ１０ａのＮＩＣ１３は、エラー処理を実行し（Ｓ１０４０）、マイコン１５と協働して、自装置を再起動する。即ち、Ｓ１０４０で、自装置のマイコン１５に対しエラーを通知することにより、自装置を再起動する。このようにして、通信システム１は、自己を、任意のＥＣＵ１０間で通信可能な環境に維持し、ＥＣＵ１０ａ〜１０ｅのいずれかのＮＩＣ１３にエラーが生じた場合には、従来システムと同様、システム全体を再起動して、自システムを正常な通信環境に復帰させる。

この他、各ＥＣＵ１０のＮＩＣ１３は、フレームを、符号化して送信用の通信信号を生成し、これを、ＦＯＴ１１を介して送信すると共に、ＦＯＴ１１を介して受信した上記符号化された通信信号から、フレームを抽出する機能を有する。また、各ＥＣＵ１０のＮＩＣ１３は、受信したフレームに含まれるデータを、マイコン１５に入力すると共に、マイコン１５から入力された送信対象のデータをフレームに格納して、次ノードに送出する機能を有する。本実施例の通信システム１では、ＮＩＣ１３のこれらの機能により、ＥＣＵ１０間でのフレーム送受信が実現される。

この他、各ＥＣＵ１０が有するマイコン１５は、プログラム等が記録されたＲＯＭ１５ａ、プログラム実行時に作業領域として使用されるＲＡＭ１５ｂ、及び、電気的にデータ書換可能な不揮発性メモリとしてのＮＶＲＡＭ１５ｃを有し、ＲＯＭ１５ａに記録されたプログラムを実行することにより、ネットワーク層より上位層の処理を実現する。

図４は、マイコン１５により実行されるプログラムの関係を示したブロック図である。マイコン１５は、ネットサービスプログラムＰ１、及び、ファンクションブロックＰ２の一群からなるアプリケーション・プログラムを有し、これらのプログラムにより、ネットワーク層より上位層の処理を実現する。

具体的に、ネットサービスプログラムＰ１は、同期データ伝送サービス、非同期データ伝送サービス、アプリケーションメッセージサービス、コントロールメッセージサービス、コマンドインタプリタ、状態通知（Ｎｏｔｉｆｉｃａｔｉｏｎ）サービス、及び、アドレスハンドラ等の機能を、マイコン１５に実現させることが可能な構成にされている。

例えば、マイコン１５は、ネットサービスプログラムＰ１を実行することにより、ファンクションブロックＰ２から入力される送信対象データに対し、正しい宛先のノードアドレス（デバイスＩＤとも呼ばれる）を付し、この送信対象データを、ＮＩＣ１３に入力して、ＮＩＣ１３経由で、送信対象データを宛先のＥＣＵ１０に送信する。また、ＮＩＣ１３から入力された自装置宛ての受信データを、宛先のファンクションブロックＰ２に入力する。

尚、送信対象データにノードアドレスを付す機能は、ネットワーク構成データを用いて実現される。ここでいう、ネットワーク構成データとは、システムを構成する各ノード（ＥＣＵ１０ａ〜ＥＣＵ１０ｅ）が有するファンクションブロックＰ２のＩＤが、このファンクションブロックＰ２を有するノードのアドレス（デバイスＩＤ）と対応付けられて記述されたデータのことである。このデータは、マスタである車両情報ＥＣＵ１０ａにより生成される。

スレーブとして機能する各ＥＣＵ１０ｂ〜１０ｅのマイコン１５は、起動時に、このネットワーク構成データを、マスタ（車両情報ＥＣＵ１０ａ）から取得して、通信システム１を構成する各ＥＣＵ１０が保有するファンクションブロックＰ２の住所及びその識別コード（ファンクションブロックＩＤ）を把握し、各ＥＣＵ１０が保有するファンクションブロックＰ２にアクセス可能に、自装置を構成する。

即ち、各ＥＣＵ１０が保有するファンクションブロックＰ２間の通信は、ファンクションブロックＰ２が、宛先のファンクションブロックＩＤを付して送信対象データを出力し、ネットワークサービスが、ネットワーク構成データに基づき、その送信対象データに、当該ファンクションブロックＩＤに対応するノードアドレスを付して、これをＮＩＣ１３に入力することで実現される。

図５は、ネットワーク構成データの取得手順に関するラダーチャートである。各ＥＣＵ１０は、通信システム１の起動時に、図５に示す手順で情報交換を行うことにより、他のＥＣＵのファンクションブロックＰ２に対してアクセス可能に自装置を構成する。

まず、各ＥＣＵ１０が起動して通信システム１が稼動すると、マスタである車両情報ＥＣＵ１０ａから、ブロードキャスト通信で、ファンクションリスト要求が、ネットワークに送出される。スレーブとして機能する各ＥＣＵ１０ｂ〜１０ｅは、マイコン１５にて、このファンクションリスト要求を受信する。

各ＥＣＵ１０のマイコン１５は、このファンクションリスト要求を受信すると、自己が保有するファンクションブロックＰ２のＩＤ及び当該ファンクションブロックＰ２を構成するファンクションのＩＤを付した保有ファンクションリストを、応答データとして、車両情報ＥＣＵ１０ａに送信する。車両情報ＥＣＵ１０ａは、ファンクションリスト要求の送信動作を実行すると共に、この応答データの受信動作を実行し、通信システム１を構成する各ＥＣＵ１０の保有ファンクションリストを取得する。

例えば、電話ＥＣＵ１０ｂは、電話機能を実現する「電話」ファンクションブロックＰ２を有するので、電話ＥＣＵ１０ｂのマイコン１５は、ファンクションリスト要求を受信すると、「電話」ファンクションブロックＰ２のＩＤを記した保有ファンクションリストを、車両情報ＥＣＵ１０ａに対して送信する。

一方、オーディオＥＣＵ１０ｃは、ＣＤ再生機能を実現する「ＣＤプレーヤ」ファンクションブロックＰ２、及び、ＤＶＤ再生機能を実現する「ＤＶＤプレーヤ」ファンクションブロックＰ２を有するので、ファンクションリスト要求を受信すると、この「ＣＤプレーヤ」ファンクションブロックＰ２のＩＤ及び「ＤＶＤプレーヤ」ファンクションブロックＰ２のＩＤを記した保有ファンクションリストを、車両情報ＥＣＵ１０ａに対して送信する。

また、オーディオアンプＥＣＵ１０ｄは、オーディオアンプ調整機能を実現する「アンプ」ファンクションブロックＰ２を有するので、ファンクションリスト要求を受信すると、「アンプ」ファンクションブロックＰ２のＩＤを記した保有ファンクションリストを、車両情報ＥＣＵ１０ａに対して送信する。

この他、ナビゲーションＥＣＵ１０ｅは、指定された目的地までの経路案内を実現する「ナビ」ファンクションブロックＰ２、ＧＰＳ受信機からの入力信号に基づき現在地点の位置座標を検出する「ＧＰＳ」ファンクションブロックＰ２、及び、マイクロフォンからの入力信号に基づき入力音声を認識する「音声認識」ファンクションブロックＰ２を有するので、ファンクションリスト要求を受信すると、「ナビ」ファンクションブロックＰ２、「ＧＰＳ」ファンクションブロックＰ２、及び、「音声認識」ファンクションブロックＰ２のＩＤを記した保有ファンクションリストを、車両情報ＥＣＵ１０ａに対して送信する。

車両情報ＥＣＵ１０ａは、このようにして、各ＥＣＵ１０から送信されてくる保有ファンクションリストを取得すると、システム１の構成を把握して、セントラルレジストリを形成し、その後に、セントラルレジストリの形成完了の旨のメッセージを、ブロードキャスト通信で、各ＥＣＵ１０に送信する。尚、セントラルレジストリは、システム１の物理構成及び論理構成のイメージを表すものであり、システム１を構成する各ノードが有するファンクションブロックＰ２のＩＤが、このファンクションブロックＰ２を有するノードのアドレス（デバイスＩＤ）と対応付けられて記述されたものである。

また、スレーブとして機能する各ＥＣＵ１０ｂ〜１０ｅは、上記セントラルレジストリの形成完了の旨のメッセージを受信すると、ネットワーク構成データ要求を車両情報ＥＣＵ１０ａに対して送信することで、ネットワーク構成データを、車両情報ＥＣＵ１０ａに対して要求する。換言すると、セントラルレジストリの内容の返答を要求する。車両情報ＥＣＵ１０ａは、このネットワーク構成データ要求を受信すると、セントラルレジストリの内容を、上記ネットワーク構成データとして、要求元のＥＣＵ１０に対し送信する。

このようにして、マスタ以外の各ＥＣＵ１０ｂ〜１０ｅに対しては、ネットワーク構成データが送信され、各ＥＣＵ１０ｂ〜１０ｅは、このデータの受信により、システムを構成する各ＥＣＵ１０が保有するファンクションブロックＰ２にアクセス可能に構成される。

また、ネットサービスプログラムＰ１により実現される状態通知サービスは、状態通知要求を送信してきたＥＣＵ１０（ノード）に対して、要求された状態の変化（プロパティの変化）を報告するサービスである。このサービスの利用設定は、上述したネットワーク構成データの送信が完了し、通信システム１を構成する各ＥＣＵ１０が、他のＥＣＵ１０のファンクションブロックＰ２にアクセス可能に構成された後、各ＥＣＵ１０からの要求に基づき、要求されたＥＣＵ１０が受動的に実行する。

具体的に、各ＥＣＵ１０のマイコン１５は、状態通知サービスに係る処理として、図６に示す処理を繰返し実行する。図６は、マイコン１５が実行する状態通知サービスを表すフローチャートである。即ち、マイコン１５は、他のＥＣＵ１０から、状態通知要求を受信すると（Ｓ１１０でＹｅｓ）、要求された内容を、状態通知設定情報として、ＲＡＭ１５ｂに記録する（Ｓ１２０）。

また、マイコン１５は、ＲＡＭ１５ｂに記録された上記内容（状態通知設定情報）に基づき、状態通知要求にて指定されたファンクションについて、当該ファンクションの状態（即ち、プロパティの値）が変化する度（Ｓ１３０でＹｅｓ）、この状態の変化を表す状態通知データを、ＮＩＣ１３経由で、要求元のＥＣＵ１０に送信する（Ｓ１４０）。このようにして、各ＥＣＵ１０は、他のＥＣＵ１０から要求された状態を、状態変化の度、要求元のＥＣＵ１０に対して通知する。

続いて、図５を用いて説明した各ＥＣＵ１０のマイコン１５が実行する処理について、その詳細を、図７及び図８を用いて説明する。尚、図７は、マスタ（車両情報ＥＣＵ１０ａ）のマイコン１５が実行するマスタ通信処理を表すフローチャートであり、図８は、スレーブ（車両情報ＥＣＵ１０ａ以外の各ＥＣＵ１０ｂ〜１０ｅ）のマイコン１５が実行するスレーブ通信処理を表すフローチャートである。

マスタとして機能する車両情報ＥＣＵ１０ａのマイコン１５は、図７に示すマスタ通信処理を、自装置（車両情報ＥＣＵ１０ａ）の起動時から開始することにより、他のＥＣＵ１０との通信を実現する。

具体的に、図７に示すマスタ通信処理を開始すると、車両情報ＥＣＵ１０ａのマイコン１５は、今回のマイコン始動が、不当例外始動に該当するものであるか否かを、ＮＶＲＡＭ１５ｃに記憶された不当例外始動フラグが、セットされた状態にあるか否かによって判断する（Ｓ２１０）。即ち、不当例外始動フラグがリセットされた状態にある場合には、今回のマイコン始動が、不当例外始動に該当するものではなく、通常始動に該当するものであると判断して（Ｓ２１０でＮｏ）、Ｓ２２０に移行し、不当例外始動フラグがセットされた状態にある場合には、今回のマイコン始動が、不当例外始動に該当するものであると判断して（Ｓ２１０でＹｅｓ）、Ｓ２３０に移行する。尚、工場出荷時点で、不当例外始動フラグは、リセットされているものとする。

そして、今回のマイコン始動が不当例外始動に該当するものではないと判断すると、マイコン１５は、自装置のＮＩＣ１３をリセットし（Ｓ２２０）、その後、Ｓ２３５に移行する。一方、今回のマイコン始動が不当例外始動に該当するものであると判断すると、マイコン１５は、自装置のＮＩＣ１３をリセットすることなく、マイコンリセットを行った旨のリセット通知データを、ブロードキャスト通信でネットワークに送出する（Ｓ２３０）。その後、Ｓ２３５に移行する。

また、Ｓ２３５に移行すると、マイコン１５は、ＮＶＲＡＭ１５ｃが記憶する不当例外始動フラグをリセット状態に設定し、その後、Ｓ２４０に移行する。
Ｓ２４０に移行すると、マイコン１５は、ファンクションリスト収集処理を実行する。具体的には、図５に示すファンクションリスト送受信プロセスのように、ブロードキャスト通信で、ファンクションリスト要求をネットワークに送出し、各ノードから送信されてくる保有ファンクションリストを受信して、受信した保有ファンクションリストに基づき、セントラルレジストリを形成する処理を実行する。

このようにして、Ｓ２４０での処理を終えると、マイコン１５は、Ｓ２５０に移行し、ネットワーク構成データ送信処理を実行する。具体的には、図５に示すネットワーク構成データ送受信プロセスのように、セントラルレジストリの形成完了の旨のメッセージを、ブロードキャスト通信で、ネットワークに送出し、これを契機として、各ＥＣＵ１０ｂ〜１０ｅから送信されてくるネットワーク構成データ要求を受け付け、ネットワーク構成データ要求を送信してきたＥＣＵ１０に対し、セントラルレジストリの内容を、上記ネットワーク構成データとして、送信する。

また、Ｓ２５０の処理を終了すると、マイコン１５は、予め定められた状態通知要求を、ネットワークを介して、特定のファンクションを有するＥＣＵ１０に対して送信し（Ｓ２６０）、当該ＥＣＵ１０に、状態通知に係る設定動作を実行させ、以後、要求した状態が変化する度に、このＥＣＵ１０から、当該状態の変化を表す状態通知データが送信されてくるようにする。

例えば、車両情報ＥＣＵ１０ａは、ナビゲーションＥＣＵ１０ｅに対して、ＧＰＳ位置情報についての状態通知要求を送信して、ＧＰＳ位置情報（換言すると車両位置座標）が変化する度に、ナビゲーションＥＣＵ１０ｅから、その位置座標が、状態通知データとして、送信されてくるようにする。

このようにして、Ｓ２６０での処理を終えると、マイコン１５は、通常の通信処理を実行して、ファンクションブロックＰ２間の通信を中継する（Ｓ２７０）。また、定期的に、他のＥＣＵ１０からリセット通知データを受信したか否かを判断し（Ｓ２８０）、リセット通知データを受信していない場合には（Ｓ２８０でＮｏ）、Ｓ２９０に移行して、自装置（自己ＥＣＵ）の再起動が必要なエラーが発生しているか否かを判断する。

そして、リセット通知データを受信していない場合且つエラーが発生していない場合には（Ｓ２８０でＮｏ、Ｓ２９０でＮｏ）、Ｓ２７０に移行する。このようにして、マイコン１５は、リセット通信データの受信有無、エラーの発生有無を定期的に判断しつつ（Ｓ２８０，Ｓ２９０）、Ｓ２７０の処理を実行して、ファンクションブロックＰ２間の通信を中継する。

一方、リセット通知データを受信したと判断すると（Ｓ２８０でＹｅｓ）、マイコン１５は、Ｓ２８５に移行して、状態通知の再要求処理を実行する。具体的には、Ｓ２６０で実行した処理と同様の処理を実行して、必要な状態通知要求を、ネットワークを介して、特定のＥＣＵ１０に対し送信する。その後、Ｓ２９０に移行して、エラーの発生有無を判断し、エラーが発生していない場合には（Ｓ２９０でＮｏ）、Ｓ２７０に移行する。

このようにして、マイコン１５は、他のＥＣＵ１０にてマイコン１５がリセットされた場合、そのＥＣＵ１０において、消失した状態通知設定情報が復元されるようにするため、起動時にした状態通知要求を、再度、同一のＥＣＵ１０に対して実行し、マイコンリセット後にも、当該ＥＣＵ１０から、状態の変化を表す状態通知データが送信されてくるようにする。

この他、Ｓ２９０で、自装置の再起動が必要なエラーが発生したと判断すると（Ｓ２９０でＹｅｓ）、マイコン１５は、発生したエラーが、アプリケーション・エラーであるか否かを判断する（Ｓ３００）。ここでは、具体的に、マイコン１５が実行するネットワーク層より上位層の処理で、正常な通信の継続が不能なエラーが発生した場合には、発生したエラーが、アプリケーション・エラーであると判断する（Ｓ３００でＹｅｓ）。一方、ＮＩＣ１３にて正常な通信の継続が不能なエラーが発生し、このエラー通知を受けて、Ｓ２９０でＹｅｓと判断した場合には、Ｓ３００において、発生したエラーが、アプリケーション・エラーではなく、ハードウェア・エラーであると判断する（Ｓ３００でＮｏ）。

そして、発生したエラーがアプリケーション・エラーであると判断すると（Ｓ３００でＹｅｓ）、マイコン１５は、Ｓ３１０に移行して、ＮＶＲＡＭ１５ｃが記憶する不当例外始動フラグをセットする。その後、マイコン１５は、Ｓ３２０に移行し、自己（当該マイコン１５）をリセットする処理を実行して、図７に示す処理を一旦終了する。但し、ここでいうリセットとは、マイコン１５のＮＶＲＡＭ１５ｃをリセットする動作を含まない。換言すると、ここでは、マイコン１５を一旦シャットダウンして、再起動する処理を実行する。

また、マイコン１５は、再起動時に、再び、図７に示す処理を開始するのであるが、この際には、不当例外始動フラグがセットされた状態にあるので、Ｓ２１０でＹｅｓと判断して、Ｓ２３０に移行し、ＮＩＣ１３をリセットせずに、リセット通知データを、ネットワークに、ブロードキャストして、マイコンリセットを行った旨を各ノードに通知する。

一方、Ｓ３００で発生したエラーがアプリケーション・エラーではないと判断すると（Ｓ３００でＮｏ）、マイコン１５は、Ｓ３１０の処理を実行せず、不当例外始動フラグをリセットの状態に保持したまま、Ｓ３２０に移行して、当該マイコン１５をリセットし、図７に示す処理を一旦終了する。また、マイコン１５は、再起動時、Ｓ２１０でＮｏと判断して、Ｓ２２０に移行し、ＮＩＣ１３をリセットすることにより、ＮＩＣ１３のエラーを解消する。その後、Ｓ２３５以降の処理を実行する。

続いて、図８を用いて、スレーブ（車両情報ＥＣＵ１０ａ以外の各ＥＣＵ１０ｂ〜１０ｅ）のマイコン１５が実行する処理について説明する。スレーブとして機能する各ＥＣＵ１０ｂ〜１０ｅのマイコン１５は、図８に示すスレーブ通信処理を、自装置の起動時から開始することにより、他のＥＣＵ１０との通信を実現する。

具体的に、図８に示すスレーブ通信処理を開始すると、各ＥＣＵ１０ｂ〜１０ｅのマイコン１５は、Ｓ２１０の処理と同様、今回のマイコン始動が、不当例外始動に該当するものであるか否かを、ＮＶＲＡＭ１５ｃに記憶された不当例外始動フラグが、セットされた状態にあるか否かによって判断する（Ｓ４１０）。

そして、今回のマイコン始動が不当例外始動に該当するものではなく通常始動に該当するものであると判断すると、マイコン１５は、自装置のＮＩＣ１３をリセットし（Ｓ４２０）、その後、Ｓ４３５に移行する。一方、今回のマイコン始動が不当例外始動に該当するものであると判断すると、マイコン１５は、Ｓ４３０にて、自装置のＮＩＣ１３をリセットすることなく、マイコンリセットを行った旨のリセット通知データを、ネットワークにブロードキャストする。その後、Ｓ４３５に移行する。

また、Ｓ４３５に移行すると、マイコン１５は、ＮＶＲＡＭ１５ｃが記憶する不当例外始動フラグをリセット状態に設定し、その後、Ｓ４４０に移行する。
Ｓ４４０に移行すると、マイコン１５は、ファンクションリスト送信処理を実行する。具体的には、図５に示すファンクションリスト送受信プロセスのように、マスタからファンクションリスト要求を受信すると、そのファンクションリスト要求に応答する形で、自己が保有するファンクションブロックＰ２のＩＤ及び当該ファンクションブロックＰ２を構成するファンクションのＩＤを付した保有ファンクションリストを、ファンクションリスト要求元に送信する。

また、このようにして、Ｓ４４０での処理を終えると、マイコン１５は、Ｓ４５０に移行し、ネットワーク構成データ取得処理を実行する。具体的には、図５に示すネットワーク構成データ送受信プロセスのように、セントラルレジストリの形成完了の旨のメッセージを、マスタ（車両情報ＥＣＵ１０ａ）から受信すると、マスタに対し、ネットワーク構成データを要求する旨のメッセージを、上記ネットワーク構成データ要求として送信し、この要求に応じてマスタから送信されてくるネットワーク構成データを受信して、自装置を、他のＥＣＵ１０のファンクションブロックＰ２と通信可能に構成する。

この他、Ｓ４５０での処理を終えると、マイコン１５は、予め定められた状態通知要求を、ネットワークを介して、特定のファンクションを有するＥＣＵ１０に対して送信し（Ｓ４６０）、当該ＥＣＵ１０に、状態通知に係る設定動作を実行させて、以後、要求した状態が変化する度に、このＥＣＵ１０から、当該状態の変化を表す状態通知データが送信されてくるようにする。

例えば、ナビゲーションＥＣＵ１０ｅは、電話ＥＣＵ１０ｂに対して、電話についての状態通知要求を送信して、電話が利用可（Ａｖａｉｌａｂｌｅ）／利用不可（Ｎｏｔ Ａｖａｉｌａｂｌｅ）のいずれの状態にあるかを表す状態通知データが、電話ＥＣＵ１０ｂから送信されてくるようにする。

また、Ｓ４６０での処理を終えると、マイコン１５は、通常の通信処理を実行して、ファンクションブロックＰ２間の通信を中継する（Ｓ４７０）。この他、マイコン１５は、マスタ（車両情報ＥＣＵ１０ａ）のマイコン１５が実行するＳ２８０〜Ｓ３２０の処理と同様にして、Ｓ４８０〜Ｓ５２０の処理を実行する。

即ち、定期的に、他のＥＣＵ１０から、リセット通知データを受信したか否かを判断し（Ｓ４８０）、リセット通知データを受信していない場合には（Ｓ４８０でＮｏ）、自装置（自己ＥＣＵ）のリセットが必要なエラーが発生しているか否かを判断する（Ｓ４９０）。

そして、リセット通知データを受信したと判断すると（Ｓ４８０でＹｅｓ）、Ｓ４８５に移行して、状態通知の再要求処理を実行する。即ち、Ｓ４６０で実行した処理と同様の処理を実行して、必要な状態通知要求を、ネットワークを介して、特定のＥＣＵ１０に対して送信する。その後、Ｓ４９０に移行して、エラーの発生有無を判断し、エラーが発生していない場合には（Ｓ４９０でＮｏ）、Ｓ４７０に移行する。このようにして、マイコン１５は、他のＥＣＵ１０のマイコン１５がリセットされた場合でも、当該ＥＣＵ１０から、状態通知データが送信されてくるようにする。

この他、Ｓ４９０で、自装置の再起動が必要なエラーが発生していると判断すると（Ｓ４９０でＹｅｓ）、マイコン１５は、Ｓ５００に移行し、Ｓ３００での処理と同様に、発生したエラーが、アプリケーション・エラーであるか否かを判断する。そして、発生したエラーがアプリケーション・エラーであると判断すると（Ｓ５００でＹｅｓ）、Ｓ５１０に移行して、ＮＶＲＡＭ１５ｃが記憶する不当例外始動フラグをセットする。

その後、マイコン１５は、Ｓ５２０に移行し、自己（当該マイコン１５）をリセットして、図８に示す処理を一旦終了する。そして、再起動時に再度実行する当該処理では、不当例外始動フラグがセットされた状態にあるので、Ｓ４１０でＹｅｓと判断して、ＮＩＣ１３をリセットせずに、リセット通知データを、各ノードにブロードキャストする（Ｓ４３０）。

一方、Ｓ５００で発生したエラーがアプリケーション・エラーではないと判断すると（Ｓ５００でＮｏ）、マイコン１５は、Ｓ５１０の処理を実行せず、不当例外始動フラグをリセットの状態に保持したまま、Ｓ５２０に移行して、当該マイコン１５をリセットし、図８に示す処理を一旦終了する。また、マイコン１５は、再起動時、Ｓ４１０でＮｏと判断して、Ｓ４２０に移行し、ＮＩＣ１３をリセットすることにより、ＮＩＣ１３のエラーを解消し、その後、Ｓ４３５以降の処理を実行する。

以上、本実施例の通信システム１の構成について説明したが、この通信システム１では、正常な通信が不能で再起動が必要なエラーが発生した場合に、従来システムのように、一律にＮＩＣ１３及びマイコン１５をリセットするのではなく、ＮＩＣ１３のエラーにより正常な通信が不能となった場合には、従来と同様、ＮＩＣ１３及びマイコン１５をリセットして再起動するが、マイコン１５のエラーにより、ソフトウェア的に正常な通信が不能となった場合には、ＮＩＣ１３をリセットせず、マイコン１５のみをリセットして、再起動するようにした。

そして、マイコン１５のリセット時に失った状態通知設定情報を復元するために、リセットを行ったＥＣＵ１０のマイコン１５から、リセット通知データを送信して、システム内の他のＥＣＵ１０に対してリセットした旨を通知し、他のＥＣＵ１０に、状態通知要求を再度実行させるようにした。

従って、本実施例の通信システム１によれば、システム内の一のＥＣＵ１０でマイコン１５のリセットが行われ、状態要求設定情報がマイコン１５から喪失した場合でも、システム全体をリセットすることなく、状態通知設定情報を、リセット前の状態に復元することができる。

よって、本実施例の通信システム１によれば、マイコン１５にエラーが生じた程度であってＮＩＣ１３にエラーが生じてない場合に、システム全体をリセットしなくても、ノード単体をリセットする程度で、エラーを解消することができ、システムを正常な状態に戻すことができる。

従って、本実施例によれば、上記通信プロトコルにて動作する通信システムにおいて、ノード数が増加して、エラーの発生頻度が高くなった場合でも、エラーを、個別のノードにて解消することができ、エラーの発生がシステム全体のリセットに繋がるのを抑えることができる。結果、本実施例によれば、上記通信プロトコルが採用された通信システムにおいて、安定した通信を実現することができる。即ち、一部ノードの軽微なエラー（アプリケーション・エラー）が、システム全体の再起動に発展するのを抑制することができ、安定的に、ノード間で良好な通信を行うことができる。

尚、本発明の通信制御ユニットは、ＦＯＴ１１及びＮＩＣ１３の組に対応し、通信処理ユニットは、プログラムにより、ネットワーク層及びそれより上位の層に属する処理を実行するマイコン１５に対応する。また、判定手段は、Ｓ３００，Ｓ５００の処理により実現され、リセット手段は、Ｓ３１０，Ｓ３２０，Ｓ２１０，Ｓ２２０，Ｓ５１０，Ｓ５２０，Ｓ４１０，Ｓ４２０の処理により実現され、リセット通知手段は、Ｓ２３０，Ｓ４３０の処理により実現されている。この他、要求処理実行手段は、Ｓ１１０〜Ｓ１４０の処理により実現され、要求手段は、Ｓ２６０，Ｓ２８５，Ｓ４６０，Ｓ４８５の処理により実現されている。

また、本発明は、上記実施例に限定されるものではなく、種々の態様を採ることができる。例えば、上記実施例では、本発明を、車内ＬＡＮに適用した例を示したが、本発明は、その他の種々のネットワークに適用することができる。

通信システム１の構成を表すブロック図である。 通信システム１を構成するＥＣＵ１０の基本構成を表すブロック図である。 ＮＩＣ１３で実行される処理を表すフローチャートである。 マイコン１５により実行されるプログラムを示したブロック図である。 ネットワーク構成データの取得手順に関するラダーチャートである。 マイコン１５が実行する状態通知サービスを表すフローチャートである。 マスタのマイコン１５が実行するマスタ通信処理を表すフローチャートである。 スレーブのマイコン１５が実行するスレーブ通信処理を表すフローチャートである。

符号の説明

１…通信システム、１０…ＥＣＵ、１１…ＦＯＴ、１１ａ，１１ｂ…光コネクタ、１３…ＮＩＣ、１５…マイコン、１５ａ…ＲＯＭ、１５ｂ…ＲＡＭ、１５ｃ…ＮＶＲＡＭ、ＬＮ…ＰＯＦケーブル、Ｐ１…ネットサービスプログラム、Ｐ２…ファンクションブロック

Claims (3)

1. 複数ノードが環状に接続され、所定プロトコルに従って、ノードから出力される通信信号が、隣接するノードへと一定方向に順に転送されることにより、ノード間の通信が実現されるリングトポロジー構成の通信システムであって、
   前記各ノードは、
   前記プロトコルに従ってネットワーク層及びそれより上位の層に属する処理を実行する通信処理ユニットと、
   隣接するノードと伝送ケーブルを介して接続され、前記プロトコルに従ってデータリンク層及び物理層に属する処理を実行して、前記伝送ケーブルを介して送信されてきた通信信号を受信し、受信した通信信号から抽出した受信データを、前記通信処理ユニットに入力すると共に、前記通信処理ユニットから入力された送信データに基づき、転送用の通信信号を生成し、前記生成した通信信号を次ノードへ送信する通信制御ユニットと、
   を備え、
   前記通信処理ユニットは、
   自ノードの再起動が必要なエラーが発生すると、前記エラーの種類に応じて、前記通信制御ユニットの再起動が必要であるか否かを判定する判定手段と、
   前記エラーが発生した場合であって、前記判定手段により前記通信制御ユニットの再起動が必要であると判定された場合には、前記通信制御ユニット及び通信処理ユニットをリセットする第一のリセット処理を実行して、自ノードを再起動し、前記判定手段により前記通信制御ユニットの再起動が不要であると判定された場合には、前記通信制御ユニットをリセットせずに、当該通信処理ユニットをリセットする第二のリセット処理を実行して、自ノードを再起動するリセット手段と、
   前記リセット手段により前記第二のリセット処理が実行されると、リセットの実行を通知するためのリセット通知データを、当該通信システムを構成する他ノードに対し、前記通信制御ユニットを介して、送信するリセット通知手段と、
   前記通信制御ユニットを介して、他ノードから所定の処理要求を受信すると、要求された処理を、繰返し実行する要求処理実行手段と、
   を備え、更に、
   前記複数ノードの内、少なくとも一つのノードは、
   前記複数ノードの内、特定のノードに対し、前記処理要求を、前記通信制御ユニットを介して送信すると共に、前記通信制御ユニットを介して、前記特定のノードから前記リセット通知データを受信すると、前記特定のノードに対し前記リセット前に送信した前記処理要求を、再度、前記特定のノードに対し送信する要求手段
   を前記通信処理ユニットに備えること
   を特徴とする通信システム。
2. 前記判定手段は、発生した前記エラーが、前記通信制御ユニットで発生したエラーである場合、前記通信制御ユニットの再起動が必要であると判定し、発生した前記エラーが、前記通信制御ユニットで発生したエラーではなく前記通信処理ユニットで発生したエラーである場合、前記通信制御ユニットの再起動が不要であると判定する構成にされていることを特徴とする請求項１記載の通信システム。
3. 前記要求処理実行手段は、前記処理要求として、他ノードから状態通知要求を受信すると、要求された状態が変化する度、状態変化を表すデータを、要求元のノードに対し、前記通信制御ユニットを介して送信する処理を実行する構成にされ、
   前記要求手段は、前記処理要求として、前記特定のノードに対し、前記状態通知要求を送信する構成にされていること
   を特徴とする請求項１又は請求項２記載の通信システム。

Images