How software-defined vehicles are redefining sustainability

Sustainability in automotive production is mostly discussed in terms of energy consumption, material use or CO₂-neutral plants. But with the rise of software-defined vehicles, part of the sustainability question is increasingly shifting into development. What is decisive is no longer only how efficiently a vehicle is built, but also how leanly it can be developed, validated, updated and kept technologically relevant over the years.

In the AMS livestream “Advanced Manufacturing and Sustainability” it became clear that software-defined vehicles open up a new lever precisely here. Jyothi Matam, Senior Technical Leader for Systems Simulation and AD/ADAS at Dassault Systèmes, described the change as one of the biggest changes in the industry. “This is one of the biggest transformations the automotive industry has experienced since the introduction of the assembly line,” she said.

Software shifts the sustainability lever into development

Whereas vehicle development used to be strongly shaped by hardware cycles, today more and more iterations are shifting into software. Components had to be built, tested, revised and tested again. Today, functions, systems and software versions can be virtually validated and later further developed via over-the-air update. This changes not only the speed of development, but also a vehicle’s environmental footprint.

“Manufacturers today need cloud-based simulation platforms that can validate software continuously and at scale,” said Matam. Equally important is end-to-end traceability from the original system requirements through the software code to final validation. This traceability is necessary for functional safety, cybersecurity and regulatory requirements. At the same time, it helps to avoid late correction loops, duplicated work and unnecessary development effort.

A central sustainability lever here lies in the lifespan of the vehicles. Matam pointed out that in the past, cars could quickly become technologically obsolete after a few years. In software-defined architectures, by contrast, the hardware remains largely the same, while functions, safety and efficiency can be improved through updates. “A key sustainability advantage is the longevity of the vehicle,” said Matam. “The hardware remains largely unchanged, while the software continues to evolve.”

Volvo relies on a common software base

How strongly this development is also changing classic OEMs was shown by Magnus Olsson, Vice President and Plant Manager at the Volvo plant in Torslanda. Olsson, who himself worked in vehicle development for many years, recalled earlier validation efforts at Volvo. For the safeguarding of the SPA platform, on which models such as XC60 and XC90 are based, they once calculated what quantity of hardware-in-the-loop test rigs would have been needed.

The result was drastic. “We calculated that we would have needed hardware-in-the-loop test benches the size of seven football pitches, running around the clock, seven days a week,” said Olsson.

For Volvo, the progress of the newer SPA2 and SPA3 platforms therefore lies above all in a shared software base. Improvements made today on the EX60 can be incorporated directly into future vehicle programmes. That reduces complexity, accelerates development and avoids redundant validation loops. “The real benefit of the new SPA2 and SPA3 platforms is that they share the same core software architecture,” said Olsson. “Every quality improvement we make today on the EX60 can be transferred directly to future programmes.”

This makes software architecture itself a sustainability issue. Because every additional software variant creates new testing effort, new validation and additional complexity.

Olsson put it accordingly clearly: “You really have to think of it as one platform. It needs a single software baseline across all products. As soon as you start branching the software into several independent versions, you create a problem for yourself.”

Validation becomes a system task

Matam also sees a fundamental change in validation in this development. Systems such as brakes, steering or chassis, which were previously developed more separately from one another, are converging in highly integrated computer architectures. As a result, assurance is shifting from the component level to the system level. “Control engineers, mechatronics engineers and software developers must work together as part of an overall system,” she said. “Verification and validation thereby become system tasks and no longer tasks of individual components.”

Legacy systems slow the data down

The same digital lifecycle applies just as much to the plants producing today's vehicles as to the software running inside them. Garrett Bell, who leads manufacturing transformation at JLR, described the practical difficulty of making older facilities part of that lifecycle. At Solihull, JLR partnered with Tata Consultancy Services to build a single view of energy consumption across the plant, eventually monitoring more than 5,000 individual data points. The challenge was not the software platform itself but the plant beneath it.

Bell explained that Solihull, like many long-established sites, had accumulated decades of body shops, paint shops and utility systems that were never designed to talk to one another. "You end up with a mixture of different body shops, paint shops, trim and final assembly areas, utility systems and generations of equipment that were never originally designed to work together," he said.

That experience pointed to a broader lesson about digital tools in manufacturing. Visibility alone does not reduce waste. Bell noted that JLR still spends roughly 60 per cent of its effort analysing data and only 40 per cent acting on it, a ratio he wants to reverse. "We should spend 90% of our time implementing improvements and only 10% generating the insights that guide those decisions," he said.

For manufacturers investing in simulation, digital twins and continuous validation, the same principle applies to development as much as to the factory floor. Digital infrastructure only pays off once it is matched by the ability to act on what it reveals.

However, this digital development is not entirely without its own environmental costs. Matam pointed out that simulation, virtual twins and AI-supported validation also require computing power and electricity. “Simulation also consumes computing resources, electricity and thereby causes a CO₂ footprint,” she said.

It is therefore crucial to use digital tools specifically where they avoid greater waste: fewer physical iterations, less duplicate validation, fewer late errors and better decisions earlier in the development process.

This also changes the role of production. Software-defined Vehicles are not only a topic for research and development. If platforms, software versions, validation and later updates become more closely connected, manufacturing must also become part of this digital lifecycle. Production data, software quality, traceability and later vehicle functions are becoming ever more closely intertwined.

The sustainability of future vehicle programmes will therefore not be measurable only in kilowatt hours per vehicle, material savings or CO₂-neutral plants. It is also reflected in fewer redundant platforms, fewer validation loops and vehicles that remain up to date for longer. Software-defined vehicles are therefore not an automatic sustainability gain. But if implemented correctly, they can help reduce waste across the entire life cycle.