Software upgrading method of vehicle electronic controller and vehicle

Abstract

This application discloses a software upgrade method for a vehicle electronic controller and a vehicle. The method includes: responding to an application module receiving an upgrade start command, parsing a diagnostic function identifier corresponding to the upgrade start command to identify the upgrade type, the diagnostic function identifier including a first diagnostic function identifier for identifying remote upgrade types and a second diagnostic function identifier for identifying offline upgrade types; assigning a value to an upgrade status flag bit in the non-volatile storage module of the electronic controller according to the upgrade type; controlling the electronic controller to switch from the application module to the bootloader module, and reading the upgrade status flag bit from the non-volatile storage module; adjusting the test source address attribute corresponding to the programming conditions according to the assigned value of the upgrade status flag bit, so as to match the upgrade process corresponding to the upgrade type and perform an upgrade on the application module. The technical solution provided by this application can reduce the software upgrade cost in vehicle electronic controllers.

Description

Technical Field

[0001] This application belongs to the field of vehicle and software upgrade technology, and particularly relates to a software upgrade method for a vehicle electronic controller and a vehicle. Background Technology

[0002] With the rapid development of automotive intelligence and connectivity, the software functions of vehicle electronic controllers are becoming increasingly complex, and the demand for software iteration and fault repair continues to rise. Remote upgrades and offline upgrades have become the two core methods for upgrading vehicle electronic controller software. However, existing technologies lack an effective mechanism to distinguish between the two upgrade types. Upgrade commands are prone to crosstalk, and the upgrade process has poor adaptability. This not only easily leads to software upgrade failures and abnormal operation of electronic controllers, but also increases the costs of manual troubleshooting, vehicle return for repair, and even large-scale recalls, seriously affecting the operational efficiency of automakers and the user experience.

[0003] Therefore, how to reduce the upgrade cost of software in vehicle electronic controllers has become an urgent technical problem to be solved. Summary of the Invention

[0004] The embodiments of this application provide a method, apparatus, computer program product, computer-readable storage medium, and vehicle for upgrading the software of a vehicle electronic controller, thereby reducing the software upgrade cost in the vehicle electronic controller to at least a certain extent.

[0005] Other features and advantages of this application will become apparent from the following detailed description, or may be learned in part from practice of this application.

[0006] According to a first aspect of the embodiments of this application, a software upgrade method for a vehicle electronic controller is provided. The electronic controller includes an application module for implementing vehicle control functions and a bootloader module for implementing software upgrade functions. The method includes: responding to the application module receiving an upgrade start command, parsing a diagnostic function identifier corresponding to the upgrade start command to identify an upgrade type. The diagnostic function identifier includes a first diagnostic function identifier and a second diagnostic function identifier, wherein the first diagnostic function identifier is used to identify a remote upgrade type and the second diagnostic function identifier is used to identify an offline upgrade type; assigning a value to an upgrade status flag bit in a non-volatile storage module of the electronic controller according to the upgrade type; controlling the electronic controller to switch from the application module to the bootloader module and reading the upgrade status flag bit from the non-volatile storage module; adjusting the test source address attribute corresponding to the programming conditions according to the assigned value of the upgrade status flag bit to match the upgrade process corresponding to the upgrade type, and performing an upgrade on the application module according to the upgrade process.

[0007] In some embodiments of this application, based on the foregoing scheme, before receiving the upgrade start command, the method further includes: configuring a first diagnostic function identifier and a controller local area network (DLAN) message type in the controller local area network (DLAN) interface module of the application module to identify the remote upgrade type, wherein the DLAN message type is used in conjunction with the first diagnostic function identifier to distinguish and receive remote upgrade messages from offline upgrade messages.

[0008] In some embodiments of this application, based on the foregoing scheme, before receiving the upgrade start command, the method further includes: configuring upgrade status flag bits that can be retained across program power loss in the non-volatile storage modules of the application module and the bootloader module, so that the value of the upgrade status flag bits remains unchanged during the process of switching from the application module to the bootloader module.

[0009] In some embodiments of this application, based on the foregoing scheme, before receiving the upgrade start command, the method further includes: creating a remote upgrade diagnostic service receiving rule in the protocol layer of the diagnostic communication management module of the application module; binding the diagnostic service receiving rule to the first diagnostic function identifier, so that the message carrying the first diagnostic function identifier can only enter the diagnostic communication management module through the diagnostic service receiving rule; configuring the test source address attribute corresponding to the remote upgrade diagnostic service receiving rule to a first preset value, and configuring the test source address attribute corresponding to the offline upgrade to a second preset value.

[0010] In some embodiments of this application, based on the foregoing scheme, before receiving the upgrade start instruction, the method further includes: reconstructing the target function for setting programming conditions in the diagnostic communication management module, adding input parameters for identifying the upgrade type to the download upgrade request function, so that the input parameters correspond one-to-one with the upgrade type.

[0011] In some embodiments of this application, based on the foregoing scheme, assigning a value to the upgrade status flag bit in the non-volatile storage module of the electronic controller according to the upgrade type includes: parsing the input parameters of the download upgrade request function to determine the upgrade type corresponding to the input parameters; if the input parameters correspond to a remote upgrade type, then assigning the upgrade status flag bit to a first preset value; if the input parameters correspond to an offline upgrade type, then assigning the upgrade status flag bit to a second preset value.

[0012] In some embodiments of this application, based on the foregoing scheme, adjusting the test source address attribute corresponding to the programming conditions according to the assigned value of the upgrade status flag bit to match the upgrade process corresponding to the upgrade type includes: determining the assigned value of the upgrade status flag bit; if the upgrade status flag bit is a first preset value, then setting the test source address attribute corresponding to the programming conditions to the first preset value to match the remote upgrade process; if the upgrade status flag bit is a second preset value, then setting the test source address attribute corresponding to the programming conditions to the second preset value to match the offline upgrade process.

[0013] In some embodiments of this application, based on the foregoing scheme, the method further includes: if the electronic controller starts the upgrade process directly from the bootloader module after power-on, then the bootloader module reads the upgrade status flag from the non-volatile storage module, adjusts the test source address attribute corresponding to the programming conditions according to the value of the upgrade status flag, and matches and executes the corresponding upgrade process.

