TestStand를 사용하여 검증 및 확인

검증 및 확인을 위한 모범 사례를 설명하기 전에, 먼저 이러한 개념의 차이와 이것이 테스트 시스템에 어떻게 적용되는지를 이해하는 것이 중요합니다.

검증

테스트 시스템을 개발할 때 첫 번째 단계는 테스트의 요구 사항을 이해하고 문서화하는 것입니다. 이러한 요구 사항을 정의하려면, 테스트 대상 장치(UUT)의 스펙에서 시작하여, UUT에 결함이 있는지 확인하기 위한 테스트 요구 사항을 개발해야 합니다. 이 개발 시점에서는 UUT에 대한 모든 고장 조건을 요구 사항이 완전히 정의하는지 확인하는 것이 중요합니다. 테스트 시스템이 원래의 목적을 달성하는지 확인하는 프로세스를 검증이라고 합니다.

검증은 시스템이 실제로 목적이나 의도를 달성하는지 평가하는 프로세스입니다.

검증은 테스트 개발 프로세스 전반에 걸쳐 이루어져야 합니다. 하지만 모든 결함은 프로젝트 라이프 사이클 초기에 해결하는 게 쉽기 때문에 요구 사항 수집 단계에서 시작하는 게 좋습니다. 검증에는 공식적인 통과/실패 테스트 절차가 포함될 수 있으며, 고객, 사용자 또는 환자와 함께 수행되는 주관적인 형태의 사용적합성 연구가 포함될 수 있습니다. 검증에는 종종 "결함 있는 제품 거부" 또는 "사용하기 쉬운 인터페이스"와 같은 일부 주관적 요구 사항이 포함됩니다. 이러한 주관적인 진술을 뒷받침하기 위해, 최대한 상세한 하위 수준의 요구 사항을 정의하여 모든 당사자가 의도된 내용에 동의하는지 확인해야 합니다.

확인

상세한 테스트 요구 사항이 개발되면, 테스트 개발자는 그 요구 사항에 해당하는 테스트 시스템을 디자인하고 구현할 수 있습니다. 일단 완료되면, 엔지니어는 테스트 시스템이 정의된 요구 사항을 모두 충족하는지 확인해야 합니다. 테스트 시스템이 지정된 요구 사항을 제대로 해결하는지 살펴보는 프로세스를 확인이라고 합니다.

확인은 디자인, 도면, 작업명세서 또는 기타 유사한 지침에서 제공하는 스펙에 따라 테스트 시스템 구축 여부를 결정하는 프로세스입니다.

확인 테스트는 제품 개발의 몇 가지 이정표에서 수행해야 합니다. 확인은 전체 시스템 또는 테스트 시스템의 더 작은 구성 요소에 대해 수행될 수 있습니다.

검증과 확인의 차이를 설명하기 위해, 테스트 부서가 테스트 대상 장치(UUT)의 전류 소비량을 측정하기 위한 간단한 테스트 픽스처를 구축한다고 가정해 봅시다. 테스트 시스템은 UUT 전원 핀에 대한 전류 측정을 UUT가 500mA 미만을 소비해야 하는 테스트 한계와 비교해야 합니다. 이를 해결하기 위해 테스트 개발자는 "UUT 전류가 최대 전력에서 500mA를 초과하지 않아야 한다"는 요구 사항을 정의합니다. 개발자는 이 측정을 위해 필요한 하드웨어로 테스트 픽스처를 디자인 및 구현하고, 최대 전원 공급 후 UUT의 전류를 확인하는 테스트 케이스를 만듭니다.

테스트 시스템의 확인을 수행하기 위해 개발자는 시스템이 허용 가능한 반복성으로 측정을 올바르게 수행하는지 확인하고, 전원이 500mA를 초과할 경우 고장을 발생시킵니다. 테스트 시스템 동작이 요구 사항과 일치하는 경우 확인이 통과됩니다.

