アクセス制御端末向けTFT LCDおよびHMIアーキテクチャの選定方法

アクセス制御端末のディスプレイは、焦点が絞られつつも要求の厳しい役割を担う。カメラ、認証リーダー、照明システム、マイク、スピーカー、キーパッド、指紋センサー、その他の認証ハードウェアとコンパクトなフロントパネルを共有しながら、ユーザーに即時的で曖昧さのないフィードバックを提供しなければならない。.

したがって、TFT LCDは端末の一部に過ぎない。承認または拒否メッセージを表示するという理由だけで、認証を検証したり、アクセス判断を行ったり、ドアを直接制御したりするわけではない。これらの機能は、端末ソフトウェア、認証サブシステム、ドアコントローラー、およびより広範なアクセス制御アーキテクチャに属する。.

OEMチームにとって、正しい設計プロセスは、完全なユーザーインタラクションとシステム境界を定義することから始まる。ディスプレイサイズ、アスペクト比、インターフェース、タッチ技術は、独立したカタログ選択として扱うのではなく、そのアーキテクチャに基づいて選択できる。.

ディスプレイを選定する前に端末の役割を定義する

“「アクセス制御端末」は、いくつかの異なる製品を指すことがある。シンプルなリーダーは、コンパクトなステータス表示のみを必要とする場合がある。タイム＆アテンダンス端末は、従業員情報、スケジュールプロンプト、タッチナビゲーションを必要とする場合がある。来訪者端末は、カメラ、QRコードワークフロー、インターホン、およびより大きなグラフィカルインターフェースを含む場合がある。生体認証端末は、顔の位置決め、認証プロンプト、登録、トランザクションフィードバックを調整する必要がある場合がある。.

最初のエンジニアリングステップは、どの機能が端末ローカルで実行され、どの機能が他の場所で実行されるかを文書化することである。.

端末の役割	一般的なディスプレイ要件	システムに関する質問
ステータスリーダー	短いプロンプト、認証ステータス、ドア状態、障害メッセージ	リーダーはローカルで判断を行うのか、それとも別のコントローラーに報告するのか？
タッチスクリーンアクセス端末	PIN入力、メニューナビゲーション、来訪者プロンプト、状況に応じた指示	ローカルで許可されるアクションは何か、タッチイベントはどのように保護・検証されるのか？
生体認証端末	位置決めガイダンス、進捗フィードバック、再試行指示、結果状態	生体情報の取得、照合、テンプレート、プライバシー制御はどこで処理されるのか？
タイム＆アテンダンス端末	ユーザー識別、打刻状態、作業コード、トランザクション確認	ネットワークまたはサーバーがオフラインの場合、何を利用可能にしておく必要があるか？
来訪者またはインターホン端末	ディレクトリ、通話状態、カメラプレビュー、指示、アクセシビリティサポート	ビデオ、オーディオ、タッチ、ドア解放、リモートオペレーター機能はどのように分離されるのか？

「4インチAndroidアクセスディスプレイ」のような要件だけでは十分ではない。エンジニアリングのベースラインは、ユーザージャーニー、認証方法、ドアコントローラーアーキテクチャ、ネットワーク依存関係、設置環境、視認位置、電源、筐体、ソフトウェアの所有権、生産数量も定義すべきである。.

フロントパネルのアーキテクチャから表示フォーマットを選択する

アクセス制御端末は通常、前面に画面以外のものも収容する必要があるため、スペースに制約がある。カメラは目の高さ付近に配置する必要がある場合がある。RFIDアンテナは、その意図された動作を妨げる材料や電子機器を避けなければならない。指紋センサーは、アクセス可能な物理的位置を必要とする。スピーカー、マイク、照明部品には、開口部または制御された光路が必要である。.

表示フォーマットはこのレイアウトに従うべきである。.

コンパクトなランドスケープディスプレイ

小型のランドスケープTFT LCDは、端末が主にステータス、短い指示、アイコン、またはシンプルなPINインターフェースを表示する場合に適している。その幅はテキストや横並びの視覚要素をサポートできるが、リーダーやカメラとフロントパネルの水平方向のスペースを競合する可能性がある。.

ポートレートタッチスクリーン

ポートレートディスプレイは、認証情報提示、PIN入力、顔位置決め、待機、結果表示といった垂直方向に順序付けられたステップをサポートできる。このフォーマットは、細長い壁掛け端末に自然に適合する場合がある。チームは、タッチターゲットサイズ、片手操作、テキスト長、カメラ配置を依然として検証する必要がある。.

