「INtime」によるリアルタイム性能の確保
〜Windows Embedded StandardとINtimeで作るリアルタイム制御システム〜

使い慣れた開発ツールが使える

　リアルタイムOSと聞くと、“開発環境やデバッグ環境が独特・特殊である”という印象を持たれるかと思います。やはり、新しい開発ツール、デバッグツールにはどうしても慣れが必要なので、導入初期に要する負担が気になるところです。

　ここでは、INtimeリアルタイムアプリケーションの開発について説明します。

　INtimeリアルタイムアプリケーションの開発にはC／C++言語を用います。実は、Visual StudioがINtimeをサポートしているので、Windowsアプリケーションの開発とまったく同一の環境でINtimeリアルタイムアプリケーションのビルドが可能になっています。導入初期の負担を軽減するうえでは、とても重要なポイントだと思います。

　Windowsアプリケーションは「Windowsシステムコール」を使用しますが、INtimeリアルタイムアプリケーションは「INtimeシステムコール」を使用します。INtimeシステムコールは、Windowsシステムコールに似せて準備されているので、追加されたシステムコールを少し覚える感覚で、制御アプリケーションの作り込みが可能になります。

　このようにして、Visual Studioで開発されたINtimeリアルタイムアプリケーションは、実行用のターゲットPCに複製する必要もなく、そのまま開発PC上で実行できます。つまり、完成したRTAファイルはEXEファイルと同じようにダブルクリックで起動できますし、PCの起動に合わせて自動的にスタートさせることもできます。

画面1　VisualStudioのウィザード画面。 INtimeアプリケーションの開発はここからはじまる

ハードウェアI/O、ハードウェア割り込み処理の実現

　Windowsアプリケーションでは、直接的なハードウェアアクセスが禁止されています。これは、システム全体のトラブルが生じないように保護されているためです。

　この保護は、インテルアーキテクチャCPUの持つ「保護レイヤ機能」によって実現されています。OSカーネルやデバイスドライバは、すべてのメモリ空間やすべてのハードウェアにアクセスするために「カーネルモード（リング0）」プログラムとして動作しますが、アプリケーションはアクセスの限定された「ユーザーモード（リング3）」プログラムとして動作するのです。

　INtimeリアルタイムアプリケーションの場合もWindowsアプリケーションと同じく、ユーザーモードに位置付けられていて、ほかのプロセスを誤って損傷することがないよう保護されています。しかし、制御のために多用することとなるハードウェアI/O処理とハードウェア割り込み処理は、アプリケーションコード内で処理することが許可されています。つまり、デバイスドライバ制作の必要性を排除して開発効率を向上させながらも、システム全体を破損することがない保護されたプログラムとして位置付けられています。

図5　INtimeの仕組み

デバッグはどのようになるのか？

　INtimeリアルタイムアプリケーションは、Visual Studio上でそのままデバッグ・実行ができます。ハードウェアI/Oから、割り込み処理に至るまで、すべてのデバッグがセルフ環境で行えるわけです。シングルステップ実行、ブレイクポイント、CPUレジスタ、メモリダンプ、実行中プロセスへのアタッチ、リモートデバッグなど、通常のWindowsアプリケーション開発工程と何ら変わるところがありません。

画面2　Visual StudioによるINtimeアプリケーションのデバッグ実行 ※画像をクリックすると拡大表示します

　完成されたリアルタイムアプリケーションは、INtimeに付属する「INscope」ツールによって、スレッドの動作順序、処理時間を確認できます。INscopeツールは開発の最終段階で制御処理のパフォーマンスを最適化するうえでも役立ちます。

画面3　INscopeによるスレッド実行のトレース ※画像をクリックすると拡大表示します

Windows Embedded StandardとINtimeによる組み込みシステムの事例

　最後に、Windows Embedded StandardとINtimeで作られた、組み込みシステムの事例を紹介します。

　硬貨・紙幣を投入して利用券を購入する、いわゆる「自動発券機」の事例です。この装置のコンセプトは、「製品コストの削減」「タッチパネルオペレーション」「音声案内」「ネットワーク対応」です。

　従来、このようなシステムはマイクロコンピュータで開発していましたが、いまではユーザーニーズも多様化し、非接触型電子マネーへの対応や、ネットワーク対応、データベース連携、タッチパネル画面の自由なカスタマイズ、券面のデザイン、動画による案内などの付加機能・付加価値を考えると、マイクロコンピュータでは追従が難しくなっています。そこで、PCアーキテクチャを採用することになったのです。

　タッチパネル画面や、音声案内、発券プリンタ、データベースアクセスはWindows Embedded Standardアプリケーションが標準機能の範囲で処理可能です。一方、信頼性とリアルタイム性が求められる硬貨・紙幣の取り扱い、人感センサ、警報機能などの機構部はINtimeリアルタイムアプリケーションが処理します。

　開発の初期段階では、汎用のデスクトップPCや、ノートPCでコーディングとデバッグが行えます。ターゲットマシンの調達を待たずに、すぐに開発に取り掛かることが可能です。また、発券プリンタなどを開発環境PCに接続すれば、機能単位のデバッグも効率的に進めることができます。

図6　自動券売機事例における機能分担

　複数のマイクロコンピュータで構成されていた装置が、1つのPCアーキテクチャ互換ボードコンピュータに置き換わったことによって、今回のケースの場合、約40％のコスト削減と約30％の筐体サイズ縮小化を達成できました。抑えられたコスト分は、より高い付加価値を持つソフトウェアの開発に充填（じゅうてん）できます。

　ほかにも、マイクロコンピュータの数百倍の性能を持つPCアーキテクチャに代替したことが、装置全体の性能を向上させています。マイクロコンピュータ同士で行われていた物理的な通信が、ソフトウェアタスク間の通信に変わったことで、ボトルネックが排除されたことも大きく貢献しています。

　また、ハードウェア点数の削減により、信頼性・保守性の向上にもつながりました。このシステムではストレージにCF（Compact Flash）を採用していますが、Windows Embedded Standardの効果が十分に発揮されています。Windowsでありながらコンパクトなフットプリントを実現できたこと。特に、EWFはWindows Embedded Standardの優良機能の1つであり、不慮のシステムファイル破損を完全に抑えたROM化を構成できています。実際にEWF機能のおかげで、PCプラットフォームのウイークポイントであったストレージのトラブルは一切生じなくなりました。

画面4　自動券売機システムのタッチパネル画面。 ボタン配置やデザインはカスタマイズが可能

◇

　以上のように、Windows Embedded StandardとINtimeの組み合わせによって、その可能性は大きく広がります。Windows Embedded StandardとINtimeで構成された制御システムの採用は、アジア圏だけでもこれまでに250社以上に及びます。

　あなたの制御システムにWindows Embedded Standardを採用すると、どのような付加価値が生まれるかをぜひ想像してみてください。

＞＞「Windows Embedded」コーナーはこちら