TOPPERS第3世代カーネル（ITRON系）統合仕様書

TOPPERS第3世代カーネル（ITRON系）は，TOPPERS/ASP3カーネルをベースとして，保護機能，マルチプロセッサ，カーネルオブジェクトの動的生成などに対応した一連のカーネルで構成される．

この仕様では，TOPPERS第3世代カーネル（ITRON系）を構成する一連のカーネルの仕様を統合的に記述するが，言うまでもなく，カーネルの種類によってサポートする機能は異なる．サポートする機能をカーネルの種類毎に記述する方法もあるが，カーネルの種類はユーザ要求に対応して増える可能性もあり，その度に仕様書を修正するのは得策ではない．

そこでこの仕様では，サポートする機能を，カーネルの種類毎ではなく，カーネルの対応する機能セット毎に記述する．具体的には，保護機能を持ったカーネルを保護機能対応カーネル，マルチプロセッサに対応したカーネルをマルチプロセッサ対応カーネル，カーネルオブジェクトの動的生成機能を持ったカーネルを動的生成対応カーネルと呼ぶことにする．

ASP3カーネルは，保護機能対応カーネル，マルチプロセッサ対応カーネル，動的生成対応カーネルのいずれでもない【ASPS0001】．ただし，動的生成機能拡張パッケージを用いると，動的生成対応カーネルの機能の一部がサポートされる【ASPS0002】．

FMP3カーネルは，マルチプロセッサ対応カーネルであり，保護機能対応カーネル，動的生成対応カーネルではない【FMPS0001】．

HRP3カーネルは，保護機能対応カーネルであり，マルチプロセッサ対応カーネル，動的生成対応カーネルではない【HRPS0001】．ただし，動的生成機能拡張パッケージを用いると，動的生成対応カーネルの機能の一部がサポートされる【HRPS0009】．

HRMP3カーネルは，保護機能とマルチプロセッサの両方に対応するカーネルであり，動的生成対応カーネルではない【HRMPS0001】．

SSP3カーネルは，保護機能対応カーネル，マルチプロセッサ対応カーネル，動的生成対応カーネルのいずれでもない【SSPS0001】．

μITRON4.0仕様は，カーネルオブジェクトの動的生成機能を持っているが，保護機能を持っておらず，マルチプロセッサにも対応していない．μITRON4.0/PX仕様は，μITRON4.0仕様に対して保護機能を追加するための仕様であり，カーネルオブジェクトの動的生成機能と保護機能を持っているが，マルチプロセッサには対応していない．

TOPPERS第3世代カーネル（ITRON系）は，アプリケーションプログラムの再利用性を向上させるために，ターゲットハードウェアや開発環境の違いをできる限り隠蔽することを目指している．ただし，ターゲットハードウェアや開発環境の制限によって実現できない機能が生じたり，逆にターゲットハードウェアの特徴を活かすためには機能拡張が不可欠になる場合がある．また，同一のターゲットハードウェアであっても，アプリケーションシステムによって使用方法が異なる場合があり，ターゲットシステム毎に仕様の細部に違いが生じることは避けられない．

そこで，TOPPERS第3世代カーネル（ITRON系）の仕様は，ターゲットシステムによらずに定めるターゲット非依存（target-independent）の規定と，ターゲットシステム毎に定めるターゲット定義（target-defined）の規定に分けて記述する．この仕様書は，ターゲット非依存の規定について記述するものであり，この仕様書で「ターゲット定義」とした事項は，ターゲットシステム毎に用意するドキュメントにおいて規定する．

また，この仕様書でターゲット非依存に規定した事項であっても，ターゲットハードウェアや開発環境の制限によって実現できない場合や，実現するためのオーバヘッドが大きくなる場合には，この仕様書の規定を逸脱する場合がある．このような場合には，ターゲットシステム毎に用意するドキュメントでその旨を明記する．

この仕様では，アプリケーションシステムを構成するソフトウェアを，アプリケーションプログラム（以下，単にアプリケーションと呼ぶ），システムサービス，カーネルの3階層に分けて考える（図2-1）．カーネルとシステムサービスをあわせて，ソフトウェアプラットフォームと呼ぶ．

カーネルは，コンピュータの持つ最も基本的なハードウェア資源であるプロセッサ，メモリ，タイマを抽象化し，上位階層のソフトウェア（アプリケーションおよびシステムサービス）に論理的なプログラム実行環境を提供するソフトウェアである．

システムサービスは，各種の周辺デバイスを抽象化するソフトウェアで，ファイルシステムやネットワークプロトコルスタック，各種のデバイスドライバなどが含まれる．

また，この仕様では，プロセッサと各種の周辺デバイスの接続方法を隠蔽するためのソフトウェア階層として，システムインタフェースレイヤ（SIL）を規定する．

システムインタフェースレイヤ，カーネル，各種のシステムサービスを，上位階層のソフトウェアから使うためのインタフェースを，API（Application Programming Interface）と呼ぶ．

この仕様書では，第3章においてシステムインタフェースレイヤのAPI仕様を，第4章においてカーネルのAPI仕様を規定する．システムサービスのAPI仕様は，システムサービス毎の仕様書で規定される．

μITRON4.0仕様では，カーネルとアプリケーションの中間にあるソフトウェアをソフトウェア部品と呼んでいたが，TOPPERS組込みコンポーネントシステム（TECS）においてはカーネルもソフトウェア部品の1つと捉えることから，この仕様ではシステムサービスと呼ぶことにした．

この仕様では，カーネルがサポートするターゲットハードウェアの構成として，以下のことを想定している．

ここに挙げるのは，この仕様を策定するにあたっての想定であり，これらをすべて満たせばカーネルを動作させることができるという網羅的な要件リストではない．逆に，これらに合致しないターゲットハードウェアであっても，ターゲット依存の仕様や制約を追加することで，カーネルを動作させることが可能な場合もある．

ハードウェア構成に対する想定を追加した．TOPPERS新世代カーネル統合仕様では，(1)と(6)の2項目のみを記述していた．

あるメモリ番地は，常に同一のメモリを指すこと（オーバレイのように，異なるメモリを同一のメモリ番地でアクセスすることがないこと）【NGKI0001】．マルチプロセッサ対応カーネルにおいては，同一のメモリに対しては，各プロセッサから同一の番地でアクセスできること【NGKI0002】．

これらの想定に合致しないメモリを持つターゲットハードウェアであっても，カーネルを動作させることは可能であるが，想定に合致しないメモリは，アプリケーションの責任で使用する必要がある．特に保護機能対応するカーネルを使用する場合には，必要なパーティショニングが達成できているか，注意して使用することが必要である．

アクセスできるプロセッサが限定されたメモリを想定していないのは，そのようなメモリ構成のターゲットハードウェアが少なくなっているためである．今後，必要性が高まった場合には，アクセスできるプロセッサが限定されたメモリを想定するように仕様拡張する可能性がある．

一定時間毎にカウントアップしながら，指定した回数カウントアップしたら割込みを発生させる機能を備えた高分解能タイマを持つこと【NGKI0556】．マルチプロセッサ対応カーネルにおいては，高分解能タイマはすべてのプロセッサから読み出すことができ，指定した回数カウントアップしたら割込みを発生させる機能は，タイムイベントを処理するプロセッサ（少なくとも1つは必要）毎に持つこと【NGKI0621】．

HRMP3カーネルでは，指定した回数カウントアップしたら割込みを発生させる機能は，すべてのプロセッサに対して持つこと【HRMPS0013】．

高分解能タイマは，一定時間毎にカウントアップするタイマと，指定した回数カウントアップしたら割込みを発生させるタイマの2つのタイマで実現することもできる．この場合，マルチプロセッサ対応カーネルにおいては，一定時間毎にカウントアップするタイマは各プロセッサで共有し，指定した回数カウントアップしたら割込みを発生させるタイマは，タイムイベントを処理するプロセッサ毎に持つことが必要である．

保護機能対応カーネルにおいては，時間パーティショニングをサポートしない場合を除き，指定した回数カウントアップしたら割込みを発生させる機能を備えたタイムウィンドウタイマを持つこと【NGKI0575】．マルチプロセッサ対応カーネルにおいては，タイムウィンドウタイマはプロセッサ毎に持つこと【NGKI0576】．

オーバランハンドラ機能をサポートする場合には，指定した回数カウントアップしたら割込みを発生させる機能を備えたオーバランタイマを持つこと【NGKI0564】．マルチプロセッサ対応カーネルにおいては，オーバランタイマはプロセッサ毎に持つこと【NGKI0565】．

保護機能対応カーネルにおいては，プロセッサが特権モードと非特権モードを備えていること【NGKI0646】．また，メモリ保護のために，MMU（Memory Management Unit）またはMPU（Memory Protection Unit）を持つこと【NGKI0647】．

マルチプロセッサ対応カーネルにおいては，各プロセッサが同一の機械語命令を実行できること【NGKI0003】．

マルチプロセッサ対応カーネルにおいては，プロセッサ間の排他制御（スピンロック）を実現するための機構を持つこと【NGKI0639】．システムインタフェースレイヤ用とカーネル内部用に，少なくとも2つのスピンロックを実現できることが望ましい【NGKI0640】．

この仕様におけるAPI仕様は，ISO/IEC 9899:1990（以下，C90と呼ぶ）またはISO/IEC 9899:1999（以下，C99と呼ぶ）に準拠したC言語を，フリースタンディング環境で用いることを想定して規定している【NGKI0004】．

ただし，C90の規定に加えて，以下のことを仮定している．

上位階層のソフトウェアから，下位階層のソフトウェアを呼び出すインタフェースをサービスコール（service call）と呼ぶ．カーネルのサービスコールを，システムコール（system call）と呼ぶ場合もある．

下位階層のソフトウェアから，上位階層のソフトウェアを呼び出すインタフェースをコールバック（callback）と呼ぶ．

オブジェクトの生成情報や初期状態などを定義するために，システムコンフィギュレーションファイル中に記述するインタフェースを，静的API（static API）と呼ぶ．

下位階層のソフトウェアに関する各種の情報を取り出すために，上位階層のソフトウェアが用いるマクロを，構成マクロ（configuration macro）と呼ぶ．

サービスコールやコールバックに渡すデータをパラメータ（parameter），それらが返すデータをリターンパラメータ（return parameter）と呼ぶ．また，静的APIに渡すデータもパラメータと呼ぶ．

オブジェクトを生成するサービスコールなど，パラメータの数が多い場合やオプションのパラメータがある場合，ターゲット定義のパラメータを追加する可能性がある場合には，複数のパラメータを1つの構造体に入れ，その領域へのポインタをパラメータとして渡す【NGKI0007】．また，パラメータのサイズが大きい場合にも，パラメータを入れた領域へのポインタをパラメータとして渡す場合がある【NGKI0008】．

C言語APIでは，リターンパラメータは，関数の返値とするか，リターンパラメータを入れる領域へのポインタをパラメータとして渡すことで実現する【NGKI0009】．オブジェクトの状態を参照するサービスコールなど，リターンパラメータの数が多い場合やターゲット定義のリターンパラメータを追加する可能性がある場合には，複数のリターンパラメータを1つの構造体に入れて返すこととし，その領域へのポインタをパラメータとして渡す【NGKI0010】．

複数のパラメータまたはリターンパラメータを入れるための構造体を，パケット（packet）と呼ぶ．

サービスコールやコールバックに，パケットを置く領域へのポインタやリターンパラメータを入れる領域へのポインタを渡す場合，別に規定がない限りは，サービスコールやコールバックの処理が完了した後は，それらの領域が参照されることはなく，別の目的に使用できる【NGKI0011】．

一部の例外を除いて，サービスコールおよびコールバックの返値は，処理が正常終了したかを表す符号付き整数とする．処理が正常終了した場合には，E_OK（＝0）または正の値が返るものとし，値の意味はサービスコールまたはコールバック毎に定める【NGKI0012】．処理が正常終了しなかった場合には，その原因を表す負の値が返る【NGKI0013】．処理が正常終了しなかった原因を表す値を，エラーコード（error code）と呼ぶ．

エラーコードは，いずれも負の値のメインエラーコードとサブエラーコードで構成される【NGKI0014】．メインエラーコードとサブエラーコードからエラーコードを構成するマクロ（ERCD）と，エラーコードからメインエラーコードを取り出すマクロ（MERCD），サブエラーコードを取り出すマクロ（SERCD）が用意されている【NGKI0015】．

メインエラーコードの名称・意味・値は，カーネルとシステムサービスで共通に定める（「2.14.4 TOPPERS共通エラーコード」の節を参照）【NGKI0016】．サービスコールおよびコールバックの機能説明中の「E_XXXXXエラーとなる」または「E_XXXXXエラーが返る」という記述は，メインエラーコードとしてE_XXXXXが返ることを意味する．

サブエラーコードは，エラーの原因をより詳細に表すために用いる．カーネルはサブエラーコードを使用せず，サブエラーコードとして常に-1が返る【NGKI0017】．サブエラーコードの名称・意味・値は，サブエラーコードを使用するシステムサービスのAPI仕様において規定する【NGKI0018】．

サービスコールが負の値のエラーコード（警告と通信エラーを表すものを除く）を返した場合には，サービスコールによる副作用がないのが原則である【NGKI0019】．ただし，そのような実装ができない場合にはこの原則の例外とし，サービスコールの機能説明にその旨を記述する【NGKI0020】．

サービスコールが複数のエラーを検出するべき状況では，その内のいずれか1つのエラーを示すエラーコードが返る【NGKI0021】．

コールバックが複数のエラーを検出するべき状況では，その内のいずれか1つのエラーを示すエラーコードを返せばよい【NGKI0022】．

なお，静的APIは返値を持たない．静的APIの処理でエラーが検出された場合の扱いについては，「2.12.5 コンフィギュレータの処理モデル」の節および「2.12.6 静的APIのパラメータに関するエラー検出」の節を参照すること．

ソフトウェア割込みによりサービスコールを呼び出す場合などに用いるためのサービスコールを識別するための番号を，機能コード（function code）と呼ぶ．機能コードは符号付きの整数値とし，カーネルのサービスコールには負の値を割り付け，拡張サービスコールには正の値を用いる【NGKI0023】．

カーネルやシステムサービスを用いるために必要な定義を含むファイル．

ヘッダファイルは，原則として，複数回インクルードしてもエラーにならないように対処されている．具体的には，ヘッダファイルの先頭で特定の識別子（例えば，kernel.hなら"TOPPERS_KERNEL_H"）がマクロ定義され，ヘッダファイルの内容全体をその識別子が定義されていない場合のみ有効とする条件ディレクティブが付加されている【NGKI0024】．

カーネルまたはシステムサービスが管理対象とするソフトウェア資源を，オブジェクト（object）と呼ぶ．特に，カーネルが管理対象とするソフトウェア資源を，カーネルオブジェクト（kernel object）と呼ぶ．

オブジェクトは，種類毎に，番号によって識別する【NGKI0025】．カーネルまたはシステムサービスで，オブジェクトに対して任意に識別番号を付与できる場合には，1から連続する正の整数値でオブジェクトを識別するのを原則とする【NGKI0026】．この場合に，オブジェクトの識別番号を，オブジェクトのID番号（ID number）と呼ぶ．そうでない場合，すなわちカーネルまたはシステムサービスの内部または外部からの条件によって識別番号が決まる場合には，オブジェクトの識別番号を，オブジェクト番号（object number）と呼ぶ．識別する必要のないオブジェクトには，識別番号を付与しない場合がある【NGKI0027】．

オブジェクト属性（object attribute）は，オブジェクトの動作モードや初期状態を定めるもので，オブジェクトの登録時に指定する【NGKI0028】．オブジェクト属性にTA_XXXXが指定されている場合，そのオブジェクトを，TA_XXXX属性のオブジェクトと呼ぶ．複数の属性を指定する場合には，オブジェクト属性を渡すパラメータに，指定する属性値のビット毎論理和（C言語の"|"）を渡す【NGKI0029】．また，指定すべきオブジェクト属性がない場合には，TA_NULLを指定する【NGKI0030】．

オブジェクトの中には，プログラムが対応付けられるものがある．プログラムが対応付けられるオブジェクト（または，対応付けられるプログラム）を，処理単位（processing unit）と呼ぶ．処理単位に対応付けられるプログラムは，アプリケーションまたはシステムサービスで用意し，カーネルが実行制御する．

処理単位の実行を要求することを起動（activate），処理単位の実行を開始することを実行開始（start）と呼ぶ．

拡張情報（extended information）は，処理単位が呼び出される時にパラメータとして渡される情報で，処理単位の登録時に指定する【NGKI0031】．拡張情報は，カーネルやシステムサービスの動作には影響しない【NGKI0032】．

カーネルが実行順序を制御するプログラムの並行実行の単位をタスク（task）と呼ぶ．タスクは，処理単位の1つである．

サービスコールの機能説明において，サービスコールを呼び出したタスクを，自タスク（invoking task）と呼ぶ．拡張サービスコールからサービスコールを呼び出した場合には，拡張サービスコールを呼び出したタスクが自タスクである．

カーネルには，静的APIにより，少なくとも1つのタスクを登録しなければならない．タスクが登録されていない場合には，コンフィギュレータがエラーを報告する【NGKI0033】．

タスクが呼び出した拡張サービスコールが実行されている間は，「サービスコールを呼び出した処理単位」は拡張サービスコールであり，「自タスク」とは一致しない．そのため，保護機能対応カーネルにおいて，「サービスコールを呼び出した処理単位の属する保護ドメイン」と「自タスクの属する保護ドメイン」は，異なるものを指す．

プロセッサが実行するタスクを切り換えることを，タスクディスパッチまたは単にディスパッチ（dispatching）と呼ぶ．それに対して，次に実行すべきタスクを決定する処理を，タスクスケジューリングまたは単にスケジューリング（scheduling）と呼ぶ．

ディスパッチが起こるべき状態（すなわち，スケジューリングによって，現在実行しているタスクとは異なるタスクが，実行すべきタスクに決定されている状態）となっても，何らかの理由でディスパッチを行わないことを，ディスパッチの保留（pend dispatching）という．ディスパッチを行わない理由が解除された時点で，ディスパッチが起こる【NGKI0034】．

プロセッサが実行中の処理とは独立に発生するイベントによって起動される例外処理のことを，外部割込みまたは単に割込み（interrupt）と呼ぶ．それに対して，プロセッサが実行中の処理に依存して起動される例外処理を，CPU例外（CPU exception）と呼ぶ．

周辺デバイスからの割込み要求をプロセッサに伝える経路を遮断し，割込み要求が受け付けられるのを抑止することを，割込みのマスク（mask interrupt）または割込みの禁止（disable interrupt）という．マスクが解除された時点で，まだ割込み要求が保持されていれば，その時点で割込み要求を受け付ける【NGKI0035】．

マスクすることができない割込みを，NMI（non-maskable interrupt）と呼ぶ．

例外処理を起こすための命令（ソフトウェア割込み命令）によって発生する例外処理を，ソフトウェア割込みと呼ぶ．ソフトウェア割込みは，特権モードで実行すべきサービスコールを呼び出すなどの目的で使用される．

μITRON4.0仕様において，未定義のまま使われていた割込みとCPU例外という用語を定義した．

時間の経過をきっかけに発生するイベントをタイムイベント（time event）と呼ぶ．タイムイベントをアプリケーションに通知する機能を，タイムイベント通知（time event notification），タイムイベントにより起動され，カーネルが実行制御する処理単位を，タイムイベントハンドラ（time event handler）と呼ぶ．

タイムイベント通知の概念を追加した．

優先順位（precedence）とは，処理単位の実行順序を説明するための仕様上の概念である．複数の処理単位が実行できる場合には，その中で最も優先順位の高い処理単位が実行される【NGKI0036】．

優先度（priority）は，タスクなどの処理単位の優先順位や，データなどの配送順序を決定するために，アプリケーションが処理単位やデータなどに与える値である．優先度は，符号付きの整数型であるPRI型で表し，1から連続した正の値を用いるのを原則とする【NGKI0037】．優先度は，値が小さいほど優先度が高い（すなわち，先に実行または配送される）ものとする【NGKI0038】．

サブ優先度（sub-priority）は，優先度が同一のタスクの間の優先順位を決定するために，アプリケーションがタスクに与える値である．サブ優先度機能をサポートするカーネルにおいては，サブ優先度を使用して優先順位を決定するか否かを，優先度毎に設定することができる【NGKI0558】．サブ優先度はuint_t型で表し，値が小さいほど優先度が高い【NGKI0559】．

ASP3カーネルは，サブ優先度機能をサポートしない【ASPS0016】．ただし，サブ優先度機能拡張パッケージを用いると，サブ優先度機能を追加することができる【ASPS0017】．

FMP3カーネルは，サブ優先度機能をサポートする【FMPS0010】．

HRP3カーネルは，サブ優先度機能をサポートしない【HRPS0012】．

HRMP3カーネルは，サブ優先度機能をサポートしない【HRMPS0002】．

SSP3カーネルは，サブ優先度機能をサポートしない【SSPS0011】．

サブ優先度の概念を追加した．

カーネルが管理する時刻を，システム時刻（system time）と呼ぶ．システム時刻は，64ビット（ただし，64ビットの整数型がサポートされていないターゲットでは，32ビット）の符号無しの整数型であるSYSTIM型で表し，単位はマイクロ秒とする【NGKI0548】．

タイムイベントを発生させる時刻を指定する場合には，基準時刻（base time）からの相対時間（relative time）によって指定する【NGKI0041】．基準時刻は，別に規定がない限りは，相対時間を指定するサービスコールを呼び出した時刻となる【NGKI0042】．

相対時間は，32ビットの符号無しの整数型であるRELTIM型で表し，単位はシステム時刻と同一，すなわちマイクロ秒とする【NGKI0549】．相対時間に指定できる最大値は，4,000,000,000（66分40秒を表す）である【NGKI0550】．この値は，構成マクロTMAX_RELTIMに定義されている【NGKI0551】．

タイムイベントを発生させる時刻を相対時間で指定した場合，タイムイベントが処理されるのは，基準時刻から相対時間によって指定した以上の時間が経過した後となる【NGKI0046】．

タイムイベントが発生するまでの時間を参照する場合には，基準時刻からの相対時間として返される【NGKI0048】．基準時刻は，相対時間を返すサービスコールを呼び出した時刻となる【NGKI0049】．

タイムイベントが発生する時刻が相対時間で返された場合，タイムイベントが処理されるのは，基準時刻から相対時間として返された以上の時間が経過した後となる【NGKI0050】．何らかの理由でタイムイベントの処理が遅れ，タイムイベントが発生する時刻をすでに過ぎている場合には，相対時間として0が返される【NGKI0552】．

サービスコールで相対時間に0を指定した場合には，高分解能タイマが基準時刻後に最初にカウントアップするのをきっかけに，タイムイベントが処理される．また，1を指定した場合には，基準時刻後に2回目にカウントアップするのをきっかけに，タイムイベントが処理される．これは，基準時刻後の最初のカウントアップは，基準時刻の直後に発生する可能性があるため，ここでタイムイベントを処理すると，基準時刻からの経過時間が1以上という仕様を満たせないためである．

同様に，相対時間として0が返された場合には，それ以降の可能な限り早いタイミングでタイムイベントが処理される．1が返された場合には，基準時刻後の2回目のカウントアップをきっかけにタイムイベントが処理される．

ただし，保護機能対応カーネルで時間パーティショニングを使用する場合には，ユーザドメインに属するタイムイベントの処理は，そのユーザドメインが実行されるタイムウィンドウに切り換わるまで実行されない．詳しくは，「2.6.7 時間パーティショニング使用時のスケジューリング規則」の節を参照すること．

システム時刻（SYSTIM型）と相対時間（RELTIM型）の時間単位は，μITRON4.0仕様では実装定義としていたが，この仕様ではマイクロ秒と規定した．また，システム時刻と相対時間のビット長を定め，相対時間の解釈についてより厳密に規定した．TMAX_RELTIMは，μITRON4.0仕様に規定されていないカーネル構成マクロである．

システム時刻（SYSTIM型）と相対時間（RELTIM型）の時間単位は，TOPPERS新世代カーネル統合仕様ではミリ秒としていたが，この仕様ではマイクロ秒に変更した．また，システム時刻と相対時間のビット長を定め，相対時間に指定できる最大値を規定した．相対時間の解釈について，タイムティックを使わない実装を想定した規定に変更した．

相対時間に指定できる最大値を4,000,000,000に制限したのは，タイムイベントを発生させる時刻を，カーネル内部では32ビットの整数型で扱えるようにするためである．

サービスコールの中で待ち状態が指定した時間以上継続した場合に，サービスコールの処理を取りやめて，サービスコールからリターンすることを，タイムアウト（timeout）という．タイムアウトしたサービスコールからは，E_TMOUTエラーが返る【NGKI0052】．

タイムアウトを起こすまでの時間（タイムアウト時間）は，32ビットの符号無しの整数型であるTMO型で表し，単位はシステム時刻と同一，すなわちマイクロ秒とする【NGKI0553】．タイムアウト時間に，0より大きく，TMAX_RELTIM以下の値を指定した場合には，タイムアウトを起こすまでの相対時間を表す【NGKI0554】．すなわち，タイムアウトの処理が行われるのは，サービスコールを呼び出してから指定した以上の時間が経過した後となる．

ポーリング（polling）を行うサービスコールとは，サービスコールの中で待ち状態に遷移すべき状況になった場合に，サービスコールの処理を取りやめてリターンするサービスコールのことをいう．ここで，サービスコールの処理を取りやめてリターンすることを，ポーリングに失敗したという．ポーリングに失敗したサービスコールからは，E_TMOUTエラーが返る【NGKI0055】．

ポーリングを行うサービスコールでは，待ち状態に遷移することはないのが原則である【NGKI0056】．そのため，ポーリングを行うサービスコールは，ディスパッチ保留状態であっても呼び出せる【NGKI0057】．ただし，サービスコールの中で待ち状態に遷移する状況が複数ある場合，ある状況でポーリング動作をしても，他の状況では待ち状態に遷移する場合がある．このような場合の振舞いは，該当するサービスコール毎に規定する【NGKI0058】．

タイムアウト付きのサービスコールは，別に規定がない限りは，タイムアウト時間にTMO_POL（＝0）を指定した場合にはポーリングを行い，TMO_FEVR（＝UINT32_MAX）を指定した場合にはタイムアウトを起こさないものとする【NGKI0059】．

相対時間の0（基準時刻後の最初のカウントアップをきっかけにタイムイベントを処理）とタイムアウト時間のTMO_POL（＝0，ポーリング）は意味が異なる．具体的な例として，dly_tsk(0U)を呼び出したタスクは待ち状態に遷移するのに対して，tslp_tsk(TMO_POL)を呼び出したタスクは待ち状態には遷移しない．

［NGKI0019］の原則より，サービスコールがタイムアウトした場合やポーリングに失敗した場合には，サービスコールによる副作用がないのが原則である．ただし，そのような実装ができない場合にはこの原則の例外とし，どのような副作用があるかをサービスコール毎に規定する．

タイムアウト付きのサービスコールを，タイムアウト時間をTMO_POLとして呼び出した場合には，ディスパッチ保留状態で呼び出すとE_CTXエラーとなることを除いては，ポーリングを行うサービスコールと同じ振舞いをする．また，タイムアウト時間をTMO_FEVRとして呼び出した場合には，タイムアウトなしのサービスコールと全く同じ振舞いをする．

タイムアウト時間（TMO型）の時間単位は，μITRON4.0仕様では実装定義としていたが，この仕様ではマイクロ秒と規定した．また，TMO型を符号無し整数に変更するとともに，ビット長を定め，指定できる最大値を規定した．

タイムアウト時間（TMO型）の時間単位は，TOPPERS新世代カーネル統合仕様ではミリ秒単位としていたが，この仕様ではマイクロ秒に変更した．また，TMO型を符号無し整数に変更するとともに，ビット長を定め，指定できる最大値を規定した．

ディスパッチ保留状態において，ポーリングを行うサービスコールを呼び出せる場合があるのに対して，タイムアウト付きのサービスコールをタイムアウト時間をTMO_POLとして呼び出すとエラーになるのは，割込み優先度マスクが全解除でない状態やディスパッチ禁止状態では，自タスクを広義の待ち状態に遷移させる可能性のあるサービスコール（タイムアウト付きのサービスコールはこれに該当）を呼び出すことはできないという原則［NGKI0175］と［NGKI0179］があるためである．

サービスコールの中で待ち状態に遷移すべき状況になった時，サービスコールの処理を継続したままサービスコールからリターンする場合，そのサービスコールをノンブロッキング（non-blocking）という．処理を継続したままリターンする場合，サービスコールからはE_WBLKエラーが返る【NGKI0060】．E_WBLKは警告を表すエラーコードであり，サービスコールによる副作用がないという原則は適用されない【NGKI0061】．

サービスコールからE_WBLKエラーが返った場合には，サービスコールの処理は継続しているため，サービスコールに渡したパラメータまたはリターンパラメータを入れる領域はまだアクセスされる可能性があり，別の目的に使用することはできない【NGKI0062】．継続している処理が完了した場合や，何らかの理由で処理が取りやめられた場合には，コールバックを呼び出すなどの方法で，サービスコールを呼び出したソフトウェアに通知するものとする【NGKI0063】．

ノンブロッキングの指定は，タイムアウト時間にTMO_NBLK（＝UINT32_MAX-1）を指定することによって行う【NGKI0064】．ノンブロッキングの指定を行えるサービスコールは，指定した場合の振舞いをサービスコール毎に規定する【NGKI0065】．

ノンブロッキングは，システムサービスでサポートすることを想定した機能である．カーネルは，ノンブロッキングの指定を行えるサービスコールをサポートしていない．

プロセッサが処理単位の実行に要した時間をプロセッサ時間（processor time）と呼ぶ．プロセッサ時間は，32ビットの符号無しの整数型であるPRCTIM型で表し，単位はマイクロ秒とする【NGKI0573】．プロセッサ時間の計測精度は，ターゲットに依存する【NGKI0574】．

プロセッサ時間は，処理単位の実行に要した時間であり，システム時刻の経過とは独立である．そのため，システム時刻の調整やドリフトの調整によって，プロセッサ時間の進み方が変わることはない．

μITRON4.0仕様およびTOPPERS新世代カーネル統合仕様では，プロセッサ時間の概念はオーバランハンドラ機能のみで使用され，データ型の名称もOVRTIMであったが，この仕様では，時間パーティショニング機能でも使用するため，概念を一般化し，PRCTIM型に改名した．また，PRCTIM型のビット長を定めた．

この節では，保護機能に関連する主な概念について説明する．この節の内容は，保護機能対応カーネルにのみ適用される．

ユーザドメインに属する処理単位がタスクの優先度を変更する際に，指定できるタスク優先度を制限することができる機能を廃止した．

保護機能対応カーネルは，処理単位が，許可されたカーネルオブジェクトに対して，許可された種別のアクセスを行うことのみを許し，それ以外のアクセスを防ぐアクセス保護機能を提供する【NGKI0066】．

アクセス制御の用語では，処理単位が主体（subject），カーネルオブジェクトが対象（object）ということになる．

保護機能対応カーネルにおいては，メモリ領域をカーネルオブジェクトとして扱い，アクセス保護の対象とする【NGKI0067】．カーネルがアクセス保護の対象とする連続したメモリ領域を，メモリオブジェクト（memory object）と呼ぶ．メモリオブジェクトは，互いに重なりあうことはない【NGKI0068】．

メモリオブジェクトは，その先頭番地によって識別する【NGKI0069】．言い換えると，先頭番地がオブジェクト番号となる．

メモリオブジェクトの先頭番地とサイズには，ターゲットハードウェアでメモリ保護が実現できるように，ターゲット定義の制約が課せられる【NGKI0070】．

保護機能を提供するために用いるカーネルオブジェクトの集合を，保護ドメイン（protection domain）と呼ぶ．保護ドメインは，保護ドメインIDと呼ぶID番号によって識別する【NGKI0071】．

カーネルオブジェクトは，たかだか1つの保護ドメインに属する．処理単位は，いずれか1つの保護ドメインに属さなければならないのに対して，それ以外のカーネルオブジェクトは，いずれの保護ドメインにも属さないことができる【NGKI0072】．いずれの保護ドメインにも属さないカーネルオブジェクトを，無所属のカーネルオブジェクト（independent kernel object）と呼ぶ．

処理単位がカーネルオブジェクトにアクセスできるかどうかは，処理単位が属する保護ドメインにより決まるのが原則である【NGKI0073】．すなわち，カーネルオブジェクトに対するアクセス権は，処理単位ではなく，保護ドメイン単位で管理される．このことから，ある保護ドメインに属する処理単位がアクセスできることを，単に，その保護ドメインからアクセスできるという．

ただし，タスクのユーザスタック領域は，ターゲット定義での変更がない限りは，そのタスク（とカーネルドメインに属する処理単位）のみがアクセスできる（「2.11.6 ユーザタスクのユーザスタック領域」の節を参照）．これは，［NGKI0073］の原則の例外となっている．

デフォルトでは，保護ドメインに属するカーネルオブジェクトは，同じ保護ドメイン（とカーネルドメイン）のみからアクセスできる【NGKI0075】．また，無所属のカーネルオブジェクトは，すべての保護ドメインからアクセスできる【NGKI0076】．詳しくは，「2.11.3 デフォルトのアクセス許可ベクタ」の節を参照すること．

システムには，カーネルドメイン（kernel domain）と呼ばれる保護ドメインが1つ存在する【NGKI0077】．カーネルドメインに属する処理単位は，プロセッサの特権モードで実行される【NGKI0078】．また，すべてのカーネルオブジェクトに対して，すべての種別のアクセスを行うことが許可される【NGKI0079】．この仕様で，「ある保護ドメイン（またはタスク）のみからアクセスできる」といった場合でも，カーネルドメインからはアクセスすることができる．

カーネルドメイン以外の保護ドメインを，ユーザドメイン（user domain）と呼ぶ．ユーザドメインに属する処理単位は，プロセッサの非特権モードで実行される【NGKI0080】．また，どのカーネルオブジェクトに対してどの種別のアクセスを行えるかを制限することができる【NGKI0081】．

ユーザドメインには，1から連続する正の整数値の保護ドメインIDが付与される【NGKI0082】．カーネルドメインの保護ドメインIDは，TDOM_KERNEL（＝-1）である【NGKI0083】．

この仕様では，システムに登録できるユーザドメインの数は，32個以下に制限する【NGKI0084】．これを超える数のユーザドメインを登録した場合には，コンフィギュレータがエラーを報告する【NGKI0085】．

ユーザドメインは，システムコンフィギュレーションファイル中にユーザドメインの囲みを記述することで，カーネルに登録する（「2.12.3 保護ドメインの指定」の節を参照）．ユーザドメインを動的に生成する機能は，現時点では用意していない．

保護機能対応でないカーネルは，カーネルドメインのみをサポートしているとみなすことができる．

μITRON4.0/PX仕様のシステムドメイン（system domain）は，現時点ではサポートしない．システムドメインは，それに属する処理単位が，プロセッサの特権モードで実行され，カーネルオブジェクトに対するアクセスを制限することができる保護ドメインである．

カーネルドメインに属するタスクをシステムタスク（system task），ユーザドメインに属するタスクをユーザタスク（user task）と呼ぶ．

特権モードで実行されるタスクをシステムタスク，非特権モードで実行されるタスクをユーザタスクと定義する方法もあるが，ユーザタスクであっても，サービスコールの実行中は特権モードで実行されるため，曖昧性を避けるために上記の定義とした．

μITRON4.0/PX仕様のシステムドメインに属するタスクは，システムタスクと呼ぶことになる．

あるカーネルオブジェクトに対するある種別のアクセスが，どの保護ドメインに属する処理単位に許可されているかを表現するビットパターンを，アクセス許可パターン（access permission pattern）と呼ぶ．アクセス許可パターンの各ビットは，1つのユーザドメインに対応する【NGKI0086】．カーネルドメインには，すべてのアクセスが許可されているため，カーネルドメインに対応するビットは用意されていない．

アクセス許可パターンは，符号無し32ビット整数に定義されるデータ型（ACPTN）で保持し，値が1のビットに対応するユーザドメインにアクセスが許可されていることを表す【NGKI0087】．そのため，2つのアクセス許可パターンのビット毎論理和（C言語の"|"）を求めることで，アクセスを許可されているユーザドメインの和集合（union）を得ることができる．また，2つのアクセス許可パターンのビット毎論理積（C言語の"&"）を求めることで，アクセスを許可されているユーザドメインの積集合（intersection）を得ることができる．

アクセス許可パターンの指定に用いるために，指定したユーザドメインのみにアクセスを許可することを示すアクセス許可パターンを構成するマクロ（TACP）が用意されている【NGKI0088】．また，カーネルドメインのみにアクセスを許可することを示すアクセス許可パターンを表す定数（TACP_KERNEL）と，すべての保護ドメインにアクセスを許可することを示すアクセス許可パターンを表す定数（TACP_SHARED）が用意されている【NGKI0089】．

カーネルオブジェクトに対するアクセスは，カーネルオブジェクトの種類毎に，通常操作1，通常操作2，管理操作，参照操作の4つの種別に分類されている【NGKI0090】．あるカーネルオブジェクトに対する4つの種別のアクセスに関するアクセス許可パターンをひとまとめにしたものを，アクセス許可ベクタ（access permission vector）と呼び，次のように定義されるデータ型（ACVCT）で保持する【NGKI0091】．

カーネルオブジェクトの種類毎のアクセスの種別の分類については，「5.8 カーネルオブジェクトに対するアクセスの種別」の節を参照すること．

μITRON4.0/PX仕様では，アクセス許可ベクタを，1つまたは2つのアクセス許可パターンで構成することも許しているが，この仕様では4つで構成するものと決めている．

保護機能対応カーネルでは，サービスコールは，ソフトウェア割込みによって呼び出すのが基本である．サービスコール呼出しを通常の方法で記述した場合，サービスコールはソフトウェア割込みによって呼び出される【NGKI0092】．

一般に，ソフトウェア割込みによるサービスコール呼出しはオーバヘッドが大きい．そのため，カーネルドメインに属する処理単位からは，関数呼出しによってサービスコールを呼び出すことで，オーバヘッドを削減することができる．そこで，カーネルドメインに属する処理単位から関数呼出しによってサービスコールを呼び出せるように，以下の機能が用意されている．

カーネルドメインに属する処理単位が実行する関数のみを含んだソースファイルでは，カーネルヘッダファイル（kernel.h）をインクルードする前に，TOPPERS_SVC_CALLをマクロ定義することで，サービスコール呼出しを通常の方法で記述した場合に，サービスコールは関数呼出しによって呼び出される【NGKI0093】．

また，カーネルドメインに属する処理単位が実行する関数と，ユーザドメインに属する処理単位が実行する関数の両方を含んだソースファイルでは，関数呼出しによってサービスコールを呼び出すための名称を作るマクロ（SVC_CALL）を用いることで，サービスコールは関数呼出しによって呼び出される【NGKI0094】．例えば，act_tskを関数呼出しによって呼び出す場合には，次のように記述すればよい．

拡張サービスコールを，関数呼出しによって呼び出す方法は用意されていない．カーネルドメインに属する処理単位が，関数呼出しによって拡張サービスコールとして登録した関数を呼び出すことはできるが，その場合，呼び出したのは単なる関数であるとみなされ，拡張サービスコールであるとは扱われない．

この節では，保護機能対応カーネルにおける時間パーティショニングに関連する主な概念について説明する．この節の内容は，保護機能対応カーネルにのみ適用される．

時間パーティショニングの機能を新たに導入した．

保護ドメインを繰り返し実行する基本的な周期を，システム周期（system cycle）と呼ぶ．

保護ドメインをどのように繰り返し実行するかは，システム動作モード（system operating mode）毎に設定することができる．システム動作モードは，システム動作モードIDと呼ぶID番号によって識別する【NGKI0577】．

保護ドメインを繰り返し実行するのを停止するシステム動作モードとして，システム周期停止モードが用意されている【NGKI0578】．システム周期停止モードのID番号は，TSOM_STP（＝-1）である【NGKI0579】．

システム周期内の連続した時間区間をタイムウィンドウ（time window）と呼ぶ．タイムウィンドウは，システム動作モード毎に登録することができる【NGKI0580】．

システム周期内で，タイムウィンドウに含まれない時間区間を，アイドルウィンドウ（idle window）と呼ぶ．

タイムウィンドウは，1つのユーザドメインに割り当てる【NGKI0581】．1つのユーザドメインに，任意の数のタイムウィンドウを割り当てることができる【NGKI0582】．すなわち，1つのユーザドメインに複数のタイムウィンドウを割り当てることができるし，タイムウィンドウを割り当てないユーザドメインがあっても良い．

どのシステム動作モードにおいてもタイムウィンドウを割り当てられていないユーザドメインが1つ以上ある場合，スケジューリング上は，それらのユーザドメインをまとめて1つのユーザドメインであるかのように扱う【NGKI0583】．タイムウィンドウを割り当てられていないユーザドメインを1つにまとめたものを，アイドルドメイン（idle domain）と呼ぶ．あるオブジェクトが「アイドルドメインに属する」といった場合には，タイムウィンドウを割り当てられていないユーザドメインのいずれかに属することを意味する．

カーネルドメインにタイムウィンドウを割り当てることはできない．カーネルドメインに属する処理単位（ユーザタスクから呼び出された拡張サービスコールを除く）は，常に（すなわち，すべてのタイムウィンドウおよびアイドルウィンドウ内で）実行することができる【NGKI0623】．

マルチプロセッサ対応カーネルでは，タイムウィンドウは，プロセッサ毎に割り当てることができる【NGKI0624】．アイドルドメインにまとめられるのは，すべてのシステム動作モードにおいて，どのプロセッサに対してもタイムウィンドウを割り当てられていないユーザドメインである【NGKI0627】．

あるユーザドメインに対して，システム動作モードAにおいてはタイムウィンドウが割り当てられており，システム動作モードBにおいては割り当てられていない場合を考える．この場合，そのユーザドメインは，システム動作モードAにおいてタイムウィンドウを割り当てられているため，アイドルドメインにはまとめられない．そのため，システム動作モードBでは，そのユーザドメインは全く実行されない．

この節では，マルチプロセッサ対応に関連する主な概念について説明する．この節の内容は，マルチプロセッサ対応カーネルにのみ適用される．

マルチプロセッサに対応するために用いるカーネルオブジェクトの集合を，クラス（class）と呼ぶ．クラスは，クラスIDと呼ぶID番号によって識別する【NGKI0095】．カーネルオブジェクトは，たかだか1つのクラスに属する【NGKI0096】．

カーネルがどのようなクラスをサポートするかと，それらの識別名とID番号は，ターゲット定義である【NGKI0644】．カーネルヘッダファイル（kernel.h）のターゲット依存部において，各クラスの識別名が，クラスIDにマクロ定義される【NGKI0645】．

処理単位を実行するプロセッサを静的に決定する機能分散型のマルチプロセッサシステムでは，プロセッサ毎にクラスを設ける方法が典型的である．それに対して，対称型のマルチプロセッサシステムで，処理単位のマイグレーションを許す場合には，プロセッサ毎のクラスに加えて，どのプロセッサでも実行できるクラスを（システム中に1つまたは初期割付けプロセッサ毎に）設ける方法が典型的である．

マルチプロセッサ対応でないカーネルは，カーネルによって規定された1つのクラスのみをサポートしているとみなすこともできる．

たかだか1つの処理単位のみを同時に実行できるハードウェアの単位を，プロセッサ（processor）と呼ぶ．プロセッサは，プロセッサIDと呼ぶID番号によって識別する【NGKI0098】．

複数のプロセッサを持つシステム構成をマルチプロセッサ（multiprocessor）と呼ぶ．マルチプロセッサ対応カーネルは，同時に複数の処理単位を実行することができる【NGKI0099】．

カーネルがサポートするプロセッサの数と各プロセッサの識別名は，ターゲット定義である【NGKI0642】．カーネルヘッダファイル（kernel.h）のターゲット依存部において，TNUM_PRCIDがサポートしているプロセッサ数に，各プロセッサの識別名がプロセッサIDに，それぞれマクロ定義される【NGKI0643】．

システムの初期化時と終了時に特別な役割を果たすプロセッサを，マスタプロセッサ（master processor）と呼び，システムに1つ存在する【NGKI0100】．どのプロセッサをマスタプロセッサとするかは，ターゲット定義である【NGKI0101】．マスタプロセッサ以外のプロセッサを，スレーブプロセッサ（slave processor）と呼ぶ．なお，カーネル動作状態では，マスタプロセッサとスレーブプロセッサの振舞いに違いはない【NGKI0102】．

処理単位は，後述のマイグレーションが発生しない限りは，いずれか1つのプロセッサに割り付けられて実行される【NGKI0103】．処理単位を実行するプロセッサを，割付けプロセッサと呼ぶ．また，処理単位が登録時に割り付けられるプロセッサを，初期割付けプロセッサと呼ぶ．

処理単位によっては，処理単位の登録後に，割付けプロセッサを変更することが可能である【NGKI0104】．処理単位の登録後に割付けプロセッサを変更することを，処理単位のマイグレーション（migration）と呼ぶ．

割付けプロセッサを変更できる処理単位に対しては，処理単位を割り付けることができるプロセッサ（これを，割付け可能プロセッサと呼ぶ）を制限することができる【NGKI0105】．

タスクの初期割付けプロセッサや割付け可能プロセッサなど，カーネルオブジェクトをマルチプロセッサ上で実現する際に設定すべき属性は，そのカーネルオブジェクトが属するクラスによって定まる．

各クラスは，ターゲット定義の属性として，初期割付けプロセッサと割付け可能プロセッサ（初期割付けプロセッサを含む1つまたは複数のプロセッサ）の情報を持つ【NGKI0107】．また，保護機能に対応しないカーネルにおいては，オブジェクトを生成する際にコンフィギュレータが確保するメモリ領域（オブジェクトの管理ブロックなど）の配置場所も，ターゲット定義である【NGKI0664】．

初期割付けプロセッサと割付け可能プロセッサを，カーネルオブジェクト毎に設定できるようにしなかったのは，これらの属性をアプリケーション設計者が個別に設定するよりも，ターゲット依存部の実装者が有益な組み合わせをあらかじめクラスとして用意しておく方が良いと考えたためである．

