第 10 回マルチ・エージェントと協調計算ワークショップ (MACC2001) 2001.11.16-17

1

マルチエージェントによるチーム航行支援安藤 英幸 広野 康平 大和 裕幸

リッジの業務は、周囲の船舶や自船の位置といった状

1 はじめに況に応じて、実行する業務を適応させる必要がある。

ビジネスや製造のプロセスモデルを整理し、情報やこのために必要となるプロセス表現の整理とワーク業務の引継ぎの自動化を目指したワークフロー管理

フローエンジンの実装を行う。

システムが注目されている。

2 背景

ワークフロー管理システムの中心となるのは、プロセスモデルとそれを実行するワークフローエンジン

船上業務の種類は、例えば見張り、船位確認とである。一般にプロセスモデルは、コミュニケーショいったレベルの業務をユニットとして約 600〜700 ユン、作業の対象、ユーザーのアクティビティといったニット程度であると言われる [1]。それぞれの業務は、視点から有向ネットワークにより表現される。また

Hutchins も述べているように構造の良くわかった問

ワークフローエンジンは、プロセスのテンプレートか題で、あらかじめ作業手順を定型化する事ができるらのインスタンスの作成、タスクの割り当て、実行と[2]。しかし、それら定型的な業務も、自船位置と航モニタリング、例外処理を行う。

路の関係、他船の位置と速度、ワッチレベル (watch

これらの枠組みは、定型的にプロセスモデルを記述level) と呼ばれる危険度の指標、他の作業、作業の記できる場合には十分である。しかし、とりまく環境の録といった多様なコンテクストに応じて、行うべき業変化に対応してプロセスの更新が必要であったり、プ務、優先順位、処理に要する時間、繰り返し業務に関ロセスを外部環境との関連で表現するのが適していする時間間隔等が変更する。

る場合には、プロセスモデルの表現の工夫と、持続的これらの船上業務についての詳細は SMS(Safetyにプラニング、スケジューリング、実行のモニタリン

Management System) マニュアルという印刷物の形グを行うワークフローエンジンが必要となってくる。

で各運航会社毎にまとめられ、船上で利用されてい本研究では、船舶のブリッジ業務に動的なワークフる。しかし、作業の状況への依存性が高い事からマロー管理システムを実装する事を目的としている。ブ

ニュアルが複雑化したり、マニュアルの見直しに必要な実作業の履歴の入手が現状では困難であることかTeam Navigation Support with Multi-Agents System
Hideyuki Ando, 東京大学 新領域創成科学研究科, Graduate School of Frontier Sciences, University of Tokyo
Kouhei Hirono, (株) 日本海洋科学, Japan Marine Science Inc.
Hiroyuki Yamato, 東 京 大 学 新 領 域 創 成 科 学 研 究 科,
Graduate School of Frontier Sciences, University ofTokyoら、ワークフロー管理システムに SMS マニュアルの情報を移植し、作業の見逃し、対応の遅れの防止、さらには、作業履歴の分析による基のプロセスモデルの改善が期待される。

21

第 10 回マルチ・エージェントと協調計算ワークショップ (MACC2001) 2001.11.16-17

2

論部分へのエキスパートシステム JESS(Java Expert

3 エージェントとアーキテクチャSystem Shell) [5] の利用、各レイヤーのコンポーネン

3.1 エージェントの構成

トの構成の変更といった改良を加えた。

ブリッジ業務の動的なワークフロー管理システム
は、プロセス、外的状況、作業者に関する情報をネッ

Agent

トワーク上で交換し、それらに基づいて適切な業務

Agent Knowledge Base(AKB)Agent Control Unit(ACU)

Social Model

SRPS

A

Cooperative Planning
Layer(CPL)

Mental Model

SRPS

A

Local Planning
Layer(LPL)

World ModelSR

PSのプラニング、スケジューリング、実行モニタリングを持続的に行う必要がある。これらの実装にマルチエージェントを採用することとし、その実装のベー

Behavior BasedA
Layer(BBL)
Active PoBs

Sensors
ActorsCommunication
World Interface(WIF)スに、Jin らがワークフローによる協調設計支援のために開発した ActiveProcess 環境を利用する [3]。

