DFSS Instructor Prep · Module 1 Layer B — Engineering Substance

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.

Why this module exists
Every Yazaki product — wiring harness, AR HUD, BMS, PDU, connector — is shaped by the vehicle’s E/E architecture choice. When a participant says “our harness goes into a zonal architecture” or “this is a CAN-FD signal”, you should not blink. This module gives you working literacy in the architectural and network vocabulary your participants live inside, plus the DFSS hooks (CTQ cascade, P-diagram noise factors, tolerance flow-down) that depend on understanding it.

What’s in this module

  1. The “electrical chassis” — why architecture is the master variable
  2. Evolution: flat → distributed → domain → zonal
  3. The four real architectures, side-by-side
  4. In-vehicle networks: CAN, CAN-FD, LIN, FlexRay, Ethernet
  5. Signal integrity & the physical layer
  6. The 12 V / 48 V / HV power architecture
  7. Software-Defined Vehicles & OTA
  8. DFSS linkage — where architecture meets DMADV
  9. Instructor facilitation: how to engage each Yazaki function
  10. 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:

  1. 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.
  2. 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.
  3. 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.
Headline numbers to keep in your back pocket
A modern premium vehicle has historically contained 60 to over 100 ECUs and 1.5 to 2 miles of wiring (40 to 50 kg of harness). Tesla Model 3, Rivian R1 Gen-2, and BMW Neue Klasse have cut this dramatically. Rivian R1 Gen-2 reduced ECUs from 17 to 7 and removed 1.6 miles of wiring. BMW reports a 30% wiring weight reduction and a 3000× variant reduction in its zonal harness.
100+
ECUs in a legacy premium car
7
ECUs in Rivian R1 Gen-2
1.6 mi
Wiring removed by Rivian Gen-2
30%
BMW Neue Klasse harness weight cut

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.

2.1   The four eras +
EraPeriodDefining featureDriver
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.
A nuance to teach to senior people
The shift to zonal is not just about wiring. It is the technological pivot that enables Software-Defined Vehicles, OTA updates, and the wresting of integration ownership from Tier-1s back to the OEM. The wiring savings (~40–60%) and weight savings (~20 kg+) are the visible part. The strategic shift is that the OEM owns the central compute and the software stack; the Tier-1 supplies dumber, more standardised electromechanical zones.
India context
Indian OEMs (Tata, Mahindra, M&M) are mostly in the distributed-to-domain transition. Premium Indian EV programs (Mahindra BE 6, XEV 9e) sit closer to domain architecture. Pure zonal in India is rare today but is the visible direction of travel. Yazaki’s product mix and DMADV projects will reflect this transition — so you’ll see all four eras represented in participant projects.
2.2   Visualising the four eras +
Distributed architecture — “every function its own ECU”
Engine ECU ABS ECU Airbag ECU BCM HVAC Infotain Cluster Door L Door R Seat ECU Park asst Lighting TPMS Wiper 14 ECUs (illustrative) · Long, heavy harness · Each ECU a Tier-1 deliverable Real distributed cars carry 60–150 ECUs in this style
Domain architecture — function clusters with high-speed backbone
Powertrain DC Chassis DC Body DC Infotain DC ADAS / Central GW Backbone (Eth/CAN-FD) 4–6 Domain Controllers · Smaller leaf-ECUs still exist · Backbone is Ethernet/CAN-FD
Zonal architecture — physical zones, central compute
Central HPC (software-defined “brain”) Zone FL Zone FR Zone RL Zone RR Few powerful ECUs · Local loads served by nearest zone · Short harness, mostly Ethernet Tesla Model 3 / Y · Rivian R1 Gen-2 (7 ECUs) · BMW Neue Klasse · VW SSP (in development)

3. The four architectures side-by-side

