CAN Protocol Interview Questions

Controller Area Network (CAN) is a robust serial communication protocol designed by Bosch for automotive use. It provides: multi-master access (any node can transmit), message-based communication (not address-based), priority-based arbitration (lower ID = higher priority), error detection with CRC and acknowledgment, and speeds up to 1 Mbit/s (CAN 2.0) or 8 Mbit/s (CAN FD). It's the backbone of nearly every vehicle, connecting ECUs for powertrain, body, chassis, and diagnostic communication.

Standard CAN (CAN 2.0A): SOF (1 bit) → 11-bit Identifier → RTR → IDE (0) → r0 → DLC (4 bits) → Data (0-8 bytes) → CRC (15 bits + delimiter) → ACK (slot + delimiter) → EOF (7 recessive). Extended CAN (CAN 2.0B): SOF → 11-bit Base ID → SRR → IDE (1) → 18-bit Extension ID → RTR → r1 → r0 → DLC → Data → CRC → ACK → EOF. Total 29-bit identifier. Both share the same physical layer.

CAN uses CSMA/CR (Carrier Sense Multiple Access with Collision Resolution). All nodes monitor the bus and transmit when idle. During the arbitration field, each transmitting node sends its ID bit-by-bit while monitoring the bus. A dominant bit (0) overwrites a recessive bit (1). If a node sends recessive but reads dominant, it loses arbitration and stops transmitting. The node with the lowest ID wins. This is non-destructive - no messages are lost or corrupted.

Dominant (logic 0): CAN_H is driven high (~3.5V), CAN_L is driven low (~1.5V), differential voltage ~2V. Recessive (logic 1): both lines at ~2.5V, differential voltage ~0V. Dominant overwrites recessive - like a wired-AND. This physical layer property enables arbitration. The bus is recessive when no node is driving it. Termination resistors (120Ω at each end) maintain proper recessive voltage levels.

CAN bus requires 120Ω termination resistors at each end of the bus to prevent signal reflections. Without termination, signals bounce back from the open ends, causing ringing and bit errors. The two 120Ω resistors in parallel give 60Ω total DC resistance - this is used for quick bus health checks with a multimeter. Split termination (2×60Ω with capacitor) provides additional EMC filtering.

