카드뉴스
CAN Data Frame은 ID·DLC·DATA만으로 끝나지 않습니다
CAN 분석기 화면에는 대개 ID, DLC, DATA가 먼저 보입니다. 하지만 이는 분석 도구가 로그 확인에 필요한 값만 추려 놓은 것입니다. Classic CAN Data Frame은 버스에서 SOF, Arbitration Field, Control Field, Data Field, CRC Field, ACK Field, EOF 순으로 전송됩니다. 시작을 맞추고, 버스 사용 순서를 정하고, 데이터 길이와 오류 여부를 확인하는 일이 각 필드에 나뉘어 있습니다. 이 구성을 알아야 값 해석 문제와 통신 자체의 문제를 구별할 수 있습니다.
SOF와 CAN ID는 전송 시작과 중재에 관여합니다
버스가 유휴 상태일 때 dominant 비트로 들어오는 SOF(Start of Frame)는 새 프레임의 시작을 알립니다. 수신 노드는 이 경계를 기준으로 프레임을 받아들이며, 이후 비트 에지를 이용해 동기를 계속 보정합니다.
CAN ID는 송신 ECU의 주소라기보다 메시지를 구분하는 식별자입니다. 동시에 여러 노드가 전송을 시작하면 각 노드는 자신이 보낸 비트와 버스 값을 비교합니다. recessive 1을 보냈는데 dominant 0이 읽힌 노드는 중재에서 물러나고, 이긴 노드는 프레임을 끊지 않고 전송합니다. 그래서 같은 형식끼리는 보통 숫자가 작은 ID가 먼저 버스를 사용합니다. 다만 표준 11비트와 확장 29비트 프레임이 섞였다면 ID 숫자만 떼어 보지 말고 중재 필드 전체를 기준으로 판단해야 합니다.
DLC와 Data Field를 물리값으로 바꾸려면 해석 규칙이 필요합니다
Classic CAN의 실제 payload는 0~8바이트입니다. DLC가 8이라면 Byte0부터 Byte7까지 있다는 뜻이지, 어느 바이트가 속도·토크·온도인지는 알려주지 않습니다. 시작 비트와 비트 길이, 바이트 순서, signed 여부, factor, offset을 적용해야 원시 데이터가 물리값으로 바뀝니다. DBC가 없거나 ECU와 DBC 버전이 맞지 않으면 정상 프레임도 엉뚱한 값으로 해석될 수 있습니다.
CAN FD는 최대 64바이트를 담고 DLC 9 이상에서 코드와 실제 길이의 대응도 달라집니다. CAN 로그를 읽을 때 프레임 형식을 먼저 확인해야 Classic CAN의 8바이트 범위와 CAN FD 길이를 혼동하지 않습니다.
CRC·ACK·EOF를 함께 보면 통신 이상을 좁힐 수 있습니다
Classic CAN의 CRC-15는 수신한 프레임 비트로 다시 계산한 값과 전송된 CRC를 비교해 손상을 검출합니다. CRC가 맞는다고 신호 정의나 데이터 내용까지 옳다는 뜻은 아닙니다. ACK도 애플리케이션 처리가 끝났다는 응답이 아닙니다. 송신 노드는 ACK slot을 recessive로 보내고, 프레임을 정상 수신한 노드가 하나라도 있으면 dominant로 덮습니다.
EOF가 프레임의 끝을 표시하면 짧은 intermission 뒤에 다음 전송이 가능합니다. 로그를 점검할 때는 ID 형식, DLC, 원시 바이트와 주기를 먼저 보고, CRC 오류나 ACK 누락이 반복되면 비트 타이밍, 종단저항, 배선, 트랜시버 상태와 오류 카운터까지 범위를 넓혀 확인하는 편이 빠릅니다.
