（タッチモニター関連コラム）Linux組み込み環境でタッチモニターを安定動作させる設計思想── DeviceTree・Qt/QML・Waylandの役割分担

産業用途でタッチモニターが採用されるのは、産業現場における情報表示手段としての有用性に加えて、タッチ操作による直感的・迅速な入力・命令が可能であることも見逃せないでしょう。

一方で、産業現場においてタッチモニターが不具合を起こす事例もあります。

タッチモニターの動作不安定や不具合は、個別に様々な原因がありますが、多くの場合最初にUI側の不具合が疑われます。

しかし、タッチモニターの不具合は必ずしもUI部分の不具合とは限りません。

この記事では、タッチモニターの不具合について、UI部分・ハードウェア部分との切り分けを改めて解説し、それぞれのレイヤーにおけるポイントを解説します。

産業用途で Linux タッチUI が採用される理由

産業用途では、LinuxベースのタッチUIが採用されることが多くあります。その理由は、柔軟性・拡張性に優れているためです。

Linuxは、医療機器、自動車などさまざまな産業で必要となる高度なグラフィカルUI（GUI）に対応しているほか、コンシューマ向けとは異なり工場内・医療現場などで用いる大画面化においても柔軟に対応できます。

また、深いメニュー階層や詳細なログ閲覧画面などの複雑なUIも、Linuxはスムーズに実装が可能です。

さらに、法人製品としての長期運用に不可欠な機能を持っています。標準で強力なネットワーク機能があるため、OTA（遠隔）更新、稼動ログの収集、セキュリティパッチの迅速な適用がスムーズに行えます。

法人向け製品の長いライフサイクルとの相性の良さも、Linuxが選定される理由のひとつです。

タッチモニター安定動作の前提は「UI」ではなく「ハードウェア定義」

産業用途においてタッチモニターを導入した際に、重要となる視点がハードウェアという土台についての認識です。

特に問題となるのは、タッチモニターの動作が安定しないという問題が生じたときです。

多くの場合、タッチモニターの動作が安定しないと、タッチモニターのUI側に問題が生じたと考えがちです。

しかし、タッチモニターは「映像」と「入力」の独立した2系統で成り立っています。

ドライバーの依存関係を正しく整理しなければ、どれほど優れたUIフレームワークを用いても、システムは必ず不安定になってしまいます。

タッチモニターにタッチの抜けや描画の乱れが生じないようにするためには、Qtなど上位のレイヤーについての問題を疑う前に、ハードウェアという土台を固める必要があるのです。

DeviceTree設計がUIの安定性を左右する理由

そもそもDeviceTreeとは、Linuxにおけるハードウェア構成をカーネルに伝えるハードウェア記述、つまり設計図のようなものです。

DeviceTreeが整備されはじめたのは2011年ごろで、その理由は多様なARMアーキテクチャが世の中に登場し、それらSoCごとに個別のプラットフォーム依存のボードファイル（の初期化コード）が乱立したという背景があります。

DeviceTreeはこの乱立に対する交通整理として整備されてきたものです。

DeviceTreeによる定義が不正確だと、UIからは原因を特定できないトラブルが生じることがあり、解決に余分な工数やデバイスそのものへの原因調査など、解決に直結しない寄り道が発生してしまうことがあります。

タッチモニターにおいては、ただ情報を表示するだけのモニターとは異なり、割り込み処理（IRQ）と入力イベントが発生することもあり、これらのイベントに不具合があると、操作感を直接的に損なうことになります。

なお、DeviceTreeの変更は必要に応じて行われますが、DeviceTreeの変更は他機能への波及が起こることがあり、安易に書き換えると別の問題を生じるリスクがあります。

DeviceTreeを書き換えたところタッチ操作が二重入力になるなど不安定化し、原因としてQML側を疑っていたところ、実はDeviceTreeの割り込み（interrupt）設定のミスだった、という事例を経験した担当者もいるでしょう。

DeviceTree書き換え時には、影響範囲の特定を前提とした慎重なリスク管理が重要です。

Qt/QMLは「UIを作るため」だけではなく「安定した設計を実現しやすい技術」

Qt/QMLは、産業用途で採用例の多い開発技術です。ではQt/QMLはどのような目的で産業用途で採用されるのでしょうか。以下の3つのポイントに分けて解説します。

• Qt/QMLが産業用途で評価される理由
• マルチタッチ・アニメーションを“安定して”描画できる理由
• 産業用途で意識すべきQt最適化の考え方

それぞれ具体的に見ていきましょう。

Qt/QMLが産業用途で評価される理由

Qt/QMLが産業用途で広く採用される理由は、産業用途という特殊性を考えることでイメージしやすくなります。

産業用途では、UIの「見た目上の正常動作」ではなく「万が一の不具合の際にもシステム全体をダウンさせないこと」にあります。

