OPU·EWP 제어기 검증 실무 사례

Automotive SPICE® is a registered trademark of the Verband der Automobilindustrie e.V. (VDA).

이 글은 공개된 Automotive SPICE® 자료를 바탕으로 작성한 개인의 실무 해설이며, VDA 또는 특정 완성차·부품회사의 공식 해석을 의미하지 않습니다. 본문의 제품 구성, 시험조건 및 고장 사례는 이해를 돕기 위해 일반화하거나 가상으로 구성한 예시입니다.

자동차 제어기 개발 현장에서 SYS.4와 SYS.5는 자주 혼동된다.

두 프로세스 모두 완성된 ECU와 HILS, CANoe, 전원공급기, 환경 챔버 등의 장비를 사용할 수 있기 때문이다. 심지어 동일한 시험 입력과 시험 장비를 사용하면서 SYS.4와 SYS.5를 수행하는 경우도 있다.

그러나 두 프로세스는 시험 장비나 시험 장소가 아니라 다음 기준으로 구분해야 한다.

SYS.4는 시스템 구성요소들이 아키텍처 설계대로 통합되었는지 확인하는 프로세스이고, SYS.5는 완성된 시스템이 시스템 요구사항을 만족하는지 확인하는 프로세스다.

이 글은 VDA QMC가 Released 상태로 공개한 Automotive SPICE® PAM 4.0을 기준으로 설명한다.

1. Automotive SPICE® 버전에 따른 명칭 차이

Automotive SPICE® 3.1과 4.0에서는 SYS.4와 SYS.5의 명칭이 다음과 같이 변경되었다.

프로세스	Automotive SPICE® 3.1	Automotive SPICE® 4.0
SYS.4	System Integration and Integration Test	System Integration and Integration Verification
SYS.5	System Qualification Test	System Verification

4.0에서는 ‘Test’보다 범위가 넓은 ‘Verification’이라는 표현을 사용한다.

따라서 동적 시험뿐만 아니라 다음과 같은 다양한 검증 방법을 적용할 수 있다.

시험(Test)
분석(Analysis)
검토(Review)
시뮬레이션(Simulation)
측정 및 비교
정적 검증
기존 검증 증거 활용

회사 또는 고객이 아직 Automotive SPICE® 3.1 용어를 사용하는 경우에는 SYS.4를 ‘시스템 통합시험’, SYS.5를 ‘시스템 인정시험’ 또는 ‘시스템 자격시험’이라고 부르기도 한다.

2. SYS.4와 SYS.5의 핵심 차이

구분	SYS.4	SYS.5
핵심 목적	시스템 구성요소의 통합 상태 검증	완성된 시스템의 요구사항 충족 검증
기준 문서	SYS.3 시스템 아키텍처	SYS.2 시스템 요구사항
주요 대상	구성요소 간 인터페이스와 상호작용	완전히 통합된 최종 시스템
핵심 질문	설계한 구조대로 연결되고 동작하는가?	요구된 기능과 성능을 만족하는가?
주요 관점	신호 흐름, 인터페이스, 타이밍, 동적 상호작용	기능, 성능, 진단, 환경, 내구, EMC
대표 추적성	아키텍처·인터페이스 ↔ 검증 항목 ↔ 결과	시스템 요구사항 ↔ 검증 항목 ↔ 결과
대표 결함	신호 연결 오류, 스케일 오류, 타이밍 불일치	성능 미달, 진단 미동작, 환경조건 미충족
최종 결과	아키텍처에 맞게 통합된 시스템	요구사항을 만족하는 시스템

두 프로세스의 대응 관계는 다음과 같다.

SYS.3 시스템 아키텍처 설계 ↔ SYS.4 시스템 통합 검증
SYS.2 시스템 요구사항 분석 ↔ SYS.5 시스템 검증

쉽게 표현하면 다음과 같다.

SYS.4는 “시스템을 설계한 대로 만들었는가?”를 확인한다.

SYS.5는 “고객이 요구한 시스템을 만들었는가?”를 확인한다.

3. OPU·EWP 시스템 구성 예시

일반적인 전동식 오일펌프 또는 전동식 워터펌프 시스템이 다음 구성요소로 이루어졌다고 가정해 보자.

ECU 하드웨어
MCU와 임베디드 소프트웨어
전원 및 보호회로
인버터와 MOSFET 구동부
모터
펌프 기구부
전류·전압·온도 센서
CAN 또는 LIN 통신
커넥터와 와이어링
차량 또는 HILS 시험환경

