Kdtyjb

Why can't CAN baud rate increase beyond 1Mbps

It's because the CAN 2.0B standard did not specify any higher in order to reduce hardware costs and still meet the various requirements of the standard (like distance and noise immunity). It's not a technical barrier.

The standard was written that way probably since they deemed the extra speed unnecessary for the intended application, and specifying a higher speed needlessly would increase the cost of all the hardware supporting the standard when the capability would be underutilized.

If the standard is written that way, few IC manufacturers will bother trying to exceed it since there's no point. It's not really a technical barrier.

From Controller Area Network Physical Layer Requirements

CAN is an open collector technology – the protocol could not work otherwise. This means that the recessive state of a CAN transceiver is not actively driven. The termination resistors together with transceiver input capacitance and cable capacitance create an RC time-constant discharge when an actively-driven dominant bit on the bus transitions to an un-driven recessive bit. For signaling rates greater than CAN's 1Mbps, a technology that actively drives the bus in both states such as RS-485 is required to facilitate the bus transitions required for high-speed signaling rates.

Ultimately, the answer to the question is how the CAN protocol is implemented at a physical level. Change that protocol and a higher data rate can be used.

From Understanding Microchip’s CAN Module Bit Timing

... the CAN protocol implements a non-destructive bitwise arbitration scheme that allows multiple nodes to arbitrate for control of the bus.
Therefore, it is necessary for all the nodes to detect/ sample the bits within the same bit time. The relationship between propagation delay and oscillator tolerance effect both the CAN data rate and the bus length.

Two masters on either end of the CAN bus must be able to communicate and arbitrate which one has the bus, while each are on the bus at the same time.

If the bus length is 30m, the time it takes to propagate the signal over the bus is: $$t_{BUS} = 30m @ 5.5 ns/m = 165ns$$

Assuming the input comparator delay is $t_{CMP}$ = 40ns and the output driver delay is $t_{DRV}$ = 60ns for all devices.

The round trip time for a bit on the physical bus will be:

$$t_{PROP} = 2(t_{BUS} + t_{CMP} + t_{DRV}) = 2 (165ns + 40ns + 60ns) = 530ns$$
$$TQ = 530ns/6 = 88.33ns $$
$$t_{BIT} = 10times TQ = 883.3ns $$
$$ f = 1/t_{BIT} = 1 / 883.3ns = 1.13MHz $$

The maximum rate is governed by bus length, line capacitance, connected nodes and the drivers selected by the protocol. In principle at 30m, CAN could do 1.13Mz if everything was perfect.

Longer the bus, the slower the data rate. But a shorter bus would mean a higher rate. CAN bit rate vs Bus length:

Both referenced documents go into this at greater length.

It can. Meet CAN-FD.

Why was a new protocol needed? CAN is a multi-master bus with arbitration and error reporting. These features limit the data rate based on the cable length, since it takes a certain amount of time for the signal to make a round trip between the two farthest nodes. That, along with backwards compatibility requirements, led to CAN-FD.

Classic CAN at 1 Mbps is limited to a 40-meter bus length. (In practice, I think it's lower due to stray capacitance.) At 100 Mbps, you'd be lucky to have even half a meter of usable bus length, which is not enough for automotive and industrial applications.