(57)【要約】【課題】各タスク間でデータの通信を行い、データ処理依頼をすることで依頼元１０１と依頼先１０５で処理を行うとき、そのデータに対応した処理のタイムアウトが発生した場合、依頼元１０１でのみ依頼開始からの相対時間でタイムアウト時間１１９を認識すると、依頼先ではタイムアウト時間１３９の認識を行えないため、タイムアウト時間の認識に食い違いが発生する。【解決手段】処理のタイムアウト時間１１９の判断に絶対時間を利用することで、依頼元１０１と依頼先１０５で、そのタイムアウト時刻１１９および１３９の認識に食い違いをなくし、また、依頼先１０５でデータを受信した時点で、処理のタイムアウト時刻１３９の絶対時間と今から実施する処理の見積もり時間１２５などを比較し、タイムアウトとなることを判断できた場合は、無駄となる処理を予め実施しないことが可能となる。【選択図】図１
2007058477.tif 000002
【特許請求の範囲】
【請求項１】
タスク（プロセスまたはスレッド）が同一コンピュータ内で、複数で並列に実行出来るマルチタスクＯＳにおいて、タスク間で依頼元からの処理依頼と依頼先からの依頼結果のデータ通信を行い、依頼先が通信された処理依頼を即時に受け取るとは限らないとき、依頼先がそのデータに対応した処理依頼の絶対時間指定の期限（タイムアウト）を検出することで処理の可能／不可能を判断することを特徴とするデータ通信システム。
【請求項２】
タスク（プロセスまたはスレッド）がネットワーク（ＬＡＮやＷＡＮ）などで繋がった別のコンピュータ上で実行できる環境において、タスク間で依頼元からの処理依頼と依頼先からの依頼結果のデータ通信を行い、依頼先が通信された処理依頼を即時に受け取るとは限らないとき、依頼先がそのデータに対応した処理依頼の絶対時間指定の期限（タイムアウト）を検出することで処理の可能／不可能を判断することを特徴とするデータ通信システム。
【請求項３】
依頼元は通信するデータにその処理のタイムアウト時間を絶対時間で付加して依頼先に送信した後、前記タイムアウト時間まで依頼結果の応答を待ち、依頼先は前記データと前記絶対時間で指定されたタイムアウト時間を受信し、前記タイムアウト時間までに処理が可能であるかを判断し、前記タイムアウト時間までに処理することができないと判断した場合には、その旨を依頼元に応答することを特徴とするデータ通信方法。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、タスク（プロセスまたはスレッド）間によるデータ通信で、依頼元から依頼された処理依頼のデータを依頼先が即時に受信するとは限らないシステムで、処理の期限（タイムアウト）の検出に関するものである。
【背景技術】
【０００２】
タスク間でデータ通信による処理を依頼する場合、往路として、依頼元が処理依頼データを送信した後に依頼先で処理依頼データを受信し、依頼先はその内容に応じて処理を行い、復路として、依頼結果を送信した後に依頼元が依頼結果を受信することで、処理が成り立つ。
【０００３】
このとき、依頼元は、その依頼の結果が応答されるまでの時間を処理依頼側で行う実際の処理そのものの時間に比べて十分と判断できる相対時間で指定し、その時間の間は応答を待つが、時間が過ぎると、タイムアウトとして処理依頼が失敗したものと判断して次の処理に移り、依頼元の処理自体が永久に待ち（ブロック）状態にならないようにしている。
【０００４】
なお、従来技術は、通信を行うためのＯＳのインターフェース（ＡＰＩやシステムコールなど）の仕様により、時間管理には相対時間を一般的に利用している。
【０００５】
【非特許文献１】『μITRON4.0仕様』  (社)トロン協会 ITRON仕様検討グループ  坂村健監修／高田宏章編(http://www.ertl.jp/ITRON/SPEC/mitron4-j.html (英語版あり)) ２．１．８章『タイムアウトとノンブロッキング』および、４章『ITRON4.0仕様の機能』でタイムアウト指定（ＴＭＯ型）利用の各ＡＰＩ
【非特許文献２】『ITRON TCP/IP API仕様』  Embedded TCP/IP技術委員会  (社)トロン協会 ITRON専門委員会 高田宏(http://www.ertl.jp/ITRON/SPEC/tcpip-j.html) ２章『ＴＣＰのＡＰＩ』、３章『ＵＤＰのＡＰＩ』でタイムアウト指定（ＴＭＯ型）利用の各ＡＰＩ
【発明の開示】
【発明が解決しようとする課題】
【０００６】
依頼先は、複数の依頼元からの接続に対応する場合が多く、依頼元からの複数の処理依頼データは、受信口にある受信バッファ内に格納され、即時に依頼先の処理として実際に受信されるとは限らず、依頼先の処理状況に応じて遅延して受信が開始される。
【０００７】
このため、依頼元で設定したタイムアウト時刻を過ぎてから依頼先で実際に受信処理が発生する場合や、受信処理はタイムアウト時刻前に行われるが処理そのものがタイムアウト時間を越えて依頼結果をタイムアウト時刻より後に応答してしまう場合がある。
【０００８】
また、依頼元は、自分の処理として、相対時間でタイムアウト時間を検出するため、依頼先に相対時間でタイムアウト時間を渡したとしても、即時受信処理が行われるとは限らない、または通信経路による遅延などのために、依頼先に相対時間が渡っても受信してからの相対時間としてしか判断することが出来ないため、依頼先は依頼元でのタイムアウト時間を判断することが出来ない。
【０００９】
このため、依頼元では、タイムアウトのため『失敗』と判断したにもかかわらず、遅延して応答が受信されることが発生し、処理の食い違いとなり、また、その遅延した応答に対応した処理を元に戻す（リカバリ）処理などで整合性を取る必要が発生してしまう欠点がある。
【００１０】
この元に戻す（リカバリ）処理も、依頼先に対して通信による処理依頼で行うこととなり、システム全体として処理が破綻する可能性が発生する。
【課題を解決するための手段】
【００１１】
課題の改善策として、依頼元から通信するデータと合わせて、その処理のタイムアウト時間を絶対時間で付加して依頼先に送信する。依頼元は、その絶対時間までは依頼結果の応答を待ち、応答が無ければ処理依頼が失敗したものとして次の処理に進む。依頼先は、データと絶対時間で指定されたタイムアウト時間を受信し、その絶対時間までに処理が可能であるか、また、依頼結果の応答の送信が可能であるかを判断し、タイムアウト時間までに処理することが出来ないと判断できれば、その処理を破棄する。
【発明の効果】
【００１２】
タイムアウトまでに処理出来ない(失敗する)ことが判った処理を行う必要がなく、結果として、失敗した処理を元に戻す（リカバリ）処理などの２次的な無駄な処理も発生しないようにできる。
【００１３】
また、タイムアウトまでに処理出来ないことを判断することで、その情報を依頼先が応答することにより、依頼元は実際のタイムアウト時間よりも早く依頼が失敗したことが判り、その時間の分早く他の処理に移行することができる。
【発明を実施するための最良の形態】
【００１４】
依頼元と依頼先、双方の処理のタイムアウト検出による無駄な処理の発生の防止を、絶対時間を用いて判断することで実現した。
【実施例１】
【００１５】
図１は、本発明の１実施例であり、処理の依頼元１０１から依頼先１０５へ往路として処理の依頼、復路として依頼結果の応答を行うシーケンス図である。
【００１６】
図２は複数の依頼元その１〜ｎ（２０１〜２０２）と依頼先２０３の構成例で、通信となる『処理依頼のデータ』と『その結果の応答データ』を見たとき、依頼元が複数個あったとしても、通信は個々に見ることができるため、依頼元を１つ、依頼先を１つとして、以下、図３、図４、図５、図６のフローチャート、図７のシーケンス図、図８、図９のテーブル、図１０の機器／モジュール構成、および図１１、図１２、図１３、図１４のフォーマットを用いて説明する。
【００１７】
本発明の絶対時間を利用する方法でも従来の相対時間を利用する方法でも、依頼元１０１のタイムアウト時刻１１９は、処理時間１２５の終了時刻に対して十分大きな値を設定する。これは、処理時間１２５の長さがある程度予測できるからであり、処理時間１２５が全く予測できない場合は、タイムアウト時刻１１９を設定することは不可能であり、この場合は本発明が対象としない事象となる。
【００１８】
処理毎に予測できた処理時間１２５と絶対時間のタイムアウト時刻１１９を算出するのに用いるタイムアウトまでの相対時間を、図８のようにテーブルに作成して置く。なお、本発明は処理時間１２５の長さの予測方法に関するものではないため、予測方法は限定しない。
【００１９】
従来の相対時間でタイムアウトを検出する場合は、依頼元１０１が依頼先１０５に対して、時刻１１１に１３１の処理依頼を送信した後、時刻１１２に１３２の依頼結果の受信待ち処理を開始する。このとき、タイムアウト時刻１１９は、時刻１１１の処理依頼時点からの相対時間を予測しているにもかかわらず、時刻１１２からタイムアウト時刻１１９までの時間を相対時間で設定してしまう。
【００２０】
このため、時刻１１２と時刻１１１の差である時間１２１の分、タイムアウト時刻１１９は後方にずれる。また、依頼先１０５では、時刻１１５に１３５で処理依頼を受信するため、相対時間を渡されたとしても、時刻１１５からの相対時間でしか認識することができないことから、依頼結果の送信の完了を含めた処理時間の期限となる依頼先１０５でのタイムアウト時刻１３９は、依頼元１０１で設定したタイムアウト時刻１１９と一致することはまずありえない。
【００２１】
結果として、依頼先１０５はタイムアウト時刻１１９を意識することなく処理を行い、処理依頼を受信する１３５が遅くなればなるほどタイムアウト時刻１１９までに依頼結果を応答することができなくなる可能性が高くなる。
【００２２】
このため、依頼元１０１がタイムアウト時刻１１９に依頼が失敗したと判断した後に、その依頼結果を遅延して受信することが発生し、依頼元１０１と依頼先１０５で依頼に対する依頼結果の認識の違いが発生してしまい、その違いを元に戻す処理（リカバリ）などの無駄な処理を誘発してしまう。
【００２３】
本発明では、依頼元１０１と依頼先１０５で絶対時間によるタイムアウト時刻１１９と１３９を同時刻として認識することにより、上記の問題を解決する。
【００２４】
本発明では、まず事前に、依頼元１０１と依頼先１０５でコンピュータシステムから取得する絶対時間を合わせる必要がある。
【００２５】
同一コンピュータシステム上での通信では同一の絶対時間の取得が可能であり、また、ネットワーク(LAN、WANなど)を介したコンピュータシステム間の通信では、各コンピュータシステムの時刻のずれを無くすために、一般に利用されているＮＴＰ（Ｎｅｔｗｏｒｋ  Ｔｉｍｅ  Ｐｒｏｔｏｃｏｌ）などをもちいて、Ｅｐｏｃｈ（１９７０／１／１  ００：００：００  ＵＴＣ）からの経過時間を一致させることにより絶対時間を合わせる。
【００２６】
なお、本発明は、各コンピュータで絶対時間を合わせることを目的とした発明ではないため、その方法は限定せず、各コンピュータの絶対時間の誤差は、処理時間１２５に対して無視できるものとして考える。
【００２７】
以下、図１０の機器／モジュール構成の装置を例に説明する。
【００２８】
サブ機器１００４には、コンソールモジュール１００１とステータス制御モジュール１００２とメイン機器制御モジュール１００３があり、各モジュールは同一コンピュータシステム上で動作する。
【００２９】
メイン機器１００５とサブ機器１００４は、それぞれ別電源で動作し、メイン機器１００５とサブ機器１００４は、ハードウェア信号線のインターフェースで繋がれており、サブ機器１００４上のメイン機器制御モジュール１００３からの指示によって電源のＯＮ／ＯＦＦやステータス情報取得などを制御できる。
【００３０】
各モジュール間の通信経路は、コンソールモジュール１００１とメイン機器制御モジュール１００３の間、ステータス制御モジュール１００２とメイン機器制御モジュール１００３の間にあり、各モジュール間毎に、依頼元１０１と依頼先１０５との対応ができ、依頼元１０１は図３と図５、依頼先１０５は図４と図６のフローチャートに従い、それぞれ並行して動作する。
【００３１】
まず、各モジュール間の通信経路毎に、通信経路の時間について判断する。
【００３２】
依頼元１０１は図３のシステムの初期化処理３０１として図５のフローチャートに従い、通信経路の時間が依頼する処理の時間１２５に対して無視できるかどうかを通信経路の時間の無視の可否判定５０１で判断する。本発明ではこの判断の基準に対するものではないので、その方法は限定しないが、後述の図６の通信経路の時間の無視の可否判定６０１での判断基準とは同一のものを利用して、それぞれで同じ結果が得られるものとする。
【００３３】
通信経路の時間の無視の可否判定５０１で同一コンピュータ上での通信などの通信経路の時間が無視できる場合（Y）は通信経路の時間を０として設定５０２し、ネットワークを経由する遠方同士での通信など通信経路の時間が無視できない場合（N）は、依頼元１０１と依頼先１０５で通信経路測定用のデータによる通信を行い、通信時間を測定し、依頼元１０１と依頼先１０５でその測定データを往路の通信時間９０１として図９の通信時間テーブルを作成し、それぞれで共有する。
【００３４】
依頼先１０５も同様に、図４のシステムの初期化処理４０１として図６のフローチャートに従い、通信経路の時間が依頼する処理の時間１２５に対して無視できるかどうかを通信経路の時間の無視の可否判定６０１で判断する。
【００３５】
通信経路の時間の無視の可否判定６０１での判断基準は、通信経路の時間の無視の可否判定５０１での判断基準と同一のものを利用して、それぞれで同じ結果が得られるものとする。
【００３６】
通信経路の時間の無視の可否判定６０１で無視できる場合（Y）は通信経路の時間を０として設定６０２し、無視できない場合（N）は、依頼元１０１と依頼先１０５と通信経路測定用のデータによる通信を行い、通信時間を測定し、依頼元１０１と依頼先１０５でその測定データを復路の通信時間９０２として図９の通信時間テーブルを作成し、それぞれで共有する。
【００３７】
この通信時間の測定の流れを表したものが、図７のシーケンス図であり、これと、図５の５０３〜５０６、図６の６０３〜６０６と合わせて以下に説明する。ただし、本発明は通信時間の見積もり方に関するものではないため、見積もり方法に関してはこの方式による見積もりに限定しない、また、図は簡易化のため、依頼元１０１と依頼先１０５の通信のネゴシエーション処理などは省略している。
【００３８】
依頼元１０１と依頼先１０５は、それぞれ並行して動作しているので、依頼元１０１の計測データの送信処理５０３と依頼先１０５の計測データの受信処理６０３の実行のタイミングはさまざまとなるが、図７では、依頼先１０５の計測データの受信６０３が先に実行された場合で記述してある。
依頼先１０５は、依頼先の受信口１０４に対して、受信処理６０３として受信処理開始７３１を行う。
依頼元１０１は、送信処理５０３として、時刻７１１の絶対時間を往路の通信時間測定用のデータ１４０１として７３２で送信処理する。
【００３９】
続いて、依頼元１０１は、復路の計測用データの受信５０４として、依頼元の受信口１０２に対して、受信処理７３３を開始する。
【００４０】
往路の通信時間測定用のデータ１４０１（＝７１１）は、通信経路１０３を経由して７３４の送信処理により、依頼先の受信口１０４に格納される。このときの時刻７１２と時刻７１１（＝１４０１）の差を往路の通信時間７２１として求める。なお、送信時の送信口の処理時間は、図の簡略化のために通信経路に含めている。
【００４１】
その後、往路の通信時間測定用のデータ１４０１（＝７１１）は、時刻７１３に受信処理７３５で、依頼先１０５に受信され、このとき、時刻７１３と時刻７１２の差である受信処理の時間７２２が発生するが、依頼元１０１の計測データの送信処理５０３と依頼先１０５の計測データの受信処理６０３の実行のタイミングで、依頼元１０１の計測データの送信処理５０３が先に実行され、計測データが依頼先の受信口１０４に時刻７１２に格納され、依頼先１０５が受信処理７３１をその時刻７１２以降に開始した場合、その分、実際に受信が完了する時刻７１３が遅くなり、その差である時間７２２が大きくなる。
その遅れた受信処理開始の分、通信経路の時間に対して余分に計上してしまうため、時間７２２は通信経路の時間には含めない。
【００４２】
続いて、依頼先１０５は、送信処理６０４として、時刻７１４の絶対時間を復路の通信時間測定用のデータ１４０１として７３６で送信処理する。
復路の通信時間測定用のデータ１４０１（＝７１４）は、通信経路１０３を経由して７３７の送信処理により、依頼元の受信口１０２に格納される。このときの時刻７１５と時刻７１４（＝１４０１）の差を復路の通信時間７２３として求める。
【００４３】
その後、復路の通信時間測定用のデータ１４０１（＝７１４）は、時刻７１６に受信処理７３８で、依頼元１０１に受信され、このとき、時刻７１６と時刻７１５の差である受信処理の時間７２４が発生するが、往路の時間７２２と同様に、受信処理７３３を時刻７１５以降に開始した場合、その分、実際に受信が完了する時刻７１６が遅くなり、その差である時間７２４が大きくなる。
その遅れた受信処理開始の分、通信経路の時間に対して余分に計上してしまうため、時刻７２４は通信経路の時間には含めない。
【００４４】
以上、往路と復路の通信時間の測定を図５の５０５および図６の６０５の繰り返し要否の判定により、依頼元１０１と依頼先１０５で１回以上の同じ回数を実施して、その平均値などを往路の通信時間９０１と復路の通信時間９０２の見積もりとし、図９の通信時間テーブルを作成する。
なお、通信するデータ量によって通信経路を通過する時間が変化する場合などは、データ量別に計測してから通信時間の見積もりを行ってもよい。ただし、本発明は、通信時間の見積もりに関するものではないため、この方法に限定しない。
【００４５】
作成した図９の通信経路の通信時間テーブルは、依頼元１０１と依頼先１０５で測定結果の共有処理５０６および６０６で情報を共有する。ただし、本発明は、情報の共有方式に関するものではないため、共有方式は限定しない。
【００４６】
次に、コンソールモジュール１００１が依頼元で電源制御処理によって処理時間８０１の処理をその依頼した時刻とタイムアウトまでの相対時間８０２から求まったタイムアウト時刻で依頼し、依頼先のメイン機器制御モジュール１００３がその処理を実行している状態のときに、依頼元１０１としてステータス制御モジュール１００２が、ステータス制御処理を依頼先１０５に依頼した場合を例に、依頼元１０１と依頼先１０５は、それぞれ処理依頼の送信３０２と処理依頼の受信４０２を行い、図１のシーケンスに従って動作する場合で説明する。
【００４７】
依頼元１０１は処理依頼の送信処理３０２として、時刻１１１とステータス制御処理のタイムアウトまでの相対時間８０４を加算して求めた処理のタイムアウト時刻１１９の絶対時間をステータス制御処理依頼のデータと共に図１１の通信フォーマットのように、それぞれ、タイムアウト時刻１１０１と通信データ１１０２に格納し、依頼先１０５に送信処理１３１を行う。
【００４８】
その後、依頼元１０１は、ステータス制御処理依頼とは独立した処理３０３を行った後、依頼結果の受信処理３０４として、時刻１１２に依頼結果の受信待ち１３２を行う。
【００４９】
このとき、ステータス制御処理依頼とは独立した処理３０３が短い時間の処理で、受信待ち１３２を行った時刻１１２が、タイムアウト時刻１１９より前方となる場合は、タイムアウト時刻１１９まで依頼結果の受信待ちを行い、依頼とは独立した処理３０３が長い時間の処理で、タイムアウト時刻１１９より後方となる場合は、依頼元の受信口１０２に依頼結果が蓄積されていれば、即時に受信し、蓄積されていなければ絶対時間でタイムアウト時刻１１９を設定しているので、即時にタイムアウトと判断できることから、依頼とは独立した処理３０３が依頼結果の受信３０４の前に入った場合でも、依頼結果の受信やタイムアウトの判定に影響を与えることはない。
【００５０】
次にステータス制御処理依頼（＝１１０２）とタイムアウト時刻１１９の絶対時間（＝１１０１）を合わせた通信フォーマットは、通信経路１０３を経由して、時刻１１３に１３３の送信処理により、依頼先の受信口１０４に格納される。
【００５１】
このときの往路の通信時間１２２は、図９の往路の通信時間９０１に対応するが、実際に通信するデータと合わせて、図１２の通信フォーマットのように、送信処理開始時刻１１１（＝１２０１）も通知することで、受信口１０４で受信した時刻１１３と時刻１１１の差の通信時間１２２を新たに求めて、図９の往路の通信時間９０１を補正することも可能である。
【００５２】
なお、通信時間を補正した場合は、依頼結果を応答するときに合わせて、依頼元１０１に通知するなどして図９の通信経路の通信時間テーブルを共有することで、タイムアウト時刻１１９の見積もりに反映させることも可能となる。ただし、本発明では、これらの通信時間の補正や見積もりの方法は限定しない。
【００５３】
次に依頼先１０５は時刻１１３の時点ではコンソールモジュール１００１からの電源制御処理依頼に対する処理を行っており、依頼元１０１からのステータス制御処理依頼を即時に受信することができない場合である。
【００５４】
依頼先１０５はステータス制御処理依頼の受信処理４０２として、実際には時刻１１３から時間１２３分遅れた時刻１１４に処理依頼の受信処理１３４を開始した後、依頼先の受信口１０４に格納されているステータス制御処理依頼を時刻１１５に１３５として受信する。
【００５５】
このとき、時刻１１５と時刻１１４の差の時間１２４も受信するデータ量によっては無視できないほどの大きさとなる場合があるが、依頼先１０５の処理は、時刻１１５から再開し、また、処理の期限であるタイムアウト時刻１３９は絶対時間で認識できるので、時間１２４の影響は考える必要はない。
【００５６】
次に依頼先１０５は、タイムアウト時刻までに処理と応答可能かの判断４０３として、以下を行う。
【００５７】
ステータス制御処理依頼のデータ（＝１１０２）と共に通知された時刻１１１とステータス制御処理のタイムアウトまでの相対時間８０４を加算して求めたタイムアウト時刻１１９（＝１３９＝１１０１）とステータス制御処理依頼を受信した時刻１１５の差から残り時間（ａ）を算出する。
ステータス制御処理の処理時間１２５（＝８０３）と予め見積もった復路の通信時間１２６（＝９０２）との和の時間（ｂ）を算出する。
【００５８】
この（ａ），（ｂ）を比較し、（ａ）＝（ｂ）の場合は、処理時間１２５（＝８０３）や通信時間１２６（＝９０２）の予測精度に応じて、（ａ）＞（ｂ）の場合または（ａ）＜（ｂ）の場合のどちらかに適用する。
【００５９】
（ａ）＞（ｂ）の場合（Ｙ）は、処理４０４として依頼されたステータス制御処理を行いその依頼結果を作成する。
【００６０】
（ａ）＜（ｂ）の場合（Ｎ）は、処理４０５としてタイムアウト時刻１１９（＝１３９）までにステータス制御処理を行うが不可能であることを依頼結果として作成する。
【００６１】
（ａ）＞（ｂ）および（ａ）＜（ｂ）のどちらの場合でも、処理４０６として再度タイムアウト時刻１１９（＝１３９）と依頼結果を送信する時刻１１６の差である残り時間（ｃ）と、予め見積もった復路の通信時間１２６（＝９０２）（ｄ）とを比較する。
【００６２】
（ｃ）＝（ｄ）の場合は、通信時間１２６（＝９０２）の予測精度に応じて、（ｃ）＞（ｄ）の場合または（ｃ）＜（ｄ）の場合のどちらかに適用する。
【００６３】
（ｃ）＞（ｄ）の場合（Ｙ）は、依頼結果を送信してもタイムアウト時刻１１９（＝１３９）より前に到達可能であり、図１３のフォーマットのように依頼結果１３０１を格納して、送信処理４０７を時刻１１６に送信処理１３６する。
【００６４】
依頼結果１３０１は、通信経路１０３を経由して時刻１１７に送信処理１３７として、依頼元の受信口１０２に格納される。このとき、前述の往路の通信時間１２２の補正のように、復路の通信時間１２６も時刻１１７と時刻１１６の差を元に復路の通信時間９０２を補正することも可能である。
【００６５】
依頼元１０１は、依頼結果１３０１の受信３０４として、依頼元の受信口１０２に格納されている依頼結果を時刻１１８に受信１３８する。
【００６６】
次に、依頼元の受信口１０２から依頼元１０１が実際に依頼結果１３０１を受信１３８する時刻１１８と時刻１１７の差の時間１２７も受信するデータ量によっては無視できないほどの大きさとなる場合があるが、タイムアウト時刻１１９の検出そのものは依頼元の受信口１０２が判断するものであるため、依頼元１０１が時間１２７の影響を考える必要はない。
【００６７】
依頼元１０１が、（ａ）＜（ｂ）のタイムアウト時刻１１９までに処理することが不可能であることを依頼結果１３０１として受信した場合は、従来の相対時間を利用した場合のように時刻１１９まで待つ必要がなくなり、時刻１１８との差の時間１２８の分、早く次の処理に移行することが可能となり、処理全体として効率が良くなる。
なお、依頼元１０１が、（ａ）＞（ｂ）のタイムアウト時刻１１９より前に依頼結果１３０１を受信できる場合は、正常ケースとして依頼元１０１の処理依頼の成功/失敗の判定３０５が成功（Ｙ）と判定されるだけであり従来と比べて変わらない。
【００６８】
（ｃ）＜（ｄ）の場合（Ｎ）は、依頼先１０５が依頼結果１３０１を送信したとしても依頼先の受信口１０２が受信する前にタイムアウトと判断することから、依頼結果１３０１を送信する必要がない。
これは依頼元１０１の処理依頼の成功/失敗の判定３０５により失敗（Ｎ）と判定され、依頼先１０５と依頼結果の認識の違いに繋がるが、これは従来と同様に元に戻す（リカバリ）処理の要否の判定３０６および戻す（リカバリ）処理３０７などが必要となるだけで、従来と比べて効率が悪くなる訳ではない。
【００６９】
もし、依頼先１０５の異常などで依頼結果１３０１が通信されない場合は、依頼元１０１はタイムアウト時刻１１９でタイムアウトすることになるが、これも従来と比べて変わらない。
【００７０】
以下、依頼元１０１および依頼先１０５は、３０８および４０８としてシステムの仕様に応じて処理の繰り返しの要否判定をして、送受信を繰り返す。
【００７１】
以上により、従来に比べて全体としてより効率よく処理依頼のやり取りを行うことが可能となる。
【図面の簡単な説明】
【００７２】
【図１】処理のタイムアウト時刻を判定する実施方法を説明したシーケンス図である。
【図２】依頼元と依頼先の接続形態を説明した図である。
【図３】依頼元の動作例を説明したフローチャートである。
【図４】依頼先の動作例を説明したフローチャートである。
【図５】依頼元のシステムの初期化の動作例を説明したフローチャートである。
【図６】依頼先のシステムの初期化の動作例を説明したフローチャートである。
【図７】通信経路の往路および復路の通信時間を予測する実施方法を説明したシーケンス図である。
【図８】処理毎の処理時間テーブルである。
【図９】通信経路の通信時間テーブルである。
【図１０】実施例の機器／モジュール構成の図である。
【図１１】通信データのフォーマットの図である。
【図１２】通信データに送信開始時間を追加したフォーマット図である。
【図１３】依頼結果の通信データのフォーマット図である。
【図１４】通信時間測定用の通信データのフォーマット図である。
【符号の説明】
【００７３】
１０１  依頼元
１０２  依頼元の受信口
１０３  通信経路、送信時の処理なども含む
１０４  依頼先の受信口
１０５  依頼先
１１１  処理依頼の送信開始時刻
１１２  依頼元の依頼結果の受信処理開始時刻
１１３  処理依頼の通信時刻
１１４  依頼先の受信処理開始時刻
１１５  依頼先の処理依頼の受信時刻
１１６  依頼結果の送信開始時刻
１１７  依頼結果の通信時刻
１１８  依頼元の依頼結果の受信時刻
１１９  処理依頼のタイムアウト時刻
２０１  依頼元その１
２０２  依頼元そのｎ
２０３  依頼先
７１１  処理依頼の送信開始時刻
７１２  処理依頼の通信時刻
７１３  依頼先の処理依頼の受信時刻
７１４  依頼結果の送信開始時刻
７１５  依頼結果の通信時刻
７１６  依頼元の依頼結果の受信時刻
８０１  電源制御処理の処理時間
８０２  電源制御処理のタイムアウトまでの相対時間
８０３  ステータス制御処理の処理時間
８０４  ステータス制御処理のタイムアウトまでの相対時間
９０１  往路の通信時間
９０２  復路の通信時間
１００１  外部入力機器を制御するコンソールモジュール
１００２  メイン機器のステータスを監視するステータス制御モジュール
１００３  メイン機器を制御するメイン機器制御モジュール
１００４  サブ機器
１００５  メイン機器
１１０１  タイムアウト時刻を格納する領域
１１０２  処理依頼の通信データを格納する領域
１２０１  送信処理開始時刻を格納する領域
１３０１  依頼結果を格納する領域
１４０１  通信測定用データを格納する領域
【図１】
2007058477.tif 000003
【図２】
2007058477.tif 000004
【図３】
2007058477.tif 000005
【図４】
2007058477.tif 000006
【図５】
2007058477.tif 000007
【図６】
2007058477.tif 000008
【図７】
2007058477.tif 000009
【図８】
2007058477.tif 000010
【図９】
2007058477.tif 000011
【図１０】
2007058477.tif 000012
【図１１】
2007058477.tif 000013
【図１２】
2007058477.tif 000014
【図１３】
2007058477.tif 000015
【図１４】
2007058477.tif 000016