For more than 25 years, I have been working with CAN (Controller Area Network) technology. During that time, I have lost count of how many times industry experts, analysts, and technology journalists predicted its imminent demise.

First, it was Ethernet.

Then came FlexRay.

Later, it was Automotive Ethernet.

More recently, CAN FD and now CAN XL have been presented as the inevitable successors to Classical CAN.

And yet, here we are in 2026.

Classical CAN remains one of the most widely used communication technologies in industrial automation, commercial vehicles, agriculture, marine electronics, medical equipment, robotics, and countless embedded systems.

The obvious question is:

Why does CAN Bus refuse to die?

The answer is surprisingly simple.

Because it still solves real-world problems exceptionally well.

The Graveyard of CAN Killers

Throughout the past two decades, several technologies have been promoted as replacements for CAN.

FlexRay was supposed to provide deterministic communication for automotive systems.

Automotive Ethernet promised virtually unlimited bandwidth.

CAN FD offered larger payloads and higher data rates.

CAN XL now promises Ethernet-like capabilities while maintaining CAN compatibility.

On paper, every one of these technologies appears superior.

Yet none of them has eliminated Classical CAN.

Instead, they have mostly joined CAN rather than replaced it.

The reason is that engineering decisions are rarely driven by specifications alone.

They are driven by cost, reliability, availability, and practicality.

CAN continues to win in all four categories.

Reliability Beats Bandwidth

One of the biggest misconceptions in engineering is that more bandwidth automatically means a better network.

In reality, most control systems simply do not need massive amounts of bandwidth.

Consider a diesel engine ECU transmitting:

• Engine speed
• Coolant temperature
• Oil pressure
• Fuel rate
• Torque information

These values change relatively slowly compared to modern network capabilities.

A message transmitted every 100 milliseconds is often more than sufficient.

Even in SAE J1939 applications, many networks operate comfortably at 250 kbit/s.

For such systems, replacing CAN with a much faster technology provides little practical benefit.

What matters more is reliability.

CAN has proven itself in environments that are hostile to electronics:

• Heavy trucks
• Construction equipment
• Agricultural machinery
• Marine systems
• Mining vehicles
• Factory automation

Many of these systems operate for decades.

Engineers trust CAN because it has earned that trust.

The Economics of "Good Enough"

Engineers love elegant technical solutions.

Management loves profitable solutions.

The two are not always the same.

Suppose you are designing a sensor network that transmits:

• Temperature
• Pressure
• Flow rate
• Position data

A Classical CAN controller costs very little.

The software stack is mature.

The diagnostic tools already exist.

The engineering team understands the technology.

Now compare that to implementing a completely new network technology.

The benefits may be marginal while development costs increase significantly.

This is why many manufacturers continue using CAN long after newer technologies become available.

The existing solution is simply good enough.

And in engineering, "good enough" often wins.

The Massive Installed Base

One of CAN's greatest strengths is something no competitor can easily replicate.

There are millions upon millions of CAN nodes already deployed worldwide.

Consider:

• Heavy-duty trucks
• Agricultural equipment
• Construction machinery
• Marine electronics
• Industrial controllers
• Medical devices
• Railway systems

Many of these products remain in service for 10, 20, or even 30 years.

Manufacturers cannot simply abandon compatibility with existing equipment.

As a result, every new design decision must consider interoperability with existing CAN networks.

The installed base continuously reinforces itself.

The larger it becomes, the harder it becomes to replace.

CAN FD: Slower Adoption Than Expected

When CAN FD was introduced, many people assumed it would quickly replace Classical CAN.

That did not happen.

Especially in North America.

CAN FD certainly offers advantages:

• Payloads up to 64 bytes
• Higher data rates during the data phase
• Improved efficiency for larger data transfers

From a technical standpoint, CAN FD is an excellent enhancement.

However, many applications simply did not need it.

If your system is already performing perfectly with 8-byte payloads and Classical CAN speeds, where is the incentive to redesign hardware, update firmware, and validate an entirely new platform?

Many manufacturers concluded that the return on investment was insufficient.

As a result, Classical CAN continues to dominate large portions of the commercial vehicle and industrial markets.

Today, CAN FD is growing, but nowhere near the rate many analysts originally predicted.

CAN XL: A Solution Looking for a Problem?

This brings us to CAN XL.

Technically, CAN XL is impressive.

It supports payloads up to 2,048 bytes and significantly higher throughput than either Classical CAN or CAN FD.

But the question remains:

Who actually needs it?

Many industrial and commercial vehicle applications still operate comfortably using Classical CAN.

Others that truly require higher bandwidth are increasingly moving toward Ethernet-based solutions.

This places CAN XL in an uncomfortable middle ground.

It offers more bandwidth than traditional CAN applications require while competing against Ethernet in applications that genuinely need high data rates.

From my perspective, CAN XL faces an uphill battle.

The slow adoption of CAN FD already demonstrated how reluctant many industries are to move away from Classical CAN.

If CAN FD struggled to gain traction in some markets, CAN XL may face an even steeper challenge.

Simplicity Matters

One of the most overlooked advantages of Classical CAN is its simplicity.

A CAN network can often be diagnosed with:

• A CAN analyzer
• A laptop
• Basic protocol knowledge

Engineers can quickly observe traffic, identify faults, and understand system behavior.

The technology remains approachable.

As network complexity increases, troubleshooting often becomes more difficult.

Many engineers appreciate that CAN remains understandable without requiring an entire IT department.

The Human Factor

There is another reason CAN refuses to die.

Engineers know it.

Universities teach it.

Technicians understand it.

Tool vendors support it.

Countless software libraries exist.

A technology ecosystem that took decades to build does not disappear overnight.

Every year, thousands of new engineers enter the workforce already familiar with CAN.

That knowledge base creates tremendous momentum.

Replacing technology is easy.

Replacing an entire ecosystem is not.

The Future of CAN

Will Classical CAN eventually disappear?

Of course.

Every technology has a lifecycle.

But predictions of its imminent death have been greatly exaggerated for more than two decades.

The reality is that CAN remains exactly what it has always been:

• Reliable
• Inexpensive
• Well understood
• Easy to implement
• Easy to troubleshoot
• More than adequate for most control applications

Those characteristics matter far more than headline-grabbing bandwidth numbers.

CAN FD will continue to grow.

CAN XL may find specialized applications.

Ethernet will continue expanding into areas that genuinely require higher throughput.

But none of those developments automatically eliminate Classical CAN.

In fact, the continued dominance of Classical CAN may be the strongest evidence yet that the technology was remarkably well designed from the beginning.

After more than 25 years of working with CAN networks, I have learned one important lesson:

Never underestimate a technology that solves real-world problems better than its replacements.

CAN Bus refuses to die because, for millions of applications around the world, it is still the right tool for the job.

A Comprehensible Guide to Controller Area Network