このブログは「Two-Wheeler Embedded UIs: Test Right or Risk Product Recalls」を翻訳・一部加筆したものです。
Industry Insights Blog Series（業界動向ブログシリーズ）
電動自転車、スクーター、または現代の2輪車におけるディスプレイは、ライダーが最も重要な情報を確認するための主要なインターフェースです。正確な速度、リアルタイムのバッテリー状態、視認性の高い方向指示灯、信頼性の高いナビゲーションは、ライダーの安全と信頼性を確保するための重要な要素です。
マイクロモビリティ分野で採用される多様な組み込みプロセッサ（リソース制約の厳しいマイクロコントローラユニット（MCU）から、より高性能なマイクロプロセッサユニット（MPU）やシステムオンチップ（SoC）まで）において、過酷な実環境下で信頼性高く機能させることは、核心的なエンジニアリングが必要です。エラーや故障は単に使用者を困惑させるだけでなく、安全事故を引き起こす可能性があり、高額なリコールを招き、重大な法的責任を伴うリスクを伴います。
ハードウェアの幅広い領域におけるテストの課題
2輪車用ディスプレイの開発とテストには、さまざまな課題の管理が伴い、以下の点に要約できます：
安全機能: 速度表示の誤り、警告表示の故障、またはナビゲーションの誤りは、ライダーの安全に直接影響を及ぼす可能性があります。信頼性を確保するため、包括的なテストが不可欠です。
過酷な環境: ディスプレイは、極端な温度範囲でも信頼性高く動作し、他の車両システム（BMSやモーターコントローラーなどで、通常はCANバス経由）からリアルタイムで送信されるデータを正確に表示する必要があります。これらは、振動や潜在的な反射光に対処しながら機能しなければなりません。これらの相互作用を手動で検証することは複雑で、しばしば不十分です。
激しい市場圧力: チームは、新機能のリリースとリリース期限の遵守という継続的なプレッシャーに直面しています。これに伴い、テストスケジュールが圧縮されることが多く、接続性や高度なグラフィックスの進化によりソフトウェアの複雑さが増す中で、この状況はさらに深刻化しています。
回帰テストのボトルネック:あるエンジニアが指摘したように、「手動の回帰テストでは追いつけなかった」。ファームウェアの更新や新機能の追加が、既存のセイフティクリティカル な機能を破損しないことを確認するプロセスは、遅く、手間のかかる手動作業であり、頻繁に 詳細ながら だが深刻なバグを見逃す傾向があります。
マイクロコントローラーと制約:マイクロモビリティは、幅広い種類の処理ハードウェアを活用しています。
1.) MCU側では、開発者は限られた処理能力（MHz）やメモリ（キロバイト）といった制約の厳しい環境に対応する必要があります。このようなシステムでは、汎用的な自動テストツールは受け入れられないオーバーヘッドを引き起こす可能性があり、デバイスの安定性を損なうか、リアルタイム動作を変化させる可能性があります。そのため、軽量で専門的なソリューションが求められます。
2.) MPU/SoCプラットフォームではリソースが豊富である一方、課題は複雑なOSの管理、高度なグラフィックススタックの最適化、および他のプロセスと並行してパフォーマンスを確保することに移行します。効率的かつ正確なテストは依然として不可欠です。
「十分」なテストツールが不十分である理由
伝統的なテスト手法は、これらの複合的な課題に完全に対応することが困難です:
手動テスト: 迅速な反復開発や回帰テストの要件に対応できないほど遅く、人的ミス（断続的なバグの検出漏れ）が発生しやすく、スケールが困難であり、カバー率も不十分（複雑なUIでは40～70％が一般的）です。
カメラ/ロボットリグ: これらのシステムは、設置とメンテナンスに高額なコスト（$10,000から$50,000以上）がかかり、物理的な調整（キャリブレーションのずれ）に敏感で、反射などの視覚的な変動に対応が難しく、内部ロジックや急激な状態変化のテストが容易ではありません。
シミュレーション/エミュレーション: 初期開発段階では有用ですが、ターゲットデバイス（MCUベースまたはMPUベースを問わず）のタイミングの微妙な違い、ハードウェアの制限、または現実の周辺機器との相互作用を完全に再現することはできません。
組み込みシステム特有の要件に特化して設計されたGUIテスト自動化への移行は、手動中心のテスト手法と比較して、効率性、テストカバレッジ、信頼性の向上を実現する手段を提供します。Squishのようなソリューションやツールは、チームがターゲットハードウェア上で直接テストを自動化できるようにし、 レグレッション（後方互換性の問題）を早期に検出することで、リリースへの信頼性を高めます。
組み込みハードウェアシステム向けに設計された自動化されたGUIテスト
Squishは、組み込みシステム全体にわたる自動化されたGUIテスト機能を提供します。このツールは、ベアメタルやRTOSベースのマイコン（マイコン向けにQtやQt Quick Ultraliteを使用する場合が多い）から、組み込みLinuxシステム（Qt6などのフレームワークをサポート）まで、幅広いプラットフォームに対応しています。
Squishは、Qt6を搭載した組み込みLinuxプラットフォームおよび、Qt for MCUsを搭載したベアメタルおよびRTOSベースのマイクロコントローラープラットフォームと互換性があります。
Lightweight & On-Target 軽量で
組み込み制約を考慮して設計されています。例えば、8MHzまでのMCUコアでテスト済みであり、極めて軽量でシステムへの影響を最小限に抑えます。デバイスの動作に過度に干渉することなく、信頼性の高いテストを提供します。
信頼性の高い検証、ハードウェアに最適化されたサイズ
MCUディスプレイ向け: Squishはピクセル単位の正確な画像とOCRベースのテストに対応し、チップに負荷をかける追加のコードは不要です。
MPUの場合: より高性能なプロセッサ（MPUでメモリやストレージ容量がより大きいものなど）では、Squishはオブジェクトのプロパティも識別するため、ビジュアル以外のより複雑な検証を実行できます。
これは、余裕がある環境での詳細なテストと、余裕がない環境での軽量なテストを意味します。
複雑な相互作用のテスト
テストスクリプト（Python、JavaScriptなど）は、マイクロモビリティに関連するインタラクションを駆動できます。例えば、低バッテリーモードのシミュレーションやOTA更新シーケンスの検証などが挙げられます。他のシステムとのインタラクション（例：CANバス信号から表示されるデータの検証）もテスト可能です。これには、テスト設定の一部としてファームウェア内に適切なテストフックやAPIを実装する必要があります。
CI/CD インテグレーション
回帰テストのボトルネックを解消するために不可欠です。Squishテストの実行をCI/CDパイプラインに統合することで、コードのコミットごとに他のチェックと並行して自動化されたGUIテストを実行し、即時フィードバックを得ることができます。
多様な組み込みマイクロプロセッサとシステムを開発する企業は、Squishを採用しています。これは、以下の持続的な課題に直接対応するからです：回帰テストのボトルネックの解消、厳しい納期下でのテストカバレッジの向上、および実際のターゲットハードウェアでの信頼性の高いUI検証の実現。マイクロモビリティ分野では、リソース制約下でのGUIの品質と信頼性を確保する必要性が、Squishのようなツールを採用する主な要因となっています。
次のステップへ
不十分なテストにより、ライダーの安全性を損なうべきではありませんし、製品のロードマップを遅らせるべきでもありません。厳しい納期を守りながら、マイクロモビリティディスプレイの信頼性を確保するためのより効果的な方法が必要な場合、組み込みシステムハードウェアの特有の制約に対応した自動テストを検討してください。
Squishがチームがより安全な製品を迅速かつ効率的にリリースするお手伝いをします。
