特開 2023-121565 リクエスト制御システム、リクエスト制御方法及びプログラム

(19)【発行国】日本国特許庁(JP)

(12)【公報種別】公開特許公報(A)

(11)【公開番号】P2023121565

(43)【公開日】2023-08-31

(54)【発明の名称】リクエスト制御システム、リクエスト制御方法及びプログラム

(51)【国際特許分類】

   G06F 11/30 20060101AFI20230824BHJP

【ＦＩ】

G06F11/30 155

G06F11/30 140A

【審査請求】有

【請求項の数】5

【出願形態】ＯＬ

(21)【出願番号】P 2022024972

(22)【出願日】2022-02-21

(71)【出願人】

【識別番号】000227205

【氏名又は名称】ＮＥＣプラットフォームズ株式会社

(74)【代理人】

【識別番号】100106909

【弁理士】

【氏名又は名称】棚井 澄雄

(74)【代理人】

【識別番号】100134544

【弁理士】

【氏名又は名称】森 隆一郎

(74)【代理人】

【識別番号】100149548

【弁理士】

【氏名又は名称】松沼 泰史

(74)【代理人】

【識別番号】100162868

【弁理士】

【氏名又は名称】伊藤 英輔

(72)【発明者】

【氏名】小林 宏次

【テーマコード（参考）】

5B042

【Ｆターム（参考）】

5B042JJ08

(57)【要約】

【課題】リクエスト制御装置、リクエスト制御システム、リクエスト制御方法及びプログラムを提供する。
【解決手段】リクエスト制御装置は、ノードが監視対象とする対象装置に対し、ノードが定期的に対象装置に関する情報を読み出すためのリクエスト要求を登録する登録部と、登録部によって登録されたリクエスト要求を対象装置に行い、リクエスト要求に対する対象装置からのリプライ情報を取得する定期リクエスト制御部と、定期リクエスト制御部により取得されたリプライ情報をノードに発行する発行制御部と、備える。
【選択図】図１０

【特許請求の範囲】

【請求項1】

ノードが監視対象とする対象装置に対し、前記ノードが定期的に前記対象装置に関する情報を読み出すためのリクエスト要求を登録する登録部と、
前記登録部によって登録された前記リクエスト要求を前記対象装置に行い、前記リクエスト要求に対する前記対象装置からのリプライ情報を取得する定期リクエスト制御部と、
前記定期リクエスト制御部により取得された前記リプライ情報を前記ノードに発行する発行制御部と、
を備えたリクエスト制御装置。

【請求項2】

前記定期リクエスト制御部は、前記登録部によって登録された前記リクエスト要求を前記対象装置に定期的に繰り返して行い、前記リクエスト要求に対する前記対象装置からの前記リプライ情報を定期的に取得する請求項１に記載のリクエスト制御装置。

【請求項3】

前記発行制御部は、前記定期リクエスト制御部により前記リプライ情報が取得されるたびに、前記リプライ情報を前記ノードに発行する請求項１または請求項２に記載のリクエスト制御装置。

【請求項4】

ノードとリクエスト制御装置とを含むリクエスト制御システムであって、
前記リクエスト制御装置は、
前記ノードが監視対象とする対象装置に対し、前記ノードが定期的に前記対象装置に関する情報を読み出すためのリクエスト要求を登録する登録部と、
前記登録部によって登録された前記リクエスト要求を前記対象装置に行い、前記リクエスト要求に対する前記対象装置からのリプライ情報を取得する定期リクエスト制御部と、
前記定期リクエスト制御部により取得された前記リプライ情報を前記ノードに発行する発行制御部と、
を備えたリクエスト制御システム。

【請求項5】

ノードが監視対象とする対象装置に対し、前記ノードが定期的に前記対象装置に関する情報を読み出すためのリクエスト要求を登録し、
登録された前記リクエスト要求を前記対象装置に行い、前記リクエスト要求に対する前記対象装置からのリプライ情報を取得し、
取得された前記リプライ情報を前記ノードに発行する、
リクエスト制御方法。

【請求項6】

リクエスト制御装置のコンピュータを、
ノードが監視対象とする対象装置に対し、前記ノードが定期的に前記対象装置に関する情報を読み出すためのリクエスト要求を登録する登録部、
前記登録部によって登録された前記リクエスト要求を前記対象装置に行い、前記リクエスト要求に対する前記対象装置からのリプライ情報を取得する定期リクエスト制御部、
前記定期リクエスト制御部により取得された前記リプライ情報を前記ノードに発行する発行制御部、
として機能させるプログラム。

【発明の詳細な説明】

【技術分野】

【0001】

本発明は、リクエスト制御装置、リクエスト制御システム、リクエスト制御方法及びプログラムに関する。

【背景技術】

【0002】

特許文献１には、マルチノード構成における診断プロセッサから共有物へのハードウェアを使った技術が開示されている。この技術では、第１ノード及び第２ノードからのバスコマンド間を調整することが開示されている。

【0003】

特許文献２には、マルチノード構成における診断プロセッサから監視対象である対象装置（ＰＳＵ（Power Supply Unit）など）へのハードウェアを使ったアクセス制御方式が開示されている。こうしたアクセス制御に関連する技術の一例を図１１を用いて説明する。

【0004】

図１１には、２つのノードＡ、Ｂと共有ＰＬＤ（Programmable Logic Device）と、ＰＳＵなどの対象装置とが示されている。図１１において、ノードＡの診断プロセッサは、ＰＬＤで構築されたＰａｒ－ＮＡ内の共有部アクセス制御Ｗｉｎｄｏｗへ、リクエスト要求とリクエスト要求の送信先とを登録するとともに、アクセス開始指示を行う。なお、ノードＡの診断プロセッサは、共有部アクセス制御Ｗｉｎｄｏｗに対してＩ２Ｃデバイス群を用いてアクセスする（ステップＳ００１）。

【0005】

Ｐａｒ－ＮＡは対象装置へのアクセス開始指示を契機に共有ＰＬＤ内の調停部へ調停要求を行う。共有ＰＬＤはＰａｒ－ＮＡ、Ｐａｒ－ＮＢ間で調停を行いＰａｒ－ＮＡに調停獲得を通知する。Ｐａｒ－ＮＡは共有ＰＬＤにリクエスト要求を行い（ステップＳ００２）、共有ＰＬＤは自身のレジスタまたはＩ２Ｃアクセスで対象装置へアクセスする（ステップＳ００３）。

【0006】

共有ＰＬＤは自身のレジスタまたは共有物へのアクセスが完了すると、対象装置からのリプライ情報（ステータス情報やデータ）をＰａｒ－ＮＡへ送信する（ステップＳ００４）。Ｐａｒ－ＮＡはリプライ情報を共有部アクセス制御Ｗｉｎｄｏｗへ登録し、診断プロセッサへの完了通知を専用線でアサートする（ステップＳ００５）。

