(57)【要約】【課題】複数ＰＬＣとの１対１通信に送達確認通信処理手順を少なくした効率的な通信をしながら、送信の衝突を防止する。【解決手段】各ＰＬＣ１Ａ〜１Ｎは、プロセッサ３にユーザ用メモリ３１とアプリケーションプログラム３２を設け、イーサネットインタフェース２に物理層２１とデータリンク層２２とＩＰ２３とＵＤＰ２４およびデータ送受信機能部２５を設ける。送信側ＰＬＣは、ＵＤＰが有するブロードキャスト送信機能を使用して、１回のコマンドリクエスト送信で複数のＰＬＣにデータを同時送信する。コマンドリクエストを受信したＰＬＣは、各々コマンドレスポンスを時間的にずらして送信側ＰＬＣに送信する。【選択図】　図１
2004088382.tif 000002
【特許請求の範囲】
【請求項１】
複数のコンピュータは、それぞれユーザ用メモリとアプリケーションプログラムを搭載するプロセッサと、物理層とデータリンク層とＩＰとＵＤＰおよび前記プロセッサの結合部にデータ送受信機能部を設けたイーサネットインタフェースとを有し、各コンピュータ間でネットワーク通信する通信方式であって、
送信側コンピュータは、前記ＵＤＰが有するブロードキャスト送信機能を使用して、１回のコマンドリクエスト送信で複数のコンピュータにデータを同時送信する手段を備え、
前記コマンドリクエストを受信したコンピュータは、各々コマンドレスポンスを時間的にずらして送信側コンピュータに送信する手段を備えたことを特徴とするコンピュータ間のネットワーク通信方式。
【請求項２】
前記アプリケーションプログラムが作成する前記コマンドリクエストのデータフォーマットは、自局のＩＰアドレスをセットした送信元局ＩＰアドレスと、受信局１局当たりに何ワード送信するかを指定する１局当たりデータワードサイズと、受信局が送達確認を応答する時間を決定する基準値をセットした送達確認応答タイマ基準値と、コマンドリクエストを送信する相手局数をセットした送信相手局数と、送信データが格納される相手局のＩＰアドレスをそれぞれ格納する受信局ＩＰアドレスと、相手局に送信するアプリケーションデータをそれぞれ格納する受信局送信データとで構成し、
前記アプリケーションプログラムが作成する前記コマンドレスポンスのデータフォーマットは、自局のＩＰアドレスをセットする送信元局ＩＰアドレスと、受信したコマンドリクエストに格納されている送信元局ＩＰアドレスをセットする応答送信先ＩＰアドレスとで構成したことを特徴とする請求項１に記載のコンピュータ間のネットワーク通信方式。
【請求項３】
前記コマンドリクエストの送信開始処理は、
前記アプリケーションプログラムでコマンドリクエスト送信のイベントが発生したとき、前記ユーザ用メモリ上に用意する再送カウンタを初期化し、次いで送信相手局にデータを送信するためにコマンドリクエストの作成を行い、さらに、送達確認受信待ちタイマのタイマ値＝送達確認応答タイマ基準値×（送信相手局数＋１）にして起動し、最後にイーサネット・インタフェースに対して送信要求を発行することを特徴とする請求項１または２に記載のコンピュータ間のネットワーク通信方式。
【請求項４】
前記送信局の送達確認待ち処理は、
前記アプリケーションプログラムでコマンドリクエストを送信後、前記送達確認受信待ちタイマがタイムアップしたならば処理を終了し、タイムアップでなければ、コマンドレスポンスの受信を待ち、コマンドレスポンスを受信したときにはコマンドレスポンス中の前記送信元局ＩＰアドレスからの送達確認受信を記憶し、次いで今回のコマンドレスポンス受信で送信相手局すべてから送達確認を受信したかチェックし、全ての送達確認を受信完了したときに送達確認受信待ちタイマを停止させ、データ送信処理を完了することを特徴とする請求項１〜３のいずれか１項に記載のコンピュータ間のネットワーク通信方式。
【請求項５】
前記送達確認受信待ちタイマのタイムアップ処理は、
前記アプリケーションプログラムでコマンドリクエスト送信後、前記再送カウンタが最大再送回数であれば、送達確認未受信の相手局を異常と認識しエラー処理を行い、
前記再送カウンタが最大再送回数未満ならば再送カウンタを＋１し、既に送達確認を受信している相手局の情報は削除して前記コマンドリクエストの作り直しを行い、次いで前記変更した送信相手局数から送達確認受信待ちタイマ値を計算しなおし再起動し、イーサネット・インタフェースに対して送信要求を発行することを特徴とする請求項１〜４のいずれか１項に記載のコンピュータ間のネットワーク通信方式。
【請求項６】
前記コマンドリクエストの受信処理は、
コマンドリクエストを受信したとき、受信したコマンドリクエストのアプリケーションヘッダ部の受信局ＩＰアドレスの中に自局と一致するエントリがあるか否かをチェックし、自局のＩＰアドレスと一致するエントリがなければ、自局に対するコマンドリクエストではないのでそのままにし、
自局のＩＰアドレスと一致するエントリがあったときは自局宛の送信データを取り込み、その後、自局と一致した受信局ＩＰアドレスの該当番号に前記送達確認応答タイマ基準値をかけた時間経過するのを待ち、コマンドレスポンスを作成し、イーサネット・インタフェースに送信要求を発行することを特徴とする請求項１〜５のいずれか１項に記載のコンピュータ間のネットワーク通信方式。
【請求項７】
前記データ送受信機能部の送信要求処理は、
前記アプリケーションプログラムから送信要求を受け取ったとき、送信データの先頭ワードをチェックし、前記コマンドリクエストを示すデータであれば宛先ＩＰアドレスをブロードキャストアドレスにして前記ＵＤＰに送信要求を発行し、コマンドレスポンスを示すデータであれば宛先ＩＰアドレスを応答送信先ＩＰアドレスにして前記ＵＤＰに送信要求を発行することを特徴とする請求項１〜６のいずれか１項に記載のコンピュータ間のネットワーク通信方式。
【発明の詳細な説明】
【０００１】
【発明の属する技術分野】
本発明は、ＰＬＣ（プログラマブル・ロジック・コントローラ）などのコンピュータ同士をイーサネット（Ｅｔｈｅｒｎｅｔ：登録商標）でネットワーク接続して互いの通信を行うコンピュータ間のネットワーク通信方式に関わる。
【０００２】
【従来の技術】
この種の通信方式は、例えば、特開２００１−２４５０１４に開示される。また、ＴＣＰ／ＩＰによる通信方式は、文献「ＳＯＦＴＢＡＮＫＢＯＯＫＳ，詳解ＴＣＰ／ＩＰ，著者　Ｗ．Ｒｉｃｈａｒｄ　Ｓｔｅｖｅｎｓ，訳者　橘康雄」に詳述される。
【０００３】
前記の公報、文献に開示されるように、イーサネットは、同軸ケーブルをデータ伝送媒体に用い、ＣＳＭＡ／ＣＤ方式（衝突検出型搬送波多重ＬＡＮのアクセス方式）のインターフェースによってコンピュータ同士の通信を可能にする。
【０００４】
近年、プラントにおける監視制御システムは、ホストコンピュータとしてワークステーションやミニコンに代えてパソコンが採用され、それに伴い最も一般的なイーサネットがコンピュータ上位ネットワークおよびコンピュータ間ネットワークのデファクト・スタンダードとして確立されたといってもよい。
【０００５】
これらパソコンやＰＬＣは、イーサネットを使った通信のためのインタフエースにＴＣＰ／ＩＰプロトコルを実装する場合、１対１通信を行うならば、信頼性の高いＴＣＰ／ＩＰを使うことが多い。
【０００６】
しかしながら、制御ＬＡＮとしての位置付けを考慮すると、論理回線の接続および切断処理は性能低下につながることから好ましくない。
【０００７】
論理回線の接続および切断処理を嫌うならば、１対１通信をＵＤＰ／ＩＰで実現することになる。なお、ＵＤＰは、それ自体に再送処理を持たないし、送達確認も行わないプロトコルである。
【０００８】
従って、１対１通信をＵＤＰ／ＩＰで実行する際に、通信の信頼性を高めるには、図１０の（ａ）に示すように、アプリケーション層（一般にラダープログラム）がＵＤＰ／ＩＰを通してデータを相手に送信（コマンドリクエスト送信）し、送信相手のアプリケーション層が送達確認を応答送信（コマンドレスポンス送信）することで送達確認をする。また、図１０の（ｂ）に示すように、送信元のアプリケーション層は、その送達確認受信を送信からの経過時間で監視し、一定時間経過しても受信しない場合、再送処理を行い、一定回数の受信なしで相手局の異常と認識するようにしている。
【０００９】
【発明が解決しようとする課題】
前記のように、１対１通信にＵＤＰを採用するなら論理回線の接続および切断処理は不要になる。しかしながら、ＴＣＰの持つ機能を、わざわざアプリケーション層で行うはめになり、ＵＤＰを採用するメリットが少なくなる。
【００１０】
本発明の目的は、イーサネットでネットワーク接続したコンピュータ間の通信に、ＵＤＰ／ＩＰを使用しながら通信効率を高めたネットワーク通信方式を提供することにある。
【００１１】
【課題を解決するための手段】
本発明は、送信局ではＵＤＰが有するブロードキャスト送信機能を有効活用し、送達確認付きの１対Ｎ通信として１回のコマンドリクエスト送信で複数局にデータを同時送信し、コマンドリクエストの受信局が各々コマンドレスポンスを時間的にずらして送信局に送信することで、送達確認通信処理手順を少なくしながら、送信の衝突を防止するようにしたもので、以下の通信方式を特徴とする。
【００１２】
（１）複数のコンピュータは、それぞれユーザ用メモリとアプリケーションプログラムを搭載するプロセッサと、物理層とデータリンク層とＩＰとＵＤＰおよび前記プロセッサの結合部にデータ送受信機能部を設けたイーサネットインタフェースとを有し、各コンピュータ間でネットワーク通信する通信方式であって、
送信側コンピュータは、前記ＵＤＰが有するブロードキャスト送信機能を使用して、１回のコマンドリクエスト送信で複数のコンピュータにデータを同時送信する手段を備え、
前記コマンドリクエストを受信したコンピュータは、各々コマンドレスポンスを時間的にずらして送信側コンピュータに送信する手段を備えたことを特徴とする。
【００１３】
（２）前記アプリケーションプログラムが作成する前記コマンドリクエストのデータフォーマットは、自局のＩＰアドレスをセットした送信元局ＩＰアドレスと、受信局１局当たりに何ワード送信するかを指定する１局当たりデータワードサイズと、受信局が送達確認を応答する時間を決定する基準値をセットした送達確認応答タイマ基準値と、コマンドリクエストを送信する相手局数をセットした送信相手局数と、送信データが格納される相手局のＩＰアドレスをそれぞれ格納する受信局ＩＰアドレスと、相手局に送信するアプリケーションデータをそれぞれ格納する受信局送信データとで構成し、
前記アプリケーションプログラムが作成する前記コマンドレスポンスのデータフォーマットは、自局のＩＰアドレスをセットする送信元局ＩＰアドレスと、受信したコマンドリクエストに格納されている送信元局ＩＰアドレスをセットする応答送信先ＩＰアドレスとで構成したことを特徴とする。
【００１４】
（３）前記コマンドリクエストの送信開始処理は、
前記アプリケーションプログラムでコマンドリクエスト送信のイベントが発生したとき、前記ユーザ用メモリ上に用意する再送カウンタを初期化し、次いで送信相手局にデータを送信するためにコマンドリクエストの作成を行い、さらに、送達確認受信待ちタイマのタイマ値＝送達確認応答タイマ基準値×（送信相手局数＋１）にして起動し、最後にイーサネット・インタフェースに対して送信要求を発行することを特徴とする。
【００１５】
（４）前記送信局の送達確認待ち処理は、
前記アプリケーションプログラムでコマンドリクエストを送信後、前記送達確認受信待ちタイマがタイムアップしたならば処理を終了し、タイムアップでなければ、コマンドレスポンスの受信を待ち、コマンドレスポンスを受信したときにはコマンドレスポンス中の前記送信元局ＩＰアドレスからの送達確認受信を記憶し、次いで今回のコマンドレスポンス受信で送信相手局すべてから送達確認を受信したかチェックし、全ての送達確認を受信完了したときに送達確認受信待ちタイマを停止させ、データ送信処理を完了することを特徴とする。
【００１６】
（５）前記送達確認受信待ちタイマのタイムアップ処理は、
前記アプリケーションプログラムでコマンドリクエスト送信後、前記再送カウンタが最大再送回数であれば、送達確認未受信の相手局を異常と認識しエラー処理を行い、
前記再送カウンタが最大再送回数未満ならば再送カウンタを＋１し、既に送達確認を受信している相手局の情報は削除して前記コマンドリクエストの作り直しを行い、次いで前記変更した送信相手局数から送達確認受信待ちタイマ値を計算しなおし再起動し、イーサネット・インタフェースに対して送信要求を発行することを特徴とする。
【００１７】
（６）前記コマンドリクエストの受信処理は、
コマンドリクエストを受信したとき、受信したコマンドリクエストのアプリケーションヘッダ部の受信局ＩＰアドレスの中に自局と一致するエントリがあるか否かをチェックし、自局のＩＰアドレスと一致するエントリがなければ、自局に対するコマンドリクエストではないのでそのままにし、
自局のＩＰアドレスと一致するエントリがあったときは自局宛の送信データを取り込み、その後、自局と一致した受信局ＩＰアドレスの該当番号に前記送達確認応答タイマ基準値をかけた時間経過するのを待ち、コマンドレスポンスを作成し、イーサネット・インタフェースに送信要求を発行することを特徴とする。
【００１８】
（７）前記データ送受信機能部の送信要求処理は、
前記アプリケーションプログラムから送信要求を受け取ったとき、送信データの先頭ワードをチェックし、前記コマンドリクエストを示すデータであれば宛先ＩＰアドレスをブロードキャストアドレスにして前記ＵＤＰに送信要求を発行し、コマンドレスポンスを示すデータであれば宛先ＩＰアドレスを応答送信先ＩＰアドレスにして前記ＵＤＰに送信要求を発行することを特徴とする。
【００１９】
【発明の実施の形態】
本発明の実施形態になるシステム構成は、図１に示すように、ＰＬＣ１ＡとＰＬＣ１Ｂ〜１Ｎがイーサネットで接続される。なお、これらをコンピュータとする場合の通信も同様である。
【００２０】
ＰＬＣ１Ａ，１Ｂ〜１Ｎは、ＰＬＣ１Ａに代表して示すように、それぞれ相互通信機能を得るためのイーサネット・インタフェース２を設ける。プロセッサ３にはユーザ用メモリ３１とそれを使用するブプリケーションプログラム（アプリケーション層）３２を持つ。
【００２１】
イーサネット・インタフェース２は、物理層２１とデータリンク層２２とＩＰ２３およびＵＤＰ２４の他に、プロセッサ３との結合部にデータ送受信機能部２５を設ける。データ送受信機能部２５は、データリンク層２２とＩＰ２３とＵＤＰ２４と同様にソフトウェアで構成される。
【００２２】
以上の構成において、主たる部位は、イーサネット・インタフェース２のデータ送受信機能部２５とプロセッサ３のアプリケーションプログラム３２であり、ＵＤＰを使用して１対１通信を行うのに際し、ＵＤＰのメリットを最大限に活かすため、ＵＤＰの特長であるブロードキャスト送信を有効活用した送達確認付きの１対Ｎ通信（１対１通信をＮ回行うのと同等の処理）を実現する。
【００２３】
図２は、基本的な通信処理を示し、同図の（ａ）にはＵＤＰによる通常の１対１通信を示し、（ｂ）にはＵＤＰによる１対Ｎ通信を示す。
【００２４】
図２の（ａ）において、ＰＬＣ１ＡがＰＬＣ１Ｂ，ＰＬＣ１Ｃ，ＰＬＣ１Ｄなどの複数局（局数＝Ｎ）と通信する場合、１対１通信（コマンドリクエスト送信とコマンドレスポンス受信の組み合わせ）をＮ回行って実現する。
【００２５】
これに対して、本発明は図２の（ｂ）に示すように、複数局Ｎにコマンドリクエスト送信の１回でデータを同時送信し（但し、一局に対するデータサイズは限定される）、コマンドリクエストを受信した複数の局が各々送達確認であるコマンドレスポンスを時間的にずらして送信することで送信の衝突を防止する。このような通信処理をすることで、複数局との送達確認通信処理手順が少なくなり、効率的な通信処理を実現する。
【００２６】
上記のような通信処理を実現するためのデータフォーマットおよび各処理を以下に詳細に説明する。なお、システム構成は、各局のＩＰアドレスをクラスＣのアドレスとし、従ってホストアドレスは１〜２５４とすることを前提とする（ネットワークアドレスは任意）。また、ローカルに閉じたネットワークを対象とし、ネットワークがまたがる通信は考慮しないことを前提とする。また、ＵＤＰで使用するポート番号は、任意の値を本発明の機能用に割り振ることを前提とする。
【００２７】
（Ａ）コマンドリクエストバッファのデータフォーマット
図３は、コマンドリクエストを送信するＰＬＣのアプリケーションプログラム３２がユーザ用メモリ３１上に作成する送信データバッファのフォーマットを示す。なお、ＵＤＰヘッダ、ＩＰヘッダ、イーサネットヘッダはイーサネット・インタフェース２によって付加される。また、以下のフォーマットは、送信相手局のＭＡＸ値を１１局とした場合を想定している。
【００２８】
図３において、
（１）コマンドリクエストは、コマンドリクエストを示すデータであり、任意の値でよい。
【００２９】
（２）送信元局ＩＰアドレスは、自局のＩＰアドレス（ホストアドレスのみ）をセットする。１〜２５４となる。
【００３０】
（３）１局当たりデータワードサイズは、受信局１局当たりに何ワード送信するかを指定する。各局で同一サイズとする。送信データ部分のＭＡＸ値が７２０ワードであり、受信局数を考慮してこのデータをチューニングする。
【００３１】
（４）送達確認応答タイマ基準値（単位：ｍｓ）は、コマンドリクエストを受信した局が、送達確認を応答する時間を決定する基準値をセットする。コマンドリクエストを受信した局は、自局ＩＰアドレスと受信局ＩＰアドレスのいずれかが一致した場合、データを取り込み、対応する受信局ナンバ（ＮＯ）×タイマ基準値の時間経過後に送達確認を送信する。また、コマンドリクエストを送信する側は、この値（送信相手局数＋１）を送達確認受信待ちのタイマ値とする。
【００３２】
（５）送信相手局数は、コマンドリクエストを送信する相手局数をセットする。送達確認受信待ちタイマがタイムアップした時、すべての送信相手から送達確認を受信していればよいが、送達確認を受信できなかった局があれば、再送処理を行う。その場合、送信相手局数は、送達確認を受信できなかった局数に変更して再送を行う。
【００３３】
（６）受信局ＮＯ１〜ＮＯ１１　ＩＰアドレスは、送信バッファに送信データが格納される相手局のＩＰアドレス（ホストアドレス）をＮＯ１から順番にすべてを格納する。相手局が１１局の場合はすべてに１〜２５４の値が格納されるが、１１未満の時は、最終格納位置から後は、０を格納する。
【００３４】
（７）受信局ＮＯ１〜ＮＯ１１に対する送信データは、相手局に送信するアプリケーションデータである。ＮＯ毎の切れ目は、１局当たりのデータワードサイズによる。
【００３５】
（Ｂ）コマンドレスポンスバッファのデータフォーマット
図４は、コマンドリクエストを受信したＰＬＣのアプリケーションプログラム３２がデータメモリ３１上に作成する応答送信データバッファのフォーマットを示す。なお、ＵＤＰヘッダ、ＩＰヘッダ、イーサネットヘッダはイーサネット・インタフェース２によって付加される。
【００３６】
図４において、
（１）コマンドレスポンスは、コマンドレスポンスを示すデータであり、任意の値でよい。
【００３７】
（２）送信元局ＩＰアドレスは、自局のＩＰアドレス（ホストアドレスのみ）をセットする。１〜２５４となる。
【００３８】
（３）応答送信先ＩＰアドレスは、受信したコマンドリクエストバッファに格納されている送信元局ＩＰアドレスをセットする。
【００３９】
（Ｃ）送信局の送信開始処理
図５は、コマンドリクエスト送信局のアプリケーションプログラム３２での送信開始処理のアルゴリズムを示す。
【００４０】
同図において、ＰＬＣのアプリケーションプログラム３２でコマンドリクエスト送信のイベントが発生（Ａ１）したならば、まず、ユーザ用メモリ上に用意する再送カウンタを０（初期化）にする（Ａ２）。次に、送信相手Ｎ局にデータを送信するため、コマンドリクエストバッファの作成を行う（Ａ３）。さらに、送達確認受信待ちタイマをタイマ値＝送達確認応答タイマ基準値×（送信相手局数＋１）で起動する（Ａ４）。相手局から応答される送達確認の最終は、送信してから送達確認応答タイマ基準値×送信相手局数の時間経過後に送信されてくるので、送達確認受信待ちタイマがタイムアップするときには、すべての相手局から送達確認が応答されることになる。最後にイーサネット・インタフェース２に対して送信要求を発行する（Ａ５）。
【００４１】
この処理によれば、相手の応答性能に合わせて送達確認応答タイマ基準値をチューニングすることで、１回の通信処理の実行時間を調整できる。
【００４２】
（Ｄ）送信局の送達確認待ち処理
図６は、コマンドリクエスト送信局のアプリケーションプログラム３２での送達確認待ち処理のアルゴリズムを示す。
【００４３】
同図において、ＰＬＣのアプリケーションプログラム３２でコマンドリクエスト送信後、送達確認受信待ちタイマがタイムアップしたならば処理を終了し、送達確認受信待ちタイマタイムアップ処理に移行する。タイムアップでなければ、コマンドレスポンスの受信を待つ（Ｂ１）。コマンドレスポンスを受信したならば（Ｂ２）、コマンドレスポンスバッファ中の送信元局ＩＰアドレスからの送達確認受信を記憶する（Ｂ３）。次に、今回のコマンドレスポンス受信で送信相手局すべてから送達確認を受信したかチェックし（Ｂ４）、まだ全てから受信していなければ、さらにコマンドレスポンスの受信を待つ。全てから送達確認を受信完了したら、送達確認受信待ちタイマを停止させ、データ送信処理を完了する（Ｂ５）。
【００４４】
（Ｅ）送達確認受信待ちタイマのタイムアップ処理
図７は、ＰＬＣのアプリケーションプログラム３２でコマンドリクエスト送信後、送達確認受信待ちタイマがタイムアップしたときのタイムアップ処理のアルゴリズムを示す。
【００４５】
同図において、再送カウンタがＮ（Ｎ＝最大再送回数）であれば（Ｃ１）、所定の回数の再送が終了したことを意味するので、送達確認未受信の相手局を異常と認識しエラー処理を行い（Ｃ３）、処理を終える。
【００４６】
再送カウンタがＮ未満ならば再送途中を意味し、再送カウンタを＋１し（Ｃ２）、コマンドリクエストバッファの作り直しを行う（Ｃ４）。この際、既に送達確認を受信している相手局の情報は削除する。具体的には、まずアプリケーションヘッダ部の送信相手局数を送達確認受信があった分だけ引いた値にする。そして受信局ＮＯ１〜ＮＯ１１ＩＰアドレスから送達確認のあった局を削除し詰め直しを行う。さらに、送達確認のあった局への送信データを削除し、詰め直しを行う。
【００４７】
次に、変更した送信相手局数から送達確認受信待ちタイマ値を計算しなおし再起動する（Ｃ５）。最後に、イーサネット・インタフェース２に対し、送信要求を発行する（Ｃ６）。
【００４８】
（Ｆ）コマンドリクエスト受信処理
図８は、コマンドリクエストを受信したＰＬＣのアプリケーションプログラム３２のコマンドリクエスト受信処理のアルゴリズムを示す。
【００４９】
同図において、コマンドリクエストを受信したら（Ｄ１）、受信したコマンドリクエストバッファのアプリケーションヘッダ部の受信局ＮＯ１〜ＮＯ１１のＩＰアドレスの中に自局と一致するエントリがあるか否かをチェックする（Ｄ２）。自局のＩＰアドレスと一致するエントリがなければ、自局に対するコマンドリクエストではないので何もしない。
【００５０】
自局のＩＰアドレスと一致するエントリがあったならば、アプリケーションデータ部より自局宛の送信データを取り込む。その際、先頭のワードオフセットは、アプリケーションヘッダ部の先頭＋（受信局ＩＰアドレスの該当ＮＯ−１）×１局当たりのデータワードサイズとなる（Ｄ３）。
【００５１】
その後、自局と一致した受信局ＩＰアドレスの該当ＮＯに送達確認応答タイマ基準値をかけた時間経過するのを待って（Ｄ４）、コマンドレスポンスを作成し（Ｄ５）、イーサネット・インタフェース２に送信要求を発行する（Ｄ６）。
【００５２】
この処理の特長は、コマンドリクエストを受信してからコマンドレスポンスを応答するまでの時間がすべての局で異なるので送信の衝突が発生しないことにある。
【００５３】
（Ｇ）データ送受信機能の送信要求処理
図９は、イーサネット・インタフェース２のデータ送受信機能２５が、プロセッサ３より送信要求を受け取った時のアルゴリズムを示す。
【００５４】
同図において、アプリケーションプログラム３２が送信要求を発行することでプロセッサから送信要求を受け取ったとき（Ｅ１）、送信データの先頭ワードをチェックし、コマンドリクエストを示すデータであれば（Ｅ２）、宛先ＩＰアドレスをブロードキャストアドレスにしてＵＤＰに送信要求を発行する（Ｅ３）。
【００５５】
また、コマンドレスポンスを示すデータであれば（Ｅ４）、宛先ＩＰアドレスをバッファ中の応答送信先ＩＰアドレスにしてＵＤＰに送信要求を発行する。
【００５６】
ようするに、コマンドリクエストはブロードキャスト送信され、コマンドレスポンスは送信元のみに送信される。
【００５７】
【発明の効果】
以上のとおり、本発明によれば、送信局ではＵＤＰが有するブロードキャスト送信機能を有効活用し、送達確認付きの１対Ｎ通信として１回のコマンドリクエスト送信で複数局にデータを同時送信し、コマンドリクエストの受信局が各々コマンドレスポンスを時間的にずらして送信局に送信するようにしたため、複数局との１対１通信に送達確認通信処理手順を少なくした効率的な通信をしながら、送信の衝突を防止することができる。
【図面の簡単な説明】
【図１】本発明の実施形態を示すシステム構成図。
【図２】本発明におけるＵＤＰによる複数局との１対１通信経路図。
【図３】実施形態におけるコマンドリクエストバッファのデータフォーマット。
【図４】実施形態におけるコマンドレスポンスバッファのデータフォーマット。
【図５】実施形態における送信局の送信開始処理。
【図６】実施形態における送信局の送達確認待ち処理。
【図７】実施形態における送達確認待ちタイマのタイムアップ処理。
【図８】実施形態におけるコマンドリクエスト受信処理。
【図９】実施形態におけるデータ送受信機能部の送信要求処理。
【図１０】ＵＤＰによる一般的な１対１通信経路図。
【符号の説明】
１Ａ，１Ｂ，１Ｎ…ＰＬＣ
２…イーサネット・インタフェース
３…プロセッサ
２１…物理層
２２…データリンク層
２３…ＩＰ
２４…ＵＤＰ
２５…データ送受信機能
３１…ユーザ用メモリ
３２…アプリケーションプログラム
【図１】
2004088382.tif 000003
【図２】
2004088382.tif 000004
【図３】
2004088382.tif 000005
【図４】
2004088382.tif 000006
【図５】
2004088382.tif 000007
【図６】
2004088382.tif 000008
【図７】
2004088382.tif 000009
【図８】
2004088382.tif 000010
【図９】
2004088382.tif 000011
【図１０】
2004088382.tif 000012