HIL(Hardware-in-the-Loop)이란?

1980년대에 전 McKinsey 컨설턴트 Donald G. Reinertsen이 발표한 획기적인 연구를 통해 시장 출시 시점의 상당한 영향이 명확히 드러났으며, "6개월의 지연은 제품 개발로 인해 수명 주기 이익의 33%에 해당할 수 있습니다"라고 밝혔습니다. 또한 1996년 6월 4일, 역사상 가장 유명한 소프트웨어 버그 중 하나로 알려진 Ariane 5 로켓의 발사 및 파괴 사례는 엔지니어링 업계에 임베디드 소프트웨어 품질의 중요성과 적절한 테스트의 필요성을 일깨워주었습니다. 그 결과 3억 7천만 달러 이상의 손실이 발생했습니다.ii 이 수치는 지연의 결과, 시장 출시 시간 단축의 필요성, 그리고 제품 설계 및 개발 수명 주기 초기에 적절한 테스트를 통해 버그와 오류를 조기에 발견함으로써 얻을 수 있는 비용 절감의 필요성에 대한 명확한 증거입니다.

생산을 시작하기 전에 결함을 찾아내는 기술을 사용하는 것이 중요합니다. 테스트를 전체 제품 설계 및 개발 주기의 필수적이고 전략적인 자산으로 만드는 것이 점점 더 중요해지고 있습니다. 단순한 사후 고려사항이나 프로세스 마지막 단계의 치명적인 문제에 그쳐서는 안 됩니다. 이러한 이해를 통해 프런트 로딩 테스트, 시프트 레프트, 모델 기반 설계, 그리고 Anything-in-the-Loop (XIL) 테스트로 알려진 방법과 전략이 개발되고 구현되었습니다. 이 기술 백서에서는 임베디드 소프트웨어 검증에서 중요한 테스트 방법론 중 하나인 HIL 테스트에 중점을 두고 있습니다.

HIL 테스트를 시작하기 전에, 실제로 개발할 제품인 Device Under Test(DUT) 또는 System Under Test(SUT)를 살펴보는 것이 가장 중요합니다. 현재와 미래의 제품은 훨씬 더 소프트웨어 중심적이고 복잡해졌습니다. Wi-Fi 라우터, 식기세척기, 식품 가공기 등과 같은 예를 고려할 때, 이제 모두 임베디드 소프트웨어 또는 펌웨어 기반입니다. 자동차, 비행기, 스마트폰은 매우 소프트웨어 정의적일 뿐만 아니라 매우 복잡한 시스템의 대표적인 예입니다. 이들은 소프트웨어 기반 시스템의 집합이기 때문입니다. 결국 이들 모두는 소프트웨어가 현재 기능 세트와 앞으로 출시될 개선사항의 정의 요소라는 공통점을 가지고 있습니다. 스마트폰의 업데이트 가능한 앱이 수천 개의 기능과 역할을 가진 멀티툴로 변모하는 것은 이러한 트렌드의 명확한 구현이며, 이는 오늘날 고객이 거의 모든 다른 제품에서도 당연히 기대하는 사항이 되었습니다.

어플리케이션, 펌웨어, 그리고 일반적인 소프트웨어는 실행될 하드웨어가 필요하므로 독립적으로 존재할 수 없습니다. 일반적으로 하드웨어는 컴퓨터 또는 프로세서, 즉 컨트롤러입니다. 이는 제품 또는 시스템 (시스템의 집합 포함)이 하드웨어 (컨트롤러)와 소프트웨어를 결합하고 통합해야 하며, 그 결과 DUT가 됩니다. 또한 컨트롤러는 상호작용할 수 있는 환경이 필요합니다. 예를 들어, 세탁기의 컨트롤러는 충분한 물이 있는지 확인하고, 물의 온도를 측정하며, 세탁 드럼의 속도 (RPM)를 제어해야 합니다. 따라서 컨트롤러는 데이터 또는 피드백을 입력으로 제공하고 명령 또는 셋포인트를 출력으로 보내는 센서 (온도, RPM) 및 액추에이터 (히터, 전기 모터)에 연결해야 합니다. 이는 그림 1과 같이 컨트롤 루프 설계 이론의 매우 기본적인 구성요소입니다. 컨트롤러 주변 환경은 일반적으로 플랜트라고 부릅니다.