그러나 제조 시 고장 모드가 존재하며, 다이오드가 역방향으로 설치되면 회로의 일부 부품이 활성화되지 않으므로, 지나치게 낮은 전류(150mA) 소비로 이어질 수 있습니다. 테스트 시스템은 이 문제를 실패로 보고하지 않습니다. 최대 한계값만 테스트하고 고장난 장치는 운송될 수 있기 때문입니다. 테스트 시스템이 규격에 따라 올바르게 구축되었지만, 시스템은 위임된 목적을 달성하지 못하여 검증에 실패합니다. 스펙과 테스트 시스템은 400-500mA와 같은 상한과 하한 측정 한계를 포함하도록 수정해야 합니다.

시스템 검증은 잘 작성된 스펙이나 도면, 작업명세서에 근거해 비교적 쉽게 수행할 수 있으며, 테스트 방법은 매우 간단하여 결함을 쉽게 찾을 수 있지만, 앞의 예에서 보듯이 검증은 더욱 까다로울 수 있습니다.

영향 분석

테스트 시스템의 검증 및 확인이 완료되고 시스템을 사용한 후에는, 시스템을 변경하거나 업데이트해야 할 수 있습니다. 이러한 업데이트는 고장난 계측기를 교체하거나 알고리즘 및 설정을 수정하는 등 시스템의 성능을 개선하거나 수정하려는 시도, 또는 유지보수나 수리에 기인할 수 있습니다. 시스템을 변경할 때 변경사항으로 인해 결함(영향 분석)이 발생하지 않도록 테스트 시스템의 어떤 부분을 재검증해야 하는지 파악해야 합니다. 

영향 분석은 테스트 시스템의 사용자가 수행하는 일련의 변경에 의해 어떤 구성요소가 영향을 받는지를 결정하는 프로세스입니다.

변경으로 인해 시스템이 눈에 띄지 않는 방식으로 부적절하게 작동하고 제품 리콜, 생산 중단 또는 기타 비즈니스 간섭을 초래할 수 있으므로, 상세한 영향 분석을 수행하는 것이 중요합니다. 시스템은 제대로 작동하지만, 변경이 결과 또는 테스트 결과에 영향을 미치고 테스트 제품에 관한 잘못된 결정을 야기할 수 있습니다. 변경 누락 또는 잘못된 검증이 초래하는 비용은 매우 클 수 있습니다. 일부 업계에서는 결함 있는 제품을 출하하면 제품 리콜이 발생할 수 있습니다. FDA는 규제 조치를 취할 권리가 있습니다. 

시스템에 대한 변경의 영향을 완화하기 위해서는 구성요소 변경이 다른 구성요소에 영향을 미치지 않도록 모듈식으로 테스트 시스템을 디자인하는 것이 중요합니다. 이를 위해서는 각 구성요소가 다른 구성요소와 완전히 분리되었는지, 그리고 독립적 검증을 위한 절차가 있는지 확인하는 것이 중요합니다. 예를 들어 하드웨어와 인터페이스하는 표준 기능 집합을 제공하는 하드웨어 추상화 계층(HAL)을 도입할 수 있습니다. HAL에 의해 정의된 기능은 나머지 테스트 시스템과는 별도로 검증될 수 있습니다. 하드웨어를 변경하면, 변경 후 HAL 기능의 동작이 동일한지 확인할 수 있으므로, HAL 계층에만 영향을 미치게 됩니다.

검증 및 확인 산업 표준

V&V의 관리 원칙은 많은 산업에 대응하여 잘 정의되어 있으며, 모범 제조 관행(GMP)과 같은 분야 또는 ISO-9000, FDA의 21 CFR 또는 IEEE 표준과 같은 규정에 요약되어 있습니다. 각 V&V 시스템은 서로 유사하지만, 두 프로세스의 일반적인 요구 사항을 설명하기 위해 약간 다른 용어를 사용합니다. 특정 요구 사항은 일반적으로 정의되지 않습니다. 이 문서에서는 자동화된 테스트 시스템을 위한 V&V 프로세스를 살펴봅니다.

FDA 21 CFR의 의료기기와 관련된 검증 요구사항은 모호하며, 의료기기가 사용자 요구와 의도된 용도에 부합하도록 검증되어야 함을 명시하는 문구를 포함하므로, 품질 시스템 관리자는 반드시 필요성을 정의하고 검증 테스트를 감독해야 합니다. 테스트 시스템의 경우, 검증 테스트를 정의하는 방법이, 알려진 고장 모드를 추적하고, 알려진 결함을 감지하는 데 도움이 되는 좋은 제품 샘플과 나쁜 제품 샘플을 시스템에 제공하는 것보다 간단할 수 있습니다. 신뢰할 수 있는 수동 테스트 절차를 사용하거나 새로운 테스트 시스템의 결과를 검증하기 위해 다른 자동화된 시스템을 포함하는 것도 좋은 방법입니다. 

검증 프로세스는 안전성, 품질 또는 비용 문제와 직결되므로, 항공, 의약품 및 의료기기 등이 관련된 경우 매우 철저한 검증이 이루어져야 합니다. 철저한 시스템 검증의 경우, 정의와 수행에만 몇 주 또는 몇 달이 걸릴 수 있습니다. 예를 들어, 테스트 시스템이 16x32 설정의 스위치 매트릭스를 사용하는 경우, 테스트 엔지니어는 연속성 테스터를 사용하여 모든 연결 가능 조합을 테스트하고 제한된 연결이 이루어지는 일이 없는지 확인할 수 있습니다. 가능한 모든 명령과 명령의 시퀀스를 테스트하고 검증해야 하는 통신 시스템의 검증도 좋은 예입니다. 이러한 검증 프로세스가 극단적으로 보일 수 있지만, 어떤 상황에서도 손상, 부상 또는 잘못된 결과가 발생하지 않도록 하는 것이 중요합니다.

V&V 프로세스는 잘 정의된 스펙에 초점을 맞춥니다. 검증은 시장이나 최종 사용자의 느슨하게 정의된 요구와 같은 일부 객관적 문제에 맞닥뜨릴 수 있습니다. 모든 테스트 시스템에 있어 가장 중요한 첫 단계는 우수한 작업 스펙과 V&V 요구 사항을 연구하고 문서화하는 것입니다. 스펙이 구체적이지 않거나 해석의 여지가 있거나 모호한 경우, 테스트 시스템이 완성되었는지 확인하는 것이 어려울 수 있습니다. 감사자 또는 관찰자가 설정 내용이 문서화되지 않았거나 잘못 구현되었다는 사실을 알게 된 경우, 테스트가 중단될 수 있습니다. 주의 깊게 잘 작성된 스펙은 손 쉬운 V&V 프로세스를 보장하는 데 도움이 될 수 있습니다.

확인에는 하나 이상의 디자인 문서 또는 도면이 필요합니다. 이는 시스템이 달성해야 하는 것을 관리하기 위함입니다.  문서와 도면은 구성요소, 어셈블리 또는 전체 시스템을 포함할 수 있습니다. 확인을 위한 스펙과 테스트 방법은 정확한 테스트 시스템을 만드는 데 필요한 만큼의 정보를 포함하는 매우 상세한 문서여야 합니다.

고객, 엔지니어가 고안한 스펙 또는 학습과 발견의 결과로 발생한 스펙의 변경을 반드시 기록하십시오. 변경 주문 프로세스를 사용하여 변경 사항과 이유를 기록하고 변경 사항을 공식화하십시오. 지침, 설정 및 테스트 한계가 올바른 문서와 일치하는 경우에만 확인이 통과됩니다. 

검증 테스트 디자인은 대체로 주관적이라서, 과학보다는 예술처럼 보일 수 있습니다. 지혜와 경험이 검증 디자인을 위한 유일한 도구로 보일 수 있지만, 요구 사항을 수집하는 것은 의미 심장하고 유용할 수 있다는 점을 기억하십시오. 기법에는 다른 테스트 픽스처나 제품의 과거 성능 검토, 운영자와 그 감독자의 면담, 과거 측정 데이터 연구 등이 포함됩니다. 테스트 시스템 통합업체에 아웃소싱하는 한 회사는 다음 프로젝트를 더 좋게 만드는 방법을 찾기 위해 각 프로젝트에 대한 상세한 검토를 수행하고, 다음 프로젝트의 체크리스트에 그 아이디어를 적용합니다.

