LIN, FlexRay, Ethernet and ECU architecture

CAN answered one question well, and in doing so exposed three more. What about a mirror motor that does not justify a CAN controller? What about a control loop that cannot wait for higher priority traffic? What about a camera producing more data in a second than CAN carries in a minute? Each got its own answer.

A vehicle gateway module on a bench with its cover removed, showing the circuit board with several transceiver chips, a large microcontroller in the centre, and multiple connectors along one edge, with labelled harness plugs for separate powertrain, chassis, body and diagnostic connections laid out beside it. — A gateway with its lid off. Each connector along the edge is a different network, and the board in the middle decides which messages are allowed to cross between them.

Why not just use CAN for everything

A comparison of four vehicle networks. LIN is drawn as a single wire with one master and several slaves on a strict schedule, running at up to twenty kilobits per second, with the note that no collision is possible so no arbitration hardware is needed and nodes are very cheap. CAN is drawn as a twisted pair with priority based arbitration at up to one megabit per second, or five with CAN FD, used for powertrain, chassis and body. FlexRay is drawn as a repeating cycle of fixed time slots on one or two redundant channels at ten megabits per second, giving guaranteed latency for control loops. Automotive Ethernet 100BASE-T1 is drawn as a single unshielded twisted pair carrying both directions at once at one hundred megabits per second, used for cameras, infotainment and software updates, connected through a switch rather than a shared bus. A table beneath compares the four on topology, speed, determinism, cost per node and typical use. — Four networks because four different problems. Cost per node, guaranteed latency and raw bandwidth pull in different directions and no single scheme wins all three.

LIN (ISO 17987) is a single wire, up to about 20 kbit/s, with one master and a handful of slaves. There is no arbitration because there can be no collision — the master sends a header naming an identifier, exactly one slave is configured to answer it, and nothing else speaks. That removes the bus controller, the second wire, the terminators and most of the silicon, and what is left is cheap enough to put inside a mirror housing.

The functions suit it. Nobody notices twenty milliseconds on a window switch, a rain sensor or a seat heater. What a manufacturer does notice is the cost of a node multiplied by four doors multiplied by every vehicle built.

FlexRay exists for the opposite reason — not cost, but determinism. On CAN a low-priority message waits for a time that depends on what else is talking. That is acceptable almost everywhere and unacceptable in a control loop that must close on a fixed interval. FlexRay divides time into a repeating cycle of slots allocated at design time, so every message’s latency is known before the vehicle is built, and it offers two redundant channels. It appeared in active suspension, active steering and some brake-by-wire systems, and its role has since largely been taken by faster CAN FD and by Ethernet.

Automotive Ethernet — 100BASE-T1 (IEEE 802.3bw) and its faster relatives — answers the bandwidth question. The change from office Ethernet is physical: a single unshielded twisted pair carrying both directions at once, instead of separate pairs and a large connector. The transceivers have to cancel their own transmission out of what they receive, which is harder electrically, but the saving in copper, weight and connector size is decisive. Above the physical layer it is ordinary Ethernet, which is why the software stacks transferred so easily.

	LIN	CAN / CAN FD	FlexRay	100BASE-T1
Wires	1	2 twisted	2 or 4	2 twisted
Speed	20 kbit/s	500 kbit/s – 5 Mbit/s	10 Mbit/s	100 Mbit/s
Access	Master schedule	Priority arbitration	Fixed time slots	Switched, point to point
Latency	Predictable, slow	Depends on traffic	Guaranteed	Low, switched
Cost per node	Lowest	Low	High	Moderate
Typical use	Mirrors, switches, seats	Powertrain, chassis, body	Chassis control loops	Cameras, infotainment, updates

The gateway

