A configuration file flashing method and device for a vehicle electronic control unit

Abstract

The application discloses a configuration file flashing method and device of a vehicle electronic control unit. The method comprises the following steps: obtaining a project configuration file decoupled from instance information of an ECU to be flashed and an upgrade configuration file comprising corresponding instance data; analyzing the upgrade configuration file to generate a variable set associated with variable references and instance data; traversing multiple flashing steps; when a current flashing step is executed, obtaining instance data corresponding to a variable reference of the current flashing step from the variable set, and dynamically replacing a variable reference in a step parameter; and executing an operation corresponding to the current flashing step based on the replaced step parameter, thereby realizing ECU configuration file flashing. The method combines instance data of an upgrade configuration file and a variable replacement mechanism, so that the same project configuration file can adapt to flashing requirements of different ECUs to be flashed by matching instance data of different upgrade configuration files, without modifying a process template itself, and the reusability of a flashing process is significantly improved.

Description

Technical Field

[0001] This application relates to the field of vehicle software upgrade technology, and in particular to a method and device for flashing configuration files of a vehicle electronic control unit. Background Technology

[0002] With the rapid development of automotive electronics technology, the Electronic Control Unit (ECU) has become a core control component of vehicles, and its software upgrades are directly related to vehicle performance optimization and operational stability. Currently, the automotive industry is developing towards multi-model and customized solutions, resulting in increasingly diverse ECU models and software versions for different models and configurations. As a crucial step in manufacturing and after-sales maintenance, ECU remapping places higher demands on the flexibility, reusability, and standardization of remapping tools.

[0003] Currently, the development of ECU flashing tools in the industry mainly relies on two technical paths: One approach is the hard-coded method, where engineers need to write independent scripts or programs for specific vehicle models or ECU models, deeply binding the flashing process logic with instance information such as ECU communication addresses, software version numbers, and upgrade package paths. This method results in repeated code modifications when adapting the same flashing logic to different scenarios, generating significant redundancy and substantially increasing development and maintenance costs.

[0004] Second, there is the configurable script mode, which describes the flashing steps through configuration files, thus achieving a certain degree of separation between process logic and code. However, this type of solution still has the following shortcomings: (1) The process template and instance data are not completely decoupled. The configuration file usually directly hardcodes instance information such as ECU address and version number, which makes the template itself unusable. If you change an ECU, you still need to copy and modify the entire configuration file; (2) There is a lack of a general execution engine. Each project needs to develop a dedicated parsing and execution script, which cannot achieve a standardized operation mechanism of "define once, execute in multiple places".

[0005] Therefore, the existing technology has not yet provided a technical solution that can completely decouple the flashing process template and instance data at the same time, and uniformly interpret and execute them through a general execution engine, which restricts the efficiency and standardization of the ECU flashing process. Summary of the Invention

[0006] To address the aforementioned issues, this application provides a method and apparatus for flashing configuration files for a vehicle electronic control unit.

[0007] The embodiments of this application disclose the following technical solutions: In a first aspect, embodiments of this application provide a method for flashing a configuration file of a vehicle electronic control unit, the method comprising: Obtain the project configuration file and the upgrade configuration file; wherein, the project configuration file is a flashing process template decoupled from the instance information of the vehicle electronic control unit (ECU) to be flashed, the workflow definition in the project configuration file includes multiple flashing steps arranged in execution order, and at least one of the multiple flashing steps includes variable references; the upgrade configuration file includes at least one instance data corresponding to the ECU to be flashed; The upgrade configuration file is parsed to generate a variable set; wherein the variable set is associated with the variable references and the instance data; The multiple flashing steps are traversed. When the current flashing step is executed, instance data corresponding to the variable reference of the current flashing step is obtained from the variable set, and the variable reference in the step parameters is dynamically replaced. The operation corresponding to the current flashing step is executed based on the replaced step parameters.

[0008] In one possible implementation, the workflow definition of the project configuration file further includes a pre-parsing node; the variable set includes a first variable set; The process of parsing the upgrade configuration file to generate a variable set includes: Execute the aforementioned pre-parsing node to determine whether the upgrade configuration file is in a standard or non-standard format; If the upgrade configuration file is in a standard format, the built-in parser is used to extract the instance data and generate the first variable set according to preset rules; If the upgrade configuration file is in a non-standard format, the external plugin specified by the pre-parsing node is called to parse the upgrade configuration file and output the first set of variables that conforms to the preset rules.

[0009] In one possible implementation, the variable set further includes a second variable set, and the method further includes: Obtain external input parameters; wherein, the external input parameters include communication configuration and flashing mode selection; The external input parameters are encapsulated into the second variable set; wherein the variable names in the second variable set correspond one-to-one with some variable references in the flashing step; The step of replacing variable references in each of the flashing steps with the instance data includes: For each flashing step, determine whether the variable reference is associated with the first variable set or the second variable set; If the variable reference is associated with the first variable set, then the corresponding instance data is extracted from the first variable set and replaced; If the variable references a second variable set, then the corresponding configuration data is extracted from the second variable set and replaced.

[0010] In one possible implementation, the project configuration file also includes UDS service mapping rules, which include the business identifier, request message format, and expected response mode of each UDS service. The operation corresponding to the current flashing step is performed based on the replaced step parameters, including: The brushing step is identified as a UDS service call step; Extract the business identifier of the replaced UDS service in the UDS service call step, and match the request message format and expected response mode corresponding to the business identifier from the UDS service mapping rules; The request message format is combined with instance data in the first variable set to fill in the placeholders in the request message format and generate a request message. The request message and the expected response pattern are jointly bound to the execution logic of the UDS service invocation step.

[0011] In one possible implementation, the project configuration file further includes a retry strategy definition, which includes a trigger condition, a maximum number of retries, and a delay array; the trigger condition is a preset negative response code. The method further includes: Execute the UDS service call step and receive the response result returned by the ECU to be flashed; If the response result matches the triggering condition, the UDS service call step is retried at intervals according to the delay time in the delay array until the response result returned by the UDS service call step fails to trigger the enrichment strategy, or the cumulative number of retries of the UDS service call step reaches the maximum number of retries.

[0012] In one possible implementation, the project configuration file also includes plugin configuration rules, which include a plugin baseline lookup directory, a default parameter mapping table, and special parameters for each plugin. The operation corresponding to the current flashing step is performed based on the replaced step parameters, including: The identified type is the flashing step, which is a plugin invocation step. Obtain the plugin baseline lookup directory and the default parameter mapping table from the plugin configuration rules; Extract the replaced custom parameters from the plugin invocation step, and combine them with the default parameter mapping table and the special parameters corresponding to the invoked plugin to generate complete plugin execution parameters; The target plugin is located based on the plugin baseline search directory, and the complete plugin execution parameters are injected into the target plugin.

[0013] In one possible implementation, the variable references in the write step include string processing instructions, which are string slicing or string concatenation. The step of retrieving instance data corresponding to the variable references in the current write step from the variable set and dynamically replacing the variable references in the step parameters includes: Identify the string processing instructions in the variable references of the flashing step; Extract the instance data corresponding to the variable references from the first variable set; The instance data is processed according to the string processing instructions to obtain the target data; the target data is then replaced in the step parameters of the corresponding flashing step.

