LIN Bus, FlexRay, and Automotive Ethernet: The Networks Beyond CAN

Modern Vehicles Use Multiple Networks

CAN bus gets most of the attention in automotive network diagnosis — and for good reason. High-speed CAN carries the most critical real-time data for powertrain and chassis management, and CAN faults generate the cascade of U-codes that bring vehicles into the shop. But CAN is not the only network in a modern vehicle, and focusing only on CAN leaves you blind to faults on the other networks that share the vehicle's electronic architecture.

A 2023 mid-range vehicle may simultaneously operate a high-speed powertrain CAN bus, a medium-speed body CAN bus, multiple LIN sub-networks for individual body modules, and Automotive Ethernet for the infotainment display and backup camera system. A premium vehicle adds FlexRay for active suspension and steering. Each network is optimized for its application — chosen because its data rate, cost, and timing characteristics match the requirements of the systems it serves.

Understanding why each network exists — what makes LIN appropriate for a mirror motor but CAN necessary for ABS data, and why Ethernet is required for camera data that neither CAN nor LIN can carry — helps you diagnose faults on each network because you understand what the network is supposed to be doing and what a fault on it should look like.

LIN Bus — The Low-Cost Body Network

Local Interconnect Network was developed specifically to provide a lower-cost alternative to CAN for simple body functions. A power mirror motor does not need to communicate at 500 kilobits per second. It needs to receive a simple command — move left, move right, stop — and acknowledge that the command was received. This simple exchange does not justify the hardware cost of a CAN transceiver in every mirror assembly, seat module, and window switch housing.

LIN solves this with a single-wire, master-slave architecture. One master node — typically the BCM — controls all communication on the LIN bus. Slave nodes — the mirror motor, the rain sensor, the seat position actuator — only transmit when the master gives them permission. The master sends a header frame that includes the identifier of the slave it wants to communicate with. Only the addressed slave responds. This eliminates the collision-avoidance complexity of CAN because only one device transmits at a time and the master controls who that is.

LIN operates at up to 20 kilobits per second on a single wire that references chassis ground. The signal swings between 0 volts (dominant bit, recessive state shorted to ground by the transmitter) and battery voltage (recessive bit, the bus pulled high by a resistor). This is a simpler, cheaper electrical interface than CAN's differential pair, but it lacks the noise immunity of differential signaling. LIN wiring needs to be kept reasonably short and away from high-current wiring to maintain signal integrity.

Common LIN bus applications: power mirror adjustment and memory, rain and light sensors, power window switch modules (on some platforms), ambient interior lighting control, seat position motors and memory, climate control panel buttons, and steering column modules. Any body function where simple commands and low data volume are sufficient can be implemented cost-effectively with LIN.

Diagnosing LIN Bus Faults

LIN bus faults present differently from CAN bus faults because of the master-slave architecture. A LIN fault almost always affects a specific subsystem — one mirror module, one seat module, one rain sensor — rather than the entire vehicle's communication network. When the left power mirror stops responding but everything else works normally, that is a LIN fault symptom. When everything on the vehicle stops communicating, that is a CAN fault symptom.

The first diagnostic step for a LIN fault is confirming whether the master can communicate with the failing slave at all. Many scan tools that support manufacturer-specific diagnostics can access LIN bus data through the BCM gateway — displaying the status of individual LIN slave devices. If the scan tool shows the left mirror module as absent or non-communicating, the fault is between the BCM and that module, not in the mirror mechanism itself.

Physical diagnosis requires a scope or meter on the LIN wire. Locate the LIN bus wire for the affected system using the vehicle's wiring diagram — it is a single wire connecting the master (BCM) to the slave module(s). With the ignition on, measure the voltage on the LIN wire at the slave module connector.

In the idle state between frames, the LIN bus should be at battery voltage — the pull-up resistor in the master holds it high. When the master transmits a header or a slave responds, the voltage drops to near zero for the dominant bits. On a scope, you see digital pulses swinging between 0V and approximately 12V.

A flat line at battery voltage means no communication is occurring — either the master is not sending frames to this slave, or the bus is shorted high and the slave cannot pull it low. Check whether the BCM is commanding the LIN sub-network by observing the wire at the BCM connector. If the BCM shows activity (pulses) but the wire at the slave shows flat high, the wiring between them is open or has high resistance.

A flat line at zero volts means the bus is shorted to ground. A slave device or the wiring itself is pulling the LIN bus to ground continuously, preventing any communication. Unplug slave devices one at a time while monitoring the wire — when the bus returns to battery voltage after unplugging a specific slave, that slave is the one shorted to ground.

FlexRay — Safety-Critical High Speed

FlexRay addresses a limitation of CAN that matters for safety-critical systems: CAN is not deterministic. CAN message delivery timing varies based on bus traffic and priority arbitration. In most automotive applications this variable timing is acceptable. But in a steer-by-wire system — where the steering wheel is mechanically disconnected from the wheels and the steering input is transmitted electrically — variable message timing is not acceptable. A delayed steering command of even a few milliseconds could cause a safety hazard.

FlexRay solves this through a time-division communication protocol. Each node is assigned a specific time slot in a fixed communication cycle, and it can only transmit in its assigned slot. Every node receives data in a guaranteed time window, every cycle. This deterministic behavior — the guarantee that a message arrives within a defined time — is what makes FlexRay suitable for active safety systems.

