Telematics & eCall

TL;DR

Telematics turns the vehicle into a connected node: GPS position, remote services, fleet data, and crash response over the AMSS modem. The TCU (Telematics Control Unit) role is the connectivity hub: manage SIM, data sessions, voice, and SDK APIs for application code on QNX or AAOS. eCall (EU-mandated) auto-dials 112 with GPS coordinates on crash detection, plus a manual SOS button. Application developers use TelAF (Telematics Application Framework), C++ APIs for calls, SMS, data, location, and firmware update. V2X adds vehicle-to-everything radio: C-V2X (cellular-based, Qualcomm’s path forward) vs legacy DSRC (802.11p, mostly deprecated in new programs).

AMSS gives you bars on the status icon. Telematics is what the vehicle does with those bars, and it’s where regulatory requirements (eCall), OEM connected services, and your application code all meet.

The TCU Role: Connectivity Hub

In modern centralized architectures, the “TCU” is often not a separate box. It’s a software role running on the cockpit SoC alongside QNX and AAOS, backed by the integrated modem (AMSS/MPSS).

TCU Responsibility	What It Means in Practice
SIM / subscription management	eUICC profiles, carrier provisioning, APN config
Data session lifecycle	Bring-up PDP/PDU contexts, reconnect on tunnel loss
Voice call control	VoLTE, emergency call routing, in-band modem
Location services	GNSS fusion, dead reckoning assist for eCall
Application API surface	TelAF SDK for OEM telematics apps
Regulatory compliance	eCall, ERA-GLONASS (Russia), regional SOS variants
Security boundary	Credentials, TLS to cloud, certificate rotation

On a Qualcomm cockpit platform (SA8155P, SA8295P), the TCU stack typically spans:

flowchart TB
    subgraph APPS["Application Layer"]
        OEM["OEM Telematics App<br/>(QNX or AAOS native)"]
        ECALL["eCall / SOS Handler"]
        CLOUD["Cloud Agent · OTA Client"]
    end

    subgraph TELAF["TelAF SDK (C++)"]
        VOICE["Voice Service"]
        DATA["Data Service"]
        SMS["SMS Service"]
        LOC["Location Service"]
        FWU["Firmware Update Service"]
    end

    subgraph MODEM["AMSS / MPSS (Modem Subsystem)"]
        QMI["QMI Voice · WDS · NAS · LOC"]
        RF["LTE / 5G / GNSS RF"]
    end

    subgraph V2X["V2X (Optional)"]
        CV2X["C-V2X PC5 / Uu"]
    end

    OEM --> TELAF
    ECALL --> VOICE
    ECALL --> LOC
    CLOUD --> DATA
    TELAF --> QMI
    V2X --> MODEM
    RF --> ANT["Antenna Farm<br/>Cellular · GNSS · V2X"]

Mental Model

Think of telematics as the vehicle’s 911 dispatcher desk. AMSS is the phone network in the wall. TelAF is the dispatcher’s console — buttons for “make call,” “send data,” “where am I,” “update phone firmware.” eCall is the red panic button wired to the airbag sensor — it must work even if the infotainment UI is frozen. Cloud services are the regional call center receiving the vehicle’s data. Your job is making sure the dispatcher desk (TelAF integration) correctly uses the phone network (QMI/AMSS) under crash and tunnel-failure stress.

eCall: When Crash Meets Regulation

eCall is an EU mandate (Regulation 2015/758, type-approved under UN ECE regulations) requiring in-vehicle emergency calling. It’s not optional for vehicles sold in scope, and it has hard real-time requirements that survive infotainment failure.

Automatic Trigger (Crash)

On qualified crash detection (typically from ACN — Automatic Crash Notification sensor fusion, often airbag deployment signal + accelerometer):

Modem initiates emergency voice call to 112 (EU emergency number)
Minimum Set of Data (MSD) transmitted, including GPS/GNSS coordinates, vehicle VIN, direction of travel, timestamp
Voice channel opens even if MSD send fails (voice is mandatory fallback)
Call must proceed without user interaction. The driver may be unconscious.

Manual Trigger (SOS Button)

The SOS button (often overhead console or center stack) triggers the same emergency call path. Regulatory testing verifies:

Button works with ignition off (within battery budget)
Button works when infotainment is crashed or booting
No accidental triggers (long-press, cover, self-test)

Why eCall Lives Close to the Modem

eCall is not implemented as an Android app making a normal phone call. It routes through modem IMS/voice QMI paths with priority queuing that bypasses AAOS media framework latency. Put eCall logic purely in AAOS Java and you fail homologation. The call must work when Android is down.

Common Gotcha

“We have eCall — it’s the SOS app on the center stack.” The UI button is one piece. eCall certification covers the full chain: crash sensor → telematics daemon → TelAF/QMI voice → AMSS IMS → RF antenna → 112 PSAP reception with valid MSD. A beautiful SOS UI with a broken modem voice path is a homologation failure, not a feature.

TelAF: The SDK You Actually Integrate

