By: Gary Cygan, Director of Software and Electronics Engineering

For most of automotive history, success meant optimizing each vehicle program for its specific customers, business case, and technical requirements.

Truck teams emphasized capability, durability, and cost. Luxury vehicle teams optimized refinement and differentiated experiences. Electric vehicle teams focused on range, charging, and energy efficiency. Each program tailored its decisions to its customers, business case, and physical realities. That model produced some of the industry’s most successful vehicles.

The software-defined era introduces an additional challenge.

Increasingly, competitive advantage depends on digital capital: the reusable digital assets, infrastructure, and engineering capabilities that can create value across a vehicle portfolio.

Every vehicle program has valid reasons to consider a different controller, sensor, interface, or software implementation. These decisions may improve the economics, timing, or execution of an individual product. Across a portfolio, however, added variation makes software more difficult to reuse, integration more complex, and validation more extensive.

This creates a fundamental tension for established automakers: The decisions that maximize value for an individual vehicle program do not always maximize value for the portfolio.

This is not a failure of individual programs or teams. It reflects a broader challenge as program value and portfolio value are measured differently, and the long-term effects of digital variation are not always visible at the point of decision.

GM is addressing this tension through its approach to the software-defined vehicle. The objective is not simply to build more software. It is to improve the return on digital capital.

Digital capital: From investment to reusable productive capacity

The analogy to physical capital is useful. Money, engineering effort, and time are invested to build plants, equipment, and tooling. Those assets create productive capacity over many years. Their value depends on how effectively they are used, maintained, and improved.

Digital systems follow a similar pattern.

Digital investment is the money, engineering capacity, and organizational attention committed to creating, validating, operating, securing, and improving digital capability.

Digital assets are the resulting reusable components: software and foundational services; computing platforms, interfaces, and communications systems; automated tests, validation environments, and engineering evidence; cybersecurity protections; diagnostics, data infrastructure and over-the-air delivery systems; development tools; cloud infrastructure; and engineering workflows.

Digital capital is the portfolio-level productive capacity created when those assets are integrated, maintained, and reused across vehicle programs. It also includes the embedded engineering knowledge and operating practices required to make them valuable over time.

These terms describe a progression from commitment to capability to value. Digital investment is what the company commits. Digital assets are what it builds. Digital capital is the enduring productive value those assets create when they can be reused and improved across the portfolio.

A digital asset can benefit multiple vehicles, strengthen future capabilities, and preserve engineering evidence for later use. It can also become obsolete, fragmented, or too costly to maintain and may eventually be retired and replaced. Its value therefore depends on its future usefulness relative to its lifecycle cost—not simply on the amount originally spent to create it.

Like physical capital, digital capital requires investment, maintenance, utilization, and lifecycle management. Its return comes from reach and reuse.

Here, return includes avoided duplication, faster development, lower lifecycle cost, reduced defect exposure and greater customer value—not only direct revenue.

A software service developed for one vehicle can benefit others. A defect corrected in a common foundation can protect multiple programs. A cybersecurity improvement can strengthen every compatible vehicle. A development tool can improve the productivity of many engineering teams.

Validation is also part of digital capital. When a defect or edge case is discovered in simulation, on a hardware test bench or in a development vehicle, the correction, test and engineering evidence can become reusable digital assets that improve future vehicles.

Over time, linked requirements, test results, issue resolutions, and validated improvements can create a reusable evidence base. This does not eliminate vehicle-specific validation. It can, however, reduce unnecessary duplication and allow prior engineering evidence to benefit more programs.

Common architecture enables greater software reuse. Software reuse supports more common testing. Common testing builds reusable evidence. Reusable evidence helps improvements move across the portfolio with greater confidence.

Each digital investment can add to the digital capital created by earlier investments. That value can compound, but only when it is managed as portfolio-level digital capital rather than as a collection of program-specific deliverables.

Digital capital does not compound automatically. It requires architectures, development practices, validation systems, and operating models that allow investments made once to create value many times across a portfolio. Developing those capabilities is a foundational part of realizing the promise of the software-defined vehicle.

