27. 組み込みシステム最適化に関する知識 II

シラバス: 

1. 科目の概要

組み込みシステムの最適化に必要な技術である性能評価の詳細や、限られた資源でシステムを実現するなかで求められる各種のトレードオフ、システムの全体最適化を考慮したハードウェア/ソフトウェアの組み合わせ方など、組み込みシステム最適化の具体的な手法について解説する。

2. 習得ポイント

本科目の学習により習得することが期待されるポイントは以下の通り。

3. IT知識体系との対応関係

「27.組み込みシステム最適化に関する知識Ⅱ」とIT知識体系との対応関係は以下の通り。

[シラバス:http://www.ipa.go.jp/software/open/ossc/download/Model_Curriculum_05_02.pdf]

<IT知識体系上の関連部分>

4. OSSモデルカリキュラム固有の知識

OSS モデルカリキュラム固有の知識としては組み込みシステムの開発における性能の最適化の際に利用するツールの知識がある。これにはOSSのプロファイラ、ベンチマークソフトなどが含まれる。

(網掛け部分はIT知識体系で学習できる知識を示し、それ以外はOSSモデルカリキュラム固有の知識を示している)

II-27-1. システム全体としての最適化

MPUの選択基準やハードウェアの選定、ソフトウェアからの制御方法などハードウェアで最適化できる部分は何かを解説し、さらに、資源の配分やメモリの効率的な利用方法などソフトウェアによる最適化を考える。このようなシステム全体としての最適化検討の手順について説明する。

【学習の要点】

* 組み込みアプリケーションの開発ツールやOSはMPUに依存しているため、MPUの選択は、MPUの性能、価格以外に開発ツールの提供状況なども加味する必要がある。

* 言語仕様・MPU・コンパイラの拡張・最適化機構を用いることで、実行速度・効率は高まるが、メモリの使用量とのトレードオフの関係にあることが多い。

図II-27-1. ハードウェアの観点による検討項目

【解説】

1) MPU の選択基準にかかわる諸要因

* 性能

- 高速なMPUによるソフトウェア処理を増やすことで、基板上の部品点数を減らすことができるが、高速なMPUは一般に消費電力と発熱が大きい。

- 廉価なMPUでもFPGAに多くの処理をさせることにより、十分な性能を出すことができる。また消費電力も抑えることができる。

* 価格

- 処理を専用ハードウェアに任せるとハードウェア原価が上がり、ソフトウェアの分担範囲を広めるとソフトウェア開発費が上がる。ハードウェア原価とソフトウェア開発費のトレードオフを考慮しなくてはならない。

* 開発ツール

- MPUに自社の技術戦略と合致した開発ツールがあることも重要な要因である。

2) ハードウェアの観点による検討項目

* 省電力・発熱対策

- 筐体には十分な強度と電磁波への対策が必要だが、製品の高密度化、MPUの高性能化による発熱への対策が特に重要になる。

- 回路基板の配置や、空気の流路などを考慮する必要がある。また、周辺機器とのやりとりに用いるバス数を増やしてデータ転送回数を減らすなどの対策が考えられる。

* 耐震性・耐湿性・塵埃対策

- 設置する環境の特性を考慮し、振動・湿度・塵埃への耐性を持たせる必要がある。

* EMC(Electro-Magnetic Compatibility)対策

- 組み込み機器の発する電磁波ノイズには国際規格による制限が加えられている。

- CISPR Pub.11.22(国際無線障害特別委員会), VCCI(日本情報処理装置等電波障害自主規制)などが電波障害に関する規格の例である。

* 保守性

- 在庫管理の観点から、部品の安定供給を考慮する必要がある。

- 組み込み機器の寿命を長くするために、偶発故障期間(初期故障期間以降、摩耗故障期間以前)の長い部品を利用することが望ましい。

3) ソフトウェアの観点による最適化検討項目

* 計算量を抑えるためにソフトウェアのプログラムに用いられるアルゴリズムを改善することが挙げられ、ループ内不変値のループ外への移動などのループ処理の改善や局所変数で高速に処理できる型の利用などが考えられる。

