Comments
Description
Transcript
柔軟性の高い情報家電のためのソフトウェアアーキテクチャ ½ はじめに
柔軟性の高い情報家電のためのソフト ウェアアーキテクチャ 会津 宏幸 z1 中島 達夫 z2 本論文では，情報家電を制御するための新しいソフトウエアアーキテクチャを提案する． 本アーキテクチャは従来 のシステムと比べて次の 3 つの特徴を持つ．1 つ目の特徴は，各ユーザが持つ PDA など を情報家電のコントローラ として用いることが可能となることである．2 つ目の特徴は，複数のデバイスを 1 つのデバイスであるかのように扱 うことが可能となることである．3 つ目の特徴は，コントロールの方式をユーザの好みや状況に応じてパーソナライ ゼーションすることが可能となることである．本アーキテクチャは汎用的なコントロールアーキテクチャを提供する ので，情報家電だけではなくコンピュータ上で実行されるアプ リケーションの制御にも用いることが可能である． A New Software Architecture for Home Networking Hiroyuki Aizuz1 and Tatsuo Nakajimaz2 This paper proposes a new software architecture for controlling devices in home networking. Our architecture has the following three characteristics that are not provided by existing home networking architecture. The rst charactersitics is that a user's PDA can be used as a remote controller for controlling respective A/V devices. The second charactersitics is that several devices can be composed, and it is controlled as a single device. The third charactersitics is that a user can customize a way to control devices according to the user' location and situation. Since our architecture is general purpose, it also can be used to control applications executed on computers. 1 はじめに ザによって異なる可能性がある. そのため, ユーザーインター フェースをカスタマイズ, 最適化可能な柔軟なハード ウエアを 現在の家電製品の多くに , リモートコントローラー (以下, コントローラとして用いることが望ましい. そのような問題点を解決するためには, 各ユーザが持つ PDA 略してリモコン ) が付属している. 例えば 各家庭の机の上には テレビ , ビデオ, エアコンなど を制御するためのいくつかのリ や携帯電話など のデバイスを用いてあらゆるデバイスを制御 モコンが置かれている. 機器本体に近づきデバイスの操作ボタ することが可能となることが望ましい. また, 各デバイスの制 ンに直接手を触れることなく , 赤外線や電波によって離れた場 御方式を PDA などのディスプレイ上に表示することによりコ 所からでもリモコンのボタンを用いて操作可能である. また， ントロールの方式をハード ウエアの制約から解放することが 最近はリモコンから操作することを前提に, 本体のスイッチ類 可能である. 実際, AT&T ケンブリッジ研究所における VNC が隠されている製品もある. しかし , それぞれのリモコンは付 [1] の研究では, サーバが生成した GUI を軽量クライアント上 属してきた機器専用であり, 他の機器をコントロールすること に出力することにより制御を柔軟に行うことが可能であるこ はできない . そのため, 家庭の中には複数のリモコンが存在し , とが示されている. また, 例えば ,Active Badges[2] や Ultrasonic Location リモコンと制御対象のデバイスとの対応関係が混乱するため， ユーザはど のリモコンでど のデバイスが制御できるかわから System[4] のようなデバイスを利用してリモコンを持つユー なくなってしまうことがよくある．また，各デバイスの機能が ザーの位置や, ユーザの向いている方向がわかればその情報を 豊富になるとともにリモコンの操作が複雑になり普通のユー 用いてコントロールするデバイスを変え, それに合わせてユー ザは簡単に制御可能なリモコンを新たに購入する場合もある. ザーインターフェースを変更することができる. 例えば , ユー ザはテレビを見ている場合は , テレビのコントローラに , エア 現在でも, リモコンの信号を記憶, エミュレートできる学習 コンを見ている場合はエアコンのコントローラとしてユーザ 型リモコンを使って 1 つのリモコンを用いて様々なデバイスを が現在持っている PDA を用いることが可能である. 制御することが可能かも知れない．しかし , 学習型リモコンの 本論文では，情報家電を制御するための新しいソフトウエ ボタンの数や位置はハード 的に固定されているため, ユーザの アアーキテクチャを提案する． 本アーキテクチャは従来のシ 要求やデバイスの特性に合わせて変更することは困難である. ステムと比べて次の 3 つの特徴を持つ．1 つ目の特徴は，各 その一方で, 各機器に付属のリモコンのボタン配置, つまり ユーザが持つ PDA などを情報家電のコントローラとして用い ユーザーインターフェースは各製品のコントロールが 容易な ることが可能となることである．2 つ目の特徴は，複数のデバ ように , 工夫, 最適化が施されていることが多い. 例えば , 使用 イスを 1 つのデバイスであるかのように扱うことが 可能とな 頻度が高いボタンは大きく, 押しやすい位置に置かれ , わかり ることである．3 つ目の特徴は，コントロールの方式をユーザ やすいボタン形状や表示に , あまり使わないボタンは小さかっ の好みや状況に応じてパーソナライゼーションすることが可 たり, カバーによって覆われていたりする. つまり, 単に複数の 能となることである．本アーキテクチャは汎用的なコントロー リモコンの機能を一個のリモコンにまとめて, ボタンを並べ直 ルアーキテクチャを提供するので，情報家電だけではなくコ すだけでは不十分である. しかし，よく利用される機能はユー ンピュータ上で実行されるアプ リケーションの制御にも用い ることが可能である． 本論文では , 第 2 節で関連研究とそれらの問題点について 述べる. また, 第 3 節では , 我々の提案するソフトウエアアー 1 z 1 北陸先端科学技術大学院大学 情報科学研究科 キテクチャの概要を説明する. 第 4 節では， リモートコント School of Information Science, Japan Advanced Institute of Science and Technology. z 2 早稲田大学理工学部情報学科 Department of Information and Computer Science, School of Science and Engineering, Waseda University. z2 1 ローラを用いて同様にデバイスを制御するかについて述べる. 第 5 節では, 我々のフレ ームワークにおいてど のように複数の デバイスをコンポジションするかについて述べる . 第 6 節で は , 我々のシステムの利用例を示し , 第 7 節では, 現在のアー キテクチャの評価と問題点について述べる . 2 従来研究と問題点 近年, 我々が日常利用している家電, 自動車, 携帯電話など にはコンピュータが組み込まれ , 更にそれらが インターネット に相互接続され つつあり , その数は増加している. これによ り, 接続された機器をユーザーの手元にある計算機からコント ロールしたり, それぞれの機器同士が通信し連携して動作する ことが可能になる . 従来は単独で動いていた機器がネットワー クにつながり遠隔操作可能になることで , 従来考えられなかっ た, まったく新しい使い方が編み出される可能性が見込まれて いる. このような環境を前提とすると, PDA や携帯電話のような 小型携帯端末をリモコン代わりにしてあらゆる機器をコント ロールすることが現実的になる. しかも複数の機器を連携しな がらコントロールすることで, あたかも複数の機器がひとつに コンポジションしたような振舞いをさせることができる. Jini[5, 6], HAVi[7], UPnP[8] をはじめ, 多くの大学, 研究 機関, 企業によりネットワーク上に直接接続されるデバイスを 取り扱う研究が行われている. これらは基本的にネットワーク 上に分散して存在するオブジェクトを, オブジェクトのプロパ ティをもとに検索して必要なオブジェクトをみつけてリモート から利用可能とするものである. コンポーネントをネットワー クに繋げるだけで使用可能になることから , 柔軟な動的な分散 システムが構築可能となると見られている. このようなシステ ムを使うことで各オブジェクト同士で通信を行い, 連携動作で きる基盤ができあがる. 本節では , 本研究と類似の目標を達成しようとする Sun マ イクロシステムが提案する Jini と松下電気やソニーなど 家電 メーカ 7 社が提案する HAVi に関する概要と問題点に関して 述べる． 2.1 Jini Jini は Java 上の分散サービスの仕様の集合である. 現在の Jini では, サービスを発見・登録するための Lookup, Discovery, Join サービス, リソースを管理するためのリースサービス，分 散イベントサービス，トランザクションサービス，JavaSpaces など のインタフェースを定義している. これらのサービ スは Java 上に分散アプ リケーションを構築する場合に一般的に使 用されるサービスであり, 特定のアプ リケーションに依存する サービスは現在の Jini では定義されていない. 本節では, この うち我々の研究と関連が深い Lookup, Discovery, Join サービ スに関してのみ議論する. Jini アーキテクチャの特徴は, 全てののデバイスおよびソフ トウェアをグループ化して連合体を形成し , 1 つの動的な分散 システムを構築できる点にある . これにより, 様々なデバイス の結合するアド ホックネットワークを構築することが 可能と なる . 例えば , 各ユーザの持つ PDA と携帯電話間でのアドレ ス帳の共有とか , PDA のアドレス帳の PC が持つデータとの 自動 Sync を行ったり, デジタルカメラからプ リンタにダイレ クトに印刷したりなどデバイスをネットワークに接続するだ けで近くに存在するデバイス間の通信を可能とする . Jini アーキテクチャでは, 計算機の演算能力, ストレ ージ, ユーザー, 通信チャネル , ハード ウェアデバイスといったもの がサービ スと呼ばれる . 各サービスは \Discovery" プロトコ ルを使用して適切な Lookup サービスを取得し \Join" という プロトコルを使用して連合体に加入する . あるサービスを利用 したい場合は Lookup サービ スを通じて必要なサービスへの アクセス方法を取得する. Jini を用いることにより様々なデバイスをネットワーク接 続するだけで利用することが可能となるため様々な設定が不 要になり細かい設定方法など知らなくても利用可能となる. し かし , 現状の Jini はいくつかの問題を持っている. Java を用いてアプ リケーションを構築する必要がある. CORBA サービスなど との共存が考慮されていない. サービ スの記述の仕方が定義されていない. Jini は基本的に Java 環境の上に構築することを前提にして おり, 通信も RMI を利用することが前提となっている. しか し現段階では CPU パワー, メモリ量の制約から家電などの組 み込み機器に Java VM を搭載するのは難しい. 現在, 組み込 み用 Java VM も開発が進んでいるが , やはりリソースの制約 からフルセットの Java VM とはならないと考えられる. また， 現在の Java 2 API をすべてのマシン上に搭載するためには最 低数メガのメモリを必要とする． メモリが少ないシステム上 では API のサブセットのみを提供することになり， すべての Java で記述されたアプリケーションが実行できるわけでない． そのため，移植性の高いアプ リケーションを構築するために は注意深く利用する API を選択する必要がある. 将来的に CPU 性能の向上やメモリなどのコストや消費電 力が下がり Java VM を搭載することに問題がなくなるかもし れない. では, 仮にフルセットの Java VM を搭載可能となっ たとしよう. Java は \Write once, run anywhere" と言われ ているが , 実際には， 動作プラットホームの違い,Java VM の バージョンや, ベンダーの違いによる Java VM の挙動の違い を解消しきれないことが予想される. 特にスレッドのリアルタ イムスケジューリング， ガーベージコレ クションのタイミン グ，Java のスレッドがユーザレベルスレッドを用いているか， カーネルスレッドを用いているかなどの違いによりアプリケー ションの記述やチューニング 方が異なる可能性がある . また, 組み込み機器など は簡単に Java VM をバージョンアップする わけにはいかないことを考慮しておかなければならない . CORBA サービスも Jini 同様のサービスを言語依存に提供 しているがそれらのサービ スと Jini の基本サービ ス間のイン タオペラビ リティに関しての検討も進んでいない . そのため , 他言語で記述されたサービ スを Jini で用いる場合は , Jini プ ロトコルから CORBA プロトコルへの変換が必要となり大き なオーバヘッド を生じると考えられる. さらに, 現在の Jini ではサービスの名前の記述方法に関し て明確な定義がない . サービ ス名を抽象的に定義可能とした 場合は, 様々なデバイス間のアド ホックな接続が容易となるが , 特定のデバイス間の接続のためには低レベルのサービ ス名も 必要になるかも知れない. 例えば , 近くのカラープ リンターに 印刷したい場合は , カラープ リンターのみ指定すればいいが , 特定のプリンタに印刷する必要がある場合は , プリンタ名を直 接指定する必要がある. また, アプ リケーションを記述する場 合, どのレベルの抽象化されたサービス名を用いるかを考慮し ないとアプ リケーションを様々な状況で用いることができな くなる. また Jini は単なる Lookup サービ スであり, 家電のコント ロールシステムのような具体的なシステム構築のためには, Jini のレ イヤの上に更になんらかのシステムを構築する必要があ る. さらに , Jini を TCP/IP 以外のネットワークプロトコル 上に構築する必要がある場合は, RMI の実装の再検討など 課 題は多い. 2.2 HAVi HAVi は ホームネットワークにおけるデジタル AV 機器の 相互接続/相互運用を実現するためのソフトウェアコンポーネ ント , API, 通信プロトコルを定義したアーキテクチャである. HAVi は以下のような特徴を持っている. プラグアンドプレ イ ユーザーが , 様々な機器を IEEE1394 など のデジタルイ ンターフェースで接続するだけで家庭内ネットワークを 構築することができる. このネットワークに, 例えば新し く機器を接続したり, 取り外した場合でも, 機器同士が通 信しあってネットワークが更新されたことを認識できる ため, ネットワークはその機能を停止することなく , 新し い機器配置に自動的に対応する. 機器の相互操作性 同仕様に基づく機器は , 相互接続や相互操作が可能なだけ でなく, 将来的には, ネットワーク上の機器間で機能を共 有することが可能. 例えばある機器を操作することで , そ の機器が持たない他機器の機能を利用することも可能. ネットワークの拡張性 将来の新しい家庭内ネットワークアプ リケーションで使 われる新しい機能を, ユーザーが既に利用している家庭 内ネットワーク上で利用するための拡張性が用意されて いる. 新たな機器・機能が開発された場合でも, すでに構 築されたネットワークに機器を接続するだけで動作させ ることが可能. また, 現在の HAVi 基本仕様において定義されている主なソ フトウエア要素は以下のとおりである. 1394 Communications Media Manager(CMM) IEEE1394 と各ソフトウエア要素間のインターフェース として働く. Event Manager(EM) ネットワークの状態変化 (例えば ネットワークに新たに 機器が接続されたり切り離されたりすること ) を他のソ フトウェア要素に知らせる. Registry ネットワーク上にど んな機器が接続されているか, また その機器がどんな機能を持っているかなど 機器に関する 情報を保持・更新する . アプ リケーション・プログラム はこの Registry から必要な情報を入手する . Messaging System(MS) ネットワーク上の各機器のソフトウェア要素同士がコミュ ニケーションするための API として働く. Device Control Module(DCM) 機器の制御を行う. アプ リケーション・プログラムは, この DCM を介して機器の制御を行いる . このためアプ リケーション・プログラム自体は個々の機器の違いを考 慮する必要がない . DCM Manager DCM の更新を行う. 新しい機器がネットワークに追加接 続されると, その機器に必要な DCM を新たに加え , ネッ トワークの更新に自動的に対応する. Data Driven Interaction(DDI)Controller 機器の表示部の GUI(Graphical User Interface) を担当 する. テキストだけの表示からグラフィックスの表示ま で, 多様なデ イスプレ イに対応する. Stream Manager(SMGR) ネットワーク上で映像や音声などのストリームデータ (連 続したデータ) の流れを監視・管理する. これらのコンポーネントを利用することにより異なるメー カの A/V 間の制御や相互接続が可能となる. しかし , 以下に 述べるような様々な問題点が残されている. デバイスの統合的な制御やフィルタモジュールの挿入 複数のデバイスのコンポジション コントロールの柔軟性 IEEE1394 以外のネットワーク A/V 機器以外の制御 現状の HAVi では , 複数のデバイスを同時に制御することが 困難である. 例えば , ビデオデータを処理する各デバイスのモ ジュールを同時にスタート／ストップ する場合などは, コント ロールを複数のデバイスに同時に配送するメカニズムが必要 となる . 特に , QOS 制御やメディア間同期のためデジタルビ デオデータやオーディオデータを各メディアエレ メントごとに タイムスタンプをつけて送る場合は, 時間のスタート／ストッ プを分散管理する必要がある . また, HAVi では, ストリーム 管理が貧弱なため様々なフィルタモジュールの挿入を行うこと が困難である. また, HAVi では, 各デバイスの DCM がそのデバイスが持 つ機能を FCM として管理している. そのため, 異なる DCM が管理する FCM 同士を統合することは容易ではない. つま り, 複数のデバイスを 1 つのデバイスであるかのように用いる ことはできない. 異なる機能を持った複数のデバイスを接続し それらを 1 つのデバイスとして扱うことを可能とすることに より各ユーザの好みに応じてデバイスをパーソナライゼーショ ンすることが可能となる. 同様に, デバイスの制御の方式はユーザ毎に変化する. 微調 整したい人もあれば , 最低限の制御のみ行いたい場合もある . また, 音声で制御したい場合もあれば , GUI を用いて制御した い場合もある. また, 現在の HAVi は IEEE 1394 を用いてデバイスを接続 することを前提としているが , 将来様々なネットワークが登場 するだろうし, インターネット上のサービスとの連携も考慮す る必要がある . さらに , A/V 機器以外の他の家電製品やコン ピュータとの融合も考慮する必要がある . 3 柔軟な情報家電フレームワークの 概要 本節では , 我々が提案する柔軟な情報家電フレームワークに ついて説明する. 3.1 本システムの目標 本フレームワークの目標は以下にあげ る 3 つである. 1 つのリモコンにより様々なデバイスの制御を可能とする. 複数デバイスのコンポジションを可能にする. 制御の方式をカスタマイズ可能にする. 第 1 の目標は A/V デバイスのみではなく様々なデバイスの制 御を 1 つのリモコンから可能とすることである. つまり, 制御 対象として, コンピュータ上のアプリケーションや A/V デバ イス以外の家電も制御可能にすることである. 第 2 の目標は , 複数のデバイスを 1 つのデバイスであるか のように扱うことを可能とすることである . この機能により, 複数のカメラとデ ィスプレ イを接続することにより作られた ビデオコンファレンスアプ リケーションを全体を 1 つのビデ オコンファレンスデバイスとして用いることを可能とする. :C,¤(oCo 5GTXGT &GXKEG &fP+6; :C,J` * &f;`o\ GT[ FKUEQX #EM :C,J` * âª:C, J` *3Î Yo)oo+f; Yo)o :C,o+f; :C, :C,J` * :C,J` * #EM 5GPF V IGP EG C FGXK #EM :C, :C,o+f; 図 2: プラグアンドプレ イ 図 1: 基本アーキテクチャ 第 3 の目標は, デバイスの制御を柔軟にカスタマイズするこ とを可能とすることである. つまり, GUI の表示を各ユーザの 好みを反映させるとか , デバイスのコンポジションをユーザの 好みや近くにあるデバイスに応じてアド ホックに接続するこ となど を可能とする. 3.2 V TGSWGU 2NWIKP 基本アーキテクチャ パーソナルエージェント (personal agent) ユーザーの位置や使用するデバイスのコンフィグレーショ ンをカスタマイズに必要な情報を持つ. 環境エージェント (environment agent) デバイスがネットワークへ接続されたり, ネットワークか ら切り離されたという, 環境の変化を監視, 状態を把握す るエージェント . コントローラ (controller) ユーザーインターフェースを司り, ユーザーに対してボ タンなどを表示したり, ユーザーからの入力を受けつけ ることができる. 本システムは図 1 に表されている, 以下の７つのコンポーネ ントから構成される. デバイス (device) 家電など の実際に動作して機能を果たす. 本システム のデバイスは HAVi のの FCM(Functional Component Module) のように, 各機器を単機能のコンポーネント単 位まで分解して取り扱う. 例えば， TV は, チューナー, アンプ , ディスプレ イ, コンバーターといった単機能のデ バイスがコンポジットしたものとして構築する. デバイスプロキシ (device proxy) デバイスをコントロールためのインターフェースとなる. リモートに存在するデバイスのコントロールは全てデバ イスプロキシを通して行われる. 実際にデバイスをコン トロールするための通信手段, 手順はデバイスプロキシ が把握しており, さまざ まな通信メディアを混在させる ことができる. デフォルトでは汎用デバイスプロキシが 用いられるが , デバイスエージェントの情報によりイン ターフェースが追加され各デバイス固有のプロキシとし て対応可能. デバイス管理サーバ (server) デバイスプロキシを生成, エージェントが転送され実行 される．Lookup サービスも行う. デバイスエージェント (device agent) 各デバイスの持っている機能や性能情報を保有している. 複数のデバイスを接続しコンポジションする際の設定を 持つことも可能. 3.3 システムの基本動作 本節では , 実際にデバイスをネットワークに接続したときど のように制御されるかについて述べる. 我々のフレームワーク 全体は Java によって記述する. まずはじめに, デバイスのプラグアンドプレ イは図 2 で示 されるシーケンスに従っておこなわれる. ネットワークにデバ イスが接続されるとデバイスはデバイス管理サーバーを探し サーバーにプラグ イン要求を出す. プラグ インされると, デバ イス管理サーバー内に接続されたデバイスに対応するデバイ スプロキシが生成される. この時, プロキシデバイスはデバイ スのネットワーク上のアドレスを保持し , 今後のサーバとデバ イス間の通信にはプロキシデバイスに登録されたアド レスが 利用される現在の我々の実装でプラグアンドプレイをサポート するためのデ ィレクトリサービスとして Jini を利用する . ま た, マルチメディアデバイスとしてカリフォルニア大学バーク レ イ校の Mash ツールキット [9] を用いる. この後, デバイスはデバイスプロキシにデバイスエージェン トを転送する. デバイスエージェントはデバイスプロキシがデ バイスと通信するために必要なコード と GUI を生成するため の GUI スペック， デバイスのコンポジションを決定するコン ポジションスペックを含んでいる. コンポジションスペックは デバイス間の接続を制御することにより, 複数のデバイスを 1 つのデバイスであるかのように見せることを可能とする. デバ イス管理サーバがコンポジションスペックを受け取るとコンポ ジットデバイスプロキシを生成する. コンポジットデバイスプ ロキシはコンポジションスペックに従いデバイスプロキシの接 続を行う. ここで言う接続とは , コントローラにより生成され たイベントをど のプロキシデバイスのイベントに配送するか を決定することである. 現在の我々の実装では移動エージェン トしてお茶の水大で開発された MobileSpace [10] を用いてい る. また, イベント 配送のメカニズムとし ては JavaBeans を 用いている . リモートコントローラもデバイスとし て同様の手順でプラ グ インされる. はじめに , リモートコントローラ上にはコント ロール可能なデバイスのリストが生成される. このリストは ユーザエージェントから送られてきたプリファレンスや現在の ユーザの位置などの環境情報を元にカスタマイズすることが可 能である. 例えば , ユーザの好みに応じて GUI を配置したり, ユーザが不必要な GUI 部品を表示しないことでユーザに応じ た制御が可能となる. また, ユーザの現在位置を用いて，ユー ザが現在いる部屋のデバイスのリストのみを生成して表示し たり, ユーザの向いている方向に存在するデバイスのリストの みを表示することが可能となる. GUI スペックをカスタマイ ズするための情報はコントローラを利用するユーザの情報を 管理するデータベースからパーソナルエージェントを転送す ることにより可能となる . パーソナルエージェントはユーザの 過去の履歴や現在位置など のユーザの現在の状況をモニタリ ングする手段を提供するのみではなく， ユーザのプ リファレ ンスなど も含んでいる. また, デバイスを制御するための GUI はデバイスエージェ ントにより GUI スペックとし てデ バイス管理サーバに 送ら れている. GUI スペックはパーソナルエージェントが持つ情 報を用いたカスタマイズにより変形され，コントローラに転 送され る. ユーザが GUI を制御することにより生成された イベントはプロキシデバイスに転送される. このイベントは， デバイス管理サーバが 持つコントローラプロキシにより受け 取られ JavaBeans のイベントに変換される. このイベントは JavaBeans のイベント配送機能を用いてデバイスプロキシに 配送される. 最終的に , デバイスプロキシはデバイスエージェ ント内のコード を用いてデバイスにコマンド を転送する. 我々 のフレームワークではデバイス管理サーバは 1 つのアプリケー ションとして実現される. そのため, イベント配送のメカニズ ムとして JavaBeans を用いることが可能であり, 複雑な分散 イベント管理が不要なため実装が大変容易となる . 4 リモート コント ローラ 本節では，我々のフレ ームワークがどのようにし てリモー トコントローラを扱うかに関して述べる . 我々のフレ ームワー クでは PDA など のタッチパネルを持ったデバイスを用いるこ とを前提としているが , 携帯電話などのそれ以外のデバイスを 用いることも可能である. また，表示デバイスを持たないもの をコントローラとして用いることも可能である. 4.1 GUI スペック デバイスエージェントは各デバイスの制御方法を記述したド キュメントである GUI スペックをデバイス管理サーバに転送 する。GUI スペックは，ディスプレイに表示すべき GUI パー ツと， パーツを操作した場合に発生するイベントに関して記 述されている．PDA などのデバイスは GUI スペックを受ける ことでコントローラとして用いることが可能となる. GUI パー ツの操作により発生したイベントはパケットにパックされデ バイス管理サーバが持つコントローラプロキシに転送される。 コントローラプロキシは受け取ったイベントを JavaBeans の イベントに変換してデバイスプロキシに配送する . また， デ バイスがコンポジションされる場合は, 複数のデバイスの GUI スペックが合成される. この場合は，これらのデバイスを統合 するデバイスが持つ GUI スペックに従い合成するか，すべて の GUI スペックをマージしたものを新しい GUI スペックと するかの戦略により新しい GUI スペックを生成する. 現在の 実装では GUI スペックを記述するための言語として XML の 拡張言語である BML(Beans Markup Language)[3] を用いて いる。 4.2 GUI のパーソナライゼーション はじめにコントローラが接続されたとき , 現在コントロール 可能なデバイスのリストが表示される. ユーザはこれらのリス トから利用したいデバイスを選択すると，ターゲットデバイ スを制御するための GUI が表示される。制御可能なデバイス のリストはデバイス管理サーバが自動的に GUI スペックを生 成し，コントローラに転送する．ここで生成されるリストは， パーソナルエージェントから得られたユーザの位置や状況に よりフィルタリングされ , 行動履歴を用いてリストの順番が並 べ替えられる. これを実現するためには, ユーザの位置情報だ けではなく各デバイスが置かれている位置に関する情報も必 要である. また, 各デバイスを制御するための GUI スペックを各ユー ザの好みに応じて変更することも可能である. このため，パー ソナルエージェントが管理するユーザの履歴や好みを用いる. GUI スペックの各パーツは属性を持ち, その属性とユーザの 好みから表示する GUI スペックを決定する. 例えば， GUI パーツの属性がオプショナルである場合は通常は表示しない． また, ユーザの履歴を用いて全く利用されていない GUI パー ツを表示しないようにする. 4.3 明示的コント ロール 我々のフレームワークでは, 様々なデバイスをコントローラ として用いることが可能である. 例えば ， カメラに接続され たジェスチャ認識ソフトウエアをコントローラとし て用いる ことも可能である．この場合は, ユーザが明示的にコントロー ラプロキシを生成する必要がある． この場合, コントローラ プロキシは，ジェスチャ認識アプリケーションの結果をイベン トに変換し，デバイスプロキシに配送する．現状では， コン トローラプロキシの生成はユーザの責任であるが， 将来的に は GUI スペックとして記述可能とする予定である. これによ り， ユーザはプログラムを記述しなくても様々なデバイスを 用いたコントロールを容易に実現することが可能である． 4.4 デバイスの選択 4.2 節で述べたように , コントローラがデバイス管理サーバ に認識されたとき, デバイス管理サーバは利用可能なデバイス のリストを GUI スペックとして生成し，コントローラに転送 する. この場合は， コンポジットされたデバイスのリストのみ が表示される． これらのリストの表示法はデバイス管理サー バのマネジ メントとして大変重要なものである． 例えば ， は じめに，デバイスのカテゴ リや部屋のリストを表示すること によりユーザが操作したいデバイスを容易に見つけることが 可能となる. 現状では , ユーザがデバイスをコンポジションする場合はコ ンポジションスペックをユーザが記述する必要がある. 将来的 には， コントローラ上に利用可能なデバイスをビジュアルに 表示し 、それらの接続を指定するだけでコンポジションスペッ クが生成されるようにする予定である。 5 デバイスのコンポジション 本節ではデバイスのコンポジションについて説明する. 我々 のフレームワークでは，各デバイスは単機能をを提供し，テレ ビやビデオなどのデバイスはコンポジットデバイスとして定義 される．つまり，テレビはチューナ， アンプ，スピーカ, ディ スプレ イデバイスを接続したコンポジ ットデバイスを 1 つの デバイスとして扱うことを可能としたものと考えることがで きる . 我々のフレ ームワークではこれだけでなく， 様々なデ バイスを接続することが可能である．ネットワークにつながっ ている複数の情報家電のデバイスを組み合わせることにより 機能拡張を行ったり，まったく新しい機能を持った家電として 使用できる可能性がある. 5.1 コンポジションの方式 我々のフレームワークでは，現在，3 つのコンポジションの 方式を提供している． 1 番目の方式は，コンポジションスペッ クを現在利用な可能なデバイスのリストから自動生成する方 法である． 2 番目の方法は，デバイスがコンポジションスペッ クをデバイス管理サーバに提供する方法である． 3 番目の方 法は，ユーザがデバイス管理サーバにコンポジションスペック を提供する方法である． 5.3.1 自動コンポジション あらかじめユーザーやデバイスがコンポジションについて プリファレンスを持っていなくとも, 各デバイスの持つ機能や デフォルトのポリシに従って自動的にコンポジションを行う. 例えば , CD デバイスのようなオーディオ出力を持つデバイス とアンプデバイスのようなオーディオ入力を持つデバイスを プラグ インすることで自動的に音楽を流す準備が整う. 当然, ユーザーやデバイスが最初から持つコンフィグレーションに より抑制することも可能である . コンポジションスペック コンポジションスペックはコントローラプロキシが生成し たイベントを複数のデバイスプロキシがエキスポート するイ ベントにマッピング するための仕様を記述したド キュ メント である．我々のフレ ームワークでは JavaBeans を用いてイベ ントの配送をおこなうことができるので，コンポジションス ペックとし て BML を用いる．コンポジションスペック内に は， Beans の接続方法が BML 言語を用いて記述されている． デバイス管理サーバはコンポジションスペックを受け取る とコンポジットデバイスプロキシを生成する．コンポジットデ バイスプロキシは結合されている各デバイスの GUI スペック を集めてマージすることによりコンポジットデバイスの GUI スペックを生成し，コントローラに転送する． 5.2 5.3 イベント イベントの配送はデバイスプロキシを実現する Beans とコ ントローラプロキシを接続することにより実現される．実際 に Beans を接続する際問題となるのは， Beans の名前付けを ど のようにおこなうかである．名前の抽象度を高くすること により，利用可能なデバイスを用いたデバイスを生成すること が可能となる．例えば， PC に接続されたチューナボード と ネットワーク上に接続されたデ ィスプレ イとスピーカを接続 することによりアド ホックなテレビデバイスを生成すること が可能である． この場合は，各デバイスの名前を抽象的に記 述し，それらの名前を用いてコンポポジションスペックを記述 することにより実現される．また，特定のデバイスを指定す る抽象度の低い名前を用いることにより通常のテレビデバイ スを実現することができる．このようなメカニズムを実現す るためには，現在の実装で用いている Java Beans の明示的な 結合法を Jini の Lookup サービスのようなサービスの内容で 結合できるものに変更する必要がある． 1 つのイベントが複数のデバイスを同時に制御する場合も存 在する． 例えば ，複数のアンプのボリュームを一括操作する 場合や装置の ON/OFF, メディアの再生のスタート・ストップ などを行う場合， GUI により生成されたイベントを同時に複 数のデバイスに配送する必要がある．この場合，イベントの配 送順序が重要となる場合もある．現在の実装では，JavaBeans を用いているためイベントの配送がど のような順番で行われ るかに 関して議論することはできない．イベントをど のよう な順序でデバイスプロキシに配送するかなど のイベント配送 のポリシを今後検討する必要がある． 5.3.2 デバイスによるコンポジション デバイスがプラグインの時点からデフォルトのコンポジショ ンの設定を保持していて , その設定に従い自動的にコンポジ ションして一つの機器とし て振舞うことを可能とする. 例え ば，TV のようにアンプ , チューナー, ディスプレイといった複 数のデバイスが 1 つのケースに入っているとする. この時, TV としてコンポジションをおこなうためのコンフィグレーション がデバイスエージェントに含まれていればプラグ イン時に自 動的に TV としてコンポジションが行われる. 5.3.3 明示的コンポジション ユーザが既存のデバイスから新しい家電機器を生成したり， 新しい機能を持ったデバイスを既存のデバイスに追加するこ とにより拡張したり，ネットワークに接続されたデバイスの アド ホックなコンポジションを行ったりする場合は，ユーザが 明示的にデバイスの結合法を指定する必要がある．その場合， ユーザが明示的にコンポジションスペックを記述して，デバイ ス管理サーバに渡す． 6 システムの動作例 本節では , 我々のフレ ームワークの利用例に関して述べる . はじめの例は, テレビデバイスが簡単なデバイスのコンポジ ションにより構成されることを示す. 次の例では, ビデオとテ レビデバイスのコンポジションとユーザインタフェースのカス タマイゼーションがどのようにおこなわれるかを示す. 最後の 例は, ビデオを会議システムデバイスがユーザの近くに存在す るデバイスのアド ホックなコンポジションにより構築される ことを示す. また, この例では, PDA など のコントローラ以外 のデバイスをコントローラとして利用するための方法を示す. 6.1 テレビの例 ここでは, 図 3 で示すように複数デバイスが暗黙的コンポ ジションの手続きにより各デバイスがコンポジットされテレ ビが構築される例を説明する. 最初に各デバイスはネットワー クに接続されるとデバイス管理サーバーを探しサーバーにプ ラグ イン要求を出す. プラグ インされると, デバイス管理サー User agent User agent comosite device proxy comosite device proxy VCR device agent Tuner VCR device agent Quality control Remote Controller audio stream Amp Display Display device proxy device agent Remote Controller video stream Amp TV Converter Converter Tuner channel channel volume volume 図 3: テレビの構成 バー内では各デバイスのデバイスプロキシが設置される. デバ イスエージェントを持っているデバイスはデバイスプロキシ にエージェントを送り出す. エージェントの持つ情報に従いデ バイスプロキシが機能拡張されインタフェースが追加される. この例では，仮想的なテレビデバイスが存在し , テレビデバイ スエージェントに含まれるテレビとしてのコンポジションス ペックをもとにコンポジションが行われ , その結果, テレビコ ンポジットデバイスプロキシが作成される. リモートコントローラもデバイスとしてプラグ インされる. リモートコントローラ上にはコントロール可能なデバイスの リストが表示される. ユーザーがコンポジット済のテレビデバ イスを利用することを選択することで， テレビ仮想デバイス のデバイスエージェントが持つ GUI スペックをコントローラ に送ることにより，テレビコントロール用の GUI がリモート コントローラーの画面に表示される. ユーザーがリモートコントローラに表示されている GUI を 操作するとリモートコントローラのデバイスプロキシに伝達 され , イベントとしてテレビコンポジットデバイスプロキシに 伝えられる. イベントを受け取ったコンポジットデバイスプロ キシはコンポジション情報に従い, イベントを各デバイスプロ キシにイベントを配送する. コンポジットデバイスプロキシ内でイベント配送を設定 , 更 に各デバイス間の実データ配送経路の設定が必要であれば 各 デバイスプロキシを通して設定を行う. 6.2 ユーザーインターフェースのコンポジシ ョンの例 図 4: ユーザーインターフェースのコンポジションの例 Server User agent comosite device proxy Motion Detector1 TV1 Motion Detector2 Video Camera1 User A Network Video Camera2 TV2 User B 図 5: ビデオ会議システムの例 この例は，デバイスの自動コンポジションの例を示してい る．テレビ録画の場合，ユーザはコントローラからビデオデバ イスとテレビデバイスの接続を指定する．この場合，ビデオデ バイスとテレビデバイスの持つ各コンポーネントデバイスの I/O ポートをチェックし，チューナと VCR デバイスが接続さ れる．そして，これら 2 つのコンポーネントデバイスの GUI スペックが 1 つの GUI スペックとして統合されコントローラ に送られる． 6.3 図 4 の例では 6.1 節のテレビに加えて, ビデオデバイスが加 わり, ユーザーがテレビと組み合わせて利用する場合を想定し たものである. 各デバイスがプラグ インされるまでは前節と同 じである. ユーザーがビデオを利用するために , ビデオデバイ スを含んだコンポジションをリモートコントローラーの GUI で選択, 指示することでビデオで再生されたビデオストリーム がディスプレイデバイスへ, オーディオストリームがアンプデ バイスへ送られるように設定される. また, チューナーデバイ スから取り込んだ 信号をビデオデバイスに送ることで録画も 可能となる. またリモートコントローラーに表示する GUI に はテレビコントロール用のインターフェースにビデオコント ロール用インターフェースが追加配置される. comosite device proxy ビデオ会議システムの例 図 5 では, 本フレ ームワークを利用したテレビネットワー ク会議システムを表している . ユーザ A, ユーザ B のそれぞ れの近くに テレビデバイスとビデオカメラデバイスが存在す ることを仮定する. コンポジションスペックには，ユーザ A に近いカメラデバイスとユーザ B に近いデ ィスプレ イデバイ ス，ユーザ A に近いディスプレイデバイスとユーザ B に近い カメラデバイスを接続するように記述されている．これによ り， アド ホックなテレビ会議システムを構築することが可能 となる．更に , 例えば 写っている人物の動作を検知できる像処 理デバイスをプラグ インする．ここで，このデバイスの検出 結果をイベントに変換するデバイスプロキシを記述する．こ のプロキシは，画像処理アプ リケーションをネットワーク上 にプラグ イン（ネットワーク上でアプ リケーションを起動）し たときに生成される．さらに，コンポジションスペックを記述 することにより画像処理デバイスプロキシが生成したイベン トをテレビ会議デバイスプロキシに配送するためのコンポジッ トプロキシが生成される．これにより，ユーザーが手を振るの を検知すると, 画像処理デバイスプロキシを通して画像処理デ バイスプロキシに 特定のジェスチャを検知したというイベン トが配送される. このデバイスプロキシは発生したイベントを コンポジットプロキシを経由してテレビ会議デバイスエージェ ントに配送する． 以上の例のように，我々のフレ ームワークを用いることに より，様々なデバイスをアド ホックに結合したり，いろいろな デバイスをコントローラとして用いることが可能かことが 明 らかである． 7 議論と今後の課題 本節では , 我々のアーキテクチャと HAVi との比較をおこ なったあと , 我々のフレ ームワークの今後の課題に関して述 べる. 我々のフレ ームワークは, 各デバイスのコンポジションを柔 軟におこなうことが可能である. つまり, HAVi では, デバイス がもつ機能間の接続を変更したり, 異なるデバイスが持つ機能 間を接続することはできない . そのため, 既存のデバイスを新 たなサード パティのデバイスの機能を用いて拡張したり, 既存 のデバイスをアド ホックに接続することにより新しいデバイ スを生成したりすることは困難である. しかし , 我々のフレ ー ムワークでは , ユーザがコンポジションスペックを記述するこ とによりテレビデバイスのチューナとアンプの間に別なデバ イスが持つ音声処理モジュールを挿入することが可能である. また, ユーザの近くに存在するカメラやディスプレイを用いる ことでアド ホックなテレビ会議システムを構築することが 可 能である. また, 我々が提案するフレ ームワークでは，コントロールの 方法をカスタマイズしたり, ユーザが持っている特殊なコント ローラを用いてデバイスを制御することも可能である . カスタ マイズを実現するため , ユーザの好みや行動の履歴を用いたり, 位置情報やユーザの状況を用いることでコントロール可能なデ バイスをフィルタリングすることも可能である. 現在の HAVi では, このような柔軟なコントロールの方法を提供することは 困難である . また, HAVi では, コントローラが IEEE1394 に接続された デバイスやそのデバイスを制御するためのリモコンを用いて しか制御することができない . そのため, リモコンの制御に関 しては個々のデバイス依存であるため我々のフレ ームワーク が提供するような統一的な管理を提供することは困難である. 次に , 現状の我々のフレームワークの問題点に関して述べる. はじめの問題点は, どのようにして離れた位置にあるデバイス を制御するかである . つまり, 外出先から家庭内のテレビを制 御したりすることをいかにに可能にするかである . また, 複数 ユーザが異なるリモコンを用いて同一のデバイスを制御する ときど のようにし て排他制御をおこなうかに関しても検討す る必要がある . 次の問題点は GUI スペックとコンポジションスペックの記 述の問題である. コンポジションスペックの問題は , デバイス をど のような抽象度をもった名前を用いて記述するかがシス テムの拡張性を大きく決定することである. つまり, 抽象度が 高い名前を用いた場合は , アド ホックなデバイスの接続を容易 に実現するが , 特定のデバイス間の接続を明示的に指定するこ とは難しい. また, GUI スペックに関しては, GUI パーツの表 示の仕方やどの GUI パーツがユーザに興味があるかをど のよ うに指定するかなどに関して検討する必要がある. また，システム全体のマネジ メントをシステムのロジック と独立に可能にすることでプログラムを変更せずに様々なポ リシを変更することが可能となる．我々は，システム全体を管 理するためのパラ メータを MIB として表現し ，SNMP を用 いて制御することを検討している．これにより，自動的に管理 できない部分をシステム管理者が明示的に制御する必要があ る．ただし ，情報家電として用いるため，極力人手による管理 を避けるようにすべきである． 最後の問題点は , デバイス間の接続の指定をど のようにおこ なうかに関してである. つまり, 各デバイスはが持つ A/V デー タ用のポートをどのように接続し , それらのデバイスをど のよ うに同時に制御するかに 関して検討する必要がある. 将来的 には, MIT の VuSystem[11] や JAIST のマルチメディアツー ルキット [12] で実現されているように，各機能間の接続を明 示的に接続し ストリームを定義することを可能とする必要が ある. ストリームを定義可能にすることにより QOS 制御やメ ディア間同期などの高度なマルチ メディアデータの処理をお こなうことが可能となる. 8 まとめ 本論文では, 柔軟な情報家電のためのソフトウエアアーキテ クチャに関して提案した. 本アーキテクチャでは，1 つのリモ コンを用いて様々なデバイスが制御可能なこと, 複数のデバイ スを 1 つのデバイスとして扱うことが 可能なこと, デバイス のコントロールの方法をユーザの好みや状況に応じてパーソ ナライズ可能なことを示した．また, 3 つの例を用いて我々の フレ ームワークの柔軟性を示した. 現在, 我々が本論文で提案 したフレ ームワークを Java 言語を用いて実装中である. また, 我々のフレ ームワークを HAVi 上のアプ リケーションとし て 構築することを検討中である. 参考文献 [1] Tristan Richardson, Quentin Staord-Fraser, Kenneth R. Wood, Andy Hopper. Virtual Network Computing IEEE Internet Computing, VOl.2, No.1. Jan/Feb 1998, pp.33-38. [2] Andy Harter, Andy Hopper. A Distributed Location System for the Active OÆce. IEEE Network, Vol.8, No.1, January 1994 [3] Beans Markup Language(BML) http://www.alphaWorks.ibm.com/formula/BML [4] Andy Ward, Alan Jones, Andy Hopper. A New Location Technique for the Active OÆce. IEEE Personal Communications, Vol.4, No.5, October 1997, pp.42-47. [5] Jim Waldo. The Jini Architecture for Network-centric Computing. Communications of the ACM, pages 76-82, July 1999. [6] Sun Microsystems. Jini http://www.jini.org/ [7] HAVi (Home Audio/Visual Interoperability) http://www.havi.org/ [8] UPnP(Universal Plug and Play) http://www.upnp.org/ [9] Steven McCanne et al. Toward a Comon Infrastructure for Multimedia-Networking Middleware. Proc. 7th Intl. Workshop on Network and Oerating Systems Support for Digital Audio and Video (NOSSDAV'97), May 1997. [10] 佐藤一朗, 高橋美奈子, 棚橋杏子, 吉野裕子: モバイルエージェント の階 層的な構成と移動, 日本ソフトウェア科学会全国大会, 9 月, 1998. [11] C.J. Lindblad and D.L. Tennenhouse. \The VuSystem: A Programming System for Compute-Intensive Multimedia", IEEE Journal of Selected Areas in Communications, 1996. [12] Tatsuo Nakajima, \A Toolkit for building Continuous Media Applications". IEEE International Workshop on Real-Time Computing, Systems and Applications(RTCSA'97)