Why one bus was never enough
CAN was presented by Bosch in 1986 and reached series production in a passenger car in 1991. The original promise was simple: replace kilometres of point-to-point wiring with one shared twisted pair on which every ECU could broadcast. Three decades later, no production vehicle runs on a single bus. A compact car carries a handful of CAN segments; a premium platform can carry more than ten CAN and CAN FD segments, dozens of LIN clusters and a growing Ethernet backbone, connecting anywhere from several dozen to well over a hundred ECUs.
The partitioning is deliberate. Engineers split the network along the same lines they split responsibility, timing and risk. Each reason below is a constraint that a single shared bus cannot satisfy at the same time:
- Bandwidth. A classic CAN bus at 500 kbit/s carries roughly 3,700 to 4,500 eight-byte frames per second at 100 % load. Powertrain, chassis, body and infotainment together produce far more traffic than that.
- Timing. Engine and brake control loops need short, predictable latency. A door module or seat motor does not. Mixing both on one bus makes the slow traffic compete in arbitration with the fast traffic.
- Fault containment. A shorted pair, a babbling node or a failed transceiver should take down one segment, not the whole vehicle.
- Power management. Body and comfort ECUs must sleep within minutes of locking the car, while some powertrain controllers wake only with the ignition. Separate segments can sleep independently.
- Security. Since the late 2010s, separating externally reachable systems (connectivity, infotainment, diagnostics) from safety-relevant control has become a regulatory expectation, not just good practice.
The classic domain map
For roughly twenty years, vehicle electrical and electronic (E/E) architecture has been organised by function domain. Every domain owns one or more buses, and each bus carries the traffic its members need. The exact split varies by manufacturer and platform generation, but the pattern below describes most vehicles on the road in 2026.
Why body networks behave differently
Body networks have the most nodes, the longest wire runs and the strictest sleep requirements. Many European vehicles of the 2000s used fault-tolerant low-speed CAN to ISO 11898-3, limited to 125 kbit/s but able to keep communicating over a single wire after a short or open on the other line. Current platforms have largely moved body traffic to high-speed CAN at 500 kbit/s per ISO 11898-2, using network management and partial networking to keep sleep current low. A body segment is also where most aftermarket equipment ends up physically close to the wiring, which is why its sleep behaviour matters far beyond the OEM's own design.
The bus families inside one vehicle
CAN is the workhorse, but it is not alone. A single vehicle typically combines four or five network technologies, each chosen for a cost, bandwidth and determinism trade-off.
LIN: the bus below CAN
LIN (Local Interconnect Network) is a single-wire, 12 V bus with one commander and up to fifteen responders, running at up to 20 kbit/s over a maximum of about 40 m. The commander owns a fixed schedule table and polls each responder in turn, so LIN needs no arbitration and no crystal on the responder side. It drives window switches, mirror motors, rain and light sensors, seat adjusters and climate flaps. Architecturally, every LIN cluster hangs off a CAN ECU acting as commander. Whatever happens on the LIN side reaches the rest of the vehicle only through that ECU's CAN messages; the LIN wire itself is invisible from any CAN segment.
FlexRay: the deterministic legacy
FlexRay was designed in the 2000s for x-by-wire and active chassis systems: 10 Mbit/s per channel, two redundant channels and a time-triggered schedule with a static segment for guaranteed slots and a dynamic segment for event traffic. It entered production in 2006 and was standardised as ISO 17458 in 2013. Many vehicles built on premium European platforms still carry FlexRay chassis networks today, so it remains relevant for service work. New platform designs, however, have largely replaced it with CAN FD for control and Ethernet with Time-Sensitive Networking (TSN) for high-bandwidth deterministic traffic.
The central gateway
Once a vehicle has more than one bus, something must connect them. In a domain architecture that is the central gateway: a dedicated ECU with a transceiver on every segment and firmware that decides which information crosses from one network to another. Its responsibilities have grown with every platform generation:
- Routing. Forwarding selected frames or individual signals from one segment to another, often re-packing them into different frames on the target bus.
- Protocol and bitrate translation. Bridging classic CAN, CAN FD, LIN, FlexRay and Ethernet, each with its own timing and payload size.
- Diagnostic routing. Terminating the diagnostic connector and forwarding workshop requests (ISO 15765-4 on CAN, ISO 13400 DoIP on Ethernet) to the addressed ECU.
- Network management coordination. Propagating wake-up and sleep decisions between segments so that the vehicle wakes and sleeps as one system.
- Firewalling and security. Filtering what is allowed to cross, rate-limiting diagnostic access, and in recent vehicles enforcing authentication before any write or active function.
- Fault isolation. Keeping a short circuit, a stuck dominant line or a babbling node on one segment from disturbing the others.
The practical consequence is easy to overlook: no single segment shows the whole vehicle. Each bus carries the traffic its members need, and the gateway decides what crosses. That is also why the diagnostic connector in a modern car gives a very different view from the buses behind it; the OBD-II and secure gateways article covers this in depth.
One trunk, a terminator at each physical end and short stubs to every control unit.
Routing has a cost
A CAN gateway is a store-and-forward device. A frame must be received completely, checked, filtered, possibly re-packed and then queued for arbitration on the target bus, where it competes with that bus's own traffic. Every hop therefore adds latency and jitter. Architects keep tight control loops inside one domain and route only information that tolerates the extra delay. For anyone working on a vehicle this means that the same piece of information can appear on several segments with different timing, different frame layouts and different update rates, because it has been re-published rather than copied.
Bandwidth arithmetic: why CAN FD arrived
The pressure on classic CAN is easiest to see with numbers. A classic data frame with an 11-bit identifier and eight data bytes is 108 bits long, plus a 3-bit interframe space, giving 111 bits before bit stuffing. In the worst case the stuffing rule adds 24 more bits, for 135 bits. The can-frame-and-arbitration article explains where each bit comes from.
t_frame = N_bits ÷ bitrate → 111 bits ÷ 500 kbit/s = 222 µs … 135 bits ÷ 500 kbit/s = 270 µs- 01Count the traffic
Assume a powertrain segment with 20 messages sent every 10 ms (2,000 frames/s) and 30 messages sent every 100 ms (300 frames/s): 2,300 frames per second in total, all with eight data bytes.
- 02Convert to bits per second
2,300 × 111 bits = 255,300 bit/s without stuffing; 2,300 × 135 bits = 310,500 bit/s with worst-case stuffing.
- 03Divide by the bitrate
255,300 ÷ 500,000 = 51 % and 310,500 ÷ 500,000 = 62 % bus load, before a single diagnostic session or error frame is added.
- 04Interpret the result
CAN arbitration is priority-based, so high-priority frames are barely affected, but the lowest-priority messages wait longer as load rises. At these loads there is little room for new functions, for diagnostic traffic or for the extra bytes that message authentication requires.
CAN FD changes the equation in two ways: up to 64 data bytes per frame and a faster data phase after the BRS bit. Moving 64 bytes as eight classic frames occupies about 1.78 to 2.16 ms of a 500 kbit/s bus. A single CAN FD frame with a 500 kbit/s nominal bitrate and a 2 Mbit/s data phase carries the same 64 bytes in roughly 0.33 to 0.41 ms, about one fifth of the bus time. The detailed comparison is in Classic CAN vs CAN FD.
From domains to zones
Domain architecture grew by adding an ECU for every new function, each wired to its own sensors and actuators wherever they sat in the vehicle. The result is a harness of several kilometres and tens of kilograms, one of the heaviest and most labour-intensive components in the car. Zonal architecture reorganises the same functions by physical location: a small number of zone controllers (for example front-left, front-right and rear) collect all sensors, actuators, LIN clusters and local CAN segments in their area and connect over an Ethernet backbone to one or more central vehicle computers, where the function software runs.
Each function has its own network, and a central gateway links them.
Why CAN does not disappear
Zonal architecture does not retire CAN; it moves CAN to the edge. A window motor, a seat module or a battery sensor needs a few bytes every few tens of milliseconds, robust operation across a wide temperature range and the lowest possible cost per node. Classic CAN and CAN FD meet that brief better than any Ethernet PHY. CAN XL, standardised in ISO 11898-1:2024, extends the family toward Ethernet-like payloads, while 10BASE-T1S multidrop Ethernet competes for the same edge role. In practice, vehicles leaving the factory in 2026 combine all of these, and mixed fleets of domain, hybrid and zonal designs will be in service for decades.
Zones also change how power is switched
Zone controllers increasingly switch power electronically instead of through relays and blade fuses, and they do so according to the vehicle's power mode. As a result, the traditional terminal 15 becomes a software state distributed over the network rather than a wire that follows a key. This matters most in electrified vehicles, where OFF, ON and READY are distinct states; see CAN in electric and hybrid vehicles.
Security is now an architectural requirement
UNECE Regulation No. 155 requires every manufacturer to operate an audited cybersecurity management system and to demonstrate its effect on each vehicle type. It became mandatory for new vehicle types in July 2022 and for all newly registered vehicles in July 2024 in the EU and the other contracting parties. Its companion, UNECE Regulation No. 156, governs software update management. Together they turned network segmentation from a design preference into an obligation and pushed several measures into series production:
- Segmentation and filtering at gateways, so that externally reachable ECUs cannot address safety-relevant control directly.
- Secure gateways that require an authenticated tester before diagnostic write, coding or programming functions are allowed.
- Message authentication (AUTOSAR SecOC), which appends a freshness value and a truncated message authentication code to selected frames. These extra bytes are one more reason the 64-byte CAN FD payload matters.
- Intrusion detection on gateways and central computers, monitoring timing and content of traffic for anomalies.
- Authenticated diagnostics, including certificate-based access via the UDS Authentication service introduced in ISO 14229-1:2020.
What architecture means in the field
For installers, service engineers and fleet integrators, architecture is not an abstract topic. It decides where a connection is safe, what a meter reading means and why the same model year can behave differently after a facelift. The rules below follow directly from the structure described above:
- 01Know which segment you are on. Wire colours and connector positions are manufacturer-specific. Use the OEM wiring documentation to confirm which segment a twisted pair belongs to before connecting anything.
- 02Respect termination. Every high-speed segment should measure close to 60 Ω between CAN-H and CAN-L with the battery disconnected. Never add a third terminator; the CAN physical layer article explains why.
- 03Stay off safety domains when you have a choice. Chassis, airbag and brake segments are the least tolerant of disturbance and the most likely to be monitored.
- 04Respect sleep. A segment that does not reach bus-sleep after locking drains the battery. Verify sleep behaviour after every installation.
- 05Expect gateways. The diagnostic connector is the gateway's service port, not a window into the vehicle's internal buses.
- 06Expect change. Facelifts, platform updates and zonal redesigns move segments, controllers and connectors. Re-check documentation for every model year.
How many CAN networks does a modern car have?
It varies widely. A compact car may have a handful of CAN segments; a premium platform can have more than ten CAN and CAN FD segments, plus many LIN clusters and an Ethernet backbone. The count also changes between model years of the same vehicle.
Is the diagnostic connector connected to every bus?
No. In most current vehicles it is connected to a dedicated diagnostic segment owned by the central gateway, which forwards diagnostic requests to the addressed ECU and returns the responses. Internal broadcast traffic stays on its own segments.
Will Automotive Ethernet replace CAN?
Not at the edge of the network. Ethernet takes over the backbone and high-bandwidth links such as cameras, while CAN and CAN FD remain the most cost-effective choice for sensors, actuators and control ECUs. Zonal vehicles still contain many CAN segments.
Is FlexRay still relevant?
For vehicles in service, yes: many premium platforms built in the last fifteen years use FlexRay in the chassis domain. For new designs, CAN FD and Ethernet with TSN have largely taken its place.
What is a zone controller?
An ECU that serves a physical area of the vehicle rather than a single function. It connects local sensors, actuators, LIN clusters and CAN segments, distributes power to them and links to central vehicle computers over Ethernet.
