(19)【発行国】日本国特許庁(JP)
(12)【公報種別】特許公報(B2)
(11)【特許番号】
(24)【登録日】2023-11-13
(45)【発行日】2023-11-21
(54)【発明の名称】リクエスト制御システム、リクエスト制御方法及びプログラム
(51)【国際特許分類】
G06F 11/30 20060101AFI20231114BHJP
【FI】
G06F11/30 155
G06F11/30 140A
(21)【出願番号】P 2022024972
(22)【出願日】2022-02-21
【審査請求日】2022-02-21
(73)【特許権者】
【識別番号】000227205
【氏名又は名称】NECプラットフォームズ株式会社
(74)【代理人】
【識別番号】100106909
【氏名又は名称】棚井 澄雄
(74)【代理人】
【識別番号】100134544
【氏名又は名称】森 隆一郎
(74)【代理人】
【識別番号】100149548
【氏名又は名称】松沼 泰史
(74)【代理人】
【識別番号】100162868
【氏名又は名称】伊藤 英輔
(72)【発明者】
【氏名】小林 宏次
【審査官】坂庭 剛史
(56)【参考文献】
【文献】特開2014-186423(JP,A)
【文献】特開2019-175003(JP,A)
【文献】特開2019-160279(JP,A)
【文献】特開2009-245430(JP,A)
【文献】特開2009-088798(JP,A)
【文献】特開平11-249976(JP,A)
【文献】米国特許出願公開第2005/0132041(US,A1)
(58)【調査した分野】(Int.Cl.,DB名)
G06F 11/30
(57)【特許請求の範囲】
【請求項1】
複数のノードとリクエスト制御装置とを含むリクエスト制御システムであって、
前記リクエスト制御装置は、
前記複数のノードが監視対象とする対象装置に対し、前記
複数のノードが定期的に前記対象装置に関する情報を読み出すためのリクエスト要求を登録する登録部と、
前記登録部によって登録された前記リクエスト要求を前記対象装置に行い、前記リクエスト要求に対する前記対象装置からのリプライ情報を取得する定期リクエスト制御部と、
前記定期リクエスト制御部により取得された前記リプライ情報を
ブロードキャストで前記
複数のノードに発行する発行制御部と、
を備え
、
前記複数のノードのそれぞれは、
専用線を用いた前記リクエスト要求の登録の完了を通知する完了通知に基づいて前記リプライ情報を取得する取得部、
を備えるリクエスト制御システム。
【請求項2】
前記定期リクエスト制御部は、前記登録部によって登録された前記リクエスト要求を前記対象装置に定期的に繰り返して行い、前記リクエスト要求に対する前記対象装置からの前記リプライ情報を定期的に取得する請求項1に記載の
リクエスト制御システム。
【請求項3】
前記発行制御部は、前記定期リクエスト制御部により前記リプライ情報が取得されるたびに、前記リプライ情報を前記
複数のノードに発行する請求項1または請求項2に記載の
リクエスト制御システム。
【請求項4】
複数のノードが監視対象とする対象装置に対し、前記
複数のノードが定期的に前記対象装置に関する情報を読み出すためのリクエスト要求を登録し、
登録された前記リクエスト要求を前記対象装置に行い、前記リクエスト要求に対する前記対象装置からのリプライ情報を取得し、
取得された前記リプライ情報を
ブロードキャストで前記
複数のノードに発行する、
リクエスト制御方法。
【請求項5】
それぞれが専用線を用いたリクエスト要求の登録の完了を通知する完了通知に基づいてリプライ情報を取得する取得部を備える複数のノードとリクエスト制御装置とを含むリクエスト制御システムにおいて、
前記リクエスト制御装置のコンピュータを、
前記複数のノードが監視対象とする対象装置に対し、前記
複数のノードが定期的に前記対象装置に関する情報を読み出すための
前記リクエスト要求を登録する登録部、
前記登録部によって登録された前記リクエスト要求を前記対象装置に行い、前記リクエスト要求に対する前記対象装置からの
前記リプライ情報を取得する定期リクエスト制御部、
前記定期リクエスト制御部により取得された前記リプライ情報を
ブロードキャストで前記
複数のノードに発行する発行制御部、
として機能させるプログラム。
【発明の詳細な説明】
【技術分野】
【0001】
本発明は、リクエスト制御システム、リクエスト制御方法及びプログラムに関する。
【背景技術】
【0002】
特許文献1には、マルチノード構成における診断プロセッサから共有物へのハードウェアを使った技術が開示されている。この技術では、第1ノード及び第2ノードからのバスコマンド間を調整することが開示されている。
【0003】
特許文献2には、マルチノード構成における診断プロセッサから監視対象である対象装置(PSU(Power Supply Unit)など)へのハードウェアを使ったアクセス制御方式が開示されている。こうしたアクセス制御に関連する技術の一例を
図11を用いて説明する。
【0004】
図11には、2つのノードA、Bと共有PLD(Programmable Logic Device)と、PSUなどの対象装置とが示されている。
図11において、ノードAの診断プロセッサは、PLDで構築されたPar-NA内の共有部アクセス制御Windowへ、リクエスト要求とリクエスト要求の送信先とを登録するとともに、アクセス開始指示を行う。なお、ノードAの診断プロセッサは、共有部アクセス制御Windowに対してI2Cデバイス群を用いてアクセスする(ステップS001)。
【0005】
Par-NAは対象装置へのアクセス開始指示を契機に共有PLD内の調停部へ調停要求を行う。共有PLDはPar-NA、Par-NB間で調停を行いPar-NAに調停獲得を通知する。Par-NAは共有PLDにリクエスト要求を行い(ステップS002)、共有PLDは自身のレジスタまたはI2Cアクセスで対象装置へアクセスする(ステップS003)。
【0006】
共有PLDは自身のレジスタまたは共有物へのアクセスが完了すると、対象装置からのリプライ情報(ステータス情報やデータ)をPar-NAへ送信する(ステップS004)。Par-NAはリプライ情報を共有部アクセス制御Windowへ登録し、診断プロセッサへの完了通知を専用線でアサートする(ステップS005)。
【0007】
ノードAの診断プロセッサは完了通知を受けてI2CアクセスでPar-NA内の共有部アクセス制御Windowからリプライ情報を取得する。なお、他ノード(ノードB)の診断プロセッサも同様のアクセス方式で共有PLD内のレジスタまたは共有物へアクセスするため、競合しないよう共有PLD内の調停部にてリクエストの排他制御をしている。
【先行技術文献】
【特許文献】
【0008】
【文献】特開2019-160297号公報
【文献】特開2019-175003号公報
【発明の概要】
【発明が解決しようとする課題】
【0009】
上述した関連技術において、例えば、ノードAの診断プロセッサから対象装置への1回のアクセスにつき、診断プロセッサとPar-NAの間で2回のI2Cアクセスが行われ、共有PLDと対象装置の間で1回のI2Cアクセスが行われる。すなわち、ノードAの診断プロセッサから対象装置への1回のアクセスにつき計3回I2Cアクセスが行われることとなる。これは、ノードBの診断プロセッサにおいても同様である。
【0010】
診断プロセッサは対象装置へのアクセスを定期的に実行している。今後対象装置が増え、診断プロセッサから対象装置へのアクセスが増加する事が予想される中、レイテンシの短縮が不可欠になっているという背景がある。そのため、アクセス回数はなるべく少ない方がよい。
【0011】
また、関連技術では、共有PLDにおけるノード間(ノードA、B)の排他制御によるオーバーヘッドが大きい。例えば、2ノード構成の場合、競合すると最大1回のI2Cアクセス分の待ち合わせは発生する。4ノード構成の場合は最大3回のI2Cアクセス分の待ち合わせが発生する。こうした待ち合わせがレイテンシ増大の要因になっている。このように関連技術では、アクセス回数が増大し、それに伴いレイテンシが増大するという課題があった。
【0012】
そこでこの発明は、リクエスト制御システム、リクエスト制御方法及びプログラムを提供することを目的としている。
【課題を解決するための手段】
【0013】
本発明の一態様によれば、リクエスト制御システムは、複数のノードとリクエスト制御装置とを含むリクエスト制御システムであって、前記リクエスト制御装置は、前記複数のノードが監視対象とする対象装置に対し、前記複数のノードが定期的に前記対象装置に関する情報を読み出すためのリクエスト要求を登録する登録部と、前記登録部によって登録された前記リクエスト要求を前記対象装置に行い、前記リクエスト要求に対する前記対象装置からのリプライ情報を取得する定期リクエスト制御部と、前記定期リクエスト制御部により取得された前記リプライ情報をブロードキャストで前記複数のノードに発行する発行制御部と、を備え、前記複数のノードのそれぞれは、専用線を用いた前記リクエスト要求の登録の完了を通知する完了通知に基づいて前記リプライ情報を取得する取得部、を備える。
【0015】
本発明の別の態様によれば、リクエスト制御方法は、複数のノードが監視対象とする対象装置に対し、前記複数のノードが定期的に前記対象装置に関する情報を読み出すためのリクエスト要求を登録し、登録された前記リクエスト要求を前記対象装置に行い、前記リクエスト要求に対する前記対象装置からのリプライ情報を取得し、取得された前記リプライ情報をブロードキャストで前記複数のノードに発行する。
【0016】
本発明の別の態様によれば、プログラムは、それぞれが専用線を用いたリクエスト要求の登録の完了を通知する完了通知に基づいてリプライ情報を取得する取得部を備える複数のノードとリクエスト制御装置とを含むリクエスト制御システムにおいて、前記リクエスト制御装置のコンピュータを、前記複数のノードが監視対象とする対象装置に対し、前記複数のノードが定期的に前記対象装置に関する情報を読み出すための前記リクエスト要求を登録する登録部、前記登録部によって登録された前記リクエスト要求を前記対象装置に行い、前記リクエスト要求に対する前記対象装置からの前記リプライ情報を取得する定期リクエスト制御部、前記定期リクエスト制御部により取得された前記リプライ情報をブロードキャストで前記複数のノードに発行する発行制御部、として機能させる。
【発明の効果】
【0017】
本発明によれば、リクエスト制御装置、リクエスト制御システム、リクエスト制御方法及びプログラムを提供することができる。
【図面の簡単な説明】
【0018】
【
図1】本発明の一実施形態の構成を示すリクエスト制御システムの構成を示すブロック図である。
【
図2】n=2としたリクエスト制御システム100の構成例を示す図である。
【
図3】診断プロセッサ対象装置へ定期的に送信するリクエスト要求を行う場合に一度だけ実行される処理概要を示す図である。
【
図4】リクエスト要求に対するリプライ情報を診断プロセッサが取得する処理概要を示す図である。
【
図5】診断プロセッサの処理の流れを示すフローチャートである。
【
図6】Par-N1PLDの処理の流れを示すフローチャートである。
【
図7】Par-N1PLDの処理の流れを示すフローチャートである。
【
図8】定期リクエスト制御部の処理の流れを示すフローチャートである。
【
図9】Par-Nx発行制御部の処理の流れを示すフローチャートである。
【
図10】リクエスト制御装置の最小構成を示す図である。
【発明を実施するための形態】
【0019】
以下、本発明の一実施形態によるリクエスト制御装置を含むリクエスト制御システムを図面を参照して説明する。
図1は同実施形態によるリクエスト制御システム100の構成を示すブロック図である。
【0020】
リクエスト制御システム100は、複数(
図1ではn個:nは2以上の整数)のノード10-1、…、10-n、ノードと同じ数のI/F(インタフェース)20-1、…、20-n、リクエスト制御装置30、および対象装置40で構成される。
【0021】
ノード10-1、…、10-nは、それぞれI/F20-1、…、20-nを介してリクエスト制御装置30と接続する。リクエスト制御装置30は、対象装置40と接続する。ノード10-1、…、10-nは、後述する診断プロセッサ等を有し、対象装置40を監視対象とする。リクエスト制御装置30は、PLD(Programmable Logic Device)で構築される。リクエスト制御装置30は、ノード10-1、…、10-nに代わって対象装置40に一括してリクエスト要求を行い、リクエスト要求に対する対象装置40からのリプライ情報をノード10-1、…、10-nに送信する。リプライ情報は、対象装置40のステータスや、対象装置40により取得されたデータ(温度などの物理量)である。
【0022】
以下、ノード10-1、…、10-nや、リクエスト制御装置30などの詳細な構成について説明する。なお、説明を簡単にするために、n=2としたリクエスト制御システム100を例に説明する。
【0023】
図2は、n=2としたリクエスト制御システム100の構成例を示す図である。
図2において、リクエスト制御システム100は、2つのノード10a、10b、2つのI/F20a、20b、リクエスト制御装置30、および対象装置40で構成される。以下の説明において、ノード10a、10bを特に区別しない場合には、ノード10と表現することがある。I/F20a、20bを特に区別しない場合には、I/F20と表現することがある。
【0024】
ノード10の構成について説明する。ノード10a、10bは、ともに同じ構成のため、ノード10aを用いて説明する。ノード10aは、診断プロセッサ101a、I2Cデバイス群102a、およびPar-N1PLD103aで構成される。Par-N1PLD103aはPLDで構築される。診断プロセッサ101aは、対象装置40に送信するリクエスト要求を生成したり、対象装置40からのリプライ情報にもとづいて対象装置40の診断を行う。リクエスト要求には、定期的に必要となるリプライ情報を要求するために、定期的に送信する必要があるリクエスト要求がある。特に断らない限り、以下の説明におけるリクエスト要求は、定期的に送信する必要があるリクエスト要求とする。定期的に送信する必要がないリクエスト要求を非定期リクエスト要求と表現することがある。
【0025】
診断プロセッサ101aは、Par-N1PLD103aと通信するためのI2Cバス1011aを有する。診断プロセッサ101aとPar-N1PLD103aは、I2Cデバイス群102aを介して接続する。
【0026】
Par-N1PLD103aは、I2Cバス1031a、共有部アクセス制御Window1032a、診断プロセッサ見えレジスタ1033a、および一時格納レジスタ1034aで構成される。I2Cバス1031aは、診断プロセッサ101aと通信するためのバスである。共有部アクセス制御Window1032aは、診断プロセッサ101aから送信される、リクエスト要求と、リクエスト要求の送信先とを登録するとともに、アクセス開始指示を受信する。アクセス開始指示を受信すると、共有部アクセス制御Window1032aは、リクエスト制御装置30にリクエスト要求を送信する。
【0027】
一時格納レジスタ1034aは、リクエスト要求に応じてリクエスト制御装置30から発行されたリプライ情報を一時記憶する。リクエスト要求は複数種類であることが一般的であり、この場合、一時格納レジスタ1034aにはリプライ情報もリクエスト要求に応じた数だけ記憶される。診断プロセッサ見えレジスタ1033aは、リクエスト要求に応じた数だけリプライ情報が一時格納レジスタ1034aに記憶されると、それら全てのリプライ情報をコピーして記憶する。診断プロセッサ101は、診断プロセッサ見えレジスタ1033aにコピーされたリプライ情報を取得する。
【0028】
Par-N1PLD103aは、I/F20aによりリクエスト制御装置30と接続する。上記I/F20aは、PLD間のインタフェースとなるため、独自のプロトコルで通信しており、その通信速度はI2Cの通信レートに対して100倍以上高速となっている。
【0029】
リクエスト制御装置30は、調停部301、定期リクエスト登録部302、Par-Nx発行制御部303、定期リクエスト制御部304、およびI2Cバス305で構成される。調停部301は、各部から送信された調停要求により各部によるアクセスを調停する。調停要求は、Par-N1PLD103a、Par-N2PLD103b、Par-Nx発行制御部303、および定期リクエスト制御部304から行われる。
【0030】
定期リクエスト登録部302は、ノード10が監視対象とする対象装置40に対し、ノード10が定期的に対象装置40に関する情報を読み出すためのリクエスト要求を管理テーブルに登録する。定期リクエスト制御部304は、診断プロセッサとは独立して動作する。定期リクエスト制御部304は、送出情報一時格納レジスタ3041を有する。定期リクエスト制御部304は、定期リクエスト登録部302によって登録されたリクエスト要求に応じて、対象装置40にリクエスト要求を行う。ここでは、管理テーブルに登録されている順に対象装置40へリクエスト要求が行われる。定期リクエスト登録部302は登録部と呼ばれることもある。
【0031】
対象装置40にリクエスト要求を行う場合、定期リクエスト制御部304は、調停部301に調停要求を行い、調停を獲得すると管理テーブルからリクエスト情報を読み出し対象装置40へリクエスト要求を行う。定期リクエスト制御部304は、リクエスト要求に対する対象装置40からのリプライ情報を取得する。定期リクエスト制御部304は、取得したリプライ情報を送出情報一時格納レジスタ3041に記憶する。
【0032】
このように、定期リクエスト制御部304は、登録されたリクエスト要求を対象装置40に定期的に繰り返して行い、リクエスト要求に対する対象装置40からのリプライ情報を定期的に取得する。これにより、登録されたリクエスト要求に対する対象装置40からのリプライ情報を取得するので、複数のノードが個々にリプライ情報を取得する場合と比較して、対象装置40へのアクセス回数を抑制することができる。
【0033】
Par-Nx発行制御部303は、定期リクエスト制御部304により取得されたリプライ情報を複数のノード10にブロードキャストで発行する。Par-Nx発行制御部303は、送出情報格納レジスタ3031を有する。Par-Nx発行制御部303は、送出情報一時格納レジスタ3041に記憶されたリプライ情報を送出情報格納レジスタ3031に記憶する。こうして送出情報格納レジスタ3031が更新されると、Par-Nx発行制御部303は、調停部301へ調停要求を行う。
【0034】
Par-Nx発行制御部303は、調停を獲得したらPar-N1PLD103a、Par-N2PLD103bへブロードキャスト信号をアサートしつつ送出情報格納レジスタ3031に記憶されたリプライ情報を発行する。なお、
図2の構成では、Par-N1PLD103a、Par-N2PLD103bのみであるため、これら2つにリプライ情報が送信されるが、ブロードキャストで送信するので、全てのノード10にリプライ情報は送信される。Par-Nx発行制御部303は発行制御部と呼ばれることもある。このように、Par-Nx発行制御部303は、定期リクエスト制御部304によりリプライ情報が取得されるたびに、リプライ情報を複数10のノードに発行する。これにより、複数のノードが個々にリプライ情報を取得する場合と比較して、調停部301における調停のオーバーヘッドを低減することができ、その結果レイテンシ増大を抑制することができる。
【0035】
対象装置40は、監視対象となる装置であり、リクエスト要求に対してリプライ情報を応答するものであれば、どのようなものであってもよい。本実施形態では、対象装置40として、コンピュータに電源を供給するPSU(Power Supply Unit)、コンピュータを冷却するFAN、コンピュータの温度を測るTMP(温度センサ)を例示している。
【0036】
次に、リクエスト制御システム100の処理概要を、
図3、
図4を用いて説明する。
図3、
図4では、一例として、ノード10aの診断プロセッサ101aが対象装置40からリプライ情報を取得する場合の処理概要を示している。
【0037】
図3は、診断プロセッサ101aが対象装置40へ定期的に送信するリクエスト要求を行う場合に一度だけ実行される処理概要を示す図である。ノード10aの診断プロセッサ101aは、Par-N1PLD103a内にある共有部アクセス制御Window1032aに、リクエスト要求とリクエスト要求の送信先とをリクエスト制御装置30内の管理テーブルへ登録すること、およびアクセス開始指示を行う(ステップS101)。
【0038】
Par-N1PLD103aは対象装置40へのアクセス開始指示を契機にリクエスト制御装置30内の調停部301へ調停要求を行う。Par-N1PLD103aは、調停を獲得すると、リクエスト制御装置30にリクエスト要求を登録させる。リクエスト制御装置30は、定期リクエスト登録部302により、管理テーブルにリクエスト要求を登録する(ステップS102)。
【0039】
リクエスト制御装置30は、定期リクエスト登録部302による管理テーブルへの登録が完了すると、リプライ情報をPar-N1PLD103aへ返却する(ステップS103)。Par-N1PLD103aは、登録が完了したことを示すステータス情報を共有部アクセス制御Window1032aへ登録する。
【0040】
Par-N1PLD103aは、診断プロセッサ101aへの完了通知を専用線でアサートする(ステップS104)。診断プロセッサ101aは完了通知を受けてPar-N1PLD103a内の共有部アクセス制御Window1032aからステータス情報を取得する(ステップS105)。登録が正常に行われた場合、ステータス情報は、正常完了を示すNormal Endとなる。これにより、Par-N1PLD103aは、リクエスト要求が登録されたか否かを判定できる。
【0041】
上述したステップS101~105の処理は、対象装置40への定期的に送信するリクエスト要求の数だけ繰り返し実行される。また、ノード10bにおいても同様の処理が行われる。なお、ノード10bにおいて処理が行われると、管理テーブルに同じリクエスト要求が登録される。このように、ノード10は、定期リクエスト登録部302にリクエスト要求を一度登録させることにより、リクエスト要求に対する対象装置40からのリプライ情報を定期的に取得することができる。これにより、定期的に繰り返して調停要求を行う必要がないため、調停部301における調停のオーバーヘッドを低減することができ、その結果レイテンシ増大を抑制することができる。
【0042】
図4は、上記ステップS101~105の処理により登録されたリクエスト要求に対するリプライ情報を診断プロセッサ101aが取得する処理概要を示す図である。なお、対象装置からのリクエスト要求に対するリプライ情報の取得はハードウェア主導(リクエスト制御装置30)で実行される。このとき、リクエスト制御装置30は、診断プロセッサ101a、101bとは独立して動作する。
【0043】
リクエスト制御装置30内の定期リクエスト制御部304はリクエスト制御装置30内にある調停部301に調停要求を行い(ステップS201)、調停を獲得すると管理テーブルからリクエスト情報を読み出し対象の対象装置40へリクエスト要求を行う(ステップS202)。対象装置40から取得されたリプライ情報は送出情報一時格納レジスタ3041に記憶される(ステップS203)。
【0044】
リクエスト制御装置30内の定期リクエスト制御部304は、管理テーブルに登録されている全てのリクエスト要求に対するリプライ情報の取得が完了すると、送出情報一時格納レジスタ3041からPar-Nx発行制御部303内の送出情報格納レジスタ3031へリプライ情報をコピーする(ステップS204)。
【0045】
リクエスト制御装置30内のPar-Nx発行制御部303は、自身の送出情報格納レジスタ3031が更新されると、リクエスト制御装置30内にある調停部301へ調停要求を行う。Par-Nx発行制御部303は、調停を獲得すると全Par-N1PLD103aへブロードキャスト信号をアサートしつつ送出情報格納レジスタ3031に記憶されたリプライ情報を発行する(ステップS205)。
【0046】
Par-N1PLD103aは、自身にある一時格納レジスタ1034aにリプライ情報を記憶し、全リクエスト要求に対するリプライ情報の取得が完了すると、一斉に診断プロセッサ見えレジスタ1022aにコピーする(ステップS206)。診断プロセッサ101aは、Par-N1PLD103aの診断プロセッサ見えレジスタ1033aからリプライ情報を取得する(ステップS207)。なお、ノード10bにおいても、ステップS206、207と同様の処理が行われる。
【0047】
このようにすることで、まずノード10とリクエスト制御装置30とのアクセス回数を抑制できる。また、リクエスト制御装置30と対象装置40のとのアクセス回数を抑制できる。これにより、レイテンシ増大も抑制することができる。
【0048】
次に、フローチャートを用いて説明する。
図5は、診断プロセッサ101a、および診断プロセッサ101bの処理の流れを示すフローチャートである。上述したように、ノード10aとノード10bは同じ構成のため、
図5の説明では、診断プロセッサ101aを用いて説明する。また、
図5以降の図では、共有部アクセス制御Windowを、省略して「共有部アクセス制御」と記載している。
【0049】
図5のステップS1-1~1-12は、
図3で説明した、診断プロセッサ101aが対象装置40へ定期的に送信するリクエスト要求を行う場合に一度だけ実行される処理の詳細を示している。まずステップS1-1~1-12について説明する。
【0050】
診断プロセッサ101aは、対象装置40へアクセスをする際には自身の管理テーブル登録完了フラグを参照し、管理テーブル登録完了フラグが1か否かを判定する(ステップS1-1)。管理テーブル登録完了フラグが0の時はリクエスト制御装置30内にある管理テーブルへの登録がないことを示し、1の時はリクエスト制御装置30内にある管理テーブルへの登録がないことを示す。
【0051】
管理テーブル登録完了フラグが0の場合には(ステップS1-1:NO)、診断プロセッサ101aは、Par-N1PLD103a内にある共有部アクセス制御Window1032aにリクエスト要求とリクエスト要求の送信先とをリクエスト制御装置30内の管理テーブルへ登録すること、およびリクエスト制御装置30へのアクセス開始指示を行う(ステップS1-2)。
【0052】
診断プロセッサ101aは、Par-N1PLD103aからの登録の完了割り込みがアサートされるのを待つ(ステップS1-3)。アサートされると(ステップS1-3:YES)、診断プロセッサ101aは、Par-N1PLD103a内にある共有部アクセス制御Window1032aから指示した処理に対するステータス情報を取得する(ステップS1-4)。
【0053】
診断プロセッサ101aは、ステータス情報が、正常完了を示すNormal Endか否かを判定する(ステップS1-5)。ステータス情報がNormal Endではない場合には(ステップS1-5:NO)、診断プロセッサ101aは、処理を終了する。ステータス情報がNormal Endの場合には(ステップS1-5:YES)、診断プロセッサ101aは、全てのリクエスト要求の管理テーブルへの登録が完了したか否かを判定する(ステップS1-6)。全てのリクエスト要求の管理テーブルへの登録が完了していない場合には(ステップS1-6:NO)、診断プロセッサ101aは、ステップS1-2に戻る。
【0054】
全てのリクエスト要求の管理テーブルへの登録が完了した場合には(ステップS1-6:YES)、診断プロセッサ101aは、Par-N1PLD103a内にある共有部アクセス制御Window1032aに指示を行う(ステップS1-7)。ここでの指示は、定期リクエスト制御部304へのアクセス開始指示と、定期リクエスト制御部304へアクセス要求を対象装置40に行わせる指示(定期リクエスト開始指示)である。
【0055】
診断プロセッサ101aは、Par-N1PLD103aからの、定期リクエスト制御部304への指示の完了割り込みがアサートされるのを待つ(ステップS1-8)。アサートされると(ステップS1-8:YES)、診断プロセッサ101aは、Par-N1PLD103a内にある共有部アクセス制御Window1032aから指示した処理に対するステータス情報を取得する(ステップS1-9)。
【0056】
診断プロセッサ101aは、ステータス情報が、正常完了を示すNormal Endか否かを判定する(ステップS1-10)。ステータス情報がNormal Endではない場合には(ステップS1-10:NO)、診断プロセッサ101aは、処理を終了する。ステータス情報がNormal Endの場合には(ステップS1-10:YES)、診断プロセッサ101aは、管理テーブル登録完了フラグを1にする(ステップS1-11)。これは、管理テーブルへの登録が正常完了し、定期リクエスト制御部304へアクセス要求を対象装置40に行わせる指示も正常完了したためである。
【0057】
次いで、診断プロセッサ101aは、リクエスト制御装置30が管理テーブルに登録されている全てのリクエストが発行される時間よりも十分大きい一定時間(例えば1s)を待ち合わせたのち、処理を終了する(ステップS1-12)。
【0058】
次に、上述したステップS1-1で否定判定された場合の処理について説明する。上述したステップS1-1で否定判定された場合のステップS1-14~1-16は、非定期リクエスト要求に関する処理である。
【0059】
管理テーブル登録完了フラグが1の場合には(ステップS1-1:YES)、診断プロセッサ101aは、対象装置40へ定期的に送信する必要があるリクエスト要求に関する処理は完了している状態である。そのため、診断プロセッサ101aは、リプライ情報の取得をするか、非定期リクエスト要求を行う。
【0060】
リプライ情報の取得ではない場合には(ステップS1-13:NO)、診断プロセッサ101aは、非定期リクエスト要求を行う(ステップS1-14)。非定期リクエスト要求を行う場合、診断プロセッサ101aは、Par-N1PLD103a内にある共有部アクセス制御Window1032aにアクセス指示情報の登録およびリクエスト制御装置30へのアクセス開始指示を行う。上記アクセス指示情報とは、非定期リクエスト要求の指示を示す情報である。
【0061】
診断プロセッサ101aは、Par-N1PLD103aからの、定期リクエスト制御部304への指示の完了割り込みがアサートされるのを待つ(ステップS1-15)。アサートされると(ステップS1-15:YES)、診断プロセッサ101aは、Par-N1PLD103a内にある共有部アクセス制御Window1032aから指示した要求に対する応答を取得して(ステップS1-16)、処理を終了する。ここでの応答は、要求に応じたステータス情報や要求に応じた各種データなどである。
【0062】
ステップS1-13において、リプライ情報の取得である場合には(ステップS1-13:YES)、診断プロセッサ101aは、診断プロセッサ見えレジスタ1033aからリプライ情報を取得し(ステップS1-17)、処理を終了する。なお、リプライ情報の取得であるか否かの判定は、診断プロセッサ101aへの完了通知が専用線でアサートされたか否かにより行うことができる。
【0063】
図6は、診断プロセッサ101aからアクセスされたPar-N1PLD103aの処理の流れを示すフローチャートである。上述したように、Par-N1PLD103aとPar-N2PLD103bは同じ構成のため、
図6の説明では、診断プロセッサ101aとPar-N1PLD103aとを用いて説明する。
【0064】
Par-N1PLD103aは、診断プロセッサ101aからアクセスされた場合に、アクセス内容が対象装置40へのアクセス開始指示であるか否かを判定する(ステップS2-1)。Par-N1PLD103aは、アクセス内容が対象装置40へのアクセス開始指示ではない場合には(ステップS2-1:NO)、Par-N1PLD103aのレジスタへのアクセスと判定し、診断プロセッサ101aが対象とするアドレスのレジスタ値の更新、またはアドレスのレジスタ値を返却し(ステップS2-2)、処理を終了する。
【0065】
上記ステップS2-1において、Par-N1PLD103aは、アクセス内容が対象装置40へのアクセス開始指示である場合には(ステップS2-1:YES)、リクエスト制御装置30の調停部301に調停要求を行う(ステップS2-3)。Par-N1PLD103aは、調停を獲得すると(ステップS2-4:YES)、共有部アクセス制御Window1032a内に記憶されている対象装置40に送信するリクエスト要求を、I/F20aを介してリクエスト制御装置30に送信して(ステップS2-5)、処理を終了する。
【0066】
図7は、リクエスト制御装置30からアクセスされたPar-N1PLD103aの処理の流れを示すフローチャートである。上述したように、Par-N1PLD103aとPar-N2PLD103bは同じ構成のため、
図7の説明では、診断プロセッサ101aとPar-N1PLD103aとを用いて説明する。
【0067】
Par-N1PLD103aは、リクエスト制御装置30からブロードキャスト信号がアサートされているか否かを判定する(ステップS3-1)。アサートされていない場合には(ステップS3-1:NO)、Par-N1PLD103aは、非定期リクエスト要求に対するリプライ情報と判定する。そして、Par-N1PLD103aは、リプライ情報がステータスの場合にはステータスを取得し、リプライ情報がデータの場合にはデータを取得する(ステップS3-2)。取得されたステータス情報またはデータは、共有部アクセス制御Window1032a内のレジスタに記憶される。
【0068】
Par-N1PLD103aは、共有部アクセス制御Window1032a内のレジスタに、ステータス情報またはデータの記憶を完了すると、診断プロセッサ101aに完了割り込みを一定時間(例えば1ms)アサートし(ステップS3-3)、処理を終了する。
【0069】
ステップS3-1において、アサートされている場合には(ステップS3-1:YES)、Par-N1PLD103aは、定期的に送信するリクエスト要求に対するリプライ情報と判定し、一時格納レジスタ1034にリプライ情報を記憶する(ステップS3-4)。Par-N1PLD103aは、全てのリプライ情報を記憶すると、診断プロセッサ見えレジスタ1033aにリプライ情報をコピーして(ステップS3-5)、処理を終了する。
【0070】
図8は、定期リクエスト制御部304の処理の流れを示すフローチャートである。定期リクエスト制御部304は、管理テーブルにおいて、定期リクエスト制御部304が読み出すアドレスを示す読み出しポインタをクリアする(ステップS4-1)。定期リクエスト制御部304は、定期リクエスト開始指示があったか否かを判定する(ステップS4-2)。定期リクエスト開始指示がない場合には(ステップS4-2)、定期リクエスト制御部304は、ステップS4-1に戻る。
【0071】
定期リクエスト開始指示があった場合には(ステップS4-2)、定期リクエスト制御部304は、リクエスト制御装置30の調停部301に調停要求を行う(ステップS2-3)。定期リクエスト制御部304は、調停を獲得すると(ステップS4-4:YES)、管理テーブルから読み出したリクエスト要求を対象装置40に送信する(ステップS4-5)。定期リクエスト制御部304は、対象装置40から取得したリプライ情報を送出情報一時格納レジスタ3041に記憶する(ステップS4-6)。定期リクエスト制御部304は、読み出しポインタを1だけ増分する(ステップS4-7)。
【0072】
定期リクエスト制御部304は、有効フラグは0か否かを判定する(ステップS4-8)。有効フラグとは、現在の読み出しポインタが指すアドレス以降にリクエスト要求が記憶されているか否かを示すフラグである。現在の読み出しポインタが指すアドレス以降にリクエスト要求が登録されている場合、有効フラグは1となり、現在の読み出しポインタが指すアドレス以降にリクエスト要求が登録されていない場合、有効フラグは0となる。
【0073】
有効フラグが1の場合には(ステップS4-8:NO)、登録されているリクエスト要求がまだあるため、定期リクエスト制御部304は、ステップS4-3に戻る。有効フラグが0の場合には(ステップS4-8:YES)、登録されているリクエスト要求がないため、定期リクエスト制御部304は、送出情報一時格納レジスタ3041に記憶されたリプライ情報を送出情報一時格納レジスタにコピーして(ステップS4-9)、ステップS4-1に戻る。したがって、定期リクエスト制御部304は、定期リクエストの開始指示があった以降は、
図8に示される処理を繰り返すこととなる。
【0074】
図9は、Par-Nx発行制御部303の処理の流れを示すフローチャートである。Par-Nx発行制御部303は、送出情報格納レジスタ3031が更新されたか否かを判定する(ステップS5-1)。Par-Nx発行制御部303はリクエスト制御装置30内にある調停部301に調停要求を行う(ステップS5-2)。調停を獲得すると(ステップS5-3:YES)、Par-Nx発行制御部303は、ブロードキャスト信号をアサートしつつ送出情報格納レジスタ3031に記憶されたリプライ情報を発行し(ステップS5-4)、処理を終了する。ここでは、全てのノード10にリプライ情報は発行される。
【0075】
図10は本実施形態によるリクエスト制御装置900の最小構成を示す図である。本実施形態によるリクエスト制御装置900は、登録部1001、定期リクエスト制御部1002、および発行制御部1003を備えればよい。
登録部1001は、ノードが監視対象とする対象装置に対し、ノードが定期的に対象装置に関する情報を読み出すためのリクエスト要求を登録する。
定期リクエスト制御部1002は、登録部1001によって登録されたリクエスト要求を対象装置に行い、リクエスト要求に対する対象装置からのリプライ情報を取得する。
発行制御部は、定期リクエスト制御部1002により取得されたリプライ情報をノードに発行する。
【0076】
このように、本実施形態によれば、複数のノードに代わり、登録されたリクエスト要求を対象装置に行い、リクエスト要求に対する対象装置からのリプライ情報を取得するので、複数のノードが個々にリプライ情報を取得する場合と比較して、対象装置へのアクセス回数を抑制することができる。
【0077】
なお、特許文献1に開示された構成において、2ノードで構成する場合にはI2Cポートが3つ必要となり、4ノードで構成する場合にはI2Cポートが5つ必要になる。安価なPLDでは専用IPとして用意されているI2Cポートは2つのものが多い。そのため、専用IPを使用せずユーザ側でI2C回路を組み込む場合、アナログ的な部分で難易度が高いため、価格、品質、拡張性といった部分で課題がある。一方、本実施形態では、専用IPが2つある安価なPLDを使って実現可能である。
【0078】
上述した実施形態では、ノード10は複数設けられているが、1つであってもよい。ノードが1つであっても、ノード10は、定期リクエスト登録部302にリクエスト要求を一度登録させることにより、リクエスト要求に対する対象装置40からのリプライ情報を定期的に取得することができる。これにより、定期的に繰り返して調停要求を行う必要がないため、調停部301における調停のオーバーヘッドを低減することができ、その結果レイテンシ増大を抑制することができる。
【0079】
上述のリクエスト制御装置は内部に、コンピュータシステムを有している。そして、上述した処理の過程は、プログラムの形式でコンピュータ読み取り可能な記録媒体に記憶されており、このプログラムをコンピュータが読み出して実行することによって、上記処理が行われる。ここでコンピュータ読み取り可能な記録媒体とは、磁気ディスク、光磁気ディスク、CD-ROM、DVD-ROM、半導体メモリ等をいう。また、このコンピュータプログラムを通信回線によってコンピュータに配信し、この配信を受けたコンピュータが当該プログラムを実行するようにしても良い。
【0080】
また、上記プログラムは、このプログラムを記憶装置等に格納したコンピュータシステムから、伝送媒体を介して、あるいは、伝送媒体中の伝送波により他のコンピュータシステムに伝送されてもよい。ここで、プログラムを伝送する「伝送媒体」は、インターネット等のネットワーク(通信網)や電話回線等の通信回線(通信線)のように情報を伝送する機能を有する媒体のことをいう。また、上記プログラムは、前述した機能の一部を実現するためのものであっても良い。さらに、前述した機能をコンピュータシステムにすでに記録されているプログラムとの組み合わせで実現できるもの、いわゆる差分ファイル(差分プログラム)であっても良い。
【符号の説明】
【0081】
10、10a、10b ノード
30 リクエスト制御装置
40 対象装置
100 リクエスト制御システム
101、101a、101b 診断プロセッサ
102a デバイス群
301 調停部
302 定期リクエスト登録部
303 発行制御部
304 定期リクエスト制御部
900 リクエスト制御装置
1000 リクエスト制御システム
1001 登録部
1002 定期リクエスト制御部
1003 発行制御部
1011a、1031a I2Cバス
1022a 診断プロセッサ見えレジスタ
1032a 共有部アクセス制御Window
1033a 診断プロセッサ見えレジスタ
1034、1034a 一時格納レジスタ
3031 送出情報格納レジスタ
3041 送出情報一時格納レジスタ