TestStand는 모듈식 아키텍처를 기반으로 구축되며, TestStand 엔진, 프로세스 모델, 테스트 코드 및 사용자 인터페이스를 포함한 많은 디커플링된 구성요소가 있습니다. 이 아키텍처는 V&V 노력에 이롭습니다. 각 구성요소들이 더 쉽게 독립적으로 분석될 수 있기 때문입니다. 또한 기존 테스트 시스템이 변경되면 재검증의 필요성이 줄어듭니다. 그 영향이 단일 구성요소로 제한되는 경우가 많기 때문입니다.

TestStand의 모듈식 구조를 통하여 각 구성요소를 개별적으로 검증 및 확인할 수 있으며, 변경사항이 테스트 시스템 전체에 미치는 영향을 줄일 수 있습니다.

테스트 시스템을 디자인할 때는 검증과 확인을 고려해야 하며, 어떠한 시스템을 구축해야 이러한 노력을 용이하게 할 수 있는지도 고려해야 합니다. 다음 섹션에서는 V&V를 염두에 두고 테스트 시스템의 구성요소를 디자인하기 위한 모범 사례를 제공합니다.

시퀀스 파일 디자인

테스트 시퀀스를 개발할 때는 다음 목표를 염두에 두십시오.

• 기능의 논리적 블록에 대해 서브시퀀스를 활용하여 기능을 구성합니다.
• 단계 간 상호 작용을 줄여 개별 단계에 대한 변경 사항이 테스트 시스템에 미치는 영향을 줄입니다.

이러한 목표에 초점을 맞추면 요구 사항이 테스트 코드에 어떻게 적용되는지 더 잘 추적할 수 있고, 개별 단계에 미치는 변경의 영향을 줄일 수 있습니다.  

별도의 단계와 단계 설정 사용

단계에 대한 조건을 정의할 때 해당 조건이 여러 단계에 적용되는지 여부를 고려하십시오. If/Else 또는 Case 단계를 사용하여 논리를 구현하는 편이 TestStand 환경에서 가시성이 높고, 확장성도 좋습니다. 또한, 다양한 옵션을 실행하고 조건당 두 단계 이상을 포함하도록 수정할 수 있습니다. 그러나 그들은 테스트 단계와 흐름 제어 사이의 관계를 도입합니다. 항상 하나의 단계에 적용되는 논리의 경우, 전제 조건을 사용하면 논리와 단계를 단일 구성요소에 포함할 수 있습니다.
테스트 코드 전환을 구현할 때도 이와 유사한 접근 방식을 사용하십시오. 단일 테스트에 적용되는 경로의 경우, 단계의 전환 설정을 사용하면 테스트 코드를 통해 전환 기능을 구성 요소화할 수 있습니다. 여러 단계에 영향을 미치는 전환의 경우, 전환 단계를 사용하는 편이 시퀀스에서 가시성이 높으며, 이로써 시퀀스가 보다 효과적으로 자체 문서화됩니다.

서브시퀀스를 사용하여 모듈화

내장된 단계 설정의 구성요소화의 이점을 별도의 단계를 사용할 수 있는 확장성과 결합하기 위해, 관련 단계 집합을 캡슐화하는 서브시퀀스를 만들 수 있습니다. 별도의 시퀀스 파일에 이러한 시퀀스 집합을 포함함으로써, 여러 테스트 어플리케이션 간에 독립적으로 검증되고 공유할 수 있는 기능 라이브러리인 시퀀스 파일을 효과적으로 만들 수 있습니다.
또한 테스트 시퀀스는 거의 전적으로 시퀀스 호출 단계로 구성되어야 합니다. 각 단계는 테스트의 논리적 그룹화를 구현합니다. 서브시퀀스의 구성은 테스트 스펙에 매핑되어야 합니다. 즉, "시스템은 디바이스의 오디오 기능을 테스트해야 합니다"와 같은 높은 수준의 요구 사항은 테스트의 시퀀스에 매핑되어야 하고, "최대 음량은 80dB를 초과하지 않아야 합니다"와 같은 낮은 수준의 지원 요구 사항은 시퀀스 내의 단계에 매핑되어야 합니다.

여러 단계 간의 종속성 감소