TelAF (Telematics Application Framework) is Qualcomm’s C++ SDK that wraps QMI into application-friendly services. Your OEM telematics binary on QNX (or sometimes AAOS native) links against TelAF. You don’t raw-pack QMI structs in product code.

TelAF Service	API Capability	Typical Use
Voice	Dial, answer, hang up, emergency call	eCall, concierge, RSA (roadside assist)
SMS	Send/receive text	Fleet notifications, fallback messaging
Data	Start/stop data calls, APN management	Cloud connectivity, OTA download
Location	GNSS fix, fused location	Navigation assist, stolen vehicle tracking
Device Management	IMEI, signal strength, modem reset	Factory test, field diagnostics
Firmware Update	Stage and apply modem images	Modem OTA (Module 7.3)

TelAF vs Android Telephony

	TelAF (QNX / native)	Android Telephony (AAOS)
Runs on	QNX telematics process, sometimes native AAOS daemon	Android framework + `TelephonyManager`
Modem access	Direct QMI via TelAF	`rild` + vendor RIL HAL → QMI
eCall suitability	Primary path for safety-regulated builds	Usually not the certified eCall path
Your daily touch	QNX telematics integration, factory EOL	`adb shell dumpsys telephony`, carrier apps

MSD Payload — What's in the Crash Packet

The Minimum Set of Data eCall packet (standardized in EN 15722) includes: vehicle type, VIN, propulsion type (ICE/EV/hybrid), timestamp, recent locations (current + optional previous), direction, and optional passenger count. It’s sent in-band over the voice call (modem tones) or out-of-band depending on generation and PSAP capability. Getting MSD encoding wrong fails type approval even if the voice call connects. QA teams test this with eCall simulators and PSAP lab benches, not just “does 112 dial.”

V2X: C-V2X vs DSRC

V2X (Vehicle-to-Everything) lets the car exchange messages with other vehicles (V2V), infrastructure (V2I), pedestrians (V2P), and networks (V2N): intersection collision warnings, work zone alerts, traffic light timing.

	DSRC (802.11p)	C-V2X (3GPP)
Radio technology	Wi-Fi-like direct radio (ITS-G5 in EU)	PC5 sidelink (direct) + Uu via cellular network
Qualcomm stance	Legacy, supported on older programs	Current path, integrated with Snapdragon modem
Range / latency	~300 m direct, low latency	Similar direct range; network mode adds cloud relay
Spectrum	Dedicated 5.9 GHz (region-dependent)	PC5 reuses cellular bands / 5.9 GHz (region-dependent)
Your daily touch	Maintaining legacy fleets, dual-radio TCUs	New platform bring-up, coexistence with LTE/5G antenna

On Qualcomm automotive platforms, C-V2X typically shares RF planning with the cellular modem: antenna isolation, calibration, and regulatory testing are joint exercises. DSRC programs often required a separate 802.11p radio. Know which your variant ships.

Connect the Dots

Module 1.4 linked Connected (CASE) to OTA and telematics. Module 7.1 explained AMSS, the modem world TelAF talks to. This page is the application layer above QMI: regulatory (eCall), OEM services (cloud, fleet), and optional V2X. Module 7.3 covers modem firmware updates via TelAF’s Firmware Update Service. Module 8 covers OTA architecture for AAOS/QNX, a separate path from modem updates.

Quick recap

TCU = connectivity hub role: SIM, data, voice, location, APIs, often on the cockpit SoC, not a separate ECU.
eCall auto-dials 112 with GPS/MSD on crash; SOS button triggers the same regulated path, not a normal Android phone call.
TelAF provides C++ APIs (voice, SMS, data, location, FW update) over QMI: your integration surface on QNX telematics.
V2X: C-V2X is Qualcomm’s forward path; DSRC is legacy 802.11p. Know your program’s radio.

Where You'll See This

Telematics bugs land in your queue disguised as “navigation can’t get GPS” or “connected services offline”:

Distinguish GNSS from cellular: TelAF Location Service vs NAS/WDS data session. GPS fix without cloud = data/APN problem. No GPS at all = antenna or LOC QMI path.
eCall test mode: Factory builds have eCall simulation that must never dial live 112 on the line. Know your project’s test PSAP number and how to enable/disable test mode before bench work.
SOS button wiring: Often GPIO to QNX telematics daemon, not AAOS input event. If SOS works in factory menu but not from physical button, suspect hardware/GPIO mapping, not TelAF.
Carrier variance: Same TelAF build, different APN/SIM profiles per region. “Works in DE, fails in US” is usually provisioning, not code.

When integrating a new cloud feature, trace the full path: your app → TelAF Data Service → QMI WDS → AMSS → carrier APN → internet. Breakage at any hop looks like “no connectivity” from the app team’s perspective.

Check Your Understanding

1. EU eCall requires which behavior on automatic crash detection?

2. Where should regulated eCall voice routing primarily execute on a Qualcomm cockpit platform?

3. C-V2X differs from legacy DSRC (802.11p) primarily in that: