関連研究

による大幅な開発費の増大のリスクを軽減する．また，組込みシステムに搭載 されるSoC の消費エネルギーは組込みシステムのソフトウェアの動的振舞か ら強い影響を受ける．Power GatingやDVFS(Dynamic Voltage and Frequency

Scaling)に代表される省エネルギー技術をSoCの設計に適用して．それらの省

エネルギー技術を有効に機能させるためには，電圧や周波数の変更，電源のオ ン/オフのタイミングを，ソフトウェアの動的な振舞いに基づいて制御する必要 があるためである．そのため消費エネルギーの見積りにソフトウェアの動的振 舞を反映する必要がある．

次に，差分開発におけるプロセス改善手法，ボトムアップ開発からトップダウン 開発への移行手段，特に上流からの要件定義と下流からのボトムアップとなる 既存システムの技術成果物との整合性の確立を対象として関連研究を調査する．

また，本研究において実施した差分開発の調査結果と問題点について述べる．

2.1 _関連研究

2.1.1 リバースモデリング

既存のリバースモデリング手法は2つに大別される．一つはソースコードを 対象とする静的解析の結果を用いるモデリング手法であり，もう一つは実際に システムを動作させることによる動的解析の結果として得られる実行トレース データ(Execution trace data) を対象とするモデリング手法である．

静的解析によるリバースモデリング手法

 静的解析によるリバースモデリング手法として，ソースコードの構造設計 と実装設計の解析に重点をおいてモデリングを行い，その結果をリファクタリ ングやプロダクトライン開発に応用する手法が提案されている[21]．

この手法の適用によって作成されるモデルの抽象度は，解析の対象がソース コードであることから低い抽象度である．ただし，作成されたモデルを更に抽 象化することが提唱されているが，主に組込みソフトウェアのパッケージ分割 と関数呼び出しの階層化により凝集度を高めて機能分割と機能理解の容易性を 目的としている．これらのことから，品質の検証を目的として，機能もしくは

2.1. 関連研究 第 2. 関連研究と課題の提起 処理単位を表現するシステムの構成要素に基づく抽象化とは異なる．この手法 においてはシステムの動的な側面であるリアルタイム性についても述べられて いるが，タスクの実行順序の明確化とメモリーやCPU等のシステムリソース の消費に対する注意喚起に留まっており，動的解析の結果は対象としていない．

また同じく静的解析によるリバースモデリング手法として，C++ソースコード のフロー解析の結果を用いることでUMLにより表現される相互作用図を自動 抽出する手法が提案されている[22]．この手法により抽出されるモデルの抽象 度は，ソースコードと同等であり抽象度は低い．

動的解析によるリバースモデリング手法

 動的解析によるリバースモデリング手法も提案されている[23]．この手法 はメタモデルと一貫性規則を用いて，動的振舞の情報からモデルを作成する．

モデル作成のためには，制御構造を把握する必要があることから，動的振舞の 情報に条件分岐や反復に関する制御情報を含めなくてはならない．またこの手 法は，システム測定による侵襲性により，システムの動的振舞を変化させる影 響があるため，システムの動的振舞とシステム性能を測定するための正確な時 間情報が得られない可能性がある．

文献[24]は，第41回Design Automation Conference (DAC 2004) 併設の Work-shop on UML for SoC Design における主要な参加者による論文集であり主な論 点は，ハードウェアとソフトウェアの協調設計，コード作成，モデル変換，モデ ル検証などである．システムレベルの設計モデルを下流工程で活用することを 主目的としており，高い抽象度のモデルによる上流工程での品質の検証や評価 についての言及は見られない.また従来のリバースエンジニアリング技術の適用 では，ソフトウェアの動的な振舞いを得ることが困難であることが指摘されて

いる[25]．これに対照的な技術として動的振舞の解析結果である実行トレース・

データの取得において，測定による侵襲性が低いシステム測定技術[26]が提案 されている．この手法ではシステムの動的な振舞いを変化させる影響が少ない ことから，システムの正確な振舞いデータが得られる．このシステム測定技術 によって得られる実行トレース・データは，観測対象となった関数の呼出・復帰 とそのタイムスタンプである実行時間情報，関数を実行するスレッドの識別子，

および指定された関数引数の値から構成される．

2.1. 関連研究 第 2. 関連研究と課題の提起

2.1.2 システム・レベルのシミュレーション検証手法

性能評価のシミュレーション手法

システムレベルの性能や機能の評価においては，システム・アーキテクチャ をモデルによって表現し，性能評価のシミュレーションに用いるモデルベース のシミュレーション手法が提案されている[27],[28],[29]. これらの手法はモデ ル記述言語にSystemCに代表されるハードウェア記述言語（HDL : Hardware Description Language)を用いる手法である．また独自のモデル記述言語で作成 されたモデルを用いるシミュレーション手法などがある[30]，[31]．いずれの手 法においても作成されるモデルの抽象度は低い抽象度であり，高い抽象度によ るシステムの機能もしくは処理単位のモデル表現はみられない．SoC設計にお いて，上流工程でのアプリケーション・ソフトウェアを含むシステムレベル検 証の重要性が提示されているが，設計完了のクライテリアを含む検証計画の作 成による，下流工程での検証の効率化の言及に留まっている[32]．同様にSoC 設計において，上流工程でのシステムレベル検証が提案されている.