[0014] According to a second aspect of the present application, a software upgrade device for a vehicle electronic controller is provided. The electronic controller includes an application module for implementing vehicle control functions and a bootloader module for implementing software upgrade functions. The device includes: a parsing unit, configured to, in response to the application module receiving an upgrade start command, parse a diagnostic function identifier corresponding to the upgrade start command to identify an upgrade type. The diagnostic function identifier includes a first diagnostic function identifier and a second diagnostic function identifier, wherein the first diagnostic function identifier identifies a remote upgrade type and the second diagnostic function identifier identifies an offline upgrade type; an assignment unit, configured to assign a value to an upgrade status flag bit in a non-volatile storage module of the electronic controller according to the upgrade type; a control unit, configured to control the electronic controller to switch from the application module to the bootloader module and read the upgrade status flag bit from the non-volatile storage module; and an adjustment unit, configured to, according to the assigned value of the upgrade status flag bit, adjust the test source address attribute corresponding to the programming conditions to match the upgrade process corresponding to the upgrade type, and perform an upgrade on the application module according to the upgrade process.

[0015] According to a third aspect of the embodiments of this application, a computer program product is provided, the computer program product including computer instructions stored in a computer-readable storage medium and adapted to be read and executed by a processor to cause a computer device having the processor to perform an operation as described in any of the first aspects above.

[0016] According to a fourth aspect of the embodiments of this application, a computer-readable storage medium is provided, the computer-readable storage medium storing at least one computer program instruction, the at least one computer program instruction being loaded and executed by a processor to perform the operation as described in any of the first aspects above.

[0017] According to a fifth aspect of the embodiments of this application, a vehicle is provided, the vehicle including one or more processors and one or more memories, the one or more memories storing at least one computer program instruction, the at least one computer program instruction being loaded and executed by the one or more processors to perform the operation as described in any of the first aspects above.

[0018] Based on the technical solution proposed in this application, when the application module receives the upgrade start command, it first identifies the source of the upgrade type through the diagnostic function identifier, and then assigns a value to the upgrade status flag bit in the non-volatile storage module according to the identified upgrade type. After the electronic controller switches from the application module to the boot program module, it reads the upgrade status flag bit to adjust the test source address attribute corresponding to the programming conditions, matches the upgrade process corresponding to the upgrade type, and completes the software upgrade. This can achieve accurate differentiation between remote upgrade types and offline upgrade types throughout the entire upgrade process. From the source of the upgrade command to the end of the upgrade process execution, the upgrade type is kept identifiable and traceable throughout the entire process, avoiding crosstalk between different types of upgrade commands, reducing upgrade failures and electronic controller malfunctions caused by upgrade process adaptation errors, thereby reducing the manpower and time costs of manually troubleshooting upgrade faults and returning vehicles to the factory for repair. At the same time, it avoids large-scale vehicle recalls caused by software upgrade faults, reducing the operational losses of car manufacturers, and ultimately achieving an effective reduction in the overall cost of vehicle electronic controller software upgrades. Attached Figure Description

[0019] The accompanying drawings, which are incorporated in and form part of this specification, illustrate embodiments consistent with this application and, together with the description, serve to explain the principles of this application. It is obvious that the drawings described below are merely some embodiments of this application, and those skilled in the art can obtain other drawings based on these drawings without any inventive effort. In the drawings: Figure 1 A flowchart illustrating the software upgrade method for a vehicle electronic controller according to an embodiment of this application is shown; Figure 2 A block diagram of a software upgrade device for a vehicle electronic controller according to an embodiment of this application is shown; Figure 3 A schematic diagram of the vehicle structure in an embodiment of this application is shown. Detailed Implementation

[0020] The technical solutions of the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this application, and not all embodiments. Based on the embodiments of this application, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of this application.

[0021] Furthermore, the described features, structures, or characteristics can be combined in any suitable manner in one or more embodiments. Numerous specific details are provided in the following description to give a thorough understanding of embodiments of this application. However, those skilled in the art will recognize that the technical solutions of this application can be practiced without one or more of the specific details, or other methods, components, apparatuses, steps, etc., can be employed. In other instances, well-known methods, apparatuses, implementations, or operations are not shown or described in detail to avoid obscuring various aspects of this application.

[0022] The block diagrams shown in the accompanying drawings are merely functional entities and do not necessarily correspond to physically independent entities. That is, these functional entities can be implemented in software, in one or more hardware modules or integrated circuits, or in different network and / or processor devices and / or microcontroller devices. It should also be noted that, for the sake of simplicity, certain components in the drawings that do not affect the interpretation of the technical solution of this application have been appropriately omitted.

[0023] The flowchart shown in the attached diagram is for illustrative purposes only and does not necessarily include all content and operations / steps, nor does it necessarily have to be performed in the described order. For example, some operations / steps can be broken down, while others can be combined or partially combined. Therefore, the actual execution order may change depending on the actual situation.

[0024] In the description of this application, it should be understood that the terms "first" and "second" are used for descriptive purposes only and should not be construed as indicating or implying relative importance or implicitly specifying the number of indicated technical features. Therefore, a feature defined as "first" or "second" may explicitly or implicitly include one or more of that feature. In the description of this application, unless otherwise stated, "multiple" means two or more.

[0025] This application proposes a software upgrade scheme for vehicle electronic controllers, which aims to achieve precise differentiation between remote upgrades and offline upgrades throughout the entire process, avoid crosstalk in upgrade instructions and process adaptation errors, reduce the risk of failures and recalls caused by upgrade failures, and ultimately reduce the overall cost of vehicle electronic controller software upgrades.

[0026] Next, this application will elaborate on the proposed software upgrade scheme for the vehicle electronic controller. (Refer to...) Figure 1 The diagram illustrates a flowchart of a software upgrade method for a vehicle electronic controller according to an embodiment of this application. The electronic controller includes an application module for implementing vehicle control functions and a bootloader module for implementing software upgrade functions. This method can be executed by a device with computing processing capabilities, such as... Figure 1 As shown, the method includes at least steps 110 to 140, which are described in detail below: In step 110, in response to the application module receiving an upgrade start command, the diagnostic function identifier corresponding to the upgrade start command is parsed to identify the upgrade type. The diagnostic function identifier includes a first diagnostic function identifier and a second diagnostic function identifier. The first diagnostic function identifier is used to identify the remote upgrade type, and the second diagnostic function identifier is used to identify the offline upgrade type.

[0027] In step 120, the upgrade status flag bit in the non-volatile storage module of the electronic controller is assigned a value according to the upgrade type.

[0028] In step 130, the electronic controller is controlled to switch from the application module to the bootloader module, and the upgrade status flag is read from the non-volatile memory module.

[0029] In step 140, the test source address attribute corresponding to the programming conditions is adjusted according to the value assigned to the upgrade status flag to match the upgrade process corresponding to the upgrade type, and the application module is upgraded according to the upgrade process.

