TestStandによる確認および検証

確認および検証の最善策について説明を進める前に、まず、これらの概念の違いと、それらの概念がテストシステムにどのように適用されるのかを理解することが重要です。

検証

どのようなテストシステムを開発する場合でも、最初のステップとして、テストの要件を理解してドキュメント化します。これらの要件を定義するには、最初にテスト対象装置（UUT）の仕様を決め、UUTの欠陥を確実に検出するためのテスト要件を作成します。この時点では、要件においてUUTの不具合条件のすべてを十分に定義することが重要になります。テストシステムが当初の意図を達成することを確かめるプロセスのことを、検証（Validation）と呼びます。

検証は、システムが実際にその目的または意図を達成したかどうかを評価するプロセスです。

検証はテスト開発プロセス全体にわたって行う必要がありますが、まずは要件収集のフェーズから始めます。これは、プロジェクトのライフサイクルの早い段階で欠陥に対処する方がはるかに簡単であるためです。検証には、正式な合否テスト手順が含まれる場合もあれば、顧客、ユーザ、または患者に対して行われるユーザビリティ調査などの主観的な形式になる場合もあります。検証には多くの場合、「欠陥製品を拒否する」、「使いやすいインタフェースを備えている」といった主観的な要件が伴います。可能であれば、こうした主観的な意見を裏付けるために、当事者全員がその意図に同意するよう、より詳細な下位レベルの要件を定義する必要があります。

確認

詳細なテスト要件を作成した後、テスト開発者は、要件を網羅するテストシステムを設計し実装することができます。設計と実装が完了したら、エンジニアは、定義した要件のすべてがテストシステムで網羅されていることを確認する必要があります。テストシステムが指定した要件に正しく対応していることを確認するプロセスのことを、確認（Verification）と呼びます。

確認は、テストシステムが、設計、図面、作業指示書、またはその他の同様のガイドラインで提供される仕様に従って構築されているかどうかを判断するプロセスです。

確認テストは、製品開発のいくつかのマイルストーンで実行する必要があります。確認は、システム全体で実行することも、テストシステム内のより小さなコンポーネントに対して実行することもできます。

確認と検証の違いを説明するため、たとえば、テスト部門がテスト対象装置（UUT）の消費電流を計測するために簡単な試験装置を作成することを考えます。テストシステムでは、テスト上限としてUUTの消費電流を500 mA未満とすることを求め、このテスト上限と、UUT電源ピンの電流測定値とを比較する必要があるとします。そこでテスト開発者は、「UUTの電流がフルパワー時に500 mAを超えてはならない」という要件を定義します。次に開発者は、この測定に必要なハードウェアを備えた試験装置を設計、実装し、フルパワー供給後のUUTの電流をチェックするテストケースを作成します。

テストシステムの確認を実行するため、開発者は、システムが許容しうる再現性をもって正しく測定を実行し、電力が500 mAを超えた場合に不具合を生成することを確認します。テストシステムの動作が要件と一致すれば、確認は合格となります。

しかし、製造には故障モードが存在します。ダイオードが逆に取り付けられていると、回路の一部が起動せず、消費電流が150 mAと極端に低くなる場合があります。テストしているのは最大上限値のみのため、この問題はテストシステムによって不具合として報告されず、不具合のあるユニットが出荷される可能性があります。テストシステムは仕様に従って正しく構築されていますが、システムは達成すべき目的を果たさないため、検証には失敗します。そこで、測定値の上限と下限が定まるように（400～500 mAなど）、仕様とテストシステムを修正する必要があります。

十分に記述された仕様、図面、または作業指示書に基づいてシステムの確認を実行することは比較的簡単であり、またテスト方法も非常に単純であるため、欠陥を見つけるのは容易ですが、前の例で示したように、検証はもっと難しくなる場合があります。

影響解析

テストシステムの検証と確認が済んでシステムを実際に利用し始めてから、システムに変更や更新を加えなければならなくなることがあります。たとえば、メンテナンス、修理、またはシステムのパフォーマンスを改善または修正する試み（故障した計測器の交換、アルゴリズムや設定の変更など）が原因となって、こうした更新が必要になることがあります。システムに変更を加える際は、変更によって欠陥が引き起こされないようにするために、テストシステムのどの部分を再検証する必要があるかを理解することが重要です。これを影響解析（Impact analysis）と呼びます。 

影響解析は、テストシステムのうちどのコンポーネントが一連の変更の影響を受けるのかを判断するプロセスです。