【0007】

ノードＡの診断プロセッサは完了通知を受けてＩ２ＣアクセスでＰａｒ－ＮＡ内の共有部アクセス制御Ｗｉｎｄｏｗからリプライ情報を取得する。なお、他ノード（ノードＢ）の診断プロセッサも同様のアクセス方式で共有ＰＬＤ内のレジスタまたは共有物へアクセスするため、競合しないよう共有ＰＬＤ内の調停部にてリクエストの排他制御をしている。

【先行技術文献】

【特許文献】

【0008】

【特許文献1】特開２０１９－１６０２９７号公報

【特許文献2】特開２０１９－１７５００３号公報

【発明の概要】

【発明が解決しようとする課題】

【0009】

上述した関連技術において、例えば、ノードＡの診断プロセッサから対象装置への１回のアクセスにつき、診断プロセッサとＰａｒ－ＮＡの間で２回のＩ２Ｃアクセスが行われ、共有ＰＬＤと対象装置の間で１回のＩ２Ｃアクセスが行われる。すなわち、ノードＡの診断プロセッサから対象装置への１回のアクセスにつき計３回Ｉ２Ｃアクセスが行われることとなる。これは、ノードＢの診断プロセッサにおいても同様である。

【0010】

診断プロセッサは対象装置へのアクセスを定期的に実行している。今後対象装置が増え、診断プロセッサから対象装置へのアクセスが増加する事が予想される中、レイテンシの短縮が不可欠になっているという背景がある。そのため、アクセス回数はなるべく少ない方がよい。

【0011】

また、関連技術では、共有ＰＬＤにおけるノード間（ノードＡ、Ｂ）の排他制御によるオーバーヘッドが大きい。例えば、２ノード構成の場合、競合すると最大１回のＩ２Ｃアクセス分の待ち合わせは発生する。４ノード構成の場合は最大３回のＩ２Ｃアクセス分の待ち合わせが発生する。こうした待ち合わせがレイテンシ増大の要因になっている。このように関連技術では、アクセス回数が増大し、それに伴いレイテンシが増大するという課題があった。

【0012】

そこでこの発明は、リクエスト制御装置、リクエスト制御システム、リクエスト制御方法及びプログラムを提供することを目的としている。

【課題を解決するための手段】

【0013】

本発明の第１の態様によれば、リクエスト制御装置は、ノードが監視対象とする対象装置に対し、前記ノードが定期的に前記対象装置に関する情報を読み出すためのリクエスト要求を登録する登録部と、前記登録部によって登録された前記リクエスト要求を前記対象装置に行い、前記リクエスト要求に対する前記対象装置からのリプライ情報を取得する定期リクエスト制御部と、前記定期リクエスト制御部により取得された前記リプライ情報を前記ノードに発行する発行制御部と、を備えた。

【0014】

本発明の第２の態様によれば、リクエスト制御システムは、ノードとリクエスト制御装置とを含むリクエスト制御システムであって、前記リクエスト制御装置は、前記ノードが監視対象とする対象装置に対し、前記ノードが定期的に前記対象装置に関する情報を読み出すためのリクエスト要求を登録する登録部と、前記登録部によって登録された前記リクエスト要求を前記対象装置に行い、前記リクエスト要求に対する前記対象装置からのリプライ情報を取得する定期リクエスト制御部と、前記定期リクエスト制御部により取得された前記リプライ情報を前記ノードに発行する発行制御部と、を備えた。

【0015】

本発明の第３の態様によれば、リクエスト制御方法は、ノードが監視対象とする対象装置に対し、前記ノードが定期的に前記対象装置に関する情報を読み出すためのリクエスト要求を登録し、登録された前記リクエスト要求を前記対象装置に行い、前記リクエスト要求に対する前記対象装置からのリプライ情報を取得し、取得された前記リプライ情報を前記ノードに発行する。

【0016】

本発明の第４の態様によれば、プログラムは、リクエスト制御装置のコンピュータを、ノードが監視対象とする対象装置に対し、前記ノードが定期的に前記対象装置に関する情報を読み出すためのリクエスト要求を登録する登録部、前記登録部によって登録された前記リクエスト要求を前記対象装置に行い、前記リクエスト要求に対する前記対象装置からのリプライ情報を取得する定期リクエスト制御部、前記定期リクエスト制御部により取得された前記リプライ情報を前記ノードに発行する発行制御部、として機能させる。

【発明の効果】

【0017】

本発明によれば、リクエスト制御装置、リクエスト制御システム、リクエスト制御方法及びプログラムを提供することができる。

【図面の簡単な説明】

【0018】

【図1】本発明の一実施形態の構成を示すリクエスト制御システムの構成を示すブロック図である。

【図2】ｎ＝２としたリクエスト制御システム１００の構成例を示す図である。

【図3】診断プロセッサ対象装置へ定期的に送信するリクエスト要求を行う場合に一度だけ実行される処理概要を示す図である。

【図4】リクエスト要求に対するリプライ情報を診断プロセッサが取得する処理概要を示す図である。

【図5】診断プロセッサの処理の流れを示すフローチャートである。

【図6】Ｐａｒ－Ｎ１ＰＬＤの処理の流れを示すフローチャートである。

【図7】Ｐａｒ－Ｎ１ＰＬＤの処理の流れを示すフローチャートである。

【図8】定期リクエスト制御部の処理の流れを示すフローチャートである。

【図9】Ｐａｒ－Ｎｘ発行制御部の処理の流れを示すフローチャートである。

【図10】リクエスト制御装置の最小構成を示す図である。

【図11】関連技術を示す図である。

【発明を実施するための形態】

【0019】

以下、本発明の一実施形態によるリクエスト制御装置を含むリクエスト制御システムを図面を参照して説明する。図１は同実施形態によるリクエスト制御システム１００の構成を示すブロック図である。

【0020】

リクエスト制御システム１００は、複数（図１ではｎ個：ｎは２以上の整数）のノード１０－１、…、１０－ｎ、ノードと同じ数のＩ／Ｆ（インタフェース）２０－１、…、２０－ｎ、リクエスト制御装置３０、および対象装置４０で構成される。

【0021】