SYS.4에서는 이러한 구성요소들을 단계적으로 통합하면서 인터페이스와 상호작용을 확인한다.

SYS.5에서는 모든 구성요소가 통합된 최종 제품을 대상으로 시스템 요구사항 충족 여부를 확인한다.

4. SYS.4에서는 무엇을 하는가?

4.1 시스템을 단계적으로 통합한다

SYS.4는 완성품을 한 번 시험하는 활동이 아니다. 시스템 아키텍처에 따라 구성요소를 정해진 순서로 통합하고, 각 단계에서 인터페이스와 상호작용을 검증하는 활동이다.

예를 들어 다음과 같은 통합 순서를 정의할 수 있다.

ECU 하드웨어에 소프트웨어를 탑재한다.
MCU와 센서 입력 인터페이스를 연결한다.
MCU와 인버터 출력 인터페이스를 연결한다.
ECU와 모터를 통합한다.
모터와 펌프 기구부를 통합한다.
CAN 또는 LIN 통신환경을 연결한다.
HILS 또는 차량 모사환경과 통합한다.
최종 시스템 구성을 완성한다.

각 단계의 시작 전제조건도 정의해야 한다.

예를 들어 ECU와 모터를 통합하기 전에 다음 항목이 완료되어야 할 수 있다.

ECU 하드웨어 기본 검증
소프트웨어 릴리스 승인
모터 단품검증
인터페이스 사양 확정
시험장비와 측정환경 준비
통합 대상의 형상 및 버전 식별

4.2 인터페이스를 검증한다

SYS.4의 핵심은 시스템 구성요소 사이의 연결과 상호작용이다.

OPU·EWP에서는 다음과 같은 항목을 확인할 수 있다.

전압과 전류 센서값이 올바른 단위와 스케일로 전달되는가?
MCU의 PWM 출력이 구동회로에 정확히 전달되는가?
모터의 회전 방향이 설계와 일치하는가?
전류 피드백이 제어주기와 동기화되어 있는가?
통신으로 수신한 회전속도 지령이 내부 제어변수에 정확히 전달되는가?
진단 모듈이 제어 모듈의 상태정보를 정확히 해석하는가?
Sleep, Wake-up 및 Power Latch 상태가 설계된 순서로 전환되는가?
신호가 요구된 순서와 시간 관계에 따라 전달되는가?
구성요소의 상태 변화가 다른 구성요소에 올바르게 반영되는가?

즉, SYS.4에서는 다음을 확인한다.

외부 통신에서 받은 지령이 통신 모듈, 제어 로직, PWM 출력, 인버터 및 모터로 설계된 순서에 따라 정확히 전달되는가?

4.3 SYS.4의 판단 기준

SYS.4 시험의 기대결과는 주로 다음과 같은 SYS.3 산출물에서 도출한다.

시스템 아키텍처 설계서
시스템 인터페이스 사양서
시스템 구성요소 정의
신호 흐름도
상태천이도
동작 시퀀스
타이밍 설계
동적 거동 설계
HW-SW 인터페이스 정의

따라서 시험이 실패하면 다음과 같은 문제를 의심할 수 있다.

인터페이스 정의 오류
신호 스케일 또는 단위 불일치
신호 연결 방향 오류
통신 데이터 해석 오류
제어주기 또는 타이밍 불일치
상태천이 순서 오류
구성요소 간 초기화 순서 오류
아키텍처 설계와 실제 구현의 불일치

5. SYS.5에서는 무엇을 하는가?

SYS.5에서는 완전히 통합된 시스템이 시스템 요구사항을 만족하는지 검증한다.

OPU·EWP를 예로 들면 다음과 같은 요구사항을 확인할 수 있다.

5.1 기능 요구사항

규정된 운전모드에서 모터가 정상적으로 기동해야 한다.
외부에서 수신한 지령에 따라 요구된 동작을 수행해야 한다.
정상운전, 제한운전 및 고장모드가 정의대로 전환되어야 한다.
Sleep과 Wake-up 기능이 요구조건에 따라 동작해야 한다.
전원 차단 후 필요한 종료 동작을 수행해야 한다.

5.2 성능 요구사항

규정된 시간 안에 목표 회전속도에 도달해야 한다.
정상상태의 회전속도 오차가 허용범위 이내여야 한다.
요구된 유량과 압력을 만족해야 한다.
소비전류와 출력이 규정 범위 안에 있어야 한다.
부하가 변화하더라도 요구된 응답성능을 유지해야 한다.

