以下、図面を参照しながら、本発明の実施形態について説明する。
図1は、本発明の実施形態に係るシミュレータ装置としてのメタレベルマルチエージェントシミュレータのブロック図である。
このメタレベルマルチエージェントシミュレータは、シミュレーションコントローラ101と、複数のシミュレータ用環境と、1つまたは複数のエージェントとを備える。ここでは、シミュレータ1用環境、シミュレータ2用環境の2つの環境を備えるが、3つ以上の環境を備えても良い。
シミュレータ1、2用環境のそれぞれに対し、分野特化型シミュレータ1、2が通信可能に接続される。分野特化型シミュレータの例としては、交通シミュレータや電力シミュレータなどがある。
分野特化型シミュレータでは、1つもしくは複数の監視対象の動作および状態変化の少なくとも一方が模擬実行されている。動作の例として、監視対象が移動可能な移動体の場合に、当該移動体の移動・行動がある。移動体が自動車であれば、道路を走行する自動車の移動(位置、速度、加速度、走行方位など)や、行動(例えばライトの点灯、サイドミラーの開閉)、エレベータであれば、エレベータの上下の移動や行動(扉の開閉など)がある。状態変化の例として、監視対象の状態がパラメータにより表現可能な場合に、当該監視対象のパラメータの変動がある。監視対象が電力消費機器であれば、当該機器の電圧・電流・電力の変動、監視対象が証券取引所等の証券取引システムであれば銘柄や株価指数などの株価変動、金融機関等の為替システムであれば通貨ペア(USD/JPY等)のレート変動、商品やサービスを提供する提供体であれば当該提供体が提供する商品やサービスの価格や内容の変動がある。動作と状態変化の両方を模擬する例として、自動車の位置、速度等の動作と、残りエネルギー量などのパラメータの変動の両方を模擬する場合がある。監視対象は、自動車や電力消費機器といった装置だけでなく、人間や動物等の生物を含んでも良い。
メタレベルマルチエージェントシミュレータは、分野特化型シミュレータ1、2のシミュレーションを時間進行の同期を図りながら進めつつ、上記エージェントを用いて、分野特化型シミュレータ1、2の少なくとも一方における監視対象の動作および状態変化の少なくとも一方を、分野特化型シミュレータ1、2の少なくとも他方の監視対象の動作および状態の少なくとも一方に反映させることで、分野特化型シミュレータ1、2を横断的にシミュレーションする。一例として、模擬している監視対象のそれぞれごとに、メタレベルエージェントシミュレータにおいて、前述したエージェントが用意することで、1人もしくは複数の人間(エージェント)が複数の異分野で行動した結果を総合的に模擬する。
シミュレータ1、2用環境はそれぞれ、シミュレータ制御部(単に制御部と呼ぶ場合もある)31と、状況監視部32とを備える。状況監視部32は、エージェント・イベント別通知間隔データベース(DB)33を含む。
状況監視部32は、それに接続された分野特化型シミュレータで実行されるシミュレーションを監視する。
エージェント・イベント別通知間隔DB33は、分野特化型シミュレータで監視している監視対象別あるいはエージェント別に、検出するイベントと、通知先エージェントと、通知時間間隔を格納している。イベントは、イベントの種類に応じた監視対象の状況を、通知先エージェントに通知するものである。状況とは、監視対象の動作または状態を特定するものでもよいし、動作または状態から推定される上位レベルの行動状態でもよいし、監視対象の環境を表すものでもよい。状況の例として、監視対象が移動体であればその位置、速度などの値、移動体の周囲の移動体の台数、移動体の場所の気象情報などがある。上位レベルの行動状態の例として、自動車の残りエネルギーが一定値以下の場合に充電スタンドに向かっていると推測できる場合に「充電スタンドに向かって移動中」などの行動状態があり得る。また、監視対象が電力消費機器であれば消費電力、電圧、電流などの値が考えられる。典型的な例では、監視対象から検出したイベントは、当該監視対象に対応するエージェントに通知する構成が考えられるが、別のエージェントに通知する構成も可能である。
状況監視部32は、分野特化型シミュレータのシミュレーションの監視に基づき、通知間隔DB33で定められた通知時間間隔で、イベントを生成して、通知先エージェントのイベント受信部21に送信する。
シミュレータ制御部31は、後述するシミュレータ時間進行部13からの指示信号に応じて、該当する分野特化型シミュレータの時間進行を制御し、また、エージェントから受信される制御アクションの実行命令にしたがって、該当する分野特化型シミュレータの制御を行う。また、シミュレータ制御部31は、エージェントから受信される調節アクションの実行命令にしたがって、通知間隔DB33を更新する。更新の例としては、検出するイベント、イベントの通知先エージェント、または、イベントの通知時間間隔を変えることがある。
シミュレーションコントローラ101は、各分野特化型シミュレータ内におけるシミュレーション時間を進める役割を有する。シミュレーションコントローラ101は、トリガイベント通知部11と、シミュレータ時間進行部13を備える。
トリガイベント通知部11は、エージェント群に、定期的に意思決定を促す役割を有する。イベント通知部11は、エージェント群参照DB12を有する。エージェント群参照DB12には、エージェント群の識別情報と、エージェント毎のイベント通知間隔が格納されている。トリガイベント通知部11は、エージェント群参照DB12に登録された各エージェントのイベント受信部21に、当該DBに登録されたイベント通知間隔で、定期的に意思決定を促すトリガイベントを送信する。なお、トリガイベントを受けたエージェントでは、トリガイベントの受信回数を記録し、受信回数に応じて、事前に定めたアクションを行うことを意思決定し、当該アクションの実行命令をシミュレータ制御部31に送る。なお、シミュレーションコントローラ101は、トリガイベント通知部11を備えない構成も可能である。この場合でも、各エージェントは、シミュレータ1,2用環境から受信するイベントに応じて意思決定を行う。
シミュレータ時間進行部13は、各分野特化型シミュレータのシミュレーション時間進行の同期をとる役割を有する。シミュレータ時間進行部13は、環境群参照DB14を有する。環境群参照DB14は、複数のシミュレータ用環境の情報が登録されている。シミュレータ時間進行部13は、環境群参照DB14に登録された各シミュレータ用環境に対し、該当する分野特化型シミュレータのシミュレーション時間を一定時間Δt進めるように指示する信号(指示信号)を出力する。各シミュレータ環境は、シミュレータ時間進行部13から指示信号を受け取る。指示信号を受け取ったシミュレータ用環境のシミュレータ制御部31は、シミュレーション時間をΔtだけ進めるよう分野特化型シミュレータを制御する。Δtは、各シミュレータ用環境で同じ値である。なお、分野特化型シミュレータごとにΔtだけシミュレーション時間を進めるのに要する実際の時間はそれぞれ異なってよい。
ここで、シミュレータ時間進行部13は、各シミュレータ用環境に同時に一定時間Δtを進める指示信号を出力し、全ての分野特化型シミュレータのシミュレーション時間がΔt進むのを待ってから、次の一定時間Δtを進める指示信号を出力してもよい。または、各シミュレータ用環境に1つずつ順番に一定時間Δtを進める指示信号を、1つの分野特化型シミュレータ用の処理が完了するごとに順番に出力しても良い。シミュレータ時間進行部13は、一定時間Δtだけシミュレーション時間が進んだことの確認を、シミュレータ用環境から応答確認信号を受け取ることで行っても良い。
メタレベルマルチエージェントシミュレータの各エージェントは、イベント受信部21、意思決定部22、実行命令送信部29を備える。
イベント受信部21は、外部から通知されるイベントを受信する。外部とは、各シミュレータ用環境の状況監視部32、およびトリガイベント通知部11である。なお、トリガイベント通知部11が設けられない場合は、イベント受信部21は、状況監視部32からイベントを受信する。
意思決定部22は、シミュレータ制御ルールDB20、センシング結果評価部23、信念DB26、信念DB更新部27、意思決定処理部28を備える。意思決定処理部28は、制御意思決定部24、調節意思決定部25を備える。
意思決定部22は、イベント受信部21で受信されたイベントをトリガにして、シミュレータ制御ルールDB20に格納された制御ルールに基づき、ルールベース推論を行うことで、該当するアクションを実行することを意思決定し、アクションの実行命令をシミュレータ用環境に送信する役割を有する。アクションの実行命令を受け取ったシミュレータ用環境のシミュレータ制御部31は、分野特化型シミュレータをアクションの実行命令に従って制御する。たとえばアクションの内容に従って、該当シミュレータにおける監視対象の動作または状態を制御する。本実施形態の特徴の1つは、エージェントにイベントを通知したシミュレータ用環境と、当該イベント通知に起因してアクションの実行命令を受けるシミュレータ用環境とが同じ場合だけでなく、異なる場合を提供する点にある。これにより、複数の分野にわたった横断的なシミュレーションを可能にする。また人間等の監視対象(またはエージェント)が複数の異分野で行動した結果を総合的にシミュレーションすることを可能にする。
シミュレータ制御ルールDB20は、1つまたは複数の制御ルールを格納する。制御ルールには、イベントと、条件と、アクションが定義される。制御ルールに示されるイベントが受信され、かつその制御ルールの条件が満たされることを制御ルールが発火すると呼ぶ。また、制御ルールが発火するためのイベントと条件とをまとめて発火条件と呼ぶ。つまり、その制御ルールに示されるイベントが受信され、かつその制御ルールの条件が成立する場合は、発火条件が満たされる、あるいは制御ルールが発火すると呼ぶ。なお、制御ルールから、条件が省略される構成も可能であり、その場合は、その制御ルールが選択されるイベントが受信された場合、その制御ルールの発火条件が満たされる。
制御ルールは、If-then形式、If-when-then形式など、任意の形式で記述することができる。たとえばif-then形式では、if内部にイベント、then内部にアクションを記述することで、if内部に定義されたイベントが受信された場合は、then内部に記述されたアクションの実行を決定することを表現できる。また、if-when-then形式では、if内部にイベント、when内部に条件、then内部にアクションを記述することで、if内部に定義されたイベントが受信され、かつwhen内部に定義された条件が成立する場合は、then内部に記述されたアクションの実行を決定することを表現できる。
アクションの実行を決定するための条件は、たとえばイベントのパラメータ(値)(監視対象の状況を示すセンシングデータの値)や、イベントのパラメータを用いた所定の計算式を用いて記述することができる。イベントのパラメータは、今回受信されたイベントのみならず、過去に受信されたイベントのパラメータを用いることもできる。
センシング結果評価部23は、外部から通知されたイベントと、信念DB26(後述)とのうち少なくとも前者に基づき、シミュレータ制御ルールDB20に格納された各制御ルールの発火条件が満たされるか評価する。すなわち、外部から通知されたイベントに応じて制御ルールを選択し、選択した制御ルールに記載された条件が成立するかを判断する。制御ルールに記載された条件は様々であり、条件の内容によっては、イベントの値や過去に受信されたイベントの値などを用いて所定の計算式を計算することで、条件が成立するかを判断する。過去に受信されたイベントの値や、過去に計算した結果を記憶しておくために信念DB26が用いられる。
信念DB26には、過去に外部から通知されたイベントの値等、条件が成立するかの計算を行うために必要な情報が記憶されている。信念DB26は信念DB更新部27により更新される。信念DB更新部27は、センシング結果評価部23の指示信号に従って、信念DB26を更新する。条件の成否を判定に、過去に通知されたイベントの値を用いず、今回通知されたイベントの値のみ用いる構成の場合は、信念DB26および信念DB更新部27を用いない構成も可能である。
センシング結果評価部23は、発火条件が満たされると判断された制御ルールが存在するとき意思決定処理部28を起動し、また信念DB26の更新が必要な場合は、信念DB更新部27を起動する。発火条件が満たされる制御ルールが存在しない場合は、信念DB更新のみ起動する構成や、何も行わない構成が考えられる。
センシング結果評価部23は、各制御ルールの条件の中に過去(たとえば前回)受信したイベントの値を用いるものがあるときは、今回受信されたイベントの値を、次回の処理で使えるように、信念DB26に記憶するよう信念DB更新部27に指示信号を出力する。信念DB更新部27は、センシング結果評価部23の指示信号に従って、信念DB26を更新する。一定期間前以上の古いデータなど、センシング結果評価部23での処理に使わないデータは消去してもよい。
意思決定処理部28は、センシング結果評価部23により発火条件が成立すると判断された制御ルールに定義されたアクションを読み出し、当該アクションを実行することを意思決定する。アクションとして、分野特化型シミュレータを制御するアクション(制御アクション)と、分野特化型シミュレータの監視対象となるイベントの種類・イベントの検出の頻度を調節するアクション(調節アクション)がある。また調節アクションに、監視対象の変更を行うアクションを含めても良い。
意思決定処理部28は、読み出したアクションが制御アクションである場合は、制御意思決定部24において、当該制御アクションを実行することを意思決定し、調節アクションである場合は、調節意思決定部25において、当該調節アクションを実行することを意思決定する。
実行命令送信部29は、意思決定処理部28で決定されたアクションの通知先となるシミュレータ用環境を、環境群参照DB30を参照して決定し、決定した通知先にアクションの実行命令を送信する。環境群参照DB30は、アクションごとに、分野特化型シミュレータの識別子を格納している。実行命令送信部29は、意思決定処理部28により決定されたアクションに対応する分野特化型シミュレータを特定し、特定した分野特化型シミュレータに接続されているシミュレータ用環境に、当該アクションの実行命令を送信する。
アクションとして制御アクションの実行命令を受信したシミュレータ用環境の制御部は、当該制御アクションの実行命令に従って分野特化型シミュレータを制御する。たとえば、当該シミュレータで模擬されている監視対象を、当該制御アクションに従って動作または状態変化させる。また、アクションとして調節アクションの実行命令を受信したシミュレータ用環境の制御部は、状況監視部32に対して、監視対象となるイベントの種類やイベントのセンシング頻度(検出頻度)等の変更の指示信号を出力し、状況監視部32は、指示信号に従って、通知間隔DB33を更新する。
意思決定部22は、トリガイベント通知部11からトリガイベントを受信した場合は、センシング結果評価部23により、シミュレータ制御ルールDB20を参照し、発火条件が満たされる制御ルールを選択する。制御ルールの条件には、たとえばトリガイベントの合計受信回数に関する条件が記載されていてもよい。この場合、センシング結果評価部23は、前回までの受信回数を信念DB26から読み出してインクリメントすることで合計受信回数を更新し、更新後の値を信念DB26に書き戻す。センシング結果評価部23は、合計受信回数が条件を満たす場合は、意思決定処理部28に発火条件が満たされた制御ルールを通知し、意思決定処理部28は制御ルールに記載されたアクションを実行することを意思決定する。実行命令送信部29は、そのアクションの実行命令の通知先となる環境を、環境群参照DB30を参照して決定し、決定した環境にアクションの実行命令を送信する。特定のアクションは、そのエージェントに対応する監視対象に特定の動作または状態変化を行わせるアクションでもよいし、その監視対象から特定のイベントを検出するアクションでもよいし、その他のアクションでもよい。変形例として、制御ルールを用いない構成も可能である。例えば、トリガイベントを受信した場合は、意思決定部22は、合計受信回数をカウントし、合計受信回数が一定値増えるごとに、事前に定めたアクションを決定し、当該アクションの実行命令を事前に定めた環境に送信するようにしてもよい。事前に定めたアクションは制御アクションでも、調節アクションでもよい。事前に定めた環境は、当該エージェントに対応する監視対象を模擬するシミュレーション用の環境でもよいし、これとは別の環境でもよい。
図2にメタレベルマルチエージェントシミュレータにおけるシミュレーションコントローラ101の動作のフローチャートを示す。
開始(step 1)後、予め定められたシミュレーション時間が終了したかどうか判定し(step 2)、終了した場合(step 2のyes)、動作を終了(step 5)する。そうでない場合(step 2のno)には、トリガイベント通知部11が、エージェント群参照DB12に応じて、各エージェントにトリガイベントを送信する(step 3)。
次いで、シミュレータ時間進行部13が、各分野特化型シミュレータのシミュレーション時間を一定時間Δt進めるよう、各シミュレータ用環境に指示信号を送る(step 4)。全ての分野特化型シミュレータのシミュレーション時間がΔt進むのを確認したら、step 2に戻る。
図3に、メタレベルマルチエージェントシミュレータにおけるエージェントのフローチャートを示す。ここでは、特にエージェントが外部からイベントを受信したときに行われる動作のフローチャートを示す。
エージェントが、外部からイベントを受信(step 1)すると、step 2に進む。センシング結果評価部23は、受信されたイベントと、信念DB26と、シミュレータ制御ルールDB20を参照して、発火条件が満たされる制御ルールが存在するか評価する。発火条件が満たされる制御ルールが存在する場合は、その制御ルールに記載のアクションに応じて、意思決定処理部28が、制御アクションを実行することを意思決定するか、または調節アクションを実行することを意思決定するか、またはこれらの両方を決定する。またセンシング結果評価部23は、信念DB26を更新するか判断する。
step 1でセンシング結果評価部23が信念DB26を更新すべきと判断したとき(step 3のyes)、信念DB更新部27が信念DB26を更新(step 4)し、step 5に進む。そうでない場合(step 3のno)には、信念DB26の更新を行うことなく、step 5に進む。
step 5では、step 1で制御アクションの実行が意思決定されたかを判断し、実行の意思決定がなされた場合(step 5のyes)には、step 6に進む。step 6では、実行命令送信部29が、当該制御アクションの実行命令の通知先となる環境を、環境群参照DB30を参照して決定し、決定した通知先にアクションの実行命令を通知する。この後、step 7に進む。一方、制御アクションの実行の意思決定がなされなかった場合(step 5のno)には、そのままstep 7に進む。
step 7では、step 1で調節アクションの実行の意思決定がされたかを判断し、実行の意思決定がなされた場合(step 7のyes)には、step 8に進む。step 8では、実行命令送信部29が、当該調節アクションの実行命令の通知先となる環境を、環境群参照DB30を参照して決定し、決定した通知先にアクションの実行命令を通知する。この後、動作を終了(step 9)する。一方、step 1で調節アクションの実行の意思決定がなされなかった場合(step 7のno)には、そのまま終了(step 9)する。
図4に、図3に示したstep 2の動作の具体例として、特定の制御ルールの発火条件が成立して、センシング頻度の調節アクションの実行を意思決定するまでのプロセスのフローチャートを示す。なお、ここでは、イベントが受信されており、当該イベントを示す制御ルールの条件が満たされるかを判定する時点からの処理の例を示す。制御ルールには選択的に2つの条件が記載されており、それぞれの条件ごとに、成立した場合に実行することを意思決定するアクションが記載されているものとする。
開始(step 1)後、信念DB26から過去のセンシングデータの値(イベントの値)v1を取得(step 2)し、イベント受信部21で今回受信されたイベントからセンシングデータの値v2を取得(step 3)する。過去のセンシングデータは、1回前など、一定回数前に受信されたイベントに含まれるセンシングデータである。
現在のセンシング頻度が、高いか低いかを判断する。一定値以上の場合は高い、一定値未満の場合は低いと判断する。現在のセンシング頻度は、信念DB26から読み出すことで取得する。現在のセンシング頻度が低いと判断した場合(step 4の「低」)の場合、値v2およびv2-v1(“-”は減算)が、所定の上下限の範囲内かを判断する(step 5)。なお、上下限の範囲は、値v2およびv2-v1で、それぞれ異なる上下限の範囲が用いられる。
値v2およびv2-v1のどちらも上下限の範囲内の場合(step 5のyes)には、そのまま終了(step 9)する。すなわちこの場合は、制御ルールに記載された一方の条件が成立しなかった場合である。
一方、v2およびv2-v1の少なくとも一方が、上下限の範囲内でない場合(step 5のno)には、センシング頻度を「低」から「高」に変更するアクション実行の意思決定(step 6)をし、終了(step 9)する。つまり、この場合は、制御ルールに記載された上記一方の条件が満たされ、その条件に応じて定められたアクションとして、センシング頻度を「高」にするアクションの実行を意思決定する場合に相当する。「高」とは、所定の値であり、step4で判断された閾値よりも高い値であるとする。
現在のセンシング頻度が高いと判断(step 4の「高」)された場合、v2およびv2-v1が、それぞれ上下限の範囲内かを判断する(step 7)。一方、v2およびv2-v1の少なくとも一方が、上下限の範囲内でない場合でない場合(step 7のno)には、そのまま終了(step 9)する。すなわちこの場合は、制御ルールに記載された他方の条件が成立しなかった場合である。
一方、値v2およびv2-v1のどちらも上下限の範囲内の場合である場合(step 7のyes)には、センシング頻度を「高」から「低」に変更するアクション実行の意思決定(step 8)をし、終了(step 9)する。つまり、この場合は、制御ルールに記載された上記他方の条件が満たされ、その条件に応じて定められたアクションとして、センシング頻度が「低」にするアクションの実行を意思決定する場合に相当する。「低」とは、所定の値であり、step4で判断された閾値よりも低い値であるとする。
これまでは、図1に示した構成に基づき、メタレベルマルチエージェントシミュレータに複数の分野特化型シミュレータを接続して、複数の分野にわたって横断的にシミュレーションを行うことや、イベントの値に応じてイベントのセンシング頻度を動的に変更することなどを示した。
なお、メタレベルマルチエージェントシミュレータと、各分野特化型シミュレータは、同じコンピュータ内で配置されてもよいし、別々のコンピュータ内に配置されてもよい。コンピュータは、一般的なパーソナルコンピュータ(PC)を用いても良いし、専用コンピュータでもよい。
また、図示の例では、シミュレータ1、2用環境は、メタレベルマルチエージェントシミュレータと同じ装置内に設けられているが、分野特化型シミュレータ1、2と同じ装置に設けられる構成も可能である。また、分野特化型シミュレータ1、2がメタレベルマルチエージェントシミュレータと同じ装置に配置されてもよい。
また、エージェントは、模擬している監視対象のすべてのそれぞれごとに用意しても良いし、模擬している監視対象の一部のみ、エージェントを用意する構成も可能である。また、すべてのエージェントをまとめて1つのエージェント処理部を構成してもよい。この場合、エージェント処理部内の各要素はすべてのエージェンに対する処理を行う。例えばエージェント処理部のイベント受信部はすべてのエージェンに対するイベントを受信する。
本実施形態の変形例として、メタレベルマルチエージェントシステムに分野特化型シミュレータだけでなく、有線または無線の通信ネットワークに接続し、分野特化型シミュレータと、通信ネットワーク上の通信装置もしくは通信装置を有するユーザもしくは通信装置を内蔵する機器との横断的なシミュレーションも可能である。分野特化型シミュレータ1を有線または無線の通信ネットワークに変更した例を図35(A)に、分野特化型シミュレータ2を有線または無線の通信ネットワークに変更した例を図35(B)に示す。この場合、通信ネットワーク上の通信装置、ユーザまたは機器を監視対象とし、通信ネットワークを介した各通信装置等の制御用の環境を用意すればよい。イベント検出は、各通信装置からネットワークを介して実際にデータを受信することで行い、アクションの実行命令は、各通信装置またはユーザデバイスにネットワークを介して実際に制御命令を送ればよい。 ユーザデバイスは携帯電話やスマートフォン等の携帯端末でもよいし、テレビやパソコン、カーナビ装置等の設置型の装置でもよいし、その他のデバイスでもよい。通信装置からアクションの完了の通知を受けることで、アクションの実行が完了したことを把握してもよい。制御命令が通信装置のユーザへの移動を促す命令等の時は、ユーザから命令を実行したことの通知を受けることで、アクションの実行が完了したことを把握してもよい。通信装置からイベントを検出する際、ユーザからの入力によりイベントを検出してもよい。なお、シミュレータ時間進行部13は、通信ネットワークの時間進行に合わせて分野特化型シミュレータの時間進行を同期させるものとする。分野特化型シミュレータのシミュレーション速度が高速な場合はこのような変形例も可能である。また別の変形例として、エージェント群の一部のエージェントは、制御ルールにしたがって実行するアクションを決定するのではなく、ユーザの指示入力に従って、すなわち、ユーザの意思に従ってアクションを決定する構成も可能である。この場合の構成例を図35(C)に示す。この場合、少なくとも1つのエージェントの意思決定部は、イベント受信部21で受信したイベントをユーザデバイスに有線または無線による通信を介して通知し、ユーザデバイスからの指示信号の入力に応じて、実行するアクションを決定する。意思決定部は、ユーザデバイスからの入力に基づき決定したアクションの実行命令に基づき、ユーザデバイスに制御命令を送っても良い。ユーザデバイスは携帯電話やスマートフォン等の携帯端末でもよいし、テレビやパソコン、カーナビ装置等の設置型の装置でもよいし、その他のデバイスでもよい。図35(C)に示した形態を、図35(A)または図35(B)に示した形態と組み合わせてもよい。
図34は、図1に示したメタレベルマルチエージェントシミュレータのハードウェアを示している。メタレベルマルチエージェントシミュレータは、コンピュータ装置を基本ハードウェアとして使用することで実現することができる。コンピュータ装置は、図34に示されるように、CPU501、入力部502、表示部503、通信部504、主記憶部505、外部記憶部506を備え、これらはバス507により相互に通信可能に接続される。入力部502は、キーボード、マウス等の入力デバイスを備え、入力デバイスの操作による操作信号をCPU501に出力する。表示部503は、LCD(Liquid Crystal Display)、CRT(Cathode Ray Tube)等の表示ディスプレイを含む。通信部504は、無線または有線の通信手段を有し、所定の通信方式で通信を行う。外部記憶部506は、例えば、ハードディスク、メモリ装置、CD−R、CD−RW、DVD−RAM、若しくはDVD−R等の記憶媒体等を含む。外部記憶部506は、本メタレベルマルチエージェントシミュレータの処理をCPU501に実行させるための制御プログラムを記憶している。また、本シミュレータが備える各記憶手段(DB)のデータを記憶している。主記憶部505は、CPU501による制御の下で、外部記憶部506に記憶された制御プログラムを展開し、当該プログラムの実行時に必要なデータ、当該プログラムの実行により生じたデータ等を記憶する。主記憶部505は、たとえば不揮発性メモリ等の任意のメモリを含む。上記制御プログラムはコンピュータ装置にあらかじめインストールすることで実現してもよいし、CD−ROM等の記憶媒体に記憶して、或いはネットワークを介して上記のプログラムを配布して、このプログラムをコンピュータ装置に適宜インストールしてもよい。なお、入力部502および表示部503を備えない構成も可能である。また、分野特化型シミュレータが本メタレベルマルチエージェントシミュレータと同じ装置の場合は通信部504を備えない構成も可能である。
以上に示した本実施形態によれば、各分野特化型シミュレータを監視する状況監視部は、適切なエージェントに適切なタイミングでイベントを送ることができ、エージェントは適切なタイミングで意思決定を行うことができる。また、各エージェントは、複数の分野にわって横断的に収集した情報をもとに、適切な分野特化型シミュレータを選択して制御できる。さらに、各エージェントは、各分野特化型シミュレータの全てのイベントを網羅的に監視できる。これらにより、個人の視点から、スマートコミュニティなどの設計・評価のために、交通、電力、上下水道、ガス、熱、医療、教育、といった異なる複数の分野を横断的にシミュレーションできるようになる。また、横断的なイベント監視のための時間を削減できるようになる。
以下、図1に示した構成を元に、本発明の実施例1〜6を説明する。
図30に、実施例1に係る分野特化型シミュレータおよびエージェントの具体例を示す。
2つの分野特化型シミュレータとして、交通シミュレータと、ITSセンターシミュレータを用意し、上位のマルチエージェントシミュレータ(図1のメタレベルマルチエージェントシミュレータ)にプラグインする。
交通シミュレータは、車1台1台の動きを、ミクロレベルでシミュレーションする。交通シミュレータで走行する数台の車を、プローブカー(ここではプローブカー1、2)として設定する。ITSセンターシミュレータは、交通シミュレータの道路の渋滞状況を把握・分析する。交通シミュレータで走行する車に対応する同数のプローブカーエージェント(ここではプローブカーエージェント1、2)を、メタレベルマルチエージェントシミュレータのエージェントとして用意する。
各プローブカーの名前(識別子)をNameによって表す。NameのプローブカーエージェントをprobeCarAgent(Name)と表す。また、交通シミュレータを監視する状況監視部32が発行するイベントを、probeCarEvent(Name,X1,Y1,V1,N1)と表す。X1,Y1はプローブカーの位置(座標)を表し、V1はプローブカーの速度、N1は、プローブカーの周囲の車の台数を表す。周囲とはたとえば半径r以内など、プローブカーから一定の範囲を表す。
図5に、実施例1に係るプローブカーエージェントに対する通知間隔DB33の例を示す。この例の場合、状況監視部32は、プローブカーcar1のプローブカーエージェントprobeCarAgent(car1)に、イベントprobeCarEvent(car1,_,_,_,_)を10秒ごとに通知することが示される。ここで、“_”は、X1,Y1,V1,N1について任意の値を代入可能であることを示す。“10秒”は、交通シミュレータ内での時間である。
図6に、実施例1に係るプローブカーエージェントのシミュレータ制御ルールDB20の例を示す。
この例では、イベントprobeCarEvent(Name,X1,Y1,V1,N1)の通知を受けた場合に対する 3つの制御ルールが含まれている。3つの制御ルールはいずれもif-when-thenの形式で表現されている。Ifにはイベント、whenには条件、thenには、アクションが記載されている。If文に記載されたイベントが通知された場合において、when文に記載された条件が成立するとき(すなわち制御ルールが発火した場合に)、thenに記載されたアクションを実行することを意思決定する。
1つ目の制御ルールでは、probeCarEvent(Name,X1,Y1,V1,N1)のイベントが通知された場合において、速度V1が時速10km以上の条件が成立する場合に、informProbeCarInfo(Name,X1,Y1,V1,N1)と、setEventInterval(probeCarEvent(Name,_,_,_,_),10)の2つのアクションを実行することが定められている。informProbeCarInfo(Name,X1,Y1,V1,N1)は、交通シミュレータ上の対応するプローブカーNameの位置、速度、周囲の車の台数をITSセンターシミュレータに通知するアクションである。setEventInterval(probeCarEvent(Name,_,_,_,_),10)は、イベントprobeCarEvent(Name,_,_,_,_)の通知間隔を10に設定するセンシング頻度調節アクションである。
2つ目の制御ルールでは、probeCarEvent(Name,X1,Y1,V1,N1) のイベントが通知された場合において、周囲の車の台数N1が10台未満の条件が成立するとき、informProbeCarInfo(Name,X1,Y1,V1,N1)と、setEventInterval(probeCarEvent(Name,_,_,_,_),10)の2つのアクションを実行することが定められている。
3つ目の制御ルールでは、probeCarEvent(Name,X1,Y1,V1,N1) のイベントが通知された場合において、速度V1が時速10km未満で、周囲の車の台数N1が10台以上の条件が成立する場合に、informProbeCarInfo(Name,X1,Y1,V1,N1)と、setEventInterval(probeCarEvent(Name,_,_,_,_),30)の2つのアクションを実行することが定められている。setEventInterval(probeCarEvent(Name,_,_,_,_),30)は、イベントprobeCarEvent(Name,_,_,_,_)の通知間隔を30に設定するセンシング頻度調節アクションである。
3つの制御ルールのいずれにおいても、probeCarEvent(Name,X1,Y1,V1,N1)のイベント通知を受けたプローブカーエージェントprobeCarAgent(car1)は、交通シミュレータ上の対応するプローブカーcar1の位置、速度、周囲の車の台数をITSセンターシミュレータに通知するアクションinformProbeCarInfo(car1,X1,Y1,V1,N1)を実行する。
3つの制御ルールの違いは、when内部における、V1>=10の場合と、N1<10の場合と、V1<10かつN1>=10の場合の違いにある。
すなわち1番目や2番目の制御ルールのように、V1>=10またはN1<10のときには、イベントprobeCarEvent(car1,_,_,_,_)の通知間隔を10に設定するセンシング頻度調節アクションsetEventInterval(probeCarEvent(car1,_,_,_,_),10)を実行することを意思決定する。3番目の制御ルールのように、V1<10かつN1>=10のときには、イベントprobeCarEvent(car1,_,_,_,_)の通知間隔を30に設定するセンシング頻度調節アクションsetEventInterval(probeCarEvent(car1,_,_,_,_),30)を実行することを意思決定する。
図7に、プローブカーエージェントprobeCarAgent(car1)の実行命令送信部29内の環境群参照DB30の例を示す。
informProbeCarInfoはITSセンターシミュレータ(itsCenterSimulator)を制御するアクションであり、setEventIntevalは交通シミュレータ(trafficSimulator)を制御するアクションである。ここでは2つのアクションのみが示されているが、実際にはより多くのアクションとシミュレータとが登録されていてもよい。実行命令送信部29は、informProbeCarInfoの実行が意思決定された場合は、当該アクションをITSセンターシミュレータ(itsCenterSimulator)用の制御部31に送信することが示される。setEventIntevalのアクションの実行が意思決定された場合は、当該アクションを交通シミュレータ(trafficSimulator)用の制御部31に送信することが示される。
以下、実施例1に係る動作を説明する。
交通シミュレータを監視する状況監視部32は、各プローブカーNameの位置(X1,Y1)、速度V1、周囲の車の台数N1を認識し、一定間隔の時間間隔で、メタレベルマルチエージェントシミュレータの対応するプローブカーエージェントprobeCarAgent(Name)に、イベントprobeCarEvent(Name,X1,Y1,V1,N1) を通知する。
本例では、交通シミュレータの状況監視部32が、イベントprobeCarEvent(car1,123123,12345,23,11)をプローブカーエージェントprobeCarAgent(car1)に通知したとする。
状況監視部32からイベント通知を受けたプローブカーエージェントprobeCarAgent(car1)の意思決定部22は、シミュレータ制御ルールDB20(図6)を参照する。V1>=10(V1=23)であるため、1番目の制御ルールに従い、アクションinformProbeCarInfo(car1,123123,12345,23,11)とsetEventInterval(probeCarEvent(car1,_,_,_,_),10)を実行することを意思決定する。
probeCarAgent(car1)の実行命令送信部29は、環境群参照DB30(図7)を参照し、アクションinformProbeCarInfo(car1,123123,12345,23,11)の実行命令を、ITSセンターシミュレータ用の制御部31に送信する。ITSセンターシミュレータ用の制御部31では、そのアクションを実行することにより、そのアクションに記載された情報(すなわちプローブカーcar1が(123123,12345)に位置し、速度は23であり、周囲に11台の車が存在する)をITSセンターシミュレータで監視されているITSセンターに登録する。
また実行命令送信部29は、引き続き、アクションsetEventInterval(probeCarEvent(car1,_,_,_,_),10)の実行命令を、交通シミュレータ用の制御部31に送信する。当該アクションの実行命令を受け取った制御部31は、交通シミュレータに対応する通知間隔DB33を、アクションに記載された情報にしたがって、更新する。
図8に通知間隔DB33が更新される様子を示す。ここでは、図8の上段から中段のように更新される。更新後の通知間隔は、前回と同じ値の10である。この結果、次に、状況監視部がイベントprobeCarEvent(car1,_,_,_,_)をprobeCarAgent(car1)に通知するのは10秒後となる。
続いて、交通シミュレータを監視する状況監視部32は、通知間隔DB33に従って、10秒後、probeCarEvent(car1,123456,12121,8,20)をプローブカーエージェントprobeCarAgent(car1)に通知したとする。
このとき、probeCarAgent(car1)の意思決定部22は、シミュレータ制御ルールDB20(図6参照)を参照し、V1<10(V1=8)かつN1>=10 (N1=20)であるため、図6に示した3番目の制御ルールの条件が成立することを決定する。したがって、3番目の制御ルールに従って、アクションinformProbeCarInfo(car1,123456,12121,8,20)とsetEventInterval(probeCarEvent(car1,_,_,_,_),30)を順に実行することを意思決定する。
probeCarAgent(car1)の実行命令送信部29は、内部の環境群参照DB30(図7)を参照し、アクションinformProbeCarInfo(car1,123456,12121,8,20)の実行命令を、ITSセンターシミュレータ用の制御部31に送信する。当該制御部31は、そのアクションに記載された情報をITSセンターシミュレータに登録する。
続いて、probeCarAgent(car1)の実行命令送信部29は、アクションsetEventInterval(probeCarEvent(car1,_,_,_,_),30)の実行命令を、交通シミュレータ用の制御部31に送信する。アクションの実行命令を受け取った制御部31は、交通シミュレータに対応する通知間隔DB33を、図8の中段から下段のように更新する。この結果、次にこのイベントをprobeCarAgent(car1)に通知するのは30秒後となる。
このように、プローブカーエージェントへのイベントの通知頻度を、速度と周囲の車の台数によって変えることができる。たとえば、渋滞のため、速度が低く、周囲の車の台数が多いときで、頻繁にプローブしても得られる情報の変化はあまりない場合に通知頻度を下げることができる。これにより、交通シミュレーションを早く進めることができる。
また、交通シミュレータを監視する状況監視部32からプローブカーエージェントへのイベント通知に応じて、当該交通シミュレータに対するアクションの実行命令だけでなく、ITSセンターシミュレータに対するアクションの実行命令(本例ではアクションプローブカーの情報をITSセンターに登録)を行うため、複数の分野(シミュレータ)にわたって横断的にシミュレーションすることが可能になる。すなわち、複数のエージェントが自らの意思で行動した結果を、複数の分野にわたって総合的にシミュレーションすることができる。
実施例1と同様、図30に示すように、2つの分野特化型シミュレータとして、ミクロレベルの交通シミュレータと、交通シミュレータの道路の渋滞状況を把握・分析するITSセンターシミュレータを用意し、これらをメタレベルマルチエージェントシミュレータにプラグインする。また、交通シミュレータで走行するプローブカー1,2に対応する同数のプローブカーエージェント1,2を、メタレベルマルチエージェントシミュレータ(図1参照)のエージェントとして用意する。
実施例1と同様、交通シミュレータを監視する状況監視部32は、各プローブカーNameの位置(X1,Y1)、速度V1、周囲の車の台数N1を認識し、通知間隔DB33に登録された通知間隔で、メタレベルマルチエージェントシミュレータの対応するプローブカーエージェントprobeCarAgent(Name)に、イベントprobeCarEvent(Name,X1,Y1,V1,N1) を通知する。図9に実施例2に係る通知間隔DB33の例を示す。この例の場合、状況監視部32は、プローブカーエージェントprobeCarAgent(car1)に、イベントprobeCarEvent(car1,_,_,_,_)を30秒ごとに通知する。ここで、“_”は任意の値を代入可能であることを示す(以下同様)。
図10に、実施例2に係るシミュレータ制御ルールDB20の例を示す。この例では、イベントprobeCarEvent(Name,X1,Y1,V1,N1)の通知を受けた場合の 2つの制御ルールが定められている。
1番目の制御ルールでは次のことが定められている。イベントprobeCarEvent(Name,X1,Y1,V1,N1)の通知を受けた場合に、信念DB26に登録されている前回の観測速度volocity(V0)と今回の速度V1の差分絶対値が時速20km未満(|V1-V0|<20)の条件が満たされるときは、del(velocity(V0))、add(velocity(V1)), informProbeCarInfo(Name,X1,Y1,V1,N1)、setEventInterval(probeCarEvent(car1,_,_,_,_),30)の4つのアクションを実行する。del(velocity(V0))は、信念DB26から前回の観測速度V0を削除するアクションである。add(velocity(V1))は、信念DB26に今回の観測速度V1を追加するアクションである。informProbeCarInfo(Name,X1,Y1,V1,N1)とsetEventInterval(probeCarEvent(car1,_,_,_,_),30)は、実施例1で述べた通りである。
2番目の制御ルールでは次のことが定められている。イベントprobeCarEvent(Name,X1,Y1,V1,N1)の通知を受けた場合に、信念DB26に登録されている前回の観測速度volocity(V0)と今回の速度V1の差分絶対値が時速20km以上(|V1-V0|>=20)の条件が満たされるときは、del(velocity(V0))、add(velocity(V1)), informProbeCarInfo(Name,X1,Y1,V1,N1)、setEventInterval(probeCarEvent(car1,_,_,_,_),1)の4つのアクションを実行する。
1番目および2番目の制御ルールのいずれの場合も、probeCarEvent(car1,X1,Y1,V1,N1)のイベント通知を受けたプローブカーエージェントprobeCarAgent(car1)は、信念DB26のvolocity(V0)を消して、velocity(V1)を加える。また、交通シミュレータ上の対応するプローブカーの位置、速度、周囲の車の台数をITSセンターシミュレータに通知するアクションinformProbeCarInfo(car1,X1,Y1,V1,N1)の実行を決定する。
2つの制御ルールの違いは、1番目の制御ルールのwhen内部における|V1-V0|<20と、2番目の制御ルールのwhen内部における|V1-V0|>=20である。
1番目の制御ルールの|V1-V0|<20が成立する場合は、イベントprobeCarEvent(car1,_,_,_,_)の通知間隔(監視周期)を30に設定するアクションsetEventInterval(probeCarEvent(car1,_,_,_,_),30)を実行することを意思決定する。2番目の制御ルールの|V1-V0|>=20が成立する場合は、イベントprobeCarEvent(car1,_,_,_,_)の通知間隔を1に設定するアクションsetEventInterval(probeCarEvent(car1,_,_,_,_),1)を実行することを意思決定する。
以下、実施例2に係る動作を説明する。
交通シミュレータを監視する状況監視部32が、イベントprobeCarEvent(car1,123123,12345,44,5)をプローブカーエージェントprobeCarAgent(car1)に通知したとする。イベント通知を受けたプローブカーエージェント(probeCarAgent(car1))の意思決定部22が、シミュレータ制御ルールDB20(図10)を参照し、意思決定のための動作を行う。
ここで、図11に、実施例2に係る信念DB26の例を示す。最初、プローブカーエージェントprobeCarAgent(car1)の速度(信念)として、図11の(1)のように、velociy(40)(速度が時速40km)が登録されているとする。
probeCarAgent(car1)の意思決定部22は、シミュレータ制御ルールDB20(図10)と信念DB26を参照し、|V1-V0|<20 (V0=40, V1=44)であることを決定する。したがって、図10に示した1番目の制御ルールの条件が成立したことを判定する。そこで、図11の(1)から(2)のように、probeCarAgent(car1)の信念DB26からvelociy(40)を消し、velociy(44)を加える。
また、アクションinformProbeCarInfo(car1,123123,12345,44,5)とsetEventInterval(probeCarEvent(car1,_,_,_,_),30)を順に実行することを意思決定する。
プローブカーエージェントprobeCarAgent(car1)の環境群参照DB30は、実施例1と同様、図7に示すようになっているとする。前述したように、informProbeCarInfoはITSセンターシミュレータ(itsCenterSimulator)を制御するアクションであり、setEventIntevalは交通シミュレータ(trafficSimulator)を制御するアクションである。
probeCarAgent(car1)の実行命令送信部29は、環境群参照DB30を参照し、アクションinformProbeCarInfo(car1,123123,12345,44,5)の実行命令を、ITSセンターシミュレータ用の制御部31に送信する。当該制御部31は、そのアクションを実行命令に従って、そのアクションに記載された情報をITSセンターシミュレータで模擬されているITSセンターに登録するように制御する。
引き続き、実行命令送信部29は、アクションsetEventInterval(probeCarEvent(car1,_,_,_,_),30)の実行命令を、交通シミュレータ用の制御部31に送信する。当該制御部31は、当該アクションの実行命令にしたがって、交通シミュレータに対応する通知間隔DB33を更新する。通知間隔DB33を更新の様子を図12に示す。ここでは、図12の上段から中段に示す状態に更新する。この結果、次にこのイベントをprobeCarAgent(car1)に通知するのは30秒後となる。
交通シミュレータの状況監視部32は、更新後の通知間隔DB33に従って、30秒後、probeCarEvent(car1,123456,12121,23,20)をプローブカーエージェントprobeCarAgent(car1)に通知したとする。
このとき、probeCarAgent(car1)の意思決定部22は、シミュレータ制御ルールDB20(図10)と信念DB26を参照し、|V1-V0|>=20 (V0=44, V1=23)であるため、図10に示した2番目の制御ルールが成立することを判定する。probeCarAgent(car1)の信念DB26からvelociy(44)を消し、velociy(23)を加える。この結果、信念DB26は、図11の (2)から(3)に示すように更新される。
また、アクションinformProbeCarInfo(car1,123456,12121,23,20)とsetEventInterval(probeCarEvent(car1,_,_,_,_),1)を実行することを意思決定する。
probeCarAgent(car1)の実行命令送信部29は、環境群参照DB30(図7)を参照し、アクションinformProbeCarInfo(car1,123456,12121,23,20)の実行命令を、ITSセンターシミュレータ用の制御部31に送信する。ITSセンターシミュレータ用の制御部31は、当該アクションの実行命令に従って、そのアクションに記載された情報を、ITSセンターシミュレータで模擬されているITSセンターに登録するよう制御する。
引き続き、実行命令送信部29は、アクションsetEventInterval(probeCarEvent(car1,_,_,_,_),1)の実行命令を、交通シミュレータ用の制御部31に送信する。当該制御部31は、当該アクションの実行命令に従って、交通シミュレータに対応する通知間隔DB33を、図12の中段から下段に示す状態に更新する。この結果、次にこのイベントをprobeCarAgent(car1)に通知するのは1秒後となる。
このように、本実施例では、プローブカーエージェントへのイベントの通知頻度を、速度変化量によって変える。たとえば、速度変化が少なく、頻繁にプローブしても得られる渋滞情報の変化が少ない場合に、通知頻度を下げることができる。これにより、交通シミュレーションを早く進めることができる。
また、交通シミュレータを監視する状況監視部32からプローブカーエージェントへのイベント通知に応じて、交通シミュレータに対するアクション実行命令だけでなく、ITSセンターシミュレータに対するアクション実行命令(本例ではアクションプローブカーの情報を登録)を行うため、複数の分野(シミュレータ)を横断的にシミュレーションすることが可能になる。すなわち、複数のエージェントが自らの意思で行動した結果を、複数の分野にわたって総合的にシミュレーションすることができる。
図31に、実施例3に係る分野特化型シミュレータおよびエージェントの具体例を示す。
2つの種類の分野特化型シミュレータとして、ミクロレベルの交通シミュレータと、充電ステーションシミュレータ1、2を用意する。充電ステーションシミュレータ1、2は、それぞれ充電ステーション1、2の使用電力量を計算する。これらのシミュレータが、メタレベルマルチエージェントシミュレータ(図1)にプラグインされている。
また、交通シミュレータで走行する電気自動車(EV)に対応するEVエージェントと、充電ステーションに対応する充電ステーションエージェントを、メタレベルマルチエージェントシミュレータのエージェントとして用意する。ここでは、EV1、2に対応するEVエージェント1,2と、充電ステーション1、2に対応する充電ステーションエージェント1,2を用意する。
図13に、実施例3に係る交通シミュレータを監視する状況監視部32の通知間隔DB33の例を示す。この例では、イベントとしてarriveEvent(ev1,station1,_)、通知先エージェントとしてevAgent(ev1)、通知間隔として10が登録されている。
arriveEvent(ev1,station1,_)は、名前ev1のEVが充電ステーションstation1に到着したときには、メタレベルマルチエージェントシミュレータの対応するEVエージェントevAgent(ev1)に、到着した充電ステーションstation1と、”_”を知らせるイベントである。本実施例では、”_”は、電池残存量(BatteryResidue)の値が入るとする。
図14に、実施例3に係るEVエージェントにおけるシミュレータ制御ルールDB20の例を示す。ここでは2つの制御ルールが定義されている。いずれの制御ルールもIf-thenの形式で定義されている。
1番目の制御ルールには、イベントarriveEvent(EVName,ChargeStation,BatteryResidue)が通知された場合は、startEVCharging(EVname,ChargeStation,BatteryResidue)のアクションを実行することを意思決定することが定められている。
arriveEvent(EVName,ChargeStation,BatteryResidue)は、充電ステーション名がChargeStationの充電ステーションに、電池残存量がBatteryResidueのEV(EVname)が到着したことを表す。startEVCharging(EVname,ChargeStation,BatteryResidue)は、電池残量(BatteryResidue)のEV(EVname)を、充電ステーション(ChargeStation)で充電するアクションを表す。
2番目の制御ルールには、endEVChargingEvnet (EVName,ChargeStation,BatteryResidue)のイベントが通知された場合は、start(EVName)を実行することを意思決定することが定められている。endEVChargingEvnet (EVName,ChargeStation,BatteryResidue)は、EV(EVName)が充電ステーション(ChargeStation)で、充電を終了し、終了次の電池残存量がBatteryResidueであることを表すイベントである。start(EVName)はEV(EVName)を充電ステーションから出発させるアクションを表す。
図15に、実施例3に係るEVエージェントにおける環境群参照DB30の例を示す。startEVCharging(_,Station,_)のアクションは、充電ステーション(Station)に対応する充電ステーションシミュレータ(evChargeStationSimulator(Station))用の制御部31に送ることが記載されている。また、充電ステーションからEVを出発させるアクションstart(_)は、交通シミュレータ(trafficSimulator)用の制御部31に送ることが記載されている。
図16に、充電ステーションシミュレータを監視する状況監視部32の通知間隔DB33の例を示す。
イベント名としてpowerUsageEvent(ChargeStation,Watt)と、通知先エージェンとしてchargeStationAgent(ChargeStation)と、通知間隔を備える形式のデータが1行目に登録されている。powerUsageEvent(ChargeStation,Watt)は、ChargeStationで使用されている全電力Wattを計算して通知するイベントである。chargeStationAgent(ChargeStation)は、充電ステーション(ChargeStation)に対応する充電ステーションエージェントを表す。図示の例では、イベントpowerUsageEvent(station1,_)を、chargeStationAgent(station1)のエージェントに60秒ごとに送ることが示されている。
また、2行目には、イベント名としてendEVChargingEvent(EVName,ChargeStaion,BatteryResidue)と、通知先エージェンとしてevAgent(EVName)と、通知間隔とを備える形式のデータが登録されている。endEVChargingEvent(EVName,ChargeStaion,BatteryResidue)は、充電ステーション(ChargeStation) でEV(EVName)の充電が終了したときに、そのときの電池残存量(BatteryResidue)を通知するイベントである。evAgent(EVName)は、EV(EVName)に対応するEVエージェントである。図示の例では、EVName=ev1、ChargeStation=station1として、10秒間隔で、充電ステーション(station1)のシミュレータで、EV(ev1)の充電状況を監視し、充電が終了すると、そのときの電池残存量BatteryResidueを元に、イベントendEVChargingEvent(ev1, Staion1,_)を、EV(ev1)に対応するエージェントに通知することが示されている。
図17に、充電ステーションエージェントのシミュレータ制御ルールDB20の例を示す。この例では2つの制御ルールが定義されている。各制御ルールは、IF-when-thenの形式で記載されている。
1番目の制御ルールには、イベントpowerUsageEvent(ChargeStation,Watt)が通知された場合において、Watt<100000の条件が満たされる場合は、setEventIntervalEvent (powerUsageEvent(ChargeStation,_),60)のアクションを実行することを意思決定することが定められている。Watt<100000は、使用電力が100kW未満であることを意味する。setEventIntervalEvent (powerUsageEvent(ChargeStation,_),60)は、60秒ごとにpowerUsageEventが通知されるように設定するアクションである。
2番目の制御ルールには、イベントpowerUsageEvent(ChargeStation,Watt)が通知された場合において、Watt>=100000の条件が満たされる場合は、setEventIntervalEvent (powerUsageEvent(ChargeStation,_),1)と、delayEVChargeSpeed(ChargeStation)のアクションを実行することを意思決定することが定められている。Watt>=100000は、使用電力が100kW以上であることを意味する。setEventIntervalEvent (powerUsageEvent(ChargeStation,_),1)は、1秒ごとにpowerUsageEventが通知されるように設定するアクションである。delayEVChargeSpeed(ChargeStation)は、充電速度を下げるように設定するアクションである。充電速度を下げることにより、使用電力を下げることができる。
図18に、実施例3に係る充電ステーションエージェントの環境群参照DB30の例を示す。ここでは、setEventIntervalEvent (powerUsageEvent(ChargeStation,_),_)およびdelayEVChargeSpeed(ChargeStation)いずれのアクションも、充電ステーションシ(ChargeStation)用のシミュレータevChargeStationSimulator(ChargeStation)の制御部31に送信することが示される。
以下、実施例3に係る動作の例を示す。
交通シミュレータを監視する状況監視部32は、通知間隔DB33(図13)を参照して、10秒間隔で交通シミュレータを監視し、名前ev1のEVが充電ステーションstation1に到着したときには、メタレベルマルチエージェントシミュレータの対応するEVエージェントevAgent(ev1)に、イベントarriveEvent(ev1,station1,BatteryResidue)を通知する。これにより、EVエージェントevAgent(ev1)に、到着した充電ステーション(station1)と、電池残存量(BatteryResidue)を知らせる。
このイベントをトリガに、EVエージェントevAgent(ev1)の意思決定部22は、シミュレータ制御ルールDB20を参照する。EVエージェントevAgent(ev1)の意思決定部22は、イベントarriveEvent(ev1,station1,BatteryResidue)を受信すると、 シミュレータ制御ルールDB20(図14)を参照し、1番目の制御ルールに従って、そのEVの充電開始アクションstartEVCharging(ev1,station1,BatteryResidue)を実行することを意思決定する。
このとき、evAgent(ev1)の実行命令送信部29は、環境群参照DB30(図15)を参照して、このアクションの送信先を決定し、送信する。具体的に、実行命令送信部29は、充電開始アクションstartEVCharging(ev1,station1,BatteryResidue)を、充電ステーション(station1)の充電ステーションシミュレータevChargeStationSimulator(station1)用の制御部31に送信する。これにより、station1の充電ステーションシミュレータを制御し、EV(ev1)の充電によるこの充電ステーション(station1)の総消費電力の影響を見ることができる。
一方、充電ステーションシミュレータevChargeStationSimulator(ChargeStation)の状況監視部32は、通知間隔DB33(図16)にしたがって、イベントpowerUsageEvent(station1,Watt)の通知を行う。イベントpowerUsageEvent(station1,Watt)を受け取った充電ステーションエージェントchargeStationAgent(station1)の意思決定部22は、シミュレータ制御ルールDB20(図17)に従って、使用電力Wattの大きさによって、異なるアクション実行の意思決定をする。
Watt<100000の場合には、1番目の制御ルールの条件が成立することを決定する。従って、使用電力通知イベントの通知間隔を60秒に設定するアクションsetEventIntervalEvent(powerUsageEvent(station1,_),60)を実行することを意思決定する。
Watt>=1000000の場合には、2番目の制御ルールの条件が成立することを決定する。従って、使用電力通知イベントの通知間隔を1秒に設定するアクションsetEventIntervalEvent(powerUsageEvent(station1,_),1)を実行することを意思決定する。これにより、使用電力が大きいときには高い頻度で使用電力を監視することが可能になる。加えて、充電速度を下げるアクションdelayEVChargeSpeed(station1) を実行することを意思決定する。これにより、使用電力を下げて、急な使用電力の増加に素早く対策することができるようになる。
実行命令送信部29は、1番目の制御ルールまたは2番目の制御ルールに応じて決定されたアクションの実行命令の送信先を、環境群参照DB30(図18)を参照して決定する。ここでは、いずれのアクションも、充電ステーションstation1の充電ステーションシミュレータevChargeStationSimulator(station1)用の制御部31に送信先が決定される。したがって、この送信先へ実行命令送信部29は、1番目の制御ルールまたは2番目の制御ルールに応じて決定されたアクションの実行命令を送信する。
図19に、実施例3に係る充電ステーションシミュレータの通知間隔DB33が更新される様子を示す。充電ステーションエージェントchargeStationAgent(station1)がイベントpowerUsageEvent(station1, 40000) を受け取ったときには、1番目の制御ルールに従って、図19の上段から中段のように、このイベントの通知間隔を60秒に設定する。その後、イベントpowerUsageEvent(station1, 120000)を受け取ったときには、2番目の制御ルールに従って、図19の中段から下段のように、このイベントの通知間隔を1秒に設定するとともに、EV(ev1)の充電速度を下げることにより使用電力を下げる。
以上、本実施例によれば、充電ステーションの使用電力が高くなったときには、充電速度を下げることにより使用電力を下げるとともに、高頻度で充電ステーションの使用電力をセンシングできる。
また、交通シミュレータを監視する状況監視部32からEVエージェントへのイベント通知(充電ステーションに到着等)に応じて、充電ステーションシミュレータに対するアクション命令実行(充電ステーションがEVを充電等)を行うため、複数の分野(シミュレータ)を横断的にシミュレーションすることが可能になる。すなわち、複数のエージェントが自らの意思で行動した結果を、複数の分野にわたって総合的にシミュレーションすることができる。
図32に、実施例4に係る分野特化型シミュレータおよびエージェントの具体例を示す。
2つの種類の分野特化型シミュレータとして、電力供給家シミュレータと、2つの電力需要家シミュレータ1、2を用意する。これらのシミュレータはメタレベルマルチエージェントシミュレータにプラグインされる。電力供給家シミュレータは、電力需要に応じて各電力需要家に提示する電力価格を調整する電力供給家を模擬する。2つの電力需要家シミュレータ1、2は、電力価格に応じて電力使用量を変える需要家1、2を模擬する。電力供給家は電力(商品)を制御する提供体の一例である。提供体として商品ではなく、サービスを提供する提供体でもよい。
実施例4に係る通知間隔DB33には、定期的に電力使用量Whと電力使用時間Minutesを計算し、使用電力量通知イベントpowerUsageEvent(Consumer,Wh,Minutes)を、電力需要家エージェントpowerConsumerAgent(Consumer)に通知することが登録されている。Consumerは、需要家の名前を表し、Whは電力使用量、Minutesは電力使用時間を表している。
図20に、電力需要家1の状況監視部32における通知間隔DB33の例を示す。この例の場合、電力需要家1の状況監視部32は、Consumer1の電力需要家シミュレータ1を監視し、30分間隔で、電力使用量Whと電力使用時間Minutesを計算し、使用電力量通知イベントpowerUsageEvent(Consumer1,_,_)を、電力需要家エージェントpowerConsumerAgent(Consumer1)に通知することが示される。
イベントpowerUsageEvent(Consumer,Wh,Minutes)を受け取った電力需要家エージェントpowerConsumerAgent(Consumer)の意思決定部22は、シミュレータ制御ルールDB20に記載の制御ルールに従って、実行すべきアクションを決定する。
図21に、実施例4に係る電力需要家エージェントのシミュレータ制御ルールDB20の例を示す。ここには2つの制御ルールが示される。各制御ルールは、それぞれ、If-when-thenの形式で記述されている。
1番目の制御ルールは、powerUsageEvent(Consumer,Wh,Minutes)が通知された場合において、Wh/Minutes*60<50000の条件が成立する場合に、informPowerUsage (Consumer,Wh,Minutes)とsetEventIntervalEvent(powerUsageEvent(Consumer,_,_),60)のアクションを実行することを意思決定することが定めている。
Wh/Minutes*60<50000は、単位時間あたりの使用電力量が50kWh未満を意味する。informPowerUsage (Consumer,Wh,Minutes)は、電力消費家(Consumer)の電力使用量(Wh)と電力使用時間(Minutes)の情報を転送するアクションであり、後述するように、本実施例では、環境群参照DB30から、転送先は電力供給家シミュレータ用の制御部31である。setEventIntervalEvent(powerUsageEvent(Consumer,_,_),60)は、powerUsageEventを60分ごとに通知するように設定するアクションである。
2番目の制御ルールは、powerUsageEvent(Consumer,Wh,Minutes)が通知された場合において、Wh/Minutes*60>=50000の条件が成立する場合に、informPowerUsage (Consumer,Wh,Minutes)とsetEventIntervalEvent(powerUsageEvent(Consumer,_,_),1)のアクションを実行することを意思決定することが定めている。
Wh/Minutes*60>=50000は、単位時間あたりの使用電力量が50kWh以上を意味する。setEventIntervalEvent(powerUsageEvent(Consumer,_,_),1)は、powerUsageEventを1分ごとに通知するように設定するアクションである。
図22に、実施例4に係る電力需要家エージェントの環境群参照DB30の例を示す。informPowerUsage(_,_,_)のアクションの通知先は、電力供給家シミュレータ(powerProviderSimulator)用の制御部、setEventIntervalEvent(powereUsageEvent(consumer,_,_),_))のアクションの通知先は、電力需要家(consumer)の電力需要化シミュレータpowerConsumerSimulator(Consumer)用の制御部であることが記載されている。
図23に、実施例4に係る電力供給家エージェントに対する通知間隔DB33の例を示す。この例では、需要家1(consumer1)に対するイベント通知が定められた例が示される。電力供給家エージェントpowerProviderAgentに、60分間隔で、イベントpowerPriceEvent(consumer1,_)を通知することが定められている。”_”には、電力価格(Price)を表す任意の値が入る。
図24に、実施例4に係る電力供給家エージェントのシミュレータ制御ルールDB20の例を示す。ここには2つの制御ルールが示される。各制御ルールは、それぞれ、If-when-thenの形式で記述されている。
1番目の制御ルールは、powerPriceEvent(Consumer,Price)のイベントが通知された場合において、Price<40の条件が成立する場合に、informPowerPrice (Consumer,Price)とsetEventIntervalEvent(powerPriceEvent(Consumer,Price),60)のアクションを実行することを意思決定することが定めている。informPowerPrice (Consumer,Price)は、単位電力価格の情報を電力需要家に転送するアクションである。setEventIntervalEvent(powerPriceEvent(Consumer,Price),60)は、60分ごとにpowerPriceEventが通知されるように設定するアクションである。
2番目の制御ルールは、powerPriceEvent(Consumer,Price)が通知された場合において、Price>=40の条件が成立する場合に、informPowerPrice (Consumer,Price)とsetEventIntervalEvent(powerPriceEvent(Consumer,Price),5)のアクションを実行することを意思決定することが定めている。
図25に、実施例4に係る電力供給家エージェントの環境群参照DB30の例を示す。informPowerUsage(Consumer,Price)のアクションの通知先は、電力需要家シミュレータ(powerConsumerSimulator(Consumer))を制御する制御部31、setEventIntervalEvent(powereUsageEvent(_,_,_)5))のアクションの通知先は、電力供給家シミュレータpowerConsumerSimulatorを制御する制御部31であることが記載されている。
以下、実施例4に係る動作を説明する。
各電力需要家の状況監視部32は、電力需要家シミュレータ1、2の状況を監視し、通知間隔DB33(図20)に従って、定期的にイベントpowerUsageEvent(Consumer,Wh,Minutes)を生成し、電力需要家エージェント1、2に通知する。
イベントpowerUsageEvent(Consumer,Wh,Minutes)を受け取った電力需要家エージェントpowerConsumerAgent(Consumer)の意思決定部22は、シミュレータ制御ルールDB20(図21)を参照する。1番目の制御ルールおよび2番目の制御ルールのどちらが成立する場合も、電力供給家シミュレータにも情報を転送するためのアクションinformPowerUsage (Consumer,Wh,Minutes)を実行することを意思決定する。
このとき、powerConsumerAgent(Consumer)の実行命令送信部29は、このアクションの実行命令の通知先を、環境群参照DB30(図22)を参照して決定する。具体的に、図22の環境群参照DB30から、アクションinformPowerUsage (Consumer,Wh,Minutes)の通知先を、電力供給家シミュレータpowerProviderSimulator用の制御部31に決定して通知する。
加えて、powerConsumerAgent(Consumer)の意思決定部22は、使用電力量Whと電力使用時間Minutesの大きさによって、異なるアクション実行の意思決定をする。
Wh/Minutes*60<50000の場合には、1番目の制御ルールの条件が成立し、電力需要家Consumerの電力需要家シミュレータから通知される使用電力量通知イベントの通知間隔を60分に設定するアクションsetEventIntervalEvent(powerUsageEvent(Consumer,_,_),60)を実行することを意思決定する。
Wh/Minutes*60>=50000の場合には、2番目の制御ルールの条件が成立し、電力需要家Consumerの電力需要家シミュレータから通知される使用電力量通知イベントの通知間隔を1分に設定するアクションsetEventIntervalEvent(powerUsageEvent(Consumer,_,_),1)を実行することを意思決定する。
このとき、powerConsumerAgent(Consumer)の実行命令送信部29は、これらのアクションの実行命令の通知先を、環境参照DB(図22)を参照して、電力需要家Consumerの電力需要家シミュレータpowerConsumerSimulator(Consumer)用の制御部31に決定して、送信する。これにより、使用電力量が大きいときには高い頻度で電力需要家の使用電力量を監視し、高い頻度で電力供給家に当該使用電力量を伝えることができるようになる。
一方、電力供給家の状況監視部32は、通知間隔DB33(図23)を参照して、イベント通知を行う。この通知間隔DB33には、電力供給家エージェントpowerProviderAgentに、一定間隔でイベントpowerPriceEvent(consumer,Price)を通知することが定められている。状況監視部32は、この通知間隔DB33の内容にしたがって、イベントpowerPriceEvent(consumer,Price)を一定間隔で、電力供給家エージェントpowerProviderAgentに通知する。イベントpowerPriceEvent(consumer,Price)を受け取った電力供給家エージェントpowerProviderAgentの意思決定部22は、シミュレータ制御ルールDB20(図24)に基づいて、実行すべきアクションを決定する。
イベントpowerPriceEvent(Consumer,Price)を受け取った電力供給家エージェントpowerProviderAgentの意思決定部22は、1番目の制御ルールおよび2番目の制御ルールのどちらが成立する場合も、アクションinformPowerPrice(Consumer,Price)を実行することを意思決定する。このとき、powerProviderAgentの実行命令送信部29は、このアクションの実行命令の通知先を、環境群参照DB30(図25)を参照して決定する。
powerProviderAgentの実行命令送信部29は、図25の環境群参照DB30からアクションinformPowerPrice (Consumer,Price)の通知先を、電力需要家シミュレータpowerConsumerSimulator(Consumer)用の制御部31に決定して通知する。これにより、電力需要家シミュレータに電力価格情報を伝えることができるようになる。
加えて、powerProviderAgentの意思決定部22は、単位電力価格Priceの大きさによって、異なるアクション実行の意思決定をする。
Price<40の場合には、1番目の制御ルールの条件が成立し、電力供給家シミュレータから通知される単位電力価格通知イベントの通知間隔を60分に設定するアクションsetEventIntervalEvent(powerPriceEvent(Consumer,Price),60)を実行することを意思決定する。
Price>=40の場合には、2番目の制御ルールの条件が成立し、電力需要家Consumerの電力供給家シミュレータから通知される単位電力価格通知イベントの通知間隔を5分に設定するアクションsetEventIntervalEvent(powerPriceEvent(Consumer,Price),5)を実行することを意思決定する。
このとき、powerProviderAgentの実行命令送信部29は、これらのアクションの実行命令の通知先を、環境参照DB(図25)を参照して、電力供給家シミュレータpowerProviderSimulator用の制御部31に決定して送信する。
これにより、使用電力量が大きいときには高い頻度で電力需要家の使用電力量を監視し、高い頻度で電力供給家に当該使用電力量を伝えることができるようになる。また、単位電力価格が高いときには高い頻度で単位電力価格を監視し、電力需要家シミュレータに伝えることができるようになる。
図33に、実施例5に係る分野特化型シミュレータおよびエージェントの具体例を示す。
分野特化型シミュレータとして、ミクロレベルの交通シミュレータを用意し、メタレベルマルチエージェントシミュレータ(図1)にプラグインする。また、交通シミュレータで走行する電気自動車(EV)に対応する同数のEVエージェントをメタレベルマルチエージェントシミュレータのエージェントとして用意する。ここでは2つのEV1,EV2に対応して、2つのEVエージェント1、2が用意される。
図26は、交通シミュレータの各EVに相当する各EVエージェントのシミュレータ制御ルールDB20の例を示す。EVの名前をEVNameと記述し、名前EVnameのEVに対応するEVエージェントをevAgent(EVName)と記述する。ここでは2つの制御ルールが定義されている。
1番目の制御ルールでは次のことが定められている。すなわち、交通シミュレータからイベントbatteryResidueEvent(EVName,BatteryResidue)が通知された場合に、電池残存量BatteryResidueが一定値(5kwh)より大きい条件が成立する場合は、 setEventInterval(batteryResidueEvent(EVname,_) ,900)のアクションを実行することを意思決定する。setEventInterval(batteryResidueEvent(EVname,_) ,900)は、電池残存量BatteryResidueを、EVに対応するEVエージェントに900秒ごとに通知させるアクションである。
2番目の制御ルールでは次のことが定められている。すなわち、交通シミュレータからイベントbatteryResidueEvent(EVName,BatteryResidue)が通知された場合に、電池残存量BatteryResidueが一定値(5kwh)以下になったら、gotoChargeStationと、 setEventInterval(batteryResidueEvent(EVname,_) ,60)のアクションを実行することを意思決定する。gotoChargeStationは、最寄りの充電ステーションにEVを向かわせるアクションである。setEventInterval(batteryResidueEvent(EVname,_) ,60)は、電池残存量BatteryResidueを、EVに対応するEVエージェントに60秒ごとに通知させるアクションである。
図27に、実施例5に係るEVエージェントの通知間隔DB33の例を示す。通知間隔(900秒の時間間隔)で、各EV(ここではev1とする)の電池残存量を、メタレベルマルチエージェントシミュレータの対応するEVエージェントに通知することが示されている。
図28に、実施例5に係るEVエージェントの環境群参照DB30の例を示す。setEventInterval(batteryResidueEvent(_,_) ,60)は、交通シミュレータ用の制御部に通知することが示されている。また、gotoChargeStationは、交通シミュレータ用の制御部に通知することが示されている。図示されたもの以外にも他のアクションが登録されてよい。たとえば、setEventInterval(batteryResidueEvent(EVname,_) ,900)等のアクションも登録されていてよい。
以下、実施例5に係る動作の例を示す。
交通シミュレータの状況監視部32は、通知間隔DB33に記載された通知間隔(図27の場合900秒の時間間隔)で、各EV(ここではev1とする)の電池残存量を通知するイベントを、メタレベルマルチエージェントシミュレータの対応するEVエージェントに通知する。
このイベント通知間隔が長すぎる場合、EVエージェントの意思決定が遅れ、最寄りの充電スケーションにたどり着く前に電欠する可能性がある。従って、図26に示した2番目の制御ルールのように、電池残存量が一定値以下(5kwh)になったら、イベント通知の頻度を通常(900秒)より短く設定(60秒)するアクションを実行する意思決定をするようにする。
例えば、メタレベルマルチエージェントシミュレータのEVエージェントevAgent(ev1)が、交通シミュレータを監視する状況監視部32から、交通シミュレータ上のEV(ev1)の電池残存量が6になったというイベントbatteryResidueEvent(ev1,6)を受信したとする。
このとき、EVエージェントevAgent(ev1)の意思決定部22は、シミュレータ制御ルールDB20(図26)に記載の1番目の制御ルールに従って、イベントの通知頻度を900秒に設定するアクションsetEventInterval(batteryResidueEvent(ev1,_) ,900)を実行する意思決定をする。
このとき、EVエージェントevAgent(ev1)の実行命令送信部29は、環境群参照DB30(図28)を参照して、このアクションの実行命令を交通シミュレータ(trafficSimulator)用の制御部31に送信する。当該制御部31は、図29の上段から中段に示すように、通知間隔DB33におけるEVエージェントevAgent(ev1)への通知間隔を900秒に設定する。
900秒後、交通シミュレータを監視する状況監視部32は、通知間隔DB33(図29中段)を参照して、メタレベルマルチエージェントシミュレータのEVエージェントevAgent(ev1)に対し、交通シミュレータ上のEV(ev1)の電池残存量が4になったというイベントbatteryResidueEvent(ev1,4)を通知したとする。
このとき、EVエージェントevAgent(ev1)の意思決定部22は、シミュレータ制御ルールDB20(図26)に記載の2番目の制御ルールに従って、まず、最寄りの充電ステーションに向かうアクションgotoChargeStationを実行することを意思決定する。
このとき、EVエージェントevAgent(ev1)の実行命令送信部29は、環境群参照DB30(図28)を参照して、このアクションの実行命令を、交通シミュレータ(trafficSimulator)用の制御部31に送信する。これにより、交通シミュレータを制御する。
引き続き、EVエージェントevAgent(ev1)の意思決定部22は、上記2番目の制御ルールに従い、イベントの通知間隔を60秒に設定するアクションsetEventIntervalEvent(batteryResidueEvent(ev1,_) ,60)を実行する意思決定をする。
このとき、EVエージェントevAgent(ev1)の実行命令送信部29は、環境群参照DB30(図28)を参照して、このアクションの実行命令を交通シミュレータ(trafficSimulator)用の制御部31に送信する。この制御部31は、通知間隔DB33に記載のEVエージェントevAgent(ev1)へのイベントの通知間隔を、図29の下段のように、60秒に設定する。
交通シミュレータを監視する状況監視部32が、通知間隔DB33に従って次にこのイベントをevAgent(ev1)に通知するのは、60秒後となる。
以上、本実施例によれば、EVの電池残存量が低くなったときには、高頻度で交通シミュレータのEVの電池残存量をセンシングすることで、電欠を防止することが可能になる。
実施例1〜5では、エージェントへのイベントの通知間隔を通知間隔DB33に設定していたが、エージェントの信念DB26に各イベントの取得間隔を記載してもよい。この構成では、エージェントが、信念DB26に記載された間隔で、能動的にイベントを取得するアクションを実行すればよい。
本発明のいくつかの実施形態を説明したが、これらの実施形態は、例として提示したものであり、発明の範囲を限定することは意図していない。これら新規な実施形態は、その他の様々な形態で実施されることが可能であり、発明の要旨を逸脱しない範囲で、種々の省略、置き換え、変更を行うことができる。これら実施形態やその変形は、発明の範囲や要旨に含まれるとともに、特許請求の範囲に記載された発明とその均等の範囲に含まれる。