タイムイベントの処理は，ターゲット定義の1つまたは複数のプロセッサで行う【NGKI0622】．タイムイベントを処理するプロセッサを，タイムイベント処理プロセッサと呼ぶ．

HRMP3カーネルでは，すべてのプロセッサがタイムイベント処理プロセッサである【HRMPS0011】．すなわち，すべてのプロセッサがタイムイベントの処理を行う．

TOPPERS新世代カーネル統合仕様では，プロセッサ毎にシステム時刻を持つローカルタイマ方式と，システム全体で1つのシステム時刻を持つグローバルタイマ方式のどちらかを用いることとしていたが，この仕様では，システム全体で1つのシステム時刻を持つものと決めた．ただし，タイムイベント処理プロセッサを複数設けられることから，TOPPERS新世代カーネル統合仕様のグローバルタイマ方式とも異なる．これに伴い，ローカルタイマ方式とグローバルタイマ方式という用語を廃止した．

保護ドメイン毎の標準セクションを廃止した．

プログラムのオブジェクトコードとデータを含むファイルを，オブジェクトモジュール（object module）と呼ぶ．オブジェクトファイルとライブラリは，オブジェクトモジュールである．

オブジェクトモジュールに含まれるセクションの配置対象となる同じ性質を持った連続したメモリ領域をメモリリージョン（memory region）と呼ぶ．

メモリリージョンは，文字列によって識別する【NGKI0112】．メモリリージョンを識別する文字列を，メモリリージョン名と呼ぶ．

メモリリージョンは，μITRON4.0/PX仕様にはない概念である．

コンパイラに特別な指定をしない場合に出力するセクションを，標準のセクション（standard sections）と呼ぶ．ターゲット定義で，それ以外のセクションを標準のセクションと扱う場合もある【NGKI0113】．

保護機能対応カーネルにおいては，カーネルに登録されたオブジェクトモジュールやセクションをどの番地に配置するかはコンフィギュレータにより決定され，リンカスクリプトもコンフィギュレータにより生成されるのが標準である．これを，自動メモリ配置と呼ぶ．

それに対して，オブジェクトモジュールやセクションをどの番地に配置するかを，アプリケーションで用意するリンカスクリプトで決定する方法を，手動メモリ配置と呼ぶ．手動メモリ配置をサポートするかどうかは，ターゲット定義である【NGKI0608】．

手動メモリ配置の機能を新たに導入した．

カーネルが実行を制御する処理単位の種類は次の通りである【NGKI0533】．

(a) タスク
(b) 割込みハンドラ
　(b.1) 割込みサービスルーチン
　(b.2) タイムイベントハンドラ
(c) CPU例外ハンドラ
(d) 拡張サービスコール
(e) 初期化ルーチン
(f) 終了処理ルーチン

ここで，タイムイベントハンドラとは，時間の経過をきっかけに起動される処理単位である周期ハンドラ，アラームハンドラ，オーバランハンドラの総称である．

ASP3カーネルでは，オーバランハンドラと拡張サービスコールをサポートしていない【ASPS0003】．ただし，オーバランハンドラ機能拡張パッケージを用いると，オーバランハンドラ機能を追加することができる【ASPS0004】．

FMP3カーネルでは，オーバランハンドラと拡張サービスコールをサポートしていない【FMPS0002】．

HRP3カーネルでは，オーバランハンドラをサポートしていない【HRPS0013】．ただし，オーバランハンドラ機能拡張パッケージを用いると，オーバランハンドラ機能を追加することができる【HRPS0014】．

HRMP3カーネルでは，オーバランハンドラをサポートしていない【HRMPS0003】．

SSP3カーネルでは，タイムイベントハンドラと拡張サービスコールをサポートしていない【SSPS0002】．

タスク例外処理ルーチンを廃止した．

処理単位の実行順序を規定するために，ここでは，処理単位の優先順位を規定する．また，ディスパッチが起こるタイミングを規定するために，ディスパッチを行うカーネル内の処理であるディスパッチャの優先順位についても規定する．

タスクの優先順位は，ディスパッチャの優先順位よりも低い【NGKI0118】．タスク間では，高い優先度を持つ方が優先順位が高く，同じ優先度を持つタスク間では，別に規定がない限りは，先に実行できる状態となった方が優先順位が高い【NGKI0119】．詳しくは，「2.6.3 タスクのスケジューリング規則」の節を参照すること．

割込みハンドラの優先順位は，ディスパッチャの優先順位よりも高い【NGKI0121】．割込みハンドラ間では，高い割込み優先度を持つ方が優先順位が高く，同じ割込み優先度を持つ割込みハンドラ間では，先に実行開始された方が優先順位が高い【NGKI0122】．同じ割込み優先度を持つ割込みハンドラ間での実行開始順序は，この仕様では規定しない．詳しくは，「2.7.2 割込み優先度」の節を参照すること．

割込みサービスルーチンとタイムイベントハンドラの優先順位は，それを呼び出す割込みハンドラと同じである【NGKI0123】．

CPU例外ハンドラの優先順位は，CPU例外がタスクで発生した場合には，ディスパッチャの優先順位と同じであるが，ディスパッチャよりも先に実行される【NGKI0124】．CPU例外がその他の処理単位で発生した場合には，その処理単位の優先順位と同じであるが，その処理単位よりも先に実行される【NGKI0125】．

拡張サービスコールの優先順位は，それを呼び出した処理単位と同じであるが，それを呼び出した処理単位よりも先に実行される【NGKI0126】．

初期化ルーチンの実行順序については「2.9.1 システム初期化手順」の節で，終了処理ルーチンの実行順序については「2.9.2 システム終了手順」の節で説明する．

終了処理ルーチンを，登録する静的APIを記述したのと逆順で実行するのは，終了処理は初期化の逆の順序で行うのがよいためである（システムコンフィギュレーションファイルを分割すると，終了処理ルーチンを登録する静的APIだけ逆順に記述するのは難しい）．

カーネルのサービスコール処理やディスパッチャ，割込みハンドラとCPU例外ハンドラの入口処理と出口処理などのカーネル処理は不可分に実行されるのが基本である．実際には，カーネル処理の途中でアプリケーションが実行される場合はあるが，アプリケーションがサービスコールを用いて観測できる範囲で，カーネル処理が不可分に実行された場合と同様に振る舞うのが原則である【NGKI0133】．これを，カーネル処理の不可分性という．

ただし，マルチプロセッサ対応カーネルにおいては，カーネル処理が実行されているプロセッサ以外のプロセッサから，カーネル処理の途中の状態が観測できる場合がある．具体的には，1つのサービスコールにより複数のオブジェクトの状態が変化する場合に，一部のオブジェクトの状態のみが変化し，残りのオブジェクトの状態が変化していない過渡的な状態が観測できる場合がある【NGKI0134】．

マルチプロセッサ対応でないカーネルでは，1つのサービスコールにより複数のタスクが実行できる状態になる場合，新しく実行状態となるべきタスクへのディスパッチは，すべてのタスクの状態遷移が完了した後に行われる．例えば，低優先度のタスクAが発行したサービスコールにより，中優先度のタスクBと高優先度のタスクCがこの順で待ち解除される場合，タスクBとタスクCが待ち解除された後に，タスクCへのディスパッチが行われる．

マルチプロセッサ対応カーネルでは，上のことは，1つのプロセッサ内では成り立つが，他のプロセッサに割り付けられたタスクに対しては成り立たない．例えば，プロセッサ1で低優先度のタスクAが実行されている時に，他のプロセッサ2で実行されているタスクが発行したサービスコールにより，プロセッサ1に割り付けられた中優先度のタスクBと高優先度のタスクCがこの順で待ち解除される場合，タスクCが待ち解除される前に，タスクBへディスパッチされる場合がある．

マルチプロセッサ対応カーネルでは，処理単位を実行するプロセッサ（割付けプロセッサ）は，その処理単位が属するクラスの初期割付けプロセッサと割付け可能プロセッサから，次のように決まる．

タスク，周期ハンドラ，アラームハンドラは，登録時に，属するクラスの初期割付けプロセッサに割り付けられる【NGKI0135】．また，割付けプロセッサを変更するサービスコール（mact_tsk，mig_tsk，msta_cyc，msta_alm）によって，割付けプロセッサを，クラスの割付け可能プロセッサのいずれかに変更することができる【NGKI0136】．

割込みハンドラ，ローカル初期化ルーチン，ローカル終了処理ルーチンは，属するクラスの初期割付けプロセッサで実行される【NGKI0137】．クラスの割付け可能プロセッサの情報は用いられない．

割込みサービスルーチンは，属するクラスの割付け可能プロセッサのいずれかで実行される【NGKI0138】．この場合，クラスの初期割付けプロセッサの情報は用いられない．ただし，割込みを複数のプロセッサで受け付けることができないターゲットシステムでは，ターゲット定義で，割込みサービスルーチンは，属するクラスの初期割付けプロセッサのみで実行されるものとする【NGKI0656】．

CPU例外ハンドラは，CPU例外が発生したプロセッサで実行される【NGKI0660】．属するクラスの割付け可能プロセッサは，そのCPU例外が発生する可能性があるプロセッサと一致していなければならない【NGKI0308】．クラスの初期割付け可能プロセッサの情報は用いられない．

以上を整理すると，次の表の通りとなる．この表の中で，「○」はその情報が使用されることを，「△」はターゲットによってはその情報が使用される場合があることを，「−」はその情報が使用されないことを示す．

オーバランハンドラ，拡張サービスコール，グローバル初期化ルーチン，グローバル終了処理ルーチンは，いずれのクラスにも属さない【NGKI0139】．オーバランハンドラは，オーバランを起こしたタスクの割付けプロセッサによって実行される【NGKI0140】．拡張サービスコールは，それを呼び出した処理単位の割付けプロセッサによって実行される【NGKI0141】．グローバル初期化ルーチンとグローバル終了処理ルーチンは，マスタプロセッサによって実行される【NGKI0142】．

割込みサービスルーチンを実行するプロセッサを，ターゲット定義で，属するクラスの初期割付けプロセッサのみとしても良いこととした．

複数のプロセッサで共通のCPU例外を許した（「2.8.1 CPU例外処理の流れ」の節を参照）ことに伴い，CPU例外が発生する可能性があるプロセッサを，CPU例外ハンドラが属するクラスの割付け可能プロセッサと一致させることとし，初期割付け可能プロセッサの情報は用いないこととした．また，CPU例外ハンドラを実行するプロセッサを，CPU例外が発生したプロセッサとした．

カーネルの初期化が完了した後，カーネルの終了処理が開始されるまでの間を，カーネル動作状態と呼ぶ．それ以外の状態，すなわちカーネルの初期化完了前（初期化ルーチンの実行中を含む）と終了処理開始後（終了処理ルーチンの実行中を含む）を，カーネル非動作状態と呼ぶ．プロセッサは，カーネル動作状態かカーネル非動作状態のいずれかの状態を取る【NGKI0143】．

カーネル非動作状態では，原則として，NMIを除くすべての割込みがマスクされる【NGKI0144】．

カーネル非動作状態では，システムインタフェースレイヤのAPIとカーネル非動作状態を参照するサービスコール（sns_ker）のみを呼び出すことができる【NGKI0145】．カーネル非動作状態で，その他のサービスコールを呼び出した場合の動作は，保証されない【NGKI0146】．

マルチプロセッサ対応カーネルでは，プロセッサ毎に，カーネル動作状態かカーネル非動作状態のいずれかの状態を取る【NGKI0147】．

処理単位が実行される環境（用いるスタック領域やプロセッサの動作モードなど）をコンテキストと呼ぶ．

カーネル動作状態において，処理単位が実行されるコンテキストは，タスクコンテキストと非タスクコンテキストに分類される【NGKI0148】．

タスクが実行されるコンテキストは，タスクコンテキストに分類される【NGKI0149】．また，タスクコンテキストから呼び出した拡張サービスコールが実行されるコンテキストは，タスクコンテキストに分類される【NGKI0150】．

割込みハンドラ（割込みサービスルーチンおよびタイムイベントハンドラを含む）とCPU例外ハンドラが実行されるコンテキストは，非タスクコンテキストに分類される【NGKI0151】．また，非タスクコンテキストから呼び出した拡張サービスコールが実行されるコンテキストは，非タスクコンテキストに分類される【NGKI0152】．

タスクコンテキストで実行される処理単位は，別に規定がない限り，タスクのスタック領域を用いて実行される【NGKI0153】．非タスクコンテキストで実行される処理単位は，別に規定がない限り，非タスクコンテキスト用スタック領域を用いて実行される【NGKI0154】．

非タスクコンテキストからは，タスクコンテキスト専用のサービスコールを呼び出すことはできない．呼び出した場合にはE_CTXエラーとなる【NGKI0157】．

非タスクコンテキスト専用のサービスコールの概念を廃止し，非タスクコンテキストからも，タスクコンテキストと同じ名称のサービスコールを呼び出すこととした．

カーネル動作状態において，プロセッサは，カーネルの振舞いに影響を与える状態として，次の状態を持つ【NGKI0158】．

これらの状態は，それぞれ独立な状態である．すなわち，プロセッサは上記の状態の任意の組合せを取ることができ，それぞれの状態を独立に変化させることができる【NGKI0159】．

プロセッサは，NMIを除くすべての割込みをマスクするための全割込みロックフラグを持つ【NGKI0160】．全割込みロックフラグがセットされた状態を全割込みロック状態，クリアされた状態を全割込みロック解除状態と呼ぶ．すなわち，全割込みロック状態では，NMIを除くすべての割込みがマスクされる．

全割込みロック状態では，システムインタフェースレイヤのAPIとカーネル非動作状態を参照するサービスコール（sns_ker），カーネルを終了するサービスコール（ext_ker）のみを呼び出すことができる【NGKI0161】．全割込みロック状態で，その他のサービスコール（拡張サービスコールを含む）を呼び出した場合の動作は，保証されない【NGKI0162】．また，全割込みロック状態で，実行中の処理単位からリターンしてはならない．リターンした場合の動作は保証されない【NGKI0164】．

保護機能対応カーネルでは，非特権モードで実行中に全割込みロック状態になることはない【NGKI0655】．

マルチプロセッサ対応カーネルでは，プロセッサ毎に，全割込みロックフラグを持つ【NGKI0165】．すなわち，プロセッサ毎に，全割込みロック状態か全割込みロック解除状態のいずれかの状態を取る．

プロセッサは，カーネル管理の割込み（「2.7.7 カーネル管理外の割込み」の節を参照）をすべてマスクするためのCPUロックフラグを持つ【NGKI0166】．CPUロックフラグがセットされた状態をCPUロック状態，クリアされた状態をCPUロック解除状態と呼ぶ．CPUロック状態では，すべてのカーネル管理の割込みがマスクされ，ディスパッチが保留される【NGKI0167】．

CPUロック状態で呼び出すことができるサービスコールは次の通り【NGKI0168】．

CPUロック状態で，その他のサービスコールを呼び出した場合には，E_CTXエラーとなる【NGKI0169】．

マルチプロセッサ対応カーネルでは，プロセッサ毎に，CPUロックフラグを持つ【NGKI0170】．すなわち，プロセッサ毎に，CPUロック状態かCPUロック解除状態のいずれかの状態を取る．

NMI以外にカーネル管理外の割込みを設けない場合には，全割込みロックフラグとCPUロックフラグの機能は同一となるが，両フラグは独立に存在する．

マルチプロセッサ対応カーネルにおいて，あるプロセッサがCPUロック状態にある間は，そのプロセッサにおいてのみ，すべてのカーネル管理の割込みがマスクされ，ディスパッチが保留される．それに対して他のプロセッサにおいては，割込みはマスクされず，ディスパッチも起こるため，CPUロック状態を使って他のプロセッサで実行される処理単位との排他制御を実現することはできない．

プロセッサは，割込み優先度を基準に割込みをマスクするための割込み優先度マスクを持つ【NGKI0171】．割込み優先度マスクがTIPM_ENAALL（＝0）の時は，いずれの割込み要求もマスクされない【NGKI0172】．この状態を割込み優先度マスク全解除状態と呼ぶ．割込み優先度マスクがTIPM_ENAALL（＝0）以外の時は，割込み優先度マスクと同じかそれより低い割込み優先度を持つ割込みはマスクされ，ディスパッチは保留される【NGKI0173】．この状態を割込み優先度マスクが全解除でない状態と呼ぶ．

割込み優先度マスクが全解除でない状態では，別に規定がない限りは，自タスクを広義の待ち状態に遷移させる可能性のあるサービスコールを呼び出すことはできない．呼び出した場合には，E_CTXエラーとなる【NGKI0175】．

マルチプロセッサ対応カーネルでは，プロセッサ毎に，割込み優先度マスクを持つ【NGKI0176】．

プロセッサは，ディスパッチを保留するためのディスパッチ禁止フラグを持つ【NGKI0177】．ディスパッチ禁止フラグがセットされた状態をディスパッチ禁止状態，クリアされた状態をディスパッチ許可状態と呼ぶ．すなわち，ディスパッチ禁止状態では，ディスパッチは保留される．

ディスパッチ禁止状態では，別に規定がない限りは，自タスクを広義の待ち状態に遷移させる可能性のあるサービスコールを呼び出すことはできない．呼び出した場合には，E_CTXエラーとなる【NGKI0179】．

マルチプロセッサ対応カーネルでは，プロセッサ毎に，ディスパッチ禁止フラグを持つ【NGKI0180】．すなわち，プロセッサ毎に，ディスパッチ禁止状態かディスパッチ許可状態のいずれかの状態を取る．

マルチプロセッサ対応カーネルにおいて，あるプロセッサがディスパッチ禁止状態にある間は，そのプロセッサにおいてのみ，ディスパッチが保留される．それに対して他のプロセッサにおいては，ディスパッチが起こるため，ディスパッチ禁止状態を使って他のプロセッサで実行されるタスクとの排他制御を実現することはできない．

非タスクコンテキストの実行中，CPUロック状態，割込み優先度マスクが全解除でない状態，ディスパッチ禁止状態では，ディスパッチが保留される【NGKI0181】．これらの状態を総称して，ディスパッチ保留状態と呼ぶ．

マルチプロセッサ対応カーネルでは，プロセッサ毎に，ディスパッチ保留状態かそうでない状態のいずれかの状態を取る【NGKI0182】．

全割込みロック状態はカーネルが管理しておらず，ディスパッチが保留されることをカーネルが保証できないため，ディスパッチ保留状態に含めていない．

全割込みロック状態，カーネル管理外の割込みハンドラ実行中（「2.7.7 カーネル管理外の割込み」の節を参照），カーネル管理外のCPU例外ハンドラ実行中（「2.8.4 カーネル管理外のCPU例外」の節を参照）を総称して，カーネル管理外の状態と呼ぶ．

カーネル管理外の状態では，システムインタフェースレイヤのAPIとsns_ker，ext_kerのみ（カーネル管理外のCPU例外ハンドラからは，それに加えてxsns_dpn）を呼び出すことができ，その他のサービスコールを呼び出すことはできない【NGKI0543】．カーネル管理外の状態から，その他のサービスコールを呼び出した場合の動作は，保証されない【NGKI0544】．

カーネル管理外の状態では，少なくとも，カーネル管理の割込みはマスクされている【NGKI0545】．カーネル管理外の割込み（の一部）もマスクされている場合もある【NGKI0546】．

保護機能対応カーネルでは，非特権モードで実行中にカーネル管理外の状態になることはない．

各処理単位が実行開始されるシステム状態の条件（実行開始条件），各処理単位の実行開始時にカーネルによって行われるシステム状態の変更処理（実行開始時処理），各処理単位からのリターン前（または終了前）にアプリケーションが設定しておくべきシステム状態（リターン前または終了前），各処理単位からのリターン時（または終了時）にカーネルによって行われるシステム状態の変更処理（リターン時処理または終了時処理）は，次の表の通りである．

この表の中で「原則(*1)」とは，処理単位からのリターン前（または終了前）に，アプリケーションが指定された状態に設定しておくことが原則であるが，この原則に従わなくても，リターン時（または終了時）にカーネルによって状態が設定されるため，支障がないことを意味する．

「自優先度に(*2)」とは，割込みハンドラを起動した割込みの割込み優先度に変更することを意味する．

「変更不可(*3)」とは，その処理単位中で，そのシステム状態を変更するAPIが用意されていないことを示す．

割込みサービスルーチンは，カーネル内の割込みハンドラから呼び出される．また，タイムイベントハンドラの内，周期ハンドラとアラームハンドラは高分解能タイマ割込みハンドラから，オーバランハンドラはオーバランタイマ割込みハンドラから，それぞれ呼び出される．割込み優先度マスクは，それらを呼び出す割込みハンドラでの状態のまま呼び出され，リターン時にも変更されない(*4)．

割込みサービスルーチンおよびタイムイベントハンドラからのリターン時に，TOPPERS新世代カーネル統合仕様では割込み優先度マスクを元に戻すものとしていたが，この仕様では元に戻さない（そのままとする）ものとした．これは，ターゲットによっては，割込み優先度マスクを元に戻すためのオーバヘッドが大きいためである．

CPU例外ハンドラ中で割込み優先度マスクを変更するAPIが用意されていないにもかかわらず，CPU例外ハンドラからのリターン時に元の状態に戻す(*5)理由は次の通りである．プロセッサによっては，割込み優先度マスクがステータスレジスタ等に含まれており，CPU例外ハンドラからのリターンで自然に元の状態に戻ってしまう．ターゲットによって振舞いが異なるのは望ましくないため，ターゲットによらず，元の状態に戻すこととしている．

CPU例外ハンドラの実行開始時には，CPUロックフラグは変更されない(*6)ことから，CPUロック状態でCPU例外が発生した場合，CPU例外ハンドラの実行開始直後はCPUロック状態となっている．CPUロック状態でCPU例外が発生した場合，起動されるCPU例外ハンドラはカーネル管理外のCPU例外ハンドラであり（xsns_dpnはtrueを返す），CPU例外ハンドラ中でunl_cpuを呼び出してCPUロック状態を解除しようとした場合の動作は保証されない．ただし，保証されないにも関わらずunl_cpuを呼び出した場合も考えられるため，リターン時には元に戻すこととしている．

カーネルに登録したタスクは，実行できる状態，休止状態，広義の待ち状態のいずれかの状態を取る【NGKI0193】．また，実行できる状態と広義の待ち状態を総称して，起動された状態と呼ぶ．さらに，タスクをカーネルに登録していない仮想的な状態を，未登録状態と呼ぶ．

(a) 実行できる状態（runnable）

タスクを実行できる条件が，プロセッサが使用できるかどうかを除いて，揃っている状態．実行できる状態は，さらに，実行状態と実行可能状態に分類される．

(a.1) 実行状態（running）

タスクが実行されている状態．または，そのタスクの実行中に，割込みまたはCPU例外により非タスクコンテキストの実行が開始され，かつ，タスクコンテキストに戻った後に，そのタスクの実行を再開するという状態．

(a.2) 実行可能状態（ready）

タスク自身は実行できる状態にあるが，それよりも優先順位の高いタスクが実行状態にあるために，そのタスクが実行されない状態．

