The problem
Vehicle makers are moving from many domain ECUs with long point-to-point harnesses to a few zonal controllers linked to central computers. The claimed gains in wiring, weight and software updates come with costs: added network hops, gateway latency and concentrated compute. Published comparisons are often qualitative. This project builds a transparent, reproducible model to quantify the trade-offs for a defined vehicle.
Objectives
- Define a reference vehicle with component locations, signal list and timing requirements.
- Model wiring topology and estimate length and mass for domain and zonal architectures.
- Model end-to-end latency on CAN, CAN FD and Ethernet paths including gateway hops.
- Estimate compute load on domain ECUs, zonal controllers and the central computer.
- Run sensitivity and optimisation studies on zone count and placement.
What you need
Tools and toolboxes
- MATLAB — Builds the parametric model, runs sweeps and produces plots.
- Optimization Toolbox or Global Optimization Toolbox — Optimises zone count and placement against wiring and latency objectives.
- Python with NetworkX and pandas — Represents topologies as graphs and computes path lengths and hop counts.
- OMNeT++ — Simulates selected Ethernet paths to check the analytical latency estimates.
- Simulink — Optionally simulates timing of critical ADAS control chains end to end.
Software
- MATLAB with Optimization Toolbox
- Python with NetworkX and pandas
- OMNeT++ with INET
- A spreadsheet for input data
Extra parts and data
None beyond the software above.
Key concepts
- Domain architecture
- ECUs grouped by function domain (powertrain, chassis, body, ADAS), each wired directly to its sensors and actuators wherever they are in the vehicle.
- Zonal architecture
- Zonal controllers placed by physical region connect nearby sensors and actuators and forward data over Ethernet to central computers that run most functions.
- Harness mass model
- An estimate of wire length and mass from routed distances, conductor cross-sections and connector counts, used to compare topologies.
- End-to-end latency chain
- The sum of sensor sampling, transmission, gateway or switch delays, computation and actuation for a function such as emergency braking.
Step-by-step guide
- 1
Define the reference vehicle
Choose a mid-size electric car and define its body coordinate frame. List around 120 components: cameras, radars, ultrasonic sensors, lamps, door modules, seat modules, brake and steering actuators, battery management and charging units. Give each an approximate position, power need and its signals with sizes and periods. Base values on public technical descriptions and engineering judgement, and record every assumption in a table so others can change it.
Checkpoint: A component and signal table with positions, rates and documented assumptions.
- 2
Define functions and timing requirements
Select key functions and their chains: automatic emergency braking, lane keeping, adaptive cruise, parking assistance, door locking and lighting. For each, list the sensors, compute location and actuators involved, and set an end-to-end latency budget. Mark which chains are safety-related, since they constrain where processing may sit and how many hops are acceptable. Draw each chain as a block diagram so the path through the network is easy to follow.
Checkpoint: A function table with chains, latency budgets and safety relevance.
- 3
Model the domain architecture
Place domain ECUs at plausible locations and connect each component directly to its ECU along a routing grid that follows the vehicle's main harness channels. Compute routed wire lengths with shortest paths on the grid in NetworkX. Connect ECUs with CAN, CAN FD and an Ethernet backbone as appropriate. Estimate wire mass from lengths, cross-sections and connector counts. Store the routing grid and component positions in files so both architectures use the same geometry.
Checkpoint: A domain topology graph with total wire length, mass and connector count.
- 4
Model the zonal architecture
Define zones (start with four: front-left, front-right, rear-left, rear-right) each with a zonal controller, plus a central computer. Connect components to the nearest zonal controller and zonal controllers to the central computer with Ethernet, in a ring or star. Recompute wiring length and mass. Assign which functions run centrally and which stay in zonal controllers for latency or safety reasons.
Checkpoint: A zonal topology graph with wiring results and a function-to-compute allocation.
- 5
Build the latency model
For each function chain and architecture, sum sampling delay, serialisation time per link from frame size and bit rate, worst-case queuing using a simple priority analysis for CAN and an upper-bound estimate for Ethernet switches, gateway processing delay and computation time. Treat uncertain values as ranges, not single numbers. Compare each chain with its budget. Keep a log of the data sources behind each assumed delay value.
Checkpoint: A table of best- and worst-case latency per chain for both architectures against budgets.
- 6
Check latency with simulation
Model two critical chains in OMNeT++ with INET: a front camera and radar to central computer to brake request path in the zonal case, and the equivalent domain path. Load the network with background traffic from the signal list. Compare simulated latency distributions with the analytical bounds; analytical worst cases should sit above the simulated maxima. Explain any violation. Record the background traffic settings so the simulation can be rerun with other loads.
Checkpoint: Simulated latency distributions that lie within the analytical bounds, or documented reasons where they do not.
- 7
Estimate compute load
Assign a compute cost to each function in operations per second, based on published benchmarks for similar algorithms, as ranges. Sum load per ECU in the domain case and per zonal controller and central computer in the zonal case. Identify where load concentrates and what redundancy the central computer would need for safety-related functions, which adds cost. Mark which functions are safety-related, since they constrain where compute can be merged.
Checkpoint: Compute load per node for both architectures with ranges and a redundancy note.
- 8
Sensitivity analysis
Sweep the number of zones from two to eight, Ethernet link speed, gateway delay and component positions. Use a one-at-a-time sweep and then a variance-based sensitivity method to see which inputs drive wiring mass and latency most. Plot results so the reader sees, for example, at what gateway delay the zonal AEB chain fails its budget. Keep the sweep scripts parameterised so new vehicle sizes can be tested without code changes.
Checkpoint: Sensitivity plots and a ranked list of the inputs that most affect each output.
- 9
Optimise zone placement
Formulate an optimisation that chooses zone controller positions and component assignments to minimise wiring mass subject to all latency budgets and a cap on components per zone. Solve with a genetic algorithm or mixed-integer formulation in MATLAB. Compare the optimum with the intuitive four-corner layout and report the gain and any change in latency margins. Record solver settings and run time so the optimisation can be reproduced.
Checkpoint: An optimised layout with wiring and latency results compared with the four-corner baseline.
- 10
Validate assumptions and write up
Check model outputs against any publicly reported harness lengths or masses for comparable vehicles, stating clearly where data is unavailable. Write the thesis chapters: reference vehicle, models, latency check, compute study, sensitivity and optimisation, with all inputs and code released. Discuss the limits of a parametric model: routing simplifications, generic compute costs and no cost model for parts. Invite a reviewer to change one input table and rerun the model as a reproducibility check.
Checkpoint: A thesis draft with released model, input tables and a clear limitations section.
Testing & validation
- Wiring length and mass for both architectures from routed paths.
- Analytical latency bounds checked against OMNeT++ simulation.
- Compute load per node with ranges.
- Sensitivity rankings and optimised zone layouts.
Expected results
A transparent parametric model comparing domain and zonal E/E architectures for wiring, latency and compute, with simulation checks, sensitivity results and an optimised zone layout.
Research angle for your PhD
Research questions: under what vehicle sizes, zone counts and network parameters does a zonal architecture reduce wiring mass without violating safety-relevant latency budgets, and which inputs dominate the outcome? Metrics: wiring length and mass, connector count, worst-case chain latency margin and peak compute load. Contribution: an open, parametric and sensitivity-analysed model, checked against network simulation, in a field where comparisons are mostly qualitative. Released models and input data make the study reproducible and suitable for journal publication.
Take it further
- Add part cost and assembly time to the objective.
- Model power distribution through zonal controllers with smart fuses.
- Add redundancy paths for fail-operational functions and recompute wiring.
- Model the effect of over-the-air update scope on software update time.
Viva and review questions
Where does a zonal architecture save wiring?
Components connect to a nearby zonal controller instead of a distant domain ECU, so long individual wires are replaced by short local wires plus a few Ethernet links.
What does it cost in latency?
Signals pass through zonal controllers and switches to a central computer, adding hops and processing delay that must fit within each function's budget.
Why did you use ranges for compute costs?
Real costs depend on algorithms and hardware not fixed at this stage, so ranges show whether conclusions hold across plausible values.
Why check the analytical model with OMNeT++?
The analytical worst-case bounds rely on simplifications, so simulation with realistic traffic checks that observed latencies stay within them.
Learn it at DIYguru
These DIYguru courses and programmes teach what this project needs.