CAN has 5 error detection mechanisms: Bit Error (node reads different bit than sent), Stuff Error (more than 5 consecutive same-polarity bits without stuffing), CRC Error (received CRC doesn't match calculated), Form Error (fixed-format field has wrong value), and ACK Error (no node acknowledged the frame). When any error is detected, the detecting node sends an Error Frame (6 dominant bits - deliberately breaks bit stuffing to flag the error to all nodes).

Each node has two counters: TEC (Transmit Error Counter) and REC (Receive Error Counter). Error-Active (TEC<128, REC<128): normal operation, can send active error frames. Error-Passive (TEC≥128 or REC≥128): can still communicate but sends passive error frames and must wait extra before retransmitting. Bus-Off (TEC≥256): node disconnects from bus - requires recovery sequence (128×11 recessive bits). Counters increment on errors, decrement on successful communication.

After 5 consecutive bits of the same polarity, the transmitter inserts a stuff bit of opposite polarity. This ensures sufficient edge transitions for receiver clock synchronization (CAN has no separate clock line). Bit stuffing applies to: SOF, Arbitration Field, Control Field, Data Field, and CRC Field. It does NOT apply to: CRC Delimiter, ACK Field, and EOF (which are fixed format). The receiver removes stuff bits transparently.

CAN 2.0: Maximum 1 Mbit/s at up to ~40m cable length. At 500 kbit/s (most common automotive rate): up to ~100m. At 125 kbit/s: up to ~500m. The limitation is signal propagation time - all nodes must see the same bit value during the bit time for arbitration to work. CAN FD: Arbitration phase at up to 1 Mbit/s (same as CAN), data phase at up to 8 Mbit/s (shorter cable length required for data phase, typically <10m).

CAN FD (Flexible Data-rate), defined in ISO 11898-1:2015, offers: data payload up to 64 bytes (vs 8 bytes in CAN 2.0), higher data-phase bitrate (up to 8 Mbit/s vs 1 Mbit/s), improved CRC (17-bit for ≤16 bytes, 21-bit for >16 bytes), and stuff bit counter for better error detection. Arbitration still happens at the nominal bitrate for backward compatibility. Two new bits: FDF (FD Format) and BRS (Bit Rate Switch) indicate CAN FD frames.

In CAN FD, the BRS (Bit Rate Switch) bit enables switching to a higher bitrate for the data phase. The frame starts at the nominal rate (e.g., 500 kbit/s) for SOF, Arbitration, and Control fields. After BRS, the bitrate switches to the data rate (e.g., 2 or 5 Mbit/s) for the Data Field and CRC. After CRC delimiter, it switches back to nominal rate for ACK and EOF. This provides backward compatibility during arbitration while boosting data throughput.

CAN 2.0: DLC 0-8 maps directly to 0-8 data bytes. CAN FD: DLC 0-8 maps to 0-8 bytes (same), DLC 9→12 bytes, DLC 10→16 bytes, DLC 11→20 bytes, DLC 12→24 bytes, DLC 13→32 bytes, DLC 14→48 bytes, DLC 15→64 bytes. These discrete values optimize payload efficiency. If your data is 10 bytes, you must use DLC 10 (16 bytes) and pad the remaining 6 bytes.

CAN uses a two-wire differential bus: CAN_H and CAN_L. High-speed CAN (ISO 11898-2): linear bus topology, 120Ω termination at each end, max 1 Mbit/s, differential signaling (~2V dominant, ~0V recessive). Low-speed fault-tolerant CAN (ISO 11898-3): up to 125 kbit/s, can operate with one wire broken, used for body electronics. CAN transceiver converts between ECU logic levels (TTL) and bus differential levels.

The CAN transceiver converts between the CAN controller's digital logic levels (TX/RX) and the differential bus signals (CAN_H/CAN_L). It provides: electrical isolation, ESD protection, bus fault tolerance (short to ground/battery), slope control for EMC, low-power modes (standby/sleep with wake-up capability), and in modern transceivers: partial networking (selective wake-up) and CAN FD support. Common transceivers: TJA1043, TJA1463 (NXP), TCAN1044 (TI).

RTR is a frame where a node requests data from another node without sending data itself - the RTR bit is recessive (1). When a node receives an RTR with an ID matching its data message, it transmits the data frame. However, RTR is rarely used in practice because: CAN FD doesn't support RTR, AUTOSAR COM uses periodic/event-driven transmission instead, and RTR adds complexity. Most modern automotive CAN networks don't use RTR.

An Overload Frame is sent by a node that needs extra time before the next frame can start. It consists of 6 dominant bits (like an error frame) followed by 8 recessive bits (delimiter). Overload frames can only occur during interframe space. Maximum 2 consecutive overload frames. In practice, overload frames are very rare in automotive applications because modern CAN controllers have sufficient buffering and processing speed.

CAN controllers provide acceptance filtering to select which messages the MCU processes. Full CAN: each hardware mailbox has an exact-match filter for one ID. Basic CAN: configurable acceptance masks - a mask register defines which ID bits must match and which are don't-care. Example: ID filter 0x100 with mask 0x7F0 accepts IDs 0x100-0x10F. Hardware filtering reduces CPU load by only interrupting for relevant messages.

A .dbc file describes the CAN communication matrix: message definitions (ID, name, DLC, cycle time, sending node), signal definitions (name, start bit, length, byte order, factor, offset, unit, min/max, receiving nodes), value tables, and node definitions. Created in tools like Vector CANdb++ or Kvaser Database Editor. AUTOSAR uses ARXML equivalently, but .dbc remains the de facto exchange format between OEMs and suppliers.

Bus load = (total bits per second on bus) / (bus bitrate) × 100%. Each message contributes: frame bits (SOF + arbitration + control + data + CRC + ACK + EOF + IFS) plus stuff bits (~20% overhead for worst case). Formula per message: bits ≈ (47 + 8×DLC) × 1.2 (stuff bits). Total load = sum of all messages × their cycle rate. Keep bus load below 50% for reliable operation - above 70% causes increased latency and potential message loss.

Main diagnostic protocols over CAN: UDS (ISO 14229) - modern standard for all diagnostic services. KWP2000 (ISO 14230) - predecessor to UDS, still in legacy ECUs. OBD-II (ISO 15031 / SAE J1979) - emission-related diagnostics, mandated by law. J1939 DM messages - commercial vehicle diagnostics. All use CAN transport protocols: ISO-TP (ISO 15765-2) for UDS/KWP, J1939-TP for J1939. UDS is by far the most common in modern vehicles.

ISO-TP is the transport protocol for sending messages larger than 8 bytes over CAN. Frame types: Single Frame (SF - data fits in one frame, ≤7 bytes), First Frame (FF - starts a multi-frame transfer, contains total length), Consecutive Frame (CF - continues the data, sequence numbered 0-F), Flow Control (FC - receiver tells sender to continue/wait/abort with block size and STmin timing). ISO-TP handles segmentation, reassembly, and flow control.

Flow Control has three parameters: Flow Status (0=ContinueToSend, 1=Wait, 2=Overflow/Abort), Block Size (BS - number of CFs to send before waiting for next FC; 0=no limit), and STmin (minimum separation time between CFs; 0-127ms or 100-900μs). These parameters let the receiver control the data rate to prevent buffer overflow. Typical automotive settings: BS=0 (no flow control blocking), STmin=1-10ms.

11-bit (Standard/CAN 2.0A): 2048 possible IDs (0x000-0x7FF), commonly used in passenger vehicles - sufficient for most networks. 29-bit (Extended/CAN 2.0B): ~537 million IDs, used in J1939 (trucks/commercial), SAE J2284, and networks requiring large address spaces. Extended frames have lower priority than standard frames with the same base ID (due to IDE bit). Both can coexist on the same bus. Most passenger car CAN uses 11-bit.

Common techniques: 1) Measure bus termination resistance (should be ~60Ω between CAN_H and CAN_L). 2) Check signal quality with oscilloscope (voltage levels, edge rates, symmetry). 3) Monitor bus with CANoe/CANalyzer for error frames, bus-off events, missing messages. 4) Check bus load percentage. 5) Verify wiring (no open/short, proper shielding). Common problems: missing termination, ground offset between ECUs, stub lines too long, defective transceiver.