[0014] Secondly, embodiments of this application disclose a configuration file flashing device for a vehicle electronic control unit, the device comprising: The acquisition module is used to acquire the project configuration file and the upgrade configuration file; wherein, the project configuration file is a flashing process template decoupled from the instance information of the electronic control unit (ECU) of the vehicle to be flashed, and the workflow definition in the project configuration file includes multiple flashing steps arranged in execution order, and the step parameters of each flashing step include at least one variable reference; the upgrade configuration file includes at least one instance data corresponding to the ECU to be flashed; The decryption module is used to parse the upgrade configuration file to generate a variable set; wherein the variable set is associated with the variable references and the instance data; The replacement module is used to traverse the multiple brushing steps, and when executing the current brushing step, to obtain instance data corresponding to the variable reference of the current brushing step from the variable set, and dynamically replace the variable reference in the step parameters. The execution module is used to perform the operation corresponding to the current flashing step based on the replaced step parameters.

[0015] In one possible implementation, the workflow definition of the project configuration file further includes a pre-parsing node; the variable set includes a first variable set; The decryption module is specifically used to execute the pre-parsing node and determine whether the format of the upgrade configuration file is a standard format or a non-standard format. If the upgrade configuration file is in a standard format, the built-in parser is used to extract the instance data and generate the first variable set according to preset rules; If the upgrade configuration file is in a non-standard format, the external plugin specified by the pre-parsing node is called to parse the upgrade configuration file and output the first set of variables that conforms to the preset rules.

[0016] In one possible implementation, the variable set further includes a second variable set, and the acquisition module is further configured to acquire external input parameters; wherein, the external input parameters include communication configuration and flashing mode selection; The decryption module is also used to encapsulate the external input parameters into the second variable set; wherein the variable names of the second variable set correspond one-to-one with the variable references in the flashing step; The replacement module is specifically used to determine whether the variable reference is associated with the first variable set or the second variable set for each write step. If the variable reference is associated with the first variable set, then the corresponding instance data is extracted from the first variable set and replaced; If the variable references a second variable set, then the corresponding configuration data is extracted from the second variable set and replaced.

[0017] In one possible implementation, the project configuration file also includes UDS service mapping rules, which include the business identifier, request message format, and expected response mode of each UDS service. The execution module is specifically used to identify the flushing step of type UDS service call step; Extract the business identifier of the replaced UDS service in the UDS service call step, and match the request message format and expected response mode corresponding to the business identifier from the UDS service mapping rules; The request message format is combined with instance data in the first variable set to fill in the placeholders in the request message format and generate a request message. The request message and the expected response pattern are jointly bound to the execution logic of the UDS service invocation step.

[0018] In one possible implementation, the project configuration file further includes a retry strategy definition, which includes a trigger condition, a maximum number of retries, and a delay array; the trigger condition is a preset negative response code. The device also includes a retry module; The retry module is used to execute the UDS service call steps and receive the response result returned by the ECU to be flashed; If the response result matches the triggering condition, the UDS service call step is retried at intervals according to the delay time in the delay array until the response result returned by the UDS service call step fails to trigger the enrichment strategy, or the cumulative number of retries of the UDS service call step reaches the maximum number of retries.

[0019] In one possible implementation, the project configuration file also includes plugin configuration rules, which include a plugin baseline lookup directory, a default parameter mapping table, and special parameters for each plugin. The execution module is specifically used to identify the flashing step, which is of the type of plugin invocation step. Obtain the plugin baseline lookup directory and the default parameter mapping table from the plugin configuration rules; Extract the replaced custom parameters from the plugin invocation step, and combine them with the default parameter mapping table and the special parameters corresponding to the invoked plugin to generate complete plugin execution parameters; The target plugin is located based on the plugin baseline search directory, and the complete plugin execution parameters are injected into the target plugin.

[0020] In one possible implementation, the variable references in the write step include string processing instructions, which are string slicing or string concatenation. The replacement module is specifically used to identify string processing instructions in the variable references of the flashing step; Extract the instance data corresponding to the variable references from the first variable set; The instance data is processed according to the string processing instructions to obtain the target data; the target data is then replaced in the step parameters of the corresponding flashing step.

[0021] Thirdly, embodiments of this application disclose a control device, including a processor and a memory, wherein the memory is used to store programs, instructions or code, and the processor is used to execute the programs, instructions or code in the memory to complete the configuration file flashing method of the vehicle electronic control unit as described in any of the first aspects.

[0022] Fourthly, embodiments of this application disclose a computer-readable storage medium storing a computer program, which is loaded by a processor to execute the configuration file flashing method for a vehicle electronic control unit as described in any of the first aspects.

[0023] This application provides a method and device for flashing the configuration file of a vehicle electronic control unit. The method obtains a project configuration file decoupled from the ECU instance information to be flashed and an upgrade configuration file including corresponding instance data. First, it parses the upgrade configuration file to generate a variable set containing associated variable references and instance data. Then, it iterates through multiple flashing steps. When executing the current flashing step, it retrieves instance data corresponding to the variable references of the current flashing step from the variable set and dynamically replaces the variable references in the step parameters. Based on the replaced step parameters, it executes the operation corresponding to the current flashing step to achieve ECU configuration file flashing.

[0024] This method designs the project configuration file as a flashing process template decoupled from instance information. Combined with instance data and variable replacement mechanisms in the upgrade configuration file, the same project configuration file can adapt to the flashing needs of different ECUs by matching instance data from different upgrade configuration files, without requiring modification of the process template itself, significantly improving the reusability of the flashing process. Simultaneously, it avoids redundant development caused by the deep coupling of process logic and instance information in traditional hard-coded models, reducing the workload of repeatedly modifying code due to changes in instance information, lowering development and maintenance costs. Furthermore, the standardized variable replacement and instantiation process enhances the flexibility and adaptation efficiency of ECU flashing. Attached Figure Description

[0025] To more clearly illustrate the technical solutions in the embodiments of this application or the prior art, the drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, the drawings described below are only some embodiments of this application. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0026] Figure 1 A flowchart illustrating a method for flashing a configuration file of a vehicle electronic control unit, provided in an embodiment of this application; Figure 2 This is a schematic diagram of a configuration file flashing device for a vehicle electronic control unit provided in an embodiment of this application. Detailed Implementation

[0027] As described earlier, firmware or configuration data flashing of ECUs is frequently required in vehicle manufacturing and after-sales service. Existing flashing processes are typically customized for specific vehicle models or ECU models, and their flashing scripts or configuration files are highly coupled with specific ECU instance information.

[0028] Whenever a new car model, ECU model, or software version needs to be supported, developers need to write or heavily modify the flashing process script from scratch. This leads to low development efficiency, high labor costs, and is prone to errors introduced by manual modifications, increasing the operational risks of the flashing process.

[0029] Furthermore, the flashing process has extremely poor reusability, making it unable to quickly respond to market changes. Maintaining and managing numerous customized flashing scripts becomes a heavy burden, severely restricting the flexibility and efficiency of online vehicle software upgrades or offline service station flashing.

