Classic + Adaptive Coexistence

Advanced11 min read

Assumes: 4.2 Classic Platform, 4.3 Adaptive Platform

TL;DR

Modern vehicles run both AUTOSAR flavors simultaneously. Classic ECUs on CAN/FlexRay broadcast signals; your Adaptive HPC (Qualcomm + QNX/AAOS) consumes and provides services over Ethernet/SOME/IP. A central gateway, often itself a Classic ECU with Ethernet, translates between worlds. E2E (End-to-End) protection guards data integrity across the boundary. Signal-to-service transformers map VehicleSpeed frames to VehicleSpeedService events. This isn’t a migration in progress. It’s the stable architecture for the next decade.

No OEM ships a “pure Adaptive” vehicle today. Understanding coexistence explains why vehicle data takes a winding path from an ABS ECU to your AAOS VHAL, and where things break. Spoiler: most of the fun is in the gateway translation layer, where signals turn into services and vice versa.

Common Gotcha

If vehicle speed is in the DBC but missing in AAOS, the bug is almost never in Android itself.

The DBC describes the Classic CAN world. AAOS reads VHAL properties backed by Adaptive services. Trace the full chain: CAN signal → gateway transform → SOME/IP event → QNX service → VHAL → AAOS. The break is usually in the gateway or service offer.

Common Gotcha

Beginner thinks Classic and Adaptive are a migration — eventually all ECUs become Adaptive and Classic disappears.

Reality: coexistence is the stable architecture for the next decade. Powertrain, body, and chassis MCUs will stay Classic. The cockpit HPC runs Adaptive. The gateway translates between them — neither platform replaces the other.

One Vehicle, Two Platforms

Vehicle Zone	Platform	Compute	Communication
Powertrain, body, chassis	Classic	MCU ECUs (AURIX, RH850)	CAN / LIN / FlexRay signals
Central gateway	Classic (+ Ethernet)	High-end MCU or early S32G	Signal routing + protocol translation
Cockpit / ADAS domain	Adaptive	HPC SoC (Qualcomm, NVIDIA)	SOME/IP services over Ethernet
Telematics	Mixed	Modem + application processor	Services + signal passthrough

The cockpit SoC didn’t replace every ECU. It consolidated infotainment and aggregated vehicle data while 40–80 Classic ECUs continue doing their jobs.

Classic controls the car; Adaptive aggregates and presents.

Architecture: Classic ECUs + Adaptive HPC + Gateway

flowchart TB
    subgraph ClassicZone["Classic Domain (CAN / LIN / FlexRay)"]
        ABS["ABS ECU<br/>Classic · WheelSpeed signal"]
        ECM["Engine ECU<br/>Classic · EngineSpeed signal"]
        BODY["Body ECU<br/>Classic · DoorAjar signals"]
        HVAC["HVAC ECU<br/>Classic · TempSetpoint signal"]
    end

    subgraph Gateway["Central Gateway ECU"]
        GW_COM["Classic COM Stack<br/>Signal RX/TX on CAN"]
        GW_XFORM["Signal-to-Service<br/>Transformer"]
        GW_E2E["E2E Protection<br/>Profile 1 / 4 / 7"]
        GW_SOMEIP["SOME/IP Stack<br/>Service provider/consumer"]
    end

    subgraph AdaptiveZone["Adaptive Domain (Ethernet)"]
        subgraph SoC["Qualcomm Cockpit SoC"]
            QNX["QNX VM<br/>Adaptive services"]
            AAOS["AAOS VM<br/>VHAL · Apps"]
            VEH_SVC["VehicleDataService<br/>ara::com consumer"]
        end
        ADAS["ADAS ECU<br/>Adaptive services"]
    end

    ABS -->|"CAN: WheelSpeed"| GW_COM
    ECM -->|"CAN: EngineSpeed"| GW_COM
    BODY -->|"CAN: DoorAjar"| GW_COM
    HVAC -->|"CAN: DoorAjar"| GW_COM

    GW_COM --> GW_XFORM
    GW_XFORM --> GW_E2E
    GW_E2E --> GW_SOMEIP

    GW_SOMEIP <-->|"Ethernet SOME/IP"| VEH_SVC
    GW_SOMEIP <-->|"Ethernet SOME/IP"| ADAS
    VEH_SVC --> QNX
    QNX <-->|"IPC / VirtIO"| AAOS
    AAOS -->|"VHAL property"| AAOS

