Can vs LIN bus interfaces in automotive electronics

Modern cars have more electronics than you can think of. Almost every vital part has tons of sensors on it with a dedicated computer called ECU (Electrical Control Unit). Usually, there are from several up to hundreds of ECU’s in a single car. Especially luxury ones. All modules have to work as an organized unit. So this is where a reliable connection interface is needed.

Probably you’ve already heard of CAN bus (Controller Area Network). It is a standard bus interface used in most vehicles where the board computer communicates with separate control ECUs taking care of the engine, gearbox, climate, security alarm, and safety bags. CAN devices are connected by using twisted pair signal wires that are more resistant to noises. Signals usually operate at the 5V level. The transfer speed can reach up to 1Mb/s for 40m cable lengths.

Engineers have put lots of thought into CAN protocol. It was designed to be flexible, reliable, and robust. There can be more than one master CAN device on the same bus. For instance, there can be a situation when several masters start communication at the same time. In this case, there is a message priority used to determine which one will have the right to transmit data first. CAN nodes act as independent units and can receive any message and take action if needed. This feature is called ‘multicast.’ This allows adding new CAN devices to an existing bus without reconfiguring the existing setup.

CAN vs. LIN interface

CAN interface is a complex interface allowing to have multiple masters, what makes it robust and versatile. But due to the increasing cost of the number of electronics used in cars, manufacturers started looking for cheaper solutions that would complement the CAN bus and be more affordable. They came up with LIN (Local Interconnect Network) bus.

LIN bus interface is a more specific standard compared to CAN. LIN can have up to 16 slave nodes controlled by one master. It is slower and cheaper as nodes are clocked by the master (no crystals for each slave node). LIN can be implemented merely as a sub-function in the CAN-LIN interface using USART in the RISC microcontroller. CAN transceiver is a sophisticated device, so it usually comes as a separate peripheral or as a separate chip. LIN uses a single wire for communications with about a 40V signal voltage level. It can reach up to 19.2kbps communication speed with a maximum 40m length of the line.

Here are some advantages of LIN over CAN

1. Cost-effective: LIN is a simpler and less expensive protocol than CAN, making it a more cost-effective solution for lower bandwidth applications that don’t require the advanced functionality provided by CAN.
2. Lower power consumption: LIN is designed for use in low-power environments and therefore has lower power consumption than CAN, which makes it a good choice for applications where power efficiency is a concern.
3. Simplified implementation: LIN has a more straightforward protocol stack than CAN, making it easier to implement and requiring less processing power. This can be particularly useful in applications with limited processing resources.
4. Shorter bus length: LIN has a shorter maximum bus length than CAN, which makes it more suitable for applications where the devices are located close to each other, such as indoor modules, seat controllers, and dashboard instruments.
5. More deterministic: LIN has a fixed cycle time and is more deterministic than CAN, which makes it a good choice for applications that require a predictable and repeatable communication cycle, such as automotive lighting and wiper systems.

A few disadvantages of LIN protocol

1. Lower bandwidth: LIN has a lower data transfer rate than CAN, which makes it less suitable for applications that require high-speed communication.
2. Limited network size: LIN is designed for use in small networks with a limited number of nodes, typically up to 16 devices. This makes it less suitable for larger networks or more complex systems.
3. Limited error detection and correction: LIN has limited error detection and correction capabilities compared to CAN, which makes it more vulnerable to errors and data corruption.
4. Limited message prioritization: LIN has a fixed message prioritization scheme, which means that it may not be able to support more complex message scheduling requirements.
5. Limited flexibility: The simplicity of the LIN protocol also means that it has limited flexibility and may not be suitable for more complex applications that require advanced functionality or customization.

Main disadvantages of the CAN protocol

1. Complexity: CAN is a more complex protocol compared to LIN, which makes it more difficult to implement and requires more processing power. This can be a disadvantage for applications with limited resources.
2. Higher cost: CAN is a more expensive protocol than LIN, primarily due to its more advanced features and higher bandwidth capabilities.
3. Limited determinism: CAN is less deterministic than LIN, which means that the timing of message delivery is not as predictable or repeatable. This can disadvantage applications that require precise timing or coordination between devices.

Here are some areas where CAN and LIN they are typically used

CAN:

• Engine control and management systems
• Transmission control systems
• Anti-lock braking systems (ABS)
• Powertrain systems
• Vehicle dynamics control systems
• Infotainment systems
• Instrument clusters
• Body control systems

LIN:

• Door modules (power windows, locks, mirrors)
• Seat controllers
• Steering wheel controls
• Sunroof control
• Dashboard instruments (e.g., fuel gauges, speedometers)
• Lighting control systems
• Wiper systems
• Climate control systems

However, there can be overlap in some applications, and the choice of protocol depends on the specific requirements of the system.

After this short overview, it is evident that the LIN interface is a low band, less effective bus interface compared to CAN. On the other hand, where efficiency isn’t a ‘must’ factor, it is a cheap complement to the CAN network.