家電製品から社会インフラ向けの機器まで、産業領域においてLinuxを適用する範囲は急速に広がりました。ただその道のりは、決して平坦なものではありませんでした。東芝では長年にわたり、省電力や起動時間の短縮、リアルタイム制御などのさまざまな難題に対峙し、それらを克服しながら新しい価値を創出することで Linuxの進化に貢献してきました。現在では、長期保守や高信頼性、さらにはサイバーレジリエンス対応といった新たな課題も浮上し、技術者たちは日々革新を追求しています。この連載では、東芝が直面した数々の困難と、それを乗り越えるための取り組みを4回にわたってひも解いていきます。
第1回では、さまざまな機器への適用におけるLinuxの課題と、それに東芝がどのように対応してきたのかを説明しました。第2回では、産業用システムで重要となる要件の一つ、「リアルタイム制御」について解説します。

ある処理を決められた時間内に完了することを保証する制御処理を「リアルタイム制御」、そのための性能を「リアルタイム性能」といいます。自動車のエアバッグの例で見てみましょう。図1に、「衝突」というイベントが発生してから、「エアバッグを開く」という処理が完了するまでの一連の流れを示しました。一般に、エアバッグは、自動車が衝突してから約0.03秒^※後には膨らみ切り、乗員を受け止めるといわれています。

※参考：
https://www.nissan.co.jp/COMPASS/ISF/3rd/PAPER/
https://global.honda/jp/safetyinfo/think_safety/vol16/airbag/

図１の左の例では、イベントの発生から処理を開始するまでの時間（レイテンシー）が小さく、決められた時間（デッドライン：0.03秒）までに処理を完了しています。一方、図１の右の例では、レイテンシーが大きすぎたことに起因して、デッドラインを守れていません。この場合、エアバッグが膨らみ切れずに乗員が大けがをする可能性が高くなります。このような現象を起こさないために、産業用機器のリアルタイム制御においては、デッドラインが重要です。これを守れなければ、例えば、利用者がスムーズに通過できない駅の自動改札機や頻繁に停電する発電所などが現れ、社会に大きな影響を及ぼす可能性があります。

リアルタイム制御は、「ハードリアルタイム」と「ソフトリアルタイム」の２つに分類されます。ハードリアルタイムとは、自動車のエアバッグのように、デッドラインまでに処理を完了しなければ重大な影響がでるものです。またソフトリアルタイムとは、デッドラインの多少の超過は許容されるものをいいます。

こうしたリアルタイム制御を行うために、従来は専用のリアルタイムOS（RTOS）が用いられてきました。しかし、近年のハードウェアの高性能化や多機能化に伴い、リアルタイム制御が求められる機器も多様化し、柔軟性が高く、さまざまな用途に適応できるOSの必要性が高まりました。このような背景の中で、オープンソースソフトウェア（OSS）として公開されているLinuxは、対応ハードウェアが豊富で、開発環境が充実しているため、システムの生産性を飛躍的に向上させる可能性を秘めています。また、世界中の多くの開発者が継続的に改良を加えているため、長期的なサポートや最新技術の導入も期待できます。これらの利点から、リアルタイム制御を実現するためにLinuxを採用する動きが広がってきました。 

標準的なLinuxは、もともとハードリアルタイムを実現するOSではありません。そのため、リアルタイムシステムに用いる際には機能を拡張する必要がありました。拡張する方法はいくつか存在し、その中で、Linuxのリアルタイム性能を向上させる機能として20年間にわたり開発が続けられてきたのが、「PREEMPT_RTパッチ」と呼ばれる拡張機能です。長い年月をかけて進化してきたPREEMPT_RTは、2024年11月、ついに標準機能としてLinux 6.12に取り込まれました。

PREEMPT_RTの機能は、Linuxのリアルタイム性能を高めるものです。しかし、それを用いるだけでは、求めるリアルタイム制御が確実に実現できるわけではありません。確実にリアルタイム制御を行うには、デッドラインを超えないように処理の特性や限界を見極めて、システムを適切に設計する必要があるからです。ここからは、Linuxでリアルタイム制御を行うときの課題と、その克服に向けた東芝の取り組みを紹介していきます。

