The software-defined vehicle (SDV) is a key development in the transportation industry, encompassing electrification, connectivity, autonomous driving, and personalization. This is achieved through a combination of software and hardware and serves as a foundation for further advancements. In this blog post, we discuss why traditional monolithic software platforms and waterfall-style development models are no longer sufficient to meet the needs of this rapidly evolving industry.
Main Challenges in Software-Defined Vehicles
The main challenges facing automotive engineers designing software-defined vehicles are to adapt their vehicle development methodologies to not only use agile processes but also to leverage data analytics, and cloud-based tools while doing so. That is to create vehicles that are able to run cloud-native and efficient code. Connected and autonomous car development requires the use of 1) advanced sensors, cameras, and other IoT-like technologies, as well as 2) leveraging network slicing using 5G 3) using data analytics to process data from these sensors to enable functionality such as driver assistance, in-car entertainment, etc.
The Car software development process has been riddled with several inefficiencies, with automobile OEMs encountering difficulties that have resulted in production delays as well as negative user feedback. Legacy leaders have struggled to master the development of software-defined cars. The challenge is to find a way to make money off of vehicle data to improve both personalization and the driving experience “in-vehicle.”
Clearly, automobile manufacturers must redefine the vehicle development process to make software-defined vehicles (SDVs). Deloitte [1] has picked the following, in order of importance, as the top 10 most important software trends for the industry:
Historically (and prior to SDVs), new vehicles were typically created using a hardware-driven approach. In this model, the criteria are first documented, a concept car is developed, and then the sourcing of components is completed, after which the development, integration, and testing of software components occur in such a sequence. Test fleets of cars are then tested on the road to begin acceptance testing; this process is expensive with little room for innovation and agile development.
In recent years, car manufacturers have focused on speeding up vehicle development and reducing costs by decoupling both software and hardware. This involves creating and testing software for vehicles that don’t yet exist using data and insights from existing cars. This can be done using simulated, cloud-based environments. According to SBD Research, major car companies spend billions of dollars annually on software R&D, with costs ranging from $1,000 to $3,000 per vehicle sold. All of this leads to the conclusion that car development will follow industries such as financial services and telecom, in moving to a model of continuous development and integration where updates to running vehicles will happen through approaches such as CI/CD and GitOps. This is hard to do with cars because each one has more than 100 control units that do different things, like safety, entertainment, cameras, etc. Thus, it is no surprise that a modern car runs about 100 million or more lines of code.
So how do hyper scalers see this challenge?
From AWS[1] –
The outdated hardware and software architecture of traditional vehicles is not suitable for software-defined vehicles. Traditional vehicles have limitations in processing power, communication efficiency, and cost of wire harnesses. Vehicle OS initiatives address these issues by covering all aspects of the software stack, including chip-specific firmware, device operating systems such as Linux, Android, and QNX, abstraction layers, middleware, and application environments, both on and off the vehicle. Each OEM must evaluate the cost-benefit of implementing these different software layers.
Further, the processing of massive data volumes generated in the running of a modern car is a key capability in providing value-added services. Like with other industries, it is a challenge to ingest and process these data volumes, which can run into the tens of TB per day for AV/ADAS (Autonomous Vehicles, Advanced driver assistance). Cost, scaling, and analytic use cases such as simulation, and AI-based inference can be huge challenges from both an infrastructure and development standpoint.
Again, from AWS [1],
Automotive manufacturers are continuously challenged by the amount of data captured and created during the development and vehicle lifecycle, not to mention data produced by future car generations. This is accelerated by the need to design and launch incremental feature improvements.
Efforts to advance vehicle functionality have led to new approaches for storing, cataloging, and analyzing driving data captured from vehicles on the road today. Combining data from connected vehicle fleets transmitted over cellular networks with manually ingested data gathered during the development phase of new vehicles requires an advanced cloud-based data mesh architecture.
The goal of a data mesh is to create a single point of truth while treating data as a product and allowing a domain-oriented decentralization of data ownership according to existing organizational structures. This means each business unit retains ownership of its data, while simultaneously making it available to other business units. The Stellantis data mesh will be designed to collect and analyze vehicle and anonymized customer data and package it to create data products. Its potential future scope stretches from vehicle development to manufacturing, to vehicle sales and marketing, to after-sales services.
Data-driven organizations use information accessibility and collaboration tooling to accelerate development and encourage experimentation, all while lowering costs.
According to Deloitte[2]
The classic waterfall software development methodology has many shortcomings. Based on the aforementioned changes in technology architecture, automobile R&D will shift from the traditional waterfall development paradigm to an agile development strategy in the context of software-defined vehicles.
The key shortcomings of software-oriented automotive transformation are organizational structure and talent supply. The organizational structure of OEMs will fundamentally change, shifting from a function-oriented structure to a platform development structure.
Obstacles from the supply chain system. The connection between vehicle and parts enterprises changes from a tower-shaped vertical relationship to an annular flat relationship.
Supply chain system impediments. The relationship between vehicle and components firms shifts from a tower-shaped vertical to an annular flat relationship.
Conclusion
Now that we have set the stage, the next blog will discuss a framework called CAEdge, which has been designed by Continental Automotive. My goal is not to promote a certain platform, but to talk about it in terms of best practices for automotive software architecture.
References
[1] Reinventing Automotive Engineering for Software-Defined Vehicles https://aws.amazon.com/blogs/industries/reinventing-automotive-engineering-for-software-defined-vehicles/
[2] Deloitte “Software-Defined Vehicles – A Forthcoming Industrial Evolution” https://www2.deloitte.com/cn/en/pages/consumer-business/articles/software-defined-cars-industrial-revolution-on-the-arrow.html
Featured Image by Mikes-Photography from Pixabay