Stop Using the Term “Software Defined Vehicles”
A jargon is born
Ever since I started working in automotive, from early 2016, I’ve encountered the term “Software Defined Vehicles” quite a few times. Over the last 3 to 4 years this term is being used more and more. The automotive industry treats this like some coveted Holy Grail of vehicle architecture that every OEM should achieve. However, this term is incorrect. Vehicles are not “software-defined”, not even Teslas.
The term was made popular by analysts who looked at Tesla and jumped to conclusions. They compared the modern car to a smartphone and predicted that vehicles will soon become more like “smartphones on wheels”. Since smartphones can sometimes gain new features by updating their software, they applied the term “software-defined” to vehicles. I would excuse the analysts for making this flawed comparison, as I did the same when I first took my baby steps into to automotive industry.
My background before 2016 was mobile devices system software. Hence, I feel I should be a fairly decent judge of whether a vehicle is becoming a smartphone on wheels, as I used to work on smartphones. My first job in the automotive industry was to program manage a large infotainment team delivering an Android Automotive head unit to one of Detroit’s finest OEMs. I saw that the infotainment system architecture had some parallels with mobile phone hardware architecture. Both had different processors for running user-facing (slow OS’es with richer capabilities), and timing critical (fast RTOS’es) software. In mobile devices, it was an application processor and a “baseband” processor. In automotive infotainment we also had a application processor, and a “vehicle-interface processor”. As an automotive greenhorn, I immediately jumped to the same conclusion as McKinsey, BCG and others… a modern vehicle is very similar to a smartphone! Now, with 8 years of automotive experience in infotainment, telematics, ADAS, body electronics, I realize how silly that conclusion was.
NOT a “Smartphone on Wheels”!
A modern vehicle is not like a smartphone. Nor is the term “software defined vehicle” really appropriate. For one, I personally do not like this “software defined” term at all. I don’t think it does justice to the engineering effort that goes into any modern vehicle. Whether it’s a Tesla or a Ford, a Rivian or a Toyota, there’s a tremendous amount of engineering that goes into chassis, body, powertrain, interior/exterior, that has nothing to do with software, apart from the use of software tools in design and simulation. Calling a vehicle “software-defined” is being quite disrespectful to the incredibly talented people who do this job. Secondly, the term is also not accurate. Being “software defined” means that using just software, new functions and features can be created. A modern vehicle is not “software defined” in this way. Rather, it is very much “hardware defined” because the functionality that can be added depends completely on the parts and components that were selected for the vehicle.
For e.g., Tesla could improve braking characteristics of the Model 3 in 2018, because they chose a braking system that was electro-mechanical, and had software logic to control braking. Something like Bosch’s “iBooster” system which uses a mechanical part to detect the driver’s brake pedal pressure, and uses a ECU to calculate and apply the brake torque. If Tesla did not have a braking system like this, or, if it was not connected over the vehicle network to other ECUs, then they would not have been able to do this. So not even Tesla is software defined. The sooner the automotive industry understands that this term is incorrect, the sooner other OEMs can correct course and catch up with Tesla
So what does it take to be like Teslas?
Unlike what McKinsey says, the way to reach Tesla’s capabilities is not by “…shifting from the traditional use of scattered, embedded electronic-control units (ECUs) to a domain-focused system with central vehicle controllers”. While Domain-Based, and Zonal architectures both have merits, it is not necessary for being able to update vehicle functions over-the-air. What is needed are three things:-
- ECU’s with ‘headroom’ to grow: This basically means that the ECU should have enough memory and processing power to support future functions. The exact amount of memory and compute headroom is difficult to estimate, and would vary based on the ECU’s functions. But ensuring there’s some percentage of headroom for future growth is critical.
- EE-Architecture & Vehicle Network that supports Software Updates: Whether it is CAN, or Ethernet, there should be a path from the Telematics Controller to each major ECU. The TCU (Telematics Control Unit) is the entity responsible for wireless communication to the outside world, and would be the main entry point for any OTA updates. The vehicle network need not be Ethernet for every ECU. Rather, it’s quite an overkill to have Ethernet everywhere. For domains like ADAS, Telematics and Connectivity, high speed and large data transfer is important. For these, Ethernet makes to most sense. For thigns like the BCM (Body Controller Module), it’s perfectly fine to have a 2 Mbps CAN. These ECUs typically have smaller binary sizes, and can be updated over CAN quite easily.
However, the interface definition between ECUs is important here. What should the other ECUs do, when they lose communication with the BCM because it is being updated? Should they all start sending diagnostic error codes? Should they all assume the worst has happened and go into error mode? Designing a foolproof software update specification is critical here.
3. Competency in Cyber-Security: While it may sound silly, for many OEMs, the reason why they cannot do a OTA software update, is simply because the ECUs are locked-down, designed to be flashed only via a diagnostics tester. Opening up the ECUs also introduces the risk of an un-authorized binary being flashed. Several traditional OEMs and their suppliers have chosen to keep ECUs locked for this reason. This was one of attack surfaces for the infamous 2015 hack of a Jeep Cherokee. Two white-hat hackers successfully hacked the vehicle by installing custom software on the U-Connect head unit. Despite the huge media attention after the 2015 hack was demonstrated, the industry is still behind in the understanding of cyber-security. I have heard some of my colleagues downplay the Jeep Cherokee hack, just because the hackers had access to the vehicle’s keyfob. This is a completely flawed analysis of the threat! For instance, there have been cases of car thieves getting access to a locked vehicle by removing the headlights and injecting CAN signals. Fun-fact… I was once in a cyber-security meeting with a automotive supplier (that shall not be named) and I heard the statement — “We use private keys for encrypting personal private information”. I am not a security expert, but I’m sure that if I encrypt something with my private key, the whole wide world can decrypt it with my public key!
What is software defined, anyways?
I think my Macbook is reasonable close to being software-defined, as I can install different software suites and completely change the function of the device. I can install Zoom or Teams and turn it into a video-conferencing device. I can install Microsoft Office and use it to create documents and spreadsheets. I can install Cubase/Pro Tools/Garage Band and turn it into a music production device. The hardware of my Macbook does not limit me from adding functions by installing new software. Vehicles are not like this at all. I doubt that vehicles ever should be like a Macbook, since a Macbook would not kill someone if it was compromised. It’s high time we in the automotive industry drop this incorrect term!