(b) 休止状態（dormant）

タスクが実行すべき処理がない状態．タスクの実行を終了した後，次に起動するまでの間は，タスクは休止状態となっている．タスクが休止状態にある時には，タスクの実行を再開するための情報（実行再開番地やレジスタの内容など）は保存されていない【NGKI0194】．

(c) 広義の待ち状態（blocked）

タスクが，処理の途中で実行を止められている状態．タスクが広義の待ち状態にある時には，タスクの実行を再開するための情報（実行再開番地やレジスタの内容など）は保存されており，タスクが実行を再開する時には，広義の待ち状態に遷移する前の状態に戻される【NGKI0195】．広義の待ち状態は，さらに，（狭義の）待ち状態，強制待ち状態，二重待ち状態に分類される．

(c.1) （狭義の）待ち状態（waiting）

タスクが何らかの条件が揃うのを待つために，自ら実行を止めている状態．

(c.2) 強制待ち状態（suspended）

他のタスクによって，強制的に実行を止められている状態．ただし，自タスクを強制待ち状態にすることも可能である．

(c.3) 二重待ち状態（waiting-suspended）

待ち状態と強制待ち状態が重なった状態．すなわち，タスクが何らかの条件が揃うのを待つために自ら実行を止めている時に，他のタスクによって強制的に実行を止められている状態．

単にタスクが「待ち状態である」といった場合には，二重待ち状態である場合を含み，「待ち状態でない」といった場合には，二重待ち状態でもないことを意味する．また，単にタスクが「強制待ち状態である」といった場合には，二重待ち状態である場合を含み，「強制待ち状態でない」といった場合には，二重待ち状態でもないことを意味する．

(d) 未登録状態（non-existent）

タスクをカーネルに登録していない仮想的な状態．タスクの生成前と削除後は，タスクは未登録状態にあるとみなす．

カーネルによっては，これらのタスク状態以外に，過渡的な状態が存在する場合がある【NGKI0196】．過渡的な状態については，「2.6.5 ディスパッチ保留状態で実行中のタスクに対する強制待ち」の節を参照すること．

ASP3カーネルでは，タスクが未登録状態になることはない【ASPS0005】．また，上記のタスク状態以外の過渡的な状態になることもない【ASPS0006】．ただし，動的生成機能拡張パッケージでは，タスクが未登録状態になる【ASPS0007】．

FMP3カーネルでは，タスクが未登録状態になることはない【FMPS0003】．上記のタスク状態以外の過渡的な状態として，タスクが強制待ち状態［実行継続中］になることがある【FMPS0004】．詳しくは，「2.6.5 ディスパッチ保留状態で実行中のタスクに対する強制待ち」の節を参照すること．

HRP3カーネルでは，タスクが未登録状態になることはない【HRPS0002】．また，上記のタスク状態以外の過渡的な状態になることもない【HRPS0003】．ただし，動的生成機能拡張パッケージでは，タスクが未登録状態になる【HRPS0010】．

HRMP3カーネルでは，タスクが未登録状態になることはない【HRMPS0004】．上記のタスク状態以外の過渡的な状態として，タスクが強制待ち状態［実行継続中］になることがある【HRMPS0005】．詳しくは，「2.6.5 ディスパッチ保留状態で実行中のタスクに対する強制待ち」の節を参照すること．

SSP3カーネルでは，タスクが広義の待ち状態と未登録状態になることはない【SSPS0003】．また，上記のタスク状態以外の過渡的な状態になることもない【SSPS0004】．

タスクの状態遷移を図2-2に示す【NGKI0197】．

未登録状態のタスクをカーネルに登録することを，タスクを生成する（create）という．生成されたタスクは，休止状態に遷移する【NGKI0198】．また，タスク生成時の属性指定により，生成と同時にタスクを起動し，実行できる状態にすることもできる【NGKI0199】．逆に，登録されたタスクを未登録状態に遷移させることを，タスクを削除する（delete）という．

休止状態のタスクを，実行できる状態にすることを，タスクを起動する（activate）という．起動されたタスクは，実行できる状態になる【NGKI0200】．逆に，起動された状態のタスクを，休止状態（または未登録状態）に遷移させることを，タスクを終了する（terminate）という．

実行できる状態になったタスクは，まずは実行可能状態に遷移するが，そのタスクの優先順位が実行状態のタスクよりも高い場合には，ディスパッチ保留状態でない限りはただちにディスパッチが起こり，実行状態へ遷移する【NGKI0201】．この時，それまで実行状態であったタスクは実行可能状態に遷移する【NGKI0202】．この時，実行状態に遷移したタスクは，実行可能状態に遷移したタスクをプリエンプトしたという．逆に，実行可能状態に遷移したタスクは，プリエンプトされたという．

タスクを待ち解除するとは，タスクが待ち状態（二重待ち状態を除く）であれば実行できる状態に，二重待ち状態であれば強制待ち状態に遷移させることをいう．また，タスクを強制待ちから再開するとは，タスクが強制待ち状態（二重待ち状態を除く）であれば実行できる状態に，二重待ち状態であれば待ち状態に遷移させることをいう．

タスクの実行開始とは，タスクが起動された後に最初に実行される（実行状態に遷移する）時のことをいう．

実行できるタスクは，優先順位の高いものから順に実行される【NGKI0203】．すなわち，ディスパッチ保留状態でない限りは，実行できるタスクの中で最も高い優先順位を持つタスクが実行状態となり，他は実行可能状態となる．

タスクの優先順位は，タスクの優先度とタスクが実行できる状態になった順序から，次のように定まる．優先度の異なるタスクの間では，優先度の高いタスクが高い優先順位を持つ【NGKI0204】．優先度が同一のタスクの間では，別に規定がない限りは，先に実行できる状態になったタスクが高い優先順位を持つ【NGKI0205】．すなわち，同じ優先度を持つタスクは，FCFS（First Come First Served）方式でスケジューリングされる．ただし，サービスコールの呼出しにより，同じ優先度を持つタスク間の優先順位を変更することも可能である【NGKI0206】．

保護機能対応カーネルにおいて，カーネルドメインに属するタスクとユーザドメインに属するタスクが同一の優先度を持つ場合には，カーネルドメインに属するタスクが高い優先順位を持つ【NGKI0588】．カーネルドメイン内とユーザドメイン内では，別に規定がない限りは，先に実行できる状態になったタスクが高い優先順位を持つ【NGKI0589】．なお，時間パーティショニングを使用した場合のスケジューリング規則については，「2.6.7 時間パーティショニング使用時のスケジューリング規則」の節を参照すること．

サブ優先度機能をサポートするカーネルにおいては，サブ優先度を使用して優先順位を決定すると設定した同一の優先度を持つタスク（保護機能対応カーネルにおいては，さらに，同じ保護ドメインに属するもの）の間では，別に規定がない限りは，サブ優先度の高いタスクが高い優先順位を持つ【NGKI0560】．サブ優先度も同一のタスクの間では，先に実行できる状態になったタスクが高い優先順位を持つ【NGKI0561】．

最も高い優先順位を持つタスクが変化した場合には，ディスパッチ保留状態でない限りはただちにディスパッチが起こり，最も高い優先順位を持つタスクが実行状態となる【NGKI0207】．ディスパッチ保留状態においては，実行状態のタスクは切り換わらず，最も高い優先順位を持つタスクは実行可能状態にとどまる【NGKI0208】．

マルチプロセッサ対応カーネルでは，プロセッサ毎に，上記のスケジューリング規則を適用して，タスクスケジューリングを行う【NGKI0209】．すなわち，プロセッサがディスパッチ保留状態でない限りは，そのプロセッサに割り付けられた実行できるタスクの中で最も高い優先順位を持つタスクが実行状態となり，他は実行可能状態となる．そのため，実行状態のタスクは，プロセッサ毎に存在する．

サブ優先度機能を追加した．

保護機能対応カーネルにおいて，カーネルドメインに属するタスクは，ユーザドメインに属する同じ優先度のタスクよりも，高い優先順位を持つものとした．

タスクが待ち解除される順序の管理のために，待ち状態のタスクがつながれているキューを，待ち行列と呼ぶ．また，タスクが同期・通信オブジェクトの待ち行列につながれている場合に，そのオブジェクトを，タスクの待ちオブジェクトと呼ぶ．

待ち行列にタスクをつなぐ順序には，FIFO順とタスクの優先度順がある．どちらの順序でつなぐかは，待ち行列毎に規定される【NGKI0210】．多くの待ち行列において，どちらの順序でつなぐかを，オブジェクト属性により指定できる【NGKI0211】．

FIFO順の待ち行列においては，新たに待ち状態に遷移したタスクは待ち行列の最後につながれる【NGKI0212】．それに対してタスクの優先度順の待ち行列においては，新たに待ち状態に遷移したタスクは，優先度の高い順に待ち行列につながれる【NGKI0213】．同じ優先度のタスクが待ち行列につながれている場合には，新たに待ち状態に遷移したタスクが，同じ優先度のタスクの中で最後につながれる【NGKI0214】．

待ち解除の条件がタスクによって異なる場合には，待ち行列の先頭のタスクは待ち解除の条件を満たさないが，後方のタスクが待ち解除の条件を満たす場合がある．このような場合の振舞いとして，次の2つのケースがある．どちらの振舞いをするかは，待ち行列毎に規定される【NGKI0215】．

(a) 待ち解除の条件を満たしたタスクの中で，待ち行列の前方につながれたものから順に待ち解除される【NGKI0216】．すなわち，待ち行列の前方に待ち解除の条件を満たさないタスクがあっても，後方のタスクが待ち解除の条件を満たしていれば，先に待ち解除される．

(b) タスクの待ち解除は，待ち行列につながれている順序で行われる【NGKI0217】．すなわち，待ち行列の前方に待ち解除の条件を満たさないタスクがあると，後方のタスクが待ち解除の条件を満たしても，待ち解除されない．

ここで，(b)の振舞いをする待ち行列においては，待ち行列につながれたタスクの強制終了，タスク優先度の変更（待ち行列がタスクの優先度順の場合のみ），待ち状態の強制解除が行われた場合に，タスクの待ち解除が起こることがある．具体的には，これらの操作により新たに待ち行列の先頭になったタスクが，待ち解除の条件を満たしていれば，ただちに待ち解除される【NGKI0218】．さらに，この待ち解除により新たに待ち行列の先頭になったタスクに対しても，同じ処理が繰り返される【NGKI0219】．

ディスパッチ保留状態において，実行状態のタスクを強制待ち状態へ遷移させるサービスコールを呼び出した場合，実行状態のタスクの切換えは，ディスパッチ保留状態が解除されるまで保留される【NGKI0226】．

この間，それまで実行状態であったタスクは，実行状態と強制待ち状態の間の過渡的な状態にあると考える【NGKI0227】．この状態を，強制待ち状態［実行継続中］と呼ぶ．一方，ディスパッチ保留状態が解除された後に実行すべきタスクは，実行可能状態にとどまる【NGKI0228】．

タスクが強制待ち状態［実行継続中］にある時に，ディスパッチ保留状態が解除されると，ただちにディスパッチが起こり，タスクは強制待ち状態に遷移する【NGKI0229】．

過渡的な状態も含めたタスクの状態遷移を図2-3に示す【NGKI0230】．

タスクが強制待ち状態［実行継続中］である時の扱いは次の通りである．

(a) プロセッサを占有して実行を継続する．

強制待ち状態［実行継続中］のタスクは，プロセッサを占有して，そのまま継続して実行される【NGKI0231】．

強制待ち状態［実行継続中］のタスクが，自タスクを終了させるサービスコールを発行すると，休止状態に遷移する【NGKI0629】．ただし，マルチプロセッサ対応カーネルでは，CPUロック状態で強制待ち状態［実行継続中］のタスクがext_tskを発行した場合には，強制待ち状態に遷移する場合もある【NGKI0648】．

(b) 実行状態のタスクに関する情報を参照するサービスコールでは，実行状態であるものと扱う．

実行状態のタスクに関する情報を参照するサービスコール（get_tid，get_did，sns_ter）では，強制待ち状態［実行継続中］のタスクが，それを実行するプロセッサにおいて実行状態のタスクであるものと扱う．具体的には，強制待ち状態［実行継続中］のタスクが実行されている時にget_tidを発行すると，そのタスクのID番号を参照する【NGKI0232】．また，get_didを発行するとそのタスクが属する保護ドメインのID番号を，sns_terを発行するとそのタスクのタスク終了禁止フラグを参照する【NGKI0534】．

(c) その他のサービスコールでは，強制待ち状態であるものと扱う．

その他のサービスコールでは，強制待ち状態［実行継続中］のタスクは，強制待ち状態であるものと扱う【NGKI0234】．

ASP3カーネルでは，ディスパッチ保留状態において実行状態のタスクを強制待ち状態へ遷移させるサービスコールはサポートしていないため，タスクが強制待ち状態［実行継続中］になることはない【ASPS0008】．

FMP3カーネルでは，ディスパッチ保留状態において実行状態のタスクを強制待ち状態へ遷移させるサービスコールを，他のプロセッサから呼び出すことができるため，タスクが強制待ち状態［実行継続中］になる場合がある【FMPS0005】．

HRP3カーネルでは，ディスパッチ保留状態において実行状態のタスクを強制待ち状態へ遷移させるサービスコールはサポートしていないため，タスクが強制待ち状態［実行継続中］になることはない【HRPS0004】．

HRMP3カーネルでは，ディスパッチ保留状態において実行状態のタスクを強制待ち状態へ遷移させるサービスコールを，他のプロセッサから呼び出すことができるため，タスクが強制待ち状態［実行継続中］になる場合がある【HRMPS0006】．

SSP3カーネルでは，タスクが広義の待ち状態になることはないため，タスクが強制待ち状態［実行継続中］になることもない【SSPS0005】．

この仕様では，ディスパッチ保留状態において，実行状態のタスクを強制終了させるサービスコールはサポートしていない．そのため，実行状態と休止状態の間の過渡的な状態は存在しない．

μITRON4.0仕様では，過渡的な状態におけるタスクの扱いは，実装依存とされている．

強制待ち状態［実行継続中］のタスクが，自タスクを終了させるサービスコールを発行した場合の扱いを規定した．

制約タスク（restricted task）は，複数のタスクでスタック領域を共有することによるメモリ使用量の削減を目的に，通常のタスクに対して，広義の待ち状態を持たないなどの機能制限を加えたものである．具体的には，制約タスクには以下の機能制限がある．

(a) 広義の待ち状態に入ることができない【NGKI0235】．

(b) サービスコールによりベース優先度やサブ優先度を変更することができない【NGKI0236】．

(c) 対象優先度の中の先頭のタスクが制約タスクである場合には，タスクの優先順位の回転（rot_rdq，mrot_rdq）を行うことができない【NGKI0237】．

(d) マルチプロセッサ対応カーネルでは，割付けプロセッサを変更することができない【NGKI0238】．

制約タスクに対して，機能制限により使用できなくなったサービスコールを呼び出した場合には，E_NOSPTエラーとなる【NGKI0239】．E_NOSPTエラーが返ることに依存している場合を除いては，制約タスクを通常のタスクに置き換えることができる【NGKI0240】．

ASP3カーネルでは，制約タスクをサポートしていない【ASPS0009】．ただし，制約タスク拡張パッケージを用いると，制約タスクの機能を追加することができる【ASPS0010】．

FMP3カーネルでは，制約タスクをサポートしていない【FMPS0006】．

HRP3カーネルでは，制約タスクをサポートしていない【HRPS0005】．

HRMP3カーネルでは，制約タスクをサポートしていない【HRMPS0007】．

SSP3カーネルでは，制約タスクのみをサポートする【SSPS0006】．そのため，すべてのタスクと非タスクコンテキストがスタック領域を共有することができ，すべての処理単位で同一のスタック領域を使用している【SSPS0007】．このスタック領域を，共有スタック領域と呼ぶ．

制約タスクは，μITRON4.0仕様の自動車制御プロファイルで導入された機能である．この仕様における制約タスクは，μITRON4.0仕様の制約タスクよりも機能制限が少なくなっている．

保護機能対応カーネルで，時間パーティショニングを使用する場合には，以下の規則に従ってタスクがスケジューリングされる．

プロセッサは，システム周期毎に，現在のシステム動作モードに対して登録されたタイムウィンドウを順に実行する（図2-4）【NGKI0590】．あるタイムウィンドウの実行中は，カーネルドメインに属する実行できる処理単位と，そのタイムウィンドウを割り当てられたユーザドメインに属する実行できるタスクの中で，優先順位の高いものから順に実行される【NGKI0591】．これらの保護ドメインに属する実行できる処理単位がない場合には，アイドルドメインに属する実行できるタスクの中で，優先順位の高いものから順に実行される【NGKI0592】．

実行中のタイムウィンドウが使用したプロセッサ時間（いずれの処理単位も実行していなかった時間も含む）から，カーネルドメインに属する処理単位（ユーザタスクから呼び出された拡張サービスコールを除く）が使用したプロセッサ時間を減じたものが，タイムウィンドウの長さに達すると，次のタイムウィンドウに切り換えられる（図2-5）【NGKI0593】．次のタイムウィンドウが設定されていない場合（言い換えると，実行中のタイムウィンドウが，現在のシステム動作モードに対して設定された最後のタイムウィンドウである場合）には，アイドルウィンドウに切り換えられる【NGKI0594】．アイドルウィンドウの実行中は，カーネルドメインに属する実行できる処理単位と，アイドルドメインに属する実行できるタスクの中で，優先順位の高いものから順に実行される【NGKI0595】．

システム周期の終了時刻になると，システム周期の切換え処理が行われる．具体的には，まず，アイドルウィンドウが実行中であるか（言い換えると，現在のシステム動作モードに対して設定されたタイムウィンドウの実行がすべて終わっているか）をチェックし，そうでない場合，カーネルはエミュレートされたCPU例外を発生させる【NGKI0596】．これを，システム周期オーバラン例外と呼ぶ．次に，システム動作モードを，次のシステム周期での遷移先システム動作モードに切り換える【NGKI0597】．その後に，新しいシステム周期を開始する．すなわち，新しいシステム動作モードに対して設定された最初のタイムウィンドウに切り換える【NGKI0598】．

システム動作モードがシステム周期停止モードである場合には，システム周期の切換えも，タイムウィンドウの実行も行われず，カーネルドメインに属する処理単位（ユーザタスクから呼び出された拡張サービスコールを除く）の中で，優先順位が高いものから順に実行される【NGKI0599】．

ユーザドメインに属するタイムイベントの処理（ユーザドメインに属する周期通知とアラーム通知の処理，ユーザドメインに属するタスクに対するタイムアウト処理と時間経過待ち状態からの待ち解除処理）は，そのユーザドメインに割り当てられたタイムウィンドウへの切換え時（厳密には，タイムウィンドウを切り換え，タイムウィンドウ通知を処理した後，タスクの実行を開始する前）に実行される【NGKI0600】．アイドルドメインに属するタイムイベントの処理は，アイドルウィンドウへの切換え時に実行される【NGKI0601】．

ディスパッチ保留状態では，システム周期の切換えとタイムウィンドウの切換えは保留される【NGKI0602】．

システム周期の切換えは，高分解能タイマ割込みをきっかけに実行される．そのため，高分解能タイマ割込みのマスクや，ディスパッチの保留によって，システム周期の切換えは遅れることになる．この場合，その遅れ時間の分，次のシステム周期（結果的には，その最後のアイドルウィンドウ）が短くなる【NGKI0650】．システム周期の切換えが，次のシステム周期末を超えて遅れる状況では，カーネルの動作は保証されない【NGKI0651】．

また，タイムウィンドウの切換えは，タイムウィンドウタイマ割込みをきっかけに実行される．そのため，タイムウィンドウタイマ割込みのマスクや，ディスパッチの保留によって，タイムウィンドウの切換えは遅れることになる．この場合，その遅れ時間の分，そのシステム周期の最後のアイドルウィンドウが短くなる【NGKI0652】．タイムウィンドウの切換えが，そのシステム周期末を超えて遅れる状況では，カーネルの動作は保証されない【NGKI0653】．

マルチプロセッサ対応カーネルでは，プロセッサ毎に，上記のスケジューリング規則を適用してタスクがスケジューリングされる【NGKI0625】．システム周期とシステム動作モードは，すべてのプロセッサで同一である【NGKI0626】．ただし，システム周期の切換え処理は，各プロセッサで同期して行われるわけではない．現在のシステム動作モードは，システム周期の切換え処理を最初に行ったプロセッサによって切り換えられる【NGKI0637】．そのため，他のプロセッサでは，一時的に，切換え前のシステム動作モードで実行している状況が生じる【NGKI0636】．なお，タイムウィンドウは，プロセッサ毎に登録することができる［NGKI0624］．

マルチプロセッサ対応カーネルでは，また，アイドルドメインにまとめられていないユーザドメインに属するタスク，周期通知，アラーム通知を，そのユーザドメインに対してどのシステム動作モードにおいてもタイムウィンドウを割り当てられていないプロセッサに割り付けることはできない【NGKI0628】．そのため例えば，プロセッサAでタイムウィンドウを割り当てられており，プロセッサBでタイムウィンドウを割り当てられていないユーザドメインに属するタスクを，プロセッサBに割り付けることはできない．

なお，システム周期オーバラン例外は，カーネル管理外のCPU例外であり，その例外ハンドラ番号はターゲット定義である【NGKI0603】．システム周期オーバラン例外に対して登録したCPU例外ハンドラからリターンすると，実行中のタイムウィンドウは打ち切られ，システム周期の切換え処理が継続される【NGKI0635】．

システム周期内で，カーネルとカーネルドメインに属する処理単位（ユーザタスクから呼び出された拡張サービスコールを除く）が使用するプロセッサ時間や，システム時刻の調整やドリフト量の設定によるシステム周期の短縮，タイマ割込みのマスクやディスパッチの保留によるシステム周期の切換えとタイムウィンドウの切換えの遅延を考慮し，十分な長さのアイドルウィンドウを確保するのは，アプリケーションの責任である．

ユーザドメインに割り当てられたタイムウィンドウの実行途中に，そのユーザドメインに属するタイムイベントの発生時刻になっても，タイムイベントはすぐには処理されない．タイムイベントが処理されるのは，そのユーザドメインに割り当てられた次のタイムウィンドウへの切換え時である．

タスクのスケジューリングに関する以上の仕様より，タスクを，FCFS方式に基づく優先順位が管理される単位に分類することができる．この単位（タスクの集合）をスケジューリング単位と呼ぶ．カーネルの実装上は，スケジューリング単位毎にレディキューを持つ．

保護機能とマルチプロセッサのいずれにも対応しないカーネルは，唯一のスケジューリング単位を持つ．すなわち，すべてのタスクが1つのスケジューリング単位に属する．

保護機能とマルチプロセッサのいずれかまたは両方に対応するカーネルは，複数のスケジューリング単位を持つ．また，スケジューリング単位を指定して操作を行うサービスコールをサポートする．それらのサービスコールにおいて，スケジューリング単位を指定する番号を，スケジューリング単位番号と呼ぶ．スケジューリング単位番号は，符号付きの整数型であるID型で表す．

