Commercial Vehicle E/E Architecture: From the Battery Post to the Driver's Screen

Updated August 2026

Ask two engineers to describe the electronics on a heavy truck and you will get two different answers. One will list boxes: a body control module, a couple of distribution boxes, a cluster, some switch panels. The other will describe flows: current from the battery, decisions from the control logic, messages on the bus, information to the driver. Both are right, and the gap between them is exactly where sourcing goes wrong. A part list can be quoted; an architecture has to be agreed.

This guide takes the second view, because it survives a change of vehicle: the functions on a city bus and a wheeled excavator are not remotely alike, but the layers underneath them are. It is written for OEM engineering and purchasing teams scoping a platform rather than replacing a part.

What “E/E architecture” means on a commercial vehicle

E/E architecture — electrical and electronic architecture, almost always written the short way — is the arrangement of the electrical and electronic content on a vehicle: which boxes exist, what each one is responsible for, how power reaches them, how they exchange information, and where the boundaries between subsystems fall. It is not a wiring diagram, which comes later and is far more detailed. It is the level at which you can still make cheap decisions, because nothing has been tooled yet.

Commercial vehicles differ from passenger cars in ways that change the architecture rather than just the parts. The nominal system voltage is usually 24 V rather than 12 V. Vehicle length pushes distribution outward, so a tractor unit often carries three or four distribution boxes where a passenger car concentrates the same job into one or two. Bodies are frequently built by a second company, which means the architecture has to expose a documented interface at the chassis boundary rather than assume one supplier owns everything. Production volumes are lower and variants are many, so configurability tends to beat integration. And the duty cycle is longer: a vehicle that runs 4,000 hours a year is not the same electrical environment as one that runs 300.

Three boundaries do most of the damage when they are left implicit: chassis versus body, tractor versus trailer, and on electric platforms high voltage versus auxiliary. Each cuts both the power and the message path, so each needs a document rather than an assumption — the two-plane figure below sets out what has to be agreed at each cut. Name all three in the specification and most interface arguments disappear before they start.

The four layers, and why the bus is not one of the steps

Almost every commercial-vehicle architecture can be read as four layers. Power moves current. Control decides. The network carries messages. The driver interface takes intent in and puts information out. Parts get mapped onto layers, not the other way around, which is why the same catalogue serves a city bus and a crane.

One clarification early, because the usual five-box flow diagram gets it wrong: the network is not a stage between control and display. It is a shared backbone that several nodes publish onto and read from, including nodes nobody in this catalogue supplies, such as the engine ECU or the ABS controller.

Power: from the battery post to a switched output

The power layer is the one that gets designed last and complained about first. Its job is unglamorous: move current from the battery to a load, protect it on the way, and do so without running heavy cable further than necessary. On a long vehicle that last constraint is what sets the layout, since copper is both expensive and heavy, and voltage drop over a 12-metre run is a design input rather than a rounding error.

A typical heavy-vehicle build has three stages. At the battery box, a main fuse module splits the feed into a handful of high-current branches: NBX-980 handles this at 9–36 VDC with MEGA and MIDI bolt-down fuses in the 30–200 A class, so one part number covers both 12 V and 24 V systems. Downstream, a central distribution box carries the many small circuits: NBX-957 is the body central box at 9–32 VDC and IP54, with an IP65 variant. Where the box has to live outside the cab, sealing rather than circuit count drives the choice, and NBX-971 is the IP67 build for chassis-rail exposure. Which of the three you actually need, and how much circuit headroom to leave, is worked through in the relay box versus fuse box versus junction box comparison.

Two cautions for the layout review. Position sets the sealing requirement more than function does, so specify the ingress class per box rather than per vehicle. And IP67 is an immersion test, not a licence for a pressure washer aimed at a connector face — if the cleaning regime involves a lance, say so, since that is a different question, answered on the IP65 / IP67 protection page.

Where does high voltage sit on an electric platform?

