The updated ECU is mainly divided into traditional embedded chip ECU and complex ECU with operating system (such as Linux, Android, AutoSAR). According to the hardware resources of the ECU, we have designed the following ECU internal storage and refresh strategy: As shown in Figure 11, the ECU with an operating system has rich hardware storage resources, and two different startup partitions are allocated in the controller. For traditional embedded ECU usually adopts the software architecture of BOOT+APP. The more complex the function of the ECU, the larger the APP capacity of the main control chip selected. In order to realize the self-rollback function of the internal software of the ECU, it is necessary to divide a part of the APP space for software backup storage. When the ECU is refreshed, the BOOT code is responsible for providing the upgrade process guidance and storing the upgrade package in the APP area (usually the program startup entry address space). Since there is usually only one entry for the embedded chip ECU program to start, when the refresh fails (APP cannot be activated), the BOOT guide program guides the backup program of APP2 to be copied to the APP area for rollback operation and startup to ensure that the ECU works normally. For ECUs with a small APP capacity that does not support APP2 space division, they can only rely on the OTA master control node to realize the backup storage of the upgrade package.