JP2005159920A

JP2005159920A - メッセージ交換管理方法、ネットワークシステム、そのマスタノード、ノード、プログラム

Info

Publication number: JP2005159920A
Application number: JP2003398247A
Authority: JP
Inventors: Fumihiko Anzai; 文彦安西; Yuugo Sunaga; 祐悟須長; Soichi Arai; 聡一新井
Original assignee: Fuji Electric FA Components and Systems Co Ltd
Current assignee: Fuji Electric FA Components and Systems Co Ltd
Priority date: 2003-11-27
Filing date: 2003-11-27
Publication date: 2005-06-16
Anticipated expiration: 2023-11-27
Also published as: JP4269911B2

Abstract

【課題】フレームの消失や多重受信の際にも矛盾が生じないようにしつつ管理テーブルを小さくすることができ、更に制御用データ交換の定周期性を保証することができる。
【解決手段】要求メッセージ送信から応答メッセージ受信までを１トランザクションとし、マスタノード３は、一旦任意の送信側ノードにトークンを与えたら、このトランザクションが完了するまでは、複数サイクル続けてこの送信側ノードにトークンを与えつづける（他のノードにはトークンを与えない）。１トランザクションは、要求メッセージ送信、ポーリング、及び応答メッセージ受信から成るが、制御時間帯に影響しないようにする。例えば、１サイクル目では要求メッセージ送信のみとし応答は期待しない。その後、応答を得るまで繰り返しポーリングを行うが、制御時間帯に影響しそうな場合にはポーリングを中断し、次のサイクルのメッセージ時間帯でポーリングを再開する。
【選択図】図３

Description

本発明は、複数ノード間でデータ交換を行うシステムにおけるメッセージ交換に係わる情報管理や、この情報を用いた多重受信や異常の検出手法等に関する。

ノード間でデータ交換を行うための送信制御システムには様々なものがある。
送信権の制御には、各ノードが自ら送信のタイミングを判定してデータを送信するシステム(CSMA/CDやトークンリング等)、システムで唯一のマスタノードが他のノードにトークンを与えてデータ送信権を一時的に貸与するシステム、等々がある。また、データ交換の制御には、要求／応答データともに各ノードが送信権を獲得したときに送信するシステム、送信権を持ったノードが他のノードの応答データをポーリングで要求するシステム、等々がある。

さらに、交換されるデータにも、常時交換されるべきデータと、必要に応じて交換されるデータがある。
ここで、ＰＬＣ（プログラマブルコントローラ）等の産業用途のシステムであって、例えばシリアルバスに複数のノード（ＣＰＵモジュール）とＩ／Ｏモジュールが接続されたネットワークシステムにおけるデータ交換では、上記常時交換されるべきデータとしてＣＰＵモジュール−Ｉ／Ｏモジュール間で交換する制御用データを、上記必要に応じて交換されるデータとしてＣＰＵモジュール間で交換する状態監視等の支援メッセージを割り当てることが多い。この様な産業用途ネットワークシステムとしては、例えば、非特許文献１、非特許文献２等で紹介されているＳＸバスシステム等がある。制御用データは、それをもとに機械を動かしているので、定周期性が強く求められる。データ交換のタイミングがまちまちでは、機械の動きが滑らかでなくなり、最悪の場合に異常な動作を起こしかねないからである。

このため、上記のように１本のネットワーク（シリアルバス等）に複数のノード（ＣＰＵモジュール）が接続された産業用途ネットワークシステムでデータ交換を行う場合は、通信サイクル内で制御用データ交換用の時間帯と支援メッセージ交換用の時間帯を明確に分けて、支援メッセージの多寡によって制御用データのタイミングが変わらないようにしている。そして、支援メッセージの処理時間が支援メッセージ交換用時間帯より長くなることを想定して、要求メッセージ送信と応答メッセージ送信を別々のトランザクションとして取り扱っている。つまり、１つのメッセージ交換処理を、“要求メッセージ送信とその確認応答”のトランザクション（送信側ノードＡのトランザクション）と、“応答メッセージ送信とその確認応答”のトランザクション（受信側ノードＢのトランザクション）とに分けて、各々送信権を獲得したノードが要求／応答メッセージを送信する。また、上記“要求メッセージ送信とその確認応答”のトランザクションにおいてもし確認応答が得られなかった場合には、次のサイクルにおいて送信権を得られた場合には再送メッセージを送信する。送信権を得られなかった場合には更にその次以降のサイクルにおいて、送信権が得られたら再送メッセージを送信する。

ここで、受信側ノードＢでは、要求メッセージ受信毎に、それが新しいメッセージなのか、それともリトライによる再送メッセージを多重受信（多重受信とは、メッセージを正常受信したにも係わらず、確認応答の途中消失等の為に送信側ノードが再送メッセージを送った為、同じ内容のメッセージを２つ受信してしまうこと）したものなのかを判定する必要がある。尚、更に、１対１通信なのかブロードキャストなのかを判定する必要もある。そこで各々の要求メッセージにはその要求メッセージに対応するトランザクションを受信側ノードＢで判別できるようにする為のトランザクションＩＤ(以下、ＴＩＤ)（例えばシリアル番号）を送信側ノードＡが付けている。そして、ある要求メッセージ送信後にこの要求メッセージの再送メッセージを送信する場合には同じＴＩＤを付ける。これによって、受信側ノードＢではＴＩＤが同じ場合には再送メッセージであると判定できる。

但し、従来では上記のように送信側ノードＡが次のサイクルにおいて送信権が得られず再送メッセージを送信できない場合であって、このときに送信権を得た別のノードＣが同じ受信側ノードＢに要求メッセージを送るような状況になった場合、受信側で１つのＴＩＤのみで管理する場合には問題が生じる。

また、要求メッセージと応答メッセージが別々のトランザクションとなっているので、例えば、上記送信側ノードＡが上記あるメッセージ交換の為の“要求メッセージ送信とその確認応答”のトランザクション完了後に、続けて別のメッセージ交換（但し宛先は同じく上記受信側ノードＢ）の為の“要求メッセージ送信とその確認応答”のトランザクションを発生させ、新たな要求メッセージを送信する場合があるので、この場合にもその送信先が同じ受信側ノードＢである場合、上記別のノードＣの場合と同様、受信側で１つのＴＩＤのみで管理する場合には問題が生じる。詳しくは後述する。

更に、ＴＩＤは後述するようにサイクリックに使用されるので、送信側で１つのＴＩＤのみで管理する場合には問題が生じる。これも詳しくは後述する。
この為、従来では、ＴＩＤは、送信側ノードＡにおいて各宛先ノード毎に管理され、受信側ノードＢにおいても各送信元ノード毎に管理される。詳しくは、以下に説明する。

まず、送信側ノードＡは、新たな要求メッセージを送信するときには、宛先ノード毎に管理されているＴＩＤの中で当該メッセージの宛先ノードに対応するＴＩＤを更新（＋１インクリメント）して、更新後のＴＩＤの値を要求メッセージに格納して送信する。一方、受信側ノードＢは、受信したメッセージ内のＴＩＤを、送信元毎に用意されたテーブル内の値と比較して、一致していたら再送メッセージと判定してそれを破棄し、不一致ならば新規メッセージと判定してそれを受け取ってＴＩＤをテーブルに格納（更新）する。この仕組みでは、リトライによる再送メッセージではＴＩＤが元の値のままなので、受信側のＴＩＤ比較でテーブル内の値と一致するので、受信したメッセージは多重受信したものとして破棄される（もちろん初送メッセージが受信されていなければ受信側のＴＩＤはその前のメッセージのＴＩＤの値なので一致しないので、新規メッセージとして受け取られる）。

上記従来のＴＩＤを用いたメッセージ管理手法について、図２７〜図２９に示す具体例を参照して、更に詳細に説明する。
ここでは、ノード数を６４として、互いにメッセージ交換をするものとする。

各ノードは、上記ＴＩＤの管理の為に、図２７（ａ）、（ｂ）に示すＴＩＤ管理テーブルを保持している。各ノードは、図２７（ａ）、（ｂ）に示すＴＩＤ管理テーブル１０１，１０２，１０３，１０４を保持しているが、送信側となる場合には図２７（ａ）に示すＴＩＤ管理テーブル１０１又は１０２、受信側となる場合には図２７（ｂ）に示すＴＩＤ管理テーブル１０３又は１０４を用いて、メッセージ交換処理を実行する。

メッセージ交換処理には、１対１の場合とブロードキャストの場合とがある。
図２７（ａ）の図上上側には、送信側で用いる１対１用のＴＩＤ管理テーブル１０１の一例を示す。

１対１のメッセージ交換に関して、ＴＩＤを送信側で管理するには、ＴＩＤ管理テーブル１０１のように、宛先毎に管理していなければならない。なぜなら、例えばＴＩＤの値はサイクリックに決定されるので（例えば；１〜２５５を使うとして、２５５までいったら再び１に戻る）、もし、あるノードＡにおける送信側の処理として、あるノードＢ宛に要求メッセージを送信してメッセージ交換処理を行った後、このノードＢ以外の他のノードとのメッセージ交換（送信）を２５４回行ってから(ＴＩＤが丁度一周した場合)、再びこのノードＢ宛に要求メッセージを送信するような状況になった場合は、ノードＢが受け取る要求メッセージのＴＩＤは前回と同じとなる為、新規メッセージであるにも関わらず受信側のノードＢによって破棄されてしまうからである。ＴＩＤ管理テーブル１０１のように宛先毎に管理すれば、途中で別のノードにメッセージを送信してもノードＢ宛のＴＩＤは変化しないので、上記の問題は生じない。

一方、１対１のメッセージ交換に関して、受信側では、例えば図２７（ｂ）の図上上側に示すような１対１用のＴＩＤ管理テーブル１０３を用いて管理する。このＴＩＤ管理テーブル１０３の例のように、受信側でも送信元毎にＴＩＤを管理する。

ＴＩＤを受信側で送信元毎に管理するのは、ＴＩＤがシステムで一意ではなく送信元毎に管理されているため、別々に管理する必要があるからである。すなわち、上述したように、あるノードＢが、あるノードＡから初送メッセージａを受信し、次に別のノードＣから初送メッセージｃを受信し（あるいはノードＡから別のメッセージの初送メッセージｂを受信し）、最後にまたノードＡから上記初送メッセージａの再送メッセージを受信した場合、もしＴＩＤを送信元毎に管理していないと（１つのＴＩＤのみ記憶する管理テーブルを用いると）、この管理テーブルに別のノードＣ又はノードＡからの初送メッセージｃ又はｂのＴＩＤを上書きしてしまう為、最後の再送メッセージが最初のメッセージａの再送を多重受信したものであることが判定できなくなるからである。

さらに、ブロードキャストメッセージは、通常、ＡＣＫや応答を期待しないので、最初から同じメッセージを複数（例えば３つ）送信することで、メッセージの途中消失等に対応しているが、受信側では（１つのみ残して他のメッセージが全て途中消失しない限り）複数の同じメッセージを受信することになるので、この多重受信を判定する必要がある。この多重判定をするためには、上記１対１用のＴＩＤ管理テーブル１０１，１０３とは別のテーブルが必要である。ブロードキャストメッセージの場合は、宛先は自ノード以外の全部のノードということになるので、送信側で管理するＴＩＤは１つで良い。つまり、図２７（ａ）に示すブロードキャスト用ＴＩＤ管理テーブル１０２を用いればよい。

しかし、受信側では図２７（ｂ）に示すブロードキャスト用ＴＩＤ管理テーブル１０４のように、送信元毎のＴＩＤを管理する管理テーブルが別途必要である。それは、送信元で宛先毎のＴＩＤとブロードキャスト用のＴＩＤが別管理なので、受信側での管理も別々にする必要があるからである。

メッセージ交換を行う際、送信側ノードでは、上記ＴＩＤ管理テーブル１０１又は１０２を用いて、新たなＴＩＤを生成し、このＴＩＤを用いて要求メッセ−ジを送信する。
図２８は、送信側ノードのＴＩＤ生成処理を示すフローチャート図である。

同図において、まず、１対１のメッセージ交換であるかブロードキャストであるかを判定する（ステップＳ４０１）。１対１のメッセージ交換である場合には（ステップＳ４０１，ＮＯ）、初送メッセージであるか、再送メッセージであるかを判定する（ステップＳ４０２）。初送メッセージである場合には（ステップＳ４０２，ＹＥＳ）、テーブル１０１において宛先ノードのノード番号（予め各ノードに割り当てられているユニークな番号；以下、宛先ノード番号と記す）に対応するＴＩＤの値を＋１インクリメントする（ステップＳ４０３）。再送メッセージである場合には（ステップＳ４０２，ＮＯ）、インクリメントはしない。

そして、テーブル１０１における宛先ノード番号に対応するＴＩＤを、送信元ノード番号（送信元ノード番号）と共に、要求メッセージに格納して（ステップＳ４０４）、要求メッセージを送信する。

一方、ブロードキャスト通信を行なう場合には（ステップＳ４０１，ＹＥＳ）、初送メッセージであるか、再送メッセージであるかを判定し（ステップＳ４０５）、初送メッセージである場合には（ステップＳ４０５，ＹＥＳ）、テーブル１０２のＴＩＤの値を＋１インクリメントする（ステップＳ４０６）。再送メッセージである場合には（ステップＳ４０５，ＮＯ）、インクリメントはしない。

そして、テーブル１０２のＴＩＤを、送信元ノード番号（送信元ノード番号）と共に、要求メッセージに格納して（ステップＳ４０７）、要求メッセージを送信する。尚、よく知られているように、ブロードキャストの場合、宛先アドレスが予め決められた特別のアドレスであるので、受信側では宛先アドレスを参照することでブロードキャストであるか否かを判定できる。

受信側ノードでは、上記要求メッセージを受信すると、まず、それが１対１なのかブロードキャストなのかを判定し、１対１用ＴＩＤ管理テーブル１０３またはブロードキャスト用ＴＩＤ管理テーブル１０４を用いて、それが新しいメッセージなのか、それともリトライによる再送メッセージなのかを判定する処理（多重検出処理と呼ぶ）を実行する。

図２９は、受信側ノードにおける上記多重検出処理を示すフローチャート図である。
図２９において、まず、受信した要求メッセージが１対１か、ブロードキャストかを判定する（ステップＳ４１１）。１対１である場合には（ステップＳ４１１、ＮＯ）、受信した要求メッセージから送信元ノード番号とＴＩＤを取り出して（ステップＳ４１２）、テーブル１０３において同じ送信元ノード番号のＴＩＤと比較する（ステップＳ４１３）。もし、両者（ＴＩＤ）が一致すれば（ステップＳ４１３，ＮＯ）、受信した要求メッセージは再送メッセージであり且つその初送メッセージは既に受信していることになるので、当該要求メッセージは破棄して（ステップＳ４１８）処理を終了する。もし、両者が不一致であれば（ステップＳ４１３，ＹＥＳ）、テーブル１０３における上記送信元ノード番号に対応するＴＩＤの値を更新する。つまり、要求メッセージに格納されていたＴＩＤの値にする（ステップＳ４１４）。そして、引き続き所定の要求メッセージ受信処理を実行する。

一方、受信した要求メッセージがブロードキャストによるものである場合には（ステップＳ４１１、ＹＥＳ）、受信した要求メッセージから送信元ノード番号とＴＩＤを取り出して（ステップＳ４１５）、このＴＩＤとテーブル１０４に格納されているＴＩＤとを比較して（ステップＳ４１６）、もし両者が一致すれば（ステップＳ４１６，ＮＯ）、上記ステップＳ４１８を実行して（要求メッセージを破棄して）、処理を終了する。もし、両者が不一致であれば（ステップＳ４１６，ＹＥＳ）、テーブル１０４のＴＩＤの値を、要求メッセージに格納されていたＴＩＤの値へと更新する（ステップＳ４１７）。

上記図２８、図２９の処理について、図２７に示す例を参照して具体例を説明する。
ここでは、ノード番号が‘０’のノード（以下、ノード０と記す）からノード番号が‘１’のノード（以下、ノード１と記す）に対して、１対１の要求メッセージを送る場合を例にする。この場合、ノード０はテーブル１０１を、ノード１はテーブル１０３を使用する。

ノード０はテーブル１０１において宛先ノード番号１のＴＩＤをインクリメント(250→251)して、このＴＩＤ(251) と送信元ノード番号(0) を要求メッセージに格納してノード１に送信する。ノード１はこの要求メッセージを受信すると、そこからＴＩＤ (251)と送信元ノード番号(0)を取り出す。そしてテーブル１０３における送信元ノード番号０のＴＩＤ(250)と比較する。この場合、ＴＩＤが不一致となるので、受信した要求メッセージは新しい（初送）メッセージであると判定する。そして、受信したＴＩＤ (251)をテーブル１０３に格納する。つまり、テーブル１０３のＴＩＤの値を更新する。