[0030] To address this technical problem, this application provides a method and apparatus for flashing the configuration file of a vehicle electronic control unit. The method obtains a project configuration file decoupled from the ECU instance information to be flashed and an upgrade configuration file including corresponding instance data. First, it parses the upgrade configuration file to generate a variable set containing associated variable references and instance data. Then, it iterates through multiple flashing steps. When executing the current flashing step, it retrieves instance data corresponding to the variable references of the current flashing step from the first variable set and dynamically replaces the variable references in the step parameters. Based on the replaced step parameters, it executes the operation corresponding to the current flashing step to achieve ECU configuration file flashing.

[0031] This method designs the project configuration file as a flashing process template decoupled from instance information. Combined with instance data and variable replacement mechanisms in the upgrade configuration file, the same project configuration file can adapt to the flashing needs of different ECUs by matching instance data from different upgrade configuration files, without requiring modification of the process template itself, significantly improving the reusability of the flashing process. Simultaneously, it avoids redundant development caused by the deep coupling of process logic and instance information in traditional hard-coded models, reducing the workload of repeatedly modifying code due to changes in instance information, lowering development and maintenance costs. Furthermore, the standardized variable replacement and instantiation process enhances the flexibility and adaptation efficiency of ECU flashing.

[0032] The method provided in this application can be widely applied to two core scenarios: vehicle manufacturing and after-sales maintenance. It achieves efficient flashing by relying on hardware such as diagnostic equipment, a host computer, and an in-vehicle communication module. In the manufacturing scenario, the production line station host acts as the execution carrier. It obtains a standardized project configuration file from the server via an industrial network and simultaneously reads instance information such as the model and hardware address of the ECU to be assembled using a barcode scanner, generating a corresponding upgrade configuration file. The host parses the upgrade configuration file to obtain a variable set, replaces the variable references in the flashing steps of the project configuration file with the instance data, and establishes communication with the ECU to be flashed through the OBD diagnostic interface module. It then instantiates the flashing steps into a flashing task, automatically completing software programming and configuration loading, adapting to the batch flashing needs of multiple production lines and multiple vehicle models.

[0033] In after-sales maintenance scenarios, repair personnel use portable diagnostic tools or tablets equipped with dedicated flashing software to download the corresponding vehicle model's project configuration file from a cloud server. Then, through the diagnostic tool's communication connection with the vehicle's ECU, they read the current ECU's instance data to generate an upgrade configuration file. After the device completes variable replacement and flashing task instantiation according to the process, it sends flashing commands to the ECU via the diagnostic tool's communication module, achieving software upgrades or fault repairs. This eliminates the need for separate diagnostic software adaptations for different vehicle models; simply changing the upgrade configuration file quickly adapts to the maintenance needs of various ECUs.

[0034] To enable those skilled in the art to better understand the present application, the technical solutions in the embodiments of the present application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of the present application, and not all embodiments. Based on the embodiments in the present application, all other embodiments obtained by those of ordinary skill in the art without creative effort are within the scope of protection of the present application.

[0035] See Figure 1 , Figure 1 This is a flowchart illustrating a method for flashing a configuration file of a vehicle electronic control unit, provided in an embodiment of this application. The execution subject of this method can be a server, a desktop computer, or other electronic device capable of computation. The following description uses an electronic device as the execution subject, and the method includes: S101: Electronic devices obtain project configuration files and upgrade configuration files.

[0036] The project configuration file is a flashing process template decoupled from the instance information of the ECU to be flashed, and can use a structured data format. The project configuration file includes a workflow definition, used to standardize the execution logic and step sequence of the flashing process. The workflow definition includes multiple flashing steps arranged in execution order, and at least one of these flashing steps includes variable references. Variable references are placeholders in the flashing step parameters used to associate instance data; they do not have actual execution meaning on their own and must be replaced by instance data to take effect.

[0037] The upgrade configuration file includes at least one instance of data corresponding to the ECU to be flashed. The instance data is the specific value corresponding to the variable reference in the upgrade configuration file, such as the ECU physical address 0x123, the target software version V2.4.1, or the upgrade package path / firmware / ECU_A_V241.bin, etc.

[0038] In practical application scenarios, project configuration files are pre-written by technicians and stored locally on servers or diagnostic devices. Their workflow is defined according to the general logic design of ECU flashing, such as a sequence of steps including activating the diagnostic session, secure access, reading the current version, transmitting upgrade data, and verifying the flashing results. Variable references in the step parameters can uniformly adopt the format ${package.xxx}, such as setting the key request address parameter in the secure access step to ${package.securityAddr}, to avoid embedding any specific instance data.

[0039] When acquiring the project configuration file, the electronic device downloads the corresponding standardized file from the server via the network or directly reads a locally stored template. When acquiring the upgrade configuration file, the electronic device can do so in two ways. In a production scenario, the electronic device reads the QR code of the ECU to be flashed using a barcode scanner, extracts information such as the ECU model and hardware address, and automatically generates an upgrade configuration file including corresponding instance data. In an after-sales scenario, the electronic device establishes communication with the ECU to be flashed via the OBD interface, reads the instance data of the ECU (such as the existing software version and hardware identifier), combines it with the target upgrade data obtained from the cloud, and generates an upgrade configuration file, ensuring that the instance data completely matches the ECU to be flashed.

[0040] This application embodiment separates the storage and retrieval of project configuration files and upgrade configuration files, decoupling the process template and execution object from the source, avoiding the problem of deep binding between process and instance information in the traditional hard-coded mode. The same project configuration file can adapt to the flashing requirements of different ECUs. Only the corresponding upgrade configuration file needs to be replaced, without modifying the process logic, significantly improving the reusability of the flashing process. At the same time, the upgrade configuration file is automatically collected or read to ensure the accuracy of instance data, reduce human input errors, and provide a reliable data foundation for subsequent variable replacement and task instantiation, improving the standardization and efficiency of the flashing process.

[0041] S102: Electronic device parses upgrade configuration file to generate variable set.

[0042] After the electronic device obtains the project configuration file and upgrade configuration file, it automatically triggers the parsing process, calling the built-in parsing module to read the raw data of the upgrade configuration file. Regardless of whether the upgrade configuration file is a standard JSON format automatically generated in a production scenario or a custom format formed by combining data read by the ECU and upgrade information from the cloud in an after-sales scenario, the parsing module will extract core instance data according to preset rules, remove redundant information, associate instance data with corresponding variable reference names, and generate a variable set with a unified structure.

[0043] For example, the ECU physical address 0x123 and the target software version V2.4.1 recorded in the upgrade configuration file will be mapped by the parsing module to the key package.ecuAddr and the value 0x123, and the key package.targetVer and the value V2.4.1, respectively. This will eventually form a first set of variables containing multiple key-value pairs, which will be stored in the temporary memory of the execution body for direct use by subsequent variable replacement steps, ensuring the standardization and consistency of the parsing results.

[0044] In this embodiment, the electronic device is further configured with a context manager to uniformly maintain various variables during execution and provide a unified variable resolution interface. In this embodiment, the variable set includes any one of a first variable set, a second variable set, and dynamically captured variables. The context manager maintains the following three types of variables (where the first variable set and the second variable set can be substituted for each other): The first variable set (package variable set): generated by parsing the upgrade configuration file, contains ECU instance data, such as physical address, software version, etc., and appears in the variable reference in the form of ${package.xxx}.

