WO2012160978A1 - システムおよびシステムの制御方法 - Google Patents

Abstract

　本発明の課題は、確率論を用いず、また、各要素にまつわる関数だけを使用して、全体を協調動作可能なシステムを提供することにある。本発明のシステムは、相互に関係性を持つ複数の機能ブロックを有し、複数の機能ブロックは、それぞれに対応した評価関数を有する記憶部と、機能ブロック自身に関係を持つ他の機能ブロックの評価関数に関する情報によって、お互いの動作レベルを調整する利潤最大化制御部と、利潤最大化制御による動作レベルの抑制を、機能ブロックの起動状態、停止状態により調整する起動停止問題解決制御部と、各機能ブロックの動作レベルを複数機能ブロック全体で満たすべき拘束条件に基づき調整する拘束条件充足制御部と、を有する。

Description

システムおよびシステムの制御方法

　本発明は、複数の機能ブロックを有し、それらの機能ブロックを自律分散適応的に統合して動作可能なシステムに関する。

　現在、システムの大規模化、あるいはシステム化されていなかったものが突如大規模システム化するという現象が様々な領域で進展している。前者の代表的なものとしては、クラウドと呼ばれる技術に関係したデータセンター、ネットワークなどのＩＴ分野であり、これらは年々規模が大きくなっている。また、後者としては、電力、エネルギー網、都市といったインフラ領域であり、スマートグリット、スマートシティといった大規模システムの案件として突如制御対象になりつつある。したがって、大規模システムをいかに制御していくかは今後非常に重要な課題になることが予想される。
　ＩＴ分野におけるシステムで実施される制御としては、計算リソース、ネットワークの負荷分散、ストレージの配置分散などの制御が挙げられる。例えば、計算リソースの負荷分散制御がどのように行われているかを、複数サーバから構成されるデータセンター（ＤＣ）をターゲットとした負荷分散方式を例として説明する。
　従来の制御の基本的な発想は、「システムの内部状態をバランスさせる」という素朴なものに帰結される。このような発想の場合、一様なシステム（同一サーバが複数）の場合には、制御方針は明らかであるが、異機種混合型システムになると、どんな指標に基づいてバランスさせるべきなのかが明らかではない。例えば、同一性能のサーバの場合には、各サーバのＣＰＵ使用率をバランスさせれば良いということが知られている一方で、性能が異なるサーバの場合には、性能に応じたＣＰＵ使用率のバランス方法が自明ではない。従来よく使われる指針である待ち行列理論で得られる結果は、確率論に基づく指針であり、どのような手段を用いて確率的な定常状態にシステムを導くか自体は、何も教えてくれない。これは何を意味するかというと、レスポンスやスループットのような満たすべき要件を最終的には満たすことができるかもしれないが、途中のプロセスや最終的に使用されているリソースの状況に関しては何の保証、制約もないことを意味している。それは即ち、エネルギー的には非常に非効率な状態になっていてもとりあえず、性能を満たすという制御になっているということである。このような制御では、システムが大規模になればなるほど、このような非効率は大きくなっていき、大きな問題となることが予想される。
　また、昨今、スマートグリッドに代表されるインフラ領域の制御も注目を集めている。これは、エネルギーコンシャスな社会になってきたため、エネルギーの無駄を省く制御をきめ細かく実施したいという思いの他に、太陽エネルギーに代表される再生可能エネルギーが従来の電力網に接続されるという状況が発生してきたため、再生可能エネルギーを含めた全体システムとして電力網を制御しなければ、電力供給がむしろ不安定になってしまうためである。したがって、このような新たな制御対象に対する効率的な制御も重要な課題となってくる。
　システムの制御の手法を大きく分けると、中央集権型で制御していくか、自律分散型で制御していくかの２つに大別される。システムがそれほど大きくないときは中央集権型の方が管理しやすく、これまでは多くのシステムが中央集権型で制御されてきた。また、システムへの外乱が予想できる場合や、システムを構成する要素が想定できる場合も中央集権型の制御が適している。つまり、予想できる環境、全体を俯瞰できる規模であるならば、中央集権型の制御は非常に有効である。中央集権型の制御とは、システムの全体像を常に正確に把握し、それにより状況を判断し、アクションを決める制御である。平たく言えば、ｉｆ　ｔｈｅｎ　ｅｌｓｅでコードを規定していく方法である。
　しかしながら、昨今、システムの大規模化により、その中央集権型のシステムでは、大規模なシステムを扱いきれなくなっており、自律分散型のシステムの検討が盛んになっている。自律分散型の制御とは、リソースなどの要素が、要素間の関係だけを用いて動作する制御であり、正確な全体情報を必ずしも必要としない。システムが大規模になればなるほど、全体情報を正確に知ることは難しくなるので、自律分散型の制御が望まれてくる。また、スマートグリッドに代表される電力網などは、再生可能エネルギーがどのタイミングでシステムに入力されるか予測し難いため、中央集権型の制御ではリソース変化にリアルタイムで適応できない可能性がある。当然、ＩＴシステムも故障などの突発的な事故を考えれば、そのようなときを想定して中央集権型の制御をかけるより、自律的に事故を修復するようにリアルタイム動作する自律制御の方が望まれるわけである。これらの要求から、自律分散型の制御の検討が盛んになっている。
　自律分散システムと称する検討は非常に多いが、各要素が自律的、分散的に存在するだけで、全体として協調していないシステムが提案されていることが非常に多い。これは、本来の自律分散システムではない。各要素を自律的、分散的にするのは簡単だが、全体として協調する、あるいは全体最適を目指して動作するシステムでなければ意味がないからであり、自律分散的に全体最適を目指して動作するシステムこそ自律分散システムと呼ぶべきである。そのような本来の自律分散システムとはどういうものだろうか。
　実は、そのようなシステムは身近に存在し、生物、脳が実施しているシステムがまさに本当の自律分散システムである。したがって、昨今、生物、脳に学ぶ自律分散システムの研究が盛んである。
　その中でも、非常に興味深い検討として、「ゆらぎ方程式」を使った技術がある（「ゆらぎで技術革新」　大阪大学ゆらぎプロジェクト　２００８）。これは以下の式（１）、（２）に示すゆらぎ方程式をベースに各要素を制御していく技術である。

　ここで、Ａｃｔｉｖｉｔｙとはバイアスの一種でそのシステムが快適と感じる位置ｘで大きな値をとる関数である。また、ηはランダムなノイズ、Ｕはそのシステムを駆動するポテンシャルを意味する。
　ゆらぎ方程式と似た方程式に、以下の式（３）に示すランジェバン方程式というのがあるが、これらは一見似ているが、工学的見地から決定的な違いがある。