* コンパイラの拡張・最適化機構を用いて、メモリ配置の最適化、関数のレジスタ割り当て操作、アセンブラ埋め込み機能などを用いる。

* 上記の最適化により、実行速度・効率は高まるが、メモリの使用量とのトレードオフの関係にあることが多い。

II-27-2. MPUの性能最適化

MPUの性能を最適化する上で留意すべき項目は何かを説明する。また、MPUの性能評価に用いるEmbedded Microprocessor Benchmark Consortium(EEMBC)やオープンソースのベンチマークについて解説する。

【学習の要点】

* ノイマン・ボトルネックに対して、データ転送時間の短縮のために、高速のメモリデバイスを使う、キャッシュメモリを使う、システムバス幅を拡大するなどの措置をとる。

* Embedded Microprocessor Benchmark Consortium(EEMBC)は組み込みベンチマークソフトウェアの標準として扱われるようになっている。

* MediaBenchなど、オープンソースのベンチマークソフトウェアも存在する。オープンソースであるがゆえ、ベンチマークの設計に特定の団体個人の意図が入りづらいという特徴を持つ。

図II-27-2. ノイマン・ボトルネック

【解説】

1) MPUの高速化とノイマン・ボトルネック

* ノイマン型コンピュータでは、メインメモリにデータを置いてMPUで必要に応じて読み出して計算するため、MPUの高速化にメモリ周辺のシステムの速度が対応出来ない場合、性能的なボトルネックとなる。これを特にノイマン・ボトルネックと呼ぶ。

* ノイマン・ボトルネックの解消は、半導体の中と外の通信速度を揃えることであり、現実的に難しい。ノイマン・ボトルネックの緩和に以下の措置がとられる。

- 高速なメモリデバイスの利用

- MPUとメインメモリの間にキャッシュメモリを置く

- システムバス(MPUとチップセットの間のバス)、メモリバスの高速化

2) Embedded Microprocessor Benchmark Consortium(EEMBC)

EEMBCは、1997年の発足以来、参加企業数を50社以上に増やし、組み込みシステムにおけるベンチマークソフトウェアとして標準として扱われるようになっている。(Ⅰ-27-8参照)

* EEMBCは、自動車・産業機器、コンシューマ向け機器、Java ME、ネットワーク機器、OA機器、通信機器という6つの具体的な分野に照準を定めた実践的な指標である。

* Java ME用のプログラムは特にJava GrinderBenchとして公開されている。GrinderBenchは6種類の組み込みJavaで頻繁に使われる種類のプログラムをベンチマークとして採用している。具体的な内容は以下の通りである。

- コンピュータ同士によるチェスの対戦

- DES, Blowfishなどの暗号化、復号化

- XMLの構文解析

- 配列データに対するソートなどの並列処理

- PNG画像のデコード

- 正規表現によるパターンマッチング

3) MediaBenchII

* MediaBenchII (http://euler.slu.edu/~fritts/mediabench/)はUniversity of California Los Angels校(UCLA)で開発されたオープンソースのベンチマークソフトウェアであり、メディア処理を中心に構成されている。

* オープンソースのベンチマークソフトウェアであるため、特定の個人や団体に有利な操作がされにくいという特徴を持つ。

* MediaBenchIIは定期的な更新を通して、メディア産業の状況をベンチマークに反映させるようにするポリシーで運営されている。

II-27-3. システムの性能評価

システム性能の要件や性能評価の考え方、システムトータルでの性能評価方法について概説する。処理時間を計測するツールとして利用できるgprofや、OSのシステム性能を計測するツールでOSSとして提供されているHBench-OSなど、各種のツールを利用したシステム性能計測方法を説明する。

【学習の要点】

* システムの性能評価を行うためにプロファイリングツールや負荷ツールが用いられる。

* 処理計測時間の計測にはgprofなどのプロファイラが用いられる。

* OSやハードウェアのシステム性能を計測にはHBench-OSなどが用いられる。

図II-27-3. HBench-OSによるアプリケーションからハードウェアを呼び出す過程の性能測定

【解説】

1) システムの性能評価

* システムの性能評価には、システムやプログラムを動作させずに行う静的な解析と、実際に動作させて行う動的な解析とがある。