그림 1. 제어 루프 설계의 기본

제품 설계 및 개발 주기를 살펴보면, 프로젝트 시작 시 컨트롤 루프의 모든 구성요소를 사용할 수 있는 것은 아닙니다. 더욱이, 개발 초기 단계에서 필요한 모든 하드웨어 및 소프트웨어 구성요소를 준비하고 사용할 수 있다는 것은 현실적이지 않습니다. 이때 시뮬레이션 및 모델 기반 설계가 그 간극을 메우기 시작합니다.

그림 2는 설계에서 프로토타이핑, 소프트웨어 및 컨트롤러 테스트, 물리적 테스트까지의 다양한 단계를 일반적인 V-다이어그램 형태로 보여줍니다. 또한 MIL(Model-in-the-Loop), SIL(Software-in-the-Loop), HIL(Hardware-In-the-Loop)의 테스트 방법론도 보여줍니다.

그림 2. V-다이어그램: 루프의 모든 항목(XIL)에서 물리적 테스트까지

디지털 시뮬레이션 및 모델 기반 설계는 다음과 같은 이유로 전체 설계 프로세스에서 핵심적입니다.

• 물리적 구성요소 선행 개발 및 테스트
• 테스트 범위 확대, 설계 반복 속도 향상
• 중복(물리적) 테스트 수를 최소화하여 속도 향상
• 코너 케이스 및 가능한 모든 시나리오에 대한 신속한 제품 품질 테스트

시뮬레이션 및 모델 기반 설계를 사용하면 MIL, SIL, HIL과 같은 테스트 방법론을 통해 훨씬 더 일찍 테스트를 시작할 수 있습니다. 그림 2 아래쪽에 나타난 바와 같이, V-다이어그램에서 오른쪽에서 왼쪽으로 이동할 때 (시프트 레프트(shift left)라고도 함) 컨트롤 루프의 구성요소가 단계적으로 교체되며, 실제 제품 설계 및 개발 주기에 따라 오른쪽으로 이동할 때에는 구성요소가 실제 하드웨어와 소프트웨어로 교체됩니다.

또한 버추얼 테스트를 사용하면 테스트 범위가 최대화되고 비용이 많이 들고 시간이 많이 소모되는 물리적 테스트를 줄일 수 있습니다. 임베디드 소프트웨어에서 발견된 결함의 개수에 대한 대략적인 추정은 1,000개 라인의 코드마다 10~20개입니다. 이것은 처음에는 많아 보이지 않을 수 있지만, 현재 일상적인 시스템에 얼마나 많은 코드 라인이 있는지 살펴보면 결함의 추정 개수가 매우 높을 수 있습니다. 8만 라인의 코드 (약 800~1,600개의 결함)를 포함하는 심박 조율기나, 700만 라인 (약 7만~14만 개의 결함)에 달하는 MRI 스캐너와 같은 의료기기를 고려할 때, 소프트웨어 복잡성의 방대함이 초래하는 영향은 더욱 명확해지며 훨씬 더 심각해집니다.

이러한 시스템의 복잡성은 전통적인 방법으로 철저히 테스트하는 것이 불가능할 정도로 지나치게 큽니다. 모든 시나리오를 물리적으로 테스트하는 것은 불가능하며, 과도한 시간과 비용이 소요됩니다. 또한 테스트 케이스가 가능한 모든 실제 조건을 다루는 것이 중요합니다. 대규모 장애, 재해, 디바이스 리콜은 이 백서 서두의 Ariane 5 사례에서 언급된 바와 같이 매우 큰 비용을 초래합니다. 하지만 무엇보다도, 이러한 결과가 브랜드 이미지와 기업 평판에 미치는 부정적인 영향은 그야말로 산정할 수 없을 정도로 막대합니다. 이러한 위험은 모델링 및 시뮬레이션을 통해 줄일 수 있습니다. 가상으로는 가능한 모든 반복 가능한 시나리오에서 제품을 확신을 가지고 테스트하는 것이 가능하므로, 최종 물리적 테스트는 값비싼 대규모 재해가 아니라 마지막 확인 절차에 불과합니다.