[0030] First, this application addresses the following: Figure 1 The technical concepts of the proposed solution are explained below: In this application, the vehicle electronic controller is a microcomputer unit in a vehicle that implements specific control functions and is a core component of the vehicle's electronic system. For example, functions such as engine control, body control, and chassis control are all implemented by the corresponding vehicle electronic controller. The application module is a program unit in the vehicle electronic controller that implements the core control functions. Under normal operating conditions, the vehicle electronic controller always runs the application module to complete the corresponding vehicle control tasks. The bootloader module is a program unit in the vehicle electronic controller specifically responsible for software upgrades and program flashing. It only starts during software upgrades. Even if the application module malfunctions, the bootloader module can still complete the software upgrade and repair normally, ensuring the maintainability of the vehicle electronic controller.

[0031] In this application, the diagnostic function identifier is a unique identifier carried in the upgrade message transmitted via the vehicle controller local area network. Each upgrade command message carries a corresponding diagnostic function identifier, allowing the electronic controller to quickly identify the source and type of the upgrade command. Specifically, the first diagnostic function identifier is a dedicated identifier configured for remote upgrades, also known as over-the-air (OTA) upgrades, which are remote software upgrades implemented through the vehicle network system, eliminating the need for the vehicle to visit a physical service station. The second diagnostic function identifier is a dedicated identifier configured for offline upgrades, where the vehicle is taken to a service station and a technician completes the software upgrade by connecting to the vehicle using dedicated diagnostic equipment.

[0032] In this application, the non-volatile storage module is a storage unit in the vehicle electronic controller that has power-off retention characteristics. Data stored in this module will not be lost due to power failure, restart, or program switching of the electronic controller, enabling stable data transfer between the application module and the bootloader module. The upgrade status flag is a status marker stored in the non-volatile storage module, used to record the upgrade type corresponding to this upgrade, enabling cross-program transfer of upgrade type information between the application module and the bootloader module.

[0033] In this application, the test source address attribute is a core parameter in the electronic controller diagnostic communication management module used to define the source address of the upgrade command. Different test source address attributes correspond to different upgrade process configurations and are the core programming condition parameters that distinguish between remote upgrade and offline upgrade processes.

[0034] In real-world vehicle applications, the vehicle's electronic control unit (ECU) is equipped with software programs conforming to the automotive open system architecture. This controller includes an application module and a bootloader module. During normal driving, the ECU runs the application module to control functions such as vehicle lights and door locks. When the vehicle receives a remote upgrade task from the automaker's cloud, the vehicle networking system can send an upgrade start command to the ECU's application module. This command carries a first diagnostic function identifier. Upon receiving the upgrade start command, the application module parses the diagnostic function identifier in the message to identify that this upgrade is a remote upgrade. Subsequently, based on the identified remote upgrade type, the application module assigns a value to the upgrade status flag in the non-volatile storage module, setting it to the value corresponding to the remote upgrade type. After the assignment is complete, the application module controls the ECU to restart, switching from the application module to the dedicated upgrade bootloader module. Once the bootloader module starts, it first reads the previously written upgrade status flag from the non-volatile storage module to obtain the type of this upgrade. Subsequently, the bootloader module adjusts the test source address attribute corresponding to the programming conditions of this upgrade according to the value assigned to the upgrade status flag, setting it to a value that matches the remote upgrade type, thereby matching the upgrade process exclusive to the remote upgrade, and finally completing the software flashing and upgrade of the application module according to the remote upgrade process.

[0035] Based on the technical solutions in steps 110 to 140 above, when the application module receives the upgrade start command, it first identifies the source of the upgrade type through the diagnostic function identifier, and then assigns a value to the upgrade status flag bit in the non-volatile storage module according to the identified upgrade type. After the electronic controller switches from the application module to the boot program module, it reads the upgrade status flag bit to adjust the test source address attribute corresponding to the programming conditions, matches the upgrade process corresponding to the upgrade type, and completes the software upgrade. This can achieve accurate differentiation between remote upgrade types and offline upgrade types throughout the entire upgrade process. From the source of the upgrade command to the end of the upgrade process execution, the upgrade type is kept identifiable and traceable throughout the entire process, avoiding crosstalk between different types of upgrade commands, reducing upgrade failures and abnormal operation of the electronic controller caused by upgrade process adaptation errors, thereby reducing the manpower and time costs of manually troubleshooting upgrade faults and returning vehicles to the factory for repair. At the same time, it avoids large-scale vehicle recalls caused by software upgrade faults, reduces the operational losses of car manufacturers, and ultimately achieves an effective reduction in the overall cost of vehicle electronic controller software upgrades.

[0036] To enable those skilled in the art to better understand this application, the following sections will further explain the details of the proposed software upgrade scheme for the vehicle electronic controller.

[0037] In this application, before receiving the upgrade initiation command, the following step 101 may also be performed: Step 101: In the Controller Area Network (CAN) interface module of the application module, configure a first diagnostic function identifier and a CAN message type for identifying the remote upgrade type. The CAN message type is used in conjunction with the first diagnostic function identifier to distinguish and receive remote upgrade messages from offline upgrade messages.

[0038] In this application, the Controller Area Network (CLAN) is a dedicated bus network for data communication between various electronic controllers within a vehicle. It is the most widely used communication bus in vehicle electronic systems, and all upgrade commands are transmitted to the corresponding electronic controllers via the CLAN. The CLAN interface module can be a fundamental software module in the automotive open system architecture responsible for CLAN message transmission, reception, and filtering. It is the core interface for electronic controllers to receive and send CLAN messages. All messages transmitted via the bus must be processed by this module before being passed to upper-level functional modules. The CLAN message type can be a set of parameters defining the CLAN message transmission format, frame type, data length, and transmission rules. Different message types correspond to different reception and filtering rules. The CLAN interface module can perform preliminary screening and differentiation of messages transmitted on the bus based on the message type.

[0039] During the software development phase of the vehicle electronic controller, developers can pre-configure the first diagnostic function identifier and its corresponding Controller Area Network (CLAN) message type in the CLAN interface module of the application module. For example, the first diagnostic function identifier configured for remote upgrades is a dedicated message ID, specifically set to 0x18DAF101. Simultaneously, the corresponding CLAN message type is configured as a data frame, the data segment length is defined as 8 bytes, the transmission cycle is single-trigger transmission, and corresponding receive filtering rules are configured. The CLAN interface module will only receive and forward a message to the upper-layer diagnostic communication management module if the message transmitted on the bus matches both the first diagnostic function identifier and the corresponding message type; other mismatched messages can be directly filtered out. Correspondingly, the second diagnostic function identifier used for offline upgrades is set to 0x18DA10F1, and its corresponding message type and filtering rules are independent of those for remote upgrades, preventing cross-matching.

