3.　リアルタイム性

　産業用OSに求められる機能が多様化していることを述べたが，基本的には組み込みシステム用のOSである以上，リアルタイム性が重要になる．また，使いこなすことが難しいといわれる最大の原因もリアルタイム性の扱いにある．

　リアルタイム性というと，応答速度が速いことと誤解される場合が多いが，厳密にはシステムに課せられる時間的制約を満足できること，あるいは一歩譲って，時間的制約が守れない場合があるとしてもシステムの時間的挙動が予測可能ということである．

　たとえば，平均的に見れば応答速度は十分に速いが，ときどき極端に遅くなることがある場合には，最大実行時間を予測できないという意味でリアルタイム性はない．

　また，周期的に起動するべきタスクの起動時刻のばらつきが大きいとか，一度起動が遅れるとその遅れがシステム全体に伝播したり，累積してどんどん遅れてしまう場合もリアルタイム性がないといえる．

　Javaのリアルタイム性が話題になることが多いが，Javaで問題になるのはガーベジコレクションによって，Java全体が止まってしまう時間をどのように制御するかということである．

　いつ，どれくらいの期間停止するかの予測ができなければ，GUIには使えても組み込み用途には使えないのである．また，UNIXのようなタイムシェアリングシステムで使われるラウンドロビンスケジューリングでは，周期的なタスクの制御ができないし，一時的なオーバロード状態のときに，どのタスクがデッドラインをオーバするかロシアンルーレット状態になってしまい，まったく予測できないことも問題となる．

　衛星放送などで，別々の回線から送られてくる画像と音声を合成する場合，リップシンクさせる機構がないと，唇の動きと聞こえてくる声が微妙にずれる高度な腹話術状態になってしまう．実時間制約が，単に高速応答性だけでない例である．

　リアルタイム性のないOSを使ってマルチメディアサーバを構築すると，このような実時間制約をもった多重処理はほとんど不可能である．ただし，リアルタイム性のあるOSを使うことだけで実現できるわけではなく，システム全体のリアルタイム性を得るためには，ハードの設定やタスク分割法も含めたノウハウの蓄積が必要である．

　一般的に要求される応答時間の目安としては，GUIなどのマン-マシン系で人間相手の場合は秒のオーダ，モータとかスイッチなどの機器を扱う場合にはmsのオーダ，内部デバイスなどの制御の場合はμsのオーダが必要になる（表2）．

　どのオーダまで保証できるかで，そのOSが何に使えるかが決まることになる．現実問題として，μsオーダのリアルタイム性要求は現状の技術ではかなり厳しい要求であり，ITRONのようなRTOSを使ってもかなり難しい領域である．

　たとえば，平均応答時間を高速化するだけなら，キャッシュを使用することが有効である．しかし，キャッシュを使用すると動作が確率的になるので，リアルタイム性の面では好ましくない．μsオーダのリアルタイム性が必要な場合，キャッシュを使用せずに高速内部RAMとして使ったほうがよい場合がある．

　このようにすることで確率的挙動がなくなり，決定論的な動作が可能になるのでリアルタイム性が期待できるようになる．組み込み用途では，割り込み応答時間が重要なパラメータである．割り込みが発生してから割り込みハンドラにコントロールが移るまでの時間を指すのが一般的である（図11）．

〔図11〕割り込み応答時間と遅延時間

　この割り込み応答時間は，たとえばSH-2であれば割り込みベクタテーブルをもっており，ハードウェアによって割り込み要因ごとに振り分けられるので，数十から数百nsオーダの高速応答が可能である．しかし，SH-3では割り込み要因に対応する割り込みハンドラの呼び出しや割り込みレベルの設定をソフトウェアで行わなければならず，へたをするとμsオーダの時間がかかってしまう場合もある．

　割り込みハンドラを呼び出すのに，RTOS内での処理が必要な場合にはさらに遅くなる．したがって，最新のRISCマシンが必ずしも高速であるとは限らないので注意が必要である．μsオーダの高速応答性を求めるのであれば，プログラムをすべて高速なRAMにロードしてから実行するなどのハード的な工夫が必要である．

　しかし，それでも平均的な高速応答性が改善されるだけであり，リアルタイム性が保証されるわけではない．つまり，リアルタイム性を保証するためには最悪実行時間を把握しなければならないが，前述のキャッシュの問題や分岐時の投機的実行などの確率的要素がある最新のRISCマシンではnsオーダで最悪実行時間を把握することは不可能である．

　そして，ちりも積もれば山となるように，OSを使用した場合，μsオーダで把握することも困難である．このように，OS以前の問題としてリアルタイム性を阻害する要因があるため，この時間領域を問題にするのであれば，OSを使用しないことを選択するべきである．

　OSを使用した場合に扱える時間領域を見積もるときに考慮すべきことは，割り込みマスク時間である．ディスパッチ処理中など，カーネルは内部データの一貫性を保つために割り込み禁止状態にする．割り込み禁止中は，割り込み要求があっても割り込みは保留されて，実際に割り込みがかかるのは割り込み解除後になる．したがって，トータルの割り込み応答時間は，前述の割り込み応答時間に，この割り込みマスク時間^注6を加える必要がある．

　割り込みマスク時間の目安は安全側を取って，もっとも時間のかかるシステムコールの処理時間と思えばよい．具体的にどの程度かというと，SH-3（7709）でスレッド型のRTOSの場合，数μsから十数μs，プロセス型のRTOSの場合，数十μsから数msである．

　Windows CEやLinuxなどの場合は，割り込みマスク時間以前に割り込み応答時間自身が，数msから数十msのオーダである^注7．具体的な数字は，メモリのウェイトをいくつ入れるかでかなり変わってくるため，それぞれのハードウェアで実測するしかない．アプリケーションがほぼ完成した状態で割り込み応答時間を実測すると，図12のようになるのが一般的である．最近は少なくなったが，カタログスペックに記載されるチャンピオンデータにはほとんど意味がない．

〔図12〕割り込み応答時間の変動

　どのようにリアルタイム性を作り込んでいくのかについては，制御用に使う以上，時間制約を守ることが必須である．使用するアプリケーションが，どの時間領域のリアルタイム性を要求するのかに応じたOS選びが重要である．

　機器の複合機能化が最近の傾向だが，情報系の機能の場合には，リアルタイム性を必要としないものもある．たとえば，インターネットに接続できる電子レンジなど，加熱時間や重量計測などの制御部分以外の情報系機能は，基本的にPCと同じである．

　今のところ，｢お料理情報ボックス｣という専用のハードウェアを利用して情報をダウンロードするらしいが，一つの機器内に制御系と情報系を実装する場合には，ダウンロード中に調理すると過熱しすぎるなどということを避けるため，相互に干渉しないような設計が必要となる．

　たとえば，リアルタイム系のタスクのリソース獲得と非リアルタイム系のタスクのリソース獲得が競合した場合，FIFOによる待ちのみをサポートしているOSでは対応できない．優先度順の待ち，さらには優先度の高いタスクが奪い取るような機構が必要である．

　ただし，優先度待ちや強制キャンセルなどの機構はOS内部を複雑にして割り込みマスク時間が長くなるなど，高速応答性にとってはマイナスである．どのシステムコールをどのように使うか，そのときタスクスイッチが発生するかなどに注意してアプリケーションを設計していく必要がある．

10月号特集トップページへ戻る

Copyright 2000 藤倉　俊幸