5.3 진단 요구사항

과전압과 저전압을 정확히 감지해야 한다.
과전류와 과온도 상태를 감지하고 보호동작을 수행해야 한다.
모터 구속 또는 기동 실패를 감지해야 한다.
통신 메시지 미수신 상태를 감지해야 한다.
규정된 재시도 후 고장을 확정해야 한다.
고장 해제조건을 만족하면 정상상태로 복귀해야 한다.
필요한 DTC와 고장정보를 저장해야 한다.

5.4 환경 및 내구 요구사항

규정된 저온과 고온 조건에서 동작해야 한다.
동작전압 범위에서 요구성능을 만족해야 한다.
진동, 충격 및 내구 조건을 만족해야 한다.
전자파 적합성 요구사항을 만족해야 한다.
장시간 운전 후에도 기능과 성능을 유지해야 한다.

SYS.5에서 확인하는 핵심 질문은 다음과 같다.

최종 OPU·EWP 시스템이 고객과 시스템 요구사항에 정의된 기능, 성능, 진단 및 환경조건을 만족하는가?

5.5 SYS.5의 판단 기준

SYS.5 시험의 기대결과는 주로 다음과 같은 SYS.2 산출물에서 도출한다.

시스템 요구사항 사양서
고객 요구사항
공개가 허용된 관련 표준 및 법규
기능 요구사항
성능 요구사항
통신 요구사항
진단 요구사항
환경 및 내구 요구사항
안전 및 보호 요구사항

6. 같은 시험이 SYS.4와 SYS.5에 모두 사용될 수 있다

현장에서 가장 많이 혼동하는 부분이다.

예를 들어 외부 통신을 통해 목표 회전속도를 지령하고 실제 모터 회전속도를 측정하는 시험이 있다고 가정해 보자.

SYS.4에서의 시험 목적

통신 수신값이 내부 제어변수에 정확히 전달되는가?
신호의 단위와 스케일이 올바른가?
제어 로직의 출력이 PWM 모듈에 정확히 전달되는가?
ECU와 모터 사이의 신호 흐름이 아키텍처와 일치하는가?
제어주기와 신호 전달 타이밍이 설계와 일치하는가?

이 시험의 기준은 시스템 아키텍처와 인터페이스 설계다.

SYS.5에서의 시험 목적

시스템이 요구된 시간 안에 목표 회전속도에 도달하는가?
정상상태 오차가 시스템 요구범위 이내인가?
규정된 전압, 온도 및 부하 조건에서 성능을 만족하는가?
목표 회전속도를 추종하지 못할 때 진단기능이 요구대로 동작하는가?

이 시험의 기준은 시스템 요구사항이다.

따라서 다음과 같이 정리할 수 있다.

같은 장비와 같은 시험 입력을 사용하더라도 검증 목적, 판단 기준 및 추적 대상에 따라 SYS.4와 SYS.5가 달라진다.

7. 고장 사례로 구분하는 방법

다음 사례는 특정 프로젝트의 실제 고장이 아니라 프로세스 구분을 위한 가상의 예시다.

사례 1. 통신 지령은 정상인데 모터가 반대 방향으로 회전한다

다음과 같은 원인이 있을 수 있다.

모터 상 연결 오류
회전 방향 설정 오류
위치신호 해석 오류
PWM 출력 순서 오류
ECU와 모터 간 인터페이스 불일치

이는 시스템 구성요소 간 인터페이스와 상호작용 문제이므로 SYS.4 성격이 강하다.

현장 노트

이 현상은 실제로 겪었습니다. 통신 지령도 수신 데이터도 정상이었는데 모터가 반대로 돌았고, 원인은 결선이나 극성이 아니라 제어 로직의 부호 오류였습니다. 통신 단계 확인만으로는 드러나지 않았고, Bench에서 실물을 돌려보고 나서야 확인됐습니다. 그 뒤로는 부호와 극성 정의를 인터페이스 문서에 명시하도록 했습니다.

사례 2. 저온·저전압 조건에서 목표 회전속도에 도달하지 못한다

시스템 요구사항에 저온·저전압 성능이 정의되어 있다면 우선 SYS.5 부적합으로 판단할 수 있다.

그러나 원인 분석 과정에서 다음 문제가 발견될 수 있다.

전압 측정 스케일 오류
전류 제한값 전달 오류
제어주기 불일치
SW와 구동회로 간 인터페이스 문제
모터 파라미터 적용 오류