FlexRay operates at 10 megabits per second — twenty times faster than high-speed CAN. It uses two channels for redundancy, both of which carry the same data. If one channel develops a fault, the system continues operating on the other channel. This redundancy is another safety requirement for steer-by-wire and active chassis systems.

In shop practice, FlexRay faults on the systems that use it — primarily BMW active steering, Mercedes active suspension, and similar premium platform systems — typically require manufacturer-specific scan tool access to read FlexRay network status and diagnose module communication. Physical layer diagnosis uses the same principles as CAN — confirm wiring integrity, check for opens and shorts between the two FlexRay wire pairs — but the voltage levels and timing specifications differ and require consulting manufacturer service data for the specific implementation.

Automotive Ethernet — The ADAS and Infotainment Network

Automotive Ethernet is the network that makes modern ADAS, high-resolution displays, and over-the-air software updates possible. The data volume requirements of these systems simply exceed what CAN can provide. A forward-facing ADAS camera processing lane departure, pedestrian detection, and adaptive cruise control data simultaneously generates 1 to 3 gigabits per second of raw data. High-speed CAN at 500 kilobits per second would require 2,000 to 6,000 CAN buses running simultaneously just for one camera. Automotive Ethernet at 100 megabits per second per wire — using one twisted pair — handles the same data in a small fraction of the cabling.

The standardized automotive Ethernet variants are 100BASE-T1 (100 megabits per second on one unshielded twisted pair) and 1000BASE-T1 (one gigabit per second on one unshielded twisted pair). The single-pair design — compared to the four pairs used in standard IT Ethernet — reduces cable weight and cost. Both variants use the same differential signaling principle as CAN — the signal is read as the difference between two wires, providing noise immunity.

Automotive Ethernet connects ADAS camera modules, radar processors, surround-view camera systems, central gateway modules, and high-resolution display modules. On vehicles with over-the-air update capability, the cellular telematics module connects to the Ethernet backbone to deliver software packages to the gateway, which distributes them to individual modules over their respective networks.

Diagnosing Automotive Ethernet faults in the shop currently requires manufacturer-specific scan tool capabilities in most cases, because the standard OBD-II diagnostic protocol does not include Ethernet network status monitoring. A camera that goes offline, a display that loses its video feed, or an ADAS system that shows a camera fault — these may be Ethernet physical layer issues (open or shorted Ethernet wiring), connector issues at the camera or display module, or module failures. Physical layer diagnosis uses the same principles as other differential networks: check for opens, shorts, and correct termination at the module connectors using the manufacturer's wiring diagrams and service specifications.

Gateway Modules and Network Translation

In a vehicle with multiple networks — high-speed CAN for powertrain, body CAN for body systems, LIN sub-networks for individual components, and Ethernet for ADAS — data frequently needs to move between networks. The engine control module on the powertrain CAN bus generates engine RPM data. The instrument cluster on the body CAN bus needs to display that RPM. The gateway module translates the data from one network format to another and forwards it.

Gateway modules are central nodes that have connections to multiple networks simultaneously. They receive data on one network, translate the message format, and re-transmit it on another network. They also provide scan tool access — the OBD-II DLC connects to the gateway, which allows the external scan tool to communicate with modules on any network the gateway connects to, even networks (like LIN) that the scan tool cannot access directly.

A failing gateway module generates U-codes on all networks simultaneously — because the gateway is what allows the modules on each network to receive translated data from the others. Modules that depend on gateway-translated data all stop receiving their data at once. This U-code cascade from gateway failure is similar in presentation to a CAN bus physical layer failure, but the 60-ohm test will come back correct because the bus wiring is intact. The fault is in the module that is supposed to translate and forward data, not in the bus itself.

Replace or reprogram the gateway module according to manufacturer procedure, which typically includes programming the new module with the vehicle identification and configuration data. An incorrectly configured gateway can block communication between networks even if it is otherwise functional.

Identifying Which Network Is at Fault

When a communication fault complaint comes in, the first step is identifying which network the affected system lives on. This requires knowing the vehicle's network architecture — which is in the service information network topology section. Not every complaint involves CAN. Spending time diagnosing the CAN bus when the fault is on a LIN sub-network wastes diagnostic time on the wrong network.

The pattern of affected systems tells you the network. A single isolated body function — one mirror, one seat, one ambient light zone — points to a LIN sub-network. Multiple powertrain and chassis systems simultaneously — engine, transmission, ABS, stability control — points to high-speed powertrain CAN. Multiple body functions simultaneously without affecting powertrain — windows, cluster, BCM functions — points to body CAN. A single ADAS camera or display module — points to Automotive Ethernet. ADAS systems across the board simultaneously — points to the Ethernet backbone or gateway.

Once you have identified the probable network, apply the appropriate diagnostic approach for that network. CAN uses the 60-ohm resistance test and scope waveform analysis. LIN uses scope waveform analysis at the single LIN wire. FlexRay and Ethernet require manufacturer scan tool access for network status and service data for physical layer specifications.

The Bottom Line

CAN bus is the most common vehicle network, but understanding only CAN leaves gaps in your diagnostic capability. LIN bus faults affect body subsystems on every modern vehicle. Automotive Ethernet faults are increasingly common as ADAS systems proliferate across vehicle lines. FlexRay appears on the premium platforms that are growing in shop volume as these vehicles age into independent shop territory. Automotive technician training that covers all major vehicle network protocols produces technicians who are not surprised by what they find on modern vehicles and who have systematic diagnostic approaches for every network type they encounter.