ノード１０－１、…、１０－ｎは、それぞれＩ／Ｆ２０－１、…、２０－ｎを介してリクエスト制御装置３０と接続する。リクエスト制御装置３０は、対象装置４０と接続する。ノード１０－１、…、１０－ｎは、後述する診断プロセッサ等を有し、対象装置４０を監視対象とする。リクエスト制御装置３０は、ＰＬＤ（Programmable Logic Device）で構築される。リクエスト制御装置３０は、ノード１０－１、…、１０－ｎに代わって対象装置４０に一括してリクエスト要求を行い、リクエスト要求に対する対象装置４０からのリプライ情報をノード１０－１、…、１０－ｎに送信する。リプライ情報は、対象装置４０のステータスや、対象装置４０により取得されたデータ（温度などの物理量）である。

【0022】

以下、ノード１０－１、…、１０－ｎや、リクエスト制御装置３０などの詳細な構成について説明する。なお、説明を簡単にするために、ｎ＝２としたリクエスト制御システム１００を例に説明する。

【0023】

図２は、ｎ＝２としたリクエスト制御システム１００の構成例を示す図である。図２において、リクエスト制御システム１００は、２つのノード１０ａ、１０ｂ、２つのＩ／Ｆ２０ａ、２０ｂ、リクエスト制御装置３０、および対象装置４０で構成される。以下の説明において、ノード１０ａ、１０ｂを特に区別しない場合には、ノード１０と表現することがある。Ｉ／Ｆ２０ａ、２０ｂを特に区別しない場合には、Ｉ／Ｆ２０と表現することがある。

【0024】

ノード１０の構成について説明する。ノード１０ａ、１０ｂは、ともに同じ構成のため、ノード１０ａを用いて説明する。ノード１０ａは、診断プロセッサ１０１ａ、Ｉ２Ｃデバイス群１０２ａ、およびＰａｒ－Ｎ１ＰＬＤ１０３ａで構成される。Ｐａｒ－Ｎ１ＰＬＤ１０３ａはＰＬＤで構築される。診断プロセッサ１０１ａは、対象装置４０に送信するリクエスト要求を生成したり、対象装置４０からのリプライ情報にもとづいて対象装置４０の診断を行う。リクエスト要求には、定期的に必要となるリプライ情報を要求するために、定期的に送信する必要があるリクエスト要求がある。特に断らない限り、以下の説明におけるリクエスト要求は、定期的に送信する必要があるリクエスト要求とする。定期的に送信する必要がないリクエスト要求を非定期リクエスト要求と表現することがある。

【0025】

診断プロセッサ１０１ａは、Ｐａｒ－Ｎ１ＰＬＤ１０３ａと通信するためのＩ２Ｃバス１０１１ａを有する。診断プロセッサ１０１ａとＰａｒ－Ｎ１ＰＬＤ１０３ａは、Ｉ２Ｃデバイス群１０２ａを介して接続する。

【0026】

Ｐａｒ－Ｎ１ＰＬＤ１０３ａは、Ｉ２Ｃバス１０３１ａ、共有部アクセス制御Ｗｉｎｄｏｗ１０３２ａ、診断プロセッサ見えレジスタ１０３３ａ、および一時格納レジスタ１０３４ａで構成される。Ｉ２Ｃバス１０３１ａは、診断プロセッサ１０１ａと通信するためのバスである。共有部アクセス制御Ｗｉｎｄｏｗ１０３２ａは、診断プロセッサ１０１ａから送信される、リクエスト要求と、リクエスト要求の送信先とを登録するとともに、アクセス開始指示を受信する。アクセス開始指示を受信すると、共有部アクセス制御Ｗｉｎｄｏｗ１０３２ａは、リクエスト制御装置３０にリクエスト要求を送信する。

【0027】

一時格納レジスタ１０３４ａは、リクエスト要求に応じてリクエスト制御装置３０から発行されたリプライ情報を一時記憶する。リクエスト要求は複数種類であることが一般的であり、この場合、一時格納レジスタ１０３４ａにはリプライ情報もリクエスト要求に応じた数だけ記憶される。診断プロセッサ見えレジスタ１０３３ａは、リクエスト要求に応じた数だけリプライ情報が一時格納レジスタ１０３４ａに記憶されると、それら全てのリプライ情報をコピーして記憶する。診断プロセッサ１０１は、診断プロセッサ見えレジスタ１０３３ａにコピーされたリプライ情報を取得する。

【0028】

Ｐａｒ－Ｎ１ＰＬＤ１０３ａは、Ｉ／Ｆ２０ａによりリクエスト制御装置３０と接続する。上記Ｉ／Ｆ２０ａは、ＰＬＤ間のインタフェースとなるため、独自のプロトコルで通信しており、その通信速度はＩ２Ｃの通信レートに対して１００倍以上高速となっている。

【0029】

リクエスト制御装置３０は、調停部３０１、定期リクエスト登録部３０２、Ｐａｒ－Ｎｘ発行制御部３０３、定期リクエスト制御部３０４、およびＩ２Ｃバス３０５で構成される。調停部３０１は、各部から送信された調停要求により各部によるアクセスを調停する。調停要求は、Ｐａｒ－Ｎ１ＰＬＤ１０３ａ、Ｐａｒ－Ｎ２ＰＬＤ１０３ｂ、Ｐａｒ－Ｎｘ発行制御部３０３、および定期リクエスト制御部３０４から行われる。

【0030】

定期リクエスト登録部３０２は、ノード１０が監視対象とする対象装置４０に対し、ノード１０が定期的に対象装置４０に関する情報を読み出すためのリクエスト要求を管理テーブルに登録する。定期リクエスト制御部３０４は、診断プロセッサとは独立して動作する。定期リクエスト制御部３０４は、送出情報一時格納レジスタ３０４１を有する。定期リクエスト制御部３０４は、定期リクエスト登録部３０２によって登録されたリクエスト要求に応じて、対象装置４０にリクエスト要求を行う。ここでは、管理テーブルに登録されている順に対象装置４０へリクエスト要求が行われる。定期リクエスト登録部３０２は登録部と呼ばれることもある。

【0031】

対象装置４０にリクエスト要求を行う場合、定期リクエスト制御部３０４は、調停部３０１に調停要求を行い、調停を獲得すると管理テーブルからリクエスト情報を読み出し対象装置４０へリクエスト要求を行う。定期リクエスト制御部３０４は、リクエスト要求に対する対象装置４０からのリプライ情報を取得する。定期リクエスト制御部３０４は、取得したリプライ情報を送出情報一時格納レジスタ３０４１に記憶する。

【0032】

このように、定期リクエスト制御部３０４は、登録されたリクエスト要求を対象装置４０に定期的に繰り返して行い、リクエスト要求に対する対象装置４０からのリプライ情報を定期的に取得する。これにより、登録されたリクエスト要求に対する対象装置４０からのリプライ情報を取得するので、複数のノードが個々にリプライ情報を取得する場合と比較して、対象装置４０へのアクセス回数を抑制することができる。

