2026년 업데이트된 Processor-in-the-Loop PiL 테스트에 관한 최신 인사이트

자율주행(AD) 및 첨단 운전자 보조 시스템(ADAS)이 고도화됨에 따라 차량 내 소프트웨어는 단순한 기능 구현을 넘어 실시간 제어, 하드웨어 자원 관리, 그리고 안전 무결성 보장이라는 복합적인 역할을 수행하게 되었습니다. 특히 ECU 및 임베디드 프로세서 상에서 실행되는 제어 소프트웨어는 차량의 실제 동작과 직접적으로 연결되므로, 코드가 하드웨어 환경에서 어떻게 동작하는지를 검증하는 과정은 개발 전반에서 핵심적인 단계로 자리 잡고 있습니다.

이러한 배경에서 Processor-in-the-Loop PiL 테스트는 모델 기반 설계 흐름 속에서 생성된 코드가 실제 타깃 프로세서에서 의도한 대로 실행되는지 검증하는 필수적인 방법론으로 활용되고 있습니다. PIL 테스트는 컴파일러, 데이터 타입, 실행 시간, 메모리 제약 등 시뮬레이션 환경에서는 드러나지 않는 하드웨어 종속적인 요소를 조기에 식별할 수 있도록 지원함으로써, 시스템 통합 단계에서 발생할 수 있는 리스크를 효과적으로 줄여줍니다.

본 글에서 LTS Group은 자동차 소프트웨어 개발 관점에서 PIL 테스트의 개념, 활용 가치 및 주요 적용 시나리오에 대한 인사이트를 공유하고자 합니다. AD/ADAS 및 차세대 ECU 개발을 고려하고 계신 분들께 실질적인 참고 자료가 되기를 바랍니다.

Processor-in-the-Loop PiL 테스트란 무엇입니까? 

PiL(Process-in-the-Loop) 테스트는 전자 제어 장치(ECU)에 나중에 사용될 프로세서 위에서 임베디드 소프트웨어를 테스트하고 검증하는 것을 의미합니다. 알고리즘과 기능은 보통 개발 환경 내 PC에서 C, C++ 언어를 직접 사용하거나 Simulink, TargetLink, ASCET 또는 ASCET-DEVELOPER 모델과 같은 모델 기반 방식으로 개발됩니다.

생성된 C/C++ 코드는 차량 내 ECU에 사용될 프로세서에 맞는 타겟 컴파일러로 컴파일되어야 합니다. PiL 테스트는 이렇게 컴파일된 코드가 타겟 프로세서에서 제대로 작동하는지 확인하기 위해 수행됩니다.

PiL 테스트를 위한 제어 알고리즘은 주로 평가 보드에서 실행되지만 때로는 실제 ECU에서 실행되기도 합니다. 두 가지 경우 모두 SiL(Software-in-the-Loop) 테스트와 달리 PC가 아닌 컨트롤러에 사용되는 실제 프로세서를 활용합니다. 타겟 프로세서를 사용함으로써 컴파일러 오류를 감지할 수 있다는 장점이 있습니다.

PiL 테스트에서 ‘In-the-loop’는 컨트롤러가 실제 하드웨어에 내장되고 테스트 대상 소프트웨어의 환경이 시뮬레이션됨을 의미합니다. PiL 테스트에서는 MiL(Model-in-the-Loop), SiL, HiL과 같은 환경 모델을 타겟 프로세서에 내장하는 것이 복잡하거나 불가능하므로, 이러한 환경 모델은 흔히 사용되지 않습니다. 환경 모델이 프로세서와 함께 사용되는 경우에는 보통 HiL(Hardware-in-the-Loop) 테스트라고 지칭합니다.