変更によって、システムが気づかないうちに正常に動作しなくなり、製品のリコールや生産の停止といったビジネスの妨げが生じる恐れがあります。そのため、詳細な影響解析を行うことが重要です。また、変更を加えてシステムは正常に動作しても、成果やテスト結果に影響を与え、テスト済みの製品について誤った決定を下してしまう可能性もあります。変更の見逃しや検証の誤りは非常に大きなコストとなって跳ね返ってくる恐れがあります。業界によっては、不良品の出荷のために製品のリコールを強いられることがあります。FDAは、規制措置を講じる権利を留保しています。 

システムへの変更が及ぼす影響を軽減するには、テストシステムをモジュール方式で設計し、あるコンポーネントへの変更が他のコンポーネントに影響を与えないようにすることが重要です。そのためには、各コンポーネントを他のコンポーネントから完全に切り離し、それぞれについて独立した検証手順を設けることが重要です。たとえば、ハードウェアとのインタフェースとなる一連の標準機能を提供する、ハードウェア抽象化レイヤ（HAL）を導入できます。HALによって定義された機能は、残りのテストシステムとは独立して検証できます。ハードウェアに変更を加えても、変更後のHAL機能の動作が同じであることを確認できるため、影響を与えるのはHALレイヤのみになります。

検証と確認の業界標準

V&Vの主要な原則については多くの業界で明確に定義されており、医薬品適正製造基準（GMP）のような規則、またはISO-9000、FDAの21 CFR、IEEE規格などの規制によって概略が示されています。それぞれのV&Vシステムの内容は似ていますが、2つのプロセスの一般的な要件を説明するために、多少異なる用語を使用しています。具体的な要件は通常は定義されていません。このドキュメントでは、自動テストシステムのV&Vプロセスについて説明します。

FDAの21 CFRにおける医療機器に特に関連した検証要件は曖昧です。たとえば、「医療機器はユーザのニーズや使用目的に適合するように検証する必要がある」と規定した文言が含まれています。そのため、品質システムの責任者がニーズを定義し、検証テストを監督する必要があります。テストシステムの場合、検証テストを定義する方法の1つとして、たとえば、既知の障害モードを追跡し、良品と不良品のサンプルを用意して、システムによる既知の欠陥の検出に役立てる、といったシンプルなものが考えられます。もしくは、信頼できる手動のテスト手順を用いたり、新しいテストシステムの結果を検証するために別の自動化システムを取り入れたりする方法も考えられます。 

航空、製薬、医療機器などの産業に関連するような事例では、検証を極めて綿密に行う必要があります。これは、安全性、品質、またはコストについて極端なケースが検証プロセスに伴うためです。綿密なシステム検証は、定義から実行までに数週間から数か月かかることがあります。たとえば、テストシステムで16x32構成のスイッチマトリックスを使用している例では、テストエンジニアが導通テスタを使用して接続の可能なすべての組み合わせをテストし、制限のある接続がされていないことを確認する、という場合があります。また、通信システムの検証を伴う事例もそうした例の1つです。このような場合、考えられるすべてのコマンドおよびコマンドシーケンスをテストして検証する必要があります。こうした検証プロセスは極端に思われるかもしれませんが、いかなる状況においても破損、けが、または誤った結果を起こさないことが求められます。

V&Vプロセスでは、明確に定義された仕様が中心となります。検証は、いくつかの客観的な問題（市場やエンドユーザによって大まかに定義されたニーズなど）の影響を受ける場合もあります。どのようなテストシステムにおいても、適切に機能する仕様とV&Vの要件を調査してドキュメント化することが、最初の最も重要なステップとなります。仕様が具体的でなかったり、解釈や曖昧さの余地が残っていたりすると、テストシステムが完全であることの確認が困難になる恐れがあります。監査人やオブザーバが、ドキュメント化されていない設定や、誤って実装された設定を見つけた場合には、テストが中止されることがあります。仕様を注意深く適切に記述することは、問題のないV&Vプロセスを保証するのに役立ちます。

確認には、システムが何を達成しなければならないのかを管理できるように、1つまたは複数の設計ドキュメントや図面が必要になります。 これらのドキュメントや図面は、コンポーネント、アセンブリ、またはシステム全体を対象とすることが考えられます。確認の仕様やテスト方法は、十分詳細にドキュメント化し、正しいテストシステムの作成に必要となる可能な限り多くの情報を記述する必要があります。

