What SDV means for your job · Bhargava Mandapati

Architecture diagrams are abstract. This page is about what actually lands on your desk.

The roles that appear#

Vehicle service developer. Writing the services that expose vehicle capability — a seat service, a lighting service — with versioned interfaces that other teams call. Closest to ordinary backend work of anything in automotive.

Platform / middleware engineer. The layer between the vehicle network and applications: signal translation, data brokers, service discovery. This is where and live.

Cockpit engineer. The cluster and infotainment domain, increasingly on one consolidated computer. Where Android Automotive knowledge applies directly.

Virtualisation / integration engineer. Hypervisor configuration, guest partitioning, proving . A genuinely scarce skill.

Vehicle DevOps. Build infrastructure, pipelines, staged rollout tooling. Almost nonexistent as a role ten years ago.

Data engineer. Vehicle telemetry pipelines, on-vehicle aggregation, fleet analysis, and the privacy obligations attached to all of it.

The roles that change rather than disappear#

In plain terms

A recurring anxiety is that classic embedded automotive skills are becoming obsolete. They are not, and it is worth being clear about why.

Someone still writes the ECU software. Zone controllers, sensors, actuators and safety-critical functions remain small embedded systems. That work continues.

Someone still owns the vehicle network. CAN does not disappear. Most vehicles will contain it for another decade, and the gateway between old and new is significant, ongoing work.

Safety engineering becomes more important, not less. Proving isolation on shared hardware is harder than proving separation between physically separate boxes.

What changes is that these roles now sit alongside service architecture, cloud delivery and continuous integration — so the people who can work across both sides become disproportionately valuable.

The skills that carry across#

Ranked by how much leverage they give you:

1. Understanding both worlds. Someone who can read a CAN database and design a service interface is the person who ends up designing the gateway — which is on every real programme, because every real programme is a mixture.

2. Service and interface design. Versioning, backwards compatibility, designing something that will not need to change for a decade. This is the distinguishing skill of the SDV era.

3. Testing without hardware. Building things that can be exercised in a pipeline rather than on a bench. The engineers who make this possible unblock everybody else.

4. Safety literacy. Not becoming a safety engineer — knowing enough to recognise when a requirement has landed on the wrong system and to escalate it early.

5. Ordinary software engineering. Version control, code review, automated testing, observability. Automotive has historically been weaker at these than the wider industry, and they transfer completely.

What a week actually looks like

An engineer on a cockpit SDV programme:

Monday. A cluster value is wrong. Trace it back through the service, the data broker and the CAN gateway. The scaling factor was applied twice.

Tuesday. Design review for a new comfort service. The argument is about whether a field should be an enum or an integer — because the interface must survive ten years and an enum cannot gain values safely without versioning.

Wednesday. The pipeline is failing intermittently. Turns out to be a timing assumption that holds on hardware and not in simulation.

Thursday. A requirement arrives saying the head unit shall display a collision warning. Escalate it — that belongs on the safety-rated path.

Friday. Review a supplier's service interface. It has a method that returns void and reports errors through a separate signal. Send it back.

Note how little of that is writing new features, and how much is interfaces, integration and evidence. That ratio is characteristic.

What to learn, in what order#

If you are coming from classic embedded automotive:

Service-oriented thinking — the communication module here
and specifically
Linux and POSIX, if you have only worked on microcontrollers
Git, CI, and automated testing as daily practice
A modern application platform — Android Automotive or AUTOSAR Adaptive

If you are coming from general software engineering:

Why vehicles are different — safety, longevity, variation
The vehicle network: CAN, and why it looks so primitive
Functional safety literacy — enough to know what you must not own
Real-time and determinism concepts
The regulatory environment, which genuinely constrains design

If you are coming from Android or app development:

This site's Learn AAOS section — the platform specifics
The communication module here — where the data comes from
Cluster and cockpit consolidation — the part that surprises app developers
Safety boundaries — what Android is and is not allowed to own

Being useful in the first month#

Next#

Into the architecture that makes all of this possible.