その後にもしこの要求メッセージのリトライとしてノード０からノード１に対して１対１の要求メッセージを送る場合、ノード０はテーブル１０１の宛先ノード番号１のＴＩＤをインクリメントすることなく(251のまま)、このＴＩＤ(251) と送信元ノード番号(0) を要求メッセージに格納してノード１に送信する。ノード１はこの要求メッセージを受信するとそこからＴＩＤ (251)と送信元ノード番号(0)を取り出す。そしてテーブル１０３の送信元ノード番号０のＴＩＤ(251：先の要求メッセージで更新済み)と比較する。この場合、ＴＩＤが一致するのでこれが多重に同じメッセージを受信した物だと判定できる。そこで、この要求メッセージは破棄する。

ブロードキャストの場合でも、受信側のＴＩＤ管理テーブルの使い方は１対１の場合と同様である。ここでは、ノード０がブロードキャストで要求メッセージを送るものとし、ノード０はテーブル１０２、ノード０以外はテーブル１０４を使用する。

ノード０は新たな要求メッセージを送信する場合には、テーブル１０２のＴＩＤをインクリメント(100→101)して、このＴＩＤ(101) と送信元ノード番号(0) を要求メッセージに格納してブロードキャスト送信する。ノード０以外の他のノードは、各々、この要求メッセージを受信するとそこからＴＩＤ (101)と送信元ノード番号(0)を取り出す。そしてこのＴＩＤ (101)をテーブル１０４の送信元ノード番号０のＴＩＤ(100)と比較する。この場合ＴＩＤは不一致となるので新しいメッセージと判定する。そして、受信したＴＩＤ (101)をテーブル１０４に格納する。

後にこの要求メッセージを多重化して番号０のノードからブロードキャストで要求メッセージを送る場合、ノード０はテーブル１０２のＴＩＤをインクリメントすることなく(101のまま)、このＴＩＤ(101) と送信元ノード番号(0) を要求メッセージに格納して送信する。ノード０以外の各ノードは、この要求メッセージを受信するとそこからＴＩＤ (101)と送信元ノード番号(0)を取り出す。そしてテーブル１０４の送信元ノード番号０のＴＩＤ(101：先の要求メッセージで更新済み)と比較する。この場合ＴＩＤが一致するのでこれが多重に同じメッセージを受信した物だと判定できる。そこで、この多重受信したメッセージを破棄する。
「拡大するＳＸバス接続機器」；富士時報Ｖｏｌ．７３ＮＯ．２、２０００、ｐ１３０〜１３１「統合コントローラ「ＭＩＣＲＥＸ−ＳＸシリーズ」のスケーラブル・・・」；富士時報Ｖｏｌ．７１、ＮＯ．１１１９９８

上述の様にＴＩＤの管理テーブルは、送信側で宛先毎、受信側で送信元毎に必要である。例えばノードが64台あり、互いにブロードキャストも含む支援メッセージを交換するシステムならば、送信側の宛先毎ＴＩＤ用が64、送信側のブロードキャストＴＩＤ用が１、受信側の送信元毎ＴＩＤ用が64、受信側のブロードキャスト送信元毎ＴＩＤ用が64、必要となる。１ＴＩＤを１バイトにすると合計193バイト必要となり、ワンチップマイコンの様にＲＡＭが数ｋバイトと小さい物に通信プロトコルを組み込む場合には、大きな負担になる。このように、組み込み用途の様な少ないリソースでも用いることができるように、管理テーブルを小さくすることが望まれる。

管理テーブルを小さくするするには、要求と応答を同じトランザクションにする必要があるが、支援メッセージの処理時間が支援メッセージ交換用時間帯の時間より長くなることも考慮する必要がある。もともとこれを避けるために、要求メッセージ送信と応答メッセージ送信を別々のトランザクションとして取り扱っている。よって、管理テーブルを小さくしても、支援メッセージの処理時間が支援メッセージ交換用時間帯の時間より長くても、支援メッセージ交換用時間帯を延ばすことなく、制御用データ交換の定周期性を維持できるようにすることが必要である。これには、当然、フレームの消失や多重受信の際にも矛盾が生じないような仕組みが必要である。

本発明の課題は、フレームの消失や多重受信の際にも矛盾が生じないようにしつつ管理テーブルを小さくすることができ、更に制御用データ交換の定周期性を保証することができるメッセージ交換管理方法、システム、プログラム等を提供することである。

本発明の請求項１記載のメッセージ交換管理方法は、複数のノードがネットワークを介して互いにデータ交換するシステムにおけるメッセージ交換管理方法であって、前記データ交換の為の通信サイクルを、前記制御データ交換の為の制御データ交換用時間帯とメッセージ交換の為のメッセージ交換用時間帯に分け、該メッセージ交換用時間帯におけるメッセージ交換処理は、要求から応答までを１トランザクションとし、システム全体の送信権管理をするマスタノードを備え、該マスタノードは、メッセージ送信の為の送信権要求を出したノードにトークンを与え、前記マスタノードからトークンを得たメッセージ送信側ノードは、複数サイクルに渡ってメッセージ交換用時間帯において任意のメッセージ受信側ノードに要求メッセージを送信すると共に該要求に対する応答を得るまでポーリングを繰り返し、前記マスタノードは前記メッセージ送信側ノードが応答を得るまで他のノードにトークンを与えないようにする。

上記のようにすることで、あるメッセージ交換の処理が完了するまでは、他のメッセージ交換のトランザクションが発生しないので、受信側のＴＩＤ管理テーブルを小さくしても問題なくなる。

また、本発明の請求項２のメッセージ交換管理方法は、例えば上記請求項１のメッセージ交換管理方法において、更に、前記メッセージ送信側ノードは、最初のサイクルで前記要求メッセージの送信を行い、２番目以降のサイクルでポーリングを繰り返し行う際には、各サイクル毎に、そのメッセージ交換用時間帯内に応答が得られない場合にはポーリングを一時中断し、次のサイクルのメッセージ交換用時間帯に入ったらポーリングを再開することで、制御データ交換の定周期性を保証する。

この様にすることで、たとえ非常に時間が掛かるメッセージ交換処理であっても、制御データ交換用時間帯に影響を与えることなく処理を行えるので、制御データ交換の定周期性を保証することができる。

そして、上記請求項１のメッセージ交換管理方法によれば、例えば請求項３のように、前記メッセージ送信側ノードでは、トランザクション番号を宛先ノード毎に管理して、新規メッセージ送信毎にその宛先に対応するトランザクション番号を更新して、該更新後のトランザクション番号と送信元ノード番号を前記要求メッセージに格納して送信し、
前記メッセージ受信側ノードでは、前回受信した要求メッセージの送信元ノード番号とトランザクション番号を記憶しておき、受信した要求メッセージの送信元ノード番号とトランザクション番号の両方が前記記憶した番号と一致する場合にはメッセージの多重受信と判定することができる。

すなわち、あるメッセージ交換の処理が完了するまでは、他のメッセージ交換のトランザクションが発生しないことが保証されているので、受信側ノードにおいては送信元ノード毎にＴＩＤを管理する必要はなくなり、前回受信した要求メッセージの送信元ノード番号とトランザクション番号を記憶しておけば済むようになり（勿論、問題なく多重受信を判定できる）、受信側のＴＩＤ管理テーブルを小さくできる。但し、受信側のＴＩＤ管理テーブルは、１対１用とブロードキャスト用の２つを用意する必要はある。

これに対して、請求項４では、以下に示す判別フラグを用いることで、受信側のＴＩＤ管理テーブルは、１対１用とブロードキャスト用共用の１つのみを用意すれば済むようになる。

すなわち、請求項４では、前記メッセージ送信側ノードでは、トランザクション番号を宛先ノード毎に管理して、新規メッセージ送信毎にその宛先に対応するトランザクション番号を更新して、該更新後のトランザクション番号と送信元ノード番号を前記要求メッセージに格納して送信し、メッセージ受信側ノードでは、前記前回受信したメッセージの送信元ノード番号とトランザクション番号を記憶すると共に該メッセージがブロードキャストメッセージであるか１対１メッセージであるかを示す判別フラグを記憶しておき、今回受信したメッセージがブロードキャストメッセージであるか１対１メッセージであるかを判定し、該判定結果と該今回受信したメッセージの送信元ノード番号とトランザクション番号とを、前記記憶しておいた値とそれぞれ比較し、全て一致する場合にはメッセージの多重受信と判定する。

また、上記従来技術では、送信側ノードにおいても、宛先ノード毎にＴＩＤを管理する必要があった。
これに対して、本発明の請求項５では、上記請求項１の方法に加え更に、前記メッセージ受信側ノードは、他ノード宛のメッセージを監視することで新たなトランザクションに移行したことを認識すると該トランザクション移行を示す情報を記憶する。

この様にすることで、たとえ送信側ノードで宛先ノード毎に区別することなくトランザクション番号を管理して、他ノード宛の要求メッセージを出し続け、ＴＩＤの更新が一周して、前回と同じ値のＴＩＤを持つ要求メッセージが送られてきたとしても、前回とは異なるトランザクションの要求メッセージであることが判別できるので、これを多重受信と誤判定することはない。また、この場合、送信側・受信側とも、１対１通信とブロードキャスト共用で管理することができる。

これより、請求項６のように、前記メッセージ送信側ノードは、宛先ノード毎に区別することなく１対１通信とブロードキャスト共用でトランザクション番号を管理して、新規メッセージ送信毎に該トランザクション番号を更新して、該更新後のトランザクション番号と送信元ノード番号をメッセージに格納して送信し、メッセージ受信側ノードでは、前回受信したメッセージの送信元ノード番号とトランザクション番号を１対１通信とブロードキャスト共用で記憶しておき、受信したメッセージの送信元ノード番号とトランザクション番号の両方が前記記憶した番号と一致する場合にはメッセージの多重受信と判定することができる。

また、例えば請求項７のように、前記マスタノードは、前記トランザクション番号を一元管理して、新規トランザクションによる送信権要求に応じてトークンを与える場合には該トランザクション番号を更新して、該更新後のトランザクション番号をトークンに格納して送信し、前記メッセージ送信側ノードは、受信したトークンから前記トランザクション番号を取り出して、該トランザクション番号を前記要求メッセージに格納して送信し、前記メッセージ受信側ノードは、前回受信した要求メッセージに含まれていたトランザクション番号を１対１通信とブロードキャスト共用で記憶しておき、今回受信した要求メッセージに含まれるトランザクション番号を前記記憶しておいた値と比較し、一致する場合にはメッセージの多重受信と判定し、次のトランザクションへ移行したことを認識すると、トランザクション移行を示す情報を記憶するようにしてもよい。

上記請求項１〜６では、従来と同様に各送信側ノードで個別にＴＩＤを更新・管理することを前提としていたので、例えば請求項６においても受信側では送信元ノード番号とトランザクション番号とを対応付けて記憶する必要があったが、請求項７では、ＴＩＤはシステム全体で一意のものとしてマスタノードで一元管理するので、トランザクション番号のみ記憶すれば済むようになる（トランザクション番号が同じであれば、それは必ず、同一トランザクションということになる。一方、請求項６等では、トランザクション番号が同じであっても、送信元ノードが異なれば、別トランザクションということになる）。

上記請求項１〜７は、受信側ノードは、１対１通信の要求メッセージを受信したらＡＣＫを返信するシステムを前提としている。このシステムでは、要求メッセージ受信したサイクル内で要求メッセージが正常かをチェックしてＡＣＫを返信する処理を行う為に掛かる時間分、メッセージ交換用時間帯を長くする必要がある。これに対して、ＡＣＫ返信処理を行わないようにした場合、要求メッセージが受信側に届かないにも係わらずそのポーリングがくる可能性があり、これが前の要求メッセージのポーリングであると誤判定してしまうという問題がある。

これに対して、請求項１１記載の発明では、前記メッセージ受信側ノードは、前記要求メッセージを受信してもＡＣＫ返信処理は行わず、前記メッセージ送信側ノードは前記各ポーリング送信の際にも該ポーリングに前記トランザクション番号と送信元ノード番号を格納して送信し、前記メッセージ受信側ノードは、ポーリングを受信すると、該ポーリングに含まれるトランザクション番号と送信元ノード番号を前記記憶してある値と比較して、不一致である場合には新規要求メッセージの消失と判定して非応答を返信する。

上記のように、ポーリングにも要求メッセージと同様にトランザクション番号と送信元ノード番号を含めるので、上記誤判定が生じないようにできる。

フレームの消失や多重受信の際にも矛盾が生じないようにしつつ管理テーブルを小さくすることができ、更に制御用データ交換の定周期性を保証することができる。また、１対１通信でＡＣＫを返さないシステムにしても、フレームの消失に対応でき、間違った応答メッセージを返信しないようにできる。

以下、図面を参照して、本発明の実施の形態について説明する。
図１に、本例によるシステム全体の概略構成図を示す。
図示の例では、バス型ネットワーク４にマスタノード３と複数のノード０，１，２、・・・が接続されている。尚、ここでは、上記従来技術と同様、そのノード番号が０のノードをノード０、ノード番号が１のノードをノード１等と記すものとする。また、図ではノードの数は、マスタノードも含めて４つのみ示しているが、より多くのノードがバス型ネットワーク４に接続されていてもよい。また、バス４は、例えば上記ＳＸバス等である。また、各ノードは例えばＰＬＣのＣＰＵモジュールであり、特に図示しない各Ｉ／Ｏモジュールとの間で制御時間帯において制御データ／センサデータ等を送受信する。

図２は、上記各ノードのハードウェア構成図である。
図２に示すノード１０は、ＣＰＵ１１、プログラムメモリ部１２、メモリ部１３、タイマ１４、伝送制御部１５等を有する。メモリ部１３は、データメモリ部１３ａ、送信バッファ１３ｂ、受信バッファ１３ｃ等の記憶領域を有する。

ＣＰＵ１１は、プログラムメモリ部１２に格納されているプログラム、データメモリ部１３ａに格納されている各種データ（後述する各種管理テーブル等）を用いて、後述するフローチャート（図４〜図８、図１３〜図１４、図１６、図１７、図１９、図２０、図２２〜図２４等のフローチャート）に示す処理を実行する。

すなわち、特に図示しないが、ノード１０は、この様な処理実行により得られる各種機能部を有するものである。例えば、特に図示しないが、ノード１０は、マスタノード３である場合には、メッセージ送信の為の送信権要求を出したノードにトークンを与え、一旦トークンを与えたノードが前記トランザクションを完了するまで他のノードにトークンを与えないようにする送信権管理部を有する。あるいは、特に図示しないが、ノード１０が、マスタノード３からトークンを得たノードであるメッセージ送信側ノードとして動作するときには、複数サイクルに渡ってメッセージ交換用時間帯において任意のメッセージ受信側ノードに要求メッセージを送信すると共に該要求に対する応答を得るまでポーリングを繰り返し、最初のサイクルで前記要求メッセージの送信を行い、２番目以降のサイクルでポーリングを繰り返し行う際には、各サイクル毎に、そのメッセージ交換用時間帯内に応答が得られない場合にはポーリングを一時中断し、次のサイクルのメッセージ交換用時間帯に入ったらポーリングを再開することで制御データ交換の定周期性を保証するメッセージ送信制御部を有する。あるいは、特に図示しないが、ノード１０は、メッセージ受信側ノードとして動作するときには、後述する各実施例の受信側ＴＩＤ管理テーブルを用いて多重受信を判定する多重受信判定部や、他ノード宛のメッセージを監視することで新たなトランザクションに移行したことを認識すると該トランザクション移行を示す情報を記憶するトランザクション移行監視部等を有する。

尚、送信するデータ（要求メッセージ等）は、一旦送信バッファ１３ｂに格納された後、伝送制御部１５によってバス４上に流される。また、伝送制御部１５によって受信したデータ（応答メッセージ等）は、一旦受信バッファ１３ｃに格納された後、ＣＰＵ１１によって処理される。

上記本例のシステムでは、まず、要求と応答を同じトランザクションにしている。これによって、ある１つのノードが複数のメッセージ送信を行いたくて、１つのメッセージの応答を待っている間に、次の要求メッセージの送信を行うこと（別のトランザクションが生じること）はない。そして、システムで唯一のマスタノード３が送信権の調停を行いトークン（送信権）の管理をする構成を前提として、更に、本例ではマスタノード３は、トークンを与えたノードのトランザクション終了するまでの間は、他のノードにはトークンを与えないようにすることを特徴としている。これによって、あるノードのトランザクションを処理中に別のノードのトランザクションが生じないようにできる。

すなわち、トークンは、ある時点においてシステム内の１ノードのみに送信権を与えるためのものだが、送信権を与えられたノードが要求メッセージを送信し、ポーリングによって応答メッセージを受信するまでトークンを別のノードに与えなければ、結果として別のトランザクションは発生しない。

