CAN·CAN FD·CAN XL과 UDS 진단 — DBC 신호·주기·오류 카운터·버스 오프·진단 서비스 검증

개념

CAN은 왜 다른가

레슨 2의 UART·SPI·I2C는 보드 안의 짧은 연결이었다. CAN(Controller Area Network)은 여러 ECU가 차량 전체에 걸친 두 선(CAN_H, CAN_L)을 공유 하는 버스다. 차동 신호라 잡음에 강하고, 마스터가 없으며, 모든 노드가 모든 프레임을 듣는다. 프레임에는 목적지 주소가 없고 ID 가 있다. ID는 "누구에게"가 아니라 "무슨 내용인가"(예: 0x1A0 = 차속)를 뜻한다.

중재 — ID가 작을수록 이긴다

두 노드가 동시에 송신을 시작하면 ID 비트를 한 비트씩 내보내며 버스를 읽는다. 0(dominant)이 1(recessive)을 이긴다. 자기가 1을 보냈는데 버스가 0이면 진 것이므로 조용히 물러나 나중에 다시 보낸다. 결과적으로 ID 값이 작을수록 우선순위가 높다. 이긴 프레임은 손상 없이 전송되므로 충돌로 대역폭을 잃지 않는다.

테스터에게 중요한 결과는 이것이다. 버스 부하가 높을 때 낮은 우선순위(큰 ID) 메시지는 계속 밀려 지연된다. 브레이크 신호는 늦지 않지만 진단 메시지나 편의 기능 메시지는 수십 ms 늦을 수 있다. 버스 부하율(보통 설계 목표 50~70% 이하)과 큰 ID 메시지의 최악 지연은 측정 대상이다.

클래식 CAN · CAN FD · CAN XL

ISO 11898-1:2024는 클래식·FD·XL 세 형식을 한 문서에서 정의한다. CAN FD의 핵심은 중재는 느린 속도로, 데이터는 빠른 속도로 보내는 비트레이트 전환(BRS)이다. 그래서 CAN FD 노드와 클래식 CAN 전용 노드가 같은 버스에 있으면 클래식 노드가 FD 프레임을 오류로 보고 오류 프레임을 낸다. 혼합 버스 구성은 시험 대상 이다.

DBC — 바이트를 물리값으로

CAN 프레임의 데이터는 그냥 바이트다. 어느 비트가 무슨 신호인지는 DBC 파일(Vector가 만든 사실상 표준 형식)이 정의한다.

BO_ 416 VehicleSpeed: 8 ESC
 SG_ VehSpd : 0|16@1+ (0.01,0) [0|320] "km/h" Cluster,EMS
 SG_ VehSpdValid : 16|1@1+ (1,0) [0|1] "" Cluster

두 번째 줄을 읽으면 이렇다. 시작 비트 0, 길이 16비트, @1 은 인텔(리틀 엔디언) 바이트 순서, + 는 부호 없음, 스케일 0.01, 오프셋 0, 범위 0~320km/h. 물리값 = 원시값 × 스케일 + 오프셋이다.

DBC 기반 신호 검증의 전형적 결함과 시험은 이렇다.

이것은 모듈 3 레슨 1의 경계값 분석을 신호마다 반복하는 일이다. 신호가 수백 개이므로 DBC를 읽어 케이스를 자동 생성 하는 스크립트가 실무 표준이다.

주기와 타임아웃 감시

대부분의 CAN 메시지는 주기적으로 보낸다(예: 차속 10ms, 도어 상태 100ms). 수신 ECU는 정해진 시간 동안 메시지가 오지 않으면 타임아웃 으로 판단하고 대체값이나 고장 처리로 넘어가야 한다.

아래 예시에 DTC 가 나온다. 장치가 고장을 감지했을 때 "무엇이 어떻게 잘못됐다" 를 정해진 번호로 남기는 고장 코드다. 정비소에서 진단기를 꽂으면 읽히는 그 코드이고, 이 모듈에서는 고장을 겪었다는 증거가 실제로 남는가 를 보는 시험 항목으로 쓴다.

요구: VehicleSpeed 주기 10ms ±10%, 수신 측은 5주기(50ms) 미수신 시 타임아웃 DTC 기록, 대체값 0 사용
 
시험 1  주기 측정: 1시간 기록, 최소·최대·표준편차 → 9~11ms 안인가
시험 2  49ms 끊김 → 타임아웃 없어야 함
시험 3  61ms 끊김 → 반드시 타임아웃 DTC, 대체값 사용
시험 4  메시지 재개 → 정상값 복귀, 복구 조건(몇 주기 연속 수신 후)이 요구대로인가

