CAN 프레임 안에 UDS는 어떻게 들어가나 — ISO-TP 정리

개정: 2026-10-04. 설명 범위를 Classical CAN 일반 주소 방식으로 한정하고, 50바이트 예제의 FC를 CTS 4회와 Wait 1회, 총 5회로 정리했습니다.

CANoe Trace의 03 22 F1 90 AA AA AA AA는 무엇일까요? 앞의 03은 UDS 서비스가 아니라 ISO-TP의 제어 정보입니다. 이 글은 CAN 데이터 안에서 길이·순번·흐름 제어를 읽는 연습입니다. 서비스가 허용되는지는 별도 UDS 사양으로 판정합니다.

1. 먼저 적용 범위를 붙입니다

아래 바이트 예제는 Classical CAN, 데이터 길이 8바이트, 일반(normal) 주소 형식, 물리 주소 1:1 전송을 가정합니다. 일반 주소는 CAN ID로 주소를 표현하므로 데이터 첫 바이트가 PCI입니다. 확장·혼합 주소 형식에는 추가 주소 바이트가 들어갈 수 있습니다. CAN FD는 최대 64바이트 데이터와 다른 길이 처리가 있으므로 여기의 “7바이트” 규칙을 그대로 적용하지 않습니다.

CAN의 ID는 프레임을 구분하고, DLC는 데이터 길이를 나타냅니다. 이 범위의 데이터는 최대 8바이트입니다. ISO-TP는 그 안에 PCI와 진단 데이터를 넣고, 한 프레임에 안 들어가면 분할·재조립합니다. CAN의 CRC·ACK는 링크 전송에 관여하지만 UDS 서비스 결과나 ECU 애플리케이션 처리 완료를 보장하지 않습니다.

2. DLC와 진단 데이터 길이는 다릅니다

03 22 F1 90 AA AA AA AA에서 DLC는 8, SF의 진단 데이터 길이는 3입니다. PCI 03의 상위 4비트 0은 Single Frame, 하위 4비트 3은 길이입니다. 실제 UDS 바이트는 22 F1 90이고 나머지 AA 네 개는 이 예제의 패딩입니다. AA는 모든 프로젝트의 공통 정답이 아닙니다.

Classical CAN·일반 주소·물리 1:1 예에서 DLC 8은 PCI 1바이트, UDS 3바이트, 패딩 4바이트로 나뉩니다. AA는 이 예제의 가정입니다.
Classical CAN·일반 주소·물리 1:1 예에서 DLC 8은 PCI 1바이트, UDS 3바이트, 패딩 4바이트로 나뉩니다. AA는 이 예제의 가정입니다.
종류PCI 예이 범위에서 읽는 내용
SF 단일03길이 3, 최대 진단 데이터 7바이트
FF 첫10 3212비트 길이 0x032=50, 이어지는 데이터 6바이트
CF 연속21순번 1, 이어지는 데이터 최대 7바이트
FC 흐름 제어30 02 14CTS, BlockSize 2, STmin 20ms

SF는 이 범위에서 UDS 7바이트까지 담습니다. 8바이트부터는 다중 전송이 필요합니다. FF의 12비트 길이를 모든 ISO-TP 판본·프레임 형식의 절대 최대값으로 설명하지 않습니다. 실제 길이 지원과 버퍼 제한은 적용 규격·구현을 확인합니다.

3. 50바이트를 실제 바이트로 나눠 봅니다

교육용 가상 요청은 2E 12 34와 값 00~2E입니다. SID 1바이트+DID 2바이트+값 47바이트=총 50바이트입니다. DID 0x1234가 실제 차량에서 존재하거나 쓰기를 허용한다는 뜻이 아니며, 아래는 실제 실행 로그가 아닙니다. DLC는 8, 패딩은 AA로 가정합니다.

테스터가 데이터를 보내고 ECU가 FC를 보냅니다. 수신기가 Wait 1회를 허용하는 상황을 가정하며, 그 뒤 각 CTS가 CF 2개를 허용합니다. 각 CF 사이의 최소 간격은 0x14=20ms입니다. Wait 허용 횟수와 대기 제한은 승인된 전송 사양을 따라야 합니다.

방향·종류데이터 필드(16진수)진단 데이터 누적
테스터 → FF10 32 2E 12 34 00 01 026
ECU → Wait31 00 00 AA AA AA AA AA6
ECU → CTS 130 02 14 AA AA AA AA AA6
테스터 → CF 121 03 04 05 06 07 08 0913
테스터 → CF 222 0A 0B 0C 0D 0E 0F 1020
ECU → CTS 230 02 14 AA AA AA AA AA20
테스터 → CF 323 11 12 13 14 15 16 1727
테스터 → CF 424 18 19 1A 1B 1C 1D 1E34
ECU → CTS 330 02 14 AA AA AA AA AA34
테스터 → CF 525 1F 20 21 22 23 24 2541
테스터 → CF 626 26 27 28 29 2A 2B 2C48
ECU → CTS 430 02 14 AA AA AA AA AA48
테스터 → CF 727 2D 2E AA AA AA AA AA50