- 静的な解析では、待ち時間、MPUのクロック数、メモリ、I/O のアクセス時間、システムバスのバンド幅などから性能を積算する場合や、プログラム中の関数呼び出しやループなどを解析する場合がある。

- 動的な解析では、以下2)、3)で示すようにプロファイラやベンチマークツールが用いられる。

2) gprofを用いた動的性能評価

* gprof ( http://sourceware.org/binutils/docs-2.16/gprof/index.html )はbinutils (GNU Binary Utilities) に含まれるプロファイラである。

* 実際にコンパイル済みのプログラムを動作させることにより、リソースを消費する箇所を特定する。リソースとしては、メモリ、電力、入出力が挙げられる。

* リソース消費の静的な見積もりは難しい場合が多く、プロファイラはリソース消費の確認のためによく用いられる。

* プロファイラを用いて行う最適化の例

- 算術計算の単純化

- コード再配置 (頻繁に実行される分岐のないコードを近くにまとめる)

- メソッドのインライン展開

* 実行コマンドの例

- プログラムをオプション付きでコンパイルする(gcc –pg)

- 実行後に.outファイルを出力する(gmon.out)

- gprofツールを実行する (gprof –p a.out gmon.out)

3) HBench-OSを用いた動的性能評価

* HBench-OS ( http://www.eecs.harvard.edu/vino/perf/hbench/ )はOSやハードウェアプラットフォームにより提供されるプリミティブな機能の実行性能を測定するベンチマークツールである。

* OS依存のアプリケーションは、プロセス生成などOSの高水準プリミティブ、bcopy, mmap, forkなどのOSの低水準プリミティブを利用してCPU、メモリなどのハードウェアにアクセスする。このアクセスの階層をパフォーマンス階層と呼ぶ。

* HBench-OSはパフォーマンス階層分析やOSに対する変化の実行性能への影響を評価する際に利用できる。

* HBench-OSはプラットフォームに制御を加えた際に、ある特有のプリミティブの実行性能がどのような影響をうけるかを理解する場合や、アプリケーションレベルを含む、完全なシステムパフォーマンス階層を把握する場合に役立つ。

II-27-4. 性能に対する制約とトレードオフの考慮

コスト面からの制約や拡張性の問題など、求められる性能に対して課される組み込みシステムの制約について説明する。さらに性能と制約のトレードオフを勘案してシステムを設計した具体的な例として、MMUを持たないMPUに対応したLinuxの実装例を紹介する。

【学習の要点】

* 性能要件を定義する際には、ソフトウェアとハードウェアの制約や拡張性を考慮しなくてはならない。

* 制約としては、開発費、材料費、開発期間といったコストが、拡張性としては、ハードウェアの耐用年数、CPU・メモリ、筐体サイズなどが挙げられる。

* トレードオフを勘案する例として、uCLinux があり、uCLinuxではMMUを持たないMPUに対応する仕組みが与えられている。

図II-27-4. 性能要件定義におけるトレードオフの検討

【解説】

1) システムとしての制約条件

* コスト面からの検討として、以下の項目が挙げられる。

- 量産価格

- 部品の流用とのトレードオフ

- 材料費用

* 拡張性からの検討として、以下の項目が挙げられる。

- ハードウェア耐用年数とのトレードオフ

- MPU、メモリ等の拡張性

- 筐体サイズとのトレードオフ

2) トレードオフを考慮した例(uClinux)