　ゆらぎ方程式とランジェバン方程式を比べると、Ａｃｔｉｖｉｔｙにしか違いがない。ある意味、ゆらぎ方程式は、ポテンシャルをＵとＡｃｔｉｖｉｔｙに分けて表現したに過ぎない印象を与えるが、これが決定的な差を生むのである。
　従来、何かを制御しようとして、ランジェバン方程式を使おうとすれば、ポテンシャルＵを正確に求めなくてはならなかった。非線形な複雑な問題に対して、ポテンシャルを求める問題は非常に難しく、解析的に解ける例は少ない。昨今流行の機械学習、強化学習なども実は、物理的にみると、あるシステムのポテンシャルを求めているのと同じであるが、ニューラルネットワークなどを用い、ブラックボックス的にポテンシャルを求めている。従来の技術で非線形な複雑な問題のポテンシャルを求めようとすると、ブラックボックス的に求めざるをえないのが現状である。
　いずれにせよ、ポテンシャルを求めるということは、モデルを設定することと同じなので、より複雑な動作を行おうとすると、ポテンシャル関数が非常に複雑になり、ひとつのポテンシャル関数では事象を表現しきれない問題が発生する。これを解決したのが、ゆらぎ方程式である。
　ゆらぎ方程式では、システムが感じる快適さをＡｃｔｉｖｉｔｙとして、ポテンシャル全体から切り離すことで、システムの動作をトップダウンで人間側が指定することができるようになる。どういうことかと言えば、システムに期待する動作を実現できるように、Ａｃｔｉｖｉｔｙを設定してやれば良い。例えば、ある位置にシステムを動かしたいとすると、所望の位置で値が最大となる関数をＡｃｔｉｖｉｔｙとして与えてやれば良い。所望の位置から遠い場合、式（１）の右辺第１項は小さな値となるので、右辺第２項のランダムノイズによって、システムの各要素が駆動される。システムの各要素を粒子と例えるなら、ブラウン運動のような状態である。所望の位置から遠い位置にあるシステムは、ブラウン運動のようなランダムな動きを行いながら、偶発的に所望の位置に近づくことがある。その際、式（１）の右辺第１項がＡｃｔｉｖｉｔｙ関数の作用により、大きな値をとる。すると、システムの動作を支配するのが、右辺第２項から右辺第１項に移る。右辺第１項がシステムを制御し始めると、後は自然とＡｃｔｉｖｉｔｙ最大となるポテンシャル位置にシステムは落ち込むのである。つまり、所望の位置に到達する。
　ここで大切なのは、ゆらぎ方程式を用いる場合は、トップダウンにＡｃｔｉｖｉｔｙを決定しているだけで、システムの各要素に対して特別な指令、制御をしないことである。システムの各要素には、式（１）の右辺の値に比例した出力を与えておけば良い。要素が複数あっても、同じように式（１）の右辺に比例した出力を与えておけば良いだけである。その際、各駆動部でのランダムノイズは独立にしておく。一方、Ａｃｔｉｖｉｔｙはすべての各要素で同じものを用いる。すると、各要素は個々の式（１）に従って単純に動作しているだけだが、全体を統括するＡｃｔｉｖｉｔｙの作用で、いつしかＡｃｔｉｖｉｔｙ最大の位置に動くように全体で協調動作するようになる。
　このように、ゆらぎ方程式を使うと、複数の要素を持つシステムでも、自律分散協調的に動作させることができる。例えば、特許文献１に示すように、この技術を使って、ネットワークの経路の自律分散制御が検討されており、自律的に障害を回避するなど、有効な結果が得られている（特許文献１）。

特開２００５−２８５０１６号公報

　上記したように、「ゆらぎ方程式」という有望な技術が検討されているが、２つの点で改善が必要と考えられる。ひとつは、確率的な制御になっているところである。即ち、式（１）ではランダムノイズを各要素の動力源として用いているため、必ずしも決定論的な動作を行わない。つまり、動作がそのときの確率によってしまい、場合によっては、冗長な制御となる。本来は、全体最適な状態を目指して、決定論的に動作して欲しいところである。
　また、もう一点は、Ａｃｔｉｖｉｔｙの設定に関してである。上記したように、この関数はトップダウンで人間が設定できるのだが、実は、全体最適の関数自体を人間が描けない場合も多いのである。人間が設定あるいは確認できるのは、各要素にまつわる関数だけであり、要素が協調した場合の状態を示す関数を描けない場合が実際はかなり多い。
　本発明は上記課題に鑑みてなされたものであり、その目的は、確率論を用いず、また、各要素にまつわる関数だけを使用して、全体を協調動作可能なシステムを提供することにある。

　前述した目的を達成するために、本発明の第１の態様は、相互に関係を持つ複数の機能ブロックを有し、複数の前記機能ブロックは、それぞれに対応した評価関数を有する記憶部と、各機能ブロックの動作レベルを複数の前記機能ブロック全体で満たすべき拘束条件に基づき制御する拘束条件充足制御部と、前記機能ブロックに関係を持つ他の機能ブロックの前記評価関数に関する情報によって、互いの動作レベルを制御する利潤最大化制御部と、前記機能ブロックの動作レベルに応じて、前記拘束条件充足制御部および前記利潤最大化制御部の制御結果を用いて、前記機能ブロックの起動状態、停止状態を制御する起動停止問題解決制御部と、を有することを特徴とするシステムである。
　本発明の第２の態様は、第１の態様に記載のシステムを用いたシステムの制御方法である。

　本発明によれば、確率論を用いず、また、各要素にまつわる関数だけを使用して、全体を協調動作可能なシステムを提供することができる。

　図１は本願発明で検討したシステム概略図である。
　図２は本願発明のアーキテクチャ概略図である。
　図３は本願発明で用いる評価関数の概略図である。
　図４Ａは起動停止問題解決部を動作させないときの本願発明の制御イメージ図である。
　図４Ｂは起動停止問題解決部を動作させないときの本願発明の制御イメージ図である。
　図４Ｃは起動停止問題解決部を動作させないときの本願発明の制御イメージ図である。
　図５Ａは起動停止問題解決部を動作させたときの本願発明の制御イメージ図である。
　図５Ｂは起動停止問題解決部を動作させたときの本願発明の制御イメージ図である。
　図５Ｃは起動停止問題解決部を動作させたときの本願発明の制御イメージ図である。
　図６は本願発明で用いる評価関数の一例を示す図である。
　図７Ａは本願発明の一実施例における実験結果を示す図である。
　図７Ｂは本願発明の一実施例における実験結果を示す図である。
　図８Ａは本願発明の一実施例における実験結果を示す図である。
　図８Ｂは本願発明の一実施例における実験結果を示す図である。
　図９Ａは本願発明の一実施例における実験結果を示す図である。
　図９Ｂは本願発明の一実施例における実験結果を示す図である。
　図１０は本願発明で用いる評価関数の一例を示す図である。
　図１１Ａは本願発明の一実施例における実験結果を示す図である。
　図１１Ｂは本願発明の一実施例における実験結果を示す図である。
　図１２は本願発明で検討したシステム概略図である。
　図１３Ａは本願発明の一実施例における実験結果を示す図である。
　図１３Ｂは本願発明の一実施例における実験結果を示す図である。
　図１４は本願発明で検討したシステム概略図である。
　図１５Ａは本願発明の一実施例における実験結果を示す図である。
　図１５Ｂは本願発明の一実施例における実験結果を示す図である。
　図１６は本願発明で検討したシステム概略図である。
　図１７は本願発明で用いる評価関数の一例を示す図である。
　図１８Ａは本願発明の一実施例における実験結果を示す図である。
　図１８Ｂは本願発明の一実施例における実験結果を示す図である。
　図１９は本願発明で検討したシステム概略図である。
　図２０Ａは本願発明の一実施例における実験結果を示す図である。
　図２０Ｂは本願発明の一実施例における実験結果を示す図である。
　図２１Ａは本願発明で検討したシステム概略図である。
　図２１Ｂは本願発明で検討したシステム概略図である。
　図２２は本願発明の一実施例における実験結果を示す図である。
　図２３Ａは本願発明で検討したシステム概略図である。
　図２３Ｂは本願発明で検討したシステム概略図である。
　図２４Ａは本願発明の一実施例における実験結果を示す図である。
　図２４Ｂは本願発明の一実施例における実験結果を示す図である。
　図２５Ａは本願発明の一実施例における実験結果を示す図である。
　図２５Ｂは本願発明の一実施例における実験結果を示す図である。