또한 어떤 단계가 이전 단계에서 얻은 데이터를 필요로 하는 경우, 단계 간 종속성을 도입할 수도 있습니다. 이전 단계 속성을 사용하여 다른 단계의 데이터에 직접 액세스하는 대신, 로컬 변수를 사용하여 첫 번째 단계부터 데이터를 저장한 다음, 이후 단계에서 변수에 액세스합니다.

또한 테스트를 실행하기 전에 각 단계가 필요한 조건을 독립적으로 설정하거나 검증하는지 확인해야 합니다. 예를 들어, 오디오 볼륨 테스트 단계에 저음, 중음 및 고음량의 볼륨 테스트가 포함되어 있고, 이후 단계에서는 중간 볼륨에서 수행해야 하는 오디오 품질 테스트를 수행하는 경우, 테스트를 수행하기 전에 볼륨이 중간 볼륨으로 설정되어 있는지 확인하십시오. 이렇게 하면 오디오 볼륨 테스트를 변경해도 오디오 품질 테스트에 영향을 미치지 않습니다.

테스트 시퀀스 문서화

시퀀스 파일에 대한 명확한 문서화는 스펙의 모든 요구 사항이 충분히 포함되도록 하는 데 있어 중요한 부분입니다. 그러나 제한 값이나 테스트 매개 변수와 같은 문서의 정보를 반복해서는 안 됩니다. 

단계 이름과 설명을 사용하여 단계의 목적을 문서화할 수 있습니다. 단계 이름은 단계가 수행하는 작업과 조치를 수행하는 이유를 설명해야 하지만 단계에 정의된 매개 변수 값을 포함해서는 안 됩니다. 예를 들어, 단계의 이름을 'Wait'라고 지정하는 대신 'Wait for system to boot'라고 지정하십시오. 이름에 추가 정보가 필요한 경우 단계의 Description 프로퍼티를 사용하여 추가 상세 내역을 지정하십시오.

또한 NI 요구 사항 게이트웨이와의 TestStand 통합을 사용하여 실제 테스트 코드에 포함되는 요구 사항을 효과적으로 추적할 수 있습니다. NI Requirements Gateway를 통해 어떤 요구 사항이 적용되는지 신속하게 파악할 수 있으며, 요구 사항을 다루는 단계로 이동할 수 있어 검증 프로세스의 속도를 높일 수 있습니다.

NI Requirements Gateway를 통해 요구 사항 문서, 테스트 시퀀스 및 테스트 리포트 간의 연결을 생성하여 모든 요구 사항이 포함되도록 보장할 수 있습니다.

단계, 시퀀스 및 시퀀스 파일에 사용할 수 있는 요구 사항 필드를 사용하여 해당 요구 사항에 대한 정보를 제공하십시오. 이러한 필드를 NI Requirements Gateway와 함께 사용하여 요구 사항 문서와 테스트 코드 간의 매핑을 만들어 요구 사항이 적용되는 위치를 신속하게 확인할 수 있습니다. 

요구 사항 필드를 사용하여 단계, 시퀀스 또는 시퀀스 파일을 스펙 문서의 특정 요구사항에 매핑

NI TestStand와 NI Requirements Gateway를 사용하여 요구 사항을 추적하는 방법에 대한 자세한 내용은 NI Requirements Gateway를 NI TestStand와 커플링 길라잡이를 참조하십시오.

독립 코드 모듈 개발

TestStand 단계는 코드 모듈을 호출하여 계측 및 자동화 하드웨어와 통신합니다. 코드 모듈은 LabVIEW, C++ 또는 C#을 포함한 여러 언어로 구현될 수 있습니다. TestStand는 단계와 코드 모듈 사이에 자연적인 경계를 제공하기 때문에, TestStand 시퀀스와는 별개로 테스트 및 검증될 수 있는 코드 모듈을 작성하는 게 유리합니다. 
코드 모듈을 테스트 시퀀스 외부에서 테스트할 수 있도록 하려면 SequenceContext 또는 기타 TestStand 참조를 사용하여 데이터에 직접 액세스하는 대신, 파라미터를 통해 데이터를 코드 모듈로 전달하십시오. 종료 모니터 구현과 같이 SequenceContext 사용이 필요한 경우, TestStand 특정 코드 없이 작동할 수 있도록 코드 모듈을 디자인합니다. LabVIEW 코드 모듈에서는 "참조되지 않음" 기능을 사용하여 SequenceContext가 유효한지 확인한 후 사용할 수 있습니다.

