Version repair method, apparatus and system, and storage medium and program product

Abstract

A version repair method, apparatus and system, and a storage medium and a program product, which relate to the field of software management and are used for improving the efficiency of software repair. The method comprises: a domain control unit sending first information to a main control unit, receiving second information from the main control unit, and flashing the software version of the domain control unit or the software version of a first sub-component, wherein after the flashing, the software version of the first sub-component matches the software version of the domain control unit, the first information comprises information indicating that the software version of the domain control unit does not match the software version of the first sub-component mounted under the domain control unit, and the second information is used for indicating version repair on a domain where the domain control unit is located. In the solution, it is possible to only flash the software version of a component requiring repair, without needing to flash the software version of other components, thereby improving the efficiency of software version repair and also saving on processing resources.

Description

A version repair method, apparatus, system, storage medium, and program product.

[0001] Cross-references to related applications

[0002] This application claims priority to Chinese Patent Application No. 202410954387.8, filed on July 16, 2024, with the invention title “A Version Repair Method, Apparatus, System, Storage Medium and Program Product”, the entire contents of which are incorporated herein by reference. Technical Field

[0003] This application relates to the field of software management technology, and in particular to a version repair method, apparatus, system, storage medium, and program product. Background Technology

[0004] With the development of science and technology, various smart terminals are gradually entering people's daily lives. Typically, smart terminals deploy a variety of software. For example, taking a vehicle as an example, a vehicle may have an in-vehicle operating system, an autonomous driving system, human-machine interaction software, navigation software, and audio-visual playback software. This software enriches the vehicle's functionality but also makes it more prone to vulnerabilities, requiring software patching and updates.

[0005] Currently, when a vehicle has a software vulnerability, it needs to be taken to the original equipment manufacturer (OEM) for repair. The OEM then uses over-the-air (OTA) technology to fix the software, or performs a near-end flash via a diagnostic interface. This repair method is cumbersome and time-consuming, hindering the efficiency of vehicle software repair.

[0006] In conclusion, improving software repair efficiency is a pressing technical problem that needs to be solved in the field of vehicle software management. Summary of the Invention

[0007] This application provides a version repair method, apparatus, system, storage medium, and program product to improve software repair efficiency.

[0008] Firstly, this application provides a version repair method applied to a domain control unit. The domain control unit can be a domain controller, a module within the domain controller (e.g., a circuit, chip, or chip system), or a logical node, logical module, or software capable of implementing all or part of the domain controller's functions. The method includes the following steps:

[0009] The domain control unit sends first information to the main control unit and receives second information from the main control unit. Based on the second information, it flashes the software version of the domain control unit or the software version of the first sub-component. The flashed software version of the first sub-component is compatible with the software version of the domain control unit. The first information includes information that the software version of the domain control unit is incompatible with the software version of the first sub-component under the domain control unit. The second information is used to instruct the domain where the domain control unit is located to perform version repair.

[0010] Using the above method, only the software version of the component that needs to be repaired in the functional domain can be flashed, without flashing the software versions of other components. Therefore, the required repair time is shorter than the time required to repair all components in a functional domain normally. Compared with the existing repair methods, it can improve the repair efficiency of software versions and save processing resources.

[0011] In one possible design, before sending the first information to the main control unit, the domain control unit also receives a third information from the main control unit. The third information is used to instruct the domain control unit to perform asset acquisition. The domain control unit obtains the software version information of the domain control unit and the software version information of each sub-component under the domain control unit. Based on the software version information of the domain control unit and the software version information of each sub-component, it determines that the software version of the domain control unit is incompatible with the software version of the first sub-component, where the first sub-component is at least one of the sub-components.

[0012] Through the above design, the software repair operation of the domain control unit can be triggered by the main control unit, thereby enabling the main control unit to centrally manage and control the software repair operation of each domain control unit.

[0013] In one example of the above design, the third piece of information could be sent by the master control unit to the domain control unit after the vehicle is started.

[0014] With the above design, a matching test can be performed every time the vehicle starts. Once a mismatch is found, the version repair process can be initiated. This ensures that the software versions of each component in the functional domain are compatible during vehicle operation, and that the functions of the functional domain can be implemented normally during vehicle operation.

[0015] In another example of the above design, the third information may be sent by the main control unit to the domain control unit after the software version upgrade of each component of the vehicle is completed and before exiting the upgrade mode.

[0016] With the above design, the vehicle can perform a matching test and version repair process after each upgrade, which ensures that the software versions of each component in the functional domain are compatible after each upgrade, and that the functions of the upgraded functional domain can be implemented normally.

[0017] In one possible design, the domain control unit flashes the software version of the domain control unit or the software version of the first sub-component. Specifically, the domain control unit obtains the software package stored locally in the domain control unit. Assuming that the version of the software package is the first version, if the current version of the domain control unit is not the first version, then the software version of the domain control unit is flashed; if the version of the first sub-component is not the first version, then the software version of the first sub-component is flashed.

[0018] Through the above design, the software versions of various components in the functional domain that have different software versions from the software package stored locally can be flashed to be consistent with the locally stored software package, thereby achieving software version compatibility of various components.

[0019] In one example of the above design, the software package stored locally by the domain control unit could be: the software package that the domain control unit received during the most recent software version upgrade of the vehicle, or the software package that the domain control unit downloaded after sending the first message and before receiving the second message.

[0020] The above design ensures that the software packages stored locally in the domain control unit are consistent with the major version of the vehicle, thereby ensuring the accuracy of the software version used to repair abnormal components based on the locally stored software packages.

[0021] In one example of the above design, the first information also includes the software version information of the domain control unit. Based on this, before receiving the second information sent by the main control unit, the domain control unit can also receive the fourth information sent by the main control unit. According to the download link included in the fourth information, the software package corresponding to the domain control unit is downloaded to the local machine. The fourth information is sent by the main control unit to the domain control unit when the software version information of the domain control unit is different from the software version information of the vehicle.

[0022] The above design allows the domain control unit to be instructed to re-download the correct software package when the software package stored locally in the domain control unit is faulty, thereby improving the accuracy of repairing faulty components based on locally stored software packages.

[0023] Secondly, this application provides a version repair method. This method is applied to a main control unit, which can be any component in a vehicle, such as a telematics box (T-Box), gateway (GW), or domain controller; or a module (e.g., circuit, chip, or chip system) within the T-Box, GW, or domain controller; or a logical node, logical module, or software capable of implementing all or part of the functions of the T-Box, GW, or domain controller. The method includes the following steps:

[0024] The main control unit receives first information from the domain control unit and sends second information to the domain control unit. The first information includes information that the software version of the domain control unit is incompatible with the software version of the first sub-component under the domain control unit. The second information is used to instruct the domain where the domain control unit is located to perform version repair.

[0025] In one possible design, the second information is also used to indicate the part to be repaired.

[0026] In one possible design, before receiving the first information from the domain control unit, the master control unit can also send a third information to the domain control unit, which instructs the domain control unit to perform asset acquisition.

[0027] In one example of the above design, the main control unit is specifically used to: send third information to the domain control unit after the vehicle starts; and / or, send third information to the domain control unit before exiting the upgrade mode after the software version upgrade of each component of the vehicle is completed.

[0028] In one example of the above design, the third information is sent after the vehicle starts. Before sending the second information to the domain control unit, the main control unit can also send the first information to the OTA cloud and receive the fifth information sent by the OTA cloud. The fifth information is used to instruct the domain where the domain control unit is located to perform version repair.

[0029] Through the above examples, OTA cloud can create repair tasks and send them to the vehicle to align the compatibility between domain control units and sub-components, thereby achieving unified management of vehicle software repair by OTA cloud.

[0030] In a further example, the first information also includes the software version information of the domain control unit. If the software version information of the domain control unit is different from the software version information of the vehicle, the fifth information also includes a download link. Based on this, after receiving the fifth information sent by the OTA cloud, the main control unit can also send a fourth information to the domain control unit before sending the second information. The fourth information contains a download link, which is used by the domain control unit to download the software package corresponding to the domain control unit.

[0031] The above examples demonstrate that when the software package stored locally in the domain control unit does not correspond to the major version of the vehicle, the domain control unit can be instructed to re-download the software package. This ensures the accuracy of the software package stored locally in the domain control unit and improves the accuracy of repairing abnormal components based on the software package.

[0032] In a further example, after the main control unit receives the fifth message sent by the OTA cloud, before sending the second message to the domain control unit, it can also send a first prompt message to the user and determine the user's first reply message. The first prompt message is used to indicate that some software needs to be repaired, and the first reply message is used to instruct the user to repair it.

[0033] The above examples demonstrate that before instructing a specific functional area to be repaired, it is possible to determine with the user whether repair is necessary. This allows for the option of repairing or not repairing the functional area according to the user's instructions, thus meeting different user needs and improving the universality of version repair methods.

[0034] In a further example, a first prompt message is displayed on a first interface of the user terminal and / or the vehicle display screen to indicate that some software needs to be repaired; after the main control unit sends the first prompt message to the user, it can also display a second interface to the user in response to the user's first operation on the first interface. The second interface includes a second prompt message, which indicates information about the mismatch between the software version of the domain control unit and the software version of the sub-component corresponding to each software to be repaired, as well as the repair method for each software to be repaired; and, in response to the user's second operation on the second interface, determines the user's first reply message.

[0035] The above examples demonstrate how user prompts and responses can be displayed through an interface. This not only allows users to see the components to be repaired more intuitively but also makes it easier for them to reply with repair suggestions, thereby improving their software repair experience.

[0036] In a further example, the main control unit can also respond to a third operation by the user on the first interface to determine a second reply message from the user, which indicates that no repair should be performed.

[0037] In a further example, if the first response message indicates immediate repair, the master control unit can directly send the second information to the domain control unit; if the first response message indicates scheduled repair, the master control unit can send the second information to the domain control unit at the scheduled time.

[0038] The above examples demonstrate two repair methods: immediate repair and scheduled repair, catering to the needs of different users.

[0039] Thirdly, this application provides a version repair method, which is applied to OTA cloud, modules (e.g., circuits, chips, or chip systems) in OTA cloud, or logical nodes, logical modules, or software capable of implementing all or part of the OTA cloud functions. The method includes the following steps:

[0040] The OTA cloud receives the first information sent by the main control unit and sends the fifth information to the main control unit. The first information includes information that the software version of the domain control unit is incompatible with the software version of the first sub-component under the domain control unit. The fifth information is used to instruct the domain where the domain control unit is located to perform version repair.

[0041] In one possible design, the first information also includes the software version information of the domain control unit. Based on this, before sending the fifth information to the main control unit, the OTA cloud can also determine whether the software version information of the domain control unit and the software version information of the vehicle are the same. If the software version information is the same, the fifth information is generated, and the fifth information does not carry a download link.

[0042] In a further possible design, if the software version information is different, the OTA cloud can generate a fifth piece of information, which includes a download link. The download link is used by the main control unit to instruct the domain control unit to download the software package corresponding to the domain control unit.

[0043] Fourthly, this application provides a version repair device that has the function of implementing the method of the first aspect or any one of the designs described above. For example, the version repair device includes modules, units or means for performing the operations involved in the method of the first aspect or any one of the designs described above. The modules, units or means can be implemented by software, or by hardware, or by a combination of software and hardware.

[0044] Fifthly, this application provides a version repair apparatus, which includes an interface circuit and one or more processors. The one or more processors are coupled to a memory. The memory stores part or all of the necessary computer program or instructions for implementing the functions involved in the method of implementing the first aspect or any of the designs in the first aspect. The one or more processors can execute the computer program or instructions, which, when executed, cause the communication apparatus to implement the method of the first aspect or any of the designs or examples in the first aspect. The interface circuit is used to implement the communication functions within the version repair apparatus and / or the communication functions between the version repair apparatus and other devices or components.

[0045] The aforementioned repair device may be a domain control unit, a module (such as a circuit, chip, or chip system) in the domain control unit, or a logic node, logic module, or software that can implement all or part of the functions of the domain control unit.

[0046] Sixthly, this application provides a version repair device that has the function of implementing the method of the second aspect or any of the designs in the second aspect. For example, the version repair device includes modules, units or means for performing the operations involved in the method of the second aspect or any of the designs in the second aspect. The modules, units or means can be implemented by software, or by hardware, or by a combination of software and hardware.

[0047] In a seventh aspect, this application provides a version repair apparatus, which includes an interface circuit and one or more processors. The one or more processors are coupled to a memory. The memory stores part or all of the necessary computer program or instructions for implementing the functions involved in the methods of implementing the second aspect or any of the designs in the second aspect. The one or more processors are executable to carry out the computer program or instructions, which, when executed, cause the communication apparatus to implement the methods of the second aspect or any of the designs or examples in the second aspect. The interface circuit is used to implement the communication functions within the version repair apparatus and / or the communication functions between the version repair apparatus and other devices or components.

[0048] The aforementioned version repair device can be a main control unit, a module in the main control unit (such as a circuit, chip, or chip system), or a logic node, logic module, or software that can realize all or part of the functions of the main control unit.