以上のように、"要求から応答までを同じトランザクションとし"且つ"マスタノードは一旦送信権を与えた任意のノードのトランザクション終了するまでの間、他のノードには送信権を与えないようにする"ことで、あるトランザクションの処理中は、全てのノード（送信権を与えられたノードも含む）において新たなトランザクションが生じることはない。よって、後述するようにＴＩＤ管理テーブルを小さくすることができる。

しかし、それだけではメッセージ交換の処理時間が掛かった場合に、メッセージ時間帯が延びて制御時間帯（制御用データ交換の時間帯）に影響して定周期性を乱してしまう。
そこで、１トランザクションを要求メッセージとポーリングと応答メッセージで組み立てる。要求メッセージは要求を受信側に送るのみで応答メッセージを期待しない。ポーリングは応答メッセージを期待する。送信権を要求してマスタノード３からトークンを与えられたノードは、要求メッセージを送信した後にポーリングを繰り返し、応答メッセージを受信するまでマスタノード３に対して送信権の要求を繰り返し行う。この間、他のノードからも送信権の要求があるかもしれないが、マスタノード３は上記の通り他のノードには送信権を与えないようにする。ただし、トークンを与えられたノードは、ポーリングの回数もしくは時間によってポーリングを一旦打ち切ってメッセージ時間帯内に抑え、制御用データ交換の時間帯を確保する。そして、次のメッセージ時間帯になるとマスタノード３は、上記トークンを与えられたノードに再びトークンを与え、そのノードは中断していたポーリングを再開する。そして応答メッセージを受信すると、次のサイクルでは送信権の要求は行わない。すると次のメッセージ時間帯になるとマスタノード３は別のノードにトークンを与えることができるので、別のトランザクションに移行することができる。

上述したように要求メッセージ送信から応答メッセージ受信までを１トランザクションにしつつ、その間に定周期の制御データを問題なく交換できるプロトコルの一例を図３に示す。

図３は、フレームの流れ(上下方向)を時間軸(右方向)で表した物で、上からマスタノード３、メッセージ(MSG)送信側ノード、メッセージ(MSG)受信側ノードの順に並んでいる。物理的な接続では１本のネットワーク４にマルチドロップでこれら３つのノードがぶら下がっているが、説明のためにこの図の様にした。尚、メッセージ送信側ノード、メッセージ受信側ノードは、何れも、図１のノード０，１，２、・・・の中の任意のノードである。

まず１サイクル目で、メッセージ送信側ノードは、制御データ交換用時間帯(制御時間帯)において制御データ交換を行うと共にマスタノード３に対してメッセージ送信権を要求する。マスタノード３は、メッセージ時間帯(MSG時間帯)に入るとメッセージ送信側ノードにトークンを与える。このトークンを得てメッセージ送信側ノードはメッセージ受信側ノードに要求メッセージ(要求MSG)を送信する。メッセージ受信側ノードは、要求メッセージを受けるとひとまず受信確認(Ack：Acknowledge)を送信する。メッセージ送信側ノードは時間に余裕があれば続いてポーリングをしても良いが、本実施例では要求メッセージ送信のみにする。

そして２サイクル目の制御時間帯では、メッセージ送信側ノードは再びメッセージ送信権をマスタノード３に要求する。次のメッセージ時間帯に入るとマスタノード３はメッセージ送信側ノードに再びトークンを与える（もし他のノードから要求があっても与えない）。このトークンを得てメッセージ送信側ノードはメッセージ受信側ノードにポーリングを行う。メッセージ受信側ノードは、ポーリングを受けると、応答メッセージ(応答MSG)が準備できていればそれを送信するが、図の例ではまだ準備できていなくて「処理中応答」を送信する。尚、メッセージ送信側ノードは時間に余裕があればもう一度ポーリングをしても良いが、図の例では１度のみにする。

そして３サイクル目の制御時間帯においても、メッセージ送信側ノードはマスタノード３にメッセージ送信権を要求する。次のメッセージ時間帯に入るとマスタノード３はメッセージ送信側ノードにトークンを与える。このトークンを得てメッセージ送信側ノードはメッセージ受信ノードにポーリングを行う。図示の例ではこのときメッセージ受信側ノードは応答データが準備できているので、ポーリングを受けると応答メッセージを送信する。

そして次の制御データ交換用時間帯では、メッセージ送信権の要求は行わない。これより、次のメッセージ時間帯に入るとマスタノード３はメッセージ送信側ノードのトランザクションが完了したものと見做し、別のノードが送信権の要求をしていればそちらにトークンを与える。つまり新たなトランザクションに移ることができる。

尚、図示の例ではメッセージ送信側ノードは各サイクル毎に逐一送信権要求を行ったが、この例に限らない。例えば、１サイクル目で送信権要求を行った後は、２サイクル目移行は送信権要求を行わなくてもトークンが与えられ続けるようにし、応答メッセージを受信したらマスタノード３に対して送信権の要求を取り下げるようにしてもよい。

以上のように、応答メッセージが準備できるまで、ポーリングとポーリングの間に制御用データの交換を行うことにより、制御用データ交換の定周期性を守りつつ、要求から応答までを１つのトランザクションで実行している。

尚、制御時間帯における通信は、単にデータをブロードキャストで流すだけであり、トランザクションは発生せず、ＴＩＤを管理する必要もないので、上記メッセージ交換のＴＩＤ管理には何等影響を及ぼさない。

図４〜図６に、図３に示す各ノード、すなわちマスタノード３、メッセージ送信ノード、メッセージ受信ノードの動作の基本処理フローチャートを示す。
図４は、マスタノード３の基本処理フローチャート図である。

図４において、マスタノード３は、タイマ１４による定周期タイマ割り込みが入る毎に（ステップＳ１１，ＹＥＳ）、まず制御時間帯における処理を行う。すなわち、他の各ノード（０，１，２・・・等）からの制御データ受信処理を行うと共に、もし１または２以上のノードから上記送信権要求があった場合にはこれを受信して記録しておく（ステップＳ１２）。続いて、メッセージ時間帯に入ったら（ステップＳ１３，ＹＥＳ）、送信権要求したノードにトークンを与えるが（ステップＳ１５）、もし複数のノードから送信権要求があった場合には、その前にどのノードにトークンを与えるかを判定する（ステップＳ１４）。この判定は、上記の通り、前のサイクルでトークンを与えたノードから引き続き送信権要求があった場合には（あるいは要求が無くても、要求の取り下げが無い限り）、このノードに引き続きトークンを与える。

図５は、メッセージ送信ノードの基本処理フローチャート図であり、図５（ａ）は制御時間帯、図５（ｂ）はメッセージ時間帯における処理を示す。
図５（ａ）において、メッセージ送信ノードは、制御時間帯に入ったら（ステップＳ２１，ＹＥＳ）、まず、通常の制御データ送信処理を行う（ステップＳ２２）。更に、他のノードに送信すべきメッセージがある場合には（ステップＳ２３、ＹＥＳ）、マスタノード３に対して送信権要求を行う（ステップＳ２４）。

ステップＳ２４の送信権要求に対して、もしトークンが与えられた場合には、メッセージ時間帯に入る毎に、図５（ｂ）に示す処理を実行する。
図５（ｂ）において、メッセージ送信ノードは、まず、応答待ちフラグがＯＮかＯＦＦかを判定する（ステップＳ３１）。応答待ちフラグは、既に要求メッセージを送信しておりメッセージ受信ノードからの応答待ちの状態である場合にはＯＮになっている。

最初は、未だ要求メッセージは送信していないので、応答フラグはＯＦＦであり、ステップＳ３２〜Ｓ３６の処理を行うことになる。まず、ＴＩＤ生成処理を行う（ステップＳ３２）。このＴＩＤ生成処理の詳細については後に実施例１，２，３で説明する。すなわち、実施例１では図７の処理、実施例２では図１０の処理、実施例３では図１３の処理を行う。

続いて、生成したＴＩＤと自己のノード番号（送信元ノード番号）を要求メッセージに含めて送信する（ステップＳ３３）。上記の通り、メッセージ受信ノードは、要求メッセージを受けると受信確認（ＡＣＫ）を返信するので、これを待ち（ステップＳ３５）、ＡＣＫを受信したら（ステップＳ３５、ＹＥＳ）、応答待ちフラグをＯＮにして（ステップＳ３６）、処理を終了する。一方、ＡＣＫを受信しないままＡＣＫ待ち時間オーバーとなった場合には（ステップＳ３４，ＹＥＳ）そのまま当該処理は終了する。この場合、応答待ちフラグはＯＦＦのままなので、次のサイクルで再びステップＳ３２〜Ｓ３６の処理を実行することになる。すなわち、次のサイクルで要求メッセージの再送処理を行うことになる。尚、特に図示しないが、ブロードキャストの場合はＡＣＫは来ない。その代わり、通常は、ブロードキャストの場合は要求メッセージを連続して複数回送信する。

一方、ＡＣＫを受信した場合には、応答待ちフラグはＯＮになっているので、次のサイクルにおいて、ステップＳ３７〜Ｓ４１の処理を実行することになる。まず、ポーリング送信を行う（ステップＳ３７）。そして、応答待ち時間内に応答メッセージを受信した場合には（ステップＳ３９、ＹＥＳ）、当該メッセージ交換は完了となり、最後に応答待ちフラグをＯＦＦにして（ステップＳ４１）処理を終了する。

一方、処理中応答を受信した場合（ステップＳ４０，ＹＥＳ）または応答が無いままＡＣＫ待ち時間オーバーとなった場合には（ステップＳ３８，ＹＥＳ）そのまま当該処理は終了する。この場合は、未だメッセージ交換は完了していないので、引き続き、次のサイクルにおいてステップＳ３７〜Ｓ４１の処理を実行することになる。勿論、この場合、送信権要求を行ってトークンを得ることは当然に行っている。

図６は、メッセージ受信ノードの基本処理フローチャート図であり、図６（ａ）は上記要求メッセージ受信時の処理、図６（ｂ）は上記ポーリング受信時の処理である。
図６（ａ）において、要求メッセージを受け取ったメッセージ受信ノードは、まず、当該要求が１対１通信かブロードキャストかを判定する（ステップＳ５１）。ブロードキャストである場合にはそのままステップＳ５４の処理に移行し、１対１通信である場合、それが自ノード宛である場合には（ステップＳ５２，ＹＥＳ）、まず、ＡＣＫを送信する（ステップＳ５３）。勿論、自ノード宛ではない場合には（ステップＳ５２，ＮＯ）受信処理は行わない。

続いて、多重検出処理を実行する（ステップＳ５４）。多重検出処理は、受信した要求メッセージが上記多重受信した再送メッセージであるか否かを判定する処理である。この多重検出処理の詳細については後に各実施例で説明する。

その後は通常の要求メッセージ解析・実行を行って（ステップＳ５５）、当該受信処理は終了する。
図６（ｂ）において、ポーリング受信したメッセージ受信ノードは、応答メッセージの準備が完了していたら（ステップＳ６１，ＹＥＳ）応答メッセージを送信し（ステップＳ６２）、そうでなければ（ステップＳ６１，ＮＯ）処理中応答を送信する（ステップＳ６３）。

以上述べた本例の手法を用いれば、制御用データ交換の定周期性を維持しつつ且つフレームの消失や多重受信の際にも矛盾が生じないようにしつつ管理テーブルを小さくすることができる。これについて、以下、実施例１，２について説明する。

上記の通り、従来は、受信側ノードにおいて送信元ノード毎にＴＩＤを記憶しておくＴＩＤ管理テーブルが必要であった。
しかし、本例では上記の通り、要求から応答までを同じトランザクションとし且つその間は別のノードにトークンを与えないようにすることで、あるメッセージ交換処理中に別のトランザクションが発生しないことを保証できるので、受信したメッセージの送信元ノード番号とＴＩＤの組が前に受信したメッセージの組と異なれば別のメッセージと判定しても問題なくなるので、受信側のＴＩＤ管理テーブルはノード数分確保しておく必要は無くなる。すなわち、１対１用のＴＩＤ管理テーブルにはノード番号とＴＩＤを１つずつ記憶しておけば良くなる。

また、本例でも受信側においてブロードキャスト用ＴＩＤ管理テーブルを１対１用とは別に設けている。これは、１対１とブロードキャストで送信につかうＴＩＤが別管理になっており、それを区別する必要があるからである。そこでブロードキャストに対応する為にノード番号とＴＩＤをもうひと組記憶しておけば良い(つまり、１対１用で１組、ブロードキャスト用で１組、計２組)。

以上のことから、実施例１では、受信側のＴＩＤ管理テーブルは後述する図９（ｂ）に示すようになる（尚、送信側のＴＩＤ管理テーブルは、図９（ａ）に示す通り、従来と同様である）。

あるいは、更に、後述する実施例２のようにしてもよい。すなわち、同じノードからのメッセージで１対１とブロードキャストのＴＩＤがたまたま同じになっても、それを別のメッセージと判定できれば良いのであるから、後述する実施例２の図１２（ｂ）に示すように、１対１とブロードキャストとで記憶する「ノード番号とＴＩＤ」を共用すると共に、「１対１とブロードキャストを識別するフラグ」を記憶すればよい。これによって、ノード番号とＴＩＤの１組と判別フラグを記憶するだけで、例えば上記のように同じノードからのメッセージで１対１のＴＩＤとブロードキャストのＴＩＤがたまたま同じになったとしても、それを別のメッセージと判定できる（１対１同士、ブロードキャスト同士でＴＩＤを比較できる）。

以下、まず、図７〜図９を参照して、実施例１について説明する。
実施例１では、図９（ａ）に示すように、送信側のＴＩＤ管理テーブルは、管理テーブル２１（１対１用）も管理テーブル２２（ブロードキャスト用）も、従来の管理テーブル１０１，１０２と同様である。よって、図７に送信側ノードのＴＩＤ生成処理（図５（ｂ）のステップＳ３２の処理）の詳細フローチャートを示すが、これは従来の図２８に示すＴＩＤ生成処理と同様である。すなわち、図７のステップＳ７１〜Ｓ７７の処理は、図２８のステップＳ４０１〜Ｓ４０７と同様である。よって、ここでは特に説明しない。

一方、受信側のＴＩＤ管理テーブルは、図９（ｂ）に示す通り、１対１用、ブロードキャスト用とも、従来の図２７（ｂ）のように各送信元ノード毎に管理する必要はなくなっている（管理テーブルを小さくできる）。そして、受信側ノードでは、図６（ａ）のステップＳ５４の多重検出処理は、図８に示す処理を行う。

図８は、実施例１における受信側ノードの多重検出処理の詳細フローチャート図である。
図８において、ステップＳ８１、Ｓ８２、Ｓ８６の処理は、従来の図２９のステップＳ４１１、Ｓ４１２、Ｓ４１５の処理と同様であるので、説明は省略する。

１対１通信である場合、ステップＳ８２の処理後、ステップＳ８３、Ｓ８４の判定を行う。すなわち、受信した要求メッセージから取り出した送信元ノード番号、ＴＩＤと、図９（ｂ）のＴＩＤ管理テーブル２３の送信元ノード番号、ＴＩＤとを比較して、もし、送信元ノード番号、ＴＩＤの両方ともが一致する場合には（ステップＳ８３、Ｓ８４の両方がＮＯ）、受信した要求メッセージは、既に正常に受信済みの要求メッセージの再送メッセージであるので（多重受信であるので）、受信した要求メッセージは破棄して（ステップＳ９０）当該処理は終了する。

一方、送信元ノード番号が一致で（ステップＳ８３，ＮＯ）且つＴＩＤが不一致である場合（ステップＳ８４，ＹＥＳ）、あるいは送信元ノード番号が不一致である場合（ステップＳ８３，ＹＥＳ）には、受信した要求メッセージは、新しいメッセージ（初送メッセージ若しくは過去に正常に受信できなかった要求メッセージの再送メッセージ）であるので、テーブル２３を更新し（ステップＳ８５）、所定の受信処理に移る。尚、テーブル２３の更新とは、受信した要求メッセ−ジの送信元ノード番号及びＴＩＤを、テーブル２３に上書きすることである。

また、ブロードキャストである場合には、ステップＳ８６の処理後、ステップＳ８７〜Ｓ９０の処理を行う。このステップＳ８７〜Ｓ９０の処理は、参照／更新する管理テーブルが、テーブル２３ではなく、テーブル２４である点を除けば、上記ステップＳ８３〜Ｓ８５、Ｓ９０の処理と同様であるので、ここでの説明は省略する。

上述した実施例１のメッセージ交換処理について、以下、具体例を挙げて説明する。
ここでは、図９に示すノード番号０のノード（ノード０）が送信側、ノード番号１のノード（ノード１）が受信側である、１対１通信の場合について説明する。

