OTA In Practice: gRPC + SOME/IP

Advanced12 min read

Assumes: 8.5 OTA Architecture, 3.3 SOME/IP

TL;DR

Production automotive OTA isn’t just Android UpdateEngine. It’s a distributed update architecture spanning cockpit SoC, zone controllers, modem, and ADAS ECUs. SOME/IP handles service discovery and control-plane RPC: finding which ECU offers UpdateManagement, subscribing to progress events, coordinating preconditions (speed, power). gRPC handles data-plane transfer: streaming signed payloads, manifest delivery, status callbacks with protobuf contracts. Your daily lb tool sits in the campaign orchestration layer. It drives gRPC sessions to update agents, uses SOME/IP to discover targets on the vehicle network, and manages fleet campaigns while UpdateEngine (or capsule/TelAF equivalents) does the actual slot writing on each compute unit.

You run lb campaigns every week. This page connects the tool you touch to the protocols underneath, and where Android UpdateEngine ends and vendor OTA begins. Theory says “seamless A/B swap.” Practice says “check it again, then check the rollback.”

Think About It

Your OTA campaign shows 98% success rate but 2% of vehicles are stuck in ‘applying’. What’s the most likely stall point?

Reveal Answer

The stall is almost always inside UpdateEngine during payload apply to the inactive slot — not in SOME/IP discovery or gRPC download (those fail earlier at 0%). Common causes: Virtual A/B snapshot merge still running, /data/ota_package or cache partition full, delta payload source-version mismatch, or a hung write to super / boot_b. On stuck units, pull adb logcat -s update_engine and adb shell dumpsys update_engine — look for SNAPSHOT_MERGE, kInsufficientSpace, or kPayloadTimestampError.

Update Agent Architecture

A modern SDV OTA stack has layers, not one daemon:

flowchart TB
    subgraph Cloud["Backend / Campaign Server"]
        CMS["Campaign Management<br/>build matrix, targeting"]
        PKG["Package Repository<br/>signed payloads"]
    end

    subgraph Bench["Your Workstation"]
        LB["lb tool<br/>campaign CLI"]
    end

    subgraph Vehicle["In-Vehicle Network"]
        subgraph Cockpit["Cockpit SoC (SA8155P)"]
            GW["OTA Gateway / Update Agent"]
            UE["UpdateEngine (AAOS)"]
            GW --> UE
        end
        subgraph Zone["Zone Controller"]
            CAP["Capsule Update Agent"]
        end
        subgraph Modem["Modem / TelAF"]
            TAF["TelAF OTA Client"]
        end
    end

    CMS --> LB
    PKG --> LB
    LB -->|"gRPC: stream payload, control"| GW
    LB -->|"SOME/IP: discover + method calls"| GW
    LB -->|"SOME/IP + gRPC"| CAP
    LB -->|"SOME/IP + gRPC"| TAF
    GW -->|"internal API"| UE

Layer	Responsibility	Example Component
Campaign orchestration	Target selection, scheduling, retry, reporting	lb, fleet backend
Transport	Discovery, session setup, streaming	SOME/IP + gRPC
Update agent	Preconditions, local apply, reboot coordination	Gateway service on each ECU
Platform engine	Partition/slot manipulation	UpdateEngine, capsule, TelAF
Boot firmware	Slot selection, AVB	ABL, bootctrl

lb orchestrates, SOME/IP finds agents, gRPC feeds payloads, and UpdateEngine writes slots.

Mental Model

Think of a fleet OTA as airport catering. SOME/IP is the intercom — “Which gate has the catering port open?” gRPC is the conveyor belt — meals (payload bytes) streamed to the right gate. lb is the ** catering manager’s tablet** — selects flights (VINs), starts deliveries, reads status. UpdateEngine is the flight crew — actually loads trays into the galley (inactive slot) once delivery arrives.

OTA orchestration = air traffic control. Multiple domains (AAOS, QNX, modem) need coordinated landing slots.

