OTA Software Updates Need to Be Reversible

Recently, Guidehouse Insights published a white paper with Aurora Labs titled 5 Preconceptions about OTA Updates. In it, we look at challenges that must be addressed in order for automakers to have successful strategies for deploying over-the-air (OTA) software updates. One of those preconceptions that must be overcome is that automakers shouldn’t go backward on software updates. A recent incident with a Tesla owner in Canada illustrates exactly why automakers need to have a mechanism to reverse changes when something goes wrong.

Since 2016, Tesla has had a feature on its cars called Summon. BMW first introduced the same basic feature in 2010, and many Hyundai Motor Group vehicles have had their own version called Remote Smart Parking Assist since 2018. Summon and other similar features allow the driver to remotely park a vehicle in, or retrieve a vehicle from, a narrow parking space where it’s not possible to open the doors. Standing outside the car and using either a smartphone app or key fob button, the driver can move the car forward and reverse.

It’s not a particularly complex feature, and it can be quite handy in many situations. Unlike some other driver assist features, it appears to have been largely trouble-free for most Tesla owners for 8 years. However, with the recent update to software version 12.5.4.1, an owner in Halifax, Nova Scotia, found that he was mostly unable to use his Model 3. The owner has an unusual living arrangement with a relatively narrow driveway between his home and his neighbor’s. The Model 3 just fits into the gap, but the doors can’t be opened when it’s parked, so he has used the Summon feature for more than 4 years without issue.

When Summon was first launched, Tesla used radar and ultrasonic sensors for the driver assist features in addition to cameras, but the company has gradually removed the use of the active sensors. The latest version of Summon, which uses cameras exclusively, detects the proximity of the walls on either side of the car and mostly refuses to move it, giving a variety of different error codes.

A regression like this isn’t entirely uncommon in software development, although ideally, there would be sufficient testing to ensure that features that work don’t get broken. Aside from Tesla’s dubious choice to rely exclusively on cameras, the real challenge here is that there is apparently no way for the owner of this car to have it reverted to the prior software version that worked.

There are practical reasons for not allowing software to be reverted to an older version, mostly having to do with security. If an update addresses a security vulnerability, it’s undesirable to let bad actors have a way to flash older versions of software that could then be exploited. On the other hand, if developers have erred with an update, it’s important to have a pathway to fix it rapidly, especially if the error effectively leads to the product being disabled.

Admittedly, this particular situation is a classic example of an edge case, but it’s also one that should be fairly straightforward to remedy. While OTA updates are widely regarded as a great way to provide customers with a positive user experience that makes the product better over time while potentially saving millions of dollars in warranty repair costs, the process is complicated. A lot of thought and care needs to be put into deploying an OTA update strategy. Part of that strategy must be having a way to fix mistakes quickly and keep customers happy.