MENU
トピックス
フォーラムご案内
プレスリリース
関連イベント
製品紹介
幹事会社
関連リンク
事務局


組込みシステム向け開発環境に望まれているもの

岩田 茂人（いわた しげと）
イーソル株式会社

はじめに

ここ数年、組込み機器の需要は過去に例を見ないほどに伸びてきています。そのことは、携帯電話、PDA、インターネット家電等々がどれほど我々の生活に身近になってきたかを考えれば、容易に実感できることでしょう。また、そういった製品の機能の充実（組込まれているシステムの大型化）に反して、Time-to-Market（製品の企画から市場投入までの時間）は確実に短くなっています。最近はやりの大型ディスカウント電気機器専門店等にたびたび足を運んでみてください。製品の入替えサイクルのなんと早いこと！この状況は一般消費者にはうれしいかぎりでしょうが、組込み技術者にとっては「うれしい悲鳴」どころか、「頭痛のタネ」となっているのが正直なところでしょう。
トロン協会のホームページに「平成12年度組込みシステムにおけるリアルタイムOSシステムの利用動向とITRON仕様OSに関するアンケート調査結果」なるものが掲載されています。その中の「リアルタイムOSの問題点」の項を見てみると
1位：技術者不足（32.3％）
4位：開発環境／ツールの不足（9%）
と、なっています（図1）。別原因にはなっていますが、「開発環境／ツールの不足」は「技術者不足」の一因になっているのではないでしょうか。
システムの大規模化、Time-to-Marketの短縮という現状が、技術者不足に拍車をかけていると筆者は考えます。少ない技術者がより短期間で市場のニーズを満たすためにも、また、成熟した組込み技術者の絶対数を増やすためにも次世代型の開発環境が望まれています。本稿ではその具体像、また、技術者はそれをどう使っていくべきなのかについての話をしていこうと思います。

図1　リアルタイムOSの問題点（http://www.itron.gr.jp/survey2001/result-j.htmlより）

開発環境の現状

次世代の理想的な開発環境の姿を模索する前に、現在に至るまでに開発環境や開発手法がどのように移り変わってきたのか、また、開発者がそれをどのように使っているのかを振り返ってみたいと思います。

●クロス開発環境

まず大前提として、組込み機器向けのソフトウェア開発は、必ずクロス開発環境で行われます。クロス開発環境とは、開発ホスト（プログラムのコンパイルやリンクを行うマシン）とターゲット（コンパイルされたプログラムを実行するマシン）が異なる場合の開発環境のことです（図2）。ただし、ターゲットとして開発ホスト上で動作するシミュレータを選択した場合でもクロス開発環境と位置づける場合があります。組込み機器の開発において、クロス開発環境を使用しないなどということは、過去から現在、そして将来にわたってありえないことでしょう。この前提が、組込み技術をより難しく、より近寄り難いものにしているのかもしれません。

●最も原始的なデバッグ手法

組込みソフトウェアは、最終的には出荷される製品（実機）のROMに焼かれて動作します。ターゲット側にデバッグのしくみがまったく入っていないような状況では、コンパイル、リンクが終わってできあがったモジュールをROMに焼いて、実機で実際の動作を見てみるという方法があります。期待どおりの動作が確認できれば問題ありませんが、ほぼ100％の確率で動作はしないでしょう。その場合は、実機で起こった不具合の検証やソースコードの見直しによって、障害個所を推測、修正し、再び実機による動作確認というサイクルを繰り返すしかありません。大規模なシステム開発においては、およそ現実的な方法とは言えません。
さらに半歩進めてみましょう。ターゲットに実装されているデバッグ用の表示器具（LED等）に何らかの情報を表示させて、その情報を元に障害個所を判定するという方法があります。この方法では、開発者のアイディア次第では有効な情報を得ることが可能です。しかし、タスクが複雑に同期を取りながら動いているようなシステムでは、この方法では限界があります。この方法はターゲット初期化部分の障害発見の手助けや、ターゲット上で定期的に起こるあるイベントの確認等に使われるのが一般的なようです。

●ターゲットと開発ホストとのインタフェース

