Classic + Adaptive Coexistence

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.

Common Gotcha

“Vehicle speed is in the DBC but not in AAOS”: the DBC describes the Classic CAN world. AAOS reads VHAL properties backed by Adaptive services. The break is usually in the gateway transform or SOME/IP service offer, not in Android. Trace: CAN signal → gateway → SOME/IP event → QNX service → VHAL → AAOS.

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.

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?

A. Run the AAOS infotainment stackB. Translate between Classic signal-based communication and Adaptive service-based communicationC. Replace all body ECUs with a single HPCD. Provide OTA updates only to MCU ECUs

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

A. Reflash the ABS ECU firstB. Trace the chain: CAN signal → gateway transform → SOME/IP service → QNX consumer → VHAL → AAOSC. Replace the Adreno GPU firmwareD. Update the AMSS modem stack

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

A. SOME/IP cannot carry binary data without E2EB. To verify integrity across the new transport (Ethernet) and detect gateway translation errorsC. Because Classic ECUs cannot compute CRCD. E2E is only required for LIN bus signals