Windowsのリアルタイム拡張「RTX」と組み込み機器への応用：汎用OSにリアルタイム性を付加するアプローチ（1/3 ページ）

Windows OSにリアルタイム機能を付与する「RTX（Real Time Extension）」をご存じだろうか。本特集では、Windowsをリアルタイムシステム化するアプローチの1つとしてRTXを紹介する。

[石黒一敏（東京エレクトロンデバイスエンベデッド・ソリューション部），＠IT MONOist] PC用表示関連情報

LINE

Hatena

1．はじめに

　ご存じの通り、マシン制御を伴うような組み込みシステムでは“リアルタイム性”が求められます。一般的に、こうしたシステムはRTOS（Real Time OS）が用いられますが、その一方で、汎用OSにリアルタイム性を付加するアプローチも存在します。

　今回の特集では、IntervalZero社が開発した“Windowsにリアルタイム機能を付与する”製品「RTX（Real Time Extension）」にフォーカスし、汎用OSにリアルタイム性を付加するアプローチとRTXの特徴について紹介します。

　RTXの最新バージョンである「RTX 2011」は、マイクロソフトの組み込みOS「Windows Embedded Standard 7 SP1」に対応し、最大32CPUまでのマルチコア対応が可能となっています。ちなみに、開発元のIntervalZero社は、今から30年以上前の1980年、米国ボストンに設立されたWindows関連テクノロージーを得意とするベンダーで、設立当初のVenturCom、その後のArdenceを経て、現在の社名IntervalZeroとなっています。


	関連記事：
⇒	「INtime」によるリアルタイム性能の確保


	関連リンク：
⇒	RTX（Real Time Extension）
⇒	IntervalZero

2．Windowsをリアルタイムシステム化するアプローチ

　“Windowsがリアルタイム性を保障できないこと”はマイクロソフト自身も認めるところです。Windows環境でリアルタイム性を必要とする場合は、他のRTOSとの併用、あるいはWindowsにリアルタイム機能を付加する製品を使用しなければなりません。

　さて、ここであらためて“リアルタイムシステム”について考えてみましょう。

　リアルタイムシステムとは、別の言い方をすると「応答時間が保障されたシステム」といえます。ある限られた時間内に必ず処理を実行できることがリアルタイムシステムの要件です。もちろん、Windows自身もそれなりに高速ですが、どんなに高性能なCPUを使っても最大で数十ミリセカンドの遅延（レイテンシ）が発生します。相手が人間であればこの値は十分短いため、“Windowsはソフトリアルタイム性についての機能を満たしている”と考えてもよいでしょう。

　ただし、マシン制御のように1000分の1秒、つまり1ミリセカンド以内に処理を行わなければならないような“ハードリアルタイム処理”を行うには、次のようなアプローチを取る必要があります。

（1）RTOSシステムとの併用

　専用RTOSとして設計された「VxWorks」や「QNX」のようなOSを別途用意してリアルタイム処理部分を担当させる方法があります。そして、Windowsの得意とするGUIと組み合わせてシステムを構築します。当然、WindowsとRTOS用に別々のハードウェアが必要となり、また2つのOS間の通信制御も必要となります。システム間をシリアルポート、TCP/IP経由で通信するような構成もありますし、RTOS側をPCIのオプションボードとして構成し、PCの拡張スロットに接続してデュアルポートRAMによる高速の共有メモリでの通信を行う構成もあります。

（2）ハイパーバイザー方式

　最近のCPUが持つ仮想化支援機能（IntelはIntel VT、AMDではAMD-V）を使って、異なる複数のシステムを1つのハードウェアに実装してしまう方法です。ハイパーバイザーは起動時にCPUの各コア、メモリなどのハードウェアリソースを分割し、分割された環境が相互に影響を与えないように初期化します。そして、一方の環境ではWindows、別の環境ではRTOSをそれぞれ起動して走らせることができます。従って、ソフト的な構成はRTOSとの併用と同じです。RTOSがx86アーキテクチャで動作していたのであれば、ほぼそのままの形で2つのシステムを1つのハードウェアに統合できます。そして、1つのハードウェアでありながら、例えばRTOS側はそのまま動作させつつ、Windows側だけをリセットして再起動させるといったことが可能です。難点としては、WindowsとRTOSに加えてハイパーバイザーのライセンス費用が掛かること、また開発環境も従来通りWindowsとRTOSを複数管理する必要があることです。

（3）Windowsリアルタイム拡張

