Why We Need an Open Source Initiative for Software-Defined Vehicles
Today, the automotive industry is at the brink of a step-change in how we think about software. And it will very likely lead to a software-driven revolution that results in software-defined vehicles. Similar to the way controller area networks (CANs) changed electric interconnections in vehicles to electronic interconnections, the software-defined vehicle pushes function networks from electronics architectures into software stacks.
To support the transformation to software-defined vehicles, major players from the IT and automotive industries must collaborate to develop an open source in-vehicle application runtime stack. For more insight into why this initiative is needed, we need to first look back at how we got here.
Mega Trends Changed the Way We Think About Automotive Software
Over the years, there’s been a complexity shift. The advent of electric drivetrains has substantially reduced mechanical complexity in vehicles, cutting the number of control electronics and the amount of software required in this area.
At the same time, highly complex, software-centric use cases for autonomous driving (AD) have increased. And opportunities for product differentiation are increasingly moving into the software space. Vehicle mechanics are incredibly important, but very few everyday drivers care whether the chassis of a new car is two percent more rigid than last year's model.
To accommodate this complexity shift, optimize controller placement, and simplify wiring harnesses, software functionality is being integrated into high-performance central vehicle computers. In the past, there was only one high-end, mostly general-purpose computer in a car: the infotainment system. Going forward, we’ll see one, two, or more central vehicle computers that serve as integration platforms, hosts for demanding applications such as AD, and connectivity hubs.
Internet connectivity for vehicles is also on the rise, and has been for some years in high-end vehicles. This trend will only increase, and it puts the spotlight on something IT people have been talking about for a long time: Products that include a lot of software, are connected to the internet, and have long product lifespans need continuous, active software maintenance — at least for parts exposed to the outside world, and at least to perform security hygiene for such systems.
Beyond basic hygiene for vehicle software security, there’s growing consumer demand for a software experience that mirrors that of mobile devices and computers. Consumers are questioning why cars have to go to dealerships for software updates. And why vehicles, which cost so much more than mobile phones, feel outdated software-wise after a year or two.
Software-Driven Revolutions Enabled Scale, Speed, and Simplicity
There are a number of software revolutions that contributed to the software-defined vehicle revolution, but here are two notable examples:
- Personal computers. Prior to the MS-DOS operating system, programs were written for specific devices or device families. However, once a single operating system could be run on different hardware setups, it was the start of an industry that could create and sell computer programs at scale, and it evolved into the entirety of today's desktop software market.
- Smartphones. During the 2000s, a similar step-change occurred in the mobile handset industry. Initiated by Apple and quickly matched by Google, a highly fragmented device landscape evolved to become two competing multi-billion-dollar software ecosystems. This consolidation dramatically simplified application development and allowed software developers to far more quickly and easily deliver applications that run on almost all handsets.
The nature of how in-vehicle software is built and allocated today, along with the existing strategy for software maintenance in vehicles, creates a situation that’s similar to mobile phones in the early 2000s. Every piece of software is highly integrated with a specific product. There’s not much carry-over across generations. Platforms across the industry are highly fragmented. Maintenance tasks are individual and huge, and the percentage of software-based functionality is always rising.
The Automotive Industry Has Unique Requirements
While there are similarities between the drivers for the software revolutions described above and the situation today in the automotive industry, there are also important differences.
One obvious difference is that vehicles are far more expensive than smartphones and have much longer lifespans. These factors raise customer expectations. They also create challenges for organizations tasked with developing and maintaining software for more than a decade.
In addition, the sheer number of parts that need to be combined, and the wide variations in how things are done, make it almost impossible to take advantage of cross-industry platforms and scaling at the software level.
Finally, vehicles include numerous safety functions that simply cannot fail, or even provide less-than-optimal performance. The impact of not meeting safety requirements is very different from the slight inconvenience that occurs if a smartphone app is slow to start.
Achieving the Ultimate Goal Requires Open Collaboration
The ultimate goal of the open source software-defined vehicle initiative is to scale in-vehicle software across vehicle models, product lines, brands, organizations, and time. Getting there requires consideration of multiple dimensions, offers considerable room for ideas, and opens the door to numerous opportunities across a broad capability matrix (Figure 1).
Figure 1: Capability Matrix for Software-Defined Vehicles
One aspect to consider is software commodification and how to reap maximum benefit from all the knowledge, solutions, and building blocks that are being driven by the global IT community. There are a huge number of viable solutions and technologies, but the automotive industry will not win the war for talent by continuing to fragment developer attention with bespoke, industry-specific toolchains and niche know-how.
At the same time, the automotive industry is sitting on a treasure trove of knowledge and engineering expertise for addressing mission-critical functionality related to reliability and product safety. The challenge is to streamline application of this knowledge and enable efficient time-to-market for related products, as well as long-term software maintainability and support.
The overall automotive ecosystem — from deeply embedded in-vehicle software to consumer-facing backend services and all the layers and players in between — is huge and diverse. We can expect to see a lot of power plays, re-shuffling, and new business models during the coming years.
Incumbent players in the automotive industry have already been maneuvering for some time to find their positions in this emerging, software-dominated landscape. We read about companies that are following established patterns of achieving market dominance based on sales volumes and the amount of resources they plan to throw at the problem. At the same time, other companies are looking to embrace a more collaborative way of building their foundational software stacks.
The upshot is there is a lot of room to maneuver in this space, and a lot of opportunity for those who get involved.
Learn More at EclipseCon
For additional insight into the software-defined vehicle initiative and why it’s needed, attend Daniel Krippner’s presentation at EclipseCon 2021.
From Automobiles to Software-Defined Vehicles
Thursday, October 28
About the Author
Daniel Krippner is an enterprise architect and tech lead of the Software-Defined Vehicle project at Robert Bosch GmbH.
More from this Edition
Markus Spiekermann explains the Eclipse Dataspace Connector project's role in trusted data exchanges between organizations.
The EclipseSource team summarizes the latest technology initiatives and advances in the vibrant and rapidly growing Eclipse Cloud DevTools community.