　以下、図面に基づいて本発明に好適な実施形態を詳細に説明する。
　まず、本発明の動作、構成をデータセンターのリソース負荷分散の例を使用して説明する。従来の技術では十分に解くことができない例として、性能の異なるサーバが混在する異機種混合型データセンターにおける負荷分散を取り上げることにする。性能の異なるサーバが複数（Ｎ個）存在し、ネットワークで結合されたデータセンターにおいて、レスポンス要求値を満たしながら、処理要求をサーバに適宜分散させる。このときデータセンター全体の消費電力もできるだけ下げる。このような問題を考えていくことにする。この問題の概略図を図１に示す。
　本発明者はこの問題を検討した結果、以下の結論に達した。
　解くべき問題は、２つの問題が混在している構造になっている。ひとつは、起動停止問題であり、もうひとつは最適化問題である。
　起動停止問題とは、リソース群（機能ブロック群）があった場合、どのリソースを使い、どのリソースを使わないかを決定する、または管理する問題である。また、最適化問題は、リソースが与えられたとして、系全体に与えられた仕事をどのように割り振れば、ある指標の元に最適化できるかという問題である。これらの問題は従来、個々に、確率論的なアプローチで解くことを試みられていることが多いが、単純な確率論では、変幻自在に変わっていく環境の中で、状況に応じてロバスト、リアルタイムに即応することが難しい。今回は、これら２つの問題を一体のものとし、状況に応じてロバスト、リアルタイムに即応できるアーキテクチャを考案した。その際、それぞれの問題を、確率論ではなく、決定論的または関係論的な方法で解く方法を考案した。本発明者が創出した機能ブロックのアーキテクチャおよびこれを束ねたシステムの概略図を図２に示す。
　図２に示したように、本願の機能ブロックは主に、起動停止問題解決制御部と、最適化問題解決制御部を有し、互いに関連する機能ブロック（他の機能ブロック）とでシステムを構成している。
　次に、それぞれの部位の解決手段について詳説する。
　まず、最適化問題の解法を説明する。
　最適化問題を解くには、ふたつの要件を考えなければならない。ひとつは、需給平衡化であり、もうひとつは全体利潤最大化である。この両者が満たされて始めて最適化が達成されたと言うことができる。需給平衡化制御は拘束条件を充足させる制御でもあるので、拘束条件充足制御と呼んでも良い。
　即ち、図２に示すアーキテクチャにおいては、最適化問題解決制御部は、利潤最大化制御部と、拘束条件充足制御部を有することになる。
　需給平衡化とは、システム全体に要求されるミッションあるいはタスクの総量を満たさなければならないという拘束条件である場合が多い。これが満たされないまま、効率や利潤が最大化されても意味がない。今回の場合、需要とは、動作レベルλ_ｉ（ｉは機能ブロックの番号）の総和となり、以下の式（４）で表される。

　需給平衡化を達成しようとした場合、各機能ブロック（リソース）の動作レベルは、拘束条件充足制御部が、以下の関係（５）を満たす方程式を用いて決定する。

　なお（５）においてλ_ｋは、動作レベルλ_ｉの機能ブロックと関係を持つ他の機能ブロックの動作レベルである。
　この方程式は、より具体的には、以下の式（６）で表される。

　ここで、Ｋ_１は動作レベル変更のゲインに相当する係数である。またλ_{ｎｏｍ，ｉ}は機能ブロックｉの規格化係数（機能ブロックの規模に相当する量）で、必ずしも必要でないが、要素がヘテロな場合、全体で規格化した係数を乗算しておいた方が良い場合が多いので、式（６）に導入している。式（６）に従い、拘束条件充足制御部が機能ブロックの動作レベルを制御すると、システム全体として、拘束条件であるＤｅｍを満たすように動作する。
　次に解くべきは、全体利潤最大化である。これは全体効率最大化と読み替えても構わない。全体利潤最大化を解くに当たっては、図３のような各要素（機能ブロック）と関係する評価関数を導入する（図２では評価関数は機能ブロックの記憶部に記憶されている）。この場合、横軸は各機能ブロックを制御するパラメータであり、今回の例では処理要求の量λなどに相当する。縦軸は、何らかの効率に関わる指標であり、具体例は後述する実施例で詳説する。
　図３から明らかなように、評価関数は凸関数である。凸関数を使用するのも本願発明のポイントである。なぜなら、多くのシステムでは何らかの効率やシステムの安定性などを図３に示すような凸関数で表すことが可能だからである。なお、図３のような上に凸な関数を凹関数と呼び、下に凸な関数を凸関数と呼ぶこともあるが、ここでは、関数の性質上で区別する表現を採用し、凹関数も凸関数と表現することにする。
　評価関数が凸関数である要素を連携させて、全体で最適化（各要素の評価関数の値の総和が最大となる状態）する問題は、「凸計画問題」として知られており、各要素の動作レベルにおける評価関数の微分値が等しい状況で最適化が達成されることが数学的に明らかにされている。今回はこの原理を応用した。今回、評価関数として凸関数を使った理由がここにある。
　この原理を勘案し、全体利潤最大化を達成する方程式は、以下の関係（７）を満たす。

　なお式（７）においてｆ_ｉは、機能ブロックｉ（ｉ番目の機能ブロック）の評価関数、ｆ_ｋは、機能ブロックｉと関係を持つ他の機能ブロックｋの評価関数である。
　より具体的には、以下の式（８）で表される。

　ここで、Ｋ_２は動作レベル変更のゲインに相当する係数である。利潤最大化制御部が式（８）を満たすように各機能ブロックの制御を行うことで、各機能ブロックは、動作レベルにおける評価関数の微分値が等しくなるように動作する。
　最終的に最適化問題を解くには、上記の需給平衡化と全体利潤最大化を同時に解くことが必要なので、最適化問題解決制御部は、式（６）と式（８）を統合した以下の式（９）で各機能ブロックの動作レベルを制御する。