3.1   What changes for Yazaki’s three product families? +
AspectDistributedDomainZonal
Typical ECU count60–15020–40 + 4–6 DCs5–10 (incl. zone & central)
Harness length~3 km, 50 kg+~2 km, 35–45 kg~1 km or less, <30 kg
BackboneCAN (low/high speed), LINCAN-FD, FlexRay, 100Base-T1 Ethernet1000Base-T1 (and beyond) Ethernet ring/star
Connectors (WH count)Very highHighStandardised, fewer
WH variantsHundreds per platformTens to hundredsFew (standardised zones)
PDU roleSingle central fuse box dominantCentral fuse box + smart fuse boxesDistributed smart PDUs at each zone (e-fuses)
Sensor data routingOften direct to function ECUTo domain controllerTo nearest zone → Ethernet → HPC
OTA capabilityVery limitedDomain-level OTAFull vehicle OTA (HPC + zones)
Tier-1 value shareHigh (ECU + harness)MediumLower (commoditised hardware) — but recurring revenue via software
Instructor framing for DMADV projects
When a Yazaki participant brings a DMADV project, the architecture context determines what’s even on the table:
  • 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.
Knowing this lets you ask the right “what is your architectural assumption?” question early in Define and avoid weeks of misaligned work.

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.

4.1   The five networks you must recognise +
NetworkSpeedPhysical layerTypical useWhat 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)
A practical “why does this matter for harness/connectors?” view
Each network has different physical-layer requirements that directly drive Yazaki’s product design:
  • 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.
Instructor talking point
When a participant working on a wiring-harness DMADV project mentions a network upgrade (e.g., “we’re moving CAN to CAN-FD”), the follow-up question you can credibly ask is: “Does that change your connector or terminal spec? What’s the return-loss requirement on the segment?” This single question signals that you understand the harness-network coupling.
4.2   Diagnostic protocols — UDS, DoIP, OBD-II +

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.

5.1   Concepts you must be able to use +
  • 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.
DFSS hook
Every one of these concepts is a candidate CTQ (Critical-to-Quality) in a network-carrying harness’s QFD. Variation in twist rate, lay length, terminal compaction, shield coverage are all process noise factors in a P-diagram. Tolerance design (statistical or worst-case) on these parameters is a natural DMADV exercise — and the kind of problem most participants will not have thought of in those terms.

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.