경계를 49ms·61ms로 벌린 이유는 타이머 해상도다. 수신 쪽 타임아웃 검사가 10ms 태스크에서 돈다면 실제 판정 시점은 50~60ms 사이에서 흔들린다. 이 구간 안의 끊김은 판정이 매번 달라지므로, 요구가 이 흔들림을 허용하는지 먼저 확인하고 허용 폭 바깥에서 합격·불합격 경계를 잡는다.

오류 카운터와 버스 오프

CAN 컨트롤러는 TEC(송신 오류 카운터) 와 REC(수신 오류 카운터) 를 가진다. 오류가 나면 카운터가 오르고(송신 오류는 +8), 성공하면 내려간다(−1).

버스 오프는 고장 난 노드가 버스 전체를 망가뜨리지 않게 하는 장치다. 하지만 버스 오프 뒤 어떻게 돌아오는가 는 소프트웨어 설계에 달려 있다. 규격은 128번의 연속 11 recessive 비트를 확인한 뒤 복귀할 수 있게 하고, 그 뒤의 정책(즉시 재시도, 점진적 재시도 간격, 몇 번 이후 포기, DTC 기록)은 요구사항이 정한다.

버스 오프 복구 시험
1. 대상 ECU가 송신 중일 때 CAN_H와 CAN_L을 단락(또는 오류 주입 장비로 비트 파괴)
2. TEC 상승 기록 → 128에서 error-passive, 255 초과에서 bus-off 진입 확인
3. 단락 해제
4. 판정: 요구된 시간 안에 복귀하는가, 복귀 시도 간격이 요구대로인가,
         버스 오프 DTC가 기록되는가, 복귀 뒤 신호가 정상인가
5. 단락을 해제하지 않은 상태로 지속 → 재시도가 버스를 계속 방해하지 않는가

마지막 항목이 자주 빠진다. 고장 난 노드가 너무 빨리 재시도하면 버스 오프와 복귀를 반복하며 버스 전체를 괴롭힌다.

UDS — 진단 서비스

UDS(Unified Diagnostic Services, ISO 14229-1)는 정비 장비나 테스트 도구가 ECU에 요청하고 응답을 받는 진단 프로토콜이다. CAN 위에서는 ISO 15765-2(ISO-TP)가 긴 메시지를 여러 프레임으로 나눠 운반한다. 요청의 첫 바이트가 서비스 ID(SID)이고, 긍정 응답은 SID + 0x40이다.

부정 응답 코드

거부할 때는 7F SID NRC 형태로 응답한다. 부정 응답은 정상 동작의 절반 이므로 긍정 경로만큼 시험한다.

SecurityAccess는 보안 시험이기도 하다. 틀린 키 시도 횟수 제한, 지연 타이머가 리셋으로 우회되지 않는가, 시드가 매번 달라지는가(고정 시드는 재전송 공격에 취약)를 본다.

도구 예시

CANoe(Vector)는 시뮬레이션·자동 시험·진단을 한 도구에서 하는 업계 표준이고, BUSMASTER는 오픈소스 버스 분석 도구다. 스크립트 자동화에는 python-can이 흔하다.

import can
bus = can.interface.Bus(channel="can0", interface="socketcan")
msg = can.Message(arbitration_id=0x1A0, data=[0xFF, 0xFF, 0, 0, 0, 0, 0, 0],
                  is_extended_id=False)
bus.send(msg)          # 원시값 0xFFFF → 무효값 처리 시험

도구보다 중요한 것은 무엇을 판정하는가 다. 같은 시험을 어느 도구로 하든 기대 결과는 요구사항과 DBC, UDS 명세에서 온다.

실무에서 왜 필요한가

차량 한 대에 ECU가 수십 개이고, 각 ECU는 다른 협력사가 만든다. 통합 단계에서 드러나는 결함 상당수가 신호 정의 불일치와 통신 이상 처리 다. 한 ECU는 DBC 3.2로, 다른 ECU는 3.1로 빌드되어 있거나, 타임아웃 대체값이 서로 다르거나, 버스 오프 뒤 복귀가 너무 빨라 버스 전체를 흔드는 일이 실제로 일어난다. 진단 서비스는 정비소와 생산 라인에서 쓰이므로, 부정 응답 한 줄이 틀려도 정비 장비가 ECU를 인식하지 못하거나 생산 라인이 멈춘다. CAN과 UDS를 아는 테스터는 이런 결함을 ECU 단독 시험 단계에서 미리 잡는다.

채용시장에서의 위치

