CAN Frame Structure

Overview

A CAN frame defines how information is transmitted on the CAN bus. Understanding the frame layout is essential for reading traffic, diagnosing issues, and reasoning about timing and security behavior.

This article explains the classical CAN data frame at a conceptual and practical level.

Prerequisites

• Binary and hexadecimal notation
• Basic networking terminology

Concept Breakdown

Frame Types

This article focuses on the CAN data frame. Other frame types (remote, error, overload) exist but follow different rules.

Core Fields

A classical CAN data frame consists of the following logical fields:

• Start of Frame
• Arbitration Field
• Control Field
• Data Field
• CRC Field
• Acknowledge Field
• End of Frame

Each field serves a specific technical purpose.

Step-by-Step Logic

1. Start of Frame (SOF) — A dominant bit marks the beginning of a frame and synchronizes all nodes.

2. Arbitration Field — Contains the identifier and RTR bit. This field determines message priority on the bus.

3. Control Field — Specifies data length and frame format.

4. Data Field — Carries 0–8 bytes of payload in classical CAN.

5. CRC Field — Used by receivers to verify frame integrity.

6. Acknowledge Field — Receivers signal successful reception.

7. End of Frame (EOF) — Marks the end of transmission and returns the bus to idle.

Common Mistakes / Misconceptions

• "The payload starts immediately after the ID" → ❌ Control bits are always present.

• "CRC guarantees security" → ❌ CRC detects errors, not malicious manipulation.

Practical Implications

• Frame size directly affects bus load and latency
• Identifier placement impacts arbitration behavior
• Payload limits influence protocol design choices
• Security tooling relies on correct field interpretation

References

• ISO 11898-1
• Bosch CAN Specification 2.0
• Vector CAN Technical Reference