개별적으로 실행 가능한 코드 모듈을 사용하여, 코드 모듈을 반복하는 테스트 픽스처를 디자인할 수 있으며, 입력 파라미터의 모든 순열을 전달할 수 있습니다. 테스트 픽스처는 결과를 알려진 정확한 결과와 비교하여 코드 모듈이 예상대로 작동하고 있는지 검증할 수 있습니다.

플러그인을 사용하여 프로세스 모델 변경

TestStand 프로세스 모델은 UUT 추적, 리포트 생성, 데이터베이스 로깅, 배치 또는 병렬 테스트를 포함하여 테스트 대상 장치에 특정되지 않은 테스트 기능을 처리합니다. TestStand와 함께 제공되는 프로세스 모델은 복잡하기 때문에 이러한 모델을 변경하기 위해서는 상당한 검증 노력이 필요합니다. 

프로세스 모델은 기본 리포트 생성 및 데이터베이스 로깅 기능을 구현하는 플러그인 아키텍처를 사용합니다. 이 아키텍처를 활용하여 프로세스 모델 시퀀스 파일 자체를 변경하지 않고 기존 프로세스 모델의 기능을 확장할 수 있습니다. 이렇게 하려면 별도의 플러그인 시퀀스 파일로 구현되는 사용자 지정 플러그인을 생성하십시오. 이 플러그인의 동작을 독립적으로 검증할 수 있습니다.

프로세스 모델 플러그인은 프로세스 모델 파일과는 별도의 구성 요소로, 개별적으로 검증할 수 있습니다.

모델이 UUT 일련 번호를 수집하는 방법을 변경하는 등 프로세스 모델 자체에서 직접 기능을 변경해야 하는 경우, 기존 기능을 구현하는 프로세스 모델의 단계를 비활성화한 다음, 새 기능을 위한 별도의 플러그인을 생성하는 것을 고려하십시오. 이 접근 방식을 사용하면 향후 사용자 정의 동작에 대한 변경을 플러그인으로만 제한할 수 있으며, 재검증하기가 더 쉬워질 것입니다. 

프로세스 모델 및 플러그인을 사용자 정의하는 방법에 대한 자세한 내용은 NI TestStand 프로세스 모델 개발 및 사용자 정의 우수 사례 문서를 참조하십시오.

테스트 세팅 및 설정 관리

테스트 시스템을 개발할 때, 테스트를 수행하는 모든 스테이션에서 TestStand 세팅이 동일해야 하며, 변경 사항의 적절한 검증 없이는 절대 수정되면 안 됩니다. 그러나 많은 TestStand 구성 요소는 개별 세팅을 가지고 있기 때문에 변경 사항이 없는지 확인하기 어려울 수 있습니다. TestStand 세팅 이외에도 인스트루먼트 세팅이 테스트 시스템 전반에 걸쳐 일관되어야 합니다. 인스트루먼트 세팅에는 NI Measurement & Automation Explorer (MAX)에서 만든 NI-DAQmx 세팅 또는 디바이스의 GPIB 및 COM 세팅이 포함될 수 있다. 그러한 세팅은 다양할 수 있으며 검증 테스트를 디자인하기 어렵습니다.

세팅이 올바른지 확인하는 한 가지 방법은 테스트 시퀀스에서 프로그램 방식으로 설정한 다음 각 세팅을 쿼리하여 세팅이 인스트루먼트 또는 프로그램에 의해 수락되었는지 확인하는 것입니다. 세팅을 쿼리할 수 없는 경우 세팅이 저장된 위치를 찾아 텍스트, INI 또는 XML 파일에서 읽습니다. 이 시스템은 TestStand 외부 항목의 상태를 확인하고 기록할 수 있으며, 이를 제어할 수 있습니다.

소스 코드 제어 도구를 사용하여 파일 관리

