​検証テストシステムを構築するアプローチを標準化して効率の向上とリスク削減を実現する

​テストシステムに関連する効率の向上について説明する前に、現在の私たちの状況を明らかにしておく必要があります。多くの場合、V&Vテストチームはまったく異なる製品やバリエーションをテストする必要があります。そのため、多様な要件や仕様を持つ製品をテストすることのできる新しいテスタを構築する準備を整えておく必要があります。新しい製品は、デバイス自体を制御するソフトウェアを使用して構築される可能性があります。真のインダストリアルIoT (IIoT) のスタイルでは、製品が情報を収集してネットワークにパブリッシュします。古い製品は、電気的機能や機械的機能をベースに構築されたり、電気コンポーネントをまったく使わずに単に機械的に構築されたりする可能性があります。 

最終的には、デバイスで最先端、最新鋭のテクノロジを使用しているかどうかや、実証済みの真の電気的または機械工学的設計に基づいているかどうかは重要ではありません。すべての製品について、製造にリリースする前にV&Vで検証と妥当性確認を行う必要があります。V&Vでのテストの実施にどのくらいの時間を利用できるかは、いくつかの要因に左右されます。市場の時間枠に対応する必要がありますか。設計チームによるスケジュールの遅れがあるでしょうか。V&Vテストによって設計の問題が明らかになった場合は、おそらくそれが原因でボードの再設計やリスピンが生じ、タイムラインが数か月ずれることになります。こうした納期短縮のさまざまなプレッシャーによって、品質よりもリスクを優先せざるを得なくなり、本来テスト計画で予定されていたテストステップが見送られます。  

イノベーションのスピードは加速し続ける必要があり、実際に加速し続けています。しかし、テストチームが利用できるリソースは同じままであるか、減少さえしています。残念ながら、この問題は今に始まったことではありません。このことが依然として最大の要因の1つとなって、私たちは結局受け身になり、緊急対応的にテスタを構築せざるを得なくなっています。 

そうした状況を改め、プロアクティブになるためには、現在のシステム構築、管理、保守の方法を見直す必要があります。受け身的なテストグループに見られる最大の兆候の1つは、多数の「カスタム」テストシステムやテスト装置が存在することです。別の言い方をすれば、セットアップ間での装置の再利用や転用は複雑で時間がかかるために行われていません。もう1つの兆候は、「すでに何度も構築した」テスタが存在することです。 テストエンジニア全員が幅広いスキルセットを身に着けているのであれば、互いに十分補い合えるかもしれませんが、最初に構築を担当した人が持ち場を離れた場合は、現在の状況の把握に時間を費やすよりもテスタを再構築した方が早いということもあります。 

組織がこうした状況に慣れてしまっている場合もありますが、そのような組織には標準化の機会が存在します。標準化によって、プロアクティブに一歩近づくことができます。

標準のアプローチには、新しいテスタの立ち上げからフリートの維持に至るまで、数々のメリットがあります。

• 明快さが促進され、個々のテストシステムの基本的な仕組みを共通して理解できるようになります。
• チームの誰もが、すべてのシステムでコードを再利用したり装置を転用したりできるようになります。 
• 同じテスタを何度も構築しなければならないリスクが軽減され、チーム全体の効率が高まります。
• カスタムのテスタを構築したチームメンバーが社内外の他の役割に移動してしまう際のリスクが軽減されます。
• 新しいテスタを立ち上げるスピードが速まります。長期的には、同じ基本的なコンポーネントを何度も開発する必要がなくなり、チームとしての基盤が整います。

高次のレベルでは、標準のアプローチによってチームの効率を高めることができますが、もちろん他にも考慮すべきことがあります。それらの考慮事項は予想されるとおり、ハードウェアとソフトウェアの2つのカテゴリに分けられます。テストシステムの標準化を成功させるために、その取り組みの開始方法と必要な考慮事項について見ていきましょう。

​テスタを見渡してみると、効率を高めるために標準化を必要とする一方で、数多くのさまざまなシステムについて考慮する必要があることに気づくかもしれません。