　次に、起動停止問題の解法を説明する。
　式（９）は要素を起動、停止する機能を実は内包している。右辺第２項は要素と要素が評価関数の傾きを経由して、抑制しあう効果を持っている。そして、実際に起こる現象としては、評価関数の傾きが大きなもの（効率の改善が大きいもの）が、評価関数の傾きの小さいもの（効率の改善が小さいもの）を抑制し、場合によっては停止させる。したがって、式（９）の右辺第２項が起動停止問題の停止問題を解く機能を内包していると言える。一方、停止している、あるいは停止させられた要素を起動させることができるのが、右辺第１項である。右辺第１項は需要が足りなければ正になり、各要素をより動作させる方向に動かす。これは結果的に停止している要素も起動する方向に動かすことを意味している。したがって、式（９）の右辺第１項が起動停止問題の起動問題を解く機能を内包している。
　しかしながら、式（９）を単純に運用しただけでは、起動停止問題を解いた上で、最適化問題を解くことにはならない。（９）の段階では、式（９）が起動する機能と、停止する機能を内包しているに過ぎないからである。例えば、図４Ａ~図４Ｃに、起動停止問題解決制御部が単純に式（９）を解いた場合の機能ブロックの動作例を示す。３つの直列結合した機能ブロック（ここではサーバに相当）が、図４Ａに示した評価関数を有するときに、トータルで０．４の負荷を実現するには、各要素がどれだけの負荷（パワ）を担当しなくてはならないかを式（９）を用いて起動停止問題解決制御部が制御したものである。なお、負荷が０以下の場合は、０をとるようにリミッタをかけた。図４Ｂが各要素の負荷の時刻変化であり、図４Ｃは各要素の評価関数の微分値の時刻変化である。図４（ｂ）より、自動的に効率の悪い「Ｎｏｄｅ３」（機能ブロック３）が停止していることがわかる。これより、一見、式（９）で起動停止問題が解けているかのように見えるが、図４Ｃをみると、「Ｎｏｄｅ１」と「Ｎｏｄｅ２」の微分値が一致していないことがわかる。「Ｎｏｄｅ３」は停止したので、「Ｎｏｄｅ３」と微分値が一致する必要はないが、起動している「Ｎｏｄｅ１」と「Ｎｏｄｅ２」の微分値が一致しないということは、システムが最適化されていないことを意味する。つまり、起動停止はできたが、最適化はされていないのである。これは、式（９）を単純に運用しただけでは、停止した機能ブロックが、起動している機能ブロックを抑制してしまうためである。
　また、例えば、需要が急に増えたとして、図４で停止された「Ｎｏｄｅ３」が起動するかというと、式（９）の右辺第２項による抑制次第では、右辺第１項の起動する機能が働いたとしても、起動できない可能性がある。例えば、式（９）の第１項の増分が第２項の抑制分より少なければ、「Ｎｏｄｅ３」は停止したままになってしまう。
　このように、起動停止問題解決制御部が式（９）を単純に解くだけでは、起動停止問題と最適化問題を両立して解くことはできない。
　そこで、本発明では、起動停止問題解決制御部に、式（９）で制御される最適化問題解決制御部に対して、機能ブロックの起動、停止状態を管理し、式（９）の制御を調整する機能を持たせることにした。具体的には、起動停止問題解決制御部には以下の機能を持たせた。
　まず、第１の機能は、停止した機能ブロック（自身の負荷分担の最小値に達した機能ブロック）または上限の負荷に到達した機能ブロックは、式（９）の右辺第２項を計算するときには存在しないものとして扱う機能である。また、第２の機能は、停止した機能ブロックまたは上限の負荷に到達した機能ブロックの負荷を計算する場合、式（９）の右辺第２項そのものが存在しないとして、右辺第１項だけを用いて計算する機能（即ち利潤最大化制御部を用いない機能）である。式（９）の右辺第１項、右辺第２項を機能ブロックの状態によって、独立に扱うところがポイントである。そこに起動停止問題解決制御部の存在意義がある。これによって、事実上動作レベルを変更できない停止した機能ブロックまたは上限の負荷に到達した機能ブロックを利潤最大化制御部の制御から切り離しつつ、起動停止問題（事実上停止した機能ブロックと同じである上限に達した機能ブロックを含む）を解き、必要とあれば、拘束条件充足制御部により、事実上停止した機能ブロックを動作する状態（起動状態）に持ち込むことができる。
　上述した２つの機能を、より具体的に説明する。
　停止した機能ブロックまたは上限の負荷に到達した機能ブロックは、式（９）の右辺第２項を計算するときには存在しない機能ブロックとして扱うというのは、例えば、起動している機能ブロックの負荷を計算しようとした場合、停止した機能ブロックまたは上限の負荷に到達した機能ブロックに関する式（９）の右辺第２項の分子を０にするということである。当然、起動している機能ブロック同士に関しては右辺第２項の分子は存在するので、起動している機能ブロックが負荷を計算しようとしている機能ブロックに繋がっている場合、右辺第２項は何らかの値を持つ可能性がある。一方、停止した機能ブロック、または上限に達した機能ブロックの負荷を計算しようとした場合、右辺第２項はないものとして扱う。つまり、右辺第２項を０として扱う。これにより、停止した機能ブロック、または上限に達した機能ブロックは、式（９）の右辺第１項のみが影響するようになり、需給に問題があれば、それらの機能ブロックを再度起動させることが可能となる。
　以上のように、本願発明で提案するような起動停止問題解決制御部と、最適化問題解決制御部により、両問題を一体として解決する制御が完成する。図５Ａ~図５Ｃに、需要が０．４から０．８に変わる場合（時刻２において）の３つの「Ｎｏｄｅ」（機能ブロック）の負荷分散の制御例を示す。図の表記は図４Ａ~図４Ｃと同じであるが、需要が０．４のときは、「Ｎｏｄｅ３」を停止し、需要が０．８になったときは「Ｎｏｄｅ３」を改めて起動する制御が実現されている。また、評価関数の傾きはどちらの需要でも最終的に同じ値に収束しており、最適化問題も解決されていることがわかる。
　需給平衡化の説明のところで、システム全体に要求されるミッションあるいはタスクの総量を満たさなければならないという拘束条件である場合が多いと書いたが、そうでない場合も想定されないわけではない。そのような場合は、その拘束条件を満たすように上述した需給平衡化の項を変形して、制御すれば良い。そのような場合も、起動停止問題解決制御部により、機能ブロックの状況を管理するのは重要で、そうしないと、起動も停止も良好に行われない。
　ここで、大きなポイントは、各機能ブロックの評価関数は設定しているが、機能ブロック全体としての評価関数は設定していないことである。全体の評価関数を設定しなくて良いのは非常に大きなメリットである。個々の機能ブロックの評価関数はいろいろ設定できるが、全体の評価関数となると、システムが複雑になればなるほど判然としないからである。また、今回のシステムは、各要素が自身の状態と自身と関係のある要素の状態の情報のみで動作できる可能性がある。需給平衡化で使う情報は、全体の情報とも考えられるが、電力システムのように、需給バランスの崩れを交流周波数の変動で知ることができるものの場合は、需給平衡化も完全に自律分散的に実施できる。つまり、需給平衡化にまつわる情報を自身から得ることができれば、全体としての情報を必要としない真の自律分散システムになれるのである。
　このシステムは、基本的に自律分散的に独立に動くので、どこかが故障したりしても、故障した要素からの信号が途絶えた分だけ、他の要素が自律的にリカバーするという動作を行う。また、突然要素を増やしたり、減らしたりしても、徐々に自律的に適正な動作に向かうことができる。つまり、外乱に対して、非常にロバストであり、また、要素の増減を自由にできるスケーラビリティを有している。
　従来のシステムは、故障に対して無力であったり、様々なエラー用のシーケンスを用意したりしなければならなかった。また、勝手に要素（リソース）を増やしたり減らしたりすればシステム全体の安定性が保たれるか保証はなく、そのたびにプログラム、処理を見直さなければならなかった。今回のシステムはこれらの問題を自律分散適応的な制御ですべて解決することができるのである。

