🅟🅘🅡 SciDev series: Software Define vehicles ; article A02

When Cars Became Computers

A reflection on the quiet revolution reshaping automotive manufacturing

There is a moment, familiar to anyone who has owned a smartphone for more than a year, when the device you bought feels genuinely different from the one sitting in your pocket today. Not because you replaced it but because it updated overnight. The camera got smarter. A bug disappeared. A feature arrived that didn’t exist when you unboxed it.

That moment is now coming for your car.

The Software Defined Vehicle (SDV) is not merely a marketing term. It represents a
fundamental inversion of how automobiles are conceived, built, sold, and experienced.

Software Defined Vehicle (SDV) is an automobile that implements core functions in software rather than hardware, allowing for features like over-the-air updates and enhanced connectivity. This represents a significant shift in automotive engineering, focusing on software as a primary component of vehicle functionality.

To understand why it matters, you first have to understand what it is replacing and why that old model, which served the industry so brilliantly for over a century, is no
longer fit for purpose.

The Legacy Model: Hardware as Destiny

The traditional automotive manufacturing model is, at its core, a hardware manufacturing model. A vehicle was designed around its physical architecture the engine, the chassis, the transmission and every system was purpose-built to serve
that hardware. The electronics were subordinate to the mechanics.
In this world, a car was finished when it rolled off the assembly line. Functionality was fixed at the point of sale. If you wanted adaptive cruise control, you specified it before purchase. If the manufacturer later improved its braking algorithm, your car never knew. The software embedded in the dozens, eventually hundreds of Electronic Control Units (ECUs) scattered across the vehicle was deeply tied to the hardware it controlled. Each ECU was a closed island, running proprietary firmware,
communicating through rigid, point-to-point wiring harnesses.
This architecture made perfect sense in an era when cars were electromechanical objects. It became a liability the moment connectivity, autonomy, and consumer software expectations entered the picture.

The numbers tell the story starkly: a modern premium vehicle can contain 150 or more ECUs and over 100 million lines of code, more software than a fighter jet. Yet that code is fragmented, siloed, and largely incapable of being meaningfully updated after the car leaves the factory.

The SDV Inversion: Software as the Product

The Software Defined Vehicle begins from a different premise entirely: the vehicle’s value is defined by its software, not just its hardware.

Hardware becomes the platform necessary, but not sufficient. A centralized compute architecture, often called a Vehicle Operating System (VOS) or a “zonal” architecture, replaces the sprawl of independent ECUs with a smaller number of powerful domain controllers or a central vehicle computer. This consolidation is not merely an engineering convenience. It is the enabling condition for everything that follows.

With a unified software layer sitting atop standardized hardware, the vehicle can now:

• Update over the air (OTA), receiving new features, performance improvements, and safety patches throughout its lifetime, just as your phone does.
• Separate hardware and software development cycles, allowing software teams to iterate continuously without waiting for the next vehicle platform refresh.
• Enable new revenue models, where features a performance mode, a driver assistance upgrade, a premium audio experience are unlocked by subscription or purchase after the vehicle is sold.
• Aggregate real-world data from millions of vehicles to train better algorithms, which are then pushed back to the fleet.

Tesla demonstrated the power of this model viscerally in 2014 when it pushed an OTA update that improved the stopping distance of the ModelS after a Consumer Reports concern a feat that would have required a physical recall in any legacy manufacturer’s hands.

Why This Is Different From Anything Before

The SDV model is not simply a modernization of the legacy process. It is a category change in what an automobile is.

The product never stops being designed

In traditional manufacturing, the design freeze the moment when no more changes are made comes months before production. From that point, the car is locked. In an SDV paradigm, the design freeze for software effectively never comes. A vehicle sold in 2025 can receive a materially improved version of its lane-keeping assist in 2027. The
product shipped is not the final product; it is version 1.0. This is alien to automotive culture. It requires manufacturers to think less like factories and more like software companies, maintaining live codebases, managing version control across a diverse fleet, and building relationships with customers that extend well
beyond the point of sale.

The supply chain relationship transforms