Qt/QMLは、UIを記述するQMLとアプリケーションの内部ロジックを担うQt（C++など）を分離しやすい設計になっています。

この構造により、UI部分とシステムロジックを明確に役割分担させることが可能です。

その結果、UI側に不具合が発生した場合でも、問題がシステム全体に波及しにくい設計を実現しやすくなります。

このように、UIとロジックを分離しやすい設計を持つ点が、Qt/QMLが産業用途で評価される理由の一つです。

マルチタッチ・アニメーションを“安定して”描画できる理由

Qtが採用される理由は、タッチ操作における特にマルチタッチなどの場面で、アニメーションを安定して描画できることにあります。

Qt Quickの「シーングラフ（Scene Graph）」と呼ばれる描画機能は、3D空間のオブジェクト（UI）の構成要素をツリー状に管理しており、変更があった部分のみをGPUにより効率的に描画するという機能を提供しています。

産業用途で意識すべきQt最適化の考え方

Qtは、シーングラフなどにより安定した描画を提供しますが、Qtを導入すれば確実な安定性を確保できるわけではありません。

この理由は、産業用機器（組み込み機器）は、リソースに厳しい制約があることが影響しています。Qtの機能を表現するためのQML側の記述が複雑すぎると、やはり処理遅延やレスポンスの遅さが発生してしまいます。

メモリ管理などリソースの管理も重要ですが、これに加えて、QML・C++など各領域での役割分担を行い、どこか特定の箇所に負荷（演算やデータ処理）が集中しないようにするなどの工夫が必要です。

Waylandは「新しいから」ではなく「構造がシンプルだから選ばれる」

Waylandとは、Linux向けのディスプレイサーバープロトコルです。

極めて単純に表現すると、ディスプレイ表示に関するルール（プロトコル）を定めた仕様書のようなものであり、安定性・安全性の高さにより、現代では産業用途だけではなくデスクトップ用途でのLinuxデスクトップ環境「GNOME」などでも採用されています。

Waylandより前には「X11」と呼ばれるディスプレイサーバーが広く採用されていました。

しかし、X11は描画処理のための経路が複雑で処理が重くなり、描画ズレが発生するなどの問題がありました。

一方、WaylandはX11より描画・入力の処理経路がシンプルで、不具合の原因が発生しにくい構造を持っています。

こうした特徴から、産業用途のタッチパネル端末や高解像度ディスプレイを使用する環境でも、滑らかな描画が実現しやすい点が評価されています。

なお、WaylandはX11に比べて新しい技術ではありますが、Waylandプロトコル自体は比較的早い段階から存在しています。ただし、Linuxデスクトップ環境や組込み環境、各種アプリケーション側の対応が進んだことで、実用的な普及が大きく進んだのは近年になってからです。

そのため、現在でもX11に依存する環境やアプリケーションが存在する点には注意が必要です。

また、Wayland環境を安定して運用するためには、QtなどのGUIフレームワークとの連携設計を適切に行うことも重要になります。

長期稼働を前提にしたUIテストと監視設計

産業用途としてタッチモニターを導入する場合、タッチモニター以外の産業機器と同様に長期稼働が前提となる事例が多いでしょう。

長期稼働では、短期稼働では想定していなかった不具合が生じる場合もあります。

これら不具合に対応するためには、稼働テストとデプロイ後の監視・更新体制が欠かせません。

• 連続稼働テストで見るべきポイント
• デプロイ後を見据えた監視と更新

上記のポイントに分けて、具体的に見ていきましょう。

連続稼働テストで見るべきポイント

産業機器は、基本的に長期稼働が前提となることが多いといえます。

現物としての機器が経年劣化で故障することと対比すると、UIは「連続稼働時のメモリ管理」や「連続稼働によって高負荷状態となった際のタッチ応答」などを検討する必要があるでしょう。

単に長時間・長期間稼働であるだけでなく、稼働時間・稼働期間に応じた「負荷」の存在や「リソース枯渇」にまで目を配ったテストを行うことが、安定動作の実現には欠かせません。

デプロイ後を見据えた監視と更新

また、デプロイ後には適切な監視設計が不可欠です。

監視の基本となる稼働ログ収集、OTAによる安全かつ確実なアップデート体制は、基本的でありながら、実は軽視される事例が多くあります。

監視・更新体制の確実な構築は、タッチモニターの長期間にわたる安定稼働を実現するための柱であるといえるでしょう。

まとめ

この記事では、産業機器としてのLinux組み込み環境でのタッチモニターの安定動作について解説しました。

タッチモニターにおける動作の不具合や不安定は、多くの場合真っ先にUI側が疑われ、UI側の整備に重点が置かれます。

しかし、タッチモニターの安定稼働という目的を実現するには、UI側を整備することに加え、ハードウェア部分の整備も同様に欠かせない要素です。

テスト・監視体制まで含めた安定稼働のための参考として、この記事で解説した内容を活用してください。