FF의 6바이트 + CF 여섯 개의 42바이트 + 마지막 CF의 2바이트 = 50입니다. CF의 PCI·마지막 패딩·FC는 이 길이에 포함하지 않습니다. CTS는 4회, Wait까지 포함한 FC는 총 5회입니다. 마지막 CF 뒤에 전송 완료 확인용 FC를 하나 더 붙이지 않습니다. 이후 UDS 응답은 별도의 반대 방향 전송입니다.

기존 50바이트 전송 흐름 개념도입니다. BS 2에서 FF 1+CF 7, CTS 4회와 Wait 1회를 포함한 FC 총 5회를 가정합니다. 20ms는 최소 간격이고 그림의 요청 바이트는 현재 가상 DID와 별개입니다.
기존 50바이트 전송 흐름 개념도입니다. BS 2에서 FF 1+CF 7, CTS 4회와 Wait 1회를 포함한 FC 총 5회를 가정합니다. 20ms는 최소 간격이고 그림의 요청 바이트는 현재 가상 DID와 별개입니다.

4. BlockSize는 바이트 수가 아닙니다

BlockSize 02는 CF 두 개를 보낸 뒤 다음 FC를 기다린다는 뜻입니다. 한 CF가 7바이트를 실으므로 완전한 블록은 14바이트입니다. 마지막 블록은 남은 2바이트만 실어도 끝납니다. BlockSize 00이면 허용된 나머지 CF를 중간 블록 FC 없이 보냅니다.

FC의 흐름 상태 0은 CTS, 1은 Wait, 2는 Overflow입니다. Wait를 받았다고 계속 보내면 안 되고, 무한 대기도 아닙니다. STmin의 00~7F는 0~127ms, F1~F9는 100~900µs입니다. 다른 예약값을 임의 시간으로 해석하지 않습니다.

5. Trace에서 실패를 좁히는 순서

  1. CAN ID·주소 형식·DLC·패딩이 승인 설정과 맞는지 봅니다. 요청과 응답의 패딩 정책은 다를 수 있습니다.
  2. FF 길이와 재조립한 데이터 길이를 비교합니다. 순번은 1~F 다음 0으로 돌아가며, 누락·순서 오류를 찾습니다.
  3. 누가 송신자·수신자인지 적고, FC 방향, BlockSize 경계의 멈춤과 다음 CTS를 확인합니다.
  4. CF 시각으로 STmin을 확인하고, FC·CF 대기 제한은 전송 사양과 대조합니다.
  5. 재조립이 끝난 뒤에 UDS SID·DID·NRC를 판정합니다. 패딩·순번 오류를 곧바로 특정 UDS NRC로 단정하지 않습니다.

단일 프레임이 통과해도 다중 프레임은 별도 시험이 필요합니다. 긴 요청·응답, 순번 누락, FC 지연, BlockSize 변경, 잘못된 패딩을 승인된 환경에서 확인하고 원시 Trace를 남깁니다. 지원하지 않는 Wait 시험을 도구에 무조건 요구하지 말고 구현의 제한도 확인하세요.

공식 자료와 이어서 읽기

Linux Kernel 공식 ISO-TP 문서는 주소 형식, 분할·FC·STmin과 구현 제한을 설명합니다. 해당 구현은 Wait 송신을 지원하지 않는다고 밝히므로 위 가상 Wait 시나리오를 그대로 재현한다고 가정하지 않습니다. CiA CAN FD 안내는 FD의 최대 64바이트 데이터를 설명합니다. 실제 판정은 적용 ISO 15765-2와 고객 전송 사양의 승인본을 사용합니다.

UDS 서비스·NRC 판정 · DBC·LDF와 로그 해석

댓글

댓글 쓰기

이 블로그의 인기 게시물

Automotive SPICE SYS.2에서 SYS.5 테스트 케이스 생성하기 — AI 활용, 요구사항부터 검증까지의 실무 프로세스