【0033】

Ｐａｒ－Ｎｘ発行制御部３０３は、定期リクエスト制御部３０４により取得されたリプライ情報を複数のノード１０にブロードキャストで発行する。Ｐａｒ－Ｎｘ発行制御部３０３は、送出情報格納レジスタ３０３１を有する。Ｐａｒ－Ｎｘ発行制御部３０３は、送出情報一時格納レジスタ３０４１に記憶されたリプライ情報を送出情報格納レジスタ３０３１に記憶する。こうして送出情報格納レジスタ３０３１が更新されると、Ｐａｒ－Ｎｘ発行制御部３０３は、調停部３０１へ調停要求を行う。

【0034】

Ｐａｒ－Ｎｘ発行制御部３０３は、調停を獲得したらＰａｒ－Ｎ１ＰＬＤ１０３ａ、Ｐａｒ－Ｎ２ＰＬＤ１０３ｂへブロードキャスト信号をアサートしつつ送出情報格納レジスタ３０３１に記憶されたリプライ情報を発行する。なお、図２の構成では、Ｐａｒ－Ｎ１ＰＬＤ１０３ａ、Ｐａｒ－Ｎ２ＰＬＤ１０３ｂのみであるため、これら２つにリプライ情報が送信されるが、ブロードキャストで送信するので、全てのノード１０にリプライ情報は送信される。Ｐａｒ－Ｎｘ発行制御部３０３は発行制御部と呼ばれることもある。このように、Ｐａｒ－Ｎｘ発行制御部３０３は、定期リクエスト制御部３０４によりリプライ情報が取得されるたびに、リプライ情報を複数１０のノードに発行する。これにより、複数のノードが個々にリプライ情報を取得する場合と比較して、調停部３０１における調停のオーバーヘッドを低減することができ、その結果レイテンシ増大を抑制することができる。

【0035】

対象装置４０は、監視対象となる装置であり、リクエスト要求に対してリプライ情報を応答するものであれば、どのようなものであってもよい。本実施形態では、対象装置４０として、コンピュータに電源を供給するＰＳＵ（Power Supply Unit）、コンピュータを冷却するＦＡＮ、コンピュータの温度を測るＴＭＰ（温度センサ）を例示している。

【0036】

次に、リクエスト制御システム１００の処理概要を、図３、図４を用いて説明する。図３、図４では、一例として、ノード１０ａの診断プロセッサ１０１ａが対象装置４０からリプライ情報を取得する場合の処理概要を示している。

【0037】

図３は、診断プロセッサ１０１ａが対象装置４０へ定期的に送信するリクエスト要求を行う場合に一度だけ実行される処理概要を示す図である。ノード１０ａの診断プロセッサ１０１ａは、Ｐａｒ－Ｎ１ＰＬＤ１０３ａ内にある共有部アクセス制御Ｗｉｎｄｏｗ１０３２ａに、リクエスト要求とリクエスト要求の送信先とをリクエスト制御装置３０内の管理テーブルへ登録すること、およびアクセス開始指示を行う（ステップＳ１０１）。

【0038】

Ｐａｒ－Ｎ１ＰＬＤ１０３ａは対象装置４０へのアクセス開始指示を契機にリクエスト制御装置３０内の調停部３０１へ調停要求を行う。Ｐａｒ－Ｎ１ＰＬＤ１０３ａは、調停を獲得すると、リクエスト制御装置３０にリクエスト要求を登録させる。リクエスト制御装置３０は、定期リクエスト登録部３０２により、管理テーブルにリクエスト要求を登録する（ステップＳ１０２）。

【0039】

リクエスト制御装置３０は、定期リクエスト登録部３０２による管理テーブルへの登録が完了すると、リプライ情報をＰａｒ－Ｎ１ＰＬＤ１０３ａへ返却する（ステップＳ１０３）。Ｐａｒ－Ｎ１ＰＬＤ１０３ａは、登録が完了したことを示すステータス情報を共有部アクセス制御Ｗｉｎｄｏｗ１０３２ａへ登録する。

【0040】

Ｐａｒ－Ｎ１ＰＬＤ１０３ａは、診断プロセッサ１０１ａへの完了通知を専用線でアサートする（ステップＳ１０４）。診断プロセッサ１０１ａは完了通知を受けてＰａｒ－Ｎ１ＰＬＤ１０３ａ内の共有部アクセス制御Ｗｉｎｄｏｗ１０３２ａからステータス情報を取得する（ステップＳ１０５）。登録が正常に行われた場合、ステータス情報は、正常完了を示すNormal Endとなる。これにより、Ｐａｒ－Ｎ１ＰＬＤ１０３ａは、リクエスト要求が登録されたか否かを判定できる。

【0041】

上述したステップＳ１０１～１０５の処理は、対象装置４０への定期的に送信するリクエスト要求の数だけ繰り返し実行される。また、ノード１０ｂにおいても同様の処理が行われる。なお、ノード１０ｂにおいて処理が行われると、管理テーブルに同じリクエスト要求が登録される。このように、ノード１０は、定期リクエスト登録部３０２にリクエスト要求を一度登録させることにより、リクエスト要求に対する対象装置４０からのリプライ情報を定期的に取得することができる。これにより、定期的に繰り返して調停要求を行う必要がないため、調停部３０１における調停のオーバーヘッドを低減することができ、その結果レイテンシ増大を抑制することができる。

【0042】

図４は、上記ステップＳ１０１～１０５の処理により登録されたリクエスト要求に対するリプライ情報を診断プロセッサ１０１ａが取得する処理概要を示す図である。なお、対象装置からのリクエスト要求に対するリプライ情報の取得はハードウェア主導（リクエスト制御装置３０）で実行される。このとき、リクエスト制御装置３０は、診断プロセッサ１０１ａ、１０１ｂとは独立して動作する。

【0043】

リクエスト制御装置３０内の定期リクエスト制御部３０４はリクエスト制御装置３０内にある調停部３０１に調停要求を行い（ステップＳ２０１）、調停を獲得すると管理テーブルからリクエスト情報を読み出し対象の対象装置４０へリクエスト要求を行う（ステップＳ２０２）。対象装置４０から取得されたリプライ情報は送出情報一時格納レジスタ３０４１に記憶される（ステップＳ２０３）。

【0044】

リクエスト制御装置３０内の定期リクエスト制御部３０４は、管理テーブルに登録されている全てのリクエスト要求に対するリプライ情報の取得が完了すると、送出情報一時格納レジスタ３０４１からＰａｒ－Ｎｘ発行制御部３０３内の送出情報格納レジスタ３０３１へリプライ情報をコピーする（ステップＳ２０４）。