保護機能対応カーネルにおいては，カーネルドメイン，アイドルドメイン，アイドルドメインにまとめられていない各ユーザドメインがスケジューリング単位となる．スケジューリング単位番号には，保護ドメインIDまたは呼び出した処理単位が属する保護ドメインを表すTDOM_SELF（＝0）を指定することができる【NGKI0630】．保護ドメインIDで指定したユーザドメインがアイドルドメインにまとめられている場合には，アイドルドメインを指定したものとする【NGKI0631】．

マルチプロセッサ対応カーネルにおいては，各プロセッサがスケジューリング単位となる．スケジューリング単位番号には，プロセッサIDを指定することができる【NGKI0632】．

保護機能とマルチプロセッサの両方に対応するカーネルにおいては，各プロセッサに対して，カーネルドメイン，アイドルドメイン，アイドルドメインにまとめられていない各ユーザドメインがスケジューリング単位となる．スケジューリング単位番号には，SCHEDNO(prcid, domid)を指定する【NGKI0633】．ここで，prcidはマルチプロセッサ対応カーネルにおけるスケジューリング単位番号，domidは保護機能対応カーネルにおけるスケジューリング単位番号，SCHEDNOは保護機能とマルチプロセッサの両方に対応するカーネルにおけるスケジューリング単位番号を構成するためのマクロである．

周辺デバイス（以下，デバイスと呼ぶ）からの割込み要求は，割込みコントローラ（IRC）を経由して，プロセッサに伝えられる．デバイスから割込みコントローラに割込み要求を伝えるための信号線を，割込み要求ラインと呼ぶ．一般には，1つの割込み要求ラインに，複数のデバイスからの割込み要求が接続される．

プロセッサは，デバイスからの割込み要求を受け付ける条件が満たされた場合，割込み要求を受け付ける【NGKI0242】．受け付けた割込み要求が，カーネル管理の割込みである場合には，カーネル内の割込みハンドラの入口処理（割込み入口処理）を経由して，カーネル内の割込みハンドラを実行する【NGKI0243】．

カーネル内の割込みハンドラは，アプリケーションが割込み要求ラインに対して登録した割込みサービスルーチン（ISR）を呼び出す【NGKI0244】．割込みサービスルーチンは，プロセッサの割込みアーキテクチャや割込みコントローラに依存せず，割込みを要求したデバイスのみに依存して記述するのが原則である【NGKI0245】．1つの割込み要求ラインに対して複数のデバイスが接続されることから，1つの割込み要求ラインに対して複数の割込みサービスルーチンを登録することができる【NGKI0246】．

ただし，カーネルが標準的に用意している割込みハンドラで対応できない特殊なケースも考えられる．このような場合に対応するために，アプリケーションが用意した割込みハンドラをカーネルに登録することもできる【NGKI0247】．

カーネルが用いる高分解能タイマ，タイムウィンドウタイマ，オーバランタイマからの割込み要求の場合，カーネル内の割込みハンドラにより，タイムイベントの処理が行われる．具体的には，タイムアウト処理やタイムイベントの通知処理（タイムイベントハンドラの呼出しを含む），タイムウィンドウの切換え処理，オーバランハンドラの呼出しなどが行われる【NGKI0248】．

なお，受け付けた割込み要求に対して，割込みサービスルーチンも割込みハンドラも登録していない場合の振舞いは，ターゲット定義である【NGKI0249】．

割込み要求は，割込み処理の優先順位を指定するための割込み優先度を持つ【NGKI0250】．プロセッサは，割込み優先度マスクの現在値よりも高い割込み優先度を持つ割込み要求のみを受け付ける【NGKI0251】．逆に言うと，割込み優先度マスクの現在値と同じか，それより低い割込み優先度を持つ割込みは，マスクされる．

プロセッサは，割込み要求を受け付けると，割込み優先度マスクを，受け付けた割込み要求の割込み優先度に設定する（ただし，受け付けた割込みがNMIである場合には例外とする）【NGKI0252】．また，割込み処理からのリターンにより，割込み優先度マスクを，割込み要求を受け付ける前の値に戻す【NGKI0253】．

これらのことから，他の方法で割込みをマスクしていない限り，ある割込み要求の処理中は，それと同じかそれより低い割込み優先度を持つ割込み要求は受け付けられず，それより高い割込み優先度を持つ割込み要求は受け付けられることになる．つまり，割込み優先度は，多重割込みを制御するためのものと位置付けることができる．それに対して，同時に発生している割込み要求の中で，割込み優先度の高い割込み要求が先に受け付けられるとは限らない【NGKI0254】．

割込み優先度は，PRI型で表現し，値が小さいほど優先度が高いものとするが，［NGKI0037］の原則には従わず，-1から連続した負の値を用いる【NGKI0255】．

割込み優先度の段階数は，ターゲット定義である【NGKI0256】．プロセッサが割込み優先度マスクを実現するための機能を持たないか，実現するために大きいオーバヘッドを生じる場合には，ターゲット定義で，割込み優先度の段階数を1にする（すなわち，多重割込みを許さない）場合がある．

割込み優先度に-1から連続した負の値を用いるのは，割込み優先度とタスク優先度を比較できるようになることと，いずれの割込みもマスクしない割込み優先度マスクの値を0にできるためである．

各割込み要求ラインは，以下の属性を持つ．なお，1つの割込み要求ラインに複数のデバイスからの割込み要求が接続されている場合，それらの割込み要求は同一の属性を持つ【NGKI0257】．それらの割込み要求に別々の属性を設定することはできない．

割込み要求ライン毎に，割込みをマスクするための割込み要求禁止フラグを持つ【NGKI0258】．割込み要求禁止フラグをセットすると，その割込み要求ラインによって伝えられる割込み要求はマスクされる【NGKI0259】．

プロセッサが割込み要求禁止フラグを実現するための機能を持たないか，実現するために大きいオーバヘッドを生じる場合には，ターゲット定義で，割込み要求禁止フラグをサポートしない場合がある【NGKI0260】．また，プロセッサの持つ割込み要求禁止フラグの機能がこの仕様に合致しない場合には，ターゲット定義で，割込み要求禁止フラグをサポートしないか，振舞いが異なるものとする場合がある【NGKI0261】．

割込み要求ライン毎に，割込み優先度を設定することができる【NGKI0262】．割込み要求ラインに対して設定された割込み優先度が，それが伝える割込み要求の割込み優先度となる【NGKI0263】．

割込み要求ラインに対する割込み要求が，レベルトリガであるかエッジトリガであるかを設定することができる【NGKI0264】．エッジトリガの場合には，さらに，ターゲット定義で，ポジティブエッジトリガかネガティブエッジトリガか両エッジトリガかを設定できる場合もある【NGKI0265】．また，レベルトリガの場合には，ターゲット定義で，ローレベルトリガかハイレベルトリガかを設定できる場合もある【NGKI0266】．

エッジトリガに設定された割込み要求ラインに対しては，割込み要求の有無を示す割込み要求フラグを持つ【NGKI0657】．割込み要求フラグは，割込み要求を示すエッジが検出されるとセットされ，割込みが受け付けられるとクリアされる【NGKI0658】．

プロセッサがトリガモードを設定するための機能を持たないか，設定するために大きいオーバヘッドを生じる場合には，ターゲット定義で，トリガモードの設定をサポートしない場合がある【NGKI0267】．

属性が設定されていない割込み要求ラインに対しては，割込み要求禁止フラグがセットされ，割込み要求はマスクされる【NGKI0268】．また，割込み要求禁止フラグをクリアすることもできない【NGKI0269】．

アプリケーションが，割込み要求禁止フラグを動的にセット／クリアする機能を用いると，次の理由でソフトウェアの再利用性が下がる可能性があるため，注意が必要である．プロセッサによっては，この割込み処理モデルに合致した割込み要求禁止フラグの機能を実現できない場合がある．また，割込み要求禁止フラグをセットすることで，複数のデバイスからの割込みがマスクされる場合がある．ソフトウェアの再利用性を上げるためには，あるデバイスからの割込みのみをマスクしたい場合には，そのデバイス自身の機能を使ってマスクを実現すべきである．

複数のデバイスからの割込み要求が接続されている割込み要求ラインを，エッジトリガに設定することは推奨されない．これは，次のような状況において，割込み要求を取りこぼす可能性があるためである．ある割込み要求ラインに，デバイスAとデバイスBからの割込み要求が接続されており，デバイスAの割込み処理を先に行う場合を考える．この時，デバイスBからの割込み要求によって割込みハンドラが実行され，デバイスAの割込み処理を行った後，デバイスBの割込み処理を行う前に，デバイスAからの割込み要求が発生した場合に，デバイスAからの割込み要求を取りこぼしてしまう．

clr_int，ras_intの振舞いを明確化するために，割込み要求フラグの概念を導入した．

NMI以外の割込み要求は，次の4つの条件が揃った場合に受け付けられる【NGKI0270】．

(a) 割込み要求ラインに対する割込み要求禁止フラグがクリアされていること

(b) 割込み要求ラインに設定された割込み優先度が，割込み優先度マスクの現在値よりも高い（優先度の値としては小さい）こと

(c) 全割込みロックフラグがクリアされていること

(d) 割込み要求がカーネル管理の割込みである場合には，CPUロックフラグがクリアされていること

これらの条件が揃った割込み要求が複数ある場合に，どの割込み要求が最初に受け付けられるかは，この仕様では規定しない【NGKI0271】．すなわち，割込み優先度の高い割込み要求が先に受け付けられるとは限らない．

割込み要求ラインを識別するための番号を，割込み番号と呼ぶ．割込み番号は，符号無しの整数型であるINTNO型で表し，ターゲットハードウェアの仕様から決まる自然な番号付けを基本として，ターゲット定義で付与される【NGKI0272】．そのため，1から連続した正の値であるとは限らない．

それに対して，アプリケーションが用意した割込みハンドラをカーネルに登録する場合に，割込みハンドラの登録対象となる割込みを識別するための番号を，割込みハンドラ番号と呼ぶ．割込みハンドラ番号は，符号無しの整数型であるINHNO型で表し，ターゲットハードウェアの仕様から決まる自然な番号付けを基本として，ターゲット定義で付与される【NGKI0273】．そのため，1から連続した正の値であるとは限らない．

割込みハンドラ番号は，割込み番号と1対1に対応するのが基本である（両者が一致する場合が多い）【NGKI0274】．

ただし，割込みを要求したデバイスが割込みベクタを生成してプロセッサに渡すアーキテクチャなどでは，割込み番号と割込みハンドラ番号の対応を，カーネルが管理していない場合がある【NGKI0275】．そこで，ターゲット定義で，割込み番号に対応しない割込みハンドラ番号や，割込みハンドラ番号に対応しない割込み番号を設ける場合もある【NGKI0276】．ただし，割込みサービスルーチンの登録対象にできる割込み番号は，割込みハンドラ番号との1対1の対応関係をカーネルが管理しているもののみである【NGKI0277】．

この節では，マルチプロセッサにおける割込み処理について説明する．この節の内容は，マルチプロセッサ対応カーネルにのみ適用される．

マルチプロセッサ対応カーネルでは，割込み処理モデルの概念図（図2-6）の中で，破線に囲まれた部分はプロセッサ毎に持ち，それ以外の部分はシステム全体で1つのみ持つ【NGKI0278】．すなわち，全割込みロックフラグ，CPUロックフラグ，割込み優先度マスクはプロセッサ毎に持つのに対して，割込み要求ラインおよびその属性（割込み要求禁止フラグ，割込み優先度，トリガモード，割込み要求フラグ）はシステム全体で共通に持つ．

割込み番号は，割込み要求ラインを識別するための番号であることから，割込み要求ラインが複数のプロセッサに接続されている場合でも，1つの割込み要求ラインには1つの割込み番号を付与する【NGKI0279】．逆に，複数のプロセッサが同じ種類のデバイスを個別に持っている場合でも，別のデバイスからの割込み要求ラインには異なる割込み番号を付与する（図2-7）【NGKI0280】．図2-7において，ローカルIRCは個々のプロセッサに対する割込みを制御するための回路であり，グローバルIRCはデバイスからの割込みをプロセッサに分配するための回路である．グローバルIRCは，必ず備わっているとは限らない．

割込み要求禁止フラグは，この仕様上はシステム全体で共通に持つこととしているが，実際のターゲットハードウェア（特に，グローバルIRCを備えていないもの）では，プロセッサ毎に持っている場合がある．そのため，ターゲット定義で，あるプロセッサで割込み要求禁止フラグを動的にセット／クリアしても，他のプロセッサに対しては割込みがマスク／マスク解除されない場合があるものとする【NGKI0281】．

複数のプロセッサに接続された割込み要求ラインに対して登録された割込みサービスルーチンは，それらのプロセッサのいずれによっても実行することができる【NGKI0282】．ただし，その内のどのプロセッサで割込みサービスルーチンを実行するかは，割込みサービスルーチンが属するクラスの割付け可能プロセッサにより決定される（「2.4.4 処理単位を実行するプロセッサ」の節を参照）．

割込みサービスルーチンが複数のプロセッサで実行できる場合に，連続して複数回の割込み要求があっても，割込みサービスルーチンが異なるプロセッサで同時に実行されることはない【NGKI0659】．

割込みサービスルーチンが属するクラスの割付け可能プロセッサは，登録対象の割込み要求ラインが接続されたプロセッサの集合に含まれていなければならない【NGKI0283】．また，同一の割込み要求ラインに対して登録する割込みサービスルーチンは，同一のクラスに属していなければならない【NGKI0284】．

それに対して，割込みハンドラはプロセッサ毎に登録する．そのため，同じ割込み要求に対応する割込みハンドラであっても，プロセッサ毎に異なる割込みハンドラ番号を付与する（図2-7）【NGKI0285】．割込みハンドラが属するクラスの初期割付けプロセッサは，割込みが要求されるプロセッサと一致していなければならない【NGKI0286】．

マルチプロセッサ対応カーネルにおける割込み番号の付与方法は，すべてのプロセッサに接続された割込み要求ラインに対しては，割込み番号の上位ビットを0とし，1つのプロセッサのみに接続された割込み要求ラインに対しては，割込み番号の上位ビットに，接続されたプロセッサのID番号を含める方法を基本とする．また，割込みハンドラ番号の付与方法は，割込みハンドラ番号の上位ビットに，その割込みハンドラを実行するプロセッサのID番号を含める方法を基本とする（図2-7）．

1つのプロセッサのみに接続された割込み要求ラインに対して登録された割込みサービスルーチンは，そのプロセッサのみを割付け可能プロセッサとするクラスに属していなければならない．

割込みサービスルーチンが異なるプロセッサで同時に実行されることはないこととした．

高い割込み応答性を求められるアプリケーションでは，カーネル内で割込みをマスクすることにより，割込み応答性の要求を満たせなくなる場合がある．このような要求に対応するために，カーネル内では，ある割込み優先度（これを，TMIN_INTPRIと書く）よりも高い割込み優先度を持つ割込みをマスクしないこととしている【NGKI0287】．TMIN_INTPRIを固定するか設定できるようにするか，設定できるようにする場合の設定方法は，ターゲット定義である【NGKI0288】．

TMIN_INTPRIよりも高い割込み優先度を持ち，カーネル内でマスクしない割込みを，カーネル管理外の割込みと呼ぶ．また，カーネル管理外の割込みによって起動される割込みハンドラを，カーネル管理外の割込みハンドラと呼ぶ．NMIは，カーネル管理外の割込みとして扱う．NMI以外にカーネル管理外の割込みを設けるか（設けられるようにするか）どうかは，ターゲット定義である【NGKI0289】．

それに対して，TMIN_INTPRIと同じかそれよりも低い割込み優先度を持つ割込みをカーネル管理の割込み，カーネル管理の割込みによって起動される割込みハンドラをカーネル管理の割込みハンドラと呼ぶ．

カーネル管理外の割込みハンドラは，カーネル内の割込み入口処理を経由せずに実行するのが基本である【NGKI0290】．ただし，すべての割込みで同じ番地に分岐するプロセッサでは，カーネル内の割込み入口処理を全く経由せずにカーネル管理外の割込みハンドラを実行することができず，入口処理の一部分を経由してカーネル管理外の割込みハンドラが実行されることになる【NGKI0291】．

カーネル管理外の割込みハンドラが実行開始される時のシステム状態とコンテキスト，割込みハンドラの終了時に行われる処理，割込みハンドラの記述方法は，ターゲット定義である【NGKI0292】．カーネル管理外の割込みハンドラからは，システムインタフェースレイヤのAPIとsns_ker，ext_kerのみを呼び出すことができ，その他のサービスコールを呼び出すことはできない【NGKI0293】．カーネル管理外の割込みハンドラから，その他のサービスコールを呼び出した場合の動作は，保証されない【NGKI0294】．

カーネル管理外の割込みの設定方法は，ターゲット定義で，次の3つの方法のいずれかが採用される【NGKI0295】．

(a-1) NMI以外にカーネル管理外の割込みを設けない

(a-2) カーネル構築時に特定の割込みをカーネル管理外にすると決める

これら場合には，カーネル管理外とする割込みはカーネル構築時（ターゲット依存部の実装時やカーネルのコンパイル時）に決まるため，カーネル管理外とする割込みをアプリケーション側で設定する必要はない【NGKI0296】．ここで，カーネル管理外とされた割込みに対して，カーネルのAPIにより割込みハンドラを登録できるかと，割込み要求ラインの属性を設定できるかは，ターゲット定義である【NGKI0297】．割込みハンドラを登録できる場合には，それを定義するAPIにおいて，カーネル管理外であることを示す割込みハンドラ属性（TA_NONKERNEL）を指定する【NGKI0298】．また，割込み要求ラインの属性を設定できる場合には，設定する割込み優先度をTMIN_INTPRIよりも高い値とする【NGKI0299】．

(b) カーネル管理外とする割込みをアプリケーションで設定できるようにする

この場合には，カーネル管理外とする割込みの設定は，次の方法で行う．まず，カーネル管理外とする割込みハンドラを定義するAPIにおいて，カーネル管理外であることを示す割込みハンドラ属性（TA_NONKERNEL）を指定する【NGKI0300】．また，カーネル管理外とする割込みの割込み要求ラインに対して設定する割込み優先度を，TMIN_INTPRIよりも高い値とする【NGKI0301】．

いずれの場合にも，カーネル管理の割込みハンドラを定義するAPIにおいて，TA_NONKERNEL属性を指定してはならない【NGKI0654】．また，カーネル管理の割込みの割込み要求ラインに対して設定する割込み優先度は，TMIN_INTPRIより高い値であってはならない【NGKI0302】．

カーネル管理外の割込みに対して，割込みサービスルーチンを登録することはできない【NGKI0303】．

アプリケーションは，プロセッサが検出するCPU例外の種類毎に，CPU例外ハンドラを登録することができる【NGKI0304】．プロセッサがCPU例外の発生を検出すると，カーネル内のCPU例外ハンドラの入口処理（CPU例外入口処理）を経由して，発生したCPU例外に対して登録したCPU例外ハンドラが呼び出される【NGKI0305】．

CPU例外ハンドラの登録対象となるCPU例外を識別するための番号を，CPU例外ハンドラ番号と呼ぶ．CPU例外ハンドラ番号は，符号無しの整数型であるEXCNO型で表し，ターゲットハードウェアの仕様から決まる自然な番号付けを基本として，ターゲット定義で付与される【NGKI0306】．そのため，1から連続した正の値であるとは限らない．

マルチプロセッサ対応カーネルでは，異なるプロセッサで発生するCPU例外を異なるCPU例外であると扱い，CPU例外ハンドラをプロセッサ毎に登録する方法と，CPU例外を複数のプロセッサ（すべてのプロセッサでも良い）で共通のものと扱い，CPU例外ハンドラを複数のプロセッサに対して登録する方法がある【NGKI0307】．どちらの方法を採用するか，または両方の方法を併用するかは，ターゲット定義である【NGKI0661】．

CPU例外ハンドラにおいては，CPU例外が発生した状態からのリカバリ処理を行う【NGKI0309】．どのようなリカバリ処理を行うかは，アプリケーション要求と，CPU例外の種類やそれが発生したコンテキストおよび状態に依存するが，大きく次の3つの方法に分類できる【NGKI0310】．

(a) カーネルに依存しない形でCPU例外の原因を取り除き，実行を継続する．

(b) CPU例外を起こしたタスクより優先して実行されるタスクを起動または待ち解除し，そのタスクでリカバリ処理を行う（例えば，CPU例外を起こしたタスクを強制終了し，再度起動する）．ただし，リカバリ処理を行うタスクを，CPU例外を起こしたタスクより優先して実行することができない場合には，この方法でリカバリ処理を行うことはできない【NGKI0311】．

(c) システム全体に対してリカバリ処理を行う（例えば，システムを再起動する）．

この中で(a)と(c)の方法は，カーネルの機能を必要としないため，CPU例外が発生したコンテキストおよび状態に依存せずに常に行える【NGKI0312】．それに対して(b)の方法は，CPU例外ハンドラからそのためのサービスコールを呼び出せることが必要であり，それが行えるかどうかは，CPU例外が発生したコンテキストおよび状態に依存する【NGKI0313】．

なお，発生したCPU例外に対して，CPU例外ハンドラを登録していない場合の振舞いは，ターゲット定義である【NGKI0314】．

CPU例外入口処理でCPU例外が発生し，それを処理するためのCPU例外ハンドラの入口処理で同じ原因でCPU例外が発生すると，CPU例外が繰り返し発生し，アプリケーションが登録したCPU例外ハンドラまで処理が到達しない状況が考えられる．このような状況が発生するかどうかはターゲットによるが，これが許容できない場合には，CPU例外入口処理を経由せずに，アプリケーションが用意したCPU例外ハンドラを直接実行するようにしなければならない．

マルチプロセッサ対応カーネルにおけるCPU例外ハンドラ番号の付与方法は，プロセッサ毎のCPU例外に対しては，CPU例外ハンドラ番号の上位ビットにプロセッサのID番号を含める方法を，すべてのプロセッサで共通のCPU例外に対しては，CPU例外ハンドラ番号の上位ビットを0とする方法を基本とする．

リカバリ処理を行うタスクを優先して実行することができない状況［NGKI0311］は，保護機能対応でないカーネルで最高優先度のタスクがCPU例外を起こした場合と，保護機能対応のカーネルでカーネルドメインに属する最高優先度のタスクがCPU例外を起こした場合に限られる．これらの場合にも，リカバリ処理を行うタスクを最高優先度とし，そのタスクの起動または待ち解除後に優先順位を回転させることで，リカバリ処理を行える場合もあるが，CPU例外を起こしたタスクが制約タスクの場合には適用できないなど，推奨できる方法ではない．

μITRON4.0仕様では，CPU例外からのリカバリ処理の方法については，記述されていない．

タスク例外処理ルーチンを廃止したことで，タスク例外処理ルーチンでリカバリ処理を行う方法が使えなくなったため，それに関する記述を削除した．

マルチプロセッサ対応カーネルで，CPU例外を複数のプロセッサで共通のものと扱うことを許すこととした．

CPU例外ハンドラからは，CPU例外発生時のディスパッチ保留状態を参照するサービスコール（xsns_dpn）を呼び出すことができる【NGKI0535】．

