（タッチモニター関連コラム）リアルタイムOSでのタッチ入力処理：応答速度と安定性の確保

RTOS（リアルタイムOS）でのタッチ入力処理は、一般的な汎用OSのタッチ入力処理とは異なる挙動をします。
それは単にOSの違いというだけではなく、RTOSと汎用OSの使用目的の違い、重視するポイントの違いに理由があります。
この記事では、RTOSのタッチ入力処理の概要と、なぜそのような処理をするかの理由について解説します。

なぜ産業機器ではRTOSがタッチUIに選ばれるのか

RTOS（リアルタイムOS）とは、厳格な優先順位に基づいて限られたリソースを管理し、高いリアルタイム性を発揮するよう設計されたOSのことです。

具体的には、ウインドリバーの「VxWORKS」や、ルネサスの「AUTOSAR OS」などが挙げられるでしょう。コンシューマ向け機器では汎用OSが採用されますが、産業機器ではこのようなRTOSが採用されます。

その理由は、RTOSが活用される現場にあります。産業用ロボットや医療機器、自動車、航空宇宙システムといった、RTOSが採用される場面を見れば、汎用OSよりも「操作遅延が許されない」環境であることは想像しやすいでしょう。

産業機械において、タッチUIなどからの入力に対してミリ秒・マイクロ秒レベルで即時に応答する「決定性（Determinism）」は、欠かせない品質要件です。つまり、入力に対する確実な即時応答が重視されるからこそ、RTOSが選ばれるのです。

また、RTOS自体が長期稼働を前提としたOS設計であり、何年にもわたって運用される産業機械の稼働期間と相性が良いという点も、選定理由のひとつです。

RTOSにおけるタッチ入力処理の基本構造

RTOSにおけるタッチ入力はどのような仕組みで駆動しているのでしょうか。ここでは、以下の2点を中心に見ていきます。

• 多くのRTOSは“割り込み駆動”を採用
• ISRからUIタスクまでのイベントフロー

多くのRTOSは“割り込み駆動”を採用

RTOS環境においては、タッチパネルからの入力検知は「ポーリング方式」ではなく「割り込み（インターラプト）駆動方式」が一般的に採用されます。これは、それぞれの方式が持つ特性によるものです。

ポーリング方式は、システムが定期的にタッチの有無を確認しに行く仕組みです。確認間隔を短くすればラグを減らすことができますが、その分CPUリソースを常に消費し続ける点は悩ましいポイントです。一方で、リソースを節約するため確認間隔を広くした場合は、確認タイミングと入力タイミングにズレが発生し、応答遅延が起こり得ます。

このような特徴から、ポーリング方式では産業機器に要求されるレベルの即時応答を実現するには課題が多くあります。

一方、割り込み駆動方式では、ユーザーが画面に触れた瞬間に、タッチコントローラーからCPUへハードウェア割り込み信号が直接送られます。この割り込み信号により、CPUは直前まで別の処理を行っていても入力の検知を優先処理できます。

システムのリソース消費を最小限に抑えつつ、産業機器に不可欠な即時応答を実現するためには、この割り込み駆動によるアプローチがポーリング方式よりも適していることがわかります。

ISRからUIタスクまでのイベントフロー

タッチ入力が割り込みとして検知されてから、実際の画面操作として反映されるまでには、システムを止めないための厳密なイベントフローが存在します。

ここで重要になるRTOS特有の規則が、「割り込みサービスルーチン（ISR）の処理時間を極力短くする」ことです。ハードウェア割り込みが発生するとISRが実行され、タッチ座標や操作状態（押下・解放など）といった最小限のデータだけを読み取ります。

次に、読み取ったデータをRTOSの「UIタスク」へ送信し、ISR自体の処理を素早く終了させます。UIタスクが起動するのはその後です。

このように、UIタスクという重い処理をISRから切り離してタスク側で実行（遅延処理）することで、リアルタイム処理を遅延させることなく、システム全体の安定性と迅速な操作性が実現できます。

低レイテンシーを実現するための優先度設計

産業機器・RTOS環境ではレイテンシー（遅延）の最小化が重要となりますが、低レイテンシーを実現するには、いくつかの方法が組み合わさっています。

• Priority DesignはUIの応答性とシステム信頼性に影響する
• 「速く見えるUI」と「安全なUI」は違う
• タッチ処理をリアルタイム制御として扱う

Priority DesignがUI品質を決める

RTOSにおけるPriority Design（優先度設計）は、UIの操作感や滑らかさだけではなく、産業機器としての信頼性を決定づける要素のひとつです。なぜなら優先度の設定により、システムに負荷がかかった際の応答性が大きく変わるため、低レイテンシーを実現するためには慎重な優先度設計が欠かせないからです。

ただし、優先度設計は単純な「AよりB」というものではなく、実機で処理を行わせてみて初めて明らかになる調整の必要性が浮上してくる場合もあります。そのため、優先度設計は極めて重要であり、かつ難しい設計ポイントのひとつであるといえます。

「速く見えるUI」と「安全なUI」は違う

UIは人間であるユーザーが見るものです。一般的なユーザーが使うことの多い汎用OSでは、滑らかなアニメーションを用いた「速く見えるUI」が重視されがちです。

一方、産業現場で求められるのは、いかなる状況でも確実に入力を受け付ける「安全なUI」です。つまり、汎用OSと産業現場では、ユーザーが期待するものが根本的に異なります。