[0049] Eighthly, this application provides a version repair device that has the function of implementing the method of the third aspect or any of the designs in the third aspect. For example, the version repair device includes modules, units or means for performing the operations involved in the method of the third aspect or any of the designs in the third aspect. The modules, units or means can be implemented by software, or by hardware, or by a combination of software and hardware.

[0050] Ninthly, this application provides a version repair apparatus, which includes an interface circuit and one or more processors. The one or more processors are coupled to a memory. The memory stores part or all of the necessary computer program or instructions for implementing the functions involved in the methods of the third aspect or any of the designs in the third aspect. The one or more processors are executable to carry out the computer program or instructions, which, when executed, cause the communication apparatus to implement the methods of the third aspect or any of the designs or examples in the third aspect. The interface circuit is used to implement the communication functions within the version repair apparatus and / or the communication functions between the version repair apparatus and other devices or components.

[0051] The aforementioned version repair device can be an OTA cloud, a module in the OTA cloud (such as a circuit, chip, or chip system), or a logical node, logical module, or software that can implement all or part of the OTA cloud functions.

[0052] In a tenth aspect, this application provides a vehicle, comprising: a domain control unit and a main control unit, wherein the domain control unit is configured to execute the method in the first aspect or any possible design of the first aspect; and the main control unit is configured to execute the method in the second aspect or any possible design of the second aspect.

[0053] In one aspect, this application provides a version repair system, including: a domain control unit, a master control unit, or an OTA cloud, wherein the domain control unit is used to execute the method in the first aspect or any possible design in the first aspect; the master control unit is used to execute the method in the second aspect or any possible design in the second aspect; and the OTA cloud is used to execute the method in the third aspect or any possible design in the third aspect.

[0054] In a twelfth aspect, this application provides a computer-readable storage medium storing computer-readable instructions that, when read and executed by a computer, cause the computer to perform any of the possible designs in the first to third aspects described above.

[0055] In a thirteenth aspect, this application provides a computer program product that, when read and executed by a computer, causes the computer to perform any of the possible designs in the first to third aspects described above.

[0056] In a fourteenth aspect, this application provides a chip for reading a computer program stored in a memory and executing any of the possible design methods in the first to third aspects above. Optionally, the chip may include a processor coupled to the memory for reading the computer program stored in the memory and implementing any of the possible design methods in the first to third aspects above. Optionally, the chip may also include components such as a memory, a communication interface, and a power supply module. The memory is used to store the computer program; the communication interface is used to receive and send data; and the power supply module is used to supply power to the processor.

[0057] In a fifteenth aspect, this application provides a chip system including a processor for supporting a computer in implementing the methods in any of the possible designs of the first to third aspects above. In one possible design, the chip system further includes a memory for storing programs and data necessary for the computer. The chip system may be composed of chips or may include chips and other discrete devices.

[0058] The technical effects that can be achieved in aspects two through fourteen above can be referred to the description of the beneficial effects in aspect one above, and will not be repeated here. Attached Figure Description

[0059] Figure 1a illustrates an exemplary architecture diagram of a version repair system applicable to this application;

[0060] Figure 1b illustrates a possible application scenario provided by this application;

[0061] Figure 2 illustrates a flowchart of a version repair method provided in this application;

[0062] Figure 3 is an exemplary schematic diagram of a notification interface provided in this application;

[0063] Figure 4 illustrates an exemplary flowchart of an asset acquisition process provided in this application;

[0064] Figure 5 illustrates a flowchart of a user-instructed repair method provided in this application;

[0065] Figure 6a is an exemplary schematic diagram of the presentation form of a first interface provided in this application;

[0066] Figure 6b is an exemplary schematic diagram of the presentation form of a second interface provided in this application;

[0067] Figure 6c illustrates a schematic diagram of the presentation format of a third interface provided in this application;

[0068] Figure 6d is an exemplary schematic diagram of another presentation form of the first interface provided in this application;

[0069] Figure 7 illustrates an interactive flow diagram of a version repair method provided in Implementation Scheme 1;

[0070] Figure 8 illustrates an interactive flow diagram of a version repair method provided in Implementation Scheme 2;

[0071] Figure 9 illustrates a schematic diagram of the presentation format of a fourth interface provided in Implementation Scheme 2;

[0072] Figure 10 illustrates a schematic diagram of the structure of a version repair device provided in this application;

[0073] Figure 11 illustrates an exemplary structural diagram of another version of the repair device provided in this application. Detailed Implementation

[0074] The version repair method provided in this application will now be described in detail with reference to the accompanying drawings and embodiments.

[0075] Please refer to Figure 1a, which exemplarily illustrates the architecture of a version repair system to which this application applies. The system includes a server and at least one terminal device, and optionally, a software development device. Communication between the server and the software development device, between the server and at least one terminal device, and between any two of the at least one terminal device, can be achieved through mobile communication networks (e.g., 5th generation (5G) or future communication networks), wireless local area networks (WLANs), or short-range communication technologies. Here, short-range communication technology refers to technologies that transmit information via radio waves over a short distance (e.g., within 100 meters), including but not limited to: Bluetooth, Wi-Fi, Near Field Communication (NFC), Wi-Fi Aware, general short-range communication technologies, and short-range communication technologies specified by the Starlight Alliance.

[0076] The software development equipment described above refers to the equipment used by software designers to develop application software packages. This equipment can belong to the application vendor or a terminal device vendor capable of installing the application software, and can take the form of a computer, server, laptop, user terminal, or other device with processing capabilities. The software development equipment can establish a connection with the server via an Internet Protocol (IP) network. Based on this connection, the software development equipment can send newly developed or patched software packages to the server.

[0077] The above-mentioned server can be a single server or a server cluster composed of multiple servers. For example, it can be a server cluster deployed in a distributed architecture, which may include one or more of the following: OTA cloud server, cloud computing server, content delivery network (CDN) server, domain name system (DNS) server, vehicle-to-everything (V2X) server, etc. These servers can coordinate with each other to jointly complete functions such as computing, data storage, and communication. For ease of description, this application collectively refers to a single server, a distributed server, and a server cluster as a server. The server can be a physical device or a virtual machine or container deployed in the cloud. The server can store software packages sent by software development equipment and provide software package download services to terminal devices.

[0078] The terminal devices described above are devices that can provide users with various services such as voice, video, photography, and data connectivity by installing application software. Terminal devices can also be called user equipment (UE), mobile station (MS), mobile terminal (MT), etc. Examples of terminal devices include, but are not limited to: mobile phones, portable Android devices (PADs), laptops, PDAs, smart TVs, printers, smart cars in the Internet of Vehicles (IoV), on-board units (OBUs), roadside units (RSUs), roadside equipment (RSEs), set-top boxes, mobile internet devices (MIDs), point-of-sale (POS) terminals, wearable devices, virtual reality (VR) devices, augmented reality (AR) devices, smart terminals in industrial control, smart terminals in self-driving, smart terminals in remote medical surgery, smart terminals in smart grids, smart terminals in transportation safety, smart terminals in smart cities, smart terminals in smart homes, and various smart meters (smart water meters, smart electricity meters, smart gas meters), etc.

[0079] It should be noted that the form and quantity of the server, terminal device, and software development equipment shown in Figure 1a above are for illustrative purposes only and do not constitute a limitation on this application. Furthermore, the above-mentioned server, terminal device, and software development equipment can be hardware, software functionally defined, or a combination of both; this application does not impose specific limitations in this regard.

[0080] Based on the above, please refer to Figure 1b, which is a schematic diagram of a possible application scenario provided by this application. This application scenario takes the server in Figure 1a as OTA cloud 110 and the terminal devices in Figure 1a as vehicle 120 and mobile phone 130 as examples. As shown in Figure 1b, vehicle 120 is connected to OTA cloud 110 and mobile phone 130 respectively, and OTA cloud 110 is also connected to mobile phone 130.

[0081] OTA Cloud 110, also known as OTA Cloud or OTA Cloud Server, is a server that interacts with vehicle 120 during the OTA upgrade process. OTA Cloud 110 can be managed by the OEM and is primarily responsible for version management of various components of vehicle 120 and upgrade task management during the OTA upgrade process. OTA Cloud 110 can obtain software packages from the software development equipment shown in Figure 1a, create corresponding download links, and send the download links to vehicle 120 that needs to update its software.

[0082] Vehicle 120 includes any type of vehicle capable of software updates. Examples include, but are not limited to, smart cars, electric vehicles, digital cars, sedans, trucks, motorcycles, buses, lawnmowers, recreational vehicles, amusement park vehicles, construction equipment, trams, or golf carts. Vehicle 120 can receive download links sent by OTA Cloud 110 and download the necessary software packages via those links, updating the software versions of one or more local components accordingly.

[0083] For example, as shown in Figure 1b, vehicle 120 may include N functional domains, where N is an integer greater than or equal to 2. These N functional domains may include, but are not limited to, the following: Power Domain, Body Domain, Chassis Domain, Cabin Domain, Intelligent Vehicle Domain, and Network Connected Domain. Each functional domain includes multiple electronic control units (ECUs), one of which acts as a domain controller, connecting (also called sub-controllers) to the other ECUs. The domain controller contains domain control software, which, by controlling the sub-controllers, enables the implementation of the corresponding functional domain's functions. For instance, the Power Domain controller is the core of the vehicle's powertrain system; by controlling its sub-controllers such as the engine and transmission, it provides the vehicle with robust power output. The Body Domain controller safeguards vehicle stability and safety; by controlling its sub-controllers such as door locks, lights, wipers, and window locks, it provides passengers with a higher level of driving safety and a more comfortable experience. The chassis domain controller is the core of vehicle handling performance. By controlling its subordinate suspension and steering systems, it enables stable handling and precise driving. The cockpit domain controller is crucial for creating a comfortable driving environment. By controlling its subordinate audio acquisition components, seat adjustment components, and air conditioning, it enables human-vehicle interaction, voice control, intelligent reminders, and intelligent monitoring, providing a highly personalized and comfortable driving experience. The intelligent driving domain controller is the core of intelligent driving. By controlling its subordinate radar and camera modules, it collects environmental and road information, enabling intelligent assisted driving functions such as autonomous driving, driver assistance, and valet parking, bringing users a completely new driving experience. The connectivity domain controller is the core of vehicle networking. By controlling its subordinate communication modules, it enables vehicle networking, historical data reporting, and emergency call functions.

[0084] As shown in Figure 1b, the vehicle 120 may also include components such as a T-Box and a GW. The T-Box is used to enable information interaction between the vehicle 120 and other devices. For example, the vehicle 120 can connect to the OTA cloud 110 and the mobile phone 130 via the T-Box. Based on this connection, the vehicle 120 can send and receive information from the OTA cloud 110 and the mobile phone 130. The GW supports one or more components in the vehicle's integrated hardware and software platform, i.e., the vehicle computing platform, such as a mobile data center (MDC), human-machine interaction (HMI), telematics control unit (TCU), T-Box, vehicle integrated / integration unit (VIU), vehicle domain controller (VDC), the above domain controllers, or other ECUs. The GW is a core component in the vehicle's electronic and electrical architecture. As the data interaction hub of the vehicle network, it can route network data from different networks, such as the controller area network (CAN), local interconnect network (LIN), and media-oriented system transport (MOST) network.

[0085] Mobile phone 130 can connect to vehicle 120, OTA cloud 110, or other cloud servers to control some functions of vehicle 120. For example, mobile phone 130 can connect to the in-vehicle entertainment system of vehicle 120 to watch videos on the phone and use navigation functions on the phone on the in-vehicle screen. Mobile phone 130 can also connect to other cloud servers and, by cooperating with other cloud servers, send verified control commands to the vehicle to achieve functions such as remotely starting vehicle 120, preheating vehicle 120, and remotely parking. Furthermore, mobile phone 130 can also connect to OTA cloud 110 to assist vehicle 120 in completing software upgrades. For example, during the software upgrade or repair process of vehicle 120, it can prompt the user to choose whether to upgrade or repair, to select the parts that need to be upgraded or repaired, and to select the time for the upgrade or repair. Of course, there may be other functions, which will not be listed here.

[0086] It should be noted that the system architecture and application scenarios described above are for the purpose of more clearly illustrating the technical solution of this application and do not constitute a limitation on the technical solution provided by this application. For example, the method provided by this application can also be applied to software repair scenarios of devices such as smart TVs, smartphones, tablets, and set-top boxes, without specific limitations here.

[0087] As described in the background section, existing repair methods suffer from low efficiency when vehicles experience software vulnerabilities. This is primarily because current methods only allow operations personnel to recreate OTA (Over-The-Air) tasks for problematic vehicles after a fault is reported, or to repair the vehicles via near-end flashing through diagnostic interfaces. Firstly, it's difficult to detect problems promptly if users don't report them. Secondly, even if users report faults, the process is cumbersome and time-consuming, requiring manual creation of repair tasks or execution of repair operations, resulting in low efficiency.