세팅을 관리하는 또 다른 방법은 세팅이 포함된 파일을 엄격하게 제어하는 것입니다. 모든 TestStand 세팅을 저장하는 설정 파일은 <TestStand Application Data>\Cfg 디렉토리에 저장됩니다. 기타 세팅의 경우 세팅 파일의 위치에 대한 자세한 내용은 제품별 설명서를 참조하십시오.
테스트 시스템 파일을 모니터링, 제어 및 저장하는 방법은 Subversion, Perforce 및 Microsoft Visual Source Safe와 같은 SCC(Source Code Control) 프로그램을 사용하는 것입니다. 이러한 프로그램의 대부분은 Microsoft SCC 인터페이스를 준수하도록 디자인되었으며, TestStand 또는 LabVIEW 내에서 사용할 수 있습니다. 파일을 저장하기 위해 임시 소유권을 가져오고 변경사항을 문서화하지 않으면 파일을 수정할 수 없는 경우도 있습니다. 이러한 프로그램은 종종 어떤 파일이 변경되었는지 알려줄 뿐만 아니라 이전 파일과 새 파일을 분석하여 변경 사항을 강조하여 검증의 단순화에 도움을 줄 수 있습니다.

또한 파일 체크섬을 사용하여 세팅 파일이 검증된 상태에서 변경되지 않았는지 확인할 수도 있습니다. 이 방법을 사용하여, 해당 체크섬을 검증된 파일 값에 대응해 계산한 체크섬과 비교하는 단계를 추가할 수 있으며, 일치하지 않을 경우 테스트 실패를 생성할 수 있습니다.   

테스트 시스템 외에도 테스트를 지원하는 모든 하드웨어와 소프트웨어가 알려진 검증된 상태인지 확인하는 것이 중요합니다. 이 섹션에서는 시스템 상태를 유지하기 위한 기법, 그리고 (필요한 경우) 변경사항을 적용하는 방법을 설명합니다.

하드웨어 설정 관리

시스템뿐 아니라 각 개별 테스트에 대해서도 인스트루먼트를 적절히 선택, 설치, 프로그래밍 및 구성해야 합니다. 예를 들어 디지털 멀티미터(DMM) 또는 오실로스코프에는 적절한 통신 및 신호 수집을 위해 설정할 수 있는 몇 가지 옵션이 있으며, 이 옵션은 테스트 시스템이 완성될 때 향후 하드웨어에 대한 변경을 위해 반드시 검증 및 확인되어야 합니다.

하드웨어 상호 작용을 관리하기 위한 하드웨어 추상화 계층(HAL)을 생성하면, 테스트 시스템에서 하드웨어를 변경할 때 필요한 재검증을 줄일 수 있습니다. HAL을 사용하면 장비별 코드 모듈을 테스트 시퀀스에서 사용하는 대신 측정 유형과 장비별 드라이버를 테스트 시퀀스에서 분리할 수 있습니다. 테스트 절차는 일반적으로 특정 계측기가 아닌 계측기 유형(예: 전원 공급장치, 디지털 멀티미터[DMM], 아날로그 출력 및 릴레이)을 사용하여 정의되므로, 추상화 계층을 사용하면 테스트 시퀀스에서 새로운 계측기 및 요구사항에 더욱 원활하게 대응할 수 있습니다. HAL을 사용하면, 전체 테스트 시스템을 완전히 테스트할 필요 없이, HAL 기능이 일련의 테스트 사례에서 이전 하드웨어와 동일한 출력을 생성하도록 하여 새 하드웨어를 검증할 수 있습니다. HAL 사용에 대한 자세한 내용은 테스트 시스템 구축의 기초: 하드웨어 및 측정 추상화 계층을 참조하십시오.

런타임에 하드웨어를 검증하는 것도 좋은 방법입니다. 런타임에 세팅 또는 기타 인자를 읽고 저장함으로써 소프트웨어와 함께 검증되어야 하는 항목이 의도한 대로 설정되고 작동된다는 확신을 가질 수 있습니다. 예를 들어, TestStand 단계는 계측기의 교정 날짜를 쿼리하여 교정이 최신인지 확인하고, COM 포트에 부착된 계측기의 모델 번호와 일련 번호를 확인하여 계측기가 교체되지 않았는지 확인할 수 있습니다. 테스트 시퀀스를 디자인하거나, 이러한 고려사항을 염두에 두고 계측기를 구입하면, V&V 프로세스를 단순화하는 데 도움이 될 수 있습니다.