仕様の変更が生じた場合は、それが顧客やエンジニアによる発案であっても、または学習や発見の結果によるものであっても、必ず記録します。変更指示のプロセスを利用して、変更内容とその理由を記録し、変更を正式なものにします。手順、設定、およびテスト制限を正しいドキュメントと照合した場合にのみ、確認が合格となります。 

検証テストの設計は主観的であることが多く、科学というより芸術のように思われるかもしれません。また、知恵と経験のみが検証設計の道具のように思われるかもしれませんが、要件を収集することによって、隠されたことが明らかになり、役に立つ可能性があることを忘れないでください。たとえば、他の試験装置やテスト製品について過去のパフォーマンスをレビューする、オペレータやその監督者に聞き取りをする、過去の計測データを調べるなどの手法があります。ある会社では、通常はテストシステムのインテグレータに外部委託をしていますが、各プロジェクトの詳細なレビューを行って次のプロジェクトを改善する方法を見つけ、それらのアイデアを次のプロジェクトのチェックリストに取り入れています。

TestStandはモジュール式アーキテクチャ上に構築されており、TestStandエンジン、プロセスモデル、テストコード、ユーザインタフェースなど、多数の分離されたコンポーネントを備えています。このアーキテクチャでは各コンポーネントの独立した解析が容易に行えるため、V&Vの作業の際に役立ちます。さらに、既存のテストシステムに変更を加える場合に、その影響が単一のコンポーネントに限定されることが多いため、再検証の必要性が少なくなります。

TestStandのモジュール式アーキテクチャにより、各コンポーネントを個別に確認および検証でき、テストシステム全体に与える変更の影響が軽減されます。

テストシステムの設計では、確認と検証について検討し、どのようなシステムアーキテクチャにすればこうした作業が容易になるかを検討することが重要です。次のセクションでは、V&Vを念頭に置きながらテストシステムのコンポーネントを設計する際の最善策を示します。

シーケンスファイルを設計する

テストシーケンスの開発では次の目標を念頭に置いてください。

• 機能の論理ブロックのサブシーケンスを利用して、機能をコンポーネント化する。
• ステップ間のやり取りを減らす。そうすることで、個々のステップに加えた変更がテストシステムに及ぼす影響が軽減される。

こうした目標に重点を置くことで、要件がテストコードでどのようにカバーされているかを追跡しやすくなり、個々のステップに加える変更の影響を減らすことができます。 

別々のステップを使用する場合とステップ設定を使用する場合

ステップの条件を定義するときは、その条件が複数のステップに適用されるかどうかを考慮してください。If/ElseやCaseステップを使用してロジックを実装した方が、TestStand環境では見通しが良く、拡張が可能になります。また、さまざまなオプションを実行するように修正したり、条件ごとに複数のステップを含めたりできます。ただし、テストステップとフロー制御との間に関係性が導入されます。常に単一のステップに適用されるロジックの場合は、前提条件を使用することで、ロジックとステップを単一のコンポーネントに収めることができます。
テストコードで切り替えを実装する場合も、同様のアプローチを使用します。単一のテストに適用されるルートの場合、ステップの切り替え設定を使用することで、テストコードによる切り替え機能をコンポーネント化できます。切り替えが複数のステップに影響を与える場合には、切り替えステップを使用した方がシーケンス内の見通しが良くなり、シーケンスの自己ドキュメント化が向上します。

サブシーケンスを使用してモジュール化する

関連するステップ群をカプセル化するサブシーケンスを作成できます。これにより、標準のステップ設定をコンポーネント化できると同時に、別々のステップを使用できる拡張性も加わります。こうしたシーケンスのセットを別のシーケンスファイルに含めることで、機能のライブラリとなるシーケンスファイルを効果的に作成でき、複数のテストアプリケーション間で独立して検証および共有できます。
また、テストシーケンスは、ほぼ完全に「シーケンス呼び出し」ステップで構成されている必要があり、それぞれがテストの論理グループを実装します。サブシーケンスの構成はテスト仕様にマップします。この場合、「システムはデバイスのオーディオ機能をテストする」などの高レベルの要件は、テスト内のシーケンスにマップします。一方、「最大音量は80 dBを超えてはならない」などの比較的低レベルの補足的な要件は、シーケンス内のステップにマップします。

複数ステップ間の依存関係を減らす

