For SDVs, Software Is The Biggest Challenge

Software-defined vehicles (SDVs) involve far more than just OTA applications enabling software upgrades over the air. Software that will manage hundreds of ECUs and other functions within the vehicle is expected to grow beyond hundreds of millions of lines of code, possibly making SDV software development the number one challenge in automotive design.

The benefits of SDVs, such as easy updates and opportunities for after-market revenue, are driving major automotive OEMs to invest in software-defined vehicle technology and approaches. Case in point: Volkswagen Group created a software division called CARIAD, which provides a scalable stack consisting of the software platform VW.os, a unified electronic architecture connecting to the VW automotive cloud. The company projects that by 2030, up to 40 million Volkswagen Group cars will run on CARIAD software.

But evolving from hardware-based automotive design to a software-based, software-defined vehicle architecture is a complicated process. Over the years, robust software development has presented many different types of challenges. As the number of lines of code increases, so does the degree of difficulty.

SDV hurdles
The unresolved issues facing SDVs include software development, cybersecurity, AI use, and system integration, among others. In order to build SDVs, automotive OEMs will need to learn to embrace software in the automotive development process. Initially, most OEMs will rely on Tier One and Tier Two suppliers to provide a solution, but eventually these OEMs will need to understand and master the software concepts and skills to make good decisions. Most importantly, the OEMs will need to determine how the software will impact the development and production schedule. It is easier to schedule the assembly of engines, chassis, interiors, and tires than to manage the software in a software-defined vehicle.

“Cross-industry collaboration is necessary to provide the infrastructure full SDV requires,” said Robert Day, director of automotive partnerships for Arm‘s Automotive Line of Business. “New SDV development methodologies must include both safety and security to ensure the car’s software-defined functions are reliable. The Scalable Open Architecture for Embedded Edge (SOAFEE) initiative is driving important collaboration among more than 100 automotive industry members. SOAFEE is introducing existing cloud-native methodologies and standards to automotive software development and deployment. At the same time this initiative is adding qualities such as safety and real-time that are needed for automotive software.”

The OEM’s budget is a significant concern in the transition to SDVs. “A software functionality that is dependent on hardware, such as a sensor or maybe a particular type of processor, can be deployed via download only if the hardware exists on the vehicle,” said David Muscat, segment chief engineer, architecture and networking business area at Continental North America. “Planning performance and resource availability for future upgrades and features is becoming more important, since this has a direct impact on vehicle price. Transitioning to an SDV architecture while maintaining the previous architectures also strains the OEM’s budget. Bringing together multiple vendors whose software is integrated in one electronic unit is not trivial.”

As the industry evolves, the traditional automotive design model will not work for the electric and autonomous vehicles of tomorrow. Those will require a complete redesign of the vehicle architecture to a software-centric approach.

“One of the main challenges is clarifying the concept of what a software-defined vehicle means, as there are varying interpretations among OEMs,” said Pedro López Estepa, director of automotive at Real-Time Innovations (RTI). “The challenge primarily revolves around establishing industry-standard hardware interfaces, vehicle APIs, and data models. Enabling collaboration with a strong ecosystem that includes new suppliers offering unique capabilities, as well as integrating traditional supply chain vendors, aims to mitigate risk while ensuring system scalability and future-proofing.”

Software development challenges
SDVs face some challenges including managing a massive amount of software. There are challenges in producing error-free code, testing, keeping track of updates and changes, and keeping the software secure.

“Within today’s premium vehicle we can have up to 150+ embedded ECUs,” said Sven Kopacz, autonomous vehicle section manager at Keysight Technologies. “Turning these into vECUs will take at least 100 million lines of code, with some estimates predicting an increase to 300+ million lines of code by 2030. With this many lines of code, we can easily imagine what could go wrong, or what should not go wrong, within our next-generation transportation and vehicles.”

And realistically, there never will be software that is truly error-free or vulnerability-free. “With continuous innovation and development of integrated hardware, software, and cloud solutions, it is inevitable to hit corner cases that will introduce errors or vulnerabilities,” said Vito Giallorenzo, senior vice president, general manager of IVY, and head of corporate development at Blackberry.

However, there is a lot that automakers and their suppliers can do to limit those vulnerabilities, both in pre-production testing and in post-production via frequent and effective over-the-air updates.

“Automakers and their suppliers need to continuously review and improve the testing approach in design and development, as well as look for new tools that automate and increase test coverage of their products,” Giallorenzo explained. “Cloud emulation is a major innovation that is coming to the industry to facilitate development and testing. Historically, testing of embedded software solutions has been hindered by the lack of chipsets and hardware, which is required to properly test complete hardware-plus-software solutions. This was particularly painful during the recent COVID-induced supply chain crunch.”

BlackBerry and others are working with cloud providers such as Microsoft Azure, Amazon AWS, and Google to develop digital twins of these automotive embedded systems, as digital twins can enable distributed R&D teams to efficiently build and test software in the cloud without the need to ship and build physical hardware systems in their labs. In effect, the cloud becomes the repository glue for engineering teams, regardless of where they are located.

