5C 分科会セッション　「分散組込みシステムのための技術」参加者は、全体の1/3〜1/4の34名だった。いろいろな方向に行きつ戻りつした議論の内容を敢えて分類してみると、下記のようになった。 1.分散組込みシステムとは? 　1.1. そのアプリケーション　1.2. そのために必要なもの 2.標準化について　2.1. CORBA 　2.2. Java 　2.3. HAVi 　2.4. Jini 　2.5. UPnP 　2.6. 組み込みLinux 　2.7. 標準化自体について 3. 設計の観点から　3.1. どう設計するか　3.2. ミドルウェア　3.3. どう記述するか　3.4. リアルタイム性と信頼性　3.5. 増殖するシステム、ダイナミックな環境への対応以下、それぞれについて、意見を列挙した。 1.分散組み込みシステムとは? 1.1.そのアプリケーション・インターネットと組み込み技術が分散組み込みのキー。　あらゆるサービスとデバイスを接続できる。　(需要)いつでもどこでも組み込みシステムは情報へのアクセスを可能にする。　(供給)さまざまな場所からの情報をサービスとして提供する(個人がサーバーとなる)。・現実問題としても単体で機能する機器というのは少なくなってきている。　インターネットコンポーネントの一部として、動作するものが多くなってきている。・一度した操作を記録して再現するような仕組みなども、有効になるのではないか。・何でもかんでも家電をネットワーク化する必要があるのか？　帰りが遅くなるから予約時間を変えるなど。・JavaやCORBAがなぜ出てきたか。資産を流用したい。標準を使いたい。　アプリケーションの多様化がますます進んでるから標準化したのに、　手段の目的化が起こり始めているのではないか？　Javaがあるから何をするかを考えるのは本末転倒ではないだろうか。　現場で実際に必要としているものができているのか？・消費者の視点で組み込みシステムがどう必要であるかを考えることも大事である。 1.2. そのために必要なもの・さまざまな小さなネットワークがインターネットを介して相互に接続する　環境が用意されると考えられる。・どこでも使えるソフトウェア。可搬性があり汎用性のあるソフトウェア。・さまざまなミドルウェアを介して実現する。CORBA,JAVA,HAVi,Jini,UPnPなど。・そのほかにもマルチメディアプレゼンテーションのための標準、・インターネット上での通信のための標準、ブルートゥースなどの無線通信プロトコル。・サービスがどこにあるのかを探すのが重要な概念になるのでは。ネームサービス。　携帯端末とサーバー間でサービスをする場合、サービスのコンポーネントは、　ネットワーク上に分散して存在していてもよい。・サービスをどう分解し、どう統合するのかが問題。 2.標準化について 2.1. CORBA ・アプリケーションごとにOSやシステムを用意できる。RT、フォルトトレラント、・コンポーネントフレームワークなどの拡張が標準化されてる。・ベンダーに依存しない。・問題点はサイズが大きく、仕様が大きい。参考書が少ない。・課題としてはQoSに基づくコンフィギュレーションを動的に制御するなど。 2.2. Java ・JAVAは仮想マシンとAPIを利用してプラットフォームに依存しない。・オブジェクト指向でマルチスレッド、メモリ管理の自動化。・組み込みへの適用も行われている。・問題点は仮想マシンによる効率の低下と、高機能だったり特殊なハードウェアの利用が困難。・システム自体が巨大。慎重に書けばどこでも動くかも。・課題はよりフレキシブルなシステムを構築できる環境を用意する。・VMやAPIを設定できるようにする。 2.3. HAVi ・DCMを移動することでデバイス制御のプロトコルをあらかじめ知る必要がない。・バージョン変更が容易である。・IEEE1394に依存している。・仕様があいまいでオープンでない。・課題は他のデバイスとの接続など。・PCでプロトタイプを開発する。移植容易性のために、家電側にもLinuxを載せ　JavaVMを走らせてHAViのミドルウェアを用意すると便利。 2.4. Jini ・サーバー側はディレクトリに提供できるサービスを登録して、アプリケーションが、　そこに問い合わせることで実現する。・アプリケーションとサービスは相互に意識を払う必要が少ない。・問題点は集中ディレクトリサービス、AdHocなシステムでどう実現するかは難しい。・リースの管理の調整が必要（省エネルギー）定期的な通信が必要で、エネルギー効率が悪い。・実装がRMIに依存している。TCP/IPの上でしか使えない。・課題は分散ディレクトリサービス、コンテキストに依存したサービスの記述。 2.5. UPnP ・Jiniに近いシステムである。アプリケーションとサーバー間が、・HTTPに準拠したプロトコルになっている。・サービスをSOAPというプロトコルで呼べる。・XMLのテキストベースで書かれている。・問題点としてはIPでしか使えない。・XMLのパージングのオーバーヘッド。・効率が重要な場合は適さない。 2.6. 組み込みLinux ・システムのメモリフットプリントの減少、　アプリケーションやライブラリ。カーネルサイズ。　Xを組み込みで使うのか？　などアプリケーションの方が影響が大きい。・リアルタイム性のサポートがもっと必要。・組み込み向けの製品は多数リリースされている。一方リアルタイム拡張は、　製品レベルではまだ少ない。研究レベルのものが中心。・開発機器上で製品開発は本当に可能か？正確な機器のシミュレートができるか？・オープンソースの有効性は？・教育コストは減らせるのか？　例えば大学などではLinux系のOSを使うことが多い。そこから出てくる人材は、　Linuxを使わせれば教育コストは短くてすむか？ 2.7. 標準化自体について・様々にある標準をどのように統合するか。　HAViとIETF、JAVAとPOSIXとどちらがポータブルといえるのか。　CORBAを本当に組み込みに使っていくのか。・ディファクトスタンダードがあちこちで見られる現状で必ずしもよいもの　が勝つとはいえないのでは？技術よりビジネスが強いのではないか。・ディファクトスタンダードに対する一つの回答がオープンソースではないか。　ビジネスとして成立するかは別問題であるが。・ソースを公開しても読める人間が少ない。・標準化に使い手が入っていない。　様々なミドルウェアをどう組み合わせて使うとよいかなどもまったくわかっていない。　企業では余裕がないから、大学等が体系化を計ることも必要である。・標準化するのは前提に全員が同じ会話をするということがあるので、　変わったことをしたい場合を考えるのは意味が違うのでは？・標準化の世界と大学の研究が分離してしまっているのではないか？　ミドルウェアがあってそれをどう使われているかを研究することも重要。　新規性だけが研究に必要ではない。企業が出せないノウハウを論文にするのも、　大学の役目ではないか。・欠点を理解した上で標準化してしまうのは、会社の利益を守るため。　大学はそのような利害関係はないので、標準化に際しても公正な立場から　発言できるのではないか？　会社の力関係でよくない仕様でも標準化されてしまう場合がある。 3. 設計の観点から 3.1. どう設計するか・システム設計はAdHocなのかシステマチックなのか？　何かを決定するときに基準になる方針があるのか？　経験がものを言うこともあるが、最近は同じようなものを作ることが少ないので、　実際にはトライ&エラーに近いものがある。　はじめから最後まで一貫した方針をとることは難しい。　仕様が途中で変わることがあたりまえにあるので、逆に仕様を固め切ってしまうこともできない。・余裕を残した設計は理想ではあるが、非現実的？ケースツールなどの助けを借りる。・複雑なアプリケーションの開発にはミドルウェアが不可欠になっていく。　ミドルウェア毎の特性を評価する手間を考えても使ったほうがいいのか？　ミドルウェアをある程度評価した上で実際に選択して利用していく。 3.2. ミドルウェア・ストリーム管理のミドルウェアが存在しない。今後増えていくのに標準が存在しない。・様々なプラットフォームで動くミドルウェア、組み込みからサーバーへのアクセス、　などが増えると考えられるので、可能な限り同じ実装をするべき。・ひとつのミドルウェアですべてをサポートするべきなのか。　→既存のミドルウェアの有効性が十分に検証されていない。 3.3. どう記述するか・携帯にJavaのアプレットをダウンロードする場合など、無線特性を考慮した記述が必要になる。・ミドルウェアが相互に連接して作業するとメリットが多い。ではどうプログラムを書くのか？・適応性や拡張性を考慮する。具体的にはどういう技術で？　patternを利用する。reflectionを使う。80年代から研究レベルでは行われている。　システムが自分の状態を認識して動作する。いきあたりばったりでなく実現できる。・自己参照ミドルウェアなどの研究が進められている。　単純に作れば遅くなってしまうから、どう実用レベルに落とすか。　実行時コンパイル、partial evaluation cross-cutting concerns ・機能以外に考えなければいけないセキュリティーなどの問題がある。　複数の機能にまたがってこれらの要素が混入しプログラムがわかり難くなる。・security authentication、技術があるだけではだめ。JavaのPrivate変数などは、　外から見えなくて安全になる。タイムシステムを使って安全性を保証する考え方もある。・問題を記述するのが難しい。あるAPIがよいかどうかを判断する客観的な指標がない。 3.4. リアルタイム性と信頼性・例えば、組み込みLinuxを載せてJavaVMとミドルウェアを用意する。　もうひとつは組み込みRTOSを用意して、同じようなシステムを構築する。　家電の必要とするリアルタイム性を保証できるのか？・開発環境とは条件が違うのでテストが必要かも。・JavaにRT性を持たせてそこでミドルウェアを書けば、開発テスト環境でも、　正確なタイミング検証をできるのではないか？・組み込みの重大な問題は早く動くことよりも正確に終了を予測できること。　そこがあいまいだとトラブルが生じやすくなる。・ソフトの大きさとリアルタイム性が言われるが、コストの問題だけなら、　組み込みだからとサイズを限定する必要はないのではないか？　メモリなどは安くなっているのだから。・リアルタイム性も目的の機能を果たせるのならそれ以上のRT性は必要ないのではないか？・IPネットワークの上でサービスを提供することに対して、自律分散システムは、　整合性を保つためのトラフィックが増加しリアルタイム性も悪いので、　その上でリアルタイム性を満たすミドルウェアの開発は非現実的ではないか？　結局クライアントサーバーモデルにおちつくのではないか。・リモート制御においては応答速度も大事だが、確実性も大切ではないか？　例えば原子炉をインターネット経由で制御できるのか？・発電所内に限った信頼性の高いネットワークを経由してなら可能かもしれない。　TCPレベルでの信頼性しか保証できないが。　フォルトトレラントな要求を現在のシステムがどこまで受理できるか？　絶対大丈夫なシステムはまだない。IPのアサンプションを確立すればすむ問題なのか？・リアルタイム性と信頼性を両立する技術はまだないのではないか？　リアルタイム自体が信頼性を要求しているのだから、　本質的にはフォルトトレラントなシステムを構築できなければいけない。　IPで駄目かというと、一概には言えない。　全てIPで制御できればコストを下げられるかもしれない。　コストが問題になると既存のものをベースに開発する必要に迫られるが、　そこでどうするかという部分が確立していない。・SLAという考え方が出てきている。レベルが何段階あるかも重要。　契約の枠組みも難しいが、信頼性などの問題にある種の解を提供するのでは？ 3.5. 増殖するシステム、ダイナミックな環境への対応・ダイナミックな環境で何が使えるかというのは定義が難しい。　現在のシステムはほとんどが静的であるから、動的な環境を予測するのは不可能に近い。　環境を定義するだけでも難しい。・自分がすでに使った分だけでもパラメータとして持っておいたら有用では？　システム設計に際して要求から仕様が決まらないようにサービスのリストを持っていて、　どれを利用するのがいいかは簡単には決められない。・変わった機能を入れるために仕様が大きくなるのは問題。　コアを小さくして周辺で拡張していくのが重要。　パラメータで自動プログラミングするようなもので難しいから、　細かい仕様が増えていくのは避けられないと思う。・機能が拡張されるほど問題が大きくなっているが、コアだけをとって、　機能は選択できるようにしたものはないのか？　機能セットを小さくした仕様もあるが、多様なことができたほうがよいとの判断で、　どんどん大きくなっているのが現状である。　本質的に必要な機能かどうかを判断できなくなっているので、　結局全てを実装するしかなくなっている。・必要な機能だけを取り込める仕様があれば、　もっと使いやすくなる。そうした動きはないのか？　全ての機能が取捨選択できればCORBAはよい選択肢になりうる。　現実には機能を動的に変更できるソフトを作成する方法論がない。　結果的に大きなものになりやすい。・多様化と統合化という矛盾する流れがある。　仕様に拡張までにらんだフレームワークを用意すれば、　システム構築者は自分の環境に適した拡張を行ってシステムを作成できる。　大学側で枠組みを提供したら。・実装レベルで変わるだけでなく仕様レベルでもシステムは変わっていく。　それを踏まえて今見えてる問題だけでなく、この先違う問題が出ることを、　仕様の中に含められるようにする必要がある。・仕様というのは技術の話ではなくてビジネスモデルの話なので、　それを技術の側面からどれだけ論じてもまとまり切ることはない。　フレームワークを決めて柔軟性を残すことが精一杯の抵抗ではないか。 (5C以上)