SDV stands for Software-Defined Vehicle.

SDS stands for Software-Defined System.

The two ideas are closely related, but they are not quite interchangeable.

A software-defined vehicle is a vehicle whose functionality, behavior, features and continuing evolution are determined to a significant degree by software rather than being fixed primarily by its hardware when it leaves the factory.

A software-defined system is the broader idea: a physical system whose capabilities are increasingly controlled, modified or extended through software.

So an SDV can be considered a particular kind of software-defined system.

The automobile just happens to be one of the most dramatic examples.

What Is a Software-Defined Vehicle?

The phrase software-defined vehicle describes the automobile industry’s shift from cars that contain software to cars whose capabilities are increasingly defined by software.

That distinction matters.

Cars have contained software for decades.

Electronic engine controls, anti-lock brakes, automatic transmissions, airbags, navigation systems and countless other vehicle functions have depended on software for years.

That alone does not make every modern car a software-defined vehicle.

In an SDV, software takes a much more central role in determining what the vehicle can do, how its systems interact and how its capabilities can change after the vehicle has been manufactured.

Bosch describes the SDV as a vehicle whose behavior and functionality are determined to a large degree by software, with new features and improvements capable of being delivered through software updates.

That final point is particularly important:

The vehicle does not necessarily stop evolving when it leaves the assembly plant.

A Traditional Vehicle Was Largely Defined at the Factory

Think about a conventional automobile.

When the car rolled off the assembly line, most of its capabilities were essentially fixed.

It had:

• A particular engine
• A particular transmission
• A particular suspension
• Specific electronic modules
• Specific dashboard functions
• Specific safety systems
• Specific convenience features

Some software could certainly be reflashed or repaired.

But changing what the vehicle fundamentally did usually meant changing hardware.

Want heated seats?

The car generally needed to be built with them.

Want a more sophisticated driver-assistance feature?

That might require different controllers, sensors and wiring.

Want new functionality five years later?

Buy a newer car.

The automotive business was built largely around this model.

An SDV Changes the Relationship Between Hardware and Software

In a software-defined vehicle, engineers increasingly try to separate software functionality from individual pieces of hardware.

Instead of every function being tightly tied to a dedicated electronic control unit, software can run on more powerful centralized computing platforms and communicate through standardized interfaces.

ETAS describes this type of software platform as abstracting applications from hardware and operating-system details through stable APIs, allowing software to become more portable across different automotive architectures.

That is a much bigger change than adding an infotainment app.

It changes how the vehicle itself is engineered.

Historically, a vehicle might contain a large number of electronic control units—ECUs—each responsible for a particular function.

One controls the windows.

Another controls the seats.

Others may control braking, steering, engine functions, lighting, climate systems, safety features and driver assistance.

Over time, the number of controllers and the complexity of the communication between them became enormous.

Software-defined vehicles increasingly move toward centralized or zonal electrical/electronic architectures, with high-performance computers handling functions that previously might have been distributed across numerous individual controllers. Bosch describes cross-domain centralized E/E architecture as an important foundation of the SDV.

That leads directly into another glossary term we will cover separately:

Zonal architecture.

The Smartphone Comparison Is Useful—Up to a Point

Software-defined vehicles are frequently compared with smartphones.

There is a reason.

When you buy a smartphone, the hardware matters enormously.

But the phone’s capabilities can continue changing after you buy it.

You can:

• Install applications
• Receive operating-system updates
• Add services
• Fix security vulnerabilities
• Change functionality
• Improve existing features

Software-defined vehicle developers want some of that same flexibility.

Bosch notes that SDVs can support new and improved functions throughout the vehicle lifecycle using over-the-air software updates.

But the smartphone analogy eventually breaks down.

A phone application crashing may be irritating.

Vehicle software controlling steering, braking or driver assistance can be safety critical.

That means the automotive industry cannot simply adopt consumer-software development practices wholesale.

An SDV still has to behave like a vehicle.

And vehicles have very little tolerance for software saying:

Unexpected error. Please restart.

Does an SDV Have to Be an Electric Vehicle?

No.

SDV and EV do not mean the same thing.

An EV is defined by its propulsion system.

An SDV is defined by the role software plays in the vehicle architecture and lifecycle.

A gasoline-powered vehicle could theoretically incorporate many SDV characteristics.

An electric vehicle could theoretically have a relatively conventional electronic architecture.

However, electrification and software-defined vehicle development are happening at the same time and often reinforce each other.

Electric vehicles depend heavily on software for:

• Battery management
• Charging
• Thermal management
• Motor control
• Energy optimization
• Range prediction