以下、本発明の実施例を、図面を参照しながら、さらに詳細に説明する。
（実施例１）
　図１に示したデータセンターのリソース負荷分散に対して、本願発明を実施した。この場合、動作レベル（ｎは機能ブロックの番号）は各リソースに割り当てられたタスク量に相当する。
　データセンターのリソース負荷分散を考えた場合、管理者がこだわる制約条件としては、レスポンス、スループット、エネルギーなどが挙げられる。まず、最初に、レスポンスとスループットが制約条件になっている場合の本願発明の実施例を示す。
　レスポンスとスループットは切っても切れない関係にあるが、それぞれの定義を記述すると以下のようになる。レスポンスＲは、処理にかかる時間そのものであり、スループットＳは、単位時間に処理される仕事量である。したがって、要求される仕事量λに対して、単純には以下の式（１０）が成立する。
　Ｓ＝λ・Ｒ　　…（１０）
　（Ｓ≦１）
　しかしながら、実際のリソースの実効的なレスポンスＲｅはこのようにはならない。これは、待ち行列理論による確率的な待ち時間を検討しなければならないのである。実効的なレスポンスはリソース単体の処理能力だけではなく、どれぐらいの仕事が到達し、どのくらい未処理の仕事が溜まっているかに依存するからである。待ち行列理論はそれを確率的な計算で明らかにしたものである。
　待ち行列理論によれば、到達してから処理が終わるまでの時間Ｔｍは以下の式（１１）のように記述される。
　Ｔｍ＝１／（μ−λ）　　…（１１）
　ここで、μは単位時間当たりの処理率を表し、レスポンスＲの逆数でもある。実効的なレスポンスＲｅは、Ｔｍの逆数と考えられるので、（１０）の関係も使うと、以下の式（１２）が成り立つ。
　Ｒｅ＝μ−λ
　　　＝１／Ｒ−Ｓ／Ｒ
　　　＝（１−Ｓ）／Ｒ　　　…（１２）
　このように、実効的なレスポンスＲｅもスループットと緊密な関係がある。式（１２）からわかるのは、実効的なレスポンスを上げたければ、スループットを下げればよいし、スループットを上げたければ、実効的なレスポンスを下げれば良い。つまり、お互いがトレードオフになっており、かつどちらかの極限値では、他方が無効状態（０になる）になるということであり、管理者は適当な按配で両者をバランスさせる必要がある。
　では、本願発明を用いて、管理者はどのようにデータセンターの負荷分散を実現すればよいのだろうか。上述したように、実効的なレスポンスとスループットはトレードオフの関係にあるので、レスポンス重視にしたければ、各要素（リソース）に分散される仕事量を低めにすればよいし、スループットを重視したければそれを多めにすれば良い。したがって、各要素に設定する関数を例えば以下のような手法で設定していけばよい。
　図６に評価関数の概略図を示す。今回の検討課題が負荷分散なので、横軸は仕事量とした。先にも述べたが、評価関数は凸関数が良いので、今回は上に凸な２次関数とした。λｍａｘはそのリソースの限界であり、λｐｅａｋは評価関数のピーク位置を表す。評価関数のピークを１として規格化しておくと、規格化評価関数は（０，０）、（λｐｅａｋ，１）を通る２次関数として決定できる。各要素（リソース）には性能差があるので、その性能差に比例した係数α_ｉを規格化評価関数に掛けることで、個々の評価関数とする。λｐｅａｋはスループットＳが１になり、実効的レスポンスＲｅが０になる位置である。先にも述べたが、レスポンス重視にしたければ、各要素（リソース）に分散される仕事量を低めにすればよいし、スループットを重視したければそれを多めにすれば良い。したがって、レスポンス重視で仕事をシステムに実施してもらいたければ、λｐｅａｋの位置を小さめに設定すれば良く、スループット重視で仕事をして欲しければλｐｅａｋの位置を大きめすれば良い。システムは本願発明の方法を使って、起動停止問題、最適化問題を解きながら動作し、それぞれの要素のλｐｅａｋの位置をできるだけ目指す。したがって、λｐｅａｋの位置を小さめに設定していれば、それぞれの要素の負荷が比較的小さめに仕事が分散されることになり、全体としてはレスポンス重視の動作となる。また、λｐｅａｋの位置を大きめに設定していれば、それぞれの要素の負荷が比較的大きめに仕事が分散されることになり、全体としてはスループット重視の動作となる。無駄なリソースは適宜停止させるので、エネルギー的にも無駄のない制御となる。
　この場合、評価関数の縦軸は実際の何らかの効率にはなっていない。むしろ管理者が動作させたい位置であり、評価関数の設定は、何らかの物理量、法則に支配されることはない。システムを動作させたい人間が、縦軸、横軸を任意に設定することができるのである。ある意味、人間がシステムに評価関数として指示を渡すと、後はシステムが自律的に協調して動作するのである。
　今回、評価関数は（０，０）、（λｐｅａｋ，１）を通る２次関数に係数α_ｉを掛けたものとしたが、凸関数であれば良いので、様々に設定して良い。極論すれば、手書きの評価関数を設定しても良い。
　上述した評価関数を用いて、図１に示すデータセンターの負荷分散の実験を行った。各サーバには、図２で示した本願発明の機能ブロックが内蔵されており、各サーバは自身に設定された評価関数と自身に接続された他のサーバの状況を見ながら、起動停止問題解決と最適化問題解決を行う。今回の各サーバはすべて接続されており、需給平衡化に必要な全体要求（需要）と現時点でのシステム全体の仕事量の差をモニタすることを可能とした。各サーバをすべて接続するのが大変な場合は、需給の差をモニタし、各サーバに伝えることができる部位を入力のところに設定しても良い。
　負荷分散を決定する係数Ｋ_１、Ｋ_２などを適宜設定した。また、サーバの総数は１０００台とした。また、各サーバの性能は均一ではなく、性能が高いものほどα_ｉを大きく設定した。
　図７Ａおよび図７Ｂに第１の実験結果を示す。グラフの横軸は時間、縦軸は、図７Ａではシステム全体の実効的なレスポンス、スループット、図７Ｂでは起動しているサーバ（リソース）の数である。最初は、λｐｅａｋを小さめに設定し、レスポンス重視で動作させている。その後、図中のスループット重視と描かれた時刻にλｐｅａｋを大きめに設定しなおしている。すると、システムは自律的にレスポンス重視な方向に動作を変更していくことが確認された。起動しているサーバも適宜調整されており、本願発明が有効であることが確認できた。
　図８Ａおよび図８Ｂに第２の実験結果を示す。グラフの横軸は時間、縦軸は、図８Ａではシステム全体の実効的なレスポンス、スループット、図８Ｂでは起動しているサーバ（リソース）の数である。あるλｐｅａｋの設定で動作させている途中で、人為的に１割のサーバを止めた（図中矢印で示す「故障発生」と記載された部分）。すると、一時的にスループット、レスポンス能力が下がるが自律的に回復する様子がわかる。サーバの能力は均一ではなく、ヘテロな状態なので、自律的に回復した後に使用されているサーバの数は、人為的にサーバを止めた前後で変わっている。これは、まさしく自律的に起動停止問題を解いていることを意味している。故障に対するロバスト性に関しても、本願発明が有効であることが確認できた。
　図９Ａおよび図９Ｂに第３の実験結果を示す。グラフの横軸は時間、縦軸は、図９Ａではシステム全体の実効的なレスポンス、スループット、図９Ｂでは起動しているサーバ（リソース）の数である。あるλｐｅａｋの設定で動作させている途中で、人為的に１００台のサーバを追加した（図中矢印で示す「サーバ追加」と記載された部分）。すると、スループット、レスポンス能力を変化させることなく、自律的に追加サーバを含めたサーバの起動停止を行い安定状態に落ち着く。これは、このシステムがスケーラブルであることを示しており、リソースの増減に対してプログラムの変更、処理の変更が全く必要ないことを意味している。これは、非常に有用な特性であり、本願発明が有効であることが確認できた。
（実施例２）
　図１に示したデータセンターのリソース負荷分散に対して、実施例１同様に本願発明を実施した。実施例１では、レスポンスとスループットが制約条件になっている場合の本願発明の実施例であったが、ここでは、エネルギーが制約条件になっている場合の本願発明の実施例を説明する。エネルギーが制約になっているという意味は、できるだけ省電力でシステムを運用したいという意味である。
　これも基本的には評価関数の設定の問題となる。
　ここでは、筋肉の効率の式を参考にすれば、動作するもののエネルギー効率は、アイドリング時の消費電力Ｈ_ｄｅｆ、仕事時消費電力Ｗ（λ）、仕事時追加消費電力（空冷ファンなど）Ｈによって、以下の式（１３）で記述することができる。