이미지
수정 2026-10-04: 가상 보충 요구사항과 판정 근거를 구분하고, 센서 오류 시험의 관찰 방법을 보완했습니다. SYS.2에서 요구사항을 작성했는데 SYS.5 테스트케이스로 옮기려니 막막한가요? 핵심은 문장을 시험 항목으로 복사하는 것이 아니라, 입력·조건·관찰값·판정 기준을 연결하는 것 입니다. 아래는 전동식 오일펌프 제어기를 가정한 교육용 예제입니다. 실제 고객 사양이나 실행 결과가 아닙니다. 시스템 요구사항에서 AI 보조 초안과 제어기 검증으로 이어지는 개념도입니다. 1. 먼저 검증의 기준을 정합니다 이 글은 Automotive SPICE 4.0 기준입니다. SYS.2는 시스템 요구사항 분석, SYS.5는 System Verification(시스템 검증)입니다. SYS.5에서는 통합된 시스템이 시스템 요구사항과 일치하는지 확인합니다. SYS.4는 시스템 아키텍처를 기준으로 요소의 통합과 상호작용을 검증합니다. HIL이나 Bench라는 장비 이름만으로 두 프로세스를 나누지 않습니다. 실제 적용 버전은 계약과 개발계획에서 확인하세요. Automotive SPICE 4.0 용어로 교정한 시스템 수준의 대응 관계입니다. SYS.2는 SYS.5, SYS.3은 SYS.4의 검증 근거와 연결됩니다. 2. 요구사항과 보충 가정을 분리합니다 이 절부터 나오는 ID·수치·시간은 모두 설명용 가상 가정입니다. 실제 시험에는 승인된 사양을 사용해야 합니다. 특히 아래 4000 RPM 대체 운전값은 안전성이 검증된 값도, 모든 펌프에 적합한 안전속도도 아닙니다. 가상 요구사항 내용 REQ-001 속도 제어 목표 명령에 따라 펌프 속도를 제어한다. REQ-002 과열 제한 내부 온도가 95°C를 초과하면 속도를 제한하고 경고를 전송한다. REQ-003 센서 오류 속도 센서 오류를 검출하면 정의된 대체 운전 모드로 전환한다. 이 문장만으로는 시험을 확정할 수 없습니다. 명령의 단위, 제한값, 반응시간, 복귀 조건이 빠져 있기 때문입니다. 예제를 완성하기 위...
자세한 내용 보기

자동차도 시험을 볼까? MIL·SIL·PIL·HIL을 초등학생도 쉽게 이해하기

이미지
수정 2026-10-04: 시험환경을 고르는 짧은 연습과 공식 업체 자료를 추가하고, 고정 순서로 오해할 수 있는 설명을 정리했습니다. 자동차도 시험을 볼까요? 새 제어 프로그램을 곧바로 도로에서 시험하면 위험하고 준비도 많이 필요합니다. 그래서 개발자는 컴퓨터 속 모델, 프로그램 코드, 자동차용 칩, 실제 제어기와 부품을 목적에 맞게 조합해 확인합니다. MIL·SIL·PIL·HIL은 “시험 고리 안에 무엇을 넣었는가”를 구분하는 이름 입니다. IL은 In-the-Loop입니다. 입력을 주고, 대상의 반응을 관찰하며, 모델이나 주변 환경과 연결해 동작을 확인한다고 이해하면 쉽습니다. 자동차 전체를 항상 고리 안에 넣는 것은 아닙니다. 작은 제어 기능 하나부터 시작할 수도 있습니다. 1교시: MIL은 모델로 아이디어를 확인합니다 MIL(Model-in-the-Loop)은 제어기와 대상의 동작을 수학 모델로 표현해 컴퓨터에서 확인하는 방식입니다. 실제 펌프와 제어기 대신 가상 펌프와 제어 알고리즘을 연결하는 모습입니다. 레고 자동차를 만들기 전에 설계 그림으로 움직임을 생각해 보는 것과 비슷합니다. MIL 개념도: 제어기와 대상의 모델로 동작 규칙을 확인합니다. “온도가 올라가면 냉각 요청을 늘릴까?”, “입력이 사라지면 어떤 상태로 갈까?” 같은 규칙을 빠르게 바꾸며 살펴볼 수 있습니다. 하지만 모델이 실제 부품의 지연이나 부하를 틀리게 표현하면 계산 결과가 좋아도 실물에서는 다를 수 있습니다. 모델의 적용 범위부터 확인해야 합니다. 2교시: SIL은 실제 코드를 PC에서 확인합니다 SIL(Software-in-the-Loop)은 제어 소프트웨어나 생성 코드를 호스트 컴퓨터에서 실행하는 방식입니다. MIL의 제어 모델 자리를 코드로 바꾼다고 생각하면 됩니다. 같은 입력에서 모델과 코드의 계산 결과를 비교하고, 경계값·상태 전환을 반복해서 확인하기 좋습니다. SIL 개념도: 호스트 컴퓨터에서 제어 소프트웨어를 실행해 비교합니다. MathWorks ...
자세한 내용 보기