あるステップにおいて前のステップで取得したデータを必要とする場合は、ステップ間に依存関係を導入することもできます。PreviousStepプロパティを使用して別のステップのデータに直接アクセスすることは避け、代わりにローカル変数を使用して最初のステップのデータを保存し、その後のステップで変数にアクセスします。

また、テストを実行する前に、各ステップで必要な条件を個別に設定または確認する必要があります。たとえば、オーディオボリュームテストにおいて、あるステップに低、中、高のボリュームテストが含まれていて、次のステップでは中のボリュームで行う必要があるオーディオ品質テストを実行する、という場合は、テストを実行する前に、ボリュームが中に設定されていることを確認する必要があります。これにより、双方のテストが独立していることが保証されます。オーディオボリュームテストに変更を加えても、オーディオ品質テストには影響しません。

テストシーケンスをドキュメント化する

シーケンスファイルの明確なドキュメントを作成することは、仕様のすべての要件が十分にカバーされていることを確認するための重要な要素となります。ただし、ドキュメント内で制限値やテストパラメータなどの情報を繰り返すことは避けてください。 

ステップの名前と説明を使用して、ステップの目的をドキュメント化できます。ステップ名には、ステップの実行内容とアクションの実行理由を示しますが、ステップで定義されているパラメータ値は含めないようにします。たとえば、ステップに「待機（Wait）」という名前を付けるのではなく、「システムが起動するまで待機（Wait for system to boot）」という名前を付けます。さらに詳しい情報を名前に示す必要がある場合は、ステップの説明プロパティを使用してさらに詳細を指定します。

または、TestStandとNI Requirements Gatewayを使用して、実際のテストコードで要件がカバーされている場所を効果的に追跡することもできます。NI Requirements Gatewayを使用すると、どの要件がカバーされているのかをすばやく確認でき、要件をカバーしているステップに移動できるので、確認のプロセスをスピーディに行えます。

NI Requirements Gatewayでは、要件ドキュメント、テストシーケンス、およびテストレポート間でリンクを作成することで、すべての要件がカバーされていることを確認できます。

ステップ、シーケンス、およびシーケンスファイルで使用可能な要件フィールドを使用して、それらがカバーする要件に関する情報を提供します。これらのフィールドをNI Requirements Gatewayで使用し、要件ドキュメントとテストコード間のマッピングを作成することで、要件がカバーされている場所をすばやく確認できます。 

要件フィールドを使用して、ステップ、シーケンス、またはシーケンスファイルを、仕様ドキュメント内の特定の要件にマップします。

NI Requirements GatewayとTestStandを使用して要件を追跡する方法の詳細については、「NI Requirements GatewayとNI TestStandの組み合わせ」チュートリアルを参照してください。

独立したコードモジュールを開発する

TestStandのステップは、計測器やオートメーションハードウェアと通信するためにコードモジュールを呼び出します。コードモジュールは、LabVIEW、C++、C#などのさまざまな言語で実装できます。TestStandではステップとコードモジュールとの間に自然な境界が設けられているため、TestStandシーケンスとは独立してテストと検証ができるコードモジュールを記述すると便利です。 
コードモジュールをテストシーケンスの外部でテストできるようにするには、SequenceContextまたは他のTestStand参照を使用してデータに直接アクセスするのを避け、代わりにパラメータを介してデータをコードモジュールに渡します。終端モニタの実装など、SequenceContextの使用が必要となる場合は、TestStandに固有のコードがなくても機能できるようにコードモジュールを設計します。LabVIEWのコードモジュールでは、「参照なし」機能を使用して、SequenceContextが有効かどうかを使用前に確認できます。

独立して実行可能なコードモジュールを使用すると、コードモジュールをループ実行して入力パラメータのすべての置換を渡す試験装置を設計できます。これにより、試験装置において結果を既知の正しい結果と比較し、コードモジュールが期待どおりに動作していることを検証できます。

プラグインを使用してプロセスモデルに変更を加える

TestStandのプロセスモデルは、UUTトラッキング、レポート生成、データベースロギング、バッチテスト、並列テストなど、テスト対象装置に固有ではないテスト機能を処理します。TestStandに付属するプロセスモデルは複雑であるため、これらのモデルに変更を加えると、かなりの検証作業が必要になります。 

プロセスモデルでは、デフォルトのレポート生成およびデータベースロギング機能を実装したプラグインアーキテクチャが使用されます。このアーキテクチャを利用することで、プロセスモデルのシーケンスファイル自体に変更を加えることなく、既存のプロセスモデルの機能を拡張できます。それには、個別のプラグインシーケンスファイルに実装されるカスタムプラグインを作成します。このプラグインの動作は独立して検証できます。