A diagram of ECU internals and vehicle network architecture. On the left an electronic control unit is drawn as a block diagram — protected power supply, input conditioning with filtering and clamping, an analogue to digital converter feeding a microcontroller, output drivers, a watchdog, non-volatile memory holding calibration and fault codes, and network transceivers — with a note that a ten bit converter divides a five volt reference into 1,024 steps of just under five millivolts. On the right the vehicle architecture is drawn with a central gateway joining a powertrain CAN, a chassis CAN, a body CAN with LIN sub-networks hanging off individual modules, an Ethernet segment for cameras and infotainment, and the diagnostic connector, with the gateway shown forwarding only selected messages and acting as the security boundary for anything arriving from outside the vehicle. — The gateway is the only place where the diagnostic connector and the outside world meet anything that moves the vehicle. That is not an accident of layout.

The networks do not simply join. A gateway sits between them and forwards only what each side needs — road speed crosses from the powertrain network to the body network; injector timing does not. Selective forwarding keeps each segment’s load down, which matters because a CAN segment’s usable capacity falls well before its nominal bandwidth.

The gateway has also become the security boundary. It is the single point through which traffic from the diagnostic connector, or from a telematics unit with a mobile connection, has to pass before it can reach anything that moves the vehicle. Concentrating that boundary in one place is the only way to reason about it.

Inside a module

A control unit is a fairly conventional embedded computer with automotive-grade protection around it:

Power supply — regulated, and hardened against the cranking dips, load dump and reverse polarity of the vehicle’s electrical environment.
Input conditioning — filtering and clamping so that an induced spike on a sensor wire never reaches the microcontroller pin.
Analogue to digital conversion — the step that turns a voltage into a number. A 10-bit converter divides its reference into 1,024 steps, so across 5 V one step is just under 5 mV, and no reading can be finer than that. Sampling rate is a separate matter and decides how fast change is seen, not how finely it is measured.
Microcontroller — running the control strategy, usually on a fixed cycle.
Output drivers — the high-side, low-side and bridge circuits of actuators and PWM control, with their own current sensing.
Watchdog — a separate circuit that resets the processor if it stops servicing it.
Non-volatile memory — calibration, adaptations and fault codes, which is why these survive a battery disconnection and why some of them must be reset deliberately.
Transceivers — one per network the module is on.

Architecture, and where it is going

The old approach added a module per function. It stopped scaling, because the loom, the connectors and the network load grew faster than the functions did.

Domain and zonal architectures concentrate software into a few powerful controllers — powertrain, chassis, body, infotainment, driver assistance — with smaller zone units near the wiring whose main job is local input and output. The harness shortens dramatically, and new functions become software rather than hardware. The cost is that the remaining units are far more dependent on one another, so a single controller’s failure now takes several functions with it.

Diagnostics ride on top of all this. UDS (ISO 14229) standardises the conversation — read a data identifier, read and clear fault codes, run a routine, enter a programming session — while what each identifier means stays largely manufacturer-specific. It also defines sessions and security access, which is how a module tells apart being read from being reprogrammed.

Over-the-air updates put a concrete requirement on the hardware. A module that overwrites its only copy of its software has nothing to run if power is lost part way through, so updatable modules hold two banks and switch only once the new image is verified. An interrupted update is then simply abandoned. That doubles the flash requirement, which is one reason a vehicle designed to be updated costs more to build.

What to take away

LIN is master-scheduled on one wire. No collision is possible, so no arbitration hardware is needed, so the node is cheap. That is the whole argument.
FlexRay buys guaranteed latency with fixed time slots, and redundancy with two channels.
100BASE-T1 carries both directions on one twisted pair, and is switched rather than shared.
The gateway forwards selectively and is the security boundary; its failure looks like everything failing.
An ADC’s bit count sets resolution; sampling rate sets responsiveness; averaging trades one for the other.
Domain and zonal architectures trade independence for a shorter harness and software-defined functions.
UDS standardises the diagnostic conversation, not its content. OTA updates need two flash banks to be safe.

That completes the electrical and networking module. The next one takes the same reasoning to the high-voltage side of an electrified vehicle.