진단 통신(UDS) 검증, 무엇을 보고 무엇을 판정하나 — 서비스·NRC·테스트케이스
개정: 2026-10-04. 세션·서비스·타이밍의 프로젝트별 조건과 CANoe 대기시간, 검증 프로세스의 차이를 정리했습니다.
UDS 진단은 테스터가 요청하고 ECU가 응답하는 클라이언트–서버 통신입니다. 검증에서 중요한 것은 서비스 번호를 외우는 일보다, 올바른 조건으로 요청하고 정해진 응답을 판정하는 일입니다. 응답이 없거나 거부됐다는 사실만으로 ECU 고장을 확정하지 마세요.
1. 주소와 시험 범위부터 정합니다
CAN의 물리 주소 진단은 특정 ECU와 1:1로 대화하고, 기능 주소 진단은 대상 기능에 해당하는 여러 ECU에 요청할 수 있습니다. 요청·응답 ID와 주소 형식은 승인된 진단 사양 및 설명 파일에서 확인합니다. 일반 CAN 메시지에도 주기·이벤트 방식이 있으므로 “일반 메시지는 언제나 주기, 진단은 언제나 응답”으로 단순화하지 않습니다.
기능 주소, 긍정 응답 억제 설정, 서비스별 응답 규칙에 따라 무응답 판정이 달라질 수 있습니다. 처음 시험을 만들 때는 물리 주소, 응답을 기대하는 서비스 하나로 시작한 뒤 범위를 확장하면 원인을 구분하기 쉽습니다. 바이트 포장·분할은 ISO-TP이고, 서비스 허용·응답 내용은 UDS라는 층의 차이도 기억하세요.
2. 기본·확장·프로그래밍 세션은 허용표와 함께 읽습니다
0x10 DiagnosticSessionControl로 진단 세션을 전환합니다. 기본, 확장, 프로그래밍이라는 이름만으로 어떤 읽기·쓰기·루틴이 허용되는지 단정할 수는 없습니다. 서비스·서브기능·DID마다 지원 세션, 보안 수준, 전압·운전 상태 같은 선행조건을 확인해야 합니다. 확장 세션으로 바꿨다고 보호된 쓰기가 모두 열리는 것도 아닙니다.
| 시험 준비 항목 | 확인할 근거 |
|---|---|
| 서비스·DID·길이 | 지원 목록과 요청·응답 정의 |
| 세션·보안 | 서비스 허용표, 보안 접근 조건 |
| P2·P2*·S3 | 승인 진단 사양·설명 파일·세션 전환 응답 등 적용 근거 |
| 주소·패딩 | CAN ID, ISO-TP 주소 형식, 전송 사양 |
S3는 비기본 세션의 비활동 시간 관리와 관련됩니다. 세션을 유지할 때는 허용된 요청이나 0x3E TesterPresent의 사용 조건과 주기를 반영합니다. TesterPresent를 모든 상황에 무조건 추가하거나, 응답 처리 중 임의로 요청을 겹치게 하지 않습니다. 실제 타이머 동작은 적용 사양과 도구 설정을 대조합니다.
3. P2와 시험 함수의 최대 대기는 다른 값입니다
P2는 요청 뒤 진단 응답을 기다리는 기준이고, NRC 0x78 ResponsePending을 받으면 P2*의 확장 대기를 고려합니다. 0x78은 최종 성공·거부가 아니라 처리 중이라는 응답입니다. 반복 대기와 최종 응답의 제한도 적용 사양으로 정합니다. 이 글의 숫자를 모든 프로젝트의 기본값으로 쓰지 않습니다.
Vector의 TestWaitForDiagResponse 안내는 함수에 주는 최대 대기와 진단 계층의 P2/P2 확장 타임아웃을 구분합니다. 함수의 최대 대기가 너무 짧으면 사양에 맞는 ECU도 타임아웃처럼 보일 수 있습니다. 긴 분할 요청은 요청 전송 완료를 확인한 뒤 응답을 기다려야 합니다.
반환값이 “응답 수신”이라고 해도 PASS는 아닙니다. 긍정·거부 종류, 원래 요청 서비스, NRC와 데이터, 응답 시간이 기대값과 맞는지 확인합니다. 진단 계층 타임아웃, 함수 최대 대기 도달, 전송 오류를 보고서에서 서로 다른 원인으로 남기면 분석이 쉬워집니다.
4. 자주 쓰는 서비스와 NRC
| 서비스 | 주요 확인 |
|---|---|
| 0x10 / 0x3E | 세션 전환 / 세션 유지 |
| 0x22 / 0x2E | DID 읽기 / 쓰기와 허용 조건 |
| 0x19 / 0x14 | DTC 정보 읽기 / 허용된 초기화 |
| 0x27 / 0x31 | 보안 접근 / 루틴 제어 |
| 0x11 / 0x85 | 리셋 / DTC 설정 제어 |
긍정 응답 SID는 요청 SID에 0x40을 더한 형태입니다. 거부 응답은 0x7F, 요청 SID, NRC로 읽습니다. 예를 들어 0x13은 길이·형식, 0x22는 조건, 0x31은 범위, 0x33은 보안 접근 관련 거부입니다. 0x7E와 0x7F NRC는 현재 세션에서의 서브기능·서비스 지원과 관련되므로 서로 구분합니다.
NRC는 원인 분석의 출발점이지 책임 판정표가 아닙니다. 의도적으로 잘못된 길이를 보냈다면 0x13이 기대 결과일 수 있고, 올바른 요청이라고 생각했다면 원시 바이트와 사양부터 대조해야 합니다. “거부되면 통과” 대신 어떤 요청 조건에서 어떤 NRC가 나와야 하는지 적으세요.
5. 가상 DID 쓰기 시험을 세 줄로 만듭니다
아래는 교육용 설계이며 실행 결과가 아닙니다. 가상 DID의 허용 범위는 MIN~MAX, 보호된 쓰기 조건은 승인 사양에서 가져온다고 가정합니다. 실제 DID·값·보안 키는 제공하지 않습니다.
| 상황 | 입력·기대값 | 후처리 |
|---|---|---|
| 정상 | 허용 세션·보안·운전 조건에서 범위 내 쓰기. 0x6E와 대상 DID 확인 | 허용된 방법으로 값 확인·원래 설정 복원 |
| 보안 거부 | 다른 조건은 동일하게 두고 잠긴 상태로 요청. 사양의 기대 NRC 확인 | 잘못된 값이 적용되지 않았는지 확인 |
| 경계 | MIN·MAX와 표현 가능한 바로 바깥값. 허용·거부 기준을 각각 기록 | 남은 설정·세션·진단 상태 복원 |
시험 전에는 DTC 등 필요한 증거를 보관하고, 초기화가 승인된 시험인지 확인합니다. 모든 시험 앞에서 무조건 DTC를 지우면 원래 상태를 잃을 수 있습니다. 원래 값, 초기 세션, 요구·DB 버전, 요청·응답 바이트와 시각을 남기고, 설정 변경·루틴 구동은 승인된 시험환경에서만 수행합니다.
6. SWE.4·5·6과 SYS.4·5를 구분합니다
Automotive SPICE 4.0에서 SWE.4는 SW 단위와 상세 설계의 일치, SWE.5는 SW 컴포넌트와 통합의 검증, SWE.6는 통합된 SW와 SW 요구사항의 일치를 봅니다. SYS.4는 시스템 요소의 통합·상호작용, SYS.5는 시스템 요구사항 검증입니다. ECU에 진단기를 붙였다는 장비 구성만으로 프로세스를 결정하지 말고, 무엇을 기준으로 무엇을 검증하는지 적습니다.
공식 근거와 이어서 읽기
- Vector: Diagnostics with CAPL — 주소·S3/P2·TesterPresent 설정
- Vector: TestWaitForDiagResponse — 최대 대기와 진단 타임아웃 구분
- VDA QMC: Automotive SPICE 4.0 — 검증 프로세스 목적
댓글
댓글 쓰기