• 開ループシステムであるテストベンチでは、セットポイントを作成し、デバイスからの出力を特定の時間間隔にわたって低いサンプルレートで測定し、記録するだけで済みます。
• 組込ソフトウェアを必要とするデバイスでは、製品がすべてのシナリオで期待どおりに応答することを検証するために、HILによる閉ループ制御システムでリアルタイムにテストを行う必要があります。
• これら2つの選択肢の中間にあるものについては、業界や注力分野にもよりますが、多くの場合、さまざまなテストシステムが製品の検証と妥当性確認に必要となります。

ハードウェアに関する考慮事項

ハードウェアの観点から見た場合、テストシステムの効率における重要な要素となるのは、柔軟性、拡張性、およびアプローチです。 

柔軟性  

V&Vテストの実行対象となる複雑さのレベルは、ある特定の範囲に及びます。ある事例では、ユーザがテストを制御でき、必要に応じてテストの開始と停止ができる、開ループの制御および測定システムが必要かもしれません。また別の事例では、HIL/組込ソフトウェアをテストするために非常に複雑な自動システムが必要になることもあるでしょう。 

効率の向上を実現するためには、複雑さの範囲に即したニーズを考慮することが必要です。複雑さの両端のニーズに対応できるアプローチを選ぶ必要があります。このことは、新たなテクノロジが開発されて新たな測定タイプのニーズが生じるにつれて、いっそう重要になります。 

標準のアプローチには、既存のさまざまな測定タイプを組み込み、テクノロジの進歩に合わせて新機能を継続的に追加できる柔軟性が必要になります。これにより、システムを最高の形で準備できるようになり、新たなテクノロジが登場するたびにV&Vテストチームが新しいアプローチを改めて学習する必要がなくなります。その結果、効率が向上し、新しいさまざまな装置の統合に伴う障害が取り払われます。

拡張性 

製品の機能が5年後も存続するかどうかを知ることは不可能です。まして10年後ではなおさらです。しかし、装置にはこのような長期にわたる持続性が期待されることが多くあります。そのため、特にV&Vテストチームにとって拡張性は極めて重要になります。 

私たちが使用する装置の一部は、最も高価であるだけでなく、統合が複雑になる場合もあります。たとえば、2台ではなく8台のデバイスをテストできるようにテストベンチを拡張するといった単純な拡張であっても、拡張が容易で、追加したチャンネルの迅速な統合や同期が可能なプラットフォームを選択していなければ、より多くのデバイスを扱えるようにスケールアップすることが難しくなる可能性があります。 

V&Vにおいては、システムの構築対象となるプラットフォームとそのアプローチを選択するにあたって、システムの拡張性を考慮する必要があります。適切なアプローチを選び、より多くのチャンネルでシステムを迅速に適応、統合、拡張することができれば、効率を高めることができます。このことは戦略における重要な要素とする必要があります。その結果、初期段階ではコストを節約することができ、長期的には必要に応じて自信を持ってシステムを容易にスケールできるようになります。

アプローチ 

ここまで、標準化によって転用や再利用が容易になることを説明しましたが、余裕を持たせることもまた重要です。タイムラインが短縮された場合、テストの1週間前に、あるいは数分前に、デバイスにキャリブレーションが必要なことや、デバイスが意図したとおりに機能しないことを見つけるのは困難です。新しいボードを入手するために緊急対応しなければならず、テストを見送る可能性もあります。ハードウェアのアプローチとプラットフォームを標準化するにあたっては、余裕のある状態で稼働時間が確保されるように、コストとプラットフォームアプローチとの間で適切なバランスを見つける必要があります。つまり、高品質で高確度の装置や機能を幅広く選ぶことが必要になります。 

すべてのテストで必要なあらゆる機能を提供するアプローチやプラットフォームが常に見つかるとは限りません。そのような場合には、同期、タイミング、スループットの要件の有無を考慮し、さまざまなタイプの装置を1つのシステムに統合することが容易か複雑かを判断することになります。プラットフォームがオープンであるほど、効率やタイムラインを損なわずに他の装置を統合できるほどの十分な柔軟性が得られる可能性が高くなります。

標準化で最も大きなリスクとなるのは、スケールができず将来の要件に対応できなくなるアプローチやプラットフォームを選んでしまうことです。最終的には、チームにとって最適な戦略を選ぶ必要があります。多くの場合、標準化に取りかかる前に徹底的な評価を実施することをお勧めします。 

ソフトウェアに関する考慮事項