Better code
Integrating software testing into the development workflow as early as possible is the best way to produce error-free code.

“As soon as the software engineer starts to write a line of code, having static code analysis integrated within the IDE or editor to identify violations of safety and security coding standards immediately increases code quality,” noted Ricardo Camacho, director of Regulatory Safety and Security Compliance for Parasoft’s embedded testing solutions. “By doing so teams identify these issues early, and they’re not left for later in the development life cycle when they’re more difficult to find and more expensive to fix. This is just the start. Each function or unit of code needs to be tested to ensure that it’s robust enough to handle any rainy- or sunny-day scenario possible. And as the developers begin to integrate their software with each other’s software, the complexity grows, and the need for integration testing becomes crucial.”

Other testing methods, like performance, stress and load tests, as well as testing to requirements, are also vital. “Satisfying requirements ensures that you are building the right product — a safe, secure, and reliable one,” Camacho said. “As software components get integrated into a system, system testing must take place. At the system level, testers are testing end-to-end functionality, bombarding it with data, even pressing buttons and turning knobs if they are there. Then acceptance testing takes place to ensure that the stakeholder is going to receive what they are paying for. Software testing at each abstraction level of software development is different, and has the purpose of producing error-free code.”

Further, DevOps principles introduce Continuous Integration/Continuous Testing/Continuous Delivery-Deployment (CI/CT/CD) – fully integrated, automated, and robust processes enabling rapid development, testing, and continuous code/function deployment.

“While in traditional processes the functional and system testing phase was done in isolation or after the car assembly with human-based testing, DevOps integrates continuous testing at the earliest concept phase,” Kopacz said. “This DevOps integration means testing is not limited just to new features. Any change in the software requires that everything tested previously be tested again to make sure it still works. This is known as regression testing. Even with a large team of testers, it is impossible to do this manually because the set of tests keeps growing every day. Therefore, either the team size or the test times would need to grow proportionally, both of which are unacceptable.”

This also means that a car cannot be taken to the test track for regression testing. “On the track we can never create the exact same test conditions, so we can never be sure that everything still works as intended,” he explained. “What is needed is a way to move manual testing on the test track to fully automated testing in the lab and make it part of a DevOps cycle. It is also important to note that with each change in the code, a potential vulnerability may be introduced. So as another part of the fully automated testing, cybersecurity penetration tests are executed on the new code with every iteration, which results in a DevSecOps (development/security/operations) methodology.”

Keeping track of changes, updates
Being able to update software over-the-air is convenient, but it comes at a price. Keeping track of all the changes cannot be ignored. Modern vehicles may have hundreds of ECUs, and the software controlling them may not come from the same supplier. Additionally, changing one part of the software within an SDV may impact the other part. Therefore, it is crucial to keep track of the changes. Otherwise, new software problems may be created as a result of an update.

“Software updates come in two flavors – FOTA (firmware over-the-air) and SOTA (application software over-the air) updates,” said Prakash Madhvapathy, director of product marketing, Tensilica audio/voice DSPs at Cadence. “FOTA affects the underlying OS and system software, while SOTA updates the application software. FOTA is more critical as it affects multiple applications, including ECU management code. In either case, the update mechanism must allow the end customer to revert to the previous version if the customer faces issues with the new firmware or software.”

Collecting customer feedback is also important to know why the update was reverted, and to make changes as necessary.

“Customer education campaigns may need to precede both push and customer-initiated updates to help them understand the value of the updates and/or to gain their confidence,” Madhvapathy said. “Keeping track of the multitudes of models, customer behaviors, preferences, software versions and contexts over the lifetime of the car is no easy task, and can be exacerbated by ownership changing hands or exit from and re-entry into the service range. Features also may be activated and de-activated temporarily by the driver, say for a long road trip. Software and databases must handle such ephemeral feature activations and billing. Questions as to the transfer of software enabled features with a change of ownership and the ramifications to software design may need consideration.”

Security
A cybersecurity compromise is always serious for the company, organization, or individuals who are affected.

“The uniqueness of protecting an automotive system really lies in the complexity of the landscape that needs to be protected,” said Avijit Sinha, chief product officer at Wind River. “Even though the electrical architectures of a vehicle will simplify as SDVs become reality, vehicles will still be a system of federated computing systems working together to operate the vehicle. The challenge with this will likely be ensuring that consistent and robust security techniques, procedures, and implementations are realized across these federated systems, which are potentially each delivered from a different supplier.”

Where is the finish line?

Fig. 2: The SDV technologies will continue to evolve well beyond 2035. Source: “Rewriting the Rules of Software-Defined Vehicles” report. Boston Consulting Group (BCG) and the World Economic Forum