SOME/IP: Service Discovery for Update Targets

SOME/IP (Scalable service-Oriented MiddlewarE over IP) runs on Automotive Ethernet, the same SOA fabric from Module 3.

Why SOME/IP for OTA Control Plane

SOME/IP Feature	OTA Use
Service Discovery (SD)	Find UpdateManagement instances on unknown ECUs
Methods (RPC)	StartDownload(), GetStatus(), CancelUpdate()
Events	ProgressChanged(42%), PreconditionFailed(SPEED)
Fields	CurrentVersion, UpdateState
Multicast/UDP SD	ECUs announce services without static IP tables

Typical discovery flow:

1. lb (or in-vehicle gateway) sends FindService for UpdateManagement (service ID program-specific)
2. Zone controller responds OfferService with IP, port, instance ID
3. lb invokes StartDownload(campaignId, manifestUrl) via SOME/IP method
4. Agent publishes ProgressChanged events during apply

Common Gotcha

If you copy SOME/IP service IDs from another program, you’ll silently find no services or call wrong methods. SOME/IP service IDs and method signatures are OEM-defined, not standardized like Android APIs. Your lb config maps logical names to ARXML/VSOMEIP configs.

gRPC: Data Transfer and Session Control

While SOME/IP handles in-vehicle service semantics, gRPC (HTTP/2 + protobuf) typically handles:

gRPC Role	Details
Payload streaming	Client/server streaming of multi-GB OTA packages
Manifest delivery	Protobuf-defined package metadata, hash, rollback index
Status callbacks	Structured error codes back to campaign tool
Authentication	mTLS, token-based fleet auth
Cross-network	Bench PC → vehicle gateway over Ethernet/Wi-Fi

Example logical service (conceptual; actual .proto is vendor-specific):

service UpdateDelivery {
  rpc StreamPackage(PackageRequest) returns (stream PackageChunk);
  rpc ReportStatus(StatusReport) returns (Ack);
  rpc QueryCapabilities(Empty) returns (CapabilityList);
}

Transport	Best For
SOME/IP	In-vehicle ECU-to-ECU, SD, real-time preconditions
gRPC	High-throughput blob transfer, cloud-to-vehicle, tool-to-gateway
HTTPS	Classic UpdateEngine server check (AAOS A/B)

Many architectures use both: SOME/IP discovers the agent and gates preconditions; gRPC streams the blob to the agent’s local cache; agent hands off file path to UpdateEngine.

Campaign Management with lb

Your lb tool (vendor OTA CLI; exact expansion varies by OEM/Tier-1) typically implements:

lb Capability	What You Do Daily
Campaign create	Target build ID, VIN list, rollout percentage
Precondition check	Speed, voltage, storage space, current build match
Trigger download	Initiate gRPC stream or point agent to CDN URL
Monitor progress	Parse SOME/IP events or gRPC status stream
Retry / abort	Cancel stuck campaigns, restart failed ECUs
Multi-ECU orchestration	Sequence: modem → zone → cockpit (dependency order)
Report export	Pass/fail per ECU for test sign-off

Typical daily workflow:

# Conceptual; exact syntax is vendor-specific
lb campaign create --build 2024.09.12.001 --targets bench-vin-list.txt
lb campaign preflight --campaign-id 8842
lb campaign start --campaign-id 8842
lb campaign status --campaign-id 8842 --watch
lb campaign logs --ecu cockpit --since 1h

lb campaign debugging checklist

When a campaign stalls at 0%:

1. SOME/IP SD: Is the update service offered? (vsomeip log, Wireshark SD packets)
2. Preconditions: Speed, gear, battery logs in agent events
3. gRPC connectivity: mTLS cert expiry, firewall on bench VLAN
4. Build fingerprint match: delta payload against wrong source version
5. Storage: /data/ota_package or cache partition full
6. Concurrent merge: Virtual A/B merge blocking apply (Page 8.5)