[0088] Furthermore, current manual repair methods typically involve software repair of the entire vehicle software or at least the components of an entire functional domain. For example, based on the architecture shown in Figure 1b, a user driving vehicle 120 may only detect a problem in a specific functional domain, without being able to pinpoint the specific ECU. Therefore, the user must report the functional domain fault to maintenance personnel, who then need to repair the software versions of all components within the faulty functional domain. For instance, this might require updating the software version of domain controller 1 and all its connected ECUs (ECU 11, ECU 12, and ECU 13), or updating the software version of domain controller N and all its connected ECUs (ECU N1 and ECU N2).

[0089] However, in real-world scenarios, only one or two components in a faulty functional domain may have software version issues, while the software versions of other components may be fine. For example, taking the functional domain where domain controller 1 resides, suppose the original software version was V1.2. However, due to a user replacing domain controller 1, its software version has been downgraded to the initial version, V1.0. In this case, there will be a mismatch between domain controller 1's software version V1.0 and the software versions V1.2 of its connected ECUs 11 to ECU 13. Therefore, when domain controller 1 uses software version V1.0 to call its connected ECUs 11 to ECU 13 with software version V1.2, the domain function may fail to function or may function inaccurately (for example, if the software versions of the intelligent driving domain controller and its connected radar sensors are incompatible, the autonomous driving function may fail to function). In this case, simply upgrading the software version of domain controller 1 from V1.0 to V1.2 will solve the problem. Alternatively, if the original software version is V1.2, but the user flashes the software version of ECU 11 to V1.3, a mismatch will occur between the V1.2 software version of Domain Controller 1 and its connected ECUs 12 and ECU 13 and the V1.3 software version of ECU 11 connected to Domain Controller 1. Therefore, when Domain Controller 1 uses software version V1.2 to call its connected ECU 11 with software version V1.3, ECU 11 will have missing functions (for example, if the software versions of the cockpit domain controller and its connected instrument panel are incompatible, the instrument panel will display missing data). In this case, simply downgrading the software version of ECU 11 from V1.3 to V1.2 will solve the problem.

[0090] However, current repair methods can only repair the software versions of all components in the entire functional domain, and cannot specifically repair the problematic components. Therefore, current repair methods suffer from low repair efficiency and waste a lot of unnecessary processing resources, failing to achieve high efficiency in software repair and high resource utilization.

[0091] In view of this, this application provides a version repair method that can specifically repair problematic components without needing to repair all components of the entire functional domain, thereby improving the efficiency and resource utilization of software repair.

[0092] The version repair method proposed in this application will be described in detail below with reference to Figures 2 to 11.

[0093] The following version repair method applies to domain control units and master control units, and may also apply to OTA clouds. Domain control units and master control units are components within terminal devices, while OTA clouds are components outside of terminal devices. For example, when the version repair method is applied to the system shown in Figure 1a, the OTA cloud can be the server in Figure 1a, and the domain control unit and master control unit can be components within any of the terminal devices in Figure 1a; these components can be the same component or different components. As another example, when the version repair method is applied to the system shown in Figure 1b, the OTA cloud can be OTA cloud 110 in Figure 1b, and the domain control unit and master control unit can be components within the vehicle 120 in Figure 1b. For example, the domain control unit can be any domain controller in vehicle 120, and the master control unit can be a T-Box or GW in vehicle 120. Alternatively, the master control unit can be other components in vehicle 120, such as a TCU or MDC. Or, the master control unit can be a domain controller in vehicle 120, such as the intelligent driving domain controller; in this case, the intelligent driving domain controller performs both the functions of the domain control unit and the master control unit.

[0094] From another perspective, the aforementioned master control unit can also be considered a module deployed in the vehicle's T-Box, GW, TCU, MDC, or a domain controller, and can also be called an OTA master module or upgrade master module. The domain control unit can also be considered a module deployed in any domain controller of the vehicle, and can also be called an OTA slave module or upgrade slave module. The modules here can be hardware modules, such as circuits, chips, or chip systems, or software modules, such as logic nodes, logic modules, or program modules; there is no specific limitation.

[0095] Taking the software module as an example, the main control unit is an application program used to control the entire OTA upgrade process and corresponding vehicle control signals. It is primarily responsible for parsing the OTA upgrade tasks sent from the OTA cloud, controlling high and low voltage and network management message communication during the vehicle's OTA upgrade process, checking whether the vehicle conditions (such as speed and gear) meet the upgrade requirements, and controlling the execution steps of each domain control unit, such as notifying the domain control unit to execute processes like downloading software packages, pre-upgrade checks and upgrades, and rollback. The domain control unit is an application program used to control the OTA upgrade steps of a single functional domain. For example, the domain control unit of the intelligent driving domain can receive control commands from the main control unit and execute specific upgrade steps based on these commands. This includes receiving download commands to download the intelligent driving domain upgrade software package and verifying its integrity and legality; receiving pre-upgrade check commands to check whether the current intelligent driving domain status meets the upgrade requirements, such as whether it is in a working state; checking whether the upgrade software package is complete and legal; and receiving upgrade commands to execute the specific intelligent driving domain software flashing process.

[0096] Based on the above, Figure 2 shows a flowchart of a version repair method provided in this application. The method includes the following steps:

[0097] Step 201: The domain control unit sends first information to the master control unit. Correspondingly, the master control unit receives the first information sent by the domain control unit.

[0098] The first information includes information about a software version mismatch between the domain control unit and the first sub-component under the domain control unit. Alternatively, the first information can be understood as indicating a software version incompatibility issue between the domain control unit and its first sub-component. For example, the first information may include a first indication message, which indicates a software version incompatibility issue between the domain control unit and its first sub-component.

[0099] Optionally, the first sub-component can be one or more sub-components under the domain control unit. For example, it can be one or more ECUs in the functional domain where the domain control unit is located. The domain control unit can monitor the software versions of each ECU (including the domain control unit) in its functional domain. When it detects that the software version of one or more ECUs in its functional domain is incompatible with its own software version, it determines that there is a software version incompatibility problem in its functional domain. In this case, the domain control unit can send the aforementioned first information to the main control unit to notify the main control unit of the incompatibility problem.

[0100] Here, software version mismatch can be understood as a mismatch in software version numbers. When the version numbers of the main control unit and the subordinate sub-components are inconsistent, there may be inconsistencies in the interface or functional definitions between the main control unit and the sub-components. For example, if the intelligent driving domain main control unit calls a certain radar sub-component to obtain positioning data, incompatible versions may result in inconsistent interface parameters, leading to errors in the positioning data returned by the intelligent driving domain main control unit from the radar sub-component. Therefore, in the case of version mismatch, the corresponding functions will be disabled or restricted. It is necessary to flash the two versions to be consistent.

[0101] Step 202: The master control unit sends the second information to the domain control unit. Correspondingly, the domain control unit receives the second information sent by the master control unit.

[0102] The second piece of information is used to instruct on version repair of the functional domain in which the domain control unit is located.

[0103] Here, the second piece of information indicates partial repair, that is, only some components in the functional domain where the domain control unit is located are repaired.

[0104] Optionally, the master control unit can coordinate with each domain control unit to perform or not perform the repair task. When the master control unit receives the first message from a domain control unit, it determines that the functional domain to which the domain control unit belongs has a software version mismatch problem. Then, the master control unit can determine whether the functional domain needs to be repaired. If it needs to be repaired, it can send the aforementioned second message to the domain control unit. If it does not need to be repaired (e.g., the user instructs not to repair), it does not need to send the second message, that is, the repair process ends.

[0105] Here, whether a functional domain needs repair can be determined based on pre-configured rules or by user instruction. For example, in a pre-configured rule example, the main control unit has a whitelist of repairable functional domains. If the functional domain containing the domain control unit is in the whitelist, the main control unit can send the aforementioned second information to that domain control unit; otherwise, the process ends. In another example, in a user instruction example, the main control unit can coordinate with other components in the vehicle or user terminals to send a prompt message to the user and wait for a response. If the user's response is "repair," the main control unit can send the aforementioned second information to the domain control unit; if the user's response is "no repair," the process ends. The prompt message can be delivered via voice, text, images, etc., such as being displayed on the user terminal, on the vehicle's infotainment screen, or played on the vehicle's audio system, etc., without limitation.

[0106] Step 203: The domain control unit flashes the software version of the domain control unit or the software version of the first sub-component. The software version of the first sub-component after flashing is compatible with the software version of the domain control unit.

[0107] Here, the domain control unit can rewrite the software version of either the domain control unit or the first sub-component, as long as the software versions of the domain control unit and the first sub-component are the same. Domain control units and first sub-components with the same software version are functionally compatible and will not experience any functional deficiencies.

[0108] In one optional example, the domain control unit can combine the second information to determine the component to be flashed, specifically in the following two scenarios.

[0109] In the first scenario, the second piece of information is merely a trigger and does not contain any substantial content.

[0110] In this situation, after receiving the second information, the domain control unit can only determine that the component in its functional domain needs to be flashed, but it does not know which component needs to be flashed. Therefore, the next step is for the domain control unit to determine the component to be flashed itself.

[0111] There are many ways to identify the component to be flashed, including but not limited to the following examples one through four:

[0112] Example 1: Determining the component to be flashed based on the software version of the software package stored locally. For instance, after receiving the second information, the domain control unit can first retrieve the software package for the current functional domain from local storage and determine its software version. Assuming the software version is version 1, the domain control unit can compare its own software version with that of the first sub-component. If the domain control unit's software version is not version 1, then the domain control unit's software version is flashed, for example, by using the software package from the current functional domain to flash the domain control unit's software version to version 1. If the first sub-component's software version is not version 1, then the first sub-component's software version is flashed, for example, by using the software package from the current functional domain to flash the first sub-component's software version to version 1. In this way, it can be ensured that the software versions of the domain control unit and its subordinate sub-components are the same as the software versions of the software packages stored locally, thereby achieving software version compatibility between the domain control unit and its subordinate sub-components.

[0113] In Example 1 above, the locally stored software package can be: the software package updated by the domain control unit in the most recent vehicle software version upgrade, or the software package downloaded by the domain control unit after sending the first message and before receiving the second message. This can be understood as the most accurate software version of the locally stored software package, corresponding to the major version of the entire vehicle, and all components in the vehicle should have this software version. For details regarding the locally stored software package, please refer to Implementation Scheme 1 and Implementation Scheme 2 below; they will not be described in detail here.

[0114] Example 2: Determine the components to be flashed based on the principle of minimizing the number of flashes required. For instance, if the number of first sub-components is small, it means the domain control unit is only incompatible with the software versions of a few sub-components within its functional domain, while being compatible with the software versions of all other sub-components. Therefore, only the incompatible software versions of the first sub-components need to be flashed. Conversely, if the number of first sub-components is large, it means the domain control unit is incompatible with the software versions of most sub-components within its functional domain. In this case, the version of the domain control unit needs to be flashed. Of course, if there are other sub-components (referred to as second sub-components) that are compatible with the software version of the domain control unit, then the software version of the second sub-components also needs to be flashed to ensure that all components within the entire functional domain use the same software version. This method can reduce the number of components to be flashed, improve flashing efficiency, and save flashing resources.

[0115] Example 3: Determine the component to be flashed based on user instructions. For instance, the domain control unit can send a notification message to the user, prompting them to select the component to be flashed. This notification message can be delivered to the user through a user interface, voice announcement, message notification, or other means.

[0116] For example, taking the interface display as an example, assuming the domain control unit is the domain controller 1 in Figure 1b above, and the first sub-component is the ECU 11 in Figure 1b above, then the domain controller 1 can display a notification interface on the vehicle's display screen and / or user terminal via GW and T-Box, or OTA cloud. The notification interface can be exemplarily shown in Figure 3. This notification interface may include the text "The software versions of domain controller 1 and ECU 11 are incompatible," and may also include two selection options: one corresponding to "domain controller 1" and the other to "ECU 11." The user can select either option, and the component corresponding to the selected option is the component to be flashed.

[0117] It should be understood that the notification interface shown in Figure 3 is only one possible example, and this application does not limit the specific presentation form of the notification interface.

[0118] Example 4: Randomly select the component to be flashed. For instance, if the randomly selected component is a domain control unit, its software version can be flashed to match the software version of the first sub-component. If the randomly selected component is the first sub-component, its software version can be flashed to match the software version of the domain control unit. This ensures that the software version of the domain control unit is compatible with the software version of the first sub-component after flashing.

[0119] Understandably, in addition to the four examples above, the domain control unit can also determine the component to be flashed in other ways, such as through interaction with third-party devices, etc., which will not be listed here.

[0120] In the second scenario, the second information is also used to indicate the component to be flashed.

[0121] In this scenario, in addition to indicating the functional domain to be flashed in the second information, the main control unit can also simultaneously indicate which components should be flashed. Thus, the domain control unit only needs to parse the second information to directly determine the components to be flashed.

