저비용 하드웨어 인 더 루프 테스팅 자동화 솔루션

오늘날 전자 제품의 반복이 번개처럼 빠르게 이루어지는 빠른 세상에서, 우리는 개발의 가장 중요한 측면 중 하나인 테스트를 종종 잊곤 합니다. 테스트는 제품을 출시하는 것을 막는 마지막 단계이기 때문에 간과하기 쉽습니다. 제품 개발에서 우리는 종종 "충분히 좋다"와 "철저하게 테스트됐다"의 양쪽 진영에서 자신을 발견합니다. 이 상황은 테스트하고, 다시 테스트하고, 그리고 또 테스트할 시간이 없기 때문에 보통 발생합니다. 

최상의 상황에서는 전문 테스트 팀을 고용했을 것입니다. 이 팀은 철저한 테스트를 수행할 준비가 되어 있습니다. 그런 멋진 테스트 팀이 있다고 해도, 우리는 정말로 그들을 프로토타입에 대한 모든 수정, 모든 작고 하찮은 변경에 대해 사용할 수 있을까요? 대부분의 경우, 대답은 아니오입니다. 이 글에서는, 당신이 원하는 것을 가지고 또 먹을 수 있는 해결책으로 문제에 접근하고자 합니다. 이 글에서는 매우 저렴한 비용으로, 그러나 매우 효과적이고 상당히 철저한 테스트 시스템을 검토할 것입니다. 이 시스템은 당신이 찾고 있던 가성비를 제공할 것입니다.

수동 테스트 대 자동 테스트

산업에서 생산 수준 테스트를 위해 자동화된 테스트 설정을 갖는 것은 꽤 흔한 일입니다. 그러나 제품 개발의 경우, 일반적인 관행은 아닙니다. 위에서 언급했듯이, 고도로 자동화된 테스트 장비를 설정하는 데 드는 비용과 개발 시간은 상당한 노력을 요구합니다. 이러한 유형의 비용과 노력은 대량 생산이나 매우 정교한 테스트 구성(예: 환경 테스트를 여러 번 거쳐야 하는 저량의 우주선 시스템)이 필요한 경우에만 정당화됩니다. 나머지 세계에 대해서는, 우리는 기본적이고 지루한 수동 테스트에 의존합니다. 이러한 종류의 테스트는 ADC/DAC 검증, 프로토콜 검사, 전력 소비 테스트 등을 포함할 수 있습니다. 테스트 유형에 관계없이, 희망은 그것이 한두 번만 수행되어야 하며, 그 후에는 테스트 그룹에게 넘겨질 수 있다는 것입니다.

의도치 않은 결과와 자동화

우리의 개발 과정에서, 하드웨어 디자인/리스핀 단계나 임베디드 소프트웨어 개발 중에, 우리는 의도치 않게 무언가를 망가뜨리게 됩니다. 예를 들어, 패드 사이에 솔더 브릿지가 생기거나 드라이버 코드가 다른 드라이버 코드로 넘쳐 흐르는 것과 같은 일이 발생할 수 있습니다. 결과가 어떻게 되든, 테스팅이 한두 번만 이루어지지 않는다는 것은 분명합니다. 문제가 발생하고, 열 번째 보드를 다시 작업한 후에는 지칠 대로 지쳐서 철저한 테스팅을 수행하기가 너무 힘듭니다. 이 문제에 대한 명백한 해결책은 자동화된 시스템이 철저한 회귀 테스팅을 수행하게 하는 것입니다. 하지만, 돈과 시간이 거의 없는 임베디드 엔지니어에게는 철저한 자동화 테스트 시스템을 개발하는 해결책이 무엇일까요?

저렴한 해결책

임베디드 시스템의 경우, 저비용이면서도 매우 확장 가능하고 실용적인 자동 테스트 솔루션이 존재합니다. 완벽하지는 않지만, 설계 엔지니어에게 가장 높은 투자 수익을 제공할 것입니다. 개념은 아날로그 신호를 구동하고, 아날로그 신호를 읽으며, 다양한 프로토콜 직렬 스트림을 생성하고, 파형을 분석할 수 있는 간단한 장치를 사용하는 것입니다. 이러한 사양을 갖춘 저비용 장치의 예로는 Analog Discovery 2가 있습니다. 이 장치는 5V 장치이지만, 상당한 성능을 자랑합니다. 저는 이것을 임베디드 시스템 개발을 위한 나의 스위스 아미 나이프로 여깁니다. 다른 비교할 만한 제품들도 있지만, 제 응용 프로그램에 특히 잘 작동하는 것으로 이 장치를 발견했습니다. 이 장치는 데스크탑 컴퓨터나 심지어 라즈베리 파이에서도 작동할 수 있습니다. 또한 사용자가 테스트 실행 파일을 빠르게 작성할 수 있도록 하는 파이썬 라이브러리도 있습니다. 편의를 위해 전체 구성을 도커화하여 모든 아키텍처에 대해 구축했습니다.

