CAN Identifiers: Standard vs. Extended

Hello! Welcome to the fifth lesson in our module on CAN bus fundamentals.

In our last session, we explored the crucial process of CAN bus arbitration, understanding how the message with the lowest numerical identifier wins bus access. This mechanism is central to ensuring that safety-critical data is prioritized in an automotive network.

Today, we will build directly on that knowledge to address a key aspect of the identifier itself. This lesson focuses on differentiating between Standard (11-bit) and Extended (29-bit) CAN identifiers. Understanding these two formats is essential for your work in both software development and system testing, as you will encounter both in modern vehicles. For instance, diagnostic messages often use Extended IDs, while many internal ECU-to-ECU messages use Standard IDs.

The Two Flavors of CAN Identifiers: Standard and Extended

At its core, the difference is simple: the length of the message identifier, which directly impacts the number of unique messages possible on a network.

• Standard CAN (CAN 2.0A): Uses an 11-bit identifier, allowing for $2^{11}$ or 2,048 unique message IDs.
• Extended CAN (CAN 2.0B): Uses a 29-bit identifier, allowing for $2^{29}$ or over 536 million unique message IDs.

Let's begin with a high-level overview of their characteristics and typical use cases.

Why Was the Extended Format Needed?

As you might guess, the 2,048 identifiers available in the standard format eventually became a limiting factor. As vehicle electronics grew more complex, and especially with the standardization needs of commercial vehicles (trucks, buses, agricultural machinery), a much larger address space was required.

The SAE J1939 protocol, which is the standard for commercial vehicles, was a major driver for the development of the 29-bit identifier, leading to the CAN 2.0B specification.

Anatomy of an Extended Frame

To support a 29-bit identifier without completely breaking compatibility, the CAN frame structure was cleverly modified. The 29-bit identifier is not just a single field; it's composed of the original 11-bit Base ID and a new 18-bit Extended ID.

Two special bits are key to making this work:

1. IDE (Identifier Extension) Bit: This bit signals whether the frame is standard or extended.
2. SRR (Substitute Remote Request) Bit: This bit exists only in the extended frame and plays a role in arbitration.

The following video provides an excellent visual walkthrough of how these pieces fit together.

To provide a static reference, the image below shows a clear side-by-side comparison of the two frame formats.

Coexistence and Arbitration on the Same Bus

One of the most elegant features of the CAN 2.0B specification is that Standard and Extended frames can coexist on the same physical bus. This is possible because of how the arbitration process interacts with the IDE and SRR bits.

Here is the critical rule:
A Standard frame will always have a higher priority than an Extended frame if their 11-bit Base IDs are identical.

Let's break down why this happens, building on what we learned about dominant ('0') and recessive ('1') bits.

1. Arbitration on the 11-bit Base ID: Both frame types start by arbitrating using their first 11 bits. If one has a lower Base ID, it wins, just as we saw in the previous lesson.
2. The Tie-Breaker: If the 11-bit Base IDs are identical, the conflict is resolved at the very next bit.
   • The Extended frame transmits the SRR bit, which is always recessive ('1').
   • The Standard frame transmits its RTR bit. If it's a data frame, the RTR bit is dominant ('0'). The Standard frame wins immediately.
   • If the Standard frame is a remote frame (RTR='1'), it ties with the Extended frame's SRR bit. The next bit decides.
3. The Final Decider (IDE Bit):
   • The Extended frame transmits a recessive ('1') IDE bit as part of its extended arbitration field.
   • The Standard frame transmits a dominant ('0') IDE bit as part of its control field.
   • The Standard frame's dominant IDE bit overwrites the Extended frame's recessive IDE bit. The Standard frame wins arbitration.

This clever design ensures that legacy 11-bit systems and higher-priority messages are never "beaten" by an extended message with the same base identifier.

Conclusion

In this lesson, we've dissected the two CAN identifier formats, moving from a high-level overview to the specific bits that enable their functionality and coexistence. As an automotive system professional, you'll frequently use tools to monitor CAN buses containing a mix of both frame types, and knowing how to distinguish them is a fundamental skill.

Key Takeaways:

• Standard CAN (11-bit ID) offers 2,048 unique identifiers and is common in passenger vehicles.
• Extended CAN (29-bit ID) offers over 536 million identifiers, driven by the needs of protocols like J1939 and modern diagnostics (UDS on CAN).
• The IDE (Identifier Extension) bit is the primary flag to differentiate the formats: 0 (dominant) for Standard, 1 (recessive) for Extended.
• The SRR (Substitute Remote Request) bit in the Extended frame is always recessive and helps ensure priority.
• Standard and Extended frames can coexist, and a Standard frame always wins arbitration against an Extended frame with an identical 11-bit Base ID.

In our next lesson, we will shift our focus from successful communication to what happens when things go wrong. We will classify CAN bus error types and describe the powerful error detection and management mechanisms built into the protocol.