Mental Model

The vehicle is a United Nations without a shared language. Classic ECUs speak Signal-ish (CAN frames). Adaptive HPC speaks Service-ish (SOME/IP). The gateway is the simultaneous interpreter at the General Assembly — listening to CAN, translating in real time, and speaking SOME/IP to the cockpit. E2E protection is the checksum on the translation — proving the interpreter didn’t garble the message.

Mnemonic: Classic speaks signals. Adaptive speaks services. The gateway translates.

Think About It

The DBC says vehicle speed is correct, but AAOS shows 0 km/h. The gateway is running. Where’s the break?

Reveal Answer

CAN is correct, so the fault is downstream of the origin ECU — most often the gateway signal-to-service transform (wrong ComSignal mapping, scaling, or stale calibration), an E2E check rejection dropping the frame, or a SOME/IP publish/subscribe mismatch so the QNX Adaptive consumer never receives the event. Trace gateway RX → E2E status → SOME/IP event trace → QNX ara::com subscription → VHAL backend; the break is rarely in Android itself.

Gateway Translation: Signals ↔ Services

The gateway performs protocol and semantic translation:

Classic → Adaptive (Signal to Service)

Step	What Happens
1. RX on CAN	Gateway Classic COM receives EngineSpeed ComSignal from ECM
2. E2E Check	Verify CRC/counter from sending ECU (Classic E2E Profile)
3. Transform	Map signal value + timestamp + quality to service event payload
4. SOME/IP Publish	Gateway offers PowertrainService / EngineSpeedEvent on Ethernet
5. Adaptive Consume	QNX VehicleDataService receives event via ara::com proxy

Adaptive → Classic (Service to Signal)

Reverse path for actuation, e.g., cabin preconditioning request from AAOS:

Step	What Happens
1. SOME/IP Call	AAOS/QNX sends SetHvacPrecondition() method request
2. Gateway Transform	Map method parameters to HvacPreCondReq ComSignal
3. E2E Protect	Apply E2E profile for outbound Classic signal
4. CAN TX	Gateway COM transmits on HVAC CAN segment
5. Classic Act	HVAC ECU SWC receives signal via RTE, actuates

E2E Protection Across Boundaries

End-to-End (E2E) protection ensures data integrity from sender to receiver, critical when a corrupted speed value could affect ADAS or display logic.

E2E Profiles (Common in Automotive)

Profile	Mechanism	Typical Use
Profile 1	CRC + counter (8-byte data)	Classic CAN signals
Profile 2	CRC + counter (data up to 4 KB)	Larger Classic payloads
Profile 4	CRC + counter + length	SOME/IP / service events
Profile 7	CRC + counter + length + source ID	Mixed topologies

Cross-Boundary E2E Strategy

When data crosses Classic → Adaptive:

1. Origin ECU applies E2E protection to the CAN signal (Profile 1)
2. Gateway verifies E2E on RX and rejects corrupted frames
3. Gateway may re-protect for the Adaptive domain (Profile 4/7) on SOME/IP
4. Adaptive consumer verifies E2E before using the value in safety-relevant logic

E2E state machines track: OK, Error, Not Available, No New Data. Adaptive apps must handle degraded states, not just last-known-good values.

E2E State Handling in Adaptive Consumers

An Adaptive service consuming gateway-translated vehicle speed must check:

• E2E status: is the data integrity verified?
• Signal age: timestamp vs current time (stale data detection)
• Gateway health: is the translation path alive?

Displaying stale speed on the cluster may be acceptable with a warning; feeding stale speed to an ADAS function is not. ASIL decomposition assigns these checks to specific software elements with defined failure reactions.

Signal-to-Service Transformer Patterns

Gateway translation isn’t a simple lookup table. Production implementations use established patterns:

Pattern 1: 1:1 Signal Mapping

One Classic signal maps to one service event field:

CAN: VehicleSpeed (0.01 km/h resolution, uint16)
  → SOME/IP: VehicleSpeedService.VehicleSpeed (float32, km/h)

Scaling, offset, and unit conversion happen in the transformer.

