(57)【要約】  機能ブロック毎に状態制御装置を設ける。機能ブロック（Ｂｉ）に対応する状態制御装置（Ｃｉ）は、機能ブロック（Ｂｉ）の状態を示す状態（λｉ）を機能ブロック（Ｂｉ）から取得すると、機能ブロック（Ｂｉ）の性能に応じた上または下に凸である評価関数（ｆｉ）に基づいて、値（Ｕｉ）及び値（Ｖｉ）を求め、状態制御装置（Ｃｊ）に前記値（Ｖｉ）を送信する。前記値（Ｖｉ）と同様にして状態制御装置（Ｃｊ）が求めた値（Ｗｊ）を状態制御装置（Ｃｊ）から受信すると、前記値（Ｕｉ）及び前記値（Ｗｊ）に応じて機能ブロック（Ｂｉ）を制御する。
2013146395.tif 000002
【特許請求の範囲】
【請求項１】
システムを構成するｎ個（ｎは２以上の自然数）の機能ブロックそれぞれに対応して設けられる状態制御装置であって、ｉ、ｊが１≦ｉ、ｊ≦ｎ、ｉ≠ｊである任意の自然数であるとき、機能ブロックＢｉに対応する状態制御装置Ｃｉは、  機能ブロックＢｉの状態を示す状態λｉを機能ブロックＢｉから取得する手段と、  機能ブロックＢｉの性能に応じて予め定められた関数ｆｉを機能ブロックＢｉの評価関数とするとき、評価関数ｆｉに基づいてＵｉ及びＶｉを求める手段と、  状態制御装置ＣｊにＶｉを送信する手段と、  状態制御装置Ｃｊに対応する機能ブロックＢｊの性能に応じて予め定められた関数ｆｊを機能ブロックＢｊの評価関数とするとき、評価関数ｆｊに基づいて求めたＷｊを、状態制御装置Ｃｊから受信する手段と、  Ｕｉ及びＷｊに応じて、状態λｉの変動分と、状態λｊの変動分の和がゼロになるように機能ブロックＢｉを制御する制御手段とを備えることを特徴とする状態制御装置。
【請求項２】
前記評価関数ｆｉ、ｆｊ、状態λｉ、λｊをそれぞれ総称して評価関数ｆ、状態λと呼ぶとき、評価関数ｆは、状態λを横軸とし、関数ｆの値を縦軸として描いた曲線が上または下に凸であるような関数であることを特徴とする請求項１に記載の状態制御装置。
【請求項３】
Ｕｉは評価関数ｆｉと横軸の交点であるゼロクロス点の横軸座標λ０，ｉであり、  Ｖｉは前記ゼロクロス点での評価関数ｆｉの傾きｇ０、ｉであり、  評価関数ｆｊにおいて傾きがｇ０，ｉと一致する点の横軸座標をｚｉｊとするとき、Ｗｊはλｊ−ｚｉｊであり、  制御手段はＳｉ＝Σ（λｊ−ｚｉｊ）−λ０，ｉとゼロとの比較結果に応じて機能ブロックＢｉを起動或いは停止することを特徴とする請求項１及び請求項２のいずれかに記載の状態制御装置。
【請求項４】
Ｕｉ及びＶｉはｄｆｉ／ｄλｉであり、  Ｗｊはｄｆｊ／ｄλｊであり、  制御手段はｄλｉ／ｄｔ＝Ｋ１（ｄｆｉ／ｄλｉ−ｄｆｊ／ｄλｊ）に従って機能ブロックＢｉを制御することを特徴とする請求項１及び請求項２のいずれかに記載の状態制御装置。
【請求項５】
複数の他の状態制御装置Ｃｊ１、Ｃｊ２、…、Ｃｊｍ（ｊ１、ｊ２、…ｊｍはｉ以外の自然数、２≦ｍ≦ｎ）それぞれに対してＶｉを送信し、かつ、  前記複数の他機能ブロックＣｊ１、Ｃｊ２、…、ＣｊｍそれぞれからＷｊ１、Ｗｊ２、…、Ｗｊｍを受信することを特徴とする請求項１乃至請求項４のいずれかに記載の状態制御装置。
【請求項６】
制御手段は、Ｕｉ及びＷｊ１に応じて定められる一の方程式に基づく制御、Ｕｉ及びＷｊ２に応じて定められる一の方程式に基づく制御、…、Ｕｉ及びＷｊｍに応じて定められる一の方程式に基づく制御を、機能ブロックＢｉに対して順不同に逐次行なうことを特徴とする請求項５に記載の状態制御装置。
【請求項７】
制御手段は、Ｕｉ及びＷｊ１、Ｗｊ２、…、Ｗｊｍに応じて定められる一の方程式に従って機能ブロックＢｉを制御することを特徴とする請求項５に記載の状態制御装置。
【請求項８】
評価関数は対応する機能ブロックの効率に関することを特徴とする請求項１乃至請求項７のいずれかに記載の状態制御装置。
【請求項９】
複数の評価関数の中から予め定められた条件に応じて選択された一の評価関数に基づいて機能ブロックを制御することを特徴とする請求項１乃至請求項８のいずれかに記載の状態制御装置。
【請求項１０】
複数の評価関数の中から予め定められた条件に応じて一の評価関数を選択する評価関数切替手段を更に備えることを特徴とする請求項１乃至請求項８のいずれかに記載の状態制御装置。
【請求項１１】
評価関数の値に対応する値を測定する手段と、測定値に基づいて評価関数を修正する手段とを更に備える請求項１乃至請求項１０のいずれかに記載の状態制御装置。
【請求項１２】
前記システムは伝達遅延量を求める際の起点となるノードを備え、  機能ブロックＢｉの性能、及び、前記起点ノードと機能ブロックＢｉとの間で行なうデータ通信にて生じる伝送遅延量に応じて定められた評価関数に基づいて機能ブロックＢｉを制御することを特徴とする請求項１乃至請求項１１のいずれかに記載の状態制御装置。
【請求項１３】
前記起点ノードは、前記ネットワークシステム内に設けられた入出力端末であることを特徴とする請求項１２に記載の状態制御装置。
【請求項１４】
機能ブロックＢｉはそれぞれコンピュータであり、λはそのコンピュータに割り当てられた仕事量である請求項１乃至請求項１３のいずれかに記載の状態制御装置。
【請求項１５】
機能ブロックＢｉはそれぞれコンピュータであり、λはそのコンピュータの消費電力である請求項１乃至請求項１３のいずれかに記載の状態制御装置。
【請求項１６】
機能ブロックＢｉはそれぞれ記憶装置であり、λはその記憶装置に記憶されているデータ量である請求項１乃至請求項１３のいずれかに記載の状態制御装置。
【請求項１７】
機能ブロックＢｉはそれぞれ発電機であり、λはその発電機の発電量である請求項１乃至請求項１３のいずれかに記載の状態制御装置。
【請求項１８】
機能ブロックＢｉはそれぞれアクチュエータであり、λはそのアクチュエータが発生する力である請求項１乃至請求項１３のいずれかに記載の状態制御装置。
【請求項１９】
請求項１乃至請求項１８のいずれかに記載の状態制御装置を備える機能ブロック。
【請求項２０】
請求項１９に記載の機能ブロックをノードとして備えるネットワークシステム。
【請求項２１】
システムを構成するｎ個（ｎは２以上の自然数）の機能ブロックそれぞれに対応する状態制御装置を用いて各機能ブロックを制御する方法であって、ｉ、ｊが１≦ｉ、ｊ≦ｎ、ｉ≠ｊである任意の自然数であるとき、機能ブロックＢｉに対応する状態制御装置Ｃｉが、  機能ブロックＢｉの状態を示す状態λｉを機能ブロックＢｉから取得する段階と、  機能ブロックＢｉの性能に応じて予め定められた関数ｆｉを機能ブロックＢｉの評価関数とするとき、評価関数ｆｉに基づいてＵｉ及びＶｉを求める段階と、  状態制御装置ＣｊにＶｉを送信する段階と、  状態制御装置Ｃｊに対応する機能ブロックＢｊの性能に応じて予め定められた関数ｆｊを機能ブロックＢｊの評価関数とするとき、評価関数ｆｊに基づいて求めたＷｊを、状態制御装置Ｃｊから受信する段階と、  Ｕｉ及びＷｊに応じて、状態λｉの変動分と、状態λｊの変動分の和がゼロになるように機能ブロックＢｉを制御する制御段階とを含むことを特徴とする制御方法。
【請求項２２】
システムを構成するｎ個（ｎは２以上の自然数）の機能ブロックそれぞれに対応するコンピュータを用いて各機能ブロックを制御するためのプログラムであって、ｉ、ｊが１≦ｉ、ｊ≦ｎ、ｉ≠ｊである任意の自然数であるとき、機能ブロックＢｉに対応するコンピュータＣｉに、  機能ブロックＢｉの状態を示す状態λｉを機能ブロックＢｉから取得する手順と、  機能ブロックＢｉの性能に応じて予め定められた関数ｆｉを機能ブロックＢｉの評価関数とするとき、評価関数ｆｉに基づいてＵｉ及びＶｉを求める手順と、  状態制御装置ＣｊにＶｉを送信する手順と、  状態制御装置Ｃｊに対応する機能ブロックＢｊの性能に応じて予め定められた関数ｆｊを機能ブロックＢｊの評価関数とするとき、評価関数ｆｊに基づいて求めたＷｊを、状態制御装置Ｃｊから受信する手順と、  Ｕｉ及びＷｊに応じて、状態λｉの変動分と、状態λｊの変動分の和がゼロになるように機能ブロックＢｉを制御する制御手順とを実行させるためのプログラム。
【発明の詳細な説明】
【技術分野】
【０００１】  本発明は、複数の機能ブロックを有し、それらの機能ブロックを自律分散適応的に統合して動作させるシステムの制御方法に関する。
【背景技術】
【０００２】  現在、システムの大規模化、あるいはシステム化されていなかったものが突如大規模システム化するという現象が様々な領域で進展している。前者の代表的なものとしては、クラウドと呼ばれる技術に関係したデータセンター、ネットワークなどのＩＴ分野であり、これらは年々規模が大きくなっている。また、後者としては、電力、エネルギー網、都市といったインフラ領域であり、スマートグリット、スマートシティといった大規模システムの案件としてとして突如制御対象になりつつある。したがって、大規模システムをいかに制御していくかは今後非常に重要な課題になることが予想される。  それに加え、昨今のエネルギーコンシャスな社会情勢は、無駄に起動しているものを停止するなどして、電力を無駄にしない制御を求めている。これはＩＴ分野、インフラ領域問わずの傾向である。一般的には、無駄な起動を行っている制御体を停止するなどの制御が有効である。  電力網に関しては、現時点ではその制御される発電所が限られているものの、効率的に電気を生み出すために、どの発電所を起動し、どの発電所を停止するかという問題が古くから検討されてきている。これは一種の負荷分散の問題であり、以下では起動停止問題と呼ぶものとする。起動停止問題は、発電所の起動と停止だけの問題ではなく、発電所の起動と停止を決めた後、起動している発電所に負荷を最適に配置するという問題も内包している。起動停止と負荷の最適配備の総合的問題である。以下、本明細書において「起動停止問題」とは、起動と停止の問題、及び、負荷の配置の問題の両方を含むものとする。これまでの解法としては、確定的な数理計画モデルとして、シナリオを想定してオフラインでスケジューリングする方法が取られている。  今後、さらに省エネルギー社会が志向されると、従来の電力網に無数の太陽エネルギーが接続されてくることが予想される。太陽光エネルギーは自然界の状態により変動するため、これまでのようにオフラインでスケジューリングしておいて、発電所を運用する方式は困難になることが予想される。これは、制御対象が大多数になり、かつ、想定外の外乱に対応しないといけないことを意味している。想定外の外乱に対応するには、オフラインのスケジューリングでは無理で、今後は、無数の（大規模な）電力ノードに関して、リアルタイムで起動停止問題を解く方法が今後は望まれると考えられる。しかしながら、リアルタイムで起動停止問題を解く方法は非常に困難である。また、大多数の制御体をどう扱っていくかという問題も存在する。  この起動停止問題はＩＴ分野にも同じように存在する。ＩＴ分野におけるシステムで実施される制御としては、計算リソース、ネットワークの負荷分散、ストレージの配置分散などの制御が上げられる。起動停止問題は様々な分野に見られる問題であり、起動、停止され、または、負荷を配置される個々の制御対象の名称は、機能ブロック、要素、リソース、ノード等、その分野によって様々である。本明細書では、これら制御対象を主に機能ブロックと呼ぶものとするが、前後の文脈によっては他の名称を用いる場合もあるので注意されたい。  従来の負荷分散方式について、複数サーバから構成されるデータセンターにおける、計算リソースの負荷分散制御を例に挙げて説明する。従来の制御方式の基本的な発想は、「システムの内部状態をバランスさせる」という素朴なものに帰結される。このような発想の場合、一様なシステム（同一サーバが複数）の場合には、制御方針は明らかであるが、異機種混合型システムになると、どんな指標に基づいてバランスさせるべきなのかが明らかではない。  例えば、同一性能のサーバの場合には、各サーバのＣＰＵ使用率をバランスさせれば良いということが知られている一方で、性能が異なるサーバの場合には、性能に応じたＣＰＵ使用率のバランス方法が自明ではない。従来よく使われる指針である待ち行列理論で得られる結果は、確率論に基づく指針であり、どのような手段を用いて確率的な定常状態にシステムを導くか自体は、何も教えてくれない。  これは何を意味するかというと、レスポンスやスループットと言った満たすべき用件を最終的には満たすことができるかもしれないが、途中のプロセスや最終的に使用されているリソースの状況に関しては何の保証、制約もないことを意味している。それは即ち、エネルギー的には非常に非効率な状態になっていてもとりあえず、性能を満たすという制御になっているということである。  このような制御では、システムが大規模になればなるほど、このような非効率は大きくなっていき、大きな問題となることが予想される。的確に停止すべきサーバは停止し、起動すべきサーバは起動するということがここでも重要で、サーバの負荷分散なども起動停止問題の１種と考えてよい。この起動停止問題は、ストレージの配置制御など多くの制御問題にも絡んできる問題である。  本発明に関連する発明が記載された文献として、特許文献１がある。特許文献１には、複数の発電装置を分散配置してなる電力系統において、複数の発電装置が各別に、電力系統内の需給バランスと複数の発電装置の発電効率に関する情報の内、自己の発電装置と他の発電装置の一部から得られる局所情報に基づいて、自律的に自己の発電装置の出力を制御することが記載されている。
【先行技術文献】
【特許文献】
【０００３】
【特許文献１】特開２００２−１６５３６５号公報
【発明の概要】
【発明が解決しようとする課題】
【０００４】  上述したようにインフラ領域、ＩＴ領域などの領域で起動停止問題が存在し、今後、制御する対象が非常に大規模になることが予想される。また、想定外の外乱が普通にシステムに入ってくる状態が想定される。そのような状況では、リアルタイムに起動停止問題を解くことが重要になるが、その方法は現時点では存在しない。また、大多数の制御体を制御しなければならないという問題の解法も自明ではない。  本発明はこうした状況に鑑みてなされたものであり、本発明が解決しようとする課題は、複数の機能ブロックからなるシステムでの起動停止問題をリアルタイムに解く手法を提供することである。本発明の手法は大多数の制御体を扱う場合であっても適用可能であり、今後有力なシステムの制御方法になると考えられる。
【課題を解決するための手段】
【０００５】  上述の課題を解決するため、本発明は、その一態様として、システムを構成するｎ個（ｎは２以上の自然数）の機能ブロックそれぞれに対応して設けられる状態制御装置であって、ｉ、ｊが１≦ｉ、ｊ≦ｎ、ｉ≠ｊである任意の自然数であるとき、機能ブロックＢｉに対応する状態制御装置Ｃｉは、機能ブロックＢｉの状態を示す状態λｉを機能ブロックＢｉから取得する手段と、制御対象となる機能ブロックＢｉの性能に応じて予め定められた関数ｆｉであって、状態λｉを横軸とし、関数ｆｉの値を縦軸として描いた曲線が上または下に凸であるような関数ｆｉを機能ブロックＢｉの評価関数とするとき、評価関数ｆｉに基づいてＵｉ及びＶｉを求める手段と、状態制御装置ＣｊにＶｉを送信する手段と、状態制御装置Ｃｊに対応する機能ブロックＢｊの性能に応じて予め定められた関数ｆｊであって、機能ブロックＢｊの状態λｊを横軸とし、関数ｆｊの値を縦軸として描いた曲線が上または下に凸であるような関数ｆｊを機能ブロックＢｊの評価関数とするとき、評価関数ｆｊに基づいて求めたＷｊを、状態制御装置Ｃｊから受信する手段と、Ｕｉ及びＷｊに応じて機能ブロックＢｉを制御する制御手段とを備えることを特徴とする状態制御装置を提供する。  また、本発明は、他の態様として、システムを構成するｎ個（ｎは２以上の自然数）の機能ブロックそれぞれに対応する状態制御装置を用いて各機能ブロックを制御する方法であって、ｉ、ｊが１≦ｉ、ｊ≦ｎ、ｉ≠ｊである任意の自然数であるとき、機能ブロックＢｉに対応する状態制御装置Ｃｉが、機能ブロックＢｉの状態を示す状態λｉを機能ブロックＢｉから取得する段階と、制御対象となる機能ブロックＢｉの性能に応じて予め定められた関数ｆｉであって、状態λｉを横軸とし、関数ｆｉの値を縦軸として描いた曲線が上または下に凸であるような関数ｆｉを機能ブロックＢｉの評価関数とするとき、評価関数ｆｉに基づいてＵｉ及びＶｉを求める段階と、状態制御装置ＣｊにＶｉを送信する段階と、状態制御装置Ｃｊに対応する機能ブロックＢｊの性能に応じて予め定められた関数ｆｊであって、機能ブロックＢｊの状態λｊを横軸とし、関数ｆｊの値を縦軸として描いた曲線が上または下に凸であるような関数ｆｊを機能ブロックＢｊの評価関数とするとき、評価関数ｆｊに基づいて求めたＷｊを、状態制御装置Ｃｊから受信する段階と、Ｕｉ及びＷｊに応じて機能ブロックＢｉを制御する制御段階とを含むことを特徴とする制御方法を提供する。  また、本発明は、他の態様として、システムを構成するｎ個（ｎは２以上の自然数）の機能ブロックそれぞれに対応するコンピュータを用いて各機能ブロックを制御するためのプログラムであって、ｉ、ｊが１≦ｉ、ｊ≦ｎ、ｉ≠ｊである任意の自然数であるとき、機能ブロックＢｉに対応するコンピュータＣｉに、機能ブロックＢｉの状態を示す状態λｉを機能ブロックＢｉから取得する手順と、制御対象となる機能ブロックＢｉの性能に応じて予め定められた関数ｆｉであって、状態λｉを横軸とし、関数ｆｉの値を縦軸として描いた曲線が上または下に凸であるような関数ｆｉを機能ブロックＢｉの評価関数とするとき、評価関数ｆｉに基づいてＵｉ及びＶｉを求める手順と、状態制��装置ＣｊにＶｉを送信する手順と、状態制御装置Ｃｊに対応する機能ブロックＢｊの性能に応じて予め定められた関数ｆｊであって、機能ブロックＢｊの状態λｊを横軸とし、関数ｆｊの値を縦軸として描いた曲線が上または下に凸であるような関数ｆｊを機能ブロックＢｊの評価関数とするとき、評価関数ｆｊに基づいて求めたＷｊを、状態制御装置Ｃｊから受信する手順と、Ｕｉ及びＷｊに応じて機能ブロックＢｉを制御する制御手順とを実行させるためのプログラムを提供する。
【発明の効果】
【０００６】  本発明によれば、複数の機能ブロックを有し、それらの機能ブロックを自律分散適応的に統合して動作させるシステムの制御全般に貢献することができる。本発明によれば、システムを外乱に対してロバストにし、また状況依存的にリアルタイムにシステムを適応させていくという制御を簡単、かつスケーラブルに実現することができる。
【図面の簡単な説明】
【０００７】  図１は本発明を適用可能なネットワークシステムの一例について説明するための図である。  図２は本発明の一実施の形態であるシステム１について説明するための図である。  図３は状態制御装置３０Ｃｉについて説明するためのブロック図である。  図４はシステム１で用いる評価関数について説明するための図である。  図５は状態制御装置４０Ｃｉについて説明するためのブロック図である。  図６は状態制御装置５０Ｃｉについて説明するためのブロック図である。  図７は機能ブロックＢｉの状態λｉと評価関数ｆｉのグラフと、機能ブロックＢｉに隣接する機能ブロックＢｊの負荷λｊと評価関数ｆｊのグラフである。  図８は状態制御装置６０Ｃｉについて説明するためのブロック図である。  図９は状態制御装置７０Ｃｉについて説明するためのブロック図である。  図１０は３つの状態制御装置Ｃ１、Ｃ２、Ｃ３が相互に接続された３角形構造のネットワークからなるシステム８０について説明するための図である。  図１１は機能ブロックＢ１、Ｂ２、Ｂ３の性能が互いに異なるときの評価関数ｆ１、ｆ２、ｆ３を示すグラフである。  図１２は性能が互いに異なる機能ブロックＢ１、Ｂ２、Ｂ３の出力λ１、λ２、λ３の時間変化を示すグラフである。  図１３は性能が互いに異なる機能ブロックＢ１、Ｂ２、Ｂ３の評価関数ｆ１、ｆ２、ｆ３の傾きの時間変化を示すグラフである。  図１４は同性能の機能ブロックＢ１、Ｂ２、Ｂ３の評価関数ｆ１、ｆ２、ｆ３を示すグラフである。  図１５は同性能の機能ブロックＢ１、Ｂ２、Ｂ３の出力λ１、λ２、λ３の時間変化を示すグラフである。  図１６は同性能の機能ブロックＢ１、Ｂ２、Ｂ３の評価関数ｆ１、ｆ２、ｆ３の傾きの時間変化を示すグラフである。  図１７は本発明の実施例１であるデータセンター７０について説明するための図である。  図１８は規格化評価関数について説明するための図である。  図１９はデータセンター７０において、評価関数のピークλｐｅａｋを変更した前後での、スループット、レスポンス及び起動リソース数の変化を示すグラフである。  図２０はデータセンター７０において、一部サーバを停止した前後での、スループット、レスポンス及び起動リソース数の変化を示すグラフである。  図２１はデータセンター７０において、サーバを追加した前後での、スループット、レスポンス及び起動リソース数の変化を示すグラフである。  図２２は発電機ネットワーク８０について説明するための図である。  図２３は発電機ネットワーク８０において、一部発電機を停止した前後での、システム全体の電力、起動リソース数の変化を示すグラフである。  図２４は発電機ネットワーク８０において、発電機を追加した前後での、システム全体の電力、起動リソース数、利潤の変化を示すグラフである。  図２５はデータセンター７０をエネルギーを制約条件として制御し、更に、λｍａｘより仕事量が大きいとき、スループットを重視する評価関数と、レスポンスを重視する評価関数について説明するためのグラフである。  図２６はエネルギーを制約条件としたデータセンター７０の負荷分散の実験における起動リソース数とエネルギー効率の時間変化を示すグラフである。  図２７はデータセンター９０について説���するための図である。  図２８はデータセンター９０において評価関数切替部９１が評価関数を切り替えた前後のレスポンス、エネルギー効率及び起動リソース数の変化を示すグラフである。  図２９はネットワークシステム１００について説明するための図である。  図３０はネットワークシステム１００において、予め他のデータセンターから分離していたデータセンター１００−１を、他データセンターと接続した前後における、レスポンス、起動リソース数の変化を示すグラフである。  図３１はストレージセンター１１０について説明するための図である。  図３２はストレージセンター１１０の制御に用いる規格化評価関数ｆを示すグラフである。  図３３はストレージセンター１１０において、規格化評価関数に乗算する係数を記録スピード優先のαｉｓからアーカイブ性優先のαｉｓに切り替えた前後における、高速性に優れたストレージ機器での記録データ量の変化を示すグラフである。  図３４はストレージセンター１１０において、規格化評価関数に乗算する係数を記録スピード優先のαｉｓからアーカイブ性優先のαｉｓに切り替えた前後における、アーカイブ性に優れたストレージ機器での記録データ量の変化を示すグラフである。  図３５は状態制御装置１２０Ｃｉについて説明するための図である。  図３６は評価関数修正部１２１Ｃｉによる評価関数の修正処理について説明するためのフローチャートである。  図３７は機能ブロックＢ１、Ｂ２、…、Ｂｎのそれぞれに状態制御装置１２０Ｃ１、１２０Ｃ２、…、１２０Ｃｎを設けたデータセンターシステムにおいて、エネルギーを制約条件とした制御を行なった実験の結果を示すグラフである。  図３８は冗長筋骨格系１３０について説明するための図である。  図３９は冗長筋骨格系１３０にて、目標位置に手先を移動させる制御を実施した結果を説明するための図である。  図４０はシステム内の全ノードを単一の状態制御装置にて制御する構成について説明するための図である。
【発明を実施するための形態】
【０００８】  ネットワーク上の複数のサーバコンピュータが連携して処理を行なうようなシステムを例に挙げて、本発明の機能、動作、構成について説明する。性能の異なるｎ台（ｎは２以上の自然数）のサーバからなるシステムを考える。サーバはネットワークを形成し、各サーバにランダムにやってくる処理（負荷）をサーバ全体で負荷分散するものとする。このようなシステムは図１のような構成となる。  このようなシステムが全体として効率的な処理を実行するにはどうすればよいかを考える。ここで、効率的な処理とは、系全体でレスポンスを最小化するとか、エネルギー効率を最大化するという意味である。このような負荷分散の問題は、効率の悪いサーバの起動、停止も含むので、本明細書にいう起動停止問題に相当する。  起動停止問題のうち、起動と停止については、リソース群があった場合、どのリソースを使い、どのリソースを使わないかを決定する、または管理する問題である。また、負荷の配置については、リソースが与えられたとして、系全体に与えられた仕事をどのように割り振れば、ある指標の元に最適化できるかという問題である。従来、これらの問題は、個々に、確率論的なアプローチで解くことを試みられていることが多い。しかし、単純な確率論では、変幻自在に変わっていく環境の中で、状況に応じてロバスト、リアルタイムに即応することが難しい。  本発明の一実施の形態であるシステム１では、図２に示すように機能ブロックＢ１、Ｂ２、…、Ｂｉ、…、Ｂｎのそれぞれに対し、状態制御装置Ｃ１、Ｃ２、…、Ｃｉ、…、Ｃｎを設ける。ｉは自然数であり、１≦ｉ≦ｎである。状態制御装置は起動停止問題をリアルタイムに解いて機能ブロックを制御する。以下、全機能ブロック、全状態制御装置に共通する説明を行なう際には機能ブロックＢｉ、状態制御装置Ｃｉとそれぞれ記すものとする。図２上では機能ブロックＢｉと状態制御装置Ｃｉは別々に記載され、両者の間を信号線が繋ぐように記載されているが、状態制御装置Ｃｉは機能ブロックＢｉに内蔵されることとしてもよい。  図３を参照して状態制御装置３０Ｃｉについて説明する。機能ブロックＢｉに対応する状態制御装置３０Ｃｉは評価関数処理部３１Ｃｉ、通信部３２Ｃｉ、制御信号生成部３３Ｃｉを備える。  評価関数処理部３１Ｃｉは、機能ブロックＢｉに予め定められた評価関数ｆｉに基づいてＵｉ、Ｖｉを生成し、通信部３２Ｃｉ、制御信号生成部３３Ｃｉに出力する。通信部３２Ｃｉは、状態制御装置Ｃｉ以外の状態制御装置Ｃｊ（ｊ≠ｉ、１≦ｊ≦ｎ）にＶｉを送信するとともに、機能ブロックＢｊの評価関数に基づいて生成されたＷｊを状態制御装置Ｃｊから受信し、Ｗｊを制御信号生成部３３Ｃｉに出力する。制御信号生成部３３Ｃｉは、Ｕｉ及びＷｊに基づいて制御信号を生成し、機能ブロックＢｉに対して出力する。  評価関数ｆｉは、機能ブロックＢｉの性能に応じて各機能ブロックに対して予め定められる関数であり、ある時刻における機能ブロックＢｉの状態を示すパラメータλｉを変数とする関数である。例えば前述のサーバシステムにおいて各サーバの負荷量をそのサーバの状態λとして用いることができる。関数ｆｉの値は機能ブロックＢｉの効率や利潤に関する指標を用いることが好ましい。効率や利潤に関する指標については後述する実施例にて詳説するので、ここでは一般的な意味での効率として理解されたい。関数ｆｉはいわば制御の指針として定められる関数であり、必ずしも測定可能な値、或いは、測定値から算出可能な値である必要はないが、そうであってもよい。  更に、評価関数ｆｉは上に凸な関数または下に凸な関数である。状態λｉを横軸にとり、関数ｆｉの値を縦軸にとったグラフを描いたとき、関数ｆｉは上または下に凸な曲線を描く。関数の凹凸に関して、上に凸な関数を凹関数と呼び、下に凸な関数を凸関数と呼ぶこともあるが、本明細書では、関数の曲線が描く凸形状の向きに言及する表現を採用し、上に凸な関数及び下に凸な関数を総称して凸関数と呼ぶものとする。  評価関数として凸関数を用いることは本発明のポイントである。なぜなら、多くのシステムでは、何らかの効率やシステムの安定性などが図４に示すような凸関数で表されるからである。評価関数が凸関数である要素を連携させて、全体で最適化する問題、即ち、各要素の評価関数の値の総和が最大となる状態を求める問題は「凸計画問題」として知られている。凸計画問題では、各要素の動作レベルにおける評価関数の微分値が等しい状況で最適化が達成されることが数学的に明らかにされている。本発明はこの原理を応用するものであり、評価関数として凸関数を用いる理由はここにある。このように凸関数を評価関数として用いることにより、本発明によれば状況に応じてロバスト、リアルタイムに即応することができる。また、その際、機能ブロックの起動／停止、及び機能ブロックへの負荷の配置に関する問題を、確率論ではなく、決定論的または関係論的な方法で解くことができる。以下、機能ブロックの起動／停止に係る制御を起動停止制御と呼び、機能ブロックの負荷の配置、分散に係る制御を負荷分散制御と呼ぶものとする。  負荷分散制御を行なう場合のシステム１について説明する。この場合、システム１は図５に示すような状態制御装置４０Ｃｉを機能ブロックＢｉのそれぞれに設ける。状態制御装置４０Ｃｉは、評価関数処理部４１Ｃｉ、通信部４２Ｃｉ、制御信号生成部４３Ｃｉに加えて監視部４４Ｃｉを備える。  評価関数処理部４１Ｃｉは、機能ブロックＢｉに予め定められた評価関数ｆｉと、後述する監視部４４Ｃｉが出力する状態λｉに基づいて、ｄｆｉ／ｄλｉを求めて、通信部４２Ｃｉ及び制御信号生成部４３Ｃｉに出力する。通信部４２Ｃｉは、状態制御装置Ｃｉ以外の状態制御装置Ｃｊ（ｊ≠ｉ、１≦ｊ≦ｎ）に対し、ｄｆｉ／ｄλｉを送信する。送信先である状態制御装置Ｃｊは、状態制御装置Ｃｉと同様に、対応する機能ブロックＢｊの評価関数ｆｊ及び機能ブロックＢｊから取得した状態λｊに基づき、ｄｆｊ／ｄλｊを生成して状態制御装置Ｃｉに送信する。通信部４２Ｃｉはこのｄｆｊ／ｄλｊを受信し、制御信号生成部４３Ｃｉに出力する。制御信号生成部４３Ｃｉは、ｄｆｉ／ｄλｉ、ｄｆｊ／ｄλｊ、予め定められた式１の方程式に従って制御信号を生成し、機能ブロックＢｉに出力する。2013146395.tif 000003
ここで、Ｋ１は状態変更のゲインに相当する係数である。このような制御を行なうことにより、制御信号生成部４３Ｃｉ、４３Ｃｊは、微分値ｄｆｉ／ｄλｉ、ｄｆｊ／ｄλｊが等しくなるように、機能ブロックＢｉ、Ｂｊの状態を変更するための制御信号を生成する。この制御は、「凸計画問題」に関して前述したように、全体利潤を最大化するポイントに各機能ブロックの状態（負荷量）を制御するのと等価である。つまり、式１の制御により、評価関数の縦軸で設定された効率が系全体として最大化される。監視部４４Ｃｉは、機能ブロックＢｉを監視して、機能ブロックＢｉの現在の状態を示すλｉを取得し、評価関数処理部４１Ｃｉに出力する。  状態制御装置Ｃ１、Ｃ２、…、Ｃｎは、それぞれ、少なくともひとつの他の状態制御装置と通信を行なって、その状態制御装置に自身の微分値を送信するとともに、その状態制御装置の微分値を受信して式１による制御を行なう。図２では、作図の便宜上、各状態制御装置はネットワークを介して他の全ての状態制御装置と通信可能であるようにも見えるが、実際の接続関係はこのようである必要はなく、例えば、他の状態制御装置ひとつだけと通信を行なうような状態制御装置がシステム１内に存在してもよい。或いは、システム１内の各状態制御装置が複数の状態制御装置と通信を行なうこととしてもよい。  上述した微分値のやりとりのように、制御信号を生成するために必要な値を互いに通信する状態制御装置間の関係、及び、そのような関係にある状態制御装置に対応する機能ブロック間の関係を本明細書では隣接と呼ぶ場合がある。例えば負荷分散制御に関する上述の説明では、状態制御装置Ｃｉ、Ｃｊは互いに隣接している。また、その機能ブロックＢｉ、Ｂｊも互いに隣接している。  式１には、効率最大化の他に大きなポイントがある。それは、式１は要素ｉ（状態制御装置Ｃｉ）と要素ｊ（状態制御装置Ｃｊ）に対して、絶対値は同じで反対の符号の状態変化を要求することである。これは、ある要素とそれに隣接する要素のある時刻における状態変化の総和が０になることを意味する。ここは、本願発明の重要ポイントである。  図１のようなシステムでは、系全体において負荷要求はローカル、即ち、機能ブロック毎に発生する。本発明では、図２のシステム１のように、機能ブロック毎に状態制御装置を設ける。そして、機能ブロック毎のローカルな負荷の授受を、ある要素とそれに隣接する要素のある時刻における状態変化の総和が０になるように制御する。このため、自律分散的処理を行なうにも関わらず、本発明では、系全体に要求されるトータルの負荷要求を過不足無く満足させることができる。  起動停止問題を解く際には、系全体（上述の例ではサーバネットワーク全体）で満たさなくてはいけない総要求（或いは総需要）がある。総要求を満たすことを需給平衡化ともいう。需給平衡化は起動停止問題を解く際の拘束条件のひとつになる。総要求を満たさないままに効率や利潤を最大化してもシステム全体としては意味がない。  起動停止問題を解く一般的な手法によれば、全体の総要求を計算し、それをもとに各要素が担当すべき負荷を分配している。このような手法によれば、系全体の総要求を各要素（機能ブロック）に適切に分配するため、系全体を統括する存在が必要になる。例えば図１のシステムであれば、システム全体に対して求められている総要求を、機能ブロックＢ１、Ｂ２、…、Ｂｎのそれぞれに対して適宜分配する手段、いわばシステムの中央制御装置とでもいうべきものが必要となる。  本発明では、互いに隣接する要素（機能ブロック）の間だけでの負荷の授受を均衡させることにより、全体の総要求を満たすことができる。その際の制御は自律分散処理により行なわれるので、全体の総要求をまとめるための中央制御装置は不要である。このような制御手法は、ネットワークが大規模化して、系全体を統括する中央制御装置を設けるのが困難になると、特に有効である。  ある状態制御装置に隣接する状態制御装置、ある機能ブロックに隣接する機能ブロックは複数であってもよい。このとき、各状態制御装置は、その状態制御装置に隣接する一の状態制御装置毎に式１を定め、このような式１による制御を隣接する全ての状態制御装置に対して順番に実行することとしてもよい。例えば、状態制御装置Ｃ１に状態制御装置Ｃ２及びＣ３が隣接しているとき、状態制御装置Ｃ１は、まず式２に従って機能ブロックＢ１を制御し、次に式３に従って機能ブロックＢ１を制御することとしてもよい。図５においてｉ＝１としたものが状態制御装置Ｃ１であるが、制御信号生成部４３Ｃ１は、まず式２に従って制御信号を生成して機能ブロックＢ１に送信し、次に式３に従って制御信号を生成して機能ブロックＢ１に送信する。2013146395.tif 000004
或いは、各状態制御装置は、その状態制御装置自身と、その状態制御装置に隣接する全ての状態制御装置の微分値に基づくひとつの方程式として式４を求め、式４に基づいて制御を行なうこととしてもよい。例えば、状態制御装置Ｃ１に状態制御装置Ｃ２及びＣ３が隣接しているとき、状態制御装置Ｃ１は式５のようなひとつの方程式に従って機能ブロックＢ１を制御することとしてもよい。このときの状態制御装置５０Ｃｉは図６のようになり、図５の制御信号生成部４３Ｃｉの代わりに、式４に基づいて制御信号を生成し、機能ブロックＢｉに出力する制御信号生成部５３Ｃｉを備える。2013146395.tif 000005
ここでλｎｏｍ，ｉは要素ｉの規格化係数である。要素がヘテロな場合、即ち、性能が異なる機能ブロックが混在している場合、システム内で規格化した評価関数を定め、機能ブロックの性能に応じた規格化係数を規格化した評価関数に乗算することにより、各機能ブロックの評価関数を定めると都合が良い場合が多いので、ここでは規格化係数を導入している。従って規格化係数λｎｏｍ，ｉは機能ブロックＢｉの能力や規模に相当する量である。  式１によれば、要素間で負荷の授受が自動的に均衡するが、式４によれば自動的な均衡はしない。このため、式４による制御を行なう場合には、ある要素とそれに隣接する要素のある時刻における状態変化の総和が０になるような工夫を加える必要がある。  状態λの変化の総和をゼロにするため、負荷を分散しようとする要素は、隣接する各要素について現時点での負荷の受け取りやすさを判定し、受け取りやすい状況にある要素に負荷を分散する。評価関数ｆが上に凸な関数の場合、微分値ｄλ／ｄｔがより大きい要素は、そうではない要素と比較して負荷を受け取りやすい状況にあると判定する。また、評価関数ｆが下に凸な関数の場合、微分値ｄλ／ｄｔがより小さい要素は、そうではない要素と比較して負荷を受け取りやすい状況にあると判定する。  例えば、微分値ｄλ／ｄｔに基づいて、隣接要素を負荷の受け取りが可能なものと不可能なものに二分し、受け取り可能な要素間で平等に負荷を分配する手法がある。評価関数が上に凸の場合、要素ｉの微分値ｄλｉ／ｄｔと、要素ｉに隣接する要素の微分値ｄλ／ｄｔそれぞれとを比較し、微分値がｄλｉ／ｄｔよりも大きい隣接要素の数をカウントする。次に、カウントした要素数で式４から導出される負荷を割り算する。そうして算出された負荷を、微分値ｄλ／ｄｔが微分値ｄλｉ／ｄｔよりも大きい要素それぞれに分配する。状態制御装置Ｃ１に状態制御装置Ｃ２、Ｃ３、Ｃ４が隣接し、このうち状態制御装置Ｃ２、Ｃ３の微分値ｄλ２／ｄｔ、ｄλ３／ｄｔがｄλ１／ｄｔよりも大きい場合、微分値ｄλ／ｄｔがｄλ１／ｄｔよりも大きい要素の数は２なので、式５で得られた値ｄλ１／ｄｔを要素数２で割った値ｄλ１／２ｄｔを、状態制御装置Ｃ２、Ｃ３それぞれに分配する。その際、ある時刻において、ｄλ１／ｄｔ＋ｄλ２／ｄｔ＋ｄλ３／ｄｔ＝０となるように制御することが重要である。  その他の手法としては、分配するときに、隣接要素の負荷の状態を見て、負荷を受け取りやすい要素に重みをかけて分配するなどが考えられる。隣接要素がどの程度負荷を受け取りやすいかは、今回の制御の原理と同様に、評価関数の微分値を比べればわかる。負荷を受け取りやすい要素とは、評価関数が上に凸な場合は、微分値ｄλ／ｄｔが自身よりも大きい要素であり、評価関数が下に凸な場合は、微分値ｄλ／ｄｔが自身よりも小さい要素である。状態制御装置Ｃ１に状態制御装置Ｃ２、Ｃ３、Ｃ４が隣接し、このうち状態制御装置Ｃ２、Ｃ３に負荷を分配する場合を考える。状態制御装置Ｃ１の微分値ｄλ１／ｄｔからＣ２の微分値ｄλ２／ｄｔを引いた値がｄλ１／ｄｔ−ｄλ２／ｄｔ＝−５、Ｃ１の評価関数微分値ｄλ１／ｄｔからＣ３の評価関数微分値ｄλ３／ｄｔを引いた値がｄλ１／ｄｔ−ｄλ３／ｄｔ＝−１��としたときに、式５で得られた値ｄλ１／ｄｔに、（ｄλ１−ｄλ２）／（ｄλ１−ｄλ２＋ｄλ１−ｄλ３）＝５／（５＋１０）＝１／３をかけた値ｄλ１／３ｄｔを状態制御装置Ｃ２に分配し、（ｄλ１／ｄｔ−ｄλ３／ｄｔ）／（ｄλ１／ｄｔ−ｄλ２／ｄｔ＋ｄλ１／ｄｔ−ｄλ３／ｄｔ）＝１０／（５＋１０）＝２／３をかけた値２ｄλ１／３ｄｔを状態制御装置Ｃ３に分配する。その際、ある時刻において、ｄλ１／ｄｔ＋ｄλ２／ｄｔ＋ｄλ３／ｄｔ＝０となるように制御する。  このような負荷分散制御により、総需要を満たしながらリアルタイムに負荷の配置の問題を解くことができる。次に、起動停止制御を行なう場合のシステム１について説明する。起動停止制御では、システム１のどの機能ブロックを起動し、どの機能ブロックを停止するかを決定する。  図７（Ａ）は機能ブロックＢｉの状態（ここでは負荷）λｉと評価関数ｆｉのグラフである。λｉ＝λ０，ｉにおいて評価関数ｆｉの値はゼロであり、傾きｇ０，ｉを有する。λ０，ｉを機能ブロックＢｉのゼロクロス点ともいう。λｉ＝λｐｅａｋ，ｉのとき、評価関数ｆｉはピーク値αｉをとる。λｍａｘ，ｉはλｉの上限値である。  図７（Ｂ）は機能ブロックＢｉに隣接する機能ブロックＢｊの負荷λｊと評価関数ｆｊのグラフである。評価関数ｆｉ、ｆｊは対応する機能ブロックＢｉ、Ｂｊの効率または利潤に対応する値を出力する。機能ブロックＢｉに隣接する機能ブロックＢｊの評価関数ｆｊにおいて、機能ブロックＢｉのゼロクロス点λ０，ｉと同じ傾きｇ０，ｉを有する点の横軸座標をｚｉｊとする。本発明の起動停止制御ではｚｉｊを指標として用いる。ｚｉｊは次の式６により表される。2013146395.tif 000006
更に、指標ｚｉｊを用いて指標Ｓｉを次の式７のように定義する。2013146395.tif 000007
指標Ｓｉは、機能ブロックＢｉに隣接する全機能ブロックの負荷の総和が、機能ブロックＢｉのゼロクロス点λ０，ｉでの負荷よりどれだけ大きいかを表している。式７においてλｊ、ｚｉｊはどちらも機能ブロックＢｉに隣接する機能ブロックに係る値である点に注意されたい。システム１の機能ブロックであっても、機能ブロックＢｉに隣接していない機能ブロックに係る値は式７には含まないものとする。  機能ブロックＢｉが停止しているとするとき、機能ブロックＢｉを起動すべき条件は、起動することで機能ブロックＢｉがゼロクロス点以上の負荷を担当する状況にあることである。この条件を満たすならば、機能ブロックＢｉの起動により機能ブロックＢｉから得られる利潤はゼロ以上になるので、機能ブロックＢｉを起動することは不利益にはならない。このように、指標Ｓｉは機能ブロックＢｉを起動／停止することによる有利／不利を数値化したものである。  式７の右辺第１項は、機能ブロックＢｉのゼロクロス点λ０，ｉにおける評価関数ｆｉの微分値をｇ０，ｉとし、機能ブロックＢｉに隣接する機能ブロックＢｊの評価関数ｆｊ上の微分値がｇ０，ｉになる負荷λｊの値ｚｉｊとするとき、機能ブロックＢｊの現在の負荷λｊとｚｉｊの差を求め、この差を機能ブロックＢｉに隣接するすべての機能ブロックについて合計したものを示している。この差の合計から右辺第２項にて機能ブロックＢｉの評価関数ｆｉのゼロクロス点λ０，ｉを引いて指標Ｓｉを得る。  指標Ｓｉがゼロより大きい状況で、停止している機能ブロックＢｉを起動すると、隣接機能ブロック群が担当中の負荷の一部を徐々に機能ブロックＢｉが担当するようになり、その負荷はゼロクロス点λ０，ｉを越える。従って、この状況で機能ブロックＢｉを起動するとプラスの利潤が生じる。機能ブロックＢｉが現に起動中の場合、指標Ｓｉがゼロより大きいことは機能ブロックＢｉを現時点で停止すべきではないことを示している。  逆に、指標Ｓｉがゼロより小さい状況で、停止している機能ブロックＢｉを起動しても、同様に隣接機能ブロック群が担当中の負荷の一部を徐々に機能ブロックＢｉが担当するようになるが、その負荷はゼロクロス点λ０，ｉ未満になる。従って、この状況で機能ブロックＢｉを起動するとマイナスの利潤が生じる。機能ブロックＢｉが現に起動中の場合、指標Ｓｉがゼロより小さいことは機能ブロックＢｉを停止すべきことを示している。  このように、指標Ｓｉの正負によって機能ブロックＢｉを起動すべきか否かを判定することができる。指標Ｓｉが負であるとは、その時点で機能ブロックＢｉは評価関数ｆｉが負の値になるような負荷λｉを担当していることを意味する。このため、評価関数ｆｉがゼロ以下になったら機能ブロックＢｉを停止すると考えてもよい。  起動しているノードを停止する場合にはもうひとつ考慮しなければならないことがある。ノードの性能が同じ場合の起動停止に関してである。先ほども述べたが、起動コストがかかる場合、どれかひとつのノードだけ起動し、残りは停止したほうが良いことが良く起こる。しかしながら、性能が同じ場合、どちらを止めればいいのか今のままでは判断できない。そこで、我々は次のようなアルゴリズムを導入した。「評価関数値が０以下で、かつ隣接ノードを含め最も値が低い場合、停止。値の比較は起動しているノード間で行う。最小値が複数ある場合でも停止。」  より詳しくは次のようなアルゴリズムである。即ち、起動中の機能ブロックＢｉの評価関数ｆｉがゼロ以下であり、かつ、機能ブロックＢｉに隣接する起動中の機能ブロックＢｊ１、Ｂｊ２、…、Ｂｊｍ（ｊ１、ｊ２、…、ｊｍはｉ以外）の評価関数ｆｊ１、ｆｊ２、…、ｆｊｍの値と比較して評価関数ｆｉの値が最も低いとき機能ブロックＢｉを停止する。このとき、評価関数ｆｊ１、ｆｊ２、…、ｆｊｍの中に、評価関数ｆｉの値と等しいものがあったとしても機能ブロックＢｉを停止する。  ネットワーク内の全ノードが完全に同期して停止する可能性は低く、また、仮に全ノードが同時に停止したとしても、本発明の起動停止制御によりいずれかのノードが起動するため問題にはならない。ネットワークの結合が疎の場合、このアルゴリズムでもいくつかセグメントが残ってしまう可能性はあるが、そのような場合は、ロードバランサを介して、隣接ノードの中で起動中のものだけではなく、更に、起動していない隣接ノードを介して接続されている起動中のノード、いわば実質的な隣接ノードを探し、上記アルゴリズムを実施するなどの方法で対処するなどが考えられる。ここでいう疎結合とは、各ノードにおいて隣接するノードの数が少ないようなネットワーク内の結合をさす。或いは、そのノード群内では、多数の他ノードと直接に接続されているが、そのノード群以外のノードとは、直接には全く接続されていない、或いは、少数としか接続されていない、いわば孤立して島のように起動しているノード群を、セグメントというとき、ふたつのセグメント間の結合を疎という。  図７（Ａ）（Ｂ）では、負荷λｉ、λｊがゼロのときに評価関数ｆｉ、ｆｊはどちらも負の値を取っている。これは、機能ブロックＢｉ、Ｂｊが作動状態を維持することにコストが発生することを意味している。機能ブロックがサーバである場合にはやや想像しにくいが、例えば、システム１が複数の発電機からなる発電ネットワークであり、機能ブロックが発電機である場合について次のように説明する。発電機での発電コストには、発電量に比例して発生する変動費と、発電量に関係なく発生する固定費がある。需要家から受け取る電気料は概ね発電量に比例するので、ある程度以上の電力を発電しないと固定費を回収することができない。図７（Ａ）においてλ０，ｉ以下の発電量ではその発電機の固定費全額を回収することができず、その発電機に注目したときの収支は赤字となる。λ０，ｉにおいて、その発電機が発生する発電量に対して需要家から受け取る電気料と、その発電量にかかる固定費と変動費の合計金額とが一致し、収支が釣り合う。  状態λがゼロのときに評価関数ｆは必ずしも負の値を取るとは限らない。後述する実施例には、システム１がデータセンターであり、各機能ブロックがデータセンターを構成するコンピュータであり、データセンターのレスポンスを最適化するものがある。このときコンピュータのレスポンスに関連する量をそのコンピュータの評価関数ｆとするが、この評価関数ｆは状態λがゼロのとき正の値を持つ。このように、評価関数は状態λがゼロのとき正��どちらの値も取り得る。しかし、負の値を取るケースを考えておけば、正の値を取るケースについてはその一部として解くことができる。  このような起動停止制御を行なう状態制御装置６０Ｃｉについて図８を参照して説明する。状態制御装置６０Ｃｉは、評価関数処理部６１Ｃｉ、通信部６２Ｃｉ、制御信号生成部６３Ｃｉ、監視部６４Ｃｉ、評価関数処理部６５Ｃｉを備える。  評価関数処理部６１Ｃｉは、予め定められた機能ブロックＢｉの評価関数ｆｉに基づいて定められる、ゼロクロス点λ０，ｉを評価関数処理部６１Ｃｉに出力する。また、評価関数処理部６１Ｃｉは、ゼロクロス点λ０，ｉでの評価関数ｆｉの傾きｇ０，ｉを通信部６２Ｃｉに出力する。評価関数処理部６１Ｃｉは予め求めたゼロクロス点λ０，ｉ及び傾きｇ０，ｉを格納する記憶装置であってもよい。  通信部６２Ｃｉは、評価関数処理部６１Ｃｉから受け取った傾きｇ０，ｉを、状態制御装置６０Ｃｉに隣接する不図示の他の状態制御装置６０Ｃｊに送信する。また、通信部６２Ｃｉは、状態制御装置６０Ｃｊが受信した傾きｇ０，ｉに基づいて生成したλｊ−ｚｉｊを受信し、制御信号生成部６３Ｃｉに出力する。  更に、通信部６２Ｃｉは、機能ブロックＢｊの評価関数ｆｊに基づいて定められるゼロクロス点λ０，ｊでの評価関数ｆｊの傾きｇ０，ｊを、状態制御装置６０Ｃｊから受信し、評価関数処理部６５Ｃｉに出力する。また、通信部６２Ｃｉは、評価関数処理部６５Ｃｉから入力されたλｊ−ｚｊｉを状態制御装置６０Ｃｊに送信する。  制御信号生成部６３Ｃｉは、評価関数処理部６１Ｃｉから受け取ったゼロクロス点λ０，ｉと、隣接する状態制御装置から通信部６２Ｃｉを介して受信したλｊ−ｚｊｉとに基づいて、指標Ｓｉを求め、その正負に応じて機能ブロックＢｉを起動乃至停止する。  監視部６４Ｃｉは、機能ブロックＢｉを監視して、機能ブロックＢｉの現在の状態を示すλｉを取得し、評価関数処理部６５Ｃｉに出力する。  評価関数処理部６５Ｃｉは、監視部６４Ｃｉから受け取った状態λｉと、通信部６２Ｃｉを介して状態制御装置６０Ｃｊから受け取った傾きｇ０，ｊに基づいて、λｉ−ｚｊｉを生成し、通信部６２Ｃｉを介して状態制御装置６０Ｃｊに送信する。  次に状態制御装置６０Ｃｉによる機能ブロックＢｉの起動停止制御の動作について説明する。評価関数処理部６１Ｃｉが出力した傾きｇ０，ｉを、通信部６２Ｃｉを介して、状態制御装置６０Ｃｉに隣接する他の状態制御装置６０Ｃｊに送信する。傾きｇ０，ｉを受信した状態制御装置６０Ｃｊは、評価関数処理部６５Ｃｊにより、監視部６４Ｃｊにて取得した状態λｊと、受信した傾きｇ０，ｊに基づいて、λｉ−ｚｊｉを生成し、通信部６２Ｃｊを介して状態制御装置６０Ｃｉに送信する。状態制御装置６０Ｃｉに戻ると、通信部６２Ｃｉにて受信したλｊ−ｚｉｊを制御信号生成部６３Ｃｉに渡す。制御信号生成部６３Ｃｉは、評価関数処理部６１Ｃｉから受け取ったゼロクロス点λ０，ｉと、隣接する状態制御装置から通信部６２Ｃｉを介して受信したλｊ−ｚｊｉとに基づいて、指標Ｓｉを求め、その正負に応じて機能ブロックＢｉを起動乃至停止する。  また、状態制御装置６０Ｃｉは、隣接する他の状態制御装置６０Ｃｊから、対応する機能ブロックＢｊの評価関数ｆｊのゼロクロス点λ０，ｊでの傾きｇ０，ｊを受信すると、監視部６４Ｃｉにて状態λｉを取得し、評価関数処理部６５Ｃｉにてλｉ−ｚｊｉを生成して、通信部６２Ｃｉを介して状態制御装置６０Ｃｊに送信する。  説明の便宜上、システム１の負荷分散制御と起動停止制御を分けて説明したので、負荷分散制御と起動停止制御のどちらか一方をシステムに適用可能なことは明らかだが、両方を備えることとして完全な最適化を目指すこととしてもよいことは、当業者には明らかだろう。例えば、図９の状態制御装置７０Ｃｉのように、式１に基づいて隣接する機能ブロック間の負荷分散制御を行ないつつ、式７及び上述のアルゴリズムを用いて、隣接する機能ブロックの状態を考慮して機能ブロックの起動停止制御を行なう状態制御装置を、機能ブロックそれぞれに設ける。これにより、システム１では、リアルタイムに負荷分散制御を含む起動停止問題を解くことができる。これは、従来のように予めスケジューリングして起動停止問題を解くことと比較して画期的である。何故なら、システム１ではシステム稼働前に想定していないような外乱や需要の変化に対してであってもリアルタイムに即応することができるからである。  また、システム１の各機能ブロックは、自律分散的に互いに独立して動作するので、いずれかの機能ブロック乃至状態制御装置が故障しても、その状態制御装置からの信号が途絶えた分だけ、他の状態制御装置が自律的に系全体の出力をリカバーするように動作する。また、機能ブロックの突然の増減に対しても、システム１は徐々に自律的に適正な動作状態に向かおうとする。つまり、システム１は、外乱に対して、非常にロバストであり、また、要素の増減を自由にできるスケーラビリティを有している。  従来のシステムは、故障に対して無力であったり、様々なエラー用のシーケンスを用意したりしなければならなかった。また、勝手に要素（リソース）を増やしたり減らしたりすればシステム全体の安定性が保たれるか保証はなく、そのたびにプログラム、処理を見直さなければならなかった。本発明のシステム１はこれらの問題を自律分散適応的な制御ですべて解決することができる。  本発明のシステム１に対する総需要の時間変化に対し、各機能ブロックがどのように起動停止、負荷分散を行なうかについて実験した。３つの状態制御装置Ｃ１、Ｃ２、Ｃ３が相互に接続された３角形構造のネットワークからなる図１０のようなシステム８０で実験を行なった。状態制御装置Ｃ１、Ｃ２、Ｃ３はそれぞれ機能ブロックＢ１、Ｂ２、Ｂ３を制御するものであり、いずれも図９の状態制御装置７０Ｃｉのように負荷分散制御と起動停止制御の両方を行なうものである。機能ブロックＢ１、Ｂ２、Ｂ３はそれぞれ性能が異なり、従ってそれぞれの評価関数ｆ１、ｆ２、ｆ３は互いに異なるものとする。図１１に評価関数ｆ１、ｆ２、ｆ３のグラフを示す。状態λ１、λ２、λ３はそれぞれ機能ブロックＢ１、Ｂ２、Ｂ３の出力（ｐｏｗｅｒ）である。評価関数ｆ１、ｆ２、ｆ３は、それぞれ状態λ１、λ２、λ３の関数であり、ここではある状態λ１、λ２、λ３における機能ブロックＢ１、Ｂ２、Ｂ３の利潤効率を示すものとする。評価関数で出力が同じときの利潤���率を比較して分かるように、機能ブロックＢ１、Ｂ２、Ｂ３の順に利潤効率が高い。このようなシステム８０において、総需要を次のように時間変化させた。即ち、時刻０から１０までの総需要を０．２とし、時刻１０から２０までの総需要を１．０とし、時刻２０以降の総需要を再び０．２に変化させた。  このときの各機能ブロックＢ１、Ｂ２、Ｂ３の出力λ１、λ２、λ３は、状態制御装置Ｃ１、Ｃ２、Ｃ３の制御により、それぞれ図１２のような時間変化を示す。即ち、時刻０から時刻１０の間、総需要が０．２のときは、最も利潤効率の高い機能ブロックＢ１のみを起動している。時刻１０において総需要が０．２から１．０に上昇すると、これに応じて機能ブロックＢ１の出力が急上昇し、時刻ｔ１において、停止中の機能ブロックＢ２、Ｂ３のうち、より利潤効率が高い機能ブロックＢ２が優先して起動される。時刻ｔ１の後で、機能ブロックＢ１及びＢ２の出力は上昇し、時刻ｔ２において未起動の機能ブロックＢ３が起動する。時刻ｔ２から時刻２０の間、機能ブロックＢ１、Ｂ２、Ｂ３の出力はそれぞれ一定である。時刻２０において、総需要が１．０から０．２に戻ると、機能ブロックＢ２、Ｂ３は停止し、機能ブロックＢ１のみが作動する状態に戻る。この間の評価関数ｆ１、ｆ２、ｆ３の傾きを図１３に示す。  既に説明したように、本願発明は数学的に起動停止問題を最適に解く仕組みとなっているので、この実験結果は、リアルタイム（動的に）起動停止問題を解きながら、外乱（需要の急変）に適応しできたことを意味する。これは非常に大きな成果である。  機能ブロックＢ１、Ｂ２、Ｂ３の性能を同じにした実験について説明する。この場合、評価関数ｆ１、ｆ２、ｆ３は同じなので、図１４に示すようにグラフは全て重なり、一本の曲線のように見える。ここでも、先と同様に、時刻０から１０までの総需要を０．２とし、時刻１０から２０までの総需要を１．０とし、時刻２０以降の総需要を再び０．２と変化させた。すべての機能ブロックの性能が同じなので、わかりにくいが、総需要が０．２のときは、機能ブロックＢ３のみ起動しており、総需要が１．０のときは３つの機能ブロックで均等に負荷を分担している様子がわかる。このように本願発明は、起動コストがあり、機能ブロックの性能が同じ場合でも有効に最適化を行える。  本願発明は、評価関数の微分を各要素で等しくするという制御を行っているが、ある関数の微分を各要素で等しくするというのが本質ではない。凸関数の微分を各要素で等しくするというのが本質である。
【実施例１】
【０００９】  本発明の一実施例であるデータセンター７０について説明する。図１７を参照すると、データセンター７０は、データ通信ネットワークを介して相互に接続されたサーバＢ１、Ｂ２、…、Ｂｉ、…、Ｂｎと、各サーバに対応する状態制御装置Ｃ１、Ｃ２、…、Ｃｉ、…、Ｃｎを備える。データセンター７０は、リソース負荷分散に対して上述の実施形態を適用したものである。本実施例では、サーバＢ１、Ｂ２、…、Ｂｉ、…、Ｂｎの状態λ１、λ２、…、λｉ、…、λｎとして、そのサーバが管理するリソースに割り当てられたタスク量（仕事量）を用いるものとする。  データセンターのリソース負荷分散を考えた場合、管理者がこだわる制約条件としては、レスポンス、スループット、エネルギーなどが上げられる。本実施例ではレスポンスとスループットを制約条件とする。  レスポンスとスループットは密接に絡み合った量である。しかも、トレードオフの関係にある。簡単に説明すると、サーバの処理限界に近づくほどスループットは向上し、レスポンスは低下する。また、レスポンスは、サーバの処理限界に近づいたときに急激に悪化するという特徴を持つ。これは待ち行列理論により説明されている。サーバの管理者は自分の管理するシステムのレスポンス要求とスループット要求をできるだけ両立するように、サーバにかかる負荷をバランスさせる必要がある。  では、本願発明を用いて、管理者はどのようにデータセンターの負荷分散を実現すればよいのだろうか。上述したように、レスポンスとスループットはトレードオフの関係にあるので、レスポンスを重視する場合は、各サーバ（機能ブロック）Ｂｉに割り当てる仕事量λｉを低めにすればよい。また、スループットを重視する場合は仕事量λｉを高めにすればよい。したがって、各要素に設定する関数を例えば以下のような手法で設定していけばよい。  図１８に評価関数の概略図を示す。今回の検討課題が負荷分散なので、横軸は仕事量λｉとした。先にも述べたが、評価関数は凸関数が良いので、今回は上に凸な２次関数とした。λｍａｘはそのリソースの限界であり、λｐｅａｋは評価関数のピーク位置を表す。評価関数のピークを１として規格化しておくと、この場合、規格化評価関数は（０，０）、（λｐｅａｋ，１）を通る２次関数として決定できる。今回の実施例では、サーバの起動にコストがかからないとして、原点周辺で評価関数の値が負になっていない。起動停止によるレスポンス、スループットの劣化が少ない場合は、このようにするのが適正である。  各要素（リソース）には性能差があるので、その性能差に比例した係数αｉを規格化評価関数に掛けることで、個々の評価関数とする。先にも述べたが、レスポンス重視にしたければ、各要素（リソース）に分散される仕事量λｉを低めにすればよいし、スループットを重視したければそれを多めにすれば良い。したがって、レスポンス重視で仕事をシステムに実施してもらいたければ、λｐｅａｋの位置を小さめに設定すれば良く、スループット重視で仕事をして欲しければλｐｅａｋの位置を大きめすれば良い。  システム１の手法を用いて、データセンター７０の各サーバは、起動停止問題を解きつつ、それぞれのλｐｅａｋの位置をできるだけ目指すように動作する���したがって、λｐｅａｋの位置を小さめに設定していれば、それぞれの要素の負荷が比較的小さめに仕事が分散されることになり、全体としてはレスポンス重視の動作となる。また、λｐｅａｋの位置を大きめに設定していれば、それぞれの要素の負荷が比較的大きめに仕事が分散されることになり、全体としてはスループット重視の動作となる。無駄なリソースは適宜停止させるので、エネルギー的にも無駄のない制御となる。  データセンター７０において、評価関数の縦軸は実際の何らかの効率にはなっていない点に注意されたい。むしろ管理者が動作させたい位置であり、評価関数の設定は、何らかの物理量、法則に支配されることはない。システムを動作させたい人間が、縦軸、横軸を任意に設定することができるのである。ある意味、人間がシステムに評価関数として指示を渡すと、後はシステムが自律的に協調して動作するのである。  今回、評価関数は（０，０）、（λｐｅａｋ，１）を通る２次関数に係数αｉを掛けたものとしたが、凸関数であれば良いので、様々に設定して良い。極論すれば、手書きの評価関数を設定しても良い。  上述した評価関数を用いて、データセンター７０の負荷分散の実験を行った。各サーバＢｉには、図９に示したような負荷分散制御と起動停止制御の両方を行なう状態制御装置Ｃｉが設けられている。各サーバＢｉは自身に設定された評価関数ｆｉと自身に接続された他のサーバの状況を見ながら制御を行う。各サーバＢｉは、自身以外の他の全てのサーバとの間とデータ通信を行なう。即ち、サーバＢｉは、ｄｆｉ／ｄλｉ、ｇ０，ｉ、λｉ―ｚｊｉを他のサーバＢｊ宛に送信し、逆に、ｄｆｊ／ｄλｊ、ｇ０，ｊ、λｊ―ｚｉｊをサーバＢｊから受信する。これにより、需給平衡化に必要な全体要求（需要）と現時点でのシステム全体の仕事量の差を各サーバにてモニタすることを可能とした。負荷分散を決定する係数Ｋ１を適宜設定した。また、サーバの総数は１０００台とした。また、各サーバの性能は均一ではなく、性能が高いものほどαｉを大きく設定した。  図１９に第１の実験結果を示す。グラフの横軸は時間である。縦軸は、システム全体の実効的なレスポンス、スループット、起動リソース数（起動しているサーバの数）である。最初は、λｐｅａｋを小さめに設定し、レスポンス重視で動作させている。その後、図中のスループット重視と描かれた時刻にλｐｅａｋを大きめに設定しなおしている。すると、グラフに示すように、レスポンスが低下する一方でスループットが上昇し、システムは自律的にレスポンス重視な方向に動作を変更していくことが確認された。起動しているサーバも適宜調整されており、本願発明が有効であることが確認できた。  図２０に第２の実験結果を示す。グラフの横軸は時間である。縦軸は、システム全体の実効的なレスポンス、スループット、起動リソース数（起動しているサーバの数）である。あるλｐｅａｋの設定で動作させている途中で、人為的に１割のサーバを止めた（図中矢印の部分）。すると、一時的にスループット、レスポンス能力が下がるが自律的に回復する様子がグラフからわかる。サーバの能力は均一ではなく、ヘテロな状態なので、自律的に回復した後に使用されているサーバの数は、人為的にサーバを止めた前後で変わっている。これは、まさしく自律的に起動停止問題を解いていることを意味している。故障に対するロバスト性に関しても、本願発明が有効であることが確認できた。  図２１に第３の実験結果を示す。グラフの横軸は時間である。縦軸は、システム全体の実効的なレスポンス、スループット、起動リソース数（起動しているサーバの数）である。あるλｐｅａｋの設定で動作させている途中で、人為的に１００台のサーバを追加した（図中矢印の部分）。すると、スループット、レスポンス能力を変化させることなく、自律的に追加サーバを含めたサーバの起動停止を行い安定状態に落ち着く。これは、このシステムがスケーラブルであることを示しており、リソースの増減に対してプログラムの変更、処理の変更が全く必要ないことを意味している。これは、非常に有用な特性であり、本願発明が有効であることが確認できた。
【実施例２】
【００１０】  本実施例は複数の発電機からなる発電機ネットワーク８０に本発明を適用したものである。図２２に示すように、発電機ネットワーク８０の機能ブロックＢ１、Ｂ２、…、Ｂｎはそれぞれ発電機であり、各機能ブロックの状態制御装置Ｃ１、Ｃ２、…、Ｃｎはデータ通信ネットワークを介してお互いに接続されている。発電機の少なくとも一部は家庭、工場、オフィス等の需要家に電力を供給している。状態λｉは発電機Ｂｉに対して割り当てられた発電パワに相当する。本実施例から分かるように、本発明では、機能ブロック間は必ずしも互いに通信を行なう必要はないが、状態制御装置間は通信を行なう必要がある。  各発電機には、図７に示したような評価関数を設定した。発電機の性能は均一ではなく、ピーク値（α）やパワ限界値（λｍａｘ）は異なる。縦軸には、発電による利潤を置いた。したがって、評価関数値がプラスなら、発電により儲かり、マイナスなら発電により損失が発生する。需要にあわせて最も利潤が高くなるように制御するのが全体として望ましい。起動によりコストが発生するので、負荷が０のときの評価関数値はマイナスとなる。また、評価関数は凸関数である２次関数で設定した。発電機の利潤関数は２次曲線で近似できることは知られている。  上述した評価関数を用いて、図２２に示す発電機ネットワーク８０の制御の実験を行った。各発電機には、図９で示した本願発明の状態制御装置が内蔵されており、各発電機は自身に設定された評価関数と自身に接続された他の発電機の状況（評価関数）を見ながら制御を行う。先にも述べているが、本願発明の制御は、要素（リソース）の起動停止の決定（起動停止制御）と、起動を決定した要素への負荷の配置の決定（負荷分散制御）に分けることができる。この両者をリアルタイムに実行するのが本来の「起動停止問題」解く制御であるが、本願発明を使って、起動停止の決定のみ、負荷の配置の決定のみを実行することもできる。本実施例では、この両者をリアルタイムに実行する本来の制御を実施した。負荷分散を決定する係数Ｋ１は適宜設定した。また、各発電機の利潤は均一ではなく、利潤が高いものほどαｉを大きくなっている。  尚、図２２において、各発電機は少なくとも２機の発電機と接続されているものの、他の全ての発電機と接続されてはいない。しかし、特定の一発電機での変化のように、ネットワーク内で局所的な変化が生じた場合であっても、連結されたネットワークであれば、ローカルな情報もいずれ全体に回っていくからである。状態制御装置は少なくとも１台の他の状態制御装置とデータ通信可能であればよい。  図２３に第１の実験結果を示す。グラフの横軸は時間であり、縦軸は、システム全体の電力、起動リソース数（起動している発電機の数）である。ある電力需要で動作させている途中で、人為的に１割の発電機を止めた（図中矢印の部分）。すると、一時的に電力供給能力が下がるが自律的に回復する様子がグラフからわかる。発電機の能力は均一ではなく、ヘテロな状態なので、自律的に回復した後に使用されている発電機の数は、人為的に発電機を止めた前後で変わっている。これは、まさしく自律的に起動停止問題を解いていることを意味している。故障に対するロバスト性に関して、本願発明が有効であることが確認できた。  図２４に第２の実験結果を示す。グラフの横軸は時間であり、縦軸は、システム全体の電力、起動リソース数（起動している発電機の数）、利潤である。ある電力需要で動作させている途中で、人為的に１００台の発電機を追加した（図中矢印の部分）。すると、発電能力を変化させることなく、自律的に追加発電機を含めた発電機の起動停止を行い安定状態に落ち着いたことがグラフから読み取れる。そのときに、利潤が増大していることがわかる。これは、追加発電機の中の利潤効率の良いものを起動し、これまで使っていた利潤効率の低いものを停止したことを意味しており、自律的に起動停止問題を解き、利潤を最大化していることがわかる。また、これは、このシステムがスケーラブルであることを示しており、リソースの増減に対してプログラムの変更、処理の変更が全く必要ないことを意味している。これは、非常に有用な特性であり、本願発明が有効であることが確認できた。  以上より、本願発明は、起動コスト（起動による劣化）があってもなくても同じように有効に使用することができることがわかった。また、サーバの負荷分散というＩＴ分野だけでなく、発電機の起動停止での応用も可能であることがわかった。ちなみに、サーバの起動停止により、レスポンス、スループットが大きく変化するようなケースでは、実施例２のように原点近傍で評価関数が負になるようにすれば良い。
【実施例３】
【００１１】  本実施例は、実施例１と同様に、図１７のデータセンター７０のリソース負荷分散に対して本発明を適用したものである。実施例１では、レスポンスとスループットを制約条件として制御を行なったが、本実施例では、エネルギーを制約条件として制御を行なう。エネルギーを制約条件として用いることにより、運用の省電力化を図るものである。本実施例も基本的には評価関数の設定の問題となる。  ここで、筋肉の効率の式を参考にして、機能ブロックＢｉが状態λで動作するときのエネルギー効率ｆｉ（λ）を次の式８のように記述する。2013146395.tif 000008
アイドリング時の消費電力をＨｄｅｆ、仕事時消費電力をＷ（λ）、仕事時追加消費電力（空冷ファンなど）をＨとする。  一般的には、この効率はλｍａｘ以下のどこかでピークを迎える凸関数になるので、λｍａｘ以下は式８を評価関数として使用すれば良い。このエネルギー効率の式では、λｍａｘ以上の仕事量は定義できないので、ここでは人為的に定めることとする。  図２５にこのようにして定めた評価関数のイメージの例を示す。λｍａｘより大きな仕事量における評価関数は、運用者が好みで設定してしまっても良い。例えば、レスポンス重視なら、早く仕事量を減らしたいので、急な斜面にしておけば良いし、スループット重視であれば、仕事量をいきなり減らさなくてもいいので、傾きが緩やかな曲線を描いてやれば良い。このように、評価関数は運用者が自在に作っていけるのである。  注意点としては、自在に作れる分、評価関数により適正にされていくものが、客観的定量性をもって適正化されているかを言及できなくなる場合がある。例えば、今回の場合、λｍａｘ以下では定量的なエネルギー効率の関数であるが、λｍａｘ以上は運用者の快適度のような定性的な関数となる。どうしても客観的定量性が必要なときは、客観的な指標を使う、または客観的な指標に変換できるものを考えていく必要がある。しかしながら、これまでのシステムの運用は管理者の経験や、好みで運用されている場合も多く、定性的な意味の評価関数で運用できるというのは、管理者の好みで運用できることでもあるので、むしろ有益な特性であると言える。  また、本実施例はエネルギーを適正にしようとしているが、実施例２のように起動コストによる原点付近の負領域を持つ評価関数を使用しなかった。起動コストを考えるべきか否かも管理者の判断で決めれば良い。ここでは、λｍａｘ以上の仕事を定義している。したがって、ここでのλｍａｘは装置の本当の限界ではない。一般的に装置を本当の限界で使用することは少なく、ある程度割り引いたところに実用的な限界を設定している。その限界を超えたところからは、できれば回復させるべきで、本実施例はその一例である。  上述した評価関数を用いて、実施例１と同様の構成でデータセンター７０の負荷分散の実験を行った。図２６に実験結果を示す。今回の例では、最初すべてのサーバ（１０００台）を動作させておき、その後、エネルギー効率、動作するサーバの台数がどうなるかを見た。図からわかるように、最初はすべてのサーバが動作することにより、無駄なエネルギーを消費していたが、自律的に起動するサーバを選択、負荷を分散させることで、消費エネルギーを減らしていることが確認できる。つまり、データセンター７０の省電力化を図る上で本発明が有効であることが確認できた。
【実施例４】
【００１２】  本実施例では、実施例１で説明したレスポンスまたはスループットを重視した制御と、実施例３で説明したエネルギー効率を重視した制御を状況依存的に切り替える手法を説明する。基本的には実施例１と同様のデータセンターの構成で実験を行ったが、１点異なるのが、状況依存的に評価関数を切り替える命令をだす評価関数切替部を設置しているところである。  本実施例のシステム概略図を図２７に示す。データセンター９０は、図１７のデータセンター７０に対応する。サーバｓ１、ｓ２、…、ｓｎは、それぞれ機能ブロックＢ１、Ｂ２、…、Ｂｎ、及び、状態制御装置Ｃ１、Ｃ２、…、Ｃｎに対応し、データ通信ネットワークを介して互いに接続されている。状態λ１、λ２、…、λｎは、それぞれサーバｓ１、ｓ２、…、ｓｎに到着した１秒当たりの処理要求の件数である。更に、データセンター９０は評価関数切替部９１を備える。  本実施例では、サーバｓ１、ｓ２、…、ｓｎのそれぞれについて、２種類の評価関数を用意する。即ち、実施例１にて説明した、レスポンス及びスループットを制約条件とした図１８のような評価関数と、実施例３にて説明した、エネルギーを制約条件とした図２５のような評価関数とを用意し、状態制御装置の記憶装置に格納しておく。そして、評価関数切替部９１は、サーバｓ１、ｓ２、…、ｓｎに対し、用いる評価関数ｆ１、ｆ２、…、ｆｎを切り替える命令を送信する。この切替命令に応じて、状態制御装置Ｃ１、Ｃ２、…、Ｃｎは、それぞれ切替命令に応じた評価関数に基づいて、起動停止制御及び負荷分散制御を実行する。  切替信号は、管理者の入力操作に基づいて選択された評価関数への切替を指示するものであってもよい。或いは、何らかの外部入力から状況を判断する不図示の判別器をデータセンター９０に更に設けることとし、その判別器を使って自動的に選択された評価関数を指定するものであってもよい。  本実施例では、評価関数切替部９１は２種類の評価関数を切り替えることとしたが、３種類以上の評価関数を用意して、そのうちのいずれかを用いることとしてもよい。また、本実施例では、データセンター９０の全体につきひとつの評価関数切替部を設ける構成としたが、各サーバに１機の評価関数切替部を設けることとしてもよい。  データセンター９０を用いて実験を行った結果を図２８に示す。評価関数切替部９１がある以外は実施例１、３と同様の条件である。グラフの横軸は時間であり、縦軸は、システム全体の実効的なレスポンス、エネルギー効率、起動しているサーバの数である。最初は、レスポンス重視で動作させ、途中で（図中矢印の部分）、エネルギー効率重視に切り替えた。すると、最初はレスポンスが高い値で、エネルギー効率はそれほど高くないが、エネルギー効率重視にすると、レスポンスは悪くなるが、エネルギー効率は高くなっていく。つまり、評価関数切替部を通じた評価関数の切り替えがうまく行っていることが確認できた。  また、この実施例より、管理者は複数の要件（レスポンス重視、エネルギー重視など）があった場合でも、プログラムの変更、処理の変更なしで、適宜システムの動作目標の変更を指示するだけで、システムの動作を変更できることがわかる。つまり、本願発明は、複数の���件が合った場合にも、有効に動作させることができ、本願発明が有効であることが確認できた。
【実施例５】
【００１３】  実施例１乃至４では、状態制御装置間のデータ通信に要する時間は無視できるほど短く、そのためネットワークによる遅延がレスポンスやスループットに影響を与えないことを前提としていた。こうしたネットワーク遅延を考慮した実施例について説明する。  図２９に示すように、本実施例のネットワークシステム１００は、ネットワークを介して互いに接続された複数のデータセンター１００−１、１００−２、…、１００−Ｎ（Ｎは２以上の自然数）からなる。データセンター１００−１、１００−２、…、１００−Ｎは、それぞれが上述のデータセンター７０に相当するデータセンターであり、ネットワークによる遅延が無視できないほど互いに離れている。  ネットワークシステム１００では、リソースがひとつのデータセンター内に閉じていないため、ネットワークによる遅延を無視することができない。したがって、レスポンス、スループットを考えるとき、処理要求を行うデータセンター（命令された処理をメインで実施しているデータセンター）からの距離（遅延）も勘案してリソースの負荷分散を行なう必要がある。  本実施例では、レスポンス重視の制御を行なうものとし、実施例１と同じ規格化評価関数に対し、そのサーバの性能に応じた係数αｉを乗じたものを各サーバの評価関数とする。処理要求を行うデータセンターからの距離（遅延）をどのように勘案するかであるが、処理要求を行うデータセンターからの伝達遅延量Ｄｌｙとしたときに、次の式９から求めた係数を、各データセンター内の要素（リソース）の性能係数αｉに加えて、規格化評価関数に乗算する。2013146395.tif 000009
これにより、各リソースが、近くのデータセンターでは比較的高い性能、遠くのデータセンターでは比較的低い性能として認知され、遅延のあるネットワーク越しでも好適なリソースの負荷分散が実施される。  ネットワークシステム１００において実験を行った結果を図３０に示す。グラフの横軸は時間、縦軸は、ネットワークシステム１００全体の実効的なレスポンス、ネットワークシステム１００全体で起動しているサーバの数である。本実験は、処理要求を行うデータセンター１００−１の比較的近い位置にある他データセンターに、処理能力が格段に高いリソースが沢山ある状況にて行なった。この状況では、ネットワークによる遅延を考慮しても、他データセンターのリソースを使用したほうが良いと考えられる。  図中の矢印の時刻までは、単一のデータセンター、即ち、処理要求を発したデータセンター１００−１だけで処理を行っている。ここまでの間、データセンター１００−１は他のデータセンター１００−２、１００−３、…、１００−Ｎと通信を行なっていない。図中の矢印の時刻にて、データセンター１００−１は他のデータセンターと通信を開始した。その後、データセンター１００−１は周りのデータセンターとネットワーク的に結合して連係動作した。  図３０によると、データセンター１００−１を他のデータセンターと連携させると、レスポンスに変化は見られないものの、起動リソース数が減少したことが見て取れる。これは、データセンター１００−１内においては比較的処理能力が低いサーバが自律的に停止する一方で、周辺の他データセンターにおいては比較的処理能力が高いサーバが自律的に起動して処理を開始したことによる。結果として、データセンター１００−１内の処理能力が低い多数のサーバで行なっていた処理を、周辺データセンターの処理能力が高い少数のサーバで行なうようになった。つまり、ネットワークシステム１００は、レスポンス能力を維持したまま、起動するリソースの数を自律的に減らしたのである。  このように、遅延のあるネットワークで結合された要素（リソース）においても、本願発明が有効であることが確認された。今後、クラウド間の連携が議論されてきた場合、本願発明を使用する意味は大きい。
【実施例６】
【００１４】  これまでの実施例では、レスポンス、スループット、エネルギーといった処理に関するリソースの負荷分散について記述してきたが、本願発明の適用例はそれだけに止まらない。本実施例では、ストレージの負荷分散に使用した実施例を説明する。  この実施例で使用したストレージセンター１１０の概略図を図３１に示す。ストレージｓ１、ｓ２、…、ｓｎはそれぞれ、図１の機能ブロックＢ１、Ｂ２、…、Ｂｎに対応し、それぞれ不図示の状態制御装置Ｃ１、Ｃ２、…、Ｃｎを備える。更に、ストレージセンター１１０は不図示の評価関数切替部を備える。状態制御装置Ｃ１、Ｃ２、…、Ｃｎ及び評価関数切替部はデータ通信ネットワークを介して互いに接続されている。状態λ１はストレージｓ１に１秒間に到着した記録要求の大きさ（ＧＢ／秒）である。  本実施例でも評価関数をどうするかが重要なポイントとなるが、図３２に示す評価関数ｆ（λ）を使用すれば良い。横軸のλはストレージ量（記録量）である。縦軸は、規格化されているが、この規格化評価関数にストレージの性能に比例した係数αｉを乗算する。この場合の性能とは記録スピード、アクセス性、アーカイブ性（保存性）などを勘案して決定すればよい。  本実施例では、記録スピード優先、アーカイブ性優先といった、ストレージセンター１１０の制御方針毎に、係数αｉを用意し、採用する制御方針に応じて係数αｉを変更する。即ち、状態制御装置Ｃｉ（１≦ｉ≦ｎ）の記憶装置に、記録スピード優先時の係数αｉｓ、アーカイブ性優先時の係数αｉａを予め格納しておく。各状態制御装置は、評価関数切替部からの指示に応じて、規格化評価関数に乗算する係数を変更する。同様に評価関数切替部を備える実施例４では、評価関数の全体を変更したが、本実施例では規格化評価関数はそのままに、係数αｉのみを変更する。係数αｉの変更によって、ストレージセンター１１０は制御方針に沿ってストレージにデータを移していく。このように評価関数の設定は非常に自由であることが、本願発明の大きな利点のひとつとなっている。  ストレージセンター１１０で負荷分散の実験を行なった。当初、ストレージセンター１１０は記録スピード優先の制御方針で制御している。このとき、ストレージセンター１１０の各ストレージの状態制御装置は、規格化評価関数ｆｉに記録スピード優先の係数αｉｓを乗算して得られる評価関数に従ってそのストレージを制御している。時刻ｔにおいて、評価関数切替部はストレージセンター１１０の各ストレージに対してアーカイブ性優先の係数αｉａに切り替えるように各ストレージの状態制御装置に通知した。本通知に応じて、各ストレージの状態制御装置は、以後、規格化評価関数ｆｉに記録スピード優先の係数αｉａを乗算して得られる評価関数に従ってそのストレージを制御した。  この実験において、ストレージセンター１１０を構成する２つのストレージでの記録データ量の時間変化は図３３、３４のグラフのようになった。図３３はストレージセンター１１０を構成するストレージの中で、記録スピードが優れているストレージに関するグラフであり、図３４は同じくストレージセンター１１０を構成するストレージの中で、アーカイブ性が高いストレージに関するグラフである。ど���らのグラフも横軸は時間であり、縦軸はそのストレージに記録されているデータ量である。  図を見るとわかるとおり、時刻ｔ以降では、アーカイブ性の高いストレージの容量が増え、高速性の高いストレージの記録量が減っている。つまり、自律的に管理者の意図をシステムが実現しているのである。このほうに、本願発明は、何らかの（要素）リソースが関連して存在（ネットワークで結合）していれば様々な分野で同じように使用できる。この実施例ではそれが確認されたことになる。  尚、本実施例では、評価関数切替部を設け、各ストレージにつきひとつの規格化評価関数と、複数の係数αを用意することにより、実質的にひとつのストレージにつき複数の評価関数を用意して制御を行なったが、ひとつのストレージにつきひとつの評価関数を用意して制御することも当然に可能である。
【実施例７】
【００１５】  これまでの実施例は、評価関数を管理者が予め設定する、あるいは供給するという形をとっていた。つまり、やや固定化された評価関数であった。また、定量的に実際の効率などと完全にマッチしているかどうか保証していないものもあった。本実施例では、その評価関数を徐々に実際のものに定量的に近づけてしまう方法について説明する。エネルギー効率は実測できる量なので、エネルギー効率に関わる評価関数を徐々に実際に即して変更する方法について述べる。エネルギー効率に関する実施例なので、実施の形態としては実施例３と同様に、図１７のデータセンター７０のリソース負荷分散に対してエネルギーを制約条件として制御を行なう。  本実施例では、図９の状態制御装置７０Ｃｉに代わって図３５の状態制御装置１２０Ｃｉを用いる。状態制御装置１２０Ｃｉは、状態制御装置７０Ｃｉの各機能ブロックに加えて、評価関数修正部１２１Ｃｉを備える。評価関数修正部１２１Ｃｉは、機能ブロックＢｉの評価関数に相当する値を測定し、その測定値に基づいて、機能ブロックＢｉに対して予め定められていた評価関数ｆｉを更新する。これにより、時間の経過に伴い、状態制御装置が参照する評価関数を対応する機能ブロックの現実の評価関数に徐々に近づけていく。  図３６を参照して評価関数修正部１２１Ｃｉによる評価関数の修正処理について説明する。状態制御装置１２０Ｃｉには予め評価関数ｆｉの初期値が定められている（ステップＳ１）。評価関数修正部１２１Ｃｉは、機能ブロックＢｉから評価関数ｆｉに対応する値を測定し、この測定値と、機能ブロックＢｉに予め定められた評価関数ｆｉとの差εを求め（ステップＳ２）、差εが所定値以上の場合は所定のゲインＧと差εの積Ｇεだけ評価関数ｆｉを修正（ステップＳ３、Ｓ４）し、差εが所定値よりも低い場合は処理を終了する（ステップＳ３、Ｓ５）。  機能ブロックＢ１、Ｂ２、…、Ｂｎのそれぞれに状態制御装置１２０Ｃ１、１２０Ｃ２、…、１２０Ｃｎを設けたデータセンターシステムにおいて、エネルギーを制約条件とした制御を行なった実験の結果を図３７に示す。状態制御装置１２０Ｃ１、１２０Ｃ２、…、１２０Ｃｎがそれぞれ評価関数修正部１２１Ｃ１、Ｃ２、…、Ｃｎを備える点以外は実施例３と同じ条件である。グラフの横軸は時間であり、縦軸はエネルギー効率である。グラフを見ると時間の経過と共にエネルギー効率が改善していることがわかる。この結果から、評価関数のダイナミックな調整も可能であることが分かった。
【実施例８】
【００１６】  これまでの実施例では、データセンター、発電機ネットワーク、ストレージセンターを制御するものであったが、本発明の適用はこれらに限定されるものではなく、複数の機能ブロックを協調動作させるようなシステム一般に適用することができる。本実施例はロボット等のアクチュエータの制御に本発明を適用したものである。  図３８を参照して本実施例の冗長筋骨格系１３０について説明する。冗長筋骨格系１３０は、６筋２関節２リンク、即ち、６つの筋肉部１３１〜１３６と、２つの関節１３７、１３８、２つのリンク１３９、１４０を備える人間の手のモデルである。このモデルは２次元平面での腕の動きを良く再現することができる。  所望の手先（リンク１４０の先端）の動きを設定すれば、関節のトルクが計算できる。関節のトルクと各筋肉の収縮には関係があるので、筋肉の収縮を設定すれば、トルクへの影響を見積もることができる。しかしながら、冗長筋骨格系１３０では、筋肉の自由度の方が関節の自由度より大きいので、所望の関節のトルクを実現するための各筋肉の収縮力の値は一義的に決まらない。つまり、様々な筋肉の収縮力のセットが解となってしまう。このような問題を解が一義的に決まらない不良設定問題と呼ぶ。  このような場合、筋肉の収縮力を一義的に決定するために、拘束条件を設定するのが有効である。本願発明者は、筋肉の効率を最小にするように筋肉の収縮力のセットを決めるべきと考えている。これはエネルギー的にメリットがあるからである。そのような場合、この問題は、発明者が考案した「起動停止問題」、つまり負荷分散の問題となる。どの筋肉を動かせば（これが負荷に相当）、最も効率が良く制御できるかという問題になるのである。  本実施例では、筋肉１３１、１３２、…、１３６をそれぞれ機能ブロックＢ１、Ｂ２、…、Ｂ６とする。状態制御装置Ｃ１、Ｃ２、…、Ｃ６は対応する筋肉を制御する不図示の装置であるが、これら装置は各機能ブロックを上述の実施形態のように制御するものであれば、必ずしも筋肉１３１、１３２、…、１３６と一対一に対応する装置として設ける必要はなく、例えば並列処理可能なひとつの処理装置にて各筋肉を制御するものであってもよい。本実施例では機能ブロックＢ１、即ち筋肉１３１が発生する収縮力を、機能ブロックＢ１の状態λ１とする。筋肉１３２〜１３６についても収縮力を状態λ２〜λ６とする。  本発明によればリアルタイムに負荷分散を実施できるので、ロボットなどの制御機器の制御には非常に有効である。本実施例は腕の例を提示しているが、ロボットの脚でも同様の制御が出来る。脚を考えると、リアルタイム性がいかに重要であるかが簡単にわかるであろう。負荷分散を計算している時間が長ければ、計算の間にロボットは転んでしまうからである。  本発明をロボットの腕の制御に応用するために各筋肉の評価関数を設定した。本実施例では、筋肉の効率の最大化を図るため、筋肉１３１〜１３６が発生する収縮力λ１〜λ６における効率を、評価関数ｆ１〜ｆ６とする。一般的に、筋肉の効率の式は以下のように記述される。デフォルトの消費エネルギーをＨｄｅｆ、仕事時消費エネルギーをＷ（λ）、仕事時追加消費エネルギーをＨとすると、次の式１０のようになる。2013146395.tif 000010
一般的には、この効率はλｍａｘ（この場合、筋収縮の最大値）以下のどこかでピークを迎える凸関数になる。  このモデルを使い、ロボットの腕を制御して、目標位置に手先を移動させる制御を実施した結果を図３９に示す。目標軌道をほぼトレースし、目標位置に手先が到達している。つまり、制御がうまく機能していることがわかった。  実施形態及び実施例にて説明したように、本願発明は、発電機、データセンター、ロボット等、非常に広範な制御機器を統一的、かつ効率的に扱う手法であることが確認できた。  以上、本発明について実施の形態及び実施例に即して説明したが、これらは例示であり、本発明はこれらに限定されるものではない。  実施例では、発電機の起動停止問題、データセンターの負荷分散（起動停止問題）、ストレージの負荷分散（起動停止問題）に対し、本発明を応用したものについて主に説明したが、特に実施例８にて説明したように、本発明は、情報分野、インフラ分野に限定されず、何らかの（要素）リソースが関連して存在（ネットワークで結合）していれば様々な分野で同じように使用できる。  ロボットなどの制御分野では、腕の実施例を示したが、当然、ロボットの脚、体にも応用できる。また、蛇型ロボットなど、人型でないものでも同様である。車輪が４個の車では負荷分散の効果は少ないが、車輪が沢山あるような車などがあれば、その車輪の負荷分散にも適用できる。被制御体より、制御体の自由度が大きいような制御には基本的にどのような場合でも適用でき、大きな効果を上げる。  状態制御装置間の接続形態についていえば、システム内の各状態制御装置が他の状態制御装置すべてと通信することとしてもよいし、システム内の一部の状態制御装置とのみ通信を行なうような状態制御装置が存在してもよい。他の状態制御装置ひとつだけと接続された状態制御装置からの情報もいずれはネットワークを介して他の全ての状態制御装置に伝搬されるからである。システム内の状態制御装置が構成するネットワークの形態は、特に限定されるものではなく、例えば、システム内にハブ装置を設け、スター型のネットワークトポロジで状態制御装置間を接続することとしてもよい。  実施例８で説明したように、状態制御装置は必ずしも機能ブロックと一対一に設ける必要はない。図４０に示すように、状態制御装置Ｃ１、Ｃ２、…、Ｃｎに対応する制御を行なう状態制御部Ｃ１、Ｃ２、…、Ｃｎを備える状態制御装置１５１をシステム全体にひとつ設け、各状態制御部が対応する機能ブロックを制御することによっても、本発明の起動停止制御及び負荷分散制御を行なうことができることは、当業者には明らかであろう。  上記の実施形態及び実施例の一部又は全部は以下の付記のようにも記載されうるが、これらに限定されるものではない。（付記１）  システムを構成するｎ個（ｎは２以上の自然数）の機能ブロックそれぞれに対応して設けられる状態制御装置であって、ｉ、ｊが１≦ｉ、ｊ≦ｎ、ｉ≠ｊである任意の自然数であるとき、機能ブロックＢｉに対応する状態制御装置Ｃｉは、  機能ブロックＢｉの状態を示す状態λｉを機能ブロックＢｉから取得する手段と、  機能ブロックＢｉの性能に応じて予め定められた関数ｆｉを機能ブロックＢｉの評価関数とする���き、評価関数ｆｉに基づいてＵｉ及びＶｉを求める手段と、  状態制御装置ＣｊにＶｉを送信する手段と、  状態制御装置Ｃｊに対応する機能ブロックＢｊの性能に応じて予め定められた関数ｆｊを機能ブロックＢｊの評価関数とするとき、評価関数ｆｊに基づいて求めたＷｊを、状態制御装置Ｃｊから受信する手段と、  Ｕｉ及びＷｊに応じて、状態λｉの変動分と、状態λｊの変動分の和がゼロになるように機能ブロックＢｉを制御する制御手段とを備えることを特徴とする状態制御装置。（付記２）  前記評価関数ｆｉ、ｆｊ、状態λｉ、λｊをそれぞれ総称して評価関数ｆ、状態λと呼ぶとき、評価関数ｆは、状態λを横軸とし、関数ｆの値を縦軸として描いた曲線が上または下に凸であるような関数であることを特徴とする付記１に記載の状態制御装置。（付記３）  Ｕｉは評価関数ｆｉと横軸の交点であるゼロクロス点の横軸座標λ０，ｉであり、  Ｖｉは前記ゼロクロス点での評価関数ｆｉの傾きｇ０、ｉであり、  評価関数ｆｊにおいて傾きがｇ０，ｉと一致する点の横軸座標をｚｉｊとするとき、Ｗｊはλｊ−ｚｉｊであり、  制御手段はＳｉ＝Σ（λｊ−ｚｉｊ）−λ０，ｉとゼロとの比較結果に応じて機能ブロックＢｉを起動或いは停止することを特徴とする付記１及び付記２のいずれかに記載の状態制御装置。（付記４）  Ｕｉ及びＶｉはｄｆｉ／ｄλｉであり、  Ｗｊはｄｆｊ／ｄλｊであり、  制御手段はｄλｉ／ｄｔ＝Ｋ１（ｄｆｉ／ｄλｉ−ｄｆｊ／ｄλｊ）に従って機能ブロックＢｉを制御することを特徴とする付記１及び付記２のいずれかに記載の状態制御装置。（付記５）  複数の他の状態制御装置Ｃｊ１、Ｃｊ２、…、Ｃｊｍ（ｊ１、ｊ２、…ｊｍはｉ以外の自然数、２≦ｍ≦ｎ）それぞれに対してＶｉを送信し、かつ、  前記複数の他機能ブロックＣｊ１、Ｃｊ２、…、ＣｊｍそれぞれからＷｊ１、Ｗｊ２、…、Ｗｊｍを受信することを特徴とする付記１乃至付記４のいずれかに記載の状態制御装置。（付記６）  制御手段は、Ｕｉ及びＷｊ１に応じて定められる一の方程式に基づく制御、Ｕｉ及びＷｊ２に応じて定められる一の方程式に基づく制御、…、Ｕｉ及びＷｊｍに応じて定められる一の方程式に基づく制御を、機能ブロックＢｉに対して順不同に逐次行なうことを特徴とする付記５に記載の状態制御装置。（付記７）  制御手段は、Ｕｉ及びＷｊ１、Ｗｊ２、…、Ｗｊｍに応じて定められる一の方程式に従って機能ブロックＢｉを制御することを特徴とする付記５に記載の状態制御装置。（付記８）  評価関数は対応する機能ブロックの効率に関することを特徴とする付記１乃至付記７のいずれかに記載の状態制御装置。（付記９）  複数の評価関数の中から予め定められた条件に応じて選択された一の評価関数に基づいて機能ブロックを制御することを特徴とする付記１乃至付記８のいずれかに記載の状態制御装置。（付記１０）  複数の評価関数の中から予め定められた条件に応じて一の評価関数を選択する評価関数切替手段を更に備えることを特徴とする付記１乃至付記８のいずれかに記載の状態制御装置。（付記１１）  評価関数の値に対応する値を測定する手段と、測定値に基づいて評価関数を修正する手段とを更に備える付記１乃至付記１０のいずれかに記載の状態制御装置。（付記１２）  前記システムは伝達遅延量を求める際の起点となるノードを備え、  機能ブロックＢｉの性能、及び、前記起点ノードと機能ブロックＢｉとの間で行なうデータ通信にて生じる伝送遅延量に応じて定められた評価関数に基づいて機能ブロックＢｉを制御することを特徴とする付記１乃至付記１１のいずれかに記載の状態制御装置。（付記１３）  前記起点ノードは、前記ネットワークシステム内に設けられた入出力端末であることを特徴とする付記１２に記載の状態制御装置。（付記１４）  機能ブロックＢｉはそれぞれコンピュータであり、λはそのコンピュータに割り当てられた仕事量である付記１乃至付記１３のいずれかに記載の状態制御装置。（付記１５）  機能ブロックＢｉはそれぞれコンピュータであり、λはそのコンピュータの消費電力である付記１乃至付記１３のいずれかに記載の状態制御装置。（付記１６）  機能ブロックＢｉはそれぞれ記憶装置であり、λはその記憶装置に記憶されているデータ量である付記１乃至付記１３のいずれかに記載の状態制御装置。（付記１７）  機能ブロックＢｉはそれぞれ発電機であり、λはその発電機の発電量である付記１乃至付記１３のいずれかに記載の状態制御装置。（付記１８）  機能ブロックＢｉはそれぞれアクチュエータであり、λはそのアクチュエータが発生する力である付記１乃至付記１３のいずれかに記載の状態制御装置。（付記１９）  付記１乃至付記１８のいずれかに記載の状態制御装置を備える機能ブロック。（付記２０）  付記１９に記載の機能ブロックをノードとして備えるネットワークシステム。（付記２１）  システムを構成するｎ個（ｎは２以上の自然数）の機能ブロックそれぞれに対応する状態制御装置を用いて各機能ブロックを制御する方法であって、ｉ、ｊが１≦ｉ、ｊ≦ｎ、ｉ≠ｊである任意の自然数であるとき、機能ブロックＢｉに対応する状態制御装置Ｃｉが、  機能ブロックＢｉの状態を示す状態λｉを機能ブロックＢｉから取得する段階と、  機能ブロックＢｉの性能に応じて予め定められた関数ｆｉを機能ブロックＢｉの評価関数とするとき、評価関数ｆｉに基づいてＵｉ及びＶｉを求める段階と、  状態制御装置ＣｊにＶｉを送信する段階と、  状態制御装置Ｃｊに対応する機能ブロックＢｊの性能に応じて予め定められた関数ｆｊを機能ブロックＢｊの評価関数とするとき、評価関数ｆｊに基づいて求めたＷｊを、状態制御装置Ｃｊから受信する段階と、  Ｕｉ及びＷｊに応じて、状態λｉの変動分と、状態λｊの変動分の和がゼロになるように機能ブロックＢｉを制御する制御段階とを含むことを特徴とする制御方法。（付記２２）  前記評価関数ｆｉ、ｆｊ、状態λｉ、λｊをそれぞれ総称して評価関数ｆ、状態λと呼ぶとき、評価関数ｆは、状態λを横軸とし、関数ｆの値を縦軸として描いた曲線が上または下に凸であるような関数であることを特徴とする付記２１に記載の制御方法。（付記２３）  Ｕｉは評価関数ｆｉと横軸の交点であるゼロクロス点の横軸座標λ０，１であり、  Ｖｉは前記ゼロクロス点での評価関数ｆｉの傾きｇ０、ｉであり、  評価関数ｆｊにおいて傾きがｇ０，ｉと一致する点の横軸座標をｚｉｊとするとき、Ｗｊはλｊ−ｚｉｊであり、  制御段階ではＳｉ＝Σ（λｊ−ｚｉｊ）−λ０，ｉとゼロとの��較結果に応じて機能ブロックＢｉを起動或いは停止することを特徴とする付記２１及び付記２２のいずれかに記載の制御方法。（付記２４）  Ｕｉ及びＶｉはｄｆｉ／ｄλｉであり、  Ｗｊはｄｆｊ／ｄλｊであり、  制御段階ではｄλｉ／ｄｔ＝Ｋ１（ｄｆｉ／ｄλｉ−ｄｆｊ／ｄλｊ）に従って機能ブロックＢｉを制御することを特徴とする付記２１及び付記２２のいずれかに記載の制御方法。（付記２５）  複数の他の状態制御装置Ｃｊ１、Ｃｊ２、…、Ｃｊｍ（ｊ１、ｊ２、…ｊｍはｉ以外の自然数、２≦ｍ≦ｎ）それぞれに対してＶｉを送信し、かつ、  前記複数の他機能ブロックＣｊ１、Ｃｊ２、…、ＣｊｍそれぞれからＷｊ１、Ｗｊ２、…、Ｗｊｍを受信することを特徴とする付記２１乃至付記２４のいずれかに記載の制御方法。（付記２６）  制御段階では、Ｕｉ及びＷｊ１に応じて定められる一の方程式に基づく制御、Ｕｉ及びＷｊ２に応じて定められる一の方程式に基づく制御、…、Ｕｉ及びＷｊｍに応じて定められる一の方程式に基づく制御を、機能ブロックＢｉに対して順不同に逐次行なうことを特徴とする付記２５に記載の制御方法。（付記２７）  制御段階では、Ｕｉ及びＷｊ１、Ｗｊ２、…、Ｗｊｍに応じて定められる一の方程式に従って機能ブロックＢｉを制御することを特徴とする付記２５に記載の制御方法。（付記２８）  評価関数は対応する機能ブロックの効率に関することを特徴とする付記２１乃至付記２７のいずれかに記載の制御方法。（付記２９）  複数の評価関数の中から予め定められた条件に応じて選択された一の評価関数に基づいて機能ブロックを制御することを特徴とする付記２１乃至付記２８のいずれかに記載の制御方法。（付記３０）  複数の評価関数の中から予め定められた条件に応じて一の評価関数を選択する評価関数切替段階を更に含むことを特徴とする付記２１乃至付記２８のいずれかに記載の制御方法。（付記３１）  評価関数の値に対応する値を測定する段階と、測定値に基づいて評価関数を修正する段階とを更に含む付記２１乃至付記３０のいずれかに記載の制御方法。（付記３２）  前記システムは伝達遅延量を求める際の起点となるノードを備え、  機能ブロックＢｉの性能、及び、前記起点ノードと機能ブロックＢｉとの間で行なうデータ通信にて生じる伝送遅延量に応じて定められた評価関数に基づいて機能ブロックＢｉを制御することを特徴とする付記２１乃至付記３１のいずれかに記載の制御方法。（付記３３）  前記起点ノードは、前記ネットワークシステム内に設けられた入出力端末であることを特徴とする付記３２に記載の制御方法。（付記３４）  機能ブロックＢｉはそれぞれコンピュータであり、λはそのコンピュータに割り当てられた仕事量である付記２１乃至付記３３のいずれかに記載の制御方法。（付記３５）  機能ブロックＢｉはそれぞれコンピュータであり、λはそのコンピュータの消費電力である付記２１乃至付記３３のいずれかに記載の制御方法。（付記３６）  機能ブロックＢｉはそれぞれ記憶装置であり、λはその記憶装置に記憶されているデータ量である付記２１乃至付記３３のいずれかに記載の制御方法。（付記３７）  機能ブロックＢｉはそれぞれ発電機であり、λはその発電機の発電量である付記２１乃至付記３３のいず��かに記載の制御方法。（付記３８）  機能ブロックＢｉはそれぞれアクチュエータであり、λはそのアクチュエータが発生する力である付記２１乃至付記３３のいずれかに記載の制御方法。（付記３９）  システムを構成するｎ個（ｎは２以上の自然数）の機能ブロックそれぞれに対応するコンピュータを用いて各機能ブロックを制御するためのプログラムであって、ｉ、ｊが１≦ｉ、ｊ≦ｎ、ｉ≠ｊである任意の自然数であるとき、機能ブロックＢｉに対応するコンピュータＣｉに、  機能ブロックＢｉの状態を示す状態λｉを機能ブロックＢｉから取得する手順と、  機能ブロックＢｉの性能に応じて予め定められた関数ｆｉを機能ブロックＢｉの評価関数とするとき、評価関数ｆｉに基づいてＵｉ及びＶｉを求める手順と、  状態制御装置ＣｊにＶｉを送信する手順と、  状態制御装置Ｃｊに対応する機能ブロックＢｊの性能に応じて予め定められた関数ｆｊを機能ブロックＢｊの評価関数とするとき、評価関数ｆｊに基づいて求めたＷｊを、状態制御装置Ｃｊから受信する手順と、  Ｕｉ及びＷｊに応じて、状態λｉの変動分と、状態λｊの変動分の和がゼロになるように機能ブロックＢｉを制御する制御手順とを実行させるためのプログラム。（付記４０）  前記評価関数ｆｉ、ｆｊ、状態λｉ、λｊをそれぞれ総称して評価関数ｆ、状態λと呼ぶとき、評価関数ｆは、状態λを横軸とし、関数ｆの値を縦軸として描いた曲線が上または下に凸であるような関数であることを特徴とする付記３９に記載のプログラム。（付記４１）  Ｕｉは評価関数ｆｉと横軸の交点であるゼロクロス点の横軸座標λ０，ｉであり、  Ｖｉは前記ゼロクロス点での評価関数ｆｉの傾きｇ０、ｉであり、  評価関数ｆｊにおいて傾きがｇ０，ｉと一致する点の横軸座標をｚｉｊとするとき、Ｗｊはλｊ−ｚｉｊであり、  制御段階ではＳｉ＝Σ（λｊ−ｚｉｊ）−λ０，ｉとゼロとの比較結果に応じて機能ブロックＢｉを起動或いは停止することを特徴とする付記３９及び付記４０のいずれかに記載のプログラム。（付記４２）  Ｕｉ及びＶｉはｄｆｉ／ｄλｉであり、  Ｗｊはｄｆｊ／ｄλｊであり、  制御段階ではｄλｉ／ｄｔ＝Ｋ１（ｄｆｉ／ｄλｉ−ｄｆｊ／ｄλｊ）に従って機能ブロックＢｉを制御することを特徴とする付記３９及び付記４０のいずれかに記載のプログラム。（付記４３）  複数の他の状態制御装置Ｃｊ１、Ｃｊ２、…、Ｃｊｍ（ｊ１、ｊ２、…ｊｍはｉ以外の自然数、２≦ｍ≦ｎ）それぞれに対してＶｉを送信し、かつ、  前記複数の他機能ブロックＣｊ１、Ｃｊ２、…、ＣｊｍそれぞれからＷｊ１、Ｗｊ２、…、Ｗｊｍを受信することを特徴とする付記３９乃至付記４２のいずれかに記載のプログラム。（付記４４）  制御段階では、Ｕｉ及びＷｊ１に応じて定められる一の方程式に基づく制御、Ｕｉ及びＷｊ２に応じて定められる一の方程式に基づく制御、…、Ｕｉ及びＷｊｍに応じて定められる一の方程式に基づく制御を、機能ブロックＢｉに対して順不同に逐次行なうことを特徴とする付記４３に記載のプログラム。（付記４５）  制御段階では、Ｕｉ及びＷｊ１、Ｗｊ２、…、Ｗｊｍに応じて定められる一の方程式に従って機能ブロックＢｉを制御することを特徴とする付記４３に記載のプログラム。（付記４６）  評価関数は���応する機能ブロックの効率に関することを特徴とする付記３９乃至付記４５のいずれかに記載のプログラム。（付記４７）  複数の評価関数の中から予め定められた条件に応じて選択された一の評価関数に基づいて機能ブロックを制御することを特徴とする付記３９乃至付記４６のいずれかに記載のプログラム。（付記４８）  複数の評価関数の中から予め定められた条件に応じて一の評価関数を選択する評価関数切替手順を更にコンピュータに実行させることを特徴とする付記３９乃至付記４６のいずれかに記載のプログラム。（付記４９）  評価関数の値に対応する値を測定する手順と、測定値に基づいて評価関数を修正する手順とを更にコンピュータに実行させる付記３９乃至付記４８のいずれかに記載のプログラム。（付記５０）  前記システムは伝達遅延量を求める際の起点となるノードを備え、  機能ブロックＢｉの性能、及び、前記起点ノードと機能ブロックＢｉとの間で行なうデータ通信にて生じる伝送遅延量に応じて定められた評価関数に基づいて機能ブロックＢｉを制御することを特徴とする付記３９乃至付記４９のいずれかに記載のプログラム。（付記５１）  前記起点ノードは、前記ネットワークシステム内に設けられた入出力端末であることを特徴とする付記５０に記載のプログラム。（付記５２）  機能ブロックＢｉはそれぞれコンピュータであり、λはそのコンピュータに割り当てられた仕事量である付記３９乃至付記５１のいずれかに記載のプログラム。（付記５３）  機能ブロックＢｉはそれぞれコンピュータであり、λはそのコンピュータの消費電力である付記３９乃至付記５１のいずれかに記載のプログラム。（付記５４）  機能ブロックＢｉはそれぞれ記憶装置であり、λはその記憶装置に記憶されているデータ量である付記３９乃至付記５１のいずれかに記載のプログラム。（付記５５）  機能ブロックＢｉはそれぞれ発電機であり、λはその発電機の発電量である付記３９乃至付記５１のいずれかに記載のプログラム。（付記５６）  機能ブロックＢｉはそれぞれアクチュエータであり、λはそのアクチュエータが発生する力である付記３９乃至付記５１のいずれかに記載のプログラム。
【符号の説明】
【００１７】Ｂ１、Ｂ２、…、Ｂｉ、…、Ｂｊ、…、Ｂｎ  機能ブロック（サーバ、発電機、ストレージ、筋肉等、ｎは２以上の自然数、１≦ｉ、ｊ≦ｎ、ｉ≠ｊ）Ｃ１、Ｃ２、…、Ｃｉ、…、Ｃｊ、…、Ｃｎ  状態制御装置３０Ｃｉ、４０Ｃｉ、５０Ｃｉ、６０Ｃｉ  状態制御装置３１Ｃｉ、４１Ｃｉ、６１Ｃｉ、６５Ｃｉ  評価関数処理部３２Ｃｉ、４２Ｃｉ、６２Ｃｉ  通信部３３Ｃｉ、４３Ｃｉ、５３Ｃｉ、６３Ｃｉ  制御信号生成部４４Ｃｉ、６４Ｃｉ  監視部７０、９０  データセンター９１  評価関数切替部１００  ネットワークシステム１００−１、１００−２、…、１００−Ｎ  データセンター（Ｎは２以上の自然数）１１０  ストレージセンター１２０Ｃｉ  状態制御装置１２１Ｃｉ  評価関数修正部１３０  冗長筋骨格系１３１〜１３６  筋肉部１３７、１３８  関節１３９、１４０  リンク  この出願は、２０１２年３月２９日に出願された日本出願特願第２０１２−０７５６５７号を基礎とする優先権を主張し、その開示のすべてをここに取り込むものである。
【図１】
2013146395.tif 000011
【図２】
2013146395.tif 000012
【図３】
2013146395.tif 000013
【図４】
2013146395.tif 000014
【図５】
2013146395.tif 000015
【図６】
2013146395.tif 000016
【図７】
2013146395.tif 000017
【図８】
2013146395.tif 000018
【図９】
2013146395.tif 000019
【図１０】
2013146395.tif 000020
【図１１】
2013146395.tif 000021
【図１２】
2013146395.tif 000022
【図１３】
2013146395.tif 000023
【図１４】
2013146395.tif 000024
【図１５】
2013146395.tif 000025
【図１６】
2013146395.tif 000026
【図１７】
2013146395.tif 000027
【図１８】
2013146395.tif 000028
【図１９】
2013146395.tif 000029
【図２０】
2013146395.tif 000030
【図２１】
2013146395.tif 000031
【図２２】
2013146395.tif 000032
【図２３】
2013146395.tif 000033
【図２４】
2013146395.tif 000034
【図２５】
2013146395.tif 000035
【図２６】
2013146395.tif 000036
【図２７】
2013146395.tif 000037
【図２８】
2013146395.tif 000038
【図２９】
2013146395.tif 000039
【図３０】
2013146395.tif 000040
【図３１】
2013146395.tif 000041
【図３２】
2013146395.tif 000042
【図３３】
2013146395.tif 000043
【図３４】
2013146395.tif 000044
【図３５】
2013146395.tif 000045
【図３６】
2013146395.tif 000046
【図３７】
2013146395.tif 000047
【図３８】
2013146395.tif 000048
【図３９】
2013146395.tif 000049
【図４０】
2013146395.tif 000050
【国際調査報告】
2013146395.tif 000051
2013146395.tif 000052