XiL 검증: MIL, SIL, PIL, HIL 상세 정리
1. 개요
XiL(X-in-the-Loop)은 임베디드 제어 시스템 개발에서 검증 대상(제어기)과 검증 환경(플랜트)을 어떤 형태로 구성하느냐에 따라 검증 단계를 구분하는 프레임워크다. 여기서 Loop는 폐루프(closed-loop) 제어 구조를 의미한다. 제어기(Controller)가 플랜트(Plant, 제어 대상 시스템)에 명령을 내리고, 플랜트의 응답이 다시 제어기로 피드백되는 루프 안에 X를 무엇으로 넣느냐가 각 단계의 차이를 만든다.
| 약어 | 명칭 | Loop 안에 들어가는 것 |
|---|---|---|
| MIL | Model-in-the-Loop | 제어기 모델 |
| SIL | Software-in-the-Loop | 제어기 소프트웨어(코드) |
| PIL | Processor-in-the-Loop | 타겟 프로세서에서 실행되는 코드 |
| HIL | Hardware-in-the-Loop | 실제 하드웨어(ECU) |
핵심 아이디어는 점진적 현실화(progressive realism)다. 개발 초기에는 모든 것을 시뮬레이션으로 구성해 빠르고 저렴하게 반복하고, 단계가 진행될수록 시뮬레이션 요소를 실물로 교체하면서 더 현실적인(그러나 더 비싸고 느린) 환경에서 검증한다. 각 단계는 서로 다른 종류의 결함을 검출하도록 설계되어 있어 상호 대체가 아니라 상호 보완 관계다.
2. V-모델과 XiL의 관계
XiL 단계는 모델 기반 개발(MBD, Model-Based Development)의 V-모델 우측(검증) 단계와 자연스럽게 대응된다.
요구사항 분석 ────────────────────────── 인수/차량 시험 (VIL)
시스템 설계 ────────────────────── 시스템 통합 시험 (HIL)
SW 아키텍처 설계 ─────────── SW 통합 시험 (PIL)
상세 설계/모델링 ────── 단위/모델 시험 (MIL, SIL)
코드 생성/구현
- 좌측(설계)이 내려갈수록 추상화 수준이 낮아지고, 우측(검증)이 올라갈수록 통합 수준과 현실성이 높아진다.
- MBD 환경에서는 Simulink/Stateflow 등으로 작성한 제어 모델이 설계 산출물이자 MIL의 검증 대상이며, 이 모델에서 자동 생성된 C 코드가 SIL 이후 단계의 검증 대상이 된다.
- 따라서 XiL은 같은 테스트 시나리오를 추상화 수준이 다른 구현체에 반복 적용하는 구조를 가지며, 이것이 뒤에서 다룰 back-to-back 테스트의 기반이 된다.
3. MIL (Model-in-the-Loop)
3.1 정의와 구성
제어기와 플랜트가 모두 모델 형태로, 동일한 시뮬레이션 환경(호스트 PC) 안에서 폐루프를 구성한다.
[호스트 PC: 시뮬레이션 환경 (예: Simulink)]
제어기 모델 ←→ 플랜트 모델
- 제어기: Simulink/Stateflow, ASCET, Modelica 등으로 작성한 제어 로직 모델
- 플랜트: 차량 동역학, 엔진, 모터, 배터리 등의 수학적 모델
- 시간: 시뮬레이션 시간(논리적 시간) 기준. 실시간 제약 없음
3.2 목적
- 제어 알고리즘 자체의 논리적 정확성 검증: 제어 전략, 상태 천이, 보호 로직이 요구사항대로 동작하는가
- 제어 성능 평가: 응답성, 오버슈트, 정착 시간, 안정성 등
- 요구사항 기반 테스트 케이스의 조기 작성과 실행 (이후 단계에서 재사용)
- 모델 커버리지 측정: condition, decision, MC/DC 등을 모델 수준에서 측정
3.3 장점과 한계
- 장점: 가장 빠르고 저렴한 반복. 코드와 하드웨어가 없어도 설계 결함을 조기에 발견. 시뮬레이션 시간을 가속할 수 있어 장시간 시나리오도 단시간에 실행 가능.
- 한계: 부동소수점 연산 기반의 이상적 환경이라 코드 수준 결함(고정소수점 오버플로, 자료형 변환 오류 등), 컴파일러 의존성, 실행 시간 문제를 전혀 검출하지 못한다. 플랜트 모델의 충실도(fidelity)가 낮으면 검증 결과의 의미도 제한적이다.
4. SIL (Software-in-the-Loop)
4.1 정의와 구성
제어기 부분을 모델이 아닌 실제 소스 코드(주로 C) 로 교체한다. 코드는 자동 코드 생성(예: Embedded Coder, TargetLink) 또는 수작업으로 작성되며, 호스트 PC의 컴파일러(x86/x64) 로 빌드되어 호스트에서 실행된다. 플랜트는 여전히 시뮬레이션 모델이다.
[호스트 PC]
제어기 코드 (호스트 컴파일 바이너리) ←→ 플랜트 모델
4.2 목적
- 모델-코드 등가성 검증: MIL과 동일한 입력을 주고 출력을 비교(back-to-back). 코드 생성 과정이나 수작업 구현에서 유입된 결함 검출
- 코드 수준 결함 검출: 자료형 문제(고정소수점 스케일링, 포화/랩어라운드), 0으로 나누기, 배열 경계 위반, 초기화 누락 등
- 코드 커버리지 측정: statement, branch, MC/DC 커버리지. ISO 26262, DO-178C 등에서 요구하는 구조적 커버리지 증빙의 핵심 단계
- 정적 분석, 런타임 오류 검사(예: Polyspace, Astree)와 병행되는 경우가 많음
4.3 장점과 한계
- 장점: 하드웨어 없이 코드 검증 가능. CI 파이프라인에 통합해 자동화·대량 반복 실행에 가장 적합한 단계. 시뮬레이션 가속 가능.
- 한계: 호스트 컴파일러와 타겟 컴파일러의 차이를 반영하지 못한다. 워드 크기, 엔디언, 부동소수점 처리 방식, 컴파일러 최적화 차이로 인한 결함은 SIL을 통과해도 남아 있을 수 있다. 실행 시간(타이밍) 검증도 불가능하다.
SIL은 소프트웨어는 진짜, 나머지는 전부 가짜인 단계다. 이 특성 덕분에 테스트 입력 생성, 시나리오 변형, 반복 실행을 소프트웨어적으로 완전히 제어할 수 있어, 자동화된 테스트 생성 연구(퍼징, 탐색 기반 테스트, LLM 기반 시나리오 생성 등)가 주로 SIL 환경을 대상으로 한다.
5. PIL (Processor-in-the-Loop)
5.1 정의와 구성
제어기 코드를 타겟 프로세서용 크로스 컴파일러로 빌드하여 실제 타겟 프로세서(또는 동일 아키텍처의 평가 보드, 명령어 수준 시뮬레이터) 에서 실행한다. 플랜트 모델은 여전히 호스트 PC에서 돌고, 호스트와 타겟은 통신 링크(시리얼, 이더넷, JTAG/디버거 등)로 한 스텝씩 데이터를 주고받는다.
[호스트 PC] [타겟 보드]
플랜트 모델 ←── 통신 링크 ──→ 제어기 코드 (크로스 컴파일)
각 시뮬레이션 스텝마다 호스트가 입력을 전송하고 타겟이 한 스텝 연산 후 출력을 반환하는 lock-step 방식이 일반적이며, 따라서 PIL은 보통 비실시간으로 동작한다 (통신 오버헤드 때문에 실제보다 훨씬 느린 경우가 많다).
5.2 목적
- 타겟 의존 결함 검출: 크로스 컴파일러의 코드 생성 오류·최적화 부작용, 워드 크기/엔디언 차이, 타겟 부동소수점 유닛(FPU) 유무에 따른 수치 차이
- 실행 시간 측정: 함수/태스크 단위 실행 시간 프로파일링, WCET(Worst-Case Execution Time) 추정의 기초 데이터 확보
- 자원 사용량 검증: 스택 사용량, 코드/데이터 메모리 점유율(ROM/RAM footprint)
- SIL과의 back-to-back 비교를 통한 수치 등가성 확인 (허용 오차 기반 비교)
5.3 장점과 한계
- 장점: 실제 타겟 연산 환경을 HIL보다 훨씬 저렴하게 확보. 컴파일러·아키텍처 기인 결함을 HIL 이전에 격리된 형태로 검출.
- 한계: 비실시간이므로 타이밍·동시성 결함(인터럽트 경합, 스케줄링 문제)은 검출 불가. 주변장치(ADC, CAN 컨트롤러 등) I/O 드라이버는 보통 루프 밖에 있어 검증되지 않는다. 통신 오버헤드로 긴 시나리오 실행이 느리다.
6. HIL (Hardware-in-the-Loop)
6.1 정의와 구성
검증 대상이 실제 ECU(양산 또는 양산 동등 하드웨어, 실제 펌웨어 탑재) 가 된다. 대신 플랜트를 실시간 시뮬레이터가 모사하며, ECU의 입출력 핀에 연결되는 센서·액추에이터 신호를 전기적으로 에뮬레이션한다.
[실시간 시뮬레이터] [실제 ECU]
플랜트 모델 (실시간 실행)
+ 신호 I/O 보드 ←── 전기 신호 ──→ 센서 입력 / 액추에이터 출력
+ 버스 시뮬레이션 ←── CAN/LIN/이더넷 ──→ 통신 인터페이스
+ 고장 주입 유닛(FIU)
- 실시간 시뮬레이터: dSPACE SCALEXIO, NI VeriStand/PXI, Vector, Speedgoat, OPAL-RT 등
- 플랜트 모델은 고정 주기(예: 1 ms) 안에 반드시 한 스텝 연산을 끝내야 하는 경성 실시간(hard real-time) 제약을 가진다. 이 때문에 MIL에서 쓰던 고충실도 모델을 단순화해야 하는 경우가 많다.
- 잔여 버스 시뮬레이션(restbus simulation): 실제로 연결되지 않은 다른 ECU들의 통신 메시지를 시뮬레이터가 대신 생성
6.2 목적
- ECU 통합 수준의 시스템 검증: 펌웨어 + OS/스케줄러 + I/O 드라이버 + 하드웨어가 결합된 상태에서의 기능 검증
- 타이밍·실시간 동작 검증: 인터럽트, 태스크 스케줄링, 통신 지연을 포함한 실제 시간 축에서의 동작
- 고장 주입(fault injection) 테스트: 센서 단선/단락, 전원 변동, 통신 오류 등 실차에서 재현하기 위험하거나 불가능한 고장 상황을 안전하게 재현. 진단(DTC) 및 안전 메커니즘 검증의 핵심 수단
- 네트워크/통신 검증: CAN, LIN, FlexRay, 차량 이더넷 프로토콜 적합성과 게이트웨이 동작
- 회귀 시험 자동화: 실차 시험 대비 재현성이 높아 야간 무인 회귀 시험에 활용
6.3 장점과 한계
- 장점: 실차 시험 전 가장 현실적인 검증 환경. 위험·파괴적 시나리오의 안전한 재현. 24시간 자동화 가능.
- 한계: 장비·구축 비용이 높고 셋업 변경이 느리다. 플랜트 모델의 실시간 제약으로 인한 충실도 손실. 전기 신호 에뮬레이션의 한계(실제 물리 부하와의 차이). 실차의 환경 조건(온도, 진동, EMC)은 별도 시험이 필요하다.
7. 단계별 비교
| 항목 | MIL | SIL | PIL | HIL |
|---|---|---|---|---|
| 제어기 | 모델 | 코드(호스트 빌드) | 코드(타겟 빌드) | 실제 ECU |
| 플랜트 | 모델(호스트) | 모델(호스트) | 모델(호스트) | 실시간 시뮬레이터 |
| 실행 환경 | 호스트 PC | 호스트 PC | 타겟 프로세서 | 실제 하드웨어 |
| 시간 개념 | 시뮬레이션 시간 | 시뮬레이션 시간 | 비실시간(lock-step) | 경성 실시간 |
| 주요 검출 결함 | 설계/알고리즘 결함 | 코드 결함, 모델-코드 불일치 | 컴파일러/아키텍처 결함, 실행 시간 | 통합/타이밍/I-O/고장 대응 결함 |
| 커버리지 | 모델 커버리지 | 코드 커버리지(MC/DC) | (보조적) | 요구사항/시나리오 커버리지 |
| 비용 | 최저 | 낮음 | 중간 | 높음 |
| 반복 속도 | 최고(가속 가능) | 높음(CI 적합) | 느림 | 실시간 고정 |
| 자동화 용이성 | 높음 | 최고 | 중간 | 중간(구축 후 높음) |
| 읽는 방법: 왼쪽에서 오른쪽으로 갈수록 현실성은 올라가고, 반복 속도와 결함 격리 능력은 내려간다. 결함을 가장 싸게 고칠 수 있는 단계는 항상 그 결함을 검출할 수 있는 가장 왼쪽 단계다. |
8. Back-to-Back 테스트와 등가성 검증
XiL 구조의 중요한 활용법은 동일한 테스트 벡터를 인접 단계에 적용해 출력을 비교하는 back-to-back(B2B) 테스트다.
- MIL vs SIL: 코드 생성/구현 과정의 결함 검출. 부동소수점 기준이라 비교적 엄격한 허용 오차 적용 가능
- SIL vs PIL: 컴파일러·아키텍처 기인 수치 차이 검출. 타겟 FPU 특성에 따라 허용 오차(tolerance) 설계가 중요
- 비교 기준: 절대 오차, 상대 오차, 또는 두 가지의 조합. 예를 들어 형태의 판정식을 사용 ISO 26262 Part 6에서는 모델 기반 개발 시 back-to-back 비교 테스트를 ASIL C/D에서 강하게 권장(highly recommended)하는 기법으로 분류한다.
9. 표준에서의 위치
- ISO 26262(자동차 기능안전): Part 6(소프트웨어)에서 요구사항 기반 테스트, 인터페이스 테스트, 고장 주입, 자원 사용량 테스트, back-to-back 테스트 등을 ASIL 등급별로 권장. 테스트 환경으로 MIL/SIL/PIL/HIL을 명시적으로 언급하며, 구조적 커버리지(분기, MC/DC) 증빙은 주로 SIL에서, 자원·타이밍은 PIL/HIL에서 확보하는 것이 일반적 매핑이다.
- IEC 61508(일반 기능안전): 시뮬레이션 기반 검증과 고장 주입을 SIL(Safety Integrity Level — 약어가 같지만 전혀 다른 개념이므로 주의) 등급에 따라 권장.
- DO-178C(항공): 타겟 환경에서의 테스트 실행과 구조적 커버리지(레벨 A는 MC/DC)를 요구. 보충 문서 DO-331이 모델 기반 개발·검증을 다룬다.
기능안전 표준의 SIL(Safety Integrity Level) 과 검증 단계의 SIL(Software-in-the-Loop) 은 약어만 같은 무관한 개념이다. 문맥으로 구분해야 하며, 논문 작성 시 첫 등장에서 풀어 쓰는 것이 안전하다.
10. 확장 개념
- VIL(Vehicle-in-the-Loop): 실제 차량을 루프에 넣고 가상 환경(가상 교통, 가상 장애물)과 결합. ADAS/자율주행 검증에 사용
- DIL(Driver-in-the-Loop): 사람 운전자를 루프에 포함하는 시뮬레이터 기반 검증. HMI, 주행감 평가
- FIL(FPGA-in-the-Loop): FPGA 구현 로직을 루프에 포함
- 전력전자 분야에서는 CHIL(Controller-HIL)/PHIL(Power-HIL) 구분도 사용된다. PHIL은 실제 전력 흐름까지 에뮬레이션한다.