Pattern 2: N:1 Aggregation

Multiple Classic signals compose one service struct:

CAN: DoorAjarFrntLe + DoorAjarFrntRi + DoorAjarReLe + DoorAjarReRi
  → SOME/IP: BodyStatusService.DoorStates (struct of 4 booleans)

Reduces SOME/IP event count; gateway aggregates on a fixed cycle.

Pattern 3: 1:N Fan-Out

One Classic signal feeds multiple Adaptive services:

CAN: VehicleSpeed
  → SOME/IP: ClusterService.Speed (display)
  → SOME/IP: AdasService.EgoSpeed (fusion input)
  → SOME/IP: TelematicsService.SpeedLog (fleet data)

Gateway may publish to multiple service instances or Adaptive apps subscribe independently.

Pattern 4: Service-to-Signal Command

Adaptive method call decomposed to Classic actuation:

SOME/IP: BodyService.LockAllDoors()
  → CAN: DoorLockCmd = LOCK_ALL (single frame to body ECU)

Command path often has stricter timing and E2E than status path.

Classic vs Adaptive: Coexistence Comparison

Aspect	Classic Domain	Gateway	Adaptive Domain
Data unit	Signal (ComSignal)	Transforms both directions	Service (method/event/field)
Wire protocol	CAN/LIN/FlexRay	Both	Ethernet SOME/IP
Config	ARXML (static)	Routing + transform config	Manifest (dynamic)
Discovery	Static routing tables	Pre-configured service offers	SOME/IP-SD
Update	ECU reflash	Gateway reflash	Process OTA
Timing	Cyclic (e.g., 10 ms task)	Transform latency budget	Event-driven + periodic
Safety	ASIL-D capable on ECU	ASIL decomposition	ASIL-B typical on SoC

Debugging the Boundary

When cross-domain features fail, use this checklist:

1. Is the Classic signal alive on CAN? (CANoe / bus log)
2. Does the gateway RX the signal? (gateway diagnostic log)
3. Does E2E check pass? (E2E error counters in gateway)
4. Is the SOME/IP service offered? (SOME/IP-SD trace)
5. Does the Adaptive consumer subscribe? (ara::com / middleware log)
6. Does QNX forward to AAOS? (IPC / VHAL backend log)
7. Does AAOS VHAL expose the property? (adb shell dumpsys car_service)

Each hop has different owners, different tools, and different failure signatures.

Where You'll See This

Coexistence shows up constantly in integration work:

• Signal lists (Classic) and service catalogs (Adaptive) maintained as paired documents: change one, update both
• Gateway calibration packages flashed separately from cockpit OTA
• E2E fault injection tests verifying cluster shows “speed unavailable” when CRC fails
• Latency budgets in requirements: “speed display ≤ 100 ms from CAN TX to AAOS property update”
• SIL/HIL benches simulating Classic ECUs + real Adaptive HPC to test translation before vehicle integration

When joining a new program, ask for the Signal-to-Service Mapping Matrix. It’s the Rosetta Stone for your platform.

Connect the Dots

Module 3 traced the industry shift from signals to services; coexistence is both running at once. Module 5–6 cover your Qualcomm SoC where Adaptive services land. Module 6.3 (VHAL) is often the last hop in the Classic → Gateway → Adaptive → AAOS chain. Module 9.4 (UDS/DoIP) routes diagnostics across the same gateway boundary.

Bottom line

1. Modern vehicles run Classic ECUs and Adaptive HPC together, not one replacing the other.
2. The central gateway translates between signal-based CAN and service-based SOME/IP.
3. E2E protection verifies data integrity at every hop, especially across the Classic/Adaptive boundary.
4. Signal-to-service transformers use mapping, aggregation, and fan-out patterns. Maintain the mapping matrix religiously.

Check Your Understanding

1. What is the primary role of the central gateway in Classic + Adaptive coexistence?

Recall

A. Provide OTA firmware updates exclusively to MCU-based Classic ECU nodesB. Replace all body ECUs with a single centralized high-performance computeC. Translate between Classic signal-based and Adaptive service-based commsD. Run the AAOS infotainment stack and host all Android system services

2. When vehicle speed is wrong in AAOS but correct on CAN, which investigation path is most logical?

