Automotive Edge Computing Explained: From SDVs to Dealership Edge Sites

What Is a Software-Defined Vehicle (SDV)?

A “software-defined vehicle” describes a car whose core functions and features are driven by software rather than hardware. It’s the continuation of the trend where vehicles evolve from mechanical systems into software-centric, connected computers on wheels.

To quote Aptiv:

“A software-defined vehicle is a vehicle whose features and functions are primarily enabled through software, a result of the ongoing transformation of the automobile from a product that is mainly hardware-based to a software-centric electronic device on wheels.”

The overarching goal is to drastically increase the cadence of vehicle features—enabling continuous delivery of new functionality and, ultimately, greater customer value. Today’s operating model still relies on dealer visits and service centers for updates and interventions, which slows this delivery cycle and limits how quickly improvements can reach drivers.

This article summarizes what defines an SDV and how it differs from traditional onboard software architectures. It also discusses challenges, possible directions, and a few personal reflections on where things might be heading.

This article focuses primarily on software-defined capabilities in commercial vehicles rather than consumer cars, where operational requirements and deployment challenges tend to differ substantially.

ECU Consolidation, Central Compute, and the Rise of Automotive Edge Computing

Traditional vehicles have relied on small, independent control units (ECUs), each dedicated to a specific function — such as braking, steering, engine timing, climate control, and so on. As new features were added, more ECUs appeared. Some modern cars ended up with over a hundred.

In the SDV model, many small ECUs are replaced by a few powerful central computers that handle multiple functions. These central systems are also moving from proprietary frameworks to more open, mainstream development tools and operating systems.

According to IBM Research, by 2030, about 90 percent of all vehicle innovations are expected to consist of software, and by 2035, three-quarters of industry executives believe the software-defined experience will be central to brand value.

In practice, the value of a vehicle is shifting from its mechanical components to the software running inside it. Features can be added or improved remotely, without requiring hardware modifications. Not only does this keep vehicles current for longer, but it can also extend their useful life.

An SDV is therefore not just a modern car — it’s a computing platform that can evolve, adapt, and improve over time.

Key SDV Characteristics in the Automotive Edge Ecosystem

The SDV domain concentrates primarily on onboard computing, where intelligence is increasingly moved into the vehicle itself:

  • Centralized computing architecture: Powerful central units replace dozens of smaller ECUs.
  • Over-the-air updates (OTA): Software updates can be delivered remotely, avoiding workshop visits.
  • Separation of hardware and software: Modular software platforms decoupled from hardware make upgrades easier and extend vehicle lifetime.
  • Virtualization and containerization: Isolation of safety-critical and non-critical functions; containerized applications enable small, controlled updates.

At the same time, realizing the full SDV vision also depends on modern edge computing outside the vehicle, for example in production facilities or customer environments. These off-board edge systems process data close to where it is generated and interact directly with the vehicle, much like industrial edge solutions that collect and act on sensor data from a truck in the field.

Benefits of SDVs in Automotive Digital Transformation

Autonomous and highly assisted driving introduce demanding edge use cases inside the vehicle. Sensors must be processed locally with low latency, and edge AI models need to run continuously even when connectivity is weak or unavailable. This onboard edge compute becomes essential for perception, decision-making, and real-time safety functions, forming a foundation for autonomous and driver-assist capabilities.

  • Faster development and testing – modern languages, CI/CD, virtualization, and containerization shorten development cycles and simplify testing.
  • Quicker innovation – modular architectures let teams roll out features separately from the base platform. Vehicles can receive new features and security updates throughout their lifetime.
  • New revenue streams – subscriptions, on-demand upgrades, and app-based features create ongoing business beyond the initial sale.
  • Longer vehicle lifetime – software-defined architectures allow vehicles to evolve after delivery. Features can be added, improved, or reconfigured over time, extending both the technical and commercial lifespan of the vehicle.
  • Predictive maintenance – onboard analytics can detect and report issues before failure.

SDV Software Architecture and the Evolution of Automotive Edge Computing

So what does the software stack of an SDV actually look like?

The field is still in its early stages of development, and opinions vary widely. Here’s a practical view that reflects how things are evolving today.

Automotive Operating Systems

The automotive domain has been dominated by Realtime OSes like QNX and VxWorks, and probably so will be for certain functions. These vendors are now providing hypervisors that allow you to run automotive Linux. Certain on-board computers will also probably run Linux natively.

The following diagram shows the growth of automotive Linux (from 2025 State of Automotive Software Development Report):

Bar chart showing the market share of automotive operating systems, with Automotive Grade Linux at 18% and AUTOSAR OS at 28% according to a 2025 report.

