=========================================================================== セッションD1 タイトル：新規提案 =========================================================================== ＝＝＝＝＝ 1．拡張現実環境を実現するための分散マルチメディアミドルウェア 　倉橋 誠○，徳永 英治，根本 将寛，Andrej van der Zee，中島 達夫（早稲田大学） 　（○：発表者） 発表内容： 我々は将来のコンピューティング環境としてユビキタス環境を想定している。 この環境では小型ネットワーク化されたコンピュータが我々の生活のどこに でも存在する。 実生活のあらゆるものがインテリジェントになり、フィジカル世界とサイバー 世界の融合し、コンピュータは空気のような存在になる。このような環境では 組込み機器もより複雑になる。 我々は拡張現実に注目する。これは人が見ている現実世界の映像にコンピュー タが情報を付加するものである。例えば、ユーザがヘッドマウントディスプレ イを装着してその画面に情報を提供する。 拡張現実の概念はあくまで現実の拡張であり、ユーザにコンピュータを意識さ せないものである。例として、名札に見立てたタグ上にコンピュータで情報を 描画するものがある。まずコンピュータが現実世界を認識するためにビジュア ルのタグを認識し、その後そこへ情報を描画する。 拡張現実により実世界とサイバー世界が融合する。コンピュータが拡張した現 　・実世界をユーザが意識させずに利用するためのインターフェースが必要で 　　ある。 　・拡張現実のソフトウェアはやや複雑になる。 　・実世界を認識するデバイスへの対応なども必要である。 　・従来のツールキットはユビキタス環境に向いていない。 　・ユビキタスコンピューティング環境ではアプリケーションは分散しざるを得 　　ない。 　　　東京なら東京で、大阪なら大阪でというように、場所に依存した処理が 　　　必要となる。 アプリケーションはコンテキストに依存する。 アプリケーションが実世界の状況を把握してコンテキストに応じた動作をする。 拡張現実環境を実現するための分散マルチメディアミドルウェアを目指す。 設計として、 　マルチメディアコンポーネント層では部品を組み立てる。 　分散環境でのプログラミングを簡単にするコンポーネントである。 　拡張現実環境のための機能を持つオブジェクトを組み立てている。 　マイクロコンポーネントとは再利用可能な最小単位である。 本システムではCORBAをベースにした分散システムを構築する。言語やOSには依 存しない。特徴は動的なオブジェクトとの洗濯とコンテキストポリシーである。 現状はマルチメディアコンポーネント部分を実装しており、基本的な部分を実 装している。拡張現実環境のための部品を実装中である。 今後の課題・検討： 　・分散マルチメディアコンポーネント内を細分化したコンポーネント化の方法 　・分散メディアコンポーネントのインタフェース、 　・動的QoS制御への対応、 　・Streamの同期、 　・具体的な拡張現実アプリケーションの開発である。 まとめ： 　・ユビキタス環境でのアプリケーション構築に対応するシステムである。 　・拡張現実環境を実現する機能をもつ。 　・柔軟性や再利用性を提供するマルチメディアコンポーネント、 　・コンテキスト依存に対応したシステムを予定している。 質疑応答 Ａ氏 Q:コンテキストポリシーとは一般的な言葉なのか？それともそちらで定義した 　ものか？ A:一般的な言葉です。 Q:ユビキタス環境の話しでは一般的であると考えてよいのか？ A:はい。 Ｂ氏 Q:こういうシステムでノイズ的な情報、欲しいと思っている以外の情報を大量 　に提供されると自分の欲しい情報を見つけられないことが考えられるがどう 　するのか？ 　A:不要な情報を取り込んでしまうということか？ 　Q:今何に注目しているのかが分かるのかということ。 A:そもそもコンテキスト情報をどのようにデータとして蓄えるかはまだまだ課 　題である。如何に不要な情報を捨てるかが課題。コンテキスト情報をどのよ 　うに整理するかはまだ始まったばかりの課題である。 Ｃ氏 Q:現在どういう環境でやっているのか？将来的にはどういうものを想定してや 　っているのか？ A:開発は普通のLinuxマシン。カメラを接続しXウィンドウとLAN環境で行って 　いる。 Q:つまりLinuxにCORBAを入れればどういうマシンでも動くということか？ 　どういうスペックあれば動くのか？ A:基本的にはそうだが、何をやるかによってスペックは変わってくる。 　用途に応じてということになる。 Q:HMD以外のデバイスを使ってはやらないのか？実生活では邪魔になると考え 　られるが。 A:確かにHMDを付けて生活するのは辛いので、他のものも考えていきたい。 　例えば、PDAの画面に移してやるということでやったほうが現実的であると 　思う。 ＝＝＝＝＝ 2．SystemMorph:Functionality Morphing 　林田 隆則○，數 勇介，村上 和彰（九州大学） 　（○：発表者） 発表内容： システムモーフとは対象プログラムの実行時にプロファイル情報に基づいてそ の実行中にソフトウェア命令セットなどを変更して消費エネルギーを最適化す る技術である。 構成する技術は、 　オンラインプロファイリング技術、 　適応型動的HW/ISA/SW強調最適化技術、 　HW/ISA/SWの動的再構成技術 である。 ファンクショナリティモーフィングに着目する。 Hot Instraction Sequence(HIS)を用いる。 　高頻度に実行される命令列、 　オブジェクトコード上での列、 　命令種別のみに着目、 このような命令列をプログラムの実行時に検出するプロファイラ。 プロファイラモデルとして、サンプリング型とイベントカウント型を使用。 サンプリング型は、周期サンプリングとランダムサンプリングにより行う。 カウント機能はない。イベントカウント型は１命令実行ごとに直前に実行した N命令をテーブルに登録し出現回数をカウントする。 評価実験を行った。 　評価指標はHitrateとNoiserate。 　JPEGによる実験。 　Hitrateはどのモデルでもほぼ同様。 　10％以内でピークを迎えその後減少。 　イベントカウンティング型は閾値を設けている分、ノイズに強い。 　考察として、サンプリング型でもHISを含む集合を得ることは可能。 　今回やったのではイベントカウンティング型の方が良い。 今後の課題： 　・システムモーフが有効なアプリケーションの模索、 　・オンラインプロファイリング手法の詳細な評価、 　・HW再構成技術と強調したプロファイリング、 やることは盛りだくさんである。 質疑応答： Ａ氏 Q:オンラインプロファイリングとオフラインとの比較をするとどうなのか？ 　今回はJPEGなのでアプリケーションによって変わりそうなので次回はどうい 　うものなのか例をあげて頂きたい。 Q:システムが実行中なら変えられないのではないか？ A:CPUが遊んでいる9割の間にやる。 　実行中に変えるには止めざるを得ない。 Ｂ氏 Q:組込みシステムではアプリケーションはスタティックである。それならオン 　ラインなくてもいいのではないか？ A:携帯のJAVAなどではアプリケーションごと飛んでくるのでそういうこ時に使 　えればよい。 Ｃ氏 Q:プロファイリングをダイナミックにやるということだが、ハード的にプロフ 　ァイリングを取るのか？ A:プロファイラは出来るだけハードに廻したい。 Ｄ氏 Q:リコンフィギュアブルな部分はコプロセッサか？ A:今はファンクションユニット。 Ｅ氏 Q:ダイナミックに取らなくてもいいのではないか？ A:スタティックが悪いわけでなく、ダイナミックにやらなければ分からない情 　報があるのではなかろうかということでやっている。 　Q:例えばどういうものか？ 　A:まだ有効なアプリケーションが見つかっていないので例はあげずらい。 　　JAVAアクセラレータなどが有効なのではないかと考える。 Ｆ氏 Q:プロファイラはコストがかかると思うが常に動かしているのか？学習してや 　るのか？ A:今のところは常に動いている。ずっと走っている必要はある程度いけばない。 Ａ氏 Q:ハードウェアだけで実現されているという印象である。ソフト屋さん、コン 　パイラ屋さんに望むことは何かあるか？ A:今のコンパイラによる最適化でなく、このシステムに向いた最適化してくれ 　るものがあればよいのではないか。 Ｂ氏 Q:対象のプロセッサは？ A:今のところ特定はしていない。 Q:物としてはいつ頃に？ A:今年度の末くらいには何かしらやりたい。 ＝＝＝＝＝ 3．抽象データ型を利用した階層化データフロー設計環境 　大森 洋一○，三宮 秀次（高知工科大学） 　（○：発表者） 発表内容： 抽象データ型を利用した階層化データフロー設計環境について。または、なぜ データフローは普及しないか？ データフローシステムの利点は何か？ 　設計者にとっては可読性が高いことによるモデルの一貫性。 　プログラム自体は並列性の明示により部品化が容易。 　ハードウェアにおいては消費電力が小さいし大域的なクロックが不要。 　SoCやコデザイン向きである。 データフローの弱点を考える。 　設計者はデータフローの考え方に慣れていないということ。 　ならば、使いやすい設計環境を提供すればよい。 　プログラムは記述にアセンブラを用いるなど低レベル。 なので、高レベルの記法をサポートする。ハードウェアの側ではトークンにタ グが必要であり、マッチング用のハードウェアが必要。しかし、最近は集積度 の向上で問題ではないのではないか。使いやすいプログラミング環境を準備す ることが必要である。 オブジェクト指向プログラミングを導入する。 当初の目的として、設計部品のライブラリ化、設計の正当性検証である。 実際は特定用途向けハードウェア設計で、ハードウェアに依存したプログラム となる。これではまずいのでハードウェア独立性の確保が必要となる。 Fundamental Instruction Set(FIS)を導入し、基本的な命令セットを用意する。 これにはデータフローに特化した命令も用意されている。 FISの評価を行った。 　DCT，HASH，IPHeaderについて評価した。 　その結果、命令は20から25もあれば十分であることが判明した。 　また、データ構造定義もハードウェアから分離すべきである。 データ構造記述の高度化。 　仮想データ駆動システムAPI、抽象データ型セットADS、仮想命令セットFISを 　実プロセッサの命令列に変換する。 フレームワークの整理、 基本ライブラリの整備、 抽象データ型記法の定義が必要である。 プログラムの枠組みとしては、 　データフロー演算を型変換とみなし、型を2種類に分類する。 　トークンは比較的単純かつ静的なデータ構造とする。 　入力及び出力は複雑な型とする。 標準データ構造の定義は、小型組込みシステムを意識してあるため、ゆるい定 義になっている。 例えば： 　抽象データ型の実装。 　モジュールを利用してデータ構造と手続きを一本化する。 　名前空間やアクセスの保護機能はない。 　設計ツールで検証する必要がある。 　モジュールは生で識別し、実行前に展開する。 　似たようなモジュールがたくさん出来てしまう。 　特徴的なパラメータをプロパティとしてまとめる。 配列のアクセスパターンは、命令によりデータアクセスパターンを選択する。 アクセスパターンやブロックの大きさはプロパティとして指定する。 まとめ： データフローシステムにおけるデータ構造記述の高度化により、いくつかの機 能が実現された。 今後の課題： 　Eclipseへの移植、 　モジュールを展開しない実装の検討、 　実プロセッサへのマッピングアルゴリズム など 質疑応答： Ａ氏 Q:普及しないのはなぜか？データフローのコンパイラがあれば入り口としては 　敷居が低くなる気がするがそれは難しいのか？ A:それはもう作っている。しかしシンタックスがCであるという以上のものでは 　ない。中でモジュールを呼んでいるだけなので効率的ではない。 Ｂ氏 Q:データフローがだめな理由は山のようにある。しかし全然使い物にならない 　わけではない。応用に限った場合には使えると思うがどのようなものを考え 　ているのか？ A:話は信号処理を中心に考えている。当面のデータフローが生きる道はこれで 　はないか。