​효율성 향상 및 위험 감소를 위한 검증 테스트 시스템 구축 접근 방식 표준화

​테스트 시스템과 관련된 효율성을 높이려면 현재 하고 있는 일부터 시작해야 합니다. V&V 테스트 팀은 종종 변형 버전 또는 완전히 다른 제품을 테스트해야 하기 때문에 다양한 요구 사항 및 스펙을 가진 제품을 테스트할 수 있는 새로운 테스터를 구축할 준비가 되어 있어야 합니다. 신형 제품에는 디바이스 자체를 제어하는 소프트웨어가 포함되어 있을 수 있습니다. 진정한 산업용 사물 인터넷(IIoT) 형태에서는 이 소프트웨어가 정보를 수집하고 네트워크에 게시합니다. 더 오래된 제품은 전기 및 기계적 기능을 기반으로 하거나 전기 부품 없은 단순히 기계 장치일 수도 있습니다.  

궁극적으로, 디바이스가 최신 기술을 사용하는 최첨단 장치이든, 또는 수없이 검증된 전기나 기계 공학 설계를 기반으로 제작되었든 중요하지 않습니다. 모든 제품은 제조 전 V&V 단계에서 검증되고 확인되어야 합니다. V&V 테스트를 수행할 수 있는 시간은 여러 요인에 달려 있습니다. 맞춰야 하는 출시 날짜가 있습니까? 설계 팀의 일정이 연기된 적이 있습니까? 아니면 V&V 테스트에서 보드 재설계 및 설계 주기 반복을 유발하는 설계 문제를 식별하여 일정이 몇 달 뒤로 밀렸을 수도 있습니다. 더 단축된 일정에 대한 이러한 모든 압력은 원래 테스트 계획에 있던 테스트 단계를 건너뛰고 품질을 희생하고 위험을 증가시킵니다.  

혁신의 속도는 계속해서 가속화되어야 합니다. 그러나 테스트 팀에서 사용할 수 있는 자원은 그대로 유지되거나 심지어 줄어들기도 합니다! 안타깝지만 이것은 새로운 일이 아닙니다. 이는 우리가 일이 터지면 그제서야 테스터 구축을 위해 바쁘게 움직이게 되는 가장 큰 이유 중 하나입니다.  

대신 능동적이 되기 위해서는 시스템이 어떻게 구축, 관리 및 유지되는지 살펴봐야 합니다. 사후대응적 테스트 그룹의 가장 큰 징후 중 하나는 많은 "맞춤형" 테스트 시스템과 테스트 장비입니다. 이 말은, 여러 테스트 구성 간에 장비를 재사용하거나 용도 변경하는 작업이 복잡하고 시간이 오래 걸리기 때문에 거의 활용되지 않는다는 것입니다. 또 다른 징후는 "여러 번 구축된" 테스터를 보유하고 있다는 것입니다. 여러 테스트 엔지니어들이 넓고 다양한 기술력을 보유하고 있으면 서로를 잘 보완할 수 있지만, 때로는 원래 무언가를 구축한 사람이 자리를 옮긴 경우, 현재 상태에서 무슨 일이 일어나고 있는지 이해하는 데 애쓰는 것보다 단순히 테스터를 다시 구축하는 것이 더 빠릅니다.  

조직에서 이와 같은 상황에 익숙할 수 있지만 이는 표준화 기회이기도 합니다. 표준화를 하면 능동적 테스트에 한 걸음 더 다가갈 수 있습니다.

새로운 테스터를 세우는 것부터 모든 장비를 유지 관리하는 것까지 표준 접근 방식의 이점은 다양합니다.