Add connected services, advanced driver assistance and automated-driving technology, and the amount of vehicle behavior controlled through software grows dramatically.

This is why EV and SDV discussions so often become intertwined.

They are different transformations occurring inside the same vehicle.

Over-the-Air Updates Are Important—but They Are Not the Entire Definition

One of the most obvious features associated with SDVs is the OTA, or over-the-air, update.

Instead of bringing the vehicle into a dealership for every software update, manufacturers can potentially deliver software remotely.

Updates might:

• Fix bugs
• Address security vulnerabilities
• Improve existing functions
• Update infotainment
• Improve battery management
• Modify driver-assistance functions
• Add entirely new capabilities

That is a powerful feature of the SDV.

But an internet-connected car capable of receiving an update is not automatically a mature software-defined vehicle.

ETAS makes a similar distinction when describing SDVs as more than merely connected vehicles.

The larger transformation involves the architecture underneath the vehicle.

The software needs to be sufficiently separated from individual hardware components.

Vehicle functions need to work across domains.

Software needs to be developed, integrated, tested, updated and maintained throughout the vehicle lifecycle.

The cloud may become part of that engineering system as well.

The Vehicle Is Becoming Part of a Larger Computing System

This is where the term becomes particularly interesting.

The software-defined vehicle does not necessarily end at the bumper.

Modern automotive software can involve:

Inside the vehicle

• High-performance computers
• ECUs
• Sensors
• Networks
• Operating systems
• Middleware
• Applications

Outside the vehicle

• Cloud services
• Software development infrastructure
• Digital twins
• Simulation environments
• Data analytics
• Fleet management systems
• Software update infrastructure

Eclipse SDV, for example, describes its open-source automotive effort as supporting software components for both in-vehicle and cloud-to-car systems.

The engineering boundary around the automobile is therefore becoming much less obvious.

The physical vehicle may be only one part of the system.

So What Is an SDS?

This brings us to the broader acronym:

SDS — Software-Defined System

Unlike SDV, which has become a widely used automotive industry term, SDS is a broader and less uniformly defined engineering expression.

It generally describes the same architectural shift applied beyond automobiles:

Move important system behavior away from being permanently embedded in specific hardware and make more of that behavior configurable, extensible or controllable through software.

The system could potentially be:

• A vehicle
• A factory machine
• A robot
• An aircraft system
• Industrial equipment
• A communications network
• A defense platform
• An energy system

The exact terminology varies by industry.

That is worth remembering when encountering the acronym SDS: unlike SDV, its meaning may depend more heavily on context.

Why Would Engineers Want a System to Be Software-Defined?

Hardware is expensive to change.

Software can be changed much more rapidly.

Imagine discovering after shipping a product that customers want a new capability.

In a hardware-defined system, adding that feature might require:

1. Designing new hardware.
2. Building prototypes.
3. Testing it.
4. Modifying manufacturing.
5. Producing the new version.
6. Selling customers another physical product.

With an appropriately designed software-defined system, some functionality can potentially be added through software.

That does not eliminate hardware engineering.

Quite the opposite.

The hardware needs to be designed with enough computing capability, interfaces, networking, memory, bandwidth and future capacity to support functions engineers may not have fully defined when the hardware was created.

That produces an interesting reversal.

Engineers used to ask:

What hardware do we need to run this feature?

Increasingly they may also need to ask:

What hardware architecture will allow software teams to create features we have not thought of yet?

Software-Defined Does Not Mean Hardware Does Not Matter

The terminology can be misleading.

A software-defined vehicle is still very much a physical machine.

It still requires:

• Brakes
• Tires
• Suspension
• Motors or engines
• Batteries or fuel systems
• Sensors
• Wiring
• Semiconductors
• Connectors
• Structural components
• Cooling systems

Software cannot brake a car without something physical capable of creating braking force.

It cannot steer without steering hardware.

It cannot measure the world without sensors.

Software-defined therefore does not mean software-only.

It means software has a much greater role in orchestrating and determining the capabilities of the hardware.

The hardware and software become increasingly interdependent.

This Changes Automotive Engineering Organizations

SDVs do not merely require different technology.

They require different engineering processes.

Traditional automotive development was heavily organized around physical subsystems.

Engine.

Transmission.

Chassis.

Electrical system.

Interior.

Body.

Software-defined development cuts across many of those boundaries.

A feature such as automated parking might involve:

• Cameras
• Ultrasonic sensors
• Radar
• Vehicle networks
• Steering
• Braking
• Vehicle dynamics
• Embedded software
• User interfaces
• Cloud services
• Cybersecurity

Which engineering department owns that?

The answer may be:

Several of them.

