Your cart is currently empty!
Automotive E/E Architecture & In-Vehicle Networks
A foundation module for facilitating DMADV programs at automotive Tier-1 suppliers like Yazaki. Covers the architectural map of a modern vehicle (distributed → domain → zonal), the in-vehicle networks that connect it, and the specific points where DFSS tools land hardest.
What’s in this module
- The “electrical chassis” — why architecture is the master variable
- Evolution: flat → distributed → domain → zonal
- The four real architectures, side-by-side
- In-vehicle networks: CAN, CAN-FD, LIN, FlexRay, Ethernet
- Signal integrity & the physical layer
- The 12 V / 48 V / HV power architecture
- Software-Defined Vehicles & OTA
- DFSS linkage — where architecture meets DMADV
- Instructor facilitation: how to engage each Yazaki function
- Self-check (10 questions)
1. The “electrical chassis” — why architecture is the master variable
The Electrical/Electronic (E/E) architecture of a vehicle is the master decision that, once made, constrains everything downstream: how many ECUs there are, how long the harness is, how many connectors are needed, what each box (PDU, BCM, gateway) does, which networks run where, and even what failures can occur and how they propagate.
Three things make architecture interesting for a DFSS instructor:
- It is decided by the OEM, not by Yazaki. The Tier-1’s job is to design optimised products given the architecture. So the architectural choice is a customer-given boundary condition in every DMADV project — and a frequent noise factor in P-diagram terms.
- It is changing fast. The industry is in the middle of a once-in-decades architectural shift from distributed to zonal. Tier-1s that don’t adapt their products will be left behind.
- It drives the CTQ tree. Customer requirements (weight, cost, reliability, OTA-updatability) flow into architecture choices, and architecture choices flow into the CTQs each Yazaki product must meet. Knowing this cascade is what makes QFD facilitation credible.
2. Evolution — flat → distributed → domain → zonal
E/E architecture has evolved through four broad eras, each driven by a particular technology pressure. A senior cohort will speak in terms of these eras casually. You should be able to follow.
| Era | Period | Defining feature | Driver |
|---|---|---|---|
| Flat / point-to-point | Pre-1980s | Every electrical device wired directly to switches and battery. No ECUs. | Mechanical-only vehicles; minimal electronics. |
| Distributed (function-based) | 1980s — 2010s | One ECU per function (ABS ECU, airbag ECU, BCM, ECM, TCM…). 60–150 ECUs. Connected by CAN, LIN. | Emissions regulations forced engine ECU; everything else followed. |
| Domain controllers | ~2015 — present | ECUs consolidated into 4–6 “domain” computers: powertrain, chassis, body, infotainment, ADAS, telematics. Connected by high-speed backbone (CAN-FD, FlexRay, Ethernet). | ADAS / infotainment compute needs; software complexity. |
| Zonal | ~2020 — emerging | 2–5 “zone controllers” placed by physical location (front-left, front-right, rear…) handle whatever loads/sensors are in that zone. A central HPC (High-Performance Computer) runs the vehicle’s “brain”. | SDV (Software-Defined Vehicle), OTA updates, EV weight reduction, manufacturing simplification. |
3. The four architectures side-by-side
| Aspect | Distributed | Domain | Zonal |
|---|---|---|---|
| Typical ECU count | 60–150 | 20–40 + 4–6 DCs | 5–10 (incl. zone & central) |
| Harness length | ~3 km, 50 kg+ | ~2 km, 35–45 kg | ~1 km or less, <30 kg |
| Backbone | CAN (low/high speed), LIN | CAN-FD, FlexRay, 100Base-T1 Ethernet | 1000Base-T1 (and beyond) Ethernet ring/star |
| Connectors (WH count) | Very high | High | Standardised, fewer |
| WH variants | Hundreds per platform | Tens to hundreds | Few (standardised zones) |
| PDU role | Single central fuse box dominant | Central fuse box + smart fuse boxes | Distributed smart PDUs at each zone (e-fuses) |
| Sensor data routing | Often direct to function ECU | To domain controller | To nearest zone → Ethernet → HPC |
| OTA capability | Very limited | Domain-level OTA | Full vehicle OTA (HPC + zones) |
| Tier-1 value share | High (ECU + harness) | Medium | Lower (commoditised hardware) — but recurring revenue via software |
- In distributed contexts, the design space is dominated by connector count, splice optimisation, branch routing, and fuse-box partitioning.
- In domain contexts, signal integrity over CAN-FD/Ethernet becomes a key CTQ; gateway latency matters.
- In zonal contexts, the harness becomes simpler but the zone controller becomes a tightly-integrated electromechanical product — exactly where Yazaki’s CDDC + EI capabilities converge.
4. In-vehicle networks — the protocols that bind it
You don’t need to teach networks to your participants — they live with them. You need enough literacy to follow when a participant says “the airbag is on a private CAN” or “we moved that signal from LIN to CAN-FD because of bit-rate” — and to spot when a network choice is the real root cause of a design issue rather than the symptom.
| Network | Speed | Physical layer | Typical use | What to listen for |
|---|---|---|---|---|
| LIN (Local Interconnect Network) | Up to 20 kbit/s | Single-wire, master-slave | Cheap actuator/sensor sub-nets: window switches, mirror motors, seat controls, sun sensor, rain sensor | “It’s just a LIN slave” → low-cost, master-driven, no arbitration |
| CAN (Controller Area Network) | 500 kbit/s (high-speed), 125 kbit/s (low-speed) | Twisted pair, differential | The workhorse — powertrain, body, ABS, airbag, instrument cluster | Almost universal; everything has at least one CAN bus |
| CAN-FD (Flexible Data-rate) | 2–8 Mbit/s in data phase | Twisted pair (same physical as CAN) | Drop-in upgrade for CAN — same wiring, longer/faster frames | Most new platforms now default to CAN-FD over classic CAN |
| FlexRay | 10 Mbit/s | Twisted pair, dual-channel | Premium European brands for x-by-wire and chassis safety functions | Largely being displaced by Automotive Ethernet, but still in Audi/BMW/MB lines |
| Automotive Ethernet (100Base-T1, 1000Base-T1, soon 10GBase-T1) | 100 Mbit/s → 10 Gbit/s | Single twisted pair (SPE) | Camera streams, ADAS sensor fusion, backbone in domain/zonal, infotainment | “This is on the Eth backbone” — high-bandwidth, time-sensitive networking (TSN) |
- CAN/CAN-FD: 120 Ω characteristic impedance twisted pair, terminations at bus ends, max stub length matters. Connector design must preserve impedance.
- Automotive Ethernet (100/1000Base-T1): Strict 100 Ω ±5 Ω impedance, return loss spec, max 15 m link, special “Mate-Q” / “H-MTD” style connectors. This is a place where ordinary automotive connectors will not work.
- LIN: Single-wire, less demanding — any standard automotive connector works.
- Shielded twisted pair (STP) vs. unshielded (UTP): driven by EMC environment.
You only need conceptual awareness here, but the words will come up:
- OBD-II: the regulatory diagnostic interface every vehicle must provide (emissions-related).
- UDS (ISO 14229): Unified Diagnostic Services — the language for ECU diagnostics, flash reprogramming, DTC (Diagnostic Trouble Code) read, etc.
- DoIP (Diagnostics over IP, ISO 13400): UDS over Ethernet — what you use when the in-vehicle backbone is Ethernet and you want fast reflashing or remote diagnostics.
For Yazaki: every ECU-bearing product (cluster, HUD, BMS, PDU, smart fuse box) must implement a UDS stack. The diagnostic interface is part of the customer-specific requirements (CSR) bundle in PPAP.
5. Signal integrity & the physical layer
This is where the architecture and network choice translates into actual wire/connector requirements. It is one of the highest-leverage areas for a DFSS instructor because robust-design and tolerance-design tools land directly here.
- Characteristic impedance (Z₀): a property of the cable/connector geometry. CAN = 120 Ω, Ethernet 100Base-T1 = 100 Ω. Mismatched impedance causes signal reflections.
- Return loss: how much signal is reflected back due to impedance discontinuities. Specified in dB. Connectors are often the worst discontinuity.
- Insertion loss: how much signal is attenuated by the cable + connector over distance. Sets max bus length.
- Crosstalk (NEXT, FEXT): coupling between adjacent pairs. Driven by twist rate, shielding, lay-up.
- Common-mode rejection ratio (CMRR): a twisted-pair’s ability to reject common-mode interference. Driven by twist quality and conductor symmetry.
- EMC margin: the difference between the device’s susceptibility level and the actual interference present. Negative margins → field failures.
6. The 12 V / 48 V / HV power architecture
E/E architecture is half about signals and half about power. Power architecture has its own evolution, parallel to the ECU evolution above.
| System | Voltage | Role | Implication for Yazaki products |
|---|---|---|---|
| 12 V LV | ~12 V DC nominal (9–16 V range) | Lighting, infotainment, ECUs, comfort loads. Universal. | Standard copper wire 0.13–6 sq mm; standard tin-plated terminals; PVC insulation. |
| 48 V “mild-hybrid” | ~48 V DC | BSG (Belt-Starter-Generator), e-superchargers, active suspension, electric pumps in mild hybrids. Tesla Cybertruck moved its entire LV bus to 48 V. | Smaller wire cross-section for same power → weight saving; but new connector/fusing range, and new safety considerations (still SELV-class, but higher arc-energy than 12 V). |
| HV traction | 400 V to 800 V DC | Battery → inverter → motor; OBC; fast-charging; e-compressor; PTC heater. | HV cables (XLPE/silicone insulation, semi-conductive layer); HV connectors with EMI shielding, HVIL, last-mate/first-break; orange jacketing. |
7. Software-Defined Vehicles & OTA
You won’t be facilitating software projects, but the term “SDV” will come up — especially with the EI team and the Senior General Manager whose stated role is end-to-end software/product lifecycle ownership. You should be able to discuss the concept without bluffing.
An SDV is a vehicle where features and behaviours are defined and updated primarily through software, decoupled from underlying hardware. The hardware ships once; the software evolves continuously.
Three pre-conditions make SDV possible:
- Centralised compute (zonal architecture with HPC) so software has a single place to live.
- OTA (Over-The-Air) update capability — vehicles must be addressable, secure, and bandwidth-capable.
- Hardware abstraction — software does not directly know which sensor model or actuator vendor is being used; HAL (Hardware Abstraction Layer) decouples them.
8. DFSS linkage — where architecture meets DMADV
This is the section that converts everything above into instructor leverage. For each DMADV phase, here is what architecture awareness lets you do that an uninformed instructor cannot.
| DMADV Phase | How architecture knowledge helps you facilitate |
|---|---|
| Define | Force participants to declare their architectural context (which OEM platform, what architecture era, voltage classes in scope). Spot when project scopes mix voltage classes or cross architectural boundaries without acknowledgement. |
| Measure | Help build the CTQ tree by asking “what does this architecture impose on your product?” — e.g., maximum harness length sets weight CTQ; backbone protocol sets EMC CTQ; OEM domain split sets connector-count CTQ. Ensure VOC translation reflects architectural reality. |
| Analyze | In concept selection (Pugh, TRIZ), ensure candidate concepts are compatible with the architectural envelope. A clever zone-controller integration is irrelevant if the OEM is committed to distributed architecture for that platform. |
| Design | In P-diagram noise factor identification, architecture-driven factors are often missed: bus-load variation, gateway latency jitter, voltage-drop along long harness runs, EMI from inverter/motor in HV systems. Prompt for these explicitly. |
| Verify | Validation matrix depends on architecture: a 100Base-T1 segment needs return-loss testing, a CAN bus does not. HV connectors need HVIL + dielectric testing every unit; LV connectors do not. Ensure DVP&R is right-sized to architecture. |
- Which OEM platform? Which architectural era (distributed / domain / zonal)?
- What voltage classes are in scope (12 V only? 48 V? HV?)
- What in-vehicle networks does your product touch?
- Is this product OTA-updatable, or hardware-fixed-at-PPAP?
- Who owns the integration — Yazaki, OEM, or shared?
9. Instructor facilitation — engaging each Yazaki function
A practical map of how each function in your roster relates to this module’s content. Use this to tailor your worked examples and your questions to each sub-group.
| Function (roster) | Architecture/network angle most relevant to them | A good question to ask them |
|---|---|---|
| WH (LV/HV) | Architecture directly drives harness length, branch count, connector count, voltage zones | “How does your current harness change if your customer moves from domain to zonal next platform?” |
| EI — AR HUD PM | HUD is one of the highest-bandwidth Ethernet consumers in the car (navigation + ADAS overlay data); often safety-related (warning rendering) | “What’s the worst-case end-to-end latency from ADAS detection to HUD pixel? Which network segment dominates it?” |
| EI — System Engineer Lead | System engineering is architecture thinking — they should be the most fluent in your room | “Walk us through how you decompose vehicle-level requirements into HUD-level requirements — that’s a CTQ cascade in QFD language.” |
| EI — Sensor / Mech HW Architect | Sensors are leaf nodes — their data has to traverse zone → backbone → consumer | “What’s the consequence if the zone gateway gets congested? Does your sensor have a deterministic latency budget?” |
| CDDC-LV (connectors, JB, fuse box, BMS, PDU, BFT) | Every architecture transition is a CDDC redesign — smart fuse boxes, e-fuses, integrated zone modules | “In a zonal architecture, your fuse box becomes part of the zone controller. How does that change your design boundary?” |
| Testing Center | Test methods depend on network types: continuity for LV, hi-pot for HV, return-loss for Ethernet | “Is your EOL test plan adapted for the next-gen automotive Ethernet harnesses?” |
| Shared Service — Advance Materials | Material trade-offs are architecture-driven (aluminium harness only makes sense for certain lengths) | “At what harness length does aluminium become a net-positive trade-off for you?” |
| Shared Service — Thermal/EMI/CFD | EMC environment differs hugely by architecture (HV inverters are worse than 12 V loads) | “What’s your worst-case EMC scenario — and is it bench-tested or simulated?” |
| SD Coordination / Project Mgmt | Architecture changes drive RFQ scope changes; managing customer change-orders is half the job | “How does your RFQ-to-delivery process change for a zonal-architecture customer vs. distributed?” |
| Innovation Cell / Technical Assistant | Future architectures are their natural language — they should help you push the cohort to think 5 years out | “What does SDV mean for Yazaki’s next product roadmap? Which products survive, which need reinvention?” |
| SGM — EI software/product lifecycle | Most senior person on the topic — likely already fluent. Treat as ally, not learner | “How are you thinking about the software-vs-hardware boundary as Yazaki moves up the stack?” |
Instructor self-check
Ten questions. These mirror the kind of phrasing your participants will use in the room. If you can answer all ten without hesitation, you’re ready to facilitate Module 1.
