議事録 分科会2 セッションSB-7「組込みシステム向けコンポーネント仕様を考える」 コーディネータ 大山 博司(オークマ) 席数 100人程度 参加人数 30人程度 ここではTOPPERSプロジェクトコンポーネントWGでディスカッションしている内容に ついて話す どんなことを期待するかについてディスカッションする 組込みコンポーネントを使用することによって何かが改善されるかを期待されてい ると思うが組込みコンポーネントの捕らえ方は人によって異なると思われる コンポーネントWGではいろんな意見が出るためなかなかまとまらない 数年前に大山が考えていたコンポーネントの概略は,非組込み系ではJava、CORBAな どの組込み用コンポーネントがあるが,もっと統合化した何かがあるとよいと考える ITRON仕様に期待することとして50%近くが,ソフトウェア部品のコンポーネント化に かかわることである 組込みソフトウェア開発の諸問題1 　複雑大規模化する組込みソフトウェアの諸問題 　多人数開発 　短納期 　長期的改良、メンテナンス 　ミドルウェアを購入して切り抜けたい 　購入に費用が大きいPCの費用を上回る 組込みソフトウェア開発の諸問題2 　マルチプロセッサが多い 　オークマで数値制御システムを開発しているがあたりまえ 　組込み用フレームワーク 　組込み用コンポーネントとは何か 　期待感はあるが何なのかよくわからない 　人によって捉え方がまちまちである 　期待する役割もさまざま 　どういった問題があるのか 　非組込み系では10年ほど前からかなり普及している 　CORBA、CCM、MS-COMなど コンポーネントの定義 あるサービスを提供する独立して交換可能なソフトウェアの構成単位のこと (以下三項目が聞き取れず) インターフェイスに適合することが重要 (以下、質問形式で議論が進む) (大山氏から宿口氏に質問) 大山氏：具体的にどういうことを期待するか 宿口氏：業務内容にかかわるが、てっとり早くソフトを開発したい デバイスが変わっても簡単に入れ替えたい 大山氏：現状の問題は何か 宿口氏：組込み屋はデバイスドライバ屋である アプリとコンポーネントのインターフェイスの境界はどこか 使う人によってあらゆるレイヤがある 高田氏：あらゆるものを必要であれば定義すればよい 宿口氏：インターフェイスということばがかみ合っていないのでは？ 山口氏：高田氏のインターフェイスとはIDLのようにコンポーネント同士が 対話するメカニズム インターフェイスがどうあるべきかが問題かを宿口氏は言っているのでは？ 具体的なインターフェイスはどんなものかを議論したほうがよいと思う 宿口氏：ワーキンググループはIDLの方向に進もうと答えを出した なぜIDLの方向にすすむことが決定されたのか？ 大山氏：各部分でインターフェイスを決めなければならないが 山口氏：メタなインターフェイス（IDLなど)を作ろうとしたきっかけは何か？ 大山氏：なぜ組込みコンポーネントなのか ブラックボックスとして扱える 最小のインターフェイスにより外部とやりとりできる 非組込み分野で普及しているが組込み分野では普及していないのはなぜか？ 10年くらいは水をあけられていると思う 非常に有用性が高いがなぜ組込みでは実現されていないのか C++よりCが利用されていてオブジェクト指向的考え方が普及していない インターフェイスと実装を分離しようという考え方 静的ライブラリ、リロケータブルオブジェクトの供給が普通である ポーティングに手間がかかるほうがベンダーには都合がよい(利益が出る) 分散フレームワークが普及していない 何の役にたつのか コンポーネントを意識したアプリ開発 何十人のエンジニアが同じソースを修正 ある程度インターフェイスを分割して見通しをよくする ソフトウェア部品を流通する 互換性のある部品の流通 異なるメーカのスタックを組み合わせて利用 マルチCPU対応 組込みの分散フレームワークを実現したい マルチCPUシステムの自動化、容易化 以上がWGが捕らえている目的 応用例 TCP/IP たとえばこのように図がかける (TCP/IPドライバの図を指して説明) 矢印は関数の呼び出しを表している IDLのように一連の関数であらわされるものを想定している 宿口氏：ワーキンググループが出している結果を知らなくて議論していた 普及しない理由としては境界がとりにくい メーカ間で階層のレベルが異なる ほしいものが異なるのでそこで終わってしまう ソフトウェア自体がコンポーネント思考で作られていない 一発で開発が終わってしまう さまざまな点を解消するには雛型を示すことも必要と考える 高田氏：デバドラをどう決定するか 小さな単位で分けてインターフェイスを定義する 小さなオーバヘッドでコンポーネント化しなければならない 各レイヤでエラーチェックをかけるのが面倒(上記と矛盾) そのあたりを解消したものが私の創造するもの ？？氏：システムが小さいと弊害がある システムの規模がある程度大きいところはもうやりはじめているはず そういうところでは受け入れられやすいのでは？ C++のクラスを拡張したようなもの 文化であり、クラス階層を知らないと使えない まずはインターフェイスを決定するのはあたりまえと考える クラスの作り方は千差万別なので万人に受け入れられるか 宿口氏：TOPPERSのコンポーネントは以上の経緯でIDLで進んだのか？ 大山氏：非組込みで受け入れられているので組込みでも受け入れられるのでは？ ？？氏：インターフェイスのオーバヘッドは嫌がられるだろう 大山氏： 組込みコンポーネントに特有の機能 静的コンポーネント生成および接続が重要 割り込み応答ルーチン/コールバックが書けることが重要 動作コンテキストの指定 非タスク部でも 一対一接続のコンパクト実装が可能 汎用性が高いとオーバヘッドが大きい 排他制御構造の実装 引数項目の自動生成 プラグ＆プレイ的機能の実装 テスト用、デバグの支援機能 HMIでデバイスをテストする機能が必要では？ 例外 ？？氏：あまり中(WG)の人に聞くとWGと変わらなくなるのでは？ 大山氏：いつもそう ？？氏：矛盾する要素が入っている 静的とローダブルモジュールは矛盾 従来あるコンポーネント仕様を引きずる部分 と組込みに使ってもらえる部分を明確に分ける必要があると思う 宿口氏：資料をカテゴライズしてほしい 割り込み応答ルーチンはカテゴリが別である 九州大？？氏：言語系技術者ががんばれば対応できる問題もある 山口氏：何を一番優先するかという問題を絞り込んだほうがよい 高田氏：全部解決できるかは議論をすすめる必要がある TOPPERSグループはコンパイラ屋がいない GCC以外の環境に対応できない Cでできる範囲でがんばりあとで言語屋さんに解決してほしい 山口氏：マクロ定義ではバグが入る余地がある 高田氏：ガイドラインで逃げればよい 宿口氏：動的モデルではIDチェックは外せない 高田先生は理想が高すぎる もっとゆっくりした変化が必要では？ 高田氏：インターフェイスごとにIDチェックを書く必要があると考える 宿口氏：リンクするときにメイクファイルを吐き出して？？？(聞き取れず) ？？氏：大げさに考えすぎ いくつか用意して必要なものを置けばよい 高田氏：ひとつのコンポーネントがいろんな場面で使えるのが理想 ITRONのEtherドライバは普及していない 場面に特化しているため いろいろな場面で使用できることが必要と考える ？？氏：動的に？ 高田氏：動的でなくてもよい 可能性のある部分のみをマクロで切り替えて用意できればよい ？？氏：組込み系に特化したのであればバラエティに富む必要は考えられない 高田氏：話がかみ合っていないのでは？ (議論が早すぎて聞き取れず) 宿口氏：コンフィグレーションでテスト支援プログラムを生成するようなことも 考えたほうが良い 大山氏：いいアイデアをありがとうございます 宿口氏：まずはCPPUNITのようなイメージでよいと思う 高田氏：Cだとセマンティクスが複雑になる 宿口氏：OSのバインディングはリンクされるときでよい という形で決めてしまえばよい 大山氏：粗結合マルチプロセッサ対応について 組込みの分散フレームワークをだれも作る人がいない 宿口氏：マルチプロセッサの定義とは？ 大山氏：マルチプロセッサで開発されている方はみえますか？ 穴田氏：ひとつのCPUで実現することをマルチプロセッサで実現している ところもある 高田氏：1CPUが3割しかない現代はCPUが一個の時代ではない 宿口氏：マルチプロセッサをやってない人はわからないだろう 大山氏：インターフェイスが規定されているだけでうまくいっているところは あまりないと思われる ？？氏：あるグラフィックコントローラの制御をしている CPUはふたつだがまったく違う制御をしている 2CPUのシステムを1CPUに落とすような作業をしている コマンドの種類は数十種類程度 高田氏：グラフィックコントローラは自分たちで作成したものか？ ？？氏：はい 大山氏：参考になりました グラフィックの場合は属性置を設定することが少ないと思われる 宿口氏：絵を書いている人は共有メモリを意識していない (議論が早すぎて聞き取れず) 宿口氏：生産性が何パーセントをしめるのか そのへんの見えかたがある デバドラを再利用していれば減価償却できる IDLをつくらないにしても ？？氏：結局やっているところはやっている 宿口氏：やっているところはやっているがそこを策定するのがWGの役割である デバイスドライバの供給屋の立場である ？？氏：とにかくなんか作らないと話が始まらない 宿口氏：使えるものがあってみなさんが使えば世の中が変わってくるだろう 高田氏：現行TOPPERSのTCP/IPはこのコンポーネントが策定されたら変えていきたい 組込みの分散フレームワークが難しいのは CANのメッセージパッシングはCORBAでは存在しない いろいろなモデルを同じフレームワークで扱うと収拾しない 大山氏：いったんつくってしまえばかわらない気がするが 宿口氏：楽にはなると思う コンポーネントはよくできていればいるほど使われつづけるものである コンポーネントを意識したアプリ作成が重要である こちらから爆弾を投げる必要がある しかしよけられる可能性がある 大山氏：緩やかなオブジェクト指向としてこの考え方を導入していきたい 宿口氏：製品の系列が決まっていると恐竜のように残りなかなか変えられない 大山氏：WGではいつもこんな感じで 組込みならではのある程度の最適化が必要という意識はいつも持っている 最後にWGの活動を紹介する 毎月1回名古屋に集まってWGが開催されている 来週火曜日、日立システムアンドサービスの会議室を使って行われる 組込みコンポーネントも今後特に重要なものになると思われる こんなような議論だがぜひ参加してほしい うまくまとまりませんでしたが今日はこれで終わります どうもありがとうございました (記録者自身の感想) コンポーネントWGに参加されている方も本セッションに参加されており、精力的に組込 み用のコンポーネント仕様策定に取り組まれている雰囲気が伝わってきた。 大山氏は非組込み系のコンポーネント仕様を組込み系に導入したいという考えをお持ち のようだったが、オーバーヘッドや製品の役割の違いなどから単純に非組込み系の技術 を組込みに対応させることが難しいという意見が大半であった。 組込み用コンポーネント仕様の現状と問題点、将来どういった方向に進んでいけばよい のかを知ることができ、非常に勉強になった。