Some technologies have a finish line. For example, once the popular USB3 standard has been established, all USB3-compliant devices will use the same standard and will not deviate from it until the next revision. But for SDVs, there is no finish line. It will continue to evolve. The migration from hardware-based to software-based vehicles will take a long time. Then it will continue to change with new architecture. Each OEM will define its own path.

Some automotive standards, such as the AUTomotive Open System Architecture (AUTOSAR), may be adopted by OEMs in their own way. According to the AUTOSAR Software Industry Report 2020, the ‘Core Partners’ includes the BMW Group, Bosch, Continental, Daimler, Ford, General Motors, the PSA Group, Toyota, and the Volkswagen Group.

Mercedes-Benz, while adopting AUTOSAR Classic as well as AUTOSAR Adaptiv, also included Linux and QNX in its design. For future development, it has the MB.OS chip-to-cloud architecture, which enables the decoupling of software and hardware.

“The automotive industry is consolidating disparate embedded chips into central heterogeneous SoCs to achieve the compute power and energy efficiency required by compute-intensive algorithms, such as the artificial intelligence algorithms required for autonomous behavior,” said Verena Beckham, chair of the Khronos SYCL SC Working Group. “One of the challenges is selecting the right programming model to enable efficient, portable, and safe code for these systems to be developed and certified easily. The SYCL SC Working Group in Khronos is working on such a programming model, which is based on SYCL and C++, but is being designed specifically to ease safety certification. Due to the popularity of AUTOSAR’s Adaptive Platform, Khronos is collaborating with AUTOSAR members to enable SYCL, and eventually, SYCL SC, to be used from within an AUTOSAR architecture to unlock the ability to offload computation to accelerators, such as GPUs.”

New SDV architecture needed
In the foreseeable future, SDV designs will include a mixture of software operating systems, hundreds of ECUs, and more sensors to support the L3 to L5 transition. In the long run, however, OEMs would much prefer simpler automotive architecture and networks, as well as manageable software stacks.

“For a full software-defined vehicle, where the functions in the vehicle are easily deployed and updated, a new zonal and central compute architecture is being recommended,” Arm’s Day said. “The zonal controllers will link to the sensors and then use high-speed communication to transfer the large amount of data to the central computer that will be running the software-defined functions. Automotive operating systems still will be required for real-time and safety functions, but general-purpose operating systems also can be used for functions like infotainment. Technologies such as virtualization and containers running on the central compute architecture will allow these operating systems and their software-defined functions to run without fear of interference from each other.”

Regardless of the vehicle electronic system architecture, there will be a need for a safe and reliable operating system to provide abstraction and connection to the hardware.

“As the demand from customers for more complex software grows, it will be crucial to implement a modern and proven operating system like Linux,” noted Francis Chow, vice president and general manager, in-vehicle operating system and edge at Red Hat.

How SDV impacts the supply chain
SDVs impact the entire supply chain, not just OEMs. Tier One and Tier Two suppliers will need to work together to support the automotive OEMs. Unlike mechanical parts, software from different suppliers may interact with each other as data is passing through from one device to another. When problems occur, it would require multiple parties to simulate and duplicate the symptoms in order to troubleshoot the problems.

“Various software providers will have to work even closer together,” said Chris Clark, senior manager, automotive software and security at Synopsys. “About three to five years ago, a Tier One manufacturer of a brake controller, for example, would design a system looking for some messages from another device or subsystem and perform the braking functions. That has expanded substantially. Not only is the ECU performing those activities, it needs to provide feedback on how it is operating, and its capabilities are based on the environmental conditions of the vehicle. If it has a software update, when is it safe to apply that software update in that activity? This opens up a very complex and challenging environment for all participants in the automotive space.”

There are a lot of benefits that come along with this, however. “One of the topics that everybody gravitates to is OTA as a huge game changer,” Clark said. “When we talk about SDV, there is an entire process of how to architect the vehicle at a more holistic level. Part of that activity is how to do the update. This is where OTA comes into play as a part of this overall activity. OTA not only provides software updates that go to the systems running within the vehicle, but also serves as the transport for that information that has been generated, collected and analyzed at the vehicle level before it is sent back to the OEM or the party that needs to get a better understanding of how the device and the overall vehicle are performing. It’s interesting to see all these players having to work more closely together and develop these solutions that are providing far more capability than drivers ever thought possible, but also doing that in a way that is cost-effective over time.”

Conclusion
In the foreseeable future, the number of lines of code for SDVs will continue to grow. This will present a number of challenges including managing a massive amount of software, difficulty in producing error-free code, intense software testing, keeping track of updates and changes and, finally, keeping the software secure. OEMs will have to continue to face these challenges indefinitely, as there is no finish line in sight.

Related Reading
Growing Challenges For Increasingly Connected Vehicles
OEMs have high expectations for connected vehicles and global growth opportunities, but it’s not that simple.
Designing Vehicles Virtually
Increasing electronic content will require more simulation to keep pace with growing complexity and continual changes and updates.