組織を構成するエージェント > 組織構成プロトコルについて

組織構成プロトコルについて

  • 全体の流れ
  • ファクトの生成
  • タスク評価
  • 採用する入札の選択
  • インスタンシエート
  • 落札情報の追加

  •  1. 全体の流れ
     このプロトコルは、契約ネットプロトコルを基にした組織構成のための協調プロトコルである。ルールセット内には、組織構成を行う上でエージェント間で共通するとルールをまとめたものであり、ルールセットを読み込んだだけでは組織構成が行われない。設計したエージェントに本プロトコルを使った組織構成を行わせるためには幾つかのルールを追加する必要がある。本プロトコルは、ワーキングメモリに該当するファクトを生成することで状態遷移を行う形式をとっているため、主にエージェント設計者が実際に追加するルールはファクトの生成のための処理になる。以下にプロトコルの全体の流れを示すが、流れの中で青い枠で囲まれた部分がエージェント設計者が記述するルールである。

    マネージャ(タスク通知) マネージャ(直接落札) コントラクタ

    (1)

    メッセージの受信
    タスク評価
    タスク通知の送信 直接落札の送信
    メッセージの受信
    (1)
    タスク評価
    入札の送信

    (2)
    入札の受信 / タイムアウト
    採用する入札の選択
    交渉終了の送信 タイムアウト

    (3)
    インスタンシエート
    インスタンシエート終了

    (4)
    落札情報の追加
    落札の送信
    落札の受信
    (3)
    インスタンシエート
    動作可能の送信
    動作可能の受信
    動作可能の送信(※)
    (※)分割したサブタスクを請け負っている全てのエージェントから動作可能メッセージを受信した後、マネージャに対して動作可能メッセージを送信する。

          : ルールセット内で処理される箇所
          : エージェント設計者が記述可能な箇所
    戻る ] 
     2. ファクトの生成
     (1) タスク評価
    メッセージの受信
    タスク評価 タスク通知/直接落札/入札の送信
     
    【解説】
     他のエージェントから送られてきたタスク通知・直接落札から以下のファクトを生成する。生成されたファクトのtask属性にOAV形式で依頼内容が記述されているが、その中のname属性は、エージェントがもっている機能を表す属性である。ある機能に対して複数のエージェントを用意したい場合は、:nameの属性値を同じにし、それ以降に記述されている他の属性で機能の差別化する。
    (task-check  :id  <タスク識別子>  :task  (task  :name  <機能名>  :属性1  値1  ...))


    メッセージの受信
    タスク評価
    タスク通知/直接落札/入札の送信
     
    【解説】
     タスクが実現可能ならば、返信用メッセージに付加する入札情報のための (bid)ファクトを生成する。ファクトを生成せずに読み込んだルールセット内のルールに発火するかどうかの処理が移ってしまうと実現不可能なタスクとして依頼が破棄されてしまうので、 (bid)ファクトを生成する前に別な処理が必要な場合は、ルールセットの優先度を変更するか、設計者が記述したルールが発火し続けるようにする。
    以下のファクトを生成することによって次の状態に遷移する。

    (bid  :id  <タスク識別子>  :content  (task  :name  <機能名>  ...))

    タスクを分割しない場合 (コントラクタ)
    → 上記の (bid)ファクトを生成するだけでよい。

    タスクを分割する場合 (マネージャ)
    → サブタスクに関するファクト (decompose)を生成する。

    (decompose :id  <タスク識別子>
    :to  <エージェント名>
    :env  <リポジトリ名>
    :wait  <時間(ミリ秒)>
    :wp  <ワークプレース名>
    :task  (task  :name  <機能名>  ...))

    (decompose)ファクトについて
    属性 説明
    :id (変更不可) タスク通知・直接落札を受信した時点で決定される値なので変更する必要はない
    :to エージェント名 直接落札の場合 → エージェント名
    タスク通知の場合 → _broadcast
    :env リポジトリ名 メッセージの送信先となるリポジトリ名
     :wait  数値 入札・拒否メッセージ待ちでタイムアウトするまでの時間
    :wp  ワークプレース名  インスタンシエート先のワークプレース名
    :task OAV形式 :name属性は必ず記述すること。それ以外の属性については任意

    メッセージの受信 タスクの評価
    タスク通知/直接落札/入札の送信
     
    【解説】
     タスク評価で生成された(decompose)ファクトを基に各メッセージを送信する。メッセージの送信後、(decompose)ファクトは削除される。
    マネージャ(タスク通知の場合)
    → 生成された (decompose)ファクトを基にタスク通知(task-announcement)メッセージを送信する。

    マネージャ(直接落札の場合)
    → 生成された (decompose)ファクトを基に直接落札(directed-award)メッセージを送信する。

    コントラクタ
    → 生成された (bid)ファクトを基に入札メッセージを送信する。

    戻る ] 
     (2) 採用する入札の選択
    入札の受信 / タイムアウト
    採用する入札の選択 交渉終了の送信
     
    【解説】
     送信したタスク通知(task-announcement)メッセージに対して送られてくる入札(bid)メッセージから以下に示すファクトを生成するが、この処理はメッセージを受信した直後ではなく、(decompose)ファクトで指定された時間が経過した後に行われる。生成したファクトの :task属性には、OAV形式で入札内容が記述されているが、:name属性以外は、エージェント設計者が自由に記述することができる。つまり、タスク通知を送信する前に生成した (decompose)ファクトの :task属性で記述した :name属性以外の情報と同じ属性を含んでいる必要はない。
    (bid-check  :id  <タスク識別子>  :bid  (task  :name  <機能名>  ...))  :no  <メッセージID>

     全ての入札(bid)メッセージに対する処理が行われると以下に示す (award-check)ファクトが生成されるので、このファクトが存在することを確認した後に、次に示す「採用する入札の選択」に関する処理を行う。
    (award-check :id <タスク識別子>
    :task (task  :name  <機能名>  ...))
    :award null
    :wp <(decompose)ファクトで指定したワークプレース名>

    入札の受信 / タイムアウト
    採用する入札の選択
    交渉終了の送信
     
    【解説】
     ここでは、入札メッセージより生成された (bid-check)ファクトの中から採用したい入札を選択するための処理を記述する。採用する入札が決定したら、その入札の (bid-check)ファクトに含まれている :no属性の値を (award-check)ファクトの :award属性に代入する。ここで、代入が行われず nullのまま、ルールセット側に推論が移行すると「入札が無い」もしくは「条件を満たせる入札が無かった」として処理が継続される。
    採用する入札の選択に関する記述例
     ...
    
     (award-check :award "null") = ?ac
     (bid-check :id ?ac:id :bid (task :name ... )) = ?bid   
    
     -->
    
     (modify ?ac:award ?bid:no)
    
     ...
    			    

    入札の受信 / タイムアウト 採用する入札の選択
    交渉終了の送信
     
    【解説】
     ここでは、採用されなかった入札メッセージに対して交渉終了 (negotiation-end)メッセージが送信され、該当する(bid-check)ファクトも同時に削除される。このメッセージを受信した落札待ちのコントラクタは、タスク分割を行っている場合は、さらに下位のコントラクタに交渉終了メッセージを伝搬し、処理中に生成したファクトを削除したあと待機状態に遷移する。これらの処理はルールセット内のルールで行われる。
    戻る ] 
     (3) インスタンシエート
    落札の受信
    (交渉終了の送信 / タイムアウト)
    インスタンシエート 動作可能の送信
    (インスタンシエート終了)
     
    【解説】
     落札 (award)メッセージを受信すると以下に示す (init)ファクトが生成される。また、同時に「(1)タスク評価」で生成した(task-check)ファクトと(bid)ファクトが削除される。
    (init :id タスク識別子 >
    :name null
    :wp 落札メッセージで指定されたワークプレース名 >
    :award 落札メッセージに記述されている落札内容 >
    :facts ( )

    initファクトについて(インスタンシエート前)
    属性 説明
    :id (変更不可)  タスク通知・直接落札を受信した時点で決定される値なので変更する必要はない。
    :name エージェント名  初期値は null。インスタンシエート(instantiate)アクションの返値として得られるワークプレース上でのエージェント名が代入される。
    :wp  ワークプレース名   マネージャから指定されたインスタンシエート先のワークプレース名が代入されている。次の「インスタンシエート」でこの値を更新することによってインスタンシエート先を変更することができる。
     :award  (任意)  マネージャから渡された落札内容が格納されている。これは後述の「落札情報の追加」で詳しく述べる。
    :facts リスト形式  後述の「インスタンシエート」において、この属性値にOAVデータを追加するとインスタンシエート(instantiate)アクション実行時に生成されたエージェントのワーキングメモリに追加される。

    落札の受信
    (交渉終了の送信 / タイムアウト)
    インスタンシエート
    動作可能の送信
    (インスタンシエート終了)
     
    【解説】
     「落札の受信(交渉終了の送信 / タイムアウト)」において生成された(init)ファクトの各属性に対して必要な情報を追加していく処理を行う。また、マネージャ側から送られてきた落札内容に対する処理を行いたい場合もこの段階で処理を行う必要がある。ここで記述する内容は必須ではなく、必要な部分についてのみ記述するだけでよい。
    • インスタンシエート先のワークプレースの指定
       以下に記述例を示すが、インスタンシエート先のワークプレース名は記述する箇所によって優先度が異なるので、エージェントの目的によって適切に設定する必要がある。

      記述例
        ...
      
        (init :name "null" :facts ()) = ?init  
      
        -->
      
        (modify ?init:wp "w1:_localhost")
      
        ...

      生成先のワークプレースの優先順位について
      優先度 記述箇所 (decompose :wp ) 説明
       コントラクタ側のインスタンシエートルール内  (無効) コントラクタ側エージェントのインスタンシエートルールの中でワークプレース名が指定されていた場合、その記述が最優先される。

       マネージャ側の(decompose)ファクト   ワークプレース名  マネージャ側から指定されたワークプレースにインスタンシエートされる。 (decompose)ファクトで記述したワークプレース名がこれに該当する。
       マネージャ側の(decompose)ファクト   null  マネージャ側の(decompse)ファクト内で指定しなかった場合、さらに上位のマネージャから指定されたワークプレースにインスタンシエートされる。

    • インスタンシエート先で必要となるファクトの追加
       インスタンシエート先のワークプレースで必要となるファクトを追加するための処理を記述する。(init)ファクトの :factsは、リスト形式になっているが、このリストに追加されたOAVデータだけが生成されたエージェントのワーキングメモリに追加される。

      記述例
        ...
      
        (init :name "null" :facts ()) = ?init  
      
        -->
      
        (unshift (URL :url "example.jp") ?init:facts)
      
        ...

    • 落札内容に対する処理
       ここでは、マネージャから送られてきた落札内容に関する処理を行う。マネージャ側での記述方法は「落札情報の追加」で述べる。具体的には、(init)ファクトの :award属性に格納されているが型などに制限はないのでエージェントに応じた設定をする必要がある。

    落札の受信
    (交渉終了の送信 / タイムアウト)
    インスタンシエート
    動作可能の送信
    (インスタンシエート終了)
     
    【解説】
     前述の「インスタンシエート」で記述された内容に従ってインスタンシエートが行われる。ここでは、 (init)ファクトの各属性が実際にインスタンシエートされたワークプレース名生成後のエージェント名で更新される。インスタンシエートに失敗していた場合は :name属性に 「FALSE」が代入される。

      インスタンシエート前   インスタンシエート後
    エージェント名 ( :name )
    null
    ワークプレース上でのエージェント名 or FALSE
    ワークプレース名 ( :wp )
    マネージャ側かコントラクタ側で指定されたワークプレース名
    アクションの引数として使用されたワークプレース名

     コントラクタの場合、インスタンシエート後にマネージャ宛に動作可能 (acceptance)メッセージを送信する。このメッセージには、分割したタスクを請け負っているエージェントも含めたエージェント名のリストを含んでいる。また、(init)ファクトは、メッセージの送信後に削除される。
     マネージャの場合、インスタンシエートに成功していれば分割したサブタスクを請け負っているエージェントに落札メッセージを送信するため、以降で述べる「落札情報の追加」に遷移する。
    戻る ] 
     (4) 落札情報の追加
    インスタンシエート終了
    落札情報の追加 落札の送信
     
    【解説】
     前述の「(3)インスタンシエート」で述べたインスタンシエートが行われた後に実行される。ここでは、引き続き (init)ファクトを使用するが記述されている内容がこれまでの処理によって更新されているので注意が必要である。
    initファクトについて(インスタンシエート後)
    属性 説明
    : id (変更不可) タスク識別子
    : name エージェント名  ワークプレース上でのエージェント名
    : wp  ワークプレース名   実際にアクションの引数として使用されたワークプレース名
     : award  (任意)  マネージャから渡された落札内容
    : facts リスト形式  ワークプレース上のマネージャエージェント名前

    インスタンシエート終了
    落札情報の追加
    落札の送信
     
    【解説】
     エージェントに対して落札情報を送りたい場合は、エージェント名を指定するのではなく機能名をキーとして (award)ファクトを生成する。ファクトは必要最低限生成するだけでよく、不足分については、落札情報を持たない (award)ファクトがルールセット内で自動的に生成される。落札情報の型に制限はないが、受信側のコントラクタで正常に処理できるか確認する必要がある。
    記述例
      ...
    
      (init :id ?id) = ?init
      (!= ?init:name "null")  ← nullの場合はインスタンシエート前
      (!= ?init:name "FALSE") ← FALSEの場合は失敗していた場合
      ~(award :id ?id)
    
      -->
    
      (make (award :id ?id :name < 機能名 > :content < 落札情報 >))  
    
      ...

    インスタンシエート終了 落札情報の追加
    落札の送信
     
    【解説】
     落札メッセージには、前述の落札情報の他にインスタンシエート先のワークプレース名や自信のワークプレース上でのエージェント名が送信される。タスク通知の場合、落札メッセージの送信時に (award-check)ファクトと採用した入札に該当する (bid-check)ファクトが併せて削除される。
    戻る ]

    Last modified: Fri Jan 24 17:17:13 JST 2003

    戻る ]   [ インデックスへ ]