• 명확성을 높이고 각 테스트 시스템이 기본적으로 작동하는 방식에 대한 공통된 이해를 촉진합니다.
• 팀의 모든 사람이 모든 시스템에서 코드를 재사용하거나 장비를 재사용할 수 있습니다. 
• 동일한 테스터를 여러 번 구축해야 하는 위험을 줄여 전반적인 팀 효율성을 높입니다.
• 팀 구성원이 맞춤형 테스터를 구축하고 사내 또는 사외로 이동했을 때 발생하는 위험을 줄입니다.
• 새로운 테스터를 세우는 속도를 높입니다. 시간이 지남에 따라 팀은 동일한 핵심 구성 요소를 계속해서 개발할 필요가 없을 정도로 기반을 갖추게 됩니다.

상위 레벨에서, 표준 접근 방식은 팀의 효율성을 높일 수 있습니다. 그러나 물론 고려해야 할 다른 사항도 있습니다. 예상대로, 이는 하드웨어와 소프트웨어의 두 가지 범주로 나눌 수 있습니다. 시작하는 방법과 성공적인 테스트 시스템 표준화를 구현하기 위해 고려해야 할 사항에 대해 살펴보겠습니다.

​전체 테스터를 살펴보면, 효율성을 높이려면 표준화가 필요하지만 고려해야 할 시스템이 많다는 것을 알 수 있습니다.

• 설정값을 생성하고 낮은 샘플 속도로 특정 시간 간격 동안 장치의 출력을 측정 및 기록하기만 하면 되는 개방 루프 시스템 테스트 벤치.
• 모든 시나리오에서 제품이 예상대로 응답하는지 검증하기 위해 HIL 폐쇄 루프 제어 시스템에서 실시간으로 테스트해야 하는 임베디드 소프트웨어가 필요한 디바이스.
• 이전 두 옵션 사이—산업 및 초점에 따라 제품을 확인하고 검증하는 데 필요한 테스트 시스템은 넓은 스펙트럼으로 분포됩니다.

하드웨어 고려 사항

하드웨어 관점에서는 유연성, 확장성과 접근 방식이 테스트 시스템 효율성의 중요한 요소입니다. 

유연성  

V&V 테스트는 종종 다양한 수준의 복잡성이 있는 스펙트럼에서 수행됩니다. 한쪽 끝에서는 사용자가 테스트를 제어하고 필요에 따라 테스트를 시작 및 중지할 수 있는 개방 루프 제어 및 측정 시스템이 필요할 수 있습니다. 반면에 HIL/임베디드 소프트웨어 테스트를 위해 고도로 복잡하고 자동화된 시스템이 필요할 수도 있습니다.  

효율성 향상을 실현하려면 스펙트럼을 고려하여 요구 사항을 분석하십시오. 선택한 접근 방식은 스펙트럼의 양쪽 끝 요구 사항을 수용 가능해야 합니다. 이는 새로운 기술이 개발되어 새로운 유형의 측정이 필요하게 되면서 더욱 중요해집니다.  

표준 접근 방식에는 다양한 유형의 기존 측정을 통합하고 기술 발전에 따라 새로운 기능을 지속적으로 추가할 수 있는 유연성이 있어야 합니다. 이렇게 하면 최고의 시스템 준비 상태를 유지할 수 있으며 V&V 테스트 팀은 기술이 발전할 때마다 새로운 접근 방식을 다시 배울 필요가 없습니다. 결과적으로 이것은 효율성을 높이고 새롭고 다른 장비를 통합할 때의 장애물을 제거합니다.

확장성 

10년 후는 고사하고 5년 후에 어떤 제품 기능이 새로 나올지 아는 것도 불가능합니다. 그러나 우리는 장비가 그 정도로 오래 지속될 것으로 기대합니다. 따라서 특히 V&V 테스트 팀의 경우 확장성이 매우 중요합니다.  

가장 비싼 장비를 사용할 뿐만 아니라 통합하기도 복잡할 수 있기 때문입니다. 2개에서 8개 장치 테스트로 확장하는 것처럼 단순한 확장처럼 복잡한 작업을 수행하지 않는 경우에도 추가 채널을 빠르게 통합하고 동기화할 수 있도록 쉽게 확장 가능한 플랫폼을 선택하지 않은 경우 더 많은 디바이스를 처리하도록 확장하는 것이 어려울 수 있습니다.  