[0040] Based on the technical solution in step 101 above, by pre-configuring the first diagnostic function identifier for identifying the remote upgrade type and the corresponding Controller Area Network (CLAN) message type in the Controller Area Network (CLAN) interface module of the application module, the remote upgrade message and the offline upgrade message can be accurately distinguished and filtered at the very front end of the electronic controller, i.e., the interface layer of bus communication, when the upgrade command enters. This avoids crosstalk and misidentification of different types of upgrade messages from the source of the upgrade process, ensures dedicated transmission and accurate reception of remote upgrade commands, reduces upper-level upgrade process anomalies caused by message identification errors, and further reduces the failure rate of software upgrades, as well as the manpower and maintenance costs of troubleshooting.

[0041] In this application, before receiving the upgrade initiation command, the following step 102 may also be performed: Step 102: Configure upgrade status flags that can be retained across program power losses in the non-volatile storage modules of the application module and the bootloader module, respectively, so that the values ​​of the upgrade status flags remain unchanged during the switching process from the application module to the bootloader module.

[0042] In this application, the upgrade status flag that can be retained across program power loss can refer to the same status flag configured in the non-volatile storage area accessible by the application module and the bootloader module respectively. Both program modules can read and write to the flag, and the value of the flag will not change due to power failure, restart or program switching of the electronic controller, so as to stably realize the transmission of upgrade type information between the two program modules.

[0043] During the software development phase of the vehicle's electronic controller, developers can allocate a dedicated state storage partition within the non-volatile storage module. This partition should grant read and write permissions to both the application module and the bootloader module. An upgrade status flag can be configured within this partition. For example, this flag can be defined as a 1-byte unsigned integer variable. The application module can assign a value to this variable based on the identified upgrade type. After the bootloader module starts, it can directly read the value of this variable from this partition. Furthermore, the value of this variable will not change during power-off restarts of the electronic controller or during switching from the application module to the bootloader module. Simultaneously, developers can configure read / write drivers for this flag in the software code of both the application module and the bootloader module to ensure that both modules can access the flag normally and that there will be no inability to read it after program switching.

[0044] Based on the technical solution in step 102 above, by configuring upgrade status flags that can be retained across program power failures in the non-volatile storage modules of the application module and the bootloader module respectively, it can be ensured that the upgrade type information is stably transmitted during the switching process from the application module to the bootloader module. This avoids the problem of loss of upgrade type information during electronic controller restart and program switching, and ensures that the bootloader module can accurately obtain the type of this upgrade, thereby matching the correct upgrade process, reducing upgrade process adaptation errors caused by information loss, further reducing the probability of upgrade failure, and thus reducing the additional costs caused by upgrade failure.

[0045] In this application, before receiving the upgrade initiation command, steps 103 to 105 may also be performed: Step 103: In the protocol layer of the diagnostic communication management module of the application module, create a remote upgrade diagnostic service receiving rule.

[0046] Step 104: Bind the diagnostic service receiving rule to the first diagnostic function identifier, so that messages carrying the first diagnostic function identifier can only enter the diagnostic communication management module through the diagnostic service receiving rule.

[0047] Step 105: Configure the test source address attribute corresponding to the diagnostic service receiving rule for remote upgrade to a first preset value, and configure the test source address attribute corresponding to the offline upgrade to a second preset value.

[0048] In this application, the diagnostic communication management module can be a core functional module in the automotive open system architecture responsible for processing all diagnostic and upgrade commands. All upgrade-related commands must be parsed, judged, and processed by this module before entering the subsequent upgrade process. The protocol layer can be the layer in the diagnostic communication management module responsible for parsing diagnostic message protocols and matching reception rules; it is the first processing step for diagnostic commands entering the diagnostic communication management module. The diagnostic service reception rules can be a set of rules defined in the protocol layer used to determine whether a diagnostic message can enter the module for processing. Only messages that match the rules can be received and processed by the diagnostic communication management module. The first preset value and the second preset value can be predefined test source address attribute values ​​corresponding to remote upgrades and offline upgrades, respectively. They are independent of each other and do not overlap.

[0049] During the software development phase of the vehicle electronic controller, developers can create a dedicated diagnostic service reception rule for remote upgrades within the protocol layer of the diagnostic communication management module in the application module. This rule is strongly bound to a first diagnostic function identifier, and the matching condition is set so that the message must carry the first diagnostic function identifier. Only messages that meet this matching condition can enter the diagnostic communication management module through this rule; other mismatched messages will be blocked. Simultaneously, developers can configure the test source address attribute corresponding to this remote upgrade diagnostic service reception rule to a first preset value of 1, and configure the test source address attribute of the regular diagnostic service reception rule for offline upgrades to a second preset value of 0. These two preset values ​​are completely distinct, corresponding to two independent upgrade process configurations. In actual operation, when a remote upgrade message carrying the first diagnostic function identifier enters the diagnostic communication management module, it can automatically match the remote upgrade-specific diagnostic service reception rule and automatically associate the corresponding test source address attribute 1, providing a basis for subsequent upgrade process configuration.

[0050] Finally, the technical effects of this solution are derived: Based on the technical solutions in steps 103 to 105 above, by creating a dedicated diagnostic service receiving rule for remote upgrades in the protocol layer of the diagnostic communication management module, binding this rule to the first diagnostic function identifier, and configuring corresponding test source address attributes for different rules, remote upgrade messages and offline upgrade messages can be distinguished and isolated again at the entry point of the diagnostic communication management module, further avoiding crosstalk between different types of upgrade messages. At the same time, corresponding test source address attributes are pre-configured for the two upgrade types, providing a stable basis for matching the subsequent upgrade process, reducing the probability of upgrade process configuration errors, thereby reducing the occurrence rate of upgrade failures and further controlling the overall cost of software upgrades.

[0051] In this application, before receiving the upgrade initiation command, the following step 106 may also be performed: Step 106: In the diagnostic communication management module, reconstruct the target function for setting programming conditions, and add input parameters for identifying the upgrade type to the download upgrade request function, so that the input parameters correspond one-to-one with the upgrade type.

[0052] In this application, the target function for setting programming conditions can be the core function in the diagnostic communication management module, responsible for configuring a complete set of programming environment parameters for software upgrades. All programming conditions in the upgrade process need to be set and initialized through this function. The download upgrade request function can be the core function that triggers the software upgrade process, used to initiate a request to the electronic controller to download and flash the upgrade package, and is the core trigger function for starting the upgrade process. The input parameter for identifying the upgrade type can be a newly added parameter passed along with the download upgrade request function. The value of this parameter corresponds one-to-one with the upgrade type, and can transmit the upgrade type information to the programming condition setting stage.