실행 예

실제 예를 고려해 보겠습니다. 이 예는 이 저장소에서 찾을 수 있습니다. 단순함을 위해, 우리의 임베디드 대상은 Arduino Duo가 될 것입니다. 아래는 우리의 전체 테스트 설정이 어떻게 생겼는지입니다:

여기서의 아이디어는 다음을 시연하는 것입니다:

• 호스트 컴퓨터가 아날로그 디스커버리 2를 통해 아날로그 신호를 아두이노로 전달하도록 지시합니다
• 아두이노는 ADC 값을 읽고 저장합니다
• 호스트 컴퓨터는 UART(USB)를 통해 ADC 값을 받습니다
• 호스트 컴퓨터는 아날로그 디스커버리 2를 통해 전송된 것과 아두이노가 보낸 텔레메트리가 일치하는지 확인합니다

이런 것을 자동화하려는 이유는 무엇일까요? ADC 근처에서 보드를 재작업하거나 누군가가 ADC와 인터페이스하는 드라이버를 변경한다고 가정해 봅시다. 전원 공급 장치에서 몇 개의 노브를 돌리는 간단한 수동 ADC 읽기만으로 하드웨어/소프트웨어를 테스트하기에 100% 확신할 수 있을까요? 그렇지 않다면, 왜 모든 순열과 모든 코너 케이스를 자동화로 커버하지 않고 우리가 직접 할까요? 그리고 좋은 조치로, 왜 같은 것을 100번이나 실행하지 않겠습니까...그냥 할 수 있으니까요! 이것은 훨씬 더 정교하고 복잡해질 수 있습니다(예: 프로토콜 테스팅, ADC 필터링 테스트 등), 하지만 이 글은 기본적인 것들만 다룰 것입니다.

테스트 스크립트는 상당히 기본적입니다. 아두이노(즉, 테스트 대상 임베디드 장치)에 적절한 프로그래밍 파일이 로드되었고 모든 것이 제대로 연결되었다고 가정할 때, 컴퓨터에서 다음과 같이 테스트 스크립트를 실행합니다:

python -m pytest test_arduino_hil.py

이것은 아날로그 디스커버리 2가 아두이노의 ADC 전압 범위를 스윕하고 ADC에서 읽은 출력 전압이 입력 전압과 일치하는지 확인하도록 트리거합니다. 벤치탑 공급 장치로 수동으로 스윕하는 대신, 스크립트가 단일 명령으로 이 작업을 대신 수행했습니다. 이와 같은 사소한 예제에서는 불필요해 보일 수 있지만, 회귀 방식과 같이 테스트를 결합할 때 이 과정은 큰 이익을 가져다줍니다.
이를 CI/CD 시스템과 결합하면, 다음과 같은 단계가 실행되고 통과하는 것을 볼 수 있습니다:

위에 표시된 단계는 다음과 같습니다:

1. docker_build: 환경 구축. 이 경우, 리눅스 PC와 라즈베리 파이와 같은 ARM 기반 장치에서 도커 이미지를 사용하고 있습니다
2. arduino_load_test: 컴파일하고 로드하고 아두이노 코드가 제대로 작동했는지 확인합니다.
3. arduino_hil_test: 물리적인 아두이노에서 하드웨어 인 더 루프 테스트를 실행합니다.

테스트 섹션을 자세히 살펴보면, 이러한 테스트가 Gitlab에 의해 캡처되고 구문 분석되었음을 알 수 있습니다:

이제 로컬 및 원격(우리의 CI/CD 시스템을 사용하여)에서 디자인을 테스트할 수 있는 소프트웨어 설정을 갖추게 되었습니다. 이를 통해 설계 엔지니어는 테스트와 디버깅 대신 설계에 계속 집중할 수 있습니다.

결론

이 글에서는 자동화된 테스트를 사용하여 설계를 동시에 및 사후에 검증하는 개념을 검토했습니다. 사소한 재작업이든 거대한 설계 변경이든, 자동화된 회귀 테스트를 갖추고 있으면 의도하지 않은 결과(즉, 한 가지를 수정하면 다른 것이 문제가 됨)를 배제할 때 큰 이점이 있습니다. 권장되는 과정은 이러한 테스트 스크립트를 설계 개발 과정과 함께 작성하는 것입니다(테스트 주도 개발과 유사). 이러한 자동화된 테스트를 CI/CD 시스템과 결합하면, 우리의 보드가 원격 대상에서 작동하며 언제 어디서나 누구나 테스트할 수 있음을 보여주는 추가 보너스를 제공합니다.

Altium이 다음 PCB 설계에서 어떻게 도움을 줄 수 있는지 알고 싶으신가요? Altium의 전문가와 상담하세요 또는 주요 DFM 문제와 그 해결책에 대해 더 알아보세요. Altium Designer의 무료 체험판을 여기에서 다운로드할 수 있습니다.