ECU Consolidation Platform

Vehicle E/E architectures built on 70–150 separate ECUs — each supplied by a different Tier-1, running proprietary middleware, with point-to-point CAN or LIN wiring — have reached the ceiling of what they can support. Updating one control unit risks breaking adjacent systems. Over-the-air updates are impractical. The bill of materials for connectors and harnesses alone adds 15–25 kg to curb weight. For our OEM client, the status quo was no longer viable for their next generation flagship line.

Problem: Distributed-ECU Legacy Architecture

The flagship program carried forward an E/E topology that had grown organically over three vehicle generations. Domain boundaries were blurry: body control, HVAC, lighting, and seat adjustment were handled by separate microcontrollers that communicated via CAN matrices with over 3 000 signal definitions. Software updates required coordinated releases across 11 suppliers. Integration tests consumed six weeks per release cycle.

• 114 discrete ECUs across the full vehicle
• No vehicle-level software ownership — validation was supplier-by-supplier
• OTA update impossible without multi-supplier coordination
• Harness weight: 47 kg — 12% over target for the new platform

Approach: Domain-Centered Consolidation on AUTOSAR Adaptive

MobilityCortex developed a domain-centered target architecture built around five high-performance domain controllers (Powertrain, Chassis, Body & Comfort, ADAS/Gateway, HMI). Each domain controller runs AUTOSAR Adaptive Platform on an Arm Cortex-A72 SoC, replacing a cluster of legacy QM/ASIL-B microcontrollers. Ethernet backbone (100BASE-T1, 1000BASE-T1) replaces point-to-point CAN for inter-domain traffic; CAN FD is retained for in-domain sensor/actuator communication where latency and cost profiles demand it.

The migration strategy followed a three-phase approach: first, signal consolidation — mapping all existing CAN signals to a unified VSS-aligned data model; second, functional clustering — grouping software components by domain affinity with explicit AUTOSAR port interfaces; third, hardware rationalization — replacing legacy ECUs with domain controllers over two model-year increments, maintaining backward compatibility via gateway translation layers.

Software Architecture

AUTOSAR Adaptive Runtime

All domain controller applications run as AUTOSAR Adaptive SWCs communicating via ara::com service-oriented communication. Safety-relevant functions (e.g., immobilizer, brake light control) are encapsulated in dedicated ASIL-B partitions with memory protection using AUTOSAR Classic coexistence on a secondary lockstep core.

OTA Update Architecture

A central Software Update Manager (SUM) orchestrates differential OTA campaigns across all domain controllers via a secure update agent. Campaign scheduling, rollback capabilities, and cryptographic verification (UPTANE-derived) ensure functional safety during field updates — a first for this vehicle line.

Diagnostic Integration

Unified Diagnostic Services (UDS, ISO 14229) are routed through the gateway domain controller. All service routines and DTC definitions were migrated to an ODX/PDX-compliant data model, enabling end-to-end workshop toolchain compatibility from day one.

Results

Technology Stack

• AUTOSAR Adaptive Platform (VRTE-based) + AUTOSAR Classic for ASIL-B partitions
• Ethernet backbone: 100BASE-T1 / 1000BASE-T1 per IEEE 802.3bw / 802.3bp
• Arm Cortex-A72 + Cortex-R5 lockstep SoC (NXP S32G2)
• SOME/IP service discovery, DDS for high-throughput sensor streams
• HSM-backed secure boot, EVITA Full key management
• Vector DaVinci Architect / Developer for AUTOSAR configuration

Interested in this capability?