ノード０からノード１に１対１の要求メッセージを送る場合、ノード０はテーブル２１を、ノード１はテーブル２３を使用する。ノード０はテーブル２１の宛先ノード番号が１のＴＩＤをインクリメント(250→251)して、このＴＩＤ(251) と送信元ノード番号(0)を要求メッセージに格納してノード１に送信する。ノード１はこの要求メッセージを受信するとそこからＴＩＤ (251)と送信元ノード番号(0)を取り出す。そしてテーブル２３の送信元ノード番号(0)、ＴＩＤ(250)とそれぞれ比較する（ステップＳ８３，Ｓ８４の判定を行う）。

この例では、送信元ノード番号は同じであるが（ステップＳ８３，ＮＯ）、ＴＩＤが不一致なので（ステップＳ８４，ＹＥＳ）、新しいメッセージと判定する。よって、受信したＴＩＤ (251)と送信元ノード番号(0)をテーブル２３に格納（上書き）すると共に、当該メッセージの受信処理（解析、その他）を行う。

もし、後に、この要求メッセージのリトライとしてノード０がノード１に１対１の要求メッセージを送った場合、ノード０はテーブル２１の宛先ノード番号が１のＴＩＤをインクリメントせずに(251のまま)、このＴＩＤ(251) と送信元ノード番号(0) を要求メッセージに格納してノード１に送信する。ノード１はこの要求メッセージを受信するとそこからＴＩＤ (251)と送信元ノード番号(0)を取り出す。そしてテーブル２３の送信元ノード番号(0)とＴＩＤ(251：先の要求メッセージで更新済み)をそれぞれ比較する。この場合は、送信元ノード番号もＴＩＤも一致するのでステップＳ８３、Ｓ８４の両方がＮＯ）、これが多重に同じメッセージを受信したものと判定できる。そこで、多重受信したメッセージを破棄する（ステップＳ９０）。

次に、ノード０からブロードキャストする場合を例にして説明する。
ノード０からブロードキャストで要求メッセージを送る場合、ノード０はテーブル２２を、ノード０以外はテーブル２４を使用する。ノード０はテーブル２２のＴＩＤをインクリメント(100→101)して、このＴＩＤ(101) と送信元ノード番号(0) を要求メッセージに格納して送信する。ノード０以外の各ノードはこの要求メッセージを受信するとそこからＴＩＤ (101)と送信元ノード番号(0)を取り出す。そしてテーブル２４の送信元ノード番号(0)、ＴＩＤ(100)とそれぞれ比較する（ステップＳ８７，Ｓ８８の処理を実行）。

この例では、送信元ノード番号は同じであるが（ステップＳ８７，ＮＯ）、ＴＩＤが不一致なので（ステップＳ８８，ＹＥＳ）、受信した要求メッセージは新しいメッセージであると判定する。よって、受信した要求メッセージのＴＩＤ (101)と送信元ノード番号(0)をテーブル２４に格納（上書き）すると共に、当該メッセージの受信処理（解析、その他）を行う。

その後、もし、この要求メッセージを多重化してノード０からブロードキャストで要求メッセージを送る場合、ノード０はテーブル２２のＴＩＤをインクリメントせずに(101のまま)、このＴＩＤ(101) と送信元ノード番号(0) を要求メッセージに格納して送信する。ノード０以外の各ノードはこの要求メッセージを受信するとそこからＴＩＤ (101)、送信元ノード番号(0)を取り出して、テーブル２４の送信元ノード番号(0)、ＴＩＤ(101：先の要求メッセージで更新済み)とそれぞれ比較する。

この例では、送信元ノード番号もＴＩＤも一致するので（ステップＳ８７，Ｓ８８の両方がＮＯ）、これが多重に同じメッセージを受信したものだと判定できる。そこで、多重受信したメッセージを破棄する。

次に、以下、実施例２について説明する。
実施例２は、実施例１と比較すると、図１２（ｂ）に示すように、受信側のＴＩＤ管理テーブルが、１対１とブロードキャストで共用するテーブルとなっている点が異なる。

実施例２においても、送信側は、実施例１と同様、図１２（ａ）に示すように、送信側のＴＩＤ管理テーブルは、管理テーブル３１（１対１用）も管理テーブル３２（ブロードキャスト用）も、従来の管理テーブル１０１，１０２と同様である。よって、図１０に送信側のＴＩＤ生成処理（図５（ｂ）のステップＳ３２の処理）の詳細フローチャートを示すが、これは従来の図２８に示すＴＩＤ生成処理と同様である。すなわち、図１０のステップＳ１０１〜Ｓ１０７の処理は、図２８のステップＳ４０１〜Ｓ４０７と同様である。よって、ここでは特に説明しない。

一方、受信側のＴＩＤ管理テーブル３３は、図１２（ｂ）に示す通り、実施例１と同様に従来の図２７（ｂ）のように各送信元ノード毎に管理する必要はなくなっており（管理テーブルを小さくできる）、更に１対１用とブロードキャスト用とが共用のテーブルとなっている。そして、受信側ノードでは、図６（ａ）のステップＳ５４の多重検出処理は、図１１に示す処理を行う。

図１１は、実施例２における受信側ノードの多重検出処理の詳細フローチャート図である。
図１１において、受信側ノードは、まず、受信した要求メッセージから送信元ノード番号とＴＩＤを取り出すと共に（ステップＳ１１１）、このメッセージがブロードキャストか１対１かを判定し（ステップＳ１１２）、１対１である場合には（ステップＳ１１２，ＮＯ）図１２（ｂ）のＴＩＤ管理テーブル３３における判定フラグ３３ａとは別に用意されている不図示の判定フラグをＯＮ状態し（ステップＳ１１３）、ブロードキャストである場合には（ステップＳ１１２，ＹＥＳ）この不図示の判定フラグをＯＦＦ状態にする（ステップＳ１１４）。尚、ここでは、判定フラグがＯＮの場合は“１対１”、ＯＦＦの場合は“ブロードキャスト”を意味するものであることが予め設定・登録されているものとする。

そして、上記受信した要求メッセージによる送信元ノード番号、ＴＩＤ、不図示の判定フラグと、ＴＩＤ管理テーブル３３における送信元ノード番号、ＴＩＤ、判定フラグ３３ａとを、それぞれ比較して、一致／不一致を判定する（ステップＳ１１５，Ｓ１１６，Ｓ１１７）。そして、もし、全てが一致する場合には（ステップＳ１１５，Ｓ１１６，Ｓ１１７の全てがＮＯ）、この要求メッセージは多重に同じメッセージを受信したものだと判定し、受信した要求メッセージを破棄する（ステップＳ１１９）。

一方、それ以外の場合、すなわち送信元ノード番号が不一致の場合（ステップＳ１１５，ＹＥＳ）、または送信元ノード番号は一致するが（ステップＳ１１５，ＮＯ）ＴＩＤが不一致である場合（ステップＳ１１６，ＹＥＳ）、あるいは送信元ノード番号もＴＩＤも一致するが（ステップＳ１１５，Ｓ１１６の両方がＮＯ）判定フラグが不一致である場合には（ステップＳ１１７，ＹＥＳ）、受信した要求メッセージは新しいメッセージであると判定する。よって、受信した要求メッセージの送信元ノード番号、ＴＩＤ、及び不図示の判定フラグによってテーブル３３を更新し（ステップＳ１１８）、その後、当該メッセージの受信処理（解析、その他）を行う。

上記ステップＳ１１７の処理を行うことで、例えば仮に同一の送信元ノードから１対１の要求メッセージとブロードキャストの要求メッセージが連続して送られてきて、偶然、両者のＴＩＤが同じであった場合にも、これらが別のメッセージであることが判別できる。

上述した実施例２のメッセージ交換処理について、以下、具体例を挙げて説明する。
ここでは、図１２に示すノード番号０のノード（ノード０）が送信側、ノード番号１のノード（ノード１）が受信側である、１対１通信の場合について説明する。

ノード０からノード１に１対１の要求メッセージを送る場合、ノード０はテーブル３１を、ノード１はテーブル３３を使用する。ノード０はテーブル３１の宛先ノード番号が１のＴＩＤをインクリメント(250→251)して、このＴＩＤ(251) と送信元ノード番号(0) を要求メッセージに格納してノード１に送信する。ノード１はこの要求メッセージを受信するとそこからＴＩＤ (251)と送信元ノード番号(0)を取り出すとともに、上記不図示の判別フラグをＯＮ状態（１対１を意味する）にする。これら各々を、テーブル３３の送信元ノード番号(0)、ＴＩＤ(250)、判別フラグ(ＯＮ状態；１対１)とそれぞれ比較する（ステップＳ１１５〜Ｓ１１７の処理）。

この例では、送信元ノード番号と判別フラグは同じであるがＴＩＤが不一致となるので、受信した要求メッセージは新しいメッセージであると判定する。そして、受信した要求メッセージのＴＩＤ (251)と送信元ノード番号(0)、及び不図示の判別フラグ(ＯＮ状態)をテーブル３３に格納（上書き）する。

もし、後に、この要求メッセージのリトライとしてノード０からノード１に１対１の要求メッセージを送る場合、ノード０はテーブル３１の宛先ノード番号が１のＴＩＤをインクリメントせずに(251のまま)、このＴＩＤ(251) と送信元ノード番号(0) を要求メッセージに格納してノード１に送信する。ノード１はこの要求メッセージを受信するとそこからＴＩＤ (251)と送信元ノード番号(0)を取り出すとともに、上記不図示の判別フラグをＯＮ状態（１対１）にする。そしてこれら各々を、テーブル３３の送信元ノード番号(0)、ＴＩＤ(251：先の要求メッセージで更新済み)、判別フラグ３３ａ(１対１)とそれぞれ比較する（ステップＳ１１５〜Ｓ１１７の処理）。

この例では、送信元ノード番号、ＴＩＤ、判別フラグの全てが一致するので、これが多重に同じメッセージを受信したものだと判定できる。そこで、多重受信したメッセージを破棄する。

上記１対１のメッセージ交換の後に、続けて、ノード０からブロードキャストで要求メッセージを送信した場合について説明する。この場合、図１２（ａ）に示すように、元々、テーブル３１における宛先ノード番号０のＴＩＤと、テーブル３２のＴＩＤは、両方とも２５０であった為、両方ともインクリメントすると２５１になるので、ノード１においては、もし上記判別フラグ３３ａがないと、両者を区別できない為、今回のブロードキャストでの要求メッセージが多重に同じメッセージを受信したものと判定してしまうが、判別フラグ３３ａを用いることで、このような誤判定は生じなくなる。

すなわち、上記状況においてノード０からブロードキャストで要求メッセージを送る場合、ノード０はテーブル３２を、ノード０以外の各ノードはテーブル３３を使用する。ノード０はテーブル３２のＴＩＤをインクリメント(250→251)して、このＴＩＤ(251) と送信元ノード番号(0) を要求メッセージに格納して送信する。ノード０以外の各ノードはこの要求メッセージを受信するとそこからＴＩＤ (251)と送信元ノード番号(0)を取り出すとともに、上記不図示の判別フラグをＯＦＦ状態（ブロードキャスト）にする。これら各々を、テーブル３３の送信元ノード番号(0)、ＴＩＤ(251：先の１対１要求メッセージで更新済み)、判別フラグ３３ａ(ＯＮ状態；１対１)と、それぞれ比較する（ステップＳ１１５〜Ｓ１１７の処理）。

このとき、他のノードはともかく、ノード１においては、送信元ノード番号とＴＩＤの両方が同じとなってしまうが、判別フラグが不一致となるので、受信した要求メッセージは新しいメッセージであると判定できる。そして、受信した要求メッセージのＴＩＤ (101)と送信元ノード番号(0)、及び不図示の判別フラグ(ＯＦＦ状態)の値をテーブル３３に格納（上書き）する。

その後、もし、この要求メッセージを多重化してノード０からブロードキャストで要求メッセージを送る場合、ノード０はテーブル３２のＴＩＤをインクリメントせずに（251のまま）、このＴＩＤ(251) と送信元ノード番号(0) を要求メッセージに格納して送信する。ノード０以外の各ノードはこの要求メッセージを受信するとそこからＴＩＤ (251)と送信元ノード番号(0)を取り出すとともに、上記不図示の判別フラグをＯＦＦ状態にする。そして、これら各々を、テーブル３３の送信元ノード番号(0)とＴＩＤ(251：先の要求メッセージで更新済み)と判別フラグ(ＯＦＦ状態)と、それぞれ比較する（ステップＳ１１５〜Ｓ１１７の処理）。

この場合、送信元ノード番号、ＴＩＤ、判別フラグの全てが一致するので、これが多重に同じメッセージを受信したものだと判定できる。そこで、多重受信したメッセージを破棄する。

次に、以下、実施例３について説明する。
上記実施例１，２では、従来と比較して、受信側の管理テーブルを削減した（各ノード毎に管理しなくて済むようにした）が、実施例３では送信側の管理テーブルを削減する（各ノード毎に管理しなくて済む）。また、受信側においても１対１用とブロードキャスト用とを共用にすることができる。尚、実施例３においても、要求から応答までを１トランザクションとし、応答完了するまでの間はマスタノード３は他のノードには送信権を与えないようにしている。

まず、既に従来技術で説明したように、従来において送信側ノードで各宛先ノード毎にＴＩＤを管理する必要があった理由は、もし１つのＴＩＤで管理すると、例えばＴＩＤは１〜２５５を使うとして（２５５までいったら再び１に戻る）、あるノード（受信側ノード）とメッセージ交換した後に、ＴＩＤの更新が丁度一周したときに、再びこのノードに要求メッセージを送ると、ＴＩＤの値は前回と同じになるので、これが多重に同じメッセージを受信したものだと誤判定されてしまうからである。

この誤判定は、受信側ノードにおいて、ある送信側ノードとのメッセージ交換した後に、この送信側ノードが次のトランザクションに移行している（他ノード宛メッセージを出している）ことを認識していない為に生じる。ここで、１対１通信に関して、通常、各ノードは、自ノード宛以外のメッセージも受信しているが、宛先が自ノードではない場合には直ちにこのメッセージを破棄している。

実施例３では、他ノード宛のメッセージを受信すると、直ちには破棄せずに、まず、このメッセージの送信元ノード番号を参照して、例えば図１５（ｂ）に示す自己のＴＩＤ管理テーブル４２において同じノード番号のＴＩＤの値を初期化する（０にする）。ここで、０にする理由は、上記の例では、ＴＩＤは１〜２５５を使う為、０は使っていないからである。よって、０にする例に限らず、ＴＩＤとして使用しない値（この例では２５６以降等）とすればよい。あるいは次のトランザクションに移行したことを示す何らかの特定の情報、記号等にしてもよい（この場合は、ＴＩＤの比較処理自体を行わない。特殊な情報、記号等が格納されていることを以って次のトランザクションに移行したものと判定する）。但し、ここでの説明及び以下の実施例４以降の説明においては、ＴＩＤの値を０にする例を用いて説明する。

上記のように強制的に０にすることで、後に上記ＴＩＤの値を初期化したノード番号のノードから要求メッセージが来た場合には、必ずＴＩＤは不一致となるので、上記誤判定は生じない。勿論、これが再送メッセージである可能性はない（上記の通り、送信側ノードが次のトランザクションに移行していることを以って、０にしているので）。

このようにすることで、送信側ノードでは、宛先毎にＴＩＤを管理する必要が無くなる。また、そもそも従来では宛先毎にＴＩＤを管理しているためにブロードキャストのＴＩＤも別に管理していたが、宛先毎ではなくなるのでブロードキャストも区別して管理する必要が無くなる。これより、図１５（ａ）に示すように、送信側のＴＩＤ管理テーブル４１は、１対１とブロードキャスト共用でＴＩＤを１つ管理すれば済むようになる。

さらに、送信側で１対１とブロードキャストとを区別して管理しなくなるので、受信側でも、図１５（ｂ）に示すように１対１とブロードキャストとで管理テーブルを共用することができる（但し、各送信元ノード毎に管理する必要はある）。

図１３、図１４に、実施例３における送信側／受信側ノードの処理フローチャートを示す。
図１３は、送信側ノードのＴＩＤ生成処理のフローチャート図である。

図１３において、まず、送信する要求メッセージが初送かリトライかを判定する（ステップＳ１２１）。初送である場合には（ステップＳ１２１、ＹＥＳ）テーブル４１のＴＩＤの値をインクリメントする（ステップＳ１２２）。リトライである場合には（ステップＳ１２１，ＮＯ）ＴＩＤの値はそのままとする。

そして、テーブル４１のＴＩＤの値と送信元ノード番号（送信元ノード番号）とを要求メッセージに格納して（ステップＳ１２３）、当該要求メッセージを送信する。
テーブル４１のようにＴＩＤを１つ管理すれば済むようになったので、図１３に示すように、ＴＩＤ生成処理は、従来の図２８の処理と比べ、簡略化される。