PIL 테스트는 자동차 테스트 워크플로우에서 SiL (Software-in-the-Loop) 테스트 이후, HIL 테스트 이전에 수행되며 생성된 코드의 타겟 프로세서별 검증을 목표로 합니다. 이 테스트는 전체 하드웨어 리그가 필요 없이 실제 ECU 환경에서 타이밍, 메모리 사용량, 컴파일러 최적화와 같은 프로세서 의존성에 대한 소프트웨어 검증이 필요할 때 사용됩니다.

• SiL 후 코드 생성

PIL은 모델로부터 코드(예: Simulink에서 C 코드)가 생성된 직후에 배포되어 수치적 동등성을 확인하고, 호스트 기반 SiL 시뮬레이션에서 놓칠 수 있는 타겟별 불일치를 포착하는 데 사용됩니다. 이 단계는 ADAS 알고리즘의 모델 기반 설계에서 통합 테스트 이전에 컴파일된 바이너리가 예상되는 동작과 일치하는지 확인하는 데 필수적입니다.

• 하드웨어 종속성 검사 

AUTOSAR BSW 또는 존(Zonal) 컨트롤러의 CI/CD 파이프라인에서 엔디언(endianness), 인터럽트 처리 또는 RTOS 상호작용과 같은 플랫폼 효과를 평가할 때 PIL을 적용합니다. 이는 평가 보드에서의 유닛/통합 테스트에 이상적이며, 고비용의 HIL 수정 작업을 피하기 위해 문제를 조기에 발견하는 데 유용합니다.

• HIL 전 최적화

PIL은 HIL 전에 실행되어 실제 프로세서 부하에서 코드 효율성을 최적화하고 타이밍 병목 현상을 디버그하며, ISO 26262 추적성을 유지하면서 SDV(Software-Defined Vehicle) 기능 배포를 가속화합니다. 다만, 하드웨어를 조기에 사용할 수 없거나 SiL에 더 적합한 순수 알고리즘 검증의 경우에는 PIL을 건너뛸 수 있습니다.

MIL, SIL, HIL, PIL 비교 

MIL, SIL, PIL, HIL은 모델 기반 설계(MBD)의 순차적인 테스트 단계로, 순수 소프트웨어 시뮬레이션에서 실제 하드웨어 상호작용으로 점진적으로 나아갑니다.

• MIL(Model-in-the-Loop)은 알고리즘 모델 자체(초기 단계)를 테스트
• SIL(Software-in-the-Loop)은 컴파일된 코드를 PC에서 테스트
• PIL(Processor-in-the-Loop)은 타겟 프로세서에서 코드를 테스트
• HIL(Hardware-in-the-Loop)은 실제 ECU를 시뮬레이션된 플랜트와 통합하여 최종 검증을 수행하며, 로직 오류(MIL)부터 하드웨어 특정 타이밍 및 I/O(HIL)에 이르는 다양한 문제를 포착함.

구체적인 비교는 다음과 같습니다.

특징	MIL (Model-in-the-Loop)	SIL (Software-in-the-Loop)	PIL (Processor-in-the-Loop)	HIL (Hardware-in-the-Loop)
테스트 대상	알고리즘 모델 자체 (예: Simulink).	호스트 PC에서 생성된 프로덕션 코드.	타겟 프로세서(예: ECU 칩)에서 실행되는 생성 코드.	실제 ECU (소프트웨어 및 하드웨어)가 실시간 플랜트 시뮬레이션에 연결됨.
환경	완전히 시뮬레이션됨 (가상).	PC에서 시뮬레이션된 플랜트 모델.	시뮬레이션된 플랜트 모델이지만 코드는 타겟 프로세서에서 실행.	실제 하드웨어 (ECU)가 시뮬레이션된 환경과 상호작용.
주요 초점	알고리즘 로직, 초기 개념적 오류.	코드 기능, 기본적인 코드 커버리지.	프로세서/컴파일러 관련 문제, 타이밍, 성능.	실시간 동작, I/O 인터페이스, 전체 시스템 통합.
정확도/현실성	가장 낮음.	중간 (PC 실행).	높음 (타겟 프로세서).	가장 높음 (실제 하드웨어, 시뮬레이션 환경).
비용/복잡성	낮음.	낮음-중간.	중간.	높음 (전용 하드웨어 필요).

