権藤 正樹（ごんどう まさき）
イーソル株式会社

T-Engine／T-KernelとeBinderを組み合せた開発環境

図1　パーツパッケージ選択画面

T-Engineはハードウェア規格の一定の標準化と、OS環境（T-Kernel）の標準化をベースにしたミドルウェアの整備と流通、ネットワークセキュリティをキーワードとしたリアルタイムシステムの開発プラットフォームです。標準化により、ミドルウェアの流通を円滑にすることによって、ソフトウェア再利用による開発コストと開発期間の短縮を図ります。
リアルタイムOS向け開発環境であるeBinderもこのT-Engineの考え方にフィットする特徴を備えています。
eBinderは、一般的なIDE（Integrated Development Environment：統合開発環境）が持つプログラムのコンフィギュレーション機能、ビルド機能、デバッガ機能などを、ソフトウェア部品とリアルタイムOSにフォーカスを当てた機能として提供しています。また、ボードごとの環境がすぐに使用できるようにBSPを提供しています。
以下にT-EngineとeBinderを組み合せた開発環境の特徴を述べていきます。

●ラピッドプロトタイピング

T-Engineの開発キットとeBinder for T-Engineをセットアップし、eBinderのプロジェクトで必要なパッケージを選択すると、システムのひな型が構成されます。各パッケージの使用方法は、自動的にプロジェクトに追加されるリファレンスを参照します。
選択したパッケージのコンフィギュレーションを行えば、ターゲットに接続して各パッケージを利用したアプリケーションを作成できます。ダイナミックローディング機能を利用して、段階的にモジュール度の高いアプリケーションを作成し、プロトタイプシステムを素早く構築することができます。

●ソフトウェア部品のサポート

eBinderは、ソフトウェア部品を“パーツパッケージ”と呼ばれる単位で管理します。パーツパッケージには、ソフト部品のプログラム（ソースまたはバイナリ）のほか、コンフィギュレーション情報やビルド設定情報、そしてデバッグや検証時に使用するサポートプログラム（ソースまたはバイナリ）等が含まれています。パーツパッケージは、プロジェクトで使用可能なものがeBinderで表示され（図1）、選択することで自動的にプロジェクトにビルド情報、コンフィギュレーション情報、デバッグ関連情報が取り込まれます。これにより、そのソフト部品に依存したビルド情報や、コンフィギュレーション情報、そしてデバッグ／検証時に力を発揮する管理データやAPIの情報がeBinderで使用できるようになります。

●マルチプログラミング環境

図2　タスクプリエンプション		図3　排他制御による優先度逆転

リアルタイムシステムの構築では、“良いタスク”を作ることがポイントです。
マルチタスク環境では、自分のタスクは基本的にいつ他のタスクやハンドラによって処理が中断されるかわかりません（図2）。
OSの排他制御機能を利用して、中断しないようにすることは可能ですが、この排他制御を多用するとシステムの即応性が低下したり、処理優先度の逆転等が発生したりするため、最低限の使用に留める必要があります（図3）。

図4　タスクコンテキストデバッグ

このような要件が十分に考慮、検証されていることが“良いタスク”の条件です。
しかし自分が作成したタスクがこのような条件を満たしているかどうか検証するのは容易ではありません。特にICE等のデバッガを使用して、割込み等すべてロックされた状態でステップ等の実行制御を行っている場合、通常のシステムではありえない環境でのテストとなるため、ランニングテスト等の検証の最終フェーズまで問題が発覚しない場合があります。

eBinderのデバッガは、タスク単位の実行制御が行えます。この場合、ブレークするのはアタッチ（指定）したタスクのみとなるため、実際のシステムの振る舞いと同じ状況で検証を行うことができます（図4）。
また、複数のタスクを同時に検証することも可能です。
このタスク単位の開発ができるeBinderの機能を利用することによって、高品質なプログラム（タスク）を自然に作成することができます。

eBinderを使ったT-Engine上でのソフトウェア開発

それではeBinderを使ってどのように T-Engine上で動作するプログラムを作成するか具体的に見ていこうと思います。

●開発モデル概要

図5　ブートイメージ構成