プロセスモデルプラグインは、プロセスモデルファイルとは別のコンポーネントであり、個別に検証できます

モデルによるUUTシリアル番号の収集方法を変更する場合など、プロセスモデル自体の機能を直接変更する必要がある場合は、既存の機能を実装しているプロセスモデルのステップを無効にしたうえで、新しい機能に対応した別のプラグインを作成することを検討してください。こうしたアプローチを取れば、将来のカスタムの動作に加える変更をプラグインのみに限定できるため、再検証が容易になります。 

プロセスモデルやプラグインのカスタマイズ方法の詳細については、「TestStandのプロセスモデルの開発とカスタマイズに関する最善策」ドキュメントを参照してください。

テストの設定および構成を管理する

テストシステムの開発では、テストを実行するすべてのステーションにわたって、すべてのTestStandで同じ設定を行い、変更を適切に検証しない限りそれらの設定を決して変更しないことが重要です。ただし、TestStandのコンポーネントの多くは個別の設定を持っているため、変更がないことを確認するのが難しい場合があります。TestStand設定に加えて、計測器の設定をテストシステム全体で一貫させることも必要です。計測器の設定には、NI Measurement & Automation Explorer（MAX）でのNI-DAQmxの設定や、デバイスのGPIBおよびCOM設定などが含まれる場合があります。これらの設定は非常に数が多く、検証テストの設計を難しくします。

設定が正しいことを確認する方法の1つとして、テストシーケンスでプログラムを通じて設定を行ったうえで、それぞれの設定をクエリし、計測器やプログラムにより設定が受け入れられたことを確認します。設定をクエリできない場合は、設定が保存されている場所を見つけ、テキスト、INI、またはXMLファイルから設定を読み取ります。TestStandの外部にある項目については、システムでそれらの状態を確認、記録し、管理下に置くことができます。

ソースコード管理ツールを使用してファイルを管理する

設定を管理するもう1つの方法として、設定が含まれているファイルを厳密に管理することができます。すべてのTestStand設定を保存している構成ファイルは、 <TestStand Application Data>\Cfgディレクトリに格納されています。それ以外の設定の設定ファイルが格納されている場所については、製品固有のドキュメントを参照してください。
テストシステムのファイルを監視、管理、保存する方法として、Subversion、Perforce、Microsoft Visual Source Safeなどのソースコード管理（SCC）プログラムが業界で普及しています。これらのプログラムの多くはMicrosoft SCCのインタフェースに準拠するように設計されており、TestStandやLabVIEWの中から使用できます。場合によっては、ファイルを保存するために、一時的にファイルの所有権を取得して、変更をドキュメント化しないとファイルを変更できないことがあります。こうしたプログラムでは多くの場合、確認の簡素化を図るために、どのファイルが変更されたのかが通知されるほか、古いファイルと新しいファイルを解析して変更部分を強調表示することができます。

また、ファイルのチェックサムを実行して、設定ファイルが検証済みの状態から変更されていないことを確認することもできます。このアプローチを利用する場合は、ファイルのチェックサムと、検証済みのファイル値で計算したチェックサムとを比較し、それらが一致しない場合にテストの不合格を生成するステップを追加できます。  

テストシステムに加えて、テストを裏付けるすべてのハードウェアとソフトウェアが既知の検証済みの状態であることを確認することが重要です。このセクションでは、システム状態を維持するための手法と、必要に応じて変更を適用する方法について説明します。

ハードウェア構成を管理する

システムについてだけでなく、個別のテストについても、計測器を適切に選択、インストール、プログラム、および構成する必要があります。たとえば、デジタルマルチメータ（DMM）やオシロスコープには、通信や信号集録を正しく行うために構成するオプションがいくつかあり、それらについて、テストシステムの完成時、および将来のハードウェアの変更時に確認と検証を行う必要があります。