[0053] During the software development phase of the vehicle's electronic controller, developers refactor the target function used to set programming conditions in the diagnostic communication management module. They modify the function's input parameter list, adding an integer parameter to the download / upgrade request function to identify the upgrade type. For example, a parameter value of 1 corresponds to a remote upgrade, while a value of 0 corresponds to an offline upgrade. After refactoring, when the download / upgrade request function is triggered, it carries this input parameter. The target function, used to set programming conditions, receives this parameter and determines the upgrade type based on its value, providing a basis for assigning values ​​to subsequent upgrade status flags.

[0054] Based on the technical solution in step 106 above, by reconstructing the objective function used to set programming conditions in the diagnostic communication management module, and adding input parameters to the download upgrade request function to identify the upgrade type, the upgrade type information can be completely transmitted to the programming condition setting stage. This establishes a clear information transmission link between upgrade type identification and upgrade process configuration, ensuring that upgrade type information can be integrated throughout the core stages of the entire upgrade process. This avoids loss or mismatch of upgrade type information during process transmission, further ensuring accurate matching between the upgrade process and the upgrade type, reducing the probability of upgrade process anomalies, and thus lowering the failure and maintenance costs of software upgrades.

[0055] In such Figure 1 In step 120, the step of assigning a value to the upgrade status flag bit in the non-volatile storage module of the electronic controller according to the upgrade type can be performed according to the following steps 121 to 123: Step 121: Parse the input parameters of the download upgrade request function and determine the upgrade type corresponding to the input parameters.

[0056] Step 122: If the input parameter corresponds to a remote upgrade type, then the upgrade status flag is assigned a first preset value.

[0057] Step 123: If the input parameter corresponds to the offline upgrade type, then the upgrade status flag is assigned a second preset value.

[0058] In the actual upgrade process, when the download upgrade request function is triggered, the application module can first parse the input parameters carried by the function to identify the upgrade type and determine the type of this upgrade. For example, when the parsed input parameter value is 1, it is determined that this upgrade is a remote upgrade type, and the application module can assign the upgrade status flag in the non-volatile storage module to the first preset value 1; when the parsed input parameter value is 0, it is determined that this upgrade is an offline upgrade type, and the application module can assign the upgrade status flag to the second preset value 0. After the assignment is completed, the application module can verify the written value to ensure that the written value completely corresponds to the upgrade type. After the verification is successful, the subsequent program switching operation is executed.

[0059] Based on the technical solutions in steps 121 to 123 above, this application determines the upgrade type by parsing the input parameters of the download upgrade request function, and then assigns a corresponding preset value to the upgrade status flag according to the upgrade type. This ensures that the assigned value of the upgrade status flag corresponds exactly to the actual upgrade type, avoiding subsequent process matching anomalies caused by incorrect flag assignment. At the same time, the one-to-one correspondence between the input parameters and the flag assignment further strengthens the transmission link of upgrade type information, ensuring that the bootloader module can read accurate upgrade type information, thereby matching the correct upgrade process, reducing the probability of upgrade failure, and further reducing the overall cost of software upgrade.

[0060] In such Figure 1 In step 140, adjusting the test source address attribute corresponding to the programming conditions based on the assigned value of the upgrade status flag to match the upgrade process corresponding to the upgrade type can be performed according to steps 141 to 143 as follows: Step 141: Determine the value assigned to the upgrade status flag.

[0061] Step 142: If the upgrade status flag is a first preset value, then set the test source address attribute corresponding to the programming conditions to the first preset value to match the remote upgrade process.

[0062] Step 143: If the upgrade status flag is the second preset value, then set the test source address attribute corresponding to the programming conditions to the second preset value to match the offline upgrade process.

[0063] In the actual upgrade process, after the bootloader module starts and reads the upgrade status flag value from the non-volatile storage module, it can first judge this value. For example, when the read flag value is the first preset value 1, the bootloader module can set the test source address attribute corresponding to the programming conditions of this upgrade to 1, and automatically match the pre-configured remote upgrade-specific process. This process is configured with the flashing rules, verification rules, timeout rules, and exception handling rules corresponding to the remote upgrade. When the read flag value is the second preset value 0, the bootloader module can set the test source address attribute to 0, and automatically match the regular process corresponding to the offline upgrade. This process is adapted to the operating habits and permission configuration of offline diagnostic devices and is completely independent of the remote upgrade process.

[0064] Based on the technical solutions in steps 141 to 143 above, this application determines the value of the upgrade status flag and sets corresponding test source address attributes for different values, thereby matching the upgrade process corresponding to the upgrade type. At the end of the upgrade process execution, hard isolation between remote upgrade and offline upgrade processes can be achieved, ensuring that the two upgrade types follow their own dedicated upgrade processes, avoiding upgrade anomalies caused by process mixing. At the same time, corresponding process rules are configured for the different needs of the two upgrade scenarios, improving the adaptability and stability of the upgrade process, reducing the probability of upgrade failure, thereby reducing the failure cost and recall risk of software upgrade, and ultimately achieving effective control of upgrade costs.

[0065] In this application, the following step 150 may also be performed: Step 150: If the electronic controller starts the upgrade process directly from the bootloader module after power-on, the bootloader module reads the upgrade status flag from the non-volatile storage module, adjusts the test source address attribute corresponding to the programming conditions according to the value of the upgrade status flag, and matches and executes the corresponding upgrade process.

[0066] In certain special scenarios, such as when an application module malfunctions and fails to start normally, an upgrade and repair can be performed directly through the bootloader module. Alternatively, during vehicle production, the initial program may need to be flashed directly through the bootloader module. Upon power-up of the electronic controller, the application module will not be started; instead, the upgrade process will begin directly through the bootloader module. In this case, after starting, the bootloader module can directly read the assigned value of the upgrade status flag from the non-volatile storage module. Based on the assigned value, it adjusts the test source address attributes corresponding to the programming conditions to match the corresponding upgrade process. For example, in an offline flashing scenario during vehicle maintenance, the upgrade status flag is assigned the second preset value of 0, and the bootloader module will match the offline upgrade process to complete the program flashing. In a remote emergency repair scenario after an application module malfunctions, the upgrade status flag is assigned the first preset value of 1, and the bootloader module will match the remote upgrade process to complete the repair and upgrade.