[33].この手法では，ハードウェアの領域において，IPコアの動的な振舞を再現

するビヘビア・モデルを用いて抽象度を高めるアプローチが採用されている．

しかしビヘビア・モデルの適用は新規開発のIPコアや，規模の大きなIPコア に限定されており，それ以外の設計要素はバスモデルもしくはHDLによる詳細 設計データを用いる．また，ソフトウェアはOS層からミドルウェア層，アプ リ層で構成されることから，実際の組込みシステムのソフトウェア構成に近い．

しかしながらそれらは，IPコアやSoCの機能や性能検証に特化したCコード によって構成されていることから，ハードウェアとソフトウェアの双方を含む システムを対象とするのではなく，あくまでもSoC開発に特化したハードウェ アの機能や性能検証に限定される．

ハードウェア・ソフトウェア協調設計（hardware software co-design，以下ハー ド・ソフト協調設計)[34],[35]は，実際に適用されている性能予測手法として一 般的である．co-designとは，ハードウェア部とソフトウェア部の設計を連携さ せながら，かつ同時並行に進める手法である．co-designは，一般的に次のよう な三つの段階を経て進められる. 

エンタープライズ・サーバ(EPS - enterprise server system)におけるCPUの

2.1. 関連研究 第 2. 関連研究と課題の提起 性能や機能の評価において，ソフトウェアの動的な振舞いを反映した実行トー レースを活用する手法が提案されている[36]. この手法においては性能評価の対 象がソフトウェアとハードウェアを含むシステムでは無く，CPU並びにキャッ シュ等の構成要素に限定されている．また実行トレースデータは本論文で用い たモデリング技術の活用は見られない．

(i) システムの仕様や機能を決定

(ii) システムの各機能をハードウェアとソフトウェアに分割し，リソースを 割り付け

(iii) システムのハードウェアとソフトウェアの詳細設計と統合検証

co-designにおける課題は,2つ目の段階において各機能をハードウェア部，ソ

フトウェア部で実行したときの処理性能や，消費エネルギーなどを検証するこ とが難しくシステムのハードウェアとソフトウェアの詳細設計と統合検証の完 了を待つ必要がある．そのために仮想開発環境などの活用によって早期に詳細 設計と統合検証を実施することで，性能予測やアーキテクチャ検証の期間を短 縮することが多く適用されている．しかし設計を開始しないと機能や性能の性 能の見積りができないため，上流工程を対象としていない．

消費エネルギーの見積もり手法

消費エネルギーを見積もる手法の多くは，その対象が主に半導体であり CPF（Common Power Format）やUPF（Unified Power Format）[37]が用い られている．いずれの手法においても消費エネルギーを見積もるために半 導体の設計データであるネットリストを活用する．ネットリストは SoC や ASIC(Application Specific Integrated Circuit)の開発における詳細設計の成果 物であることから，開発の下流工程において適用が可能な技術であり，上流工程 において抽象度の高いアーキテクチャ設計の段階で消費エネルギーを見積もる ことには適さない．またSoCや ASICに搭載するIPコアの単位や，モジュー ル単位の粗粒度なスリープ制御手法[38]がある．いずれの手法においてもシス テムが搭載するソフトウェアの動的な振舞に着目した，シミュレーション手法 とは異なる．スプレッド・シートを用いた消費エネルギーの見積もり手法[39]

は,SoC開発の上流工程において一般的に用いられる．IPコアの仕様から推測

2.1. 関連研究 第 2. 関連研究と課題の提起 される静的な消費エネルギーと，アクティビティ・ファクタもしくはスイッチン グ・ファクタから推測される動的な消費エネルギーを用いた見積もり手法であ る．この手法においては，SoCやIPコアの仕様から推測される静的な消費エネ ルギーは十分な精度があると判断できるが，動的な消費エネルギーはアクティ ビティ・ファクタに十分な精度を求めることが難しく，高い精度が得られない．

またSoCを搭載するシステムの上で実行されるソフトウェアの動的な振舞には 着目していない．UMLモデルを用いることで，SoCに搭載するキャッシュメモ リーの消費エネルギーを見積もる手法が提案されている[40]. この手法はUML モデルによる設計データを使用して用いた消費エネルギーの見積もり手法であ るが提案する手法はSoCアーキテクチャを参照してその振舞いをUMLモデル で表現する点で異なる．

2.1.3 差分開発における課題と改善手法

派生開発推進協議会（AFFORDD:Association For Facilitation OF Rational Derivational Development)[41]において，組込システムに限定することなく，

パッケージソフトや制御系ソフト，エンタープライズの領域も含めて，差分開発 における効果的な開発手法の開発や普及の推進が行われている. 派生開発推進協 議会において提唱されている開発アプローチであるXDDP(eXtreme Derivative Development Process) を,差分開発に適用した事例が報告されている[42],[43].

この開発アプローチは，要求定義の工程における成果物である要件から変更の 影響を分析，ソースコードの修正対象を特定して効率良く，高い品質で差分を ソースコードに実装することを目的とするアプローチである．このアプローチ は差分開発の効率化が目的であるが，アーキテクチャ設計やシステム設計の工 程が省略されている既存の差分開発の問題点の解決を目指すものではない．つ まり上流工程における品質の検証等のフロントローディングへの対応を意図し て段階的な詳細化を適用するトップダウン開発のアプローチとは異なり，ボト ムアップ開発そのものである．