When a node's TEC reaches 256, it enters Bus-Off state and disconnects from the bus. Recovery requires detecting 128 occurrences of 11 consecutive recessive bits (= 128 × bus idle). This takes at minimum 128 × 11 × bit time (≈2.8ms at 500 kbit/s). After recovery, the node restarts with TEC=0 and REC=0. In AUTOSAR, CanSM manages bus-off recovery with configurable strategies: immediate recovery, delayed recovery, or escalation to DEM.

Signals have physical and raw representations. Physical = raw × factor + offset. Example: Engine RPM - raw value 0-16383 (14 bits), factor=0.25, offset=0, physical range 0-4095.75 RPM. Min/max define valid physical range. Factor and offset enable packing large physical ranges into small bit fields. Byte order (Intel/Motorola) determines bit layout. These properties are defined in the .dbc file and used by COM for signal conversion.

NM keeps ECUs awake on a network. When an ECU needs communication, it sends periodic NM messages (dedicated CAN ID). All ECUs monitor NM messages - if received, stay awake. When no NM messages for NM Timeout period, transition to sleep. AUTOSAR NM is decentralized - no coordinator needed. Key parameters: NM cycle time (~100ms), NM timeout (~1-4s), Wait Bus Sleep time (~150ms). NM enables synchronized bus sleep to reduce power consumption.

ECUs in sleep mode can be woken by: 1) Bus wake-up - any dominant signal on the sleeping bus triggers the transceiver to wake the MCU. 2) Local wake-up - MCU event (timer, pin change). 3) Selective wake-up (partial networking) - CAN FD transceiver filters wake-up frames and only wakes for specific message IDs. After wake-up, the ECU initializes and sends an NM message to wake other ECUs. The transceiver must be in standby (not sleep) to detect bus activity.