Legacy automotive procurement operated on rigorous, multi-year cycles. A Tier 1 supplier would win a contract for a specific ECU, deliver the hardware and embedded software to a specification, and that was largely the end of the relationship for that
vehicle generation.

In the SDV model, the supplier relationship must be continuous. Software interfaces need to be open and standardized enough that OEM developers and potentially third- party developers can write against them. This demands a shift from proprietary, closed supplier ecosystems toward something resembling the platform dynamics of iOS or Android: a controlled environment with defined APls, and an ecosystem of developers
building on top.

Several manufacturers are explicitly pursuing this. Volkswagen’s CARIAD software subsidiary, Stellantis’s partnership with Foxconn, and GM’s Ultifi platform all represent bets that controlling the software platform is as strategically important as controlling
the powertrain once was.

Safety and validation become continuous challenges

Perhaps the deepest tension in the SDV model is with the automotive industry’s foundational commitment to safety. Legacy vehicles were validated exhaustively before launch, and that validation was largely final. An OTA update that modifies braking behavior, steering response, or any safety-critical system raises an uncomfortable
question: how do you validate a vehicle that keeps changing?

Regulatory frameworks are still catching up. The UN’s WP.29 regulation has begun
establishing requirements for OTA updates and cybersecurity, but the industry is navigating largely new territory. The engineering discipline of functional safety
(governed by ISO 26262) was built for a world of fixed hardware and software. Extending it to continuously updated, connected vehicles is one of the genuinely hard
problems the industry is working through right now.

The talent base has to change

A traditional automotive OEM employed mechanical engineers, manufacturing specialists, and supplier relationship managers. The SDV model demands a talent profile that looks much more like a technology company: software engineers, cloud architects, machine learning specialists, cybersecurity experts, and UX designers who understand
the unique constraints of the in-vehicle environment. This is not a marginal adjustment. It is a cultural transformation. Companies like BMW and Mercedes-Benz have opened software development centers in Silicon Valley and across Europe, competing directly for talent with the companies that represent their
most disruptive competitive threat.

The Honest Tensions

Reflection demands honesty about what is hard, not just what is promised.

Not every manufacturer is positioned equally. Legacy OEMs carry decades of technical debt in the form of proprietary middleware, supplier lock-in, and engineering cultures resistant to the cadence of software development. Startups like Tesla, Rivian,
and Nio were born SDV-native; they did not have to unwind what came before.

The subscription model remains culturally contested. BMW’s experiment with heated seat subscriptions in certain markets provoked genuine consumer backlash. The idea that a feature physically present in a car you own must be unlocked by ongoing payment is, for many buyers, not a value proposition, it is an affront. The industry will need to develop more nuanced thinking about which features belong behind a paywall
and which erode trust when placed there.

Cybersecurity risk scales with connectivity. A vehicle that can be updated remotely can, in principle, be compromised remotely. The attack surface of a modern connected car — cellular modem, Bluetooth, Wi-Fi, GPS, V2X communication is vast. A cybersecurity incident affecting a manufacturer’s entire connected fleet would be
catastrophic in ways that have no precedent in automotive history.

What It Means, Finally

The Software Defined Vehicle is not a technological novelty. It is the automotive industry’s reckoning with a fact that every other consumer electronics category
absorbed decades ago: software is the product, hardware is the vessel.

The implications cascade in every direction through manufacturing strategy, supplier relationships, revenue models, talent acquisition, regulatory compliance, and the
relationship between automaker and customer. None of these transitions are simple.
Many of them are painful.

But the direction is irreversible. The car that parks itself in your garage tonight is already accumulating data that will make its successors smarter. The question is no longer
whether vehicles will be defined by their software.
The question is which companies will define the software that defines the vehicles.

The answer to that question will reshape one of the world’s largest industries and it is
being written right now, in code.

🅟🅛🅤🅖🅖🅔🅓🅘🅝🅡🅘🅓🅔 𝔼.𝕍.𝕖𝕣𝕪𝕥𝕙𝕚𝕟𝕘, 𝔼.𝕍.𝕖𝕣𝕪𝕨𝕙𝕖𝕣𝕖