* uClinux (http://uclinux.org/)はローエンドの組み込み機器など、メモリ管理ユニット(MMU)の無い組み込み環境でLinuxの利点を生かす目的で開発された。

- 1998年にPalm Pilot向けに開発されて以降、OSSとしてARM, MIPS, SPARC, Hitachi SH, Motorolla coldfireなどの環境に移植されている。

- 多数のデバイス、ファイルシステム、ネットワークプロトコルをサポートしている。

- 組み込みLinuxで最初に商業的に成功したディストリビューションと言われており、オープンソースコミュニティによる開発が継続されている。

* 通常のLinuxとuClinuxとの違いは、メモリ保護機構と仮想メモリ機構の有無である。ハードの制約を満たすために、ソフトウェア開発の負担が生じる。

- メモリ保護機構が無いため、特権プロセスでないプロセスでも意図しないメモリ領域の書き換えを起こす危険性がある。そのため、ポインタなどの扱いに注意したセキュアなプログラミングを心がけ、十分にテストをする必要がある。

- 仮想メモリ機構が無いため、カーネル部分を含めたすべてのプロセスが同じメモリ空間を使う。そのため一つのプロセスの暴走がシステム暴走につながる。また、動的なメモリ割り当ての結果、フラグメンテーションが生じやすくなってしまう。

* 通常のLinuxのコードをuClinuxに移植する際には、メモリ処理コードの更新が必要となる。

- Linuxのシステムコールのforkは、呼び出し元プロセスを複製して新しいプロセスを生成する。ネットワークサービスのデーモンプログラムなどではforkを多用している。

- uClinuxではMMUをサポートしていないため、プロセスの複製を確実に行えず、そのためfork命令も用意されていない。代わりにvfork命令が用意され、呼び出し元プロセスと新しいプロセスと双方で同じメモリ空間を利用する。

II-27-5. 性能評価の解析、シミュレーションとモニタリング

性能評価の解析的手法、シミュレーションによりシステム性能を評価するシミュレータ、および実機の性能をモニタリングする様々な手法を説明する。また具体的な例として、PIC (Programmable Intelligent Computer)を対象としたOSSのシミュレータであるgpsim, SxSim, PICEMUなどを紹介する。

【学習の要点】

* 性能評価の解析的手法として、確率ペトリネットや待ち行列理論が用いられる。

* ターゲットデバイスや入出力デバイスのシミュレーションを行う、シミュレータを用いた性能評価も行われる。シミュレータは実機でデバッグする際に生じるオーバーヘッドを削減する。

* PICを対象としたOSSのシミュレータにはgpsim、SxSimなどが存在する。

図II-27-5. 待ち行列理論(M/M/nモデル)

【解説】

1) 性能評価の解析的手法

* 性能評価の解析的手法として、確率ペトリネットや待ち行列理論が用いられる。

* 確率ペトリネット(Stochastic Petri-net)

- ペトリネットは並行動作や分散状態、および資源の概念を表現できる。

- ペトリネットの状態遷移に対して遅延時間を設定できるものを時間ペトリネットと呼ぶ。

- 時間ペトリネットでは、発火遅延時間モデル(発火可能になってからの遅延時間を設定)、発火継続時間モデル(発火してからの継続時間を設定)、プレース遅延時間モデル(プレースにトークンが来てから発火するまでの遅延時間を設定)という時間モデルが用意されている。

- 確率ペトリネットは、時間ペトリネットで導入された時間に確率を導入するモデルであり、遅延時間に指数分布する確率分布を与えたものである。

* 待ち行列理論 (Queuing Theory)

- 待ち行列理論は、オペレーションズリサーチの分野で発展した理論であり、様々な待ち行列の形態に対して、平均長、到着して行列を抜けるまでの時間などを数学的に計算する。

- 待ち行列は、ケンドールの記法(1953)を用いて「M/M/1」のように表現される。これは、「窓口に到着する人の到着する間隔(到着率)/窓口でサービスを受ける時間/窓口の数」であり、「ポアソン分布に従ったランダムな到着間隔/ポアソン分布に従ったランダムな処理時間/処理するサービスの窓口は1つ」を意味する。

- PDQ(http://www.perfdynamics.com/Tools/PDQ.html)は待ち行列理論を利用したオープンソースの性能解析ツールである。

2) シミュレーション

* ターゲットデバイスや入出力デバイスのシミュレーションを行う、シミュレータを用いた性能評価も行われる。シミュレータは実機でデバッグする際に生じるオーバーヘッドを削減する。

* PIC(Programmable Intelligent Computer)を対象としたオープンソースのシミュレータには以下の事例がある。

