CAN Frame에서 다룬 기존 CAN 프레임은 Data Field가 최대 8바이트로 제한되고, 프레임 전체가 하나의 비트율로만 전송된다. Robert Bosch GmbH는 이 두 한계를 넘어서기 위해 2012년 CAN FD(CAN with Flexible Data-Rate) 사양을 발표했다 — Data Field를 최대 64바이트로 늘리고, 중재가 끝난 구간만 별도로 설정한 더 빠른 비트율로 전송할 수 있게 확장한 프레임 형식이다[1]. 이 확장은 이후 ISO 11898 Part 1에 편입돼 기존 CAN 프레임과 나란히 규정된다.
Example
중재 구간과 데이터 위상의 비트율을 1:8로 설정하면, 헤더·CRC 오버헤드가 늘어난 점을 감안해도 전체 처리량은 기존 CAN 대비 약 6배로 늘어난다[2].
확장된 Control Field
CAN FD는 Control Field에 세 비트를 새로 끼워 넣는다. FDF(Flexible Data-Rate Format) 비트는 recessive로 전송돼 프레임이 CAN FD 형식임을 알린다 — dominant면 기존 CAN 형식이다. FDF 뒤에는 항상 dominant로 고정된 예약 비트 r0가 따르고, 그 뒤로 BRS(Bit Rate Switch)와 ESI(Error State Indicator) 두 비트가 이어진 다음 DLC로 연결된다[1].
Standard Format(11비트 식별자)에서는 RTR 비트가 있던 자리가 dominant로 고정된 예약 비트로 바뀐다 — RTR은 Data Frame과 Remote Frame을 가르는 비트였지만, CAN FD에는 Remote Frame이 없으므로 이 자리는 더 이상 가변값일 필요가 없다[1]. Extended Format(29비트 식별자)에서도 원래 RTR이 있던 자리가 동일하게 dominant로 고정되며, 이 비트는 흔히 RRS(Remote Request Substitution)라 불린다.
Data Field 확장과 DLC
DLC(Data Length Code) 필드는 4비트 그대로지만 해석이 늘어난다. DLC 0~8은 기존 CAN과 동일하게 바이트 수를 그대로 가리키지만, 기존 CAN에서 9~15가 모두 8바이트로 묶이던 것과 달리 CAN FD에서는 각 값이 서로 다른 Data Field 길이를 가리킨다[1]:
| DLC | CAN Data Field(바이트) | CAN FD Data Field(바이트) |
|---|---|---|
| 0~8 | 0~8 | 0~8 |
| 9 | 8 | 12 |
| 10 | 8 | 16 |
| 11 | 8 | 20 |
| 12 | 8 | 24 |
| 13 | 8 | 32 |
| 14 | 8 | 48 |
| 15 | 8 | 64 |
CAN FD는 Remote Frame을 정의하지 않는다 — Data Field 없이 특정 식별자의 데이터를 요청하는 절차 자체가 CAN FD 형식에는 없다[1]. 그 결과 버스에 실리는 메시지는 식별자 길이(Standard·Extended)와 프레임 종류를 조합해 Standard/Extended Remote Frame, Standard/Extended CAN Data Frame(최대 8바이트), Standard/Extended CAN FD Data Frame(최대 64바이트) 여섯 가지로 좁혀진다[3].
Bit Rate Switch(BRS)와 데이터 위상
CAN FD 컨트롤러는 비트 타이밍 레지스터를 두 벌 설정한다 — 기존 CAN Bit Timing과 동일하게 동작하는 Arbitration Phase용 명목 비트율과, 그보다 짧은 비트 시간을 쓸 수 있는 Data Phase용 별도 비트율이다. BRS 비트가 recessive면 이 두 번째 비트율로 전환되고, dominant면 전환 없이 명목 비트율을 유지한다[1].
전환 지점은 비트 하나 단위로 고정된다 — BRS 비트의 Sample Point에서 Data Phase 비트율로 전환되고, CRC Delimiter 비트의 Sample Point에서 다시 Arbitration Phase 비트율로 돌아온다[1]. 이 전환이 가능한 이유는 두 구간이 요구하는 동기화 수준이 다르기 때문이다 — 중재 중에는 여러 노드가 동시에 신호를 내보내므로 모든 노드가 서로 동기 상태를 유지해야 하지만, 중재가 끝나 단일 노드만 송신하는 구간에서는 이 다중 노드 동기화 제약이 사라진다[2].
이 두 전환 지점에서는 CAN Bit Timing이 규정하는 일반적인 재동기화 절차를 쓰지 않는다. 대신 FDF 비트에서 이어지는 dominant 예약 비트(r0)로의 recessive→dominant 전환을 하드 동기화 지점으로 삼고, Data Phase 동안에는 송신 노드가 재동기화를 하지 않는다[1].
ESI(Error State Indicator)
일반 CAN에는 수신 노드가 송신 노드의 오류 상태를 알 수단이 없다. CAN FD는 ESI 비트로 이를 보완한다 — 송신 노드가 Error Active 상태면 ESI를 dominant로, Error Passive 상태면 recessive로 실어, 프레임을 받는 모든 노드가 송신 노드의 오류 상태를 그 자리에서 알 수 있게 한다[1].
CRC 확장과 Stuff Count
CAN FD는 최대 64바이트로 늘어난 Data Field를 보호하기 위해 15비트 CRC보다 긴 두 다항식을 새로 쓴다 — Data Field가 16바이트 이하면 17비트 CRC_17(생성 다항식 16진수로 0x3685B), 16바이트를 넘으면 21비트 CRC_21(0x302899)이며, 둘 다 기존 CRC_15와 같은 해밍 거리(HD=6)를 유지하도록 설계됐다. 계산 대상 비트열도 달라진다 — 일반 CAN에서는 스터프 비트가 CRC 계산에서 제외되지만, CAN FD는 스터프 비트까지 포함해 계산한다[1].
CRC Sequence 구간의 스터핑 규칙도 다르다. 5비트 연속 규칙 대신, CRC Sequence의 첫 비트 앞과 그 뒤로 4비트마다 고정된 위치에 스터프 비트를 끼워 넣고, 그 값은 항상 직전 비트의 반대 값으로 고정한다[1].
Warning
Bosch의 2012년 최초 사양(Version 1.0)은 이 고정 스터핑만으로는 검출하지 못하는 오류 유형이 있다는 약점이 뒤늦게 발견됐다. 국제 표준화 과정에서 이를 보완해 CRC Sequence 앞에 스터프 비트 개수를 담는 4비트 Stuff Count 필드(3비트 그레이 코드 + 패리티 비트 1개)를 추가한 개정판이 나왔다 — 흔히 ISO CAN FD라 부른다. 두 버전은 CRC 계산 방식이 달라 서로 통신할 수 없으므로 한 버스에 섞어 쓰면 안 된다(단, 어느 쪽이든 일반 CAN 프레임만 주고받는 경우는 예외다)[4].
기존 CAN과의 공존
CAN FD 컨트롤러는 기존 CAN 프레임도 그대로 송수신할 수 있어, 두 형식이 같은 버스에 공존하도록 설계됐다. 다만 이는 일방향이다 — CAN FD 형식을 해석하지 못하는 기존 CAN 노드는 CAN FD 프레임이 버스에 실리는 동안 정상적으로 통신에 참여할 수 없으므로, 마이그레이션 기간에는 이런 노드를 버스에서 배제하거나 대기 상태로 묶어두어야 한다[1].