V&V에서는 시스템을 구축할 플랫폼과 접근 방식을 선택할 때 시스템 확장성을 고려되어야 합니다. 올바른 접근 방식을 통해 더 많은 채널로 시스템을 신속하게 적응, 통합 및 확장할 수 있다면 효율성을 높일 수 있습니다. 이것은 초기에 비용을 절감하고 장기적으로 필요한 경우 시스템을 쉽게 확장할 수 있다는 자신을 가질 수 있게 하므로 전략의 중요한 부분이어야 합니다.

접근법 

표준화를 통해 용도 변경 및 재사용이 더 쉬워지는지에 대해 논의했지만 예비 부품 준비도 중요합니다. 일정이 단축되었을 때, 테스트 1주일이나 몇 분 전, 장치에 보정이 필요하거나 장치가 의도한 대로 작동하지 않는다는 소식을 들으면 대책을 세우기가 어렵습니다. 이제 새 보드를 얻기 위해 매우 서둘러야 하며 테스트가 밀려날 수 있습니다. 하드웨어 접근 방식과 플랫폼을 표준화할 때 가동 시간을 보장하기 위해 예비 부품 전략으로 비용과 플랫폼 접근 방식 간에 적절한 균형을 찾아야 합니다. 궁극적으로 이것은 선택하는 것이 고품질과 정확성을 갖춘 광범위한 장비와 기능을 제공해야 함을 의미합니다.  

모든 테스트에서 필요한 모든 기능을 제공하는 접근 방식과 플랫폼을 찾는 것이 항상 가능한 것은 아닙니다. 이 경우 동기화, 타이밍 및 처리량 요구 사항을 고려하고 서로 다른 유형의 장비를 하나의 시스템에 통합하는 것이 얼마나 쉬운지 또는 복잡한지 분석하십시오. 플랫폼이 더 개방적일수록 효율성과 일정을 해치지 않으면서 다른 장비를 통합할 수 있을 만큼 충분히 유연합니다.

표준화할 때 가장 큰 위험은 미래의 상황에 맞게 확장할 수 없는 접근 방식이나 플랫폼을 선택하는 것입니다. 궁극적으로 선택한 전략은 팀에 적합해야 합니다. 표준화 과정을 시작하기 전에 철저한 평가를 수행하는 것이 종종 도움이 됩니다.  

소프트웨어 고려 사항

하드웨어 고려 사항과 마찬가지로 테스트의 복잡성도 소프트웨어 접근 방식을 표준화할 때 중요합니다. 스펙트럼의 최하단에서는 출력을 제어하고 하드웨어의 입력을 측정할 수 있는 턴키 소프트웨어가 정확히 지금 필요한 것임을 알게 될 수도 있습니다. 이러한 유형의 소프트웨어를 통해 테스트 엔지니어는 올바른 하드웨어를 구현하고 테스트 벤치를 더 빠르게 세우는 데 집중할 수 있습니다. 그러나 규모가 어느 정도 커지면, 테스트는 엔지니어가 내부 종속성이 다른 테스트 루틴을 실행할 수 있는 자동화된 테스터를 구축해야 할 정도로 복잡해질 것입니다. 이렇게 되면 시간이 훨씬 더 많이 걸립니다.  

테스트 엔지니어는 다양한 시나리오를 실행해야 하는 복잡한 제품을 테스트할 때 모든 테스트를 수동으로 실행하는 데 너무 오래 걸리기 때문에 자동화된 시스템 구축으로 눈을 돌립니다. 테스트 프로그램과 루틴을 작성하는 것은 이제 업무의 필수적인 부분이 됩니다. 팀의 기술 수준을 고려할 때 다양한 유형의 소프트웨어 및 프로그래밍 언어에 대해 다양한 수준의 숙련도가 있음을 알게 될 것입니다. 그러나 앞에서 언급한 것처럼 공통적 접근 방식이 없으면 시간이 지나면서 테스트 시스템을 관리하고 유지하는 것이 어렵거나 불가능해집니다.  

