Trending Articles
Trending Topics
Trending
This article is part of our Opinions section, where we invite industry professionals to share their views on the most pressing technology questions of our era.
With modern vehicles now containing over 150 million lines of code, you’d expect the automotive industry to treat software development with the same rigour as vehicle manufacturing. Yet, carmakers are still approaching software like it’s 1995.
Original Equipment Manufacturers (OEMs) might well have perfected the discipline of manufacturing, but they’ve so far failed to apply this to software, staying stuck with legacy approaches. This is creating rabbit warrens of code, embedded in every aspect of the vehicle where small errors could lead to performance issues, compromised safety features, and even physical harm. With industry projections suggesting automotive code will have increased a hundredfold by 2030, this approach simply can’t continue.
For most carmakers, software still isn’t top of mind when thinking about manufacturing. Instead, it’s the physical production elements of complex robotics, assembling body components, and the installation of the engine. But in reality, software is just as vital as the petrol used in the engine.
Unfortunately, it’s nowhere near as organised. Across the sector, automotive developers are struggling with platform fragmentation and siloes across suppliers, which makes every new feature or update a nightmare to carry out.
In 2024 alone, there were over 28 million vehicles affected by recalls, and 13.8 million of those were linked specifically to software issues. Some might experience minor issues like a slightly buggy interface, but others could see their driver assistance systems impacted or even safety features like airbags and anti-lock brakes malfunction at critical moments.
Naturally, these issues land right back at the feet of the manufacturers with these wide-scale recalls. And the costs don’t just stop there. Bug fixes are estimated to cost ten times more with each development phase they progress to, giving those post-release bug fixes a hefty price tag. Manufacturers might be able to solve the issue in the short term, but it’s just delaying the inevitable.
At least the cause is clear. Technical debt.
Manufacturers might be coding state-of-the-art programmes, but they’re doing so on a fragmented foundation, on old vehicle architectures that simply can’t handle it. Coding might have progressed, but each new addition has bloated the entire codebase, making it more complex and ultimately creating a behemoth that’s almost impossible to update or add features to.
The traditional engineering response is often just to add another Electronic Control Unit (ECU), which is only a short-term fix and ultimately deepens the technical debt. Automaker development teams are left managing dozens of siloed ECUs from different suppliers, trapped in painfully slow update cycles. And this all has a knock-on effect as vehicles remain exposed to security vulnerabilities for far longer than necessary.
Right now, carmakers are managing this Jenga tower of software, but it’s simply not sustainable. That’s why it’s time for carmakers to treat software development like the body of the car, creating a repeatable production process with the same high standards and quality checks given to the rest of the structure.
But where should carmakers get started? The answer isn’t to throw even more developers, coders, or engineers at the problem. Without clear direction, there’s nothing to stop these teams from getting stuck in that same loop.
Change needs to come from the top with leadership that is focused on SDV, treating the software of a vehicle with the same reverence as its engine. If we turn to the other, more physical side of car manufacturing for inspiration, we can see the steps to take; we just need to adapt them to software.
Look at any car production line, and no matter the manufacturer, you’d recognise the same fundamental approach. The same needs to be said for software. Instead of each ‘software factory’ creating and following its own unique production processes with fragmented architecture, we need to either commit to standardised platforms or a cross-platform approach that’s suited to all. Once we’re all speaking the same language, testing, developing, and most importantly, bug fixes will become far easier, no matter what model of car the software is in.
Once we’ve got a unified approach, we can’t just leave it there. The code might be far simpler to understand and iterate, but it doesn’t mean it’s perfect. We need to establish regular testing of automotive software throughout the entire development process, not just after deployment. As we’ve established, it’s far easier and cheaper to iterate before the cars go out into the world than after. And, this approach will open learning opportunities from each production cycle, so we can keep refining the process.
Throughout all these changes, we need to keep the end-to-end process in mind. We aren’t just creating software that operates in isolation. Software architectures need to be iterative and flexible enough to adapt and work with the countless other components that make up the modern vehicle.
The skill and knowledge are already out there – software companies have proven these disciplines work at scale. We just need someone to drive the change from within, with the authority and vision to overhaul legacy approaches before they become untenable. Because until every OEM can apply the discipline of a vehicle assembly line in their very own ‘software factories’, cars will be stuck with a question mark over their reliability.