PiL 테스트의 중요성

타겟 프로세서에서 자동 생성 코드의 정확성 검증

PiL 테스트는 컴파일된 프로덕션 코드를 타겟 마이크로프로세서에서 직접 실행하여, 참조 모델과 실제 실행 코드 간의 기능적 동등성을 확인합니다. 모델 기반 설계(Model-Based Design) 워크플로우에서 흔히 발생하는 불일치는 제어 로직 자체보다는 코드 생성, 컴파일러 최적화, 고정 소수점 스케일링(fixed-point scaling) 및 워드 길이 과정에서 발생합니다.

PiL은 Model → Code → Execution 체인이 일관성을 유지하고 있음을 입증하는 매우 중요한 검증 단계입니다. 이는 MiL 및 SiL 테스트만으로는 완벽하게 보장하기 어렵습니다. 따라서 PiL은 ISO 26262와 같은 기능 안전 표준의 소프트웨어 검증 요구사항을 충족하기 위한 핵심적인 기술 기반을 제공합니다.

마이크로프로세서 아키텍처 특유의 오류 조기 감지

SiL 테스트와 달리, PiL은 코드를 실제 CPU의 모든 특성을 가진 실행 환경에 배치하여 오버플로우, 반올림 오류, 엔디언(endianness), 정수 동작(integer behavior) 및 실행 순서와 같이 처리 하드웨어 수준에서만 나타나는 오류를 노출합니다.

이러한 오류가 HiL 또는 ECU 통합 단계에서 늦게 발견될 경우, 수정 비용이 매우 커지고 개발 지연 위험이 발생합니다. 따라서 PiL은 “조기 기술 필터” 역할을 하여, 오류가 더 복잡한 시스템 통합 요소에 의해 가려지기 전에 순수한 소프트웨어 오류를 분리하고 처리할 수 있게 합니다.

HiL 및 시스템 통합 단계에서의 위험 및 비용 절감

PiL의 가장 큰 전략적 가치는 HiL 단계로 진입하기 전에 소프트웨어 계층을 정화함으로써 테스트 벤치 점유 시간을 단축하고 후반 디버깅 비용을 대폭 절감하는 데 있습니다. PiL에서 로직, 코드 생성 및 프로세서 관련 오류가 처리되면, HiL은 타이밍, I/O 및 시스템 상호작용 검증이라는 본연의 역할에 집중할 수 있습니다.

현대적인 개발 환경(CI/CD, Agile, SDV)에서 PiL은 타겟 CPU 기반 테스트 자동화도 지원하여 소프트웨어와 하드웨어의 병렬 개발을 가능하게 함으로써 프로젝트 일정과 자원 활용을 최적화합니다.

PiL 테스트 한계

SIL 및 PIL 시뮬레이션의 공통 한계점

소프트웨어 SiL 및 PiL 시뮬레이션 모두에서 Simulink 환경에서 직접 실행하는 대신 자동 생성된 코드 기반의 시뮬레이션 메커니즘으로 인해 여러 근본적인 한계가 존재합니다.

첫째, 시뮬레이션 중 매개변수 조정(tunable parameters) 기능이 크게 제한되며 특히 블록 매개변수나 복잡한 데이터 유형의 경우 더욱 그렇습니다. 이는 다양한 구성을 빠르게 조정하거나 테스트해야 할 때 유연성을 저해합니다.

또한, PiL은 특정 형태의 전역 데이터 저장소만 지원하며 지역 데이터 저장소(local data stores)는 완벽하게 지원하지 않아 복잡한 지역 데이터 구조를 가진 모델에 어려움을 초래합니다. 또 다른 중요한 한계는 PiL이 런타임에 코드의 오류 상태를 확인하지 않는다는 점이며, 이로 인해 타겟에서만 발생하는 런타임 오류를 놓칠 수 있습니다.