[0045] The second variable set (cmd variable set): is generated by encapsulating external input parameters and includes dynamic parameters such as communication configuration and flashing mode selection. It appears in the variable reference in the form of ${cmd.xxx}.

[0046] Dynamically captured variables: These are specified by the setVar field in the UDS service response and stored in the context. They have no fixed prefix and are used for reference in subsequent steps.

[0047] In addition, step-level parameters can be introduced when executing specific steps. Step-level parameters are provided by the `params` field in the current flush step definition, and are formatted as a collection of key-value pairs. In the request message format defined by the UDS service, they are placed in the form `${params.yyy}`. The scope of step-level parameters is limited to the current step and is not confused with global variables in the context manager.

[0048] For example, a request message format in a UDS service definition might be "2EF15A${params.ts_str}${params.serial}", and the corresponding step definition could contain "params":{"ts_str":"20260214","serial":"FFFFFFFFFF"}. When processing this step, the execution engine will extract the corresponding value from the params object of the current step, replace the placeholders in the message, and generate a complete UDS request.

[0049] This application's embodiments generate a unified-format variable set through a standardized parsing process, establishing a clear association between variable references and instance data. This provides accurate and efficient data support for variable references in subsequent batch replacement and flashing steps, avoiding replacement errors caused by inconsistent instance data formats. Simultaneously, the parsing process automatically removes redundant information, retaining only valid instance data, reducing the computational load on the execution entity and improving the execution efficiency of subsequent steps. Furthermore, the unified variable set structure ensures that upgrade configuration files from different sources and in different formats can be adapted to the same project configuration file, further enhancing the compatibility and flexibility of the solution.

[0050] To further enhance the compatibility of the solution with upgrade configuration files of different formats and ensure the standardization and flexibility of the parsing process, the workflow definition of the project configuration file can also include a pre-parsing node. This pre-parsing node is used to adapt to upgrade configuration files of different formats, extracting instance data and generating variable sets through differentiated parsing logic. The variable set includes a first variable set, implemented as follows: Upon execution of the pre-parsing node, the electronic device determines whether the upgrade configuration file is in a standard or non-standard format. If the upgrade configuration file is in a standard format, the built-in parser extracts instance data and generates the first variable set according to preset rules. If the upgrade configuration file is in a non-standard format, the electronic device calls the external plugin specified by the pre-parsing node to parse the upgrade configuration file and outputs the first variable set that conforms to preset rules.

[0051] The pre-parsing node is a pre-defined parsing rule declaration unit in the project configuration file. Its core function is to define the parsing method of the upgrade configuration file, ensuring that regardless of whether the upgrade configuration file is in a standard or non-standard format, it can be transformed into a unified set of first variables. When the general execution engine of the electronic device enters the parsing process, it will first execute this pre-parsing node, and identify the format type of the upgrade configuration file through the pre-defined judgment logic in the node. Standard format refers to data format that conforms to the industry or execution engine's pre-defined specifications, such as JSON format with fixed fields. Non-standard formats include file formats not included in the pre-defined specifications, such as manufacturer-defined structures and special encoding formats.

[0052] If the upgrade configuration file is determined to be in a standard format, the execution engine will directly call the built-in parser to traverse the fields in the file according to preset rules, accurately extracting the instance data corresponding to the variable references in the project configuration file. No additional adaptation is required, and the first variable set of key-value pairs can be quickly generated, ensuring parsing efficiency. If the configuration file is determined to be in a non-standard format, the execution engine will call the corresponding external parsing plugin according to the plugin path specified in the pre-parsing node. This plugin is pre-developed to adapt to specific non-standard formats, enabling it to identify and extract valid instance data from non-standard files. Then, according to the execution engine's preset rules, the extracted instance data is encapsulated into a first variable set in a unified format, ensuring that the output result is consistent with the structure of the first variable set parsed in the standard format.

[0053] Through the pre-parsing node, electronic devices can efficiently process standard format files while remaining compatible with various non-standard format files, significantly improving the solution's adaptability and flexibility, and meeting the upgrade configuration file parsing needs of different manufacturers and application scenarios. Meanwhile, the external plugin calling mechanism does not require modification of the core logic of the execution engine; only corresponding plugins need to be developed for new non-standard formats, reducing the complexity of system expansion. Furthermore, the unified structure of the first variable set output ensures the stability and consistency of subsequent variable replacement steps, avoiding parsing failures or replacement errors due to format differences, further improving the reliability and standardization of the entire flashing process.

[0054] S103: The electronic device traverses multiple flashing steps. When executing the current flashing step, it retrieves instance data corresponding to the variable reference of the current flashing step from the variable set and dynamically replaces the variable reference in the step parameters.

[0055] After generating the first set of variables, the electronic device initiates a process of traversing the flashing steps. The general execution engine strictly follows the step order defined in the workflow, loading each flashing step one by one, scanning all variable references in the step parameters that exist in a preset format (such as ${package.xxx}), and using these variable references as matching keywords to compare with the key names in the first set of variables.

[0056] During the matching process, if a variable reference in the flashing step parameters can be found in the first variable set, the variable reference is directly replaced with the associated instance data. For example, the parameter ${package.securityAddr} in the security access step will be replaced with "0x123" in the first variable set, and ${package.targetVer} in the version verification step will be replaced with "V2.4.1". If the variable reference contains string processing instructions, the execution engine will first process the instance data according to the instructions, and then fill the processed result into the step parameters to ensure that the parameter format conforms to the ECU communication requirements.

[0057] After all the brushing steps have been traversed and executed, the execution engine generates a structured execution report, recording the execution status and results of each step.

[0058] This application's embodiments achieve precise binding between the flashing process template and ECU instance data through automated traversal and variable replacement operations. This allows the project configuration file, decoupled from instance information, to possess execution attributes specific to a particular ECU. The same project configuration file only needs to match different sets of first variables to adapt to different ECU models, without modifying any process logic. This significantly improves the reusability of the flashing process and reduces the cost of repetitive development. Simultaneously, the standardized automatic replacement process avoids errors that may occur from manual parameter modification, ensuring the accuracy and consistency of flashing step parameters and laying a reliable foundation for the smooth execution of subsequent flashing tasks.

[0059] Based on replacing the variable references in the flashing step using the first variable set, to further adapt to dynamic configuration requirements during the flashing process, such as communication parameter adjustments and flashing mode selection, this embodiment of the application can also introduce external input parameters and construct a second variable set. This enriches the data source of the variable references and enables more refined configuration of step parameters. The specific implementation of the second variable set is as follows: The electronic device acquires external input parameters and encapsulates them into a second variable set. For each flashing step, the electronic device determines whether the variable reference is associated with a first or second variable set. If the variable reference is associated with the first variable set, the electronic device extracts the corresponding instance data from the first variable set and replaces it; if the variable reference is associated with the second variable set, the electronic device extracts the corresponding configuration data from the second variable set and replaces it.

