로봇 SIL은 제어·인지 소프트웨어를 가상 하드웨어와 환경에서 빠르게 반복하는 시험이고, HIL은 실제 제어기나 I/O 일부를 시뮬레이터에 연결해 주기 지연, 버스 오류, 전기적 동작과 장치 의존성을 확인하는 시험입니다. SIL로 시나리오 폭을 확보하고 HIL로 실제 인터페이스와 시간 제약을 좁힌 뒤 실기 시험과 상관성을 확인해야 어느 시험도 현실을 대신한다고 과장하지 않게 됩니다.
아래에서는 용어의 차이를 실제 시스템 경계, 실패 조건과 검증 순서로 나눠 살펴봅니다.
SIL과 HIL의 차이는 시뮬레이터 이름이 아니라 시험 고리 안에 실제 하드웨어가 어디까지 들어오는지다
SIL에서는 로봇 제어 알고리즘과 미들웨어 노드를 일반 컴퓨터 또는 가상 실행 환경에서 돌리고 센서·액추에이터·환경은 모델로 대체합니다. HIL에서는 양산 제어기, 안전 I/O, 네트워크 인터페이스나 드라이브 일부를 실제로 연결하고 나머지 플랜트가 실시간으로 반응합니다.
NIST 제조 로봇 테스트베드는 실제 구성요소와 가상 구성요소의 다양한 조합을 실험에 사용한다고 설명합니다. 따라서 문서에는 SIL·HIL이라는 이름보다 실물인 것, 모사한 것, 생략한 것과 관측 가능한 신호를 블록 경계로 표시하는 편이 정확합니다.
SIL은 빠른 반복과 결정적 재현으로 상태 공간을 넓게 탐색할 때 가장 강하다
수천 개의 지도, 조명, 마찰, 장애물, 지연과 센서 노이즈를 병렬로 바꾸고 동일한 seed로 실패를 재현할 수 있습니다. 코드 변경마다 인터페이스·단위·좌표계·경계값 회귀를 자동화하기에도 좋고 실제 장비 충돌 위험 없이 극단 조건을 넣을 수 있습니다.
그러나 빨리 돈다는 사실이 물리적으로 맞다는 뜻은 아닙니다. 접촉, 케이블 탄성, 카메라 노출, 네트워크 큐, 모터 포화와 열 제한을 단순화했다면 그 가정을 시험 결과와 함께 표시하고, 모델이 다루지 않는 위험은 HIL이나 실기로 넘깁니다.
HIL은 실제 제어기와 I/O가 시간 안에 올바른 신호를 주고받는지 확인하는 시험이다
양산 CPU의 스케줄링, 드라이버 초기화, CAN·EtherCAT·Ethernet 패킷, ADC·엔코더 신호, watchdog, 안전 I/O와 부팅 순서는 데스크톱 SIL에서 드러나지 않을 수 있습니다. HIL은 이러한 실제 경계에 계산 가능한 가상 플랜트를 연결해 장비를 파손하지 않고 지연과 오류를 반복합니다.
HIL이라고 해서 모든 하드웨어가 필요한 것은 아닙니다. 테스트 목적에 맞는 제어기와 I/O만 실제로 두고, 실제 모터가 없는 경우 전기적 부하와 피드백 범위를 에뮬레이터가 재현하는지 명시해야 합니다. HIL 범위 밖의 브레이크 마찰과 구조 진동은 여전히 실기 검증 대상입니다.
| 시험층 | 실제 구성 | 잘 찾는 문제 | 놓치기 쉬운 문제 |
|---|---|---|---|
| SIL | 소프트웨어 실행 환경 | 논리·상태·인터페이스·회귀 | 실제 주기·전기·물리 오차 |
| HIL | 제어기·I/O·통신 일부 | deadline·driver·bus·watchdog | 전체 구조·접촉·현장 환경 |
| 실기 | 로봇·도구·환경 | 물리 상호작용·운영 절차 | 희귀 조합의 넓은 탐색 |
엔지니어링 테스트베드 사진에서 먼저 볼 것은 외형보다 실제와 가상의 연결 지점이다
실제 로버가 있다고 모든 시험이 HIL인 것은 아닙니다. 제어 소프트웨어까지 가상 컴퓨터에서 실행하면 SIL에 가깝고, 실제 제어기의 입출력 단자와 시간 기준이 플랜트 모델에 연결돼 닫힌 고리를 만들 때 HIL의 핵심이 생깁니다.
사진은 실제 이동 하드웨어를 검증하는 테스트베드를 보여 주지만 특정 로봇 HIL 구성의 증거는 아닙니다. 시험 보고서에는 장비 사진보다 하드웨어 목록, 펌웨어 해시, I/O 배선, 시뮬레이터 step, 시간 동기와 신호 스케일을 재현 가능하게 남깁니다.
같은 요구사항을 시험층마다 다른 합격 신호로 번역해야 결과가 이어진다
예를 들어 장애물 감지 후 정지라는 요구는 SIL에서 인지 이벤트부터 제동 명령까지의 논리와 다양한 장면을 보고, HIL에서 실제 제어기 출력 지연과 통신 timeout을 보고, 실기에서 최종 정지 거리와 잔류 위험을 봅니다. 어느 한 층의 통과를 다른 층의 통과로 대신하지 않습니다.
요구사항 ID, 시나리오 ID, 입력 데이터 버전, 관측 신호, 합격 기준과 남은 가정을 하나의 추적표로 묶습니다. 로봇 추론 지연 예산처럼 평균 대신 최악 지연과 분포를 다루는 요구는 시뮬레이션 시간과 실제 벽시계 시간을 구분해야 합니다.
모델 충실도는 높고 낮음 한 단어가 아니라 시험 결정을 바꿀 수 있는 오차로 표현한다
NIST 로봇 신기술 성능 연구는 가상 환경의 정확도와 지연을 평가할 필요가 있다고 지적합니다. 로봇 모델은 질량·관성, 마찰, 액추에이터 포화, 센서 노이즈, 통신 지연과 환경 동역학 중 어떤 항목이 의사결정에 중요한지부터 고릅니다.
모델 파라미터를 실기 데이터로 식별한 날짜와 운용 범위를 남기고, 속도·하중·온도·바닥 조건별 잔차를 비교합니다. 오차가 합격 여유보다 크면 그 시나리오는 SIL에서 합격 판정을 내리지 않고 HIL 또는 실기 확인이 필요한 것으로 분류합니다.
시간 시험에서는 시뮬레이션 step과 실제 제어 주기, 네트워크 지연을 한 축으로 섞지 않는다
SIL은 실제보다 빠르거나 느리게 실행될 수 있어 알고리즘 순서는 맞아도 deadline miss를 숨길 수 있습니다. HIL은 플랜트가 실제 시간에 맞춰 계산되고 제어기의 clock, I/O 샘플링, transport 지연과 jitter가 합격 창 안에 있는지 관측해야 합니다.
로봇 시간 동기화에서 다룬 clock offset과 timestamp 경계를 시험 장비에도 적용합니다. 입력 생성 시각, 제어기 수신 시각, 출력 시각과 플랜트 반응 시각을 같은 기준으로 수집하지 않으면 HIL 지연 측정이 케이블이나 로거 지연과 섞입니다.
고장 주입은 센서 값 하나를 0으로 만드는 것보다 발생 위치와 지속 시간을 통제해야 한다
패킷 손실, 순서 뒤바뀜, stale timestamp, 엔코더 점프, 바이어스 증가, 과전류, actuator saturation, I/O stuck, watchdog reset을 정상 운전의 특정 상태에서 주입합니다. 같은 고장도 가속 중인지 도킹 직전인지에 따라 시스템 반응이 달라집니다.
고장을 simulator 내부에서만 만들면 실제 드라이버와 통신 스택의 진단 경로를 건너뛸 수 있습니다. SIL에서는 논리 범위를 넓게, HIL에서는 실제 핀·버스·드라이버 경계에 가깝게 주입하고, 고장 제거 뒤 복구와 재시작 조건까지 관찰합니다.
시험 증거 점검표는 시나리오 수보다 모델 가정과 실기 상관성을 앞으로 끌어낸다
각 시나리오에는 왜 이 시험층에서 가능한지, 어떤 실제 구성요소가 포함됐는지, 어떤 물리는 모사하지 않았는지, 합격 기준의 시간 기준이 무엇인지 적습니다. 결과 파일에는 코드·모델·파라미터·컨테이너·제어기 펌웨어 해시와 seed를 함께 보존합니다.
같은 장면을 실기에서 소수라도 재현해 주요 출력의 방향과 오차 분포를 비교합니다. 상관성이 깨지면 모델을 조정한 뒤 과거 SIL 회귀를 다시 돌리고, 실기 결과에 맞추느라 특정 사례만 과적합하지 않았는지 별도 조건으로 확인합니다.
SIL과 HIL의 합격 기준은 정확도뿐 아니라 실패를 드러내는 진단 가능성까지 포함한다
안전한 정지를 했더라도 원인 코드가 틀리거나 로그 시간이 어긋나면 현장에서 같은 장애를 구분하기 어렵습니다. 상태 전이, fault code, timeout 원인, fallback 진입, 운영자 알림과 재시작 차단이 요구사항과 일치하는지 시험합니다.
시험 장비 자체의 실패도 분리해야 합니다. 시뮬레이터 overrun, I/O 에뮬레이터 포화, 네트워크 캡처 손실을 로봇 실패로 세지 않도록 장비 health와 시험 유효성 판정을 먼저 하고, 유효하지 않은 실행은 자동 재시도보다 원인 기록 후 제외합니다.
| 검증 항목 | SIL 관측 | HIL 관측 | 실기 확인 |
|---|---|---|---|
| 기능 | 상태·출력·경로 | 실제 I/O·제어기 출력 | 작업 결과 |
| 시간 | 논리 latency·sim step | deadline·jitter·bus delay | 센서-동작 종단 지연 |
| 고장 | 대규모 시나리오 | 핀·버스·driver 반응 | 물리적 안전 상태 |
| 진단 | 로그·fault state | watchdog·HMI·reset | 운영자 절차 |
CI에 넣는 SIL과 예약형 HIL, 제한된 실기 시험은 변경 위험에 따라 실행 빈도를 다르게 둔다
단위·인터페이스·짧은 시나리오 SIL은 커밋마다 실행하고, 긴 확률 시나리오는 야간에 돌릴 수 있습니다. 실제 제어기가 필요한 HIL은 하드웨어 풀과 펌웨어 조합을 예약해 후보 빌드마다 수행하고, 실기는 안전 담당자와 셀 가용 시간을 고려해 릴리스 게이트로 둡니다.
모든 변경을 같은 시험으로 막으면 파이프라인이 느려지고 결국 우회가 생깁니다. 제어 주기, 드라이버, 안전 I/O, 모델·센서 인터페이스를 건드린 변경은 관련 HIL과 실기 세트를 자동 선택하고 단순 UI 변경은 좁은 회귀로 제한합니다.
최종 완료는 SIL 통과율이 아니라 실기와의 오차 경계를 알고 릴리스 결정을 추적할 수 있는 상태다
NIST의 Digital Twins for Robot Systems in Manufacturing은 실제 제어기나 PLC를 디지털 표현과 연결하는 가상 시운전·HIL의 역할을 설명합니다. 동시에 가상 모델은 목적과 충실도 범위를 가진 도구이므로 실제 안전 검증을 자동 대체하지 않습니다.
가상 시운전과 디지털 트윈의 차이를 참고해 SIL·HIL 결과를 설계 탐색, 소프트웨어 회귀, 제어기 통합, 현장 인수 중 어디에 사용할지 분리합니다. 릴리스 기록에는 통과 수치뿐 아니라 미모사 위험, 면제 승인과 실기 상관 결과를 남깁니다.
로봇 SIL과 HIL 시험 차이에서 자주 묻는 질문
시뮬레이터에서 실제 제어기를 쓰면 모두 HIL인가요?
실제 제어기가 닫힌 제어 고리에서 I/O와 시간 제약을 주고받아야 HIL의 의미가 생깁니다. 단순히 로그를 재생하거나 제어기 화면만 연결한 구성은 별도로 설명해야 합니다.
SIL이 충분히 정교하면 실기 시험을 생략할 수 있나요?
아닙니다. 모델이 생략한 접촉, 구조, 열, 전기, 환경과 운영 절차가 남으므로 위험에 맞는 실기 검증과 모델 상관 확인이 필요합니다.
HIL에서는 어떤 고장을 먼저 넣어야 하나요?
위험 평가와 현장 고장 기록에서 빈도·심각도가 큰 통신 timeout, stale 센서, I/O stuck, 제어기 과부하, watchdog과 전원 복구부터 우선합니다.
시뮬레이션 시간과 실제 시간은 왜 구분하나요?
SIL이 실제보다 빠르거나 느리게 실행되면 알고리즘 결과는 맞아도 실제 deadline과 jitter를 검증하지 못할 수 있기 때문입니다.
SIL과 HIL 결과는 어떻게 연결하나요?
같은 요구사항·시나리오 ID 아래 입력, 관측 신호와 합격 기준을 층별로 정의하고 일부 조건을 실기에서 반복해 모델 잔차를 기록합니다.
2026년 7월 확인. 이 글은 NIST 로봇 테스트베드·디지털 트윈 자료를 바탕으로 시험층을 설명한 것이며, 특정 안전 표준의 적합성 평가나 실제 로봇 검증을 대체하지 않습니다.