　一般的には、この効率はλｍａｘ以下のどこかでピークを迎える凸関数になるので、λｍａｘ以下は式（１３）を評価関数として使用すれば良い。このエネルギー効率の式の場合、λｍａｘ以上の仕事量は定義できないので、今回は、人為的に描いた。図１０に使用した評価関数のイメージを示すが、λｍａｘより大きな仕事量における評価関数は、運用者が好みで設定してしまっても良い。例えば、レスポンス重視なら、早く仕事量を減らしたいので、急な斜面にしておけば良いし、スループット重視であれば、仕事量をいきなり減らさなくてもいいので、傾きが緩やかな曲線を描いてやれば良い。このように、評価関数は運用者が自在に作っていけるのである。注意点としては、自在に作れる分、評価関数により適正にされていくものが、客観的定量性をもって適正化されているかを言及できなくなる場合がある。例えば、今回の場合、λｍａｘ以下では定量的なエネルギー効率の関数であるが、λｍａｘ以上は運用者の快適度のような定性的な関数となる。どうしても客観的定量性が必要なときは、客観的な指標を使う、または客観的な指標に変換できるものを考えていく必要がある。しかしながら、これまでのシステムの運用は管理者の経験や、好みで運用されている場合も多く、定性的な意味の評価関数で運用できるというのは、管理者の好みで運用できることでもあるので、むしろ有益な特性であると言える。
　上述した評価関数を用いて、実施例１と同様の構成でデータセンターの負荷分散の実験を行った。図１１Ａおよび図１１Ｂに実験結果を示す。今回の例では、最初すべてのサーバ（１０００台）を動作させておき、その後、エネルギー効率、動作するサーバの台数がどうなるかを見た。図１１Ａおよび図１１Ｂからわかるように、最初はすべてのサーバが動作することにより、無駄なエネルギーを消費していたが、自律的に起動するサーバを選択、負荷を分散させることで、消費エネルギーを減らしていることが確認できる。つまり、本願発明が有効であることが確認できた。
（実施例３）
　本実施例では、実施例１で説明したレスポンスまたはスループットを重視した制御と、実施例２で説明したエネルギー効率を重視した制御を状況依存的に切り替える手法を説明する。基本的には実施例１と同様のデータセンターの構成で実験を行ったが、１点異なるのが、状況依存的に評価関数を切り替える命令を出す評価関数切り替え部を設置しているところである。本実施例のシステム概略図を図１２に示す。この評価関数切り替え部は、各サーバ（リソース）が従う評価関数を、実施例１で用いたものと実施例２で用いたもののどちらかに切り替える命令を、各リソースに送信する。その命令を受けた各リソースは、命令にあった評価関数を設定し、起動停止問題、最適化問題を解く制御を実施する。評価関数切り替え部は、管理者の希望を受け取り、それに適した評価関数を選択、各リソースに命令を送信しても良いし、何らかの外部入力から状況を判断する判別器を設定し、その判別器を使って自動的に評価関数の選択を行っても良い。今回は、実施例１で用いた評価関数と実施例２で用いた評価関数の２種類の切り替えを行ったが、この切り替えは２種類にとどまる必要はなく、評価関数を設定すれば、所望の数の評価関数の切り替えを実施することができる。また、今回の例では、評価関数切り替え部を全体でひとつ置いたが、個々の機能ブロック（リソース）に設置するという方法も考えられる。
　上述したシステムを用いて、実験を行った結果を図１３Ａおよび図１３Ｂに示す。評価関数切り替え部がある以外は実施例１、２と同様の条件である。グラフの横軸は時間、縦軸は、図１３Ａではシステム全体の実効的なレスポンス、エネルギー効率、図１３Ｂでは起動しているサーバ（リソース）の数である。最初は、レスポンス重視で動作させ、途中で（図中矢印の部分）、エネルギー効率重視に切り替えた。すると、最初はレスポンスが高い値で、エネルギー効率はそれほど高くないが、エネルギー効率重視にすると、レスポンスは悪くなるが、エネルギー効率は高くなっていく。つまり、評価関数切り替え部を通じた評価関数の切り替えがうまく行っていることが確認できた。また、この実施例より、管理者は複数の要件（レスポンス重視、エネルギー重視など）があった場合でも、プログラムの変更、処理の変更なしで、適宜システムの動作目標の変更を指示するだけで、システムの動作を変更できることがわかる。つまり、本願発明は、複数の要件が合った場合にも、有効に動作させることができ、本願発明が有効であることが確認できた。
（実施例４）
　本実施例では、データセンターが複数あり、それらがネットワークで繋がっている場合のリソース負荷分散の例を説明する。個々のデータセンターは実施例１と同様の構成であるが、それらが図１４に示したように、ネットワークで結合されて複数存在するというモデルである。上述の実施例との違いは、リソースがデータセンター内に閉じていないので、ネットワークによる遅延が無視できなくなることである。したがって、レスポンス、スループットを考えるとき、処理要求を行うデータセンター（命令された処理をメインで実施しているデータセンター）からの距離（遅延）も勘案して機能ブロック（リソース）の負荷分散をやらなければならないことである。
　今回の実施例では、レスポンス重視の制御を行う。つまり、実施例１で使用した評価関数をすべてのリソースに対して使用した。処理要求を行うデータセンターからの距離（遅延）をどのように勘案するかであるが、処理要求を行うデータセンターからの伝達遅延量Ｄｌｙとしたときに、