Applied

A. Replace the Adreno GPU firmware because it handles cluster display renderingB. Trace CAN signal → gateway transform → SOME/IP → QNX consumer → VHAL → AAOSC. Reflash the ABS ECU firmware first since it is the speed signal origin ECUD. Update the AMSS modem stack to the latest baseband processor release version

3. Why is E2E protection applied again when the gateway forwards data to the Adaptive domain?

Applied

A. Classic ECUs lack the processing power to compute CRC for E2E profilesB. SOME/IP protocol fundamentally cannot transport binary data without E2EC. To verify integrity on the new Ethernet transport and catch gateway errorsD. E2E protection is only required for signals transmitted on LIN sub-buses

4. Four door-ajar CAN signals (front-left, front-right, rear-left, rear-right) are combined into one BodyStatusService.DoorStates struct on SOME/IP. Which signal-to-service transformer pattern is this?

Applied

A. N:1 aggregation — multiple Classic signals compose one Adaptive eventB. Direct passthrough — raw CAN frame forwarded unchanged as SOME/IP payloadC. 1:1 signal mapping — one CAN signal maps to exactly one SOME/IP fieldD. 1:N fan-out — one CAN signal feeds multiple independent SOME/IP services

5. CAN VehicleSpeed is verified correct in CANoe. Gateway SOME/IP offer is active. QNX VHAL logs show no speed property updates. AAOS cluster shows 0 km/h. Where is the most likely break?

Synthesis

Connects to: Module 6 — VHAL

A. Modem LTE attach state in AMSS is blocking vehicle data from reaching AAOSB. Adreno GPU display pipeline — a rendering bug is hiding the speed valueC. Gateway transform or E2E rejection dropping the translated SOME/IP eventD. ABS ECU wheel-speed algorithm — reflash the Classic ECU firmware image

6. After an Adaptive HPC OTA updates VehicleSpeedService but the gateway calibration package is unchanged, the cluster displays 2× actual speed. Root cause category?

Synthesis

Connects to: Module 8 — Build, Flash & Update

A. AAOS Car Service is missing the required SPEED property access permissionB. Classic ABS ECU is transmitting frames with corrupted CRC on every cycleC. SOME/IP-SD discovery timeout expired on the vehicle Ethernet backbone linkD. Coexistence config mismatch — gateway scaling is a separate flash artifact

Module Review: AUTOSAR

Question 1 of 10

AUTOSAR Classic uses RTE (Runtime Environment) for SWC communication. AUTOSAR Adaptive uses ara::com. A developer asks: 'Can I call an Adaptive service from a Classic SWC directly?' Answer?

🔗 Connects to: Module 5 — Multi-OS Layout

A. Only if both platforms run the identical AUTOSAR release version numberB. Yes — ara::com is fully backward compatible with Classic RTE port APIsC. No — Classic uses RTE on MCU, Adaptive uses ara::com on HPC; gateway bridgesD. Yes, via shared memory mapped between the MCU chip and the HPC processor

Further Reading

• AUTOSAR Foundation Standard — Shared protocols and interoperability artifacts that enable Classic ECUs and Adaptive HPC platforms to coexist within one vehicle architecture.
• AUTOSAR Classic Platform — Gateway Requirements — Classic COM gateway and PDU routing specifications that define how central gateway ECUs translate between bus domains.
• AUTOSAR Cross-Standard Working Groups — E2E Protection — Cross-platform End-to-End protection profiles (1, 2, 4, 7) used at the Classic/Adaptive boundary described in this page’s E2E section.
• Vector — AUTOSAR Gateway and Communication — Integration patterns for signal routing, protocol translation, and gateway ECU configuration between CAN/LIN and Ethernet domains.
• AUTOSAR Adaptive Platform — Service Communication — Adaptive service interface and SOME/IP binding specs that define the target format for signal-to-service transformers on the HPC side.
• ISO 13400 — Diagnostic Communication over IP (DoIP) — Ethernet diagnostic transport that crosses the same gateway boundary as vehicle data, often sharing routing infrastructure with SOME/IP services.
• ETAS — Vehicle Integration and Testing — Validation tooling and methodology for multi-domain integration testing across Classic ECU networks and Adaptive HPC platforms on SIL/HIL benches.