ハードウェアに関する考慮事項と同様に、ソフトウェアのアプローチについて標準化を行う際も、テストの複雑さが重要になります。複雑さの範囲の下限では、ハードウェアの出力の制御や入力の測定が可能なターンキーソフトウェアがまさに必要になる場合があります。このタイプのソフトウェアでは、テストエンジニアは適切なハードウェアの実装とテストベンチの立ち上げの迅速化に専念することができます。しかし、スケールの範囲がある点を超えると、テストが複雑になり、さまざまな内部依存関係を持つテストルーチンをひととおり実行できる自動テスタを構築する必要が生じ、それにはより多くの時間がかかります。 

複雑な製品のテストで多数の異なるシナリオを実行する必要がある場合には、すべてのテストを手動で実行するには時間がかかりすぎるというだけの理由で、自動システムの構築に目が向けられます。テストプログラムやルーチンの記述は、今ではテストエンジニアにとって不可欠な仕事となっています。チームのスキルセットを考慮する際、たいていは、さまざまなタイプのソフトウェアやプログラミング言語について、習熟度のレベルが異なることに気づきます。しかし、すでに述べたように、共通のアプローチがなければテストシステムの管理や保守は時間の経過とともに困難になるか、不可能になります。 

ソフトウェアのアプローチの検討を始めるにあたっては、フレームワークという言葉を何度も耳にすることでしょう。拡張性を念頭に置いて構築されたオープンなフレームワークを整備すれば、新しいテスタを構築するたびにチーム全員が同じ基本的なコンポーネントを構築せずに済みます。こうした同じ基本的なコンポーネントをテスタごとに構築していることは見落とされがちです。これは、ソフトウェアの中に「隠れている」ためです。ただしこの点は、ソフトウェアの検討にあたって実際に効率が向上する部分でもあります。 

理想的なソフトウェアのアプローチでは、複雑さの範囲の下限において、コードを開発することなく迅速なセンサ構成やデータロギングをサポートする必要があります。開発が必要な場合であっても、エンジニアに適したフレームワークを提供するオープンなアプローチが求められます。テストエンジニアは、より迅速にテストを開発、デバッグ、デプロイできる必要があり、複数の異なる言語で記述されたテストコードをフレームワークに直接統合する必要があります。そのようなケースではテストを自動化しようとする可能性が高まるため、さまざまなタイプのハードウェアをどの程度容易に統合できるかを考慮する必要もあります。統合が容易であれば、フレームワークによって必要なハードウェアを使用できる能力が制限されてしまうことがなくなります。 

ハードウェアとソフトウェアに関する考慮事項を一致させる必要性

標準化では総じて、効率の向上とリスクの軽減がテーマとなります。ソフトウェア側とハードウェア側のすべてを確実に連携させ、シームレスに統合できるようにする必要があります。選択したハードウェアのドライバが、選択したソフトウェアのアプローチをサポートしていなければ、必要な効率の向上は望めません。同様に、選択したソフトウェアのアプローチが十分にオープンでなく、異なる言語間での再作業が必要になり、コードを実行するラッパーの作成が必要になった場合には、新しい計測器を追加する際に保守や管理が非常に複雑になります。最終的には、双方の面で最適なアプローチを見出し、統合が容易で拡張性のあるソフトウェアとハードウェアのプラットフォームを標準化する必要があります。 

標準化はシステムだけにとどまるものではありません。プロセスやデータもまた重要です。標準化によって適切なデータが得られれば、製品の性能に関してだけでなく、テスト環境全体に関する貴重な洞察を得ることができます。プロセスの観点から言えば、現在どこでボトルネックが発生しているか、どのワークフローを改善できるか、あるいは現在手動で実行しているステップのうちどれを自動化できるかを、特定することができます。 

すでに説明したように、システムの構築、管理、保守の方法を標準化することで、数多くの効率向上を実現できます。NIのソフトウェアとハードウェアのソリューションは、高品質、オープン性、拡張性、柔軟性を念頭に開発されているため、ソフトウェアまたはハードウェアのアプローチで妥協が必要だと思われるような場合でも、妥協をせずに既存の基盤を利用して、さらに短時間でフレームワークや標準のアプローチを構築できます。チームメンバー全員のスキルセットや習熟度に応じて構築を行い、生産性を加速する共通のフレームワークに集結させることで、標準のアプローチの実装がよりシームレスに行えます。