[0060] External input parameters refer to dynamic configuration data that is manually entered by the operator or automatically transmitted by the execution environment before the flashing process is executed. These mainly include ECU communication configuration (such as baud rate and communication port number), flashing mode selection (such as forced flashing and incremental flashing), and timeout threshold settings, which are related to the flashing execution conditions. This type of data does not change with the ECU instance information, but it will affect the execution logic of the flashing process.

[0061] While acquiring the project configuration file and upgrade configuration file, the electronic device simultaneously acquires the aforementioned external input parameters and encapsulates them into a second variable set according to preset rules. The second variable set also adopts a key-value pair structure. Here, the key is the name of the corresponding variable reference in the flashing step (such as ${cmd.baudRate}), and the value is the specific external configuration data, ensuring that the variable names in the second variable set correspond one-to-one with some variable references in the flashing step.

[0062] During the variable reference replacement operation in the flashing process, the general execution engine of the electronic device identifies and judges each variable reference, distinguishing whether it is associated with the first variable set or the second variable set. This can be quickly determined using preset prefixes for variable references, such as the `package` prefix associating with the first variable set and the `cmd` prefix associating with the second variable set. If the variable reference is determined to be associated with the first variable set, ECU instance data is extracted from the first variable set for replacement; if it is determined to be associated with the second variable set, external configuration data is extracted from the second variable set for replacement. Finally, all variable references are filled, generating the flashing process.

[0063] By introducing external input parameters and a second set of variables, this embodiment expands the variable data source for the flashing process from ECU instance data to dynamic configuration data. This allows the same project configuration file to not only adapt to instance information of different ECUs but also flexibly handle different flashing execution conditions, further enhancing the flexibility and adaptability of the flashing process. Simultaneously, a clear variable set association judgment mechanism ensures accurate variable replacement from different data sources, avoiding data confusion and guaranteeing the accuracy of the replaced project configuration file. Furthermore, the separate management of external configuration data and ECU instance data makes parameter adjustments in the flashing process more convenient. No modification to the core logic of the project configuration file is required; only changes to external input parameters are needed to switch flashing modes and communication parameters, reducing operational complexity.

[0064] After completing the association judgment and basic replacement logic between variable references and corresponding variable sets, to meet the refined requirements of instance data format in the ECU flashing process, such as version number segment matching and communication address format concatenation, this application embodiment also supports embedding string processing instructions in variable references. Through targeted processing of instance data, the replaced step parameters are made to fully conform to the ECU's communication protocol specifications. The specific implementation method is as follows: The electronic device identifies string processing instructions in the variable references of the flashing steps and extracts the instance data corresponding to the variable references from the first variable set. The electronic device processes the instance data according to the string processing instructions to obtain the target data and replaces the target data in the step parameters of the corresponding flashing step.

[0065] String processing instructions include two types: string slicing and string concatenation. These are directly embedded in the variable references of the brushing step and are used to define the processing rules for instance data. String slicing instructions are used to extract specified character segments from the instance data, while string concatenation instructions are used to combine instance data with preset fixed characters to form a parameter format that meets the requirements.

[0066] When an electronic device goes through the flashing process and identifies a variable reference containing string processing instructions, it will prioritize parsing the type and specific rules of the processing instructions carried in that variable reference. For example, when the variable reference is ${package.version[0:3]}, it carries a string slicing instruction, which extracts the first three characters of the version number. When the variable reference is ${package.ecuAddr}_80, it carries a string concatenation instruction, which combines the ECU address with the fixed suffix "_80".

[0067] Subsequently, the execution engine extracts the original instance data associated with the variable reference from the corresponding first variable set, such as the version number "V2.4.1" and the ECU address "0x123". Next, it processes the original instance data strictly according to the identified string processing instructions: slicing the version number "V2.4.1" yields the target data "V2.4", and concatenating the ECU address "0x123" yields the target data "0x123_80". Finally, the processed target data is replaced with the parameter position corresponding to the flashing step, completing the precise replacement of the variable reference.

[0068] This application's embodiments achieve dynamic and refined processing of instance data by embedding string processing instructions in variable references. This eliminates the need for pre-processing data formats in the upgrade configuration file or modifying the project configuration file's workflow logic, ensuring that the replaced step parameters perfectly match the ECU's communication protocol requirements, significantly improving parameter adaptation accuracy. Simultaneously, the integrated design of string processing instructions and variable references simplifies the data format adaptation process, preventing flashing communication failures due to data format inconsistencies, and further enhancing the stability and compatibility of the entire flashing process.

[0069] S104: The electronic device performs the operation corresponding to the current flashing step based on the replaced step parameters.

[0070] The replaced step parameters have removed all placeholder variable references, and the parameters for the flashing steps are now filled with specific data, such as instance data, external configuration data, or target data after string processing. These parameters are specific instruction data that perfectly match the ECU to be flashed and the flashing conditions.

[0071] After obtaining the replaced step parameters and completing integrity verification, the electronic device executes the operation corresponding to the current flashing step based on the replaced step parameters. For example, if a step is a UDS service call step, the execution engine will bind the step to the UDS communication module, load the ECU communication address, request message format, and other data already filled in the step parameters, and configure the communication baud rate, timeout threshold, and other operating parameters; if it is a plug-in call step, it will bind to the plug-in scheduling module, confirm the plug-in path and complete execution parameters, and ensure that the plug-in can be called normally. At the same time, the execution engine will allocate temporary running resources for the flashing task and establish a task execution log to record the execution status and results of each step, which is convenient for subsequent anomaly investigation and tracing.

[0072] This application embodiment executes the operation corresponding to the current flashing step based on the replaced step parameters, realizing the transformation of the flashing process from rule definition to actual implementation, and ensuring the effective execution of the flashing logic. At the same time, the replaced step parameters have a standardized execution form, unifying the task scheduling logic under different ECUs and different flashing scenarios, further enhancing the standardization of the solution, and the establishment of task execution logs provides convenience for traceability and anomaly investigation of the flashing process, reducing maintenance costs.

[0073] For frequently occurring UDS service call steps in the flashing process, such as diagnostic session activation and secure access authentication, since these must comply with the UDS communication protocol specification, this embodiment of the application ensures the standardization and accuracy of UDS service calls by pre-setting UDS service mapping rules in the project configuration file. The specific implementation method is as follows: The electronic device identifies the UDS service call step as a "flash" step. It extracts the business identifier of the replaced UDS service from the UDS service call step and matches the request message format and expected response mode corresponding to the business identifier from the UDS service mapping rules. The electronic device combines the request message format with instance data from the first variable set, fills in the placeholders in the request message format, generates the request message, and binds the request message and expected response mode together to the execution logic of the UDS service call step.

[0074] UDS service mapping rules are a set of standardized communication rules preset in the project configuration file, used to standardize the calling logic of various UDS services. UDS service mapping rules include the business identifier of each UDS service (used to uniquely distinguish different UDS services, such as "0x10" corresponding to the diagnostic session activation service), the request message format (a standardized message template that conforms to the UDS protocol, containing unfilled placeholders, such as ECU address placeholders), and the expected response mode (a response standard used to determine whether the UDS service call is successful).

