The Device Chronicle interviews Sam Abuelsamid, Principal Research Analyst at Guidehouse Insights, on the evolution of the automotive industry towards software-defined vehicles and OTA updates. Sam develops and writes research reports on alternative fuels, powertrains, advanced driving technologies, and connected fuels. Guidehouse Insights is a premier market intelligence and advisory firm covering the global energy transformation with a focus on emerging resilient infrastructure systems.
Based out of Detroit, Sam has a background as an automotive engineer and automotive journalist. Sam still writes a monthly column on automated and connected vehicles for SAE Automotive Engineering. He also co-hosts the Wheel Bearings podcast. Wheel Bearings is an online conversation about some of the more exciting topics in the automotive and transportation world.
Sam is well-positioned to share perspectives on the challenges and innovation possibilities from the software-defined vehicle and the development of vehicle OS platforms.
The interview with Sam is one of several interviews we are doing with key opinion leaders in the automotive industry on the software-defined vehicle and the increasing importance of OTA.
Read other exciting strategy articles on software-defined vehicles and OTA from automotive OEM executives Mark Gerban, Leonel Leal, and Luigi Forcelli. These interviews build on the recent work by Northern Tech CTO and Mender co-founder Eystein Måløy Stenberg to lay out the essential requirements for automotive-grade OTA updates. These are important in light of the new cybersecurity standards for automotive, including ISO/SAE 21434 and UNECE R155/R156.
Chapter 1 - Challenges faced when developing software-defined vehicles
Sam begins the interview by pointing out that the biggest challenge with software-defined vehicles (SDVs) is ensuring safety. He says “In many areas of technology, if the software goes wrong, if there's a failure, if there's a bug, something crashes, the consequences may be annoying, but generally not life-threatening. That is not the case with automotive. When things go wrong in a vehicle weighing 3,000 to 9,000 pounds or more running down the highway, the consequences can indeed be life or death.” As a consequence of this, automotive OEMs must take even greater responsibility and care to ensure that the software distributed to vehicles is robust, safe, and reliable. They must minimize any opportunity for unintended consequences, unintended use of the software, or inappropriate use of that software or feature. This was emphasized with the recent recall of two million Tesla vehicles.
Chapter 2 - Transition from distributed embedded architecture to zonal architecture
Software in automotive is not a new phenomenon. Sam recalls that the automotive industry began using electronic controls and software in the early 1970s following the first round of emission controls and fuel economy and safety regulations. The industry started with engine management systems to manage exhaust emissions and improve fuel economy. And over time, manufacturers gradually added more and more features to the vehicles. Features have been added in an ad hoc fashion. San points out that “Each time a new feature was required, it would be supplied internally by the automaker or by a tier supplier. That feature would include sensors, actuators, and an electronic control unit (ECU) with embedded software. Whenever a feature was added, the OEM would have to find somewhere to package that ECU in the vehicle. These ECUs could come from dozens or hundreds of suppliers across the industry. That meant that OEMs had diverse systems that were not necessarily compatible with each other, making it very hard to update those features over time. The OEM couldn't update that software through connectivity or remotely if there were a bug. And so the vehicle would have to go into a service center to be updated or repaired.”
Now, the industry is shifting to a more modern architecture, knowing that there are hundreds or thousands of different features in the vehicle that are being consolidated, taking them off their dedicated ECUs, running on little microcontrollers, and putting them on more centralized computing. The evolution is towards higher performance computing, where an abstraction layer is being put between the applications, the functions, and the low-level embedded hardware. The OEMs are disconnecting each of these three layers, allowing for asynchronous development of the underlying computing hardware and the software layers. This in combination with modern wireless communications technology, is making it easier to use OTA to push out an update when there's a problem such as a security vulnerability, a bug, or when there is a need to enhance a feature and get that to millions of users.
Chapter 3 - Impact of the increasing influence of software
Software becomes more pervasive, its influence is more significant, and the hardware becomes commoditized. “As the software updates, the OEM can keep the underlying hardware the same because they have, to some degree, over-provisioned the computing hardware. If the manufacturer decides to switch from one computing platform, one System on Computer (SoC), main computer, zonal controllers, to a different one abstracted from the applications, they don't have to rewrite all those functions or applications to switch over.”
Chapter 4 - Software changing the business model for automotive OEMs
Sam stresses that software has had a significant impact, and will have an even greater impact on the automaker's business model in the future. He says “Traditionally, over the last 130-odd years of the auto industry, the model was that an OEM would design, build, and sell a vehicle, and that was the end of their connection to that vehicle, aside from providing service and repair parts over the life of the vehicle or having to do any updates for recalls for regulatory compliance. But once the vehicle left the factory, it would have the functionality that that car would have until the end of its lifespan, unless the customer maybe did some aftermarket things.”
Sam argues that ever since Tesla launched the Model S in 2012, the expectation has been that the vehicle will improve and gain functionality over its useful life because of its ability to do so much with software. So in the end customers are getting this expectation that they may wake up one day and suddenly their vehicle has a new feature, or they may decide that a feature that they either didn't need or couldn't afford at the time they purchased the vehicle is now available, they can subscribe or buy that feature at any point in the vehicle's lifespan and have that functionality added. And that, because traditionally, manufacturers didn't have to continue updating and supporting existing cars in the field, there was no associated cost. He stresses that “If an OEM is going to continue to update existing vehicles for five, ten years or more after the vehicles are in the field, there's a significant cost associated with doing that software development, validation, and distribution.” As a result, OEMs are looking at new models like subscriptions to functions, where there's a recurring revenue stream to help fund that, the cost of that software development and validation.
Chapter 5 - Evolution of automotive-grade OTA
Sam explains that one of the key reasons why the automotive industry has shifted towards these modern E /E architectures, and more centralized computing is to allow the capability to update the software on those vehicles more efficiently, more robustly. “The hardware footprint shrinks from 100 plus ECUs in a vehicle down to maybe a dozen or fewer than a dozen total compute platforms in the car. The OEMs want to reliably update this software.”
The OEM does not want to brick a vehicle while pushing out an OTA update. Bricking is where the device freezes when receiving a software update due to a loss of power or connectivity. In this case the dealership would have to send out a tow truck to pull that vehicle into a service center to then update everything and get it working again.
There are also costs associated with the distribution of that software. There are bandwidth costs for server ingress and egress costs of software storage and transmission.
Sam continues to say “And when you're going from a few tens of thousands or hundreds of thousands of vehicles Tesla had for most of the 2010s to suddenly potentially having to update tens or hundreds of millions of vehicles, those update costs can explode rapidly.”
To do that as efficiently as possible, you want to have relatively frequent updates to meet consumer needs, but you also want to have those updates as tiny as possible. That also reduces the potential for introducing new problems and bugs in that software.
Chapter 6 - OTA & business model development
Sam believes that Tesla has been the most successful OEM in harnessing OTA for business model development. He says “More so, having the OTA capability has attracted customers to the (Tesla) brand. But it has yet to be directly financially successful for them. The one exception would be their ability to sell their enhanced autopilot and quote-unquote full self-driving capabilities, even though Teslas cannot perform self-driving without supervision. But they have convinced customers to pay enormous amounts of money, thousands of dollars, for the software that has a meager marginal cost to Tesla and has helped them achieve profitability.”
But at the same time, the deployed fleet of Tesla vehicles in the field has expanded dramatically. Tesla has also shifted the way that they do their updates. They used to do all their updates over a cellular connection to the vehicle. When they had relatively few cars and those bandwidth costs were relatively modest, they could afford to do that as the number of vehicles on the road has exploded over the last several years. They have shifted away from that to relying on telling customers that If they want OTA updates, then their vehicles will have to be connected to a Wi-Fi connection at their home or somewhere else where Tesla is not paying for that connectivity, that bandwidth.
Ford has been successful in shifting its BluCruise hands free driving assistance to a monthly or annual subscription model. They seem to be getting reasonable uptake on this. Where OEMs have tried to get customers to pay subscription fees for heated steering wheels or seats in their vehicles, that has failed so far.
Sam believes It would help if the end customer would purchase a premium subscription plan to have OTA updates over a cellular connection. Many OEMs are trying to find ways to convince customers to pay for premium subscription plans for connectivity that will at least cover the bandwidth costs for OTA updates. So, most automakers have yet to figure out a perfect business model for how they will be profitable doing this. They have some ideas, but it's been slim right now. Some experiments, like BMW trying to get customers to pay for the subscription for heated seats or heated steering wheels in their cars, have been a “miserable failure.” Customers wanted to avoid paying for that. On the other hand, Ford is now experimenting with something similar to what Tesla has done, where they've shifted their Blue Cruise hands-free driving assist to a subscription model for which customers pay a monthly or annual subscription. And they are getting some reasonable uptake on that.
The OTA updates need to be able to work over multiple pathways into the vehicle and use whatever is most cost-effective. Of course, the one crucial thing is that the technology needs to be flexible enough to shift from LTE to Wi-Fi to whatever the cheapest available source of bandwidth is.
One of the other associated challenges is having multiple connectivity pathways in the vehicle, which also increases the number of potential attack surfaces for security problems. Cybersecurity, that's the other big challenge around doing OTA updates: the OEM must ensure that their entire value chain is as secure and resilient as possible from the software development. They must ensure that something doesn't get introduced early on in the software development process to their cloud infrastructure that is storing and deploying those updates to the vehicle itself. Even if there are not necessarily bugs in the software they are deploying, if there are vulnerabilities in there that an outsider can exploit, that can also cause various negative consequences. The OEMs must apply zero trust principles and security by design right from the beginning of the software development in the CICD right through to its deployment via the OTA.
Chapter 7 - OTA for safety, regulatory compliance & lowering costs from recalls
Sam agrees that OTA is essential for safety, regulatory compliance, and controlling costs around recalls for software fixes and hardware faults or conventions. Recalls cost automakers billions of dollars a year, and in some cases, if it requires a hardware change or a problem with the hardware design that requires a hardware update, an OTA update is not going to fix that. That will need the vehicles to continue to be brought into a service center to be updated and corrected to have hardware upgraded. But increasingly, OEMs control more vehicle elements with software and update them over the air without the end customer needing to visit their dealership. When the OEM identifies a safety problem, the vehicle must go into a service center, and the OEM must get the customers to bring their cars in on schedule. It's inconvenient for customers. It's costly for the manufacturers to have a technician plug in and do that update. One of the real potential benefits of OTA is the ability to push out an update to the entire vehicle fleet simultaneously.
Sam explains that there have been instances in the past where some manufacturers have had a recall, and it has taken multiple years to get the majority of the vehicle fleet updated. In fact, some cases are ongoing right now, for example, the Takata airbag inflators. That's a recall situation that has been going on for probably close to seven or eight years now, partly because of problems getting replacement components and getting the customers to bring their cars in to get the updates done. But for software issues, the OEM can get that done in a matter of days and update the entire fleet without disrupting their customers' lives and saving enormous amounts of cost.
Sam explains that in the US, the National Highway Traffic Safety Administration has a time limit of about two years; a minimum of 85% of the vehicle fleet has to be updated if there's a safety recall. And if they don't hit that threshold, the manufacturer must pay significant fines. Ram Trucks had an issue like that several years ago with their pickup trucks. So it's essential. And if it's a safety issue that needs fixing, it's not just a matter of fines or inconvenience. “The OEM wants to fix that problem before it impacts customers on the road, where it causes a safety problem, potentially leading to injuries or deaths.”
Chapter 8 - Next-generation OTA requirements
Sam concludes the interview by saying that the automotive OEMs are increasingly trying to figure out how to do OTA updates as reliably as possible. They want to avoid deploying a corrupted file to vehicles that could cause the vehicle to be disabled and necessitate a visit to a service center. “The entire process for doing that update to the vehicle must be as safe and secure as possible to minimize the potential for bad actors to push out an update to cars that would potentially cause vehicles to be disabled or allow someone, a bad actor, to take remote control of the car.”
OEMs look for security, speed, and cost control in OTA updates. For larger OEMs, the variations are complex regarding what they're trying to update. Configuration management is a massive part of this, particularly for legacy automakers with dozens of models in their lineup with various configurations. “If an OEM has five, 10, or 15 different models in their lineup, there will be different combinations of hardware. The underlying hardware in the vehicles will change if they have been in the field for five or ten years. Even with relatively few buildable vehicle combinations, the underlying hardware will change over time.”
Battery systems get updated, electric motors get updated, and engines get updated. The OEM has to manage all those configurations, ensuring they get the right piece of code into the right vehicle in the correct configuration. The OEM needs to ensure it has the right match to avoid sending the wrong code to a vehicle, causing it to be disabled, which is potentially a real issue. The optimal solution involves being able to query each vehicle, find out exactly what the configuration is, get the correct file, send that file to that vehicle, and ensure it gets updated correctly. It doesn't have a problem during the update process. Overall, it is a big challenge for the automakers.
Get in touch with Sam on Linkedin or by email: sam.abuelsamid@guidehouse.com.