具体的には、「ユーザーの目から見て速く見えるかどうか」よりも、「産業現場において確実に動作する安全性・信頼性」が重視されるべきでしょう。

タッチ処理をリアルタイム制御として扱う

産業現場で使用されるRTOSでは、タッチ入力処理は単なるUI操作ではなく、他タスクとの優先度関係の中でリアルタイム制御タスクとして扱われることが多いとされています。

実際の優先度設定は機器の要求仕様に依存しますが、重要操作（非常停止・パラメータ変更など）を確実に処理するため、描画タスクより高優先度に配置される設計が採られます。

産業現場では、画面の描画更新タスクよりも、非常停止や数値（パラメータ）変更などの「タッチ検知によって起こるタスク」の優先度を高く設定する必要があります。システムに負荷がかかった状態でも、仮に表示遅延を起こしてでも操作遅延を防ぎ、安全性を担保することが必要です。

RTOS特有のメモリ制約がタッチUI設計に与える影響

タッチUIの設計で汎用OSよりもRTOSが採用される理由のひとつが、「動的メモリ割当（malloc/freeなど）」による処理時間のばらつきを避けることです。

産業機器などリアルタイム性の確保が必要な環境では、動的メモリ割り当てによる処理時間のばらつきが問題になるため、リアルタイム性が高い領域では静的割り当てが推奨されます。ただし、RTOSが動的メモリを一切使用しないわけではなく、用途や優先度に応じて適切に使い分けられます。

RTOSのUI設計では、OS起動時に固定サイズを確保する「静的割り当て」が求められます。タッチ入力の遅延やシステム停止を防ぐには、描画中の裏画面と表示中の表画面を一瞬で切り替える「ダブルバッファリング」が採用されます。

タッチ入力の受付と負荷の大きい描画処理を完全に切り離すことで、遅延の少ない確実な応答性と安定性の実現を目指すものです。

これに加えて、即時応答が基本となるRTOSでは、ハードウェアからの割り込み（ISR）とUIタスクが「現在のタッチ座標」などを共有するクリティカル領域にも気を配る必要があります。

ISRとUIタスクが同時にアクセスした場合に生じるのがデータの競合という問題であり、競合が発生すると、座標情報の中途半端な上書きや誤動作を招く恐れがあります。排他制御などにより、クリティカル領域で競合が起こらないような保護設計を用いることで、産業機器の安全なタッチUI運用を実現する必要があります。

ただし、ダブルバッファリング・クリティカル領域保護設計のいずれも「その設計を盛り込んでいれば安全」というものではありません。たとえば、ダブルバッファリングは描画と表示の2面分のフレームメモリを必要とするため、メモリ容量上限に注意が必要であるなど、実際に生じる負荷を意識しながらメモリ制約を検討する必要があります。

軽量UIフレームワークは「リアルタイム性を壊さない」ために選ぶ

多くのRTOS環境では軽量UIフレームワークが適しています。軽量UIフレームワークは、RTOS環境を前提に設計されており、リソース消費量が予測しやすく安定して動作する点が特徴です。

また、産業機器のUI設計では、アニメーションなど「動きのある描画」よりも、システム負荷を「抑える」発想が重要です。汎用OSのUIに慣れたユーザーにとっては、この点が見落とされがちな評価ポイントです。

過度なアニメーションを最小限に留め、描画頻度を適切に制御することで、クリティカルな制御処理への影響を防ぎ、確実な応答性・信頼性を実現するという前提が、軽量UIフレームワーク選定の根拠といえるでしょう。

「タッチが壊れる前提」で考えるフェールセーフ設計について

産業機器のタッチUIは、故障・反応停止が起こり得ることを前提としたフェールセーフ設計が重要です。

フェールセーフは、たとえば経年劣化などによる機器の故障や電源喪失などの突発的な故障だけではなく、人間による想定外の連続タップなどの本来意図しない操作や外部ノイズによる誤入力にも備える必要があります。

例として、タッチ操作に慣れていない人が、必要以上に何度も同じ場所をタッチしたり、本来は指でタッチするところを手のひらや拳でタッチするなどにより、本来よりも広い箇所が判定を受けるなどの事例もありえます。

また、ノイズについては機器により異なりますが、無線電波（電波ノイズ）で影響を受ける事例や、水・雪によるノイズ、雷放電（空電ノイズ）などが発生する場合もあります。

様々な原因により、万が一UIタスクがフリーズ（応答停止）する事態に備えて、ウォッチドッグタイマー（WDT）による監視と自動リカバリ機構を組み込むことが、フェールセーフ設計の第一歩です。

WDTによる周期的な監視は、あまりにも監視頻度が高いと、UIタスクが応答を返す前に停止判定をしてしまう恐れがありますが、反対に監視頻度が低いと応答停止の発見が遅れます。最適な監視時間の選定は、監視対象となる産業機器によって異なるため、画一的な基準はありません。

まとめ

この記事では、一般的なコンシューマ用途で使われる汎用OSとRTOSのタッチ処理について、RTOSの使用目的や重要視するポイントに着目して解説しました。

RTOSは見た目の滑らかさやリッチさではなく、タッチした際に確実に、即時に動作することを目的としています。その理由は、産業機器など処理の遅れが深刻な事態を招きやすいという特徴があるためです。

RTOSは即時の応答を実現するため、リソースの集中、遅延処理などの複数の組み合わせと、フェールセーフによって、産業現場での安定した稼働を実現しているのです。