　そして、Windows自身にリアルタイム機能を付与する“Windowsのリアルタイム拡張”です。こちらは、Windowsに何らかの手を加えてリアルタイム機能を追加する方法です。例えば、リアルタイムOSであるWindows CEを利用し、Windowsへ専用スケジューラを導入してWindowsとともに動作させます。Windows CE側に高いプライオリティを持たせることでリアルタイム性を確保し、リアルタイム処理のすき間を縫ってWindowsを動作させます。Windows CEのタスクの1つとして通常のWindowsが動作しているようなイメージです。この構成の場合、CPUコアが1つであるとリアルタイム側の負荷にWindowsが大きく影響を受けてしまいますが、最近のマルチコアCPUであれば、それぞれの処理を各CPUコアに分散させることで、効率の良い処理を行わせることができます。なお、本稿で紹介するRTXもこのようにWindowsをリアルタイム拡張しますが、RTXの場合は「HAL（Hardware Abstraction Layer）」上にRTXサブシステムを導入するというアプローチを取っています。

　ここでは3つのアプローチについて紹介しましたが、注意しておきたいのは、いずれの方法を用いても“従来のWindowsアプリケーションがリアルタイム動作するようになるわけではない”ということです。リアルタイム機能は、追加されたリアルタイム側のプログラムによって実現されるものです。Windowsシステムを使用するのは、WindowsのGUIによる操作性、開発の容易性を活用するのが目的です。

　最近では、制御機器であってもマルチタッチ機能を活用した“スマートフォン・ライク”な操作パネルがトレンドになりつつあります。これらを考えると、操作部にWindowsを使っていくのは正しい流れといえるでしょう。

図1　Windowsのリアルタイム拡張で、よりシンプルなシステムへ

　さらに、もしWindowsベースのPCだけでリアルタイム制御が可能であればコストダウンなど多くのメリットが享受できます。図1のように複数必要であったハードウェア／ソフトウェアのシステムは、よりシンプルなシステムへと簡略化されます。長期間生産される組み込み機器においては専用部品をできるだけ使わないことがBOM（部材）コストを抑えるポイントです。

3．RTXのアーキテクチャ

　RTXは、HAL上にRTXサブシステムを導入する手法を用いています。HALの拡張I/Fを使ってRTXサブシステムがWindowsへ入り込むような形態となっており、RTXはWindowsシステムの内部に導入されていることになります。

図2　RTXのアーキテクチャ

　ここで考慮すべきは、Windowsのメモリ管理です。Windowsは仮想メモリで動作しており、物理メモリが足りなくなるとそのページをHDDへスワップアウトさせることによって、物理メモリよりも大きな仮想メモリ空間を提供します。当然、動作すべきプログラムがメモリ上に存在しなければ、HDDからのスワップインが発生します。これには相応の時間がかかり、Windowsがリアルタイム性を保障できない要因の1つとなっています（ちなみに、Windows CEはリアルタイムOSですが、こちらもデマンドページング：“必要になるまでそのコードを読み出さない”を無効にしておかなければリアルタイム性は発揮できません）。

　すなわち、リアルタイム処理にかかわるプログラムは、物理メモリ上に必ず実体が存在する必要があります。この問題に対してRTXは、Windowsの「非ページメモリ」を利用することで対応しています。非ページメモリとは、Windowsが管理するスワップアウトされない、つまりプログラムが物理メモリ上に存在していることが保障されているメモリ領域です。Windowsシステムにおいても即時に応答しなければならない割り込みハンドラ、カーネルなどはここに配置されています。

　RTXサブシステムは、ドライバとしてこの非ページ領域にロードされ、またRTXのアプリケーションも同領域にロードされて動作します。この部分はOSのカーネルレイヤーであり、x86アーキテクチャでいう「Ring0」となります（図2の中央赤色の部分）。

　RTXサブシステムは、約0.5Mバイトとコンパクトに作られており、実質的にシステム全体を管理するスケジューラとなります。基本的にRTXアプリケーションをリアルタイム動作させ、RTXのアプリケーションがアイドル状態になったときだけ、Windows側を動作させるように機能します。

　ちなみに、非ページメモリには上限があり、Windows OSの種別、搭載メモリによって上限は変化します。例えば、Windows XPの場合は256Mバイトが上限です。RTXアプリとWindowsアプリは共有メモリによってプロセス間通信とデータの受け渡しを行うことができますが、これらのバッファも非ページメモリ上に確保されるため、大量のデータを扱う場合、非ページメモリが不足するという問題が発生します。このようなケースにおいて、IntevalZero社から1つのアイデアが提供されています。それは、Windowsが使用するメモリを制限することで、“Windowsが使用していないメモリを巨大な共有メモリとして活用してしまおう”というものです。Windows XPにおいてはBoot.ini、Windows Vista／Windows 7においてはBCDストアのオプションで、Windowsが使用するメモリを制限できます。例えば、1.5Gバイトのメモリが搭載されたシステムにおいて、Windows側が1.0Gバイトしか使用しないように指定すれば、残りの512MバイトをWindows管理外の単なるメモリとして自由に使うことができます。