CAN vs LIN vs Automotive Ethernet: In-Vehicle Networks Explained
What is the difference between CAN, LIN and Automotive Ethernet? LIN is the cheapest and slowest network, built for simple local actuators and sensors at up to 20 kbit/s. CAN and CAN FD carry robust, priority-based control traffic at up to 1 Mbit/s for Classical CAN and a faster data phase for CAN FD. Automotive Ethernet adds switched links from 10 Mbit/s into multi-gigabit rates for cameras, diagnostics, backbones and central compute. Modern cars use all three because speed, latency, cost and fault containment matter more than choosing one winner.
A window switch does not need a gigabit link. Eight cameras cannot share a 20 kbit/s LIN bus. The useful engineering question is not which network is best, but where each one earns its place in the vehicle.
What is an in-vehicle network?
An in-vehicle network moves commands, measurements, diagnostics and software data between electronic control units, sensors, actuators and computers. It is part of the wider automotive E/E architecture, which also decides where computing and electrical power live.
The network has to survive voltage transients, electromagnetic noise, temperature, vibration and faults. It must also wake and sleep with the vehicle, support production diagnostics and deliver critical messages within a justified time. Raw bandwidth is only one design input.
CAN vs LIN vs Automotive Ethernet comparison
| Characteristic | LIN | CAN / CAN FD | Automotive Ethernet |
|---|---|---|---|
| Maximum or family rate | Up to 20 kbit/s | Classical CAN up to 1 Mbit/s; CAN FD data phase can reach 8 Mbit/s with suitable design | 10 Mbit/s, 100 Mbit/s, 1 Gbit/s and multi-gigabit variants |
| Access method | One commander schedules responder transmissions | Multiple controllers arbitrate by message identifier | Usually switched, full-duplex point-to-point links; 10BASE-T1S also supports shared media |
| Wiring | One signal wire plus ground reference | Differential twisted pair | One balanced pair per T1 link |
| Data per message | Up to 8 data bytes | 8 bytes in Classical CAN, up to 64 in CAN FD | Ethernet frames support much larger transfers and streams |
| Relative endpoint cost | Lowest | Low to medium | Higher PHY, switch and software cost, with possible system-level savings |
| Typical use | Windows, mirrors, seats, locks, small climate actuators | Body, chassis, powertrain, battery, thermal and diagnostics | Backbone, cameras, infotainment, central compute, OTA and DoIP |
Cost is deliberately relative. A cheap transceiver can become expensive if its network forces extra gateways, duplicated computers or long harness branches. Ethernet can cost more at one port yet save money at vehicle level when it consolidates links and computing.
How LIN works in a car
LIN, Local Interconnect Network, is a scheduled serial bus. One commander sends a header according to a schedule table. The assigned responder then supplies the data. Because responders do not arbitrate for the bus, their hardware and clocks can stay simple and cheap. The schedule also makes timing predictable.
The tradeoff is obvious: 20 kbit/s and eight data bytes are enough for a mirror position or seat motor status, not camera video or a large calibration transfer. LIN usually sits below a CAN-connected body controller or zone controller. That parent node translates local signals into the rest of the car.
How CAN and CAN FD work
CAN, Controller Area Network, is a shared differential bus. Controllers begin transmission when the bus is idle. If two start together, nondestructive arbitration lets the frame with the higher-priority identifier continue while the other waits. In standard CAN, a numerically lower identifier wins. The identifier describes the message and its priority, not a destination address.
Classical CAN carries up to eight data bytes and reaches 1 Mbit/s. CAN FD expands the payload to 64 bytes and can switch to a higher rate during the data phase. CiA notes that the achievable rate depends on topology, cable, connectors and transceivers. CAN SIC hardware can support up to 8 Mbit/s under a suitable design, but that number is not a promise for every harness.
What is Automotive Ethernet?
Automotive Ethernet uses the Ethernet frame and MAC concepts familiar from computer networks, paired with physical layers designed for vehicle cabling, electromagnetic compatibility, temperature and packaging. T1 variants communicate over one balanced pair rather than the four-pair cable associated with office Gigabit Ethernet.
| Ethernet PHY | Rate | Typical role |
|---|---|---|
| 10BASE-T1S | 10 Mbit/s | Lower-cost edge nodes and multidrop control segments |
| 100BASE-T1 | 100 Mbit/s | Zone links, gateways, displays and moderate-rate sensors |
| 1000BASE-T1 | 1 Gbit/s | Backbones, cameras and high-performance computers |
| 2.5/5/10GBASE-T1 | 2.5 to 10 Gbit/s | High-resolution sensor aggregation and compute links |
Ethernet does not mean every packet uses TCP. Vehicles can carry UDP, TCP, SOME/IP services, diagnostics over IP, time synchronization and network-management traffic. AUTOSAR defines SOME/IP for remote procedure calls, events and serialization across automotive systems.
Bandwidth is not the same as latency or determinism
A 1 Gbit/s link can move far more data than CAN, but safety analysis asks when the important message arrives under worst-case load. LIN gets predictability from its schedule. CAN gets priority and bounded behaviour from arbitration when bus load and message timing are engineered correctly. Switched Ethernet removes collisions on full-duplex links, then uses queue design, traffic classes, time synchronization and Time-Sensitive Networking where bounded latency is required.
This is why “Ethernet is faster" is true but incomplete. A poorly configured switch can delay a small critical packet behind other traffic. A well-designed CAN bus can deliver a high-priority brake status quickly even though its total bandwidth is modest.
Why Automotive Ethernet and zonal architecture are rising
Cameras, radar, infotainment, centralized logging and software updates create traffic that legacy control buses were not designed to carry. At the same time, the software-defined vehicle needs stable, service-oriented communication between reusable software and shared computers. Ethernet brings bandwidth, switching, mature IP tooling and a scalable family of physical layers.
Zonal architecture changes the wiring problem. Instead of running every door, lamp and sensor wire toward a function-specific controller elsewhere in the car, nearby devices terminate at a zone controller. The zone aggregates local LIN, CAN, Ethernet and direct I/O, then connects to central compute through a fast Ethernet backbone. OPEN Alliance describes this shift as services on high-performance computers connected to zonal ECUs that manage local input and output.
Domain controller vs zone controller
| Controller | Organised by | Typical responsibility | Wiring effect |
|---|---|---|---|
| Domain controller | Function | Body, chassis, powertrain, cockpit or ADAS | Devices can cross the car to reach their functional domain |
| Zone controller | Physical location | Local I/O, power distribution, gateway and real-time edge control | Nearby devices terminate locally, then share a backbone |
| Central computer | Vehicle-wide software | Cross-domain applications, services and high-performance processing | Consumes aggregated data instead of every raw wire |
Production vehicles often mix all three. A zonal diagram does not prove that every domain controller disappeared, nor does it guarantee a lighter harness. Redundancy, safety separation, power distribution and packaging can add paths. The gain must be demonstrated at whole-vehicle level.
How CAN, LIN and Ethernet coexist in one vehicle
A realistic path might start with a LIN window motor. Its door or zone controller publishes selected status on CAN or as an Ethernet service. A central body application commands the function through the backbone, while the zone handles hard local timing. Cameras connect through Ethernet, a brake controller can remain on dedicated CAN, and diagnostics cross the gateway.
The gateway is therefore more than a plug adapter. It translates signals and services, packs messages, filters traffic, manages wake-up, applies security policy and isolates faults. The architecture has to preserve meaning and timing across every conversion.
Will Automotive Ethernet replace CAN and LIN?
Ethernet will keep expanding, especially as 10BASE-T1S lowers the entry cost for edge nodes. It still does not erase the economics of a proven CAN controller or a LIN actuator. CAN has an enormous installed base, mature tooling and efficient event-driven control. LIN remains hard to beat when a device moves slowly and sends a few bytes.
The likely endpoint is not one homogeneous network. It is a cleaner hierarchy: Ethernet for the backbone and data-heavy endpoints, CAN or CAN FD for many robust control islands, and LIN for the cheapest local branches. Newer CAN XL and Ethernet edge standards may move the boundaries, but function, safety case and vehicle cost decide the result.
Where in-vehicle networking fits in the engineering stack
Network design connects the systems that make a car work to the compute platform. See how Tesla applies the SDV model, how Nvidia Automotive supplies centralized compute, and why AI functions need controlled sensor data. The responsibility boundary in Level 2 vs Level 3 driving makes network timing and fault containment more than a performance concern.
The physical platform still matters. Network controllers and computers must integrate with an EV's 800-volt and low-voltage architecture, survive the automotive development and validation process, and reach a controlled Start of Production. The automotive engineering hub connects those layers.
Primary sources: The LIN Consortium's LIN 2.2A specification; CiA's CAN generation and data-rate overview; IEEE specifications for 100BASE-T1, 1000BASE-T1, 2.5/5/10GBASE-T1 and 10 Mbit/s single-pair Ethernet; OPEN Alliance on the domain-to-zonal shift; and AUTOSAR's SOME/IP protocol specification.
CAN, LIN and Automotive Ethernet: frequently asked questions
What is the difference between CAN, LIN and Automotive Ethernet?
LIN is the lowest-cost, lowest-speed scheduled bus for simple local devices. CAN provides robust priority-based control communication. Automotive Ethernet provides switched bandwidth and IP-compatible networking for backbones, cameras, diagnostics and central compute.
Is Automotive Ethernet replacing CAN?
Not completely. Ethernet is taking over high-bandwidth backbones and some edge links, while CAN and CAN FD remain efficient for many control networks. Most current vehicles use gateways and zone controllers to combine them.
How fast are LIN, CAN and Automotive Ethernet?
LIN runs up to 20 kbit/s. Classical CAN reaches 1 Mbit/s, while CAN FD can use a faster data phase up to 8 Mbit/s with suitable topology and transceivers. Automotive Ethernet standards span 10 Mbit/s to multi-gigabit rates.
Why is LIN still used in cars?
LIN keeps the controller, transceiver, wiring and software inexpensive for low-rate functions such as mirrors, seats, windows, locks and simple climate actuators. Those devices do not need Ethernet bandwidth.
What is the difference between a domain controller and a zone controller?
A domain controller groups functions such as body, chassis or infotainment. A zone controller groups nearby physical devices, aggregates their power and data, and connects the zone to central compute.
Does Automotive Ethernet always use TCP/IP?
No. Ethernet defines the link technology and frames. It can carry IP, TCP, UDP, SOME/IP and diagnostics, but time synchronization, network management and other traffic can use Ethernet without TCP.
Original EV-Global illustration, created for this in-vehicle network guide.