Environment
User Interface

ActiveProcess の各エージェントは、ネームサーバー

inputを介して KQML メッセージを交換する。コンテンツフォーマットを利用している。本研究では、航海士の図2支援を行うユーザーエージェント、船長につきチーム

suggestion/recommendation

SRPS
A

User

言語としては、順序なしリストを表現できる独自のOther agents and systems
Information flow
Control flow
Situation recognition
Planning & scheduling
ActionAgent architecture

全体の業務プロセスを管理するマネージャーエージェ
ント、船舶運航に関する情報をもつセンサーデータ

エージェントの内部構成を図 2 に表す。全体は World

サーバーのラッパーとして働くリソースエージェント

Interface(WIF)、Agent Knowledge Base(AKB)、を配置した (図 1)。

Agent Control Unit(ACU) に よって 構 成 さ れ る 。
WIF はエージェントと外部環境とのインターフェー
スで、ユーザーインターフェース、他のエージェント

Resource agent
User agent

User agentとの通信、センサーデータの取得に利用する。エー
ジェントの持つ周囲の環境に関する知識、作業者のName server
Sensor data server

行うワークフロー、他エージェントに関する知識はManager agent
Requests and results messages in K Q M LWorld model, Mental model, Social model の 3 層

Register messages in K Q M LSensor data on UDP/IPに分けて AKB に置かれる。また、AKB はそれらの知識の登録、取り出しのためのインターフェースを

図1

Multi agents configuration持つ。ACU では AKB の知識を基に即応 (BBL)、熟考 (LPL)、協調 (CPL) のそれぞれの層が独立して状況の認識、プラニング、アクションを行う。ACU 内

3.2 多層型アーキテクチャのレイヤー間の通信には KQML を使用する。即応ActiveProcess では、自律的な振る舞い、推論、エー層では、Pattern of Behavior(PoB) と呼ばれるエージェント間の協調といった知的な機構に関しては、ドジェントの振る舞いのパターンを記述したモジュール

メインに合わせて開発を行う必要がある。本システの Active/Inactive の切り替えを行う。PoB には反射

ムでは、エージェントに求められるタスクの多様性的な対応を行うための reactive PoB と他の層からのから、即応、熟考、協調の 3 つの機能を独立したレ委託により Active な状態になる procedure PoB がイヤーとして実現し、協調ロボットの実装を良く整ある。

理した InterRAP アーキテクチャの概念を基本的にエージェントは全体として、AKB の知識をベース採用することとした [4]。ただし、熟考、協調層の推に即応、熟考、協調の各層がプラニング、スケジュー22

第 10 回マルチ・エージェントと協調計算ワークショップ (MACC2001) 2001.11.16-17
リングを行い、PoB の実行リスト (Active PoBs) のWorkflow

3

チーム全体の作業プロ切り替えを判断している事になる。

セス

Activity

1 人の作業者に割り当

3.3 実装てる作業の最小単位

システムは WindowsNT/2K 上で開発を行った。
エージェントの開発には Java 言語を利用したが、他Work Element

Operation の集合

Operationのアプリケーションとの連携を容易にするため Visual

作業の最小単位表1

Role of each layer

J++ を用いて COM(Component Object Model) のDLL(Dynamic Link Library) として実装した。また、ユーザーインターフェースの実装は Visual Basic を4.2 プラニング、スケジューリング用いた。

ユーザーの作業のプラニング、スケジューリング
は、図 4 の手順で行われる。外部環境の変化にマッ

4 プロセスマネージメント

チするルールが発火し、実行するべきサブツリーが選4.1 プロセスモデル択される。選択されたサブツリーは、順序の制約を満Wilkins らは、現実問題へのプラニング技術の適応たすように展開され、一連のオペレーションにより構を考える場合、ドメイン知識の利用が不可欠である事成されるプランとなる。これに、それぞれの作業時間を指摘している [6]。ドメイン知識を利用したプラニを適応してスケジュールが構成される。この作業は継ングの代表として HTN(Hierarchical Task Network)

続的に繰り返される。また、現時点で、サブツリーのがある。HTN ではツリー構造によってプロセスを記選択のために用意したルールの例を以下に示す。

