(57)【特許請求の範囲】
【請求項１】
複数のノードが接続されるネットワークに接続可能な管理局であって、
複数種のプロトコルに対し、各プロトコルを使用するノードに関する情報を記憶するノード管理情報記憶部と、
前記ノード間の伝送フレームを送受する際に使用するプロトコルの使用順に関する情報を記憶するプロトコル運用情報記憶部とを備え、
前記ノード管理情報記憶部に格納された情報に基づいて、ネットワークに接続されたノードに対して初期設定を行う機能と、
前記プロトコル運用情報記憶部に格納された情報に基づいて、所望のプロトコルを実行させるための制御信号を各ノードに向けて出力する機能を備えたことを特徴とする管理局。
【請求項２】
複数種のプロトコルを使用して伝送フレームの送受を行うネットワークに接続可能なノードであって、
前記複数種のプロトコルのうち、自ノードが対応するプロトコルに関する情報を記憶する記憶部を備え、
前記ネットワークに接続された管理局から送られてくる使用するプロトコルを特定する制御信号に基づき、前記記憶部にアクセスし、自ノードがその使用するプロトコルに対応するか否かを判断し、対応する場合には所定のタイミングで伝送フレームを送出する機能を備えたことを特徴とするノード。
【請求項３】
複数のノードが接続されるネットワークにおける伝送フレームの通信方法であって、
前記ネットワークは、複数種のプロトコルを適宜使用して前記ノード間の伝送フレームの通信を実行可能とし、
前記複数のノードは、予め自己が対応する１または複数のプロトコルが設定されるとともに、その設定されたプロトコルを実行するための情報が記憶され、
前記ネットワークに接続された管理局が、前記複数のプロトコルの使用順を管理し、
次に使用するプロトコルを前記複数のノードに通知し、
前記複数のノードはその通知を受信し、自己が対応するプロトコルか否かを判断し、対応する場合には、前記情報に基づいて所定のタイミングで伝送フレームを送出することを特徴とする通信方法。
【発明の詳細な説明】
【０００１】
【発明の属する技術分野】
この発明は、管理局及びノード並びに通信方法に関するものである。
【０００２】
【従来の技術】
複数のノードが接続されたネットワークにおいて、任意のノード間でデータの送受を行う場合には、ネットワーク上でデータ（フレーム）の衝突が生じない様にするため、各種の制御方式，プロトコルによって規定される手順にしたがって送受信されるようになっている。
【０００３】
プロトコルの一例を示すと、ネットワーク上に流れる唯一のトークンを取得したノードがそのトークンとともにデータを送信するトークンパッシングバス方式や、伝送フレームそのものをトークンとみなす疑似トークンパッシングバス方式や、各アドレスごとに予め送信時間を予約し、その予約した時間内にフレームを送信するようにした時間監視プロトコル（特開平９−１２８０１９号等参照）などの複数種のバスアビトレーションプロトコルがあった。そして、ネットワークを構築するに際し、いずれか１つのプロトコルを択一的に選択し、プログラムを形成していた。
【０００４】
【発明が解決しようとする課題】
従来のネットワークでは、単一のプロトコルを用いて制御していたため、以下のような特徴を有する。すなわち、トークンパッシングバス方式は、全てのアプリケーションに対応可能であり、フレームの衝突がほぼ確実に回避できるものの、トークンフレームを送出するため、回線使用効率が低下する。
【０００５】
疑似トークンパッシングバス方式は、ブロードキャストやマルチキャストでのアプリケーションに向き、フレームエラーが発生にない状態では、トークンフレームを送出しないため回線使用効率が向上する。しかし、宛先ノードがＡＣＫを返す場合に、フレームエラーが発生すると疑似トークンの受け渡し、消失時の処理が困難になる。
【０００６】
時間監視プロトコルは、Ｉ／Ｏ伝送など比較的小規模でサイクリックな伝送に向き、トークンフレーム（疑似トークンも含む）を送出しないため、回線使用効率が向上する。当然、トークン消失処理も不要で、バス制御の処理が単純になる。ただし、各ノードは、予め決まった時間領域にバスを占有するため、データ量を可変にしたり、エラー時に再送処理をすることが難しくなり、柔軟性に欠けるという問題がある。
【０００７】
このように、各方式でそれぞれ長短が有るので、設置するネットワークの状況を考慮し、より適した方式を決定し、それに応じたプログラムを組むようにしていた。従って、短所も有することになり、十分満足する方式にはできなかった。
【０００８】
この発明は、複数のノード間で通信を行う際に使用するトークンパッシングバス方式，疑似トークンパッシングバス，時間監視プロトコルなどの複数種のバスアピトレーションプロトコルを同一のネットワーク上で実行することで、それぞれの特長を生かし、短所を補ったネットワークシステムを構築するための管理局及びノード並びに通信方法を提供することを目的とする。
【０００９】
【課題を解決するための手段】
この発明による管理局では、複数のノードが接続されるネットワークに接続可能な管理局であって、複数種のプロトコルに対し、各プロトコルを使用するノードに関する情報を記憶するノード管理情報記憶部と、前記ノード間の伝送フレームを送受する際に使用するプロトコルの使用順に関する情報を記憶するプロトコル運用情報記憶部とを備え、前記ノード管理情報記憶部に格納された情報に基づいて、ネットワークに接続されたノードに対して初期設定を行う機能と、前記プロトコル運用情報記憶部に格納された情報に基づいて、所望のプロトコルを実行させるための制御信号を各ノードに向けて出力する機能を備えたものである。
【００１０】
ここで管理局は、ネットワークを構築するノードの１つに上記機能を実装し管理局を兼ねるようにしても良いし、別途管理局を設けてもよい。ノード管理情報記憶部は、実施の形態では、ノード管理テーブルに対応し、プロトコル運用情報記憶部は、実施の形態では、プロトコル運用テーブルに対応している。さらに、制御信号は、実施の形態では、プロトコルスタートフレームに対応する。さらに、使用するプロトコルは、実施の形態では、トークン，疑似トークン，管理時間の３つについて説明したが、本発明はこれに限ることは無く、例えば、ポーリングセレクションの他、各種のものを適用できる。
【００１１】
また、この発明によるノードでは、複数種のプロトコルを使用して伝送フレームの送受を行うネットワークに接続可能なノードであって、前記複数種のプロトコルのうち、自ノードが対応するプロトコルに関する情報を記憶する記憶部を備え、前記ネットワークに接続された管理局から送られてくる使用するプロトコルを特定する制御信号に基づき、前記記憶部にアクセスし、自ノードがその使用するプロトコルに対応するか否かを判断し、対応する場合には所定のタイミングで伝送フレームを送出する機能を備えたものである。
【００１２】
ネットワーク全体として複数のプロトコルが使用可能となっていれば、個々のノードは、必ずしも全てのプロトコルに対応している必要はなく、そのうちの一部または１つのプロトコルに対応するものでもよい。
【００１３】
また、複数種のプロトコルを使用して伝送フレームの送受を行うとは、係る複数種のプロトコルを同じに使用するのではなく、所定の順に択一されたプロトコルを用いて送信することを意味する。
【００１４】
さらに、この発明では、複数のノードが接続されるネットワークにおける伝送フレームの通信方法であって、前記ネットワークは、複数種のプロトコルを適宜使用して前記ノード間の伝送フレームの通信を実行可能とし、前記複数のノードは、予め自己が対応する１または複数のプロトコルが設定されるとともに、その設定されたプロトコルを実行するための情報が記憶され、前記ネットワークに接続された管理局が、前記複数のプロトコルの使用順を管理する。次に使用するプロトコルを前記複数のノードに通知し、前記複数のノードはその通知を受信し、自己が対応するプロトコルか否かを判断し、対応する場合には、前記情報に基づいて所定のタイミングで伝送フレームを送出することである。
【００１５】
この発明によれば、複数種のプロトコルが同一のネットワーク上に流れる。換言すると、ネットワークは、複数のプロトコルを利用して伝送フレームを送出できる。よって、接続するノードの種類や数その他の状況に応じて、ネットワークを構築すれば、各プログラムの長所を取り入れることができ、また、効率のよいデータ伝送が可能となる。さらに、異なるプロトコル同士のみにそれぞれ対応するノードであっても、同一のネットワークに接続し、動作させることが可能となる。
【００１６】
【発明の実施の形態】
図１は、本発明の好適な一実施の形態を示している。同図に示すように、複数のノード１０がケーブル１１を介して接続され、任意の相手と双方向通信できるネットワークを構築している。そして、本発明では、このネットワーク上でフレームを送受信する際のプロトコルを複数用意し、所定のプロトコルを用いて相手に情報伝送するようになっている。
【００１７】
係る所定のプロトコル（バスのアビトレーションのプロトコル）としては、本形態では、トークンパッシングバス方式，疑似トークンパッシングバス，時間監視プロトコルなどの複数種のバスアビトレーションを使用している。そして、そのプロトコルの運用管理するたの管理局２０をそのネットワークに接続するようにしている。
【００１８】
まず、本形態で用いる３つのプロトコルについて説明すると、トークンパッシングバスは、図２（ａ）に示すようになっており、伝送フレームＦとＡＣＫとトークンをセットにして送信する。このトークンが、ネットワーク上に唯一存在することから各ノードはそのトークンを獲得して送信することにより、データの衝突を回避している。なお、ＡＣＫはあってもなくてもよい。また、再送を行うサービスにおいては、送信権を持っているノードがＡＣＫ受信後、トークンを送出する。
【００１９】
疑似トークンパッシングバスは、同図（ｂ）に示すように伝送フレームＦそのものをトークンとみなす方式である。これを実現するためには、各ノードは、自局の前に送信するノードアドレスを記憶し、その記憶したノードアドレスのノードからのフレームを受信した場合には、所定のタイミングで送信フレームを送出することになる。一例を示すと、アドレス＃１のノードは、ノードアドレス＃０を記憶保持している。従って、＃０からの伝送アドレスを受信すると、次は＃１のノードが伝送アドレスを送出することになる。そして、それ以外のノードからの伝送フレームを受信しても、自己からは伝送アドレスを送信しない。これにより、予め定められた順番にしたがって各ノードが伝送フレームを送信するので、ネットワーク上で衝突が起きにくい。なお、返送（ＡＣＫレスポンス）は行えない。また、伝送するデータがない場合には、データのない空のフレームを送信することになる。
【００２０】
時間監視プロトコルは、同図（ｃ）に示すように、各ノードがプロトコルスタートフレーム受信後のある時間帯について、バスを占有する予約をしている方式であり、伝送するフレーム長と物理的伝送遅延とを考慮して伝送フレーム同士が重ならないように送信時間の設定を行い、その設定にしたがって各ノードが伝送フレームを送信するものである。よって、フレームは固定長の必要がある。なお、この方式は、例えば特開平９‐１２８０１９号公報などに詳しく説明されている。
【００２１】
次に、ノード１０及び管理局２０の内部構造について説明する。ノード１０は、ＰＬＣ，Ｉ／Ｏ，センサ，ＮＣ，ＡＤコンバータその他の通信機能を持つ各種装置により実現される。そして、図１に示したように、伝送フレームをネットワーク上に送信する送信部１２と、ネットワーク上を流れる伝送フレームを受信する受信部１３を備えている。さらに、自ノードが対応するプロトコルにしたがって動作するための情報を格納したプロトコル対応テーブル１４を有している。もちろん、図示省略するが、ノード１０が本来持っている機能を実現したり、送信する伝送フレームを生成したり、受信した伝送フレームを解析し所定の処理をする処理部を備えている。
【００２２】
そして、プロトコル対応テーブル１４の具体的な内部構造は、図３に示すようになっている。すなわち、疑似トークン，トークン並びに時間監視の３つのプロトコルに対し、自ノードが対応するか否かのフラグと、対応する場合に各プロトコルが正常に動作するために必要な情報を関連付けたテーブルとなっている。
【００２３】
具体的には、疑似トークンの場合には、自局（自ノード）の前に伝送フレームを送信するノードのノードアドレスを格納したレジスタへのポインタと、自局の後に伝送フレームを送信するノードのノードアドレスを格納したレジスタへのポインタを格納する。さらに、先頭ノードフラグ（自局が疑似トークンで伝送する場合の先頭ノードの場合には１をセットし、それ以外は０をセットする）を備えている。先頭ノードの場合には、自局の前に伝送フレームを送出することはないので、係る自局の前に送信するノードのノードアドレスの格納領域は、ｎｕｌｌとなっている。
【００２４】
また、トークンの場合には、自局の後に伝送フレームを送信するノードのノードアドレスを格納したレジスタへのポインタを格納する。さらに、時間監視の場合には、自ノードが送信する送信順番を格納したレジスタへのポインタを格納する。なお、ポインタではなく直接アドレスを格納しても良い。
【００２５】
もちろん、ノード１０によっては、３つのプロトコル全てに対応するものもあれば、１または２個に対応するものもある。そして、未対応の場合には当然のことながらレジスタへのポインタは格納されない（何かしらのデータを登録していても良い）。
【００２６】
一方、管理局２０は、ノード１０と同様に、ネットワークを介して伝送フレームを送受信するための送信部２１並びに受信部２２と、自ノードが対応するプロトコルにしたがって動作するための情報を格納したプロトコル対応テーブル２３を有している。
【００２７】
このプロトコル対応テーブル２３の内部データ構造は、図３に示したものと同様である。すなわち、管理局２０も、ネットワークに接続された通信端末の１つであり、ノードとしての機能も有するので、管理局２０から何らかの伝送フレームを送信する場合には、このプロトコル対応テーブル２３に格納された情報に基づいて実行する。
【００２８】
さらに管理局２０の機能を実現するために、プロトコル運用情報記憶部たるプロトコル運用テーブル２４と、ノード管理情報記憶部たるノード管理テーブル２５を備えている。プロトコル運用テーブル２４は、各プロトコルをいつ・どのような頻度で実行するかについての情報であり、具体的には図４に示すようなデータ構造となっている。このプロトコル種別格納レジスタ＃ｎは、ｎ番目（厳密に言うと、０番からスタートしているのでｎ＋１番目）に実行するプロトコル種別が格納されたレジスタへのポインタが格納されており、このプロトコル種別にしたがって、制御部２７がプロトコルの開始に際してプロトコルスタートフレームを送出する。
【００２９】
プロトコルスタートフレームは、トークンパッシングバス方式並びに疑似トークンパッシングバスではトークンの役割を、また、時間監視プロトコルではトリガフレームの役割を持つ。そして、具体的なフレーム構造は、図５に示すようになっており、このプロトコルスタートフレームを発した後、それ以降に開始されるプロトコルの種別情報が記述してある。
【００３０】
ノード管理テーブル２５は、各プロトコルに対応するノードアドレスを格納するもので、具体的には図６に示すようなデータ構造となっている。そして、各プロトコルの欄には、そのプロトコルにおいて送信するノード順に、ノードアドレスを格納する。この例でもレジスタへのポインタが格納されているが、具体的なアドレスを格納してももちろん良い。そして、図から明らかなように、各プロトコルに対応するノード数は必ずしも一致しないため、各プロトコルに対応するレジスタ数も異なることがある。
【００３１】
管理局２０の制御部２７は、保有する各テーブルに格納された情報に基づいて、ネットワークに接続された各ノードに対して初期設定を行うイニシャル機能と、その初期設定を終了後、所定のタイミングでプロトコルスタートフレームを発し、実際にシステムを稼動する運用機能を有する。具体的には、図７に示すフローチャートを実行するようになっている。
【００３２】
同図に示すように、まず、ノード管理テーブル２５に基づいて所定のノードに対して疑似トークンパッシングバスを実行するために必要な初期設定（疑似トークンイニシャル）を実行し（ＳＴ１０）、次いで、トークンパッシングバスを実行するために必要な初期設定（トークンイニシャル）を実行し、最後に時間監視プロトコルを実行するために必要な初期設定（時間監視イニシャル）を実行し（ＳＴ３０）、イニシャル機能を完了する。なお、各プロトコルのイニシャル手順は図示した例に限らず、任意の順で実行できる。
【００３３】
次いで、プロトコル運用テーブル２４を参照しながら、所定のタイミングで所望のプロトコルスタートフレームを送信するといった実際の運用を実行する（ＳＴ４０）。
【００３４】
そして、疑似トークンイニシャル（ＳＴ１０），トークンイニシャル（ＳＴ２０），時間監視イニシャル（ＳＴ３０）並びに運用実行（ＳＴ４０）の各処理は具体的にはそれぞれ図８〜図１１に示すようになっている。
【００３５】
すなわち、まず疑似トークンイニシャルは、図８に示すようにＩを０にセットし、先頭ノードに対するイニシャルか否かを判断する（ＳＴ１１，ＳＴ１２）。そして、先頭ノードの場合には、ステップ１３に進み、ノード管理テーブル２５の疑似トークンのテーブルにおけるノードアドレス設定レジスタ＃Ｉに格納されノードに対し、先頭ノードであることを通知する（ＳＴ１３）。一方、先頭ノードでない場合には、ステップ１４に進み、ノード管理テーブル２５の疑似トークンのテーブルにおけるノードアドレス設定レジスタ＃Ｉに格納されたノードに対し、そのノードの前のノードアドレス（設定レジスタ＃Ｉ−１の内容）を通知する（ＳＴ１３）。
【００３６】
そしてステップ１３，１４の処理を実行後、各通知を行ったノードに対し、引き続きそのノードの後のノードアドレス（設定レジスタ＃Ｉ＋１の内容）を通知する（ＳＴ１５）。
【００３７】
次いでＩをインクリメントし（ＳＴ１６）、疑似トークンの最終ノードか否かを判断し（ＳＴ１７）、最終ノードでない場合にはステップ１４に戻り、上記処理を実行する。このようにして、ノード管理テーブル２５の疑似トークンの欄に格納された全てのノードに対して、そのノード（自局）の前後のノードのノードアドレスを通知し、疑似トークンイニシャル手続を完了する。
【００３８】
トークンイニシャルは、図９に示すように、Ｉを０にセットし（ＳＴ２１）、ノード管理テーブル２５のトークンのテーブルにおけるノードアドレス設定レジスタ＃Ｉに格納されたノードに対し、そのノードの後のノードアドレス（設定レジスタ＃Ｉ＋１の内容）を通知する（ＳＴ２２）。
【００３９】
次いでＩをインクリメントし（ＳＴ２３）、トークンの最終ノードか否かを判断し（ＳＴ２４）、最終ノードでない場合にはステップ２２に戻り、上記処理を実行する。このようにして、ノード管理テーブル２５のトークンの欄に格納された全てノードに対して、そのノード（自局）の後のノードのノードアドレスを通知し、トークンイニシャル手続を完了する。
【００４０】
時間監視イニシャルは、図１０に示すように、Ｉを０にセットし（ＳＴ３１）、ノード管理テーブル２５の時間監視のテーブルにおけるノードアドレス設定レジスタ＃Ｉに格納されたノードに対し、そのノードの送信順番、つまり、「Ｉ」を通知する（ＳＴ３２）。
【００４１】
次いでＩをインクリメントし（ＳＴ３３）、時間監視で動作する最終ノードか否かを判断し（ＳＴ２４）、最終ノードでない場合にはステップ３２に戻り、上記処理を実行する。このようにして、ノード管理テーブル２５の時間監視の欄に格納された全てのノードに対して、そのノード（自局）の送信順番を通知し、時間監視イニシャル手続を完了する。
【００４２】
一方、運用実行は、図１１に示すように、Ｉを０にセットし（ＳＴ４１）、プロトコル運用テーブル２４に格納されたプロトコル種別格納レジスタ＃Ｉの内容を取得し、それに対応したプロトコルを動作するためのプロトコルスタートフレームを送出する（ＳＴ４２）。そして、その＃Ｉのプロトコルに基づき対応する全てのノードが伝送フレームの送信を完了したか否かを判断する（ＳＴ４３）。そして、係る送信が完了（プロトコル完了）するのを待つ。
【００４３】
完了後、Ｉをインクリメントし、プロトコル種別格納レジスタの最後か否かを判断し（ＳＴ４４，ＳＴ４５）、最後でない場合には、ステップ４２に戻り、係るインクリメントした新たなＩに基づいて決定されたプロトコルスタートフレームを送出する。
【００４４】
このようにすることにより、プロトコル運用テーブル２４に格納された＃０〜＃Ｙの全てについて、プロトコルスタートフレームを送信し、所望のプロトコルに基づく伝送フレームの送信が完了したならば、ステップ４１に戻りＩを０にリセットし、システム稼動停止するまで、上記処理を最初から繰り返し実行することになる。
【００４５】
一方、上記したイニシャル機能（ＳＴ１０，ＳＴ２０，ＳＴ３０）並びに運用機能（ＳＴ４０）の実行に伴い各通知を受けたノードは、図１２，図１３に示す処理を実行することになる。換言すると、各ノードには、係る処理機能を実現する制御部１５を備えることになる。
【００４６】
具体的には、イニシャル手順においては図１２に示すように、受信待ちをしている状態（ＳＴ５１）において、自ノード宛てのフレームの受信が有ったならば、その内容を解析し、疑似トークンイニシャルにおける先頭ノードの通知か否かを判断し（ＳＴ５２）、先頭ノード通知であれば、プロトコル対応テーブル１４の疑似トークンにおける疑似トークン対応フラグ並びに先頭ノードフラグにそれぞれ１をセットする（ＳＴ５３）。また、受信したフレームが疑似トークンの自局の前のノードアドレス通知（ＳＴ５４）の場合には、プロトコル対応テーブル１４の疑似トークンにおける疑似トークン対応フラグに１をセットするとともに、自局の前のノードアドレス格納レジスタに通知を受けた値をセットする（ＳＴ５５）。さらに、受信したフレームが疑似トークンの自局の後のノードアドレス通知（ＳＴ５６）の場合には、プロトコル対応テーブル１４の自局の後のノードアドレス格納レジスタに通知を受けた値をセットする（ＳＴ５７）。上記の処理を実行することにより、管理局２０のステップ１０に基づく処理に対応した疑似トークンイニシャル手順が完了する。
【００４７】
一方、受信したフレームがトークンの自局の後のノードアドレス通知（ＳＴ５８）の場合には、プロトコル対応テーブル１４のトークンにおけるトークン対応フラグに１をセットするとともに、自局の後のノードアドレス格納レジスタに通知を受けた値をセットする（ＳＴ５９）。この処理を実行することにより、管理局２０のステップ２０に基づく処理に対応したトークンイニシャル手順が完了する。
【００４８】
また、受信したフレームが時間監視の送信順番通知（ＳＴ６０）の場合には、プロトコル対応テーブル１４の時間監視における時間監視対応フラグに１をセットするとともに、送信順番格納レジスタに通知を受けた値（送信順番）をセットする（ＳＴ６１）。この処理を実行することにより、管理局２０のステップ３０に基づく処理に対応した時間監視イニシャル手順が完了する。
【００４９】
一方、受信したフレームがプロトコルスタートフレームの場合には、そのフレームのコマンドからプロトコル種別を解析し、疑似トークンであれば、自ノードのプロトコル対応テーブル２５をアクセスし、疑似トークン対応フラグが１になっているか否かを判断する（ＳＴ７２，ＳＴ７３）。そして、１の場合には、疑似トークン方式を実行する（ＳＴ７４）。つまり、プロトコル対応テーブル２５の自局の前のノードアドレスをもつノードからの伝送フレームを受信すると、自ノードから伝送フレームを送出する。なお、送信するデータがない場合には、空のデータを送出する。一方、疑似トークン対応フラグが１でない場合には、今回のプロトコルスタートフレームに基づくフレームの伝送には関与しないため、ステップ５１に戻り、次のフレーム受信を待つ。
【００５０】
また、受信したプロトコルスタートフレームのコマンドが、トークンであれば、自ノードのプロトコル対応テーブル２５をアクセスし、トークン対応フラグが１になっているか否かを判断する（ＳＴ７５，ＳＴ７６）。そして、１の場合には、トークン方式を実行する（ＳＴ７７）。つまり、トークンを取得し、自ノードから伝送フレームを送出する。一方、トークン対応フラグが１でない場合には、今回のプロトコルスタートフレームに基づくフレームの伝送には関与しないため、ステップ５１に戻り、次のフレーム受信を待つ。
【００５１】
さらにまた、受信したプロトコルスタートフレームのコマンドが、時間監視であれば、自ノードのプロトコル対応テーブル２５をアクセスし、時間監視対応フラグが１になっているか否かを判断する（ＳＴ７８，ＳＴ７９）。そして、１の場合には、時間監視プロトコルを実行する（ＳＴ８０）。つまり、各ノードから送信される伝送フレームを監視し、自己の送信順番が来たならば、伝送フレームを送出する。一方、時間監視対応フラグが１でない場合には、今回のプロトコルスタートフレームに基づくフレームの伝送には関与しないため、ステップ５１に戻り、次のフレーム受信を待つ。
【００５２】
そして、上記した処理を、ネットワークシステムが停止するまで繰り返し実行する。これにより、管理局２０に格納されたデータに基づいてネットワークに接続された各ノードに対するイニシャル手順を実行し、その後、実際の運用を実行させ、所望のプロトコルを用いてデータの伝送を可能とする。換言すると、プログラミングツール等を用いて管理局２０のプロトコル運用テーブル２４並びにノード管理テーブル２５を組み込むだけで、ネットワークを構築するノードに対するイニシャルが自動的に行える。
【００５３】
すなわち、各プロトコルは、管理局２０が送出するプロトコルスタートフレームにより開始される。そして、プロトコルスタートフレームには、それ以降に開始されるプロトコルの種別情報が記述してある。よって、ネットワークに接続されたノードは、プロトコルスタートフレームを受信し、それ以降に開始されるプロトコルの種別を認識し、各通信処理が開始される。また、各プロトコルの実行頻度を制御することで、各プロトコルを使用するサービスの応答性，容量について差を付けることが可能である。
【００５４】
図１４は、実際の運用例を示している。ここで、ノードは、アドレス＃０，１，２，３，４，５，６，７，８が接続されており、各ノードは、以下のプロトコルに対応するものとする。
アドレス＃０〜＃３→時間監視プロトコル
アドレス＃２，４，６，８→疑似トークンパッシングバス方式
アドレス＃５〜＃８→トークンパッシングバス方式
【００５５】
このように、同一ネットワーク上において異なるプロトコルを適宜の順で用いて伝送フレームの送受ができる。さらに、図示のように時間監視プロトコルを頻繁に行うことにより応答性をよくし、トークンパッシングバス方式と疑似トークンパッシングバスは交互に運用するようにすると、時間監視プロトコルを用いてインターロック信号の高速なハンドリングができ、例えば、複数のＮＣからなるノード１０に対する同期制御を行うに際し、インターロック１ｍｓｅｃ以下に制御することが簡単にできる。また、生産管理など、伝送データが多く、必ずしも頻繁に伝送しなくても良い場合には、例えばトークンパッシングバス方式により数十ｍｓｅｃのオーダーで実行することができる。
【００５６】
【発明の効果】
以上のように、この発明では、複数のノード間で通信を行う際に使用するトークンパッシングバス方式，疑似トークンパッシングバス，時間監視プロトコルなどの複数種のバスアピトレーションプロトコルを同一のネットワーク上で実行することができる。その結果、それぞれのプロトコルの特長を生かし、短所を補ったネットワークシステムを構築することができる。
【図面の簡単な説明】
【図１】本発明の好適な一実施の形態を示す図である。
【図２】各種のプロトコルの一例を示す図である。
【図３】プロトコル対応テーブルの内部データ構造を示す図である。
【図４】プロトコル運用テーブルの内部データ構造を示す図である。
【図５】プロトコルスタートフレームを示す図である。
【図６】ノード管理テーブルの内部データ構造を示す図である。
【図７】管理局の制御部の機能を示すフローチャートである。
【図８】疑似トークンイニシャルの具体的な処理手順を示すフローチャートである。
【図９】トークンイニシャルの具体的な処理手順を示すフローチャートである。
【図１０】時間監視イニシャルの具体的な処理手順を示すフローチャートである。
【図１１】運用実行の具体的な処理手順を示すフローチャートである。
【図１２】ノードの制御部の機能を示すフローチャートの一部である。
【図１３】ノードの制御部の機能を示すフローチャートの一部である。
【図１４】運用例を示す図である。
【符号の説明】
１０  ノード
１１  ケーブル
１２  送信部
１３  受信部
１４  プロトコル対応テーブル
１５  制御部
２０  管理局
２１  送信部
２２  受信部
２３  プロトコル対応テーブル
２４  プロトコル運用テーブル
２５  ノード管理テーブル
２７  制御部
【図１】
0003622607.tif 000002
【図２】
0003622607.tif 000003
【図３】
0003622607.tif 000004
【図４】
0003622607.tif 000005
【図５】
0003622607.tif 000006
【図６】
0003622607.tif 000007
【図７】
0003622607.tif 000008
【図８】
0003622607.tif 000009
【図９】
0003622607.tif 000010
【図１０】
0003622607.tif 000011
【図１１】
0003622607.tif 000012
【図１２】
0003622607.tif 000013
【図１３】
0003622607.tif 000014
【図１４】
0003622607.tif 000015