Captured at (ISO local): 2026-05-18 05:17:24

I. Introduction: Why Industry Cannot Do Without CAN

In autonomous driving, rail transit, and industrial automation, CAN (Controller Area Network) is the undisputed cornerstone of communications. Unlike Ethernet or serial interfaces, CAN is inherently designed for real-time behavior and high reliability. Its unique non-destructive arbitration mechanism and strong immunity to electromagnetic interference allow critical control commands to be transmitted reliably even in harsh EMI environments.

II. Core Technology in Depth

1. Physical Layer: Differential Signaling and Logic Levels

CAN uses differential signaling to transmit data. The logical state is represented by the voltage difference between two wires (CAN_H, CAN_L):

• Dominant level (logical 0): CAN_H ≈ 3.5 V, CAN_L ≈ 1.5 V. The bus is “pulled down” in this state—even if a node wishes to transmit a recessive bit, the bus will still appear dominant while any node transmits dominant.

• Recessive level (logical 1): CAN_H ≈ CAN_L ≈ 2.5 V.

• Termination resistors: Both ends of the bus must have a 120 Ω terminator to match impedance and prevent reflections.

  

2. Data Link Layer: Non-destructive bitwise arbitration

This is CAN’s defining feature. CAN uses CSMA/CD + AMP (Carrier Sense Multiple Access / Collision Detection + Arbitration Priority Message):

• Principle: When multiple nodes transmit at the same time, they transmit while continually monitoring the bus. Because dominant bits (0) override recessive bits (1), nodes sending a numerically larger ID (lower priority) will detect a discrepancy between what they transmitted and what they read on the bus, and therefore stop transmitting immediately, exiting the contention.

• Outcome: Higher-priority frames pass through without arbitration delay. Lower-priority frames are automatically rescheduled. This does not produce Ethernet-like “collisions”.

  

You are absolutely right—it is indeed the structure of CAN 2.0A (standard frame) that was listed earlier.

In real projects and introductory articles, CAN 2.0A (Standard) versus CAN 2.0B (Extended) is usually discussed side by side. The core distinction is ID length plus the resulting control bits needed so both widths can coexist.

Below is a structured contrast you can paste into technical notes:

3. Frame structure: Standard frame (2.0A) vs. extended frame (2.0B)

CAN defines two dominant formats that can coexist on the same bus. The clearest distinction is capacity of the “identity tag (ID)”:

A. CAN 2.0A (standard frame)

Most common for smaller and mid-sized systems:

• Identifier (ID): 11-bit encoding. Supports up to 2¹¹ = 2,048 distinct message identifiers.
• Control bit IDE (Identifier Extension): In the control field it is dominant (0), declaring a standard frame.
• Characteristics: Compact format, somewhat lower framing overhead compared with extended IDs.

B. CAN 2.0B (extended frame)

For complex systems needing many logical addresses (heavy machinery, automotive J1939, etc.), extended frames widen the identifier:

• Identifier (ID): 29 bits composed of 11-bit base ID + 18-bit extension. Supports hundreds of millions of distinct IDs from a bitwise-combinatorics perspective.
• Control bit SRR (Substitute Remote Request): Replaces RTR positioning as found in pure standard frames—keeps the bit-timing layout aligned.
• Control bit IDE (Identifier Extension): Recessive (1) tells receivers “there are eighteen more identifier bits ahead—keep receiving.”
• Characteristics: Can pack richer semantics into IDs (priority, sources, destinations, etc.) according to OEM protocols.

(Illustration placeholder)

Technical comparison matrix

Compatibility mechanics

Hardware reading the serialized ID observes bit twelve (IDE). If IDE is dominant, receivers know exactly eleven identity bits preceded the DLC. If IDE is recessive, hardware knows another eighteen-bit extension trails before DLC. Mixed traffic therefore coexists cleanly—no ambiguity about where one frame ends conceptually relative to DLC.

How Python reflects this distinction

# Standard frame (CAN 2.0A)
msg_standard = can.Message(
    arbitration_id=0x123, 
    is_extended_id=False, # corresponds to IDE = 0
    data=[1, 2, 3]
)

# Extended frame (CAN 2.0B)
msg_extended = can.Message(
    arbitration_id=0x12345678, 
    is_extended_id=True,  # corresponds to IDE = 1
    data=[4, 5, 6]
)

CAN is often called “the non-freezing fieldbus.” Achieving zero lockups is not coincidence—it owes to exceptionally strict fault handling plus isolation. The protocol not only discovers errors—it differentiates fleeting noise from catastrophic hardware faults and removes persistently offending nodes automatically.

Detailed drill-down:

4. Error handling—the “self-recovery” playbook

CAN mandates five orthogonal error checks coordinated at the silicon level via TEC and REC counters (“transmit” and “receive” error budgets).

(1) Five detection mechanisms

1. Bit error
   • Principle: While transmitting bits, controllers read the bus concurrently. Transmitting recessive yet observing dominant—or the opposite—is a bit error unless a defined exception applies.
   • Exemptions: Losing arbitration (reading dominant while transmitting recessive) or receiving ACK dominance while recessive locally are deliberate and ignored.
