테마
09. DTC와 고장 정보 관리
학습 목표
- DTC가 무엇이고 왜 3바이트 코드 구조를 사용하는지 이해할 수 있다.
- DTC Status Byte의 주요 비트 의미를 설명할 수 있다.
- Operation Cycle, Test Failed, Pending, Confirmed 개념을 구분할 수 있다.
- Snapshot Data와 Extended Data의 차이를 설명할 수 있다.
- Clear Diagnostic Information과 Read DTC Information 서비스의 역할을 이해할 수 있다.
전체 구조
1. DTC는 차량 고장의 이름표다
DTC(Diagnostic Trouble Code)는 차량에서 감지한 고장을 식별하는 코드다.
세탁기나 보일러가 E03 같은 에러 코드를 보여주듯, 자동차 ECU도 고장을 코드로 기록한다.
차이가 있다면 자동차는 많은 ECU와 표준 진단 장비가 함께 동작해야 하므로, 코드 형식과 조회 방식이 더 체계적으로 정리되어 있다는 점이다.
일반적으로 DTC는 3바이트 코드로 표현된다.
그리고 사람이 읽기 쉬운 P0138 같은 형태로도 나타낼 수 있다.
2. DTC 코드는 영역과 정의 주체를 포함한다
DTC 이름의 앞 글자는 고장 영역을 나타낸다.
| 문자 | 영역 |
|---|---|
| P | Powertrain, 엔진/변속기 등 구동계 |
| C | Chassis, 섀시 |
| B | Body, 바디/편의 장치 |
| U | Network, 통신/네트워크 |
두 번째 자리 일부는 표준 코드인지 제조사 정의 코드인지 나타낼 수 있다.
예를 들어 표준화 단체가 정의한 코드와 OEM이 자체 정의한 코드는 같은 형식 안에서 구분된다.
정확한 매핑은 ISO 15031-6, SAE J2012, OEM 사양을 기준으로 봐야 한다.
3. 고장 감지 로직은 ECU 소프트웨어가 구현한다
DTC는 마법처럼 자동으로 생기지 않는다.
ECU 소프트웨어 안에 "어떤 조건이면 고장으로 볼 것인가"를 판단하는 로직이 있어야 한다.
예를 들어 배터리 전압 과소 고장을 감지한다고 하자.
실무에서는 단순히 한 번 기준값을 넘었다고 바로 Confirmed DTC로 만들지 않을 수 있다.
Debounce, Operation Cycle, 연속 실패 횟수, Aging 조건 같은 세부 규칙을 OEM 사양에서 정한다.
4. Operation Cycle은 고장 판단의 시간 단위다
Operation Cycle은 고장 체크를 수행하는 하나의 운용 구간이다.
시동 On에서 Off까지를 하나의 Operation Cycle로 볼 수도 있고, 특정 ECU 기능 활성 구간을 기준으로 잡을 수도 있다.
Operation Cycle 개념이 필요한 이유는 "이번 주기에서 고장이 났는가", "이전 주기에서 났던 고장이 아직 의미가 있는가"를 구분하기 위해서다.
예를 들어:
- 이번 주기에서 한 번이라도 실패했는가?
- 현재 가장 최근 테스트 결과가 실패인가?
- 여러 주기에서 반복 실패해 Confirmed로 볼 것인가?
- 여러 주기에서 정상이라면 Confirmed를 해제할 것인가?
이런 판단이 DTC Status Byte의 비트와 연결된다.
5. DTC Status Byte는 고장의 현재 상태를 8비트로 표현한다
각 DTC는 1바이트짜리 상태값을 가진다.
이것이 DTC Status Byte다.
대표적인 비트 의미는 다음과 같다.
| Bit | 이름 예시 | 의미 |
|---|---|---|
| 0 | testFailed | 가장 최근 테스트 결과가 실패인지 |
| 1 | testFailedThisOperationCycle | 현재 Operation Cycle에서 실패가 있었는지 |
| 2 | pendingDTC | 고장이 의심되는 pending 상태인지 |
| 3 | confirmedDTC | 고장이 확정되어 저장된 상태인지 |
| 4 | testNotCompletedSinceLastClear | 마지막 Clear 이후 테스트가 완료되지 않았는지 |
| 5 | testFailedSinceLastClear | 마지막 Clear 이후 실패가 있었는지 |
| 6 | testNotCompletedThisOperationCycle | 현재 Operation Cycle에서 테스트가 완료되지 않았는지 |
| 7 | warningIndicatorRequested | 경고등 표시 요청이 필요한지 |
프로젝트에 따라 일부 비트는 사용하지 않거나 세부 조건이 다를 수 있다.
특히 Confirmed DTC의 설정과 해제 조건은 OEM 사양을 반드시 확인해야 한다.
6. Pending과 Confirmed는 다르다
Pending DTC는 고장이 의심되는 상태다.
예를 들어 한 Operation Cycle에서 실패가 발생했지만 아직 확정 조건을 만족하지 않았을 수 있다.
Confirmed DTC는 고장이 확정되어 비휘발성 메모리(NVM)에 저장되거나 정비 진단에서 의미 있게 다뤄지는 상태에 가깝다.
예를 들어 2번 연속 Operation Cycle에서 실패해야 Confirmed로 볼 수도 있고, 40번 연속 정상 주행 후 Aging으로 Confirmed를 해제할 수도 있다.
이 숫자는 표준이 전부 고정해 주는 것이 아니라 OEM 정책에 따라 달라질 수 있다.
7. Snapshot Data는 고장 순간의 사진이다
Snapshot Data 또는 Freeze Frame은 고장이 발생한 순간의 차량 상태를 기록한 데이터다.
말 그대로 "그때 어떤 상태였는지"를 남긴다.
예를 들어 배터리 전압 과소 DTC가 발생했을 때 다음 정보를 저장할 수 있다.
- 배터리 전압
- 차량 속도
- 엔진 RPM
- 외기 온도
- Operation Cycle 카운터
Snapshot Data에 들어가는 값들은 DID로 식별되는 데이터일 수 있다.
즉 DTC와 여러 DID가 매핑된다.
한 DTC에 Snapshot을 몇 개까지 저장할지, 새 고장이 생기면 기존 Snapshot을 덮어쓸지, 최초 고장만 저장할지, 가장 최근 고장을 저장할지는 프로젝트 사양에서 정한다.
8. Extended Data는 고장 통계 정보다
Extended Data는 고장과 관련된 통계 또는 부가 정보다.
Snapshot이 "고장 순간의 상태"라면, Extended Data는 "고장이 얼마나, 어떻게 누적되었는지"에 가깝다.
예시는 다음과 같다.
| Extended Data 예시 | 의미 |
|---|---|
| Failure Counter | 지금까지 몇 번 실패했는지 |
| Aging Counter | Aging 진행 상태 |
| Occurrence Counter | 고장 발생 횟수 |
| Time Since First Fail | 최초 고장 이후 시간 |
| Time Since Last Fail | 마지막 고장 이후 시간 |
Extended Data에도 Record Number가 있다.
주의할 점은 Snapshot의 Record Number와 Extended Data의 Record Number가 서로 다른 개념이라는 것이다.
9. Clear Diagnostic Information: SID 0x14
Clear Diagnostic Information은 저장된 진단 정보를 지우는 서비스다.
SID는 0x14다.
요청에는 어떤 DTC 또는 어떤 DTC 그룹을 지울지 나타내는 값이 들어간다.
예를 들어 0xFFFFFF는 모든 DTC를 의미하는 그룹 값으로 쓰일 수 있다.
Clear 요청이 들어오면 프로젝트 사양에 따라 다음 정보가 초기화될 수 있다.
- DTC Status Byte
- Snapshot Data
- Extended Data
- Confirmed DTC 정보
- 기타 진단 저장 정보
무엇을 지울지, 무엇은 남길지는 표준과 OEM 사양을 함께 확인해야 한다.
10. Read DTC Information: SID 0x19
Read DTC Information은 DTC 관련 정보를 조회하는 서비스다.
SID는 0x19이고, SubFunction이 많다.
대표적인 SubFunction은 다음과 같다.
| SubFunction | 이름 | 역할 |
|---|---|---|
0x01 | ReportNumberOfDTCByStatusMask | 특정 Status 조건에 맞는 DTC 개수 조회 |
0x02 | ReportDTCByStatusMask | 특정 Status 조건에 맞는 DTC 목록 조회 |
0x03 | ReportDTCSnapshotIdentification | 저장된 Snapshot 식별 정보 조회 |
0x04 | ReportDTCSnapshotRecordByDTCNumber | DTC와 Record Number로 Snapshot 실제 데이터 조회 |
0x06 | ReportDTCExtendedDataRecordByDTCNumber | DTC와 Record Number로 Extended Data 조회 |
| 기타 | First/Most Recent/Supported/Permanent DTC 등 | 다양한 조회 기능 |
Status Mask 기반 조회는 비트 마스크로 조건을 지정한다.
예를 들어 Bit 0이 1인 DTC만 찾고 싶다면 요청 마스크에서 해당 비트를 켠다.
11. DTC Format Identifier와 Available Mask
ReadDTC 응답에는 단순히 DTC 목록만 들어가지 않을 수 있다.
DTC Format Identifier와 DTC Status Availability Mask 같은 정보가 포함될 수 있다.
| 항목 | 의미 |
|---|---|
| DTC Format Identifier | DTC 코드 형식을 어떤 표준 체계로 해석할지 |
| DTC Status Availability Mask | 해당 ECU가 어떤 Status Bit를 지원하는지 |
Availability Mask가 중요한 이유는 ECU가 8개 Status Bit를 모두 지원하지 않을 수 있기 때문이다.
Tester가 지원하지 않는 비트를 조건으로 요청하면 적절한 Negative Response가 필요할 수 있다.
핵심 정리
- DTC는 ECU가 감지한 고장을 식별하는 코드이며, 영역과 정의 주체 정보를 포함할 수 있다.
- DTC Status Byte는 각 DTC의 현재 상태를 8비트로 표현한다.
- Pending과 Confirmed는 고장 의심 상태와 확정 상태를 구분하는 데 쓰인다.
- Snapshot Data는 고장 발생 시점의 상태값이고, Extended Data는 고장 통계나 부가 정보다.
0x14는 진단 정보를 삭제하고,0x19는 DTC 관련 정보를 다양한 SubFunction으로 조회한다.- DTC의 세부 동작은 표준만으로 끝나지 않고 OEM 사양에 의해 크게 달라질 수 있다.
확인 질문
- DTC Status Byte의 Bit 0과 Bit 1은 어떤 차이가 있는가?
- Pending DTC와 Confirmed DTC를 구분하는 이유는 무엇인가?
- Snapshot Data와 Extended Data는 각각 어떤 질문에 답하기 위한 데이터인가?
ReportDTCByStatusMask요청에서 Status Mask가 필요한 이유는 무엇인가?