eBinderを利用した場合、BSPが提供されているため、入手したその時点からカーネルがフルに動作します。よってカーネルとeBinderのターゲットモジュールを含むブートイメージを作成し、それをターゲットにロードします（図5）。
このイメージには、OSと最低限のドライバモジュール等が含まれているだけで、アプリケーションから見た場合は、いわゆる初期タスクのみが動作している状態になっています。
ブートイメージにまだ含まれていない、作成対象のプログラムは、eBinderのダイナミックローディング機能を使用してターゲットにロードし、シェルやデバッガによるタスク生成及び起動を行うことによって、ブートイメージ上で動作するプログラムをインクレメンタルに作成して行きます（図6）。
検証が完了したモジュールはブートイメージに追加するか、ブートイメージとは別に部分リンク（パーシャルリンク）したリンクイメージとしてまとめ、段階的に最終的なシステムのイメージを構築していきます（図7）。
検証の最終段階では、デバッグビルドではないイメージを使用します。eBinderはデバッグ情報がなくてもシェルや、システム・スナップショット取得、システムトレース取得などを行うことができるため、リリースビルドでの検証をスムースに行うことができます。
このように、常に動作するシステムを維持し、段階的にシステムを構築していくという手法が基本のモデルとなります。

図6　ダイナミックローディングを利用したプログラム作成のイメージ		図7　インクレメンタルなモジュール作成

●システム構築

図8　パーツパッケージのコンフィギュレーション

システムの構築は、プロジェクトを作成することから始めます。ウイザードに従って、必要なパッケージを選択し、各パッケージで必要なコンフィギュレーションを行っていきます（図8）。
コンフィギュレーションを行ったら、システムのビルドを行い、ブートイメージを作成します。このとき、選択されたミドルウェア等のパッケージも合わせてビルドされますが、すべてライブラリとしてビルドされるため、使用されていないモジュールはブートイメージにはリンクされません。
ターゲットにこのブートイメージをロードするには、ブートローダを使用する、ROMに書き込む、ICEでロードするなどさまざまな方法が利用できます。T-Engineの場合は、T-Monitor／T-Kernelのブートローディング機能を利用し、メモリカード等からイメージのロードを行うことができます。
このブートイメージを実際にターゲットにロードし、起動すると、最低限のシステムが実行状態となり、作成対象となるプログラムを実行し検証するためのプラットフォームが整います。

●プログラムの作成／実行／検証

eBinderでのタスクの作成は、いわゆるCプログラミングで main( ) 関数をエントリとしたプログラムを作成するのと似ています。開発者は、タスクのエントリ関数となるグローバル関数を作成します。同時にそのエントリ関数から呼び出す内部関数等もあわせて作成します。これらの関数群が複数のソースファイルに分かれる場合は、ロードが簡単に行えるように1つのオブジェクトファイルに部分リンクしておきます。これをブートしたターゲットに対してロードします。
ロードしたプログラムを実行するには、eBinderの?デバッガからエントリ関数を指定してタスクを生成してアタッチして実行、?シェルからエントリ関数を直接実行、そして?シェルでタスク生成＆起動用の関数を実行の3通りのいずれかの方法を使用します（図9）。
いずれの場合でも生成したタスクはデバッガでエントリ関数にブレークポイントを張りステップ実行等が行えます。プログラムに問題を発見した場合は、タスクを終了させ、プログラムを修正し、リロードして再度タスクを生成して検証を行います。
また、重要なのは、タスクが使用している各種システム資源をキチンと解放するクリーンアップ関数を作成しておくことです。生成したタスクの検証を中断する場合は、このクリーンアップ関数をシェルから関数実行するようにします。これは通常のシステム実行時でも、何らかの異常が発生した場合にタスクを正常に再起動するために必要です。また、このクリーンアップ関数を作成しておくことにより、そのタスクがどのようなシステム資源を使用しているのか常にトラックできます。このようなクリーンアップ関数は信頼性の高いシステムを作成する上で必須といえます。
ちなみに、作成したプログラムが参照しているカーネルのライブラリや、プロジェクト作成時に選択したミドルウェアのライブラリ等、ブートイメージのリンク時に作成したライブラリ群のオブジェクトは、ブートイメージに実際にリンクされていなくとも、作成したイメージのロード時に動的に参照が解決され、必要に応じて同時にロードが行われます。また、すでにブートイメージに含まれているオブジェクト群も、ターゲットにeBinderを接続する際にシンボルをローディングするため、これらもロード時に自動的にリンクが解決されます（図10）。
タスク間の同期／通信を検証したい場合は、対象となる複数のタスクを同時にデバッガでアタッチして、ステップ・バイ・ステップで検証できます（図11）。
作成したタスクが思ったように動作しない場合などは、システムのスナップショットを取得して状態を調べることができます（図12）。
また、複数のタスク間の協調動作を調べたり、タスクが設計した範囲内の振る舞いをしているかどうかをシステムのトレース情報を元に調査したりすることができます（図13）。
これらのツールは、カーネルのみならず、選択したソフトウェア部品のパッケージに対して透過的に機能を提供するので、自分が設計、作成していないソフトウェア部品等の動きや状態を調べる際に威力を発揮します。