[0067] Based on the technical solution in step 150 above, by setting corresponding flag reading and process matching logic for the scenario where the electronic controller directly starts the upgrade process from the bootloader module, the upgrade method of this application can cover all possible software upgrade scenarios. It not only adapts to the normal upgrade process initiated from the application module, but also to the special upgrade scenario initiated directly from the bootloader module, thereby improving the applicability and compatibility of the method, avoiding upgrade failures caused by the inability to adapt the upgrade process in special scenarios, reducing the probability of vehicles returning to the factory for repair, and further reducing the overall operation and maintenance cost of software upgrades.

[0068] Next, in order to enable those skilled in the art to better understand this application, the proposed software upgrade method for vehicle electronic controllers will be described below with reference to a specific embodiment.

[0069] In one specific embodiment of this application, the electronic controller may be a body electronic controller that conforms to the open system architecture of automobiles. The controller includes an application module and a bootloader module. The application module is used to implement the control functions of body lights, door locks and windows. The bootloader module is used to implement the software upgrade function of the application module. The controller has a built-in controller local area network interface module, a non-volatile storage module and a diagnostic communication management module.

[0070] In this embodiment, it may include two parts: a pre-configuration phase and an upgrade execution phase.

[0071] The pre-configuration phase is completed during the controller software development phase and may include the following steps: The first step is to configure the first diagnostic function identifier and the Controller Area Network (CAN) message type in the Controller Area Network (CAN) interface module of the application module to identify the remote upgrade type. The first diagnostic function identifier is set to 0x18DAF101, and the CAN message type is configured as a data frame with a data segment length of 8 bytes. At the same time, the corresponding receive filtering rules are configured so that only messages matching this identifier and message type can be received. The second diagnostic function identifier for offline upgrades is configured as 0x18DA10F1, and the corresponding message type and filtering rules are independent of those for remote upgrades.

[0072] The second step is to divide a dedicated state storage partition in the non-volatile storage module. This partition has read and write permissions for both the application module and the bootloader module. An upgrade status flag that can be retained across programs after power failure is configured in this partition. This flag is a 1-byte unsigned integer variable that can be read and written by both the application module and the bootloader module.

[0073] The third step is to create a dedicated diagnostic service receiving rule for remote upgrades in the protocol layer of the diagnostic communication management module of the application module, bind the rule to the first diagnostic function identifier, set the matching condition to the requirement that the message must carry the first diagnostic function identifier, configure the test source address attribute corresponding to the rule to the first preset value 1, and configure the test source address attribute of the regular rule corresponding to offline upgrades to the second preset value 0.

[0074] The fourth step is to refactor the Dcm_SetProgConditions function in the diagnostic communication management module, which is used to set programming conditions, and add an input parameter to the download upgrade request function FBL_Integration_DownloadRequest to identify the upgrade type. When the value of this parameter is 1, it corresponds to the remote upgrade type, and when the value is 0, it corresponds to the offline upgrade type.

[0075] In the upgrade execution phase of this embodiment, there are three scenarios: normal remote upgrade, normal offline upgrade, and upgrade directly launched from the bootloader module. The specific steps for the normal remote upgrade scenario are as follows: The first step is that the vehicle receives a remote upgrade task from the automaker's cloud. The vehicle networking system sends an upgrade start command to the application module of the body electronic controller through the controller area network. The message corresponding to this command carries the first diagnostic function identifier 0x18DAF101.

[0076] The second step is that after the application module's controller LAN interface module receives the message, it verifies the diagnostic function identifier and message type of the message through the pre-configured filtering rules. After successful verification, the message is transmitted to the diagnostic communication management module.

[0077] The third step involves the diagnostic communication management module matching the message using the remote upgrade-specific diagnostic service receiving rules, parsing the message content, and triggering the download upgrade request function. The input parameter value of this function is 1, corresponding to the remote upgrade type.

[0078] The fourth step involves the application module parsing the input parameters of the download upgrade request function, determining that this upgrade is a remote upgrade, assigning the upgrade status flag in the non-volatile storage module to the first preset value of 1, and then verifying the value to ensure accuracy.

[0079] Fifth, the application module completes the preparations for the upgrade, controls the electronic controller to restart, and switches from the application module to the bootloader module.

[0080] Step 6: After the bootloader module starts, it first reads the value of the upgrade status flag from the non-volatile storage module. The value read is 1, which determines that this upgrade is a remote upgrade.

[0081] Step 7: The bootloader module sets the test source address attribute corresponding to the programming conditions of this upgrade to the first preset value 1, matches the upgrade process exclusive to remote upgrade, and completes the verification and flashing of the upgrade package according to the process. After the flashing is completed, the integrity and legality of the new application module are verified.

[0082] Step 8: After verification, the boot program module controls the electronic controller to restart and switch to the new application module. After the upgrade is completed, the upgrade status flag is cleared and the upgrade log is recorded synchronously.

[0083] The execution steps for a normal offline upgrade scenario are consistent with the logic of a normal remote upgrade scenario. The difference is that the upgrade start command is issued by a dedicated offline diagnostic device, carrying the second diagnostic function identifier 0x18DA10F1, the input parameter value of the download upgrade request function is 0, the upgrade status flag is assigned the second preset value 0, and the boot program module matches the conventional process corresponding to the offline upgrade to complete the upgrade.

[0084] In this embodiment, the upgrade scenario that starts directly from the bootloader module involves the following steps: The first step is that the application module of the vehicle's electronic controller malfunctions and cannot start normally. The repair personnel trigger an emergency upgrade using a dedicated diagnostic device. After the electronic controller is powered on, it directly enters the boot program module and does not start the application module.

[0085] The second step is that after the bootloader module starts, it directly reads the value of the upgrade status flag from the non-volatile storage module. In this case, it is an offline emergency repair scenario, and the flag is assigned the second preset value of 0.

[0086] The third step involves the bootloader module setting the test source address attribute corresponding to the programming conditions to the second preset value of 0, matching the offline upgrade process, completing the repair and flashing of the application module, verifying the flashing process, controlling the electronic controller to restart, and restoring the normal operation of the application module.

[0087] Overall, this application achieves source identification of upgrade types through diagnostic function identifiers, ensures stable cross-program transmission of upgrade type information through upgrade status flags in non-volatile storage modules, and achieves precise matching of the upgrade process by adjusting the test source address attributes. It achieves precise differentiation and hard isolation between remote and offline upgrades throughout the entire upgrade chain, effectively solving the problems of upgrade command crosstalk and poor process adaptability in existing technologies. This significantly reduces the probability of upgrade failure and minimizes the cost losses caused by manual troubleshooting, vehicle return for repair, and even large-scale recalls. Furthermore, the method of this application is fully compatible with the software development specifications of automotive open system architectures and can be directly applied to mainstream vehicle electronic controller software development. It possesses strong versatility and feasibility, effectively helping automakers control the overall cost of software upgrades and improve operational efficiency and user experience.