ハードウェアのやり取りを管理するためのハードウェア抽象化レイヤ（HAL）を作成すると、テストシステムのハードウェアに変更を加えた際に必要な再検証を減らすのに役立ちます。HALを使用すると、テストシーケンスにおいてデバイスに固有のコードモジュールを利用するのではなく、テストシーケンスから測定タイプや計測器特有のドライバを分離することができます。通常、テスト手順は特定の計測器を基に定義されるのではなく、計測器のタイプ（電源、デジタルマルチメータ（DMM）、アナログ出力、リレーなど）を基に定義されます。そのため、抽象化レイヤを利用することで、新しい計測器や要件に対するテストシーケンスの適応度が高まります。HALを導入すると、新しいハードウェアを検証する際、テストシステム全体を完全にテストする必要がなくなり、一連のテストケースでHALの機能から以前のハードウェアと同じ出力が生成されることを確認するだけで済みます。HALの使用の詳細については、「テストシステム構築の基礎:ハードウェアと計測方法を抽象化するソフトウェアレイヤ」を参照してください。

また、ハードウェアを実行時に検証することもお勧めします。実行時に設定やその他の係数を読み取って保存すれば、ソフトウェアと共に検証を必要とする項目について、それらが意図したとおりに構成され動作するとみなすことができます。たとえば、TestStandステップで計測器のキャリブレーション日をクエリしてキャリブレーションが最新であることを確認したり、COMポートに接続されている計測器のモデル番号やシリアル番号を確認して計測器がまだ交換されていないことを確認したりできます。こうした考慮事項を念頭に置きながら、テストシーケンスを設計し、場合によっては計測器を購入することで、V&Vプロセスの簡素化に役立てることができます。

ハードウェアの変更の必要性が予想される場合は、V&Vプロセスで変更することを検討する必要があります。計測器に障害が発生し、メーカとモデルが同じ別の計測器を挿入する場合は、正常な動作を確認するために何を実行する必要があるかを検討し、変更が正常に行われたことを確認するためのテストを設計します。IVI（Interchangeable Virtual Instrument）のドライバやインタフェースを計測器のセットアップに使用すると、メーカやモデルが同じ2台の計測器間で、またはメーカやモデルが異なる2台の計測器間で、移行の簡素化がしやすくなります。

ソフトウェア構成を管理する

テストシステムを保守する際は、新機能が利用可能になったときにそれらを活用できるように、LabVIEW、TestStand、またはその他のプログラムのアップグレードを検討する必要があります。こうしたソフトウェアのアップグレードは、いつでも再検証や再確認を行うきっかけになります。アップグレードの可能性を探ることは、投資収益率（ROI）の実践例と捉えることができます。たとえば、効率化された開発インタフェースを入手するために、システムのデプロイ後にではなく開発中にアップグレードを行うことが考えられます。ただし、最近のTestStandのアップグレードにおける場合と同様に、実行速度が向上するとテスト時間が短縮され、スループットが向上し、収益が増加する可能性があります。どちらの場合も再検証のコストが決定要因になりますが、このコストはROIの向上にもつながるため、費用と労力に見合うだけの価値があります。通常は、ソフトウェアの必要な検証回数を最小限に抑えるために、複数のソフトウェアアップグレードを一度に行います。

テストシステムで一貫したソフトウェアセットを維持するため、検証済みのシステムからベースイメージを作成し、新しいテストステーションのセットアップ時にこのイメージを使用することを検討してください。ただし、イメージを使用する場合でも、ソフトウェアの更新が行われないようにする必要があります。ナショナルインスツルメンツのソフトウェアの場合は、NI更新サービスが更新プログラムを自動的にインストールしないように構成されていることを確認してください。デフォルトでは、ほとんどのコンピュータでMicrosoftの更新プログラムが自動的に実行されます。Sun、Apple、Adobeなどの他の企業でも、Webベースの自動更新を使用しています。V&Vプロセスの対象となるシステムではすべて、自動の変更やアップグレードを無効にする必要があります。自動更新によって生じる変更は予測不能であり、動作や設定に未知の影響を与える可能性があります。 

貴社のIT部門で、ウイルススキャンソフトウェアの使用、スクリーンセーバなどのセキュリティポリシーの設定、必要に応じたパッチやアップグレードのインストールなどについて、社内のコンピュータを管理する一般的なポリシーを設けている場合があるかもしれません。製造部門はIT部門と連携して、それらのポリシーには手を付けずに、TestStandシステムの管理をしやすくする必要があります。貴社のコンピュータに特に影響を与える項目は何かを調べる必要がありますが、ウイルススキャナの削除、スクリーンセーバの無効化、会社全体にわたるアップグレードやパッチの適用除外といったニーズが、ITのポリシーとまったく異なる場合があるかもしれません。

NI TestStand開発者向けのトピックをカバーする、TestStand上級アーキテクチャシリーズの追加ドキュメントを表示するには、ここをクリックしてください。