[0122] The component to be flashed can be determined by the main control unit itself or through interaction with the OTA cloud. For example, taking the latter, after receiving the first information, the main control unit can send it to the OTA cloud. This first information, besides carrying information about the software version mismatch between the domain control unit and the first sub-component, can also include the software version information of both the domain control unit and the first sub-component. Upon receiving the first information, the OTA cloud can obtain the overall vehicle version number, and then, based on the software version information of the domain control unit and the first sub-component, identify the component that differs from the overall vehicle version number and inform the main control unit of this component's information. The main control unit then sends this component information, along with a second message, to the domain control unit, enabling the domain control unit to flash the software version of that component.

[0123] Based on the above version repair method, the domain control unit only flashes the software version of the components that need repair within the functional domain, and does not flash the software versions of other components. Therefore, the required repair time is shorter than the time required to normally repair all components in a functional domain. Compared with existing repair methods, this improves the efficiency of software version repair and saves OTA resources. Understandably, since only some components in the functional domain are flashed, only the software versions of some components in the functional domain will change compared to before the flash, while the software versions of other components will remain unchanged.

[0124] In one possible implementation, before performing step 201 above, as shown in Figure 4, steps 401 to 405 can also be performed:

[0125] Step 401: The master control unit sends third information to the domain control unit. Correspondingly, the domain control unit receives the third information sent by the master control unit.

[0126] The third piece of information is used to instruct the domain control unit to collect assets.

[0127] Optionally, the main control unit is configured with triggering conditions for third information. When the main control unit determines that the vehicle meets the triggering conditions for third information, it can send third information to each domain control unit in the vehicle to instruct each domain control unit to collect assets. For example, referring to Figure 1b above, if the main control unit is domain controller 1, then when domain controller 1 determines that the triggering conditions for third information are met, it can send third information to each of domain controllers 2, ..., N to instruct each of domain controllers 2 to N to collect assets in its own functional domain. Furthermore, domain controller 1 can also collect assets in its own functional domain. Alternatively, if the main control unit is a T-Box, then when the T-Box determines that the triggering conditions for third information are met, it can send third information through the GW to each of domain controllers 1, ..., N to instruct each of domain controllers 1 to N to collect assets in its own functional domain.

[0128] The triggering conditions for third-party information can be pre-set, or they can be configured or modified by the user. Some possible examples include, but are not limited to, the following:

[0129] Triggering condition one: after the vehicle is started, or, also known as after the vehicle is powered on.

[0130] Here, after the vehicle starts, the main control unit powers on and sends third-party information to each domain control unit in the vehicle to instruct them to collect assets. Thus, a matching check is performed every time the vehicle starts. If any incompatibility is detected, a version repair process is initiated. This ensures that the software versions of all components in the functional domains are compatible during vehicle operation, and that the functional domains can function correctly during vehicle operation.

[0131] Triggering condition two: before exiting upgrade mode after the software version upgrade of each component of the vehicle is completed.

[0132] This refers to a situation where, during the normal vehicle upgrade process, the software versions of various components in the vehicle have been upgraded, but the upgrade mode has not yet been exited. For example, the main control unit has received messages from each domain control unit indicating that the upgrade of its respective functional domain is complete, but has not yet sent a message to the OTA cloud indicating that the upgrade is finished. At this time, the main control unit can send third-party information to each domain control unit in the vehicle to instruct each domain control unit to perform asset collection, thereby initiating the corresponding detection and version repair process.

[0133] Based on trigger condition two, a corresponding detection and version repair process will be performed after each vehicle upgrade. This ensures that the software versions of each component in the functional domain are compatible after each upgrade, and the functions of the upgraded functional domain can be implemented normally.

[0134] Triggering condition three: the time interval since the last sending of the third message is one cycle.

[0135] In other words, the main control unit can send a third message to each domain control unit in the vehicle at regular intervals, so that each domain control unit can perform asset collection at regular intervals.

[0136] Based on trigger condition three, the vehicle can perform a matching test and version repair process every certain period of time. This can continuously ensure the compatibility of software versions of various components in the functional domain and promptly detect incompatibility issues.

[0137] Triggering condition four: Receiving the user's corresponding detection instruction.

[0138] Optionally, if a user discovers that a function in a certain functional domain is not working or is missing while driving the vehicle, they can send a corresponding detection instruction to the main control unit for that functional domain (or for all functional domains). This corresponding detection instruction can be triggered using any one or more of the following methods: voice, interface click, button press, or gesture recognition. For example, the user can click a setting button on the in-vehicle display and / or user terminal, press a button located in the vehicle cabin, or make a sound near the in-vehicle microphone, thereby causing the components in the vehicle to receive the corresponding detection instruction and send it to the main control unit. Based on this corresponding detection instruction, the main control unit sends third-party information to the domain control unit in the corresponding functional domain or all functional domains to instruct the domain control unit to perform asset acquisition.

[0139] Based on trigger condition four, the vehicle can perform corresponding detection and version repair processes according to the user's instructions to meet the user's real-time needs.

[0140] Of course, there may be other triggering conditions, which will not be listed here.

[0141] Using the above methods, the vehicle will automatically perform matching checks and version repairs when the trigger conditions are met, which can improve the efficiency of discovering part mismatch issues and reduce manual operation costs.

[0142] Step 402: The domain control unit obtains the software version information of each sub-component.

[0143] Optionally, the domain control unit can send an asset acquisition request to each of its subordinate sub-components. Upon receiving the asset acquisition request, each sub-component obtains its own asset information and returns it to the domain control unit in an asset response message.

[0144] The asset information may include software version number, calibration version number, and hardware version number. The software version number refers to the version number of the software currently running on the sub-component; the calibration version number refers to the version number of the parameters used by the sub-component when running the current software; and the hardware version number refers to the version number of the physical hardware of the sub-component. Since the hardware version number is related to the physical hardware and cannot be changed, the software versions flashed in this application mainly refer to the software version number and the calibration version number.

[0145] Step 403: The domain control unit obtains the software version information of the domain control unit.

[0146] Here, the software version information of the domain control unit includes the software version number, calibration version number, hardware version number, and other information of the domain control unit.

[0147] Optionally, the domain control unit can also obtain information on whether the functional domain supports A / B zones. Whether A / B zones are supported refers to whether hot-switching is supported. Generally, when a functional domain does not support A / B zones, it has only one zone, and its operations can only be performed within that zone. If a software update is needed, the operations in that zone must be interrupted. However, vehicle operations cannot be interrupted, otherwise, safety issues will arise. Therefore, theoretically, software upgrades, repairs, or updates cannot be performed on a functional domain that does not support A / B zones. Conversely, when a functional domain supports A / B zones, it has two zones, and the functional domain is currently operating in one of them, such as zone B. Before updating zone B, the relevant operations in zone B can be migrated to zone A. This ensures that the software version in zone B can be updated without interrupting operations, thus achieving hot-switching. When a functional domain supports A / B zones, since updating a zone does not affect business execution, software upgrades, repairs, or updates can be performed on that functional domain.

[0148] It should be noted that when a functional domain supports AB zones, although there are two zones, the software versions of the two zones are stored in the same storage space. That is, the domain control unit locally stores only one software package, but this software package is used by the two zones in the form of a temporary cache.

[0149] Step 404: The domain control unit determines whether there is a software version mismatch between the domain control unit and the first sub-component based on the software version information of the domain control unit and the software version information of each sub-component. If yes, proceed to step 201; otherwise, proceed to step 405.

[0150] Here, the first sub-component can be one or more of the sub-components under the domain control unit. For example, referring to Figure 1b above, taking domain controller 1 as the domain control unit, if it is a scenario where domain controller 1 is replaced, then the software version of domain controller 1 will not be compatible with the software versions of all its sub-components ECU 11 to EUC 13. In this case, the first sub-component is ECU 11 to EUC 13. As another example, if it is a scenario where the software version of ECU 11 is flashed locally, then the software version of domain controller 1 is only incompatible with the software version of its sub-component ECU 11, but compatible with the software versions of other sub-components ECU 12 and EUC 13. In this case, the first sub-component is ECU 11.

[0151] Step 405: The domain control unit ends the repair process.

[0152] Optionally, in steps 404 and 405 above, the domain control unit can compare its own software version number with the software version numbers of its subordinate sub-components, and compare its own calibration version number with the calibration version numbers of its subordinate sub-components. If they are all the same, there is no software version mismatch problem, and the domain control unit can end this repair process. Conversely, if at least one sub-component's software version number is different from the domain control unit's, and / or at least one sub-component's calibration version number is different from the control unit's, then the current functional domain has a software version mismatch problem. The domain control unit can generate first information based on the domain control unit's asset information, the asset information of each sub-component, and the mismatch relationship between the domain control unit and at least one sub-component, and send it to the main control unit. This first information can be understood as including the domain control unit's and its subordinate sub-components' software version numbers, calibration version numbers, hardware version numbers, whether the current functional domain supports AB zones, and the mismatch relationship between the domain control unit and at least one sub-component.

[0153] Furthermore, optionally, the domain control unit can also include information on whether the current functional domain supports self-healing flashing in the first information, based on whether the current functional domain supports AB partitions. For example, when the functional domain supports AB partitions, since the functional domain can undergo software version upgrades, repairs, and updates, the domain control unit can include information on whether the current functional domain supports self-healing flashing in the first information. When the functional domain does not support AB partitions, since the functional domain cannot undergo software version upgrades, repairs, and updates, the domain control unit can include information on whether the current functional domain does not support self-healing flashing in the first information.

[0154] Based on this, after receiving the first message from the domain control unit, if the first message contains information indicating that self-healing flashing is not supported, the main control unit can directly terminate the repair process without sending the second message to the domain control unit. That is, it does not need to execute step 202, thus saving unnecessary resource overhead. Conversely, if the first message contains information indicating that self-healing flashing is supported, the main control unit can perform the software version flashing operation according to steps 202 to 203.

[0155] In one possible implementation, before instructing the domain control unit to repair the software version of its functional domain, the main control unit can first confirm with the user whether repair is necessary. That is, after executing step 201 above and before executing step 202 above, as shown in Figure 5, the following steps 501 to 504 can also be executed:

[0156] Step 501: The main control unit sends a first prompt message to the user. Correspondingly, the user receives the first prompt message sent by the main control unit.

[0157] The first message indicates that some software needs to be repaired.

[0158] Optionally, the initial notification message can be displayed on both the vehicle and / or mobile devices. For example, a notification can be displayed on both the vehicle and mobile devices, so that the user is notified of the repair requirement regardless of whether they are currently in the vehicle.

[0159] Optionally, the initial notification message can be delivered via voice broadcast, interface display, SMS notification, or message notification.

[0160] For example, taking voice prompts in the vehicle as an example, the main control unit can send the first prompt message to the in-vehicle voice device, which could be a car stereo or speaker. After receiving the first prompt message, the in-vehicle voice device can broadcast it aloud so that users in the vehicle can hear the information that some software in the vehicle needs to be repaired.

[0161] For example, taking the display of prompts on the vehicle's interface as an example, the main control unit can send the first prompt message to the vehicle's infotainment screen. The infotainment screen can include, but is not limited to, the central control screen, passenger screen, navigation screen, instrument panel, projection screen, and the windshield of the head-up display (HUD). After receiving the first prompt message, the infotainment screen can display it on its screen. In this way, users in the vehicle can intuitively obtain information that some software in the vehicle needs repair by viewing the infotainment screen.

[0162] For example, taking mobile device notifications as an example, the main control unit can send the first notification message to the user terminal, which could be the user's mobile phone 130 in Figure 1b, or a PAD, etc. If the main control unit is a T-Box, the T-Box can directly push the first notification message to the user terminal. If the main control unit is a domain controller, such as the Intelligent Driving Domain Controller, the main control unit needs to send the first notification message to a server (such as the server in Figure 1a, or the OTA Cloud 110 in Figure 1b), which will then indirectly push it to the user terminal. After receiving the first notification message, the user terminal can directly broadcast it via its speaker, display it on its screen, or push the message through an application, etc., without any specific limitations.

[0163] Step 502: The user sends a reply message to the main control unit. Correspondingly, the main control unit receives the reply message sent by the user.

[0164] The reply message is used to indicate the repair method.

[0165] Optionally, the repair method can be "Do not repair", "Repair", "Repair immediately", or "Schedule repair".

[0166] Optionally, replies can be sent on the vehicle and / or a mobile device. For example, if the user is not currently in the vehicle, they can operate on their mobile device to remotely reply to the main control unit in the vehicle. If the user is currently in the vehicle, they can reply directly on the vehicle's terminal. In other words, users can choose the most convenient operation to reply, thus improving the user's repair experience.

[0167] Optionally, replies can be sent via voice message, tapping the interface, sending an SMS, or sending a text message. The method of replying to the message can be the same as or different from the method of the initial notification message; there are no specific limitations.

[0168] For example, taking the implementation of both the first prompt message and the reply message as being based on a user interface, after the vehicle and / or user terminal receive the first prompt message, they can display the first interface on the vehicle's infotainment screen and / or the terminal's display screen. The first interface includes the first prompt message. As an example, the presentation of the first interface is shown in Figure 6a. This first interface includes the text "Some software in your vehicle needs to be repaired. We recommend that you repair it immediately!" (i.e., the first prompt message), and may also include two buttons: a "View" button and a "Do not repair" button.