IFS is the minimum gap between consecutive CAN frames, consisting of: Intermission (3 recessive bits) followed by Bus Idle (any number of recessive bits until next SOF). Error-Passive nodes must wait an additional 8 recessive bits (Suspend Transmission) after intermission before transmitting again - this gives Error-Active nodes priority after an error. The IFS prevents frames from running together.

Priority is determined by the CAN ID during arbitration - lower ID = higher priority. This is inherent in the protocol design: during bit-by-bit arbitration, a dominant (0) bit wins over recessive (1). So ID 0x001 has higher priority than 0x7FF. Network designers assign IDs based on message criticality: safety-critical messages (braking, steering) get lowest IDs. Gateway routing may need to preserve priority across buses.

Listen-only (bus monitoring) mode allows a node to receive all frames without participating in: ACK (doesn't send dominant ACK bit), error detection (doesn't send error frames), or arbitration (doesn't transmit). Useful for: diagnostic tools monitoring traffic without affecting the bus, commissioning new nodes, and analyzing bus problems. Most CAN controllers support this mode. In AUTOSAR, this corresponds to SILENT communication mode in CanSM.

A signal group is a set of related signals within a CAN message that must be updated atomically. In AUTOSAR COM, signal groups are read/written as a complete set using shadow buffers - ensuring consistency even if an interrupt updates the message between individual signal reads. Example: wheel speed signals (FL, FR, RL, RR) in one message should be read together to get a consistent snapshot. COM provides Rte_Read_SG and Rte_Write_SG APIs.

Cycle time is the periodic interval at which a message is transmitted (e.g., 10ms for engine RPM, 100ms for door status). Defined in the communication matrix (.dbc/ARXML). Types: Cyclic (sent at fixed interval), Event (sent on data change), Cyclic-Event (cyclic normally, immediate on change), and Cyclic-If-Active (cyclic only when function is active). Cycle time affects bus load - too many fast messages can overload the bus.

A gateway ECU receives messages on one CAN bus and retransmits them on another. Types: 1) PDU routing - forward complete message with same/different ID. 2) Signal routing - extract signals from source message, repack into destination message (possibly different layout). 3) Protocol conversion - CAN to CAN FD, CAN to Ethernet. AUTOSAR PduR handles PDU-level routing; COM handles signal-level routing. Latency and determinism are key gateway design concerns.

CAN FD nodes can detect Classical CAN frames and CAN FD frames. A Classical CAN controller receiving a CAN FD frame will see a form error (due to the FDF bit) and send an error frame - this causes bus errors. To prevent this, all nodes on a CAN FD bus should be CAN FD capable, or use protocol exception handling: CAN FD controllers can be configured to tolerate FDF without sending error frames, enabling mixed networks during migration.

Normal: full transmit/receive capability. Standby: low-power mode, can detect bus activity for wake-up, no transmit. Sleep: lowest power, no bus monitoring (unless selective wake-up). Listen-Only: receive only, no ACK or transmit. Common modes in AUTOSAR (CanTrcv): NORMAL, STANDBY, SLEEP. Mode transitions are controlled by CanSM through CanTrcv driver. Power consumption: Normal ~10mA, Standby ~10-50μA, Sleep ~1-5μA.

At high data-phase bitrates, the propagation delay through the CAN transceiver becomes significant compared to the bit time. TDC compensates for this delay during the data phase. The CAN controller measures the round-trip delay (TX→transceiver→bus→transceiver→RX) and uses this to correctly sample its own transmitted bits. Without TDC, bit errors occur at high data rates. TDC offset and filter window are configurable parameters.

Standard bitrates: 500 kbit/s - most common for powertrain/chassis CAN. 250 kbit/s - body/comfort CAN. 125 kbit/s - low-speed applications. 1 Mbit/s - high-speed applications, some OEM backbone CAN. CAN FD: 500 kbit/s arbitration + 2 Mbit/s data phase (common), 500 kbit/s + 5 Mbit/s (high performance). Bitrate must be identical across all nodes on the same bus. OEMs typically standardize on 2-3 bitrates across the vehicle.