- Gnucap (http://www.gnu.org/software/gnucap/ ): Gnuの回路解析用パッケージ。

- NG-spice (http://sourceforge.net/projects/ngspice/): Spice3f5(UCバークレー校が開発したOSSの回路シミュレータ)の後継版ツール(Next Generation Simulation Program with Integrated Circuit Emphasis)。

- gpsim (http://www.gnupic.org/): GnuのPICマイコン用のシミュレータ。

- PICEMU (http://www.picemulator.com/): PICエミュレータ。

II-27-6. システム資源のトレードオフを考慮した性能向上

組み込みシステムにおける限られたシステム資源によるトレードオフを考慮して、性能や信頼性の向上という課題を解決するためのポイントを説明する。具体的な事例として、組み込みLinuxのCPUリソース管理を行うことで全体の性能向上を図ることを目的としたアカウンティングシステム(CABI)について説明する。

【学習の要点】

* 性能向上や信頼性向上のために、組み込みシステム特有の制限である限られたリソースを効率的に管理する枠組みが必要になる。

* 組み込みLinuxにおいて、CPUのリソースを管理することで全体の性能向上を図るアカウンティングシステムCABI (CPU Accounting & Blocking Interface)が提案されている。

図II-27-6. CPU利用の最適化による性能向上

【解説】

1) 限られたリソースにおける性能向上・信頼性向上のポイント

組み込みシステムの限られたリソースのなかでシステムの性能向上や信頼性向上を狙うには、いくつかのパターンがある。

* 組み込みシステムにおける性能向上・信頼性向上策

システム全体の性能向上や信頼性向上を目的としたシステム設計の例を示す。

- リアルタイムOSの利用

- 部分的なハードウェア化(FPGAやASICを利用した特定処理のハードウェア化)

- 必要最低限の機能に絞ったシステム環境の利用

* BusyBoxの利用

組み込みシステムに特化したLinux環境として広く利用されているものにBusyBoxがある。BusyBoxには、以下のような特長がある。

- フットプリントが小さい(ファイルサイズを小さくできる)

- システム構築が比較的容易

2) リソース管理の必要性

潤沢なリソースの存在を前提として、アドホックな利用が許されている一般のコンピュータシステムと異なり、限られたリソースを有効に使うことが求められている組み込みシステムでは、リソースを効率的に管理するフレームワークが必要になる。

* メモリリソースの管理

一般的に組み込みシステムは一次記憶、二次記憶とも容量が限られていることが多い。そのため使わないソフトウェアコンポーネントはあらかじめ削除しておいたり、メモリを効率的に利用したりするための管理が必要である。

* CPUリソース(計算リソース)の管理

CPU性能も一般的なコンピュータに比べると高くはない。そのため限られたCPUを効率的に使用するには、できるだけアイドル時間を減らして計算リソースを必要な処理に振り分けなければならない。

* 入出力デバイスの管理

入出力デバイスに対するデータのやりとりは無用な割り込みや待ち時間発生の原因となる。したがってシステム全体の最適化に向けては、入出力管理もリソース管理として欠かせない項目のひとつである。

3) アカウンティングシステムCABI (CPU Accounting & Blocking Interface)

組み込みシステムにおいて特定のアプリケーションがCPUを独占使用してしまうことがないように、CPUの利用時間を管理してシステムの全体最適化を目指すためのリソース管理システムである。IPAによる2004年度OSS活用基盤整備事業の一環として開発された。

* CABIによって実現される効果

適切なCPU利用時間管理を行うことで、以下の効果が期待される。

- 応答性の向上

- セキュリティ向上

- リアルタイム性の保証

II-27-7. システム資源のトレードオフを考慮したコスト低減

組み込みシステムにおける限られたシステム資源によるトレードオフを考慮した上でのコスト低減策について、そのポイントを示す。ライセンシングコストを削減するOSSの利用やその限界、組み込みシステムの特殊なハードウェアとそれに対応するOSSのデバイスドライバ不足など、各種の課題を示す。

【学習の要点】

* 組み込みシステムにおいても、限られた資源や数々の制約のなかで、OSSを利用することで開発コストを低減することができる。

* 低価格かつ大量に販売するような組み込み製品の場合、ライセンスコスト削減の効果は大きい。

* コスト削減のためにOSSを利用しようとしてもうまくいかない場合もある。とくに特殊なハードウェアに対するOSSの対応状況は課題のひとつである。

図II-27-7. ライセンスコスト削減による低コスト化の実現

【解説】

1) OSSの利用によるコスト低減