[0169] If the user clicks the "Do Not Repair" button, the user's response message indicates "Do Not Repair" as the repair method. If the user clicks the "View" button (i.e., the first operation), the main control unit can further send a second prompt message to the vehicle and / or user terminal. Based on the second prompt message, the vehicle and / or user terminal will display a second interface on the vehicle screen and / or terminal display screen, which includes the second prompt message. As an example, the presentation of the second interface is shown in Figure 6b. This second interface includes detailed information on each problem point to be repaired, such as which domain control unit has a software version incompatibility problem with which sub-component. Below each problem point, there can also be three buttons: "Do Not Repair," "Repair Now," and "Schedule Repair."

[0170] For each issue, users can choose a repair method based on their needs. For example, if the issue is insignificant and doesn't require repair, the user can click the "Don't Repair" button, and the reply message will indicate "Don't Repair." If the issue is urgent and not repairing it will affect the vehicle's current driving, the user can click the "Repair Now" button, and the reply message will also indicate "Repair Now." If the issue is not urgent and can be delayed, to save processing resources, the user can click the "Schedule Repair" button. In this case, the vehicle and / or user terminal can also display a third interface on the vehicle screen and / or the terminal display, allowing the user to select a repair time. As an example, the presentation of the third interface is shown in Figure 6c. This third interface includes the text "Please select a time to schedule repair" and multiple scroll boxes. The multiple scroll boxes correspond to the year, month, day, hour, and minute (in some scenarios, there may also be a scroll box for seconds). Users can select the date and time to schedule repair by scrolling through each scroll box. For example, the date and time selected by the user in the figure is "July 15, 2024, 00:00".

[0171] It is understandable that the first to third interfaces shown in Figures 6a to 6c are merely examples. The first and second prompt messages can also be implemented through other forms of interfaces, or some elements may differ from the above interfaces, or they may be implemented together in one interface. For example, in another example, the first interface could also be as shown in Figure 6d, which could also include a "Repair" button. If the user clicks the "Repair" button, all problem points will be repaired. This avoids the user having to select and click on each problem point one by one, thus achieving one-click repair and saving the user's operational complexity.

[0172] In addition, other prompting and reply methods are similar to the interface display methods described above. For example, let's take the case where both the first prompt message and the reply message are based on voice as an example:

[0173] After receiving the first prompt message, the vehicle and / or user terminal can broadcast the message via the vehicle's audio system and / or the terminal's speaker, such as "Some software in your vehicle needs repair; we recommend you repair it immediately!" Then, the vehicle and / or user terminal can activate the vehicle's microphone and / or the terminal's microphone to capture the user's voice response. If the user replies with "Do not repair," the repair method indicated in the user's response message is "Do not repair." If the user replies with "Repair," the repair method indicated in the user's response message is "One-click repair," meaning all issues will be repaired.

[0174] If the user replies with the voice message "Report incompatibility details," the vehicle and / or user terminal can then use the vehicle audio system and / or terminal speaker to broadcast information about the software version incompatibility of each problematic domain control unit and sub-component. After each problem is broadcast, the system will ask the user "Do you need immediate repair or schedule a repair?" and receive the user's response via the vehicle microphone and / or terminal microphone. If the user replies with the voice message "No repair," the repair method indicated in the user's reply message will be "No repair." If the user replies with the voice message "Repair immediately," the repair method indicated in the user's reply message will be "Repair immediately." If the user replies with the voice message "Schedule a repair," the system can then use the vehicle audio system and / or terminal speaker to broadcast "Please select a time for scheduled repair," and receive the user's scheduled repair time via the vehicle microphone and / or terminal microphone.

[0175] It should be understood that other prompting and reply methods can be deduced by analogy, and will not be repeated here.

[0176] Step 503: The main control unit determines whether the reply message indicates that the functional domain where the domain control unit is located should be flashed. If not, proceed to step 504; if yes, proceed to step 202 as above.

[0177] Optionally, referring to Figures 6a to 6d above, if the user clicks the "Do Not Repair" button (i.e., the third operation) in Figure 6a or 6d, a reply message indicates that the functional domain containing all domain control units should not be flashed. If the user clicks the "Do Not Repair" button corresponding to a specific functional domain in Figure 6b, a reply message indicates that the functional domain containing that domain control unit should not be flashed. If the user clicks the "Repair" button in Figure 6d, a reply message indicates that the functional domain containing all domain control units should be flashed. If the user clicks the "Repair Now" button or "Schedule Repair" button (i.e., the second operation) corresponding to a specific functional domain in Figure 6c, a reply message indicates that the functional domain containing that domain control unit should be flashed.

[0178] Step 504: The main control unit ends the process.

[0179] Here, for a domain control unit, if the reply message indicates that the functional domain to which the domain control unit belongs should not be flashed, it means that the user does not need to repair the functional domain. Therefore, the repair process for the functional domain can be ended directly to meet the user's actual needs.

[0180] Conversely, if the reply message instructs the functional domain containing the domain control unit to be flashed, it can be determined whether to flash immediately or schedule a flash. If it is an immediate flash, the second message can be sent directly to the domain control unit, instructing it to immediately begin the repair process for the functional domain. If it is a scheduled flash, the second message can be sent to the domain control unit at the scheduled time (e.g., midnight on July 15, 2024, as shown in Figure 6c), so that the domain control unit can automatically start the repair process for the functional domain at the user-specified time.

[0181] Based on the above implementation method, by determining with the user whether a certain functional domain needs to be repaired and the corresponding repair method before instructing the user to repair it, the user can repair or not repair the functional domain according to the user's instructions, thus meeting different user needs and improving the universality of version repair methods.

[0182] The above content introduces the general process of the version repair method. The following section will further introduce other implementation details based on two implementation schemes.

[0183] It should be noted that the following implementation scheme one corresponds to an example where the triggering condition for the third information is the aforementioned triggering condition one, and the following implementation scheme two corresponds to an example where the triggering condition for the third information is the aforementioned triggering condition two. The relevant content of these two implementation schemes also applies to other triggering conditions, such as the aforementioned triggering condition three, triggering condition four, and other triggering conditions, which this application does not specifically limit.

[0184] Furthermore, in the various embodiments of this application, unless otherwise specified or logically conflicting, the terms and / or descriptions of different embodiments are consistent and can be referenced by each other, and the technical features of different embodiments can be combined to form new embodiments according to their inherent logical relationships.

[0185] Implementation Plan 1

[0186] Please refer to Figure 7, which illustrates the interactive flow of a version repair method provided in Implementation Scheme 1. The method includes the following steps:

[0187] Step 701: After the vehicle starts, the main control unit sends third information to the domain control unit. Correspondingly, the domain control unit receives the third information sent by the main control unit after the vehicle starts.

[0188] The third piece of information is used to instruct the domain control unit to collect assets.

[0189] Step 702: The domain control unit obtains the software version information of the domain control unit and the software version information of each of its subordinate sub-components, and determines that the software version of the domain control unit is incompatible with the software version of its first subordinate sub-component.

[0190] The first sub-component is at least one of the sub-components attached to the domain control unit.

[0191] Step 703: The domain control unit sends first information to the master control unit. Correspondingly, the master control unit receives the first information sent by the domain control unit.

[0192] The relevant content of steps 701 to 703 above can be found in Figure 4 and related text above, and will not be repeated here.

[0193] Step 704: The main control unit sends the first information to the OTA cloud. Correspondingly, the OTA cloud receives the first information sent by the main control unit.

[0194] Optionally, during vehicle startup and subsequent diagnostics, if a software version mismatch is detected in a particular functional domain, the issue could be due to an error in the domain control unit's software version or an error in the software version of a sub-component under the domain control unit. The main control unit cannot determine the specific cause. If the former is the problem, the software package stored locally in the domain control unit is highly likely incorrect (i.e., not compatible with the overall vehicle version). This software package cannot be used to flash the domain control unit or its sub-components; a correct software package needs to be obtained from the OTA cloud.

[0195] Based on this, to ensure the correctness of the software packages stored locally by the domain control unit, the main control unit can forward the first information sent by the domain control unit to the OTA cloud after receiving it. This first information may include, in addition to information about software version incompatibility between the domain control unit and its subordinate first sub-components, other asset information such as vehicle identification, vehicle type, vehicle software version number, domain control unit software version number, software version numbers of each subordinate sub-component, and whether the functional domain supports flashing, etc.

[0196] Step 705: The OTA cloud determines whether the software version of the domain control unit is the same as the software version of the vehicle's major version. If not, proceed to step 706; if yes, proceed to step 709.

[0197] Optionally, based on the content of the first information above, after receiving the first information, the OTA cloud can first parse the first information to obtain the aforementioned incompatibility relationship, vehicle identification, vehicle type, software version number of the domain control unit, software version numbers of each subordinate sub-component, and information on whether the functional domain supports flashing. Then, based on the parsed vehicle type, the OTA cloud can determine whether the vehicle is a non-test vehicle. Non-test vehicles may include domestic sales vehicles and commercial vehicles. When the vehicle is not a non-test vehicle, it means that the vehicle is a test vehicle. Test vehicles may require incompatible versions for some tests, and the incompatibility relationship does not need to be repaired. Therefore, the main control unit can directly end the process. When the vehicle is a non-test vehicle, the OTA cloud can also determine whether the functional domain where the domain control unit is located supports flashing based on the parsed information on whether the functional domain supports flashing. If it does not support flashing, the process can also be directly ended.

[0198] If the vehicle is not a test vehicle, and the functional domain where the domain control unit resides also supports flashing, the OTA cloud can also query its local queue list based on the parsed vehicle identifier to determine if a queued task for that vehicle exists. If it exists, it means that the OTA cloud has previously created an upgrade or repair task for that vehicle, but because the vehicle was not previously online, the upgrade or repair task could not be pushed to the vehicle, or it could have been pushed to the vehicle but the user had not yet clicked whether to upgrade or repair. In this case, there is no need to create a repair task again, so the OTA cloud can directly end the process. Conversely, if no queued task exists for the vehicle, it can then query the local database based on the parsed vehicle software version number to see if a matching major version exists. If it does not exist, it means there is a problem with the vehicle software version number. Therefore, the OTA cloud can generate fault information and store it in a local problem list, where the fault information indicates that a repair task for the problematic vehicle cannot be generated. Optionally, OTA Cloud can also display a query button on its interface. The query button can be presented as a small red dot, an exclamation mark, or a text prompt. By clicking the query button, maintenance personnel can see the various fault information stored in the problem list. Each fault information includes the vehicle identification of the failed repair and the reason for the failure.

[0199] Conversely, if a matching vehicle version exists locally in the OTA cloud, the OTA cloud can obtain this vehicle version and compare its software version number with that of the domain control unit. If the domain control unit's software version number is not the vehicle version number, it indicates a problem with the domain control unit's software version. This could be due to a component replacement causing the original software package to be deleted, or the domain control unit not having the software package at the factory. In these cases, the domain control unit needs to re-download the software package. Conversely, if the domain control unit's software version number matches the vehicle version number, it indicates that the domain control unit's software version is correct. If this is subsequently verified by the main control unit, the domain control unit does not need to re-download the software package.

[0200] Step 706: The OTA cloud sends the fifth piece of information to the main control unit, which includes a download link. Correspondingly, the main control unit receives the fifth piece of information sent by the OTA cloud.

[0201] Understandably, since the domain control unit's software version is based on locally stored software packages for upgrades or updates, a problem with the domain control unit's software version indicates a problem with the locally stored software package, requiring the domain control unit to download a working software package. Therefore, the OTA cloud can send a fifth piece of information carrying a download link to the main control unit. The address corresponding to the download link stores the software package for the functional domain where the domain control unit resides, and the software version of this package is the same as the overall vehicle version.

[0202] Optionally, the download link needs to be created by operations and maintenance personnel, a process that typically takes a considerable amount of time, during which the vehicle may have already been taken offline. Therefore, before sending the fifth message to the main control unit, the OTA cloud can first determine whether the main control unit is online. If it is online, it means the vehicle is still online. In this case, the OTA cloud can directly send the fifth message to the main control unit, allowing the vehicle to complete the flashing of the problematic software version during this usage. Conversely, if the main control unit is offline, it means the vehicle has already been taken offline. In this case, the OTA cloud can store the flashing task (i.e., the fifth message) created this time in a local queue list. When the vehicle is detected to be online again, the flashing task in the queue list will be sent to the main control unit, allowing the vehicle to directly flash the problematic software version the next time it comes online.

[0203] In step 707, the master control unit sends a fourth message to the domain control unit, which includes a download link. Correspondingly, the domain control unit receives the fourth message sent by the master control unit.

[0204] In step 708, the domain control unit downloads the software package from the download link to its local machine. Then, proceed to step 710.