バータイプディスプレイ

細長いバーLCDは、製品が認証リーダーの上部または横にスリムなステータスエリアを必要とする場合に有用である。特徴的な工業デザインを提供し、カメラやセンサーのためのスペースを確保できる。ただし、細長いアスペクト比は従来のUIレイアウトを制限するため、アプリケーションはアクティブエリアに特化して設計されなければならない。.

RJY Displayの公開Smart Accessデモンストレーションでは、小型のバータイプLCDとAndroidマザーボードが使用されており、このアーキテクチャが特定のアクセス端末プロジェクトで検討可能であることを示している。このデモンストレーションは、すべてのバーディスプレイやAndroidボードが自動的にすべてのアクセス制御システムに適しているという証明として解釈されるべきではない。.

高速で曖昧さのないフィードバックを中心にUIを設計する

ドア端末のインタラクションは短時間である。ユーザーは入り口に立って複雑なインターフェースを学習することを期待しない。ディスプレイは、単一の色、小さなアイコン、短時間のアニメーションに依存することなく、現在の状態を明確にすべきである。.

最低限、以下の視覚的動作を定義する：

• アイドル状態および準備完了状態；;
• 認証情報検出；;
• 認証情報評価中；;
• アクセス許可；;
• アクセス拒否；;
• 第2要素要求；;
• 無効または読み取り不能な認証情報；;
• 該当する場合のドア開放、ドア保持、ドア強制状態；;
• 端末オフラインまたはコントローラー利用不可；;
• サービス、メンテナンス、またはタンパー状態；;
• 電源またはネットワーク中断後の復旧。.

成功状態と失敗状態は、理解できるのに十分な時間表示されるべきであるが、画面は前のユーザーに関する情報を露出させることなく、プライバシーを保護するアイドル状態に戻るべきである。.

コントラストとタッチターゲット

組み込み端末インターフェースは自動的にウェブページではないが、WCAG 2.2は有用なUI設計の参考情報を提供する。最小コントラスト基準の下で、通常のテキストには少なくとも4.5:1、大きなテキストには3:1のコントラスト比を指定している。また、タッチ操作されるインターフェース向けの最小および拡張ポインターターゲットガイダンスも定義している。.¹

これらの値は、製品に適用されるアクセシビリティ要件や実機テストに取って代わるものではない。これらは、テキスト、アイコン、コントロールを評価するための出発点を提供する。最終的な可読性は、ピクセル密度、フォントレンダリング、カバーガラスの反射、視認距離、設置高さ、周囲光、実際のユーザーの視力にも依存する。.

許可状態と拒否状態を区別するために色のみを使用することは避ける。色を明確なアイコン、テキスト、オーディオ、またはその他の適切な信号と組み合わせる。また、ドアコントローラーが矛盾する状態を報告している間に、緑色の確認を表示することも避けるべきである。.

ディスプレイ、タッチ、認証入力を分離する

ディスプレイは出力デバイスである。タッチセンサー、カメラ、RFIDリーダー、指紋センサー、キーパッド、マイクは別個の入力システムである。これらはホストプロセッサと筐体を共有する場合があるが、異なるインターフェース、ドライバー、タイミング要件、障害モードを持つ。.

サブシステム	主要機能	代表的な統合に関する質問
TFT LCD	プロンプト、ステータス、グラフィカルUIを表示する	パネルインターフェース、タイミング、電源、バックライト、視野角、機械的適合性
タッチセンサー	ユーザーのタッチ座標またはジェスチャーを報告する	タッチコントローラー、USBまたはI2C経路、カバースタック、チューニング、接地、ドライバー
カメラと照明	承認されたアプリケーション機能のために画像を取得する	視野、画像インターフェース、照明、熱負荷、プライバシー、アプリケーションの所有権
クレデンシャルリーダー	カード、タグ、モバイルクレデンシャル、またはその他の対応トークンを読み取る	アンテナ位置、プロトコル、コントローラー境界、電気的ノイズ、筐体材料
指紋またはキーパッド入力	別の認証要素またはユーザー入力方法を提供する	物理的アクセス、データ経路、清掃、摩耗、プライバシー、ローカルソフトウェア統合
マイクとスピーカー	インターホンまたは可聴フィードバックを提供する	オーディオコーデック、音響設計、エコー、開口部、シーリング、アプリケーション動作