Linuxは、さまざまなユースケースに合うように汎用的に作られたOSです。そのためさまざまな分野や用途での利用が可能です。しかしこれを、組込みLinuxとして利用してリアルタイム制御を行う場合には、この汎用性が短所となることがあります。例えば、サーバーやパソコンで利用されるLinuxでは、「プログラムの実行にメモリが必要になったら割り当てる」「複数のプログラムを切り替えながら、あたかも同時に動いているかのように実行する」「マルチコアCPUのコア間で負荷分散する」といったことが「程よく」行われています。

では、リアルタイム制御において、この「程よく」の動作がどのような影響を与えるのかを、先ほどのエアバッグの例で考えてみましょう。ここでは実施する処理を単純化し、（1）事故が起きた衝撃を受け取る、（2）エアバッグを膨らませるという2つの手順とします。例えば（1）の処理で、「衝撃を受け取るためにプログラムを動かそうとしたら、ほかのプログラムの実行完了を0.01秒待たないといけなかった」、さらには「いざ実行を始めたところ、受け取った衝撃の信号を格納する場所がなく、メモリを割り当てるための調整に0.05秒かかった」ということが起こったら……。これでは、0.03秒といわれているエアバッグが膨らみ切るまでの時間（デッドライン）を、（2）にたどり着く前に超えてしまいます。こうならないように、リアルタイム制御を行う際には、Linuxの機能を使って次のような対処が必要です。

• 緊急性の高いプログラムほど、優先的に動作できるようにする
• 使うメモリは事前に割り当てておく

これらに対応した上で、さらに必要となる見極めがあります。それは、Linuxで実現可能なレイテンシーの度合い、そして処理にかかる時間とCPUに割り当て可能な時間です。

■ Linuxのレイテンシーを見極める

前述したように、あるイベントが発生してから処理を開始するまでの時間をレイテンシー（遅延時間）と呼びます。リアルタイム制御では、レイテンシーが短ければ短いほど良いというわけではなく、一定の範囲に収まることが重要です。定期的にイベントが発生する周期処理の場合、各イベントの発生からそれぞれ処理を完了するまでの時間がデッドラインに収まっていればよく、その範囲内であれば、レイテンシーの長さが変化することは問題ありません（図2）。

周期処理について、私たちはさまざまな評価を行っています。まず行ったのは、CPU負荷状況下でのレイテンシー評価です（図3）。オリジナルのLinuxでは、周期が500マイクロ秒と300マイクロ秒のどちらのときも、平均値は3マイクロ秒程度でしたが、デッドライン（周期）を100回以上超過し、その中の最悪値（レイテンシーの最大値）は28ミリ秒を超えました。これは、多くの場合は性能がよいが、実際にはレイテンシーの幅が非常に大きく、実用するにあたっては問題となることを示しています。

一方のPREEMPT_RTを用いた場合について説明します。500マイクロ秒周期の処理では、平均値は12マイクロ秒程度とオリジナルに比べて大きくなっていますが、デッドラインの超過を起こさず、最悪値は200マイクロ秒程度に収まっていることがわかります。これは、リアルタイム制御の処理にかかる時間が300マイクロ秒以内であれば、計算上は500マイクロ秒の応答性能を常に実現できるということです。この「常に実現できる」ことが、リアルタイム制御において重要なところです。

それではPREEMPT_RTでの300マイクロ秒周期の評価はどうだったのか。こちらは、平均値は11マイクロ秒程度でしたが、デッドラインを93回超過し、その中の最悪値は約27ミリ秒と、とても大きな値でした。ただし今回の評価は、CPUの負荷をあえて高めて優先度の高い処理が確実に実行されるかどうかを確認したもののため、この評価結果だけで300マイクロ秒周期を達成できない理由にはなりません。しかし、短い周期で安定した動作を達成しようとすればするほど、処理量（処理にかけられる時間）の制約が大きくなっていくことは明白です。システム設計にも、より厳密さが求められていくことがわかる結果となりました。

■CPUに割り当て可能な時間を見極める

あるプログラムを実行する際に、CPUが占有される時間のことを「CPU時間」といいます。私たちは、レイテンシーの見極めに加えて、リアルタイム処理に割り当て可能なCPU時間の評価と改善も行いました。評価を開始した当時、標準のPREEMPT_RTを用いたLinuxにおいて、2ミリ秒の処理に対して1ミリ秒のCPU時間を割り当てたときは、正常に動作しました。しかし、CPU時間を1ミリ秒未満の粒度で設定すると、CPU時間を正しく割り当てることができませんでした（図4－改善前）。