xsns_dpnは，CPU例外がタスクコンテキストで発生し，そのタスクがディスパッチできる状態であった場合にfalseを返す【NGKI0316】．xsns_dpnがfalseを返した場合，そのCPU例外ハンドラから，非タスクコンテキストから呼び出せるすべてのサービスコールを呼び出すことができ，［NGKI0311］の状況を除いては，(b)の方法によるリカバリ処理が可能である【NGKI0317】．

xsns_dpnがtrueを返した場合，そのCPU例外ハンドラからは，xsns_dpnに加えて，システムインタフェースレイヤのAPIとsns_ker，ext_kerのみを呼び出すことができ，その他のサービスコールを呼び出すことはできない【NGKI0321】．xsns_dpnがtrueを返したにもかかわらず，その他のサービスコールを呼び出した場合の動作は，保証されない【NGKI0322】．この場合には，(b)の方法によるリカバリ処理は行うことはできず，(a)または(c)の方法によるリカバリ処理を行うしかないことになる．

CPU例外ハンドラで行える操作に関しては，μITRON4.0仕様を見直し，全面的に修正した．

CPU例外発生時にタスク例外処理ルーチンを実行開始できない状態であったかを参照するサービスコール（xsns_xpn）を廃止した．

エラーコードによってアプリケーションに通知できないエラーをカーネルが検出した場合に，アプリケーションが登録したエラー処理を，カーネルが呼び出す場合がある【NGKI0323】．この場合に，カーネルが検出するエラーをCPU例外と同等に扱うものとし，エミュレートされたCPU例外と呼ぶ【NGKI0324】．また，エラー処理のためのプログラムをエミュレートされたCPU例外ハンドラと呼び，CPU例外ハンドラと同等に扱うものとする【NGKI0325】．

具体的には，エミュレートされたCPU例外ハンドラに対してもCPU例外ハンドラ番号が付与され，CPU例外ハンドラと同じ方法で登録できる【NGKI0326】．また，エミュレートされたCPU例外ハンドラからも，CPU例外ハンドラから呼び出せるサービスコールを呼び出すことができ，CPU例外ハンドラと同様のリカバリ処理を行うことができる【NGKI0327】．

エミュレートされたCPU例外およびCPU例外ハンドラは，μITRON4.0仕様に定義されていない概念である．

カーネル非動作状態，カーネル内のクリティカルセクションの実行中，全割込みロック状態，CPUロック状態，カーネル管理外の割込みハンドラ実行中のいずれかで発生したCPU例外を，カーネル管理外のCPU例外と呼ぶ．また，それによって起動されるCPU例外ハンドラを，カーネル管理外のCPU例外ハンドラと呼ぶ．さらに，カーネル管理外のCPU例外ハンドラ実行中に発生したCPU例外も，カーネル管理外のCPU例外とする．

それに対して，カーネル管理外のCPU例外以外のCPU例外をカーネル管理のCPU例外，カーネル管理のCPU例外によって起動されるCPU例外ハンドラをカーネル管理のCPU例外ハンドラと呼ぶ．

カーネル管理外のCPU例外ハンドラにおいては，xsns_dpnはtrueを返す【NGKI0330】．そのため，「2.8.2 CPU例外ハンドラから呼び出せるサービスコール」の節で述べた制限［NGKI0321］［NGKI0322］が課される．

カーネル管理外のCPU例外は，カーネル管理外の割込みと異なり，特定のCPU例外をカーネル外とするわけではない．同じCPU例外であっても，CPU例外が起こる状況によって，カーネル管理となる場合とカーネル管理外となる場合がある．

システムのリセット後，最初に実行するプログラムを，スタートアップモジュールと呼ぶ．スタートアップモジュールはカーネルの管理外であり，アプリケーションで用意するのが基本であるが，スタートアップモジュールで行うべき処理を明確にするために，カーネルの配布パッケージの中に，標準のスタートアップモジュールが用意されている【NGKI0331】．

標準のスタートアップモジュールは，プロセッサのモードとスタックポインタ等の初期化，NMIを除くすべての割込みのマスク（全割込みロック状態と同等の状態にする），ターゲットシステム依存の初期化フックの呼出し，ゼロ初期化データセクション（bssセクション）のクリア，初期化データセクション（dataセクション）の初期化，ソフトウェア環境（ライブラリなど）依存の初期化フックの呼出しを行った後，カーネルの初期化処理へ分岐する【NGKI0332】．ここで呼び出すターゲットシステム依存の初期化フックでは，リセット後に速やかに行うべき初期化処理を行うことが想定されている．

マルチプロセッサ対応カーネルでは，すべてのプロセッサがスタートアップモジュールを実行し，カーネルの初期化処理へ分岐する【NGKI0333】．ただし，共有リソースの初期化処理（ゼロ初期化データセクションのクリア，初期化データセクションの初期化，ソフトウェア環境依存の初期化フックの呼出しなど）は，マスタプロセッサのみで実行する【NGKI0334】．各プロセッサがカーネルの初期化処理へ分岐するのは，共有リソースの初期化処理が完了した後でなければならないため，スレーブプロセッサは，カーネルの初期化処理へ分岐する前に，マスタプロセッサによる共有リソースの初期化処理の完了を待ち合わせる必要がある【NGKI0335】．

カーネルの初期化処理においては，まず，カーネル自身の初期化処理（カーネル内のデータ構造の初期化，カーネルが用いるデバイスの初期化など）と静的APIの処理（オブジェクトの登録など）が行われる【NGKI0336】．静的APIのパラメータに関するエラーは，コンフィギュレータによって検出されるのが原則であるが，コンフィギュレータで検出できないエラーが，この処理中に検出される場合もある【NGKI0337】．

静的APIの処理順序によりシステムの規定された振舞いが変化する場合には，システムコンフィギュレーションファイルにおける静的APIの記述順と同じ順序で静的APIが処理された場合と，同じ振舞いとなる【NGKI0338】．例えば，静的APIによって同じ優先度のタスクを複数生成・起動した場合，静的APIの記述順が先のタスクが高い優先順位を持つ．それに対して，最初の通知時刻が同じである複数の周期通知の通知順序は，同じシステム時刻で行うべき処理が複数ある場合の処理順序が規定されないことから（「4.6.1 システム時刻管理」の節を参照），静的APIの記述順となるとは限らない．

次に，静的API（ATT_INI）により登録した初期化ルーチンが，システムコンフィギュレーションファイルにおける静的APIの記述順と同じ順序で実行される【NGKI0339】．

マルチプロセッサ対応カーネルでは，初期化ルーチンには，クラスに属さないグローバル初期化ルーチンと，クラスに属するローカル初期化ルーチンがある【NGKI0129】．グローバル初期化ルーチンは，すべてのプロセッサがカーネル自身の初期化処理と静的APIの処理を完了した後に，マスタプロセッサによって実行される【NGKI0340】．ローカル初期化ルーチンは，グローバル初期化ルーチンの実行が完了した後に，それが属するクラスの初期割付けプロセッサによって実行される【NGKI0341】．

以上が終了すると，カーネル非動作状態から動作状態に遷移し（「2.5.1 カーネル動作状態と非動作状態」の節を参照），カーネルの動作が開始される【NGKI0342】．具体的には，システム状態が，全割込みロック解除状態・CPUロック解除状態・割込み優先度マスク全解除状態・ディスパッチ許可状態に設定され（すなわち，ディスパッチ保留状態が解除され），タスクの実行が開始される．

マルチプロセッサ対応カーネルでは，すべてのプロセッサがローカル初期化ルーチンの実行を完了した後に，カーネル非動作状態から動作状態に遷移し，カーネルの動作が開始される【NGKI0343】．マルチプロセッサ対応カーネルにおけるシステム初期化の流れと，各プロセッサが同期を取るタイミングを，図2-8に示す【NGKI0344】．

μITRON4.0仕様においては，初期化ルーチンの実行は静的APIの処理に含まれるものとしていたが，この仕様では，初期化ルーチンを登録する静的APIの処理は，初期化ルーチンを登録することのみを意味し，初期化ルーチンの実行は含まないものとした．

カーネルを終了させるサービスコール（ext_ker）を呼び出すと，カーネル動作状態から非動作状態に遷移する（「2.5.1 カーネル動作状態と非動作状態」の節を参照）【NGKI0345】．具体的には，NMIを除くすべての割込みがマスクされ，タスクの実行が停止される．

マルチプロセッサ対応カーネルでは，カーネルを終了させるサービスコール（ext_ker）は，どのプロセッサからでも呼び出すことができる【NGKI0346】．1つのプロセッサでカーネルを終了させるサービスコールを呼び出すと，そのプロセッサがカーネル動作状態から非動作状態に遷移した後，他のプロセッサに対してカーネル終了処理の開始を要求する【NGKI0347】．複数のプロセッサから，カーネルを終了させるサービスコール（ext_ker）を呼び出してもよい【NGKI0348】．

次に，静的API（ATT_TER）により登録した終了処理ルーチンが，システムコンフィギュレーションファイルにおける静的APIの記述順と逆の順序で実行される【NGKI0349】．

マルチプロセッサ対応カーネルでは，終了処理ルーチンには，クラスに属さないグローバル終了処理ルーチンと，クラスに属するローカル終了処理ルーチンがある【NGKI0131】．ローカル終了処理ルーチンは，すべてのプロセッサがカーネル非動作状態に遷移した後に，それが属するクラスの初期割付けプロセッサによって実行される【NGKI0350】．グローバル終了処理ルーチンは，すべてのプロセッサでローカル終了処理ルーチンの実行が完了した後に，マスタプロセッサによって実行される【NGKI0351】．

以上が終了すると，ターゲットシステム依存の終了処理が呼び出される【NGKI0352】．ターゲットシステム依存の終了処理は，カーネルの管理外であり，アプリケーションで用意するのが基本であるが，カーネルの配布パッケージの中に，ターゲットシステム毎に標準的なルーチンが用意されている【NGKI0353】．標準のターゲットシステム依存の終了処理では，ソフトウェア環境（ライブラリなど）依存の終了処理フックを呼び出す【NGKI0354】．

マルチプロセッサ対応カーネルでは，すべてのプロセッサで，ターゲットシステム依存の終了処理が呼び出される【NGKI0355】．マルチプロセッサ対応カーネルにおけるシステム終了処理の流れと，各プロセッサが同期を取るタイミングを，図2-9に示す【NGKI0356】．

マルチプロセッサ対応カーネルで，あるプロセッサからカーネルを終了させるサービスコール（ext_ker）を呼び出しても，他のプロセッサがカーネル動作状態で割込みをマスクしたまま実行し続けると，カーネルが終了しない．

プロセッサが割込みをマスクしたまま実行し続けないようにするのは，アプリケーションの責任である．例えば，ある時間を超えて割込みをマスクしたまま実行し続けていないかを，ウォッチドッグタイマを用いて監視する方法が考えられる．割込みをマスクしたまま実行し続けていた場合には，そのプロセッサからもカーネルを終了させるサービスコール（ext_ker）を呼び出すことで，カーネルを終了させることができる．

μITRON4.0仕様には，システム終了に関する規定はない．

ID番号で識別するオブジェクトは，オブジェクトを生成する静的API（CRE_YYY）またはサービスコール（acre_yyy）によってカーネルに登録する【NGKI0357】．

オブジェクトを生成する静的API（CRE_YYY）は，生成するオブジェクトにID番号を割り付け，オブジェクトの識別名を割り付けたID番号にマクロ定義する【NGKI0359】．同じ識別名のオブジェクトが生成済みの場合には，E_OBJエラーとなる【NGKI0360】．

オブジェクトを生成するサービスコール（acre_yyy）は，割付け可能なID番号の数を指定する静的API（AID_YYY）によって確保されたID番号の中から，使用されていないID番号を1つ選び，生成するオブジェクトに割り付ける【NGKI0361】．割り付けたID番号は，サービスコールの返値としてアプリケーションに通知する【NGKI0362】．使用されていないID番号が残っていない場合には，E_NOIDエラーとなる【NGKI0363】．

割付け可能なID番号の数を指定する静的API（AID_YYY）は，システムコンフィギュレーションファイル中に複数記述することができる【NGKI0364】．その場合，各静的APIで指定した数の合計の数のID番号が確保される【NGKI0365】．

オブジェクトを生成するサービスコール（acre_yyy）によって登録したオブジェクトは，オブジェクトを削除するサービスコール（del_yyy）によって登録を解除することができる【NGKI0366】．登録解除したオブジェクトのID番号は，未使用の状態に戻され，新たに生成するオブジェクトに割り付けられる【NGKI0367】．この場合に，登録解除前のオブジェクトに対して行うつもりの操作が，新たに生成したオブジェクトに対して行われないように，注意が必要である．

オブジェクトを生成する静的APIによって登録したオブジェクトは，登録を解除することができない．登録を解除しようとした場合には，E_OBJエラーとなる【NGKI0369】．

タスク以外の処理単位は，その処理単位が実行されている間でも，登録解除することができる【NGKI0370】．この場合，登録解除された処理単位の実行が途中で終了させられることはなく，処理単位が自ら実行を終了するまで，処理単位の実行は継続される【NGKI0371】．

同期・通信オブジェクトを削除した時に，そのオブジェクトを待っているタスクがあった場合，それらのタスクは待ち解除され，待ち状態に遷移させたサービスコールはE_DLTエラーとなる【NGKI0372】．複数のタスクが待ち解除される場合には，待ち行列につながれていた順序で待ち解除される【NGKI0373】．削除した同期・通信オブジェクトが複数の待ち行列を持つ場合には，別の待ち行列で待っていたタスクの間の待ち解除の順序は，該当するサービスコール毎に規定する【NGKI0374】．

オブジェクトを再初期化するサービスコール（ini_yyy）は，指定したオブジェクトを削除した後に，同じパラメータで再度生成したのと等価の振舞いをする【NGKI0375】．ただし，オブジェクトを生成する静的APIによって登録したオブジェクトも，再初期化することができる【NGKI0376】．

なお，動的生成対応でないカーネルでは，オブジェクトを生成するサービスコール（acre_yyy），割付け可能なID番号の数を指定する静的API（AID_YYY），オブジェクトのアクセス許可ベクタを設定するサービスコール（sac_yyy），オブジェクトを削除するサービスコール（del_yyy）は，サポートされない【NGKI0377】．

ID番号を指定してオブジェクトを生成するサービスコール（cre_yyy）を廃止した．また，ID番号で識別するオブジェクトを，オブジェクトを追加する静的API（ATT_YYY）によってカーネルに登録する機能を廃止した．オブジェクトを生成する静的APIによって登録したオブジェクトは，登録解除できないこととした．

μITRON4.0仕様では，割付け可能なID番号の数を指定する静的API（AID_YYY）は規定されていない．

複数の待ち行列を持つ同期・通信オブジェクトを削除した時に，別の待ち行列で待っていたタスクの間の待ち解除の順序は，μITRON4.0仕様では実装依存とされている．

アクセス許可ベクタを指定してオブジェクトを生成する静的API（CRA_YYY）は廃止し，オブジェクトの登録後にアクセス許可ベクタを設定する静的API（SAC_YYY）をサポートすることとした．これにあわせて，アクセス許可ベクタを指定してオブジェクトを登録するサービスコール（cra_yyy，acra_yyy，ata_yyy）も廃止した．

ID番号で識別するオブジェクトを，オブジェクトを追加する静的API（ATT_YYY）によってカーネルに登録する機能を廃止した．

ID番号を指定してオブジェクトを生成するサービスコール（cre_yyy）とアクセス許可ベクタを指定してオブジェクトを登録するサービスコール（cra_yyy，acra_yyy，ata_yyy）を廃止したのは，必要性が低いと考えたためである．静的APIについても，サービスコールに整合するよう変更した．

オブジェクト番号で識別するオブジェクトは，オブジェクトを定義する静的API（DEF_YYY）またはサービスコール（def_yyy）によってカーネルに登録する【NGKI0378】．

オブジェクトを定義するサービスコール（def_yyy）によって登録したオブジェクトは，同じサービスコールを，オブジェクトの定義情報を入れたパケットへのポインタをNULLとして呼び出すことによって，登録を解除することができる【NGKI0379】．登録解除したオブジェクト番号は，オブジェクト登録前の状態に戻され，同じオブジェクト番号に対して新たにオブジェクトを定義することができる【NGKI0380】．登録解除されていないオブジェクト番号に対して再度オブジェクトを登録しようとした場合には，E_OBJエラーとなる【NGKI0381】．

オブジェクトを定義する静的APIによって登録したオブジェクトは，登録を解除することができない【NGKI0382】．登録を解除しようとした場合には，E_OBJエラーとなる【NGKI0383】．

なお，動的生成対応でないカーネルでは，オブジェクトを定義するサービスコール（def_yyy）はサポートされない【NGKI0384】．

この仕様では，オブジェクトの定義を変更したい場合には，一度登録解除した後に，新たにオブジェクトを定義する必要がある．また，オブジェクトを定義する静的APIによって登録したオブジェクトは，この仕様では，登録解除できないこととした．

識別する必要がないために，識別番号を持たないオブジェクトは，オブジェクトを追加する静的API（ATT_YYY）によってカーネルに登録する【NGKI0604】．

オブジェクトを生成する際に必要なメモリ領域の内，サイズが一定のものについては，コンフィギュレータによって，オブジェクトの管理ブロックなどの形で確保される【NGKI0665】．

それに対して，オブジェクトを生成する際に，サイズが一定でないメモリ領域を必要とする場合には，オブジェクトを生成する静的APIおよびサービスコールに，使用するメモリ領域の先頭番地を渡すパラメータを設ける【NGKI0385】．

静的APIにおいて，使用するメモリ領域の先頭番地を渡すパラメータをNULLとした場合，必要なメモリ領域は，コンフィギュレータによって確保される【NGKI0386】．

保護機能対応カーネルでは，コンフィギュレータによって確保されるメモリ領域は，別に規定がない限りは，カーネルドメイン向け（マルチプロセッサ対応カーネルの場合には，さらに，オブジェクトが属するクラス向け）の標準RAMリージョン内に確保される【NGKI0649】．

サービスコールにおいて，使用するメモリ領域の先頭番地を渡すパラメータをNULLとした場合，必要なメモリ領域は，カーネルによって，別に規定がない限りは，カーネルメモリプール領域から確保される【NGKI0618】．保護機能対応カーネルまたはマルチプロセッサ対応カーネルで，どのカーネルメモリプール領域が使用されるかについては，「4.13 システム構成管理機能」の節を参照すること．

コンフィギュレータとカーネルが，オブジェクト生成に必要なメモリ領域をどこに確保するかを規定した．

保護機能対応カーネルにおいて，オブジェクトが属する保護ドメインは，オブジェクトの登録時に決定し，登録後に変更することはできない【NGKI0387】．

オブジェクトを静的APIによって登録する場合には，オブジェクトを登録する静的APIを，そのオブジェクトを属させる保護ドメインの囲みの中に記述する［NGKI0459］．無所属のオブジェクトを登録する静的APIは，保護ドメインの囲みの外に記述する［NGKI0460］（「2.12.3 保護ドメインの指定」の節を参照）．

オブジェクトをサービスコールによって登録する場合には，オブジェクト属性にTA_DOM(domid)を指定することにより，オブジェクトを属させる保護ドメインを設定する【NGKI0390】．ここでdomidは，そのオブジェクトを属させる保護ドメインのID番号であり，TDOM_KERNEL（＝-1）を指定することでカーネルドメインに属させることができる．また，domidにTDOM_SELF（＝0）を指定するか，オブジェクト属性にTA_DOM(domid)を指定しないことで，自タスクが属する保護ドメインに属させることができる．さらに，無所属のオブジェクトを登録する場合には，domidにTDOM_NONE（＝-2）を指定する．

ただし，特定の保護ドメインのみに属することができるオブジェクトを登録するサービスコールの中には，オブジェクトを属させる保護ドメインをオブジェクト属性で設定する必要がないものもある【NGKI0391】．

割付け可能なID番号の数を指定する静的API（AID_YYY）で確保したID番号は，AID_YYYを保護ドメインの囲みの中に記述した場合には，その保護ドメインに属するオブジェクトに，保護ドメインの囲みの外に記述した場合には，無所属のオブジェクトに割り付けられる【NGKI0610】．

この仕様では，カーネルオブジェクトが属する保護ドメインを参照する機能は用意していない．

割付け可能なID番号は保護ドメイン毎に確保することにし，AID_YYYを保護ドメインの囲みの中にも記述できることとした．

オブジェクトをサービスコールによって登録する場合に，オブジェクトを属させる保護ドメインをオブジェクト属性で指定することにしたのは，保護機能対応でないカーネルとの互換性のためには，サービスコールのパラメータを増やさない方が望ましいためである．

マルチプロセッサ対応カーネルにおいて，オブジェクトが属するクラスは，オブジェクトの登録時に決定し，登録後に変更することはできない【NGKI0395】．

オブジェクトを静的APIによって登録する場合には，オブジェクトを登録する静的APIを，そのオブジェクトを属させるクラスの囲みの中に記述する［NGKI0470］．クラスに属さないオブジェクトを登録する静的APIは，クラスの囲みの外に記述する［NGKI0397］（「2.12.4 クラスの指定」の節を参照）．

オブジェクトをサービスコールによって登録する場合には，オブジェクト属性にTA_CLS(clsid)を指定することにより，オブジェクトを属させるクラスを設定する【NGKI0398】．ここでclsidは，そのオブジェクトを属させるクラスのID番号であり，clsidにTCLS_SELF（＝0）を指定するか，オブジェクト属性にTA_CLS(clsid)を指定しないことで，自タスクが属するクラスに属させることができる．

割付け可能なID番号の数を指定する静的API（AID_YYY）で確保したID番号は，AID_YYYを囲むクラスに属するオブジェクトにのみ割り付けられる【NGKI0399】．AID_YYYは，確保したID番号を割り付けるオブジェクトの属すべきクラスの囲みの中に記述しなければならない．クラスの囲みの外に記述した場合には，E_RSATRエラーとなる【NGKI0401】．

この仕様では，カーネルオブジェクトが属するクラスを参照する機能は用意していない．

オブジェクトをサービスコールによって登録する場合に，オブジェクトを属させるクラスをオブジェクト属性で指定することにしたのは，マルチプロセッサ対応でないカーネルとの互換性のためには，サービスコールのパラメータを増やさない方が望ましいためである．

ID番号で識別するオブジェクトのすべてと，オブジェクト番号で識別するオブジェクトの一部に対して，オブジェクトの状態を参照するサービスコール（ref_yyy，get_yyy）を用意する【NGKI0402】．

オブジェクトの状態を参照するサービスコールでは，オブジェクトの登録時に指定し，その後に変化しない情報（例えば，タスクのタスク属性や初期優先度）を参照するための機能は用意しないことを原則とする【NGKI0403】．自タスクの拡張情報を参照するサービスコール（get_inf）は，この原則に対する例外の一つである．

カーネルオブジェクトに対するアクセスは，そのオブジェクトに対して設定されたアクセス許可ベクタによって保護される【NGKI0405】．ただし，アクセス許可ベクタを持たないオブジェクトに対するアクセスや，特定のオブジェクトに関連しないシステムの状態に対する操作，オブジェクトを定義するサービスコールについては，スケジューリングに関係するものは保護ドメインに対するアクセス許可ベクタによって，その他はシステム状態に対するアクセス許可ベクタによって保護される【NGKI0568】．また，オブジェクトを生成するサービスコールは，生成するオブジェクトが属する保護ドメインに対するアクセス許可ベクタによって保護される【NGKI0612】．