When cockpit succeeds but zone fails, you’re in multi-ECU orchestration territory. Check lb dependency graph: some programs require modem before AAOS, or zone before cockpit display sync.

Separate transport failures from apply failures: gRPC 200 + UpdateEngine kPayloadHashMismatchError = bad payload, not bad network.

Platform Engines: Who Actually Writes the Slot

Engine	Platform	Mechanism
Android UpdateEngine	AAOS on cockpit SoC	A/B or Virtual A/B payload apply to UFS partitions
Capsule update	AUTOSAR Adaptive / zone controllers	Software Cluster packaging, UCM (Update Configuration Management)
TelAF (Telematics AF)	Qualcomm modem / telematics	Firmware OTA for AMSS, managed service lifecycle
QNX SLM / custom	QNX host OS	Vendor-specific image swap, may parallel AAOS OTA

Comparison Matrix

Aspect	UpdateEngine (Android)	Capsule (Adaptive)	TelAF (Modem)
Partition model	GPT A/B slots, super	UCM software clusters	Modem firmware store
Payload format	.bin OTA payload (Google)	AUTOSAR package / manifest	QTI modem OTA format
Discovery	Often localhost from gateway	SOME/IP to UCM service	Service-based on internal bus
Rollback	bootctrl + AVB	UCM rollback API	Modem anti-rollback fuses
Typical agent	AAOS system service	Adaptive application	TelAF daemon
Your tool visibility	adb logcat update_engine	SOME/IP trace + UCM logs	lb modem status + QXDM

sequenceDiagram
    participant LB as lb tool
    participant SD as SOME/IP SD
    participant GW as Cockpit Update Agent
    participant GRPC as gRPC stream
    participant UE as UpdateEngine

    LB->>SD: FindService(UpdateManagement)
    SD-->>LB: OfferService (192.168.x.x)
    LB->>GW: StartDownload (SOME/IP method)
    GW->>GW: Check preconditions (speed=0, power OK)
    LB->>GRPC: StreamPackage(manifest)
    GRPC->>GW: Payload chunks
    GW->>UE: ApplyPayload(path)
    UE->>UE: Write inactive slot
    UE-->>GW: UPDATED_NEED_REBOOT
    GW-->>LB: ProgressEvent(100%)
    LB->>GW: ConfirmReboot (policy-gated)
    GW->>UE: Reboot

When UpdateEngine Runs vs Gateway Proxy

Some programs embed UpdateEngine directly in the AAOS update app: lb talks gRPC to a cloud backend, Android downloads via HTTPS. Others place an OTA gateway on QNX or a privileged Android service that proxies to UpdateEngine via binder IPC, so lb never touches UpdateEngine directly. Check your program’s sequence diagram in the integration spec to know where your logs live.

Integration with Secure Boot (Page 8.4)

Every engine hits the same gates:

Gate	Where Enforced
Payload signature	UpdateEngine / UCM before apply
Rollback index	ABL + modem fuses
AVB match	First boot after apply
Campaign signing	Backend + lb mTLS / package signature

A perfectly delivered gRPC stream still fails if the payload wasn’t signed with the production OTA key matching fused trust anchors.

Connect the Dots

Module 3 (SOA) introduced SOME/IP primitives: methods, events, fields. Page 8.5 covered A/B slot mechanics UpdateEngine implements. Page 8.3 gives ADB commands for UpdateEngine log grep. Page 8.2 (QFIL) remains the recovery path when OTA bricks both slots.

In brief

1. lb orchestrates campaigns. It doesn’t write partitions directly.
2. SOME/IP = in-vehicle discovery + control plane. gRPC = payload streaming + structured status.
3. UpdateEngine, capsule, and TelAF are platform-specific apply engines under the agent.
4. Debug by layer: SD connectivity → gRPC transfer → precondition → apply engine → AVB boot.

Check Your Understanding

1. In a typical automotive OTA stack, what is SOME/IP primarily responsible for?

Recall

