ハードウェア・イン・ザ・ループテスト自動化のための低コストソリューション

今日のように電子機器のイテレーションが稲妻のように速いペースで進む世界では、開発の最も重要な側面の一つであるテストを忘れがちです。テストは製品をリリースすることを妨げる最後の段階であるため、簡単に見過ごされがちです。製品開発では、「十分良い」対「徹底的にテストされた」のキャンプに自分自身を常に見つけます。この状況は、テストし、再テストし、さらにテストする時間がないために通常発生します。

最良の状況では、専門のテストチームを雇って、徹底的なテストを実行できるようになっているでしょう。その高級なテストチームを持っていても、プロトタイプに加えるすべての修正、小さくて取るに足らない変更ごとに本当に彼らを利用できるでしょうか？ほとんどの場合、答えはノーです。この記事では、ケーキを持っても食べても良いという解決策で問題にアプローチしたいと思います。この記事では、非常に低コストでありながら非常に効果的でかなり徹底的なテストシステムをレビューします。これは、あなたが探していたコストパフォーマンスを実現します。

手動テスト対自動テスト

業界では、自動テスト設定（主に生産レベルのテスト用）を持つことがかなり一般的です。しかし、製品開発においては、一般的な習慣ではありません。上述の通り、洗練された自動テスト装置を設定するためのコストと開発時間は、高い努力を必要とします。この種のコストと努力は、大量生産または非常に洗練されたテスト構成を持つ低量生産（例えば、環境テストを何度も受ける低量の宇宙船システムなど）での生産にのみ正当化されます。世界の残りの部分にとっては、基本的で退屈な手動テストに頼ることになります。この種のテストは、ADC/DACの検証、プロトコルチェック、消費電力テストなど、さまざまな範囲に及ぶことがあります。テストの種類に関わらず、希望としては、一度か二度行えば十分で、その後はテストグループに引き渡すことができるというものです。

意図しない結果と自動化

私たちの開発中には、ハードウェアの設計/リスピンの段階や組み込みソフトウェアの開発中に、意図せず何かを壊してしまうことがあります。例えば、パッド間にはんだブリッジができたり、ドライバーコードが他のドライバーコードに影響を及ぼしてしまうことがあります。結果がどうであれ、テストが一度や二度で済むわけではないことは明らかです。問題が発生し、10回目の基板の修正後に徹底的なテストを行うことは通常非常に疲れる作業です。この問題に対する明白な答えは、自動化システムによって徹底的な回帰テストを行わせることです。しかし、資金も時間もあまりない組み込みエンジニアにとって、徹底的な自動テストシステムを開発する解決策は何でしょうか？

安価な解決策

組み込みシステムには、低コストで非常にスケーラブルかつ実用的な自動テストソリューションが存在します。完璧ではありませんが、設計エンジニアに最高の投資収益を提供します。このコンセプトは、アナログ信号を駆動し、アナログ信号を読み取り、さまざまなプロトコルのシリアルストリームを生成し、波形を分析できるシンプルなデバイスを使用することです。このような仕様を持つ低コストデバイスの例として、Analog Discovery 2があります。これは5Vデバイスですが、かなりの性能を備えています。私はこれを組み込みシステム開発のためのスイスアーミーナイフと考えています。他にも同等の製品はありますが、私のアプリケーションに特に適していると感じたデバイスです。このデバイスは、デスクトップコンピューターやラズベリーパイで動作します。また、Pythonライブラリも備えており、ユーザーが迅速にテストエグゼクティブを組み立てることを可能にします。便宜上、フル構成をdocker化し、すべてのアーキテクチャでビルドしました。

Easy, Powerful, Modern

The world’s most trusted PCB design system.

Learn More

実行例

実際の例を考えてみましょう。このリポジトリで見つけることができます。簡単のために、私たちの組み込みターゲットはArduino Duoになります。以下が私たちのフルテストセットアップの様子です：

ここでのアイデアは以下を実演することです：

• ホストコンピュータがAnalog Discovery 2に命じて、アナログ信号をArduinoに送る
• ArduinoがADCの値を読み取り、保存する
• ホストコンピュータがUART（USB）経由でADCの値を受け取る
• ホストコンピュータが、Analog Discovery 2経由で送信されたものと、Arduinoによって送信されたテレメトリが一致するかを検証する

なぜ、このようなことを自動化したいのでしょうか？ADCの近くで基板を再作業したり、ADCとインターフェースするドライバーを誰かが変更したりした場合を想定してみましょう。電源供給装置のいくつかのノブを回して単純な手動ADC読み取りを行うだけで、ハードウェア/ソフトウェアをテストするのに十分な自信がありますか？そうでない場合、なぜ自動化であらゆる順列とすべてのコーナーケースをカバーさせて、私たちがそれを行う必要がないようにしないのでしょうか？そして、念のため、同じことを100回実行してみてはどうでしょうか...単にできるからです！これはもっと洗練され複雑になる可能性があります（例えば、プロトコルテスト、ADCフィルタリングテストなど）、しかし、この記事では基本的なことだけに留めます。

Manufacturing Made Easy

Send your product to manufacturing in a click without any email threads or confusion.

Learn More

テストスクリプトはかなり基本的です。Arduino（つまり、テスト対象の組み込みデバイス）に適切なプログラムファイルがロードされ、すべてが適切に接続されていると仮定すると、コンピュータでテストスクリプトを以下のように実行します：

python -m pytest test_arduino_hil.py

これにより、Analog Discovery 2がArduinoのADCの電圧範囲をスイープし、入力電圧がADCから読み取った出力電圧と一致するかを検証します。ベンチトップ電源で手動でスイープするのではなく、スクリプトが単一のコマンドでそれを行いました。このような簡単な例では不要に思えますが、このプロセスは、回帰テストのような形でテストを組み合わせる際に大きな利益をもたらします。
これをCI/CDシステムと組み合わせることで、以下のステージが実行され、パスするのを見ることができます：

上記のステージは：

1. docker_build: 環境をビルドします。この場合、Linux PCとRaspberry PiなどのARMベースのデバイス上でdockerイメージを使用しています
2. arduino_load_test: コンパイルしてロードし、Arduinoコードが正しく動作したことを検証します。
3. arduino_hil_test: 物理的なArduino上でハードウェア・イン・ザ・ループテストを実行します。

テストセクションをより詳しく見てみると、これらのテストがGitlabによってキャプチャされ、解析されたことがわかります：

Requirements Management Made Easy

Connect design data and requirements for faster design with fewer errors

Find Out More

これで、ローカルおよびリモートで（CI/CDシステムを使用して）設計をテストするためのソフトウェアセットアップが整いました。これにより、設計エンジニアは、後でのテストやデバッグに集中する代わりに、設計に集中し続けることができます。

結論

この記事では、自動テストを使用して設計を同時におよび事後に検証するコンセプトについて検討しました。小さな修正であれ、大規模な設計変更であれ、自動回帰テストを持っていることは、意図しない結果（つまり、一つを修正して、別のものを壊す）を排除する際に大きな利点をもたらします。推奨されるプロセスは、これらのテストスクリプトを設計開発プロセスと並行して記述することです（テスト駆動開発に似ています）。これらの自動テストをCI/CDシステムと組み合わせることで、リモートターゲットでボードが動作していることを示し、いつでも、どこでも、誰でもテストできるという追加の利点が得られます。

次のPCB設計でAltiumがどのようにお手伝いできるかもっと知りたいですか？Altiumの専門家に相談するか、上位のDFM問題とその解決策についてもっと発見してください。 こちらからAltium Designerの無料トライアルをダウンロードできます。