(57)【要約】【課題】  工程管理システムにおけるサーバ間で、必ずしもリアルタイム性が要求されないデータ送受信を円滑に行う手段を提供する。【解決手段】  工程サーバ２は、データを送信するためにＴＣＰ／ＩＰ送信用ソケットの開設を行う（Ｓ４０１）。統括サーバ３は、データを受信するためにＴＣＰ／ＩＰ受信用ソケットの開設準備を行い（Ｓ４０２）、ソケットの開設を行う（Ｓ４０３）。工程サーバ２は、送信要求があれば（Ｓ４０４のＹｅｓ）、送信先別データ群に格納されている未送信のデータを、ファイルとして送信用フォルダにコピーする（Ｓ４０５）。そして、統括サーバ３に受信要求メッセージを送信する（Ｓ４０６）。統括サーバ３は、工程サーバ２から受信要求メッセージを受信する（Ｓ４０７）。次に、その受信要求メッセージによって示されたファイルを、工程サーバ２の送信用フォルダから統括サーバ３の受信用フォルダにＦＴＰで受信する（Ｓ４０８）。【選択図】      図４
2005267011.tif 000002
【特許請求の範囲】
【請求項１】
各工程を管理する工程サーバと、全工程を管理する統括サーバとがネットワークによって接続されて構成される工程管理システムにおいて、任意のサーバ間で工程に関するデータの送受信を行うデータ送受信方法であって、
送信元サーバが、前記データの所在を示すデータ所在情報を含むデータ受信要求メッセージを送信先サーバに送信するステップと、
前記送信先サーバが、前記データ受信要求メッセージを受信し、その受信したデータ受信要求メッセージに含まれるデータ所在情報に従って、前記送信元サーバから前記データを受信するステップと、
を含むことを特徴とするデータ送受信方法。
【請求項２】
各工程を管理する工程サーバと、全工程を管理する統括サーバとがネットワークによって接続されて構成される工程管理システムにおいて、任意のサーバ間で工程に関するデータの送受信を行うデータ送受信方法であって、
送信元サーバが、ＴＣＰ／ＩＰ送信用のソケットを開設するステップと、
送信先サーバが、ＴＣＰ／ＩＰ受信用のソケットを開設するステップと、
前記送信元サーバが、前記送信先サーバに送信しようとするデータを所定のフォルダにファイルとして格納するステップと、
前記送信元サーバが、その送信元サーバのＩＰアドレス、前記データのファイルを格納したフォルダ名およびファイル名を含むデータ受信要求メッセージを前記送信先サーバにソケット通信によって送信するステップと、
前記送信先サーバが、前記データ受信要求メッセージをソケット通信によって受信し、その受信したデータ受信要求メッセージに含まれるＩＰアドレス、フォルダ名およびファイル名に従って、前記送信元サーバから前記データのファイルをＦＴＰ通信によって受信するステップと、
を含むことを特徴とするデータ送受信方法。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、工程管理システムのサーバ間における工程データの送受信方法に関する。
【背景技術】
【０００２】
工程管理システムは、生産計画に従って各工程に対して生産の指示を発行し、各工程から生産の実績を入力し、その入力した実績や今後の生産計画に基づいて更に生産の指示を行うシステムである。その工程管理システムは、工程の全体管理を行う統括サーバと、各工程の管理を行う複数の工程サーバとが、ネットワークを介して接続されて構成される。工程サーバは、統括サーバからの指示を受けて、または、定期的に（例えば、毎週、毎月など）自工程における生産の実績データを作成し、その作成した実績データを統括サーバに送信する。この実績データを送信するとき、統括サーバに共有のフォルダを設けておいて、各工程サーバがそのフォルダを送信先としてデータ送信を行う方法がある。この方法によれば、統括サーバに１つのフォルダを設けることによって、複数の工程サーバが実績データの送信を行うことができる。実績データの送信には、必ずしもリアルタイム性が要求されないので、他の工程サーバが送信しているときには、それが終了してから送信することも可能である。統括サーバと工程サーバとの間のデータ送受信用プロトコルとしては、ＦＴＰ（File Transfer Protocol）を適用することが多い（ＦＴＰの実施例については、特許文献１参照）。
【特許文献１】特開平１１−１４９４２７号公報（段落００１５〜００３０、図１、図２）
【発明の開示】
【発明が解決しようとする課題】
【０００３】
しかしながら、統括サーバの共有フォルダに各工程サーバが実績データを送信する方法においては、統括サーバがダウンしていたり、他の工程サーバが送信しているときには、データの送信ができないという問題がある。ＦＴＰを適用した場合、共有フォルダに送信可能な状態であって、他の工程サーバが送信していなければ、その時点で送信可能になるが、データを送信できない状態から送信できる状態になったことが通知されるわけではない。従って、一旦送信できない状態に遭遇すると、送信できるようになるまで、工程サーバが統括サーバへのデータ送信をリトライ（再試行）する必要があり、工程サーバの負担が大きい。このとき、複数の工程サーバがデータ送信のリトライを行うと、ネットワーク上のトラフィックが増大してしまう。一方、統括サーバ・工程サーバ間だけでなく、工程サーバ同士でデータの送受信を行うことによって、例えば、統括サーバを介することなく工程間の生産の調整などを行いたいというニーズもある。
【０００４】
そこで、本発明は、前記問題に鑑み、工程管理システムにおけるサーバ間で、必ずしもリアルタイム性が要求されないデータ送受信を円滑に行う手段を提供することを課題とする。
【課題を解決するための手段】
【０００５】
前記課題を解決する本発明のうち、請求項１に係る発明は、各工程を管理する工程サーバと、全工程を管理する統括サーバとがネットワークによって接続されて構成される工程管理システムにおいて、任意のサーバ間で工程に関するデータの送受信を行うデータ送受信方法であって、送信元サーバが、データの所在を示すデータ所在情報を含むデータ受信要求メッセージを送信先サーバに送信するステップと、送信先サーバが、データ受信要求メッセージを受信し、その受信したデータ受信要求メッセージに含まれるデータ所在情報に従って、送信元サーバからデータを受信するステップとを含むことを特徴とする。
【０００６】
請求項２に係る発明は、各工程を管理する工程サーバと、全工程を管理する統括サーバとがネットワークによって接続されて構成される工程管理システムにおいて、任意のサーバ間で工程に関するデータの送受信を行うデータ送受信方法であって、送信元サーバが、ＴＣＰ／ＩＰ送信用のソケットを開設するステップと、送信先サーバが、ＴＣＰ／ＩＰ受信用のソケットを開設するステップと、送信元サーバが、送信先サーバに送信しようとするデータを所定のフォルダにファイルとして格納するステップと、送信元サーバが、その送信元サーバのＩＰアドレス、データのファイルを格納したフォルダ名およびファイル名を含むデータ受信要求メッセージを送信先サーバにソケット通信によって送信するステップと、送信先サーバが、データ受信要求メッセージをソケット通信によって受信し、その受信したデータ受信要求メッセージに含まれるＩＰアドレス、フォルダ名およびファイル名に従って、送信元サーバからデータのファイルをＦＴＰ通信によって受信するステップとを含むことを特徴とする。
【発明の効果】
【０００７】
請求項１および請求項２に係る発明によれば、データ受信要求メッセージを受けた送信先サーバが実際のデータ受信を行うので、必要なときだけネットワークを使用することになり、ファイル共有の場合と比較して、送信先サーバへのアクセスの競合などによるネットワーク上の無用なトラフィックが少なくなる。送信元サーバがデータ受信要求メッセージを送信先サーバに送信することによって、実際のデータ受信は送信先サーバが行うので、送信元サーバは他の処理を行うことができる。例えば、送信元サーバが工程サーバであるとき、データ送受信に係るネットワーク障害が発生していても、工程サーバは工程に関する処理を進めることができる。
【発明を実施するための最良の形態】
【０００８】
以下、本発明を実施するための最良の形態（以下、「本発明の実施の形態」という）について図面を参照して詳細に説明する。
【０００９】
≪工程管理システムの構成と概要≫
まず、図１を参照して、本発明の実施の形態に係る工程管理システムの構成と概要について説明する。図１に示すように、工程管理システム１は、工程サーバ２、統括サーバ３およびそれらを接続するネットワーク４から構成される。
工程サーバ２は、所定の工業製品を製造する工場の生産ラインにおける１つの工程を管理するサーバである。統括サーバ３から受信した生産指示データに基づいて生産の指示を行い、所定の時間や所定の期間ごとの生産実績データを作成し、その作成したデータを定期的に統括サーバ３に送信する。また、前記生産指示を達成することができるように、全工程における前工程または後工程に係る他の工程サーバ２との間で生産の調整などを行うためのデータを送受信することもある。工程サーバ２には、例えば、制御用コンピュータを介して生産用ロボットが接続されていて（図示せず）、製品種別、品数、使用部材などの具体的な生産の指示、その工程における生産実績データの採取などをリアルタイムに実行できるように構成されている。なお、工程サーバ２は、１つの工程ではなく、複数の工程をまとめて管理する機能を持っていてもよい。
統括サーバ３は、製造工場における生産ライン全体を統括管理するサーバであり、ネットワーク４を介して複数の工程サーバ２と接続される。各工程サーバ２に生産の指示を行うために生産指示データを送信し、定期的に各工程サーバ２から生産実績データを受信し、その受信した生産実績データや今後の生産計画などに基づいて、更に生産指示データの送信を行うことによって、生産ライン全体を統括管理する。なお、工程サーバ２および統括サーバ３は、ＰＣ（Personal Computer）やサーバなどによって実現される。詳細な構成については後記する。
ネットワーク４は、工程サーバ２および統括サーバ３を接続する通信網であり、構内ＬＡＮ（Local Area Network）などによって実現される。
【００１０】
≪サーバの構成と概要≫
次に、図２を参照して、本発明の実施の形態に係る工程サーバの構成と概要について説明する。図２に示すように、工程サーバ２は、制御手段２１、送信データ記憶手段２２および受信データ記憶手段２３から構成される。
制御手段２１は、工程サーバ２を制御する中枢機能を有するものであり、メイン制御プログラム２１ａ、データ送信処理プログラム２１ｂ、データ受信処理プログラム２１ｃ、工程データ取得プログラム２１ｄなどから構成される。メイン制御プログラム２１ａは、プログラム全体の制御を行うものであり、一般に、ＯＳ（Operating System）やカーネルと呼ばれるものである。ここでは、特に、プログラム間のインターフェースやイベントの検出などの役割を担う。データ送信処理プログラム２１ｂは、工程サーバ２が他のサーバにデータを送信するときの処理を行うものである。データ受信処理プログラム２１ｃは、工程サーバ２が他のサーバからデータを受信するときの処理を行うものである。工程データ取得プログラム２１ｄは、生産ラインから工程データを取得し、その工程データを所定の箇所に格納し、その工程データを統括サーバ３（図１参照）や他の工程サーバ２に送信するように要求を行うものである。なお、これらのプログラムは、本発明の実施の形態を説明するために記載したものであり、実際には、その他にも各種プログラムが搭載される。また、制御手段２１は、ＣＰＵ（Central Processing Unit）が所定のメモリに記憶された各プログラムを実行することによって実現され、その実現機能には、ＬＡＮボードなどのネットワーク接続機器によってネットワーク４を介したデータの送受信を行う機能を含むものとする。
【００１１】
送信データ記憶手段２２は、工程サーバ２から他のサーバに送信するデータを記憶するものであり、その記憶するデータとしては、送信スプール管理情報２４、送信先別データ群２５、ＦＴＰ送信データ２６などがある。送信スプール管理情報２４は、工程サーバ２から他のサーバに送信するデータのスプール管理を行うための情報であり、具体的には、送信先別データ群２５の各データについて、未送信や送信済などの状態を記憶したデータベースである。データの「未送信」の状態を示す情報は、工程データ取得プログラム２１ｄによって追加される。一方、データの「送信済」の状態を示す情報は、データ送信処理プログラム２１ｂによって更新される。送信先別データ群２５の各データとの対応付けは、データに固有の番号であるデータＩＤなどによるリンクによって行われる。送信先別データ群２５は、工程データ取得プログラム２１ｄによって取得された工程データを送信先のサーバごとに分類したものである。前記のように、送信先別データ群２５の各データの「未送信」、「送信済」などの状態は、送信スプール管理情報２４によって管理されている。ＦＴＰ送信データ２６は、工程サーバ２から他のサーバにＦＴＰによって正に送信しようとするデータであり、具体的にはＦＴＰ送信用フォルダに格納されるものである。ＦＴＰ送信データ２６は、少なくとも送信先サーバのＩＰアドレスおよびデータの種別を示すデータ種別ＩＤを含むものとする。
なお、ＦＴＰは、ＴＣＰ／ＩＰの上位層で動作するファイル転送プロトコルであり、ＡＳＣＩＩ（American Standard Code for Information Interchange）、ＥＢＣＤＩＣ（Extended Binary Coded Decimal Interchange Code）、バイナリ・ファイルなど多くのファイル・フォーマットに対応している。
【００１２】
受信データ記憶手段２３は、工程サーバ２が他のサーバから受信したデータを記憶するものであり、その記憶するデータとしては、ＦＴＰ受信データ２７、マスタデータ２８などがある。ＦＴＰ受信データ２７は、工程サーバ２が他のサーバからＦＴＰによって正に受信したデータであり、具体的にはＦＴＰ受信用フォルダに格納されるものである。マスタデータ２８は、工程サーバ２が他のサーバから受信したデータを体系的に整理、格納したものであり、具体的には、送信元サーバごとのデータを時系列に記憶したデータベースである。
なお、送信データ記憶手段２２および受信データ記憶手段２３は、ハードディスク装置などの不揮発性記憶装置によって実現される。
【００１３】
続いて、図３を参照して、本発明の実施の形態に係る統括サーバの構成と概要について説明する。図３に示すように、統括サーバ３は、制御手段３１、送信データ記憶手段３２および受信データ記憶手段３３から構成される。
制御手段３１は、統括サーバ２を制御する中枢機能を有するものであり、メイン制御プログラム３１ａ、データ送信処理プログラム３１ｂ、データ受信処理プログラム３１ｃなどから構成される。送信データ記憶手段３２は、統括サーバ３から他のサーバに送信するデータを記憶するものであり、その記憶するデータとしては、送信スプール管理情報３４、送信先別データ群３５、ＦＴＰ送信データ３６などがある。受信データ記憶手段３３は、統括サーバ３が他のサーバから受信したデータを記憶するものであり、その記憶するデータとしては、ＦＴＰ受信データ３７、マスタデータ３８などがある。
なお、統括サーバ３における各構成要素の機能および実現形態は、工程サーバ２と同様なので、その説明は割愛する。
【００１４】
≪サーバ間のデータ送受信方法≫
図４を参照して、本発明の実施の形態に係る工程管理システムにおけるサーバ間のデータ送受信方法について説明する（適宜図１ないし図３参照）。ここでは、工程サーバ２から統括サーバ３にデータを送信する場合を例にして説明するが、このデータ送受信方法は、それに限定されるものではなく、統括サーバ３から工程サーバ２へのデータ送受信、工程サーバ２間のデータ送受信など、いずれのサーバ間のデータ送受信にも適用される方法である。また、ここでは、特にデータの流れを中心に説明し、各サーバにおける処理の詳細（各プログラムの動作を含む）については別途説明するものとする。
まず、工程サーバ２は、データを統括サーバ３に送信するために、ＴＣＰ／ＩＰ（Transmission Control Protocol/Internet Protocol）送信用ソケットの開設を行う（Ｓ４０１）。送信側における「ソケット」とは、データ送信先のＩＰアドレスおよびポート番号（データを取り扱うアプリケーションプログラムの識別番号）からなる制御情報である。送信側における「ソケットの開設」とは、そのソケットを生成し、その生成したソケットなどを格納するためのメモリ領域を確保すると共に、そのソケットが示すデータ送信先の統括サーバ３に通信開始を通知することをいう。一方、統括サーバ３は、工程サーバ２からデータを受信するための準備として、ＴＣＰ／ＩＰ受信用ソケットの開設準備を行う（Ｓ４０２）。受信側における「ソケット」とは、通信を許可するデータ送信元のＩＰアドレスと、受信したデータを取り扱う自身のポート番号とからなる制御情報である。特定のサーバとだけ通信したいときには、ＩＰアドレスにそのサーバのＩＰアドレスを設定し、どのサーバとも通信するときには、ＩＰアドレスにゼロを設定する。受信側における「ソケットの開設準備」とは、そのソケットを生成し、その生成したソケットなどを格納するためのメモリ領域を確保すると共に、他のサーバからの接続（通信開始の通知に対応）を待ち受けることをいう。そして、統括サーバ３は、Ｓ４０１によって工程サーバ２から通信開始の通知を受信すると、ＩＰアドレスを照合することによって通信を許可するか否かを判断し、工程サーバ２に応答を返信する。ここで、統括サーバ３が、通信を許可する応答を返信すれば、工程サーバ２と接続状態になり、受信側における「ソケットの開設」が実施されたことになる（Ｓ４０３）。
【００１５】
工程サーバ２では、ソケットの開設（Ｓ４０１）が完了すると、送信要求があるか否かをチェックする（Ｓ４０４）。この送信要求は、例えば、生産ラインから工程データを受信したときなどに発生し、データを他のサーバに送信するためのイベントである。このとき、送信データ記憶手段２２の送信先別データ群２５に新たなデータが追加され、送信スプール管理情報２４にその追加されたデータに対応付けられた「未送信」の状態が追加される。送信要求がなければ（Ｓ４０４のＮｏ）、チェック（Ｓ４０４）を繰り返す。送信要求があれば（Ｓ４０４のＹｅｓ）、送信先別データ群２５に格納されている「未送信」のデータを、所定のファイルとしてＦＴＰ送信データ２６のＦＴＰ送信用フォルダにコピーする（Ｓ４０５）。そして、統括サーバ３に対して、そのデータのファイルをＦＴＰによって受信するように要求する受信要求メッセージを送信する（Ｓ４０６）。この受信要求メッセージは、工程サーバ２におけるファイルの所在が分かるように、ＩＰアドレス、ドライブ名、フォルダ名、ファイル名などを含むものとする。
【００１６】
統括サーバ３は、工程サーバ２から受信要求メッセージを受信する（Ｓ４０７）。次に、その受信要求メッセージによって示されたファイルを、工程サーバ２のＦＴＰ送信用フォルダから統括サーバ３自身のＦＴＰ受信用フォルダ（受信データ記憶手段３３のＦＴＰ受信データ３７）にＦＴＰによって受信する（Ｓ４０８）。そして、受信したファイルのデータをマスタデータ３８に登録、更新する（Ｓ４０９）。このとき、例えば、データが逐次発生し、時系列に追加記録していくようなものであれば、登録を行い、データが最新状態だけを保持するようなものであれば、更新を行うものとする。マスタデータ３８への登録、更新が終了すれば、受信したファイルは不要になるので、ＦＴＰ受信用フォルダのファイルを削除する（Ｓ４１０）。そして、工程サーバ２から受信した受信要求メッセージに対する応答として、ファイル受信が正常に終了したことを示す応答メッセージを送信し（Ｓ４１１）、次のメッセージの受信を待つ。
【００１７】
工程サーバ２は、統括サーバ３から応答メッセージを受信する（Ｓ４１２）。その応答メッセージからファイル受信が正常に終了したことを認識し、ＦＴＰ送信用フォルダ（送信データ記憶手段２２のＦＴＰ送信データ２６）のファイルを削除する（Ｓ４１３）。そして、送信スプール用管理情報２４の更新を行う（Ｓ４１４）。すなわち、統括サーバ３に送信したデータの「未送信」の状態を「送信済」の状態に書き換える。これによって、１つの「未送信」データの送信が完了し、再び送信要求のチェックを行う（Ｓ４０４）。
【００１８】
以上のように、他のサーバに送信すべきデータを一旦送信先サーバごとにスプールしておき、ソケットによる他のサーバとの接続状態が確立した時点でデータ送信（実際には、送信先サーバによるデータ受信）を行うことにより、サーバ間のデータ送受信を効率的に行うことができる。また、送信先サーバ自身がＦＴＰによってデータ受信を行うので、送信先サーバにおけるアクセス競合などによる無用な処理時間を削減することができる。
従来のように複数のサーバから送信先サーバの共有フォルダにデータを送信する方法においては、大量のデータ送信を行う場合、送信先サーバでアクセス競合が発生する可能性が大きい。これに対して、本発明のデータ送受信方法においては、まず、送信元サーバから送信先サーバに１パケットに収まる程度のサイズの受信要求メッセージを送信するので、ほとんどの場合、この送信は正常に行われる。次に、送信先サーバが送信元サーバから随時データを受信するが、この場合、受信要求メッセージに含まれるデータの所在情報に従ってＦＴＰ通信でデータ受信を行うので、大量のデータ受信を行ったとしても、アクセス競合が発生する可能性は小さい。
【００１９】
なお、サーバ間において双方向のデータ送受信が必要な場合は、それぞれのサーバにおいてデータ送信処理およびデータ受信処理を動作させる。このとき、それぞれのサーバにおいて、データ送信用およびデータ受信用の２つのソケットを開設することになる。また、ＦＴＰを実行するソフトウエアもそれぞれのサーバにインストールされる。このとき、それぞれのサーバについてＦＴＰのユーザ登録を行うことになる。また、匿名接続はしないものとする。
【００２０】
≪データ送信処理の詳細≫
次に、図５を参照して、本発明の実施の形態に係るサーバにおけるデータ送信処理について説明する（適宜図１ないし図３参照）。このデータ送信処理は、工程サーバ２および統括サーバ３の両方が実行する処理であるが、ここでは、工程サーバ２の処理を例にして説明する。また、図５のフローチャートが示すデータ送信処理は、基本的には、データ送信処理プログラム２１ｂが行う処理であるが、メイン制御プログラム２１ａや工程データ取得プログラム２１ｄが関係するところもあるので、その都度説明する。
データ送信処理プログラム２１ｂは、メイン制御プログラム２１ａからタスク起動（開始）されると、まず、イベント待ち処理を行う（Ｓ５００）。このイベント待ち処理では、プログラム制御を一旦メイン制御プログラム２１ａに戻し、データ送信処理プログラム２１ｂが処理すべきイベントが発生するまで待機する。そのようなイベントが発生したとき、データ送信処理プログラム２１ｂは、メイン制御プログラム２１ａから再びプログラム制御を渡される。これは、メイン制御プログラム２１ａから見ると、一旦データ送信処理プログラム２１ｂをタスク起動することによって、プログラムのメモリ領域などの動作環境を確保し、いつでも動作させることができる状態にしておき、実際に処理すべきイベントが発生したときにデータ送信処理プログラム２１ｂを再起動することになる。メイン制御プログラム２１ａは、データ送信処理プログラム２１ｂが処理すべきイベントがなければ、タスク起動された他のプログラムに別の必要な処理を行わせることができ、ＣＰＵ資源を有効に活用することが可能になる。
【００２１】
イベント待ち処理（Ｓ５００）において、データ送信処理プログラム２１ｂが再起動されたということは、Ｓ５０１ないしＳ５０５に示すいずれかのイベントが少なくとも１つ発生したことを意味する。まず、データ送信処理プログラム２１ｂは、送信要求があるか否かをチェックする（Ｓ５０１）。送信要求は、工程データ取得プログラム２１ｄが、生産ライン、例えば、制御用コンピュータを介して生産用ロボットから工程データを受信し、その受信した工程データを他のサーバに送信することを要求するものである。このとき、工程データ取得プログラム２１ｄは、その工程データを送信先別データ群２５に追加し、その工程データに対応付けられた「未送信」の状態を送信スプール管理情報２４に追加する。その後、送信要求が、工程データ取得プログラム２１ｄから送信され、メイン制御プログラム２１ａを経由して、データ送信処理プログラム２１ｂに受信される。送信要求があれば（Ｓ５０１のＹｅｓ）、応答待ち中フラグがオンであるか、および、タイマ起動中であるかをチェックする（Ｓ５０６）。そして、応答待ち中フラグがオンまたはタイマ起動中であれば（Ｓ５０６のＹｅｓ）、仕掛り中の動作があることを示すので、送信要求に対応する処理を行うことなくイベント待ち処理（Ｓ５００）に戻る。
【００２２】
応答待ち中フラグがオンでない、かつ、タイマ起動中でなければ、送信要求に対応する処理を実行するために、ソケットが開設中か否かをチェックする（Ｓ５０７）。データ送信先のＩＰアドレスを含むソケットがあれば（Ｓ５０７のＹｅｓ）、未送信データがあるか否かをチェックする（Ｓ５１０）。そのようなソケットがなければ（Ｓ５０７のＮｏ）、ソケットの開設を行う（Ｓ５０８）。統括サーバ３との接続状態が確立し、ソケットの開設が正常に行われたとき（Ｓ５０９のＹｅｓ）、未送信データがあるか否かをチェックする（Ｓ５１０）。送信スプール管理情報２４を参照して、「未送信」の状態のデータがあれば（Ｓ５１０のＹｅｓ）、送信データおよび受信要求メッセージを作成する（Ｓ５１１）。具体的には、未送信データを送信先別データ群２５からＦＴＰ送信用フォルダ（送信データ記憶手段２２のＦＴＰ送信データ２６）にファイル形式にしてコピーし、工程サーバ２におけるそのファイルの所在が分かるように、ＩＰアドレス、ドライブ名、フォルダ名、ファイル名、データ種別ＩＤなどを含む受信要求メッセージを作成する。そして、ＴＣＰ／ＩＰによるソケット通信によって、受信要求メッセージを統括サーバ３に送信する（Ｓ５１２）。その送信が正常に行われたとき（Ｓ５１３のＹｅｓ）、応答待ち中フラグをオンにし、受信待ちタイマを起動する（Ｓ５１７）。その後、イベント待ち処理（Ｓ５００）に戻る。なお、ソケットの開設が正常に行われなかったとき（Ｓ５０９のＮｏ）や受信要求メッセージの送信が正常に行われなかったとき（Ｓ５１３のＮｏ）には、ソケットの切断（Ｓ５１５）以降の処理を行う。
【００２３】
Ｓ５０１のチェックにおいて送信要求がなければ（Ｓ５０１のＮｏ）、１０秒タイマ切れまたは再送タイマ切れになっているか否かをチェックする（Ｓ５０２）。１０秒タイマ切れまたは再送タイマ切れになっていれば（Ｓ５０２のＹｅｓ）、ソケットが開設中か否かをチェックする（Ｓ５０７）。
１０秒タイマ切れにも再送タイマ切れにもなっていなければ（Ｓ５０２のＮｏ）、ソケット切断または受信待ちタイマ切れが発生しているか否かをチェックする（Ｓ５０３）。ソケット切断または受信待ちタイマ切れが発生していれば（Ｓ５０３のＹｅｓ）、応答待ち中フラグをオフにする（Ｓ５１４）。そして、ソケットを切断し（Ｓ５１５）、１０秒タイマを起動する（Ｓ５１６）。その後、イベント待ち処理（Ｓ５００）に戻る。
【００２４】
Ｓ５０３のチェックにおいてソケット切断も受信待ちタイマ切れも発生していなければ（Ｓ５０３のＮｏ）、ＴＣＰ／ＩＰによるソケット通信によって受信したメッセージがあるか否かをチェックする（Ｓ５０４）。受信メッセージがあれば（Ｓ５０４のＹｅｓ）、応答待ち中フラグおよび受信待ちタイマをオフにする（Ｓ５１８）。これは、メッセージの受信によって、応答待ちや受信待ちの状態が解除されたからである。次に、実際にメッセージの受信処理を行う（Ｓ５１９）。この受信が正常に行われたとき（Ｓ５２０のＹｅｓ）、その受信したメッセージが正常応答のメッセージであるか否かをチェックする（Ｓ５２１）。正常応答メッセージであれば（Ｓ５２１のＹｅｓ）、データ送信先である統括サーバ３がデータの受信を正常に行ったことを認識して、ＦＴＰ送信データ２６の削除および送信スプール管理情報２４の更新を行う（Ｓ５２２）。具体的には、ＦＴＰ送信用フォルダ（送信データ記憶手段２２のＦＴＰ送信データ２６）からファイルを削除し、送信スプール管理情報２４の「未送信」の状態を「送信済」の状態に更新する。更に、停止要求中フラグがオンになっているか否かをチェックする（Ｓ５２３）。オンであれば（Ｓ５２３のＹｅｓ）、停止要求が来ていることを認識して、Ｓ５２９のチェックを行う。オフであれば（Ｓ５２３のＮｏ）、次の未送信データの送信を行うために、Ｓ５１０のチェックを行う。なお、停止要求については後記する。
【００２５】
Ｓ５２０のチェックにおいてメッセージの受信が正常でなければ（Ｓ５２０のＮｏ）、Ｓ５１５以降の処理を行う。Ｓ５２１のチェックにおいて正常応答メッセージでなければ（Ｓ５２１のＮｏ）、再送要求があるか否かをチェックする（Ｓ５２４）。再送要求のイベントには、例えば、ユーザが工程サーバ２のメンテナンス画面からその送信が異常終了したデータの再送を指示することなどがある。再送要求がなければ（Ｓ５２４のＮｏ）、異常時の後処理としてＳ５１５以降の処理を行う。再送要求があれば（Ｓ５２４のＹｅｓ）、停止要求中フラグがオンになっているか否かをチェックする（Ｓ５２５）。オンであれば（Ｓ５２５のＹｅｓ）、Ｓ５２９のチェックを行う。オフであれば（Ｓ５２５のＮｏ）、応答待ち中フラグをオンにし、再送タイマを起動する（Ｓ５２６）。その後、イベント待ち処理（Ｓ５００）に戻る。
【００２６】
Ｓ５０４のチェックにおいて受信メッセージがなければ（Ｓ５０４のＮｏ）、停止要求があるか否かをチェックする（Ｓ５０５）。停止要求のイベントには、例えば、ユーザが工程サーバ２のメンテナンス画面から電源切断の指示を行ったり、工程サーバ２に接続されるＵＰＳ（Uninterruptible Power Supply、無停電電源装置）が電源断を検知して工程サーバ２のシャットダウンを要求したりすることなどがある。停止要求がなければ（Ｓ５０５のＮｏ）、イベント待ち処理（Ｓ５００）に戻る。停止要求があれば（Ｓ５０５のＹｅｓ）、応答待ち中フラグがオンであるか否かをチェックする（Ｓ５２７）。オンであれば（Ｓ５２７のＹｅｓ）、停止要求中フラグをオンにして（Ｓ５２８）、イベント待ち処理（Ｓ５００）に戻る。オフであれば（Ｓ５２７のＮｏ）、ソケットが開設中であるか否かをチェックする（Ｓ５２９）。開設中であれば（Ｓ５２９のＹｅｓ）、ソケットを切断して（Ｓ５３０）、データ送信処理を終了する。開設中でなければ（Ｓ５２９のＮｏ）、そのままデータ送信処理を終了する。このとき、データ送信処理プログラム２１ｂはデータ送信処理を終了すると同時にタスク消滅し、プログラム制御はメイン制御プログラム２１ａに戻る。
【００２７】
≪データ受信処理の詳細≫
次に、図６を参照して、本発明の実施の形態に係るサーバにおけるデータ受信処理について説明する（適宜図１ないし図３参照）。このデータ受信処理は、工程サーバ２および統括サーバ３の両方が実行する処理であるが、ここでは、統括サーバ３の処理を例にして説明する。また、図６のフローチャートが示すデータ受信処理は、基本的には、データ受信処理プログラム３１ｃが行う処理であるが、メイン制御プログラム３１ａが関係するところもあるので、その都度説明する。
データ受信処理プログラム３１ｃは、メイン制御プログラム３１ａからタスク起動（開始）されると、まず、イベント待ち処理を行う（Ｓ６００）。このイベント待ち処理の詳細は、既に説明したデータ送信処理プログラム２１ｂの場合と同様である。すなわち、イベント待ち処理（Ｓ６００）において、データ受信処理プログラム３１ｃは、プログラム制御を一旦メイン制御プログラム３１ａに戻す。そして、メイン制御プログラム３１ａは、実際に処理すべきイベントが発生したときにデータ受信処理プログラム３１ｃを再起動する。
【００２８】
データ受信処理プログラム３１ｃが、メイン制御プログラム３１ａから再起動されたということは、Ｓ６０１ないしＳ６０５に示すいずれかのイベントが少なくとも１つ発生したことを意味する。まず、データ受信処理プログラム３１ｃは、自身が起動直後であるか、または、タイマ切れが発生しているか否かをチェックする（Ｓ６０１）。このチェックは、データ受信処理プログラム３１ｃ自身が初期状態またはリセット状態であるか否かを確認するものである。起動直後またはタイマ切れであれば（Ｓ６０１のＹｅｓ）、ソケットの開設準備を行う（Ｓ６０６）。具体的には、ソケットの生成やメモリ領域の確保などを行い、その開設準備が正常であるか否かをチェックする（Ｓ６０７）。正常であれば（Ｓ６０７のＹｅｓ）、イベント待ち処理（Ｓ６００）に戻る。正常でなければ（Ｓ６０７のＮｏ）、Ｓ６１０以降の処理を行う。
【００２９】
Ｓ６０１のチェックにおいて起動直後でもタイマ切れでもなければ（Ｓ６０１のＮｏ）、ソケットの開設要求があるか否かをチェックする（Ｓ６０２）。このチェックは、データを送信しようとしている他のサーバから通信開始の通知があったか否かを確認するものである。ソケットの開設要求があれば（Ｓ６０２のＹｅｓ）、ソケットの開設を行う（Ｓ６０８）。具体的には、通信開始の通知を受信し、その通信を許可するか否かを判断し、相手先のサーバに応答を返信する。そして、その開設が正常であるか否かをチェックする（Ｓ６０９）。正常であれば（Ｓ６０９のＹｅｓ）、イベント待ち処理（Ｓ６００）に戻る。正常でなければ（Ｓ６０９のＮｏ）、Ｓ６１０以降の処理を行う。
Ｓ６０２のチェックにおいてソケットの開設要求がなければ（Ｓ６０２のＮｏ）、ソケット切断が発生しているか否かをチェックする（Ｓ６０３）。ソケット切断が発生していれば（Ｓ６０３のＹｅｓ）、ソケットを切断し（Ｓ６１０）、タイマを起動する（Ｓ６１１）。その後、イベント待ち処理（Ｓ６００）に戻る。
【００３０】
Ｓ６０３のチェックにおいてソケット切断が発生していなければ（Ｓ６０３のＮｏ）、ＴＣＰ／ＩＰによるソケット通信によって他のサーバから受信したメッセージがあるか否かをチェックする（Ｓ６０４）。受信メッセージがあれば（Ｓ６０４のＹｅｓ）、実際にメッセージの受信処理を行い（Ｓ６１２）、そのメッセージの受信が正常であるか否かをチェックする（Ｓ６１３）。正常でなければ（Ｓ６１３のＮｏ）、Ｓ６１０以降の処理を行う。正常であれば（Ｓ６１３のＹｅｓ）、その受信したメッセージに含まれるデータ種別ＩＤによって、工程データ（生産実績データなど）を受信するように促すものであるか否かをチェックする（Ｓ６１４）。受信したメッセージが工程データの受信を促すものであれば（Ｓ６１４のＹｅｓ）、ＦＴＰによるデータ（ＦＴＰ受信データ３７）の受信およびマスタデータ３８の更新を行う（Ｓ６１５）。このとき、マスタデータ３８の更新が完了した時点で、ＦＴＰ受信用フォルダ内の受信ファイルを削除するようにしてもよい。そして、正常応答メッセージを作成し（Ｓ６１６）、その作成した応答メッセージを相手先のサーバに送信する（Ｓ６１７）。Ｓ６１４のチェックにおいて、受信したメッセージが工程データの受信を促すものでなければ（Ｓ６１４のＮｏ）、異常応答メッセージを作成し（Ｓ６１９）、その作成した応答メッセージを相手先のサーバに送信する（Ｓ６１７）。応答メッセージの送信が正常であれば（Ｓ６１８のＹｅｓ）、イベント待ち処理（Ｓ６００）に戻る。応答メッセージの送信が正常でなければ（Ｓ６１８のＮｏ）、Ｓ６１０以降の処理を行う。
【００３１】
Ｓ６０４のチェックにおいて受信メッセージがなければ（Ｓ６０４のＮｏ）、停止要求があるか否かをチェックする（Ｓ６０５）。停止要求のイベントには、例えば、ユーザが統括サーバ３のメンテナンス画面から電源切断の指示を行ったり、統括サーバ３に接続されるＵＰＳが電源断を検知して統括サーバ３のシャットダウンを要求したりすることなどがある。停止要求がなければ（Ｓ６０５のＮｏ）、イベント待ち処理（Ｓ６００）に戻る。停止要求があれば（Ｓ６０５のＹｅｓ）、ソケットが開設中であるか否かをチェックする（Ｓ６２０）。開設中であれば（Ｓ６２０のＹｅｓ）、ソケットを切断して（Ｓ６２１）、データ受信処理を終了する。開設中でなければ（Ｓ６２０のＮｏ）、そのままデータ受信処理を終了する。このとき、データ受信処理プログラム３１ｃはデータ受信処理を終了すると同時にタスク消滅し、プログラム制御はメイン制御プログラム３１ａに戻る。
【００３２】
なお、ここで説明した統括サーバ３のようにデータを受信するサーバにおいては、複数のポート番号にデータ受信処理プログラム３１ｃまたはＦＴＰ受信用プログラムを割り当て、それぞれのポート番号を持つ受信用ソケットを複数開設してもよい。これによれば、複数のポート番号それぞれに対応してデータ受信処理プログラム３１ｃまたはＦＴＰ受信用プログラムをタスク起動し、複数のデータ受信用プログラムが動作可能な状態にしておくことによって、複数のサーバからのデータ受信に対応することが可能になる。
【００３３】
以上本発明の実施の形態について説明したが、図２の制御手段２１および図３の制御手段３１のそれぞれで実行されるプログラムをコンピュータによる読み取り可能な記録媒体に記録し、この記録媒体に記録されたプログラムをコンピュータシステムに読み込ませ、実行することにより、本発明の実施の形態に係る工程サーバ２および統括サーバ３が実現されるものとする。ここでいうコンピュータシステムとは、ＯＳ（Operating System）などのソフトウエアや周辺機器などのハードウエアを含むものである。
【００３４】
以上本発明について好適な実施の形態について一例を示したが、本発明は前記実施の形態に限定されず、本発明の趣旨を逸脱しない範囲で適宜変更が可能である。
【図面の簡単な説明】
【００３５】
【図１】本発明の実施の形態に係る工程管理システムの構成を示す図である。
【図２】本発明の実施の形態に係る工程サーバの構成を示す図である。
【図３】本発明の実施の形態に係る統括サーバの構成を示す図である。
【図４】本発明の実施の形態に係るサーバ間のデータ送受信方法を示すフローチャートである。
【図５】本発明の実施の形態に係るサーバにおけるデータ送信処理を示すフローチャートである。
【図６】本発明の実施の形態に係るサーバにおけるデータ受信処理を示すフローチャートである。
【符号の説明】
【００３６】
１      工程管理システム
２      工程サーバ
３      統括サーバ
４      ネットワーク
２１、３１  制御手段
２２、３２  送信データ記憶手段
２３、３３  受信データ記憶手段
【図１】
2005267011.tif 000003
【図２】
2005267011.tif 000004
【図３】
2005267011.tif 000005
【図４】
2005267011.tif 000006
【図５】
2005267011.tif 000007
【図６】
2005267011.tif 000008