【0045】

リクエスト制御装置３０内のＰａｒ－Ｎｘ発行制御部３０３は、自身の送出情報格納レジスタ３０３１が更新されると、リクエスト制御装置３０内にある調停部３０１へ調停要求を行う。Ｐａｒ－Ｎｘ発行制御部３０３は、調停を獲得すると全Ｐａｒ－Ｎ１ＰＬＤ１０３ａへブロードキャスト信号をアサートしつつ送出情報格納レジスタ３０３１に記憶されたリプライ情報を発行する（ステップＳ２０５）。

【0046】

Ｐａｒ－Ｎ１ＰＬＤ１０３ａは、自身にある一時格納レジスタ１０３４ａにリプライ情報を記憶し、全リクエスト要求に対するリプライ情報の取得が完了すると、一斉に診断プロセッサ見えレジスタ１０２２ａにコピーする（ステップＳ２０６）。診断プロセッサ１０１ａは、Ｐａｒ－Ｎ１ＰＬＤ１０３ａの診断プロセッサ見えレジスタ１０３３ａからリプライ情報を取得する（ステップＳ２０７）。なお、ノード１０ｂにおいても、ステップＳ２０６、２０７と同様の処理が行われる。

【0047】

このようにすることで、まずノード１０とリクエスト制御装置３０とのアクセス回数を抑制できる。また、リクエスト制御装置３０と対象装置４０のとのアクセス回数を抑制できる。これにより、レイテンシ増大も抑制することができる。

【0048】

次に、フローチャートを用いて説明する。図５は、診断プロセッサ１０１ａ、および診断プロセッサ１０１ｂの処理の流れを示すフローチャートである。上述したように、ノード１０ａとノード１０ｂは同じ構成のため、図５の説明では、診断プロセッサ１０１ａを用いて説明する。また、図５以降の図では、共有部アクセス制御Ｗｉｎｄｏｗを、省略して「共有部アクセス制御」と記載している。

【0049】

図５のステップＳ１－１～１－１２は、図３で説明した、診断プロセッサ１０１ａが対象装置４０へ定期的に送信するリクエスト要求を行う場合に一度だけ実行される処理の詳細を示している。まずステップＳ１－１～１－１２について説明する。

【0050】

診断プロセッサ１０１ａは、対象装置４０へアクセスをする際には自身の管理テーブル登録完了フラグを参照し、管理テーブル登録完了フラグが１か否かを判定する（ステップＳ１－１）。管理テーブル登録完了フラグが０の時はリクエスト制御装置３０内にある管理テーブルへの登録がないことを示し、１の時はリクエスト制御装置３０内にある管理テーブルへの登録がないことを示す。

【0051】

管理テーブル登録完了フラグが０の場合には（ステップＳ１－１：ＮＯ）、診断プロセッサ１０１ａは、Ｐａｒ－Ｎ１ＰＬＤ１０３ａ内にある共有部アクセス制御Ｗｉｎｄｏｗ１０３２ａにリクエスト要求とリクエスト要求の送信先とをリクエスト制御装置３０内の管理テーブルへ登録すること、およびリクエスト制御装置３０へのアクセス開始指示を行う（ステップＳ１－２）。

【0052】

診断プロセッサ１０１ａは、Ｐａｒ－Ｎ１ＰＬＤ１０３ａからの登録の完了割り込みがアサートされるのを待つ（ステップＳ１－３）。アサートされると（ステップＳ１－３：ＹＥＳ）、診断プロセッサ１０１ａは、Ｐａｒ－Ｎ１ＰＬＤ１０３ａ内にある共有部アクセス制御Ｗｉｎｄｏｗ１０３２ａから指示した処理に対するステータス情報を取得する（ステップＳ１－４）。

【0053】

診断プロセッサ１０１ａは、ステータス情報が、正常完了を示すNormal Endか否かを判定する（ステップＳ１－５）。ステータス情報がNormal Endではない場合には（ステップＳ１－５：ＮＯ）、診断プロセッサ１０１ａは、処理を終了する。ステータス情報がNormal Endの場合には（ステップＳ１－５：ＹＥＳ）、診断プロセッサ１０１ａは、全てのリクエスト要求の管理テーブルへの登録が完了したか否かを判定する（ステップＳ１－６）。全てのリクエスト要求の管理テーブルへの登録が完了していない場合には（ステップＳ１－６：ＮＯ）、診断プロセッサ１０１ａは、ステップＳ１－２に戻る。

【0054】

全てのリクエスト要求の管理テーブルへの登録が完了した場合には（ステップＳ１－６：ＹＥＳ）、診断プロセッサ１０１ａは、Ｐａｒ－Ｎ１ＰＬＤ１０３ａ内にある共有部アクセス制御Ｗｉｎｄｏｗ１０３２ａに指示を行う（ステップＳ１－７）。ここでの指示は、定期リクエスト制御部３０４へのアクセス開始指示と、定期リクエスト制御部３０４へアクセス要求を対象装置４０に行わせる指示（定期リクエスト開始指示）である。

【0055】

診断プロセッサ１０１ａは、Ｐａｒ－Ｎ１ＰＬＤ１０３ａからの、定期リクエスト制御部３０４への指示の完了割り込みがアサートされるのを待つ（ステップＳ１－８）。アサートされると（ステップＳ１－８：ＹＥＳ）、診断プロセッサ１０１ａは、Ｐａｒ－Ｎ１ＰＬＤ１０３ａ内にある共有部アクセス制御Ｗｉｎｄｏｗ１０３２ａから指示した処理に対するステータス情報を取得する（ステップＳ１－９）。

【0056】

診断プロセッサ１０１ａは、ステータス情報が、正常完了を示すNormal Endか否かを判定する（ステップＳ１－１０）。ステータス情報がNormal Endではない場合には（ステップＳ１－１０：ＮＯ）、診断プロセッサ１０１ａは、処理を終了する。ステータス情報がNormal Endの場合には（ステップＳ１－１０：ＹＥＳ）、診断プロセッサ１０１ａは、管理テーブル登録完了フラグを１にする（ステップＳ１－１１）。これは、管理テーブルへの登録が正常完了し、定期リクエスト制御部３０４へアクセス要求を対象装置４０に行わせる指示も正常完了したためである。

【0057】

次いで、診断プロセッサ１０１ａは、リクエスト制御装置３０が管理テーブルに登録されている全てのリクエストが発行される時間よりも十分大きい一定時間（例えば１ｓ）を待ち合わせたのち、処理を終了する（ステップＳ１－１２）。

【0058】

次に、上述したステップＳ１－１で否定判定された場合の処理について説明する。上述したステップＳ１－１で否定判定された場合のステップＳ１－１４～１－１６は、非定期リクエスト要求に関する処理である。

