As the pioneer of the whole-vehicle OTA technology, Tesla has equipped all its vehicles, from the Model S launched in 2012 to the latest Model 3, with OTA capabilities. It not only allows for upgrading the in-vehicle entertainment system, applications, etc. over the air, but also facilitates software updates of ECUs, such as the battery management system, the electric drive control unit, the whole-vehicle control unit, etc.
OTA Framework of Tesla
As indicated in Figure 1, Tesla’s OTA architecture is designed such that the firmware package is downloaded from the cloud, decrypted, and checked for integrity by the CID of the central control system using a private handshake protocol.
Looking at the OTA Upgrade Framework, there are mainly two upgrade methods: one is for ECUs connected to Ethernet, and the other is for ECUs converted to the CAN bus through the gateway.
For ECUs with Ethernet connections, they all have ic-updater and cid-updater upgrade agents, where cid-updater is responsible for getting the firmware package and verifying it from the cloud, and can be viewed as a local server, while ic-updater acts as a remote agent.
In addition, for these types of ECUs, the software upgrade method used is A/B backup, as shown in Figure 2. For example, if the current version is in area A and software needs to be updated, the software will first be written to area B. When the update is complete, B zone is started as the main system, and A zone is used as the backup area.
For ECUs updated via the UDS protocol or other protocols based on the gateway on the CAN bus, the required files are extracted from release.tgz, including:
1) boot.img: runs during the upgrade process, similar to a commonly used flash driver;
2) Release_version.txt: contains firmware version information;
3) Versionmap2.tsv and Signedmetadata_map.tsv: contain firmware information;
4) Internaloptiondefault.tsv: contains default firmware configuration information.5) The format of the ECU named file is ECUName/ProviderID/ECUFwName.hex. It is mainly a hex format file, the file that really needs to be downloaded to the ECU.
Tesla’s OTA Suppliers
To achieve the OTA framework mentioned above, Tesla’s current choice of supplier is Red Bend, a subsidiary of Harman. Red Bend’s OTA platform is used for communication between vehicles and the cloud, and Harman and Tesla allow both parties to replace code rather than files. However, when it comes to the issue of vehicle software upgrades, Tesla relies on its internally developed API interface.
What exactly is Harman? Harman is actually a Samsung subsidiary (acquired in 2017), focusing on interconnectivity technology for the automotive, consumer, and enterprise-level markets, and strongly integrating the Internet of Things and the connected car.
In Harman’s OTA solution, the “Software Update Gateway” jointly developed with NXP is used and can provide secure OTA operations for all vehicle ECUs without worrying about CPU, memory, and network resources being too small. It also integrates network security measures, such as automatically starting binary file scanning from the OTA system before the update service is activated.
Currently, there are other manufacturers using Harman’s OTA solution besides Tesla, as shown in table 1.
Summary of Tesla’s OTA in Recent Years
From 2012 to the present, Tesla’s OTA has been implemented for 9 years. What OTA has been implemented during this long time span?
From 2012 to April 2019, a period of more than 6 years, a total of 37 OTA upgrades were implemented, an average of 6 times per year, as shown in Figure 3.
In these upgrades, there were 11 improvements in potential issues, 67 imports of new functions, and 64 optimizations of interaction interfaces and logic, as shown in Figure 4.
From the perspective of the controllers involved in the upgrade, they include 20 ECUs such as ADAS, ESP, EPS, Ibooster, VCU, BCM, HU, IPC, BMS, OBC, AC, MCU, AMP, GW, PTC, CAMERA, ECSS, SRCU, TPMS, and IPC. Among them, the upgrade frequency of HU is as high as 20 times, while the frequency of upgrading EPS, OBC, AMP, and others is the lowest, only once. As shown in Figure 5, this is also easy to understand because the closer it is to the execution layer in the network architecture, the fewer changes usually occur.
From the perspective of different functional domains, these upgrades involve power systems, cabin entertainment domains, vehicle electronic domains, chassis and autonomous driving domains, among which the cabin entertainment domain has the highest upgrade frequency, reaching 20 times. Since July 2016, Tesla has accelerated the development of self-developed autonomous driving systems, so the upgrade frequency in the autonomous driving domain has increased year by year, as shown in Figure 6.
For the autonomous driving domain, its software upgrade has gone through three stages:
Stage one: from version 4.0 to 6.0
Tesla did not truly incorporate intelligent driving functions, and its OTA upgrades mainly focused on intelligent networking, human-machine interaction, and navigation functions.
Stage two: from version 6.1 to 7.1
Tesla first preliminarily realized intelligent driving functions, realizing three major functions of LKA, ALC, and APA.
Stage three: version 8.0 to 10.0
Tesla continuously optimized the ADAS system. The 8.0 version alone updated more than 200 improvements, and further expanded the entertainment and human-machine interaction functions.
Finally, let’s take a look at what Tesla has specifically updated over the years.
This article is a translation by ChatGPT of a Chinese report from 42HOW. If you have any questions about it, please email bd@42how.com.