이러한 원인은 SYS.4, SWE.5, SWE.4 또는 하드웨어 검증 영역에서 확인할 수 있다.

즉, SYS.5에서 최종 제품의 증상이 발견되고, 하위 프로세스에서 근본원인을 찾는 구조가 될 수 있다.

현장 노트

이 항목도 실제로 겪었습니다. 상온에서는 목표 회전속도에 문제없이 도달했는데, 저온 챔버에서 시험해 보니 저전압 조건에서 출력 토크가 부족해 목표에 도달하지 못했습니다. 상온 시험만으로는 드러나지 않는 문제였습니다. 그 뒤로는 저온과 저전압을 조합한 조건을 필수 시험 항목에 넣었습니다.

사례 3. 고우선순위 Task가 다른 Task를 선점한다

시스템 아키텍처에 Task 동작, 우선순위, 타이밍 및 동적 거동이 정의되어 있다면 해당 설계와 실제 동작의 일치 여부는 SYS.4 관점에서 확인할 수 있다.

이러한 선점 동작으로 인해 최종 제어 응답시간이나 진단시간 요구사항을 만족하지 못한다면 SYS.5에도 영향을 줄 수 있다.

현장 노트

이 현상도 겪은 적이 있습니다. 원인은 인터럽트가 한꺼번에 몰리면서 처리가 지연된 것이었고, HIL 통합시험에서 확인됐습니다. 그 뒤로는 기능이 동작하는지만 보지 않고, CPU 사용량과 주기 지연 같은 자원 사용량을 별도 검증 항목으로 관리하고 있습니다.

8. SYS.4 실무 산출물

SYS.4에서는 일반적으로 다음과 같은 정보와 증거가 필요하다.

시스템 통합 순서
통합 단계별 전제조건
시스템 통합 검증 계획
통합 검증 방법
시스템 아키텍처 및 인터페이스 사양
통합 단계별 검증 항목
합격·불합격 판정 기준
시험환경 및 장비 구성
시험 데이터와 로그
회귀검증 선정 기준
부적합 및 문제관리 기록
검증 결과 요약
관계자 결과 공유 기록

추적성은 다음 구조로 관리하는 것이 좋다.

시스템 아키텍처·인터페이스 → SYS.4 검증 항목 → SYS.4 검증 결과

단순히 링크만 연결해서는 충분하지 않다. 아키텍처 설계 내용과 시험조건, 입력, 기대결과 및 판정기준이 서로 일치하는지도 검토해야 한다.

9. SYS.5 실무 산출물

SYS.5에서는 일반적으로 다음과 같은 정보와 증거가 필요하다.

시스템 검증 계획
시스템 요구사항 사양서
시스템 검증 방법
기능 및 비기능 검증 항목
합격·불합격 판정 기준
시험환경과 환경조건
릴리스별 검증 항목 선정 근거
회귀검증 선정 기준
시험 데이터와 로그
요구사항 커버리지
부적합과 영향 분석
미해결 문제 및 제한사항
시스템 검증 결과보고서
관계자 결과 공유 기록

추적성은 다음 구조로 관리하는 것이 좋다.

시스템 요구사항 → SYS.5 검증 항목 → SYS.5 검증 결과

SYS.5 완료 여부는 시험 개수만으로 판단해서는 안 된다. 해당 릴리스 범위에 포함된 시스템 요구사항이 충분히 검증되었는지 확인해야 한다.

10. SYS.4와 SYS.5의 Entry·Exit 기준

SYS.4 Entry 기준 예시

통합 대상 구성요소의 버전이 식별되어 있다.
구성요소별 선행 검증이 완료되어 있다.
시스템 아키텍처와 인터페이스가 승인되어 있다.
통합 순서와 전제조건이 정의되어 있다.
시험환경과 측정장비가 준비되어 있다.
검증 항목과 판정기준이 정의되어 있다.

SYS.4 Exit 기준 예시

계획된 구성요소가 모두 통합되어 있다.
주요 인터페이스와 동적 상호작용이 검증되어 있다.
검증 결과와 로그가 저장되어 있다.
발견된 문제점이 등록되고 영향이 분석되어 있다.
통합된 시스템의 형상과 버전이 식별되어 있다.
SYS.5를 시작할 수 있는 상태인지 판단되어 있다.

SYS.5 Entry 기준 예시