Through non-destructive bitwise arbitration. When multiple nodes start transmitting simultaneously (all detect bus idle and start SOF), they compete during the ID field. Each node sends its ID while reading the bus. If a node sends recessive (1) but reads dominant (0), another node with a lower ID is also transmitting - it loses arbitration and stops. The winner continues uninterrupted. The losing node retries in the next bus idle period. No frames are lost.

The ACK field has 2 bits: ACK slot and ACK delimiter. The transmitter sends both as recessive. All receivers that successfully received the frame (CRC valid) drive the ACK slot dominant. The transmitter reads the ACK slot - if it's dominant, at least one node received the frame correctly. If recessive (no ACK), the transmitter flags an ACK error and retransmits. ACK only confirms reception by at least one node, not all nodes.

Key practices: 1) Keep bus load below 50% nominal, 70% peak. 2) Assign message IDs by priority (safety-critical = lowest). 3) Use proper 120Ω termination at both ends. 4) Keep total stub length short (<0.3m per node at 500kbit/s). 5) Use twisted pair shielded cables. 6) Separate high-speed and low-speed CAN buses. 7) Plan for gateway overhead. 8) Reserve IDs for future expansion. 9) Implement bus-off recovery strategy. 10) Define wake-up/sleep behavior early.

CAN XL is the newest CAN standard (CiA 610): up to 2048 bytes payload (vs 64 bytes CAN FD), data rate up to 20 Mbit/s, new frame format with acceptance field for protocol multiplexing (CAN, TCP/IP), and support for tunneling Ethernet frames over CAN. CAN XL maintains CAN's arbitration mechanism for backward compatibility. It positions CAN between traditional CAN FD and Automotive Ethernet, potentially reducing the need for Ethernet on some networks.

CAN bit time = Sync Segment (1 TQ) + Propagation Segment + Phase Segment 1 + Phase Segment 2. Sample point = (Sync + Prop + Phase1) / total bit time × 100%. Recommended: 75-87.5% for CAN, 75-80% for CAN FD data phase. Example: at 500 kbit/s with 16 TQ/bit, sample at TQ 13 = 81.25%. All nodes must have compatible sample points. CAN FD data phase requires tighter tolerance due to higher bitrate. Tools like Vector Timing Calculator help.

Gateway delay = time from receiving a message on one bus to transmitting it on another. Sources: receive interrupt latency + software processing + transmit queue waiting + arbitration time. Typical: 1-5ms for signal routing, <1ms for PDU routing. Minimize by: using hardware-accelerated routing (some MCUs have CAN-to-CAN gateway peripherals), PDU routing instead of signal routing, high-priority TX mailboxes, and dedicated gateway task with high OS priority.

Error confinement prevents a faulty node from permanently disrupting the bus. The TEC/REC mechanism automatically isolates chronically faulty nodes (Bus-Off). Additional fault tolerance: low-speed CAN (ISO 11898-3) can operate with one wire shorted/open. CAN transceivers handle bus faults (CAN_H short to battery, CAN_L short to ground). For safety-critical applications, redundant CAN buses or CAN FD with dual-channel transceivers provide additional robustness.

CAN carries ADAS-related signals: radar/camera object data, vehicle dynamics (speed, yaw rate, steering angle), driver inputs (brake pedal, turn signals), actuator commands (brake intervention, steering torque), and system status. However, ADAS increasingly uses Automotive Ethernet for high-bandwidth sensor data (camera images, point clouds). CAN remains for lower-bandwidth control signals and legacy sensor integration. Domain controllers often bridge CAN and Ethernet.

OBD-II uses CAN as the primary physical layer (ISO 15765-4) with standardized IDs: 0x7DF (functional request to all ECUs), 0x7E0-0x7E7 (physical requests to specific ECUs), 0x7E8-0x7EF (responses). OBD-II services access emission-related data: Service $01 (current data), $02 (freeze frame), $03 (confirmed DTCs), $04 (clear DTCs), $06 (test results), $09 (vehicle info). The DLC-9 connector pin 6 (CAN_H) and pin 14 (CAN_L) are standardized.