アクセス許可ベクタ等によって許可されていないアクセス（アクセス違反）は，カーネルによって検出され，以下の方法によって通知される．

サービスコールにより，メモリオブジェクト以外のカーネルオブジェクトに対して，アクセス許可ベクタによって許可されていないアクセスを行おうとした場合，サービスコールからE_OACVエラーが返る【NGKI0408】．また，メモリオブジェクトに対して，アクセス許可ベクタによって許可されていない管理操作または参照操作を行おうとした場合も，サービスコールからE_OACVエラーが返る【NGKI0409】．

メモリオブジェクトに対して，通常のメモリアクセスにより，アクセス許可ベクタまたはメモリオブジェクト属性によって許可されていない書込みアクセスまたは読出しアクセス（実行アクセスを含む）を行おうとした場合，CPU例外ハンドラが起動される【NGKI0410】．どのCPU例外ハンドラが起動されるかは，ターゲット定義である【NGKI0411】．ターゲットによっては，エミュレートされたCPU例外ハンドラの場合もある．また，ターゲット定義で，アクセス違反の状況に応じて異なるCPU例外ハンドラが起動される場合もある．この（これらの）CPU例外ハンドラを，メモリアクセス違反ハンドラと呼ぶ．

メモリアクセス違反ハンドラで，アクセス違反を発生させたアクセスに関する情報（アクセスした番地，アクセスの種別，アクセスした命令の番地など）を参照する方法が，ターゲット定義で用意されている【NGKI0414】．

メモリオブジェクトに対して，サービスコールを通じて，アクセス許可ベクタまたはメモリオブジェクト属性によって許可されていない書込みアクセスまたは読出しアクセスを行おうとした場合，サービスコールからE_MACVエラーが返る【NGKI0412】．ただし，ターゲット定義で，E_MACVエラーが返るのに代えて，メモリアクセス違反ハンドラが起動される場合がある【NGKI0413】．

メモリオブジェクトとしてカーネルに登録されていないメモリ領域に対して，ユーザドメインから書込みアクセスまたは読出しアクセス（実行アクセスを含む）を行おうとした場合には，メモリオブジェクトに対するアクセスが許可されていない場合と同様に扱われる【NGKI0415】．

ユーザタスクから，サービスコールを通じて，メモリオブジェクトの境界を越えるメモリ領域にアクセスを行おうとした場合，サービスコールからE_MACVエラーが返る【NGKI0673】．ただし，ターゲット定義で，このエラーチェックが省略される場合がある【NGKI0674】．

ユーザタスクから，サービスコールを通じて，アラインされていないメモリアクセスを行おうとした場合，サービスコールからE_MACVエラーが返る【NGKI0670】．ただし，ターゲット定義で，E_MACVエラーが返るのに代えて，ターゲット定義のCPU例外ハンドラが起動される場合がある【NGKI0671】

以下の状況における振舞いは，この仕様では規定されず，ターゲットに依存する．

μITRON4.0/PX仕様では，アクセス保護の実装定義の制限について規定しているが，この仕様では，メモリオブジェクトに対するアクセス許可ベクタのターゲット定義の制限以外については規定していない．

オブジェクトを生成するサービスコールの保護は，生成するオブジェクトが属する保護ドメインに対するアクセス許可ベクタによって行うものとした．

サービスコールを通じて，メモリオブジェクトの境界を越えるメモリ領域にアクセスを行おうとした場合と，アラインされていないメモリアクセスを行おうとした場合の振舞い明記した．

オブジェクトを生成するサービスコールの保護は，生成するオブジェクトが属する保護ドメインに対するアクセス許可ベクタによって行うものとした．これに伴って，オブジェクトを生成する際に使用するリソース（ID番号，カーネルメモリプール領域）の確保量についても，保護ドメイン毎に設定することとした．

サービスコールを通じて，メモリオブジェクトの境界を越えるメモリ領域にアクセスを行おうとした場合と，アラインされていないメモリアクセスを行おうとした場合の振舞い明記した．

オブジェクトを登録するサービスコールを，そのオブジェクトのアクセス許可ベクタによって保護しないのは，オブジェクトを登録する前には，アクセス許可ベクタが設定されていないためである．

メモリオブジェクトの書込みアクセスと読出しアクセス（実行アクセスを含む）に対して設定できるアクセス許可パターンは，ターゲット定義で制限される場合がある【NGKI0417】．

ただし，少なくとも，次の5つの組み合わせの設定は，行うことができる．

(a) メモリオブジェクトが属する保護ドメインのみに，読出しアクセス（実行アクセスを含む）のみを許可する【NGKI0418】．これを，専有リードオンリー（private read only）と呼ぶ．

(b) メモリオブジェクトが属する保護ドメインのみに，書込みアクセスと読出しアクセス（実行アクセスを含む）を許可する【NGKI0419】．これを，専有リードライト（private read/write）と呼ぶ．

(c) すべての保護ドメインに，読出しアクセス（実行アクセスを含む）のみを許可する【NGKI0420】．これを，共有リードオンリー（shared read only）と呼ぶ．

(d) すべての保護ドメインに，書込みアクセスと読出しアクセス（実行アクセスを含む）を許可する【NGKI0421】．これを，共有リードライト（shared read/write）と呼ぶ．

(e) メモリオブジェクトが属する保護ドメインに，書込みアクセスと読出しアクセス（実行アクセスを含む）を許可し，他の保護ドメインには，読出しアクセス（実行アクセスを含む）のみを許可する【NGKI0422】．これを，共有リード専有ライト（shared read private write）と呼ぶ．

また，ターゲット定義で，1つの保護ドメインに登録できるメモリオブジェクトの数が制限される場合がある【NGKI0423】．

カーネルオブジェクトを登録した直後は，次に規定されるデフォルトのアクセス許可ベクタが設定される．

保護ドメインに属するカーネルオブジェクトに対しては，通常操作1，通常操作2，参照操作の3つの種別のアクセスが，その保護ドメインのみに許可される【NGKI0613】．すなわち，カーネルドメインに属するオブジェクトに対しては，上記の3つのアクセス種別のアクセス許可パターンがTACP_KERNELに，ユーザドメインに属するオブジェクトに対しては，上記の3つのアクセス種別のアクセス許可パターンがTACP(domid)（domidはオブジェクトが属する保護ドメインのID番号）に設定される．管理操作のアクセス許可パターンは，そのカーネルオブジェクトが属する保護ドメインに対する通常操作1のアクセス許可パターンと同じ値に設定される【NGKI0614】．

無所属のカーネルオブジェクトに対しては，通常操作1，通常操作2，参照操作の3つの種別のアクセスが，すべての保護ドメインに許可される【NGKI0615】．すなわち，上記の3つのアクセス種別のアクセス許可パターンが，TACP_SHAREDに設定される．管理操作のアクセス許可パターンは，無所属に対する通常操作1のアクセス許可パターンと同じ値に設定される【NGKI0616】．

保護ドメインのアクセス許可ベクタは，通常操作1，通常操作2，参照操作はその保護ドメインのみに許可され，管理操作はカーネルドメインのみに許可される【NGKI0569】．すなわち，カーネルドメインに対しては，4つのアクセス許可パターンがいずれもTACP_KERNELに，ユーザドメインに対しては，通常操作1，通常操作2，参照操作のアクセス許可パターンがTACP(domid)に，管理操作のアクセス許可パターンがTACP_KERNELに設定される．

無所属に対するアクセス許可ベクタは，通常操作1，通常操作2，参照操作はすべての保護ドメインに許可され，管理操作はカーネルドメインのみに許可される【NGKI0617】．すなわち，通常操作1，通常操作2，参照操作のアクセス許可パターンがTACP_SHAREDに，管理操作のアクセス許可パターンがTACP_KERNELに設定される．

システム状態1とシステム状態2のアクセス許可ベクタは，4つの種別のアクセスがいずれも，カーネルドメインのみに許可される【NGKI0426】．すなわち，8つのアクセス許可パターンがいずれも，TACP_KERNELに設定される．

保護ドメイン以外のカーネルオブジェクトに対する管理操作のアクセス許可パターンを，そのカーネルオブジェクトが属する保護ドメインに対する通常操作1（無所属のカーネルドメイン場合は，無所属に対する通常操作1）のアクセス許可パターンと同じ値に設定されるものとした．

アクセス許可ベクタをデフォルト以外の値に設定するために，カーネルオブジェクトのアクセス許可ベクタを設定する静的API（SAC_YYY）と，保護ドメインのアクセス許可ベクタを設定する静的API（ACV_DOM），システム状態のアクセス許可ベクタを設定する静的API（SAC_SYS）が用意されている【NGKI0570】．

また，動的生成対応カーネルにおいては，カーネルオブジェクトのアクセス許可ベクタを設定するサービスコール（sac_yyy）と，保護ドメインのアクセス許可ベクタを設定するサービスコール（sac_dom），システム状態のアクセス許可ベクタを設定するサービスコール（sac_sys）が用意されている【NGKI0571】．ただし，静的APIによって登録したオブジェクトは，サービスコール（sac_yyy）によってアクセス許可ベクタを設定することができない．アクセス許可ベクタを設定しようとした場合には，E_OBJエラーとなる【NGKI0430】．

メモリオブジェクトに対しては，アクセス許可ベクタを設定する静的APIは用意されておらず，オブジェクトを追加する静的API（ATT_YYY）によって，登録と同時にアクセス許可ベクタを設定することができる【NGKI0605】．アクセス許可ベクタの記述を省略した場合には，デフォルトのアクセス許可ベクタが設定される【NGKI0606】．

オブジェクトに対するアクセスが許可されているかは，そのオブジェクトにアクセスするサービスコールを呼び出した時点でチェックされる【NGKI0432】．そのため，アクセス許可ベクタを変更しても，変更以前に呼び出されたサービスコールの振舞いには影響しない．例えば，待ち行列を持つ同期・通信オブジェクトのアクセス許可ベクタを変更しても，呼び出した時点ですでに待ち行列につながれているタスクには影響しない．また，ミューテックスのアクセス許可ベクタを変更しても，呼び出した時点ですでにミューテックをロックしていたタスクには影響しない．

この仕様では，カーネルオブジェクトに設定されたアクセス許可ベクタを参照する機能は用意していない．

カーネルオブジェクトのアクセス許可ベクタをデフォルト以外の値に設定する際に，オブジェクトに対して同じ保護ドメインに属する処理単位からアクセスできるようにするには，その保護ドメインからアクセスできることを明示的に指定する必要がある．

アクセス許可ベクタを指定してオブジェクトを生成する静的API（CRA_YYY）は廃止し，オブジェクトの登録後にアクセス許可ベクタを設定する静的API（SAC_YYY）をサポートすることとした．

静的APIによって登録したオブジェクトは，サービスコール（sac_yyy）によってアクセス許可ベクタを設定することができないこととした．

オブジェクトの状態参照するサービスコール（ref_yyy）により，オブジェクトに設定されたアクセス許可ベクタを参照する機能サポートしないこととした．

メモリオブジェクトに対しては，オブジェクトを追加する静的API（ATT_YYY）によって，オブジェクトの登録と同時にアクセス許可ベクタを設定することができるようにし，登録と同時にアクセス許可ベクタを設定する静的API（ATA_YYY）は廃止した．

カーネルオブジェクトの生成に必要なメモリ領域（「2.10.4 オブジェクト生成に必要なメモリ領域」の節を参照）の中で，カーネルの内部およびカーネルドメインに属する処理単位のみからアクセスされるものを，カーネルの管理領域と呼ぶ．

ユーザドメインに属する処理単位からカーネルを保護するためには，カーネルの管理領域にアクセスできるのは，カーネルドメインのみでなければならない．そのため，カーネルの管理領域は，書込みアクセスおよび読出しアクセスが可能で，4つの種別のアクセスがカーネルドメインのみに許可されたメモリオブジェクト（これを，カーネル専用のメモリオブジェクトと呼ぶ）の中に置かれる【NGKI0433】．

カーネルの管理領域として，カーネル専用のメモリオブジェクトに含まれないメモリ領域を指定した場合，E_OBJエラーとなる【NGKI0434】．また，カーネルの管理領域の先頭番地にNULLを指定した場合，必要なメモリ領域が，カーネル専用のメモリオブジェクトの中に確保される【NGKI0435】．

以下のメモリ領域が，カーネルの管理領域に該当する．

ユーザタスクのユーザスタック領域と固定長メモリプール領域は，ユーザドメインに属する処理単位からもアクセスされるため，カーネルの管理領域には該当しない．

ユーザタスクが非特権モードで実行する間に用いるスタック領域を，システムスタック領域（「4.1 タスク管理機能」の節を参照）と対比させて，ユーザスタック領域と呼ぶ．ユーザスタック領域は，そのタスクと同じ保護ドメインに属する1つのメモリオブジェクトとしてカーネルに登録される【NGKI0437】．ただし，他のメモリオブジェクトとは異なり，次のように扱われる．

タスクのユーザスタック領域に対しては，そのタスクのみが書込みアクセスおよび読出しアクセスを行うことができる【NGKI0438】．そのため，通常操作1（書込みアクセス）と通常操作2（読出し・実行アクセス）に対するアクセス許可パターンは意味を持たない【NGKI0439】．管理操作と参照操作に対するアクセス許可パターンは，タスクと同じ値に設定される【NGKI0609】．また，ユーザスタック領域に対する実行アクセスは，禁止する【NGKI0663】．ただし，ターゲットハードウェアの制約によって実行アクセスを禁止できない場合には，ターゲット定義で，実行アクセスを禁止しないこととする【NGKI0440】．

ただし，上記の仕様を実現するために大きいオーバヘッドを生じる場合には，ターゲット定義で，タスクのユーザスタック領域を，そのタスクが属する保護ドメイン全体からアクセスできるものとする場合がある【NGKI0441】．

この仕様では，タスクのユーザスタック領域は，そのタスクのみがアクセスできるものとした．

カーネルやシステムサービスが管理するオブジェクトの生成情報や初期状態などを記述するファイルを，システムコンフィギュレーションファイル（system configuration file）と呼ぶ．また，システムコンフィギュレーションファイルを解釈して，カーネルやシステムサービスの構成・初期化情報を含むファイルなどを生成するツールを，コンフィギュレータ（configurator）と呼ぶ．

システムコンフィギュレーションファイルには，カーネルの静的API，システムサービスの静的API，保護ドメインの囲み，クラスの囲み，コンフィギュレータに対するINCLUDEディレクティブ，C言語プリプロセッサのインクルードディレクティブ（#include）と条件ディレクティブ（#if，#ifdefなど）のみを記述することができる【NGKI0442】．

コンフィギュレータに対するINCLUDEディレクティブは，システムコンフィギュレーションファイルを複数のファイルに分割して記述するために用いるもので，その文法は次の通りである【NGKI0619】．

コンフィギュレータは，INCLUDEディレクティブによって指定されたファイル中の記述を，システムコンフィギュレーションファイルの一部分として解釈する【NGKI0444】．すなわち，INCLUDEディレクティブによって指定されたファイル中には，カーネルの静的API，システムサービスの静的API，保護ドメインの囲み，クラスの囲み，コンフィギュレータに対するINCLUDEディレクティブ，C言語プリプロセッサのインクルードディレクティブと条件ディレクティブのみを記述することができる．

C言語プリプロセッサのインクルードディレクティブは，静的APIのパラメータを解釈するために必要なC言語のヘッダファイルを指定するために用いる【NGKI0445】．コンフィギュレータが生成するファイルでは，インクルードディレクティブは先頭に集められる【NGKI0447】．

C言語プリプロセッサの条件ディレクティブは，有効とする静的APIとC言語プリプロセッサのディレクティブを選択するために用いることができる【NGKI0620】．1つの静的APIの記述の途中に，条件ディレクティブを記述することはできない【NGKI0448】．

コンフィギュレータは，システムコンフィギュレーションファイル中の静的APIを，その記述順に解釈する【NGKI0449】．そのため例えば，タスクを生成する静的APIの前に，そのタスクにアクセス許可ベクタを設定する静的APIが記述されていた場合，アクセス許可ベクタを設定する静的APIがE_NOEXSエラーとなる．

C言語プリプロセッサのインクルードディレクティブは，コンフィギュレータが生成するファイルでは先頭に集められるため，インクルードするC言語のヘッダファイル中でマクロの定義を変更（定義を解除した後に，定義し直す）した場合，意図しない動作をする可能性がある．

C言語プリプロセッサの条件ディレクティブは，保護ドメインの囲みを無効にしない．そのため，条件ディレクティブで囲みが選択されなかった保護ドメインに対しても，保護ドメインIDが割り付けられる．

システムコンフィギュレーションファイルにおけるC言語プリプロセッサのディレクティブの扱いを全面的に見直し，コンフィギュレータに対するINCLUDEディレクティブを設けた．また，共通静的APIを廃止した．μITRON4.0仕様における#includeディレクティブの役割は，この仕様ではINCLUDEディレクティブに置き換わる．逆に，μITRON4.0仕様におけるINCLUDE静的APIの役割は，この仕様では#includeディレクティブに置き換わる．

C言語プリプロセッサの条件ディレクティブは，有効とするC言語プリプロセッサのディレクティブの選択にも用いることができるものとした．

静的APIは，次に述べる例外を除いては，C言語の関数呼出しと同様の文法で記述する【NGKI0450】．すなわち，静的APIの名称に続けて，静的APIの各パラメータを","で区切って列挙したものを"("と")"で囲んで記述し，最後に";"を記述する．ただし，静的APIのパラメータに構造体（または構造体へのポインタ）を記述する場合には，構造体の各フィールドを","で区切って列挙したものを"{"と"}"で囲んだ形で記述する【NGKI0451】．

サービスコールに対応する静的APIの場合，静的APIのパラメータは，対応するサービスコールのパラメータと同一とすることを原則とする【NGKI0452】．

静的APIのパラメータは，次の4種類に分類される．

(a) オブジェクト識別名

オブジェクトのID番号を表す識別名を指定するパラメータ．単一の識別名のみを記述することができる．

コンフィギュレータは，オブジェクト生成のための静的API（CRE_YYY）を処理する際に，オブジェクトにID番号を割り付け，構成・初期化ヘッダファイルに，指定された識別名を割り付けたID番号にマクロ定義するC言語プリプロセッサのディレクティブ（#define）を生成する【NGKI0453】．

オブジェクト生成以外の静的APIが，オブジェクトのID番号をパラメータに取る場合（カーネルの静的APIでは，SAC_TSKのtskidパラメータ等がこれに該当する）には，パラメータとして記述する識別名は，生成済みのオブジェクトの名称を表す識別名でなければならない．そうでない場合には，コンフィギュレータがエラーを報告する【NGKI0455】．

静的APIの整数定数式パラメータの記述に，オブジェクト識別名を使用することはできない【NGKI0456】．

(b) 整数定数式パラメータ

オブジェクト番号や機能コード，オブジェクト属性，サイズや数，優先度など，整数値を指定するパラメータ．プログラムが配置される番地に依存せずに値の決まる整数定数式を記述することができる．

整数定数式の解釈に必要な定義や宣言等は，システムコンフィギュレーションファイルからC言語プリプロセッサのインクルードディレクティブによってインクルードするファイルに含まれていなければならない【NGKI0457】．

(c) 一般定数式パラメータ

処理単位のエントリ番地，メモリ領域の先頭番地，拡張情報など，番地を指定する可能性のあるパラメータ．任意の定数式を記述することができる．

定数式の解釈に必要な定義や宣言等は，システムコンフィギュレーションファイルからC言語プリプロセッサのインクルードディレクティブによってインクルードするファイルに含まれていなければならない【NGKI0458】．

NULLを指定することが特別な意味を持つ一般定数式パラメータにおいて，NULLの意味を持たせたい場合には，静的APIのパラメータに「NULL」と記述しなければならない【NGKI0638】．NULLに展開されるマクロを記述しても，NULLの意味にはならないので注意すること．

(d) 文字列パラメータ

オブジェクトモジュール名やセクション名など，文字列を指定するパラメータ．任意の文字列を，C言語の文字列の記法で記述することができる．

μITRON4.0仕様においては，静的APIのパラメータを次の4種類に分類していたが，コンフィギュレータの仕組みを見直したことに伴い全面的に見直した．

(A) 自動割付け対応整数値パラメータ
(B) 自動割付け非対応整数値パラメータ
(C) プリプロセッサ定数式パラメータ
(D) 一般定数式パラメータ

この仕様の(a)が，おおよそμITRON4.0仕様の(A)に相当するが，(a)には整数値を記述できない点が異なる．(b)〜(c)と(B)〜(D)の間には単純な対応関係がないが，記述できる定数式の範囲には，(B)⊂(C)⊂(b)⊂(c)＝(D)の関係がある．

μITRON4.0仕様では，静的APIのパラメータは基本的には(D)とし，コンフィギュレータが値を知る必要があるパラメータを(B)，構成・初期化ファイルに生成するC言語プリプロセッサの条件ディレクティブ（#if）中に含めたい可能性のあるパラメータを(C)としていた．

それに対して，この仕様におけるコンフィギュレータの処理モデル（「2.12.5 コンフィギュレータの処理モデル」の節を参照）では，コンフィギュレータのパス2において定数式パラメータの値を知ることができるため，(B)〜(D)の区別をする必要がない．そのため，静的APIのパラメータは基本的には(b)とし，パス2で値を知ることのできない定数式パラメータのみを(c)としている．

保護機能対応カーネルでは，オブジェクトを登録する静的API等を，そのオブジェクトを属させる保護ドメインの囲みの中に記述する【NGKI0459】．無所属のオブジェクトを登録する静的APIは，保護ドメインの囲みの外に記述する【NGKI0460】．保護ドメインに属すべきオブジェクトを登録する静的API等を，保護ドメインの囲みの外に記述した場合には，コンフィギュレータがE_RSATRエラーを報告する【NGKI0461】．

ユーザドメインの囲みの文法は次の通り【NGKI0462】．

保護ドメイン名には，ユーザドメインの名称を表す単一の識別名のみを記述することができる【NGKI0463】．

コンフィギュレータは，ユーザドメインの囲みを処理する際に，ユーザドメインに保護ドメインIDを割り付け，構成・初期化ヘッダファイルに，指定された保護ドメイン名を割り付けた保護ドメインIDにマクロ定義するC言語プリプロセッサのディレクティブ（#define）を生成する【NGKI0464】．また，ユーザドメインの囲みの中およびそれ以降に記述する静的APIの整数定数式パラメータの記述に保護ドメイン名を記述すると，割り付けた保護ドメインIDの値に評価される【NGKI0465】．

ユーザドメインの囲みの中を空にすることで，ユーザドメインへの保護ドメインIDの割付けのみを行うことができる【NGKI0466】．

カーネルドメインの囲みの文法は次の通り【NGKI0467】．

同じ保護ドメイン名を指定したユーザドメインの囲みや，カーネルドメインの囲みを，複数回記述してもよい【NGKI0468】．保護機能対応でないカーネルで保護ドメインの囲みを記述した場合や，保護ドメインの囲みの中に保護ドメインの囲みを記述した場合には，コンフィギュレータがエラーを報告する【NGKI0469】．