SYS.4 통합 검증이 완료되어 있다.
최종 시스템 구성이 식별되어 있다.
시험 대상 소프트웨어와 하드웨어 버전이 확정되어 있다.
시스템 요구사항이 승인되어 있다.
릴리스 범위와 검증 범위가 정의되어 있다.
시험환경과 검증 항목이 준비되어 있다.

SYS.5 Exit 기준 예시

릴리스 범위의 시스템 요구사항이 검증되어 있다.
요구사항과 결과의 양방향 추적성이 확보되어 있다.
시험 결과와 원본 로그가 보관되어 있다.
미해결 문제의 제품 영향이 평가되어 있다.
검증 결과가 관계자에게 공유되어 있다.
출하 또는 고객 제출 가능 여부가 판단되어 있다.

11. 실무에서 자주 발생하는 오해

“HILS 시험은 모두 SYS.5다”

그렇지 않다. HILS는 검증 환경일 뿐이다.

시스템 아키텍처와 인터페이스를 확인하면 SYS.4
시스템 요구사항 충족 여부를 확인하면 SYS.5

“SYS.4는 부품을 조립하는 활동이다”

단순 조립만으로는 SYS.4가 완성되지 않는다.

통합 순서를 정의하고 각 단계에서 인터페이스, 신호 흐름, 타이밍 및 동적 상호작용을 검증해야 한다.

“SYS.5는 차량시험만 해당한다”

SYS.5는 다음과 같은 다양한 환경에서 수행할 수 있다.

시스템 시험벤치
HILS
환경 챔버
EMC 시험장
실차 또는 시험차량

중요한 것은 시험 장소가 아니라 완성된 시스템의 요구사항 충족 여부를 입증하는 것이다.

“시험 결과가 PASS이면 추적성은 필요 없다”

PASS 결과만으로는 어떤 요구사항 또는 아키텍처를 검증했는지 확인하기 어렵다.

검증 대상, 시험조건, 기대결과, 실제결과, 판정 및 대상 버전이 연결되어야 한다.

“SYS.4와 SYS.5는 시험 케이스를 반드시 완전히 분리해야 한다”

동일한 시험 절차나 자동화 스크립트를 재사용할 수 있다.

다만 다음 항목은 구분해야 한다.

검증 목적
기준 문서
추적 대상
기대결과
판정 근거
결과보고 범위

12. SYS.4와 SYS.5를 빠르게 판별하는 방법

시험 항목이 어느 프로세스에 해당하는지 헷갈릴 때는 다음 질문을 사용하면 된다.

이 검증 항목의 기대결과와 판정기준을 어느 문서에서 가져왔는가?

판정기준의 출처	해당 프로세스
SYS.2 시스템 요구사항	SYS.5
SYS.3 시스템 아키텍처·인터페이스	SYS.4
SWE.1 소프트웨어 요구사항	SWE.6
SWE.2 소프트웨어 아키텍처	SWE.5
SWE.3 상세설계·소프트웨어 유닛 설계	SWE.4

시험 제목이나 장비명만으로 프로세스를 구분하면 오류가 발생하기 쉽다.

예를 들어 시험 제목이 ‘CAN 통신시험’이라고 하더라도 다음과 같이 구분될 수 있다.

CAN 데이터가 내부 모듈에 정확히 전달되는지 확인 → SYS.4 또는 SWE.5
최종 ECU의 CAN 기능이 시스템 요구사항을 만족하는지 확인 → SYS.5
CAN 소프트웨어 요구사항 충족 여부를 확인 → SWE.6

13. 검증팀이 사용할 수 있는 실무 체크리스트

SYS.4 체크리스트

통합 대상과 순서가 정의되어 있는가?
통합 단계별 전제조건이 있는가?
SYS.3 아키텍처와 인터페이스에서 검증 항목을 도출했는가?
신호 흐름과 데이터 해석을 확인했는가?
타이밍과 동적 상호작용을 확인했는가?
변경 시 회귀검증 범위를 선정했는가?
아키텍처·검증 항목·결과의 추적성이 있는가?
시험 대상의 HW·SW 버전이 식별되어 있는가?
결과와 원본 로그가 보관되어 있는가?
부적합이 문제관리 프로세스와 연결되어 있는가?

SYS.5 체크리스트