Common causes: 1) Wiring faults - open circuit, short to ground/battery, damaged shielding. 2) Termination issues - missing or incorrect value resistors. 3) Ground offset - different ground potentials between ECUs. 4) EMC interference - from ignition, motor drivers, or external sources. 5) Defective transceivers - stuck dominant fault. 6) Software bugs - incorrect timing, excessive TX causing bus overload. 7) Connector issues - corrosion, bent pins, water ingress.

TTCAN (ISO 11898-4) adds deterministic time-triggered scheduling to CAN. A reference message establishes a synchronized time base. The communication cycle is divided into time windows assigned to specific messages. Nodes transmit only in their assigned windows, eliminating arbitration delays for time-critical messages. Free windows allow event-triggered communication. TTCAN is less common than FlexRay for deterministic communication. Most implementations use standard CAN with careful scheduling instead.

J1939 uses CAN 2.0B (29-bit IDs) with 250 kbit/s. The 29-bit ID encodes: Priority (3 bits), PGN (Parameter Group Number - 18 bits combining Data Page, PDU Format, PDU Specific), and Source Address (8 bits). J1939 defines standard PGNs for engine, transmission, brakes, etc. Transport protocol: BAM (broadcast) and CMDT (connection-mode) for messages >8 bytes. Address claiming (J1939-81) assigns dynamic addresses. Dominant in trucks, buses, and off-highway vehicles.

Strict inverse relationship: lower CAN ID = higher message priority. This is enforced by the arbitration mechanism - dominant (0) bits win over recessive (1) bits. ID 0x000 has the absolute highest priority (all dominant), ID 0x7FF (standard) the lowest. Network designers must carefully assign IDs: airbag control gets very low IDs (~0x050-0x080), while infotainment gets high IDs (~0x500-0x7FF). Priority inversion doesn't occur in CAN.

During CAN FD standardization, an early implementation (Bosch CAN FD 1.0, sometimes called 'non-ISO') differs from the final ISO 11898-1:2015 standard in CRC calculation. ISO CAN FD includes a stuff bit counter in the CRC calculation for better error detection. Non-ISO does not. The two are incompatible - a non-ISO node and ISO node cannot communicate. Modern CAN FD controllers support both; always use ISO CAN FD for new designs.

Active Error Frame: sent by Error-Active nodes, consists of 6 dominant bits (active error flag) followed by error delimiter (8 recessive bits). The 6 dominant bits violate bit stuffing rules, ensuring all nodes detect the error. Passive Error Frame: sent by Error-Passive nodes, consists of 6 recessive bits (passive error flag) + delimiter. Passive error frames don't disrupt other transmissions - they're essentially invisible unless the bus is idle.

Steps: 1) List all signals needed between ECUs with their properties (type, range, resolution, cycle time). 2) Group signals into messages based on sender, timing requirements, and logical grouping. 3) Assign message IDs based on priority. 4) Define signal positions (start bit, length, byte order, factor, offset). 5) Calculate bus load - ensure <50%. 6) Define TX/RX relationships for each ECU. 7) Document in .dbc or ARXML. Tools: Vector CANdb++, PREEvision.

The CAN specification itself doesn't limit the number of nodes. Practical limits come from: electrical loading (each transceiver adds capacitance - typically 30-50 nodes before signal integrity degrades), bus load (more nodes = more messages = higher load), and physical cable length. In automotive, a single CAN bus typically has 5-20 ECUs. Modern vehicles have 3-8 CAN buses with a gateway ECU connecting them, totaling 40-100+ CAN-connected ECUs.

The bus is idle when no node is transmitting - both CAN_H and CAN_L are at approximately 2.5V (recessive state, differential voltage ≈ 0V). Any node can start transmission by driving a dominant SOF bit during idle. The bus must be idle for at least 3 bit times (IFS intermission) after a frame before a new frame can start. Continuous idle indicates either an empty bus or all nodes in sleep/off state.