コスト削減はOSSの利用に対する大きな理由のひとつである。

* ライセンスコスト削減以外のOSS利用によるコスト削減効果

OSSにより、既存のソフトウェアを流用することで開発コストそのものを抑えることができる。また当該組み込みシステムのハードウェアに特化したチューニングを行うことで最適化が可能になり、結果としてハードウェアのコストも下げることが可能となる場合がある。

2) ライセンスコスト圧縮の必要性

消費者向けの組み込み機器製品は常に価格競争にさらされている。したがって組み込みシステムであることの制約に加えて開発コストや製造コストにも多くの資金を注ぎ込むことができないという制約を抱えている。

* ライセンスコストの控除

販売価格に制約が課されている組み込み製品の場合は、ソフトウェアのライセンスコストを無視することができない。全体構成のうちソフトウェアの位置付けが大きいシステムの場合、ソフトウェアのライセンスコストが製造原価の大きな比率を占めるようになるケースもある。この現象はとくに低価格で大量の製品を販売することで利益を稼ぐ小型の組み込み機器で顕著である。

* 基本ソフトウェアのライセンスコスト

商用の基本ソフトウェアに関するライセンスコストは製造原価をかさ上げする要因のひとつとして取り上げられることも多い。そのような場合、組み込みLinuxやTOPPERS等のOSSによる基本ソフトウェアを採用することでライセンスコストを排除することが可能である。

3) OSS利用時の問題点と対策

組み込みシステムでは、特殊なハードウェアや、あまり一般的ではない入出力デバイスを利用することもある。OSSの開発モデルを考えると、そのような機器への対応やマイナーなデバイスドライバの実装はされにくい。したがって、コスト削減のためにOSSを利用できない場合もある。

* 標準化対応のハードウェアを利用

ハードウェア設計の際に、できるだけ標準的なハードウェアコンポーネントを利用したり、標準的なプロトコルに対応した設計を行ったりという工夫を加える。標準的なプロトコルに対応していれば、標準化されたOSSのデバイスドライバがそのまま動作する可能性がある。

* ハードウェア情報のオープン化

特許で知財を守るなどの対策をとった後に、ハードウェア情報を公開することで対応するOSSの開発を期待する戦略もある。またIBMがPC互換機の普及戦略でとったように、ビジネス上の観点からハードウェア情報を公開する戦略もある。

* 組み込み機器用SDK(Software Development Kit)

とくにプログラマブルな情報機器といった組み込み機器においては、その機器で動作するソフトウェアを開発するためのSDKを用意してOSSとして提供することも効果的である。Googleが提供しているAndroidのように、組み込みLinuxをベースとすることで開発者が参入しやすいコミュニティを形成することもできる。

II-27-8. システム資源のトレードオフを考慮した最適化

組み込みシステムにおける限られたシステム資源を考慮した最適化について、具体的な手法や対策を説明する。具体的には、フレームワークに頼らずスクラッチからの開発、C++を止めてC言語で記述、BusyBoxを利用してLinuxを最小化する、といった方法を解説する。

【学習の要点】

* 組込システムの開発では容量の制約から高機能なライブラリやフレームワークを使えないことがしばしばある。

* 同様の理由でC++言語ではなくC言語を用いることがある。

* BusyBoxやuClibcを利用することで、OSや実行コードの容量を小さくすることが組み込み開発ではしばしば行われる。

図II-27-8. BusyBoxとuClibcの利用によるメモリ使用量の削減

【解説】

1) C言語の利用事例の多さ: 組込みソフトウェア産業実態調査

* 組込みソフトウェア産業実態調査のプロジェクト責任者向け調査 (情報処理推進機構、2007年、http://sec.ipa.go.jp/download/200706es.php)によると、C言語を利用するプロジェクトが56.4%、C++言語を利用するプロジェクトが36.6%となっている。

* これは、リソース制限の厳しい組み込み機器における開発の主流は、高機能なライブラリやフレームワークの提供されているC++言語ではなく、C言語であることを示している。

2) BusyBox (II-27-6参照)