A. Replacing ABL for slot selection and bootctrl metadata management tasksB. Streaming multi-gigabyte payload bytes from cloud to UFSC. Computing dm-verity hash treesD. Service discovery and control-plane RPC — finding agents, invoking methods

2. Where does the lb tool sit in the OTA architecture?

Recall

A. Campaign orchestration — triggering, monitoring, and coordinating ECU updatesB. It replaces UpdateEngine and writes directly to boot partitionsC. It runs inside TrustZone and signs vbmetaD. It is the Android recovery image

3. Cockpit AAOS OTA succeeds via UpdateEngine, but a zone controller fails. Most likely architectural explanation?

Applied

A. SOME/IP and gRPC are Android-only protocols that cannot run on AUTOSAR ECUsB. UpdateEngine automatically coordinates and updates all ECUs in the vehicleC. Multi-ECU campaigns have separate agents — zone uses AUTOSAR UCM, own domainD. Zone controllers cannot be updated OTA and always require physical QFIL flash

4. A campaign stalls at 0% progress. vsomeip logs show no OfferService for UpdateManagement, but gRPC mTLS to the cloud succeeds. Where do you debug first?

Applied

A. SOME/IP discovery — agent offline, wrong VLAN, or mismatched service IDsB. QFIL rawprogram partition offsets not aligned to the UFS erase block sizeC. UpdateEngine dm-verity merge failure on AAOS blocking the post-OTA rebootD. PBL fuse configuration mismatch between the SoC stepping and the BSP build

5. lb streams a signed payload via gRPC to the cockpit gateway, which calls UpdateEngine ApplyPayload(). Where does SOME/IP fit in this flow compared to gRPC?

Synthesis

Connects to: Module 3 — Signals to Services

A. SOME/IP replaces gRPC for all payload byte streaming and partition writesB. gRPC handles only modem firmware updates; SOME/IP handles only AAOS OTAC. Neither protocol is used — UpdateEngine polls HTTPS directly from the cloudD. SOME/IP discovers agent and gates preconditions; gRPC streams the payload

6. A zone controller OTA uses AUTOSAR Adaptive UCM instead of UpdateEngine. Which apply-engine difference matters most for lb campaign sequencing?

Synthesis

Connects to: Module 4 — AUTOSAR

A. UCM bypasses secure boot entirely and writes directly to flash partitionsB. UCM has own rollback API + SOME/IP — lb orchestrates it as independent ECUC. UCM requires a physical QFIL flash for every software update on that ECUD. UCM uses GPT A/B slots identical to AAOS bootctrl for slot management

Module Review: Build, Flash & Update

Question 1 of 12

lb OTA campaign: SOME/IP prepareUpdate succeeds, gRPC StreamDownload completes 100%, finalizeUpdate returns error 'AVB verification failed.' Most likely cause?

🔗 Connects to: Module 3 — gRPC

A. Payload corrupted, wrong key, or vbmeta mismatch — AVB checks at apply timeB. Vehicle was moving during the download phase and exceeded the speed thresholdC. SOME/IP service discovery timeout between the update agent and orchestratorD. Network interruption during the OTA payload download phase from the cloud

Further Reading

• gRPC Documentation — Protocol reference for streaming OTA payloads, structured status callbacks, and mTLS session setup between campaign tools and in-vehicle agents.
• AUTOSAR SOME/IP Specification — Service discovery, methods, and events used for in-vehicle update control-plane RPC and precondition signaling.
• Over-the-Air Updates Overview — Android UpdateEngine foundation that cockpit gateway agents delegate to for A/B slot writes on AAOS.
• AUTOSAR Adaptive Platform — UCM (Update and Configuration Management) context for zone-controller capsule updates in multi-ECU campaigns.
• AOSP Release Tools (OTA) — Source tree for OTA payload generation including delta/incremental update tooling used in fleet campaigns.
• Android Verified Boot — Signature and rollback gates every apply engine hits after gRPC delivery, regardless of transport success.