[0075] The electronic device identifies the type of each flashing step and filters out all flashing steps that are UDS service call steps. These UDS service call steps typically include a clear UDS service business identifier field, and variable reference replacement has been completed, with the business identifier filled with a specific value.

[0076] Subsequently, the electronic device extracts the replaced UDS service business identifier from the UDS service call step. Using this identifier as a search keyword, it accurately matches the corresponding request message format and expected response mode from the UDS service mapping rules in the project configuration file. After the matching is completed, the execution engine combines the request message format with the ECU instance data (such as ECU physical address, software version, etc.) in the first variable set, fills the placeholders in the message format (such as filling the address "0x123" of the ECU into the address field of the message), and generates a request message that can directly communicate with the ECU to be flashed.

[0077] Finally, the electronic device binds the generated request message and the matched expected response pattern to the execution logic of the UDS service call step, clarifying the request content to be sent when the step is executed and the response standard to be verified, ensuring that the UDS service call and response verification can be completed in accordance with the specifications when the step is executed in the future, and realizing the standardized instantiation of the UDS service call step.

[0078] This application's embodiments unify the management of core rules for UDS communication and flashing process templates, avoiding the problem of scattered embedded code in UDS message formats in traditional hard-coded modes, and improving the standardization of UDS service calls. Simultaneously, through a business identifier matching mechanism, it ensures that various UDS services can accurately call the corresponding communication rules, generating request messages adapted to specific ECUs by combining the first or second variable set. This guarantees communication accuracy and enables the reuse of UDS service rules. The same UDS service mapping rule can adapt to different ECUs; only different instance data needs to be filled in using the first variable set, further enhancing the reusability and flexibility of the solution. Furthermore, the binding of the expected response mode with the request message provides a clear standard for subsequent UDS service call response verification, effectively avoiding flashing failures due to misjudgment of responses and improving the reliability of the flashing process.

[0079] Considering that temporary communication anomalies or ECU busy conditions may occur during the UDS service call, causing the ECU to return a negative response and triggering a flashing interruption, this embodiment adds a fault-tolerant mechanism to the UDS service call steps by pre-defining a retry strategy definition in the project configuration file. This ensures the stability of the UDS service call and guarantees the smooth progress of the flashing process. The specific implementation method is as follows: When executing the UDS service call step, the electronic device receives the response result returned by the ECU to be flashed. If the response result matches the triggering condition, the UDS service call step is retried at intervals according to the delay time in the delay array until the response result returned by the UDS service call step fails to trigger the enrichment strategy, or the cumulative number of retries for executing the UDS service call step reaches the maximum number of retries.

[0080] The retry policy definition is a set of pre-defined fault-tolerance rules in the project configuration file, specifically designed to handle abnormal responses during UDS service calls. The retry policy definition includes three core parameters: trigger condition, maximum number of retries, and delay array. The trigger condition is explicitly defined as a pre-defined negative response code, i.e., the response code returned by the ECU indicating that the service call failed but can be retried, such as NRC78 "Request rejected, wait" or NRC10 "Invalid service". The maximum number of retries limits the retry limit to avoid resource waste caused by infinite retries. The delay array defines the time interval for each retry, such as [100ms, 200ms, 300ms]. The delay array can use an incremental delay method to reduce the pressure on the ECU and communication link caused by frequent retries.

[0081] The execution process of this retry strategy is closely linked to the execution of the UDS service call steps. After the electronic device starts an executable flashing task, it executes the instantiated UDS service call steps in sequence, sends the bound request message to the ECU to be flashed through the communication module, and receives the response result returned by the ECU in real time.

[0082] The electronic device compares the received response with the trigger conditions defined in the retry policy to determine whether to trigger the retry mechanism. If the response does not match the trigger conditions, the UDS service call step is considered to have been executed successfully, and subsequent flushing steps continue. If the response matches the trigger conditions, the retry process is initiated, and the UDS service call step is retried strictly according to the delay intervals in the delay array. Each retry uses the request message bound at instantiation time to ensure consistency during the retry process.

[0083] Throughout the retry process, the electronic device will accumulate the number of retries in real time. When the accumulated number of retries reaches the preset maximum number of retries, or when the response returned by the ECU after a retry no longer triggers the triggering condition, the retry will be terminated immediately. If the retry is successful, the subsequent steps will continue; if the retry fails, an error log will be recorded and the entire flashing task will be terminated to facilitate troubleshooting by the operator.

[0084] By defining a pre-defined retry strategy and adding a fault-tolerance mechanism to the UDS service call steps, the system effectively solves the problem of flashing interruptions caused by occasional issues such as temporary communication anomalies and ECU busyness during UDS service calls. This significantly improves the stability of UDS service calls and the fault tolerance of the flashing process, reducing the flashing failure rate. The incremental delay design of the delay array avoids the additional pressure on the ECU and communication link caused by frequent retries, and can reasonably utilize time intervals to wait for the ECU to recover to a ready state, improving the retry success rate. At the same time, the retry strategy definition is integrated into the project configuration file, without modifying the core logic of the execution engine. The triggering conditions, number of retries, and delay intervals can be flexibly adjusted according to the characteristics of different UDS services to adapt to the UDS service call requirements in different scenarios. This further enhances the flexibility and adaptability of the solution, reduces the cost of manual intervention due to occasional anomalies, and improves the automation level of the flashing process.

[0085] For auxiliary operations in the flashing process that cannot be implemented through built-in modules, such as secure access key calculation and ECU health status detection after flashing, this application embodiment standardizes the instantiation process of plugin invocation steps by pre-setting plugin configuration rules in the project configuration file, thereby achieving efficient integration of external plugins with the flashing task and further enriching the functional coverage of the flashing process. The specific implementation method is as follows: The electronic device is identified as a flashing step within a plugin invocation process. The plugin baseline lookup directory and default parameter mapping table are retrieved from the plugin configuration rules. The electronic device extracts the replaced custom parameters from the plugin invocation step, combines them with the default parameter mapping table and the specific parameters corresponding to the invoked plugin, and generates complete plugin execution parameters. The target plugin is located based on the plugin baseline lookup directory, and the complete plugin execution parameters are injected into the target plugin.

[0086] Plugin configuration rules are standardized plugin integration specifications preset in the project configuration file. These rules include a plugin baseline lookup directory, a default parameter mapping table, and specific parameters for each plugin. The plugin baseline lookup directory defines a unified root path for the execution entity to find external plugins, preventing call failures caused by inconsistent plugin paths. The default parameter mapping table contains common basic parameters required for each plugin's operation, such as communication port, execution timeout threshold, and log storage path, eliminating the need for repeated definition in each plugin call step. The specific parameters for each plugin are pre-set parameters tailored to the functional characteristics of different plugins, such as the algorithm version parameter for the key calculation plugin and the verification item parameter for the health check plugin, adapting to the plugin's personalized execution needs.

[0087] When an electronic device instantiates a flashing step, it first filters out flashing steps of the type "plugin invocation step". The plugin invocation step has completed variable reference replacement and carries a clear plugin name and custom parameters, such as the target plugin identifier and personalized parameters configured by the user as needed.

