リアルタイムLinuxとPREEMPT_RTの適用判断
産業機器では、AI推論や画像処理などの高度な機能と、一定周期で動作する制御処理を同じ基盤へ統合するケースが増えています。そこで注目されているのが、Linuxのスケジューリング遅延を抑えるPREEMPT_RTです。
この記事では、PREEMPT_RTの仕組みやエッジAIとの共存設計、FA（ファクトリーオートメーション）・制御用途に適用する際の評価・選定方法を解説します。
- リアルタイムLinuxとPREEMPT_RTの位置づけ
- PREEMPT_RTによるスケジューリング遅延の抑制メカニズム
- エッジAI・DL処理とリアルタイム制御の共存設計
- FA・制御用途でのPREEMPT_RTの評価と適用判断
リアルタイムLinuxとPREEMPT_RTの位置づけ
リアルタイムLinuxとは、PREEMPT_RTなどにより、処理の応答時間や完了時刻の予測可能性を高めたLinuxの総称です。リアルタイム性の確保では、平均的な処理速度だけでなく、負荷がかかった場合でも処理の開始・完了の時刻を予測できることが重要です。
本記事では、イベントの発生から対象となる処理の開始までにかかる時間を「遅延（レイテンシ）」、周期や遅延のばらつきを「ジッタ」、所定の評価条件で観測された遅延の最悪値を「最大遅延」と表記します。なお、この遅延は主にスケジューリング遅延や起床遅延の観点から扱います。最大遅延を示す場合は、負荷や測定時間などの評価条件も併記します。
標準Linuxは、システム全体の処理効率や公平性を重視して設計されています。そのため、負荷状況や割り込み処理の影響で、スケジューリング遅延やジッタが増大することがあります。PREEMPT_RTは、カーネル内で高優先度タスクを実行しやすくし、スケジューリング遅延やその最大値を抑える仕組みです。Linux 6.12からは、PREEMPT_RT（CONFIG_PREEMPT_RT）によるフルプリエンプト型リアルタイム構成がメインラインで有効化できるようになりました。なお、用途によっては従来どおり-rt系の追加パッチやディストリビューション提供のRTカーネルを用いる場合もあります。
ただし、厳密な期限や安全性が求められる場合は、RTOS（リアルタイムOS）も選択肢となります。リアルタイムLinuxは、Linuxの豊富な機能を活用しながら、一定周期の制御処理で遅延やジッタを抑えたい用途に適しています。
なお、PREEMPT_RTは遅延やジッタを抑えるための仕組みですが、期限内の処理完了を保証するものではありません。RTOSを用いる場合も同様に、タスクや優先度の設計、最悪実行時間の見積もり、ハードウェアを含むシステム全体の検証が必要です。安全・保護機能など期限逸脱が許容できない処理については、要求するリアルタイム性に応じて、RTOSやマイコン、FPGAなどへの分離も検討します。
PREEMPT_RTによるスケジューリング遅延の抑制メカニズム
PREEMPT_RTは、高優先度タスクが待たされる要因を減らし、スケジューリング遅延を抑えます。主な仕組みは、プリエンプション範囲の拡大、割り込み処理のスレッド化、ロック待ちの抑制です。
カーネル内プリエンプション範囲の拡大
プリエンプションとは、実行中の処理を中断し、優先度の高い処理へCPUを割り当てる仕組みです。標準Linuxでは、カーネル内部に処理を中断できない区間があり、優先度の高いタスクが起動してもすぐに実行できないことがあります。
PREEMPT_RTは、カーネル内で処理を中断できる範囲を広げ、優先度の高いタスクへ速やかにCPUを切り換えます。長時間待たされる要因を減らすことでスケジューリング遅延やジッタを抑え、処理開始時刻を予測しやすくします。
割り込み処理のスレッド化と優先度制御
割り込み処理は、デバイスからの通知やソフトウェアによる処理要求を契機に実行されます。標準Linuxでは、ハードIRQコンテキストで実行される一次処理はスケジューラの管理外で動作します。この処理が長引くと、重要な制御タスクの実行を妨げるおそれがあります。
そこでPREEMPT_RTでは、多くの割り込みハンドラをスレッド化し、優先度を設定できるようにします（ただし一部の割り込みは例外としてスレッド化されません）。また、遅延処理であるIRQ_WORKもスレッド化の対象です。割り込みスレッドと制御タスクに優先度を設定すれば、重要度に応じた実行順序を制御できるようになります。
スリーピングロックと優先度継承による待ち時間の抑制
低優先度タスクがロックを保持し、高優先度タスクが待たされる状態を「優先度逆転」と呼びます。
PREEMPT_RTでは、spinlock_tをrt_mutexに基づくスリーピングロックとして扱います。PREEMPT_RTのrt_mutexは、高優先度タスクがロック待ちになった場合、ロックを保持する低優先度タスクの優先度を自動的に引き上げ（優先度継承）、処理とロックの速やかな解放を促します。一方、raw_spinlock_tはPREEMPT_RTでもスピニングロックとして扱われ、低レベルの割り込み処理などで用いられるものです。
エッジAI・DL処理とリアルタイム制御の共存設計
LinuxはAI開発環境や周辺機器のサポートが充実しており、AI推論（ディープラーニングによる画像認識・異常検知処理を含む）とリアルタイム制御を1つの機器へ統合しやすいOSです。ただし、処理同士の干渉を抑える設計が欠かせません。
Linux向けDLフレームワークとアクセラレータの活用
Linuxでは、GPUを利用したディープラーニング（DL）処理向けのSDKやライブラリ、実行環境が整っています。これらを活用すれば、画像認識や異常検知などのAI推論をGPUで高速化できます。
センサ入力や装置制御とAI推論を同じLinux環境へ統合することで、検出結果を制御へ反映するシステムも構築しやすくなります。ただし、推論処理によるCPUやメモリへの負荷がかかっても、制御処理が許容遅延やデッドラインの要件を満たせるように設計することが重要です。
CPUコアの用途別分離とアフィニティ設定による干渉の抑制
マルチコアCPUでは、リアルタイム制御、AI推論、OSの管理処理などに使用するCPUコアを用途別に分け、CPU時間の競合を抑えます。cpusetやisolcpusなどで制御タスク用のCPUコアを分け、nohz_fullやrcu_nocbsなどを必要に応じて組み合わせることで、条件が満たされる場合にはスケジューリングクロックのtickやRCUコールバックによる干渉を低減できます。ただし、割り込み、カーネル処理、共有資源へのアクセスなどによる影響を完全に排除できるわけではないため、実機での評価が必要です。
さらに、CPUアフィニティでは制御タスクを実行するCPUコアを指定し、IRQアフィニティではデバイス割り込みを処理するCPUコアを指定します。ただし、メモリ帯域やキャッシュなどの共有資源による干渉は残るため、高負荷時の遅延がどの程度になるか、実機で確認することが必要です。
通信・画像処理・ログ収集を含む上位機能の統合
Linuxのパッケージやドライバを活用すれば、産業用ネットワーク、画像処理、ログ保存、遠隔監視、クラウド連携なども同一基盤へ統合できます。ハードウェアやOSを集約することで、構成の簡素化や開発・保守の効率化につながる点がメリットです。
一方、AI推論やドライバ処理の干渉が大きく、許容遅延やデッドラインの要件を満たせないこともあります。その場合は、制御をRTOSで、上位機能をLinuxで動かす構成や、制御処理を別のプロセッサへ分離する構成も検討対象となります。
FA・制御用途でのPREEMPT_RTの評価と適用判断
PREEMPT_RTをFA機器や制御システムへ適用する際は、必要なリアルタイム要件を明確にし、実機で評価した上で採用を判断します。PREEMPT_RTだけで要件を満たせない場合は、RTOSや専用ハードウェアへの分離も検討が必要です。
制御周期・デッドライン・許容遅延の明確化
最初に、対象となる制御処理の時間要件を数値化します。確認する項目は、処理を繰り返す制御周期、イベント発生～処理開始までの許容遅延、処理の完了期限であるデッドライン、周期や遅延のばらつきを示すジッタなどです。
時間の長さだけでなく、期限を超えた場合の影響も整理します。同じ1ミリ秒の遅延でも、画面表示の更新であれば許容できる一方、モータ制御や安全装置では、装置の故障や品質の低下につながる可能性があります。安全性や品質への影響を含めて要件を決めることが重要です。
cyclictestと高負荷試験による最大起床遅延・ジッタの評価
PREEMPT_RTの性能評価には、Linuxのリアルタイム性を測定するcyclictestが使われます。一定周期でスレッドを起床させ、予定していた起床時刻と実際の起床時刻の差を計測することで、スケジューリング遅延を確認するツールです。
評価では平均値だけでなく、最大起床遅延やジッタ、長時間稼働時に発生する外れ値を確認します。CPUやメモリ、ストレージ、ネットワークへ負荷をかけ、AI推論や通信、ログ保存などが同時に動作する実運用に近い条件で検証します。ただし、cyclictestで測定できるのは主にスレッドの起床遅延です。制御処理全体の完了時間やイベント入力から出力確定までにかかる時間については、実際のアプリケーションやハードウェアを含めて評価する必要があります。
リアルタイムLinux・RTOS・専用ハードウェアの選定
OSやハードウェアは、リアルタイム性だけでなく、AI開発環境、必要なリソース、機能安全への対応、開発・保守コストを含めて選定します。厳密な時間要件がなければ標準Linux、AI推論や通信と時間制約のある一定周期の制御を統合する場合はリアルタイムLinuxが候補となります。
一方、厳密な期限管理や高い信頼性が求められる処理では、RTOSやマイコンなどへの分離を検討します。さらに、センサ入力から出力の確定までに（システム構成により異なりますが）サブマイクロ秒～数十マイクロ秒級の確定応答が求められ、OS上のソフトウェア処理では時間要件を満たせない場合は、FPGAなどの専用ハードウェアも選択肢です。1つの方式に集約せず、処理ごとの要件に応じて組み合わせることが重要です。