On a battery-electric truck or bus the traction pack is a separate domain that the low-voltage body electronics do not draw from directly. A DC-DC controller stands between them: EBX-2314 takes a 600 VDC nominal input over a 400–750 VDC range and produces the regulated 18–32 VDC auxiliary bus that the rest of this article assumes, rated 36 kW with on-board pre-charge control and UDS diagnostics. It also reserves a 10 kW high-voltage output for HV-side accessories such as heaters and compressors — the part buyers most often miss, since those loads never appear on the 24 V list at all. Pack-side protection is a separate discipline again: JDK-2509 is a DC 1500 V fuse in the aBat utilisation category of IEC 60269-7. The new-energy vehicle overview goes through the whole low-voltage stack by system.

Control: which box decides what

The control layer is where architectures diverge most, and where the word “controller” hides at least three different jobs. A body control module owns comfort, lighting, doors and the interlocks between them: EBX-954 is the 24 V heavy-truck example, 18–32 VDC with a 67-channel input bank, 45 driver channels split 26 high-side and 19 low-side, 3 × CAN plus LIN, and ISO 15765 diagnostics. A vehicle control unit supervises the powertrain instead: EBX-960 handles power-up and power-down sequencing, pedal parsing, torque arbitration and recuperation on a 7–48 VDC platform rated to +105 °C, because it rides where the heat is. EBX-960B is the variant that hosts the battery-management strategy on the same scheduler. A power management unit does neither: it switches and protects real current, with per-channel limiting and diagnostics.

Buyers most often conflate the first and the third, which is understandable, since both have connectors full of outputs. The distinction that matters commercially is whether the box carries load current or only decides. BCM versus VCU versus PMU works through the boundary in detail; the short version is that a PMU such as EBX-2050 puts 12 PWM channels, 17 digital inputs, 24 high-side outputs and an integrated 12-fuse / 4-relay bay behind one J1939 connection, while EBX-2052 takes the same idea to 2 × 50 A direct outputs at IP66 for a chassis position. Where the requirement is simply many protected circuits with intelligence over them, EBX-2160 carries 11 relays and 60+ fuses with UDS and J1939-73 diagnostics on a single assembly.

Below these sit the domain modules, and they are the ones that decide harness cost. A door module such as EBX-2163 or a lighting module such as EBX-2164 exists so that the twelve wires a door or a trailer lamp cluster would otherwise need never cross the vehicle. What crosses instead is a bus pair and a power feed sized for that zone — the copper does not disappear, it stops being one wire per function. The deeper treatment of each module type, including the dedicated guides for door, window and lighting control, sits in the Smart Control Modules technical guide.

Network: a backbone with several owners

Three things travel on a commercial vehicle network, and they have different tolerance for delay: control messages that must arrive on time, status that can be late, and diagnostics that only matter when a technician is plugged in. CAN carries most of it, J1939 defines what the messages mean on heavy-duty platforms, and LIN handles the slow local clusters where a full CAN drop would be overkill.

The architecture question is not which protocol, but how many segments and who separates them. A gateway becomes worthwhile when the segment count grows, when a segment has to carry CAN-FD traffic that older classical-only nodes cannot tolerate, or when the workshop needs one diagnostic entry point rather than four. EBX-2301 is the dedicated part for that role: 6 × CAN with two CAN-FD-capable channels, 3 × LIN and a K-Line diagnostic channel, with routing tables and filter masks set per the network-design specification. Telematics is a related but separate decision, since EBX-2054 reaches the outside world over 4G with GNSS and 2 × CAN at 250 kbps, and what it is allowed to see should be a curated message set rather than a raw powertrain segment.

Protocol depth belongs elsewhere: the Smart Control Modules guide covers CAN-FD, J1939 and UDS, and T-BOX telematics covers the uplink. What belongs in an architecture review is narrower — the segment map, the baud rate on each, who owns the gateway configuration, and which functions must keep working when the bus does not.

Which functions should stay off the network?