게다가 코드 인터페이스 설명 파일(code interface description file)이 없으면 PiL이 시작될 수 없습니다. 블록 수준에서도 제한이 나타나는데, 예를 들어 PiL/SiL 출력을 Merge 블록에 직접 연결하는 것을 허용하지 않으며, Scope 또는 Stop Simulation과 같은 런타임 디스플레이 블록을 완벽하게 지원하지 않습니다. 이러한 요소들로 인해 SiL/PiL은 초기 테스트 단계에서 순수 Simulink 시뮬레이션을 완전히 대체할 수 없습니다.

데이터 및 데이터 유형 관련 한계점

PiL의 중요한 한계 중 하나는 Simulink와 타겟 간의 데이터 유형 및 데이터 통신 지원 기능에 있습니다. 구체적으로 PiL은 인터페이스 경계를 통해 전달되는 멀티워드(multiword) 형식의 고정소수점(fixed-point) 신호를 지원하지 않아, 폭이 넓거나 특수한 산술 표현을 사용하는 모델에 어려움을 줍니다. 마찬가지로 32비트보다 넓은 고정소수점 유형은 타겟 하드웨어 아키텍처와 호환되지 않을 경우 오류를 일으키거나 일관성 없는 결과를 초래할 수 있습니다.

또한, PIL은 불리언(boolean) 유형이 불리언, uint8 또는 int8과 같은 지원되는 유형 중 하나로 정확히 매핑될 것을 요구합니다. 데이터 유형 교체(data type replacement) 구성이 적절하지 않으면 시뮬레이션이 실행되지 않습니다. 특히 Simulink.ImageType과 같은 고급 데이터 유형은 PIL에서 전혀 지원되지 않으므로, PIL을 이미지 처리 또는 컴퓨터 비전 시스템에 적용하는 능력을 제한합니다. 이러한 한계는 하드웨어 근접성과 Simulink 환경의 풍부한 데이터 표현 능력 사이의 절충점을 반영합니다.

일관성 및 시뮬레이션 매개변수 관련 한계점

결과 비교 및 분석 측면에서 PiL은 데이터 대조 과정의 신뢰성에 직접적인 영향을 미치는 한계가 존재합니다. 표준 시뮬레이션과 PiL 간의 결과를 비교하기 위해 시뮬레이션 데이터 인스펙터를 사용할 때, 샘플링 시간의 차이가 발생할 수 있어 신호 매칭이 어려워지고 잘못된 결론으로 이어질 가능성이 있습니다.

또한, PiL의 데이터 로깅 기능은 주로 최상위 모델의 루트 수준 신호로 제한됩니다. 특히 복잡한 서브시스템 내의 많은 내부 신호는 로깅되지 않거나 이름이 변경될 수 있습니다. 이는 기능 안전 표준을 준수해야 하는 프로젝트에서 중요한 요구 사항인 추적성(traceability) 및 모델 내부 동작에 대한 상세 분석 기능을 저해합니다.

SIL과 비교했을 때 PIL의 고유한 한계점

PIL은 SiL에 비해 타겟 하드웨어에서 코드를 실행해야 하므로 특유의 추가적인 한계를 가집니다. 첫째, PIL은 하드웨어 구현 설정에 매우 크게 의존합니다. 바이트 순서(byte order), 워드 크기(word size) 또는 정렬(alignment)과 같은 매개변수가 정확하게 설정되지 않으면 시뮬레이션 오류 또는 예측 불가능한 동작을 초래할 수 있습니다.

이와 더불어 코드 커버리지(code coverage), 스택 사용 프로파일링(stack usage profiling) 또는 특정 성능 측정과 같은 많은 고급 분석 기능은 PiL 실행 시 지원되지 않거나 제한적이며 특히 원격 빌드 시나리오나 임베디드 타겟의 경우 더욱 그렇습니다. 이러한 특성 때문에 PiL은 코드 품질에 대한 심층 분석보다는 하드웨어에서 코드 동작을 검증하는 목적에 더 적합합니다. 즉, PiL은 최종 실행 환경과의 높은 유사성을 달성하기 위해 관측 및 분석 능력을 희생합니다.