하드웨어가 변경되었다고 예상되는 경우, 반드시 V&V 프로세스의 변경을 고려해야 합니다. 계측기가 고장나서 동일한 제조사 및 모델의 다른 계측기를 삽입하게 된 경우, 올바르게 작동하는지 확인하기 위해 무엇을 해야 하는지 고려하고, 변경이 제대로 되었는지 확인하기 위한 테스트를 디자인해야 합니다. 계측기 설정을 위해 IVI (Interchangeable Virtual Instrument) 드라이버와 인터페이스를 사용하면, 동일한 제조사 또는 모델의 두 계측기 간 전환, 또는 서로 다른 제조사 또는 모델의 두 계측기 간 전환을 단순화할 수 있습니다.

소프트웨어 설정 관리

테스트 시스템을 유지관리할 때, 새로운 기능을 사용할 수 있도록 LabVIEW, TestStand 또는 다른 프로그램을 업그레이드하는 것을 고려해야 합니다. 이런 소프트웨어 업그레이드는 재검증 및 재확인을 위한 트리거입니다. 잠재적인 업그레이드를 ROI (투자 수익)로 간주하십시오. 예를 들어, 능률적인 개발 인터페이스를 얻고자 하는 경우, 개발 중에 업그레이드할 수는 있지만, 시스템을 배포한 후에는 업그레이드할 수 없습니다. 그러나 최근 TestStand 업그레이드의 경우처럼 실행 속도가 향상되면 테스트 시간이 단축되고 처리량이 증가하며 매출이 증가할 수 있습니다. 두 경우 모두 재검증 비용이 결정적인 요소지만, 그 비용 또한 긍정적인 ROI를 제공할 수 있으므로 비용과 노력을 들일 가치가 있습니다. 일반적으로 여러 소프트웨어 업그레이드를 한 번에 수행하여 소프트웨어를 검증하는 횟수를 최소화해야 합니다.

테스트 시스템에서 일관된 소프트웨어 세트를 유지하려면 검증된 시스템에서 기본 이미지를 생성하고 새 테스트 스테이션을 설정할 때 이 이미지를 사용하는 것을 고려해 보십시오. 그러나 이미지를 사용할 때에도 소프트웨어 업데이트가 발생하지 않도록 해야 합니다. NI 소프트웨어의 경우, NI 업데이트 서비스가 업데이트를 자동으로 설치하지 않도록 설정되었는지 확인하십시오. 기본적으로 Microsoft 업데이트는 대부분의 컴퓨터에서 자동으로 실행됩니다. Sun, Apple, Adobe와 같은 다른 회사들도 웹 기반 자동 업데이트를 사용합니다. V&V 프로세스의 영향을 받는 모든 시스템에서 자동 변경 및 업그레이드를 비활성화해야 합니다. 자동 업데이트가 만드는 변경은 예측이 불가능하고 작동과 세팅에 알려지지 않은 영향을 미칠 수 있습니다. 

IT 부서는 바이러스 검사 소프트웨어 사용, 화면 보호기 같은 보안 정책 설정, 패치와 업그레이드 설치(필요한 경우) 등 회사 내의 컴퓨터를 제어하는 일반적인 정책을 가지고 있을 수 있습니다. 제조 부서는 IT 부서와 협력하여 TestStand 시스템을 건드리지 않고 관리해야 합니다. 컴퓨터에 구체적으로 어떤 항목이 영향을 미치는지 결정해야 하지만, 사용자의 요구는 바이러스 스캐너 제거, 화면 보호기 끄기, 전사적 업그레이드 또는 패치 적용 제외와 같은 IT 정책과 차이가 날 수 있습니다.

고급 NI TestStand 개발자에게 유용한 토픽을 다루는 TestStand 고급 아키텍처 시리즈의 추가 문서를 보려면 클릭하십시오.