保護ドメインの囲みの文法を変更した．

保護ドメインに属すべきオブジェクトを登録する静的API等を保護ドメインの囲みの外に記述した場合のエラーコードをE_RSATRとしたのは，オブジェクトを動的に登録するAPIにおいては，オブジェクトの属する保護ドメインを，オブジェクト属性によって指定するためである．

マルチプロセッサ対応カーネルでは，オブジェクトを登録する静的API等を，そのオブジェクトを属させるクラスの囲みの中に記述する【NGKI0470】．クラスに属さないオブジェクトを登録する静的API等は，クラスの囲みの外に記述する【NGKI0397】．クラスに属すべきオブジェクトを登録する静的API等を，クラスの囲みの外に記述した場合や，クラスに属さないオブジェクトを登録する静的API等を，クラスの囲みの中に記述した場合には，コンフィギュレータがE_RSATRエラーを報告する【NGKI0471】．

クラスの囲みの文法は次の通り【NGKI0472】．

クラスIDには，静的APIの整数定数式パラメータと同等の定数式を記述することができる【NGKI0473】．使用できないクラスIDを指定した場合には，コンフィギュレータがE_IDエラーを報告する【NGKI0474】．

同じクラスIDを指定したクラスの囲みを複数回記述してもよい【NGKI0475】．マルチプロセッサ対応でないカーネルでクラスの囲みを記述した場合や，クラスの囲みの中にクラスの囲みを記述した場合には，コンフィギュレータがエラーを報告する【NGKI0476】．

なお，保護機能とマルチプロセッサの両方に対応するカーネルでは，保護ドメインの囲みとクラスの囲みはどちらが外側になっていてもよい【NGKI0477】．

クラスに属すべきオブジェクトを登録する静的API等をクラスの囲みの外に記述した場合のエラーコードをE_RSATRとしたのは，オブジェクトを動的に登録するAPIにおいては，オブジェクトの属するクラスを，オブジェクト属性によって指定するためである．

コンフィギュレータは，次の3つないしは4つのパスにより，システムコンフィギュレーションファイルを解釈し，構成・初期化情報を含むファイルなどを生成する（図2-10）．

最初のパス1では，システムコンフィギュレーションファイルを解釈し，そこに含まれる静的APIの整数定数式パラメータの値をCコンパイラを用いて求めるために，パラメータ計算用C言語ファイル（cfg1_out.c）を生成する．この時，システムコンフィギュレーションファイルに含まれるC言語プリプロセッサのインクルードディレクティブは，パラメータ計算用C言語ファイルの先頭に集めて生成する．また，条件ディレクティブは，順序も含めて，そのままの形でパラメータ計算用C言語ファイルに出力する．システムコンフィギュレーションファイルに文法エラーや未サポートの記述があった場合，オブジェクトの識別名に重複があった場合，ユーザドメインの数が制限を超えた場合には，この段階でエラーが検出される．

次に，Cコンパイラおよび関連ツールを用いて，パラメータ計算用C言語ファイルをコンパイルし，パラメータの計算結果を含むロードモジュール（パラメータ計算結果ファイル，cfg1_out）を生成する．静的APIの整数定数式パラメータに解釈できない式が記述された場合には，この段階でエラーが検出される．

コンフィギュレータのパス2では，パス1で生成されたロードモジュールから，C言語プリプロセッサの条件ディレクティブによりどの静的APIが有効となったかと，それらの静的APIの整数定数式パラメータの値を取り出し，カーネルおよびシステムサービスの構成・初期化ファイル（kernel_cfg.c）と構成・初期化ヘッダファイル（kernel_cfg.h）を生成する．構成・初期化ヘッダファイルには，登録できるオブジェクトの数（動的生成対応でないカーネルでは，静的APIによって登録されたオブジェクトの数に一致）やオブジェクトのID番号などの定義を出力する．静的APIの整数定数式パラメータに不正がある場合には，この段階でエラーが検出される．

パス2で生成されたファイルを，他のソースファイルやオブジェクトファイルとあわせてコンパイルし，アプリケーションのロードモジュールを生成する．静的APIの一般定数式パラメータに解釈できない式が記述された場合には，この段階でエラーが検出される．

コンフィギュレータのパス3では，パス2で生成されたロードモジュールから，静的APIのパラメータの値などを取り出し，妥当性のチェックを行う．静的APIの一般定数式パラメータに不正がある場合には，この段階でエラーが検出される．

保護機能対応カーネルで自動メモリ配置の場合には，メモリ配置を決定し，メモリ保護のための設定情報を生成するために，さらに以下の処理を行う（図2-11）．

コンフィギュレータは，決定したメモリ配置に従ってロードモジュールを生成するために，リンカスクリプト（ldscript.ld）を生成する．また，メモリ保護のための設定情報を，メモリ構成・初期化ファイル（kernel_mem.c）に生成する．これらのファイルを生成するためには，パス3以降で初めて得られる情報が必要となるため，これらのファイルはパス3以降でしか生成できず，最終的なロードモジュールも，パス3以降で生成する．

そのため，パス2で生成されたロードモジュールは，仮のロードモジュールという位置付けになる．ここで，パス3以降で必要な情報を取り出し，最終的なロードモジュールのサイズを割り出せるように，パス3以降でメモリ構成・初期化ファイルに生成するのと同様のデータ構造を，パス2において仮のメモリ構成・初期化ファイル（kernel_mem2.c）に生成する．また，これをリンクするための仮のリンカスクリプト（cfg2_out.ld）を生成し，これらを用いて仮のロードモジュール（cfg2_out）を生成する．

パス3は，ターゲット依存で用いるパスで，メモリ配置やメモリ保護のための設定情報のサイズを最適化するための処理を行う．パス2で生成された仮のロードモジュールから必要な情報を取り出し，再度，仮のメモリ構成・初期化ファイル（kernel_mem3.c）と仮のリンカスクリプト（cfg3_out.ld）を生成する．また，これらを用いて仮のロードモジュール（cfg3_out）を生成する．この段階で，メモリオブジェクトに重なりがあるなどのエラーが検出される場合もある．

パス4では，パス3（パス3を用いない場合はパス2）で生成された仮のロードモジュールから必要な情報を取り出し，最終的なメモリ構成・初期化ファイル（kernel_mem.c）とリンカスクリプト（ldscript.ld）を生成する．またパス4では，保護機能対応でないカーネルにおいてパス3で行っていた静的APIパラメータの値などの妥当性のチェックも行う．そのため，静的APIの一般定数式パラメータに不正がある場合には，この段階でエラーが検出される．

パス4で生成されたファイルを，他のソースファイルとあわせてコンパイルし，アプリケーションの最終的なロードモジュールを生成する．

最後に，最終的なロードモジュールが，パス3（パス3を用いない場合はパス2）で生成された仮のロードモジュールと同じメモリ配置であることをチェックする．両者のメモリ配置が異なっていた場合には，ロードモジュールが正しく生成されていない可能性があるが，これは，コンフィギュレーション処理の不具合を示すものである．

なお，コンフィギュレータがロードモジュールから情報を取り出す際には，ロードモジュールからダンプファイル（Sレコードフォーマットなどファイル）とシンボルファイル（ロードモジュール中の各シンボルとアドレスの対応表を含むファイル）を生成し，それらのファイルを読み込む．

コンフィギュレータの処理モデルは全面的に変更した．

静的APIのパラメータに関するエラー検出は，同じものがサービスコールとして呼ばれた場合と同等とすることを原則とする【NGKI0478】．言い換えると，サービスコールによっても検出できないエラーは，静的APIにおいても検出しない．静的APIの機能説明中の「E_XXXXXエラーとなる」または「E_XXXXXエラーが返る」という記述は，コンフィギュレータがそのエラーを検出することを意味する．

ただし，エラーの種類によっては，サービスコールと同等のエラー検出を行うことが難しいため，そのようなものについては例外とする【NGKI0479】．例えば，メモリ不足をコンフィギュレータによって検出するのは容易ではない．

逆に，オブジェクト属性については，サービスコールより強力なエラーチェックを行える可能性がある．例えば，タスク属性にTA_STAと記述されている場合，サービスコールではエラーを検出できないが，コンフィギュレータでは検出できる可能性がある．ただし，このようなエラー検出を完全に行おうとするとコンフィギュレータが複雑になるため，このようなエラーを検出することは必須とせず，検出できた場合には警告メッセージを出力する【NGKI0480】．

なお，コンフィギュレータは，この仕様で警告メッセージを出力すると規定されている以外の状況でも，警告メッセージを出力する場合がある【NGKI0641】．

μITRON4.0仕様では，静的APIのパラメータに関するエラー検出について規定されていない．

アプリケーション設計者がオブジェクトのID番号を指定するために，コンフィギュレータのオプション機能として，以下の機能が用意されている．

コンフィギュレータのオプション指定により，オブジェクト識別名とID番号の対応表を含むファイルを渡すと，コンフィギュレータはそれに従ってオブジェクトにID番号を割り付ける【NGKI0481】．それに従ったID番号割付けができない場合（ID番号に抜けができる場合など）には，コンフィギュレータはエラーを報告する【NGKI0482】．

またコンフィギュレータは，オプション指定により，オブジェクト識別名とコンフィギュレータが割り付けたID番号の対応表を含むファイルを，コンフィギュレータに渡すファイルと同じフォーマットで生成する【NGKI0483】．

μITRON4.0仕様では，オブジェクト生成のための静的APIのID番号を指定するパラメータに整数値を記述できるため，このような機能は用意されていない．

TOPPERS共通定義（共通データ型，共通定数，共通マクロ）は，TOPPERS共通ヘッダファイル（t_stddef.h）およびそこからインクルードされるファイルに含まれている【NGKI0484】．TOPPERS共通定義を用いる場合には，TOPPERS共通ヘッダファイルをインクルードする【NGKI0485】．

TOPPERS共通ヘッダファイルは，カーネルヘッダファイル（kernel.h）やシステムインタフェースレイヤヘッダファイル（sil.h）からインクルードされるため，これらのファイルをインクルードする場合には，TOPPERS共通ヘッダファイルを直接インクルードする必要はない【NGKI0486】．

C90に規定されているデータ型以外で，TOPPERSソフトウェアで共通に用いるデータ型は次の通りである（一部，C90に規定されているものも含む）【NGKI0542】．

ここで，データ型が「AまたはB」とは，AかBのいずれかの値を取ることを示す．例えばER_BOOLは，エラーコードまたは真偽値のいずれかの値を取る．

int8_t，uint8_t，int64_t，uint64_t，int128_t，uint128_t，float32_t，double64_tが使用できるかどうかは，ターゲット定義である【NGKI0488】．これらが使用できるかどうかは，それぞれ，INT8_MAX，UINT8_MAX，INT64_MAX，UINT64_MAX，INT128_MAX，UINT128_MAX，FLOAT32_MAX，DOUBLE64_MAXがマクロ定義されているかどうかで判別することができる【NGKI0489】．IEEE754準拠の浮動小数点数がサポートされていない場合には，ターゲット定義で，float32_tとdouble64_tは使用できないものとする【NGKI0490】．

B，UB，H，UH，W，UW，D，UD，VP_INTに代えて，C99準拠のint8_t，uint8_t，int16_t，uint16_t，int32_t，uint32_t，int64_t，uint64_t，intptr_tを用いることにした．また，uintptr_t，int128_t，uint128_tを用意することにした．

メモリ領域のサイズを表すデータ型として，SIZEに代えて，C90準拠のsize_tを用いることにした．

データタイプが定まらないものへのポインタを表すデータ型であるVPは，void*と等価であるため，用意しないことにした．また，ターゲットシステムにより振舞いが一定しないことから，VB，VH，VW，VDに代わるデータ型は用意しないことにした．

INT，UINTに代えて，C99の型名と相性が良いint_t，uint_tを用いることにした．また，32ビット以上かつint_t型（またはuint_t型）以上のサイズが保証される整数型として，long_t，ulong_tを用意し，8ビット以上のサイズで必ず存在する整数型として，C99準拠のint_least8_t，uint_least8_tを導入することにした．int_least16_t，uint_least16_t，int_least32_t，uint_least32_tを導入しなかったのは，16ビットおよび32ビットの整数型があることを仮定しており，それぞれint16_t，uint16_t，int32_t，uint32_tで代用できるためである．

TECSとの整合性を取るために，BOOLに代えて，bool_tを用いることにした．また，IEEE754準拠の単精度浮動小数点数を表す型としてfloat32_t，IEEE754準拠の倍精度浮動小数点数を表す型としてdouble64_tを導入した．

高分解能タイマのカウント値のデータ型としてHRTCNTを，オブジェクト管理領域を確保するためのデータ型としてMB_Tを用意することにした．

メモリ領域のサイズを表すデータ型として，SIZEに代えて，C90準拠のsize_tを用いることにした．

性能評価用システム時刻のためのデータ型であるSYSUTMを廃止し，高分解能タイマのカウント値のデータ型であるHRTCNTを追加した．

C90に規定されている定数以外で，TOPPERSソフトウェアで共通に用いる定数は次の通りである（一部，C90に規定されているものも含む）．

BOOLをbool_tに代えたことから，TRUEおよびFALSEに代えて，trueおよびfalseを用いることにした．

TOPPERSソフトウェアで共通に用いるメインエラーコードは次の通りである【NGKI0540】．

(A) 内部エラークラス（EC_SYS，-5〜-8）

(B) 未サポートエラークラス（EC_NOSPT，-9〜-16）

(C) パラメータエラークラス（EC_PAR，-17〜-24）

(D) 呼出しコンテキストエラークラス（EC_CTX，-25〜-32）

(E) 資源不足エラークラス（EC_NOMEM，-33〜-40）

(F) オブジェクト状態エラークラス（EC_OBJ，-41〜-48）

(G) 待ち解除エラークラス（EC_RLWAI，-49〜-56）

(H) 警告クラス（EC_WARN，-57〜-64）

このエラークラスに属するエラーコードは，警告を表すエラーコードであり，［NGKI0019］の原則では例外としている．

(I) 通信エラークラス（EC_COMM，-65〜-72）

このエラークラスに属するエラーコードは，通信エラー表すエラーコードであり，［NGKI0019］の原則では例外としている．

通信エラークラスは，μITRON4.0仕様に規定されていないエラークラスである．E_NORES，E_RASTER，E_COMMは，μITRON4.0仕様に規定されていないエラーコードである．

通信エラークラスは，TOPPERS新世代カーネル統合仕様に規定されていないエラークラスである．E_RASTER，E_COMMは，TOPPERS新世代カーネル統合仕様に規定されていないエラーコードである．

μITRON4.0仕様では，エラーコード構成・分解マクロ（ERCD，MERCD，SERCD）のみが定義されており，μITRON4.0/PX仕様で，アクセス許可パターン構成マクロ（TACP）が追加定義されている．他は追加定義したものである．

C99に用意されていないUINT_CとULONG_Cを導入したのは，アセンブリ言語からも参照する定数を記述するためである．C言語のみで用いる定数をこれらのマクロを使って記述する必要はない．

ここで，TACPのパラメータ（domid）には，ユーザドメインのID番号のみを指定することができる【NGKI0504】．TDOM_SELF，TDOM_KERNEL，TDOM_NONEを指定した場合，どのようなアクセス許可パターンが構成されるかは保証されない【NGKI0505】．

カーネルを用いるために必要な定義は，カーネルヘッダファイル（kernel.h）およびそこからインクルードされるファイルに含まれている【NGKI0507】．カーネルを用いる場合には，カーネルヘッダファイルをインクルードする【NGKI0508】．

ただし，カーネルを用いるために必要な定義の中で，コンフィギュレータによって生成されるものは，カーネル構成・初期化ヘッダファイル（kernel_cfg.h）に含まれる【NGKI0509】．具体的には，登録できるオブジェクトの数（TNUM_YYY）やオブジェクトのID番号などの定義が，これに該当する．これらの定義を用いる場合には，カーネル構成・初期化ヘッダファイルをインクルードする【NGKI0510】．

μITRON4.0仕様で規定されており，この仕様で廃止されたデータ型および定数を用いる場合には，ITRON仕様互換ヘッダファイル（itron.h）をインクルードする【NGKI0511】．

この仕様では，コンフィギュレータが生成するヘッダファイルに，オブジェクトのID番号の定義に加えて，登録できるオブジェクトの数（TNUM_YYY）の定義が含まれることとした．これに伴い，ヘッダファイルの名称を，μITRON4.0仕様の自動割付け結果ヘッダファイル（kernel_id.h）から，カーネル構成・初期化ヘッダファイル（kernel_cfg.h）に変更した．

値が0のオブジェクト属性（TA_HLNG，TA_TFIFO，TA_WSGL）は，デフォルトの扱いにして廃止した．これは，「(tskatr & TA_HLNG) != 0U」のような間違いを防ぐためである．TA_ASMは，有効な使途がないために廃止した．メールボックス機能を廃止したため，TA_MPRIとTA_MFIFOは廃止した．

「2.14.4 TOPPERS共通エラーコード」の節で定義したメインエラーコードの中で，E_CLS，E_WBLK，E_BOVR，E_COMMの4つは，カーネルでは使用しない【NGKI0541】．

ASP3カーネルでは，サービスコールから，E_RSFN，E_RSATR，E_MACV，E_OACV，E_NOMEM，E_NOID，E_NORES，E_NOEXSが返る状況は起こらない【ASPS0011】．E_RSATRは，コンフィギュレータによって検出される【ASPS0012】．ただし，動的生成機能拡張パッケージでは，サービスコールから，E_RSATR，E_NOMEM，E_NOID，E_NOEXSが返る状況が起こる【ASPS0013】．

FMP3カーネルでは，サービスコールから，E_RSFN，E_RSATR，E_MACV，E_OACV，E_NOMEM，E_NOID，E_NORES，E_NOEXSが返る状況は起こらない【FMPS0007】．E_RSATRとE_NORESは，コンフィギュレータによって検出される【FMPS0008】．

HRP3カーネルでは，サービスコールから，E_RSATR，E_NOID，E_NORESが返る状況は起こらない【HRPS0006】．E_RSATRは，コンフィギュレータによって検出される【HRPS0007】．ただし，動的生成機能拡張パッケージでは，サービスコールから，E_RSATR，E_NOIDが返る状況が起こる【HRPS0011】．

HRMP3カーネルでは，サービスコールから，E_RSATR，E_NOID，E_NORESが返る状況は起こらない【HRMPS0008】．E_RSATRとE_NORESは，コンフィギュレータによって検出される【HRMPS0009】．

SSP3カーネルでは，サービスコールから，E_RSFN，E_RSATR，E_MACV，E_OACV，E_ILUSE，E_NOMEM，E_NOID，E_NORES，E_NOEXS，E_RLWAI，E_TMOUT，E_DLTが返る状況は起こらない【SSPS0008】．E_RSATRは，コンフィギュレータによって検出される【SSPS0009】．

スタック領域をアプリケーションで確保するために，次のデータ型とマクロを用意している【NGKI0516】．

これらを用いて，サイズszのスタック領域を確保する方法は次の通り【NGKI0517】．

この方法で確保したスタック領域を，サービスコールまたは静的APIに渡す場合，スタック領域のサイズにはROUND_STK_T(sz)を，スタック領域の先頭番地には<スタック領域の変数名>を指定する【NGKI0518】．

ただし，保護機能対応カーネルにおいては，上の方法によりタスクのユーザスタック領域を確保することはできない【NGKI0519】．詳しくは，「4.1 タスク管理機能」の節のCRE_TSKの機能の項を参照すること．

保護機能対応カーネルでは，オブジェクトが属する保護ドメインを指定するためのオブジェクト属性を作るマクロとして，次のマクロを用意している【NGKI0520】．

マルチプロセッサ対応カーネルでは，オブジェクトが属するクラスを指定するためのオブジェクト属性を作るマクロとして，次のマクロを用意している【NGKI0521】．

保護機能対応カーネルでは，サービスコールの呼出し方法を指定するためのマクロとして，次のマクロを用意している【NGKI0522】．

保護機能とマルチプロセッサのいずれかまたは両方に対応するカーネルでは，スケジューリング単位番号を構成するためのマクロとして，次のマクロを用意している【NGKI0634】．

スケジューリング単位番号を構成するマクロ（SCHEDNO）を追加した．

ASP3カーネルでは，タスク優先度の最大値（TMAX_TPRI）は16に固定されている【ASPS0014】．ただし，タスク優先度拡張パッケージを用いると，TMAX_TPRIを256に拡張することができる【ASPS0015】．

FMP3カーネルでは，タスク優先度の最大値（TMAX_TPRI）は16に固定されている【FMPS0009】．

HRP3カーネルでは，タスク優先度の最大値（TMAX_TPRI）は16に固定されている【HRPS0008】．

HRMP3カーネルでは，タスク優先度の最大値（TMAX_TPRI）は16に固定されている【HRMPS0010】．

SSP3カーネルでは，タスク優先度の最大値（TMAX_TPRI）は16に固定されている【SSPS0010】．

メールボックス機能を廃止したため，メッセージ優先度の最小値（TMIN_MPRI）と最大値（TMAX_MPRI）は廃止した．

マルチプロセッサ対応カーネルでは，プロセッサの数を知るためのマクロとして，次の構成マクロを用意している［NGKI0643］．

マルチプロセッサ対応カーネルでは，特殊な役割を持ったプロセッサを知るためのマクロとして，次の構成マクロを用意している【NGKI0526】．

ここでTOPPERS_TEPP_PRCは，タイムイベント処理プロセッサの集合をビットマップとして表す符号無し整数型の数値で，プロセッサIDがNのプロセッサがタイムイベント処理プロセッサである場合に下位からN番目のビットが1，そうでない場合には下位からN番目のビットが0となっている．

HRMP3カーネルでは，すべてのプロセッサがタイムイベント処理プロセッサであるため，TOPPERS_TEPP_PRCは用意していない【HRMPS0012】．

TOPPERS_SYSTIM_PRCID（システム時刻管理プロセッサのID番号），TOPPERS_SYSTIM_LOCAL（ローカルタイマ方式），TOPPERS_SYSTIM_GLOBAL（グローバルタイマ方式）を廃止した．TOPPERS_TEPP_PRCを追加した．

保護機能対応カーネルでは，自動メモリ配置と手動メモリ配置のどちらが使われているかを知るためのマクロとして，次の構成マクロを用意している【NGKI0607】．

カーネルのメーカコード（TKERNEL_MAKER）は，TOPPERSプロジェクトから配布するカーネルでは，TOPPERSプロジェクトを表す値（0x0118）に設定されている．

カーネルの識別番号（TKERNEL_PRID）は，TOPPERSカーネルの種類を表す．

カーネル仕様のバージョン番号（TKERNEL_SPVER）は，上位8ビット（0xf6）がTOPPERS第3世代カーネル（ITRON系）仕様であることを，中位4ビットがメジャーバージョン番号，下位4ビットがマイナーバージョン番号を表す．

カーネルのバージョン番号（TKERNEL_PRVER）は，上位4ビットがメジャーバージョン番号，中位8ビットがマイナーバージョン番号，下位4ビットがパッチレベルを表す．