임베디드 소프트웨어 테스트는 문제 감지 방법론으로 사용되며, 시뮬레이션 및 모델 기반 설계를 많이 사용하는 호환 가능한 워크플로우로 설계 및 테스트 팀을 연결합니다.

그림 3. 컨트롤 루프 표현에서의 MIL, SIL, HIL 및 물리적 테스트

첫 번째 단계인 MIL (그림 3의 사분면 1)은 컨트롤러와 컨트롤러 주변의 전체 플랜트 (환경)를 포함한 모든 것을 시뮬레이션합니다.

두 번째 단계인 SIL (그림 3의 사분면 2)에서 소프트웨어 엔지니어는 컨트롤 모델에서만 타겟 코드를 생성하고, 블록을 대체하며 플랜트가 시뮬레이션되는 동안 소프트웨어 프로토타입을 생성합니다. 이 처음 두 단계에서는 시뮬레이션과 모델만을 사용하여 테스트를 실행할 수 있으며, 실제 물리적 하드웨어 구성요소는 거의 필요하지 않습니다.

세 번째 단계인 HIL (그림 3의 사분면 3)은 이 방법론에서 핵심입니다. 코드는 물리적 하드웨어 기반의 컨트롤 유닛 (빠른 컨트롤 프로토타이핑 플랫폼 또는 생산된 컨트롤러)에 배포 및 실행되어, 시뮬레이션 플랜트를 사용하여 가능한 모든 실제 시나리오를 테스트하고 (최종) 물리적 테스트 (그림 3의 사분면 4)로 이동하기 전에 다시 테스트할 수 있습니다.

따라서 HIL은 차량 생산 라인에서 섀시 및 구동계가 본체와 결합하는 것에 비유할 수 있습니다. 실제 컨트롤러 하드웨어에서 개발된 소프트웨어 코드를 실행하여, SIL 환경에서 임베디드 코드를 실행할 때 일반적으로 나타나지 않는 모든 타이밍, 동기화, 실행 결함을 확인할 수 있습니다.

MIL과 SIL의 강조 및 활용도를 높이기 위한 기대와 개발이 활발히 진행되고 있습니다. 그러나 HIL은 항상 실제 컨트롤러 플랫폼에서 임베디드 소프트웨어를 실행하기 위한 검증 수단이 되어야 하며, 이를 통해 안전하고 보안성이 확보된 소프트웨어 중심 제품을 시장에 자신 있게 출시할 수 있습니다. HIL 테스트의 장점은 다음과 같습니다:

• 안전 테스트—비용이 많이 들거나 위험한 장비가 손상될 위험 방지
• 비용 효율성—전체 프로토타입의 필요성을 줄임
• 빠른 개발—전체 시스템을 구축하기 전에 조기 테스트 지원
• 반복 가능한 시나리오—일반적인 케이스 및 에지 케이스, 결함을 안정적으로 시뮬레이션

그림 4. 물고기 비유: HIL 시스템은 수족관과 동일합니다.

HIL은 물리적 DUT (컨트롤러에서 실행되는 임베디드 소프트웨어) 주위에 가상 환경 또는 가상 현실 (디지털 트윈)을 제공하여 실제 환경 (물리적 트윈)과 연결되어 있다고 "믿게 하는" 테스트 방법론입니다. 그림 4와 같이 매우 간단한 유사점은 수족관이나 어항 속 물고기입니다. 수족관은 조절된 시뮬레이션 환경을 제공하여 물고기가 생존에 필요한 모든 것을 갖추도록 함으로써 바다의 실제 환경 (먹이, 물, 온도, 염도 등)을 완벽하게 모방합니다.