図１４（ａ）は、受信側ノードの多重検出処理のフローチャート図である。
図１４（ａ）において、まず、受信した要求メッセージから送信元ノード番号とＴＩＤを取り出して（ステップＳ１３１）、テーブル４２において同じ送信元ノード番号のＴＩＤと比較する（ステップＳ１３２）。もし、ＴＩＤが一致すれば（ステップＳ１３２，ＮＯ）、受信した要求メッセージは多重に同じメッセージを受信したものだと判定し、当該要求メッセージは破棄して（ステップＳ１３４）処理を終了する。もし、ＴＩＤが不一致であれば（ステップＳ１３２，ＹＥＳ）、テーブル４２における上記送信元ノード番号に対応するＴＩＤの値を更新する。つまり、要求メッセージに格納されていたＴＩＤの値を上書きする（ステップＳ１３３）。そして、引き続き所定の要求メッセージ受信処理を実行する。

実施例３では、図１４（ａ）に示す通り、受信側ノードの多重検出処理も、従来の図２９の処理と比べ、簡略化される。
但し、これだけでは、上記誤判定が生じる可能性がある。

それ故に、実施例３では、常時、他ノード宛のメッセージを監視しており、他ノード宛の要求メッセージを受信する毎に、図１４（ｂ）に示す処理を実行する。
図１４（ｂ）に示すように、他ノード宛の要求メッセージを受信すると、この要求メッセージから送信元ノード番号を取り出して（ステップＳ１４１）、テーブル４２において同じ送信元ノード番号のＴＩＤの値を初期化（０）する（ステップＳ１４２）。尚、この例に限らず、他ノード宛の要求メッセージ内のＴＩＤによってテーブル４２を更新するようにしてもよい。

これによって、既に説明してあるように、上記誤判定が生じることはなくなる。
上述した実施例３の処理について、以下、具体例を挙げて説明する。ここでは、ＴＩＤの値を初期化（０）する例を用いて説明する。

ここでは、まず、図１５に示す例においてノード番号０のノード（ノード０）が送信側、ノード番号１のノード（ノード１）又はノード０以外の全ノードが受信側となる場合を例にして説明する。

ノード０からノード１に１対１の要求メッセージを送る場合、もしくはノード０からブロードキャストの要求メッセージを送る場合、ノード０はテーブル４１を、ノード１はテーブル４２を使用する。

ノード１に１対１の要求メッセージを送信する場合、ノード０はテーブル４１のＴＩＤをインクリメント(250→251)して、このＴＩＤ(251) と送信元ノード番号(0) を要求メッセージに格納してノード１に送信する。ノード１はこの要求メッセージを受信するとそこからＴＩＤ (251)と送信元ノード番号(0)を取り出す。そしてテーブル４２の送信元ノード番号が０のＴＩＤ(250)と比較する。この場合、ＴＩＤは不一致となるので、受信した要求メッセージは新しいメッセージであると判定する。そして、受信したＴＩＤ (251)をテーブル４２に格納（上書き）して、所定の受信処理（解析等）を実行する。

その後、この要求メッセージのリトライとしてノード０からノード１に要求メッセージを送る場合、ノード０はテーブル４１のＴＩＤはインクリメントせずに(251のまま)、このＴＩＤ(251) と送信元ノード番号(0) を要求メッセージに格納してノード１に送信する。ノード１はこの要求メッセージを受信するとそこからＴＩＤ (251)と送信元ノード番号(0)を取り出す。そしてテーブル４２の送信元ノード番号０のＴＩＤ(251：先の要求メッセージで更新済み)と比較する。この場合、ＴＩＤが一致するので、これが多重に同じメッセージを受信したものだと判定し、多重受信したメッセージを破棄する。

そして、その後、ノード０から例えばノード２に１対１の要求メッセージを送る場合、ノード０はテーブル４１のＴＩＤをインクリメント(251→252)して、このＴＩＤ(252) と送信元ノード番号(0) を要求メッセージに格納してノード２に送信する。ノード１はこの要求メッセージは自分宛ではないがそれを受信すると、そこから送信元ノード番号(0)を取り出す。そしてテーブル４２の送信元ノード番号０のＴＩＤ(251：先の要求メッセージで更新済み)を初期化(0)する。

その後も、ノード０は、ノード１以外の他のノードに対して１対１の要求メッセージ送信処理を繰り返し、当然その都度テーブル４１のＴＩＤはインクリメントされ、ＴＩＤの値は２５５になった次は１に戻り、更にインクリメントし続けた結果、ＴＩＤの値が再び２５０になっていたものとする。

この状況でノード０がノード１に１対１の要求メッセージを出す場合、ノード０はテーブル４１のＴＩＤをインクリメント(250→251)して、このＴＩＤ(251) と送信元ノード番号(0) を要求メッセージに格納してノード１に送信する。ノード１はこの要求メッセージを受信するとそこからＴＩＤ (251)と送信元ノード番号(0)を取り出す。そしてテーブル４２の送信元ノード番号が０のＴＩＤ(0)と比較する。テーブル４２のＴＩＤの値‘０’は、上記の通り、通常のＴＩＤの値としては有り得ないようにしているので、比較の結果は必ず不一致になる。よって、受信した要求メッセージは新しいメッセージであると、正しく判定できる。もし、上記初期化を行っていないと、上記の通り、テーブル４２の送信元ノード番号が０のＴＩＤの値は‘２５１’となっているので、比較の結果は一致となり、新しいメッセージであるにも係わらず多重に同じメッセージを受信したものだと誤判定してしまうことになるが、実施例３ではこのような誤判定を防ぐことができる。

以下、実施例４について説明する。
実施例４は、上記実施例３の延長線上の実施例であり、受信側のＴＩＤ管理テーブルも上記実施例２等と同様に小さくしている例である（実施例３においても小さくすることは出来るが、実施例３はあえて送信側のみ小さくする例を示したに過ぎない）。

すなわち、送信側では、実施例３と同様、図１８（ａ）に示すＴＩＤ管理テーブル５１のみで済むようになる。また、受信側のＴＩＤ管理テーブルは、実施例１、２のように各送信元ノード毎に管理する必要が無くなるだけでなく、上記実施例３によってブロードキャストと１対１の区別をつける必要がなくなるので、図１８（ｂ）のＴＩＤ管理テーブル５２のように送信元ノード番号とＴＩＤを１組記憶すれば良くなる。

さらに、受信側ノードにおいて他ノード宛メッセージでＴＩＤの初期化をする判定を簡略化できる。前述の実施例３では、受信側ＴＩＤ管理テーブルが送信元毎にＴＩＤを管理しているため、受信した他ノード宛てのメッセージ内の送信元ノード番号を見て該当するＴＩＤを初期化（又は更新）する必要があった。しかし、実施例４では受信側でもＴＩＤを１組記憶しているだけなので、他ノード宛のメッセージを受信したら、その宛先を見ることなく管理テーブルのＴＩＤを初期化（または更新）することができる（上記の通り要求から応答までが同じトランザクションになっているので、他ノード宛のメッセージを受信するということは別のトランザクションに移ったことを示している）。

図１６、図１７に、実施例４における送信側／受信側ノードの処理フローチャートを示す。
図１６は、送信側ノードのＴＩＤ生成処理のフローチャート図である。

図１６のステップＳ１５１〜Ｓ１５３の処理は、図１３のステップＳ１２１〜Ｓ１２３の処理と同様であるので、ここでの説明は省略する。
図１７（ａ）は、受信側ノードの多重検出処理のフローチャート図である。

図１７（ａ）において、まず、受信した要求メッセージから送信元ノード番号とＴＩＤを取り出して（ステップＳ１６１）、これら各々を、テーブル５２に記憶されている送信元ノード番号、ＴＩＤとそれぞれ比較し、もし両方とも一致した場合（ステップＳ１６２，Ｓ１６３の両方でＮＯ）、受信した要求メッセージは多重に同じメッセージを受信したものだと判定し、当該要求メッセージは破棄して（ステップＳ１６５）処理を終了する。それ以外の場合（少なくとも一方が不一致）には、テーブル５２を更新する（ステップＳ１６４）。つまり、受信した要求メッセージの送信元ノード番号、ＴＩＤを上書きする。そして、引き続き所定の要求メッセージ受信処理を実行する。

また、実施例３と同様、常時、他ノード宛のメッセージを監視しており、他ノード宛の要求メッセージを受信する毎に、図１７（ｂ）に示す処理を実行する。
図１７（ｂ）に示すように（既に述べたように）、実施例４では、実施例３とは異なり、他ノード宛の要求メッセージを受信することを以って、テーブル５２のＴＩＤの値を初期化（０）する（ステップＳ１７１）。つまり、送信元ノード番号を参照する処理を省ける。尚、図では、初期化することのみ示しているが、他ノード宛の要求メッセージ内のＴＩＤによってテーブル５２を更新するようにしてもよい。

これによって、実施例３と同様、上記誤判定が生じることはなくなる。
上述した実施例４の処理について、以下、具体例を挙げて説明する。ここでは、他ノード宛の要求メッセージを受信することを以って、テーブル５２のＴＩＤの値を初期化（０）する例を用いて説明する。

ここでは、まず、図１８に示す例においてノード番号０のノード（ノード０）が送信側、ノード番号１のノード（ノード１）又はノード０以外の全ノードが受信側となる場合を例にして説明する。

ノード０からノード１に１対１の要求メッセージを送る場合（初送メッセージ）、もしくはノード０からブロードキャストの要求メッセージを送る場合、ノード０はテーブル５１を、ノード１はテーブル５２を使用する。ノード０はテーブル５１のＴＩＤをインクリメント(250→251)して、このＴＩＤ(251) と送信元ノード番号(0) を要求メッセージに格納してノード１に送信する。ノード１はこの要求メッセージを受信するとそこからＴＩＤ (251)と送信元ノード番号(0)を取り出す。そしてこれらをテーブル５２の送信元ノード番号(0) 、ＴＩＤ(250) とそれぞれ比較する。

この場合、送信元ノード番号は同じであるが、ＴＩＤが不一致なので、新しいメッセージと判定する。そして、受信したＴＩＤ (251) と送信元ノード番号(0)をテーブル５２に格納（上書き）する。

その後、もし、この要求メッセージのリトライとして番号０のノードから番号１のノードに要求メッセージ（再送メッセージ）を送る場合、ノード０はテーブル５１のＴＩＤをインクリメントせずに(251のまま)、このＴＩＤ(251) と送信元ノード番号(0) を要求メッセージに格納してノード１に送信する。ノード１はこの要求メッセージを受信するとそこからＴＩＤ (251)と送信元ノード番号(0)を取り出す。そして、これらを、テーブル５２の送信元ノード番号(0)、ＴＩＤ(251：先の要求メッセージで更新済み)とそれぞれ比較する。その際、上記実施例１，２と同様、上記初送メッセージ受信から再送メッセージ受信までの間に他のノードから要求メッセージを受信することはないので（別のトランザクションは発生しない）、テーブル５２は更新されていないので、上記の通り送信元ノード番号もＴＩＤも一致する。よって、受信した要求メッセージが多重に同じメッセージを受信したものだと判定できる。そこで、多重受信したメッセージを破棄する。

そして、その後、ノード０からノード１以外のノード（例えばノード２）に１対１の要求メッセージを送る場合、ノード０はテーブル４１のＴＩＤをインクリメント(251→252)して、このＴＩＤ(252) と送信元ノード番号(0) を要求メッセージに格納してノード２に送信する。ノード１はこの要求メッセージは自分宛ではないがそれを受信すると、そこから送信元ノード番号(0)を取り出す。そしてテーブル５２の送信元ノード番号０のＴＩＤ(251：先の要求メッセージで更新済み)を初期化(0)する。尚、初期化(0)する例に限らず、ＴＩＤとして使用しない値等にすればよいことは既に述べたが、本実施例では、ＴＩＤとして使用する値にしても構わない。すなわち、上記他のノード宛の要求メッセージに含まれるＴＩＤ(252)によってテーブル５２の送信元ノード番号０のＴＩＤを更新(251→252)してもよい。これは実施例３においても同様である。要は、ノード０側でＴＩＤの更新が一周して再び２５１になってＴＩＤ(251)の要求メッセージを送ってきたときに、これが別のメッセージである（多重受信ではない）ことが判別できるようにしていれば、何でもよいのである。

その後も、ノード０は、ノード１以外の他のノードに対して１対１の要求メッセージを送る処理を繰り返し、当然その都度テーブル５１のＴＩＤはインクリメントされ、ＴＩＤの値は２５５になった次は１に戻り、更にインクリメントし続けた結果、ＴＩＤの値が再び２５０になっていたものとする。また、その間、ノード１は、一度も他のノードから要求メッセージ（ブロードキャストも含めて）を受け取ることは無かったものとする。

この状況でノード０がノード１に１対１の要求メッセージを出す場合、ノード０はテーブル５１のＴＩＤをインクリメント(250→251)して、このＴＩＤ(251) と送信元ノード番号(0) を要求メッセージに格納してノード１に送信する。ノード１はこの要求メッセージを受信するとそこからＴＩＤ (251)と送信元ノード番号(0)を取り出す。そしてテーブル５２の送信元ノード番号(0)、ＴＩＤ(0)と比較する。テーブル５２のＴＩＤの値‘０’は、上記の通り、通常のＴＩＤの値としては有り得ない値であるので、比較の結果は必ず不一致になる。よって、受信した要求メッセージは新しいメッセージであると、正しく判定できる。もし、上記初期化を行っていないと、上記の通り、テーブル５２には送信元ノード番号(0)、ＴＩＤ(251)が格納されているので、比較の結果は一致となり、新しいメッセージであるにも係わらず多重に同じメッセージを受信したものだと誤判定してしまうことになるが、実施例４においてもこのような誤判定を防ぐことができる。

以下、実施例５について説明する。
上記実施例１〜４では、各送信側ノード毎に個別にＴＩＤを更新（インクリメント）・管理していたが、実施例５ではシステムでＴＩＤを一元管理する。すなわち、ＴＩＤはマスタノードで例えば図２１（ａ）に示すＴＩＤ管理テーブル６１によって一元管理する。よって、マスタノード以外の各ノードは、ＴＩＤ生成処理（インクリメント）は行わないし、送信側ＴＩＤ管理テーブルも保持する必要なく、図２１（ｂ）に示す受信側ＴＩＤ管理テーブル６２のみを保持・管理するば済むようになる。尚、実施例５においても、要求から応答までを同じトランザクションとし、マスタノードは１つのトランザクションが完結するまで、他のノードにはトークンを与えないようにする点は、実施例１〜４と同じである。

マスタノードは、任意のノードから送信権要求があると、トークン（送信権）を要求元ノードに与えるが、実施例５ではその際、マスタノードは自己が管理するＴＩＤ管理テーブル６１によってＴＩＤを更新（インクリメント）して、このＴＩＤをトークンに含めて要求元ノードに与える。

送信権要求元ノードはトークンに含まれるＴＩＤを取り出して要求メッセージに格納して送信すればよい。このようにマスタノードでＴＩＤを一元管理すると、送信元のノード番号とＴＩＤの関係は無くなり、実施例４では受信側で送信元ノード番号とＴＩＤを記憶していたものに対し、実施例５ではＴＩＤだけを記憶すれば良くなる。

また、実施例４では受信側ノードにおいて他ノード宛メッセージ受信を以ってＴＩＤを更新または初期化していたが、実施例５では受信側ノードはマスタノードでＴＩＤ更新が行われたことを認識することを以って、ＴＩＤの初期化もしくは更新を行う。この認識の方法は、以下の４つのうちの何れかを用いればよい。
・他ノード宛の要求メッセージを受信すると、このメッセージ内のＴＩＤによってテーブル６２を更新（上書き）する。
・他ノード宛の要求メッセージ受信を以って（トリガとして）、テーブル６２のＴＩＤを初期化。
・自分宛でも他ノード宛でも良く、宛先に関係なくトークンを受信した場合、このトークン内のＴＩＤとテーブル６２のＴＩＤとを比較して、不一致ならテーブル６２のＴＩＤを初期化。
・他ノード宛のトークン受信を以って（トリガとして）、テーブル６２のＴＩＤを初期化。

上記いずれの方法でも、マスタノードでＴＩＤの更新が行われたことを認識することができる。
図１９、図２０に、実施例５におけるマスタノード／送信側ノード／受信側ノードの処理フローチャートを示す。

図１９（ａ）は、マスタノードのＴＩＤ生成処理のフローチャート図である。
つまり、上記の通り、実施例５では、ＴＩＤはシステムで一意のものとしマスタノードで一元管理するので、ＴＩＤ生成処理はマスタノードで行う（送信側ノードでは行わない）。

図１９（ａ）において、マスタノードは、任意のノードから送信権要求があると、それが前のサイクルで送信権を与えたノードから継続して要求されたもの（継続送信権要求）であるか否かを判定し（ステップＳ１８１）、継続送信権要求である場合には（ステップＳ１８１，ＹＥＳ）、テーブル６１のＴＩＤを更新することなく、このＴＩＤをトークンに含めて（ステップＳ１８３）、要求元ノードにトークンを送信する。一方、継続送信権要求ではない場合には（ステップＳ１８１，ＮＯ）、テーブル６１のＴＩＤを更新し（＋１インクリメントし）（ステップＳ１８２）、この更新後のＴＩＤをトークンに含めて（ステップＳ１８３）、要求元ノードにトークンを送信する。