あるサブシステムの障害は別のサブシステムによって隠蔽されてはならない。例えば、機能するLCDはクレデンシャルリーダーがオンラインであることを証明しない。カメラプレビューは生体認証処理やドアコントローラーが利用可能であることを証明しない。タッチアニメーションは要求された操作が受け入れられたことを証明しない。.

LCDとホスト間のインターフェースを意図的に選択する

ディスプレイ経路は選択されたホストボードに依存する。コンパクトな組み込みシステムはRGB、MIPI DSI、LVDS、eDP、SPI、またはその他の対応パネルインターフェースを使用する場合がある。コントローラーボードのディスプレイは代わりにHDMIなどの外部ビデオソースを受け入れる場合がある。.

これらのアーキテクチャは無造作に混在させてはならない。HDMIは生のMIPI、RGB、LVDS、またはeDPパネルを受動的に駆動できない。アクティブレシーバー、ブリッジ、スケーラー、またはコントローラーボードが必要であり、ソースビデオをLCDが期待する電気的フォーマット、タイミング、初期化に変換する。.

タッチは別個の入力経路として残る。一般的なHDMIタッチディスプレイでは、HDMIが画像を伝送し、USBがタッチ座標を伝送する。組み込みタッチコントローラーは代わりにI2Cまたは別のインターフェースを介して接続する場合がある。²USB Implementers Forumは、準拠するUSB入力デバイスで使用されるヒューマンインターフェースデバイスクラス仕様を公開している。.²

モジュールを選択する前に、以下を確認すること：

• ホストボードのモデルとハードウェアリビジョン;
• ネイティブディスプレイ出力とコネクタ;
• LCD解像度、タイミング、ピクセルフォーマット;
• インターフェースレーン、チャンネル、またはバス構成;
• パネル電源レール、リセット、イネーブルシーケンス;
• バックライト電圧、電流、輝度制御方法;
• タッチコントローラーインターフェースとオペレーティングシステムドライバー;
• 画面回転とタッチ座標回転;
• ブートロゴ、リカバリ画面、アプリケーション起動動作;
• カメラ、リーダー、オーディオ、外部I/O要件.

HMIコンピュータをドア制御境界から分離する

アクセス端末には、ディスプレイ、タッチUI、カメラ、オーディオ、ネットワークアプリケーションを駆動するAndroidまたはLinuxコンピューティングボードが含まれる場合がある。同じ筐体にはドア制御電子機器が含まれる場合もあり、端末は別のセキュアコントローラーと通信する場合もある。.

プロジェクトは、どのコンポーネントがアクセス判断を行い、どのコンポーネントがロックに通電するかを定義しなければならない。グラフィカルアプリケーションは、画面上のホストボードで動作するという理由だけで、唯一のセキュリティ境界と見なされるべきではない。.

Security Industry Associationは、Open Supervised Device Protocolを、アクセス制御およびセキュリティ製品間の相互運用性を向上させることを目的としたアクセス制御通信標準として説明している。現在のSIA情報はOSDP v2.2.2を特定し、OSDPがIEC 60839-11-5として公開されていることに言及している。.³

これは、すべてのRJY Displayボードまたは提案された端末がOSDPをサポートすることを意味しない。プロジェクトがOSDP、RS-485、Wiegand、Ethernet、CAN、リレーI/O、またはその他の通信方法を必要とする場合、そのプロジェクトに対して正確なハードウェア、電気設計、ソフトウェア実装、認証要件を確認しなければならない。.

オフラインおよび障害時の動作を定義する

ネットワーク喪失、サーバー利用不可、ドアコントローラー通信喪失は異なるイベントである。UIは端末が検証できる状態のみを表示すべきである。.

解決すべき質問には以下が含まれる：

• 端末はオフライン中に承認されたクレデンシャルをローカルで処理できるか？
• どのコンポーネントがクレデンシャル、権限、監査記録を保存するか？
• ネットワークが利用不可だがローカルアクセスが動作している場合、どのメッセージが表示されるか？
• 端末がサーバーには到達できるがドアコントローラーには到達できない場合、何が起こるか？
• 不完全なトランザクションは停電後にどのように回復されるか？
• 時刻、言語、構成はどのように同期されるか？
• どの情報が許可されていないユーザーから隠されなければならないか？

異なるオフライン状態が異なるサービスアクションやアクセスポリシーを必要とする場合、一般的な「オフライン」アイコンでは不十分である。.

Androidまたは組み込みボードの互換性を管理された構成としてレビューする