That is one reason SDV development creates organizational challenges as well as technical ones.

Bosch describes SDV development as requiring increasingly cross-domain engineering rather than treating vehicle systems as isolated domains.

SDVs Also Change Testing

Traditional vehicle testing never disappears.

Engineers will still crash cars.

Drive them in deserts.

Freeze them.

Shake them.

Run them around test tracks.

But software changes far more frequently than physical hardware.

You cannot build a physical prototype every time someone modifies code.

Software-defined vehicle development therefore relies heavily on virtual development and automated validation.

This is where several other acronyms become important:

• MIL — Model-in-the-Loop
• SIL — Software-in-the-Loop
• HIL — Hardware-in-the-Loop
• VIL — Vehicle-in-the-Loop

dSPACE, for example, is developing continuous testing workflows that combine SIL and HIL testing for SDV development.

We will cover MIL, SIL and HIL separately because they deserve their own explanation.

But their growing importance makes sense.

If software can change continuously, testing needs to become much more continuous too.

Then There Is Cybersecurity

There is one less pleasant consequence of making vehicles increasingly dependent on software and connectivity.

Software can be attacked.

A mechanical defect can create a safety problem.

A software vulnerability can create both a safety problem and a cybersecurity problem.

Software-defined vehicle engineering therefore requires security to continue long after production.

Manufacturers may need to:

• Monitor vulnerabilities
• Maintain software
• Authenticate updates
• Protect communications
• Manage cryptographic keys
• Patch deployed vehicles
• Maintain software for many years

The ability to update a vehicle remotely creates risk.

But it also provides one of the mechanisms for addressing that risk.

A vulnerability discovered after production can potentially be corrected with a secure software update rather than waiting for every vehicle to reach a service location.

Does “Software-Defined” Mean Manufacturers Can Charge for Everything?

This is where SDV becomes controversial for consumers.

If software can activate a feature after the vehicle has been sold, manufacturers can potentially sell:

• Optional features
• Temporary features
• Subscriptions
• Performance upgrades
• Connected services

Bosch explicitly notes that SDVs can support features and services delivered through subscriptions or individual purchases after the vehicle is sold.

Technically, that can be useful.

A second owner might activate a feature the original buyer did not purchase.

A manufacturer might add functionality that did not exist when the vehicle was built.

But customers may understandably feel differently when hardware is already installed in their vehicle and software simply prevents them from using it without another payment.

Software-defined vehicles therefore create not only engineering questions.

They create business-model questions.

And consumer-acceptance questions.

Is SDV Just Another Automotive Buzzword?

There is certainly plenty of marketing surrounding the term.

Almost every major automotive software supplier now talks about software-defined vehicles.

But beneath the marketing language is a genuine engineering transformation.

AUTOSAR continues developing standards and collaborative software intended to support SDV architectures, while the Eclipse Foundation operates a dedicated Software Defined Vehicle working group focused on modular, scalable open-source automotive software.

Those efforts would make little sense if SDV were simply another name for “cars have computers.”

The harder question is not whether the transformation exists.

It is:

How software-defined does a vehicle have to be before we call it an SDV?

There is not one universally accepted dividing line.

That is why the term can sometimes seem frustratingly vague.

A Simple Way to Think About SDV

When you encounter SDV, think:

The vehicle’s capabilities are increasingly determined by software, and those capabilities can continue evolving after the physical vehicle has been manufactured.

When you encounter SDS, think:

The same software-defined principle applied to a broader engineered system rather than specifically to a vehicle.

And when someone says a car is software-defined merely because it has a touchscreen and receives map updates?

It is reasonable to ask a few more questions.

Can vehicle functions evolve?

How tightly is software tied to individual hardware controllers?

Can applications operate across vehicle domains?

Can software be developed and tested independently of the final physical vehicle?

Can functions be safely updated throughout the product lifecycle?

How much of the vehicle’s behavior is really being determined by software?

Those questions get much closer to what software-defined actually means.

Why SDV Matters to Engineering

For a hundred years, automotive engineering largely revolved around making the physical machine better.

Better engines.

Better structures.

Better suspensions.

Better aerodynamics.

Better manufacturing.

None of that disappears.

But now automotive engineers also have to build a digital architecture capable of evolving alongside the physical one.

That changes how vehicles are designed.

How they are tested.

How engineering teams collaborate.

How suppliers interact.

How vehicles are maintained.

And potentially how long a vehicle can continue gaining new capabilities.

The car is still a machine.

But increasingly, understanding what that machine can do requires understanding the software running inside it—and the much larger software system surrounding it.

That is the idea behind the software-defined vehicle.