* BusyBox (http://www.busybox.net/)はGNU coreutils、util-linuxなどに入っている、Unix系OSで共通に使われるユーティリティツールを単独の小さなツールに実装したものであり、カーネルのサイズを減らすことを目的に開発されている。”The Swiss Army Knife of Embedded Linux”と称される。

* コマンドには、chmod、dd、find、kill、cp、nslookup、initなど使用頻度の高いツールの多くが含まれる。(http://www.busybox.net/screenshot.html)

* $ /bin/busybox ls と実行することで、lsコマンドと同様の結果を返す。

* 実際には、”/bin/ls -> /bin/busybox” というシンボリックリンクが張られている。

* # make menuconfig から、BusyBoxに含めるツールをグラフィカルに選択することができる。

3) uClibc

* uClibc(http://www.uclibc.org/)は組み込みLinux向けに開発されたサイズの小さなCライブラリである。

* Cライブラリの代表例であるGNU C Library (glibc)は非常に良く用いられるが、組込システムに導入するにはサイズが大きすぎるという問題があった。そのため、サイズを削減したuClibcが開発された。

* uClibcにより、glibcを使うほぼ全てのアプリケーションを実行することができる。

* # make menuconfigからuClibcに含めるライブラリをグラフィカルに選択することができる。

* glibcを使うアプリケーションからuClibcを使うように変更するためには、ソースコードを再コンパイルすればよい。

* uClibcは通常のLinuxとMMUの無いLinux (uClinux、II-27-4参照)の双方をサポートしている。

4) buildrootツール(http://buildroot.uclibc.org/)を利用することでBusyBoxとuClibcを組み合わせたシステムを容易に構築する事ができる。

II-27-9. OSと応用ソフトウェアの組み合わせ方

組み込みシステムを最適化する際に、要求される機能を満たし、拡張性や信頼性を確保し、開発コストを削減するために、OSと応用ソフトウェアをどのように組み合わせればよいかについて説明する。技術的な観点からの説明に加え、いずれかもしくは両者にOSSを利用する際の留意点も示す。

【学習の要点】

* 組み込みシステムの制限を満たしつつ様々な要求を実現するためには、OSの機能を利用するか、自前で実装するかといった検討も必要となる。

* アプリケーションとして処理を実装するか、デバイスドライバとして処理を実装するかといった観点でも異なる。

* OSSとして提供されるソフトウェアを部分的に利用して実現する際には、ライセンスにも配慮する必要がある。

図II-27-9. 実装方法の違いによるトレードオフ

【解説】

1) OSが提供するサービスの利用と自分で実装するケースの使い分け

組み込みシステムにおいて必要な処理を行う際に、OSが提供するサービスを利用できる場合とそうでない場合がある。OSが提供するサービスを利用できる場合でも、自前で実装したほうがよい場合もある。

* メモリ確保の例

通常、C言語で動的にメモリを確保する方法はmalloc() 関数の利用が一般的である。しかしこの場合、malloc() の内部動作はブラックボックス化[1]されており、確実な最適化を行うことは難しい。メモリの利用方法が限定的であれば、sbrk() やmmap() 等のシステムコールを利用して一定のメモリ領域を確保しておき、その中でアプリケーションがメモリブロックの管理を行うことで、より最適なメモリ確保を実現することが可能である。

2) 実装方法の違いによるメリット・デメリット

また入出力や機器制御に近いところの処理においては、アプリケーションとして処理を実装するか、あるいはデバイスドライバとして実装するかといった、実装方法の違いによる得失も十分に検討する価値がある。

* アプリケーションとして実装する場合のメリット・デメリット

アプリケーションとして実装した処理は、ユーザプロセスとして動作する。そのためプログラムに不具合が存在したとしても、アプリケーションが強制終了するだけに留まりシステム全体の動作は保護される。またアプリケーションレベルの開発は比較的容易である。

* デバイスドライバとして実装する場合のメリット・デメリット