[0205] Optionally, after receiving the fifth message sent by the OTA cloud, if the fifth message contains a download link, the main control unit can first generate a fourth message based on the download link and send it to the domain control unit to instruct the domain control unit to download the software package from the download link and store it locally. Then, a trigger message, namely the second message in step 712 below, is sent to the domain control unit to instruct the domain control unit to flash the software version of its functional domain.

[0206] In the above scenario, the software package stored locally by the domain control unit is downloaded after the domain control unit sends the first message to the main control unit and before receiving the second message from the main control unit, corresponding to the major version of the entire vehicle. Since the software package download operation is completed before the main control unit sends the second message to the domain control unit, the software package stored locally by the domain control unit can be updated to be consistent with the major version of the entire vehicle before instructing the domain control unit to perform the flashing, thus ensuring the accuracy of subsequent flashing based on the locally stored software package.

[0207] Understandably, although the domain control unit needs to go through the download process, the download process is automatic and will not prompt the user on the vehicle screen or mobile device. After the automatic download is completed, the main control unit can execute the following steps 710.

[0208] In step 709, the OTA cloud sends the fifth piece of information to the main control unit. This fifth piece of information does not include a download link. Accordingly, the main control unit receives the fifth piece of information sent by the OTA cloud and then executes step 710.

[0209] Here, after receiving the fifth message sent by the OTA cloud, if the fifth message does not contain a download link, it may optionally also contain integrity verification information. The main control unit verifies the software package stored locally by the domain control unit based on this integrity verification information. If the verification passes, it means that the software package stored locally by the domain control unit is consistent with the overall vehicle version, and the software package is correct and does not need to be downloaded again. Therefore, the main control unit only needs to send a trigger message to the domain control unit, which is the second message in step 712 below, to instruct the domain control unit to flash the software version of its functional domain.

[0210] In the above scenario, since the domain control unit has not downloaded a new software package, the software package stored locally by the domain control unit is the software package after the most recent upgrade of the vehicle. If the vehicle has not been upgraded before, it corresponds to the initial software package.

[0211] Step 710: The main control unit sends a first prompt message to the user. The user receives the first prompt message sent by the main control unit.

[0212] The first message indicates that some software needs repair. Optionally, the user may also be prompted to choose a repair method.

[0213] After the OTA cloud sends the fifth piece of information to the main control unit, if the domain control unit already has the correct software package locally, there will be no further download process. The domain control unit can then directly reuse the locally stored software package for flashing. However, in scenarios where the domain control unit does not have the correct software package locally due to component replacement, the domain control unit will be instructed to download the same version of the software package as the vehicle's major version again. Compared to a regular upgrade task, the system no longer prompts the user that software is pending an upgrade, nor does it provide a description of the new features in the upgrade version. Instead, it displays a version repair prompt page, indicating that some software needs to be repaired. This prompt can be displayed on both the vehicle's infotainment screen and mobile devices, and the corresponding buttons have changed from "Update Now" and "Schedule Update" to "Repair Now" and "Schedule Repair". For specific prompt content, please refer to Figures 5, 6a to 6d above, and the text description.

[0214] Step 711: The user sends a first reply message to the main control unit. The main control unit receives the first reply message sent by the user.

[0215] The first response message is used to indicate the functional domain in which the repair domain control unit is located.

[0216] For example, in conjunction with Figures 6a to 6d above, the first reply message can correspond to the user clicking the "Repair" button in Figure 6a or Figure 6d, or the "Repair Now" or "Schedule Repair" button corresponding to the current domain control unit in Figure 6b.

[0217] Optionally, if the user sends a second response message to the main control unit, indicating that the functional domain where the domain control unit is located should not be repaired, the main control unit can directly terminate the repair process for the functional domain where the current domain control unit is located. The second response message can correspond to the user clicking the "Do Not Repair" button in Figure 6d or the "Do Not Repair" button corresponding to the current domain control unit in Figure 6b.

[0218] It should be noted that steps 710 and 711 above are optional steps. That is to say, after the domain control unit downloads the software package from the download link to the local machine, or after receiving the fifth message that the download link does not exist, it can directly execute step 712 below without needing to confirm with the user.

[0219] In step 712, the master control unit sends the second information to the domain control unit. Correspondingly, the domain control unit receives the second information sent by the master control unit.

[0220] Here, the second message may simply be a trigger message without any actual content.

[0221] Optionally, before sending the second information to the domain control unit, the main control unit can also check whether the vehicle speed and gear position meet the requirements before the repair, such as whether the vehicle speed is lower than the set speed and whether the gear is in the parking position. If so, the main control unit can send the second information to the domain control unit.

[0222] Optionally, after receiving the second information, the domain control unit can retrieve the locally stored software package. If step 712 is executed after step 708 above, the software package is one that the domain control unit has just downloaded and is consistent with the overall vehicle version. If step 712 is executed after step 709 above, the software package is the software version after the last upgrade of the domain control unit; otherwise, it is the initial version. In either case, the software version of the software package stored locally by the domain control unit is consistent with the overall vehicle software version.

[0223] Step 713: The domain control unit flashes the software version of the domain control unit or the software version of the first sub-component. The flashed software version of the first sub-component is compatible with the software version of the domain control unit.

[0224] Here, the domain control unit can flash only sub-components with software versions different from the locally stored software packages. For example, it can retrieve the software package for a sub-component with a different software version from the locally stored software package, flash the software version of that sub-component, and wait for the flashing result returned by the sub-component. Since the locally stored software packages are consistent with the overall vehicle version, the software version of the flashed sub-component will be consistent with the overall vehicle version.

[0225] Step 714: The domain control unit sends the repair result to the master control unit. Correspondingly, the master control unit receives the repair result sent by the domain control unit.

[0226] Here, after receiving the flashing result of the sub-component, the domain control unit returns the repair result to the main control unit.

[0227] Optionally, after receiving the repair result from the domain control unit, if the main control unit determines that the functional domain where the domain control unit is located has been successfully flashed, it can also return a successful repair response message to the OTA cloud. If it determines that the functional domain where the domain control unit is located has failed to flash, it can return to step 712 above, that is, instruct the domain control unit to re-flash. If the flashing is successful within the preset number of flashes, a successful repair response message is returned to the OTA cloud. If the flashing is not successful before the preset number of flashes is reached, a failed repair response message is returned to the OTA cloud so that the OTA cloud can notify the maintenance personnel to perform manual repair.

[0228] Based on the above implementation scheme one, a version compatibility check can be performed every time the vehicle starts. If a version mismatch is detected between the domain control unit and its sub-components, a repair task is automatically created on the OTA cloud and sent to the vehicle to align the compatibility between the domain control unit and its sub-components, ensuring that the software versions of the components in each functional domain of the vehicle are consistent. In this way, the software versions of the components in each functional domain are compatible during vehicle operation, thereby ensuring vehicle stability and functional availability, and contributing to a better driving experience for the user.

[0229] Implementation Plan 2

[0230] Please refer to Figure 8, which illustrates the interactive flow of a version repair method provided in Implementation Scheme 2. The method includes the following steps:

[0231] Step 801: The OTA cloud sends an upgrade task to the main control unit. Correspondingly, the main control unit receives the upgrade task sent by the OTA cloud.

[0232] The upgrade task includes a download link, and the address corresponding to the download link stores the software package to be upgraded.

[0233] Optionally, there may be multiple download links, each corresponding to a different functional domain in the vehicle. The address corresponding to a download link stores the upgrade software package for all components (including the domain control unit and all its sub-components) in the corresponding functional domain.

[0234] Step 802: The master control unit sends a download task to the domain control unit. Correspondingly, the domain control unit receives the download task sent by the master control unit.

[0235] The download task includes a download link.

[0236] Optionally, the download link is the download link corresponding to the functional domain where the domain control unit is located.

[0237] For example, after receiving an upgrade task, the main control unit parses the upgrade task to obtain the download links corresponding to each functional domain. Based on the download links corresponding to each functional domain, it sends a download task to the domain control unit of each functional domain. The download task includes the download link corresponding to the functional domain where the domain control unit is located.

[0238] Step 803: The domain control unit downloads the software package from the download link to its local machine.

[0239] Here, since the download link contains the upgrade packages for all components in the functional domain where the domain control unit is located, the domain control unit will locally store the upgrade packages for all components in its functional domain after completing the download process.

[0240] Step 804: The main control unit sends an upgrade notification message to the user. Correspondingly, the user receives the upgrade notification message sent by the main control unit.

[0241] The upgrade prompt message is used to prompt users to choose whether to upgrade or not.

[0242] Optionally, upgrade notifications can be delivered via voice announcements, interface displays, SMS notifications, or message notifications.

[0243] For example, taking interface display as an example, the main control unit can send an upgrade prompt message to the vehicle and / or user terminal. The vehicle and / or user terminal then display a fourth interface on the vehicle's infotainment screen and / or the terminal's display screen, which includes the upgrade prompt message. As an example, please refer to Figure 9, which shows one possible presentation of the fourth interface. This fourth interface includes the text "Your vehicle software needs an upgrade. We recommend that you upgrade immediately" (i.e., the upgrade prompt message), and may also include two buttons: an "Upgrade Now" button and an "Schedule Upgrade" button.

[0244] It is understandable that the fourth interface shown in Figure 9 is only an example, and this application does not limit the specific interface presentation of the upgrade prompt.

[0245] Step 805: The user sends an upgrade response message to the main control unit. Correspondingly, the main control unit receives the upgrade response message sent by the user.

[0246] The upgrade response message indicates that an upgrade should be performed.

[0247] Optionally, in conjunction with the fourth interface shown in Figure 9, the upgrade reply message can correspond to the user's operation of clicking the "Upgrade Now" button or the "Schedule Upgrade" button on the fourth interface.

[0248] Step 806: The master control unit sends an upgrade instruction to the domain control unit. Correspondingly, the domain control unit receives the upgrade instruction from the master control unit.

[0249] Referring to Figure 9 above, if the user clicks the "Upgrade Now" button, the main control unit can immediately send an upgrade instruction to the domain control unit after receiving the user's upgrade response message, instructing the domain control unit to immediately upgrade the software version of its functional domain. If the user clicks the "Schedule Upgrade" button, the main control unit can wait until the user's scheduled time before sending the upgrade instruction to the domain control unit, so that the domain control unit can perform the upgrade according to the user's specified time.

[0250] Step 807: The domain control unit upgrades the software version of each component in its functional domain based on the locally stored software package.

[0251] Here, the domain control unit can retrieve software packages from its local storage, extract the corresponding software package from the local storage, and update its own software version. The domain control unit can also retrieve the software packages for its subordinate sub-components from its local storage, send them to each sub-component respectively, and instruct each sub-component to perform an upgrade. Each sub-component uses the received software version to update its own software version, and after the update is complete, returns the upgrade result to the domain control unit.

[0252] Understandably, since the software package stored locally was just downloaded and corresponds to the software version to be upgraded, after the domain control unit upgrades all components in its functional domain based on the locally stored software package, the software version of all components in the functional domain can be updated to the required software version.

[0253] Step 808: The domain control unit sends the upgrade result to the master control unit. Correspondingly, the master control unit receives the upgrade result sent by the domain control unit.

[0254] Optionally, after the pre-control unit receives the upgrade results of all its subordinate sub-components, it determines that all sub-components have been upgraded. At this time, the domain control unit can send the upgrade results of its functional domain to the main control unit. The upgrade results are used to indicate that the functional domain has been upgraded.

[0255] In step 809, the master control unit sends third information to the domain control unit. Correspondingly, the domain control unit receives the third information sent by the master control unit.

[0256] The third piece of information is used to instruct the domain control unit to collect assets.

[0257] Optionally, the main control unit can send the third information to all domain control units in the vehicle after receiving the upgrade results from all domain control units in the vehicle. Alternatively, it can send the third information to each domain control unit after receiving the upgrade result from each domain control unit. In other words, the main control unit can perform version repair centrally after all functional domains have been upgraded, or it can perform version repair separately for each upgraded functional domain; there is no specific limitation.

[0258] Taking the former as an example, after receiving the upgrade results from all domain control units, the main control unit determines that the software versions of all vehicle components have been upgraded. According to the original upgrade process, the main control unit needs to return the upgrade results to the OTA cloud and then exit the upgrade mode. However, in this application, the main control unit does not return the upgrade results to the OTA cloud first, that is, it does not exit the upgrade mode. Instead, it sends third-party information to each domain control unit to instruct each domain control unit to perform asset collection, that is, to start the software version detection process to calibrate the accuracy of this upgrade result.

[0259] Step 810: The domain control unit obtains the software version information of the domain control unit and the software version information of each of its subordinate sub-components, and determines that the software version of the domain control unit is incompatible with the software version of its first subordinate sub-component.

[0260] The first sub-component is at least one of the sub-components attached to the domain control unit.

[0261] Here, since the upgrade has just been completed, the software package stored locally by the domain control unit can be understood as the software version to be upgraded in this upgrade task. If a sub-component is incompatible, it means that the sub-component's version number is inconsistent with the software version to be upgraded in this OTA upgrade task. The main control unit sends the first message to the incompatible domain control unit. Conversely, if they are compatible, the process can be terminated directly without sending the first message to the main control unit.

