테마
08. UDS 서비스, 세션, 보안 접근
학습 목표
- DID와 Read/Write Data By Identifier 서비스의 관계를 설명할 수 있다.
- ECU Reset 서비스가 SubFunction으로 리셋 종류를 구분하는 방식을 이해할 수 있다.
- Diagnostic Session Control과 TesterPresent의 역할을 설명할 수 있다.
- P2, P2*, S3 타이밍 파라미터의 큰 의미를 이해할 수 있다.
- Security Access의 Seed-Key 절차와 Routine Control의 RID 개념을 설명할 수 있다.
전체 구조
1. DID는 ECU 데이터의 이름표다
UDS에서 ECU 내부의 특정 데이터를 읽거나 쓸 때 **DID(Data Identifier)**를 사용한다.
DID는 보통 2바이트 값이며, "어떤 데이터를 의미하는지"를 구분한다.
예를 들어 OEM이 다음 DID 테이블을 정의했다고 하자.
| DID | 데이터 | 크기 | 읽기/쓰기 | 변환 |
|---|---|---|---|---|
0x0001 | 배터리 전압 | 1byte | Read | factor 0.1 |
0x0002 | 엔진 RPM | 2byte | Read | factor 1 |
0x0003 | 제한 속도 값 | 1byte | Read/Write | factor 1 |
0xF190 | VIN | 17byte | Read | 표준 예약 DID |
DID 값은 차량 전체에서 항상 같은 의미로 쓰인다고 가정하면 위험하다.
일부 표준 예약 DID를 제외하면, 많은 DID는 ECU와 프로젝트마다 다르게 정의될 수 있다.
2. Read Data By Identifier: SID 0x22
Read Data By Identifier 서비스는 DID로 특정 데이터를 읽는 서비스다.
SID는 0x22다.
요청은 대략 다음 구조다.
| Byte | 의미 |
|---|---|
| 1 | 0x22 |
| 2~3 | DID |
| 4~5 | 추가 DID, 여러 개 요청 시 반복 |
Positive Response는 0x62로 시작하고, 요청한 DID와 실제 데이터를 함께 돌려준다.
Read 서비스는 여러 DID를 한 번에 요청할 수 있다.
다만 응답 데이터가 길어지면 뒤에서 볼 ISO-TP 분할 전송이 필요하다.
3. Write Data By Identifier: SID 0x2E
Write Data By Identifier 서비스는 특정 DID에 값을 쓰는 서비스다.
SID는 0x2E다.
요청은 대략 다음 구조다.
| Byte | 의미 |
|---|---|
| 1 | 0x2E |
| 2~3 | DID |
| 4~ | 쓸 데이터 |
Positive Response는 0x6E로 시작하고, 보통 성공한 DID를 돌려준다.
Read와 달리 Write는 일반적으로 한 번에 하나의 DID를 쓰는 구조로 이해하면 된다.
Write는 위험한 기능이 될 수 있다.
따라서 특정 세션에서만 허용하거나, Security Access가 열린 상태에서만 허용하는 경우가 많다.
4. ECU Reset: SID 0x11
ECU Reset은 ECU를 리셋시키는 서비스다.
SID는 0x11이고, 어떤 방식으로 리셋할지는 SubFunction으로 구분한다.
| SubFunction | 의미 예시 |
|---|---|
0x01 | Hard Reset |
0x02 | Key Off On Reset |
0x03 | Soft Reset |
0x04 | Enable Rapid Power Shutdown |
0x05 | Disable Rapid Power Shutdown |
리셋은 ECU 동작을 크게 바꾸는 요청이므로 아무 세션에서나 허용하지 않는 경우가 많다.
허용되지 않는 세션에서 요청하면 NRC로 실패 응답이 올 수 있다.
5. Diagnostic Session Control: SID 0x10
UDS에는 Session이라는 개념이 있다.
ECU가 어떤 진단 모드에 있는지 나타내는 상태로 이해하면 된다.
대표적인 세션 예시는 다음과 같다.
| Session | 의미 |
|---|---|
| Default Session | ECU가 기본적으로 들어가는 일반 세션 |
| Programming Session | 소프트웨어 다운로드, 리프로그래밍에 사용 |
| Extended Diagnostic Session | 더 많은 진단 기능을 허용 |
| Safety System Diagnostic Session | 안전 시스템 관련 특수 진단 |
위 세션은 대표 예시다. 실제 ECU가 어떤 세션을 지원하고 어떤 전이를 허용하는지는 표준 범위와 프로젝트 사양에 따라 달라질 수 있다.
Session을 바꾸는 서비스가 Diagnostic Session Control이고 SID는 0x10이다.
각 세션에서 허용되는 서비스는 프로젝트 사양에 따라 정한다.
예를 들어 ECU Reset은 Extended Session에서만 허용하고, Write DID는 Security Access가 열린 Programming Session에서만 허용할 수 있다.
6. TesterPresent와 S3 타이머
Default가 아닌 세션에 들어간 뒤 아무 요청도 오지 않으면 ECU는 일정 시간 후 Default Session으로 돌아갈 수 있다.
이때 사용하는 대표 타이밍이 S3 Server다.
Tester는 세션을 유지하고 싶으면 주기적으로 TesterPresent 서비스를 보낸다.
SID는 0x3E다.
TesterPresent 주기는 ECU의 S3 timeout보다 짧아야 한다.
그렇지 않으면 Tester가 세션을 유지한다고 생각해도 ECU는 이미 Default Session으로 돌아갈 수 있다.
주기 유지용 TesterPresent에서는 Positive Response가 꼭 필요하지 않은 경우도 많다. 이때 suppress positive response bit를 세워 0x3E 0x80 형태로 보내기도 하며, 실제 사용 여부는 ECU 사양을 따른다.
7. P2와 P2*는 응답 대기 시간이다
Tester가 Request를 보낸 뒤 ECU의 Response를 기다리는 시간도 중요하다.
| 타이밍 | 의미 |
|---|---|
| P2 Server | ECU가 일반 응답을 보내기까지 필요한 시간 |
| P2 Client | Tester가 일반 응답을 기다리는 시간 |
| P2* Server | ECU가 더 오래 걸리는 작업에서 추가로 필요한 시간 |
| P2* Client | Tester가 Response Pending 이후 기다리는 시간 |
ECU가 요청을 바로 완료할 수 없지만 처리 중이라면 NRC 0x78(Response Pending)을 보낼 수 있다.
Tester는 이 응답을 받으면 더 긴 P2* 시간 동안 기다린다.
Session Control 응답에는 해당 세션에서 사용할 P2/P2* 값이 포함될 수 있다.
Tester는 이 값을 보고 자신의 대기 시간을 조정해야 한다.
8. Security Access: SID 0x27
진단 기능 중에는 아무나 실행하면 위험한 것들이 있다.
- 소프트웨어 업데이트
- 중요한 DID 쓰기
- 특정 루틴 실행
- 보안 관련 데이터 접근
이런 기능을 보호하기 위해 UDS는 Security Access 서비스를 제공한다.
SID는 0x27이고, 기본 절차는 Seed-Key 방식이다.
보안 레벨은 여러 개일 수 있다.
각 레벨은 서로 다른 자물쇠처럼 생각하면 된다.
중요한 점은 Seed-Key 알고리즘 자체가 외부에 공개되면 안 된다는 것이다.
표준은 절차를 정하지만, 실제 Key 계산 알고리즘은 OEM 또는 프로젝트에서 관리한다.
9. Routine Control: SID 0x31
Routine Control은 ECU 내부에 사전에 정의된 루틴을 실행, 중지, 결과 조회하는 서비스다.
SID는 0x31이고, 루틴은 **RID(Routine Identifier)**로 구분한다.
| SubFunction | 의미 |
|---|---|
0x01 | Start Routine |
0x02 | Stop Routine |
0x03 | Request Routine Results |
예를 들어 특정 모터를 좌우로 500회 반복 구동하는 내구 테스트 루틴을 정의할 수 있다.
Tester는 RID와 입력 파라미터를 넣어 루틴을 시작하고, 나중에 결과를 요청한다.
Routine Control은 자유도가 높다.
따라서 RID별 입력 파라미터와 결과 포맷은 프로젝트 사양에서 정확히 정의해야 한다.
핵심 정리
- DID는 ECU 내부 데이터의 식별자이고,
0x22와0x2E서비스로 읽고 쓸 수 있다. - ECU Reset은 SubFunction으로 Hard, Key Off On, Soft 같은 리셋 종류를 구분한다.
- Session Control은 ECU의 진단 모드를 바꾸고, 세션마다 허용되는 서비스가 달라질 수 있다.
- TesterPresent는 S3 timeout으로 세션이 Default로 돌아가는 것을 막기 위해 주기적으로 보낸다.
- P2/P2*는 응답 대기 시간이고,
NRC 0x78은 더 기다리라는 의미다. - Security Access는 Seed-Key 절차로 보호 기능 접근을 제어한다.
- Routine Control은 RID 기반으로 사전 정의된 루틴을 시작, 중지, 결과 조회한다.
확인 질문
- DID와 CAN Signal은 모두 "값을 식별한다"는 점에서 비슷하지만 어떤 차이가 있는가?
- Write DID가 특정 세션과 보안 레벨에서만 허용되는 이유는 무엇인가?
- TesterPresent 주기가 S3 timeout보다 길면 어떤 일이 생기는가?
- Security Access에서 Seed만 받고 Key를 보내지 않으면 보호 기능을 실행할 수 없는 이유는 무엇인가?