A growing share of next-generation SDV workloads will rely on Linux and container technologies to enable modular, updateable, and cloud-native application models inside the vehicle.

AUTOSAR & It’s Evolution

AUTOSAR has long provided a standardized abstraction layer for ECUs. It’s ambitious and has enabled compatibility across suppliers. However, its size and complexity make it more challenging to apply modern software principles, such as lightweight services, rapid iteration, and open-source collaboration.

It resembles large enterprise architectures from earlier IT eras, think J2EE, that eventually gave way to simpler, modular stacks. The industry trend now leans toward Linux-based platforms, containers, and modern languages such as Rust.

Automotive meets modern software principles

An important bridge between traditional AUTOSAR architectures and modern cloud-native approaches is the SOAFEE initiative (Scalable Open Architecture for Embedded Edge). It outlines a lightweight reference stack for software-defined vehicles based on containers, service-oriented APIs, and orchestration principles adapted from the cloud world. SOAFEE combines real-time and safety-critical automotive requirements with modern DevOps and CI/CD practices, defining a standardized foundation for running and updating applications in vehicles. In many ways, it represents a practical evolution from AUTOSAR toward Linux-based and containerized platforms.

The Eclipse SDV initiative shares many of the same ideas — openness, modularity, and modern development workflows — though it’s broader in scope and still at an earlier stage of maturity.

Eclipse SDV and the Emerging Automotive Edge Ecosystem

The Eclipse SDV initiative is a promising step in that direction. It collects open-source projects aimed at bringing modern software practices into the automotive world. The scope is broad, and while some components are mature, others are still in their early stages. Adopting it today requires significant effort in integration, filling functional gaps, and addressing compliance and security responsibilities.

None of that makes it the wrong choice — but it does mean that organizations must be realistic about the internal engineering investment required to create a complete, production-grade platform.

See the diagram on challenges for using automotive Open Source (from 2025 State of Automotive Software Development Report).

Bar chart detailing challenges for automotive open source, highlighting time and development resources at 39% and safety/security concerns at 30%.

Automotive Edge Computing: Beyond the Vehicle

The automotive edge extends far beyond what happens inside the vehicle. While onboard compute handles real-time perception and control, a parallel edge ecosystem supports operations, maintenance, and lifecycle management across the entire fleet. This off-board edge includes environments such as dealerships, service centers, charging stations, and even customer industrial sites where vehicles operate. Local edge nodes handle diagnostics, data filtering, and service intelligence close to where the data is generated, which is essential when connectivity is limited or costly

These locations host infrastructure that processes data locally, connects intermittently mobile vehicles, and enables field-level decisions without depending on central cloud services. Edge nodes aggregate sensor data, run diagnostics near the source, and prepare data for transfer to backend platforms. They also support remote assistance, targeted software deployments, and continuous measurement of vehicle health even when connectivity is unreliable.

Importantly, this distributed edge is not merely a communications layer but a computing layer. It can run containerized applications. In practice, the automotive edge extends the vehicle’s software-defined architecture, ensuring that SDV capabilities remain operational across the entire operational environment rather than only within the vehicle.

Closing thoughts

The shift toward software-defined vehicles is really about pace. Large, monolithic software stacks are giving way to smaller, modular components built with containers, APIs, and automated pipelines. These modern principles enable the development, validation, and deployment of features to occur continuously, rather than in multi-year release cycles.

Traditional automotive frameworks brought structure but also friction. Their weight and rigidity slow down iteration and make integration across suppliers harder. The direction is clear: lighter architectures, continuous integration, and virtual validation environments that shorten feedback loops and enable vehicles to evolve long after delivery.

Industry programs are important catalysts, yet they also show how standardization can both enable and delay progress. Collaboration is valuable, but the fastest teams will be those that adopt modern software methods pragmatically—using what works today instead of waiting for consensus.

Ultimately, success in the SDV era will stem from agility: the ability to deliver reliable software quickly, learn from it, and continually improve. The future belongs to those who move first, not just those who agree first.

Keep reading: Key Considerations for a Software-Defined Vehicle Development Platform

Frequently Asked Questions

Onboard computing reuses edge technology like Linux, Containers and Edge Orchestration.

In-vehicle compute represents what runs in the vehicle, whereas automotive edge represents associated services surrounding cars and the transport sector.

Onboard compute provides limited footprint, Kubernetes is too heavy. Furthermore Kubernetes solves the data-center problem with elasticity etc which is not part of the SDV domain.

SDVs use cloud platforms for fleet management, data aggregation, and backend analytics. Industrial protocols like MQTT, V2X protocols are used.