リアルタイムオペレーティングシステム

リアルタイムオペレーティングシステム（RTOS）は、厳密に定義された時間制約を持つデータとイベントを処理するリアルタイムコンピューティングアプリケーション用のオペレーティングシステム（OS）です。RTOSは、マルチタスクまたはマルチプログラミング環境でスケジューラ、データバッファ、または固定タスク優先順位付けを使用してシステムリソースの共有を管理するUnixなどのタイムシェアリングオペレーティングシステムとは異なります。すべての操作は、指定された時間とリソース制約内で検証可能に完了するか、そうでない場合はフェイルセーフである必要があります。リアルタイムオペレーティングシステムはイベント駆動型でプリエンプティブです。つまり、OSは競合タスクの関連する優先度を監視し、タスクの優先度を変更できます。イベント駆動型システムは優先度に基づいてタスクを切り替えますが、タイムシェアリングシステムはクロック割り込みに基づいてタスクを切り替えます。^[1]

RTOS の重要な特性は、アプリケーションのタスクを受け入れて完了するまでにかかる時間に関する一貫性のレベルです。この変動が「ジッター」です。^[2]「ハード」リアルタイム オペレーティング システム (ハード RTOS) は、「ソフト」リアルタイム オペレーティング システム (ソフト RTOS) よりもジッターが少なくなります。ハード RTOS では遅い応答は間違った応答ですが、ソフト RTOS では遅い応答は許容されます。主な設計目標は、高スループットではなく、ソフトまたはハードのパフォーマンス カテゴリを保証することです。通常または一般的に期限に間に合う RTOS はソフト リアルタイム OS ですが、期限を確定的に守れる場合はハード リアルタイム OS です。^[3]

RTOSには、スケジューリングのための高度なアルゴリズムがあります。スケジューラの柔軟性により、プロセスの優先順位をより広範囲にコンピュータ システムで調整できますが、リアルタイム OS は、多くの場合、限られたアプリケーションに特化しています。リアルタイム OS の重要な要素は、割り込み遅延とスレッド切り替え遅延を最小限に抑えることです。リアルタイム OS は、一定時間内に実行できる作業量よりも、応答速度や予測可能性によって評価されます。^[4]

RTOS は、入力刺激を処理するのにかかる時間が、同じタイプの次の入力刺激までの経過時間よりも短いオペレーティング システムです。

最も一般的なデザインは次のとおりです。

• イベント駆動型 -優先度の高いイベントの処理が必要な場合にのみタスクを切り替えます。プリエンプティブ優先度または優先度スケジューリングと呼ばれます。
• タイムシェアリング - 定期的なクロック割り込みとイベントでタスクを切り替えます。ラウンドロビンと呼ばれます。

タイムシェアリング設計では、厳密に必要な頻度よりも頻繁にタスクが切り替わりますが、よりスムーズなマルチタスク処理が可能になり、プロセスまたはユーザーがマシンを独占的に使用しているかのような錯覚が生じます。

初期のCPU 設計では、タスクを切り替えるために多くのサイクルが必要で、その間 CPU は他の有用な処理を実行できませんでした。切り替えに非常に長い時間がかかるため、初期の OS では、不要なタスク切り替えを回避することで CPU 時間の浪費を最小限に抑えようとしました。

一般的な設計では、タスクには次の 3 つの状態があります。

1. 実行中（CPU 上で実行中）
2. 準備完了（実行準備完了）
3. ブロックされています (イベント、I/O などを待機しています)。

一般的にCPU コアごとに一度に実行できるタスクは 1 つだけなので、ほとんどのタスクはほとんどの場合ブロックされているか、準備完了状態です。準備完了キュー内の項目数は、システムが実行する必要のあるタスクの数と、システムが使用するスケジューラの種類によって大きく異なります。より単純な非プリエンプティブでもマルチタスク システムでは、タスクは CPU の時間を他のタスクに譲らなければならないため、準備完了キューで実行準備完了状態のタスクの総数が多くなることがあります (リソース不足)。

通常、スケジューラ内の準備完了リストのデータ構造は、スケジューラのクリティカル セクションで費やされる最悪の時間の長さを最小限に抑えるように設計されています。この時間中はプリエンプションが禁止され、場合によってはすべての割り込みが無効になりますが、データ構造の選択は、準備完了リストに含めることができるタスクの最大数によっても異なります。

準備完了リストに数個以上のタスクがない場合は、準備完了タスクの二重リンク リストが最適であると考えられます。準備完了リストに通常は数個のタスクしか含まれず、ときどきそれ以上のタスクが含まれる場合は、リストを優先度順に並べ替えて、実行する最も優先度の高いタスクを見つけるのにリストを走査する必要がないようにする必要があります。代わりに、タスクを挿入するにはリストを走査する必要があります。

この検索中は、プリエンプションを抑制しないでください。長いクリティカル セクションは、小さな部分に分割する必要があります。低優先度タスクの挿入中に高優先度タスクを準備する割り込みが発生した場合、低優先度タスクが挿入される直前に、その高優先度タスクを挿入して実行できます。