2. Stuff error
   • Principle: To avoid long runs without edges (clock-recovery killers), transmitters inject a complementary bit whenever five identical bits would otherwise appear consecutively (bit stuffing).
   • Trigger: Witnessing six identical bits violates the rule—raise stuff error.
3. CRC error
   • Principle: Transmitter attaches a fifteen-bit residue; receivers recompute polynomial division.
   • Trigger: Mismatch ⇒ CRC fault.
4. Form error
   • Principle: Dedicated recessive separators (CRC delimiter, ACK delimiter, EOF, etc.).
   • Trigger: Unexpected dominant positions corrupt frame grammar.
5. ACK error
   • Principle: Transmitters recessive during ACK-slot expect at least one listener to dominate.
   • Trigger: Completely recessive slot means “nobody heard me.”

(2) Per-node bookkeeping: TEC versus REC

Each controller tracks two escalating counters guiding fault progression:

• TEC (Transmit Error Counter)
• REC (Receive Error Counter)

Penalty / reward heuristic:

• Any detected fault ⇒ jump (typically +8 for local contributors).
• Successful exchange ⇒ graceful decay (−1), ensuring chronic offenders escalate quickly yet healed nodes rehabilitate steadily.

(3) Three node states governed by counters

Depending on thresholds, controllers rotate among:

(Illustration placeholder; see ./3.png if bundled with original article.)

5. Advanced—recovering intentionally from Bus-Off?

• Vehicles typically rely on NM (Network Management) policies to resurrect modules after deterministic cool-down sequencing.
• Frequent recurring Bus Off indicates physical-layer investigation (reflections due to absent termination; damaged transceiver; harness shielding ruptures).

III. Evolution milestone: CAN FD (Flexible Data-Rate)

As sensor payloads grew, classical CAN (≤8 B per frame, ≈ 1 Mbit/s) became cramped. FD adds:

1. Up to sixty-four payload bytes
2. Dual bit-rates: arbitration-phase remains conservative; accelerates strictly inside BRS/data phases (≈ 5 Mbit/s and beyond silicon-dependent).

IV. Hands-on desktop simulation with production-grade toolchain

Linux exposes controllers as networked interfaces (SocketCAN), giving socket semantics identical-ish to TCP/IP abstractions:

1. Environment scaffolding (Ubuntu/Debian)

Without hardware leverage Kernel vcan virtual adapters:

# load virtual CAN module
sudo modprobe vcan

# bring up pseudo interface `vcan0`
sudo ip link add dev vcan0 type vcan
sudo ip link set up vcan0

# install candump / candump-compatible utilities bundle
sudo apt-get install can-utils

2. Python idiomatic notifier pattern

Leveraging python-can with non-blocking notifier callback:

import can
import threading
import time

def print_message(msg):
    """Callback printing arriving frames."""
    print(f"[{time.strftime('%H:%M:%S')}] ID: {msg.arbitration_id:03x} | "
          f"DLC: {msg.dlc} | Data: {msg.data.hex().upper()}")

class CanNode:
    def __init__(self, channel='vcan0'):
        # initialise SocketCAN
        self.bus = can.interface.Bus(channel=channel, bustype='socketcan')
        self.notifier = None

    def start_receive(self):
        # notifier pattern => thread-friendly receive path
        self.notifier = can.Notifier(self.bus, [print_message])
        print("Listening on vcan0...")

    def send_periodic_data(self):
        """simulate periodic actuator telegrams"""
        msg = can.Message(
            arbitration_id=0x101, 
            data=[0xAA, 0xBB, 0xCC, 0x00, 0x01, 0x02, 0x03, 0x04],
            is_extended_id=False
        )
        try:
            while True:
                self.bus.send(msg)
                print(f"Sent: {msg.arbitration_id:03x}")
                time.sleep(1) # emit at 1 Hz
        except KeyboardInterrupt:
            self.stop()

    def stop(self):
        if self.notifier:
            self.notifier.stop()
        self.bus.shutdown()

if __name__ == "__main__":
    node = CanNode('vcan0')
    node.start_receive()
    node.send_periodic_data()

3. Observing canonical traffic snapshots

Separate shell—candump is CAN’s analogue to Wireshark line-mode:

candump vcan0

Typical streamed row:

  vcan0  101   [8]  AA BB CC 00 01 02 03 04

Synthetic stress:

cangen vcan0 -g 10 -I 7FF -L 8  # random frame burst every ten milliseconds

V. Takeaways plus practical guidance

1. ID choreography: Ship DBC artefacts early—safety-critical telegrams (brakes, steer-by-wire proxies) merit numerically dominating IDs (smaller eleven-bit identifiers ⇒ higher dominance).
2. Bus-loading discipline: Aim ≤50 % average utilization; instantaneous peaks seldom exceed ~70 % if latency budgets matter—measure with analyzers routinely.
3. Application strata: Bare CAN transports bits; semantics ride CANopen, J1939, UDS, etc.—never reinvent wheels without ISO alignment.

Beyond copper and bits, mastering CAN blends physics, probability, and choreography of deterministic collaboration. Hopefully this teardown elevates abstraction from sporadic tooling usage toward confident architecture—opening automotive / industrial vistas alike.