자동차 전장 검증 공고에서 CAN·CAN FD·UDS는 거의 필수 키워드이고, CANoe·CANalyzer 사용 경험이 우대 조건으로 자주 붙는다. 면접에서는 "중재가 어떻게 동작하나", "버스 오프 조건과 복구 시험을 어떻게 설계하나", "NRC 0x33과 0x7F의 차이는" 같은 질문이 나온다. 존 아키텍처가 확산되면서 CAN XL과 차량 이더넷을 함께 이해하는 인력 수요도 늘고 있다. 도구 사용법보다 DBC와 UDS 명세를 시험 케이스로 바꿔 본 경험 이 차별점이 된다.

실습 과제

과제 1 — DBC 한 줄 해독 (10분)

SG_ CoolantTemp : 24|8@1+ (1,-40) [-40|215] "degC" 를 해독해 시작 비트·길이·바이트 순서·부호·스케일·오프셋·범위를 적는다. 원시값 0, 40, 255가 각각 몇 °C인지 계산하고, 경계값 시험 케이스 다섯 개(무효값 포함)를 설계한다.

과제 2 — 타임아웃 시험 설계 (15분)

"도어 상태 메시지(주기 100ms)가 300ms 동안 오지 않으면 도어 열림으로 간주하고 경고등을 켠다. 3주기 연속 수신되면 정상 복귀한다." 이 요구로 경계 시험 케이스를 만들고, 수신 측 검사 태스크 주기가 20ms일 때 경계를 어떻게 잡을지 설명한다.

과제 3 — UDS 부정 경로 표 (15분)

WriteDataByIdentifier(0x2E)로 차대번호 DID(0xF190)를 쓰는 기능에 대해, 긍정 응답 1건과 부정 응답 6건(NRC 0x13·0x22·0x31·0x33·0x7F 포함)을 유도하는 요청 바이트열과 기대 응답을 표로 쓴다.

자가 체크리스트

• CAN ID 중재 원리와 버스 부하가 큰 ID 메시지 지연에 미치는 영향을 설명할 수 있다
• 클래식 CAN·CAN FD·CAN XL의 페이로드와 속도 차이, 혼합 버스의 위험을 말할 수 있다
• DBC 신호 정의를 읽고 스케일·오프셋·바이트 순서·범위 경계 케이스를 만들 수 있다
• 주기·타임아웃 시험의 경계를 타이머 해상도까지 고려해 잡을 수 있다
• TEC·REC와 error-passive·bus-off 조건, 버스 오프 복구 시험 절차를 설명할 수 있다
• UDS 주요 서비스(0x10·0x11·0x14·0x19·0x22·0x27·0x2E)와 대표 NRC를 유도하는 요청을 쓸 수 있다

흔한 실수

• 긍정 응답만 시험한다. UDS에서 부정 응답은 명세의 절반이다. 세션·보안·길이·범위 조건마다 NRC를 유도한다.
• DBC 값을 중간값 하나로만 확인한다. 바이트 순서 오류는 중간값에서 우연히 맞기도 한다. 최소·최대·한쪽 바이트만 채운 값을 쓴다.
• 타임아웃 경계를 요구 숫자 그대로 잡는다. 검사 태스크 주기만큼 판정이 흔들린다. 흔들림 폭 바깥에서 경계를 잡는다.
• 버스 오프 진입만 보고 끝낸다. 복귀 시간, 재시도 간격, 고장 지속 시 버스 방해 여부가 진짜 시험이다.
• SecurityAccess 지연 타이머를 한 번만 본다. 리셋·전원 재투입으로 우회되지 않는지 확인한다.
• 도구 화면을 증거로 삼는다. 기록 파일(로그·트레이스)과 사용한 DBC 버전을 함께 보관해야 재현된다.

참고 자료

• ISO 11898-1:2024 — Road vehicles, Controller area network (CAN), Part 1: Data link layer and physical coding sublayer — 클래식·FD·XL 형식 정의
• ISO 14229-1:2020 — Unified diagnostic services, Part 1: Application layer (ISO)
• CAN in Automation (CiA) — CAN FD·CAN XL 기술 자료와 CiA 규격
• python-can 문서 — 스크립트 기반 송수신과 로그 기록
• Vector, "DBC File Format Documentation" — DBC 문법
• ISO 15765-2 — Diagnostic communication over CAN(ISO-TP) 전송 계층
• 레슨 s5-m46-l02 — 직렬 통신의 프레임과 오류 처리
• 레슨 s1-m03-l01 — 경계값 분석
• 레슨 s5-m29-l07 — 저하 상태에서의 타임아웃·재시도 점검