출처: Mathworks

산업별 PiL 테스트의 적용 사례

자동차 분야

자동차 분야에서 PiL 테스트는 임베디드 소프트웨어의 검증 및 확인(V&V) 프로세스에서 중요한 역할을 수행하며, 특히 소프트웨어 정의 차량(SDV) 모델로의 전환이 가속화되는 현 시점에서 더욱 중요해지고 있습니다. PiL은 제어 모델로부터 자동으로 생성된 코드를 실제 ECU 또는 타겟 마이크로컨트롤러에서 직접 실행하여 실제 하드웨어 조건에서 제어 알고리즘의 동작을 정확하게 평가할 수 있도록 합니다. 이는 엔진, 변속기, 브레이크, 조향 시스템, ADAS 및 차세대 도메인 컨트롤러와 같이 엄격한 실시간 요구사항을 갖는 시스템에 특히 중요합니다.

MiL 및 SiL과 비교하여 PiL은 고정소수점 연산의 오차, 스케줄링으로 인한 지연, CPU 자원 한계 또는 컴파일러 및 마이크로프로세서 아키텍처와 관련된 오류와 같이 코드가 하드웨어에서 실행될 때만 발생하는 문제들을 조기에 발견하는 데 도움을 줍니다. 따라서 PiL은 HiL 또는 실제 차량 테스트로 넘어가기 전 필수적인 중간 단계가 되어 통합 단계에서의 비용과 위험을 크게 줄여줍니다. ISO 26262나 ASPICE와 같은 안전 표준을 준수하는 프로젝트에서 PiL은 모델에서 생성된 코드가 타겟 ECU에서 올바르게 작동할 수 있음을 입증하는 데 중요한 역할을 하며, 이를 통해 모델 기반 설계 개발 체인의 신뢰도를 높입니다.

항공우주 분야

항공우주 산업에서 PiL 테스트는 비행 제어, 항법 및 비행 관리와 같은 중요한 항공전자 시스템을 검증하는 데 사용됩니다. 이러한 시스템은 극도로 높은 수준의 정확성과 신뢰성을 요구하며, 시간이나 계산상의 작은 오차라도 심각한 결과를 초래할 수 있습니다. PiL은 타겟 하드웨어에서 제어 코드를 직접 테스트하여 다양한 시뮬레이션 비행 시나리오에서 시스템의 성능, 지연 및 동작을 평가할 수 있습니다. 이를 통해 엔지니어링 팀은 실제 비행 테스트를 수행하기 전에 이론적 모델과 하드웨어 구현 간의 차이점을 조기에 발견할 수 있습니다.

의료기기 분야

의료기기, 특히 이식형 기기나 환자 모니터링 시스템의 경우, PiL 테스트는 제어 소프트웨어의 안전성과 신뢰성을 보장하는 데 매우 중요합니다. PiL은 실제 하드웨어에서 코드를 실행함으로써 신호 처리, 실시간 반응 및 센서와의 상호작용을 포함하여 실제 작동 조건과 유사한 환경에서 기기의 동작을 평가하는 데 도움을 줍니다. 이는 개발자들이 성능 또는 하드웨어 자원과 관련된 잠재적 오류를 조기에 발견하고, 동시에 의료 산업의 엄격한 인증 및 규정 준수 요구사항을 충족하도록 지원합니다.

산업 자동화 분야