기술적 측면에서 DUT와 같은 소프트웨어 중심 제품에 초점을 맞추면, HIL은 컨트롤러의 실제 신호를 테스트 시스템 (플랜트)에 연결하는 임베디드 소프트웨어 테스트 기법입니다. HIL은 소프트웨어 모델과 시뮬레이션을 사용하여 현실을 시뮬레이션합니다. 따라서 실제 환경을 모방하는 HIL 테스트 시스템은 수족관과 같고, DUT (임베디드 소프트웨어를 실행하는 물리적 컨트롤러)는 물고기에 해당합니다. 이렇게 하면 컨트롤러 (또는 DUT)가 세탁기, 비행기 또는 자동차와 같이 조립된 제품에 설치되어 있다고 믿게 됩니다.

테스트와 설계 반복은 실제 시스템에 연결된 것처럼 시뮬레이션 플랜트를 통해 이루어집니다. 반복 가능한 가상화 시나리오를 사용하면, 엔지니어는 모든 실제 구성요소를 갖출 필요 없이, 또한 하드웨어 기반 물리적 테스트의 비용, 복잡성, 또는 일정 제약 없이 수천 가지 조건에서 컨트롤러를 시험할 수 있습니다. 실제 컨트롤러 또는 DUT는 HIL 시스템에서 입력을 받고 출력을 HIL 시스템으로 다시 보냅니다. HIL 시스템은 버스 인터페이스를 포함한 입력과 출력, 그리고 필요한 플랜트 모델을 포함한 HIL 어플리케이션 소프트웨어를 실행하는 리얼타임 컴퓨팅 코어로 구성됩니다. 그림 5와 같이 HIL 테스트 시스템 설정이 광범위한 가상 현실을 제공하는 모든 요구사항을 충족하려면 최소한 다음과 같은 핵심 요소로 구성되어야 합니다.

• DUT (컨트롤러에서 실행되는 임베디드 소프트웨어)
• DUT에 연결할 I/O 및 버스 인터페이스
• I/O 및 통신 버스를 결정적으로 읽고, 쓰고, 제어하며 어플리케이션 소프트웨어를 실행할 수 있는 리얼타임 컴퓨팅
• 테스트 시스템 구성, 시뮬레이션 모델 통합 및 배포, 테스트 또는 여러 테스트 케이스 (수동 및 자동) 실행, 결과 및 동작 분석 및 디버깅을 위한 어플리케이션 소프트웨어
• 시뮬레이션 모델

그림 5. HIL 테스트 시스템 설정의 컨트롤 루프

앞서 언급한 것처럼, HIL 시스템의 핵심 요소들입니다. 추가적인 요소는 다음 항목을 포함할 수도 있습니다.

• 오류 주입
• FPGA 기반 I/O
• I/O 스위칭
• 신호 컨디셔닝
• 로드 또는 에뮬레이션 로드에 대한 연결
• Restbus 시뮬레이션 (다른 컨트롤러의 입력이 필요한 경우; 예: 복합 시스템 환경 등)
• 연속 통합 및 연속 배포(CI/CD) 파이프라인까지 자동화 테스트

NI의 HIL 테스트에 대한 플랫폼 기반 접근 방식은 개발자와 사용자에게 개방형 및 유연한 빌딩 블록으로 구성된 툴박스를 제공합니다. 이를 통해 상용 제품 (COTS)을 활용한 폭넓은 커스터마이징이 가능하며, 소형 벤치탑부터 구성요소, 시스템, 그리고 완전 통합된 HIL 설정까지 확장할 수 있습니다. 사용자는 현재와 미래의 과제에 맞춰 무엇을 사용할지, 어떻게 확장하고 발전시킬지 스스로 결정할 수 있습니다. 공급업체 의존성을 최소화하면서, 사용자는 워크플로우와 테스트 자산의 개발 및 유지보수를 완전히 통제할 수 있습니다.

NI HIL 테스트 시스템 아키텍처는 HIL 시스템의 다양한 요소를 다루는 포괄적인 하드웨어 및 소프트웨어 플랫폼을 제공합니다. 개방형, 사용자 정의 가능한 툴체인은 NI, NI 파트너, 타사 하드웨어 및 소프트웨어를 혼합하여 HIL 테스트 시스템을 변경, 확장 및 확장할 수 있는 기능을 최대화합니다.