なる係数を、各データセンター内の要素（リソース）の性能係数α_ｉに加えて、規格化評価関数に乗算した。これにより、各リソースが、近くのデータセンターでは比較的高い性能、遠くのデータセンターでは比較的低い性能として認知され、遅延のあるネットワーク越しでも好適なリソースの負荷分散が実施される。
　上述した複数のデータセンターがある場合において、実験を行った結果を図１５Ａおよび図１５Ｂに示す。グラフの横軸は時間、縦軸は、図１５Ａではシステム全体の実効的なレスポンス、図１５Ｂでは起動しているサーバ（リソース）の数である。今回は処理要求を行うデータセンターの近くに、処理能力が格段に高いリソースが多くあるケースでの実験とした。したがって、ネットワークによる遅延があったとしても、外のデータセンターのリソースを使用したほうが良いと想定されるケースである。図中の矢印の部分までは、単一のデータセンターで処理（を行っているのだが処理要求を行うデータセンターだけで処理を行っているという意味）、その後は、周りのデータセンターとネットワーク的に結合し、レスポンス、起動しているサーバ数を見たものである。起動しているサーバ数というのはネットワークで結合したすべてのデータセンターにおきる起動しているリソース数である。図１５Ａおよび図１５Ｂから、ネットワークでデータセンター間を結合すると、格段に処理能力の高いリソースを求めて、自律的にリソースを起動停止し、レスポンス能力を維持したまま、ネットワーク越しの格段に処理能力の高いリソースを使用し、起動するリソースの数を自律的に減らしている様子がわかる。遅延のあるネットワークで結合された要素（リソース）においても、本願発明が有効であることが確認された。今後、クラウド間の連携が議論されてきた場合、本願発明を使用する意味は大きい。
（実施例５）
　これまでの実施例では、レスポンス、スループット、エネルギーといった処理に関するリソースの負荷分散について記述してきたが、本願発明の適用例はそれだけに止まらない。ここでは、ストレージの負荷分散に使用した実施例を説明する。
　この実施例で使用したシステムの概略図を図１６に示す。実施例１のリソースがストレージに変更されたイメージである。各ストレージには、図２で示した本願発明の機能ブロックが内蔵されている。この場合も評価関数をどうするかが重要なポイントとなるが、図１７に示す評価関数を使用すれば良い。この場合、横軸のλ_Ｓはストレージ量（記録量）である。縦軸は、規格化されているが、この規格化評価関数にストレージの性能に比例した係数αｓ_ｉを乗算する。この場合の性能とは記録スピード、アクセス性、アーカイブ性（保存性）などを勘案して決定すればよい。このケースでは、記録スピードを出したいとき、アーカイブ性を出したいときなどの状況に合わせて、各要素の係数αｓ_ｉだけ変更するという制御も考えられる。その変更により、システムは要求に適したストレージにデータを移していく。このように評価関数の設定は非常に自由であることが、本願発明の大きな利点のひとつとなっている。
　上述したストレージの負荷分散の例に関して、実験を行った結果を図１８Ａおよび図１８Ｂに示す。グラフの横軸は時間、縦軸は、そのストレージに記録されているデータの量である。今回の例では、高速性のあるストレージのひとつと、アーカイブ性の高いストレージのひとつを取り出し、モニタした結果を示している。図中の矢印のところで、評価関数を高速性重視のものから、アーカイブ性を重視するものに変更している。図を見るとわかるとおり、矢印以降では、アーカイブ性の高いストレージの容量が増え、高速性の高いストレージの記録量が減っている。つまり、自律的に管理者の意図をシステムが実現しているのである。このほうに、本願発明は、何らかの機能ブロック（リソース）が関連して存在（ネットワークで結合）していれば様々な分野で同じように使用できる。この実施例ではそれが確認されたことになる。
（実施例６）
　これまでの実施例では、情報分野の負荷分散制御の話であったが、本願発明の適用は情報分野に限らない。例えば、インフラ系のエネルギー、水などの制御にも問題なく使用できる。この実施例では、複数の太陽光エネルギーを接続した場合に、適正な電力が得られるか、本願発明を用いて実施した例を説明する。
　本実施例の概略図を図１９に示す。丸印が太陽光エネルギー源である。エネルギーを消費するのが需要家であるが、需要家は太陽光エネルギーの供給源になる場合もあり、そのような需要家のところには丸印が描いてある。太陽光エネルギー発生源には、図２で示した本願発明の機能ブロックが内蔵されており、各太陽光エネルギー発生源は自身に設定された評価関数と自身に接続された他の太陽光エネルギー発生源の状況を見ながら、起動停止問題解決と最適化問題解決を行う。今回、太陽光エネルギー発生源が自身の電力を調整する方法としては、パネルの角度を変える方法を採用した。今回の実施例は所謂スマートグリッドの雛形を用いた実験例である。実験の都合上、電力会社が供給する電力網を使用した実験はできなかったが、今回の実施例が有効であれば、電力会社の発電所と再生可能エネルギー（太陽エネルギー、風力エネルギーなど）のヘテロな（ハイブリッドな）電力網でも有効に働くのは間違いない。
　上述した電力の負荷分散の例に関して、実験を行った結果を図２０Ａおよび図２０Ｂに示す。グラフの横軸は時間、縦軸は、図２０Ａでは、そのシステム全体としての電力量、図２０Ｂでは動作している太陽光エネルギー源（リソース数）である。図中の矢印に示す「故障発生」と記載されたところで、故意に幾つかの太陽光エネルギー源を遮断した。幾つかの太陽光エネルギー源を遮断したときに、電力量は一瞬低下するが、すぐに自律的に適正な電力量に戻る。今後、再生可能エネルギーが、既存の電力網にどんどん乗り入れてくると考えられる。再生可能エネルギーは、状況に非常に左右されるエネルギー源なので、電力供給をしたり、しなかったりは日常茶飯事で、かつ予想できない。このような状況では、本願発明が実施したように、システムが自律的に自己復元できる必要がある。本願発明が非常に有効に活用されることが予想される。また、この実施例から、本願発明が情報分野のみならずインフラ分野の制御にも有効であることが実証された。
（実施例７）
　これまでの実施例は、評価関数を管理者が予め設定する、あるいは供給するという形をとっていた。つまり、やや固定化された評価関数であった。また、定量的に実際の効率などと完全に適合しているかどうか保証していないものもあった。ここでは、その評価関数を徐々に実際のものに定量的に近づけてしまう方法について説明する。エネルギー効率は実測できる量なので、エネルギー効率に関わる評価関数を徐々に実際に即して変更する方法について述べる。エネルギー効率に関する実施例なので、基本構成は実施例２と同じものを使用した。
　今回の場合、各リソースに設定された評価関数を徐々に定量的に正確なものにするというものである。基本的には最初に設定された評価関数の値と現時点での実測値の差に係数を掛けてフィードバックしていくという方法である。これにより、徐々に、評価関数が定量的に正しくなっていく。図２１Ａに示すように、各機能ブロック（リソース）にこのフィードバックプロセスを実行する評価関数修正制御部を設け、図２１ＢでＳ０~Ｓ４と示す各プロセスを実行する。
　上述したシステムで、エネルギー効率がどう推移するかを見たのが図２２である。評価関数修正部が各リソースに取り付けられている以外は、実施例２と同じ条件である。グラフの横軸は時間、縦軸はエネルギー効率であるが、時間とともにエネルギー効率が改善していることがわかる。評価関数のダイナミックな調整も可能であることがわかった。
（実施例８）
　これまでの実施例では、停止した要素（ノード）がネットワークを完全に遮断してしまうケースに関して説明しなかった。このようなケースはあまり多くなく、また全ノードを管理している部分があれば問題ないので、必ずしも考える必要はないが、この実施例ではそのようなケースについて考えてみる。簡単のため、図２３Ａに示す９個のノード（機能ブロック）が直線的に並んだ場合の負荷分散について考える。実施例としては図１の特殊なネットワーク形状とも考えられる。評価関数としては、図２３Ｂに示すように、ノード番号を３で割り、余りが１のもの、２のもの、０のものは同じとした。トータルの需要を０．４として、単純に本願発明を適用すると図２４Ａおよび図２４Ｂに示す結果となる。本来、ノード１、４、７が同じ負荷となり、その他のノードの負荷が０となるはずであるが、ノード１、４、７は同じ負荷となっていない（図示していないが、その他のノードの負荷は０になっていることは確認されている）。また、評価関数の微分値も同じとなっていない。つまり、うまく起動停止問題と最適化問題を解くことができていない。これは、ノード１、４、７を繋ぐ、間のノードが停止してしまったことで、式（９）の右辺第２項が働かなくなってしまったからである。
　このような場合は、停止したノードとはいえ、隣接ノードのうち起動しているノードの評価関数の微分値を周辺のノードに伝えるように制御をかけると問題がなくなる。つまり、自身が停止しても、周辺の起動しているノードの評価関数の微分値を周辺に伝達する機能を起動停止問題解決ブロックに組み込むのである。
　そのようにした場合の制御結果を図２５Ａおよび図２５Ｂに示す。間のノードが停止しても、ノード１、４、７がしっかり相互作用し、起動停止問題、最適化問題を解いていることがわかる。このように、起動停止問題解決ブロックに自身と周辺ノードの状況を管理する機能をつけていくことで、様々な状況でも問題なく起動停止問題、最適化問題を解決することができる。
　システムの都合により、クリティカルなパスが存在してしまい、そこが故障してしまうというケースにおいてもこのような手法を使うことで問題なく起動停止問題、最適化問題を解決することができるのである。