산업 자동화 분야에서 PiL 테스팅은 PLC(Programmable Logic Controller) 및 기타 산업 제어기에 실행되는 제어 알고리즘을 테스트하고 검증하는 데 적용됩니다. PiL은 스캔 주기, I/O 지연, 자원 한계와 같은 요소가 시스템 성능에 직접적인 영향을 미치는 실제 하드웨어 환경에서 제어 코드의 동작을 평가할 수 있도록 합니다. 이를 통해 엔지니어는 다양한 작동 조건에서 시스템이 안정적으로 설계된 대로 작동하는지 확인한 후 실제 생산 라인에 배포할 수 있습니다.

가전제품 분야

스마트폰, 태블릿, 웨어러블과 같은 가전제품 분야에서 PiL 테스트는 타겟 하드웨어에서 임베디드 소프트웨어를 직접 테스트하여 성능, 안정성 및 자원 소비량을 평가하는 데 기여합니다. PiL은 코드 최적화, 전력 소비 또는 하드웨어 호환성과 관련된 문제점들을 발견하는 데 도움을 주는데, 이러한 문제들은 호스트 시뮬레이션만으로는 정확하게 평가하기 어렵습니다. 덕분에 제조업체는 제품을 시장에 출시하기 전에 품질을 향상시킬 수 있습니다.

자주 묻는 질문 

PIL(Processor-in-the-Loop) 테스트이란 무엇인가요?

PiL(Processor-in-the-Loop) 테스팅은 모델에서 자동 생성된 코드를 프로세서 또는 타겟 하드웨어에서 직접 실행하고 시뮬레이션 환경 및 자극 신호는 Simulink/호스트가 제어하는 테스트 방법론입니다. PIL은 실제 하드웨어에서 코드가 올바르게 동작하는지, 특히 실시간 동작, 데이터 유형 및 시스템 자원 측면에서 확인하는 데 도움을 줍니다.

임베디드 시스템 개발 프로세스에서 PIL 테스팅은 언제 사용해야 하나요?

PiL 테스팅은 알고리즘이 MiL(Model-in-the-Loop)/SIL(Software-in-the-Loop) 단계에서 검증된 후, HiL(Hardware-in-the-Loop) 또는 현장 테스트로 넘어가기 전에 사용해야 합니다. 이 시점은 모델에서 생성된 코드가 타겟 하드웨어에서 올바르게 작동하는지 확인하는 이상적인 시기이며, 특히 자동차 ECU, 항공 전자 장비 또는 의료 기기와 같은 실시간 및 고안전성 시스템에서 중요합니다.

PIL은 MIL, SIL, HIL 테스팅과 어떻게 다른가요?

MIL은 모델 수준에서 알고리즘을 테스트하고 SiL은 호스트에서 실행되는 코드를 테스트하는 반면 PiL은 타겟 하드웨어에서 실행되는 코드를 테스트합니다. 한편, HiL은 플랜트, 센서 및 액추에이터가 시뮬레이션되는 전체 시스템을 테스트합니다. PiL은 SiL과 HiL 사이의 중요한 중간 단계 역할을 하며, 전체 시스템을 통합하기 전에 하드웨어 관련 문제를 조기에 발견하는 데 도움을 줍니다.

마무리 

지금까지 2026년 업데이트된 Process-in-the-Loop PiL 테스트에 관한 인사이트를 살펴보았습니다.

LTS Group은 PiL, SiL, MiL, HiL 테스트 및 자동차 품질 검증에 있어 고객님의 신뢰할 수 있는 파트너입니다. 자동차 소프트웨어 개발 및 테스트  분야에서 9년 동안 깊이 있는 경험을 바탕으로 LTS Group은 자동차 개발자들이 직면하는 어려움을 명확히 이해하고 있습니다. 저희는 시뮬레이션부터 자동 검증에 이르는 포괄적인 테스트 솔루션을 제공하여 고객님이 비용, 복잡한 통합, 전문 인력 부족이라는 장벽을 극복할 수 있도록 돕습니다 .

지금 바로 LTS Group에 문의하시어 탁월한 품질로 고객님의 제품을 더 빠르게 시장에 출시해 보세요.