PXI는 진정한 COTS 기술을 기반으로 구축된 업계 선도 표준 하드웨어 플랫폼입니다. 이는 최고 수준의 타이밍 및 동기화 기능을 제공하며 HIL 테스트 시스템의 기본 요소입니다. 또한 PXI는 FPGA 기반 기술, 범용 인터페이스, 업계별 통신 프로토콜 등 다양한 I/O 및 버스 인터페이스를 지원합니다.

이러한 I/O 및 버스 솔루션은 NI 스위치 로드 및 신호 컨디셔닝 (SLSC) 플랫폼을 추가하여 더욱 확장할 수 있습니다. SLSC는 테스트 시스템 측의 실제 I/O 및 버스 인터페이스와 DUT 사이의 신호 경로에 사용자 정의 프런트 엔드 모듈을 추가합니다. 표준화된 COTS 연결 및 폼 팩터를 통해 오류가 발생하기 쉬운 포인트 투 포인트 배선 방식을 제거합니다. 이렇게 하면 전체 시스템이 단순화되고 신호 스위칭 및 컨디셔닝, 로드 통합, 결함 삽입 등이 가능합니다.

NI VeriStand는 NI HIL 시스템 및 임베디드 소프트웨어 리얼타임 테스트를 위한 핵심 어플리케이션 소프트웨어입니다. 설정 기반 HIL 시스템 셋업 및 컨트롤 (UI 및 API), 디버깅, 모델 통합, 리얼타임 자극 생성, 제품 내 자동화뿐만 아니라 NI LabVIEW, C/C++, Python 등을 통한 광범위한 맞춤형 자동화 API 기능을 통해 제품 개발 주기를 가속화합니다.

여기서 NI HIL Test System Architecture에 대해 자세히 알아보십시오.

오늘날의 제품은 소프트웨어 중심이 되었으며, 고객 기대의 근간은 제품이 미래에도 계속 진화하고 개선되어 지속적이고도 새로운 가치를 제공할 것이라는 점입니다. 시뮬레이션, 모델 기반 설계, HIL 테스트를 활용한 버추얼 검증 테스트는 테스트 범위와 제품 품질을 향상시키는 주요 방법론입니다. 또한 이러한 방법론은 테스트를 초기 설계 및 개발 주기에 도입하고 통합함으로써 출시 시간을 단축하고, 비용이 많이 들고 시간이 많이 소요되는 물리적 테스트의 필요성을 최소화합니다.

이로써 “테스트”라는 단어는, 설계를 생산으로 그리고 최종적으로 시장으로 옮기는 데 필요한 마지막 단계로 흔히 정의되고 사용되지만, 전체 제품 혁신을 위한 전략적 이점으로 전환됩니다. HIL을 통해 테스트는 프로젝트 계획표에 있는 하나의 확인란 이상의 의미로 격상됩니다. 이는 설계와 기업의 성공을 위한 혁신의 필수 요소가 됩니다 ("6개월의 지연은 제품 개발로 인해 수명 주기 이익의 33%에 해당할 수 있습니다" 참조).

혁신적인 기업들은 기존의 출시 전 테스트 이외의 영역에서도 HIL을 활용하고 있습니다. HIL의 장기적인 목표는 Ariane 5 사례처럼 비용이 많이 들거나 대량 생산되는 최종 제품에서의 치명적인 실수를 방지하는 것이지만, 소프트웨어 엔지니어가 소프트웨어 설계를 반복적으로 테스트하고 조정할 수 있는 설계 도구이기도 합니다. 이렇게 하면 공식 테스트가 시작되기 전에 검증된 제품이 만들어집니다. 또한 소프트웨어 엔지니어는 신속하게 새로운 아이디어를 구상하고 테스트할 수 있어, 시기적절한 피드백을 통해 혁신을 극대화할 수 있습니다.

• HIL 테스트 시스템 아키텍처 살펴보기
• Whirlpool가 HIL 테스트를 사용하는 방법 보기
• HIL이 어떻게 아처 항공을 가속화했는지 알아보기
• ZF가 HIL을 사용하여 ADAS를 검증하는 방법 보기