[0262] Step 811: The domain control unit sends first information to the master control unit. Correspondingly, the master control unit receives the first information sent by the domain control unit.

[0263] The first piece of information includes information about the incompatibility between the software versions of the domain control unit and its subordinate first sub-component.

[0264] In step 812, the master control unit sends the second information to the domain control unit. Correspondingly, the domain control unit receives the second information sent by the master control unit.

[0265] Combining steps 811 and 812 above, there are two possible implementation methods:

[0266] In the first implementation, after completing asset acquisition, each domain control unit can return a first message to the main control unit. Some first messages contain information indicating that the software versions of the domain control unit and all its subordinate sub-components are compatible, while others contain information indicating that the software versions of the domain control unit and its first subordinate sub-components are incompatible. Based on this, after receiving the first messages from all domain control units, the main control unit determines that all domain control units have completed asset acquisition. The main control unit can then, based on the first messages returned by each domain control unit, send a second message only to the domain control units with incompatible software versions, instructing these control units to perform software version repair operations.

[0267] In the second implementation method, after each domain control unit completes asset acquisition, if there are any incompatibilities, it can return a first message to the main control unit. If there are no incompatibilities, it does not need to send a message to the main control unit, thus saving communication overhead. Based on this, the main control unit only needs to receive the first message from a domain control unit to determine that there is an incompatibility issue. Therefore, the main control unit can directly send a second message to that domain control unit to instruct it to perform software version repair operations.

[0268] Optionally, since the software package stored locally by the domain control unit was downloaded during the recent upgrade and already corresponds to the software version to be upgraded, the master control unit only needs to send a trigger message to the domain control unit, without requiring the domain control unit to download the upgrade software package again. Therefore, the second message can simply be a trigger message without any substantive content.

[0269] Step 813: The domain control unit flashes the software version of the domain control unit or the software version of the first sub-component. The flashed software version of the first sub-component is compatible with the software version of the domain control unit.

[0270] Optionally, the domain control unit can obtain locally stored software packages and retrieve the software package of the first sub-component whose software version is incompatible with the domain control unit from the locally stored software packages. The software package of the first sub-component is then used to upgrade the software version of the first sub-component so that the upgraded first sub-component corresponds to the software version that needs to be upgraded.

[0271] Step 814: The domain control unit sends the flashing result to the master control unit. Correspondingly, the master control unit receives the flashing result sent by the domain control unit.

[0272] Optionally, after receiving the flashing results from each domain control unit, the main control unit determines that the version repair process is complete. At this point, the main control unit can return an upgrade completion message to the OTA cloud, thereby exiting the upgrade mode.

[0273] Based on the above implementation scheme 2, a version compatibility check can be performed once at the end of each vehicle upgrade. If it is found that the software version of the sub-component in the functional domain is incompatible with the main control unit, the version repair process will be automatically entered to re-flash the software version of the incompatible sub-component, so as to align the software version of the sub-component with the software version of the domain control unit. Moreover, the aligned software version is the software version of this upgrade, thus ensuring the accuracy of the upgrade.

[0274] Based on the version repair method described above, this application can also provide a version repair device, which can be used to execute the above version repair method. The relevant features can be found in the above method embodiments, and will not be repeated here.

[0275] In one possible implementation, Figure 10 shows a possible structural schematic diagram of a version repair device provided in this application. The version repair device 1000 may include modules or units for implementing the methods described in the embodiments above. For example, in one possible design, the version repair device 1000 includes a processing unit 1010 and a transceiver unit 1020.

[0276] The processing unit 1010 can also be referred to as a processor, processing chip, processing board, processing unit, or processing device, etc., and the transceiver unit 1020 can also be referred to as a communication unit, transceiver, transceiver device, or transceiver unit, etc. Optionally, the transceiver unit 1020 is used to perform the processing operations in the above-mentioned version repair method. The transceiver unit 1020 is used to perform the sending and receiving operations in the above-mentioned version repair method. The device in the transceiver unit 1020 that implements the receiving function can be regarded as a receiving unit, and the device in the transceiver unit 1020 that implements the sending function can be regarded as a sending unit. That is, the transceiver unit 1020 includes a receiving unit and a sending unit.

[0277] The repair device 1000 can be the domain control unit or a module (e.g., circuit, chip, or chip system) in the domain control unit as described above, or it can be a logical node, logical module, or software applied to or used in conjunction with the domain control unit or its module, capable of realizing all or part of the functions of the domain control unit.

[0278] For example, in one embodiment, the transceiver unit 1020 is used to send first information to the main control unit and receive second information from the main control unit. The first information includes information that the software version of the domain control unit is not compatible with the software version of the first sub-component under the domain control unit. The second information is used to instruct the domain where the domain control unit is located to perform version repair. The processing unit 1010 is used to flash the software version of the domain control unit or the software version of the first sub-component. After flashing, the software version of the first sub-component is compatible with the software version of the domain control unit.

[0279] In one possible design, before the transceiver unit 1020 sends the first information to the main control unit: the transceiver unit 1020 is also used to receive third information from the main control unit, the third information being used to instruct the domain control unit to perform asset acquisition; the processing unit 1010 is also used to obtain the software version information of the domain control unit and the software version information of each sub-component under the domain control unit, and based on the software version information of the domain control unit and the software version information of each sub-component, determine that the software version of the domain control unit is incompatible with the software version of the first sub-component, the first sub-component being at least one of the sub-components under the domain control unit.

[0280] In a further possible design, the third piece of information is sent by the main control unit to the domain control unit after the vehicle starts or before exiting the upgrade mode after the software version upgrade of each component of the vehicle is completed.

[0281] In one possible design, the processing unit 1010 is specifically used to: obtain the software package stored locally in the domain control unit, wherein the version of the software package is the first version; if the current version of the domain control unit is not the first version, then the software version of the domain control unit is flashed; if the version of the first sub-component is not the first version, then the software version of the first sub-component is flashed.

[0282] In a further possible design, the software package stored locally by the domain control unit may be: the software package that the domain control unit received during the most recent software version upgrade of the vehicle, or the software package that the domain control unit downloaded after sending the first message and before receiving the second message.

[0283] In a further possible design, the first information also includes the software version information of the domain control unit; before the transceiver unit 1020 receives the second information sent by the main control unit: the transceiver unit 1020 is also used to receive the fourth information sent by the main control unit, the fourth information including a download link, the fourth information being sent by the main control unit to the domain control unit when the software version information of the domain control unit is different from the software version information of the vehicle; the processing unit 1010 is also used to download the software package corresponding to the domain control unit to the local machine according to the download link.

[0284] The repair device 1000 can be the main control unit or a module (e.g., circuit, chip, or chip system) in the main control unit as described above, or it can be a logic node, logic module, or software applied to the main control unit or its module, or used in conjunction with the main control unit or its module, capable of realizing all or part of the functions of the main control unit.

[0285] For example, in one embodiment, the transceiver unit 1020 is used to receive first information from the domain control unit and send second information to the domain control unit. The first information includes information that the software version of the domain control unit is incompatible with the software version of the first sub-component under the domain control unit. The second information is used to instruct the domain where the domain control unit is located to perform version repair.

[0286] In one possible design, the second information is also used to indicate the part to be repaired.

[0287] In one possible design, before receiving the first information sent by the domain control unit, the transceiver unit 1020 is also used to send a third information to the domain control unit, which instructs the domain control unit to perform asset acquisition.

[0288] In a further possible design, the transceiver unit 1020 is specifically used to: send third information to the domain control unit after the vehicle is started; and / or, send third information to the domain control unit before exiting the upgrade mode after the software version upgrade of each component of the vehicle is completed.

[0289] In one possible design, the third message is sent after the vehicle is started. Before sending the second message to the domain control unit, the transceiver unit 1020 is also used to: send the first message to the OTA cloud and receive the fifth message sent by the OTA cloud. The fifth message is used to instruct the domain where the domain control unit is located to perform version repair.

[0290] In a further possible design, the first information also includes the software version information of the domain control unit. If the software version information of the domain control unit is different from the software version information of the vehicle, the fifth information also includes a download link. After receiving the fifth information sent by the OTA cloud, the transceiver unit 1020 is also used to send the fourth information to the domain control unit before sending the second information. The fourth information contains a download link, which is used by the domain control unit to download the software package corresponding to the domain control unit.

[0291] In a further possible design, after receiving the fifth information sent by the OTA cloud and before sending the second information to the domain control unit, the transceiver unit 1020 is also used to: send a first prompt message to the user and determine the user's first reply message. The first prompt message is used to prompt the user to select a repair method, and the first reply message is used to indicate that repair should be performed.

[0292] In a further possible design, the first prompt message is displayed on a first interface of the user terminal and / or the vehicle display screen to indicate that some software needs to be repaired; after sending the first prompt message to the user, the transceiver unit 1020 is further configured to: in response to the user's first operation on the first interface, display a second interface to the user, the second interface including a second prompt message, the second prompt message indicating information about the mismatch between the software version of the domain control unit and the software version of the sub-component corresponding to each software to be repaired, and the repair method for each software to be repaired; in response to the user's second operation on the second interface, determine the user's first reply message.

[0293] In a further possible design, the transceiver unit 1020 is also used to: in response to a third operation by the user on the first interface, determine a second reply message from the user, the second reply message being used to indicate that no repair should be performed.

[0294] In a further possible design, the transceiver unit 1020 is specifically used to: if the first reply message indicates immediate repair, then directly send the second information to the domain control unit; if the first reply message indicates scheduled repair, then send the second information to the domain control unit at the scheduled time.

[0295] The repair device 1000 can be the OTA cloud or a module (e.g., circuit, chip, or chip system) in the OTA cloud as described above, or it can be a logical node, logical module, or software applied to the OTA cloud or its module, or used in conjunction with the OTA cloud or its module, capable of realizing all or part of the OTA cloud functions.

[0296] For example, in one embodiment, the transceiver unit 1020 is used to receive first information sent by the main control unit and send fifth information to the main control unit. The first information includes information that the software version of the domain control unit is not compatible with the software version of the first sub-component under the domain control unit. The fifth information is used to instruct the domain where the domain control unit is located to perform version repair.

[0297] In one possible design, the first information also includes the software version information of the domain control unit; before the transceiver unit 1020 sends the fifth information to the main control unit, the processing unit 1010 is used to: determine whether the software version information of the domain control unit and the software version information of the vehicle are the same; if the software version information is the same, the fifth information is generated, and the fifth information does not carry a download link.

[0298] In a further possible design, the processing unit 1010 is also used to: generate fifth information if the software version information is different, the fifth information including a download link, the download link being used by the main control unit to instruct the domain control unit to download the software package corresponding to the domain control unit.

[0299] It is understood that the division of units in the above-described device is merely a logical functional division. One function can correspond to one functional unit, or two or more functions can be integrated into one functional unit. In actual implementation, all or some units can be integrated onto a single physical entity, or distributed across different physical entities. Furthermore, the aforementioned functional units can be implemented in hardware, software, or a combination of both. Whether a function is executed in hardware or software depends on the specific application and design constraints of the technical solution. Those skilled in the art can use different methods to implement the described functions for specific applications, but such implementations should not be considered beyond the scope of this application.

[0300] In one example, the functional unit in any of the above devices may be one or more integrated circuits configured to implement the above methods, such as: one or more application-specific integrated circuits (ASICs), or one or more central processing units (CPUs), one or more microcontroller units (MCUs), one or more digital signal processors (DSPs), or one or more field-programmable gate arrays (FPGAs), or a combination of at least two of these integrated circuit forms.

[0301] In another possible implementation, please refer to Figure 11, which shows another possible structural schematic of the version repair device. The version repair device 1100 shown in Figure 11 includes at least one processor 1110 and interface circuitry 1120. The at least one processor 1110 is coupled to a memory. Optionally, the memory may be located within the version repair device 1100, integrated with the processor 1110, or it may be located outside the version repair device 1100. For example, the version repair device 1100 may also include at least one memory 1130. The at least one memory 1130 stores the necessary computer programs (or instructions) and / or data for implementing any of the above embodiments; the at least one processor 1110 can execute the computer programs (or instructions) and / or data stored in the at least one memory 1130 to complete the methods in any of the above embodiments.

[0302] The version repair device 1100 can interact with other devices through the interface circuit 1120. For example, the interface circuit 1120 can be a transceiver, circuit, bus, module, pin, or other type of communication interface. When the version repair device 1100 is a chip-type device or circuit, the interface circuit 1120 can also be an input / output circuit, capable of inputting information (or receiving information) and outputting information (or sending information). The processor can be an integrated processor, microprocessor, integrated circuit, or logic circuit, and the processor can determine the output information based on the input information.

[0303] The coupling in this embodiment is an indirect coupling or communication connection between devices, units, or modules, which can be electrical, mechanical, or other forms, used for information exchange between devices, units, or modules. The processor 1110 may operate in conjunction with the memory 1130 and the interface circuit 1120. This embodiment does not limit the specific connection medium between the processor 1110, the memory 1130, and the interface circuit 1120.

