ハードウェア・イン・ザ・ループテスト：イントロダクション

「ハードウェア・イン・ザ・ループ」テストを検索すると、複雑なリアルタイムシステムの例が頻繁に見つかります。例えば、このNational Instrumentsの記事は、ハードウェア・イン・ザ・ループ（HIL）が何であるか、そして自動車内の電子制御ユニットのテストの例を提供している上で、素晴らしい説明と背景を提供しています。この記事では、HILテストコンセプトのより小さく、より取り組みやすいバージョンに焦点を当てます。

ハードウェア・イン・ザ・ループテストとは何か？

この記事の目的のために、我々はハードウェア・イン・ザ・ループテストを従来提示される方法（例えば、自動車アプリケーション内で）とは少し異なる方法で定義します。製品をテストする際の複雑さの異なる三つのレイヤーを観察しましょう。

テストフォーマット1：基本的な手動テスト

このテスト形式では、エンジニアがデバイスを手動でテストします。これには、デジタルマルチメーターで基板上のテストポイントを探る、オシロスコープで波形を観察する、またはコンピューター画面上でテレメトリー読み取りを手動で解析することが含まれます。エンジニアは、手動の設計検証テストを通じて製品をテストします。

テストフォーマット2：自動テスト

このテストセットアップは、通常エンジニアによって行われる同じ測定と検証を実行しますが、コンピュータによって自動化された方法で実行されます。ホストコンピュータは直接計測器（例：マルチメーター、オシロスコープなど）に命令を出し、デバイスからのテレメトリを解析し、その後、エンジニアによって設定された基準に基づいてテストセットを検証します。

テストフォーマット3：ハードウェア・イン・ザ・ループテスト

ハードウェア・イン・ザ・ループテストは、実世界のアプリケーションをシミュレートする追加の刺激を加えることで、自動テストを新たなレベルに引き上げます。例えば、テスト対象のデバイス（DUT）には、刺激が必要な一連のセンサーがあるかもしれません。テスト機器は、それらのセンサーの他端をシミュレートして、DUTのセンサー側を刺激します。別の例としては、DUT上のRS-422レシーバーにRS-422トラフィックを駆動することが挙げられます。私たちがDUTに新しい刺激を駆動し、ホストコンピュータからテレメトリを読み取り、必要に応じてテストを適切に調整できる（例：初期テストを通過した後に、より速く、より多くのRS-422トラフィックを駆動する）という考えです。

ハードウェア・イン・ザ・ループを採用する利点

アプリケーションに基づいて、なぜハードウェア・イン・ザ・ループ（HIL）テストを自動テスト（そしてもちろん手動テスト）よりも採用するかが明確になる場合があります。複雑なシステム、または（システムのシステム）を統合しようとしている場合、多くの外部刺激が必要であれば、基本的な自動チェックアウトテストでは不十分です。基本的なバッテリーチャージャーを考えてみましょう。電源、負荷、バッテリーをシミュレートしてコントローラ回路をテストすることはできますが（物理的にもソフトウェアを通じても）、実際の電源、バッテリー、負荷を使用して設計をテストする方が現実的です。さらに、このプロセスを自動化できれば、エンジニアはテストよりも開発に時間を費やすことができます。

Easy, Powerful, Modern

The world’s most trusted PCB design system.

Learn More

コスト分析：それは価値がありますか？

ハードウェア・イン・ザ・ループテストを採用するかどうかを決定する際には、次の要因を考慮する必要があります：

1. テスト時間：デバイスのテストにどれくらいの時間を費やす予定ですか？基本的なチェックアウトを行って終わりですか、それとも数ヶ月のテストが必要ですか？
2. テストの再発生：同じテストをどれくらいの頻度で実行しますか？このテストセットアップ（つまり、機器と自動化スクリプト）は将来の設計に使用できますか？
3. テスト機器：自動テストと手動テストに必要な機器を揃えるコストはどのくらいかかりますか？

これらおよびその他の要因を考慮したら、手動テストを続けるか、自動/ハードウェア・イン・ザ・ループテストに投資するかの決定を始めることができます。

始め方

私の経験に基づくと、ハードウェア・イン・ザ・ループテストへの最も簡単な入門は、National Instruments (NI) が提供する包括的なテストフレームワークを使用することです。NIはプラグアンドプレイが可能な包括的なハードウェア/ソフトウェアプラットフォームを持っています。包括的なフレームワークを検討する際に考慮すべきいくつかの長所と短所はこちらです：

複雑なシステムに取り組んでいた期間、LabVIEWは自動テストのための私の主力でした。これには、LabVIEWプロジェクトとVIのための完全な継続的インテグレーションおよび継続的デプロイメントパイプラインの構築も含まれます。より小さなシステムに移行し、よりシンプルなハード・イン・ザ・ループのサポートが必要になったとき、私はカスタムまたは市販のハードウェアとPythonスクリプト（pytestフレームワークを使用）に移行し始めました。再び、これはすべてアプリケーションに依存し、前に述べたように、テスト時間、テストの再発生、およびテスト機器がこの決定を推進する主要な要因です。

結論

この記事では、ハードウェア・イン・ザ・ループテストの概念と、それが手動テストおよび自動テストとどのように異なるかを検討しました。また、ハードウェア・イン・ザ・ループテストを採用する利点と、それが本当にユーザーのニーズに合っているかどうかを評価する方法についても検討しました。最後に、始めるためのいくつかの方法について議論しました。ハードウェア・イン・ザ・ループテストがすべての人に適しているわけではありませんが、適切なアプリケーションに対しては、投資が非常に迅速に報われることは明らかです。

エレクトロニクスを設計する世界

サイロを解体し、エレクトロニクス開発の全ての側面にわたる協力を強化する

詳細を見る

Altiumが次のPCB設計でどのようにお手伝いできるか、もっと知りたいですか？Altiumの専門家に相談するか、トップDFM問題とその解決策についてもっと発見してください。