述し、ゴールに合わせて上位概念を選択し、下位のツ• 周囲に船が接近してきた場合に起動リーを展開し、最終的にプリミティブな操作で構成• ワッチレベルに応じた起動されるプランを得る。本研究でも、記述が可能であ• デフォルトで起動ることから、階層構造というドメイン知識を用いたプロセス記述を採用し、特に Jin らが ActiveProcessで利用している Workflow, Activity, Work Element,Operation の 4 階層によるプロセスモデルに従う事とした。プロセスモデルのツリーの各階層の役割を、
表 1 に示す。
また、動的な環境の変化に対応して適切なプラニングを行うために、全体のツリーのうちどのサブツリーを駆動するかという知識をエキスパートシステ

図4Planning and scheduling

ム JESS のルールという形で記述する。（図 3)。
Workflow

rule 1

4.3 実行とモニタリング

rule 2Activity
WorkElementOperation

rule 3...

熟考層でスケジューリングが行われた作業は、ユー

rule n

ザーインターフェースを通して、ユーザーに対して提Hierarchical process model Process activation rules

図3示され、その終了までをモニタリングされる。各作業のモニタリングは、図 5 に示す状態遷移規則に基づいProcess modelて行われる。エージェントとユーザーインターフェー

23

第 10 回マルチ・エージェントと協調計算ワークショップ (MACC2001) 2001.11.16-17スの間で、図 5 の矢印の上に示されたフラグを交換し、状態を遷移する。作業のモニタリングは、即応層

4

自船データ

1 秒間隔で生成

他船データ

3 秒間隔で生成（一般的なレーのレベルの作業モニタリング用 PoB が担当する。開ダーの周期が３秒であるため）。

始時には熟考層から Active にするメッセージが即応層に送られ、ユーザーインターフェースを介してユーザーに提示される。作業終了時には、ユーザーからの自船の運動

舵角とエンジンテレグラフ値の計算

入力より、応答遅れを考慮して終了の通知を受けて、熟考層が業務の終了を認識し、先のモニタリング用 PoB を Inactive にするように即応層にメッセージを送る。

船体運動計算する。
他船の運動

予め設定されたコースをトレー計算

スさせて運動を再現。変針動作
は一定の角速度で回頭させていREADYNO REPLY

TO_ACTIVATE

る。

WAIT_FOR_ACTIONRES_COMMENCERES_ABORT RES_POSTPONENO REPLY

NO_REPLYEXECUTION_DENIEDRES_ABORTRES_POSTPONERES_DONEASK_CONFIRMATION

電子海図上に自船位置と他船位

TO_CONFIRM

RES_ABORT

置、それぞれの速度ベクトルを

RES_NOTICERECEIVE_NOTICEEXECUTION_COMPLETED

表示

WAIT_FOR_NOTICEEXECUTION_POSTPONED

重ねて表示。ECDIS と同等invalid

表2

no reply

Specification of the simulator

EXECUTION_FAILED

5.1 プロセスツリーの展開
図5

State transition for operation monitoring

航海士エージェントは、「見張り」Activity 以下の階層構造を展開し、目視による監視、レーダーによる監視といった Operation を順次促し、次に「船位測定」

5 検証

Activity 以下の階層構造を展開し、下位の Operation開発したエージェントの動作を確認するため、船舶の実行を提示し、当直航海士の作業遂行支援を行う事のデスクトップ型の操船シミュレータ（仕様を表 2 にを確認した。

示す）に接続した。自船、他船に関する情報は、レーダー装置を代替するセンサーデータサーバからネット5.2 作業のモニタリングワーク上のリソースエージェントに対して送られる。

航海士エージェントは、状態遷移規則に基づき、モシミュレーションの海域は、伊豆大島東方で、自船はニタリング用の PoB を通して、ユーザーインター洲崎沖変針点向け航行中とした。シミュレーション

フェースとの間でメッセージの送受信を行い、選択は、ワッチレベル１ (当直航海士 1 名体制) として開された Operation が最終的に、正常終了、異常終了、始した。当直航海士は船長から「見張り」、「船位測延期、応答なしのいずれかの状態になるまでモニタリ定」、「避航操船」の 3 つの Activity を与えられていングを行った。また、応答が許容時間内にない場合にる。船長は船橋にいない状態であるが、「ワッチレベは、入力の催促を行った。

