테마
07. 진단통신과 UDS 기본 구조
학습 목표
- 진단통신이 등장한 배경과 주요 기능을 설명할 수 있다.
- UDS, OBD, XCP의 목적 차이를 구분할 수 있다.
- UDS의 Request/Response 모델과 SID 개념을 이해할 수 있다.
- Positive Response와 Negative Response의 기본 포맷을 해석할 수 있다.
- Physical Addressing과 Functional Addressing의 차이를 설명할 수 있다.
전체 구조
1. 왜 진단통신이 필요한가?
개발자가 만든 소프트웨어는 ECU에 다운로드되어 실행된다.
개발 초기에는 JTAG, Trace32 같은 장비를 직접 연결해 소프트웨어를 다운로드하고 디버깅할 수 있다.
하지만 양산 차량에 들어가는 ECU는 보통 케이스에 들어가 차량 내부 깊숙한 곳에 장착된다.
보안과 내구성 문제 때문에 개발용 포트가 제거되거나 접근하기 어려워진다.
그런데 차량이 조립된 뒤에도 다음 요구는 계속 남는다.
- 현재 ECU에 어떤 소프트웨어 버전이 들어 있는지 확인
- 차량 장착 후 소프트웨어 업데이트 또는 리프로그래밍
- 특정 캘리브레이션 값 읽기와 쓰기
- ECU 리셋
- 고장 코드와 고장 발생 시점 데이터 확인
- 정비소에서 고장 원인 추적
- OTA 업데이트 전후 상태 점검
이런 요구를 처리하기 위한 표준화된 통신 방식이 진단통신이다.
2. 진단통신은 채용 공고에서도 자주 보인다
자동차 소프트웨어 개발, 시험, 평가 직무에서는 다음 키워드를 자주 만난다.
| 키워드 | 의미 |
|---|---|
| Diagnosis / Diagnostic | 진단 관련 기능 |
| UDS | Unified Diagnostic Services, 가장 널리 쓰이는 진단 서비스 표준 |
| Diag | Diagnostic의 축약 표현 |
| Reprogramming | 소프트웨어 재다운로드 또는 업데이트 |
| OTA | Over-the-Air, 무선 업데이트 |
| DTC | Diagnostic Trouble Code, 고장 진단 코드 |
| DID | Data Identifier, 특정 데이터 식별자 |
진단통신을 모른다고 신입 채용이 불가능한 것은 아니다.
하지만 이 키워드를 알고 있으면 채용 공고와 실무 업무의 연결이 훨씬 잘 보인다.
3. UDS, OBD, XCP는 목적이 다르다
자동차 진단 또는 측정과 관련된 표준은 하나만 있는 것이 아니다.
| 표준/프로토콜 | 초점 | 실무 감각 |
|---|---|---|
| UDS | 범용 진단 서비스 | ECU 상태 읽기, 쓰기, 세션, 보안, 루틴, DTC 관리 |
| OBD | 법규 중심 진단 | 배기가스 관련 고장과 표준 진단 포트 |
| XCP | 측정과 캘리브레이션 | 내부 변수 측정, DAQ, 캘리브레이션 |
| J1939 | 상용차/중장비 계열 네트워크 | CAN 기반 상위 프로토콜 계열 |
자동차 업계에서 "진단통신"이라고 말할 때 가장 자주 만나는 것은 UDS다.
UDS는 ISO 14229 표준에 정의된 진단 서비스 집합으로 이해하면 된다.
4. UDS는 Request/Response 방식이다
UDS의 기본 동작은 단순하다.
- 진단기(Tester)가 ECU에 Request를 보낸다.
- ECU(Server)가 요청을 해석하고 기능을 수행한다.
- ECU가 Response를 보낸다.
UDS에서는 요청할 수 있는 기능 하나하나를 Service라고 부른다.
각 Service에는 1바이트짜리 번호가 붙는데, 이것이 **SID(Service Identifier)**다.
예를 들어:
| SID | 서비스 |
|---|---|
0x10 | Diagnostic Session Control |
0x11 | ECU Reset |
0x14 | Clear Diagnostic Information |
0x19 | Read DTC Information |
0x22 | Read Data By Identifier |
0x27 | Security Access |
0x2E | Write Data By Identifier |
0x31 | Routine Control |
요청 메시지의 첫 바이트에는 보통 SID가 들어간다.
5. Positive Response는 SID에 0x40을 더한다
ECU가 요청을 정상 수행하면 Positive Response를 보낸다.
UDS의 기본 규칙은 응답 SID가 요청 SID에 0x40을 더한 값이라는 것이다.
| 요청 서비스 | Request SID | Positive Response SID |
|---|---|---|
| Read Data By Identifier | 0x22 | 0x62 |
| ECU Reset | 0x11 | 0x51 |
| Diagnostic Session Control | 0x10 | 0x50 |
| Security Access | 0x27 | 0x67 |
예를 들어 Tester가 0x22로 데이터를 읽어 달라고 요청했는데, 응답 첫 바이트가 0x62라면 "Read Data By Identifier 요청이 성공했다"는 뜻으로 해석할 수 있다.
6. Negative Response는 0x7F로 시작한다
ECU가 요청을 수행할 수 없으면 Negative Response를 보낸다.
Negative Response의 기본 포맷은 다음과 같다.
| Byte | 의미 |
|---|---|
| 1 | 0x7F |
| 2 | 원래 요청한 SID |
| 3 | NRC, Negative Response Code |
대표적인 NRC 예시는 다음과 같다.
| NRC | 의미 |
|---|---|
0x11 | Service Not Supported |
0x12 | SubFunction Not Supported |
0x13 | Incorrect Message Length Or Invalid Format |
0x22 | Conditions Not Correct |
0x31 | Request Out Of Range |
0x33 | Security Access Denied |
0x78 | Response Pending |
NRC는 단순 실패 표시가 아니다.
"왜 실패했는지"를 진단기와 개발자가 판단할 수 있게 해 주는 중요한 정보다.
7. Physical Addressing은 특정 ECU를 지정한다
CAN은 브로드캐스트 방식이므로 모든 ECU가 버스 메시지를 볼 수 있다.
그런데 진단 요청은 특정 ECU 하나에게만 보내고 싶을 때가 많다.
UDS on CAN에서는 CAN ID를 이용해 주소 지정 방식을 정한다.
특정 ECU 하나를 대상으로 하는 방식이 Physical Addressing이다.
Physical Addressing은 특정 ECU의 데이터 읽기, 리셋, 세션 변경, 보안 접근처럼 대상이 명확한 요청에 사용된다.
8. Functional Addressing은 여러 ECU에게 동시에 묻는다
Functional Addressing은 특정 ECU 하나가 아니라, 해당 기능을 지원하는 여러 ECU에게 요청을 보내는 방식이다.
예를 들어 "현재 지원하는 진단 정보를 알려줘" 같은 요청을 여러 ECU에게 동시에 보내고 싶을 수 있다.
Functional Addressing에서는 여러 ECU가 요청을 볼 수 있기 때문에, 모든 ECU가 Positive Response를 보내면 버스 부하가 커질 수 있다.
그래서 UDS에는 Positive Response를 생략하도록 요청하는 Suppress Positive Response 비트가 있다.
Functional 요청은 편리하지만, 어떤 ECU가 응답해야 하고 어떤 응답은 생략해도 되는지 프로젝트 사양을 정확히 따라야 한다.
9. 표준과 프로젝트 사양을 함께 봐야 한다
UDS 표준은 공통 규칙을 제공한다.
하지만 실제 프로젝트에서는 많은 세부 사항을 OEM 사양서가 정한다.
예를 들어:
- 어떤 CAN ID를 Physical Request/Response에 사용할지
- 어떤 CAN ID를 Functional Request에 사용할지
- 어떤 서비스와 DID를 지원할지
- 어떤 NRC를 어떤 조건에서 보낼지
- 어떤 세션에서 어떤 서비스가 허용되는지
- 어떤 보안 레벨이 필요한지
따라서 UDS를 공부할 때는 표준 문서만 보거나 프로젝트 사양만 보는 것으로 부족하다.
표준의 기본 규칙을 이해하고, 프로젝트 사양에서 실제 값을 확인해야 한다.
핵심 정리
- 진단통신은 차량 장착 후 ECU 상태 읽기, 업데이트, 리셋, 고장 정보 확인 같은 요구에서 등장했다.
- UDS는 가장 널리 쓰이는 진단 서비스 표준이며, OBD와 XCP는 초점이 다르다.
- UDS는 Tester가 Request를 보내고 ECU가 Response를 돌려주는 구조다.
- Positive Response는 요청 SID에
0x40을 더한 값으로 시작한다. - Negative Response는
0x7F + 원래 SID + NRC구조를 가진다. - Physical Addressing은 특정 ECU 대상, Functional Addressing은 기능 대상 또는 여러 ECU 대상 요청에 사용된다.
확인 질문
- 양산 차량에서 JTAG 같은 개발 포트만으로는 유지보수가 어려운 이유는 무엇인가?
- UDS에서 Service와 SID는 어떤 관계인가?
0x22요청에 대해0x62응답이 오면 어떤 의미인가?- Functional Addressing에서 Positive Response를 생략하는 기능이 필요한 이유는 무엇인가?