デバイスドライバとして処理を実装した場合、その部分はカーネルモードで動作するため速度的に有利な場合がある。パケットフィルタリングなど低レベル処理を実装しやすいという利点もある。また割り込みを優先させるモードもあり、準リアルタイム性を確保しやすいという利点もある。ただしその開発はアプリケーション開発と比較すると難しく、また実装に不具合があった場合にはシステム全体を暴走させる危険がある。

3) ライセンスの配慮

OSSとして提供されているオペレーティングシステムに、デバイスドライバとして実装した自前のソフトウェアを組み込む場合は、ライセンスの取り扱いに注意しなければならない場合があることに気をつける。

* Linuxへ組み込む場合

LinuxカーネルはGPLでライセンスされている。FSFの見解によれば、カーネルと一体となり動作するカーネルモジュールやデバイスドライバはGPLでなければならない。現状では、デバイスの情報を秘匿したいベンダがソースコードを公開せずにバイナリ配布しているデバイスドライバも流通している。このようなデバイスドライバをLinuxへ組み込むことについては議論があり、十分に留意する必要がある。

II-27-10. システム最適化の方式

組み込みシステムの性能向上を狙いとした設計を行う際に留意すべきポイントを示す。リアルタイム性、クリティカル性、ハードウェア容積による制約といった各種の制約のもとでシステムを最適化するための、C言語プログラムや組み込みJavaによる設計方針を解説する。

【学習の要点】

* C言語プログラムでは、言語仕様の活用、プロセッサ特性の活用、コンパイラの拡張機能・最適化機構の活用によりシステムの最適化を行う。

* 特に、コンパイラの最適化機構では、使用メモリ量の最適化を扱うことが多い。

* Javaのリアルタイム仕様であるRTSJ (Real-Time Specification for Java)ではガベージコレクションにポリシーを適用し、リアルタイム制約に対応する。

図II-27-10. RTSJの特徴

【解説】

1) 組み込み開発における最適化 – C言語のコンパイラによる最適化

* 実行効率を最適化する手法として、言語仕様の活用、プロセッサ特性の活用、コンパイラの拡張機能・最適化機構の利用、などが挙げられる。他にもリンケージエディタによる最適化などが考えられる。(Ⅰ-27-9参照)

* コンパイラの最適化においては使用するメモリ量と速度のトレードオフが発生する。以下にコンパイラによる最適化オプションの例を示す。

- インライン展開を行うと、速度は向上するが、メモリの使用量が急激に増えるため注意が必要である。

- 汎用レジスタの退避・復旧のオプションを利用する際にはメモリの使用量を抑える場合に、RAMの使用量が増大する場合があり、注意が必要である。

- 四則演算、比較、代入式の高速化を利用する場合、複数の命令による処理を避けるために、ランタイムライブラリを利用するオプションが用意されている。ランタイムライブラリを使うことで、実行速度は多少落ちるものの、メモリ使用量を抑えることができる。

2) 組み込み開発における最適化 – Java言語のリアルタイム仕様

* RTSJ (Real-Time Specification for Java)はJava言語でリアルタイムの振る舞いをどのように扱うかを規定した仕様である。

* RTSJにはリファレンス実装が提供されている。

- RTSJ Reference Implementation (RI) and Technology Compatibility Kit (TCK)

- http://www.timesys.com/java/

* スレッドのスケジューリング、メモリ管理、同期とリソース共有、非同期イベント処理などに特徴がある。

* スケジューリングフレームワークは”Schedulable”と明示されたエンティティのみをスケジューリングの対象とし、実行可能性の分析を行う。また、エラーの時のために、適切なハンドラーのスケジューリングを行う。従来のJVMに無かった優先度順位をつけることができる。

* メモリ管理に関して、以下の3種類のメモリモデルを定義している。GCによる時間の遅延がクリティカルな場合にのみ、従来のヒープメモリ以外のモデルを適用する。

- Heap : GC(ガーベッジコレクション)の対象となる。従来のモデル。

- Immortal : GCの対象とならず、回収もされない。

- Scoped : GCの対象外だが、使われなくなると回収される。

* ソフトリアルタイムのスレッドは以下のようにして生成する。

- (従来)Thread thread = new java.lang.Thread();

- (ソフトリアルタイム)RealtimeThread rtThread = new javax.realtime.RealtimeThread();