The invisible factory problem

Consider a plant designed to build four different vehicles. An automaker invests billions of dollars in facilities, equipment, and tooling, expecting that specific investment to be used to build that specific portfolio of four vehicles.

If the second vehicle in the portfolio needed an unexpected design change that required another plant and billions of dollars of additional investment, the decision would receive intense scrutiny. The cost would be visible, measurable, and directly connected to the vehicle's business case.

Physical capital makes tradeoffs difficult to ignore. Digital capital is different.

A vehicle program may choose a different software implementation, controller, or interface to reduce an immediate cost or address a timing constraint. Individually, these decisions can appear reasonable. Collectively, they can create additional software to develop, interfaces to integrate, environments to test, cybersecurity surfaces to protect and updates to maintain throughout the life of the vehicle.

The digital investment is real, but it is distributed across engineering, validation, cybersecurity, tooling, and product-support organizations. Because the costs are dispersed over time and across teams, the full portfolio impact is often less visible than an equivalent physical capital investment.

This is the invisible factory problem: decisions that would be evaluated as capital-allocation choices in the physical world are often treated as local engineering decisions in the digital world.

As variation accumulates, engineering capacity shifts from creating new capabilities to integrating, validating and maintaining existing ones. The greatest cost of fragmentation is not the complexity it creates. It is the innovation it limits.

From program economics to portfolio economics

A vehicle program must still deliver the right product at the right cost and time. Its software and electronics decisions also influence the return on the company’s broader digital capital.

The answer is not maximum commonality, nor is it the elimination of vehicle-specific engineering. It is distinguishing between differentiation that creates meaningful customer value and variation that unnecessarily recreates work. This requires managing digital capital intentionally.

Shared digital assets and the capabilities that support them need clear owners, investment plans, reuse expectations, and lifecycle accountability. Program decisions should consider both the immediate benefit of variation and its longer-term effect on the portfolio’s digital capital.

This broader perspective does not prevent exceptions. It ensures that their full value and cost are understood.

When considering a variation, teams can evaluate the additional software and validation it will require, how long it will need to be maintained, and the cybersecurity, diagnostic, and update obligations it will create. They can also consider whether future capabilities will need to be adapted separately and how much engineering capacity the variation will require after launch.

The core question is whether the immediate vehicle-level benefit justifies the additional digital investment and the resulting lifecycle cost to the portfolio.

Creating long-term value requires balancing vehicle-specific needs with portfolio-level considerations. Vehicle programs bring critical knowledge of customers, products and execution. Platform teams bring visibility to reuse, lifecycle obligations, and portfolio complexity.

Engineering for scale and differentiation

Designing an electrical and computing architecture for a single vehicle is relatively straightforward. The greater challenge is engineering a common digital foundation that can scale across a diverse portfolio while supporting the differentiation required by distinct vehicle types, propulsion systems, and customer expectations.

GM is solving this challenge through a next-generation electrical and centralized computing platform. The platform is designed to provide common foundations where scale creates leverage while preserving flexibility where vehicle-specific engineering creates value.

A software-defined vehicle platform cannot be optimized solely for commonality or solely for differentiation. It must enable both. The engineering challenge is determining where commonality creates leverage and where differentiation creates value.

Packaging: Defining architectural homes

Engineers must determine not only where hardware belongs within a vehicle, but also where functions should reside within the overall architecture. That makes packaging both a physical and a logical decision.

The platform’s Central Compute Unit, or CCU, provides a common home for computing-intensive capabilities such as infotainment, active safety, perception, and selected vehicle services. At the same time, some functions remain closer to the hardware they manage because of safety, timing, diagnostics, regulatory requirements, or specialized interfaces.

The objective is not to centralize everything. It is to define architectural boundaries intentionally and apply them consistently across the portfolio.

Power: Managing energy as a platform resource

Power management is becoming increasingly important as vehicles rely more heavily on software, connectivity, and compute.

Software plays a growing role in coordinating power delivery, managing device activation, isolating faults, and optimizing energy consumption throughout the vehicle.

