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