Androidボードはグラフィックス、ネットワーキング、カメラ、オーディオ、アプリケーションサポートを提供できるが、「Android互換LCD」は完全なエンジニアリング仕様ではない。互換性は、正確なパネル、ボードリビジョン、ブートローダー、カーネル、BSP、デバイスツリー、ディスプレイドライバー、タッチドライバー、アプリケーションイメージに対して確立されなければならない。.

システムチームは、各周辺機器がサポートされるネイティブインターフェースを使用するか、外部ブリッジまたはコントローラーを必要とするかを確認すべきである。利用可能なコネクタだけでは、すべてのカメラ、ディスプレイ、タッチセンサー、クレデンシャルリーダー、オーディオデバイスが同時に動作できることを証明しない。.

プロトタイプ承認前に、ソフトウェア責任も割り当てられるべきである：

• LCDタイミングとパネル初期化;
• バックライト制御とアイドルポリシー;
• タッチドライバーとキャリブレーション;
• 画面とタッチの回転;
• カメラドライバーとアプリケーションパイプライン;
• クレデンシャルリーダーSDKまたはプロトコル統合;
• ドアコントローラー通信;
• 起動、ウォッチドッグ、アプリケーションリカバリ;
• リモートアップデートとロールバック戦略;
• 本番イメージおよび構成管理。.

RJY Displayは、定義されたディスプレイプロジェクトに関するコントローラーボードおよびファームウェアの議論をサポートしますが、ソフトウェア適応はプロジェクトに依存します。これは自動的なプラグアンドプレイ機能として扱われるべきではありません。.

カバーガラス、タッチ、機械構造を調整する

端末の前面パネルは、単一の機械的および光学的アセンブリとして設計されなければなりません。LCDアクティブエリア、タッチセンサー、カメラウィンドウ、照明開口部、リーダーアンテナ、マイク、スピーカー、指紋センサー、印刷枠、および実装機能はすべて、制御されたスペースを競合します。.

以下の完全な図面をレビューすること：

• LCD外形、アクティブエリア、および表示エリア；;
• タッチセンサーおよびカバーガラスの外形；;
• カメラおよび照明の光学経路；;
• 印刷枠の位置合わせおよび公差；;
• FPC出口、コネクタ位置、およびケーブル曲げ；;
• リーダーアンテナの位置および周辺材料；;
• スピーカーおよびマイクの音響経路；;
• 実装荷重、接着エリア、およびキープアウトゾーン；;
• サービスアクセスおよび交換手順；;
• 機器メーカーによって定義されたガスケット、接合部、および筐体要件。.

カバーガラスは既存のディスプレイプラットフォームに合わせて調整可能ですが、完成した端末の耐衝撃性、浸入保護、または環境認証を単独で確立するものではありません。これらの特性は、完全な筐体、材料、シール、実装、および認定プログラムに依存します。.

LCDだけでなく、完全なアクセス端末を検証する

テスト画像を表示するディスプレイサンプルは、まだ検証済みの端末ではありません。代表的なプロトタイプには、対象のLCD、タッチスタック、ホストボード、カメラ、照明、認証リーダー、オーディオハードウェア、ドアコントローラーインターフェース、電源アーキテクチャ、ケーブル配線、筐体、およびソフトウェアリリースが含まれるべきです。.

ディスプレイおよびUI検証

対象の実装高さ、視聴距離、および接近方向からすべてのユーザー状態を確認すること。通常および低周囲光、反射、言語バリエーション、長い名前、エラーテキスト、画面回転、調光、ウェイクアップ、およびプライバシータイムアウトをテストすること。.

入力および周辺機器検証

組み立てられた筐体内で、タッチ精度、エッジ動作、リーダー動作、カメラ位置合わせ、照明、指紋またはキーパッドアクセス、オーディオレベル、およびマイク性能を検証すること。周辺機器は一度に一つだけでなく、同時に動作させること。.

障害および復旧検証

コールドスタート、繰り返しの電源サイクル、アプリケーション再起動、ウォッチドッグ復旧、ネットワーク切断、サーバー再接続、ドアコントローラー通信喪失、安全な場合の周辺機器切断、失敗したソフトウェアアップデートおよびロールバックをテストすること。対応する承認済みシステムイベントなしに、画面がアクセス許可状態を表示しないことを確認すること。.

本番構成管理