[0088] Subsequently, the electronic device extracts the corresponding plugin baseline lookup directory and default parameter mapping table from the plugin configuration rules in the project configuration file. Next, it extracts the replaced custom parameters in the plugin invocation step, integrates them with the general basic parameters in the default parameter mapping table and the special parameters corresponding to the plugin, supplements the general parameters not explicitly specified in the custom parameters and necessary special parameters, and verifies the validity of the parameter format. Finally, it generates a complete and compliant set of plugin execution parameters to ensure that the plugin has all the conditions for normal operation.

[0089] Finally, the electronic device searches the directory based on the plugin baseline, locates the target plugin according to the preset path traversal rules, injects the generated complete plugin execution parameters into the target plugin, completes the instantiation of the plugin call step, and makes the step executable. When the subsequent flashing task executes this step, it can directly start the target plugin and pass parameters to complete the corresponding auxiliary flashing operation.

[0090] This application embodiment achieves standardized integration of external plugins and flashing tasks by pre-setting plugin configuration rules and standardizing the instantiation process of plugin invocation steps. This avoids the complexity and poor compatibility issues caused by customized plugin integration in traditional hard-coded modes, improving the scalability and functional coverage of the flashing process. The unified definition of the plugin baseline lookup directory ensures the accuracy and efficiency of plugin location, reducing the complexity of plugin deployment and invocation. The design of the default parameter mapping table reduces parameter redundancy in plugin invocation steps, simplifying the plugin configuration process. Furthermore, the integration of custom parameters, default parameters, and special parameters ensures the integrity and compliance of plugin execution parameters, preventing plugin failures due to missing parameters and improving the reliability of plugin invocation. In addition, this integration method does not require modification of the core logic of the execution engine; only adding plugins and configuring corresponding plugin rules is needed to extend the functionality of the flashing process, significantly reducing the functional iteration cost of the flashing solution and adapting to ECU flashing needs in more complex scenarios.

[0091] This application also provides a device for flashing configuration files for a vehicle electronic control unit, such as... Figure 2 As shown, the device includes: The acquisition module 201 is used to acquire the project configuration file and the upgrade configuration file; wherein, the project configuration file is a flashing process template decoupled from the instance information of the electronic control unit (ECU) of the vehicle to be flashed, and the workflow definition in the project configuration file includes multiple flashing steps arranged in execution order, and the step parameters of each flashing step include at least one variable reference; the upgrade configuration file includes at least one instance data corresponding to the ECU to be flashed; The decryption module 202 is used to parse the upgrade configuration file to generate a variable set; wherein the variable set is associated with the variable references and the instance data; The replacement module 203 is used to traverse the multiple brushing steps, and when executing the current brushing step, obtain instance data corresponding to the variable reference of the current brushing step from the variable set, and dynamically replace the variable reference in the step parameters. The execution module 204 is used to perform the operation corresponding to the current brushing step based on the replaced step parameters.

[0092] In one possible implementation, the workflow definition of the project configuration file further includes a pre-parsing node; the variable set includes a first variable set; The decryption module 202 is specifically used to execute the pre-parsing node and determine whether the format of the upgrade configuration file is a standard format or a non-standard format. If the upgrade configuration file is in a standard format, the built-in parser is used to extract the instance data and generate the first variable set according to preset rules; If the upgrade configuration file is in a non-standard format, the external plugin specified by the pre-parsing node is called to parse the upgrade configuration file and output the first set of variables that conforms to the preset rules.

[0093] In one possible implementation, the variable set further includes a second variable set, and the acquisition module 201 is further configured to acquire external input parameters; wherein, the external input parameters include communication configuration and flashing mode selection; The decryption module 202 is also used to encapsulate the external input parameters into the second variable set; wherein the variable names of the second variable set correspond one-to-one with the variable references in the flashing step; The replacement module 203 is specifically used to determine whether the variable reference is associated with the first variable set or the second variable set for each write step. If the variable reference is associated with the first variable set, then the corresponding instance data is extracted from the first variable set and replaced; If the variable references a second variable set, then the corresponding configuration data is extracted from the second variable set and replaced.

[0094] In one possible implementation, the project configuration file also includes UDS service mapping rules, which include the business identifier, request message format, and expected response mode of each UDS service. The execution module 204 is specifically used to identify the flushing step of type UDS service call step; Extract the business identifier of the replaced UDS service in the UDS service call step, and match the request message format and expected response mode corresponding to the business identifier from the UDS service mapping rules; The request message format is combined with instance data in the first variable set to fill in the placeholders in the request message format and generate a request message. The request message and the expected response pattern are jointly bound to the execution logic of the UDS service invocation step.

[0095] In one possible implementation, the project configuration file further includes a retry strategy definition, which includes a trigger condition, a maximum number of retries, and a delay array; the trigger condition is a preset negative response code. The device also includes a retry module; The retry module is used to execute the UDS service call steps and receive the response result returned by the ECU to be flashed; If the response result matches the triggering condition, the UDS service call step is retried at intervals according to the delay time in the delay array until the response result returned by the UDS service call step fails to trigger the enrichment strategy, or the cumulative number of retries of the UDS service call step reaches the maximum number of retries.

[0096] In one possible implementation, the project configuration file also includes plugin configuration rules, which include a plugin baseline lookup directory, a default parameter mapping table, and special parameters for each plugin. The execution module 204 is specifically used to identify the flashing step, which is of the type of plugin invocation step. Obtain the plugin baseline lookup directory and the default parameter mapping table from the plugin configuration rules; Extract the replaced custom parameters from the plugin invocation step, and combine them with the default parameter mapping table and the special parameters corresponding to the invoked plugin to generate complete plugin execution parameters; The target plugin is located based on the plugin baseline search directory, and the complete plugin execution parameters are injected into the target plugin.

[0097] In one possible implementation, the variable references in the write step include string processing instructions, which are string slicing or string concatenation. The replacement module 203 is specifically used to identify string processing instructions in the variable references of the writing step; Extract the instance data corresponding to the variable references from the first variable set; The instance data is processed according to the string processing instructions to obtain the target data; the target data is then replaced in the step parameters of the corresponding flashing step.

[0098] This application also provides a control device. The control device may include a memory and a processor. The processor is used to execute the configuration file flashing method for the vehicle electronic control unit described in any of the above embodiments. The memory may be random access memory (RAM), flash memory, read-only memory (ROM), non-volatile read-only memory (EPROM), registers, hard disk, removable disk, etc.

[0099] The memory can store computer instructions. When these instructions are executed by the processor, the processor can use them to perform the configuration file flashing method for the vehicle's electronic control unit. The memory can also store data.

[0100] In the above embodiments, implementation can be achieved, in whole or in part, through software, hardware, firmware, or any combination thereof. When implemented in software, it can be implemented, in whole or in part, as a computer program product. A computer program product includes one or more computer instructions. When the computer program instructions are loaded and executed on a computer, all or part of the flow or function according to the embodiments of this application is generated. The computer can be a general-purpose computer, a special-purpose computer, a computer network, or other programmable device. The computer instructions can be stored in a computer-readable storage medium or transmitted from one computer-readable storage medium to another. For example, computer instructions can be transmitted from one website, computer, server, or data center to another website, computer, server, or data center via wired (e.g., coaxial cable, fiber optic, Digital Subscriber Line (DSL)) or wireless (e.g., infrared, wireless, microwave, etc.) means. The computer-readable storage medium can be any available medium that a computer can access or a data storage device such as a server or data center that integrates one or more available media. The available medium can be a magnetic medium (e.g., floppy disk, hard disk, magnetic tape) or a semiconductor medium (e.g., solid-state disk (SSD)).