クリティカル応答時間は、フライバック時間と呼ばれることもあり、新しい準備完了タスクをキューに入れて、最も優先度の高いタスクを実行状態に復元するのにかかる時間です。適切に設計された RTOS では、新しいタスクの準備完了には準備完了キュー エントリごとに 3 ～ 20 命令かかり、最も優先度の高い準備完了タスクの復元には 5 ～ 30 命令かかります。

高度なシステムでは、リアルタイム タスクが多くの非リアルタイム タスクとコンピューティング リソースを共有し、準備リストが任意の長さになることがあります。このようなシステムでは、リンク リストとして実装されたスケジューラの準備リストでは不十分です。

一般的に使用されるRTOSスケジューリングアルゴリズムには以下のものがある: ^[5]

• 協調的なスケジュール
• 先制的なスケジュール
  • レートモノトニックスケジューリング
  • ラウンドロビンスケジューリング
  • 固定優先度プリエンプティブスケジューリング、プリエンプティブタイムスライシングの実装
  • 固定優先度スケジューリングと遅延プリエンプション
  • 固定優先度非プリエンプティブスケジューリング
  • クリティカルセクションのプリエンプティブスケジューリング
  • 静的時間スケジューリング
• 最も早い締め切り優先アプローチ
• マルチスレッドグラフトラバーサルによる確率的有向グラフ

Unixのようなマルチタスク オペレーティング システムは、リアルタイム タスクには不向きです。スケジューラは、コンピュータへの要求が最も低いジョブに最高の優先順位を与えるため、時間的に重要なジョブが十分なリソースにアクセスできるようにする方法はありません。マルチタスク システムでは、複数のタスク間でデータとハードウェア リソースを共有する必要があります。通常、2 つのタスクが同じ特定のデータまたはハードウェア リソースに同時にアクセスするのは安全ではありません。^[6]この問題を解決する一般的な方法は 3 つあります。

汎用オペレーティング システムでは通常、ユーザー プログラムが割り込みをマスク (無効)することはできません。これは、ユーザー プログラムが CPU を制御できるためです。最近の CPU の中には、割り込み制御がオペレーティング システムの重要なリソースと見なされているため、ユーザー モードコードで割り込みを無効にすることを許可しないものもあります。ただし、多くの組み込みシステムや RTOS では、システム コールの効率を高めるためにアプリケーション自体をカーネル モードで実行できるほか、OS の介入を必要とせずにアプリケーションがオペレーティング環境をより細かく制御できるようにしています。

シングルプロセッサ システムでは、カーネル モードで実行されているアプリケーションで割り込みをマスクする方法が、共有リソースへの同時アクセスを防ぐ最もオーバーヘッドの低い方法です。割り込みがマスクされ、現在のタスクがブロッキング OS 呼び出しを行わない場合、他のタスクや割り込みが制御を引き継ぐことができないため、現在のタスクが CPU を排他的に使用し、クリティカルセクションが保護されます。タスクがクリティカル セクションを終了するときは、割り込みのマスクを解除する必要があります。保留中の割り込みがあれば、それが実行されます。一時的な割り込みのマスクは、クリティカル セクションを通る最長パスが、必要な最大割り込み待ち時間よりも短い場合にのみ行う必要があります。通常、この保護方法は、クリティカル セクションが数個の命令で構成され、ループが含まれていない場合にのみ使用されます。この方法は、ビットが異なるタスクによって制御される場合に、ハードウェア ビットマップ レジスタを保護するのに最適です。

他のすべてのタスクをブロックせずに共有リソースを予約する必要がある場合 (フラッシュ メモリへの書き込みを待機するなど)、ミューテックスや OS 監視のプロセス間メッセージングなど、汎用オペレーティング システムでも利用可能なメカニズムを使用することをお勧めします。このようなメカニズムにはシステム コールが含まれ、通常は終了時に OS のディスパッチャ コードが呼び出されるため、実行には通常数百の CPU 命令が必要ですが、一部のプロセッサでは割り込みのマスクに 1 つの命令しかかからない場合があります。

(非再帰的な) ミューテックスは、ロックされているか、ロック解除されているかのいずれかです。タスクがミューテックスをロックすると、他のすべてのタスクは、ミューテックスがその所有者(元のスレッド) によってロック解除されるまで待機する必要があります。タスクは、ミューテックスの待機にタイムアウトを設定できます。ミューテックス ベースの設計には、優先度の逆転やデッドロックなど、よく知られている問題がいくつかあります。

優先度の逆転では、優先度の低いタスクにミューテックスがあるために優先度の高いタスクが待機しますが、優先度の低いタスクには作業を完了するための CPU 時間が割り当てられません。一般的な解決策は、ミューテックスを所有するタスクに、最も高い待機タスクの優先度を「継承」させることです。ただし、この単純なアプローチは、複数のレベルの待機がある場合には複雑になります。タスクA はタスクBによってロックされたミューテックスを待機し、タスク B はタスクCによってロックされたミューテックスを待機します。複数のレベルの継承を処理すると、他のコードが優先度の高いコンテキストで実行されるため、優先度が中程度のスレッドが不足する可能性があります。

