소프트웨어 정의 차량(SDV), 검증은 어떻게 바뀌나 — V모델에서 DevOps까지
개정: 2026-10-04. V모델과 CI/CD의 관계를 정리하고, 가상 변경 한 건의 검증·승인 흐름을 추가했습니다.
소프트웨어 정의 차량(SDV)은 소프트웨어를 통해 기능을 구현하고 개선하는 차량을 뜻합니다. 양산 뒤 변경은 이전에도 있었지만, 업데이트를 지원하는 차량에서는 변경과 회귀 검증을 지속적으로 연결할 필요가 커집니다. OTA는 무선 업데이트 방식이지, 모든 ECU가 언제든 변경될 수 있다는 뜻은 아닙니다.
1. V모델을 버리는 대신 반복 실행을 붙입니다
V모델은 요구사항·설계와 검증의 대응 관계입니다. 시스템 요구사항은 시스템 검증으로, SW 요구사항은 통합된 SW 검증으로 확인합니다. 요구가 바뀌면 영향받은 설계·시험·추적성도 갱신합니다. 한 번 시험하고 끝내는 모델로 이해하면 안 됩니다.
DevOps는 개발과 운영의 피드백을 연결하는 방식입니다. CI는 코드 통합 때 빌드와 자동 검증을 수행하는 실천이고, CD는 검증한 결과물을 배포 가능한 상태로 준비하거나 배포하는 흐름입니다. 자동차에서는 자동 빌드와 실제 차량 배포 사이에 안전·보안·릴리스 승인이 필요할 수 있습니다. 자동 시험의 성공 표시가 배포 허가를 대신하지는 않습니다.
| 질문 | V모델의 역할 | CI/CD의 역할 |
|---|---|---|
| 무엇을 확인하나? | 요구·설계별 검증 기준 연결 | 선정한 검증을 반복 실행 |
| 변경 후 무엇을 남기나? | 영향·추적성과 결과 근거 | 빌드·환경·시험 실행 이력 |
| 누가 배포를 결정하나? | 프로젝트의 릴리스 절차와 승인권자 | |
2. 가상 예제: 냉각 펌프 명령의 복귀 조건 변경
아래는 교육용 계획이며 실제 고객 사양이나 시험 결과가 아닙니다. 가상 EWP 제어기에서 통신 중단 뒤 메시지 한 개만 돌아와도 정상 명령을 선택하던 기능을 바꾼다고 합시다. 변경 요구 EX-REQ-R2는 “승인된 연속 유효 수신 조건을 만족한 뒤 정상 복귀”입니다. 횟수·간격·대체 명령은 여기서 만들지 않고 요구사항의 변수 N_VALID·T_GAP·CMD_BACKUP을 사용합니다.
- 변경 접수: EX-CR-01에 변경 이유, 적용 ECU·SW 버전, 요구사항 ID와 미확정 조건을 적습니다. 시스템 담당자가 냉각 요구와 대체 명령의 적합성을 먼저 확인합니다.
- 영향 분석: 수신 유효성, 복귀 카운터, 상태머신, 타임아웃, 선택 명령과 진단 보고를 연결합니다. 복귀를 늦추면 냉각 응답도 달라질 수 있으므로 상위 기능을 범위에 포함합니다.
- 검증 선정: 정상 통신, 중단 유지, 복귀 경계, 복귀 도중 무효 메시지를 고릅니다. 변경하지 않은 보호·기동 기능도 공유 코드를 쓰는지 보고 회귀 범위를 정합니다.
3. SIL에서 빠르게, HIL에서 실제 ECU로
SIL은 컴퓨터에서 SW를 실행해 입력·상태·기대 결과를 비교하는 환경입니다. 이 예제에서는 N_VALID 직전과 충족 시점, T_GAP 경계, 중간 오류 때 카운터 처리와 CMD_BACKUP 유지를 반복 확인합니다. 같은 입력을 이전 버전에도 넣으면 달라진 동작을 찾기 쉽습니다. 이전 결과를 곧바로 정답으로 삼지는 않습니다.
HIL은 실제 ECU를 모사 환경에 연결합니다. 선정한 SIL 시험에 더해 실제 통신 수신과 태스크 실행 시점, 전원 재인가 뒤 상태, 명령 출력과 진단 보고를 확인합니다. SIL이 통과했어도 타깃 실행·I/O 문제가 남을 수 있습니다. 실제 유량·열·기계 부하가 쟁점이면 실물 Bench와 모델 상관성 확인도 별도로 계획합니다.
| 단계 | 관측·판정 | 남길 증거 |
|---|---|---|
| SIL | 연속 유효 횟수, 복귀 상태, 선택 명령 | 입력 시나리오·모델·SW 버전·결과 로그 |
| HIL | 수신·태스크 시각과 요구된 전환 시간 | ECU·설정·DB·장비 버전, 원시 Trace와 측정값 |
| 승인 | 범위 충분성, 실패 처리,상위 영향 | 검토 기록·미해결 목록·승인 대상 버전 |
4. 파이프라인의 최소 흐름
“커밋 → 빌드·정적 분석 → 선정한 단위/SIL 검증 → HIL 예약·실행 → 결과 묶음 생성 → 릴리스 검토”로 시작할 수 있습니다. 실패·환경 오류·미실행을 PASS와 구분합니다. HIL 장비가 비어 있지 않으면 승인 대기 상태를 유지하고, 누락된 시험을 성공으로 계산하지 않습니다.
처음부터 모든 시험을 매번 돌리기보다, 변경 영향과 위험으로 선정 규칙을 문서화하세요. 테스트의 입력과 기대값이 같은 잘못된 사양에서 만들어지지 않았는지도 검토합니다. AI가 시험 초안을 만들어도 판정값의 근거와 실행 결과는 사람이 확인해야 합니다.
5. 배포 검토에 가져갈 한 묶음
EX-CR-01 → EX-REQ-R2 → 변경 설계 → 구현·설정 버전 → 선정 시험 ID → 원시 로그 → 판정 → 승인 기록을 연결합니다. 승인 기록에는 대상 바이너리·적용 조건·검토자·승인자·일자·남은 제한을 적습니다. 실제 배포에는 차량·ECU의 업데이트 지원, 안전·보안 요구와 복구 절차도 확인합니다.
필드 데이터를 쓰려면 수집·이용 권한과 보안 조건을 먼저 확인합니다. 발견한 상황을 재현 입력으로 바꾸되, 모델로 재현할 수 없는 부분은 별도 시험으로 남깁니다. SDV 검증의 핵심은 시험 횟수를 늘리는 것이 아니라, 변경마다 필요한 증거를 다시 만들고 같은 버전을 승인하는 일입니다.
처음 맡은 사람이 놓치기 쉬운 승인 공백
빌드한 파일과 HIL에 내려받은 파일이 같은지 식별값으로 확인합니다. 시험 뒤 설정을 바꿨다면 이전 결과를 새 설정의 증거로 그대로 쓰지 않습니다. 요구 ID만 연결하는 것보다 기대값이 그 요구와 일치하는지가 중요합니다. 빠진 조건에는 확인 담당자와 기한을 붙이고, 승인 전까지 미확정으로 보이게 남겨두세요.
가상 변경의 첫 제출물은 거창한 자동화 플랫폼이 아니라 변경 영향표와 선정 시험 목록입니다. 각 시험에 실행 환경, 기대 결과의 출처, 증거 위치와 미실행 사유를 적으면 수동 검토로도 시작할 수 있습니다. 반복되는 부분을 자동화하되, 승인 판단을 숨기는 자동화는 피합니다.
공식 근거와 이어서 읽기
VDA QMC Automotive SPICE 4.0 PRM/PAM: §3.3.4의 생명주기 모델 관계, SWE.4~6 및 SYS.4~5의 검증 목적을 참고했습니다. 위 파이프라인은 교육용 제안이며 표준이 정한 유일한 순서가 아닙니다.
댓글
댓글 쓰기