CAN 프레임 하나와 진단 응답 하나는 다르다
M28.02까지는 링크의 타이밍/프레임과 응용 신호를 나눴다. 진단에서도 한 프레임이 도착했다는 사실과 완전한 진단 응답을 받았다는 사실을 구분해야 한다. 응답이 여러 프레임으로 나뉘면 길이·순서·대기/흐름 제어가 추가된다.
ISO-TP(ISO15765-2)는 CAN에서 큰 메시지를 나눠 보내고 다시 모으는 전송 프로토콜이다. UDS(Unified Diagnostic Services, ISO14229 계열)는 무엇을 읽거나 요청하며 어떤 응답을 주는지 다루는 진단 서비스다. UDS는 CAN 자체의 프레임 형식과 같은 이름이 아니다.
| 계층 | 이번 단위에서 확인할 근거 |
|---|---|
| 링크 | CAN ID/형식·payload 길이·오류/ACK |
| 전송 | ISO-TP 주소·분할/흐름 제어·길이/순서·완전한 PDU와 전송 결과 |
| 진단 | UDS SID/대상 데이터·세션/권한·응답 코드·응용 대기/최종 결과 |
PDU(Protocol Data Unit)는 해당 계층이 주고받는 데이터 단위다. 여기서 'UDS PDU'는 분할되기 전 또는 재조립된 진단 메시지를 뜻한다. 링크 ACK는 이 재조립/진단 성공을 대신하지 않는다.
기본은 자체 가상 기록 분석이다. CAN ID·데이터 식별자/기록·타이머는 특정 차종의 설정이 아니며 실제 진단 도구/차량을 연결하지 않는다. 아래 길이는 Classical CAN·11bit ID·payload8B·normal addressing·추가 주소 바이트 없음으로 한정한다. FD/다른 주소 형식/긴 길이에7B/6B 같은 수용량을 그대로 적용하지 않는다.
목적과 주소 형식을 따로 정한다
Linux ISO-TP 문서는 physical addressing의1:1, functional addressing의1:N 통신과 normal/extended/mixed 주소 형식을 나눈다. normal은 CAN ID로 주소를 나타내고, 추가 주소 바이트를 쓰는 형식은 payload 공간도 달라진다. physical/functional이라는 목적과 normal/extended/mixed라는 형식을 한 축으로 혼동하지 않는다.
그림 M28.03-1. 각 칸은 서로 다른 역할/근거다. 아래 방향은 자료/처리의 연결이며 실제 성공을 자동으로 보장하지 않는다. 직접 제작한 개념도이며 본문의 조건과 함께 읽는다.
CAN 링크 자체의 ID는 메시지 식별/중재에 쓰인다. 여기서 ID를 주소로 쓴다는 말은 상위 ISO-TP가 설정한 CAN ID 쌍에 진단 연결의 주소 역할을 부여한다는 뜻이다. 일반적인 목적지/발신자 주소나 인증 정보를 CAN 링크가 자동 제공한다는 뜻이 아니므로 앞 단위의 구분과 모순되지 않는다.
가상1:1 normal 연결의 ID 쌍은 다음과 같다. TX/RX는 누구의 관점인지 적어야 한다.
| 관점 | 이번 가상 연결 |
|---|---|
| tester(진단 요청 측) | TX0x620 / RX0x628 |
| ECU(응답 측) | TX0x628 / RX0x620 |
이 ID 쌍은 응용 데이터에 자동 들어가는 장치 인증 정보가 아니다. functional 요청에서는 여러 대상/응답·응답 억제 조건이 관여할 수 있으므로 '아무 응답이 없으면 모든 ECU가 고장'이라고 결론내리지 않는다. 이 활동의1:1 기록을 여러 ECU 전체의 상태로 확대하지 않는다.
첫 바이트가 UDS 서비스인지 전송 제어인지 확인한다
SID(Service Identifier)는 UDS 서비스 식별자다. 예를 들어0x22는 ReadDataByIdentifier이고, DID(Data Identifier)는 읽을 데이터 기록을 식별한다. 이번 가상 DID0x1234는 '상태 레코드'이며 실제 차량 정의가 아니다. UDS 요청은 22 12 34의3B다. 이 DID는 두 바이트12/34로 적으며 앞 단위의 속도 신호 little-endian을 임의로 가져오지 않는다.
이를 이번 Classical normal 형식의 Single Frame(SF)에 넣으면 raw CAN payload는 다음8B다.
03 22 12 34 00 00 00 00
03은 ISO-TP PCI(Protocol Control Information)의 SF/유효 길이3이고, 뒤의22부터3B가 UDS다. 나머지0은 이 예시에서 정한 padding이며 UDS 요청에 덧붙이지 않는다. 첫03을 UDS SID라고 읽거나 전체8B를 진단 요청으로 처리하면 계층을 잘못 읽은 것이다.
반대로 ISO-TP 스택이 이미 재조립/PCI 제거를 해준 API 출력은 22 12 34 자체일 수 있다. raw CAN 캡처와 이 출력을 구분해야 한다. 이미 제거된 PCI를 다시 제거해22를 버리지 않는다. Linux 문서의 API 구분을 확인하는 이유다. 여기서는 소켓/코드를 실행하지 않는다.
20B 응답은 첫 프레임과 두 연속 프레임으로 나뉜다
가상 ECU의 정상 UDS 응답을 62 12 34와 기록 데이터01부터11까지라고 준다. 여기의01~11은 16진수0x01부터0x11(십진17)까지17개 값이다. 따라서3+17=20B다. 데이터의 세부 물리 의미는 이번 예시에서 정의하지 않았으므로 임의로 속도/고장 수치로 해석하지 않는다.
이 응답의 ISO-TP 분할 기록은 다음과 같다. FF(First Frame)는 첫 프레임, CF(Consecutive Frame)는 연속 프레임, FC(Flow Control)는 흐름 제어 프레임이다. 표의 바이트는 CAN payload만이며 CAN ID/CRC/ACK 비트는 포함하지 않았다.
| 전송자/단계 | CAN ID·8B payload와 해석 |
|---|---|
| ECU FF | 0x628: 10 14 62 12 34 01 02 03. 10/14는 FF와 전체 길이0x014=20B, 첫 UDS 데이터6B |
| tester FC | 0x620: 30 00 05 00 00 00 00 00. 수신측이 다음 전송 조건을 제공 |
| ECU CF1 | 0x628: 21 04 05 06 07 08 09 0A. 순서1과 다음 UDS 데이터7B |
| ECU CF2 | 0x628: 22 0B 0C 0D 0E 0F 10 11. 순서2와 마지막 UDS 데이터7B |
첫 프레임의10은 FF 형식/길이 상위 부분이며 UDS 서비스0x10을 요청한 것이 아니다. CF의21/22도 순서 정보다. CF2 첫22를 또 다른 UDS 요청으로 읽지 않는다. 6+7+7=20B가 모여야 UDS 응답 하나가 완성된다.
이 사례는 마지막 CF에 남는 padding이 없다. 길이가 짧은 다른 메시지에서 CF에 남는 자리가 있으면 선언된 전체 PDU 길이까지만 모으고 padding 규칙을 별도로 확인한다. 길이가 맞는지 보지 않고8B씩 전부 이어 붙이지 않는다. 최신 ISO-TP의 긴 길이 확장/장치 버퍼 제한도 이번20B 예시와는 별도다.
FC는 전송 허용 조건이며 진단 성공 응답이 아니다
FC의 30 00 05를 세 부분으로 나눈다.
| 부분 | 이번 FC의 의미 |
|---|---|
| 30 | FC 형식과 CTS(Clear To Send), 전송 계속 허용 |
| 00 | BS(Block Size)=0: 남은 CF를 블록 경계의 추가 FC 없이 보낼 수 있음 |
| 05 | STmin=5ms: 연속 CF 사이 최소 분리 시간 |
BS0은 '0프레임만 보내라'는 뜻이 아니다. BS1로 바꾸면 CF 하나를 보낸 뒤 아직 데이터가 남을 때 다음 블록 전 FC를 기다린다. 메시지가 이미 끝났다면 불필요한 마지막 FC를 기다리지 않는다.
STmin의0x00~0x7F는0~127ms,0xF1~0xF9는100~900µs 범위의 별도 인코딩이다. 0xF1을241ms로 읽지 않는다. 예약된 코드는 지원 규칙을 확인한다. STmin은 최대 응답 마감이 아니고, FC를 받았다는 사실도 UDS 처리가 끝났다는 뜻이 아니다.
뒤의 P2/P2* 기록과 별개인 국소 전송 사례로 CF1 전송 종료가10ms, CF2 전송 시작이15ms라고 준다. 간격5ms는 STmin5ms 경계와 맞는다. CF2가14ms에 시작하면4ms로 부족하다. 실제 캡처 시각이 프레임 시작인지 끝인지도 모르면서 같은 뺄셈을 적용하지 않는다. 첫 CF까지의 대기와 모든 UDS 응답 시간을 STmin 하나로 대신하지 않는다.
부분 수신을 완전한 응답으로 채우지 않는다
이 예시에서 첫 CF는 순서1, 다음은순서2여야 한다. 21 다음23이 오면 순서가 맞지 않는다. 순서 번호는4bit라 긴 전송에서는15 다음0으로 순환하지만, 이것이 임의 누락을 허용한다는 뜻은 아니다. 기대 순서/전체 길이/현재 전송을 함께 확인해야 한다.
FF만 받고 CF가 오지 않거나 FC를 받지 못한 경우, timeout/overflow·padding/순서 오류를 전송 결과로 남긴다. 첫6B를 성공 응답처럼 응용에 주거나 빠진 바이트를0으로 채우지 않는다. 원인도 ECU 고장 하나로 확정하지 않는다. 주소쌍/모드·버퍼/전송 지연/실제 캡처 누락 등을 더 확인해야 한다.
Linux 구현/문서는 수신 timeout/순서·padding과 송신 FC timeout/overflow 등을 나눠 보고한다. 도구마다 오류 형식/지원이 다르므로 해당 버전의 반환값/원본 기록을 함께 남긴다. CAN ACK가 있었어도 이 전송 실패가 사라지는 것은 아니다.
완전한 UDS 응답도 긍정·거부·진행 중으로 나눈다
PEAK PCAN-UDS 매뉴얼은 정상 응답 SID의0x40 offset과 부정 응답 식별자0x7F를 설명한다. 여기의0x22 요청에 대한 정상 응답은0x62다. SID만 맞추지 않고 요청 대상 DID와 데이터 길이/형식도 확인한다.
다음은 PCI를 제거한 UDS PDU의 예시다.
| UDS PDU | 해석 |
|---|---|
62 12 34 ... | 이번0x22 / DID0x1234의 정상 응답 형식. 데이터/길이·현재 요청 대응 확인 필요 |
7F 22 31 | 0x22에 대한 NRC0x31(requestOutOfRange). 이번 요청/조건에서 거부됨 |
7F 22 78 | 0x22에 대한 NRC0x78(responsePending). 처리에 시간이 더 필요하며 최종 응답 대기 |
NRC(Negative Response Code)는 부정 응답의 이유 코드다. 7F/22/31은 세 개의 독립 서비스 요청이 아니다. 또 진행 중78을 최종 성공 또는 즉시 재요청 신호로 바꾸지 않는다. AUTOSAR DCM R24-11의 응답 pending 처리도 최종 응답과 구분한다.
정상 진단 응답은 해당 서비스의 응답이며 물리 제어/정지·전체 ECU 정상·인증 완료를 뜻하지 않는다. 거부는 서버가 특정 조건/권한/지원 범위에서 요청을 받아들이지 않은 결과일 수 있다. 한 번의 NRC만으로 실제 센서/배선 고장을 확정하지 않는다.
P2/P2* 대기와 ISO-TP 완성 시간을 구별한다
P2 계열은 응용 진단 응답을 기다리는 시간, ISO-TP의 FC/CF 대기는 전송 흐름을 기다리는 시간이다. 모두 'timeout'이라고 써도 기산점/대상/단위·실패 처리가 다르다. 서버의 처리 시간과 클라이언트가 관측하는 응답 대기도 구분한다.
다음은 자체 가상 클라이언트 정책이다. P2 대기 한도50ms, pending 수신 완료 뒤 다음 응답 시작까지의 P2* 대기 한도500ms라고 준다. 실제 모든 ECU에 같은 값을 적용하지 않으며 전송/재조립의 별도 감시도 있다고 가정한다.
| 제공 시각 | 사건/판정 |
|---|---|
| 0ms | 요청 전송 완료, P2 대기 시작 |
| 39ms | pending 응답의 수신 시작. 39≤50ms |
| 40ms | 완전한7F 22 78수신, 다음 응답 대기 시작 |
| 120ms | 최종 응답 FF 수신 시작. 120−40=80≤500ms |
| 140ms | CF까지 재조립 완료/정상 PDU 확인. 전송 감시도 별도 통과했다고 제공 |
이 기록은 응답 시작 대기와 전송 완성/형식 확인까지 나누었기 때문에 최종 결과를 판정할 수 있다. 120ms에 FF가 보였지만 CF 순서가 틀렸다면140ms의 정상 PDU 확인을 주장할 수 없다. P2/P2* 안에 응답이 시작됐다는 사실만으로 재조립 완료까지 보장하지 않는다.
pending이 반복되면 해당 정책의 다음 대기와 전체 작업 한도/최대 횟수도 확인한다. 상한 없이 기다리거나 응답이 늦다는 이유로 같은 요청을 무조건 반복하지 않는다. 클라이언트 대기가 끝났다고 서버 작업도 취소/완료됐다는 뜻은 아니다. 미확인·늦은 응답/중복 요청의 처리 정책을 남긴다.
세션은 진단 문맥이며 보안 권한과 같다 하지 않는다
진단 세션은 현재 허용 서비스/조건·타이밍 등의 문맥이다. 기본 세션과 비기본 세션이 있고, 서버가 지원하는 세션/서비스는 형상/정책에 따라 다르다. 세션 변경 응답을 받았다고 모든 작업의 보안 권한을 얻은 것은 아니다. 세션·SecurityAccess/인증·서비스별 조건을 구분한다.
S3server는 비기본 세션의 유휴 관리와 관계된다. 독립된 가상 유휴 사례에서 S3=5000ms, 타이머 시작0ms·이후 요청/진단 처리가 없다고 준다. 시각5001ms면 유휴 한도를 넘겨 기본 세션 복귀를 예상한다. 앞의 pending 처리 타임라인에 이 유휴 조건을 섞지 않는다.
TesterPresent는 연결된 tester가 있음을 알리는 서비스지만 임의 주기로 무한 송신하는 과제가 아니다. 지원/세션 정책·응답 억제·현재 처리/타이머 조건을 실제 문서에서 확인해야 한다. CAN ID가 유지됐다는 사실만으로 예전 세션/권한 상태가 남았다고 가정하지 않는다.
다음 진단 단계에 원본과 미확인을 넘긴다
보고서에는 대상/형상·주소쌍/방식·CAN 형식·원본 프레임/시각·재조립 PDU·요청 SID/DID·세션/조건·응답/오류·타이머·미확인을 연결한다. 장비 없는 분석에서 실제 진단 수행/고장 해결을 완료했다고 쓰지 않는다.
기존 4.4 시간 정합의 원본 시각 원칙과 M26.06 요구/결함 근거를 이어 간다. 다음 M28.04 DTC·고장 추적에서도 응답 코드·진단 기록·실제 고장 원인을 나누어 읽는다.