Windowsアプリケーションのデバッグのようにデバッグツールを用いてプログラムのステップ実行や、メモリダンプを行うにはどうしたらよいのでしょうか。それらを実現するために、ターゲット上のハードウェアやソフトウェアにいくつかの工夫がなされています。
・フルICEデバッガ
「CPUがどのように動いているかが監視できればプログラムの振る舞いを解析できるはずである」という思想の元に作られたしくみです。CPUの代わりにCPUとそっくりな動作をする回路を作り、さらにその動作を制御できるようにします。その回路を組込んだ機器はICE（インサーキットエミュレータ）と呼ばれます。ICEはターゲット上のCPUを接続するソケットに接続され、ターゲットボードの動作を制御します。さらにICEは、パラレルポート等で開発ホストに接続され、開発ホスト上のアプリケーションによってその実行を制御されるのが一般的です（図3）。
・JTAGデバッガ
CPUサイズの小型化、ASIC化が進むにつれて従来のICEを用いたデバッグ手法は不可能になりました。そこで、次に登場したのが元来チップにハードウェア的なテストのために設けられたJTAG（Joint Test Action Group）を利用したデバッグ手法です。エミュレーション用の回路をCPUに搭載し、JTAGポートを経由してCPUと通信することによってエミュレーション機能を実現します。この場合もJTAGデバッガはパラレルポート等で開発ホストと接続され、開発者は開発ホスト上のアプリケーションを利用して、ターゲットの実行を制御します（図4）。
・ROMモニタ型デバッガ
「フルICE用のICソケットやJTAGといったデバッグ用の特別なインタフェースがない場合にもプログラムの実行を制御したりメモリダンプをしたい」といった要望も当然のように生まれてきました。これを実現するのがROMモニタ型デバッガと呼ばれるデバッガです。ROMモニタ型デバッガはターゲットに実装されているROMにデバッグモニタと呼ばれるプログラムを焼いておき、そのプログラムが開発ホストとシリアルやパラレル経由で通信してコマンドを受け取り、プログラムの実行を制御します（図5）。ROMモニタ型デバッガは、その機能がソフト的に実現されているので、制限事項も多いですが、さまざまな応用的な機能を比較的簡単に実装することができるのが特徴です。
どの方式のデバッガにも一長一短がありますが、今回はその細かな違いはあえて問題にしません。ここで理解してもらいたいことは、開発ホストからターゲットのプログラムの実行を制御したり、CPUやメモリ内部の状態を参照するしくみがあるということです。これらのしくみを基礎として、開発ホスト上で動くデバッグツールが進化してきました。

図2　クロス開発環境

図3　フルICEデバッガ

図４　ＪＴＡＧデバッガ

図5　ROMモニタ型デバッガ

●デバッグツールの進化

図6　システムパフォーマンス解析ツール
（イーソル社の統合開発環境「eBinder」が持つ解析ツール「EvenTrek」）

図7　設計ツール
開発ホスト側からターゲットのプログラムの実行制御、状態参照等を行いプログラムの障害を取り除くのに役立てるツールをデバッグツールと呼びます。デバッグツールは前項で述べたしくみを利用してその機能を実現するわけですが、その機能も開発者のニーズに合わせて進化しています。
・オーソドックスなデバッグツール
フルICEやJTAGデバッガが提供する機能と同等の機能を提供するデバッガです。アプリケーションの形態には、コマンドラインで操作するCUIツールとマウスカーソル等で操作するGUIツールがあります。代表的な機能としては、プログラムのステップ実行、ブレークポイント機能、メモリ参照／書換え、レジスタ参照／書換え、変数参照、バックトレースといった機能があります。これらの機能で複雑なシステムの難度の高い障害を取り除くには、使用しているカーネルやミドルウェアの内部実装に精通している必要があります。カーネルの開発やデバイスドライバの開発に適したデバッグツールといえるでしょう。
・高機能なデバッグツール
組込みシステムの複雑化に伴って、従来のデバッグツールでシステム全体を把握することは困難になってしまいました。そこで、さまざまな付加機能のついたデバッグツールが登場しています。代表的なものとしては、ウィンドリバー社のTornado（トルネード）注1）やイーソル社のeBinder（イーバインダー）（図6）注2）等があげられます。これらのツールには従来のデバッガの持っていた機能のほかにシステム全体のパフォーマンス（割込み等のイベントのトレース、各コンテキストのCPU占有率、各コンテキストのスタック使用量等）を解析する機能や、ミドルウェアの内部情報を判りやすい形に加工して表示してくれる機能が付加されています。これらの機能を使うことによってそれほどシステム（カーネル、ミドルウェアやアプリケーション）の実装に精通していなくても、システム全体の動作を把握することが容易になります。
デバッグのフェーズとは関係なくなりますが、設計、コーディング、コンフィギュレーション、ビルド、ドキュメント管理に特化したツールも出現してきています。これらのツールは今までマニュアルで行っていた作業を自動化しただけでなく、他のフェーズとの連携までもを自動化したものもあります。例えば、ある設計ツールは設計が終わるとその機能に関連するヘッダファイル、ソースファイルのテンプレート、ドキュメントのテンプレートを自動生成してくれます（図7）。これらのツールをうまく使いこなせば、経験の少ない技術者にも熟練した技術者に近いレベルのアウトプット（設計書、ソース、デバッグ効率）が期待できます。

