µITRON4.0 仕様における新機能

前述したように，µITRON4.0仕様には従来のµITRON仕様が持っていなかった 新機能が数多く導入されている．以下では，µITRON4.0仕様における新機能を 簡単に紹介する．

例外処理のための機能

µITRON4.0仕様では，従来のµITRON仕様では実装依存として定義していな

かった例外処理の枠組みを定義している．

プロセッサが何らかの例外条件を検出すると，プロセッサはCPU例外ハンドラ 図1-2. µITRON3.0仕様とµITRON4.0仕様の機能レベル

を起動する．CPU例外ハンドラは，例外の種類毎にアプリケーションで定義す ることができる．CPU例外ハンドラはシステム全体で共通であるため，CPU例 外ハンドラ内で例外が発生したコンテキストや状況を調べ，必要であれば例外 が発生したタスクに処理を任せることができる．タスクに処理を任せるために 用意したのが，タスク例外処理機能である．

タスク例外処理機能は，UNIXのシグナル機能を簡略化したような機能で，

ITRON2仕様の強制例外に類似の機能である．タスク例外処理機能の典型的な

用途として，次のようなものが挙げられる．

• ゼロ除算などのCPU例外をタスクに伝える．

• 他のタスクに終了要求を出す．

• タスクにデッドラインが来たことを通知する．

µITRON4.0仕様が例外処理のために定義している機能は，より複雑な例外処理

機能を実現する場合にそのプリミティブとして使うことができるよう配慮し て設計されている．

データキュー

データキューは，1ワードのデータをメッセージとして通信するための機構で ある．µITRON3.0仕様では，メールボックスを実装するために，リンクリスト を使う方法とリングバッファを使う方法のいずれを用いてもよいものとして いた．それに対してµITRON4.0仕様では，ソフトウェアの移植性を向上させる ために，メールボックスの実装をリンクリストを使う方法に限定すると同時 に，リングバッファを使って実装したメールボックスと同等のデータキュー を，別のオブジェクトとして規定することとした．

データキューは，自動車制御応用において強い要求があったことから，当初自 動車制御用プロファイル独自の機能として導入する方向で検討したが，データ キューが他の応用分野においても有用であること，データキューを使わないア プリケーションにおいてはそのためのプログラムがリンクされないように実 装できることから，スタンダードプロファイルに含めることとなった．

システム状態参照機能

他で開発されるアプリケーションから呼び出されることを前提としてソフト ウェア部品を構築する場合には，ソフトウェア部品の各サービスルーチンが，

どのようなコンテキストから呼ばれても対応できることが求められる．ところ

がµITRON3.0仕様では，現在のシステム状態を調べるには，レベルEの機能で

あるref_sysを使うしか方法がなかった．ref_sysをサポートしていないカーネル

製品も多く，サポートしている場合でも，他の情報も一緒に参照できるために オーバヘッドが大きくなるという問題があった．

そこでµITRON4.0仕様には，現在のシステム状態を小さいオーバヘッドで参照

する機能として，5つのサービスコール（sns_yyy）を導入した．これらのサー ビスコールはいかなるコンテキストからも呼び出すことができ，いずれもブー

ル値を返す（エラーを返すことはない）．これらのサービスコールを用いると，

例えば，待ち状態に入るサービスコールを呼べる状態にあるかどうかを，小さ いオーバヘッドで調べることができる．

また，これらのサービスコールを用いると，排他制御が必要な処理を行うため に，一時的にCPUロック状態（またはディスパッチ禁止状態）にし，処理が終 わった後で元の状態に戻すことが容易にできる．これに関連して，µITRON3.0 仕様では，ディスパッチ禁止状態でloc_cpuを呼び出してCPUロック状態にす ると元の状態に戻す方法がなかったが，µITRON4.0仕様ではディスパッチ禁止 状態とCPUロック状態を独立な状態とすることで，この問題も解決している．

ID番号の自動割付けを行うオブジェクト生成機能

µITRON3.0仕様では，オブジェクトを動的に生成する場合には，生成するオブ ジェクトのID番号をアプリケーションで指定しなければならなかったが，大 規模なシステムにおいては，使っていないID番号を管理するのが面倒になる という問題があった．そこでµITRON4.0仕様では，生成するオブジェクトのID 番号をアプリケーションで指定するのではなく，カーネルが割り付けたID番 号を用いてオブジェクトを生成するサービスコールを新たに導入した．割り付 けられたID番号は，サービスコールの返値として，アプリケーションに返さ れる．