図１９（ｂ）は、送信側ノードにおける要求メッセージ送信処理の一部であるＴＩＤ抽出処理を示すフローチャート図である。
特に図示していないが、要求メッセージ送信を行いたい送信側ノードは、まず、制御時間帯において、マスタノードに対して、送信権要求を行う。これに対して図１９（ａ）の処理によってトークンが与えられた場合には、図１９（ｂ）に示すように、まずトークンからＴＩＤを取り出す（ステップＳ１９１）。そして、取り出したＴＩＤを要求メッセージに格納して（ステップＳ１９２）、当該要求メッセージを送信する。

図２０（ａ）は、受信側ノードにおける多重検出処理のフローチャート図である。
図２０（ａ）において、受信側ノードは、図１９（ｂ）の処理によって送られてくる要求メッセージを受信すると、この要求メッセージからＴＩＤを取り出して（ステップＳ２０１）、これをテーブル６２のＴＩＤと比較する（ステップＳ２０２）。

もしＴＩＤが一致すれば（ステップＳ２０２，ＮＯ）、多重に同じメッセージを受信したものとし、この要求メッセージは破棄する（ステップＳ２０４）。もし、ＴＩＤが不一致であれば（ステップＳ２０２，ＹＥＳ）、この要求メッセージは新しいメッセージであるとし、テーブル６２を更新（要求メッセージのＴＩＤを格納）すると共に（ステップＳ２０３）、所定の受信処理（メッセージ解析・実行等）を行う。

実施例５では、上述してあるように、ＴＩＤをシステムで一意のものとしマスタノードで一元管理するが、このようにしても、受信側ノードで認識できないままＴＩＤが更新され続けて丁度一周したときに偶然、テーブル６２のＴＩＤと同じＴＩＤを含む要求メッセージが送られてきた場合、これが新たなメッセージであることが認識できず、このメッセージを間違って破棄してしまう、という問題は生じる。

この問題に対して、実施例５では、図２０（ｂ）に示す４つのフローチャート（４つの方法）の何れかを実行することで、上記問題が生じないようにできる。
図２０（ｂ）に示す第１の方法では、他ノード宛の要求メッセージを受信すると、この要求メッセージからＴＩＤを取り出して（ステップＳ２１１）、テーブル６２を更新する（取り出したＴＩＤをテーブル６２に格納する）（ステップＳ２１２）。

図２０（ｂ）に示す第２の方法では、他ノード宛の要求メッセージを受信したことを以って（そのＴＩＤを取り出すことなく）、テーブル６２のＴＩＤを初期化（０）する（ステップＳ２２１）。

図２０（ｂ）に示す第３の方法では、自分宛でも他ノード宛でも宛先に関係なくトークンを受信した場合、このトークンに含まれるＴＩＤを取り出して（ステップＳ２３１）、取り出したＴＩＤとテーブル６２のＴＩＤとを比較し、不一致の場合には（ステップＳ２３２，ＹＥＳ）、テーブル６２を初期化（０）する（ステップＳ２３３）。一方、ＴＩＤが一致した場合は（ステップＳ２３２，ＮＯ）、そのまま処理を終了する。

図２０（ｂ）に示す第４の方法では、他ノード宛のトークンを受信したことを以って（そのＴＩＤを取り出すことなく）、テーブル６２のＴＩＤを初期化（０）する（ステップＳ２４１）。

上述した実施例５の処理について、以下、具体例を挙げて説明する。
ここでは、ノード番号０のノード（ノード０）が送信側、ノード番号１のノード（ノード１）又はノード０以外の全ノードが受信側となる場合を例にして説明する。マスタノード、ノード１で管理するＴＩＤは、図２１に示す通り、両方とも２５０であったものとする。

ノード０からノード１に１対１の要求メッセージを送る場合、もしくはノード１がブロードキャストの要求メッセージを送る場合、まずノード０はマスタノードに対して送信権要求を出し、ノード０からの送信権要求を受けたマスタノードはテーブル６１のＴＩＤをインクリメント(250→251)して、このＴＩＤ(251) をトークンに格納してノード０に送信する。このトークンを受け取ったノード０は、このトークンに含まれるＴＩＤを要求メッセージに格納してノード１に送信する。ノード１はこの要求メッセージを受信するとそこからＴＩＤ (251)を取り出して、テーブル６２のＴＩＤ(250)と比較する。この場合、ＴＩＤは不一致となるので、受信した要求メッセージは新しいメッセージであると判定する。そして、受信したＴＩＤ (251) をテーブル６２に格納（上書き）する。そして、所定の受信処理（メッセージ解析・実行等）を開始する。

また、ノード１は、ノード０に対してＡＣＫを送信する。但し、ここでは、ノイズ等の影響でノード０はＡＣＫを受信できなかったとする。
そこで、ノード０は、この要求メッセージのリトライとしてノード１に再送メッセージを送るものとし、マスタノードに対して送信権要求を送る。マスタノードは同じノード(0)からの継続した送信権要求を受け取ることになるのでテーブル６１のＴＩＤをインクリメントせずに(251のまま)、このＴＩＤ(251) をトークンに格納してノード０に送信する。このトークンを受け取ったノード０は、トークンに含まれるＴＩＤを要求メッセージに格納してノード１に送信する。ノード１はこの要求メッセージを受信するとそこからＴＩＤ (251)を取り出し、テーブル６２のＴＩＤ(251：先の要求メッセージで更新済み)と比較する。この場合、ＴＩＤが一致するのでこれが多重に同じメッセージを受信したものだと判定できる。そこで、多重受信したメッセージを破棄する。

その後、ノード１は、上記最初に受信した要求メッセージに対する応答メッセージを作成してノード０に送信し、当該メッセージ交換は終了したとする。
その後、ノード０が、ノード１以外の他のノード（例えばノード２）に１対１の要求メッセージを送る為、マスタノードに対して送信権要求を行ったとする。この場合、マスタノードは、テーブル６１のＴＩＤをインクリメント(251→252)して、このＴＩＤ(252) をトークンに格納してノード０に送信する。このトークンを受け取ったノード０は、このトークンに含まれるＴＩＤを要求メッセージに格納してノード２に送信する。

ここで、ノード１は、上記ノード０−ノード２間のメッセージ交換の為のトークンまたは要求メッセージを監視して、以下の４つの処理の何れか１つを実行する。
（１）ノード１は、上記要求メッセージは自分宛ではないがそれを受信すると、その中のＴＩＤ(252)をテーブル６２のＴＩＤ(251：先の要求メッセージで更新済み)に上書きする。
（２）ノード１は、上記要求メッセージは自分宛ではないがそれを受信すると、テーブル６２のＴＩＤ(251：先の要求メッセージで更新済み)を初期化(0)する。
（３）ノード１は、受信したトークン（宛先はなんでも良い）の中のＴＩＤ(252)とテーブル６２のＴＩＤ(251：先の要求メッセージで更新済み)を比較して、不一致なのでこれを初期化(0)する。
（４）ノード１は、自分宛ではないトークンを受信すると、テーブル６２のＴＩＤ(251：先の要求メッセージで更新済み)を初期化(0)する。

その後、上記ノード０−ノード２間のメッセージ交換は完了したものとする。
その後、再び、ノード０がノード１に１対１の要求メッセージを送る為もしくはノード０がブロードキャストの要求メッセージを送る為に、ノード０がマスタノードに送信権要求した場合、マスタノードはテーブル６１のＴＩＤをインクリメント(252→253)して、このＴＩＤ(253) をトークンに格納してノード０に送信する。トークンを受け取ったノード０は、このトークンに含まれるＴＩＤをメッセージに格納してノード１に送信する。ノード１はこの要求メッセージを受信するとそこからＴＩＤ (253)を取り出して、テーブル６２のＴＩＤ(先に初期化もしくは252を上書きされた)と比較する。そうすると、ＴＩＤが不一致なので新しいメッセージと判定できる。そして、受信したＴＩＤ (253)をテーブル６２に格納する。

次に、以下、実施例６について説明する。実施例６は、上記実施例１〜５に追加する実施例である。すなわち、実施例１〜５では、多重受信の判定を行うことまでを説明し、新しいメッセージを受信したときの応答メッセージ作成・送信、要求側での応答メッセージの正常な受取完了までの処理については説明していなかった。

実施例６では、これについて説明する。但し、上記実施例１〜５は、図４〜図６の処理をベースにしていたが、実施例６ではこれとは多少異なり、１対１通信の場合でもＡＣＫを返さない処理をベースにするものとする。ＡＣＫを返さない理由は後に説明する。勿論、これは一例であり、実施例６は図４〜図６の処理をベースにしてもよい。但し、この場合、後述するＮａｃｋ返信するような事態は生じなくなるし、よってポーリングにＴＩＤを格納する必要もなくなる。

実施例６において、まず、メッセージ交換処理に関しては、受信側ノードでは、上記受信側のＴＩＤ管理テーブルだけでなく、応答保持情報、処理中フラグを用いて処理を行う。

既に実施例１〜５で説明してある通り、受信した要求メッセージが新たなメッセージであると判定した場合、そのメッセージを受け入れてＴＩＤを更新するが、この要求メッセージ受け入れの際には、更に、上記応答保持情報(応答メッセージの準備が完了して保持していることを示す情報)をクリア（０）する。

その後、受け入れた要求メッセージによって要求された処理を終了し、応答メッセージを準備できたら、応答保持情報をセット（１）する。
上記の通り、送信側ノードでは、要求メッセージを送信後、１又は複数回、ポーリングを送信する。受信側ノードでは、このポーリングを受信する毎に、応答保持情報を参照して、それが立っていれば（１）応答メッセージを送信し、立っていなければ（０）予め用意しておいた“処理中を通知するためのフレーム”を送信する。

このようにすれば、要求メッセージに対する処理中にポーリングが来てもそれにたいして処理中を通知できる。また、応答メッセージが途中で消失した為に、リトライによるポーリングが来ても、保持されている応答メッセージによって何回でも同じ応答を返すことができる。

また、本例では、上記の通り、要求メッセージを受信してもＡＣＫを返さないので、送信側は要求メッセージが届いたか否かを認識できない。この為、要求メッセージが届いたか否かに関係なく、続けてポーリングを送信する。よって、受信側では、要求メッセージがノイズ等で受信側に届かないにも関わらず、続いてポーリングが届くことになる。この場合は、このポーリングを新しいトランザクションのものと判定して非応答(Not ACK：Nack)を返す必要がある。決して前のトランザクションのポーリングの続きと判定して前の応答メッセージを返してはならない。一方、上記の通り、応答メッセージがノイズ等で送信側ノードに届かない場合のリトライでポーリングが届く場合がある。この場合は、このポーリングを前のトランザクションの続きと判定して、前の応答メッセージを返す必要がある。

実施例６では、上記の状況に対応する為に、ポーリングにもＴＩＤを格納してトランザクションの管理をする。
そして、受信側ノードは、上記要求メッセージを受信した場合だけでなく、自ノード宛のポーリングを受信した場合にも、このポーリングに格納されているＴＩＤを受信側ＴＩＤ管理テーブルに記憶されているＴＩＤ(要求メッセージで更新されている)と比較して、ＴＩＤ一致ならばトランザクションの継続と判定して、応答保持情報がセットされていれば応答メッセージを送信し、セットされていなければ処理中を送信する。

一方、ＴＩＤ不一致ならば要求メッセージ消失等のトランザクション異常と判定してNackを送信する。
以上の様に、実施例６によれば、ポーリングもＴＩＤで管理する事により、要求メッセージ消失等のトランザクションの異常に対応できる。

上記実施例６を実施例５に適用した場合の処理フローチャートを、図２２〜図２４に示す。また、図２２〜図２４の処理について具体例を挙げて説明する為の図を図２５、図２６に示す。

図２２は、上記の場合のマスタノードの処理フローチャート図である。
図２２において、タイマ１４による定周期タイマ割り込みが入る毎に（ステップＳ２５１，ＹＥＳ）、まず制御時間帯における処理を行う。すなわち、他の各ノード（０，１，２・・・等）からの制御データ受信処理を行うと共に、もし１または２以上のノードから上記送信権要求があった場合にはこれを受信して記録しておく（ステップＳ２５２）。続いて、メッセージ時間帯に入ったら（ステップＳ２５３，ＹＥＳ）、送信権要求したノードにトークンを与えるが（ステップＳ２５６）、もし複数のノードから送信権要求があった場合には、その前にどのノードにトークンを与えるかを判定する（ステップＳ２５４）。この判定は、既に述べている通り、前のサイクルでトークンを与えたノードから引き続き送信権要求があった場合には（あるいは要求が無くても、要求の取り下げが無い限り）、このノードに引き続きトークンを与える。

そして、図１９（ａ）に示すＴＩＤ生成処理を行って（ステップＳ２５５）、トークンを送信する（ステップＳ２５６）。
図２３は、上記の場合の送信側ノードのトークン受信処理のフローチャート図である。

図２３において、要求メッセージ送信側ノードは、まず、応答待ちフラグがＯＮかＯＦＦかを判定する（ステップＳ２６１）。応答待ちフラグは、既に要求メッセージを送信しておりメッセージ受信ノードからの応答待ちの状態である場合にはＯＮになっている。

最初は、未だ要求メッセージは送信していないので、応答フラグはＯＦＦであり、ステップＳ２６２以降の処理を行うことになる。まず、本例では上記の通り実施例５に適用した場合の例なので、送信側ノードではＴＩＤ生成処理は行わない。ＴＩＤはマスタノードで生成されてトークンに含まれてくるので、受信したトークンからＴＩＤを取り出す処理を行う（ステップＳ２６２）。

そして、トークンから取り出したＴＩＤと自己のノード番号（送信元ノード番号）を要求メッセージに含めて送信する（ステップＳ２６３）。その後応答待ちフラグをＯＮにして（ステップＳ２６４）、処理を終了する。

ここで、本処理では、上記図５（ｂ）の処理とは異なり、ＡＣＫ受信は不要になっている。つまり、受信側ノードは、要求メッセージを受信してもＡＣＫを返さない。ＡＣＫを用いなくても、後に図２６で説明するように、ポーリングに対してＮａｃｋが返信されてくれば、要求メッセージが受信側に届いていないと判定できるので、図２３には図示していないが、その場合には再送をするかどうかを上位処理で判定すれば良い。

この様にＡＣＫを用いないようにしている理由は、要求メッセージは通常数十〜百数十バイト程度である為、受信側ノードがサムチェックを行ってデータが壊れていないかどうかを判定するのに時間がかかるので、この判定は制御データ交換処理のバックグランド処理で行いたいからである。もし、ＡＣＫを返す場合、この判定を１サイクルのメッセージ時間帯内で行わなければならない為、その分、メッセージ時間帯を長くする必要が生じる。一方、上記のようにこの判定を制御データ交換処理のバックグランド処理で行えば、次のサイクルでポーリングがくるまでに判定終了していればよいので、メッセージ時間帯を長くする必要はない。もし、要求メッセージが壊れていたら破棄して、ポーリングに対してＮａｃｋを返信すればよい。尚、ポーリングは数バイト程度なのでサムチェックは短時間で済み、その応答も十数バイト程度なので、メッセージ時間帯を長くする必要はない。

また、これも特に図示しないが、上記図５（ｂ）と同様、ブロードキャストの場合は通常ＡＣＫや応答メッセージは来ないので、要求メッセージを連続して複数回送信するだけであり、ポーリングも行うことなく、処理を終了する。

上述したように最初のサイクルでステップＳ２６２〜Ｓ２６４の処理を実行したら、次のサイクル以降においては、応答フラグはＯＮになっているので、応答メッセージを正常に受信するまで、ステップＳ２６５〜Ｓ２６９の処理を繰り返し実行することになる。

まず、ポーリング送信を行う（ステップＳ２６５）。そして、応答待ち時間内に応答メッセージを受信した場合には（ステップＳ２６７、ＹＥＳ）、当該メッセージ交換は完了となり、最後に応答待ちフラグをＯＦＦにして（ステップＳ２６９）処理を終了する。

一方、処理中応答を受信した場合（ステップＳ２６８，ＹＥＳ）または応答が無いまま応答待ち時間オーバーとなった場合には（ステップＳ２６６，ＹＥＳ）そのまま当該処理は終了する。この場合は、未だメッセージ交換は完了していないので、引き続き、次のサイクルにおいてステップＳ２６５〜Ｓ２６９の処理を実行することになる。勿論、この場合、送信権要求を行ってトークンを得ることは当然に行っている。

