Python 학습하기👆
티스토리 뷰
UDS에서 가장 복잡한 서비스 중 하나, 0x31 Routine Control. 그 원리와 구조, 제대로 알고 계신가요?
UDS(Unified Diagnostic Services)를 공부하다 보면 가장 자주 등장하는 서비스 중 하나가 바로 `0x31 Routine Control`입니다. 그런데도 아직 많은 개발자들이 이 기능의 정확한 구조나 하위기능들을 혼동하곤 하죠. “StartRoutine과 RequestResults 차이가 뭐더라?” “RoutineIdentifier는 어디에 쓰는 거지?” 저도 예전에 초보 시절, 이런 질문들에 혼란을 겪었던 기억이 납니다.
Routine Control은 단순한 데이터 요청이 아니라, 실제 ECU 내부에서 루틴(기능)이 실행되도록 지시하는 매우 중요한 명령입니다. 부트로더, 시리얼 넘버 초기화, DTC 리셋 등 수많은 진단 서비스의 핵심이죠. 이번 포스트에서는 이 복잡한 서비스를 단순하고 명확하게, 예제와 함께 정리해드립니다.
특히 오늘 알려드릴 정보는 ISO 14229-1 기반으로 구성되어 있으며, 실무에서 바로 활용 가능한 명세 중심으로 구성했습니다. 이 포스트 하나로 UDS 0x31을 완전 정복할 수 있는 기회를 절대 놓치지 마세요!
목차
Routine Control이란?
UDS 서비스 0x31(Routine Control)은 ECU에서 특정 루틴을 실행, 중단하거나 결과를 요청하는 데 사용되는 서비스입니다. 예를 들어, 부트로더에서 펌웨어를 검증하거나, DTC(진단 Trouble Code)를 리셋하거나, 특정 하드웨어 테스트를 수행할 때 사용됩니다. 일반적으로 ECU 내부에서 실행 가능한 사용자 정의 진단 기능들이 여기에 등록되며, 진단 요청자는 RoutineIdentifier를 통해 어떤 루틴을 제어할지를 지정합니다.
서브기능 코드 설명
0x31 서비스에는 세 가지 주요 서브기능 코드가 존재하며, 이를 통해 루틴의 동작 유형을 구분합니다. 이 서브기능은 요청 메시지의 두 번째 바이트에 위치합니다. 다음은 각 코드의 의미입니다.
| SubFunction | 의미 | 용도 |
|---|---|---|
| 0x01 | StartRoutine | 루틴 실행 시작 |
| 0x02 | StopRoutine | 루틴 실행 중단 |
| 0x03 | RequestRoutineResults | 루틴 결과 요청 |
메시지 구조와 예제
0x31 서비스는 다음과 같은 형식으로 요청 메시지를 구성합니다. RoutineIdentifier는 루틴의 고유 ID이며, 필요에 따라 인자 데이터(RoutineOptionRecord)를 추가할 수 있습니다.
- [0x31] [SubFunction] [RoutineIdentifier_H] [RoutineIdentifier_L] [RoutineOptionRecord...]
- 예: 31 01 00 01 → Routine ID 0x0001 시작
Routine ID 정의와 종류
RoutineIdentifier는 2바이트(16비트) 값으로, ECU 내에 정의된 각 루틴의 고유 ID입니다. 어떤 루틴을 실행할지를 이 ID로 구분하며, OEM마다 다르게 정의될 수 있습니다. 예를 들어, 한 제조사에서는 0x0001을 EEPROM 삭제, 0x0002를 Flash 확인용으로 사용할 수 있죠.
| RoutineIdentifier | 루틴 설명 |
|---|---|
| 0x0001 | EEPROM 초기화 |
| 0x0002 | Flash CRC 체크 |
| 0xFF00 | Bootloader 진입 조건 확인 |
실제 적용 사례
Routine Control은 다양한 상황에서 실제로 사용됩니다. 예를 들어, 차량 시동 시 CAN 통신 초기화를 위한 루틴을 실행하거나, 업데이트된 소프트웨어가 제대로 적용되었는지 Flash Integrity Check 루틴을 돌릴 수 있습니다. 또한 일부 보안 진단 기능은 루틴을 통해 상태 인증 또는 초기화 작업을 수행하죠.
- Flash 다운로드 후 CRC 검증 루틴 실행
- 시동 후 보안 시퀀스 초기화 루틴
- 비밀번호 인증 후 EEPROM 리셋 실행
UDS 0x31 Routine Control은 단순한 진단 명령이 아니라, ECU 기능을 직접 제어하는 핵심 인터페이스입니다. 이번 글을 통해 구조와 메시지 형식을 이해하고, 실무 적용까지 감을 잡으셨길 바랍니다. 앞으로도 복잡한 UDS 서비스들을 하나씩 함께 풀어나가 보아요
'개발 > 그 외 개발관련' 카테고리의 다른 글
| 오토사 플랫폼 vs 클래식 플랫폼: 자동차의 본질을 바꾸는 프레임 전쟁 (0) | 2025.04.01 |
|---|---|
| UDS(Unified Diagnostic Services) 완벽 가이드: 자동차 진단 프로토콜의 핵심 (0) | 2025.03.28 |
| UDS 서비스 목록 (0) | 2025.03.27 |
| UDS ECU Firmware Download Services (example) (0) | 2025.03.27 |
| CAN 통신 완전 정복: 자동차부터 산업 장비까지 (0) | 2025.03.27 |