GM’s approach is to establish common power-management strategies, interfaces, and software services that can be reused across the portfolio while supporting the specific electrical requirements of different vehicles. This creates a shared foundation for managing energy without forcing every application into the same physical solution.

Propulsion: Common interfaces, different physics

Few areas illustrate the balance between scale and differentiation more clearly than propulsion.

Internal-combustion, hybrid, and battery-electric vehicles must solve fundamentally different problems. Engine controls, battery-management systems, charging systems, and power electronics each have unique timing requirements, operating constraints, and physical architectures.

These differences should not be forced into artificial uniformity. Instead, the platform provides common interfaces, software foundations, and development practices while allowing propulsion-specific systems to remain optimized for their distinct requirements.

This allows diverse propulsion systems to benefit from shared digital capital without sacrificing the capabilities that make each vehicle successful.

Thermal: Shared strategies, different systems

Thermal management presents a similar challenge. Gasoline vehicles can use engine-generated heat in ways electric vehicles cannot. Electric vehicles must carefully manage batteries, power electronics, charging, and cabin temperatures. Hybrid vehicles combine elements of both.

The objective is not a single thermal solution for every vehicle. It is to establish common software, controls, and interfaces where they create value while preserving the propulsion-specific systems required by each application.

Together, packaging, power, propulsion, and thermal management illustrate the engineering discipline required to achieve both scale and differentiation.

The software-defined vehicle is not about making every vehicle the same. It is about creating common digital foundations that reduce unnecessary variation while preserving the differences customers value and vehicle physics require.

That principle extends beyond technology. Common architecture without common development practices, reusable validation assets, clear ownership, and portfolio governance can still create fragmentation. GM is therefore connecting the architecture with changes in how software is developed, validated, secured, deployed, and improved.

The strategic question is not whether vehicles should be different, but how to determine where differentiation creates customer value, where commonality creates portfolio leverage, and how the two can coexist on a shared digital foundation.

How GM is turning digital capital into customer value

GM is addressing this challenge by developing a common digital foundation that can scale across a broad and differentiated vehicle portfolio.

Centralized compute, high-speed networking, and shared software are important parts of that foundation. But GM’s approach goes beyond the technology itself. It connects architecture with common development practices, reusable validation assets, cybersecurity, engineering tools, clear ownership, and portfolio-level decision-making.

Together, these elements are designed to allow software, testing, and engineering knowledge developed for one application to create value across many others. As the platform scales, each improvement can strengthen a growing foundation rather than remain isolated within a single vehicle program.

Customers may never see that foundation directly, but they experience what it enables: faster fixes, more effective updates, better quality, increasingly capable features, and digital experiences that improve over time.

The new architecture enables up to 35 times more AI computing power for autonomy, a two-to-four-times improvement in infotainment performance, 10 times more software updates for new features, and up to 1,000 times more bandwidth than its previous system.

These metrics are important, but the larger transformation is in how GM creates, manages, and reuses digital capability.

GM is not solving this by making every vehicle the same. Trucks will continue to be trucks, and Cadillacs will continue to be Cadillacs. Different propulsion systems, customer expectations, and product missions will continue to require thoughtful engineering and differentiated solutions.

The objective is to preserve what should be unique while sharing what creates portfolio leverage.

That’s why GM is building a common architecture capable of supporting different vehicle types and propulsion systems while also changing how software is developed, validated, secured, deployed, and improved. The architecture and operating model are being designed to work together.

GM is improving the return on digital capital by: reducing unnecessary variation, making engineering assets more reusable, and enabling each new investment to build on those that came before it. The work is difficult because it requires balancing immediate program needs with long-term portfolio value. GM’s scale makes solving that tension especially important and valuable.

This is the larger promise of the software-defined vehicle. Its value does not come from centralized compute alone. It comes from combining excellent, differentiated vehicles with the ability to share software, validation, and engineering investment across an enterprise.

GM is building the technology, engineering systems, and organizational discipline required to do both. And, it’s how we’re turning the auto industry’s next capital discipline into a competitive advantage.