図２４（ａ）は、上記の例における受信側ノードの要求メッセージ受信処理のフローチャート図である。
要求メッセージを受け取ったメッセージ受信ノードは、まず、当該要求が他ノード宛の１対１通信であるか、自ノード宛の１対１通信またはブロードキャストであるかを判定する（ステップＳ２８１、Ｓ２８２）。もし、要求メッセージが他ノード宛の１対１通信である場合には（ステップＳ２８２，ＮＯ）、そのまま当該処理を終了する。一方、自ノード宛の１対１通信またはブロードキャストである場合には、ステップＳ２８３の処理に移行する。

ステップＳ２８３では、上記処理中フラグがＯＮであるか否かを判定し、ＯＮである場合には（ステップＳ２８３，ＹＥＳ）、この要求は受けられないと見做して破棄し、当該受信処理は終了する。

ここで、処理中フラグを使うのは、受信側ノードで要求に対する処理中に、何らかの原因で送信側でトランザクションが中断された為、その後別のトランザクションに移り、新たな要求メッセージが来た場合を検出するためである（本手法では１トランザクション完了するまでは他のトランザクションは発生させないが、送信側で何らかの原因でトランザクションが中断されたならば、話は別である）。処理中フラグがオフならば新たな要求を受付可能だが、処理中フラグがオンならば本来は受付不可能であるので、上記の通り新しい要求メッセージを破棄するが、この例に限らず、処理中の要求を中断・破棄して新たな要求を受け付けるようにしても良い。

処理中フラグがＯＦＦの場合には（ステップＳ２８３，ＮＯ）、続いて、多重検出処理を実行する（ステップＳ２８４）。この多重検出処理は、この例では実施例５の図２０（ａ）の処理を行う。

その後は、処理中フラグをＯＮすると共に応答保持情報をＯＦＦしてから（ステップＳ２８５，Ｓ２８６）、所定の受信処理（要求メッセージの解析・実行）を行う（ステップＳ２８７）。

処理が終了したら、要求がブロードキャストの場合には（ステップＳ２８８，ＹＥＳ）応答メッセージは送信しないので、そのまま処理中フラグをＯＦＦして（ステップＳ２９１）当該受信処理は終了する。一方、１対１通信の場合には（ステップＳ２８８，ＮＯ）、応答メッセージを生成・保持して（ステップＳ２８９）、応答保持情報はＯＮしておく（ステップＳ２９０）。そして、処理中フラグをＯＦＦして（ステップＳ２９１）当該受信処理は終了する。

送信側ノードは、１対１通信の場合、要求メッセージを送信後ポーリングを行うので、図２４（ａ）の処理後だけでなく処理中にもポーリングが送られてくるので、受信側ノードではこのポーリングを受信する毎に図２４（ｂ）に示すポーリング受信処理を行う。

図２４（ｂ）において、受信側ノードは、まず、受信したポーリングに含まれるＴＩＤを取り出す（ステップＳ３０１）。上記の通り、実施例６では、送信側ノードは、要求メッセージだけでなくポーリングにもＴＩＤを格納して送信するからである。

そして、取り出したＴＩＤをテーブル６２のＴＩＤと比較して、一致した場合には（ステップＳ３０２，ＹＥＳ）、これは先に受け付けた要求メッセージと同じトランザクションによるポーリングであるので、続いて、応答保持情報を参照し、これがＯＮである場合には、既に応答メッセージが作成済みであり送信準備完了していることになるので（ステップＳ３０３，ＹＥＳ）、保持されている応答メッセージを送信する（ステップＳ３０４）。一方、応答保持情報がＯＦＦの場合には未だ応答メッセージは作成完了されていないことになるので（ステップＳ３０３，ＮＯ）、「処理中」を返信する（ステップＳ３０５）。

一方、ＴＩＤが不一致の場合には（ステップＳ３０２，ＮＯ）、このポーリングは現在処理中または処理完了して応答メッセージを保持しているものに対応する要求メッセージに関するポーリングではないので、このポーリングに対して応答メッセージを返すわけには行かないので、非応答(Nack)を返す（ステップＳ３０６）。また、この場合は新たなトランザクションが発生していることになるので、前のトランザクションのポーリングが来ることはないので、応答保持情報をＯＦＦする（ステップＳ３０７）。

図２５、図２６は、上記図２２〜図２４の処理について具体例を挙げて説明する為の図であり、図２５は正常処理、図２６はトランザクション異常時の処理を示す。
尚、図２５、図２６において図中のＴＫＮはメッセージ時間帯でマスタノードから送信側ノードに与えられるトークン、ＭＳＧは要求メッセージ、ＰＯＬはポーリング、Ｎａｃｋは非応答を意味するものであり、また図２５、図２６はこれらの各フレームとＴＩＤに注目して記述してあり、その他の定周期で交換している制御用データや送信権要求等については省略してある。また、マスタノード、要求メッセージ送信側ノードの動作も省略してあるが、図２２、図２３に示す通りである。

図２５、図２６の処理は、一連の連続した処理を示し、最初はマスタノードで管理するＴＩＤは２５０であったものとする。また、これまでの例と同様、要求メッセージ送信側ノードはノード０、要求メッセージ受信側ノードはノード１であるものとして説明する。

この状態でまず図２５の左側に示すように、１対１のメッセージ交換が行われるものとする。この場合、まず、要求メッセージ送信側ノードであるノード０からの送信権要求を受けたマスタノードは、テーブル６１のＴＩＤをインクリメント(250→251)してこれをトークンに格納してノード０に送信する。このトークンを受け取ったノード０は、このトークンに含まれるＴＩＤ(251)を要求メッセージに格納して要求メッセージ受信側ノードであるノード１に送信する。

ノード１は、この要求メッセージを受信するとそこからＴＩＤ (251)を取り出してテーブル６２のＴＩＤ(250)と比較する。この場合、ＴＩＤが不一致なので新しいメッセージと判定しテーブル６２のＴＩＤを更新(251)する。尚、その前に、図示の例では処理中フラグがオフなので要求受付可能と判定し、要求メッセージを内部に取り込んでいる。そして、処理中フラグをオン、応答保持情報をオフして、上記新規メッセージの解析・実行を開始する。

ノード０は、要求メッセ−ジ送信後は、応答メッセージを受け取るまで繰り返しポーリングを送信する。このポーリングにはトークンから得たＴＩＤ(251)が格納されており、ノード１はポーリングを受信する毎にそこからＴＩＤ(251)を取り出してテーブル６２のＴＩＤ(251)と比較する。この場合、ＴＩＤが一致するので上記受け付けた要求メッセージと同じトランザクションのポーリングであると判定する。そして、ここでは、応答保持情報がオフなので、「処理中」をノード１に返す。

その後、ノード１は、上記受け付けた要求に対する処理が終了すると、応答メッセージを準備して応答保持情報をオンするとともに処理中フラグをオフする。
この状態で、再び、ノード０がＴＩＤ(251)を格納したポーリングを送信すると、ノード１は受信したポーリングからＴＩＤ(251)を取り出してテーブル６２のＴＩＤ(251)と比較する。この場合もＴＩＤが一致するので上記と同様の判定を行う。そして、今回は上記の通り、応答保持情報がオンなので、保持しておいた応答メッセージをノード１に返す。尚、応答メッセージの送信に伴って応答保持情報はオフすることはしない。その理由は図２６で説明する。

以上のように１対１メッセージの基本プロトコルは行われる。
続いて、図２５の図上中央付近に示すように、ノード０からブロードキャストが行われたとする。ブロードキャストは確認応答（ＡＣＫ）をとれないので、通常は複数回（図の例では３回）同じ要求メッセージを送信して信頼性を上げている。

ノード０からの送信権要求を受けたマスタノードは、テーブル６１のＴＩＤをインクリメント(251→252)してそれをトークンに格納してノード０に送信する。このトークンを受け取ったノード０はそのＴＩＤ(252)を要求メッセージに格納してブロードキャスト送信する。受信側としてはここではノード１についてのみ説明する。ノード１は受信した要求メッセージからＴＩＤ (252)を取り出してテーブル６２のＴＩＤ(251)と比較する。この場合、ＴＩＤが不一致なので新しいメッセージと判定する。尚、その前に、処理中フラグがオフなので要求受付可能と判定し、要求メッセージを内部に取り込む処理を行っている。そして、受信ＴＩＤを更新(252)すると共に、処理中フラグをＯＮ、応答保持情報をＯＦＦしてから、要求メッセージの解析・実行処理を開始する。

ノード０はその後にＴＩＤ(252)を格納した要求メッセージを再送信する（上記３回のうちの２回目）。ノード１はこの要求メッセージを受信するとそこからＴＩＤ(252)を取り出して記憶していた受信ＴＩＤ(252)と比較する。この場合、ＴＩＤが一致するのでメッセージの再送信だと判定してそれを破棄する。

ノード０はその後にＴＩＤ(252)を格納した要求メッセージを再々送信する（上記３回のうちの３回目）。ノード１はこの要求メッセ−ジを受信するとそこからＴＩＤ(252)を取り出して記憶していた受信ＴＩＤ(252)と比較する。この場合もＴＩＤが一致するので要求メッセージの再送信だと判定してそれを破棄する。その後、ノード１は、上記受け付けていた要求の処理が終了すると、処理中フラグをオフする。尚、ブロードキャストの場合は、応答メッセージは送信しないので、応答メッセージ作成や応答保持情報をＯＮする処理は行わない。

以上のようにブロードキャストの三重送信の基本プロトコルは行われる。
続いて、図２５の図上右側には、マスタノードが上記ノード０以外の別のノードから送信権要求を受けた場合を示す。

別のノードからの送信権要求を受けたマスタノードは、テーブル６１のＴＩＤをインクリメント(252→253)してそれをトークンに格納して要求元ノード送信する。ノード１はこのトークンを受信するとそこからＴＩＤ (253)を取り出してテーブル６２のＴＩＤ(252)と比較する。この場合、ＴＩＤが不一致なので、テーブル６２のＴＩＤを初期化（０）する。尚、これは上記４つの方法の１つを例にしただけであり、４つの方法のうちのどれを用いても良い。

図２６には、ノイズ等でフレームが消失してトランザクション異常が発生した場合の動作を示す。
図２６の左側には、再びノード０がノード１に対して１対１要求メッセージを送信し、この要求に対する応答メッセージが途中で消失した場合の動作例を示す。

この例において最初の応答メッセージを送信するまでは、図２５の１対１メッセージで説明した通りであり(ただし、テーブル６２のＴＩＤは初期化（０）されているので、多重判定処理は必ず不一致となる)、ここでの説明は省略する。

そして、応答メッセージがノイズ等何らかの原因で途中で消失した為、ノード０は、応答メッセージが来ないので、リトライとして再びＴＩＤ(254)を格納したポーリングを送信する。ノード１はこのポーリングを受信するとそこからＴＩＤ(254)を取り出してテーブル６２のＴＩＤ(254)と比較する。この場合ＴＩＤが一致するので、メッセージと同じトランザクションのポーリングだと判定する。そして応答保持情報がオンなので、応答メッセージをノード０に再送信する。

応答メッセージ送信に伴って応答保持情報をオフしていないのは、このようなポーリングのリトライに対応するためである。
図２６の図上右側には、要求メッセージが消失して、ノード１にいきなりポーリングが来た例を示す。

この例において、ノード０からの送信権要求を受けたマスタノードは、テーブル６１のＴＩＤをインクリメント(254→255)してそれをトークンに格納してノード０に送信する。トークンを受け取ったノード０はそのＴＩＤ(255)を要求メッセージに格納してノード１に送信する。しかしこの例では途中でこの要求メッセージは消失してノード１には届かなかった。要求メッセ−ジが届かないのでノード１のテーブル６２のＴＩＤは254のままである。

しかしながら、本例では上記の通りＡＣＫは返信されないので、ノード０は、要求メッセージが届いていなくても、続いてＴＩＤ(255)を格納したポーリングを送信することになる。

この場合、ノード１はこのポーリングを受信するとそこからＴＩＤ(255)を取り出してテーブル６２のＴＩＤ(254)と比較する。すると、ＴＩＤが不一致となるので、前の要求メッセージと違うトランザクションによるポーリングだと判定する。よって、このポーリングに前の要求メッセージに対する応答メッセージを返すわけには行かないので、非応答(Nack)を返す。また、応答保持情報をオフする。

以上説明したように、本発明によれば、小さいＴＩＤ管理テーブルで問題なく多重受信を判別できる。すなわち、従来より、ノイズ等でＡＣＫが消失した為に多重にメッセージを送ったり、ブロードキャストで多重に送信しても、要求メッセージに格納されるＴＩＤとＴＩＤ管理テーブルとで整合性を取り多重受信を判別することで、同じ処理を多重に実行することがなくなるようにしていたが、本発明ではＴＩＤ管理テーブルを非常に小さくすることができるようになる。

例えば、従来ではノード数の３倍も記憶しておかなくてはならなかったＴＩＤ管理テーブルを、本例では最小の場合、送信側と受信側でＴＩＤを１つずつ記憶すれば良くなるので、リソースが少ないワンチップマイコンが良く使われている機器組込み用途にも使える。もし別置のＲＡＭが不要になれば安価なネットワークを構築することができる。例えば、ノード数が64の場合、193バイト記憶する必要があったのがわずか２バイトに減り、191バイトの削減になる。

また、受信側ノードでは要求メッセージを一時的にバッファに格納して処理を行っているが、従来では、受信した要求メッセージに関する処理を行っている最中に別の要求メッセージを受信する可能性がある為、１つのバッファしか用意していない場合、前の要求メッセージが未だ処理中に新しい要求メッセージをバッファに上書きしてしまう。これを避ける為に、従来では、このバッファを複数（例えば３個）用意していた。

一方、本発明では、要求と応答までの１トランザクションが完了するまで他のトランザクションは発生しないので、受信した要求メッセージ処理を行っている最中に別の要求メッセージを受信することは無くなるので(但し、送信側でトランザクションが中断される場合は除く)、上記バッファは１個で済むようになる。例えば、１要求メッセージが256バイトであり、従来ではバッファを３個用意していたが、本発明では１個だけでよくなり、512バイト削減できる。これは、ＲＡＭが数ｋバイトしかないワンチップマイコンから見ると大きな節約になるので、ＴＩＤ管理テーブルの削除だけでは別置ＲＡＭを削除できない場合でも、この512バイト削減で別置ＲＡＭを削除できる可能性が増える。

また、本発明によれば、上記特徴に加えて更に、データ交換の定周期性を守りながらメッセージの交換を行うことができる。これは、例えば機器間で定周期に行う制御データ交換の他に支援メッセージを交換する場合に、その要求メッセージに対する応答処理の処理時間に関係なく定周期性を守ることができ、例えば、EEPROM書き込みのような時間のかかる処理をメッセージで送信しても、要求メッセージとポーリングの間やポーリング同士の間に制御データの交換を行って定周期性が守られるので、定周期性が乱れたことを原因とする異常が発生しない。

例えば支援系からのプログラムダウンロードでEEPROMへの書き込みが100m秒かかるとしても、それを複数サイクルに渡って処理を行うことができるので、定周期データ交換を50m秒で行うことは可能である。１サイクル目の要求メッセージで受信側が処理を開始し、２サイクル目のポーリングに処理中応答が返り、３サイクル目のポーリングにも処理中応答が返り、４サイクル目のポーリングに応答メッセージが返る。このように、時間のかかる処理があっても、早いサイクルで制御データの交換を定周期性を守りながら行うことができる。

また、１対１通信の場合にもＡＣＫを返信しないようにした場合、新たなトランザクションに対応するポーリング（但し、その要求メッセージは途中消失した）に対して前のトランザクションの応答メッセージを誤って送ってしまったりする可能性があったが、ポーリングにもＴＩＤを格納することでこの様な事態を回避できるし、更に要求メッセージが途中消失していることを認識してＮａｃｋを返信することで送信側に知らせることもできる。

例えば、モータやスイッチの近くなどノイズ発生源の近くにネットワークを敷設してフレーム消失やリトライが多発しても、要求と応答メッセージの整合性がとれているので安全に通信をすることができる。

また、通常の環境でも、応答確認をとらないブロードキャストメッセージは受信側への到達を確認できないものである。しかし、本方式では初送と再送の区別ができて受信側で多重受信分を破棄できるので、送信側が多重に送信することにより到達確率の向上を安全に行うことができる。