SYS.4가 완료된 통합 시스템을 사용했는가?
SYS.2 시스템 요구사항에서 검증 항목을 도출했는가?
기능·성능·진단·환경 요구사항을 포함했는가?
릴리스 범위에 맞게 검증 항목을 선정했는가?
변경에 따른 회귀검증 범위를 정의했는가?
요구사항·검증 항목·결과의 추적성이 있는가?
시험조건과 판정기준이 명확한가?
시험 대상의 HW·SW 버전이 식별되어 있는가?
미해결 문제의 제품 영향을 평가했는가?
최종 결과가 출하 또는 릴리스 판단에 활용되었는가?

14. AI 활용: SYS.4·SYS.5 검증에서 안전하게 쓰는 방법

AI 활용 예시: 시험 데이터·요구사항·검증 증거를 함께 검토하는 엔지니어링 환경

AI는 SYS.4·SYS.5 검증의 초안 작성·누락 탐색·반복 작업 정리에 특히 유용하다. 다만 AI의 출력은 검증 증거 자체가 아니며, 승인된 요구사항·아키텍처·원본 로그와 담당 엔지니어의 검토가 반드시 필요하다.

활용 업무	AI가 도울 수 있는 일	사람이 확인할 일
SYS.4	인터페이스 표에서 신호·단위·방향·타이밍 점검표 초안 생성	실제 아키텍처, 인터페이스 버전, 예외 조건과 판정 기준
SYS.5	요구사항에서 정상·경계·고장 조건의 시험 후보와 추적성 누락 후보 생성	요구사항 해석, 안전 영향, 실제 시험 결과 및 승인
결과 분석	로그 요약, 이상 구간 후보, 보고서 초안 및 변경 영향 질문 정리	원본 로그의 재현성, 인과관계, 결론과 고객 제출 내용

권장 입력 방식: 실제 고객명·차종·보안키·회로도·비공개 사양은 제거하거나 익명화한 뒤, 대상 프로세스·입력자료·출력 형식·제외 범위·사람의 검토 항목을 명시한다.

15. FAQ

Q1. HIL에서 수행하면 모두 SYS.5인가요?

아니다. HIL은 시험환경이다. SYS.3 아키텍처와 인터페이스의 통합 상태를 판정하면 SYS.4이고, SYS.2 시스템 요구사항의 충족을 판정하면 SYS.5이다.

Q2. 같은 시험 절차를 SYS.4와 SYS.5에 재사용할 수 있나요?

가능하다. 다만 검증 목적, 기준 문서, 추적 대상, 기대결과와 결과보고 범위를 각각 구분해야 한다.

Q3. SYS.5는 실차에서만 할 수 있나요?

아니다. 시스템 시험벤치, HIL, 환경 챔버, EMC 시험장, 실차 등 요구사항을 입증할 수 있는 적절한 환경에서 수행할 수 있다.

Q4. AI가 만든 테스트케이스를 그대로 사용해도 되나요?

안 된다. AI 결과는 초안이다. 요구사항·안전 분석·인터페이스·시험환경·실제 측정값을 담당 엔지니어가 검토해 승인해야 한다.

Q5. SYS.4와 SYS.5를 가장 빠르게 구분하는 질문은 무엇인가요?

“판정기준을 SYS.3 아키텍처·인터페이스에서 가져왔는가, SYS.2 시스템 요구사항에서 가져왔는가?”를 확인하면 된다. 전자는 SYS.4, 후자는 SYS.5이다.

16. 결론

SYS.4와 SYS.5의 가장 중요한 차이는 시험 장비나 시험 장소가 아니다.

검증 대상과 판단 기준이 다르다.

SYS.4는 시스템 구성요소들이 SYS.3 아키텍처와 인터페이스 설계에 맞게 통합되었는지를 확인한다.

SYS.5는 완전히 통합된 시스템이 SYS.2 시스템 요구사항을 만족하는지를 확인한다.

실무적으로는 다음 질문만 기억해도 두 프로세스를 상당히 명확하게 구분할 수 있다.

“이 시험으로 아키텍처의 연결과 상호작용을 입증하려는가, 아니면 최종 시스템 요구사항의 충족을 입증하려는가?”

전자는 SYS.4이고 후자는 SYS.5다.

참고자료

VDA QMC, Automotive SPICE® Process Reference Model / Process Assessment Model, Version 4.0
VDA QMC Automotive SPICE® 공식 페이지
[Automotive SPICE® PAM 4.0 공식 문서](https://vda-qmc.de/wp-content/uploads/2023/12/Automotive-SPICE-PAM-v40.pdf)

이전 글
← ASPICE SYS.4와 SYS.5 차이(1): 시스템 통합 검증과 시스템 검증 실무 가이드