技術展で見かけたスグレモノ「リアルタイム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を一言でいうなら「トレース ツール」でしょうか。

プログラムのソースにテストポイントと呼ばれる関数を埋め込んで、コンパイル。
実行すると、どこのテストポイントを通過したか、とかいつ通過したか、などの情報を得ることができます。

うん。トレース機能ですね。

でも、デバッガでもできるよね?
できないものもあるけど。だから自作して…あの時は大変だったなあ…

などと思いつつ通り過ぎようとしたのですが、ちょうどデモが始まったので、聞いてみることにしたのです。
(デモが終わったところで質問攻め。時間無いのにね。)

そして知ったスゴイところ。

  1. CPUやOSを選ばない。つまり、ほとんどの環境で使える。
  2. 速い。テストポイントを設置しても、パフォーマンスがあまり落ちない。

単にパフォーマンスがすごいとかではなく、明確な仕組み上の理由があります。

 

まず、なぜプラットフォームを選ばないか。

構成:

ターゲット(開発中の製品)→ <GPIO数本> → ツール本体 → PC

ポイントはGPIOで繋ぐ(他の方法もあるそうです)、ということ。

テストポイントにおける処理は、そのソースの場所を示す番号をGPIO経由で出力するだけなので。
そんな処理であれば、どんなCPUでもOSでもできますよね。

GPIOの本数は多ければ多いほど、速度的メリットがあるそうです。

 

次に、なぜ速いか。

その理由の1つはテストポイントにおける処理が簡単で極僅かだから、です。

もう一つの理由は、テストポイントから送られた情報を、ツール本体で受け取るから、です。

PCなどで受け取ろうとすると、PCのパフォーマンスに依存するので、取りこぼしかねない、という心配が出てきますが、ツール本体がそこを保証してくれるので(聞きそびれましたが、当然リアルタイムOSかハードウェア処理でしょう)、ツール本体のパフォーマンスが許す限り、早くできるのです。

受け取った情報はツール本体がバッファリングするので、PCに対してはハイパフォーマンスを求めないそうです。
つまり、遅いPCを使っても、取りこぼすことは無い。

そして、テストポイントを通過したタイミングを示すタイムスタンプは、ツール本体で生成するので、ターゲットボードに時間の概念も求めないですし、GPIOに通す情報量も最小限です。

そして、やはり気になるのは、これを仕込むことによって、どれだけ実行速度が落ちるか、ということ。

テストポイントは手動で好きなところにも設定可能ですが、自動で関数の出入り口と、分岐箇所、他にもタスクの切り替え点などに設置できます。

また、通常のテストポイントは、その場所を伝えるものですが、テストポイント通過時の任意の変数値を伝えることも可能。

バグをとらえるためであれば、全体。あるいは疑わしい範囲にテストポイントを設置すればよいですし、
処理時間を調べるためならば、任意の場所に設置すれば良いわけです。

関数における処理時間のバラツキもグラフ化でき、バラツキ確認や、異常動作を拾い集めるという使い方もできます。

テストポイントの設置をファイル別や関数別に自動で行うとか、チェックボックスで外すとか、アプリの機能も充実してました。

想定以上の人気があったらしく、3日目はカタログが切れていたとのことで…他にも役立ちそうな機能があったと思いましたが、「必要十分」を超える機能が備わっている、ということは良く分かりました。

 


 

ちなみに、両方とも百万円ちょっと。
「妥当な価格設定」と思うと同時に「(DT10は)1案件じゃ無理。設備投資レベルだな」「(INtimeは)数の出ない案件じゃ厳しい」とも思うのでした。

やはり案件次第ですね。

コメントを残す

メールアドレスが公開されることはありません。 * が付いている欄は必須項目です