セッション SB-7 組み込みシステム向けコンポーネント仕様を考える --------------------------------------------------------------------------- 大山さん 最初に,組み込みシステムのコンポーネントに何を期待するかについて議論してい きたい 大山さん 組み込みコンポーネントを組み合わせて組み込みソフトウェアを組み上げれば,生 産性が飛躍的に向上するのではないかという期待が強い.しかし,具体的に何を期 待するかがわからない.そもそも組み込みコンポーネントとは何かがわからない. 組み込みコンポーネントは幅広い概念であり,各個人で捉え方が異なる.そこが, 議論の白熱するところである. 大山さん 私の2年前の考えでは,ESC(組み込みコンポーネント)が中心にあり,C/C++,JAVA, CORBA, ECMA Script などがクライアントであり,既存のコンポーネントが API と して提供されている.提供されるコンポーネントとしては,GUI オブジェクトや ハ ードウェアコンポーネントがある. 大山さん 話は変わるが,ITRON 仕様に期待されていることは,ソフトウェア部品の標準化, 開発環境としてのインターフェースの標準化や,デバッガやGUI ライブラリの標準 化などがある.ソフトウェア部品の標準化はまさにコンポーネントであり,その他 のものもコンポーネントに関わるものがいくつもある.結果として,期待するもの 50% 以上はコンポーネントに関わるものであると感じる. 大山さん 組み込みコンポーネントで考えられている諸問題を概観すると,次のようになる. 1. 組み込みソフトウェアの複雑化,大規模化 2. ミドルウェアを部品として購入して組み込むことが多いが,ソフトウェアの費用  が高い 3. マルチプロセッサシステムが増加しているが,構成する手段が整っていない 大山さん 期待感はあるが,コンポーネントの定義が人によってまちまちであり,期待する役 割もさまざまである.非組み込み系では,考えも実際のコンポーネントもよく普及 している(CORBA CCM,GNU BONOBO, JavaBeans など). 非組み込み系でのコンポーネントの定義は次のようなものであると考えられる. ・あるサービスを提供し,独立して交換可能なソフトウェアの構成単位 ・インターフェースに適合し,それを実装するもの 大山さん ここで参加者の方に,コンポーネントにどんなことを期待するのか,また,どんな 問題があるか質問したい. 宿口さん どういう問題があるかという点では,業務内容によると思うが手っ取り早くシステ ムを開発したいが,デバイスが変わっても簡単に入れ替わって欲しい. 宿口さん システムの規模によって要求は変わるのではないか.組み込み屋はデバイスドライ バ屋と言うほど、組み込みソフトのほとんどがデバイスの制御ソフトである.しか し,そのときに作るものはシステムの規模によって変わる.ある会社では,デバイ スドライバを作る量は少なくてすむかもしれないし,ある会社ではほとんどデバイ スドライバを作らなければならないかもしれない.そうすると,アプリとコンポー ネントのインターフェースをどこに置くかを決めなければならない.したがって, インターフェースに適合させるというところが,組み込みシステムのコンポーネン トの最大の問題ではないか.非組み込み系でのコンポーネントのインターフェース は,各社の都合により決められてきた可能性がある.例えば,その会社のビジネス モデルによって,あるところより先には手を出して欲しくないために,そこにイン ターフェースを置いている. 高田先生 今はインターフェースという言葉が噛み合っていない気がする.どこまでがアプリ でどこまでがコンポーネントかということは特に考えなくても良いのでは.例えば, アプリがコンポーネントでもよい. 宿口さん インターフェースの部分がモジュールの切口である.したがって,まずはその切口 をどこにするかが問題になる. 高田先生 それは,IDL によって解決できる. 宿口さん 使う人によって,レイヤが違っていてそのレイヤが人によって違うことが問題であ る.使う側はレイヤをあらゆるところで定義しておいてもらわなければならない. 高田先生 それは必要なら定義すればよいのではないか. 宿口さん しかし,それでは数が増えすぎる.それらをすべて認めるのか,という話になる. また,やはり使う人ごとに異なるインターフェースが欲しいということになる. 高田先生 まだ噛み合っていない気がする.例えば,デバッガのインターフェースを標準化し ようといっているのではないのか. 宿口さん それは,コンポーネントのインターフェースとは違う話ではないか.ここでは, コンポーネントのインターフェースが問題である. 高田先生 まず,どんな規約みたいなものがあるのか,という話では. 宿口さん その規約というのが,組み込みシステムの業種に応じて欲しいものが違うのでは, ということでしょう. 高田先生 では,そのようなあらゆるインターフェースを作っていけばよいのでは. 宿口さん 作っていけばいいんですけども… 高田先生 やはり噛み合っていない気がする. A さん 高田先生のいうインターフェースは IDL を定義して,コンポーネントを開発する メカニズムを言っているのでは.宿口さんのいうインターフェースは,まさに, そのコンポーネントの持つ仕様や動作を言っているのでは.だから噛み合っていな いのでは. 高田先生 私もそのような気がして IDL という例えを出したのだが,まだ噛み合っていない. インターフェースを定義するのが IDL である. A さん もう一つ補足だが,高田先生はメタなものが必要だということを言っているが, 宿口さんはインターフェースがどうあるべきかを言っている.それで合っていま すか. 宿口さん そのようなイメージである. A さん ここで,どちらを議論するかを明確にしないと話が噛み合わないのでは.私が問題 として思っているのは宿口さんと同じ問題意識で,メタな話も大切だと思うが,具 体的にどうあるべきかを考えることが重要であると思う. 大山さん この WG の方向性としては高田先生のいうような方向であるが,なぜそのような方 向性であるかは,宿口さんのいうような問題であるような気がする.どこにインタ ーフェースを決めるか,という点. 宿口さん どこでインターフェースを決めるか,という問題だが,場合によって階層化する位 置が違うのではないかということ.この問題に対しては,WG では IDL を作ろうと いう答えを出したということでよいか.その流れがあるとして,私はどう(インタ フェースを)切らなければならないかが問題としてあると思う. 高田先生 これまで検討してきたことは,デバッガを作るガイドラインなどがある. 宿口さん IDL を使う方法ではなく,なぜ IDL を使う方向になったかという理由を説明して 頂きたい. 大山さん そこは,あまり深い議論があったわけではなく始まっているような気がする.確か に,インターフェースをどこで決めるかという問題があるが,まずそれを決めるメ タなルールをまず作ろうということからであった. A さん IDL は既存のものがあると思うが,この WG で新たに作ろうとした背景はあるのか. 高田さん それについてはまた後の方で話すのがよいと思う. 大山さん なぜ組み込みコンポーネントかについて説明する. 組み込みコンポーネントは,独立性の高いソフトウェアモジュールを構成する手段 である.独立性が高くなると,諸問題の多くを解決できる可能性がある.しかし, 非組み込み分野では普及しているにもかかわらず組み込み分野では普及していない. この理由はなぜか. なぜ普及していないのか ・C++ より C がよく利用されていて、OO的考え方 が普及していない ・組み込む手段として、静的ライブラリ、リロケータブルオブジェクトの供給が普通 ・分散フレームワークが普及していない 何の役に立つのか ・コンポーネントを意識したアプリ開発 ・SW 部品の流通 ・マルチCPU対応 応用 ・TCP/IP Ethernet/PPP/無線LAN ・GUIコンポーネント 宿口さん 普及しない理由としては、それぞれのメーカによって欲しいインターフェース,階層 レベルが違うからでは.次に,作り方の問題として、コンポーネント指向で作られて いないのが原因では.その推測される理由としては,設計のモデルと実装のモデルが 同一になってしまうことが考えられる.このときに機能分割はされているかも知れな いが,コンポーネントとして考えていない.そのために再利用できなくなる.したが ってコンポーネント指向で設計をする必要がある.このような流れで IDL という方法 に来たのだろうと推測できる. 高田先生 異なるレイヤで再利用をしたいという要求に答えるには,コンポーネントを小さい単 位で提供すればよい.そして,異なるレイヤで再利用を行うときに,少ないオーバヘ ッドの処理が可能なコンポーネントが使えればよい.しかし,コンポーネントの完全 性を追求すると,各レイヤでエラーチェックのコードを入れなければならない.これ が大きなオーバヘッドとなる.このオーバヘッドの問題を解決したい. B さん 現在ではシステムが大きくなり,ある程度のソフトウェアの階層化はされているはず である.そのようなところではコンポーネントは受け入れやすいのではないか.それ ぞれの開発者が欲しいレイヤが異なるという問題があるが,まずはそのようなインタ ーフェースを決めてしまうのがよいのではないか. 大山さん IDL を使って抽象化して再利用性を高めることは非組込み系ではすでに実証されてい ると考えており,組み込み系でもそれは受け入れられていくと思う.この WG でもそ の方向だと思う. C さん 組み込みではインターフェースのオーバヘッドが嫌だというのは大きな要因だと思う. 大山さん 少し,先の話題に進みたい. 組み込みコンポーネントに特有の機能 ・静的コンポーネント生成および接続 ・動的なコンポーネントはオーバヘッドが嫌われる ・非タスク部はコンテキストが指定できないと困る D さん このあたりに特にいうことはなく、どのように実現するかの方法論になると思う 宿口さん それは requirement に対してどう実装するかということですね. D さん このスライドでは,矛盾する要素が入っている.静的コンポーネントの接続とローダ ブルモジュールは矛盾している.そのような矛盾を切り分けて,大規模なプログラム では,従来のコンポーネントの考えを使わなければ使えない,という話しと,組み込 みでは独立性を出さないと使ってもらえないなどの区別をしなければならないのでは. 宿口さん 動的コンポーネントの生成とローダブルモジュールは実装の違い,また,それとは別 にコンテキストの指定などがある.それらをカテゴライズすべき. (九州大学 E さん) 整理しないといけないと思うが,こことは別の問題も含まれていると考えられる. 例えば,コンパイラの自動最適化や,エラーチェックは言語処理系で解決できるので はないか.そのような他の部分で解決できる問題と,われわれで解決すべき問題を分 けるべき. 宿口さん 言語処理系の話がでてきたのでしゃべるが,高田先生の理想は相当なパラダイムシフ トが必要.言語レベルで対応しようとすると,エラーチェックのコードと本質的な実 装のコードは言語レベルで区別する仕掛けが必要.そうすると,リンクの概念も変わ ってきてもっと大きい部分から変えなければならなくなってくると思われる.それよ りも,もっと問題を絞った方がいい解決法がでるのではないかと思う. 高田先生 確かに,これらを同時に解決するかどうかはこれからの検討次第で,難しくなるから ある部分は置いておこうということになる可能性はある.また,われわれは OS のグ ループであって,コンパイラには強くない.コンパイラを考えてくると、gcc 以外の 環境ではどうなるか,などの問題がでる.実際的なアプローチとしては,エラーチェ ックなどはコーディングガイドラインでエラーチェックのコードをあるきまった書き 方で書かせるようにすることなどが考えられる.それなら C 言語でできる. そして,まずは C 言語でできる範囲で書やって,あとから新しい言語を作っていく ことがよいのでは. 宿口さん マクロで解決しようとするとバグが多くなるなどの問題がある. それよりも,現在の C のプリプロセッサではなく,別のプリプロセッサを開発するの がよいと思う. 高田先生 ifdef などよりもよい方法としては,チェックのための専用のマクロ(CHECK_***() など)を作ってやるのがよいと思う.それをすべてのコンポーネントに適用すれば よいのではないか. 宿口さん 静的モデルなら ID チェックがなくてよいが動的モデルならばおそらく必須になる. したがって,状況によって,エラーチェックのコードが外せたり外せなかったりす るように必要がある.また,それとは別の話しで,私は簡単なところから行こうと しているが,高田先生はドラスティックに現在の方法を変えようとしている. 高田先生 アカデミックな立場ではいつもそのような感じはあるが,それだからこそ ID チェ ックのコード生成を IDL を用いたインターフェース生成のところで議論したいと 思う. 宿口さん スタティックなモジュールとダイナミックなモジュールを一つのプログラムから作 りたいという要求があるとして,それはコンフィギュレーションするときに設定す ることでチェックコードが入ったり入らなかったりすればよい. 高田先生 まさにそういうことで,コンポーネントがどう接続されるかで変わるのが理想. 例えば,TCP と IP のリライアビリティレベルが同じならば IP 側ではチェック コードがでないとか,片方がどのような動作をするかわからないときはチェック コードが出るなど. 宿口さん 今おっしゃたのは,ソースレベルでは ifdef などを使って書いておいて,リンク をするときにコンポーネントの接続を見て自動生成するようなイメージか. 高田先生 そのようなイメージだ. F さん 問題を大袈裟に考えているのでは.コンポーネントだから場合によって取り換え ればよいのでは. 高田先生 私の個人的な目標では,一つのコンポーネントはできるだけ再利用性を高くした いという目標がある.私の経験では,例えば ITRON のデバイスドライバは,あ まり流通していない.各社が同じデバイスを使っているが,デバイスドライバを 各社の商品に特化して書いていて汎用性がないということがある.そのような状 況ではなくて,なるべく一つのコードでどこの製品にも使えるようにするのが目標. F さん それは動的にやらなければならないのか. 高田先生 動的にやる必要はない F さん それならば,静的なときに使うソースコードや動的なときに使うソースコードを あらかじめ用意しておけばよいのでは. 高田先生 そのソースコードを一本化したい.組み合わせが少なければよいが、組み合わせ 爆発を起こすと大変. F さん それは自動でやってもあらかじめ用意しても組み合わせの数は同じではないか. 高田先生 事前に用意しておくのではなく,その場その場で生成するという方法. F さん しかし,現場でそのような何十通りもあるとは考えにくい.せいぜい数通りでは. 高田先生 ある一つの現場ではなく,そのコンポーネントの使われる状況で… G さん TOPPERS は組み込みを対象としているので,組み込みに限ればそんなに多様にはな らないのではないか 高田先生 さっきは IP の例を出したが,メッセージの渡し方など,いろいろ変わって来る. G さん ソースコードを書く人にとっては,いろいろ変わるというのは動的でも静的でも同じ H さん 時間の流れを考えれば,最初は信頼性が低いのでチェックを入れときたいが,信頼で きるようになったから外したいなどという要求はあるのではないか. G さん それならば,たくさん用意しておかなければならないということはない.一つのコード を変えて行けばよいのでは. 宿口さん 高田先生もたくさん用意しておくとはいっていない. G さん 検証にかかる時間などは変わらないのではないか 宿口さん 検証などにかかる時間は同じだろう. しかし,コンフィグした内容に合わせて必要なテストが生成できたりすればよい. テストそのものはそれぞれのコンフィグレーションでやらなければならない. G さん テスト支援という意味か 宿口さん テスト支援という意味も含めて,コンフィグレーションが変わるごとにテストの生成なども 考えていかなければならない. 大山さん いいアイデアをありがとうございます.そこまで考えていなかったが, チェックコードを生成可能で,それが正しいコードかのテストが必要な状況もあると思う. G さん しかしそれは,実機でやらなければならないのでは. 大山さん 実機になるかもしれないが,テストはしなければならないと思う. 宿口さん 最初は静的なモジュールからテストをしていって,あとで仕様がはっきりしてき たら、その部分のテストができるようになればよい.最終的には実機でやらなけ ればならないが,シミュレーションででもテストができるというのが大事. H さん 先ほど大袈裟ではないかと言ったのは,言語処理系を作ってそこで支援しなけれ ばならないような,そういうことまではやらなくてはよいのではないか,という ことを言った. 宿口さん それはやり方の一つだと思う. 高田先生 ID チェックくらいは C言語でできる範囲だと思うが,メッセージ渡しくらいに なると言語を作ってやりたくなる気がする.C 言語で書くとかなり面倒になる. H さん しかし,作りなおすときには使わないのでは. 高田先生 それはそうだと思う.まずは C で作って,そこから先は言語屋さんに任せる. 大山さん 個人的には,いま議論しているようなことは,分散システムにおいて信頼性や設計 の効率化に効果があると思っているが,実際にマルチプロセッサシステムを設計し ている方はいますか. 宿口さん その前に,マルチプロセッサのどのようなシステムを考えているのか決めておきたい. 例えば,負荷分散などか 大山さん 負荷分散でもよいと思う. 宿口さん どのようなプロセッサ間通信を行うものか.密結合型でないものでよいか. 大山さん それでよい.メモリ非対称のマルチプロセッサシステムとする.そのようなシステム を使っている方はおられるか. I さん どちらかというと,私の職場ではマルチCPU よりもシングルCPU. 高田先生 あるアンケートでは、シングルCPUは3割,現在はマルチプロセッサが普通のはず. 宿口さん システムを統括する人はマルチCPU を意識するが,サブシステムの開発の人はそうで ない.サブシステムの先がインターフェースが定義されていて,サブシステムの開発 の人はマルチ CPU は意識しないのでは. 大山さん その方法でうまくいけばよいが、うまくいったと聞いたことはあまりない 宿口さん うまくいっているかどうかではなく,マルチプロセッサを意識しているかどうか. J さん 私のところでは,実際には 2つCPU が載っているが,完全に独立しているので, 実際の開発では複数の CPU を意識することはない. 宿口さん 複数のプロセッサがあるが,ソフトとしては賢いデバイスドライバに見えるような感 じで,意識しなくてよいのでは.大山さんが言われるマルチプロセッサの気になる点 はどういった点か. 大山さん 例えば,CPU 間の通信はどのようになっているのか.コマンドは何個くらいか. K さん 直接の担当ではないのではっきりとはいえないが,数十種類程度で,問題点はデータ の転送が多くなりすぎるとうまくいかなくなるような仕様である. 高田先生 それは,ソフトウェアは既存で完成していたものを用いたのか,あるいは自分達で つくったのか K さん 自分達でつくったもので,ITRON は日立の古いものだった. 高田先生 相手が枯れているのもならば,あまり気にならないのでは. L さん 枯れているからではなく,片流れだからでは、 大山さん グラフィックの場合などではあまり困ることはないかもしれないが,別の場合では, どのビットが立っているかとかどの順番でやるかなどは IDL 化していた方がよいの では.枯れているソフトならよいかもしれないが,開発中は苦労するのではないか J さん 大山さんの発言で共有メモリがでているが,実際には共有メモリを隠す. そういう場合は通信でやって皮をかぶせている. 宿口さん それが使う人のレイヤの違いで,階層化されているからうまくいく. その実現が IDL か C 言語かという違い. 高田先生 共有メモリじゃなくて,関数なのか,メッセージでやるのかという話では. 大山さん その共有メモリの皮の部分を作るのがユーザ側ではないかと思う. その皮を作るのが大変ではないか. 宿口さん それは会社によって違う. 大山さん そこの生産性をあげたい. 宿口さん そこの生産性が業務の何%を占めているかが問題.他のアプリケーションと比較して 少なければ無視してよくなる. 大山さん 信頼性などを考えれば,やっておいた方がよいと思う. K さん そういうことはやっている人はやっている. 宿口さん やっている人はやっていると思うが,それを文書化した人はいない可能性がある. 文書化したような方式を提案するのがわれわれの役割という気がする. K さん コンポーネントにするというのはクラスライブラリにするということだと思う. 決まったライブラリがあるから再利用ができる. 宿口さん ユーザとしては使いやすいものが欲しい.しかし,設計者はデバイスドライバが 書きやすい環境が欲しい. 高田先生 API がすべてのデバイスドライバで標準化できるなら素晴しいが,それはできそ うもない.だからそれに変わる方法を考えているということ. K さん 何か作らないと話は始まらないと思う. 宿口さん コンポーネントの作り方を決めようと言っていて、それに従うと再利用が可能に なるということ. 高田先生 とりあえず,TOPPERS のカーネルや TCP/IP などから始めたい K さん カーネルのコンポーネント化というのは,マルチプロセッサなどでそれぞれのプロセ ッサに対してカーネルを変えるということか 高田先生 それができるようになることを期待している. カーネルのコンポーネント化は,カーネルに対して IDL の記述が提供されていて, それからカーネルが派生していくようなものかもしれない. 高田先生 最後の話題として分散に関してですが,組み込み分散でとても難しいのは, メソッド呼出しとそのリターンで成っているものが業界ごとにあること. 業界ごとにあるので,ぐちゃぐちゃになる.そのようなものをまとめて扱うモデル があればよいのではないかと思っている. 大山さん メッセージ渡しなどを統一的に扱えたらよいというのがある.宿口さんのいうと おり,一度作ったあとは変わらないというのはそうだと思うが,改変の容易性など を上げるのはよいと思う. 宿口さん コンポーネントはよくできていたら使われるかもしれないが,インターフェースだけ 定義して全部作らなかった意味がない. 高田先生 実装はすべてやってなくても,いろいろなものを仕様化しておくことは価値があると 思う. 宿口さん 設計手法の研究ではなく,「コンポーネントを意識したアプリ開発」が重要なわけで すね.それを OS 側から提案するのはあるかもしれない. 大山さん 最後にまとめると,WG としてやろうとしていることは非常に幅広いことだが、幅広い ことを個別にではなく統一的に扱いたい.しかし、最適化は無視でなくて、組込みな ので最適化は考える.そのような感じで進んでいる.しかし,人によって意識が違う ところが難しいのかもしれない.