【0059】

管理テーブル登録完了フラグが１の場合には（ステップＳ１－１：ＹＥＳ）、診断プロセッサ１０１ａは、対象装置４０へ定期的に送信する必要があるリクエスト要求に関する処理は完了している状態である。そのため、診断プロセッサ１０１ａは、リプライ情報の取得をするか、非定期リクエスト要求を行う。

【0060】

リプライ情報の取得ではない場合には（ステップＳ１－１３：ＮＯ）、診断プロセッサ１０１ａは、非定期リクエスト要求を行う（ステップＳ１－１４）。非定期リクエスト要求を行う場合、診断プロセッサ１０１ａは、Ｐａｒ－Ｎ１ＰＬＤ１０３ａ内にある共有部アクセス制御Ｗｉｎｄｏｗ１０３２ａにアクセス指示情報の登録およびリクエスト制御装置３０へのアクセス開始指示を行う。上記アクセス指示情報とは、非定期リクエスト要求の指示を示す情報である。

【0061】

診断プロセッサ１０１ａは、Ｐａｒ－Ｎ１ＰＬＤ１０３ａからの、定期リクエスト制御部３０４への指示の完了割り込みがアサートされるのを待つ（ステップＳ１－１５）。アサートされると（ステップＳ１－１５：ＹＥＳ）、診断プロセッサ１０１ａは、Ｐａｒ－Ｎ１ＰＬＤ１０３ａ内にある共有部アクセス制御Ｗｉｎｄｏｗ１０３２ａから指示した要求に対する応答を取得して（ステップＳ１－１６）、処理を終了する。ここでの応答は、要求に応じたステータス情報や要求に応じた各種データなどである。

【0062】

ステップＳ１－１３において、リプライ情報の取得である場合には（ステップＳ１－１３：ＹＥＳ）、診断プロセッサ１０１ａは、診断プロセッサ見えレジスタ１０３３ａからリプライ情報を取得し（ステップＳ１－１７）、処理を終了する。なお、リプライ情報の取得であるか否かの判定は、診断プロセッサ１０１ａへの完了通知が専用線でアサートされたか否かにより行うことができる。

【0063】

図６は、診断プロセッサ１０１ａからアクセスされたＰａｒ－Ｎ１ＰＬＤ１０３ａの処理の流れを示すフローチャートである。上述したように、Ｐａｒ－Ｎ１ＰＬＤ１０３ａとＰａｒ－Ｎ２ＰＬＤ１０３ｂは同じ構成のため、図６の説明では、診断プロセッサ１０１ａとＰａｒ－Ｎ１ＰＬＤ１０３ａとを用いて説明する。

【0064】

Ｐａｒ－Ｎ１ＰＬＤ１０３ａは、診断プロセッサ１０１ａからアクセスされた場合に、アクセス内容が対象装置４０へのアクセス開始指示であるか否かを判定する（ステップＳ２－１）。Ｐａｒ－Ｎ１ＰＬＤ１０３ａは、アクセス内容が対象装置４０へのアクセス開始指示ではない場合には（ステップＳ２－１：ＮＯ）、Ｐａｒ－Ｎ１ＰＬＤ１０３ａのレジスタへのアクセスと判定し、診断プロセッサ１０１ａが対象とするアドレスのレジスタ値の更新、またはアドレスのレジスタ値を返却し（ステップＳ２－２）、処理を終了する。

【0065】

上記ステップＳ２－１において、Ｐａｒ－Ｎ１ＰＬＤ１０３ａは、アクセス内容が対象装置４０へのアクセス開始指示である場合には（ステップＳ２－１：ＹＥＳ）、リクエスト制御装置３０の調停部３０１に調停要求を行う（ステップＳ２－３）。Ｐａｒ－Ｎ１ＰＬＤ１０３ａは、調停を獲得すると（ステップＳ２－４：ＹＥＳ）、共有部アクセス制御Ｗｉｎｄｏｗ１０３２ａ内に記憶されている対象装置４０に送信するリクエスト要求を、Ｉ／Ｆ２０ａを介してリクエスト制御装置３０に送信して（ステップＳ２－５）、処理を終了する。

【0066】

図７は、リクエスト制御装置３０からアクセスされたＰａｒ－Ｎ１ＰＬＤ１０３ａの処理の流れを示すフローチャートである。上述したように、Ｐａｒ－Ｎ１ＰＬＤ１０３ａとＰａｒ－Ｎ２ＰＬＤ１０３ｂは同じ構成のため、図７の説明では、診断プロセッサ１０１ａとＰａｒ－Ｎ１ＰＬＤ１０３ａとを用いて説明する。

【0067】

Ｐａｒ－Ｎ１ＰＬＤ１０３ａは、リクエスト制御装置３０からブロードキャスト信号がアサートされているか否かを判定する（ステップＳ３－１）。アサートされていない場合には（ステップＳ３－１：ＮＯ）、Ｐａｒ－Ｎ１ＰＬＤ１０３ａは、非定期リクエスト要求に対するリプライ情報と判定する。そして、Ｐａｒ－Ｎ１ＰＬＤ１０３ａは、リプライ情報がステータスの場合にはステータスを取得し、リプライ情報がデータの場合にはデータを取得する（ステップＳ３－２）。取得されたステータス情報またはデータは、共有部アクセス制御Ｗｉｎｄｏｗ１０３２ａ内のレジスタに記憶される。

【0068】

Ｐａｒ－Ｎ１ＰＬＤ１０３ａは、共有部アクセス制御Ｗｉｎｄｏｗ１０３２ａ内のレジスタに、ステータス情報またはデータの記憶を完了すると、診断プロセッサ１０１ａに完了割り込みを一定時間（例えば１ｍｓ）アサートし（ステップＳ３－３）、処理を終了する。

【0069】

ステップＳ３－１において、アサートされている場合には（ステップＳ３－１：ＹＥＳ）、Ｐａｒ－Ｎ１ＰＬＤ１０３ａは、定期的に送信するリクエスト要求に対するリプライ情報と判定し、一時格納レジスタ１０３４にリプライ情報を記憶する（ステップＳ３－４）。Ｐａｒ－Ｎ１ＰＬＤ１０３ａは、全てのリプライ情報を記憶すると、診断プロセッサ見えレジスタ１０３３ａにリプライ情報をコピーして（ステップＳ３－５）、処理を終了する。

【0070】