調査の結果、Linuxでは1ミリ秒未満の時間の割り当てがそもそも考慮されていなかったことを突き止めました。そこで、高精度なタイマーを用いて改良を施し、1ミリ秒未満の粒度でも正確にCPU時間を割り当てられるようにしました。改善後は、1ミリ秒周期の処理に対して、0.5ミリ秒ずつCPU時間を割り当てることができています（図4－改善後）。

この改良をコミュニティーのイベントで提案したとき、ちょうどその場にいたこの機能の作成者に「え？ 1ミリ秒未満の粒度なんて、ほとんど必要ないよね」と言われたことをよく覚えています。ただ、世の中には同じ悩みを抱えている人がいるものです。実際その後に別の人からも同様の提案がなされ、いまでは選択可能な手段の一つとなっています。私たちの提案とは異なる実装方法となりましたが、オープンな場で問題提起をして議論が深まり、良い方向に向かった一例です。

現在はCPUのマルチコア化が進み、複数の処理を同時に実行することが可能となりました。CPUの性能向上に伴い、並行して処理できる量が増えると、一つのコンピューターに複数の機能を集約することが現実的になります。例えば、リアルタイム制御処理と汎用処理の共存です。周期的に機器の制御を行いながら、その結果を集約してグラフィカルに表示する。機器の制御は確実に定期実行する必要がありますが、集約した情報は見たいときに見られれば問題ありません。

ただし、このようなリアルタイム処理と非リアルタイム処理を混在させてCPUを共有した場合、非リアルタイム処理がいつどのタイミングで実行されるかわからず、リアルタイム処理に予測不可能な影響がでてしまうことがあります。これを避けるために、リアルタイム処理にはCPUコアを占有させて隔離し、非リアルタイム処理の影響が起きない構成にします（図5）。

この構成で実際に試したところ、多数の周期処理がありCPUの負荷が高いときに、まれに大きな遅延が起こることが判明しました（図6－改善前）。その原因を細かく見ていくと、リアルタイム処理と非リアルタイム処理の両方で共有される「Linuxの内部処理」による影響が見えてきました。周期的な処理がいくつも動いていると、ときおりプログラムを起動するタイミングを制御するためのタイマーの整理が必要になります。この処理が隔離しきれない実装になっていたことが原因だと突き止め、対策したことで、リアルタイム制御処理を切り離すことに成功しました（図6－改善後）。

このように、東芝ではLinuxをリアルタイム制御に用いるために、さまざまな評価と改良を繰り返し、産業機器への適用を実現してきました。

ここまでは、Linuxを用いてリアルタイム制御を行う上での課題と、その克服に向けた東芝の取り組みを紹介してきました。長年にわたり取り組んできた成果は、東芝のさまざまな製品で、それぞれの特性に応じて取捨選択され、用いられています。

例えば、「TOSMAP-DS/LX」という、発電を制御するためのコントローラーです。ここでは、Linuxの最適化により、発電の制御に必要なリアルタイム性能を実現しました。^※1 また、0.5ミリ秒（エアバックが膨らむまでの時間の6分の1の時間）という高速な定周期処理を実現している、ユニファイドコントローラ「VmシリーズtypeS」もあります。このtypeSは、IoTに対応したコントローラーで、リアルタイム制御が求められるコントローラーとしての機能と、汎用的な処理を行うコンピューターとしての機能を、それぞれ独立したCPUコアに割り当て、同時に実行することを可能としています。^※2

※1：参考文献 東芝レビュー「運用性と環境の改善を実現する次世代コントローラTOSMAP-DS/LX」（https://www.global.toshiba/content/dam/toshiba/migration/corp/techReviewAssets/tech/review/2013/11/68_11pdf/a08.pdf (PDF形式)(312KB)）
※2：参考文献 東芝レビュー「エッジリッチなCPSを実現する制御システム向けIoT対応コントローラー」（https://www.global.toshiba/content/dam/toshiba/jp/technology/corporate/review/2021/01/f04.pdf (PDF形式)(606KB)）

今回は、組込みLinuxの重要な要素の一つである、リアルタイム制御に関する東芝の取り組みを紹介しました。私たちは、汎用的に作られているLinuxをリアルタイム制御に用いるために、さまざまな技術開発と評価を繰り返し、さらにコミュニティーとも連携しながら産業用途に求められる品質と性能を達成してきました。

次回は「コミュニティー」に焦点を当て、産業分野における共通課題の解決に向けたOSSコミュニティーの立ち上げと、そこで行われている技術開発について掘り下げます。ぜひご期待ください。