[0101] This application also provides a readable storage medium for storing the methods provided in the above embodiments. For example, RAM, flash memory, ROM, EPROM, registers, hard disk, removable disk, or any other form of storage medium in the art.

[0102] In the embodiments of this application, the terms "first" and "second" (if they exist) are used only as name identifiers and do not represent the order of first and second.

[0103] It should be noted that the various embodiments in this specification are described in a progressive manner, with each embodiment focusing on the differences from other embodiments. Similar or identical parts between embodiments can be referred to interchangeably. Regarding the methods disclosed in the embodiments, since they correspond to the product embodiments disclosed in the embodiments, the description is relatively simple; relevant parts can be referred to in the description of the product embodiments.

[0104] The above description of the disclosed embodiments enables those skilled in the art to make or use this application. Various modifications to these embodiments will be readily apparent to those skilled in the art, and the general principles defined herein may be implemented in other embodiments without departing from the spirit or scope of this application. Therefore, this application is not to be limited to the embodiments shown herein, but is to be accorded the widest scope consistent with the principles and novel features disclosed herein.

Claims

1. A method for flashing a configuration file for a vehicle electronic control unit, characterized in that, The method includes: Obtain the project configuration file and the upgrade configuration file; wherein, the project configuration file is a flashing process template decoupled from the instance information of the vehicle electronic control unit (ECU) to be flashed, the workflow definition in the project configuration file includes multiple flashing steps arranged in execution order, and at least one of the multiple flashing steps includes variable references; the upgrade configuration file includes at least one instance data corresponding to the ECU to be flashed; The upgrade configuration file is parsed to generate a variable set; wherein the variable set is associated with the variable references and the instance data; The multiple flashing steps are traversed. When the current flashing step is executed, instance data corresponding to the variable reference of the current flashing step is obtained from the variable set, and the variable reference in the step parameters is dynamically replaced. The operation corresponding to the current flashing step is executed based on the replaced step parameters.

2. The method according to claim 1, characterized in that, The workflow definition in the project configuration file also includes a pre-parsing node; The variable set includes a first variable set; The process of parsing the upgrade configuration file to generate a variable set includes: Execute the aforementioned pre-parsing node to determine whether the upgrade configuration file is in a standard or non-standard format; If the upgrade configuration file is in a standard format, the built-in parser is used to extract the instance data and generate the first variable set according to preset rules; If the upgrade configuration file is in a non-standard format, the external plugin specified by the pre-parsing node is called to parse the upgrade configuration file and output the first set of variables that conforms to the preset rules.

3. The method according to claim 1, characterized in that, The variable set also includes a second variable set, and the method further includes: Obtain external input parameters; wherein, the external input parameters include communication configuration and flashing mode selection; The external input parameters are encapsulated into the second variable set; wherein the variable names in the second variable set correspond one-to-one with some variable references in the flashing step; The step of retrieving instance data corresponding to the variable references in the current write step from the variable set and dynamically replacing the variable references in the step parameters includes: For each flashing step, determine whether the variable reference is associated with the first variable set or the second variable set; If the variable reference is associated with the first variable set, then the corresponding instance data is extracted from the first variable set and replaced; If the variable reference is associated with the second variable set, then the corresponding configuration data is extracted from the second variable set and replaced.

4. The method according to claim 1, characterized in that, The project configuration file also includes UDS service mapping rules, which include the business identifier, request message format and expected response mode of each UDS service. The operation corresponding to the current flashing step is performed based on the replaced step parameters, including: The brushing step is identified as a UDS service call step; Extract the business identifier of the replaced UDS service in the UDS service call step, and match the request message format and expected response mode corresponding to the business identifier from the UDS service mapping rules; The request message format is combined with instance data in the first variable set to fill in the placeholders in the request message format and generate a request message. The request message and the expected response pattern are jointly bound to the execution logic of the UDS service invocation step.

5. The method according to claim 4, characterized in that, The project configuration file also includes a retry policy definition, which includes a trigger condition, a maximum number of retries, and a delay array; the trigger condition is a preset negative response code. The method further includes: Execute the UDS service call step and receive the response result returned by the ECU to be flashed; If the response result matches the triggering condition, the UDS service call step is retried at intervals according to the delay time in the delay array until the response result returned by the UDS service call step fails to trigger the enrichment strategy, or the cumulative number of retries of the UDS service call step reaches the maximum number of retries.

6. The method according to claim 1, characterized in that, The project configuration file also includes plugin configuration rules, which include a plugin baseline lookup directory, a default parameter mapping table, and special parameters for each plugin. The operation corresponding to the current flashing step is performed based on the replaced step parameters, including: The identified type is the flashing step, which is a plugin invocation step. Obtain the plugin baseline lookup directory and the default parameter mapping table from the plugin configuration rules; Extract the replaced custom parameters from the plugin invocation step, and combine them with the default parameter mapping table and the special parameters corresponding to the invoked plugin to generate complete plugin execution parameters; The target plugin is located based on the plugin baseline search directory, and the complete plugin execution parameters are injected into the target plugin.

7. The method according to claim 1, characterized in that, The variable references in the flashing step include string processing instructions, which are string slicing or string concatenation. The step of retrieving instance data corresponding to the variable references in the current write step from the variable set and dynamically replacing the variable references in the step parameters includes: Identify the string processing instructions in the variable references of the flashing step; Extract the instance data corresponding to the variable references from the first variable set; The instance data is processed according to the string processing instructions to obtain the target data; the target data is then replaced in the step parameters of the corresponding flashing step.

8. A configuration file flashing device for a vehicle electronic control unit, characterized in that, The device includes: The acquisition module is used to acquire the project configuration file and the upgrade configuration file; wherein, the project configuration file is a flashing process template decoupled from the instance information of the electronic control unit (ECU) of the vehicle to be flashed, the workflow definition in the project configuration file includes multiple flashing steps arranged in execution order, and at least one of the multiple flashing steps includes variable references; the upgrade configuration file includes at least one instance data corresponding to the ECU to be flashed; The decryption module is used to parse the upgrade configuration file to generate a variable set; wherein the variable set is associated with the variable references and the instance data; The replacement module is used to traverse the multiple brushing steps, and when executing the current brushing step, to obtain instance data corresponding to the variable reference of the current brushing step from the variable set, and dynamically replace the variable reference in the step parameters. The execution module is used to perform the operation corresponding to the current flashing step based on the replaced step parameters.

9. A control device, characterized in that, It includes a processor and a memory, the memory being used to store programs, instructions, or code, and the processor being used to execute the programs, instructions, or code in the memory to complete the configuration file flashing method for a vehicle electronic control unit as described in any one of claims 1-7.

10. A computer-readable storage medium, characterized in that, The system contains a computer program that is loaded by a processor to execute the configuration file flashing method for the vehicle electronic control unit as described in any one of claims 1-7.

Images