소프트웨어 접근 방식을 고려하기 시작할 때 프레임워크라는 단어를 계속해서 듣게 될 것입니다. 확장을 염두에 두고 구축된 개방형 프레임워크가 있으면 팀원 모두가 새 테스터를 구축할 때마다 동일한 기본 구성 요소를 구축하지 않아도 됩니다. 우리는 종종 각 테스터에 대해 동일한 기본 구성 요소를 매번 다시 구축한다는 사실을 잊습니다. 이와 같은 동일한 기본 구성 요소가 소프트웨어 내에 "숨겨져" 있기 때문입니다. 그러나 여기에서 소프트웨어 관점의 진정한 효율성 향상이 일어납니다.  

이상적으로는 소프트웨어 접근 방식이, 스펙트럼의 최하단에서는 코드를 개발할 필요 없이 빠른 센서 구성 및 데이터 로깅을 지원해야 합니다. 그러나 개발이 필요할 때는 엔지니어에게 프레임워크를 제공하는 개방형 접근 방식이 좋습니다. 테스트 엔지니어는 여러 언어로 작성된 테스트 코드를 프레임워크에 직접 통합하여 테스트를 더 빠르게 개발, 디버그 및 배포할 수 있어야 합니다. 이 경우 테스트를 자동화하려고 할 가능성이 높으므로 필요한 하드웨어를 사용하는 능력을 제한하는 프레임워크를 택하지 않도록, 다양한 유형의 하드웨어를 통합하는 것이 얼마나 쉬운지 고려해야 합니다.  

하드웨어 및 소프트웨어 고려 사항 일치 필요

전반적으로 표준화는 효율성을 높이고 위험을 줄입니다. 소프트웨어와 하드웨어 측면의 모든 것이 함께 작동하고 원활하게 통합될 수 있는지 확인해야 합니다. 선택한 소프트웨어 접근 방식을 지원하지 않는 드라이버가 있는 하드웨어를 선택하면 필요한 효율성을 얻을 수 없습니다. 마찬가지로, 소프트웨어 접근 방식이 충분히 개방적이지 않고 여러 언어에 걸쳐 재작업이 필요하고 코드를 실행하기 위한 래퍼를 만들어야 하는 경우 새 장비를 추가할 때 유지 관리하기가 너무 복잡해집니다. 궁극적으로 두 가지 모두에 대한 최상의 접근 방식을 찾고 쉽게 통합되고 확장 가능한 소프트웨어 및 하드웨어 플랫폼으로 표준화해야 합니다.  

표준화에는 단순한 시스템 이상입니다. 프로세스와 데이터도 중요합니다. 표준화할 때 올바른 데이터는 제품 성능뿐만 아니라 전체 테스트 환경에 대한 귀중한 통찰력을 제공할 수 있습니다. 프로세스의 맥락에서 이를 사용하면 오늘날 병목 현상이 있는 위치, 개선할 수 있는 작업 흐름, 현재 수동으로 수행되는 단계를 자동화할 수 있는 위치를 식별할 수 있습니다.  

논의한 바와 같이 시스템을 구축, 관리 및 유지하는 방법을 표준화하면 많은 효율성 향상을 경험할 수 있습니다. NI의 소프트웨어 및 하드웨어 솔루션은 고품질, 개방성, 확장성 및 유연성을 염두에 두고 개발되었으므로 소프트웨어 또는 하드웨어 접근 방식을 타협해야 한다고 생각하더라도 기존 기반을 사용하고 훨씬 더 짧은 시간에 프레임워크와 표준 접근 방식을 구축할 수 있습니다. 모든 팀 구성원의 기술과 숙련도를 기반으로 생산성을 가속화하는 공통 프레임워크에서 이를 연결하면 표준 접근 방식을 보다 원활하게 구현할 수 있습니다.