図８は、定期リクエスト制御部３０４の処理の流れを示すフローチャートである。定期リクエスト制御部３０４は、管理テーブルにおいて、定期リクエスト制御部３０４が読み出すアドレスを示す読み出しポインタをクリアする（ステップＳ４－１）。定期リクエスト制御部３０４は、定期リクエスト開始指示があったか否かを判定する（ステップＳ４－２）。定期リクエスト開始指示がない場合には（ステップＳ４－２）、定期リクエスト制御部３０４は、ステップＳ４－１に戻る。

【0071】

定期リクエスト開始指示があった場合には（ステップＳ４－２）、定期リクエスト制御部３０４は、リクエスト制御装置３０の調停部３０１に調停要求を行う（ステップＳ２－３）。定期リクエスト制御部３０４は、調停を獲得すると（ステップＳ４－４：ＹＥＳ）、管理テーブルから読み出したリクエスト要求を対象装置４０に送信する（ステップＳ４－５）。定期リクエスト制御部３０４は、対象装置４０から取得したリプライ情報を送出情報一時格納レジスタ３０４１に記憶する（ステップＳ４－６）。定期リクエスト制御部３０４は、読み出しポインタを１だけ増分する（ステップＳ４－７）。

【0072】

定期リクエスト制御部３０４は、有効フラグは０か否かを判定する（ステップＳ４－８）。有効フラグとは、現在の読み出しポインタが指すアドレス以降にリクエスト要求が記憶されているか否かを示すフラグである。現在の読み出しポインタが指すアドレス以降にリクエスト要求が登録されている場合、有効フラグは１となり、現在の読み出しポインタが指すアドレス以降にリクエスト要求が登録されていない場合、有効フラグは０となる。

【0073】

有効フラグが１の場合には（ステップＳ４－８：ＮＯ）、登録されているリクエスト要求がまだあるため、定期リクエスト制御部３０４は、ステップＳ４－３に戻る。有効フラグが０の場合には（ステップＳ４－８：ＹＥＳ）、登録されているリクエスト要求がないため、定期リクエスト制御部３０４は、送出情報一時格納レジスタ３０４１に記憶されたリプライ情報を送出情報一時格納レジスタにコピーして（ステップＳ４－９）、ステップＳ４－１に戻る。したがって、定期リクエスト制御部３０４は、定期リクエストの開始指示があった以降は、図８に示される処理を繰り返すこととなる。

【0074】

図９は、Ｐａｒ－Ｎｘ発行制御部３０３の処理の流れを示すフローチャートである。Ｐａｒ－Ｎｘ発行制御部３０３は、送出情報格納レジスタ３０３１が更新されたか否かを判定する（ステップＳ５－１）。Ｐａｒ－Ｎｘ発行制御部３０３はリクエスト制御装置３０内にある調停部３０１に調停要求を行う（ステップＳ５－２）。調停を獲得すると（ステップＳ５－３：ＹＥＳ）、Ｐａｒ－Ｎｘ発行制御部３０３は、ブロードキャスト信号をアサートしつつ送出情報格納レジスタ３０３１に記憶されたリプライ情報を発行し（ステップＳ５－４）、処理を終了する。ここでは、全てのノード１０にリプライ情報は発行される。

【0075】

図１０は本実施形態によるリクエスト制御装置９００の最小構成を示す図である。本実施形態によるリクエスト制御装置９００は、登録部１００１、定期リクエスト制御部１００２、および発行制御部１００３を備えればよい。
登録部１００１は、ノードが監視対象とする対象装置に対し、ノードが定期的に対象装置に関する情報を読み出すためのリクエスト要求を登録する。
定期リクエスト制御部１００２は、登録部１００１によって登録されたリクエスト要求を対象装置に行い、リクエスト要求に対する対象装置からのリプライ情報を取得する。
発行制御部は、定期リクエスト制御部１００２により取得されたリプライ情報をノードに発行する。

【0076】

このように、本実施形態によれば、複数のノードに代わり、登録されたリクエスト要求を対象装置に行い、リクエスト要求に対する対象装置からのリプライ情報を取得するので、複数のノードが個々にリプライ情報を取得する場合と比較して、対象装置へのアクセス回数を抑制することができる。

【0077】

なお、特許文献１に開示された構成において、２ノードで構成する場合にはＩ２Ｃポートが３つ必要となり、４ノードで構成する場合にはＩ２Ｃポートが5つ必要になる。安価なＰＬＤでは専用ＩＰとして用意されているＩ２Ｃポートは２つのものが多い。そのため、専用ＩＰを使用せずユーザ側でＩ２Ｃ回路を組み込む場合、アナログ的な部分で難易度が高いため、価格、品質、拡張性といった部分で課題がある。一方、本実施形態では、専用ＩＰが２つある安価なＰＬＤを使って実現可能である。

【0078】

上述した実施形態では、ノード１０は複数設けられているが、１つであってもよい。ノードが１つであっても、ノード１０は、定期リクエスト登録部３０２にリクエスト要求を一度登録させることにより、リクエスト要求に対する対象装置４０からのリプライ情報を定期的に取得することができる。これにより、定期的に繰り返して調停要求を行う必要がないため、調停部３０１における調停のオーバーヘッドを低減することができ、その結果レイテンシ増大を抑制することができる。

【0079】

上述のリクエスト制御装置は内部に、コンピュータシステムを有している。そして、上述した処理の過程は、プログラムの形式でコンピュータ読み取り可能な記録媒体に記憶されており、このプログラムをコンピュータが読み出して実行することによって、上記処理が行われる。ここでコンピュータ読み取り可能な記録媒体とは、磁気ディスク、光磁気ディスク、ＣＤ－ＲＯＭ、ＤＶＤ－ＲＯＭ、半導体メモリ等をいう。また、このコンピュータプログラムを通信回線によってコンピュータに配信し、この配信を受けたコンピュータが当該プログラムを実行するようにしても良い。

【0080】

また、上記プログラムは、このプログラムを記憶装置等に格納したコンピュータシステムから、伝送媒体を介して、あるいは、伝送媒体中の伝送波により他のコンピュータシステムに伝送されてもよい。ここで、プログラムを伝送する「伝送媒体」は、インターネット等のネットワーク（通信網）や電話回線等の通信回線（通信線）のように情報を伝送する機能を有する媒体のことをいう。また、上記プログラムは、前述した機能の一部を実現するためのものであっても良い。さらに、前述した機能をコンピュータシステムにすでに記録されているプログラムとの組み合わせで実現できるもの、いわゆる差分ファイル（差分プログラム）であっても良い。

【符号の説明】

【0081】