承認された構成は、LCDモデルおよびリビジョン、タッチセンサー、カバーガラス図面、カメラ、リーダー、オーディオコンポーネント、ホストボードリビジョン、ドアインターフェースハードウェア、ケーブル図面、ファームウェア、BSP、デバイスツリー、アプリケーションビルド、構成ファイル、および本番テスト手順を特定すべきです。.

動作するエンジニアリングサンプルは、文書化されていないケーブル、手動でインストールされたドライバー、一時的なレジスタ設定、または記録されていないタッチ構成に依存する場合、再現可能ではありません。.

完全なアクセス端末ディスプレイのRFQを準備する

有用なエンジニアリングレビューのために、以下を提供すること：

• 端末タイプおよび対象アプリケーション；;
• 屋内、シェルター付き、または屋外の設置条件；;
• 前面パネルおよび筐体図面；;
• 対象ディスプレイサイズ、アスペクト比、および解像度；;
• 代表的なUI画面および対応言語；;
• 視聴距離、実装高さ、および周囲光条件；;
• タッチスクリーンおよびカバーガラス要件；;
• カメラ、照明、リーダー、指紋、キーパッド、およびオーディオ要件；;
• ホストプロセッサまたはコントローラボードのモデル；;
• 推奨LCDおよびタッチインターフェース；;
• ドアコントローラー通信および外部I/O要件；;
• オペレーティングシステム、BSP、ドライバー、およびアプリケーションの責任範囲；;
• 電源、熱、および筐体制約；;
• プロトタイプ数量、予想生産量、およびライフサイクル期待値；;
• 必要な製品レベル規格および検証基準。.

RJY Displayは、既存のディスプレイプラットフォームを基に、利用可能なTFT LCDモジュール、バーディスプレイ、タッチオプション、コントローラーボード、およびカスタマイズをレビューできます。議論には、プロジェクトの実現可能性に応じて、カバーガラス、バックライト、FPC、インターフェース、タッチ、コントローラーボード、ファームウェア、および機械的調整が含まれます。.

エンジニアリングレビューのために、アクセス端末のディスプレイ、ホストボード、UI、周辺機器、および筐体要件を送付してください。.

よくあるご質問

アクセス制御端末にはどのようなディスプレイフォーマットが適していますか？

コンパクトなランドスケープ、ポートレート、またはバータイプのTFT LCDが、端末のUI、カメラ、認証リーダー、キーパッド、指紋センサー、および筐体レイアウトに応じて適している場合があります。正しいフォーマットは、ディスプレイサイズのみではなく、完全な前面パネルアーキテクチャから選択されるべきです。.

TFT LCDは生体認証またはアクセス制御を実行しますか？

いいえ。TFT LCDはプロンプトと結果を表示します。カメラキャプチャ、生体認証処理、認証読み取り、アクセス判断、およびドア制御は、複数の機能が1つの組み込みホストボードを共有する場合でも、別個のハードウェアおよびソフトウェア機能に属します。.

HDMIは、生のMIPI、RGB、LVDS、またはeDPパネルに直接接続できますか？

いいえ。HDMIには、パネル互換のインターフェース、タイミング、および初期化を生成するためのアクティブレシーバー、ブリッジ、スケーラー、またはコントローラーボードが必要です。パッシブケーブルはその変換を実行したり、パネル電源およびバックライト機能を提供したりすることはできません。.

Androidコントローラーボードは、任意のアクセス制御ディスプレイで動作しますか？

いいえ。正確なLCD、タッチコントローラー、ボードリビジョン、インターフェース、タイミング、コネクタ、電源、ブートローダー、カーネル、BSP、デバイスツリー、およびソフトウェアイメージについて互換性を検証する必要があります。カメラ、リーダー、オーディオ、およびドアコントローラー通信などの周辺機器要件も確認する必要があります。.

アクセス端末HMIを承認する前に、何をテストすべきですか？

完全なディスプレイおよびタッチスタック、カメラと照明、認証リーダー、オーディオ、ドアコントローラー通信、UI状態、視聴条件、起動、繰り返しの電源サイクル、ネットワーク喪失、コントローラー喪失、アプリケーション復旧、ソフトウェアアップデート動作、筐体組み立て、および管理された本番構成をテストすること。.

参考文献

1. World Wide Web Consortium（ワールド・ワイド・ウェブ・コンソーシアム）、, Webコンテンツアクセシビリティガイドライン2.2. ↩
2. USB Implementers Forum（USB実装者フォーラム）、, ヒューマンインターフェースデバイスの仕様とツール. ↩
3. セキュリティ産業協会, オープン監視デバイスプロトコル. ↩