注1）http://www.windriver.co.jp/product/index_tornado.html
注2）http://www.esol.co.jp/ebinder/

●開発環境にまつわる問題点

近年、ハードウェアの高性能化が爆発的な勢いで進む中、組込みシステムの規模もそれに追随して増大しています。それでは、開発環境はそれに追いつく勢いで進化しているでしょうか。答えはNOです。その原因は、どこにあるのか探ってみましょう。

図8　道具が進化するサイクル

図9　閉じていない進化のサイクル
・閉じていない進化のサイクル
どんな道具でも進化していくにはあるサイクルがあります（図8）。
1. ある人が何かを日常に行っています（ルーチンワーク）
2. は楽をするために使っている道具にある工夫を加えます（道具の進化）
3. 人は前よりも楽をすることができるようになります（効率アップ）
4. 1に戻る
こうして、地道にサイクルを重ねながら道具は進化していくわけです。この方程式はなぜ組込みシステムの開発に当てはまらないのでしょうか。答えはいたって単純です。同じようなこと（システムの開発）をするときでも微妙な条件（CPUの種類やカーネルの種類等）の違いによって、使う道具（開発環境）が異なってくるからです（図9）。例えば、さまざまな条件下でシリアルのドライバだけを作っている人がいるとします。しかし、このルーチンワークと思われる作業をこなすにあたってでさえ、使用する開発環境はさまざまな要因に左右されて毎回変わってしまいます。結果、似たような用途の道具はそれぞれ別々の方向に進化してしまい、結局どれか1つの道具に慣れてしまった人にとって、別の方向に進化した（もちろん同じ用途に使う）道具は使い勝手の悪いだけのものになってしまいます。
・開発環境をあてにしない技術者たち
現場の開発者の生の声を拾ってみました。経験1〜2年程度の技術者の多くは、前出のTornadoやeBinderといった開発環境を求めていました。理由は以下のようなものでした。「組込みの経験が浅いので障害の原因を追求するのは暗闇の中を手探りしているような気分になる」、「高機能な開発環境のシステム解析ツール等が使えれば…」。しかし、実際には、それらのツールが自分が使用したい条件下（カスタムボード、オリジナルカーネル等）では使用できないことのほうが多いという問題もあります。
また、経験10年以上のあるベテラン開発者は以下のような意見を提供してくれました。「高機能な開発環境を熟知するよりはオーソドックスな開発環境を極めたほうが良い。理由は、ある開発環境に特化した機能に慣れてしまうと、（別の開発環境を使わなければならない状況で）応用が効かなくなる。オーソドックスな機能を応用していろいろな開発方法を身に付けたほうがトータルで良い。デバッグの8割は頭の中で行う。ツールは推測を確かめるためにしか使えない（ツールに頼るな）」。おもしろい意見だと思いました。おそらく深層心理では恒久的に使えるリッチな機能を持つ開発環境を求めているのだと思います。ただし、実際問題として10数年の経験が彼等に開発環境に対する、ある種のあきらめを持たせてしまったのでしょう。第一線で活躍する彼等がそのような意見を持っている以上、開発環境が順調に進化していくはずがありません。また、そのような状況では大規模化していくシステムに開発が追いつけなくなり、技術者には負担ばかりがかかってしまいます。

次世代の開発環境に求められるもの

開発環境の進化が思うようにいかない原因は、1つの開発環境を恒久的に使い続けられない組込み業界のしくみにありそうです。そのため、さまざまな開発環境が別々の方向に進化していき、開発環境が本来進化していく道を見失ってしまっているのではないでしょうか。問題がはっきりしたところで、これらの問題を解決する次世代の開発環境のあるべき姿を探ってみましょう。

●開発環境の進化のスピードを上げるために