Within one ECU with multiple messages to send, the CAN controller manages an internal transmit queue. Messages are typically sent in order of their CAN ID priority (lowest ID first), but this depends on the controller implementation. Some controllers have multiple TX mailboxes with configurable priority (mailbox number or CAN ID). AUTOSAR CanIf provides software TX buffering and priority management above the hardware level for flexible transmit scheduling.

Time Quantum is the smallest time unit for CAN bit timing configuration. One bit time consists of multiple TQs (typically 8-25). TQ = 1 / (CAN clock frequency × prescaler). Example: 80 MHz clock, prescaler=10 → TQ = 1/(80M×10) = 12.5ns. With 16 TQ per bit: bit time = 200ns → 5 Mbit/s. The bit segments (Sync, Propagation, Phase1, Phase2) are configured in TQ units. SJW (Synchronization Jump Width) defines the max clock correction per bit, also in TQ.

CAN FD improvements: 1) Longer CRC - 17-bit for ≤16 bytes, 21-bit for >16 bytes (vs 15-bit in CAN 2.0). 2) Stuff Bit Counter - counts stuff bits and includes in CRC calculation, detecting stuff errors that classic CRC might miss. 3) Better Hamming Distance - CAN FD achieves HD=6 for up to 64 bytes (meaning any 5-bit error is detected), compared to HD=6 only for 8 bytes in CAN 2.0. This makes CAN FD more reliable for larger payloads.

SAE J2284 defines CAN application layers for passenger vehicles. J2284-1: High-speed CAN at 500 kbit/s (powertrain/chassis). J2284-2: Low-speed CAN at 250 kbit/s (body). J2284-3: CAN FD at 500 kbit/s nominal / 2 Mbit/s data (higher bandwidth applications). These standards define: voltage levels, timing parameters, fault tolerance requirements, and bus access rules specific to automotive applications. They complement ISO 11898 with vehicle-specific requirements.

Strategies: 1) Spread message cycle times to avoid phase alignment (add offsets). 2) Use event-triggered instead of cyclic transmission where possible. 3) Move less critical messages to slower cycle times. 4) Split high-load buses into separate networks. 5) Migrate to CAN FD for larger payloads in fewer frames. 6) Implement TX inhibit during overload conditions. 7) Use minimum DLC (don't pad unnecessarily). Analysis tools like CANoe bus statistics view help identify load peaks.

CAN SIC is a feature in newer CAN transceivers that improves signal quality for CAN FD high-speed data phases. It provides active ringing suppression on the bus by clamping oscillations after dominant-to-recessive transitions. Without SIC, reflections at higher bitrates can cause bit errors. SIC transceivers are recommended for CAN FD data rates above 2 Mbit/s. They're backward compatible with existing CAN/CAN FD installations.

Message (alive) counter: a 4-bit rolling counter in the message data that increments with each transmission. The receiver verifies the counter increments correctly to detect message loss or repetition. Message timeout: the receiver monitors the expected cycle time and triggers a timeout if no message arrives within a configured window (e.g., 3× cycle time). Both mechanisms are essential for safety-relevant signals (ISO 26262) and are part of E2E protection.

Partial networking transceivers (ISO 11898-2:2016) can selectively wake the MCU based on specific wake-up frames (WUF). The transceiver has configurable data filters - it only wakes the ECU if a CAN frame matching the filter (specific ID and data pattern) is received. Frames not matching the WUF are ignored, keeping the ECU in sleep. This enables individual ECU wake-up, significantly reducing vehicle idle power consumption. Configuration is done via SPI during initialization.

Compliance testing includes: 1) Physical layer testing - oscilloscope verification of voltage levels, edge rates, sample point (Vector VH1160 or Kvaser Leaf Pro). 2) Protocol conformance - verifying frame format, error handling, arbitration behavior. 3) Communication matrix compliance - all messages sent/received per specification (cycle time, signal values). 4) Timing verification - message latency, jitter. 5) EMC testing - immunity and emission. CANoe test environments automate protocol-level verification.