ルの切り替え」の Activity が常時割り当てられている。この状態で、以下の点についてシステムの動作を5.3 動的な環境でのサブツリーの選択確認した。

「ワッチレベル切り替え」Activity が起動される

1. プロセスツリーの展開条件を、この検証では TCPA （最接近までの時間）

2. 作業のモニタリングがプラスで、DCPA（最接近時の距離）が 1 マイル

3. 動的な環境でのサブツリーの選択以下となる船舶が、同時に、10 マイル以内に 2 隻以上現れたとき とした。船長エージェントは、リソー
スエージェントから TCPA, DCPA 情報を定期的に24第 10 回マルチ・エージェントと協調計算ワークショップ (MACC2001) 2001.11.16-17

5

取得し、この条件を満たす状態に変化した直後に、船ワークフローエンジンの機能としては、作業スケ長に対してワッチレベルの切り替え Operation を提ジューリングの作成に関して、iterative repair の導示し、船長はワッチレベルを変更した。 航海士エー入等による、より無理のないスケジュールの更新手法

ジェントはワッチレベルが変更された事を受け、「避の検討、作業者間の負荷分散、ユーザーによるスケ航操船」Activity の担当を外し、代わって船長エージュール変更を許すためのインターフェースが必要とジェントが「避航操船」Activity を担当するツリーに考えている。

加えた。

7 謝辞
6 まとめ

本研究の遂行にあたり、（株）日本海洋科学の東京

船上のブリッジ作業支援というドメインにおける動大学名誉教授小山健夫先生から多数のご助言を頂き的ワークフロー管理システムの設計を行うにあたり、ました。また、東京大学助教授の白山晋先生、増田

プロセスモデルとして、階層構造で表現されるプロセ

宏先生、海上安全技術研究所の伊藤博子氏には研究スモデルと、駆動するべきサブツリーを選択する規の遂行にご協力いただきました。システム開発にあ則を記述したエキスパートシステムのルールを併用たり、南カリフォルニア大学の Prof. Yan Jin からはした。また、それらを実行するためのワークフローエ

ActiveProcess のソースコードの提供と多数のご助言ンジンのアーキテクチャとして、マルチエージェントを頂きました。ここに感謝いたします。なお、本研究を採用し、特に、多様なタスクを並行してこなすためは平成 12 年度文部省科学研究費補助金による基礎基に、InterRAP の多層アーキテクチャを基に、エキス盤 (A)(2)-1230817 の補助を受けました。

パートシステムを推論エンジンとして使用するなど参考文献の拡張を行った。
これらにより実装した動的ワークフロー管理シス[1] 日本造船協会第 238 研究部会. 新しいフリートサポー
トシステムの研究、平成 10 年度報告書. 社団法人 日本造船研究協会, 1999.
[2] E. Hutchins. The technology of team navigation,
1990.
[3] Yan Jin, Li Zhao, and Arun Raghunath. Activeprocess: A process-driven and agent-based approach to supporting collaborative engineering. InProc. of ASME Design Engineering Technical Conference, Las Vegas, Nevada, 1999.
[4] Jörg P. Müller. The design of intelligent agents:a layered approach, Vol. 1177. Springer-Verlag Inc.,New York, NY, USA, 1996.
[5] Jess. http://herzberg.ca.sandia.gov/jess/.
[6] D. Wilkins and M. desJardins.
A call forknowledge-based planning. AI Magazine, Vol. 22,
pp. 99–115, 2001.

テムが、環境を認識し、条件に適応するサブツリーを選択し、それを展開し、作業者のスケジュールを作成し、その実行をモニタリングする事を、船舶の操船シミュレーターを利用した実験において確認した。
実用に向けては、まだ非常に多くの課題がある。現時点では、プロセスモデルの準備とルールの数が十分ではなく、この整備が必須となる。また、エージェ
ントの認識できる情報は大きく制限され、例えば気象や海象といった情報を扱うことができない。これらを含めて、どのように人間とエージェントが協調的に作業を行うかを考えていく必要がある。

25