(57)【特許請求の範囲】
【請求項１】
マスタノードとスレーブノードを含む複数のノード各々が共有メモリを有し、各ノードが、所定の通信サイクルでネットワークを介して前記共有メモリのデータを相互に送受信するシステムであって、
前記通信サイクル内に、前記各ノードが自ノードの前記共有メモリのデータを相互に異なるタイミングで送信する帯域であるコモンメモリ帯域と、メッセージ帯域とが含まれており、
前記スレーブノードは、
前記自ノードの共有メモリデータ送信時に、任意の他のノードへのメッセージがある場合には、メッセージ送信要求を付加して送信するメッセージ送信要求手段と、
該メッセージ送信要求に対して、前記マスタノードから許可通知があった場合には、前記メッセージ帯域において前記メッセージの送信処理を行うメッセージ送信処理手段とを有し、
前記マスタノードは、
前記メッセージ送信要求に応じて、該要求を許可するか否かを決定する許可決定手段と、
該要求を許可するノードに対して前記許可通知を送信する許可通知手段と、
を有することを特徴とするネットワーク伝送システム。
【請求項２】
前記許可決定手段は、前記メッセージ帯域の長さに応じて予め設定されている最大数に基づいて、前記メッセージ送信要求を行ったノードのなかで許可するノードを決定することを特徴とする請求項１記載のネットワーク伝送システム。
【請求項３】
前記許可決定手段は、許可するノードの数を前記最大数までとすることを特徴とする請求項２記載のネットワーク伝送システム。
【請求項４】
前記許可決定手段は、許可するメッセージ数を前記最大数までとすることを特徴とする請求項２記載のネットワーク伝送システム。
【請求項５】
前記許可決定手段は、前記メッセージ送信要求のなかに許可しなかった送信要求がある場合には、該送信要求を未許可要求として保留しておき、次の通信サイクルにおいて該未許可要求を優先的に許可することを特徴とする請求項１〜４の何れかに記載のネットワーク伝送システム。
【請求項６】
前記メッセージ送信処理手段は、前記メッセージ帯域において、前記許可通知に基づいて決定される所定のタイミングで、前記メッセージの送信処理を行うことを特徴とする請求項１〜５の何れかに記載のネットワーク伝送システム。
【請求項７】
前記メッセージ送信処理手段は、前記許可通知に基づいて自ノードの順番を認識して、該順番に予め設定される所定値を乗じることで、前記所定のタイミングを決定することを特徴とする請求項６記載のネットワーク伝送システム。
【請求項８】
前記マスタノードの前記許可決定手段は、自ノードに任意の他のノードへのメッセージがある場合には、自ノードも含めて前記要求を許可するノードを決定することを特徴とする請求項１〜７の何れかに記載のネットワーク伝送システム。
【請求項９】
各々が共有メモリを有する複数のノードから成り、各ノードが、所定の通信サイクルでネットワークを介して前記共有メモリのデータを相互に送受信し、前記複数のノードのうち１台をマスタノードとし、他をスレーブノードとするシステムにおける該マスタノードにおいて、
前記通信サイクル内に、前記各ノードが自ノードの前記共有メモリのデータを相互に異なるタイミングで送信する帯域であるコモンメモリ帯域と、メッセージ帯域とが含まれており、
前記コモンメモリ帯域内に各スレーブノードから相互に異なるタイミングで送信されてくる前記共有メモリデータを受信すると、該共有メモリデータにメッセージ送信要求が含まれているか否かを確認することで、その通信サイクルにおいてメッセージ送信を要求するスレーブノードを判別するメッセージ送信要求ノード判別手段と、
該各メッセージ送信要求ノードに対して、該要求を許可するか否かを決定する許可決定手段と、
該要求を許可するノードに対して許可通知を送信する許可通知手段と、
を有することを特徴とするネットワーク伝送システムのマスタノード。
【請求項１０】
各々が共有メモリを有する複数のノードから成り、各ノードが、所定の通信サイクルでネットワークを介して前記共有メモリのデータを相互に送受信し、前記複数のノードのうち１台をマスタノードとし、他をスレーブノードとするシステムにおける該スレーブノードにおいて、
前記通信サイクル内に、前記各ノードが自ノードの前記共有メモリのデータを相互に異なるタイミングで送信する帯域であるコモンメモリ帯域と、メッセージ帯域とが含まれており、
前記自ノードの共有メモリデータ送信時に、任意の他のノードへのメッセージがある場合には、メッセージ送信要求を付加して送信するメッセージ送信要求手段と、
該メッセージ送信要求に対して、前記マスタノードから許可通知があった場合には、前記メッセージ帯域において前記メッセージの送信処理を行うメッセージ送信処理手段と、
を有することを特徴とするネットワーク伝送システムのスレーブノード。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、各ノードがコモンメモリデータを共有するシステムに関する。
【背景技術】
【０００２】
ネットワークにおける通信の分類として、ブロードキャスト送信(以下、ＢＣ送信)とユニキャスト送信(以下、ＵＣ送信)の分類がある。ＢＣ送信は、ネットワーク参加局全局にあてて自局データを送信する方法である。ＵＣ送信は、自局から特定相手局に向けて1対1で通信する場合に使用される。
【０００３】
ＢＣ送信は、同一データを複数局に同時に送る場合にデータ伝送の効率が良いが、全ての局が正しくデータを受信できたかどうかを確認する手段がなく、データ伝送の確実性という意味では課題がある。
【０００４】
一方で、ＵＣ送信は、特定相手局に向けてデータ伝送されるため、データ伝送効率はＢＣ送信に比べ劣るが、相手局からの応答をもらうことで送信を完了する手順(プロトコル)を確立すれば、ＢＣ送信に比べデータ伝送の確実性は高い。
【０００５】
トークンを用いたコモンメモリ交換とメッセージ通信の併用による通信サイクルの短縮に関しては、特許文献１に開示されている従来例がある。
特許文献１の従来技術では、メッセージの送信機会をネットワークの参加局に均等に割り当てたり、予め決められた割合で送信権を割り当てるなどして、メッセージ送信を管理することで、サイクリック周期を短縮している。しかしながら、メッセージ通信は、本来、突発的に不特定の局から発生するものであり、メッセージ負荷の動的変動に対して効率が悪い方式と言える。
【０００６】
また、例えば、従来のプラント制御用伝送システム等のような産業用ネットワークでは、システムを構成する各機器（各ノード；各局）が、リアルタイム性を保証したうえで相互に大容量のデータ交換を行う必要がある。したがって、例えば各機器に搭載されるアプリケーションによるアクセス要求の発生に応じてイベント的に相互アクセスを行うような場合には、ネットワーク負荷がアプリケーションに依存してしまい、リアルタイム性を保証することができない。
【０００７】
尚、リアルタイム性を保証するとは、例えば後述するＴＳ帯域内で全てのノードのコモンメモリデータ送信処理が完了すると共に、これが後述する定周期Ｔで繰り返し実行されることである。換言すれば、定周期Ｔを維持しつつ、全てのノードのコモンメモリが同一且つ最新のデータを保持できるようにすることである。
【０００８】
そこで、従来では、各局に仮想的な共有メモリ（コモンメモリ）を備えて、各局が相互に異なるタイミングで、ネットワーク上の全局へ自局のコモンメモリデータの送信を行う技術（共有メモリ方式と呼ぶ）が存在する。上記コモンメモリデータを受信した各局が、それによって自局のコモンメモリの格納データを更新することにより、リアルタイム性を保証したデータ交換方式を実現している。
【０００９】
また、例えば特許文献２には、各局に任意のタイムスロットが割り当てられ、各局が自己に割り当てられたタイムスロットのタイミングでデータ送信等を行うこと等が開示されている。特許文献２の従来技術では、各ノードの内蔵タイマによる時分割多重アクセス方式と、マスタノードからの同期化フレームによってスレーブノードの内蔵タイマを補正する方式とを併用している。また、特許文献２の手法では、伝送路を、バス又はシリアルケーブルで接続されたネットワークとして構成している。
【先行技術文献】
【特許文献】
【００１０】
【特許文献１】特開平９−１４９０５９号公報
【特許文献２】特開２００５−１５９７５４号公報
【発明の概要】
【発明が解決しようとする課題】
【００１１】
ところで、最近では、産業用ネットワークにおいてもイーサネット（Ｅｔｈｅｒｎｅｔ）（登録商標）の適用が進んでおり、情報系機器との連携も考慮されたコントローラレベルでのネットワークにおいては主流となりつつある。特許文献２の手法を、イーサネットを物理層とした回線へ適用しようとした場合には、以下のような課題がある。
【００１２】
例えば、特許文献２の手法では、物理層をバス或いはシリアルケーブルのカスケードとしている。そのため、ブロードキャスト送信されたデータの受信タイミングは、各局同時或いはほぼ無視できる時間差であることが想定できる。
【００１３】
しかしながら、例えば１００ＢＡＳＥ−ＴＸや１０００ＢＡＳＥ−Ｔ等のＥｔｈｅｒｎｅｔを伝送路とした場合では、トポロジとしてスター型が採用され、ＨＵＢ（ハブ）のような中継装置を含めた構成となる。
【００１４】
一般的に、ＨＵＢにおいては、フレームデータの中継に際し、ストア＆フォワードといわれる中継方式を採用しており、全フレームデータを受信しきらなければ宛先ノードへの送信を行わない。このため、ブロードキャスト送信データの各ノードでの受信タイミング遅延量は、経由するＨＵＢの段数によって変化する。したがって、例えば１０００ＢＡＳＥ−Ｔ等の高速な通信回線を用いて高効率なデータ交換を実現しようとする場合には、上述したような遅延を無視できない。
【００１５】
また、例えば、マスタ局が送信する同期化フレームを各スレーブ局が受信するタイミングが、ばらついた場合には、各スレーブ局のタイマ補正タイミングがばらついてしまい、各局でのデータ送信タイミングの重複（輻輳）が発生してしまう。輻輳によって、データの延着だけでなく、ＨＵＢ等のバッファ容量等によってはフレームデータの破棄が発生する。これは、産業用ネットワークとしては致命的と成り得ることである。特に、マスタ局からの同期化フレームに対して輻輳が発生した場合には、フレーム破棄が発生しなくとも、同期化フレームの受信タイミングがさらに遅くなるだけでなく、輻輳したフレームのサイズや種類によって遅れ時間が不確定となる。そのため、従来手法では、システム全体でのデータ交換周期が乱れてしまう問題がある。
【００１６】
ここで、本出願人は、先願（WO 2013121568 A1）の発明を提案している。
先願では、高効率なコモンメモリデータ交換手法を実現しているが、コモンメモリデータ交換手法は、予め決められた構造を持つデータの更新を定期的に行うことに向いており、例えば各局において突発的に発生する特定相手局向けのデータ(メッセージ)を扱うことが難しい。すなわち、一般的に、メッセージ通信処理は、1対1のデータ交換として実装され、相手局が送信データを確実に受信したことを確認する為に、相手局が確認応答を返信する。しかしながら、ＢＣ送信では、複数局がほぼ同タイミングでデータを受信するため、確認応答が困難である。
【００１７】
上記のことから、メッセージ通信を行うのであれば、ＵＣ送信を用い、送信したメッセージに対して確認応答が返信されるような通信方式がふさわしい。尚、確認応答は、肯定応答(ＡＣＫ；ACKnowledgement)または否定応答(ＮＡＣＫ；Negative ACKnowledgement)等となる。
【００１８】
また、メッセージ通信に関して、各々の局で突発的にメッセージ送信要求が発生するので、データの衝突を防ぐため、メッセージ送信権を用いた送信権管理が行われることが一般的である。これに関して、例えばトークン方式の場合、トークンをネットワーク参加局に巡回させて、トークンを取得した局がメッセージの送信を行うことができる。
【００１９】
上記トークン方式では、各トークン周回におけるメッセージ送信要求局の数の多寡に応じて、トークン巡回時間が伸び縮みしてしまうため、時間確定的に通信を行いたい上記コモンメモリデータ交換手法とは相いれない。つまり、トークン巡回時間が変動する為にメッセージ通信に掛かる時間も変動するので、上記コモンメモリデータ交換手法のリアルタイム性を保証できなくなる。
【００２０】
本発明の課題は、特に共有メモリを有するノード間で定周期で共有メモリデータ交換するシステムにおいて、リアルタイム性を保証しつつ輻輳が生じることなくメッセージ通信も行うことができるネットワーク伝送システム等を提供することである。
【課題を解決するための手段】
【００２１】
本発明のネットワーク伝送システムは、マスタノードとスレーブノードを含む複数のノード各々が共有メモリを有し、各ノードが、所定の通信サイクルでネットワークを介して前記共有メモリのデータを相互に送受信するシステムであって、下記の特徴を有する。
【００２２】
前記通信サイクル内に、前記各ノードが自ノードの前記共有メモリのデータを相互に異なるタイミングで送信する帯域であるコモンメモリ帯域と、メッセージ帯域とが含まれる構成とする。
【００２３】
そして、前記スレーブノードは、前記自ノードの共有メモリデータ送信時に、任意の他のノードへのメッセージがある場合には、メッセージ送信要求を付加して送信するメッセージ送信要求手段と、該メッセージ送信要求に対して、前記マスタノードから許可通知があった場合には、前記メッセージ帯域において前記メッセージの送信処理を行うメッセージ送信処理手段とを有する。
【００２４】
また、前記マスタノードは、前記メッセージ送信要求に応じて、該要求を許可するか否かを決定する許可決定手段と、該要求を許可するノードに対して前記許可通知を送信する許可通知手段とを有する。
【発明の効果】
【００２５】
本発明のネットワーク伝送システムによれば、特に共有メモリを有するノード間で定周期で共有メモリデータ交換するシステムにおいて、リアルタイム性を保証しつつ輻輳が生じることなくメッセージ通信も行うことができる。
【図面の簡単な説明】
【００２６】
【図１】本例のネットワーク伝送システムの概略構成例である。
【図２】各ノードの各タイマに応じた動作例である。
【図３】スレーブノードのサイクルタイマ補正のための処理手順の一例を示す図である。
【図４】共有メモリについて示す図である。
【図５】先願のシステムのデータ送信動作を示す図である。
【図６】本例のシステムのデータ送信動作を示す図（その１）である。
【図７】（ａ）はコモンメモリデータフレーム、（ｂ）は許可フレームのデータ構成例である。
【図８】本例のシステムのデータ送信動作を示す図（その２）である。
【図９】許可フレームのデータ構成例（その２）である。
【図１０】本例のシステムのデータ送信動作を示す図（その３）である。
【図１１】各ノードのタイマ動作とそれに応じたデータ送信タイミングを示す図である。
【図１２】マスタノードにおける送信タイマ処理のフローチャート図である。
【図１３】マスタノードにおける受信処理のフローチャート図である。
【図１４】マスタノードにおける許可フレーム生成処理のフローチャート図である。
【図１５】スレーブノードにおける送信タイマ処理の処理フローチャート図である。
【図１６】スレーブノードにおけるメッセージ送信要求に係わる状態遷移図である。
【図１７】本例のネットワーク伝送システムの機能ブロック図である。
【図１８】本例のノードの概略ハードウェア構成図である。
【発明を実施するための形態】
【００２７】
以下、図面を参照して本発明の実施の形態について説明する。
尚、以下に説明する１実施形態は、先願（WO 2013121568 A1）をベースにした例であるが、この様な例に限らない。但し、基本的には、定周期でコモンメモリのデータ交換を行うシステムを前提とする。そして、本手法は、この定周期の通信サイクルにおいて、コモンメモリのデータ交換を行う為の帯域に加えて、メッセージ通信を行う為の帯域も設ける。そして、先願はコモンメモリデータ交換の上記リアルタイム性を保証できるものであり、本手法では、これを損なうことなく、メッセージ通信も行えるようにしている。
【００２８】
また、先願では、各ノードが、共有メモリ（コモンメモリ）を備えると共にサイクルタイマ、センドタイマ等を備える構成であったが、以下の１実施形態でも基本的にこの構成を備えるものとする。但し、タイマに関しては、この様な一例に限らない。
【００２９】
また、先願では、各スレーブノードのサイクルタイマを、マスタノードのサイクルタイマと同期させる為の処理も行っており、以下の１実施形態でも基本的に同様の処理を行うものとする。但し、この例に限らない。尚、上記サイクルタイマは、上記通信サイクル（一定周期Ｔ）を生成する為のタイマである。
【００３０】
上述したことから、以下に説明する一実施例では、まず、例えば、ネットワークを構成する各ノード（スレーブ局）のサイクルタイマの起動タイミングを、同期化フレーム受信タイミングではなく、マスタ局の同期化フレーム送信タイミングに合わせ込む。つまり、例えば図１のようなシステム構成では、通信路上の各中継装置（例えば、ＨＵＢ等）でフレームの中継遅延が生じるが、この中継遅延による影響（同期誤差）を最小限とするための同期合わせを行う。これによって、各ノードの通信サイクルの同期化等を高精度に行うことができる。
【００３１】
尚、本説明における“同期”とは、例えば各ノードのタイマのカウンタ動作（起動タイミング；位相等）が合っている状態をいうが、これに限定されるものではない。
図１は、本実施形態におけるネットワーク伝送システムの概略構成の一例を示す図である。
【００３２】
図１に示すネットワーク伝送システム１０は、一例として、複数のノード装置１１と、１又は複数のＨＵＢ（ハブ）１２とを有する。なお、ノード装置や中継装置の数や種類、接続方法については、図示の例に限定されるものではない。また、ＨＵＢ１２は、中継装置の一例であり、この例に限るものではない。
【００３３】
また、図１の例では、ＨＵＢ１２は、ＨＵＢ１２−１〜１２−５の５台あるものとする。また、ノード装置１１は、ノード装置１１−１、ノード装置１１−２、ノード装置１１−３の３台あるものとし、以下、基本的にこれらをノードＡ、ノードＢ、ノードＣと記すものとする。但し、特に区別しない場合にはノード装置１１と記すものとする。
【００３４】
ここで、図１の例では、ノードＡをマスタノード（マスタ局）とし、ノードＢ、ノードＣをスレーブノード（スレーブ局）とする。これより、マスタノードＡ、スレーブノードＢ、Ｃ等と記す場合もあるものとする。
【００３５】
また、図１の例に示すように、ネットワーク伝送システム１０の通信路は、各ノード間に中継装置（ＨＵＢ１２）を有するスター型である。各ノード装置１１は、通信路を介して相互に接続されている。図示の例では、ノードＡ及びノードＣが同一のＨＵＢ１２−１に接続されており、ノードＢは、５段のＨＵＢ１２を経由してノードＡ及びノードＣと接続されている。
【００３６】
なお、中継装置は、一例としてＨＵＢ１２を示すが、この例に限定されるものではなく、例えばルータ、リピータ、光コンバータ等であってもよい。
また、各ノード装置１１は、例えばプログラマブルコントローラ（ＰＬＣ）、ＰＣ（Ｐｅｒｓｏｎａｌ Ｃｏｍｐｕｔｅｒ）、サーバ、入出力（Ｉ／Ｏ）モジュール、各種ドライブ装置（例えば、インバータ、サーボ等）等であるが、これらの例に限らない。
【００３７】
ここで、ネットワーク伝送システム１０は、上記背景技術で説明した共有メモリ方式が用いられているものとする。よって、各ノードＡ，Ｂ、Ｃは、図１では図示しない共有メモリ（コモンメモリ）を有している。そして、各ノードは、所定の通信サイクル（後述する定周期Ｔ）で、相互に異なるタイミングで、ネットワーク上の全局へ自局の共有メモリデータの送信を行うことを繰り返す。これを受信した各ノード（各局）は、当該受信データを自ノードの共有メモリの該当領域に上書き格納することで、データを更新する。この様にして、リアルタイム性を保証したデータ交換方式を実現している。
【００３８】
尚、各ノードにおいて、任意のアプリケーションの処理実行に伴って、共有メモリにアクセスするが、上記処理によってリアルタイムに最新の更新データにアクセスできることになる。上記アプリケーションは、例えばプラント等の各種機器の制御用のアプリケーションであるが、この例に限らない。
【００３９】
尚、リアルタイム性を保証するとは、上述したように、例えば後述する図５、図６等に示すＴＳ帯域内に、全てのノードのコモンメモリデータ送信処理が完了すると共に、これが定周期Ｔで繰り返し実行されることである。換言すれば、定周期Ｔを維持しつつ、全てのノードのコモンメモリが同一且つ最新のデータを保持できるようにすることである。
【００４０】
ここで、図４に、共有メモリについて示す。
図１に示すシステム構成例の場合、全てのノードにおいて、その共有メモリは、ノードＡ用の記憶領域とノードＢ用の記憶領域とノードＣ用の記憶領域とを有する。各ノードが、自己の共有メモリにおいて任意にデータ更新できる記憶領域は、自ノード用の記憶領域のみであり、それ以外の記憶領域については他ノードから送信されてくるデータを、上書き格納するだけである。例えば、ノードＡの場合、自己の共有メモリにおいて上記ノードＡ用の領域に対してのみ任意のデータ更新が行える。これは、例えば上記制御用等のアプリケーションの処理実行に伴って、自ノード用の記憶領域のデータを更新するものである。
【００４１】
そして、ノードＡは、通信サイクル毎に所定の送信タイミングになると、自己の共有メモリにおけるノードＡ用の記憶領域の格納データを、ブロードキャスト送信する。他のノードＢ、Ｃは、この送信データを受信すると、これを自己の共有メモリのノードＡ用の記憶領域に上書き格納する。
【００４２】
この様にして、全てのノードＡ，Ｂ、Ｃの共有メモリのノードＡ用の記憶領域には、同じデータが格納された状態とする。これは、ノードＢ用の記憶領域、ノードＣ用の記憶領域についても同様であり、これによって全てのノードＡ，Ｂ、Ｃの共有メモリには同じデータが格納された状態とすることができる。そして、この共有メモリ格納データは、リアルタイムのほぼ最新のデータであると言える。
【００４３】
尚、上記のように各ノード装置１１が送信するのは、共有メモリの全データではなく自ノード用の記憶領域の格納データであるが、本説明ではこの点について逐一述べずに、単に共有メモリデータ（コモンメモリデータ）を送信すると記すものとする。
【００４４】
ここで、上記各ノード装置１１が上記コモンメモリデータを送信するタイミングが、相互に異なるようにする必要がある。つまり、各局でのデータ送信タイミングの重複（輻輳）が発生しないようにする必要がある。
【００４５】
その為に、本例では上述したように、上記先願と同様に、全てのノードＡ，Ｂ、Ｃが、同一の時間（Ｔ）が設定されたサイクルタイマ（第１のタイマ）や、センドタイマ等を有している。そして、各ノードは、自己のサイクルタイマによって規定される定周期Ｔ（通信サイクル）を基準にして動作する。そして、各ノードが、この基準に基づいて自己のセンドタイマ（第２のタイマ）を動作させて、センドタイマのタイマアップ時を自己の上記送信タイミングとする。各局のセンドタイマの設定値が相互に異なるように設定することで、各局のデータ送信タイミングの重複（輻輳）が発生しないようにできるはずである。
【００４６】
しかしながら、実際には、例えばサイクルタイマの位相ズレ等が原因となって、誤った送信タイミングとなってしまう場合がある。その一例を図２に示す。
図２の例では、スレーブノードＢのサイクルタイマの位相が、マスタノードＡのサイクルタイマとズレており、その為にノードＢのコモンメモリデータ送信タイミングが遅れて、ノードＡの同期化フレーム送信タイミングと重なっている状態を示している。
【００４７】
以下、図２について説明する。
図２は、各ノードの各タイマに応じた動作例である。
図２は、ノードＢが新規にネットワーク伝送システム１０に加入した後、未だ先願の手法によるズレ補正を行う前の状態を示している。尚、このとき、スレーブノードＣのサイクルタイマは、既にマスタノードＡのサイクルタイマと同期化済みであるものとする。従って、図ではノードＣのサイクルタイマの動作は示していないが、図示のサイクルタイマ（Ａ）（ノードＡのサイクルタイマ）の動作と同じであることになる。
【００４８】
一方で、図示のサイクルタイマ（Ｂ）（ノードＢのサイクルタイマ）には、サイクルタイマ（Ａ）に対して図示の遅延２６が発生している。つまり、この遅延２６の分の位相ズレが生じている。尚、この様なサイクルタイマの表記と同様、センドタイマに関しても例えばノードＢのセンドタイマはセンドタイマ（Ｂ）と図示・表記するものとする。
【００４９】
ここで、マスタノードＡは、周期Ｔの通信サイクル毎に、最初に同期化フレーム２１をブロードキャスト送信する。各スレーブノードは、例えば後述するサイクルタイマの位相補正を未だ行っていないときには、この同期化フレーム受信に応じて自己のサイクルタイマをクリア（起動）する。また、自己のサイクルタイマの起動に合わせて自己のセンドタイマをクリア（起動）する。これより、上記遅延２６は、ノードＡからノードＢへ上記同期化フレームが届くまでに掛かる伝送遅延と見做すこともできる。
【００５０】
各ノード装置１１では、基本的には、自己のサイクルタイマがタイマアップする毎に直ちに当該サイクルタイマをクリア（起動）すると共に、自己のセンドタイマも併せてクリアする。そして、センドタイマがタイマアップしたときを上記コモンメモリデータ送信タイミングとして、自己の共有メモリの自ノード用の記憶領域の格納データを、通信路上にブロードキャスト送信する。例えばノードＡは図示のタイミングで図示のデータ２３を送信し、ノードＣは図示のタイミングで図示のデータ２４を送信する。また、ノードＢも図示のタイミングで図示のデータ２５を送信するが、これは正常なタイミングでのデータ送信ではない。これについて以下に説明する。
【００５１】
各センドタイマは、相互に異なる時間が設定されており、従って同一タイミングでクリアした場合には、必ず相互に異なるタイミングでタイマアップすることになる。更に、最も長い時間が設定されているセンドタイマを有するノード装置１１であっても、そのデータ送信処理がその周期Ｔ内に完了するように、予めセンドタイマの時間が設定されているものとする。図示の例では、センドタイマ（Ｂ）に最も長い時間が設定されている。
【００５２】
しかしながら、上記のようにサイクルタイマ（Ｂ）の位相ズレ（遅延２６）があると、センドタイマ（Ｂ）のタイマアップタイミングが遅れてしまい、図示のようにデータ送信処理が次の周期Ｔまで及んでしまう場合もあり得る。この為、図示のように、次の周期Ｔにおける同期化フレーム２１の送信タイミングと重なってしまい、輻輳が発生する。
【００５３】
この様な問題が生じないようにする為に、本手法では、上記先願と同様にして、例えばサイクルタイマ（Ｂ）がサイクルタイマ（Ａ）と同期するように、上記位相ズレを修正する。この位相ズレ修正処理については、図３を参照して説明するが、その前にタイマ補正を行う必要性に関して以下に更に説明する。
【００５４】
ここで、一般的なイーサネットのＨＵＢでは、ストア＆フォワードといわれるインタフェース方式が採用されている。この場合、送られてきたフレームは、全てをＨＵＢ内の受信バッファに蓄え、ＨＵＢ内部処理（例えば、異常判定や宛先判定等）を行ってから送信される。また、送信先ポートが使用中の場合を想定した受信バッファは、余裕を持ったサイズが確保されているのが普通であり、多少の輻輳であればデータの消失は発生せずに通信を行うことができる。しかしながら、同期化フレームは、その受信タイミングが同期を行ううえでの重要な要素であり、同期化フレームの遅延受信は致命的である。
【００５５】
また、例えばイーサネットでは、ＱｏＳ（Ｑｕａｌｉｔｙ ｏｆ Ｓｅｒｖｉｃｅ）等によるフレームの優先度制御を行うことができる。しかしながら、図２の例では、すでにノードＢからのデータ２５が受信状態になっているため、優先度の設定によらず同期化フレーム２１はノード装置Ｃでの受信も遅れてしまい、システム上の各ノードの同期が崩れてしまう。
【００５６】
イーサネットで使用されるＨＵＢは、ＩＰアドレス（Ｉｎｔｅｒｎｅｔ Ｐｒｏｔｏｃｏｌ Ａｄｄｒｅｓｓ）を持っておらず、通常、システム構成ノードからは認識されない。また、ＨＵＢは、スター型のトポロジで構築可能なため、システム構成ノード間で何段ものＨＵＢを経由してシステムを構築することが可能であり、またＨＵＢによる遅延時間もメーカや機種等によって異なる場合が多い。そのため、実際には、システムが構成されるまで、マスタノードからスレーブの各ノードへの遅れ時間を設定することは困難であった。
【００５７】
そこで、本例では先願と同様に、マスタノードが自己と各スレーブノード間の伝送遅延時間を実測にて求めて、これを各スレーブノードに通知することで、マスタノードのサイクルタイマと各スレーブノードのサイクルタイマとを同期させることができる。この処理は、例えば各スレーブノードのシステムへの加入時に行う。但し、この例に限らず、例えばシステム起動時や運用中に行うようにしてもよい。
【００５８】
ここで、図３に、スレーブノードのサイクルタイマ補正のための処理手順の一例を示す。尚、これは、上記先願のサイクルタイマ補正手順と略同様と見做しても構わない。
尚、図２では示していないが、図３においては、上記周期Ｔの通信サイクル内を、図示にＴＣ帯域とＴＳ帯域とに分割しているものと見做している。ＴＣ帯域は同期化フレームの送信用の帯域であり、ＴＳ帯域は上記共有メモリデータ送信用の帯域である。同期化フレーム送信や返信の処理は、ＴＣ帯域内に完了するように設定されていると共に、全てのノードの共有メモリデータ送信処理がＴＳ帯域内に完了するように設定されている。但し、上記の様にサイクルタイマの位相ズレ等が原因で、設定通りに動作しない場合もあり得る。
【００５９】
また、図３に示す矩形の枠はデータフレームを示し、枠の中の文字はデータフレームの種別を示す。つまり、“ＴＣ”は上記同期化フレームを意味し、“ＴＳ＊”は、上記共有メモリデータの送信フレーム（ノードデータと呼ぶものとする）を意味する。尚、“ＴＳ＊”における＊は、送信元ノードを意味し、例えば“ＴＳＣ”は、ノードＣが送信する上記ノードデータを意味する。各ノードＡ〜Ｃに対する横線の上側の矩形は送信フレームを示し、下側の矩形は受信フレームを示している。
【００６０】
また、枠内の文字によって各フレームを呼ぶものとする。例えば、枠内に“ＯＫ”となるフレームは、ＯＫフレームと呼ぶ。
また、図３において、ｒｅｑフレーム３３は加入要求を示し、ＯＫフレーム３４は加入許可を示し、ｄｌｙフレーム３５は同期化フレームに対する返信を示し、ＳＥＴフレーム３６は遅延時間設定用のフレームを示す。
【００６１】
また、図３は、ノードＡ，Ｃによって運用中にノードＢが新規加入した場合を示している。これより、図上左側に示すように、ノードＣのサイクルタイマ（Ｃ）は、既に図示のようにノードＡのサイクルタイマ（Ａ）に同期しているが、ノードＢのサイクルタイマ（Ｂ）は、図示のように未だノードＡのサイクルタイマ（Ａ）に同期していない状態となっている。尚、図示の状態では、ノードＢは、マスタノードＡからの上記同期化フレーム受信タイミングで、自己のサイクルタイマ（Ｂ）をクリア（起動）している。この為、上記の通り、ＴＣフレームの伝送遅延があるので、ノードＢのサイクルタイマ（Ｂ）と、ノードＡのサイクルタイマ（Ａ）とには、図示のように位相ズレが生じている。
【００６２】
ここで、新規加入ノードであるノードＢは、任意のＴＳ帯域中に、加入要求フレームであるｒｅｑフレーム３３を、マスタノードであるノードＡに対して送信する。ノードＡは、加入要求したノードＢの加入可否を判断したうえで、加入許可をする場合はＯＫフレーム３４を、同期化フレームＴＣの送信の際に送信する。
【００６３】
ノードＡからＯＫフレーム３４を受け取ったノードＢは、次の同期化フレームＴＣ受信時に直ちにマスタ宛に返信フレーム（ｄｌｙフレーム３５）を送信する。
そして、上記ｄｌｙフレーム３５を受信したノードＡは、例えば、そのときのサイクルタイマのカウント値等を記録する。サイクルタイマのスタート時に同期化フレームが送信されているので、このカウント値は同期化フレーム送信時からｄｌｙフレーム３５受信時までの時間を示すことになる。ノードＢは、ＴＣフレーム受信時に直ちに上記ｄｌｙフレーム３５を返信しているので、上記ｄｌｙフレーム３５の受信時のサイクルタイマ値と同期化フレームＴＣ送信時のサイクルタイマ値（＝０）との差分が、ノードＡ−ノードＢ間の往復の伝送時間（往復伝送遅延時間）の実測値と見做すことができる。
【００６４】
よって、この往復伝送遅延時間の半分の値が、片道の伝送遅延時間と見做せる。そして、この片道の伝送遅延時間は、上記ＴＣフレームのノードＡの送信時からノードＢ受信時までの時間と見做せ、以ってサイクルタイマの位相ズレ量（図２の例では上記遅延２６）と見做せる。尚、以下、“往復”と言わない限りは、伝送遅延時間は、片道分の時間を意味するものとする。
【００６５】
上述したことから、ノードＡは、上述した処理によって得られた上記伝送遅延時間を、加入要求したスレーブノード（ノードＢ）に対して図示のＳＥＴフレーム３６にて通知する。尚、ＳＥＴフレーム３６は、例えばＴＣフレームと共に送信する。
【００６６】
ノードＢは、ＳＥＴフレーム３６を受信することで得た上記伝送遅延時間によって自己のサイクルタイマ設定値を減算する。すなわち、ノードＢは、「Ｔ−伝送遅延時間」をサイクルタイマ（Ｂ）にセットしてサイクルタイマ（Ｂ）を起動する。これによって、例えば図３に示す時間３９の分だけタイマアップのタイミングが早まることになり、以ってサイクルタイマ（Ａ）との位相ズレが補正されることになる。これによって、ノードＢは、自己のサイクルタイマ（Ｂ）を、マスタノードであるノードＡのサイクルタイマ（Ａ）と同期させることができる。尚、ノードＢは、その後は、サイクルタイマの設定時間をＴとして動作させる。
【００６７】
尚、図３の例では、ノードＢのサイクルタイマ（Ｂ）が、ノードＡのサイクルタイマ（Ａ）より遅れていたため、上述した減算処理により同期させたが、これに限定されるものではない。
【００６８】
例えば、ノードＢのサイクルタイマ（Ｂ）が、ノードＡのサイクルタイマ（Ａ）より進んでいた場合には、ノードＢは、ＳＥＴフレーム３６で通知された伝送遅延時間を自己のサイクルタイマ設定値に加算する。すなわち、「Ｔ＋伝送遅延時間」をサイクルタイマ（Ｂ）にセットしてサイクルタイマ（Ｂ）を起動する。これによって、自己のサイクルタイマ（Ｂ）を、マスタノードであるノードＡのサイクルタイマ（Ａ）と同期させることができる。
【００６９】
尚、上記サイクルタイマ設定値の減算／加算は、サイクルタイマの本来の設定値（周期Ｔ）に対する加算／減算であり、上記のように「Ｔ±伝送遅延時間」で表される。但し、これは補正の為の一時的な措置であり、その後は再び周期Ｔでサイクルタイマを動作させる。
【００７０】
このように、自己のサイクルタイマ（Ｂ）の調整を終えたノードＢは、システムへの加入が許可されたものとして、ＴＳ帯域でデータ送信可能とする。
【００７１】
＜システム運用中における同期ずれの検出方法及び修正方法＞
次に、システム運用中における同期ズレの検出方法及び修正方法について、具体的に説明する。これは、基本的に、各スレーブノード側で独自に行うことができる。
【００７２】
まず、各スレーブノード側では、上記図３で説明した、加入時にマスタノードＡから通知される上記伝送遅延時間を保持しておく。上記のことから、各スレーブノードでは、マスタノードと同期できている状態であれば、自己のサイクルタイマのカウント値が上記伝送遅延時間となったタイミングで上記ＴＣフレームを受信するはずである。つまり、スレーブノードは、マスタノードＡと同期できている状態であれば、マスタノードＡから送信される同期化フレームＴＣを、遅延時間分遅れて受信することになる。
【００７３】
上記のことから、例えば、各スレーブノードは、自己のサイクルタイマで同期化フレームＴＣの受信タイミングを測定して、同期ズレの有無やズレ量を検出する。つまり、ＴＣフレーム受信時のサイクルタイマのカウント値と、上記保持されている伝送遅延時間との差分を求める。差分が‘０’の場合は、正常（同期がとれている）と判定する。但し、この例に限らず、差分の絶対値が所定の閾値未満である場合も、正常（同期がとれている）と判定するようにしてもよい。
【００７４】
上記のことから、上記差分が‘０’ではない場合、あるいは上記差分の絶対値が上記閾値以上である、異常（同期ズレが生じている）と判定する。そして、異常と判定した場合には、上記差分を用いて、上記図３で説明した加入時と同様にして、自己のサイクルタイマの補正を行う。
【００７５】
尚、上記の例に限らず、例えば複数回連続して異常（同期ズレが生じている）と判定された場合に、上記自己のサイクルタイマの補正を行うようにしてもよい。また、この場合における補正量は、例えば上記複数回の上記差分の平均値を用いるようにしてもよいが、この例に限らない。
【００７６】
ここで、図５に、上述した先願のシステムのデータ送信動作を概略的に示す。
図３で示したように、先願のシステムでは、一定の周期時間Ｔを定め、この周期Ｔの通信サイクルを、図５に示すように、同期用の帯域であるＴＣ帯域と、コモンメモリのデータ交換用の帯域であるＴＳ帯域とに分割している。
【００７７】
ＴＣ帯域では、マスタノードから同期化フレーム４１が送信され、これに基づき各スレーブノードが自局のサイクルタイマを調整する。ＴＳ帯域中では、各ノードが、自局の送信タイミングでコモンメモリデータフレーム４２をブロードキャスト送信する。この送信タイミングは、上述した通り、各局毎に自局のサイクルタイマとセンドタイマに基づいて決定され、基本的には全ての局で相互に異なるタイミングと成るように設定されている。また、上記コモンメモリデータフレーム４２は、上述した自己の共有メモリにおける自ノード用の記憶領域の格納データを送信するデータフレームである。
【００７８】
このようにすることで、メッセージ型通信プロトコルで用いられるトークンを排除し、ネットワークの効率的運用を可能としている。
一方、本手法では、図６に示すように、上記周期Ｔの通信サイクルを、上記ＴＣ帯域と上記ＴＳ帯域と図示のＭＳＧ帯域とに分割している。ＭＳＧ帯域は、任意のノード間で１対１のメッセージ通信を行う為の帯域である。尚、ここでも、ノードＡがマスタノードであり、他のノードＢ，Ｃ等がスレーブノードであるものとする。また、ここでも、図示の矩形がデータフレームを示し、矩形内の文字がフレーム種別または送信元ノードを示すものとする。例えば、図示の「ｂ」は、ノードＢが送信元であるデータフレームを意味する。あるいは、例えば図示の「同期」が、上記同期化フレームを意味する。
【００７９】
ここで、ＭＳＧ帯域の長さは、任意に決めて構わないが、固定的とする必要がある。もし、ＭＳＧ帯域の長さを、例えばメッセージ数に応じて可変とした場合、それによって定周期Ｔを維持出来なくなってしまう。つまり、上記リアルタイム性を保証できなくなる。例えば、マスタがトークンを送信し、このトークンがシステムを巡回してマスタに戻ってくるまでを、ＭＳＧ帯域とする場合、メッセージ数が多ければその分ＭＳＧ帯域が長くなる。
【００８０】
この為、上記の通りＭＳＧ帯域の長さを固定的とする必要があるが、メッセージ送信要求は、突発的に生じる場合が多く、メッセージ数がゼロとなる場合もあれば、メッセージ数が多数となる場合もある。メッセージ数がゼロのときにはＭＳＧ帯域が無駄となることになる。特に、ＭＳＧ帯域の長さを長く設定すると、メッセージ数がゼロのときにはこのＭＳＧ帯域が無駄が大きいことになる。
【００８１】
何れにしても、周期Ｔは、ＴＣ帯域＋ＭＳ帯域＋ＭＳＧ帯域によって決まることになる。そして、ＴＣ帯域の長さは、例えば上記往復伝送遅延時間によって決まることになり、ＴＳ帯域の長さは、基本的にはシステム全体のコモンメモリデータ量によって決まることになる。そして、例えば周期Ｔの長さが一定に決まっているのであれば、ＭＳＧ帯域の長さも、これらＴＣ帯域とＴＳ帯域の長さに応じて固定的に決まることになる。但し、この例に限らず、ＭＳＧ帯域の長さを任意に決めてよく、これに応じて周期Ｔの長さが決まるようにしてもよい。
【００８２】
図６に示す例では、ＭＳＧ帯域の長さは、１つのメッセージだけを送信可能な程度の長さとしている。この例では、任意の通信サイクルにおいて複数のノードでメッセージ送信要求が発生した場合、そのなかで１つの局だけがメッセージを送信出来ることになる。この為、何れか１つの局だけがＭＳＧ帯域におけるメッセージ送信権を得るようにする必要がある。
【００８３】
本手法では、その為に、ＴＳ帯域における上記コモンメモリデータフレーム４２を利用する。すなわち、図６に示すように、スレーブノードは、メッセージ送信が必要な場合、自己のコモンメモリデータフレーム４２にメッセージ送信要求５１を含めてブロードキャスト送信する。スレーブノードは、例えばフレーム４２中にあるメッセージ送信要求の有無を示すフラグ（後述するCTRL66））を、セットすることで、マスタノードへメッセージ送信要求５１を出すことができる。図６の例では、ノードＢはメッセージ送信要求５１を出しているが、ノードＣはメッセージ送信要求５１を出していない。
【００８４】
尚、マスタノードＡは、自局でメッセージ送信要求が発生した場合には、メッセージ送信要求５１を出す必要はなく、自局もメッセージ送信を要求するノードの１つとして他の要求ノードと同様に扱うものとする。そして、自局内の処理によって自局にもメッセージ送信許可を与えることができる。図６の例では、マスタノードＡでは、自局のメッセージ送信要求は発生していないものとする。
【００８５】
例えば、この様にして、各スレーブノードは、マスタノードに対して、メッセージ送信要求５１を通知する。そして、これに対して、マスタノードは、許可／不許可を判定して、これをＭＳＧ帯域の初めに図示の許可フレーム５２によって各スレーブノードへ通知する。許可されたスレーブノードのみが、当該ＭＳＧ帯域中にメッセージの送信を行う。この例では、マスタノードはノードＢのメッセージ送信を許可すると判定して、これを許可フレーム５２によってノードＢへ通知する。これより、この通知を受けたノードＢが、ＭＳＧ帯域内で図示のメッセージ５３を送信することになる。
【００８６】
尚、マスタノードは、自局のみ許可する場合には、許可フレーム５２を送信することなく、ＭＳＧ帯域において所定のタイミングでメッセージ送信を行うようにしてもよい。
ここで、図７（ａ）に、本例のコモンメモリデータフレーム４２のデータ構成例を示す。
【００８７】
図示の例では、コモンメモリデータフレーム４２は、フレーム種別を示すＦＣ６１、フレームサイズを表すＳＩＺＥ６２、送信元局番、宛先局番を示すＳＡ６３，ＤＡ６４等と、F_NO６５、コントロールビット（ＣＴＲＬ）６６、ＤＡＴＡ６７、ＦＣＳ６８等から成る。
【００８８】
F_NO６５は、個別のフレームを識別し、フレーム抜け等の監視を行うためのフレーム番号である。ＤＡＴＡ６７が、他のノードと共有させる為に送信する自己のコモンメモリの自ノード用領域の格納データ（コモンメモリデータ）である。ＦＣＳ６８は、フレームデータ化けなどの異常をチェックするためのフレームチェックシーケンスコードである。
【００８９】
そして、上記コントロールビット（ＣＴＲＬ）６６が、上記メッセージ送信要求５１を示すフラグ情報である。コントロールビット（ＣＴＲＬ）６６は、メッセージ送信の要求の有／無を示す１bitのフラグなどでよい。スレーブノードは、メッセージ送信要求がある場合には、コントロールビット（ＣＴＲＬ）６６をＯＮしてコモンメモリデータフレーム４２を送信する。尚、ここに示すフレーム構成は一例であって、この例に限らず、これら以外の情報が付加されていても構わない。
【００９０】
また、図７（ｂ）に、上記許可フレーム５２のデータ構成例を示す。
図７（ｂ）の例では、許可フレーム５２は、フレーム種別を示すＦＣ７１、フレームサイズを表すＳＩＺＥ７２、送信元局番、宛先局番を示すＳＡ７３，ＤＡ７４等と、F_NO７５、ME_A７６、ＦＣＳ７７等から成る。F_NO７５、ＦＣＳ７７は、F_NO６５、ＦＣＳ６８と同様と見做してよく、ここでの説明は省略する。
【００９１】
そして、ME_A７６は、メッセージ送信許可局番であり、マスタノードがメッセージ送信許可したスレーブノードの識別情報（ここでは局番とする）である。
許可フレーム５２は、ブロードキャスト送信され、基本的には全てのスレーブノードが受信することになる。そして、各スレーブノードは、受信した許可フレーム５２の上記メッセージ送信許可局番（ME_A）７６が、自ノードの局番と一致するか否かをチェックし、一致した局のみがメッセージを送信することができる。但し、要求５１を出していないスレーブノードは、この様なチェックは行わなくてもよい。
【００９２】
図６の例では、メッセージ送信許可局番（ME_A）７６はノードＢの局番となっており、これより図６に示すようにノードＢがメッセージを任意の相手局へ送信することになる。
尚、メッセージ通信の場合、一般的に、メッセージを受信した局はＡＣＫ／ＮＡＣＫ等の応答を送信元へ返信する必要があるが、これはネットワークＬＳＩなどのハードウェアレベルで判断可能な処理であるので、上記メッセージ送信されたＭＳＧ帯域内に当該メッセージ受信後すぐに応答することも可能である。尚、上記ハードウェアレベルで判断可能な処理とは、例えば、自局番とメッセージフレームの宛先局番とが等しいか否かをチェックする処理や、FCSまでを受信した結果、フレームに異常がないか等をチェックする処理等である。 
【００９３】
但し、この例に限らず、例えば、次の通信サイクルにおいて例えばＣＴＲＬフィールドの別のビットを使用して応答することも可能である。尚、図７（ａ）に示すＣＴＲＬ６６は、例えば８ビットのフィールドであり、これをＣＴＲＬフィールドと呼ぶものとするが、上記の通りメッセージ送信の要求の有／無を示す１bitのデータがあれば済むので、残りの７bitは不使用となっている。上記CTRLフィールドの別のビットとは、この７bitのうちの任意の１bitまたは複数bitであり、これをＡＣＫ／ＮＡＣＫ等の応答用に割り当てておくものである。
【００９４】
また、上記許可されたノードは、基本的に、ＭＳＧ帯域内にメッセージ送信処理を完了するはずである。しかしながら、例えば、何等かの優先度が高い処理が発生していた為に、メッセージ送信処理開始が遅れることも想定し得る。この想定に対応して、例えば、任意のメッセージ送信許容時間を予め設定しておき、許可されたスレーブノードが許可フレーム５２受信時からメッセージ送信許容時間内にメッセージ送信できない場合は、当該スレーブノードにおいて送信を断念すると判定するようにしてもよい。このようにすることで、固定的な長さのメッセージ帯域内でメッセージに関する処理（送信または断念）を完了でき、ネットワークの同期を乱すことなく、コモンメモリデータ交換とメッセージ送信とを実現できる。
【００９５】
上記図６に示す例は、上記の通り、1周期に1つのメッセージのみ送信可能な例であるが、当然、この様な例に限らない。例えば図８等に示すように、任意の通信サイクルのＭＳＧ帯域内で複数のメッセージを送信可能としてもよい。尚、図６と図８との違いは、基本的に、ＭＳＧ帯域の長さである。つまり、図８は図６よりもＭＳＧ帯域が長い。
【００９６】
ここで、メッセージは、不特定局が非同期に要求を行うので、任意の通信サイクルにおいて複数局でメッセージ送信要求が発生することがある。図６の例の場合、マスタ局は、複数局からメッセージ送信要求５１があった場合には、何れか１つの局に対してのみ送信許可を与え、残りの局に対しては後の通信サイクルにおいて送信許可を与える。
【００９７】
図８の例でも、基本的にはこれと同様であってよい。すなわち、１周期内に送信可能なメッセージ数（最大送信許可数）をＭ個とすると、任意の通信サイクルにおけるメッセージ要求局数をＮ台とした場合、Ｎ≦Ｍである場合には、Ｎ台の局全てに対してその通信サイクル内での送信許可を与える。一方、Ｎ＞Ｍである場合には、要求局のなかで任意のＭ台に対してのみ、その通信サイクル内での送信許可を与え、残りの局については後の通信サイクルにおいて送信許可を与えるようにする。
【００９８】
尚、ＭＳＧ帯域を長くすることで、上記最大送信許可数Ｍを多くすることができるので、たとえ任意の通信サイクル内にシステムを構成する全局からメッセージ送信要求が発生しても、全局にその通信サイクル内での送信許可を与えることも可能となる。しかしながら、上記の通り、メッセージは、不特定局が非同期に要求を行うので、メッセージ送信要求局が１つもない通信サイクルもあり得る。この様な場合、その通信サイクルではＭＳＧ帯域中には何等データ送受信が行われないので、無駄となる。そして、上記のようにＭＳＧ帯域を長くしている場合には、この無駄が非常に大きいことになる。この為、ＭＳＧ帯域をあまり長くすると、実用上問題となる。
【００９９】
そして、図８の例では、例えば１周期内に、２つのメッセージを送信可能となっているものとする。そして、図示の例では、任意の１つの通信サイクル内のＴＳ帯域内に、ノードＢとノードＣの２台のノードが、それぞれ、メッセージ送信要求５１を出している。尚、マスタノードＡは、自身のメッセージ送信要求はないものとする。この場合、マスタノードＡは、ノードＢ，Ｃの両方とも許可するものと判定して、上記許可フレーム５２によって、これら２つのノードＢ．Ｃに対してメッセージ送信許可を通知することになる。
【０１００】
ここで、図９に、許可フレーム５２のデータ構成例（その２）を示す。これは、本例のように、１つの通信サイクル内で複数のメッセージ送信が許可され得る場合に応じたものである。
【０１０１】
尚、図９において、上記図７（ｂ）に示すデータ構成と同一のものには同一符号を付してあり、その説明は省略する。これより、図９のデータ構成が図７（ｂ）と異なる点は、メッセージ送信許可数（ME_NO）８１が追加されていると共に、メッセージ送信許可局番群８２を有する点である。尚、メッセージ送信許可局番群８２は、複数の上記メッセージ送信許可局番（ME_A）７６から成るものと見做してよい。
【０１０２】
図８の例の場合、メッセージ送信許可数（ME_NO）８１は‘２’となり、メッセージ送信許可局番群８２には、ノードＢとノードＣの局番が格納されることになる。これより、ＭＳＧ帯域でこの許可フレーム５２を受信したノードＢとノードＣは、それぞれ、自ノードがメッセージ送信許可されたものと見做して、同ＭＳＧ帯域中に自ノードのメッセージ送信処理を実行する。
【０１０３】
但し、ノードＢとノードＣとで、データ送信タイミングの重複（輻輳）が発生しないようにする必要がある。例えば図８に符号５３で示すタイミングで各々のメッセージ送信させる必要がある。これを実現する為に、例えば、メッセージ送信許可局番群８２における並び順に従って、許可フレーム受信時から所定の時間間隔で順番にメッセージ送信するようにする。この具体例は後述するが、このようにすれば、メッセージ通信が輻輳することはない。
【０１０４】
また、１つの局が一度に複数のメッセージ要求を出す場合もあり得る。
この様な場合に対応する為には、まず、上記図７（ａ）に示すコモンメモリデータフレーム４２のデータ構成において、上記コントロールビットＣＴＲＬ６６は、メッセージ送信の要求の有／無を示す１bitのデータとしたが、これを変更する。すなわち、コントロールビットＣＴＲＬ６６を、送信要求フレーム数を表す数値とする。よって、基本的には、１bitではなく、複数bitとする。この様にすることで、一つの局から複数のメッセージ送信要求を行うことができる。
【０１０５】
例えば、図１０の例では、任意の通信サイクルにおいて、ノードＢのみが上記メッセージ送信要求５１を出しているが、これは上記コントロールビットＣＴＲＬ６６を‘２’としているものであるものとする。尚、図１０では、図８と同様、１周期内に２つのメッセージ送信可能となっているものとする。つまり、最大送信許可数Ｍ＝‘２’となっているものとする。
【０１０６】
ここで、マスタノードＡは、任意の通信サイクルにおけるトータルのメッセージ要求数が、最大送信許可数Ｍ＝‘２’以下である場合には、
これより、上記のように要求局がノードＢのみであり且つメッセージ送信要求数が‘２’である例では、マスタノードＡは、トータルのメッセージ要求数が２となることから、全てのメッセージ送信要求を許可するものと判定する。そして、ノードＢに対して、当該通信サイクル内に上記２つのメッセージ送信を行うことを許可する旨を通知する。これは、例えば、図９に示す許可フレーム５２において、上記メッセージ送信許可数（ME_NO）８１を‘２’とすると共に、メッセージ送信許可局番群８２にノードＢの識別ＩＤ（ここでは「ｂ」と記すものとする）を２つ格納すればよい。つまり、図９に示すME_A_1とME_A_2の両方に「ｂ」が格納されていればよい。これによって、この許可フレーム５２を受信したノードＢは、自局が当該通信サイクル内に２つのメッセージ送信を許可されたものと判定できる。
【０１０７】
尚、図８、図１０の何れの例においても、マスタノードＡは、任意の通信サイクルにおいて上記最大送信許可数Ｍよりも多いメッセージ送信要求があった場合には、上記の通り、そのうちの一部のみにその通信サイクルにおける送信許可を与えるが、残りについては一旦これを保留する。そして、それ以降の通信サイクルにおいて、保留した局について優先的に送信許可を与える。そして、保留した局全てについて送信許可を与えた後で、改めて各局から通知されるメッセージ送信要求を取り込むようにし、メッセージ送信機会が均等に与えられるようにする。
【０１０８】
以下、図１１以降の図面を参照して、本手法について更に詳細に説明する。
本手法では、上記の通り、一定周期Ｔの通信サイクル毎に、コモンメモリのデータ交換を行うことを、基本動作としている。そして、当該コモンメモリデータ交換に係わる上記リアルタイム性を保証しつつ、メッセージ送信も行えるようにしている。つまり、本手法の通信プロトコルは、所定の周期Ｔで処理が一巡する定周期型のプロトコルであって、コモンメモリデータ交換だけでなくメッセージ送信も行えるようにしているものと言える。
【０１０９】
そして、図１１に示すように、周期Ｔの通信サイクルは、上記同期タイミング生成の為のＴＣ帯域と、コモンメモリデータ交換の為のＴＳ帯域と、メッセージ通信の為のＭＳＧ帯域とに分割される。
【０１１０】
図１１は、本手法における各ノードのタイマ動作とそれに応じたデータ送信タイミングの一例を示す図である。
ここで、図１１に示すシステム全体の動作例では、システムは、マスタノードＡと、３台のスレーブノードＢ、Ｃ，Ｄを有するものとする。そして、既に説明したように、周期Ｔは、各ノードがそれぞれ有するサイクルタイマによって規定される。ここでは全てのスレーブノードのサイクルタイマが、既にマスタノードＡのサイクルタイマと同期している状態であるものとする。よって、図１１では、１つのサイクルタイマの動作のみを示すが、これは全てのノードのサイクルタイマの動作を示すものと見做してよい。
【０１１１】
尚、既に説明した通り、マスタノードＡは、ＴＣ帯域において上記同期化フレーム４１をブロードキャスト送信し、この同期化フレーム４１に基づいて各スレーブノードのサイクルタイマの同期化が行われることになる。尚、全ノードにおいて、自己のサイクルタイマがタイマアップする毎に直ちにクリア（再起動）する。
【０１１２】
また、本例では、マスタノードＡと各スレーブノードは、上記サイクルタイマに加えてセンドタイマも備えている。センドタイマは、基本的に、ＴＳ帯域における自局のコモンメモリデータ送信タイミングを生成するタイマである。但し、本手法では、更に、マスタノードにおいては上記許可フレーム５２の送信タイミングも生成する。また、各スレーブノードにおいては、自己のメッセージ送信タイミングも生成する。但し、メッセージ送信タイミング生成の為にセンドタイマに設定する時間は、固定的ではなく動的に決定されるものであり、例えば上記メッセージ送信許可局番群（ME_A）８２の格納内容（自局の順番）に基づいて決定されるものである。詳しくは後述する。
【０１１３】
全てのノードにおいて、自己のサイクルタイマをクリアするタイミングで、自己のセンドタイマもクリアするが、その際にセンドタイマに設定する時間は、予め登録されている固定値であり且つ各ノードで相互に異なる値となっている。これより、図１１に示すように、全てのノードで相互に異なるタイミングでセンドタイマがタイマアップすることになる。
【０１１４】
マスタノードは、自局のサイクルタイマのクリア（起動）の際に、自局のコモンメモリデータの送信タイミングを示す設定時間をセンドタイマにセットして起動する。この設定時間（第１設定時間）は、予め登録されている固定値であり、図示の例ではＴＣ帯域の長さと同じであり、従って図示のようにＴＳ帯域の始まりのタイミングでセンドタイマはタイマアップする。そして、タイマアップしたら、上記の通り、コモンメモリデータフレーム４２をブロードキャスト送信する。尚、この例は、マスタノードのコモンメモリデータの送信タイミングを、ＴＳ帯域の最初としている場合に応じてものであり、この例に限るものではない。
【０１１５】
また、マスタノードは、上記センドタイマがタイマアップしたら直ちにセンドタイマに第２設定時間をセットして再起動する。この第２設定時間は、予め登録されている固定値であり、例えばＴＳ帯域の長さとする。そして、センドタイマがタイマアップしたら、上記許可フレーム５２をブロードキャスト送信する。
【０１１６】
一方、各スレーブノードにおいても、自局のサイクルタイマのクリア（起動）の際に、自局のコモンメモリデータの送信タイミングを示す設定時間を自局のセンドタイマにセットして起動する。この設定時間（コモンメモリ設定時間と呼ぶものとする）は、予め登録されている固定値であり、更に、少なくとも上記第１設定時間より大きく且つ「第１設定時間＋第２設定時間」よりも小さい値とする。換言すれば、ＴＳ帯域内にタイマアップするように設定されている。更に、このコモンメモリ設定時間は、全てのスレーブノードで相互に異なる値となるように設定されている。更に、コモンメモリ設定時間は、上記第１設定時間とは異なるように設定されている。
【０１１７】
これより、図１１に示すように、各ノードのセンドタイマは、ＴＳ帯域内に相互に異なるタイミングでタイマアップすることになる。
そして、各スレーブノードも、各々、自己のセンドタイマのタイマアップにより、コモンメモリデータをブロードキャスト送信する。その際、メッセージ送信要求が発生していた場合には、上記メッセージ送信要求５１を含めて送信する。図１１の例では、スレーブノードＢ，Ｄで、メッセージ送信要求が発生しているものとする。
【０１１８】
メッセージ送信要求が無いスレーブノードＣは、その通信サイクル内ではセンドタイマを再起動しない。
一方、上記メッセージ送信要求５１を送信したスレーブノードＢ．Ｄは、許可された場合には、その通信サイクル内で所定のタイミングで自己のセンドタイマを再設定・再起動する。所定のタイミングとは、上記許可フレーム５２受信時等である。また、再設定する値は、上記コモンメモリ設定時間とは異なる。再設定する値は、許可フレーム５２の内容に基づいて決定する。
【０１１９】
すなわち、許可フレーム５２受信したスレーブノードは、その上記メッセージ送信許可局番群（ME_A）８２を参照することで、当該通信サイクル内でのメッセージ送信が許可されたか否かと、許可された場合にはその順番（メッセージ送信許可位置）を知ることができる。本例では最大２つまで許可されるので、メッセージ送信許可位置は‘１’と‘２’の何れかとなる。図９の例では、“ME_A_1”に自局の局番があればメッセージ送信許可位置は‘１’であるものと判定し、“ME_A_2”に自局の局番があればメッセージ送信許可位置は‘２’であると判定する。
【０１２０】
これより、マスタ局からメッセージ送信許可が与えられたスレーブ局は、「メッセージ送信許可位置×メッセージ送信許容時間」を求めて、この算出値に基づいてセンドタイマを再設定して再起動する。そして、センドタイマがタイマアップしたタイミングで、メッセージの送信を行う。
【０１２１】
メッセージ送信許容時間は、予め任意に設定されており、例えば図示のスレーブノードＢのセンドタイマ再起動からタイマアップまでの長さ“α”に相当する。図示の例では、メッセージ送信許可位置は、ノードＢが‘１’、ノードＤが‘２’となっているものとする。これより、ノードＤのセンドタイマの再設定値は、ノードＢのセンドタイマの再設定値の約２倍となり、図示のように、ノードＢとノードＤとは相互に異なるタイミングで自己のメッセージ送信を行うことになる。
【０１２２】
尚、図１１では、図示表現上、ＭＳＧ帯域開始時点でセンドタイマを再起動しているように見えるかもしれないが、これは伝送遅延無しで許可フレーム５２を受信したと仮定した場合のイメージを示しているだけであり、実際には多少は伝送遅延が生じているはずである。よって、実際には、ＭＳＧ帯域開始時点から多少時間が経過した時点で、センドタイマの再設定・再起動が行われることになる。
【０１２３】
また、この場合、センドタイマの再設定値を、例えばノードＢに関して図示の長さαとすると、タイマアップのタイミングは、実際には図示のタイミングよりも遅れることになる。これは、上記伝送遅延の分だけ遅れることになる。よって、この点を考慮してセンドタイマの再設定値を決定するようにしてもよい。つまり、上記例では上記メッセージ送信許容時間＝αと見做してよいので、例えば「メッセージ送信許可位置×メッセージ送信許容時間」から伝送遅延時間を差し引いた値を、センドタイマに再設定するようにしてもよい。例えばこの様にして適宜調整することで、自己のメッセージ送信許可位置に応じた所定のタイミングで、メッセージ送信することができる。尚、上記の通り、各スレーブノード毎の伝送遅延時間は既に分かっている。
【０１２４】
尚、タイマによる処理は、マイコン等が持つ割込み機能により起動される。基本的にタイマ割込みによる処理は、自局からの送信フレーム(同期化フレーム、コモンメモリデータ、許可フレーム、メッセージ等)の送信タイミングを生成しており、これら送信するデータは、これらの処理とは非同期に準備される。例えば、メッセージは、上位のアプリケーションが送信要求を行ったタイミングで生成される。
【０１２５】
尚、上記一例では、センドタイマを再設定して利用する例を示したが、この例に限らず、メッセージ送信タイミング生成用のタイマ（３つ目のタイマ）を設けるようにしてもよい。あるいは、その逆に、特にマスタノードにおいては、センドタイマを更に再設定することでＭＳＧ帯域終了タイミングも生成させることで、図１１に示すＴＣ帯域、ＴＳ帯域の終了タイミング生成と組み合わせて周期Ｔを規定できるようにすることもできる。つまり、この場合、サイクルタイマは不要とすることができ、タイマ数を削減できることになる。
【０１２６】
以下、図１２〜図１５のフローチャート図を参照して、マスタノード、スレーブノードの処理動作例について説明する。図１２〜図１４は、マスタノードの処理フローチャート図である。
【０１２７】
マスタノードの処理は、例えば、送信タイマ処理、受信処理、許可フレーム生成処理等である。図１２は送信タイマ処理、図１３は受信処理、図１４は許可フレーム生成処理のフローチャート図である。
【０１２８】
まず、図１２を参照して、マスタノードにおける送信タイマ処理について説明する。
図１２の処理は、タイマ割込み発生毎に実行される。タイマ割込みは、サイクルタイマまたはセンドタイマがタイマアップする毎に発生する。尚、サイクルタイマとセンドタイマのどちらがタイマアップしたものであるのかは、区別できるようになっている。また、例えば、センドタイマの設定時間（設定の種別）が、設定時に記録されるようになっていてもよい。
【０１２９】
そして、まず、発生したタイマ割込みが、サイクルタイマのタイマアップによるタイマ割込みである場合には、同期化フレーム送信タイミングであるものと判定して（ステップＳ１１，ＹＥＳ）、同期化フレームをブロードキャスト送信すると共に（ステップＳ１２）、センドタイマに上記第１設定時間を設定して起動する（ステップＳ１３）。更に、サイクルタイマを再起動して（ステップＳ１４）、本処理を終了する。
【０１３０】
また、発生したタイマ割込みが、上記第１設定時間が設定されたセンドタイマのタイマアップによるものである場合には、コモンメモリデータ送信タイミングであると判定して（ステップＳ１５，ＹＥＳ）、自局のコモンメモリデータをブロードキャスト送信する（ステップＳ１６）。そして、センドタイマに上記第２設定時間を設定して再起動して（ステップＳ１７）、本処理を終了する。
【０１３１】
また、発生したタイマ割込みが、上記第２設定時間が設定されたセンドタイマのタイマアップによるものである場合には、許可フレーム送信タイミングであると判定して（ステップＳ１８，ＹＥＳ）、許可フレーム５２をブロードキャスト送信する（ステップＳ１９）。尚、許可フレーム５２の生成処理は、図１４に示し後に説明する。
【０１３２】
更に、マスタノード自身にメッセージ送信要求が生じる場合もあり得るので、図１４の処理によって送信許可したノードとして自ノードがある場合には（ステップＳ２０、ＹＥＳ）、センドタイマを再々設定して再々起動する（ステップＳ２１）。このときの設定時間は、例えば上記「メッセージ送信許可位置×メッセージ送信許容時間」によって求めるが、この例に限らない。そして、本処理を終了する。
【０１３３】
また、発生したタイマ割込みが、上記ステップＳ２１で再々起動されたセンドタイマのタイマアップによるものである場合には、自己のメッセージ送信タイミングであるものと判定して（ステップＳ１８，ＮＯ）、メッセージ送信処理を行い（ステップＳ２２）、本処理を終了する。
【０１３４】
上述したように、送信タイマ処理では、割込みの要因等に基づいて次回タイマ割込み時の動作が決められる。マスタ局もメッセージを送信することがあるため、自局に送信許可を与える場合は、さらにセンドタイマを使用して自局のメッセージ送信タイミングを生成する。
【０１３５】
図１３は、ＴＳ帯域における受信処理のフローチャート図である。
上記の通り、ＴＳ帯域においては、各ノードは、自局のコモンメモリデータをブロードキャスト送信する。よって、マスタノードＡは、ＴＳ帯域中に各ノードから送信されるコモンメモリデータを順次受信することになる。図１３の処理は、この様なコモンメモリデータ受信毎に実行されるものである。つまり、何等かのデータ受信毎に受信割込みが発生し、それによって図１３の処理が開始される。
【０１３６】
尚、コモンメモリデータ受信時には、自己のコモンメモリの該当領域に受信データを上書きする処理等も行うが、ここでは直接関係ない処理であるので、その説明は省略するものとする。これは、コモンメモリデータ受信以外のデータ受信時に関しても同様である。
【０１３７】
図１３の処理では、まず、受信したデータがコモンメモリデータであるか否かを判定し（ステップＳ３１）、コモンメモリデータ以外のデータ（例えば同期化フレーム等）受信である場合には（ステップＳ３１，ＮＯ）、本処理を終了する。尚、上記の通り、省略しているだけであり、実際には同期化フレーム受信に応じた所定の処理が実行されることになる。
【０１３８】
コモンメモリデータ受信である場合には（ステップＳ３１，ＹＥＳ）、その上記コントロールビット（ＣＴＲＬ）６６を参照することで、メッセージ送信要求があるか否かを判別する（ステップＳ３２）。そして、メッセージ送信要求が無ければ（ステップＳ３２，ＮＯ）本処理を終了する。
【０１３９】
一方、メッセージ送信要求がある場合には（ステップＳ３２，ＹＥＳ）、前回の通信サイクルにおいて許可しなかったメッセージ送信要求は無いのであれば（ステップＳ３３，ＹＥＳ）、受信した要求をバッファに登録する（ステップＳ３４）。登録するデータは、要求元のノードの識別ＩＤや要求されたメッセージ数等である。
【０１４０】
尚、バッファに登録された要求の数が、後述する図１４における送信可能数を超える場合には、その一部はバッファに残った状態のまま（そして後述する送信残フラグがＯＮの状態で）、次回の通信サイクルに移行することになる。上記ステップＳ３３の処理は、例えばこの送信残フラグがＯＮの場合にＮＯと判定するものであるが、この例に限らない。
【０１４１】
尚、前回の通信サイクルで許可しなかったメッセージ送信要求がバッファに残っている場合には（ステップＳ３３，ＮＯ）、図示していないが例えば今回の通信サイクルで受信したメッセージ送信要求は、別領域に記憶して、本処理を終了する。
【０１４２】
尚、例えばＴＳ帯域開始直後に、上記別領域に１以上の要求が記憶されているか否かをチェックし、記憶されている場合には、当該記憶されている要求全てを上記バッファに転送して格納すると共に後述する送信残フラグをＯＮするようにしてもよい。これによって、前回の通信サイクルの際に受け付けられなかった要求を、優先的に許可させるようにすることができる。
【０１４３】
そして、例えばＴＳ帯域の最後の空き時間に（全てのノードからのコモンメモリデータ受信処理が完了した後に）、あるいは上記ステップＳ１９の処理の際に、上記バッファの格納データ等に基づいて、例えば図１４に示す許可フレーム生成処理を実行する。
【０１４４】
図１４に示す例では、まず、メッセージ送信要求の有無を確認する（ステップＳ４１）。これは、例えば上記バッファにデータがあればメッセージ送信要求ありと判定して（ステップＳ４１，ＹＥＳ）、ステップＳ４２へ移行する。尚、メッセージ送信要求無しと判定した場合には（ステップＳ４１，ＮＯ）、本処理を終了する。
【０１４５】
ステップＳ４２では、上記バッファに格納されている要求の数が、予め設定されている送信可能数を超えているか否かを判定する。尚、送信可能数は、１つの周期（そのＭＳＧ帯域）で送信出来るメッセージの数であり、本例では上記の通り‘２’となることになる。
【０１４６】
もし、上記バッファの要求数が、上記送信可能数を超えている場合には（要求数＞送信可能数）（ステップＳ４２，ＹＥＳ）、送信残フラグをＯＮして（ステップＳ４３）、変数“ループ最大”に上記送信可能数をセットする（ステップＳ４４）。一方、上記バッファの要求数が、上記送信可能数以下である場合には（ステップＳ４２，ＮＯ）、送信残フラグをＯＦＦしたうえで（ステップＳ４５）、変数“ループ最大”に上記要求数をセットする（ステップＳ４６）。尚、送信残フラグは、上記の通りステップＳ３３の判定の際に利用される。
【０１４７】
そして、上記ステップＳ４２の判定がＹＥＳ／ＮＯの何れであっても、上記変数“ループ最大”の数の分だけ、ステップＳ４７の処理を繰り替して、本処理を終了する。
ステップＳ４７の処理は、許可フレーム生成処理であり、上記バッファから任意の１つのメッセージ送信要求を取り出して、例えばこの要求に含まれる局番（要求元ノードの識別情報）を、許可フレーム５２の上記メッセージ送信許可局番（ME_A）７６または上記メッセージ送信許可局番群８２に格納する処理である。尚、取り出された要求は、バッファから消去される。
【０１４８】
また、上記ステップＳ４７のループ処理が完了したら、最後に、上記変数“ループ最大”の数を、上記メッセージ送信許可数（ME_NO）８１に格納する。
上記のように生成した許可フレーム５２は、例えば、ＭＳＧ帯域の開始直後等に送信されることになる。
【０１４９】
尚、「要求数＞送信可能数」である場合に、バッファに格納されている複数の要求のなかでどの要求に対して許可を与えるのかについては、その決定方法は特に限定しない。例えば一例としては、各要求の要求元の局番に基づいて、局番が小さい順、あるいは局番が大きい順に、許可を与えるようにしてもよい。あるいは、バッファへの格納順により許可を与えるようにしてもよい。つまり、最も最初にバッファに格納された要求から順に、許可を与えるようにしてもよい。
【０１５０】
以上、マスタノードの処理動作について説明した。
以下、各スレーブノードの処理動作について、図１５、図１６を参照して説明する。
図１５は、スレーブノードにおける送信タイマ処理の処理フローチャート図である。
【０１５１】
尚、ここではサイクルタイマは調整済み（マスタと同期している）の状態であるものとする。
尚、図１５の処理は、基本的には、上記図１２の処理と同様、サイクルタイマまたはセンドタイマがタイマアップする毎に発生するタイマ割込みに応じて実行開始される。但し、例外として、許可フレーム５２を受信した場合にも、図１５の処理が実行される。
【０１５２】
そして、まず、発生したタイマ割込みが、サイクルタイマのタイマアップによるタイマ割込みである場合に（ステップＳ５１，ＹＥＳ）、センドタイマに上記“コモンメモリ設定時間”をセットしてセンドタイマを起動する（ステップＳ５２）。更に、サイクルタイマを再起動する（ステップＳ５３）。そして、本処理を終了する。
【０１５３】
また、発生したタイマ割込みが、上記ステップＳ５２で起動されたセンドタイマのタイマアップによるものである場合には、コモンメモリデータ送信タイミングであると判定して（ステップＳ５４，ＹＥＳ）、自局のコモンメモリデータをブロードキャスト送信する（ステップＳ５５）。尚、その際、メッセージ送信要求がある場合には、上記メッセージ送信要求５１を含めて送信する。そして、本処理を終了する。
【０１５４】
また、許可フレーム５２を受信した場合には（ステップＳ５６，ＹＥＳ）、その上記メッセージ送信許可局番（ME_A）７６または上記メッセージ送信許可局番群８２を参照することで、自局がメッセージ送信許可されたか否かを判定する（ステップＳ５７）。そして、自局がメッセージ送信許可された場合には（ステップＳ５７，ＹＥＳ）、センドタイマを再設定して再起動する（ステップＳ５８）。このときの設定時間は、例えば上記「メッセージ送信許可位置×メッセージ送信許容時間」によって求めるが、この例に限らない。そして、本処理を終了する。
【０１５５】
尚、許可フレーム５２を受信した場合でも、上記メッセージ送信要求５１を送信していなかった場合には、何も処理を行わないようにしてもよい。
そして、発生したタイマ割込みが、上記ステップＳ５８で再起動したセンドタイマがタイマアップしたものである場合には、メッセージ送信タイミングであるものと判定して（ステップＳ５６，ＮＯ）、メッセージ送信処理を行い（ステップＳ５９）、本処理を終了する。
【０１５６】
図１６は、スレーブノードにおけるメッセージ送信要求に係わる状態遷移図である。
各ノードは、メッセージ送信要求に係わり、図１６に示す「送信要求なし」９１、「送信要求あり」９２、「送信要求中」９３、「送信待ち」９４、「応答待ち」９５の５つの状態を持つ。これらの状態は、メッセージ送信要求の有無、コモンメモリフレームの送信、許可フレームの受信、メッセージの送信などのイベントにより遷移する。ここでは、「送信要求なし」９１の状態から、状態遷移について説明する。
【０１５７】
まず、そのノード内部で何等かのメッセージ送信イベントが発生した場合、「送信要求なし」９１から「送信要求あり」９２の状態へ遷移する。そして、「送信要求あり」９２の状態でコモンメモリデータ送信タイミングとなったら、コモンメモリデータフレーム４２にメッセージ送信要求５１を含めてブロードキャスト送信する。そして、これに伴って「送信要求あり」９２から「送信要求中」９３の状態へと遷移する。
【０１５８】
そして、「送信要求中」９３の状態で、許可フレーム５２を受信し、且つ、自局が送信許可されていた場合には、上記センドタイマの再起動を行う等して、「送信待ち」９４の状態へと遷移する。そして、「送信待ち」９４で、上記センドタイマがタイマアップしたら、メッセージを送信して、「応答待ち」９５の状態へと遷移する。
【０１５９】
「応答待ち」９５の状態は、メッセージ送信相手局からのACK／NACK応答待ち状態である。そして、ＡＣＫを受信した場合には、今回のメッセージ送信処理は正常に完了したものとして、「送信要求なし」９１の状態へ遷移する。
【０１６０】
また、応答がNACKの場合、または応対が無いままタイムアウトした場合には、リトライ処理を実行する。これは、メッセージ送信相手局の処理負荷を勘案し、応答受信から一定時間後に同一メッセージを再送する。この時、リトライカウンタをアップする。そして、「送信要求中」９３の状態へと遷移する。
【０１６１】
尚、リトライによって「送信要求中」９３となった場合には、例えばリトライ有りを記録しておく。そして、例えばＴＳ帯域において、メッセージ送信処理の有無だけでなくリトライの有無もチェックし、リトライ有りが記憶されている場合にも、コモンメモリデータフレーム４２にメッセージ送信要求５１を含めてブロードキャスト送信するようにしてもよい。尚、この場合、必ずしも上記に同一メッセージの再送が行えるわけではなく、許可されなかった場合には、その通信サイクルでは同一メッセージの再送は行わない。そして、次の通信サイクルで再びメッセージ送信要求５１を出すことになる。
【０１６２】
その後も、上記「応答待ち」９５の状態でNACK応答受信またはタイムアウトすると、上記処理を行ってリトライカウンタをアップするが、その際、リトライカウンタが一定数に達したか否かをチェックする。もし、リトライカウンタが一定数以上となったら、メッセージ送信をあきらめて異常終結（リトライオーバ）する。そして、「送信要求なし」９１の状態へと遷移する。
【０１６３】
尚、リトライカウンタは、ACK受信による正常完了またはリトライオーバにてリセットされる。
尚、上記ACK／NACK応答は、例えば相手局からのコモンメモリフレーム上の情報として通知されるように構成してもよい。また、もし、自局宛のACK／NACK応答がない場合は、例えば３周期分までコモンメモリフレームを受信する毎に自局宛のACK／NACK応答の有無をチェックし、それでも応答がない場合にメッセージ送信に失敗したとみなし、つまり上記タイムアウトと見做して、同一メッセージを再送するようにしてもよい。
【０１６４】
尚、図示の処理中に新たな要求が発生した場合は、この要求はキューイングされる。
図１７は、本例のネットワーク伝送システム１０の機能ブロック図である。
本例のネットワーク伝送システム１０は、各々が共有メモリを有する複数のノードから成り、各ノードが、所定の通信サイクルでネットワークを介して上記共有メモリのデータを相互に送受信するシステムであって、上記複数のノードのうち１台をマスタノード１１０とし、他をスレーブノード１２０とする。
【０１６５】
また、上記通信サイクル内に、上記各ノードが自ノードの共有メモリデータを相互に異なるタイミングで送信する帯域であるコモンメモリ帯域と、メッセージ帯域とが含まれるように構成する。
【０１６６】
そして、上記スレーブノード１２０は、メッセージ送信要求部１２１、メッセージ送信処理部１２２等を有する。
メッセージ送信要求部１２１は、上記自ノードの共有メモリデータ送信時に、任意の他のノードへのメッセージがある場合には、メッセージ送信要求を付加して送信する。
【０１６７】
メッセージ送信処理部１２２は、該メッセージ送信要求に対して、上記マスタノード１１０から許可通知があった場合には、上記メッセージ帯域において上記メッセージの送信処理を行う。
【０１６８】
また、上記マスタノード１１０は、許可決定部１１１、許可通知部１１２等を有する。
許可決定部１１１は、上記メッセージ送信要求に応じて、該要求を許可するか否かを決定する。
【０１６９】
許可通知部１１２は、該要求を許可するノードに対して例えば上記メッセージ帯域の初めに上記許可通知を送信する。
ここで、例えば、上記許可決定部１１１は、上記メッセージ帯域の長さに応じて予め設定されている最大数に基づいて、上記メッセージ送信要求を行ったノードのなかで許可するノードを決定する。これは、例えば、許可するノードの数を最大数までとする。あるいは、許可するメッセージ数を最大数までとする。これは、例えば、メッセージ送信要求を行ったノードの数が１つであり、且つ、該ノードが複数のメッセージの送信を要求した場合に、最大数までメッセージ送信を許可する。
【０１７０】
上記許可決定部１１１は、例えば、上記メッセージ送信要求のなかに許可しなかった送信要求がある場合には、該送信要求を未許可要求として保留しておき、次の通信サイクルにおいて該未許可要求を優先的に許可する。
【０１７１】
また、例えば、上記メッセージ送信処理部１２２は、上記メッセージ帯域において、上記許可通知に基づいて決定される所定のタイミングで、上記メッセージの送信処理を行う。これは、例えば、上記許可通知に基づいて自ノードの順番を認識して、該順番に予め設定される所定値を乗じることで、上記所定のタイミングを決定する。これは例えば上記「メッセージ送信許可位置×メッセージ送信許容時間」によって求めるが、この例に限らない。
【０１７２】
また、上記マスタノード１１０の上記許可決定部１１１は、自ノードに任意の他のノードへのメッセージがある場合には、自ノードも含めて上記要求を許可するノードを決定する。
【０１７３】
あるいは、マスタノード１１０は、上記コモンメモリ帯域内に各スレーブノードから相互に異なるタイミングで送信されてくる共有メモリデータを受信すると、該共有メモリデータにメッセージ送信要求が含まれているか否かを確認することで、その通信サイクルにおいてメッセージ送信を要求するスレーブノードを判別するメッセージ送信要求ノード判別部１１３を更に有するものと見做しても良い。
【０１７４】
図１８は、本例のノードの概略ハードウェア構成図である。
尚、ここでは、各ノードのハードウェア構成のうちの一部のみを示すものとする。つまり、上述したデータ送受信動作に関係する構成のみを示すものとする。
【０１７５】
図示の構成例では、ノード装置１１は、プロセッサ２００、メモリ２１０等を有する。
プロセッサ２００は、例えばＣＰＵ／ＭＰＵ等の演算プロセッサ等である。
メモリ２１０には、予め所定のアプリケーションプログラム２１１が記憶されている。また、図示の例では、メモリ２１０の記憶領域の一部を、共有メモリ２１２として使用しているが、この例に限らない。
【０１７６】
プロセッサ２００は、アプリケーション実行エンジン２０１、ネットワーク制御部２０２等を有する。アプリケーション実行エンジン２０１は、例えば上記メモリ２１０に記憶されているアプリケーションプログラム２１１を実行することで、例えば上記図１２〜図１４に示す処理、あるいは上記図１５、図１６に示す処理、図１７に示す各種機能部の処理等を実行する。但し、これらの処理におけるネットワークを介したデータ送受信制御は、ネットワーク制御部２０２が実行する。
【０１７７】
また、ここでは図示していないが、プロセッサ２００は、上記サイクルタイマやセンドタイマ等を備えている。アプリケーション実行エンジン２０１が、これら各種タイマを制御しながら、所定のタイミングで上記ネットワーク制御部２０２を介してデータ送信することになる。また、ネットワーク制御部２０２は、例えば受信したデータがコモンメモリデータである場合には、これを上記共有メモリ２１２の該当領域に上書き記憶する。
【０１７８】
また、上記アプリケーションプログラム２１１には、例えば不図示の制御対象の制御用のプログラムも含まれていても良い。プロセッサ２００は、この様な制御プログラムを実行中、必要に応じて、共有メモリ２１２における自ノード用の記憶領域のデータを更新する。
【０１７９】
尚、メモリ２１０は、例えばＤＤＲ−ＳＤＲＡＭ（Double-Data-Rate Synchronous Dynamic Random Access Memory）であるが、この例に限らない。
本手法によれば、特に上記共有メモリを有する複数のノード間で定周期でコモンメモリデータ交換する通信を行う必要があるシステムにおいて、上記リアルタイム性を保証しつつ更にメッセージ通信も行うことができる。
【０１８０】
すなわち、例えば上記先願（WO 2013121568 A1）のような時分割型のコモンメモリデータ交換手法は、上述したように、予め決められた構造を持つデータの更新を定期的に行うことに向いており、例えば各局において突発的に発生する特定相手局向けのデータ(メッセージ)を扱うことが難しい。また、メッセージ通信に関して局間での送信競合・データの衝突を防ぐため、トークン方式を利用した場合、上述したように、トークン巡回時間が伸び縮みしてしまうため、時間確定的に通信を行いたいコモンメモリ交換プロトコルと相いれない。つまり、コモンメモリデータ交換に係わる上記リアルタイム性を保証できなくなる可能性がある。換言すれば、定周期のコモンメモリデータ交換を維持できなくなる可能性がある。
【０１８１】
これに対して、上述した本手法によれば、上記先願の同期ネットワーク上のコモンメモリデータ交換に係わるリアルタイム性の保証を維持しつつ、メッセージ通信機能を付加することが可能となり、高速・大容量のコモンメモリデータ交換とメッセージ通信を同期ネットワーク上で実現することができる。更に、動的に変化するメッセージ通信要求元、要求数に対応して最適な送信権割付けを行うことが可能となる。
【０１８２】
その為に、本手法では、上述したように、一定の周期Ｔを分割してコモンメモリデータ交換帯域であるＴＳ帯域とメッセージ帯域を設ける。そして、ＴＳ帯域で送信されるフレーム上にメッセージ送信要求を示すデータを付加することで、マスタ局に対して送信権を要求する。マスタ局は、自局も含めて要求のあったノードのなかから決められたルールに従ってメッセージ帯域における送信権を与える。
【０１８３】
但し、上記リアルタイム性を保証するために、メッセージ帯域の長さは固定的とし、以って各周期Ｔ内でメッセージ帯域中に送信可能なメッセージ数が決められている。つまり、上限が決まっている。この上限を超えないようにして、上記送信権を与える。送信権を与えられなかったノードに関しては、次回以降の通信サイクルにおいて送信権を与える。
【０１８４】
上記上限は、１または複数であってよい。複数である場合には、一度に複数のノードに対して上記送信権を与えてもよい。あるいは、上限が複数である場合であって、複数のメッセージの送信要求するノードがあった場合に、このノードに複数のメッセージの送信権を与えるようにしてもよい。
【符号の説明】
【０１８５】
１０  ネットワーク伝送システム
１１（１１−１〜１１−３）  ノード装置
１２（１２−１〜１２−５）  ＨＵＢ
２１  同期化フレーム
２３  （ノードＡの）送信データ
２４  （ノードＣの）送信データ
２５  （ノードＢの）送信データ
２６  遅延
３３  ｒｅｑフレーム
３４  ＯＫフレーム
３５  ｄｌｙフレーム
３６  ＳＥＴフレーム
４１  同期化フレーム
４２  コモンメモリデータフレーム
５１  メッセージ送信要求
５２  許可フレーム
５３  メッセージ
６１  フレーム種別（ＦＣ）
６２  フレームサイズ（ＳＩＺＥ）
６３  送信元局番（ＳＡ）
６４  宛先局番（ＤＡ）
６５  フレーム番号（F_NO）
６６  コントロールビット（ＣＴＲＬ）
６７  コモンメモリデータ（ＤＡＴＡ）
６８  フレームチェックシーケンスコード（ＦＣＳ）
７１  フレーム種別（ＦＣ）
７２  フレームサイズ（ＳＩＺＥ）
７３  送信元局番（ＳＡ）
７４  宛先局番（ＤＡ）
７５  フレーム番号（F_NO）
７６  メッセージ送信許可局番（ME_A）
７７  フレームチェックシーケンスコード（ＦＣＳ）
８１  メッセージ送信許可数（ME_NO）
８２  メッセージ送信許可局番群
９１  「送信要求なし」
９２  「送信要求あり」
９３  「送信要求中」
９４  「送信待ち」
９５  「応答待ち」
１１０  マスタノード
１１１  許可決定部
１１２  許可通知部
１１３  メッセージ送信要求ノード判別部
１２０  スレーブノード
１２１  メッセージ送信要求部
１２２  メッセージ送信処理部
２００  プロセッサ
２０１  アプリケーション実行エンジン
２０２  ネットワーク制御部
２１０  メモリ
２１１  アプリケーションプログラム
２１２  共有メモリ
【図１】
0006265058.tif 000002
【図２】
0006265058.tif 000003
【図３】
0006265058.tif 000004
【図４】
0006265058.tif 000005
【図５】
0006265058.tif 000006
【図６】
0006265058.tif 000007
【図７】
0006265058.tif 000008
【図８】
0006265058.tif 000009
【図９】
0006265058.tif 000010
【図１０】
0006265058.tif 000011
【図１１】
0006265058.tif 000012
【図１２】
0006265058.tif 000013
【図１３】
0006265058.tif 000014
【図１４】
0006265058.tif 000015
【図１５】
0006265058.tif 000016
【図１６】
0006265058.tif 000017
【図１７】
0006265058.tif 000018
【図１８】
0006265058.tif 000019