本例によるシステム全体の概略構成図を示す。図１に示す各ノードのハードウェア構成図である。本例のシステムにおけるメッセージ交換のプロトコルの一例を示す図である。マスタノードの基本処理フローチャート図である。送信側ノードの基本処理フローチャート図であり、（ａ）は制御時間帯、（ｂ）はメッセージ時間帯における処理を示す。受信側ノードの基本処理フローチャート図であり、（ａ）は要求メッセージ受信時の処理、（ｂ）はポーリング受信時の処理を示す。送信側ノードのＴＩＤ生成処理（実施例１）のフローチャート図である。受信側ノードの多重検出処理（実施例１）のフローチャート図である。（ａ）は送信側、（ｂ）は受信側のＴＩＤ管理テーブルである（実施例１）。送信側ノードのＴＩＤ生成処理（実施例２）のフローチャート図である。受信側ノードの多重検出処理（実施例２）のフローチャート図である。（ａ）は送信側、（ｂ）は受信側のＴＩＤ管理テーブルである（実施例２）。送信側ノードのＴＩＤ生成処理（実施例３）のフローチャート図である。実施例３における受信側ノードの処理フローチャート図であって（ａ）は多重検出処理、（ｂ）は他ノード宛メッセージ受信時の処理を示す。（ａ）は送信側、（ｂ）は受信側のＴＩＤ管理テーブルである（実施例３）。送信側ノードのＴＩＤ生成処理（実施例４）のフローチャート図である。実施例４における受信側ノードの処理フローチャート図であって（ａ）は多重検出処理、（ｂ）は他ノード宛メッセージ受信時の処理を示す。（ａ）は送信側、（ｂ）は受信側のＴＩＤ管理テーブルである（実施例４）。実施例５における処理であって、（ａ）はマスタノードによるＴＩＤ生成処理、（ｂ）は送信側ノードによるＴＩＤ抽出処理を示すフローチャート図である。受信側ノードの処理フローチャート図（実施例５）であって、（ａ）は多重検出処理、（ｂ）はＴＩＤ強制変更処理を示す。（ａ）は送信側、（ｂ）は受信側のＴＩＤ管理テーブルである（実施例５）。実施例６におけるマスタノードの処理フローチャート図である。実施例６における送信側ノードの処理フローチャート図である。実施例６における受信側ノードの処理フローチャート図であって、（ａ）は要求メッセージ受信時の処理、（ｂ）はポーリング受信時の処理を示す。図２２〜図２４の処理について具体例（正常時）を示して説明する為の図である。図２２〜図２４の処理について具体例（トランザクション異常時）を示して説明する為の図である。（ａ）は送信側、（ｂ）は受信側のＴＩＤ管理テーブルである（従来例）。送信側ノードのＴＩＤ生成処理（従来例）のフローチャート図である。受信側ノードの多重検出処理（従来例）のフローチャート図である。

符号の説明

０，１，２ノード
３マスタノード
４バス型ネットワーク
１０ノード
１１ＣＰＵ
１２プログラムメモリ部
１３メモリ部
１３ａデータメモリ部
１３ｂ送信バッファ
１３ｃ受信バッファ
１４タイマ
１５伝送制御部
２１送信側ＴＩＤ管理テーブル（１対１用）（実施例１）
２２送信側ＴＩＤ管理テーブル（ブロードキャスト用）（実施例１）
２３受信側ＴＩＤ管理テーブル（１対１用）（実施例１）
２４受信側ＴＩＤ管理テーブル（ブロードキャスト用）（実施例１）
３１送信側ＴＩＤ管理テーブル（１対１用）（実施例２）
３２送信側ＴＩＤ管理テーブル（ブロードキャスト用）（実施例２）
３３受信側ＴＩＤ管理テーブル（１対１とブロードキャスト共用）（実施例２）
４１送信側ＴＩＤ管理テーブル（１対１とブロードキャスト共用）（実施例３）
４２受信側ＴＩＤ管理テーブル（１対１とブロードキャスト共用）（実施例３）
５１送信側ＴＩＤ管理テーブル（１対１とブロードキャスト共用）（実施例４）
５２受信側ＴＩＤ管理テーブル（１対１とブロードキャスト共用）（実施例４）
６１送信側ＴＩＤ管理テーブル（１対１とブロードキャスト共用）（実施例５）
６２受信側ＴＩＤ管理テーブル（１対１とブロードキャスト共用）（実施例５）

Claims

複数のノードがネットワークを介して互いにデータ交換するシステムにおけるメッセージ交換管理方法であって、
前記データ交換の為の通信サイクルを、前記制御データ交換の為の制御データ交換用時間帯とメッセージ交換の為のメッセージ交換用時間帯に分け、
該メッセージ交換用時間帯におけるメッセージ交換処理は、要求から応答までを１トランザクションとし、
システム全体の送信権管理をするマスタノードを備え、
該マスタノードは、メッセージ送信の為の送信権要求を出したノードにトークンを与え、
前記マスタノードからトークンを得たメッセージ送信側ノードは、複数サイクルに渡ってメッセージ交換用時間帯において任意のメッセージ受信側ノードに要求メッセージを送信すると共に該要求に対する応答を得るまでポーリングを繰り返し、
前記マスタノードは前記メッセージ送信側ノードが応答を得るまで他のノードにトークンを与えないようにすることを特徴とするメッセージ交換管理方法。
前記メッセージ送信側ノードは、最初のサイクルで前記要求メッセージの送信を行い、２番目以降のサイクルでポーリングを繰り返し行う際には、各サイクル毎に、そのメッセージ交換用時間帯内に応答が得られない場合にはポーリングを一時中断し、次のサイクルのメッセージ交換用時間帯に入ったらポーリングを再開することで、制御データ交換の定周期性を保証することを特徴とする請求項１記載のメッセージ交換管理方法。
前記メッセージ送信側ノードでは、トランザクション番号を宛先ノード毎に管理して、新規メッセージ送信毎にその宛先に対応するトランザクション番号を更新して、該更新後のトランザクション番号と送信元ノード番号を前記要求メッセージに格納して送信し、
前記メッセージ受信側ノードでは、前回受信した要求メッセージの送信元ノード番号とトランザクション番号を記憶しておき、受信した要求メッセージの送信元ノード番号とトランザクション番号の両方が前記記憶した番号と一致する場合にはメッセージの多重受信と判定することを特徴とする請求項１又は２記載のメッセージ交換管理方法。
前記メッセージ送信側ノードでは、トランザクション番号を宛先ノード毎に管理して、新規メッセージ送信毎にその宛先に対応するトランザクション番号を更新して、該更新後のトランザクション番号と送信元ノード番号を前記要求メッセージに格納して送信し、
メッセージ受信側ノードでは、前記前回受信したメッセージの送信元ノード番号とトランザクション番号を記憶すると共に該メッセージがブロードキャストメッセージであるか１対１メッセージであるかを示す判別フラグを記憶しておき、
今回受信したメッセージがブロードキャストメッセージであるか１対１メッセージであるかを判定し、該判定結果と該今回受信したメッセージの送信元ノード番号とトランザクション番号とを、前記記憶しておいた値とそれぞれ比較し、全て一致する場合にはメッセージの多重受信と判定することを特徴とする請求項１又は２記載のメッセージ交換管理方法。
前記メッセージ受信側ノードは、
他ノード宛のメッセージを監視することで新たなトランザクションに移行したことを認識すると該トランザクション移行を示す情報を記憶することを特徴とする請求項１又は２記載のメッセージ交換管理方法。
前記メッセージ送信側ノードは、宛先ノード毎に区別することなく１対１通信とブロードキャスト共用でトランザクション番号を管理して、新規メッセージ送信毎に該トランザクション番号を更新して、該更新後のトランザクション番号と送信元ノード番号をメッセージに格納して送信し、
メッセージ受信側ノードでは、前回受信したメッセージの送信元ノード番号とトランザクション番号を１対１通信とブロードキャスト共用で記憶しておき、受信したメッセージの送信元ノード番号とトランザクション番号の両方が前記記憶した番号と一致する場合にはメッセージの多重受信と判定することを特徴とする請求項５記載のメッセージ交換管理方法。
前記マスタノードは、前記トランザクション番号を一元管理して、新規トランザクションによる送信権要求に応じてトークンを与える場合には該トランザクション番号を更新して、該更新後のトランザクション番号をトークンに格納して送信し、
前記メッセージ送信側ノードは、受信したトークンから前記トランザクション番号を取り出して、該トランザクション番号を前記要求メッセージに格納して送信し、
前記メッセージ受信側ノードは、前回受信した要求メッセージに含まれていたトランザクション番号を１対１通信とブロードキャスト共用で記憶しておき、今回受信した要求メッセージに含まれるトランザクション番号を前記記憶しておいた値と比較し、一致する場合にはメッセージの多重受信と判定し、次のトランザクションへ移行したことを認識すると、トランザクション移行を示す情報を記憶することを特徴とする請求項１又は２記載のメッセージ交換管理方法。
前記次のトランザクションへ移行したことを認識するとトランザクション移行を示す情報を記憶するステップは、
（１）他ノード宛のメッセージを検出すると、その中のトランザクション番号を取り出して、記憶しておいたトランザクション番号に上書きする
（２）他ノード宛のメッセージを検出すると、記憶しておいたトランザクション番号を初期化する
（３）トークンを検出すると、その中のトランザクション番号を取り出して、記憶しておいたトランザクション番号と比較して、不一致ならば記憶しておいたトランザクション番号を初期化する
（４）他ノード宛のトークンを検出すると、記憶しておいたトランザクション番号を初期化する
の何れかを用いるものであることを特徴とする請求項７記載のメッセージ交換管理方法。
前記メッセージ受信側ノードは、
応答保持情報を保持しており、
前記多重受信か否かの判定において、多重受信ではないと判定した場合には、前記受信した要求メッセージを受け入れて該要求に応じた処理を開始すると共に前記応答保持情報をクリアし、
前記要求に応じた処理が完了して応答メッセージの準備ができた場合には前記応答保持情報をセットし、
前記各ポーリング受信毎に前記応答保持情報を参照し、応答保持情報がリセットされている場合には「処理中」応答を返し、応答保持情報がセットされている場合には前記応答メッセージを返すことを特徴とする請求項３〜８の何れかに記載のメッセージ交換管理方法。
前記メッセージ受信側ノードは、
処理中フラグを有し、
前記多重受信ではないと判定した場合において前記要求に応じた処理を開始するときに前記処理中フラグをオンし、該処理が完了したときに該処理中フラグをオフし、
要求メッセージを受信したときに前記処理中フラグがオン状態である場合には、該処理中の処理を要求したトラザクションが中断したと見なすことを特徴とする請求項３〜９の何れかに記載のメッセージ交換管理方法。
前記メッセージ受信側ノードは、前記要求メッセージを受信してもＡＣＫ返信処理は行わず、
前記メッセージ送信側ノードは前記各ポーリング送信の際にも該ポーリングに前記トランザクション番号と送信元ノード番号を格納して送信し、
前記メッセージ受信側ノードは、ポーリングを受信すると、該ポーリングに含まれるトランザクション番号と送信元ノード番号を前記記憶してある値と比較して、不一致である場合には新規要求メッセージの消失と判定して非応答を返信することを特徴とする請求項３〜１０の何れかに記載のメッセージ交換管理方法。
複数のノードがネットワークを介して互いにデータ交換するネットワークシステムにおいて、
前記データ交換の為の通信サイクルを、前記制御データ交換の為の制御データ交換用時間帯とメッセージ交換の為のメッセージ交換用時間帯に分け、該メッセージ交換用時間帯におけるメッセージ交換処理は、要求から応答までを１トランザクションとし、
システム全体の送信権管理をするマスタノードを備え、
該マスタノードは、メッセージ送信の為の送信権要求を出したノードにトークンを与え、一旦トークンを与えたノードが前記トランザクションを完了するまで他のノードにトークンを与えないようにする送信権管理手段を有することを特徴とするネットワークシステム。
前記マスタノードからトークンを得たノードであるメッセージ送信側ノードは、
複数サイクルに渡ってメッセージ交換用時間帯において任意のメッセージ受信側ノードに要求メッセージを送信すると共に該要求に対する応答を得るまでポーリングを繰り返し、最初のサイクルで前記要求メッセージの送信を行い、２番目以降のサイクルでポーリングを繰り返し行う際には、各サイクル毎に、そのメッセージ交換用時間帯内に応答が得られない場合にはポーリングを一時中断し、次のサイクルのメッセージ交換用時間帯に入ったらポーリングを再開することで制御データ交換の定周期性を保証するメッセージ送信制御手段を有することを特徴とする請求項１２記載のネットワークシステム。
前記メッセージ受信側ノードは、
１対１通信、ブロードキャスト各々に対応して、前回受信した要求メッセージの送信元ノード番号とトランザクション番号を記憶する第１の受信側ＴＩＤ管理テーブルを有し、
該第１の受信側ＴＩＤ管理テーブルを用いて多重受信を判定する第１の多重受信判定手段を有することを特徴とする請求項１３記載のネットワークシステム。
前記メッセージ受信側ノードは、
前回受信した要求メッセージの送信元ノード番号とトランザクション番号を記憶すると共に該要求メッセージがブロードキャストメッセージであるか１対１メッセージであるかを示す判別フラグを記憶する第２の受信側ＴＩＤ管理テーブルを有し、、
該第２の受信側ＴＩＤ管理テーブルを用いて多重受信を判定する第２の多重受信判定手段を有することを特徴とする請求項１３記載のネットワークシステム。
前記メッセージ受信側ノードは、
他ノード宛のメッセージを監視することで新たなトランザクションに移行したことを認識すると該トランザクション移行を示す情報を記憶するトランザクション移行監視手段を有することを特徴とする請求項１３記載のネットワークシステム。
前記メッセージ送信側ノードは、宛先ノード毎に区別することなく１対１通信とブロードキャスト共用でトランザクション番号を管理する第１の送信側ＴＩＤ管理テーブルを有し、
前記メッセージ受信側ノードは、１対１通信とブロードキャスト共用で前回受信した要求メッセージの送信元ノード番号とトランザクション番号を記憶する第３の受信側ＴＩＤ管理テーブルと、該第３の受信側ＴＩＤ管理テーブルを用いて多重受信を判定する第３の多重受信判定手段を有することを特徴とする請求項１６記載のネットワークシステム。
前記マスタノードは、前記トランザクション番号を一元管理して、新規トランザクションによる送信権要求に応じてトークンを与える場合には該トランザクション番号を更新して、該更新後のトランザクション番号をトークンに格納するトランザクション番号管理手段を更に有し、
前記メッセージ送信側ノードのメッセージ送信制御手段は、受信したトークンから前記トランザクション番号を取り出して、該トランザクション番号を前記要求メッセージに格納して送信し、
前記メッセージ受信側ノードは、１対１通信とブロードキャスト共用で前回受信した要求メッセージのトランザクション番号を記憶する第４の受信側ＴＩＤ管理テーブルと、該第４の受信側ＴＩＤ管理テーブルを用いて多重受信を判定する第４の多重受信判定手段を有することを特徴とする請求項１３記載のネットワークシステム。
複数のノードがネットワークを介して互いにデータ交換するネットワークシステムにおけるシステム全体の送信権管理をするマスタノードにおいて、
メッセージ送信の為の送信権要求を出したノードにトークンを与え、一旦トークンを与えたノードが前記トランザクションを完了するまで他のノードにトークンを与えないようにする送信権管理手段を有し、
前記データ交換の為の通信サイクルを、前記制御データ交換の為の制御データ交換用時間帯とメッセージ交換の為のメッセージ交換用時間帯に分け、該メッセージ交換用時間帯におけるメッセージ交換処理は、要求から応答までを１トランザクションとすることを特徴とするマスタノード。
複数のノードがネットワークを介して互いにデータ交換するネットワークシステムにおける前記各ノードにおいて、
前記データ交換の為の通信サイクルを、前記制御データ交換の為の制御データ交換用時間帯とメッセージ交換の為のメッセージ交換用時間帯に分け、該メッセージ交換用時間帯におけるメッセージ交換処理は、要求から応答までを１トランザクションとし、複数サイクルに渡ってメッセージ交換用時間帯において任意のメッセージ受信側ノードに要求メッセージを送信すると共に該要求に対する応答を得るまで各サイクル毎にそのメッセージ交換用時間帯内でポーリングを繰り返すメッセージ送信制御手段を有することを特徴とするノード。
複数のノードがネットワークを介して互いにデータ交換するネットワークシステムにおけるシステム全体の送信権管理をするマスタノードのコンピュータに、
メッセージ送信の為の送信権要求を出したノードにトークンを与え、一旦トークンを与えたノードが前記トランザクションを完了するまで他のノードにトークンを与えないようにする機能
を実現させる為のプログラム。
複数のノードがネットワークを介して互いにデータ交換するネットワークシステムにおける前記各ノードのコンピュータに、
前記データ交換の為の通信サイクルを、前記制御データ交換の為の制御データ交換用時間帯とメッセージ交換の為のメッセージ交換用時間帯に分け、該メッセージ交換用時間帯におけるメッセージ交換処理は、要求から応答までを１トランザクションとし、複数サイクルに渡ってメッセージ交換用時間帯において任意のメッセージ受信側ノードに要求メッセージを送信すると共に該要求に対する応答を得るまで各サイクル毎にそのメッセージ交換用時間帯内でポーリングを繰り返す機能
を実現させる為のプログラム。