6.1   Three voltage worlds, increasingly co-existing +
SystemVoltageRoleImplication 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 DCBSG (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 traction400 V to 800 V DCBattery → 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.
A growing reality: the “two-net” or “three-net” car
A modern BEV typically has all three voltage systems coexisting: HV traction, 48 V auxiliary (some platforms), and 12 V LV for legacy loads. The DC-DC converter steps HV down to 12 V/48 V. A Yazaki harness/connector designer must understand which voltage domain each circuit lives in — they have completely different wire, connector, validation, and safety requirements.
Instructor talking point
A standard mistake in DMADV scoping is mixing voltage classes in the same project boundary. If a participant says “we’re going to optimise the wiring layout in the front of the EV”, ask: “Are you including the HV cabling to the e-compressor, or just LV body wiring?” Forcing this clarity in Define avoids huge downstream confusion.

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.

7.1   What “SDV” actually means in practice +

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:

  1. Centralised compute (zonal architecture with HPC) so software has a single place to live.
  2. OTA (Over-The-Air) update capability — vehicles must be addressable, secure, and bandwidth-capable.
  3. Hardware abstraction — software does not directly know which sensor model or actuator vendor is being used; HAL (Hardware Abstraction Layer) decouples them.
Why a Tier-1 should care
In an SDV world, OEMs increasingly want to own the software stack themselves and treat the Tier-1 hardware as standardised commodities they can second-source. This is exactly why the VW-Rivian partnership exists — VW is paying $5.8 billion for Rivian’s zonal hardware + architecture so it can build SDVs faster. Yazaki’s strategic response is to move up into integrated electromechanical zone modules (which combine harness, connectors, fuse box, power electronics, sensors, and zone controller into one delivered assembly), rather than supplying loose components. This is real, current, and your senior participants are thinking about it.

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.

8.1   The DMADV–architecture mapping +
DMADV PhaseHow 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.
A “must-ask” question template for early Define
When any DMADV project kicks off in your room, ask these five architectural-context questions and write the answers on a flip-chart visible all 9 days:
  1. Which OEM platform? Which architectural era (distributed / domain / zonal)?
  2. What voltage classes are in scope (12 V only? 48 V? HV?)
  3. What in-vehicle networks does your product touch?
  4. Is this product OTA-updatable, or hardware-fixed-at-PPAP?
  5. Who owns the integration — Yazaki, OEM, or shared?
These five answers anchor every downstream design decision. If a project cannot answer them, the project isn’t ready for DMADV — and you’ve just done your most valuable facilitation of the day.

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.

9.1   Engagement map by function +
Function (roster)Architecture/network angle most relevant to themA 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.

Q1. A participant says: “Our customer is moving from a domain to a zonal architecture next platform.” What is the single biggest implication for Yazaki’s wiring-harness business?
A. Higher copper consumption
B. More LIN-based actuator nets
C. Significantly shorter total harness length, fewer variants, more standardisation
D. Move from PVC to silicone insulation
Correct — zonal architectures cut wiring by ~40–60% (Rivian removed 1.6 miles, BMW reports 30% weight cut and 3000× variant reduction). This restructures the WH business model.
Q2. The single most common in-vehicle network across all vehicle eras is:
A. FlexRay
B. CAN (Controller Area Network)
C. Automotive Ethernet
D. MOST
Correct — CAN (and increasingly CAN-FD) is essentially universal. Every modern vehicle has at least one CAN bus.
Q3. Why does Automotive Ethernet (100/1000Base-T1) require special connectors and tighter harness construction tolerances?
A. Higher voltage
B. Higher current
C. Different colour coding
D. Strict 100 Ω impedance and return-loss requirements at GHz frequencies
Correct — at automotive-Ethernet data rates, every impedance discontinuity creates reflection. Connectors and twisted-pair quality become signal-integrity critical.
Q4. In a typical legacy distributed E/E architecture, the approximate number of ECUs is:
A. 5 to 10
B. 60 to 150
C. 500 to 1000
D. Same as a Tesla Model 3
Correct — premium legacy cars often exceed 100 ECUs. Zonal architectures are reducing this to under 10.
Q5. A 48 V mild-hybrid bus is attractive because:
A. For the same power, you can use thinner copper — saving harness weight and cost
B. It eliminates the need for any HV system
C. It is regulated as ELV (extra-low voltage) so no shielding is needed
D. It uses the same connectors as 12 V
Correct — power = V × I, so quadrupling voltage at constant power cuts current by 4× and cross-section roughly proportionally. Big weight saving for high-power auxiliary loads.
Q6. In a P-diagram for a wiring-harness signal-integrity DMADV project, “EMI from the traction inverter” is most accurately classified as a:
A. Control factor
B. Signal factor
C. Noise factor (external environment)
D. Response variable
Correct — EMI from the inverter is environmental noise the harness must be robust against. Shielding, twist, ground partitioning are the control factors that make it robust.
Q7. The “central HPC” in a zonal architecture serves which primary function?
A. Power conversion
B. Hosts the vehicle’s software stack and orchestrates the zones
C. Battery thermal management
D. The main fuse panel
Correct — the HPC is where the vehicle’s software-defined behaviour lives. Zone controllers handle the local electromechanical interface.
Q8. A participant brings an AR-HUD DMADV project. Which “Define” question would best surface the architectural context?
A. What is the brightness target?
B. What is the unit cost target?
C. What is the optical FoV?
D. Which network delivers ADAS data to the HUD, and what’s the end-to-end latency budget?
Correct — the others are product-internal CTQs; only D forces the architectural context (network type, gateway path, latency budget) into the project frame.
Q9. Why are OEMs (e.g., VW paying Rivian $5.8B) racing toward zonal architectures, beyond just wiring savings?
A. Better radio reception
B. Higher peak torque
C. It is the prerequisite for software-defined vehicles, OTA updates, and OEM control of the software stack
D. To eliminate fuses entirely
Correct — the strategic prize is software control, OTA monetisation and reduced dependency on Tier-1 ECUs. Wiring savings are the visible benefit; software ownership is the strategic one.
Q10. As a DFSS instructor, the most valuable architectural question to plant on the wall for ALL 9 days of the program is:
A. “Which OEM platform, what era, what voltage classes, what networks?”
B. “What is your unit cost target?”
C. “How long is your harness?”
D. “Is your supplier ISO 9001 certified?”
Correct — A is the architectural anchor for every downstream DMADV decision. Without it, projects drift; with it, every choice has context.