図9　3つのタスク実行方法の画面		図10　リンク解決のイメージ
図11　マルチコンテキストデバッグの画面		図12　PartScopeとEvenTrekで取得できる情報とソースコードレベルの情報の関係（1）
図13　PartScopeとEvenTrekで取得できる情報と ソースコードレベルの情報の関係（2）		図14　標準部品と独自部品の違い

●ソフトウェア部品のパッケージ化

最後にソフトウェア部品のパッケージ化について少しだけ述べさせていただきます。
ソフトウェア部品は市販のものに留まらず、たとえば社内で開発したソフトウェアも対象になります。市販のものは比較的何らかの標準規格（通信プロトコル、ファイルシステム等）に準拠したものが主流になり、これらに関しては独自に作成するメリットは少ないので、有償、無償を問わず外部から入手するのが望ましい部品です。一方、これら標準部品を基盤にして、独自性を出して行くソフトウェア部品が別に存在します。これら独自ソフトウェア部品は、社内や、特定の部門、あるいは関連プロジェクトで活用することにより、その流通範囲内で作成するシステムの付加価値の再利用と技術の共有化を促進します（図14）。
eBinderでは、これらソフトウェア部品をパッケージ化するツールを提供しています。パッケージ化された部品はPart Package（パーツパッケージ）と呼ばれ、その部品のコンフィギュレーション情報、ビルド情報、検証時に状態のスナップショットやAPIトレースを収集するためのサポートプログラムと、パッケージに関するドキュメントで構成されています（図15）。
これらの情報は、プロジェクトでパッケージを選択すると自動的にeBinderに取り込まれ、パッケージの種類を問わず、透過的にeBinderの機能が利用できます（図16）。
特に、システムのスナップショット取得機能で参照できるソフトウェア部品の管理情報や、トレース解析ツールで取得できるAPIトレース情報は、サポートプログラムの実装が必要となるものの、ソフトウェア部品の直接の設計者や実装者以外がそのソフトウェア部品を利用するためには非常に有用です。たとえばソフトウェア部品が思うように動作しない場合等、そのソフトウェア部品の状態をスナップショット取得ツールで調べたり、そのソフトウェア部品がカーネルの資源等をどのように利用しているかをトレースツールで調べたりすることが、そのソフトウェア部品の実装情報（内部データ構造や、動作仕様）を知らなくとも可能になり、ソースコードレベルではなく、かつUMLレベルでもない中間の抽象度でのシステム検証が行えます（図12）。

図15　パーツパッケージの構成要素イメージ		図16　パーツパッケージがプロジェクトに取り込まれるイメージ

今後の展開

今回は誌面の都合上、簡単なタスクの作成程度までの説明しかできませんでしたが、機会があれば、アプリケーションライブラリの作成手法や、それをeBinderでパッケージとして扱うためのパッケージ化の手法等についてもお話ししたいと思います。T-Engineフォーラム（http://www.t-engine.org/）でもミドルウェア流通ワーキングループ、カーネル／デバッグワーキンググループでの基盤を検討していますので、楽しみにしていてください。

back