インテルを源流に持つRTOS「INtime」はWindowsとの共存で強みを発揮する：リアルタイムOS列伝（56）（2/3 ページ）

IoT（モノのインターネット）市場が拡大する中で、エッジ側の機器制御で重要な役割を果たすことが期待されているリアルタイムOS（RTOS）について解説する本連載。第56回は、Windows環境と共存するRTOSという形で提供されている「INtime」を紹介する。

[大原雄介，MONOist]

同一プロセッサの複数コアにノードを割り当てた分散処理が可能

　2000年にtenAsysはRadiSysからスピンオフし、以後はiRMXのサポートとINtimeを中心とする製品の開発と提供、サポートを行っていく。他にも、IntelのVT（Virtualization Technology）を利用してWindowsと並列動作する形で組み込み環境を提供するeVM仮想化プラットフォームなどもラインアップに加えていたが、どうもこれは最終的にINtimeに吸収される形で提供されるようになったもようだ。というのは、最新のINtimeの特徴として、ハイパーバイザベースでの動作が可能という項目が挙げられており、先程ちょっと説明した「Linuxなどの他のOSをゲストOSとしてINtime上で稼働可能」もこのハイパーバイザーを利用してのものとなっている。

　さてそのINtime。基本的にはクローズドソースの製品であって、コード類は一切公開されていない。それどころか評価版も「入手したければ連絡しろ」方式なので、ちょっと初めての開発者にはハードルが高い。ただし、もともとがiRMXの上位製品的な扱いで開発され始めたこともあり、iRMXと似た雰囲気はある（のだが、iRMXそのものがもう廃れているので、あまり参考にならないかもしれない）。

　OSの構造としては“Deterministic、Event-Driven Processing”とされており、ターゲットはWindowsなどとの共存を前提としていることからx86ベースのプラットフォームであり、C++ 2020に準拠したプログラミング環境（とライブラリ9）が提供されるとしている。面白いのが動作環境で、例えば4コアのプロセッサのうち2コアをINtime、残りをWindowsに割り当てた上で、それぞれのOS間をVirtual Network Switchでつなぐ（しかもTSN（Time-Sensitive Networking）サポート付き）といった使い方（図2）が可能としている。

図2　ちなみにINtime自身はSMPに非対応であり、そもそもSMPに対応するつもりがないと明言している。Deterministicに割り込み処理などを行おうとすると、SMPはむしろ妨げになるという発想である［クリックで拡大］ 出所：tenAsys

　処理量が足りなければ、複数コアにINtimeのノードを割り当て、お互いに通信しながら処理を分散するという仕組みで、プログラミング的には別ノードとなるが、実態は同一のプロセッサ内のL3キャッシュなどを経由して相互に通信を行っているので、言うほどオーバーヘッドは大きくない。強いて言えば、複数のINtimeノードが存在する関係で、専有するメモリのオーバーヘッドは無視できないとは思うが、KB〜MBオーダーのSRAM／フラッシュしか使えないMCUはともかく、GBオーダーのメモリが使えるx86プラットフォームでこれは問題にならないだろう。ちなみにtenAsysのブローシャによれば、最小構成で必要となるメモリ量はINtime 7.0で32MB、INtime 7.1で64MBとなっており、L3に全部収まるほどの小ささではない（1ノードだけならギリギリというあたりで、2ノード以上だとあふれる）が、最小でも4GBや8GBが当たり前の昨今では問題になるようなサイズではないだろう。

　ちなみに図2は同一ノード内の複数コアに処理を分散するという話であるが、異なるノードで分散的に処理を行うINtime Distributed RTOS（図3）というものもある。こちらはGOBS（Global Objects）を利用してそれぞれのカーネルの間の通信や同期を行っており、このGOBSをGOBSnet経由で複数ノードにまたがる形で1つのシステムを構築できる、というシステムも提供している。このあたりの柔軟性の高さがINtimeの一つの売りとなっている。

図3　GOBSnetはいわば論理的なネットワークであって、物理的にはイーサネット、PCI（PCI／PCIeベースの共有メモリのことだろうか？）、RS-232Cなどがサポートされるとしている［クリックで拡大］