１０、１０ａ、１０ｂ ノード
３０ リクエスト制御装置
４０ 対象装置
１００ リクエスト制御システム
１０１、１０１ａ、１０１ｂ 診断プロセッサ
１０２ａ デバイス群
３０１ 調停部
３０２ 定期リクエスト登録部
３０３ 発行制御部
３０４ 定期リクエスト制御部
９００ リクエスト制御装置
１０００ リクエスト制御システム
１００１ 登録部
１００２ 定期リクエスト制御部
１００３ 発行制御部
１０１１ａ、１０３１ａ Ｉ２Ｃバス
１０２２ａ 診断プロセッサ見えレジスタ
１０３２ａ 共有部アクセス制御Ｗｉｎｄｏｗ
１０３３ａ 診断プロセッサ見えレジスタ
１０３４、１０３４ａ 一時格納レジスタ
３０３１ 送出情報格納レジスタ
３０４１ 送出情報一時格納レジスタ

【図1】

【図2】

【図3】

【図4】

【図5】

【図6】

【図7】

【図8】

【図9】

【図10】

【図11】

【手続補正書】

【提出日】2023-06-26

【手続補正1】

【補正対象書類名】特許請求の範囲

【補正対象項目名】全文

【補正方法】変更

【補正の内容】

【特許請求の範囲】

【請求項1】

複数のノードとリクエスト制御装置とを含むリクエスト制御システムであって、
前記リクエスト制御装置は、
前記複数のノードが監視対象とする対象装置に対し、前記複数のノードが定期的に前記対象装置に関する情報を読み出すためのリクエスト要求を登録する登録部と、
前記登録部によって登録された前記リクエスト要求を前記対象装置に行い、前記リクエスト要求に対する前記対象装置からのリプライ情報を取得する定期リクエスト制御部と、
前記定期リクエスト制御部により取得された前記リプライ情報をブロードキャストで前記複数のノードに発行する発行制御部と、
を備え、
前記複数のノードのそれぞれは、
専用線を用いた前記リクエスト要求の登録の完了を通知する完了通知に基づいて前記リプライ情報を取得する取得部、
を備えるリクエスト制御システム。

【請求項2】

前記定期リクエスト制御部は、前記登録部によって登録された前記リクエスト要求を前記対象装置に定期的に繰り返して行い、前記リクエスト要求に対する前記対象装置からの前記リプライ情報を定期的に取得する請求項１に記載のリクエスト制御システム。

【請求項3】

前記発行制御部は、前記定期リクエスト制御部により前記リプライ情報が取得されるたびに、前記リプライ情報を前記複数のノードに発行する請求項１または請求項２に記載のリクエスト制御システム。

【請求項4】

複数のノードが監視対象とする対象装置に対し、前記複数のノードが定期的に前記対象装置に関する情報を読み出すためのリクエスト要求を登録し、
登録された前記リクエスト要求を前記対象装置に行い、前記リクエスト要求に対する前記対象装置からのリプライ情報を取得し、
取得された前記リプライ情報をブロードキャストで前記複数のノードに発行する、
リクエスト制御方法。

【請求項5】

それぞれが専用線を用いたリクエスト要求の登録の完了を通知する完了通知に基づいてリプライ情報を取得する取得部を備える複数のノードとリクエスト制御装置とを含むリクエスト制御システムにおいて、
前記リクエスト制御装置のコンピュータを、
前記複数のノードが監視対象とする対象装置に対し、前記複数のノードが定期的に前記対象装置に関する情報を読み出すための前記リクエスト要求を登録する登録部、
前記登録部によって登録された前記リクエスト要求を前記対象装置に行い、前記リクエスト要求に対する前記対象装置からの前記リプライ情報を取得する定期リクエスト制御部、
前記定期リクエスト制御部により取得された前記リプライ情報をブロードキャストで前記複数のノードに発行する発行制御部、
として機能させるプログラム。

【手続補正3】

【補正対象書類名】明細書

【補正対象項目名】０００１

【補正方法】変更

【補正の内容】

【0001】

本発明は、リクエスト制御システム、リクエスト制御方法及びプログラムに関する。

【手続補正4】

【補正対象書類名】明細書

【補正対象項目名】００１２

【補正方法】変更

【補正の内容】

【0012】

そこでこの発明は、リクエスト制御システム、リクエスト制御方法及びプログラムを提供することを目的としている。

【手続補正5】

【補正対象書類名】明細書

【補正対象項目名】００１３

【補正方法】変更

【補正の内容】

【0013】

本発明の一態様によれば、リクエスト制御システムは、複数のノードとリクエスト制御装置とを含むリクエスト制御システムであって、前記リクエスト制御装置は、前記複数のノードが監視対象とする対象装置に対し、前記複数のノードが定期的に前記対象装置に関する情報を読み出すためのリクエスト要求を登録する登録部と、前記登録部によって登録された前記リクエスト要求を前記対象装置に行い、前記リクエスト要求に対する前記対象装置からのリプライ情報を取得する定期リクエスト制御部と、前記定期リクエスト制御部により取得された前記リプライ情報をブロードキャストで前記複数のノードに発行する発行制御部と、を備え、前記複数のノードのそれぞれは、専用線を用いた前記リクエスト要求の登録の完了を通知する完了通知に基づいて前記リプライ情報を取得する取得部、を備える。

【手続補正6】

【補正対象書類名】明細書

【補正対象項目名】００１４

【補正方法】削除

【補正の内容】

【手続補正7】

【補正対象書類名】明細書

【補正対象項目名】００１５

【補正方法】変更

【補正の内容】

【0015】

本発明の別の態様によれば、リクエスト制御方法は、複数のノードが監視対象とする対象装置に対し、前記複数のノードが定期的に前記対象装置に関する情報を読み出すためのリクエスト要求を登録し、登録された前記リクエスト要求を前記対象装置に行い、前記リクエスト要求に対する前記対象装置からのリプライ情報を取得し、取得された前記リプライ情報をブロードキャストで前記複数のノードに発行する。

【手続補正8】

【補正対象書類名】明細書

【補正対象項目名】００１６

【補正方法】変更

【補正の内容】

【0016】

本発明の別の態様によれば、プログラムは、それぞれが専用線を用いたリクエスト要求の登録の完了を通知する完了通知に基づいてリプライ情報を取得する取得部を備える複数のノードとリクエスト制御装置とを含むリクエスト制御システムにおいて、前記リクエスト制御装置のコンピュータを、前記複数のノードが監視対象とする対象装置に対し、前記複数のノードが定期的に前記対象装置に関する情報を読み出すための前記リクエスト要求を登録する登録部、前記登録部によって登録された前記リクエスト要求を前記対象装置に行い、前記リクエスト要求に対する前記対象装置からの前記リプライ情報を取得する定期リクエスト制御部、前記定期リクエスト制御部により取得された前記リプライ情報をブロードキャストで前記複数のノードに発行する発行制御部、として機能させる。