==========================================================
分科会2 セッション S2-4-1
タイトル ：組込みソフトウェアコンポーネントを256倍使うためには
時間 ：15:10〜16:50
参加人数 ：21人
会場 ：C会場
コーディネータ: 佐藤洋介(デンソー) 山崎進(福岡知的クラスター研究所)
==========================================================
[概要]
・プロダクトラインやコンポーネントフレームワークを組込みに導入するに当
たっての、期待する点や問題点などの抽出を行い、それについて議論を行う。
[形式]
・パワーポイントによる説明の後、複数箇条の質問について意見を出しディス
カッションを行う。
----------------------------------------------------------
■自己紹介
佐藤：
・昔は、携帯電話コンテンツシステム開発、カーナビゲーションシステム開発
・今は、車載ソフトウェアプラットフォーム開発
・電子機器事業事業 エンジン制御など
・車の中に搭載されるECUを作っている
・これからは、車載ソフトウェアアーキテクチャ標準化
山崎：
・九州大学の福田先生のプロジェクトで活動中
・ソフトウェアプロダクトラインを組込みの現場で使えるように
・プロダクトラインで組込みシステムを開発中
・Nameplates: 地理的に分散したグループメンバーの行先表示
・IPコミュニケーションボード: SIP, RTPを用いたLinuxベースのVoIP端末
・開発事例を元に方法論と支援ツールを構築
----------------------------------------------------------
■導入
・組込みシステム開発の現状
・開発の中心はソフトウェアになりつつある
・組込みソフトウェアは大規模・複雑化の傾向
・昔のマイコンはエンジンだけ制御していれば良かった
・システム内ネットワーク化（車内LANなど）や、システム外インフラと
の接続（インターネットなど）の外的要因があった分野は特にこの傾向
が顕著
・組込みソフトウェア開発の課題
・大規模・複雑化するソフトウェアをいかに管理し、開発・保守を行うか
・複雑化によって混入する不具合を除去し、いかに品質を維持・向上させるか
・車両の技術トレンド
・60〜70年代にかけてメカの制御をエレクトロニクスで置き換え
・80〜90年代にデジタル化・高機能化
・00年代に入るとさらにネットワーク化
・例: カーナビが前方のカーブを検知→ステアリング制御
・ECUの数の増加、開発の大規模化
・現在, 高級車クラスでECUの数は60個程度
・プログラムサイズ, ソフトウェア技術者数ともに年々増加
・世の中の取り組み
・ビジネス系では、大規模・複雑化によって発生する諸問題を、Javaや.NET
などにミドルウェアを統一し、EJBやCORBAなどのコンポーネントを流通さ
せる仕組みを整え対応
・組込み系ではリソース制約、時間制約などの特性の違いによりコンポーネ
ントベース開発は普及していない
・C言語、アセンブラベース
・アーキテクチャよりも制御ロジック重視
・しかし最近、大規模・複雑化や短納期要求などの外圧が強まり、コンポー
ネント標準化の動きが活発化
・AUTOSAR, JasPar, TOPPERSコンポーネント仕様
・また、プロダクトラインを組込み開発に適用する研究も登場
----------------------------------------------------------
■コンポーネント標準化事例
・事例：AUTOSAR
・AUTOSARとは
・Automotive Open System Architecture
・自動車メーカとサプライヤが中心となり、車載ソフトウェアや電子アー
キテクチャの共通化を目指して設立したコンソーシアム（2003年7月設立）
・思惑
・部品メーカ：いろんなメーカに部品を売りたい
・自動車メーカ：良い部品を安く買いたい
・活動のねらい
・車載システムの複雑さの低減
・自動車メーカ、サプライヤを超えたソフトウェア流通、再利用の実現
・AUTOSARパートナーシップ構成
・Core Partner (決定権)
・OEM 6社、Supplier 3社
・Premium Member (意見提出権)
・OEM 6社、Supplier 8社、半導体4社、3rd Party 11社
・AUTOSARコンセプト
・VFB(Virtual Function Bus)
・ハードウェアやネットワークリソースを仮想化したバス
・複数のECUから構成される車両システムを一つの仮想的なECUとして開発・
管理する
・RTE(VFBを実現する手段)
・アプリケーションソフトウェアの実行環境
・RTEのAPIのみでアプリを記述
・ハードウェア仮想化
・ゼロオーバーヘッドを目指す
・最適化手法
・静的結合
・ツールによる作業効率化
・接続コードの自動作成
・タスクへの自動割付
・事例：JasPar
・JasParとは
・Japan Automotive Software Platform Architecture
・トヨタ自動車、日産自動車、本田技術研究所などが幹事会員
・いわばAUTOSARの国内版
・活動のねらい
・ソフトウェア基盤、車載LAN要素技術などの非競争領域を、日本企業各
社が協力して開発することで、技術開発コストの削減や技術開発の促進
を図る
・事例 TOPPERS
・TOPPERSでは組込みコンポーネントWGにより、コンポーネント仕様を策定
中
・2005年5月現在、仕様の基本部分が完成
・特徴
・オーバーヘッドを極力排除するため、静的なコンポーネント定義・生成・
結合を基本としている
・開発効率化に焦点を絞り、CORBAなどと比較し、機能を限定させる
・従来のコンポーネントモデルとの用語的混乱を避ける意味から、独自の
用語体系を用いる（コンポーネント＝セル等）
----------------------------------------------------------
■プロダクトライン
・ソフトウェアプロダクトライン
・工場のプロダクトラインからの類推
・一つのラインで複数種の製品(製品群)を生産
・これをソフトウェアに導入できないか？
・一つの開発プロセスで複数種のSWを生産
・米国 CMU, 欧州 ITEA などで研究
・ITEA はプロダクトファミリーと呼んでいる
・なぜプロダクトライン導入か？〜単なる再利用ではダメ
・特に携帯・情報家電開発において
・ニーズの多様化
・追加機能部だけ開発すれば…
×想定していない機能追加→既存コードを大幅に変更
・短期間低コストで
・基本部は再利用
×拡張可能にしたため過剰スペックに→工期が延びる
・高信頼性
・既存資産は十分テストしているので, 安心
×前提条件が変化→リリース後予期せぬ不具合が発生
・問題点: 戦略・計画性の欠如
・最初から計画的に再利用を考えれば, 前述の問題は起きない
・ニーズの多様化: どんなニーズに応えるか
・短期間低コストで: 必要十分な機能は何か
・高信頼性: 想定される前提条件は何か
・そうは言うものの…
・範囲の問題: どこまで計画すればいい？
・変化の問題: 突然の変化はつきもの
・マーケティングプランに着目
・各企業はマーケティングプラン(MP)を立案
・MPに含まれるもの
・市場動向
・どのようなニーズに応えるか
・どのような製品をいつ投入するか
・つまり範囲・変化の問題が織り込まれている
→MPを基に再利用の計画を立ててはどうか？
・MPが変更になる可能性もあるが
・一つの開発プロセスに比べれば寿命が長いというのが前提
・プロダクトライン開発方法論の特徴
・製品群のMPを決めて, その範囲で再利用
・再利用の効率化のため, 共通部分と差異部分を開発の初期段階から徹底的
に分析
・共通部分が出来るだけ多くなるようにモデル化することが肝
・必要十分なアーキテクチャを設計
・MPの範囲内
・共通部分と差異部分の分離
・再利用の対象はコード, ドキュメント, テストデータ, 運用データ, ノウ
ハウなど(資産)
・設計にコンポーネントベース開発を用いる場合あり
----------------------------------------------------------
■問題提起
・コンポーネントand/orプロダクトライン開発に移行したいが
・I/F標準化の問題
・現状は縦割りの組織なのに、コンポーネントのI/Fは誰が決めるのか？
抽象度は？
・導入の問題
・昔プロトタイプを作ったが、量産開発に適用する段階になって量産グルー
プから反対された
・ドラスティックに設計手法が変わると、これまでのような品質保証がで
きない
・現状のソースコードは手が付けられない
・コンポーネントを作り出せる・プロダクトラインで開発できる能力を持っ
た担当者がいない
・資産運用の問題
・現状の構成管理もままならないのにコンポーネント/プロダクトライン
化だなんて
・議論
・コンポーネントベース開発・プロダクトライン開発に移行するためには、
課題がたくさん
・実現する仕組みやプロセスだけではない
・導入し、運用するには、次のような議論をしたい
・○○が障害だ
・○○が課題だ
・○○しなければならない
・今回の目的は課題の共有と解決策の発見
----------------------------------------------------------
■コンポーネントのアンケート
Q1. 実際にコンポーネントを利用している人: 2
Q2. 組込みコンポーネントフレームワークがあれば使用したいと思う人: 7
Q2-1. 何も知らないので判断がつかない: 2
Q3. なぜ使用しないのか？
Q4. コンポーネントに何を期待するか？
Q5. コンポーネントの何が不安か？
・プロダクトラインは効果があるように見えるが、コンポーネントはどちらか
というと、効果が見えにくい。仕組みがしっかりしていれば使えるかもしれ
ない。
・コンポーネント導入によって工数が大幅に削減されるわけではないというの
が普及活動が進まない原因の一つ。
・コンポーネントに期待することは、差分開発と再利用の促進
・このためには共通部分と差分を分割する方法が問題である。これは個人の
過去の経験によるところが大きい。
・再利用という観点では会社の資産である方が望ましいが、残念ながら会社
としての資産ではない。
・分割と資産運用の仕方の2つの問題があるが、コンポーネントを使うこと
で、それらの解決がしやすくなることを期待する。
・運用面では、コンポーネントに分割することで、分担を決めやすいというメ
リットもある。
・分担することで開発に割り振ることが出来る人数が増え、工数が短くなっ
たという効果がある。
・工数の見積もりもしやすい。
・コンポーネントを設計できる人があまりいないという不安がある。
・実際、オブジェクト指向を使ってモデリングする技術を持った技術者が組
込みにあまりいない。これからの技術者の育成が課題。現状ではオブジェ
クト指向モデリングの技術を持った技術者は数％程度。
・フレームワークを設計する人は、たくさんは必要ない。フレームワークを
設計する技術を持ったアーキテクトがプロジェクトに1〜2人いれば良い。
・この場合はフレームワーク自体のレビューが問題になる。現状はアーキ
テクト任せ。
・AUTOSARやJasperなどでコンポーネントを規格化すると部品メーカーが安く
買い叩かれる。競争についていくため他のコンポーネントと差別化を図ろう
とするとインタフェースが拡張されることになり、インタフェースの標準化
という目標が達せられないのでは？
----------------------------------------------------------
■プロダクトラインのアンケート
Q1. 実際にプロダクトラインを利用している人: 0
Q2. プロダクトラインを使用してみたいと思う人: 8
Q3. コンポーネントに何を期待するか？
Q4. コンポーネントの何が不安か？
・期待
・コストの削減
・投資回収が最低ライン
・共通化によって似たようなものを別個に開発するコストの削減に期待
・テストの工数
・現状では製品の数だけテストの工数がかかる。何らかの工夫をしたい
・テストの共通フレームワークが出来ると解決できる？
・フレームワークだけあっても工数は削減できないかもしれない
・戦略的再利用によって新規開発に集中できると嬉しい。
・特に上流工程で新しいものを創造することに集中したい
・フレームワークで実現できる？
・開発プロセスや運用、ノウハウを資産として再利用することで、仕様を実装
するバラつきがなくなることに期待
・不安
・ソフトウェア部隊だけでは対応できない
・現場だけでなく経営陣が興味を持ち、かつ技術がついてくればうまくい
く？
・コア資産のメンテナンス
・設計情報を管理するツールによってコア資産の保守コストを下げる取り
組みをしている。ツールを使っていたら上手く資産運用できていたとい
うものを作りたい
・既存の資産をどう生かすか
・既存の莫大な資産は、一旦モデル化することによって行う。
・具体例として、あるプロトコルのライブラリがあった時、分析段階で
はプロトコルのモデルを利用する
・そのプロトコルがRFCになっているような場合はそのまま利用
・自社製のプロトコルの場合はリバースエンジニアリングを行う。こ
のコストは馬鹿にならない。
・既存資産の中で変更できないコードなどの部分についても、何らかのモ
デル化が必要。この場合はモデル化の精度が問題になる。
・プロダクトライン単独ではなく、製品ドメインまで含めて議論する必要があ
る。全ての製品にプロダクトラインが適用できるとは思わない。
・プロダクトラインでうまくいきそうな企業
・長寿命の単一の製品を作っている
・その製品が機能的に複雑でない
・アプリがあまり大きくない
・上流から下流まで一貫して扱っている
・一旦構築したプロダクトラインの寿命をプロダクトライン進化によって延ば
す試みはあるが、これによってどれだけ寿命を延ばせるかは不明
----------------------------------------------------------
■まとめ
コンポーネント：
・コンポーネントを使うと何が嬉しいかが煮詰め切れていない
・工数の見積もりと分担が行いやすくなるというのは興味深い
・運用面、人材教育(特にアーキテクト)が課題。
・共通部・差異部の分割はプロダクトラインと連携できそう
・何をコンポーネント化するかという戦略が必要
プロダクトライン：
・今回の議論で問題がより明確になった
・品質保証、特にテストの問題
・既存資産の扱いの問題
・事例研究として公開する