開発環境の進化のサイクルを壊す要因はなんだったのでしょう。そうです、常に同じ開発環境を使い続けられないということです。では、なぜ開発環境を頻繁に変えなければならないのでしょうか。カーネルやソフトウェア部品、ハードウェアの仕様の違いが原因でした。カーネルに関してはμITRON仕様のように統一化されたオープンな仕様がすでに存在します。さらに、その仕様にデバッグ用のしくみまで盛り込もうという動きも出てきています。また、本特集で取り上げられているT-EngineプロジェクトのようにリアルタイムOS、ハードウェアの仕様を統一しようといったプロジェクトも発足されています。このような仕様をサポートする開発環境を作っていくことで、継続して1つの開発環境を使っていけるような流れを業界に作っていくことが必要なのではないでしょうか。また、一歩進んで、開発ツール自体の機能仕様をある程度統一化することができれば、開発環境の切替えが容易になり、正しい競争の中で開発環境が進化していくことが予想できます。

●開発環境に求められる役割

現在、開発環境に課せられている役割は、そのプロジェクトの開発効率を引き上げることにあると言えます。その役割を強化していくことも大切なことです。例えば、最近ではソフトウェア部品の組込みを強力にサポートするためのしくみを持った開発環境も出現しています。具体的には、コンフギュレーションの自動化、ソフトウェア部品の内部情報の参照、バージョンアップ時の対応等のしくみです。このしくみによって、完成度の高いソフトウェア部品であれば実装をまったく理解せずに開発を行うことが可能です。
また、冒頭で述べた問題点の中に「組込み技術者の不足」という問題点がありました。この問題を解決するために開発環境に教育的な要素を盛り込むといったことも考えられます。例えば、常にシステム資源を90％以上も使用してシステムが動いていた場合、それを検知して警告したり、スタックがオーバーフローした場合にやはり警告を出す機能を設けるとか、逆にシステム資源やスタックがほとんど使用されないようなシステムでは、資源の無駄使いをなくすべきである旨のアドバイスを表示する、また、システム的に異常なほど長い時間割込みが入らない場合はそういった旨の警告を表示するといったことが考えられます。そのほかにもアイディア次第でいろいろな教育的要素を盛り込めるはずです（ベテランの技術者にも重宝されそうな機能でもあります）。このような開発環境を使用すれば、新米技術者に組込みシステム開発に必要な素養が自然と身に付き、技術者不足が自然に解消していくのではないでしょうか。

技術者が忘れてはいけないもの

さて、ここまでは「開発環境に求められているもの」についていろいろと話をしてきました。要約すると、「開発環境が誰でも使える便利な道具になっていくべきだ」ということを訴えてきたつもりです。しかし、道具が便利になるということは、人がやるべきことが少しずつ減ってくることでもあります。例えば、ひと昔前のコンパイル、リンク作業を考えてみましょう。最近の若い技術者は知らないかもしれませんが、ソースコードを1行修正してコンパイル、リンクをし直すのに平気で半日かかった時代がありました。その時代の技術者は、リンクし直す前に、机上デバッグを数時間も、それこそ机に穴が空くほどしたものでした。ある意味、1文字の凡ミスが時間的に取り返しのつかない事態を招くこともあったのです。しかし、開発ホストの性能が飛躍的に向上した現在、コンパイラをコーディングのミスを見つけるためのツールのごとく考えている技術者がいます。ある意味効率的なやり方なのかもしれません。ですが、昔のように何時間もする必要はありませんから、少なくとも一度は机上デバッグをしてみてください。机上デバッグでコンパイルエラーでは検出できない障害を検出できることもあるのです。年寄りくさいことを書きましたが、道具の進歩によって必要なくなるものと、捨ててはいけないものをはっきりと区別することを忘れないでください。

まとめ

組込みシステム開発において、「技術者不足」、「開発環境／ツールの不足」といった問題を解決するためには、ハードウェア、ソフトウェア両方の仕様を統一し、さまざまな条件で同様のシステムを開発する際に同一の開発環境を使えるようにすることが必要です。また、開発環境をより進化させ、組込み技術者を育成することも必要です。一方で、技術者は開発環境の進歩によって開発技術の本質を見失うことなく、開発環境を使いこなしていくことが必要であるということも忘れないでください。
その意味でも、「T-Engine」への期待も大きく、今後も積極的に取り組んでいきたいと考えています。

back
Copyright(C)2002 T-Engine Forum all rights reserved.
mail: office@t-engine.org