デッドロックでは、2 つ以上のタスクがタイムアウトなしでミューテックスをロックし、他のタスクのミューテックスを永久に待機することで、循環的な依存関係が作成されます。最も単純なデッドロックのシナリオは、2 つのタスクが交互に 2 つのミューテックスをロックするときに発生しますが、順序は逆です。デッドロックは、慎重な設計によって防止できます。

リソース共有のもう 1 つのアプローチは、タスクが組織化されたメッセージ パッシングスキームでメッセージを送信することです。このパラダイムでは、リソースは 1 つのタスクによってのみ直接管理されます。別のタスクがリソースを照会または操作する必要がある場合、そのタスクは管理タスクにメッセージを送信します。リアルタイム動作はセマフォシステムほど鮮明ではありませんが、単純なメッセージ ベースのシステムは、プロトコル デッドロックの危険をほとんど回避し、一般にセマフォ システムよりも動作が優れています。ただし、セマフォのような問題が発生する可能性があります。タスクが低優先度のメッセージを処理しているときに、受信メッセージ キュー内の高優先度のメッセージ (または高優先度のタスクから間接的に発信されたメッセージ) を無視すると、優先度の逆転が発生する可能性があります。プロトコル デッドロックは、2 つ以上のタスクが互いに応答メッセージを送信するのを待機しているときに発生する可能性があります。

割り込みハンドラは、最も優先度の高いタスクの実行をブロックし、リアルタイム オペレーティング システムはスレッドのレイテンシを最小限に抑えるように設計されているため、割り込みハンドラは通常、可能な限り短く保たれます。割り込みハンドラは、可能であればハードウェアとのすべてのやり取りを延期します。通常、必要なのは、割り込みを承認または無効にすること (割り込みハンドラが戻ったときに再び発生しないようにするため) と、作業を行う必要があることをタスクに通知することだけです。これは、セマフォを解放するか、フラグを設定するか、メッセージを送信することによって、ドライバー タスクのブロックを解除することで実行できます。スケジューラは、多くの場合、割り込みハンドラ コンテキストからタスクのブロックを解除する機能を提供します。

OS は、スレッド、ミューテックス、メモリなど、管理するオブジェクトのカタログを維持します。このカタログの更新は厳密に制御する必要があります。このため、アプリケーションが OS 関数を実行しているときに、割り込みハンドラが OS 関数を呼び出すと問題が発生する可能性があります。割り込みハンドラから呼び出された OS 関数は、アプリケーションの更新が原因でオブジェクト データベースが不整合な状態になっていることに気付く可能性があります。この問題に対処するには、統合アーキテクチャとセグメント化アーキテクチャという 2 つの主要なアプローチがあります。統合アーキテクチャを実装する RTOS は、内部カタログの更新中に割り込みを無効にするだけで問題を解決します。この欠点は、割り込みレイテンシが増加し、割り込みが失われる可能性があることです。セグメント化アーキテクチャは直接 OS 呼び出しを行わず、OS 関連の作業を別のハンドラに委任します。このハンドラは、どのスレッドよりも高い優先度で実行されますが、割り込みハンドラよりも低い優先度で実行されます。このアーキテクチャの利点は、割り込みレイテンシにほとんどサイクルが追加されないことです。その結果、セグメント化されたアーキテクチャを実装する OS は、統合アーキテクチャと比較して予測可能性が高く、より高い割り込みレートを処理できるようになります。^{[引用が必要]}

同様に、 x86 互換ハードウェアのシステム管理モードでは、オペレーティング システムに制御が返されるまでに長い時間がかかることがあります。

リアルタイム オペレーティング システムでは、他のオペレーティング システムよりも メモリの割り当てが重要です。

まず、安定性のために、メモリ リーク(割り当てられたが使用後に解放されないメモリ) があってはなりません。デバイスは、再起動を必要とせずに無期限に動作する必要があります。^{[引用が必要]}このため、動的なメモリ割り当ては好ましくありません。^{[引用が必要]}可能な限り、必要なメモリ割り当てはすべてコンパイル時に静的に指定されます。

動的メモリ割り当てを避けるべきもう 1 つの理由は、メモリの断片化です。メモリの小さなチャンクの割り当てと解放が頻繁に行われると、使用可能なメモリが複数のセクションに分割され、空きメモリが十分にあるにもかかわらず、RTOS が十分に大きな連続したメモリ ブロックを割り当てることができない状況が発生する可能性があります。次に、割り当ての速度が重要です。標準的なメモリ割り当て方式では、長さが不確定なリンク リストをスキャンして適切な空きメモリ ブロックを見つけますが、^[7] RTOS ではメモリ割り当てが一定時間内に実行されなければならないため、これは受け入れられません。

機械式ディスクの応答時間ははるかに長く、予測不可能であるため、上で説明した RAM 割り当てと同じ理由で、ディスク ファイルへのスワップは使用されません。

シンプルな固定サイズ ブロック アルゴリズムは、オーバーヘッドが低いため、 シンプルな組み込みシステムに最適です。

Wikibook Embedded Systemsには、リアルタイムオペレーティングシステムに関するページがあります。