(57)【特許請求の範囲】
【請求項１】
相互に関係性を持つ複数の機能ブロックを有するシステムの制御方法であって、
前記複数の機能ブロックの各々に対応した機能ブロックの状態に関する評価関数を設定し、
前記複数の機能ブロックの中から選ばれた所定の機能ブロック群を仮想機能ブロックとし、
前記仮想機能ブロックに含まれる機能ブロックの評価関数を用いて仮想評価関数を作成し、
前記仮想評価関数に基づいて前記システムを制御し、
前記仮想評価関数が前記機能ブロックの評価関数の微分関数の逆関数に基づいて作成されることを特徴とするシステムの制御方法。
【請求項２】
前記機能ブロックの各々の動作レベルを数１（iは機能ブロックの番号）、前記機能ブロックの評価関数を数２、前記評価関数の動作レベルによる微分を数３、その逆関数を数４とすると、前記仮想評価関数の横軸を数５、縦軸を数６とした場合（ｊは仮想評価関数を作成する仮想機能ブロックの番号）、ある値（数７）に対して、数８、数９とすることを特徴とする請求項１に記載のシステムの制御方法。
【数１】
0006052896.tif 000022
【数２】
0006052896.tif 000023
【数３】
0006052896.tif 000024
【数４】
0006052896.tif 000025
【数５】
0006052896.tif 000026
【数６】
0006052896.tif 000027
【数７】
0006052896.tif 000028
【数８】
0006052896.tif 000029
【数９】
0006052896.tif 000030
【請求項３】
前記仮想機能ブロックを複数個まとめて、さらに上位の仮想機能ブロックとし、
前記仮想機能ブロックの仮想評価関数を用いて、前記上位の仮想機能ブロックの仮想評価関数を作成することにより、階層的な仮想機能ブロックを作成することを特徴とする請求項１又は２に記載のシステムの制御方法。
【請求項４】
前記評価関数が凸関数であることを特徴とする請求項１から３のいずれか１項に記載のシステムの制御方法。
【請求項５】
前記仮想評価関数に基づいた前記システムの制御は、前記機能ブロックの評価関数又は前記仮想評価関数の微分値を比べることにより行われることを特徴とする請求項１から４のいずれか１項に記載のシステムの制御方法。
【請求項６】
前記機能ブロック又は前記仮想機能ブロックのそれぞれの動作レベルを数１０（iは前記機能ブロック又は前記仮想機能ブロックの番号）、前記機能ブロック又は前記仮想機能ブロックの評価関数を数１１、前記評価関数（数１１）の動作レベルによる微分を数１２とすると、数１３なる関係(jはiと関係を持つ機能ブロック番号)が成立する方程式を用いて動作レベルを決定することを特徴とする請求項１に記載のシステムの制御方法。
【数１０】
0006052896.tif 000031
【数１１】
0006052896.tif 000032
【数１２】
0006052896.tif 000033
【数１３】
0006052896.tif 000034
【請求項７】
前記システムは、前記複数の機能ブロックを自律分散適応的に統合して動作させることを特徴とする請求項１から６のいずれか１項に記載のシステムの制御方法。
【請求項８】
相互に関係性を持つ複数の機能ブロックを有するシステムの制御装置であって、
前記複数の機能ブロックの各々に対応した機能ブロックの状態に関する評価関数を設定する設定手段と、
前記複数の機能ブロックの中から選ばれた所定の機能ブロック群を仮想機能ブロックとし、前記仮想機能ブロックに含まれる機能ブロックの評価関数を用いて仮想評価関数を作成する仮想評価関数作成手段と、
前記仮想評価関数に基づいて前記システムを制御するシステム制御手段を有し、
前記仮想評価関数作成手段は、前記仮想評価関数を、前記機能ブロックの評価関数の微分関数の逆関数に基づいて作成することを特徴とするシステムの制御装置。
【請求項９】
前記仮想評価関数作成手段は、前記機能ブロックの各々の動作レベルを数１４（iは機能ブロックの番号）、前記機能ブロックの評価関数を数１５、前記評価関数の動作レベルによる微分を数１６、その逆関数を数１７とすると、前記仮想評価関数の横軸を数１８、縦軸を数１９とした場合（ｊは仮想評価関数を作成する仮想機能ブロックの番号）、ある値（数２０）に対して、数２１、数２２となる仮想評価関数を作成することを特徴とする請求項８に記載のシステムの制御装置。
【数１４】
0006052896.tif 000035
【数１５】
0006052896.tif 000036
【数１６】
0006052896.tif 000037
【数１７】
0006052896.tif 000038
【数１８】
0006052896.tif 000039
【数１９】
0006052896.tif 000040
【数２０】
0006052896.tif 000041
【数２１】
0006052896.tif 000042
【数２２】
0006052896.tif 000043
【請求項１０】
前記仮想評価関数作成手段は、前記仮想機能ブロックを複数個まとめて、さらに上位の仮想機能ブロックとし、前記仮想機能ブロックの仮想評価関数を用いて、前記上位の仮想機能ブロックの仮想評価関数を作成することにより、階層的な仮想機能ブロックを作成することを特徴とする請求項８又は９に記載のシステムの制御装置。
【請求項１１】
前記評価関数が凸関数であることを特徴とする請求項８から１０のいずれか１項に記載のシステムの制御装置。
【請求項１２】
前記システム制御手段は、前記機能ブロックの評価関数又は前記仮想評価関数の微分値を比べることにより、前記システムを制御することを特徴とする請求項８から１１のいずれか１項に記載のシステムの制御装置。
【請求項１３】
前記システム制御手段は、前記機能ブロック又は前記仮想機能ブロックの各々の動作レベルを数２３（iは機能ブロック又は仮想機能ブロックの番号）、前記機能ブロック又は前記仮想機能ブロックの評価関数を数２４、前記評価関数（数２４）の動作レベルによる微分を数２５とすると、数２６なる関係(jはiと関係を持つ機能ブロック番号)が成立する方程式を用いて動作レベルを決定することを特徴とする請求項８に記載のシステムの制御装置。
【数２３】
0006052896.tif 000044
【数２４】
0006052896.tif 000045
【数２５】
0006052896.tif 000046
【数２６】
0006052896.tif 000047
【請求項１４】
前記システムは、前記複数の機能ブロックを自律分散適応的に統合して動作させることを特徴とする請求項８から１３のいずれか１項に記載のシステムの制御装置。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、複数の機能ブロックを有し、それらの機能ブロックを自律分散適応的に統合して動作させるシステムの制御方法及び制御装置に関する。
【背景技術】
【０００２】
現在、システムの大規模化あるいはシステム化されていなかったものが突如大規模システム化するという現象が様々な領域で進展している。前者の代表的なものとしては、クラウドと呼ばれる技術に関係したデータセンター、ネットワークなどのＩＴ分野であり、これらは年々規模が大きくなっている。また、後者としては、電力、エネルギー網、都市といったインフラ領域であり、スマートグリット、スマートシティといった大規模システムの案件として突如制御対象になりつつある。したがって、大規模システムをいかに制御していくかは今後非常に重要な課題になることが予想される。
それに加え、昨今のエネルギーコンシャスな社会情勢は、無駄に起動しているものを停止するなどして、電力を無駄にしない制御を求めている。これはＩＴ分野、インフラ領域を問わず共通な傾向である。一般的には、無駄な起動を行っている制御体を停止するなどの制御が有効である。
電力網に関しては、現時点ではその制御される発電所が限られているものの、効率的に電気を生み出すために、どの発電所を起動し、どの発電所を停止するかという問題が古くから検討されてきている。これは一種の負荷分散の問題であり、「起動停止問題」と呼ばれている。「起動停止問題」は、発電所の起動と停止だけの問題ではなく、発電所の起動と停止を決めた後、起動している発電所に負荷を最適に配置するという問題も内包している。これは、起動停止と負荷の最適配備の総合的問題である。これまでの解法としては、確定的な数理計画モデルとして、シナリオを想定してオフラインでスケジューリングする方法が取られている。
今後、さらに省エネルギー社会が志向されると、従来の電力網に無数の太陽エネルギーが接続されてくることが予想される。太陽光エネルギーは自然界の状態により変動するため、これまでのようにオフラインでスケジューリングしておいて、発電所を運用する方式は困難になることが予想される。これは、制御対象が大多数になり、かつ、想定外の外乱に対応しないといけないことを意味している。想定外の外乱に対応するには、オフラインのスケジューリングでは無理で、今後は、無数の（大規模な）電力ノードに関して、リアルタイムで「起動停止問題」を解く方法が望まれると考えられる。
この「起動停止問題」はＩＴ分野にも同じように存在する。
ＩＴ分野におけるシステムで実施される制御としては、計算リソース、ネットワークの負荷分散、ストレージの配置分散などの制御が挙げられる。例えば、計算リソースの負荷分散制御がどのように行われているかを、複数サーバから構成されるデータセンター（ＤＣ）をターゲットとした負荷分散方式を例として説明する。
従来の制御の基本的な発想は、「システムの内部状態をバランスさせる」という素朴なものに帰結される。このような発想の場合、一様なシステム（同一サーバが複数）の場合には、制御方針は明らかであるが、異機種混合型システムになると、どんな指標に基づいてバランスさせるべきなのかが明らかではない。
例えば、同一性能のサーバの場合には、各サーバのＣＰＵ使用率をバランスさせれば良いということが知られている一方で、性能が異なるサーバの場合には、性能に応じたＣＰＵ使用率のバランス方法が自明ではない。従来よく使われる指針である待ち行列理論で得られる結果は、確率論に基づく指針であり、どのような手段を用いて確率的な定常状態にシステムを導くか自体は、何も教えてくれない。
これは何を意味するかというと、レスポンスやスループットと言った満たすべき用件を最終的には満たすことができるかもしれないが、途中のプロセスや最終的に使用されているリソースの状況に関しては何の保証、制約もないことを意味している。それは即ち、エネルギー的には非常に非効率な状態になっていてもとりあえず、性能を満たすという制御になっているということである。
このような制御では、システムが大規模になればなるほど、このような非効率は大きくなっていき、大きな問題となることが予想される。的確に停止すべきサーバは停止し、起動すべきサーバは起動するということがここでも重要で、サーバの負荷分散なども「起動停止問題」の一種と考えてよい。
この「起動停止問題」は、ストレージの配置制御など多くの制御問題にも絡んでくる問題である。しかしながら、リアルタイムで「起動停止問題」を解く方法は非常に困難で、これまで存在しなかった。
これに関連する技術として、例えば、特開２００２−１６５３６７号公報（特許文献１）、特開２００７−１６６８５５号公報（特許文献２）、特開２０１０−２７９２３８号公報（特許文献３）等がある。
特許文献１は、電力系統の運用状況、負荷状況に対応して、需要家の電圧を適正に維持すると共に、送電損失低減などの経済運用が可能な電圧・無効電力制御システムに関する。特許文献２は、発電機起動停止計画における運用コストの最小化を図るものである。特許文献３は、分散型電源が漸次追加接続される電力系統であっても電力系統全体を安定して監視制御するシステムに関する。
【先行技術文献】
【特許文献】
【０００３】
【特許文献１】特開２００２−１６５３６７号公報
【特許文献２】特開２００７−１６６８５５号公報
【特許文献３】特開２０１０−２７９２３８号公報
【発明の概要】
【発明が解決しようとする課題】
【０００４】
発電所、サーバといった機能ブロックに評価関数を設定することにより、リアルタイムに「起動停止問題」を解くことは本願発明者の考案により基本的には可能であるが、近年、機能ブロック（または要素）が大多数になっており、この方法をより効率的に制御できる方法が望まれている。
このように、大規模かつ複雑なシステムを、外乱に対してロバストに動作させたり、リアルタイムで状況依存的に変化させたりするのは非常に困難な課題である。また、これらの制御をスケーラブルに実施することはほぼ不可能であった。
本発明の目的は、上述した従来技術の課題を解決するための技術を提供することにあり、大規模かつ複雑なシステムを、外乱に対してロバストに動作させたり、リアルタイムで状況依存的に変化させたりすることが可能なシステムの制御方法及び制御装置を提供することにある。
【課題を解決するための手段】
【０００５】
本発明に係るシステムの制御方法は、
相互に関係性を持つ複数の機能ブロックを有するシステムの制御方法であって、
前記複数の機能ブロックの各々に対応した機能ブロックの状態に関する評価関数を設定し、
前記複数の機能ブロックの中から選ばれた所定の機能ブロック群を仮想機能ブロックとし、
前記仮想機能ブロックに含まれる機能ブロックの評価関数を用いて仮想評価関数を作成し、
前記仮想評価関数に基づいて前記システムを制御することを特徴とする。
また、本発明に係るシステムの制御装置は、
相互に関係性を持つ複数の機能ブロックを有するシステムの制御装置であって、
前記複数の機能ブロックの各々に対応した機能ブロックの状態に関する評価関数を設定する設定手段と、
前記複数の機能ブロックの中から選ばれた所定の機能ブロック群を仮想機能ブロックとし、前記仮想機能ブロックに含まれる機能ブロックの評価関数を用いて仮想評価関数を作成する仮想評価関数作成手段と
前記仮想評価関数に基づいて前記システムを制御するシステム制御手段を有することを特徴とする。
【発明の効果】
【０００６】
本発明によれば、大規模かつ複雑なシステムを、外乱に対してロバストに動作させたり、リアルタイムで状況依存的に変化させたりすることができる。これにより、これらの制御をスケーラブルに実施することが可能になる。
【図面の簡単な説明】
【０００７】
図１は、「起動停止問題」を示すシステム概略図である。
図２は、本発明で用いる評価関数の概略図である。
図３Ａは、本発明で用いる指標と評価関数の関係の概略図である。
図３Ｂは、本発明で用いる指標と評価関数の関係の概略図である。
図４は、本発明の検証に用いた一例としてのネットワーク構造の概略図である。
図５Ａは、本発明の動作結果の一例を示す説明図である。
図５Ｂは、本発明の動作結果の一例を示す説明図である。
図５Ｃは、本発明の動作結果の一例を示す説明図である。
図６Ａは、本発明の動作結果の一例を示す説明図である。
図６Ｂは、本発明の動作結果の一例を示す説明図である。
図６Ｃは、本発明の動作結果の一例を示す説明図である。
図７は、ロードバランサを一つ使用する機能ブロックのネットワーク構成の概略図である。
図８は、ロードバランサを階層化して使用する機能ブロックのネットワーク構成の概略図である。
図９は、本発明の実施例１で検討したシステム概略図である。
図１０は、本発明のアーキテクチャの概略図である。
図１１Ａは、本発明の実施例１における実験結果を示す説明図である。
図１１Ｂは、本発明の実施例１における実験結果を示す説明図である。
図１２は、本発明の実施例２で検討したシステム概略図である。
図１３は、本発明で用いる評価関数の一例を示す説明図である。
図１４Ａは、本発明の実施例２における実験結果を示す説明図である。
図１４Ｂは、本発明の実施例２における実験結果を示す説明図である。
図１５Ａは、本発明の実施例２における実験結果を示す説明図である。
図１５Ｂは、本発明の実施例２における実験結果を示す説明図である。
図１６は、本発明の実施例３で検討したシステム概略図である。
図１７は、本発明の実施例３における実験結果を示す説明図である。
図１８は、本発明の実施例３における実験結果を示す説明図である。
【発明を実施するための形態】
【０００８】
以下、本発明の実施の形態を、図面を参照しながら詳細に説明する。
本発明の実施の形態は、以下の方法により、リアルタイムで「起動停止問題」を解く方法を提供する。つまり、機能ブロックに評価関数を設定し制御する方法をより効率的に実施することにより、機能ブロックが大多数になっても問題なくシステムを制御できるようにする。
本発明の実施の形態について、発電機の「起動停止問題」を例に取り説明する。
この発電機の「起動停止問題」は、性能の異なる発電機が混在する場合を想定している。発電機は能動的にパワを調整できるものを想定しており、太陽光など受動的に発電するものは、この説明では想定していない。
受動的な発電機を能動的システムに組み込むときは、逆潮流などの問題を制御するブロックを組み込み、そこを制御すれば、基本的に本発明を適用できる。性能の異なる発電機が複数個（Ｎ個）存在し、それが電力ネットワークを形成し、全体需要を満たしながら、無駄のない発電を実行するという問題を考える。無駄のない発電という意味は、発電量の調整のみならず、発電機の起動・停止も含むので、これは「起動停止問題」となる。ここで、この「起動停止問題」のシステム概略図を図１に示す。
解くべき問題は、２つの問題が混在している構造になっている。一つは、起動停止の決定であり、もう一つは負荷の配置である。本明細書では、制御対象を機能ブロック、要素、リソース、ノードと表現するが、どれも同じである。
起動停止とは、リソース群があった場合、どのリソースを使い、どのリソースを使わないかを決定または管理する問題である。また、負荷の配置は、リソースが与えられたとして、系全体に与えられた仕事をどのように割り振れば、ある指標の基に最適化できるかという問題である。これらの問題は従来、個々に、確率論的なアプローチで解くことを試みられていることが多いが、単純な確率論では、変幻自在に変わっていく環境の中で、状況に応じてロバスト・リアルタイムに即応することが難しい。
本発明は、これら２つの問題を一体のものとし、状況に応じてロバスト・リアルタイムに即応できるアーキテクチャを提供する。その際、それぞれの問題を、確率論ではなく、決定論的または関係論的な方法で解く方法を提供する。
上記アーキテクチャでは、完璧な最適化として、起動停止と負荷の配置を一体として解いたが、起動停止だけを決定するなど個別に使用することも可能である。
「起動停止問題」は系全体（この場合、発電機ネットワーク全体）で満たさなくてはいけない総需要がある。これを満たすことを需給平衡化と言い、ひとつの拘束条件となる。これが満たされないまま、効率や利潤が最大化されても意味がない。今回の場合、需要とは、動作レベル（数１）（ｉは機能ブロックの番号、ここでは発電機の番号）の総和となり、以下の数２で表される。
0006052896.tif 000002
動作レベルは機能ブロックの状態と考えても良い。今回の説明では、発電機のパワと考えれば良い。
需給平衡化を達成しようとした場合、各要素（リソース）の動作レベルは以下の方程式（数３）で決定すればよい。
0006052896.tif 000003
ここで、Ｋ１は動作レベル変更のゲインに相当する係数である。また、数４は要素ｉの規格化係数で、必ずしも必要でないが、要素がヘテロな場合、全体で規格化した係数を乗算しておいた方が良い場合が多いので、数３に導入している。
0006052896.tif 000004
数５は要素の規模に相当する量である。数３に従い、各要素の動作レベルを制御すると、システム全体として、拘束条件であるＤｅｍを満たすように動作する。
0006052896.tif 000005
次に、負荷の配置である全体利潤最大化を考える。これは全体効率最大化と読み替えても構わない。ここで、本発明では、図２のような各要素と関係する評価関数を導入する。
この場合、横軸は各要素を制御するパラメータであり、今回の例では発電パワ量などに相当する。縦軸は、何らかの効率または利潤に関わる指標である。この何らかの効率に関わる指標の例は以下の実施例のところで詳説するので、ここでは、一般的な効率として捉えることとする。
この効率に関わる評価関数を凸関数で表す。凸関数を使用するのも本発明のポイントである。なぜなら、多くのシステムは何らかの効率やシステムの安定性などを図３Ａ、図３Ｂに示すような凸関数で表されるからである。図２に示すように、上に凸な関数を凹関数と呼び、下に凸な関数を凸関数と呼ぶこともあるが、ここでは、関数の性質上で区別する表現を採用し、凹関数も凸関数と表現することにする。
評価関数が凸関数である要素を連携させて、全体で最適化（各要素の評価関数の値の総和が最大となる状態）する問題は、「凸計画問題」として知られており、各要素の動作レベルにおける評価関数の微分値が等しい状況で最適化が達成されることが数学的に明らかにされている。本発明ではこの原理を応用している。今回、評価関数として凸関数を使った理由がここにある。
この原理を勘案し、全体利潤最大化を達成する方程式（数６）を以下のように記述した。
0006052896.tif 000006
ここで、Ｋ２は動作レベル変更のゲインに相当する係数である。この制御をかけることで、各要素は動作レベルにおける評価関数の微分値（数７）を等しくしようとして動作する。
0006052896.tif 000007
最終的に需給を満足させながら最適な負荷配置を行うには、上記の需給平衡化と全体利潤最大化を同時に解くことが必要なので、各要素の動作レベルの制御は両者を統合した以下の式（数８）で制御する。
0006052896.tif 000008
上記までの説明の手法で、負荷の配置の問題はリアルタイムに解くことができる。
次に、この起動停止をどのように決定していくかについて以下に説明する。
まず、自身のノードと、そのノードに隣接するノードの評価関数間にある指標を定義する。図３に、本発明で用いる指標と評価関数の関係の概略図を示す。
負荷が０のときに、効率または利潤（縦軸）が負の値を取っている意味は、起動によりコストが発生することを意味している。例えば、発電所の場合、縦軸を利潤と考えれば、運転（起動）しているにも関わらず、需要がなければ、需要家からお金を集めることができず、運転（起動）コストの分だけ利潤がマイナスになる。グラフはそのような状態を意味している。
下記の実施例のところで示すが、データセンターのレスポンスを最適化するようなときは、縦軸がレスポンス関連量となり、負荷０のところでも評価関数は正の値を持つ。負荷０において、評価関数は正負どちらもとる可能性があるのだが、負の値をとる方を考えておけば、正の値をとる場合はその一部として解くことができる。従って、ここでは、負荷０において、評価関数が負の値をとるケースで説明する。
ここで、ノードｉ（自身）のゼロクロス点を数９、隣接ノードｊの評価関数における、ノードｉのゼロクロス点と同じ傾きの点を数１０、隣接ノードｊの現在の負荷を数１１とする。したがって、数１２は以下の式（数１３）で書くことができる。
0006052896.tif 000009
0006052896.tif 000010
そして、ここで以下の指標（数１４）を定義する。
0006052896.tif 000011
この指標は、現在の隣接ノードの負荷（総和）が、自身のゼロクロス点よりどれだけ大きいかを意味している。もしノードｉが停止しているとして、ノードｉを起動すべき条件は、起動することでノードｉがゼロクロス点以上の負荷を担当する状況にあるかどうかである。そうすれば利潤はマイナスにならないため、ノードｉを起動することで不利はない。指標Ｓｉはそれを数値化したものである。隣接ノードｊがノードｉのゼロクロス点における評価関数微分値と等価な数１５よりどれだけ負荷を担当しているかを示すのが右辺第１項であり、それをゼロクロス点（数１６）で引くことで（右辺第２項）、自身のゼロクロス点以上の負荷が周りに存在しているかを示す指標となっている。
0006052896.tif 000012
Ｓｉが０より大きければ、ノードｉを起動したときにいずれ隣接ノードが担当している負荷はノードｉが担当することになり、かつノードｉの担当負荷はゼロクロス点以上となる。逆に、Ｓｉが０より小さければ、ノードｉが隣接ノードｊの担当負荷を新たに担っても、ゼロクロス点以下となり、ノードｉの起動により利潤をマイナスにしてしまう。指標Ｓｉはこのようなものであり、Ｓｉの正負を見ることでノードｉを起動すべきか停止すべきかがわかる。Ｓｉが負のときとは、その時点でノードｉの負荷は評価関数が負の値をとる領域にあるということで、起動しているノードは評価関数が０以下になった時点で停止すると考えても良い。
起動しているノードを停止する場合にはもうひとつ考慮しなければならないことがある。ノードの性能が同じ場合の起動停止に関してである。先ほども述べたが、起動コストがかかる場合、どれか一つのノードだけ起動し、残りは停止したほうが良いことが頻繁に起こる。しかしながら、性能が同じ場合、どちらを止めればいいのか今のままでは判断できなかった。そこで、本発明では、以下のアルゴリズムを導入した。
「評価関数値が０以下でかつ隣接ノードを含め最も値が低い場合は停止する。値の比較は起動しているノード間で行う。最小値が複数ある場合でも停止する。」
これにより、全結合なら、すべてのノードの性能が等しくても、最終的に１ノードだけ残ることになる。ネットワークの結合が疎の場合、このアルゴリズムでもいくつかセグメントが残ってしまう可能性はあるが、そのような場合は、ロードバランサを介して、実質的な隣接ノードを探し、上記アルゴリズムを実施するなどの方法で対処するなどが考えられる。
以上のように、数８で制御しながら、数１４の指標のモニタと、上記停止用のアルゴリズムで起動停止を決定すれば、リアルタイムに「起動停止問題」を解くことができる。これは従来のように予めスケジューリングして「起動停止問題」を解いていたのに比べ画期的なことである。なぜなら、想定外の外乱や需給変化があってもリアルタイムに即応できるからである。
また、このシステムは、基本的に自律分散的に独立に動くので、どこかが故障したりしても、故障した要素からの信号が途絶えた分だけ、他の要素が自律的にリカバーするという動作を行う。また、突然要素を増やしたり、減らしたりしても、徐々に自律的に適正な動作に向かうことができる。つまり、外乱に対して、非常にロバストであり、また、要素の増減を自由にできるスケーラビリティを有している。
従来のシステムは、故障に対して無力であったり、様々なエラー用のシーケンスを用意したりしなければならなかった。また、勝手に要素（リソース）を増やしたり減らしたりすればシステム全体の安定性が保たれるか保証はなく、そのたびにプログラム及び処理を見直さなければならなかった。本発明のシステムでは、これらの問題を自律分散適応的な制御ですべて解決することができるのである。
上記需給平衡化の説明のところで、システム全体に要求されるミッションあるいはタスクの総量を満たさなければならないという拘束条件がある場合が多いと記載したが、そうでない場合も想定されないわけではない。そのような場合は、その拘束条件を満たすように上述した需給平衡化の項を変形して、制御すれば良い。電力システムのように、需給バランスの崩れを交流周波数の変動で知ることができる場合は、需給平衡化も完全に自律分散的に実施できる。つまり、需給平衡化にまつわる情報を自身から得ることができれば、全体としての情報を必要としない真の自律分散システムになれるのである。
以下に、本発明の動作について詳細を説明する。
簡単のため、今回は３つのノードが相互に繋がった３角形の構造のネットワーク状態に対して本発明を適用した例について説明する。ここで、このネットワークの構造を図４に示す。
まず、この３つのノードに図５Ａ、図５Ｂ、図５Ｃに示すそれぞれ異なる評価関数を設定した。その後、総需要を時刻０から１０まで０．２、時刻１０から２０まで１．０、時刻２０以降にまた０．２と変化させた場合のノードの起動停止・負荷の分担を、本発明の制御で実施した。その様子も図５に示す。
総需要が０．２のときは最も利潤効率の良いノード１だけ起動し、総需要が１．０に増えると、性能の順にノード２、ノード３を起動し、負荷の分担を設定していることがわかる。そして、再度総需要が０．２になると、ノード２、３を停止して、ノード１のみ起動した状態に戻ることがわかる。本発明は数学的に起動停止問題を最適に解く仕組みとなっているので、これはリアルタイム（動的に）起動停止問題を解きながら、外乱（需要の急変）に適応しできたことを意味する。これは非常に大きな成果である。
また、３つのノードが同じ性能を持っている場合の例を図６Ａ、図６Ｂ、図６Ｃに示す。ノードの性能が同じなので、評価関数のグラフはすべて重なっており、一つに見える。この場合も、総需要を時刻０から１０まで０．２、時刻１０から２０まで１．０、時刻２０以降にまた０．２と変化させた。すべてのノードの性能が同じなので、わかりにくいが、総需要が０．２のときは、ノード３のみ起動しており、総需要が１．０のときは３つのノードで均等に負荷を分担している様子がわかる。
このように、本発明は、起動コストがあり、ノードの性能が同じ場合でも有効に最適化を行える。
次に、本発明の機能、動作及び構成について、データセンターのサーバの「起動停止問題」の例を使用して説明する。言い換えると、データセンターにおける負荷分散の問題とも言える。ここでは、性能の異なるサーバが混在していることを想定しており、性能差に応じて、上述したような凸関数の評価関数を各サーバに設定する。制御は上述した本発明の方法を使用するものとする。
図７に示すように、サーバの負荷分散の場合、一つのロードバランサ７０にサーバ（機能ブロック７１）が繋がっている構成がとられることも多い。これをスター型と呼ぶ。この場合、サーバ（機能ブロック７１）全体が担当するトータルの負荷はロードバランサ７０にまず投入され、ロードバランサが各サーバ（機能ブロック７１）の負荷割り当てを計算し、割り当て分の負荷を各サーバ（機能ブロック７１）に投げるという負荷分散が行われる。
これとは別に、ロードバランサ７０が特に存在せず、各サーバ（機能ブロック７１）に負荷が独立で投入され、それを各サーバ（機能ブロック７１）同士で負荷分散する場合もある。本発明はどちらのケースでも使用できるが、説明が簡単なスター型の場合を例に説明する。
スター型の構成を見れば明らかだが、ロードバランサ７０に繋がるサーバ（機能ブロック７１）が増えれば増えるほどロードバランサ７０の処理量は増加する。そこで、ロードバランサ７０を介した負荷分散においては、図８に示すように、ロードバランサ８０を階層化し、個々のロードバランサ８０の処理負荷を低減する方法が取られることも多い。このように階層化することで、サーバ（機能ブロック８１）の総数が増えても、ロードバランサ８０は自身に繋がる下位のロードバランサ８０の中の数個への負荷分散を考えれば良いだけになり、ロードバランサ８０の処理負荷が圧倒的に少なくなる。
しかしながら、本発明の制御方法は、ターミナルの機能ブロック８１（この場合、サーバ）の評価関数のみを設定しているのみなので、ロードバランサ８０間の負荷分散をどうすれば良いのか自明ではない。階層化されたロードバランサ８０間で負荷分散を適当に実施してしまうと、本来、ターミナルであるサーバ（機能ブロック８１）の能力に応じて負荷分散すべきものが間違ったもの（非効率なもの）になってしまう。
そこで、本発明では、機能ブロック８１がロードバランサ８０などで階層化された場合に、どのようにロードバランサ８０間で負荷分散をすれば、機能ブロック８１間で最適な負荷分散ができるかについて考案されている。ここで、サーバという機能ブロック８１がロードバランサ８０によって階層化される場合の説明をしているが、ロードバランサと同じ機能を担当する機能ブロック（ここではサーバ）をロードバランサとして設定しても良い。
その際、上位の機能ブロック（ロードバランサ役のサーバ）が負荷分散以外に、負荷そのものの処理を担当してもいいし、担当しなくても良い。担当するなら、上位の機能ブロックの評価関数も勘案して、以下の考案を実施すれば良いし、担当しないなら、上位の機能ブロックの評価関数は勘案しないで、以下の考案を実施すれば良い。
上述した本発明の制御方法は、機能ブロックに凸関数である評価関数を設定することで、自分自身に隣接する機能ブロックが評価関数の微分値を同じにするように制御するだけで、系全体（機能ブロック全体）の最適化ができるというものである。この原理を熟考すると、上述した本発明の制御方法により設定される系全体の負荷と系全体の利潤（効率）の関係もまた凸関数になり、それが機能ブロックの評価関数により一義的に設定できるはずである。これはつまり、機能ブロックを束ねるロードバランサを仮想的な機能ブロックと考えると、ロードバランサの仮想評価関数が機能ブロックの評価関数の総体として一義的に定まるということになる。
これを応用すると、機能ブロックの評価関数が設定されているだけで、図８のような階層化されたロードバランサ８０すべての仮想評価関数が設定できてしまうのである。機能ブロック８１の評価関数を用いて、まずそれを束ねるロードバランサ８０の仮想評価関数を設定し、さらにそのロードバランサ８０を束ねる上位のロードバランサ８０の仮想評価関数を設定し、最終的には頂点のロードバランサ８０の仮想評価関数を設定するといったことが可能である。このように設定された仮想評価関数は、ターミナルの機能ブロック８１（ここではサーバ）の特性を反映しているため、頂点のロードバランサ８０のみに系全体で処理する負荷を投入し、下位のロードバランサ８０の仮想評価関数を用いて、階層的に順次下位に負荷を分散させていくと、最終的にサーバに投入される負荷は最適になる。言い換えると、図７と図８の構成におけるサーバの負荷分散の量は全く同じになると言うことである。
次に、上記仮想評価関数をどのように作ればよいかについて以下に説明する。
機能ブロックそれぞれの動作レベルを数１７（ｉは機能ブロックの番号）、機能ブロックの評価関数を数１８、評価関数の動作レベルによる微分を数１９、その逆関数を数２０とすると、仮想評価関数の横軸を数２１、縦軸を数２２とした場合（ｊは仮想評価関数を作成する仮想機能ブロックの番号）、ある値（数２３）に対して、数２４、数２５とすれば良い。
0006052896.tif 000013
仮想機能ブロック同士でさらに上位の仮想機能ブロックの評価関数を作る場合、上記の数２６、数２７を数２８、数２９に読み替えて実施すれば良い。上述した本発明の制御方法では、数３０が０以下になった機能ブロックは停止させられるので、そのような機能ブロックの値は、仮想評価関数の値を計算するときに含まない。
0006052896.tif 000014
0006052896.tif 000015
仮想評価関数は、機能ブロックの起動停止状態を反映して変わっていく。つまり、リアルタイムに「起動停止問題」を解いており、また、外乱に対してロバストでもある。この特性は、仮想評価関数を使わなかったときと変わらない。
本発明により、機能ブロックが大多数になったときでも、効率的に制御を実施することが可能となる。また、以下の実施例で示すが、本発明は「起動停止問題」だけではなく、ロボットのアクチュエータの制御など、通常の制御でも使用できる。
以下、本発明の実施例について詳細に説明する。
【実施例１】
【０００９】
図９に示した発電機の「起動停止問題」に対して、本発明を実施・適用した。
この場合、動作レベル（数３１）（ｉは機能ブロックの番号）は各発電機に割り当てられた発電パワに相当する。
0006052896.tif 000016
各発電機には、図３に示したような評価関数を設定した。発電機の性能は均一ではなく、ピーク値（α）やパワ限界値（λｍａｘ）は異なる。縦軸には、発電による利潤を置いた。したがって、評価関数値がプラスなら、発電により儲かり、マイナスなら発電により損失が発生する。需要にあわせて最も利潤が高くなるように制御するのが全体として望ましい。起動によりコストが発生するので、負荷が０のときの評価関数値はマイナスとなる。また、評価関数は凸関数である２次関数で設定した。発電機の利潤関数は２次曲線で近似できることは知られている。
本実施例では、需要家９０に最も近いところにロードバランサ機能を持つ機能ブロック９１を配置する。発電機９２はこのロードバランサ（機能ブロック９１）によっていくつかのセグメントに分割された状態となる。ロードバランサ（機能ブロック９１）間はネットワーク９３で繋がっており、全体として連結した発電機ネットワークを形成している。
図１０に示すように、各ロードバランサ（機能ブロック９１）には、本発明に係る制御システム１００が内蔵されている。
図１０に示すように、制御システム１００は、仮想評価関数作成部１０１とシステム制御部１０２を有する。仮想評価関数作成部１０１は、自身に連なる発電機９２の評価関数を用いて、仮想評価関数を作成する。システム制御部１０２は、仮想評価関数を他のロードバランサと比べることで、それぞれのセグメントの負荷の割り当てを決定する。
その後、割り当てられた負荷を、自身に連なる発電機９２の評価関数をもとに、同様に発電機９２に割り振る。これによって、系全体の負荷を最適化する。
発電機９２の制御の場合、全体需要を満たせているかどうかをローカルに知ることができる。ローカルに知るとは、発電機９２が全体の情報を得ることなしに、自分が周りから得ることができる情報で知ることができるということである。電力が供給不足な時は、交流周波数は系統全体において一様に減少し、供給過剰な時は逆に、交流周波数は増加することが知られている。
その原理を使えば、全部の発電機９２の発電パワを知らなくても、ローカルに全体需要に対する発電パワの過不足を判断できる。つまり、ローカルに数４の右辺第１項を計算できる。また、数４の右辺第２項はそもそもローカルに仕入れる情報なので、結果的に、発電機９２はローカルな情報のみで数４の制御を実現できる。
したがって、全体需要に関する情報を知るために、すべての発電機９２の発電パワをモニタする中央集権的な装置は必要ない。今回の場合は、制御システム１００を発電機９２ではなく、ロードバランサ（機能ブロック９１）に設定しているが、事情は同じで、各ロードバランサ（機能ブロック９１）は、全体需要をローカルに知ることができる。
負荷分散を決定する係数Ｋ１、Ｋ２などは適宜設定した。また、各発電機９２の利潤は均一ではなく、利潤が高いものほどαｉは大きくなっている。
本発明を従来のものと比べるために、従来のシステム構成の実施も行った。この場合は、図１に示す発電機ネットワークを使った。発電機１１の数、位置と、需要家の数、位置は図９と同じで、ネットワーク構成が階層化されているか、されていないかの違いがある。
従来例（図１参照）では、階層化は行われておらず、ロードバランサ的な機能ブロックを全く置いていない。したがって、発電機１１のそれぞれに図１０と同じ制御システム１００を設定した。ただし、この場合は、仮想評価関数作成部１０１（図１０参照）は必要ないので、仮想評価関数作成部１０１は使わず、システム制御部１０２（図１０参照）のみを使用した。
図１１に本発明を適用した実施例１と従来例の実験結果を示す。
グラフの横軸は時間、縦軸は、システム全体の電力（電力量、図１１Ａ参照）、起動している発電機の数（起動リソース量、図１１Ｂ参照）である。
ある電力需要で動作させている途中で、人為的に１割の発電機を止めた（図中矢印の部分）。実線が本発明を適用した実施例１の場合で、破線が従来例の階層化していない場合である。
どちらの場合も、一時的に電力供給能力が下がるが自律的に回復する様子がわかる。しかしながら、本発明を適用した実施例１の方が、回復が速いこともわかる。これは、階層化（図９参照）により、計算・ネットワークが効率的になっているためで、本発明の有効性が確認された。また、発電機の能力は均一ではなく、ヘテロな状態なので、自律的に回復した後に使用されている発電機の数は、人為的に発電機を止めた前後で変わっている。これは、まさしく自律的に起動停止問題を解いていることを意味している。故障に対するロバスト性に関して、本発明が有効であることも確認できた。
【実施例２】
【００１０】
実施例１では、発電機の起動停止問題の制御を実施したが、本発明の適用範囲が広範にわたることを示すため、実施例２以降では他領域での実施例を示すことにする。
図１２に示すデータセンターのリソース負荷分散に対して、本発明を実施・適用した。この場合、動作レベル数３２（ｉは機能ブロックの番号）は各リソースに割り当てられたタスク量（仕事量）に相当する。
0006052896.tif 000017
図１２に示すように、データセンター１２０は、複数のサーバ１２１を有する。データセンター１２０のリソース負荷分散を考えた場合、管理者がこだわる制約条件としては、レスポンス、スループット、エネルギーなどが挙げられる。
まず、最初に、レスポンスとスループットが制約条件になっている場合の本発明の実施例を示す。
レスポンスとスループットは密接に絡み合った量である。しかも、トレードオフの関係にある。簡単に説明すると、サーバ１２１の処理限界に近づくほどスループットは向上し、レスポンスは低下する。また、レスポンスは、サーバ１２１の処理限界に近づいたときに急激に悪化するという特徴を持つ。これは待ち行列理論により説明されている。サーバ１２１の管理者は自分の管理するシステムのレスポンス要求とスループット要求をできるだけ両立するように、サーバ１２１にかかる負荷をバランスさせる必要がある。
次に、本発明を用いて、管理者はどのようにデータセンター１２０の負荷分散を実現すれば良いのかについて説明する。上述したように、レスポンスとスループットはトレードオフの関係にあるので、レスポンス重視にしたければ、各要素（リソース）に分散される仕事量（数３３）を低めにすれば良いし、スループットを重視したければそれを多めにすれば良い。したがって、各要素に設定する関数を例えば以下のような手法で設定していけば良い。
0006052896.tif 000018
図１３に評価関数の概略図を示す。
今回の検討課題が負荷分散なので、横軸は仕事量（数３４）とした。先にも述べたが、評価関数は凸関数が良いので、今回は上に凸な２次関数とした。λｍａｘはそのリソースの限界であり、λｐｅａｋは評価関数のピーク位置を表す。評価関数のピークを１として規格化しておくと、この場合、規格化評価関数は（０，０）、（λｐｅａｋ，１）を通る２次関数として決定できる。
0006052896.tif 000019
ここで重要なのは、実施例１と違い、原点周辺で評価関数の値が負になっておらず、サーバ１２１の起動にコストがかからないとしている点である。起動停止によるレスポンス、スループットの劣化が少ない場合は、このようにするのが適正である。
各要素（リソース）には性能差があるので、その性能差に比例した係数αｉを規格化評価関数に掛けることで、個々の評価関数とする。先にも述べたが、レスポンス重視にしたければ、各要素（リソース）に分散される仕事量（数３５）を低めにすればよいし、スループットを重視したければそれを多めにすれば良い。したがって、レスポンス重視で仕事をシステムに実施してもらいたければ、λｐｅａｋの位置を小さめに設定すれば良く、スループット重視で仕事をして欲しければλｐｅａｋの位置を大きめすれば良い。
0006052896.tif 000020
システムは本発明の方法を使って、起動停止問題を解きながら動作し、それぞれの要素のλｐｅａｋの位置をできるだけ目指す。したがって、λｐｅａｋの位置を小さめに設定していれば、それぞれの要素の負荷が比較的小さめに仕事が分散されることになり、全体としてはレスポンス重視の動作となる。
また、λｐｅａｋの位置を大きめに設定していれば、それぞれの要素の負荷が比較的大きめに仕事が分散されることになり、全体としてはスループット重視の動作となる。無駄なリソースは適宜停止させるので、エネルギー的にも無駄のない制御となる。
この場合、評価関数の縦軸は実際の何らかの効率にはなっていない。むしろ管理者が動作させたい位置であり、評価関数の設定は、何らかの物理量、法則に支配されることはない。システムを動作させたい人間が、縦軸、横軸を任意に設定することができるのである。ある意味、人間がシステムに評価関数として指示を渡すと、後はシステムが自律的に協調して動作するのである。
今回、評価関数は（０，０）、（λｐｅａｋ，１）を通る２次関数に係数αｉを掛けたものとしたが、凸関数であれば良いので、様々に設定して良い。極論すれば、手書きの評価関数を設定しても良い。
データセンター１２０内のサーバ１２１、ロードバランサの構造は、図７、図８に示したものの両方を実施した。図７の構成は、従来例であり、図８は、本発明の構成である。
どちらの場合も図１０の制御システム１００をロードバランサ７０、８０に搭載した。実施例１と同様で、従来例の場合は、仮想評価関数作成部１０１（図１０参照）は使用しなかった。
負荷分散を決定する係数Ｋ１、Ｋ２などを適宜設定した。また、サーバ１２１の総数は１０００台とした。また、各サーバ１２１の性能は均一ではなく、性能が高いものほどαｉを大きく設定した。
図１４Ａ、図１４Ｂに第１の実験結果を示す。
グラフの横軸は時間、縦軸は、システム全体の実効的なレスポンス、スループット（図１４Ａ参照）、起動しているサーバの数（起動リソース数、図１４Ｂ参照）である。
最初は、λｐｅａｋを小さめに設定し、レスポンス重視で動作させている。その後、図１４Ａ、図１４Ｂ中のスループット重視と描かれた時刻にλｐｅａｋを大きめに設定しなおしている。実線が本発明で、破線が従来の階層化していない場合である。
どちらの場合も、システムは自律的にレスポンス重視な方向に動作を変更していくことが確認された。起動しているサーバも適宜調整されており、制御が有効である様子がわかる。しかしながら、本発明の方が、動作が速いこともわかる。これは、階層化により、計算・ネットワークが効率的になっているためで、本発明の有効性が確認された。
図１５Ａ、図１５Ｂに第２の実験結果を示す。
グラフの横軸は時間、縦軸はシステム全体の実効的なレスポンス、スループット（図１５Ａ参照）、起動しているサーバの数（起動リソース数、図１５Ｂ参照）である。
あるλｐｅａｋの設定で動作させている途中で、人為的に１割のサーバを止めた（図中矢印の部分）。実線が本願発明で、破線が従来の階層化していない場合である。どちらの場合も、一時的に性能が下がるが自律的に回復する様子がわかる。しかしながら、本発明の方が、回復が速いこともわかる。これは、階層化により、計算・ネットワークが効率的になっているためで、本発明の有効性が確認された。
また、サーバの能力は均一ではなく、ヘテロな状態なので、自律的に回復した後に使用されているサーバの数は、人為的にサーバを止めた前後で変わっている。これは、まさしく自律的に起動停止問題を解いていることを意味している。故障に対するロバスト性に関しても、本発明が有効であることが確認できた。
【実施例３】
【００１１】
実施例１、２では、いわゆるシステムの制御を実施したが、本発明は基本的に複数の機能ブロックを協調させるものなら何でも使用できる。例えば、ロボットなどのアクチュエータの制御にも使用できる。本実施例では、このようなアクチュエータの制御に本発明を実施・適用した。
本発明を、図１６に示す６筋２関節２リンクの冗長筋骨格系に適用した場合を説明する。
６筋２関節２リンクの冗長筋骨格系とは、文字通り、６つの筋肉部（筋肉１〜筋肉６）と、２つの関節（関節１、関節２）がある人間の手のモデルである。２次元平面での腕の動きを良く再現するモデルである。
所望の手先の動きを設定すれば、関節のトルクが計算できる。関節のトルクと各筋肉の収縮には関係があるので、筋肉の収縮を設定すれば、トルクへの影響を見積もることができる。しかしながら、今回のモデルの場合、筋肉の自由度の方が関節の自由度より大きいので、所望の関節のトルクを実現するための各筋肉の収縮力の値は一義的に決まらない。つまり、様々な筋肉の収縮力のセットが解となってしまう。これを解が一義的に決まらない不良設定問題と呼ぶ。このような場合、筋肉の収縮力を一義的に決定するために、拘束条件を設定するのが有効である。
本発明者は、筋肉の効率を最小にするように筋肉の収縮力のセットを決めるべきと考えている。これはエネルギー的にメリットがあるからである。そのような場合、この問題は、本発明者が考案した「起動停止問題」、つまり負荷分散の問題となる。どの筋肉を動かせば（これが負荷に相当）、最も効率が良く制御できるかという問題になるのである。筋肉の収縮力を負荷として、そのときの筋効率をできるだけ最適化するように本発明の方法で制御する。
本発明の方法は、リアルタイムに負荷分散を実施できるので、ロボットなどの制御機器の制御には非常に有効である。今回は腕の例を提示しているが、ロボットの脚でも同様の制御が出来る。脚を考えると、リアルタイム性がいかに重要であるかが簡単にわかるであろう。負荷分散を計算している時間が長ければ、計算の間にロボットは転んでしまうからである。
本発明の制御方法を、ロボットの腕に応用するために、各筋肉の評価関数を設定した。この場合、負荷は筋肉の収縮力であるので、横軸は筋肉の収縮力とした。また、筋肉の効率を最大化するために、縦軸は筋効率を設定した。一般的に、筋肉の効率の式は以下の数９のように記述される。デフォルトの消費エネルギーをＨｄｅｆ、仕事時消費エネルギーをＷ（λ）、仕事時追加消費エネルギーをＨとすると、以下のようになる（数３６）。
0006052896.tif 000021
一般的には、この効率はλｍａｘ（この場合、筋収縮の最大値）以下のどこかでピークを迎える凸関数になる。
このモデルで本発明と従来例の比較を行った。本発明の実施例としては、筋肉１、２、３（図１６参照）をまとめて、それに負荷を分散するロードバランサ的な処理ユニット（図示せず）を設置した。
したがって、図１０に示す本発明の制御システム１００は、その処理ユニットに設置されることになる。図１６には示していないが、処理ユニットはリンク１に装着した。各筋肉を駆動する駆動ユニットは各筋肉近くに装着しており、ロードバランサ的な処理ユニットは、それら駆動ユニットに指示を出す。従来例では、各筋肉を駆動する駆動ユニットに図１０の制御システム１００を設置した。実施例１、２と同様で、従来例では、仮想評価関数作成部１０１（図１０参照）は動かさない。
ロボットの腕を制御して、目標位置に手先を移動させる制御を実施した結果を図１７に示す。これは、本発明の実施における実験結果だが、目標軌道をほぼトレースし、目標位置に手先が到達している。つまり、制御がうまく機能している。従来例でも制御は同様にできることを確認している。
一方で、図１８に、目標位置までの到達時間を、本発明と従来例に関して示す。
ここで、図１８のグラフの横軸は時間を示し、縦軸は手先位置をそれぞれ示す。また、実線が本発明で、破線が従来の階層化していない場合である。本発明の方が、より早く目標位置に到達しており、本発明が効率的に負荷分散を実施できていることが確認できる。
以上のように、本発明は、発電機、データセンター、ロボット等、非常に広範な制御機器を統一的かつ効率的に扱う手法であることが確認できた。
以上、本発明の実施の形態について実施例を用いて具体的に説明したが、本発明は上述の実施例に限定されるものではなく、本発明技術的思想に基づく各種の変形が可能である。
例えば、上記実施例２では、ＩＴ分野におけるデータセンターへの適用を提示したが、ストレージの配置負荷分散にも同様に適用できる。また、ネットワークのディレイなどを考慮しなかったが、ネットワークのディレイに相当する係数を隣接するサーバの評価関数に乗算することで考慮することができる。
また、データセンターの評価関数として、レスポンス、スループット以外に実施例３に示すようなエネルギー効率の関数を設定し、データセンターのエネルギー効率最適化を実施することもできる。
また、今回、評価関数を予め設定したが、評価関数を自律的にフィードバックで学習したり、改善したりすることも可能である。
また、ロボットなどの制御分野では、腕の実施例（実施例３）を示したが、当然、ロボットの脚、体にも応用できる。また、蛇型ロボットなど、人型でないものでも同様である。車輪が４個の車では負荷分散の効果は少ないが、車輪が沢山あるような車などがあれば、その車輪の負荷分散にも適用できる。被制御体より、制御体の自由度が大きいような制御には基本的にどのような場合でも適用でき、大きな効果を奏する。
【産業上の利用可能性】
【００１２】
本発明は、複数の機能ブロックを有し、それらの機能ブロックを自律分散適応的に統合して動作させるシステムの制御全般に利用可能である。システムを外乱に対してロバストにし、また状況依存的にリアルタイムにシステムを適応させていくという制御を簡単かつスケーラブルに実現することができる。
本願は、２０１１年８月３０日出願の日本国特許出願２０１１−１８７７０２を基礎とするものであり、同特許出願の開示内容は全て本願に組み込まれる。
【図１】
0006052896.tif 000048
【図２】
0006052896.tif 000049
【図３Ａ】
0006052896.tif 000050
【図３Ｂ】
0006052896.tif 000051
【図４】
0006052896.tif 000052
【図５Ａ】
0006052896.tif 000053
【図５Ｂ】
0006052896.tif 000054
【図５Ｃ】
0006052896.tif 000055
【図６Ａ】
0006052896.tif 000056
【図６Ｂ】
0006052896.tif 000057
【図６Ｃ】
0006052896.tif 000058
【図７】
0006052896.tif 000059
【図８】
0006052896.tif 000060
【図９】
0006052896.tif 000061
【図１０】
0006052896.tif 000062
【図１１Ａ】
0006052896.tif 000063
【図１１Ｂ】
0006052896.tif 000064
【図１２】
0006052896.tif 000065
【図１３】
0006052896.tif 000066
【図１４Ａ】
0006052896.tif 000067
【図１４Ｂ】
0006052896.tif 000068
【図１５Ａ】
0006052896.tif 000069
【図１５Ｂ】
0006052896.tif 000070
【図１６】
0006052896.tif 000071
【図１７】
0006052896.tif 000072
【図１８】
0006052896.tif 000073