応答時間や遅延時間に不確実性や非再現性がなく、deterministicであり、特にその最悪値が予測可能であるシステム、ないしは予測しやすいような内部構成になっているシステムをリアルタイムシステムと呼ぶ。

μT-Kernelは、上記のような特性を持ったリアルタイムシステムを構築するためのリアルタイムOSである。

プログラムの並行実行の単位を「タスク」と呼ぶ。すなわち、一つのタスク中のプログラムは逐次的に実行されるのに対して、異なるタスクのプログラムは並行して実行が行われる。ただし、並行して実行が行われるというのは、アプリケーションから見た概念的な動作であり、実装上はカーネルの制御のもとで、それぞれのタスクが時分割で実行される。

また、システムコールを呼び出したタスクを「自タスク」と呼ぶ。

プロセッサが実行するタスクを切り替えることを「ディスパッチ」(または「タスクディスパッチ」)と呼ぶ。また、ディスパッチを実現するカーネル内の機構を「ディスパッチャ」(または「タスクディスパッチャ」)と呼ぶ。

次に実行すべきタスクを決定する処理を「スケジューリング」(または「タスクスケジューリング」)と呼ぶ。また、スケジューリングを実現するカーネル内の機構を「スケジューラ」(または「タスクスケジューラ」)と呼ぶ。スケジューラは、一般的な実装では、システムコール処理の中やディスパッチャの中で実現される。

一般に、プログラムの実行される環境を「コンテキスト」と呼ぶ。コンテキストが同じというためには、少なくとも、プロセッサの動作モードが同一で、用いているスタック空間が同一(スタック領域が一連)でなければならない。ただし、コンテキストはアプリケーションから見た概念であり、独立したコンテキストで実行すべき処理であっても、実装上は同一のプロセッサ動作モードで同一のスタック空間で実行されることもある。

タスクの実行順序、すなわち実行可能状態のタスクに実行権を与えて実行状態とする際の順序関係を「優先順位 Precedence」と呼ぶ。タスクXよりもタスクYの優先順位が高い場合、タスクYが先に実行される。また、あるタスクXを実行中に、タスクXよりも優先順位の高いタスクYが実行できる状態になった場合、タスクYに実行権が移ってタスクYが実行状態となるとともに、タスクXは実行状態から実行可能状態となる。

	補足事項
	「優先順位(Precedence)」に似た意味を持つ用語として「優先度(priority)」があり、タスクの実行順序に影響を与える点はいずれも同じである。しかし、「優先度」がAPIのパラメータ等によってアプリケーションから明示的に指定されるタスクの属性であるのに対して、「優先順位」は複数のタスク間でその実行順序を示すために用いる概念である。タスク間の優先順位はタスクの優先度に基づいて定められ、優先度の高いタスクは優先順位も高い。一方、優先度の同じタスク同士であっても、両者の優先順位は同じではない。同じ優先度を持つタスク間では、先に実行できる状態(実行状態または実行可能状態)になったタスクの方が高い優先順位を持つ。ただし、tk_rot_rdq などのAPIの実行により、同じ優先度を持つタスク間の優先順位が変更される場合がある。

アプリケーションやミドルウェアからμT-Kernelの提供する機能を呼び出すための標準インタフェースを総称して、API(Application Programming Interface)と呼ぶ。APIは、カーネルの機能を直接的に呼び出すシステムコールのほか、拡張SVCやマクロ、ライブラリ関数として実現されるものも含まれる。

OSの起動時あるいは起動後に動的に追加されたシステムコールを「拡張SVC」と呼ぶ。μT-Kernel 3.0の仕様では、サブシステム管理機能 を使って拡張SVCを定義する。また、μT-Kernel/SMのAPIを実装するために、拡張SVCを利用することができる。

拡張SVCの処理を実行するプログラムを「拡張SVCハンドラ」と呼ぶ。

μT-Kernel 3.0のうち、拡張SVC、マクロ、ライブラリ関数として実装される部分を除いた部分を「カーネル」と呼ぶ。μT-Kernel/SMのAPIは拡張SVC、マクロ、ライブラリ関数として実装することが可能であり、そのような方法で実装された部分は、μT-Kernel 3.0のOS仕様には含まれるが「カーネル」には含まれない。一方、μT-Kernel/OSとμT-Kernel/DSの全ての機能は「カーネル」に含まれる。

非タスク部実行中のシステム状態を考える場合には、「カーネル」に含まれる機能か否かを意識する必要がある。

仕様として標準化していない事項である。実装ごとに仕様を規定しなければならない。実装仕様書に具体的な実装内容について明記しなければならない。アプリケーションプログラムにおいて、実装定義の事項に依存している部分は移植性が確保されない。

仕様において、ターゲットシステム、または、システムの動作条件によって振舞いが変わる事項であることを示す。実装ごとに振舞いを規定しなければならない。実装仕様書に具体的な実装内容について明記しなければならない。アプリケーションプログラムにおいて、実装依存の事項に依存している部分は基本的に移植する際に変更が必要となる。