EV Platform & Architecture
A modern EV platform is a cyber-physical system: energy storage, power electronics, thermal loops, sensors, networks, compute, and the software layers that coordinate them. In a software-defined vehicle (SDV), the platform becomes a programmable substrate where control, diagnostics, autonomy, and over-the-air (OTA) updates run across a unified architecture. In practice, SDV adds centralized compute, zonal controllers, a vehicle operating system (OS), secure OTA, and structured telemetry so functions can improve continuously after start of production (SOP).
The vehicle platform is sometimes confused with other similar-sounding architectures:
| Term | What it is | Primary scope | What it predicts best |
|---|---|---|---|
| Vehicle Platform Architecture | Shared physical and powertrain foundation: pack integration, HV topology, thermal strategy, packaging hard points | Mechanical + HV + thermal + packaging | Charging sustain, efficiency, serviceability, cost structure, variant speed |
| E/E Architecture | How low-voltage (LV) controllers and networks are organized (distributed ECU vs domain vs zonal + central compute) | LV control, networks, compute placement, wiring topology | OTA scope, diagnostics, feature velocity, wiring mass, cybersecurity surface |
| ADAS/Autonomy Architecture | Sensors, compute, redundancy, and software pipeline for driver assist / autonomy | Perception, planning, compute, safety concepts | Capability ceiling, sensor upgradeability, data pipeline needs, compute thermal headroom |
Platform class
These classes are common used.
| Platform class | Definition | Typical strengths | Typical constraints |
|---|---|---|---|
| EV-native | Designed around EV packaging and drivetrain from day one | Packaging efficiency, thermal integration, variant speed | Higher upfront engineering cost; needs scale to amortize |
| Shared | Supports ICE/hybrid/EV variants on a shared base | Lower capex, faster EV entry for legacy OEMs | Packaging and cooling compromises; often limited HV/thermal headroom |
| Commercial/upfit-first | Designed for fleet duty cycles with modular bodies and upfit compatibility | Serviceability, predictable depot behavior, upfit ecosystem | May trade aero and mass optimization for modularity |
| Software-centric | Designed for central compute + zonal from the start, with broad OTA domains | Feature velocity, diagnostics depth, fleet iteration speed | Requires strong software governance and cybersecurity maturity |
Platform defines vehicle behavior
Two EVs with similar batteries can behave very differently on the road or at a charger because the platform defines the constraint set the vehicle must operate within. This becomes most visible during DC fast charging, sustained highway driving, cold-weather operation, and repeated high-load use.
- Charging curve shape and sustain
Peak charging power is momentary. Platform-level thermal design, current limits, and pack architecture determine how long high power can be sustained and how aggressively power is tapered. - Repeatable fast-charging performance
Cooling loop design, chiller capacity, and pack thermal mass determine whether a vehicle can fast-charge repeatedly without steep derating. - Real-world efficiency vs rated range
Drivetrain integration, inverter design, thermal losses, and auxiliary load management often dominate real-world efficiency more than battery size alone. - Cold-weather behavior
Heat pump architecture, coolant routing, and software-controlled thermal prioritization determine winter range loss and charging reliability. - Sustained power and highway behavior
Motor cooling, inverter thermal limits, and voltage class affect how well a vehicle maintains power at speed or under load. - Software update and feature expansion ceiling
Wiring topology, controller consolidation, and compute placement define what can realistically be updated or added over the vehicle’s lifetime.
In short:
Specs tell you what the vehicle can do once.
Platform tells you what the vehicle can do repeatedly, reliably, and in the future.
Core platform elements (physical layer)
These determine the real-world behavior users notice (charging repeatability, efficiency, winter performance, long-term service cost).
| Element | What it includes | Primary impacts |
|---|---|---|
| High-voltage topology | 400 V vs 800 V class, bus design, HV distribution, contactors, DC/DC, onboard charger (OBC) | Charge power potential, cable mass, inverter design, thermal loads |
| Battery pack integration | Module-to-pack vs cell-to-pack, structural pack, crash structure, sealing, service access | Mass, stiffness, safety, repairability, lifecycle cost |
| Thermal architecture | Coolant loops, heat pump, chiller strategy, pack and power-electronics cooling | Charging sustain, cold-weather range, repeatable performance |
| Drivetrain + power electronics | Motor type, inverter topology, silicon vs SiC (silicon carbide) devices, gearbox integration | Efficiency, torque response, sustained power, thermal headroom |
Core SDV elements (software-defined layer)
These determine feature velocity, diagnostics depth, OTA scope, and the vehicle’s ability to evolve.
| # | SDV element | What it does | Why it matters |
|---|---|---|---|
| 1 | Central vehicle compute | Runs multi-domain workloads (powertrain, body, energy, ADAS) on consolidated compute with accelerators (GPU/NPU/DSP) | Enables consolidation, higher capability, and faster iteration across domains |
| 2 | Zonal vehicle architecture | Zonal controllers aggregate IO (inputs/outputs) by physical location; central compute coordinates vehicle-wide behavior | Reduces wiring, improves serviceability, increases OTA granularity |
| 3 | Vehicle operating system | Hardware abstractions, scheduling, partitioning between safety-critical and non-critical domains; supports services/containers where used | Standardizes interfaces and enables consistent update/rollback behavior |
| 4 | In-vehicle networks | CAN/CAN-FD, LIN, automotive Ethernet; optionally TSN (time-sensitive networking) for deterministic traffic | Bandwidth and determinism constraints shape ADAS, diagnostics, and zonal behavior |
| 5 | Energy & thermal software | BMS (battery management system) estimation (SOC/SOH), cell balancing, thermal orchestration across pack, inverter, motor, cabin | Charging sustain, winter behavior, degradation management, predictable road trips |
| 6 | Powertrain control software | Torque delivery, traction control, regen blending, motor control (FOC), HV fault detection and isolation | Efficiency and drivability; stability and safety under faults |
| 7 | Perception & sensor fusion context | Sensor synchronization, calibration, and fusion pipelines feeding ADAS/autonomy compute | Capability ceiling and robustness to degraded sensors |
| 8 | Autonomy compute stack | On-vehicle inference for perception/prediction/planning; health monitoring for latency and quality of service | Determines ADAS/autonomy ceiling and upgrade path constraints |
| 9 | Vehicle OTA architecture | Secure boot, signed images, staged updates, delta updates (when supported), rollback paths, campaign telemetry | Security, reliability, and feature velocity across the fleet |
| 10 | Safety + redundancy + fail-operational | Redundant compute paths, independent power domains where needed, safety concept alignment (e.g., ISO 26262) | Defines what remains safe under partial failures and during updates |