　本発明は、複数の機能ブロックを有し、それらの機能ブロックを自律分散適応的に統合して動作させるシステムの制御全般に貢献できるものであり、産業上の利用可能性非常に大きい。システムを外乱に対してロバストにし、また状況依存的にリアルタイムにシステムを適応させていくという制御を簡単、かつスケーラブルに実現することができる。
　また、上記した実施形態および実施例では、データセンターの負荷分散、ストレージの負荷分散、太陽光発電源の制御などの例を用いて、本願発明を説明したが、上述したように、本願発明は、情報分野、インフラ分野に限定されず、何らかの機能ブロック（リソース）が関連して存在（ネットワークで結合）していれば様々な分野で同じように使用できる。
　なお、上記機能ブロックの各部は、ハードウェアとソフトウェアの組み合わせを用いて実現すればよい。ハードウェアとソフトウェアとを組み合わせた形態では、ＲＡＭに本発明のシステムのプログラムが展開され、プログラムに基づいて制御部（ＣＰＵ）等のハードウェアを動作させることによって、各部を各種手段として動作させる。また、前記プログラムは、記憶媒体に記録されて頒布されても良い。当該記録媒体に記録されたプログラムは、有線、無線、又は記録媒体そのものを介して、メモリに読込まれ、制御部等を動作させる。なお、記録媒体を例示すれば、オプティカルディスクや磁気ディスク、半導体メモリ装置、ハードディスクなどが挙げられる。
　なお、本出願は、２０１１年５月２３日に出願された、日本国特許出願第２０１１−１１４２６６号からの優先権を基礎として、その利益を主張するものであり、その開示はここに全体として参考文献として取り込む。

Claims (20)

1. 　相互に関係を持つ複数の機能ブロックを有し、
   　複数の前記機能ブロックは、
   　それぞれに対応した評価関数を有する記憶部と、
   　各機能ブロックの動作レベルを複数の前記機能ブロック全体で満たすべき拘束条件に基づき制御する拘束条件充足制御部と、
   　前記機能ブロックに関係を持つ他の機能ブロックの前記評価関数に関する情報によって、互いの動作レベルを制御する利潤最大化制御部と、
   　前記機能ブロックの動作レベルに応じて、前記拘束条件充足制御部および前記利潤最大化制御部の制御結果を用いて、前記機能ブロックの起動状態、停止状態を制御する起動停止問題解決制御部と、
   　を有することを特徴とするシステム。
2. 　前記評価関数が凸関数であることを特徴とする請求項１記載のシステム。
3. 　前記起動停止問題解決制御部は、
   　動作レベルが下限または上限の機能ブロックがある場合に、前記利潤最大化制御部の制御結果を調整して前記機能ブロックの起動状態、停止状態を制御することを特徴とする請求項１または２に記載のシステム。
4. 　前記起動停止問題解決制御部は、
   　前記機能ブロックに関係を持つ他の機能ブロックの動作レベルが上限または下限にある場合、前記利潤最大化制御部が、前記他の機能ブロックが存在しないものとして動作レベルを制御した結果を用いて前記機能ブロックの起動状態、停止状態を制御することを特徴とする請求項３記載のシステム。
5. 　前記起動停止問題解決制御部は、
   　前記機能ブロックの動作レベルが上限または下限にある場合、前記利潤最大化制御部の制御結果を用いないで前記機能ブロックの起動状態、停止状態を制御することを特徴とする請求項３記載のシステム。
6. 　前記機能ブロックに関係を持つ他の機能ブロックからの情報は、前記他の機能ブロックの評価関数の傾きに比例した値に関する情報であり、かつ前記機能ブロックの動作を抑制する情報であることを特徴とする請求項１~５のいずれか１項に記載のシステム。
7. 　前記拘束条件充足制御部は、
   　以下の式（１）を満たす関係が成立する方程式を用いて前記機能ブロックの動作レベルを決定することを特徴とする請求項１~６のいずれか１項に記載のシステム。
   

   
8. 　前記拘束条件充足制御部は、
   　以下の式（２）を満たす関係が成立する方程式を用いて前記機能ブロックの動作レベルを決定することを特徴とする請求項７に記載のシステム。
   

   
9. 　前記利潤最大化制御部は、
   以下の式（３）を満たす関係が成立する方程式を用いて前記機能ブロックの動作レベルを決定することを特徴とする請求項１~８のいずれか１項に記載のシステム。
   

   
10. 　前記利潤最大化制御部は、
    　以下の式（４）を満たす関係が成立する方程式を用いて前記機能ブロックの動作レベルを決定することを特徴とする請求項９に記載のシステム。
    

    
11. 　前記拘束条件充足制御部および前記起動停止問題解決制御部は、前記機能ブロック自身の動作レベルを決定するときに、以下の式（５）を満たす関係が成立する方程式を用いて動作レベルを決定することを特徴とする請求項１~１０のいずれか１項に記載のシステム。
    

    
12. 　前記起動停止問題解決制御部は、
    　前記式（５）を用いて前記機能ブロックの起動状態、停止状態を制御することを特徴とする請求項１０に記載のシステム。
13. 　前記起動停止問題解決制御部は、
    　前記機能ブロックに関係を持つ他の機能ブロックの動作レベルが上限または下限にある場合、前記他の機能ブロックにおいては、前記式（５）の右辺第２項を計算するときには存在しない機能ブロックとして扱うことを特徴とする請求項１２記載のシステム。
14. 　前記起動停止問題解決制御部は、
    　前記機能ブロックの動作レベルが上限または下限にある場合、前記式（５）の右辺第２項が存在しないものとして前記式（５）を計算することを特徴とすることを特徴とする請求項１２記載のシステム。
15. 　前記起動停止問題解決制御部は、
    　前記機能ブロックの動作レベルが上限または下限にある場合、隣接する機能ブロックの評価関数の情報を伝達することで、利潤最大化制御における起動している機能ブロックの利潤最大化制御を調整することを特徴とする請求項１~１４のいずれか１項に記載のシステム。
16. 　請求項１~１５のいずれか１項に記載のシステムを用いたシステムの制御方法。
17. 　相互に関係を持つ複数の他の機能ブロックに接続され、
    　評価関数を有する記憶部と、
    　動作レベルを前記機能ブロック全体で満たすべき拘束条件に基づき制御する拘束条件充足制御部と、
    　前記他の機能ブロックの前記評価関数に関する情報によって、動作レベルを制御する利潤最大化制御部と、
    　動作レベルに応じて、前記拘束条件充足制御部および前記利潤最大化制御部の制御結果を用いて、起動状態、停止状態を制御する起動停止問題解決制御部と、
    　を有することを特徴とする機能ブロック。
18. 　前記評価関数が凸関数であることを特徴とする請求項１７記載の機能ブロック。
19. 　前記起動停止問題解決制御部は、
    　前記他の機能ブロックの動作レベルが上限または下限にある場合、前記利潤最大化制御部が、前記他の機能ブロックが存在しないものとして動作レベルを制御した結果を用いて前記機能ブロックの起動状態、停止状態を制御することを特徴とする請求項１７または１８に記載の機能ブロック。
20. 　前記起動停止問題解決制御部は、
    　前記他の機能ブロックの動作レベルが上限または下限にある場合、前記利潤最大化制御部の制御結果を用いないで前記機能ブロックの起動状態、停止状態を制御することを特徴とする請求項１７または１８に記載の機能ブロック。

Images