고장 코드와 고장 원인을 같은 것으로 읽지 않는다
DTC(Diagnostic Trouble Code)는 진단 고장 코드다. ECU가 정의한 모니터/검사 결과를 기록하고 분류하는 데 사용한다. 코드가 있다는 사실만으로 특정 부품이 물리적으로 고장났다고 확정할 수는 없다. 전원·배선·설정·시간/통신·센서·소프트웨어 문제 등이 같은 모니터 결과로 드러날 수 있다.
M28.03의 전송/응답 구분을 이어 간다. 이 단위의 입력은 이미 재조립된 UDS PDU와 자체 가상 상태/관찰 표다. CAN 프레임의 PCI를 다시 붙여 읽지 않는다. 아래 DTC 숫자와 이름·서버 지원/기록은 교육용 정의이며 실제 차종/표준 DTC의 의미나 실제 진단 수행 결과가 아니다.
DTC 식별자와 상태 바이트를 나눈다
이번 UDS 기록은 DTC3B와 status1B로 읽는다. 세 바이트 식별자를 보았다고 OBD의 P코드 이름으로 임의 변환하지 않는다. DTC 형식/서버 정의가 필요하다. 부정 응답의 NRC 한 바이트와도 구분한다.
상태는 여러 비트로 이루어져 있다. AUTOSAR DEM R24-11의 UDS 상태 설명을 아래처럼 읽는다. 마스크는16진수다.
| bit/마스크 | 이름과 해석 |
|---|---|
| 0 / 01 | testFailed: 가장 최근 수행한 검사의 실패 결과 |
| 1 / 02 | testFailedThisOperationCycle: 이번 operation cycle 중 실패 보고가 있었음 |
| 2 / 04 | pendingDTC: 현재 또는 직전 완료 cycle의 실패와 관계된 대기 상태 |
| 3 / 08 | confirmedDTC: 설정된 확정 조건을 충족한 이력 |
| 4 / 10 | testNotCompletedSinceLastClear: 마지막 초기화 뒤 검사 미완료 |
| 5 / 20 | testFailedSinceLastClear: 마지막 초기화 뒤 실패 보고가 있었음 |
| 6 / 40 | testNotCompletedThisOperationCycle: 이번 cycle의 검사 미완료 |
| 7 / 80 | warningIndicatorRequested: 경고 표시 요청 상태 |
operation cycle은 진단 시스템이 정의하는 운영 구간이다. 앞 교재의10ms 제어 release 한 번과 같지 않으며 모든 ECU에서 무조건 시동 한 번을 뜻하는 것도 아니다. 확인/aging(이력 소멸)·debounce(일시 변화와 유효 실패를 가르는 조건) 정책도 설정에 따라 다르다. 모든 고장이 두 번이면 확정된다는 규칙을 만들지 않는다.
confirmed는 현재 testFailed와 같지 않다. 또한 testFailed=0이어도 이번 검사가 아직 완료되지 않았다면 현재 정상이라는 결론은 부족하다. bit7의 요청 상태도 실제 경고등을 물리적으로 관측한 결과와 구별한다.
지원 마스크와 선택 마스크의 역할은 다르다
가상 서버의 DTCStatusAvailabilityMask를0x4F라고 준다. 지원하는 비트는0/1/2/3/6이다. 지원하지 않는 bit7을0이라고 보았다고 '경고 요청이 없다'고 확정하지 않는다.
클라이언트의 DTCStatusMask는 어떤 상태를 선택할지 정한다. 지원하는 선택 비트와 status를 AND했을 때 하나라도 남으면 선택한다. 선택한 모든 비트가 동시에1이어야 하는 조건이 아니다. 지원하지 않는 비트만 선택한 조회는 전체 고장 유무를 판정하는 근거가 아니다.
아래 세 기록은 같은 가상 서버/메모리/형상의 제공 상태다.
| DTC/교육용 이름 | 제공 status와 해석 |
|---|---|
| A:123456 / 센서 값 유효성 | 48=08+40. 확정 이력과 이번 검사 미완료. 현재 통과라고 할 수 없음 |
| B:234567 / 제어 입력 오래됨 | 0F=01+02+04+08. 최근/이번 실패·pending·확정 |
| C:345678 / 입력 누락 | 07=01+02+04. 최근/이번 실패·pending이며 아직 확정 비트 없음 |
mask08은 A/B를 고른다. C도 실패 비트가 있지만 확정 비트가 없어 이번 선택에서는 빠진다. mask09(08+01)은 A/B/C 모두를 고른다. A는08, C는01만 맞아도 선택되기 때문이다. mask80은 지원 마스크4F와 겹치지 않아 이 서버의 경고 상태/전체 정상 여부를 판단할 수 없다.
완전한 읽기 응답에서 레코드 개수를 확인한다
가상 요청 19 02 08은 ReadDTCInformation의 reportDTCByStatusMask와 mask08이다. 응답을 다음과 같이 제공한다.
59 02 4F 12 34 56 48 23 45 67 0F
59/02는 해당 서비스/하위기능의 응답,4F는 지원 마스크다. 그 뒤 12 34 56 48이 A, 23 45 67 0F가 B다. 전체11B 중 앞3B를 제외하면8B이며4B씩 두 기록이다. C는 이번 선택에서 제외됐다.11B를 한 개 Classical CAN payload라고 해석하지 않는다. 이미 ISO-TP가 완성한 PDU다.
DTC 목록이 비어 있어도 조회 대상 ECU/메모리·세션/권한·선택/지원 마스크·기록 설정·검사 완료 여부를 확인한다. 현재 활성 고장 전부가 없다는 결론으로 바로 넘어가지 않는다. 읽기 NRC도 DTC 식별자와 다르다. 7F 19 31이면0x19 요청의 범위 거부이며 'DTC31 고장 발생'이 아니다.
삭제 전에 원본과 진단 조건을 보존한다
코드만 적고 삭제하면 고장 당시 상태를 복원하기 어렵다. 대상 ECU/형상·주소/세션·조회 메모리/마스크·원본 PDU/수신 시각·해석 정의·모니터의 실행/미완료 상태를 먼저 기록한다. 원본 측정 시각이 있으면 수신 시각과 구분하고 clock/epoch도 남긴다.
snapshot/freeze frame은 특정 사건에 연결해 저장한 데이터, extended data는 추가 진단 기록이다. 어느 사건/레코드 번호·형식/단위·갱신 조건에 해당하는지는 서버 정의를 확인한다. 이름만 보고 지금의 실시간 값으로 표시하거나 서로 다른 사건의 값을 한 장면처럼 합치지 않는다.
AUTOSAR DCM R24-11 §7.4.2.4/.5는 읽기와 초기화·메모리 선택을 구분한다. 같은 DTC라도 다른 메모리/조건의 결과를 섞으면 삭제 전후 비교도 잘못될 수 있다.
초기화 응답은 수리 완료 증거가 아니다
ClearDiagnosticInformation(0x14)은 선택한 DTC/그룹의 오류 메모리를 초기화하는 서비스다. 지원 대상/세션/권한·관련 기록/NVM 반영 정책을 서버 자료에서 확인해야 한다. 임의의 숫자를 모든 서버의 유효 그룹으로 쓰거나 전체 삭제를 기본 절차로 제시하지 않는다.
이번 가상 서버는 groupOfDTC 필드의0x123456을 단일 A만 대상으로 허용한다고 준다. 실제 장치에 대한 조작 지시가 아니다.
| 제공 기록 | 판정 |
|---|---|
14 12 34 56 → 54 | 가상 서버가 해당 초기화에 정상 응답. A의 대상 범위와 관련됨 |
이후 같은mask08 조회: 59 02 4F 23 45 67 0F | 확정 목록에 B만 남음. A가 목록에서 사라졌음 |
| 물리 검사/수리·A 모니터 재실행 자료 없음 | A가 실제로 수리/정상화됐다고 할 수 없음. B의 실패도 남음 |
사후 응답은7B로 앞3B+기록4B 하나다. 삭제된 코드가 안 보이는 것은 초기화의 결과일 수 있고, 검사 조건이 아직 충족되지 않은 상태일 수도 있다. 실제 원인이 남으면 다시 기록될 수 있다. 요청이 timeout이면 초기화의 수행 여부부터 미확인이지, 성공/아무 일도 없음 중 편한 쪽으로 채우는 것이 아니다.
기록 설정 off와 고장 제거·통신/제어 정지는 다르다
ControlDTCSetting(0x85)은 DTC 기록 설정을 제어한다. 이번 가상 서버가 추가 옵션 없는 해당 요청을 지원한다고 준다. 다음도 실제 수행 로그가 아닌 제공 사례다.
| UDS 요청/응답 | 의미와 별도 근거 |
|---|---|
85 02 → C5 02 | DTC 설정 off 접수. 기존 DTC 삭제/센서 고장 제거/모터 정지 응답 아님 |
| off 동안 목록/상태 변화가 없음 | 새 실패가 없었다는 근거로 부족. 기록/갱신을 보지 못한 공백 가능 |
85 01 → C5 01 | 설정 on 응답. 놓친 사건이 자동 복원됐거나 현재 검사가 통과했다는 뜻 아님 |
AUTOSAR DEM의 설정 제어는 off일 때 관련 상태 보고를 무시하는 동작과 다른 초기화/상태 경로를 구분한다. 센서 모니터/응용 코드 자체가 반드시 멈춘다는 뜻이 아니다. ControlDTCSetting과 통신 제어/물리 제어를 같은 기능으로 설명하지 않는다.
세션 변경/기본 세션 복귀·모드 조건에 따라 설정이 다시 켜지는 정책도 있다. 이전 off 응답만 보고 영구 유지로 가정하지 않는다. 지원 범위/시작·종료 시각·관찰 공백을 기록하고 다시 켜진 상태/검사 조건에서 관측해야 한다.
'입력이 오래됨'에서 원인까지 가려면 무엇이 더 필요한가
다음은 앞의 코드 해석과 연결하는 별도 제공 관찰 구간이다. 같은 clock/epoch에서 now1000ms, 원본 sample990ms이며 허용 나이는0~5ms라고 준다. 나이10ms로 초과다. 이때 B의 '제어 입력 오래됨' 모니터 실패는 증상과 연결되지만 원인을 하나로 확정하지 않는다.
| 제공 관찰 | 해석/추가 확인 |
|---|---|
| 원본 나이10ms | 이번 허용5ms 초과. 생성/전송/queue·clock 경로를 나눠 조사 |
| 한 순간TEC0/REC0 | 그 카운터 관측. 과거 오류/대기·원본 갱신 문제가 전혀 없었다는 뜻 아님 |
| 호스트가 누락을0으로 대체해 표시 | 현재 정상0/물리 정지 관측이 아니라 표시 경로의 대체값 |
| 전원/배선·획득 주기 실측 없음 | 부품 고장/배선 단선은 추가 자료가 필요한 가설 |
가능한 가설을 나눈다. 원본 획득/생산 주기가 늦었는가, 버스/처리 queue에서 지연됐는가, clock 매핑/epoch가 틀렸는가, 잘못된 버전/형상을 사용했는가를 원본 시각/시퀀스·각 단계 기록으로 확인한다. 전원/배선·센서 문제도 별도 관측 없이 배제하거나 확정하지 않는다.
변경은 대상 형상·바꾼 조건·예상 관찰·재검사 경계를 기록한다. 예를 들어 나이5/6ms·누락/clock 오류·정상 복귀를 같은 조건에서 비교할 계획을 세울 수 있다. 계획만 적었다면 '수정 후 PASS'를 만들지 않는다. 삭제/off로 사라진 이력이나 검사 미완료를 정상 결과로 채우지도 않는다.
추적 보고서는 관찰·가설·변경·재검증을 분리한다
보고서에는 원본 진단/시간·상태/마스크·형상/조건 → 관찰한 증상 → 원인 가설과 필요한 추가 근거 → 변경 제안 → 실제 재검사 결과/미수행을 연결한다. 실제 수행하지 않은 수리/진단 조작은 수행란에 적지 않는다.
기존 4.4 시간 정합과 M26.06 결함 보고를 재사용한다. 학습 산출물은 위 증거를 읽고 부족한 것을 판정한 기록이다. 다음 M28.05 다운로드·보안 접근·검증·리셋에서도 서비스 정상 응답과 실제 작업 결과를 구별한다.