[0088] The following describes an embodiment of the apparatus described in this application, which can be used to execute the software upgrade method for the vehicle electronic controller described in the above embodiments of this application. For details not disclosed in the apparatus embodiments of this application, please refer to the embodiments of the software upgrade method for the vehicle electronic controller described above in this application.

[0089] See Figure 2 The diagram shows a block diagram of a software upgrade device for a vehicle electronic controller according to an embodiment of this application. The electronic controller includes an application module for implementing vehicle control functions and a bootloader module for implementing software upgrade functions.

[0090] like Figure 2 As shown, the software upgrade device 200 for a vehicle electronic controller according to an embodiment of this application includes: a parsing unit 201, an assignment unit 202, a control unit 203, and an adjustment unit 204.

[0091] The system includes a parsing unit 201, which, in response to the application module receiving an upgrade start command, parses the diagnostic function identifier corresponding to the upgrade start command to identify the upgrade type. The diagnostic function identifier includes a first diagnostic function identifier and a second diagnostic function identifier, wherein the first diagnostic function identifier identifies a remote upgrade type and the second diagnostic function identifier identifies an offline upgrade type. An assignment unit 201 is used to assign a value to the upgrade status flag bit in the non-volatile storage module of the electronic controller according to the upgrade type. A control unit 203 is used to control the electronic controller to switch from the application module to the bootloader module and read the upgrade status flag bit from the non-volatile storage module. An adjustment unit 204 is used to adjust the test source address attribute corresponding to the programming conditions according to the assigned value of the upgrade status flag bit to match the upgrade process corresponding to the upgrade type, and to perform an upgrade on the application module according to the upgrade process.

[0092] In some embodiments of this application, based on the foregoing scheme, the device further includes: a configuration unit, configured in the controller local area network interface module of the application module before receiving the upgrade start command, to configure a first diagnostic function identifier and a controller local area network message type for identifying the remote upgrade type, wherein the controller local area network message type is used in conjunction with the first diagnostic function identifier to distinguish and receive remote upgrade messages and offline upgrade messages.

[0093] In some embodiments of this application, based on the foregoing scheme, the configuration unit is configured to: before receiving the upgrade start instruction, configure upgrade status flag bits that can be retained across program power loss in the non-volatile storage modules of the application module and the bootloader module respectively, so that the value of the upgrade status flag bits remains unchanged during the process of switching from the application module to the bootloader module.

[0094] In some embodiments of this application, based on the foregoing scheme, the configuration unit is configured to: before receiving the upgrade start command, create a remote upgrade diagnostic service receiving rule in the protocol layer of the diagnostic communication management module of the application module; bind the diagnostic service receiving rule to the first diagnostic function identifier, so that the message carrying the first diagnostic function identifier can only enter the diagnostic communication management module through the diagnostic service receiving rule; configure the test source address attribute corresponding to the remote upgrade diagnostic service receiving rule to a first preset value, and configure the test source address attribute corresponding to the offline upgrade to a second preset value.

[0095] In some embodiments of this application, based on the foregoing scheme, the configuration unit is configured to: before receiving the upgrade start instruction, reconstruct the target function for setting programming conditions in the diagnostic communication management module, add input parameters for identifying the upgrade type to the download upgrade request function, so that the input parameters correspond one-to-one with the upgrade type.

[0096] In some embodiments of this application, based on the foregoing scheme, the assignment unit 201 is configured to: parse the input parameters of the download upgrade request function and determine the upgrade type corresponding to the input parameters; if the input parameters correspond to the remote upgrade type, then assign the upgrade status flag bit to a first preset value; if the input parameters correspond to the offline upgrade type, then assign the upgrade status flag bit to a second preset value.

[0097] In some embodiments of this application, based on the foregoing scheme, the adjustment unit 204 is configured to: determine the value of the upgrade status flag; if the upgrade status flag is a first preset value, then set the test source address attribute corresponding to the programming conditions to the first preset value to match the remote upgrade process; if the upgrade status flag is a second preset value, then set the test source address attribute corresponding to the programming conditions to the second preset value to match the offline upgrade process.

[0098] In some embodiments of this application, based on the foregoing scheme, the adjustment unit 204 is configured as follows: if the electronic controller starts the upgrade process directly from the boot program module after power-on, the boot program module reads the upgrade status flag bit from the non-volatile storage module, adjusts the test source address attribute corresponding to the programming conditions according to the value of the upgrade status flag bit, and matches and executes the corresponding upgrade process.

[0099] Based on the same inventive concept, embodiments of this application provide a computer program product, the computer program product including computer instructions stored in a computer-readable storage medium and adapted to be read and executed by a processor so as to cause a computer device having the processor to perform operations performed by the software upgrade method for the vehicle electronic controller as described above.

[0100] Based on the same inventive concept, embodiments of this application provide a computer-readable storage medium storing at least one computer program instruction, which is loaded and executed by a processor to perform the operations performed by the software upgrade method for the vehicle electronic controller as described above.

[0101] Based on the same inventive concept, this application also provides a vehicle, see reference. Figure 3The diagram shows a structural schematic of a vehicle according to an embodiment of this application. The vehicle includes one or more memories 304, one or more processors 302, and at least one computer program (computer program instruction) stored in the memory 304 and executable on the processor 302. When the processor 302 executes the computer program, it implements the software upgrade method of the vehicle electronic controller as described above.

[0102] Among them, Figure 3 In this document, a bus architecture (represented by bus 300) is used. Bus 300 may include any number of interconnected buses and bridges, linking various circuits including one or more processors represented by processor 302 and memory represented by memory 304. Bus 300 may also link various other circuits such as peripheral devices, voltage regulators, and power management circuits, which are well known in the art and therefore will not be described further herein. Bus interface 305 provides an interface between bus 300 and receiver 301 and transmitter 303. Receiver 301 and transmitter 303 may be the same element, i.e., a transceiver, providing a unit for communicating with various other devices over a transmission medium. Processor 302 is responsible for managing bus 300 and general processing, while memory 304 can be used to store data used by processor 302 during operation.

[0103] The functions described herein can be implemented in hardware, software executed by a processor, firmware, or any combination thereof. When implemented in software executed by a processor, the functions can be stored as one or more instructions or codes on or transmitted via a computer-readable medium. Other examples and embodiments are within the scope and spirit of this application and the appended claims. For example, due to the nature of software, the functions described above can be implemented using software executed by a processor, hardware, firmware, hardwired, or any combination thereof. Furthermore, the functional units can be integrated into a single processing unit, or each unit can exist physically separately, or two or more units can be integrated into a single unit.

