技術展で見かけたスグレモノ「リアルタイムOS INtime」「動的テストツール DT10」
先日、組込みシステム開発技術展（Japan IT Week）を少しだけ覗いてきました。
時間が無かったのでほんの一部のブースしか見れなかったのですが、2つほど紹介します。
1台のPCをWindowsとリアルタイムOSに分割！「INtime」
リアルタイム性が求められる製品に、汎用的なWindowsなどのOSを搭載しようと考えるとき、多くの場合は、リアルタイムOS用のCPU（＋ボード）と汎用OS用のCPU（＋ボード）を別々に用意します。
それは、汎用OSでリアルタイム性を確保することが難しいためです。
パフォーマンスの向上したコンピュータは、リアルタイムに近い応答性を発揮するレベルになってきました。
しかし、真のリアルタイム性は、パフォーマンス向上だけでは得られません。
真のリアルタイム性とは、何も理想論や概念の話ではなく、実際に必要な、色々なシーンで求められる要件の事です。
リアルタイム性の一例を見てみましょう。
ある信号が別の機器から飛んできました。これを受け取って、即行動に移さなければならない、遅れは許されない、という要件があったとします。
この「即」とはどのくらいでしょうか？
理想論の話ではないので、0秒などとは言いません。
もちろん要件次第ですが、例えば、最大1 ms（1000分の1秒）という要求仕様だったとしましょう。
1 msという時間は、パフォーマンスの高い最近のコンピュータから見れば、容易い数字です。
信号を受け取ってからアクションを起こすまでに、多少複雑な処理を行ったとしても、1 us（1000000分の1秒）もあればできそうなものです。
しかし、汎用OSにおいて、1 msをわずかでも超えることは許されない、と言われたら、途端に難易度が上がります。
汎用OSでは、その他の様々な処理が常時行われているからです。
常時行われている処理を限界まで削ったとしても、突発的な操作や別のアクションが発生する可能性がある以上、どうしても、この要件を守り切ることができないのです。
あるいは、超ハイスペックなコンピュータに加え、OSやアプリケーションに様々な工夫を凝らせば、この要件を守れるかもしれません。
しかし、「保証」できるかとなると、また別次元の話となるのです。
リアルタイムOSは、汎用性には劣るものの、各処理やプログラムに優先順位を厳密に定められる、などの利点により、こういった要件に応えることが可能です。
「保証」できるレベルで、です。
なぜ リアルタイムOSならそれが可能か、という話は今回は置いておきましょう。
前置きが長くなりましたが、リアルタイム性が必要な案件では、リアルタイムOSが求められます。
装置にGUIやインターフェースを自由かつ迅速に設けたい、という場合、やはり汎用OSが便利です。
しかし、前述の様にリアルタイム用と汎用OS用の2つのボードを設けると大変です。
開発はもちろん、手配もメンテも。下手をすると、その手間が2倍にもなりかねません。
そんな悩みに「INtime」（＾＾）
そういえば、数年前にINtimeを見かけたのを思い出しました。
リアルタイム性が必要な製品にWEBサーバを加えたい、ということで色々調べていた時のことです。
その時は情報不足と予算や開発期間の都合でINtimeは土俵に乗りませんでしたが、その時もINtimeの特異性に驚いたものです。
INtimeは、リアルタイムOSの名前ですが、同時に、Windowsとの共存を可能とする技術パッケージの名前でもあります。
最近は当たり前になったマルチコアCPU。
1つのデバイスの中に、複数のCPUコアは入ったもののことです。
マルチコアCPUの一部のコアを汎用OSに使用し、
別のコアをリアルタイムOSに使用する、というのがINtimeです。
つまり、1台のPCの中で、WindowsとリアルタイムOSが、同時に動作するのです。
切り替え式ではありません。同時に走るのです。
マルチコアが当たり前になった今、その有用性が跳ね上がったのではないかと考えます。
WindowsとリアルタイムOS（以降RTOS）が同じボードで動作するため、互いのデータ交換も迅速に行われます。
メモリ上で受け渡すイメージですので、オーバーヘッドは、ほぼゼロですね。
PCは、特に成長とリリースサイクルの早い製品です。
そのハードウェアをRTOSで利用できるということは、パフォーマンス的にもかなり有利です。
PCの拡張ボードなど、豊富な資源が利用できることも大きなメリットです。
話を聞いた限りでは、リアルタイムOSからも多くの拡張ボードが利用できるということですので、あまり制約を感じませんでした。
是非、使ってみたいですね。
「Windowsで制御しているのだけど、時々発生する遅延で困ってる」という方、いませんか？
INtimeはTenAsys社の登録商法です。国内代理店はマイクロネット。
マイクロネットは日本語ドキュメントやトレーサブルコントローラなど、いろいろなINtime互換製品を展開しています。↓
動的テストツール DT10 … どんなものなの？ JTAGデバッガとは違うんだよね？
… 私の認識はこの程度でしたので、今まで動的テストツールというものに触れたことはありませんでした。
今回、ハートランド・データさんのデモを見て、そんな便利なものだったのか！と目からウロコだったので、ここで紹介します。
色々他にも種類はあると思うのですが、今回見せてもらったDT10を一言でいうなら「トレース ツール」でしょうか。
プログラムのソースにテストポイントと呼ばれる関数を埋め込んで、コンパイル。
実行すると、どこのテストポイントを通過したか、とかいつ通過したか、などの情報を得ることができます。
うん。トレース機能ですね。
でも、デバッガでもできるよね？
できないものもあるけど。だから自作して…あの時は大変だったなあ…
などと思いつつ通り過ぎようとしたのですが、ちょうどデモが始まったので、聞いてみることにしたのです。
（デモが終わったところで質問攻め。時間無いのにね。）
そして知ったスゴイところ。
- CPUやOSを選ばない。つまり、ほとんどの環境で使える。
- 速い。テストポイントを設置しても、パフォーマンスがあまり落ちない。
単にパフォーマンスがすごいとかではなく、明確な仕組み上の理由があります。
まず、なぜプラットフォームを選ばないか。
構成：
ターゲット（開発中の製品）→ ＜GPIO数本＞ → ツール本体 → PC
ポイントはGPIOで繋ぐ（他の方法もあるそうです）、ということ。
テストポイントにおける処理は、そのソースの場所を示す番号をGPIO経由で出力するだけなので。
そんな処理であれば、どんなCPUでもOSでもできますよね。
GPIOの本数は多ければ多いほど、速度的メリットがあるそうです。
次に、なぜ速いか。
その理由の1つはテストポイントにおける処理が簡単で極僅かだから、です。
もう一つの理由は、テストポイントから送られた情報を、ツール本体で受け取るから、です。
PCなどで受け取ろうとすると、PCのパフォーマンスに依存するので、取りこぼしかねない、という心配が出てきますが、ツール本体がそこを保証してくれるので（聞きそびれましたが、当然リアルタイムOSかハードウェア処理でしょう）、ツール本体のパフォーマンスが許す限り、早くできるのです。
受け取った情報はツール本体がバッファリングするので、PCに対してはハイパフォーマンスを求めないそうです。
つまり、遅いPCを使っても、取りこぼすことは無い。
そして、テストポイントを通過したタイミングを示すタイムスタンプは、ツール本体で生成するので、ターゲットボードに時間の概念も求めないですし、GPIOに通す情報量も最小限です。
そして、やはり気になるのは、これを仕込むことによって、どれだけ実行速度が落ちるか、ということ。
テストポイントは手動で好きなところにも設定可能ですが、自動で関数の出入り口と、分岐箇所、他にもタスクの切り替え点などに設置できます。
また、通常のテストポイントは、その場所を伝えるものですが、テストポイント通過時の任意の変数値を伝えることも可能。
バグをとらえるためであれば、全体。あるいは疑わしい範囲にテストポイントを設置すればよいですし、
処理時間を調べるためならば、任意の場所に設置すれば良いわけです。
関数における処理時間のバラツキもグラフ化でき、バラツキ確認や、異常動作を拾い集めるという使い方もできます。
テストポイントの設置をファイル別や関数別に自動で行うとか、チェックボックスで外すとか、アプリの機能も充実してました。
想定以上の人気があったらしく、3日目はカタログが切れていたとのことで…他にも役立ちそうな機能があったと思いましたが、「必要十分」を超える機能が備わっている、ということは良く分かりました。
ちなみに、両方とも百万円ちょっと。
「妥当な価格設定」と思うと同時に「（DT10は）1案件じゃ無理。設備投資レベルだな」「（INtimeは）数の出ない案件じゃ厳しい」とも思うのでした。
やはり案件次第ですね。