割込みサービスルーチン

割込み処理のアーキテクチャは，プロセッサやシステムにより違いが大きく，

標準化の難しい部分である．従来のµITRON仕様では，割込みハンドラの記述 方法はプロセッサやシステムに最適に定めるべき事項と考えて標準化してい なかったが，デバイスドライバの移植性を向上させるためには，移植性の高い 割込み処理の記述方法が求められている．

そこでµITRON4.0仕様では，従来の仕様と同様の割込みハンドラに加えて，移 植性を確保して割込み処理を記述するための割込みサービスルーチンの機能 を新たに導入した．割込みサービスルーチンは，割込みの発生源となるデバイ スのみに依存して記述できることを目指して，仕様が設計されている．

ミューテックス

厳しい時間制約を持つリアルタイムシステムを構築する場合には，優先度逆転 現象を防ぐための仕組みとして，優先度継承プロトコルや優先度上限プロトコ ルが必要になる．ミューテックスは，優先度継承プロトコルと優先度上限プロ トコルをサポートする排他制御のための機構として，µITRON4.0仕様で新たに 導入した機能である．ミューテックスの導入にあたっては，POSIXのリアルタ イム拡張におけるミューテックスの機能を参考にした．

オーバランハンドラ

厳しい時間制約を持つリアルタイムシステムを構築する場合に必要となるも う一つの機能として，µITRON4.0仕様では，タスクが与えられたプロセッサ時 間を使い切ったことを検出するためのオーバランハンドラの機能を導入した．

システムが時間制約を満たしていないことを検出する最も単純な方法は，処理 がデッドラインまでに終了しないことを検出する方法である（処理がデッドラ インまでに終了しないことの検出は，アラームハンドラなどを使うことで実現 できる）．ところがこの方法には，優先度の高いタスクがデッドラインまで実 行を続けた場合，優先度の低いタスクは連鎖的にデッドラインを守れなくなる という問題がある．この問題を解決するには，タスクが与えられたプロセッサ 時間を使い切ったことを検出するための機構が必要になる．

コンフィギュレーション方法の標準化

スタンダードプロファイルでは，タスクやセマフォなどのカーネルオブジェク トは静的に生成されることを想定している．そのため，スタンダードプロファ イルに準拠したカーネル上に実現されたアプリケーションソフトウェアを，他 のスタンダードプロファイル準拠のカーネル上に移植するためには，アプリ ケーションプログラムそのものを移植することに加えて，カーネルオブジェク トの生成情報を新しいカーネルに移行することも必要になる．

従来のµITRON仕様では，カーネルオブジェクトの生成情報を記述する方法は

標準化していなかったため，生成情報の記述方法はカーネル製品毎にかなり異 なったものとなっていた．例えば，オブジェクトの生成情報を直接C言語の構 造体の初期化データの形で記述させる製品もあれば，GUIを持ったコンフィ ギュレータを備えている製品もある．このような状況では，大規模なアプリ ケーションを他のカーネルに移植する際に，生成情報の移植工数が無視できな くなる．ここで，書き直し作業そのものの工数はそれほど大きくなくても，製 品毎に異なる記述方法を学習するのにかかる時間も工数に含めて考えるべき であることに注意して欲しい．

そこでµITRON4.0仕様では，オブジェクトの生成情報の記述方法と，それを基

にカーネルやソフトウェア部品をコンフィギュレーションする方法を標準化 している．システムコンフィギュレーションファイル中での，オブジェクトの 生成情報の記述方法を，静的APIと呼ぶ．静的APIの名称は，同じ機能を持つ サービスコールの名称を大文字で記述したものとしており，静的APIとサービ スコールでパラメータを一致させている（ただし，パケットへのポインタの代 わりに，パケットの各要素の値を“{”と“}”の中に列挙する）．これは，片方を 覚えればもう片方も自然に覚えられるという教育的効果を狙ったものである．

また，静的APIを処理するコンフィギュレータは，ID番号が与えられないオブ ジェクトにID番号を自動的に割り付ける機能を持たなければならない．これ により，別々に開発されたモジュールを組み上げてアプリケーションを構築す る場合にも，オブジェクトのID番号割付けの管理を省略することができ，大