[0104] In the several embodiments provided in this application, it should be understood that the disclosed technical content can be implemented in other ways. The device embodiments described above are merely illustrative; for example, the division of units can be a logical functional division, and in actual implementation, there may be other division methods. For instance, multiple units or components may be combined or integrated into another system, or some features may be ignored or not executed. Furthermore, the displayed or discussed mutual coupling, direct coupling, or communication connection may be through some interfaces; the indirect coupling or communication connection between units or modules may be electrical or other forms.

[0105] The units described as separate components may or may not be physically separate. Similarly, the components of the control device may or may not be physical units; they may be located in one place or distributed across multiple units. Some or all of the units can be selected to achieve the purpose of this embodiment, depending on actual needs.

[0106] When the integrated unit is implemented as a software functional unit and sold or used as an independent product, it can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of this application, in essence, or the part that contributes to the prior art, or all or part of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute all or part of the steps of the methods described in the various embodiments of this application. The aforementioned storage medium includes various media capable of storing computer program instructions, such as USB flash drives, read-only memory (ROM), random access memory (RAM), portable hard drives, magnetic disks, or optical disks.

[0107] The above description is merely an embodiment of this application and is not intended to limit this application. Various modifications and variations can be made to this application by those skilled in the art. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of this application should be included within the scope of the claims of this application.

Claims

1. A software upgrade method for a vehicle electronic controller, characterized in that, The electronic controller includes an application module for implementing vehicle control functions and a bootloader module for implementing software upgrade functions. The method includes: In response to the application module receiving an upgrade start command, the diagnostic function identifier corresponding to the upgrade start command is parsed to identify the upgrade type. The diagnostic function identifier includes a first diagnostic function identifier and a second diagnostic function identifier. The first diagnostic function identifier is used to identify the remote upgrade type, and the second diagnostic function identifier is used to identify the offline upgrade type. According to the upgrade type, the upgrade status flag bit in the non-volatile storage module of the electronic controller is assigned a value; The electronic controller is controlled to switch from the application module to the bootloader module, and the upgrade status flag is read from the non-volatile memory module; Based on the value assigned to the upgrade status flag, the test source address attribute corresponding to the programming conditions is adjusted to match the upgrade process corresponding to the upgrade type, and the application module is upgraded according to the upgrade process.

2. The method according to claim 1, characterized in that, Before receiving the upgrade launch command, the method further includes: In the Controller Area Network (CAN) interface module of the application module, a first diagnostic function identifier and a CAN message type are configured to identify the remote upgrade type. The CAN message type is used in conjunction with the first diagnostic function identifier to distinguish and receive remote upgrade messages from offline upgrade messages.

3. The method according to claim 1, characterized in that, Before receiving the upgrade launch command, the method further includes: In the non-volatile storage modules of the application module and the bootloader module, upgrade status flags that can be retained across program power failures are configured respectively, so that the value of the upgrade status flags remains unchanged during the process of switching from the application module to the bootloader module.

4. The method according to claim 1, characterized in that, Before receiving the upgrade launch command, the method further includes: In the protocol layer of the diagnostic communication management module of the application module, create a remote upgrade diagnostic service receiving rule; The diagnostic service receiving rule is bound to the first diagnostic function identifier, so that messages carrying the first diagnostic function identifier can only enter the diagnostic communication management module through the diagnostic service receiving rule. Configure the test source address attribute corresponding to the diagnostic service receiving rule for remote upgrade to a first preset value, and configure the test source address attribute corresponding to the offline upgrade to a second preset value.

5. The method according to claim 4, characterized in that, Before receiving the upgrade launch command, the method further includes: In the diagnostic communication management module, the objective function for setting programming conditions is reconstructed, and an input parameter for identifying the upgrade type is added to the download upgrade request function, so that the input parameter corresponds one-to-one with the upgrade type.

6. The method according to claim 5, characterized in that, The step of assigning a value to the upgrade status flag bit in the non-volatile storage module of the electronic controller according to the upgrade type includes: Parse the input parameters of the download upgrade request function to determine the upgrade type corresponding to the input parameters; If the input parameter corresponds to a remote upgrade type, then the upgrade status flag is assigned a first preset value; If the input parameter corresponds to an offline upgrade type, then the upgrade status flag is assigned a second preset value.

7. The method according to claim 1, characterized in that, The step of adjusting the test source address attribute corresponding to the programming conditions based on the assigned value of the upgrade status flag to match the upgrade process corresponding to the upgrade type includes: Determine the value assigned to the upgrade status flag; If the upgrade status flag is a first preset value, then the test source address attribute corresponding to the programming condition is set to the first preset value to match the remote upgrade process; If the upgrade status flag is the second preset value, then the test source address attribute corresponding to the programming conditions is set to the second preset value to match the offline upgrade process.

8. The method according to claim 1, characterized in that, The method further includes: If the electronic controller starts the upgrade process directly from the bootloader module after power-on, the bootloader module reads the upgrade status flag from the non-volatile storage module, adjusts the test source address attribute corresponding to the programming conditions according to the value of the upgrade status flag, and matches and executes the corresponding upgrade process.

9. A software upgrade device for a vehicle electronic controller, characterized in that, The electronic controller includes an application module for implementing vehicle control functions and a bootloader module for implementing software upgrade functions. The device includes: The parsing unit is configured to, in response to the application module receiving an upgrade start command, parse the diagnostic function identifier corresponding to the upgrade start command to identify the upgrade type. The diagnostic function identifier includes a first diagnostic function identifier and a second diagnostic function identifier. The first diagnostic function identifier is used to identify the remote upgrade type, and the second diagnostic function identifier is used to identify the offline upgrade type. The assignment unit is used to assign a value to the upgrade status flag bit in the non-volatile storage module of the electronic controller according to the upgrade type. The control unit is used to control the electronic controller to switch from the application module to the bootloader module, and to read the upgrade status flag from the non-volatile memory module; The adjustment unit is used to adjust the test source address attribute corresponding to the programming conditions according to the value assigned to the upgrade status flag, so as to match the upgrade process corresponding to the upgrade type, and perform the upgrade on the application module according to the upgrade process.

10. A vehicle, characterized in that, The vehicle includes one or more processors and one or more memories, wherein at least one piece of program code is stored in the one or more memories, and the at least one piece of program code is loaded and executed by the one or more processors to implement the method as described in any one of claims 1 to 8.

Images