[0304] Optionally, referring to Figure 11, the processor 1110, the memory 1130, and the interface circuit 1120 are interconnected via a bus. The bus can be a peripheral component interconnect (PCI) bus or an extended industry standard architecture (EISA) bus, etc. The bus can be divided into address bus, data bus, control bus, etc. For ease of illustration, only one thick line is used in Figure 11, but this does not indicate that there is only one bus or one type of bus.

[0305] In the embodiments of this application, the processor 1110 may be a general-purpose processor, a digital signal processor, an application-specific integrated circuit, a field-programmable gate array or other programmable logic device, a discrete gate or transistor logic device, or a discrete hardware component, capable of implementing or executing the methods, steps, and logic block diagrams disclosed in the embodiments of this application. The general-purpose processor may be a microprocessor or any conventional processor, etc. The steps of the methods disclosed in the embodiments of this application can be directly manifested as being executed by a hardware processor, or being executed by a combination of hardware and software modules in the processor.

[0306] In this embodiment, the memory 1130 can be a non-volatile memory, such as a hard disk drive (HDD) or a solid-state drive (SSD), or it can be volatile memory, such as random-access memory (RAM). The memory 1130 can be any other medium capable of carrying or storing desired program code in the form of instructions or data structures, and accessible by a computer, but is not limited thereto. The memory 1130 in this embodiment can also be a circuit or any other device capable of implementing storage functions for storing program instructions and / or data.

[0307] When the version repair device 1100 is used to implement the above method embodiment, the processor 1110 is used to implement the function of the processing unit 1010, and the interface circuit 1120 is used to implement the function of the transceiver unit 1020. These will not be repeated here.

[0308] Based on the above, this application also provides a version repair system, which includes the above domain control unit and main control unit, or may also include OTA, and can be used to execute the version repair method provided in any of the above method embodiments.

[0309] The OTA cloud is primarily responsible for managing the ECU version and upgrade tasks for vehicle OTA upgrades, including the management of repair tasks as described in this application. The OTA cloud can generate repair tasks based on version mismatch information reported by the vehicle and distribute them to the vehicle's main control unit. The main control unit is primarily responsible for the process control of the vehicle's OTA tasks, while the domain control unit is primarily responsible for the software flashing of the domain controllers and their sub-components for specific functional domains.

[0310] Based on the above, this application also provides a vehicle, including the above-mentioned domain control unit and main control unit. The domain control unit can be used to perform the operations performed by the domain control unit in any of the above method embodiments, and the main control unit can be used to perform the operations performed by the main control unit in any of the above method embodiments.

[0311] Based on the above, this application also provides a server, including the above-mentioned OTA cloud, which can be used to perform the operations performed by the OTA cloud in any of the above method embodiments.

[0312] Based on the above, this application also provides a computer-readable storage medium storing instructions that, when executed, cause the method provided in any of the above-described method embodiments to be implemented. The computer-readable storage medium may include various media capable of storing program code, such as a USB flash drive, portable hard drive, read-only memory, random access memory, magnetic disk, or optical disk.

[0313] Based on the above, this application also provides a computer program product, which includes: a computer program (also referred to as code or instructions), which, when run on a computer, causes the computer to perform the method provided in any of the above method embodiments. Optionally, the computer can be a terminal device.

[0314] In this application, "at least one" means one or more, and "more than one" means two or more. "And / or" describes the relationship between related objects, indicating that three relationships can exist. For example, A and / or B can represent: A alone, A and B simultaneously, or B alone, where A and B can be singular or plural. Furthermore, the various numbers involved in the embodiments of this application (such as the numerical designations "first," "second," etc.) are merely for descriptive convenience and are not intended to limit the scope of the embodiments of this application. The order of the sequence numbers of the above processes does not imply the order of execution; the execution order of each process should be determined by its function and internal logic.

[0315] Those skilled in the art will understand that embodiments of this application can be provided as methods, systems, or computer program products. Therefore, this application can take the form of a completely hardware embodiment, a completely software embodiment, or an embodiment combining software and hardware aspects. Furthermore, this application can take the form of a computer program product implemented on one or more computer-usable storage media (including, but not limited to, disk storage, compact disc read-only memory (CD-ROM), optical storage, etc.) containing computer-usable program code.

[0316] This application is described with reference to flowchart illustrations and / or block diagrams of methods, apparatus (systems), and computer program products according to this application. It should be understood that each block of the flowchart illustrations and / or block diagrams, and combinations of blocks in the flowchart illustrations and / or block diagrams, can be implemented by computer program instructions. These computer program instructions can be provided to a processor of a general-purpose computer, special-purpose computer, embedded processor, or other programmable data processing apparatus to produce a machine, such that the instructions, which execute via the processor of the computer or other programmable data processing apparatus, create means for implementing the functions specified in one or more flowchart illustrations and / or one or more block diagrams.

[0317] These computer program instructions may also be stored in a computer-readable storage medium that can direct a computer or other programmable data processing apparatus to function in a particular manner, such that the instructions stored in the computer-readable storage medium produce an article of manufacture including instruction means that implement the functions specified in one or more flowcharts and / or one or more block diagrams.

[0318] These computer program instructions may also be loaded onto a computer or other programmable data processing apparatus to cause a series of operational steps to be performed on the computer or other programmable apparatus to produce a computer-implemented process, such that the instructions, which execute on the computer or other programmable apparatus, provide steps for implementing the functions specified in one or more flowcharts and / or one or more block diagrams.

Claims

1. A version repair method characterized by comprising: The application is applied to a domain control unit, and comprises the following steps: sending first information to a master control unit, wherein the first information comprises information that a software version of the domain control unit and a software version of a first subcomponent hung under the domain control unit are not matched; receiving second information from the master control unit, wherein the second information is used for indicating that a domain where the domain control unit is located is repaired in version; rewriting the software version of the domain control unit or the software version of the first subcomponent, and the software version of the first subcomponent after rewriting is matched with the software version of the domain control unit.

2. The method of claim 1, wherein, Before the step of sending the first information to the master control unit, the method further comprises the following steps: receiving third information from the master control unit, wherein the third information is used for indicating that the domain control unit collects assets; obtaining software version information of the domain control unit and software version information of each subcomponent hung under the domain control unit; determining that the software version of the domain control unit and the software version of the first subcomponent are not matched according to the software version information of the domain control unit and the software version information of each subcomponent, wherein the first subcomponent is at least one of the subcomponents.

3. The method of claim 2, wherein, The third information is sent by the master control unit to the domain control unit after the vehicle is started or before the master control unit exits an upgrading mode after software versions of each component of the vehicle are upgraded.

4. The method of any one of claims 1 to 3, wherein, The step of rewriting the software version of the domain control unit or the software version of the first subcomponent comprises the following steps: obtaining a software package stored locally by the domain control unit, wherein a version of the software package is a first version; if a current version of the domain control unit is not the first version, rewriting the software version of the domain control unit, and if a version of the first subcomponent is not the first version, rewriting the software version of the first subcomponent.

5. The method of claim 4, wherein, The software package stored locally by the domain control unit is a software package when the domain control unit is last time upgraded in software version or a software package downloaded by the domain control unit before the domain control unit receives the second information after the first information is sent.

6. The method of claim 4 or 5, wherein, The first information further comprises software version information of the domain control unit. Before the step of receiving the second information sent by the master control unit, the method further comprises the following steps: receiving fourth information sent by the master control unit, wherein the fourth information comprises a download link, and the fourth information is sent by the master control unit to the domain control unit in a case that the software version information of the domain control unit is different from software version information of the vehicle; downloading a software package corresponding to the domain control unit to a local device according to the download link.

7. A version repair method characterized by comprising: The application is applied to a master control unit, and comprises the following steps: receiving first information from a domain control unit, wherein the first information comprises information that a software version of the domain control unit and a software version of a first subcomponent hung under the domain control unit are not matched; sending second information to the domain control unit, wherein the second information is used for indicating that a domain where the domain control unit is located is repaired in version.

8. The method of claim 7, wherein, The second information is also used for indicating a component to be repaired.

9. The method of claim 7 or 8, wherein, Before the step of receiving the first information sent by the domain control unit, the method further comprises the following steps: The third information is sent to the domain control unit, and the third information is used to instruct the domain control unit to collect assets.

10. The method of claim 9, wherein, The third information is sent to the domain control unit, and the third information is used to instruct the domain control unit to collect assets. The third information is sent to the domain control unit after the vehicle is started, and the third information is sent to the domain control unit before the upgrade mode is exited after the software version upgrade of each component of the vehicle is completed. The third information is sent to the domain control unit after the vehicle is started, and the third information is sent to the domain control unit before the upgrade mode is exited after the software version upgrade of each component of the vehicle is completed.

11. The method of claim 9 or 10, wherein, The third information is sent to the domain control unit after the vehicle is started, and the third information is sent to the domain control unit before the upgrade mode is exited after the software version upgrade of each component of the vehicle is completed. The first information is sent to the OTA cloud. The fifth information sent by the OTA cloud is received, and the fifth information is used to instruct to repair the version of the domain where the domain control unit is located.

12. The method of claim 11, wherein, The first information further includes software version information of the domain control unit, and in the case that the software version information of the domain control unit is different from the software version information of the vehicle, the fifth information further includes a download link. The fourth information is sent to the domain control unit, and the fourth information includes the download link, and the download link is used for the domain control unit to download a software package corresponding to the domain control unit. The fourth information is sent to the domain control unit, and the fourth information includes the download link, and the download link is used for the domain control unit to download a software package corresponding to the domain control unit.

13. The method of claim 11 or 12, wherein, The first prompt message is displayed in a first interface of a user terminal and / or a vehicle-mounted display screen, and is used to instruct that there is part of software to be repaired. The first prompt message is displayed in a first interface of a user terminal and / or a vehicle-mounted display screen, and is used to instruct that there is part of software to be repaired. The first prompt message is displayed in a first interface of a user terminal and / or a vehicle-mounted display screen, and is used to instruct that there is part of software to be repaired.

14. The method of claim 13, wherein, The second interface is displayed to the user in response to a first operation of the user in the first interface, the second interface includes a second prompt message, the second prompt message is used to instruct that the software version of each software to be repaired and the software version of the sub-component of the domain control unit corresponding to each software to be repaired are not matched, and the repair method of each software to be repaired. The first reply message of the user is determined in response to a second operation of the user in the second interface. The method further includes: The second reply message of the user is determined in response to a third operation of the user in the first interface.

15. The method of claim 14, wherein, The second information is sent to the domain control unit, and the second information is used to instruct the domain control unit to repair the version. If the first reply message instructs to repair immediately, the second information is directly sent to the domain control unit; if the first reply message instructs to repair by appointment, the second information is sent to the domain control unit at an appointed time point.

16. The method of claim 14 or 15, wherein, The application is applied to an over-the-air (OTA) cloud, and includes: The first information sent by the master control unit is received, and the first information includes information that the software version of the domain control unit is not matched with the software version of a first sub-component hung under the domain control unit.

17. A version repair method characterized by comprising: The fifth information is sent to the master control unit, and the fifth information is used to instruct to repair the version of the domain where the domain control unit is located. ​ ​ 18. The method of claim 17, wherein, The first information further includes software version information of the domain control unit. Before the sending of the fifth information to the master control unit, the method further includes: determining whether the software version information of the domain control unit and the software version information of the vehicle are the same, and if the software version information is the same, generating the fifth information, wherein the fifth information does not carry a download link.

19. The method of claim 18, wherein, The method further includes: if the software version information is not the same, generating the fifth information, wherein the fifth information includes a download link, and the download link is used for the master control unit to instruct the domain control unit to download a software package corresponding to the domain control unit.

20. A version repair apparatus characterized by comprising: A module or unit for performing the method of any one of claims 1-6, or the method of any one of claims 7-16, or the method of any one of claims 17-19.

21. A version repair apparatus, characterized by comprising: A processor and an interface circuit, wherein the processor is configured to communicate with other devices through the interface circuit to implement the method of any one of claims 1-6, or implement the method of any one of claims 7-16, or implement the method of any one of claims 17-19.

22. A version repair system, characterized by A domain control unit and a master control unit, or further including an over-the-air (OTA) cloud, wherein the domain control unit is configured to perform the method of any one of claims 1-6, the master control unit is configured to perform the method of any one of claims 7-16, and the OTA cloud is configured to perform the method of any one of claims 17-19. The storage medium stores a computer program or instructions, and when the computer program or instructions are executed, the method of any one of claims 1-6 is implemented, or the method of any one of claims 7-16 is implemented, or the method of any one of claims 17-19 is implemented.

23. A computer-readable storage medium, characterized in that, The computer program product includes instructions, and when the instructions are executed, the method of any one of claims 1-6 is implemented, or the method of any one of claims 7-16 is implemented, or the method of any one of claims 17-19 is implemented.

24. A computer program product, characterised in that, ​

Images