That last item is the one most worth arguing about early, and it is usually stated too simply. The requirement is not that every critical function must be hard-wired; it is that a critical function should not depend on a single network path. Which functions may be commanded over the bus at all is an output of the vehicle safety assessment, not a wiring preference. In practice the candidates that come out of that assessment are familiar — emergency stop, battery isolation, hazard lights, and the ground-level controls a technician uses during service — and each wants a device built for its own job rather than a switch borrowed from the dashboard. An emergency stop should be a dedicated latching cut-off, which is what JDK-2425 is — struck to actuate, rotated to release, rated 10 mA to 10 A at IP67, and on a heavier circuit breaking the control side of a contactor rather than the load itself. A battery main isolator is a different device again: the main feed far exceeds what any panel switch is rated to break, so a signal switch can at most drive the coil of an isolator. Routine off-bus switching is the third case and the one worth naming separately in a specification: auxiliary lamps, or a two-mode select a technician needs while the network is asleep, where a rugged sealed selector such as JDK-2201 at 15 A on 24 V and IP67 is the right class of part.

Driver interface: switches in, screens out

The top layer is the only one the operator ever perceives, and it is where the architecture decision has the most visible cost consequence. Every switch is either a wire to somewhere or a node on a bus, and the crossover point arrives sooner than most buyers expect.

A dashboard with a handful of functions is cheapest hard-wired. Somewhere around eight to twelve functions a multiplexed panel starts to win on harness alone, though where that crossover falls depends on your harness rather than on the switch count by itself: EDK-907 puts a full panel on one CAN pair at 18–32 VDC with a 24 V / 500 mA hard-wire backup channel and IP53, rated beyond 30,000 key cycles. Door clusters are a separate case, well served by LIN because the data rate is trivial and the wire count is not — EDK-914 is the 18–32 VDC window switch at 5 ± 1.5 N key force and over 50,000 cycles. CAN versus LIN versus hard-wired switches has the trade-off in full, including where hard-wiring remains the correct answer.

On the output side the cluster is the display a vehicle is least able to do without, because it carries the regulated telltales that have to reach the driver whatever else the dashboard is doing. That makes the format an architecture decision rather than a styling one: a combined cluster keeps those indicators on hardware independent of the main rendering pipeline, while a fully digital panel puts every indication behind one screen. Environment drives the rest of the spec — PBX-2301 is an 8-inch IPS cluster rated from −45 °C with built-in heating and a 5000 m altitude rating, on two CAN channels at 500 kbps with CAN-FD support. A head-up display is an addition rather than a replacement: PBX-961 projects a 15-inch virtual image at 2.4 m nominal on an 18–32 VDC supply. HUD versus digital cluster and the instrument cluster guide take those two choices further. Camera and mirror-replacement video is worth separating in the architecture, because it does not travel as bus content.

Two paths through the vehicle, and the three places they get cut

With the four layers in place, the architecture is easier to read as two overlapping paths rather than a stack. Current runs through its stages in a fixed physical order. Messages do not: a node publishes onto a shared pair and any other node reads it. Most specification arguments happen where those two paths cross a boundary that nobody wrote down.

Centralised or distributed — and what actually decides it

The recurring question in an architecture review is how much to put in one box. Both answers are defensible, and the honest version is that the decision follows the vehicle rather than a philosophy.

In practice most commercial programmes land in the middle: a central body controller for the functions that live near it, plus a small number of domain modules where distance or a body interface justifies them. What tips a specific function outward is rarely the electronics. It is the wire count, the mounting environment, and whether somebody else builds that part of the vehicle.

Who states what, layer by layer

The single most useful hour before an RFQ goes out is spent separating two things: the facts only your side can state, and the answers you are entitled to expect back. Mixing them is what produces a quote against the wrong architecture. One pair per layer covers it.

Everything else — connector families, sealing class, temperature range, approvals per destination market — follows from those four, which is why an architecture answer costs far less to change now than a tooling answer does later. The OEM RFQ checklist is the commercial counterpart to this list, covering volumes, timing and the template to send.

Vehicle type shapes all of this more than any general principle does. The same four layers resolve differently on a heavy truck, a bus or coach with its passenger-request layer, a construction machine with hydraulic outputs and wash-down exposure, and an agricultural platform with implement interfaces.

If you are scoping a platform rather than replacing a part, the useful next step is a specification call: bring the function list by zone, the intended segment map and the mounting positions, and we will come back with where the boundaries between boxes would sensibly fall. Use the contact page or message +86 134 6767 4786 on WhatsApp — typical reply within one business day.