Upgrading method and device for vehicle electronic control unit

Abstract

The invention discloses a method and equipment for upgrading a vehicle electronic control unit. The method comprises the following steps: receiving an original upgrade configuration introduced when an application layer initiates a flash task, loading a corresponding project configuration file based on the original upgrade configuration, and declaring a preposed analysis node for defining a rule of converting different standard original upgrade configurations into standard instance data in the project configuration file; the front analysis node is executed, the original upgrading configuration is converted into a standard instance data set according to an analysis conversion rule, an upgrading configuration file is generated based on the instance data set, and the upgrading configuration file serves as upgrading configuration input of the configuration file flashing process of the vehicle electronic control unit so as to complete upgrading of the vehicle electronic control unit.

Description

Technical Field

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

[0002] With the rapid development of automotive electronics technology, the Electronic Control Unit (ECU) has become the core control component of various vehicle systems. ECU software flashing is a crucial step in vehicle manufacturing, after-sales maintenance, and functional upgrades. Due to the different technical systems of OEMs and component suppliers within the industry, there are significant differences in the format and field definitions of upgrade configuration files. Furthermore, ECU flashing covers multiple scenarios, including production line programming, cloud-based OTA upgrades, and offline diagnostic tool flashing, placing higher demands on the universality and adaptability of upgrade configuration file processing.

[0003] There are currently two main technical approaches to vehicle ECU remapping: one is to use hard-coded, dedicated tools for specific vehicle models or ECUs, deeply coupling the remapping process with the upgrade configuration file format; the other is to describe the remapping process using configurable scripts, which, while separating the process logic from specific parameters to some extent, still hardcodes the upgrade package instance information directly into the script. Both methods require developing dedicated processing logic for upgrade configuration files of specific standards, making it impossible to achieve universal parsing and processing of heterogeneous upgrade configuration files from different standards.

[0004] The existing technology not only significantly increases the development and maintenance costs of the flashing system and extends the flashing adaptation cycle for new car models and new ECUs, but also leads to a rigid architecture of the flashing system, poor scalability, and the inability to effectively reuse the processing logic under different flashing scenarios. Even if the flashing process has been standardized, the problem of heterogeneous upgrade configuration has not been solved. Summary of the Invention

[0005] To address the aforementioned issues, this application provides a method and apparatus for upgrading vehicle electronic control units, aiming to solve the problem of heterogeneous upgrade configurations.

[0006] The embodiments of this application disclose the following technical solutions: In a first aspect, embodiments of this application provide a method for upgrading a vehicle electronic control unit, the method comprising: Receive the original upgrade configuration when the application layer initiates a flashing task; The corresponding project configuration file is loaded according to the original upgrade configuration; the project configuration file declares a pre-parsing node, which is used to define the parsing and conversion rules for converting original upgrade configurations of different standards into standard instance data; The preceding parsing node is executed to convert the original upgrade configuration into a standard set of instance data according to the parsing and conversion rules. An upgrade configuration file is generated based on the instance data set; wherein, the upgrade configuration file serves as the upgrade configuration input for the vehicle electronic control unit configuration file flashing process, so as to realize the upgrade of the vehicle electronic control unit.

[0007] In one possible implementation, the type of the preceding parsing node is declared as either a built-in parsing type or a plugin parsing type; The execution of the pre-parsing node includes: If the preceding parsing node is a built-in parsing type, the built-in parser is called to extract the upgrade configuration data in the original upgrade configuration according to the parsing conversion rules, and then converts and generates the instance data set. If the preceding parsing node is a plugin parsing type, the external parsing plugin specified by the preceding parsing node is invoked to process the original upgrade configuration according to the parsing conversion rules, and the instance data set is output.

[0008] In one possible implementation, the invocation of the built-in parser extracts the upgrade configuration data from the original upgrade configuration according to the parsing and transformation rules, transforms it, and generates the instance data set, including: The built-in parser is invoked to perform format parsing and data verification on the original upgrade configuration. According to the UDS service field definition and the preset field mapping relationship of the parsing and transformation rules, the extracted upgrade configuration data is encapsulated into a key-value pair structure corresponding to the standardized field names; Based on the content of the upgrade file pointed to by the original upgrade configuration, and in conjunction with the UDS specification, a flashing step flow consistent with the step format in the project configuration file is generated; the content of the upgrade file is a preset standard format; The key-value pair structure and the brushing step stream are used as the standard instance data set.

[0009] In one possible implementation, the step of invoking the external parsing plugin specified by the preceding parsing node to process the original upgrade configuration according to the parsing conversion rules includes: The execution path of the external parsing plugin is located according to the preset rules in the project configuration file; Synchronize the file path and parsing / conversion rules of the original upgrade configuration to the external parsing plugin; The external parsing plugin is invoked to execute the parsing and conversion rules to process the original upgrade configuration; The parsing and transformation rules are used to output the set of instance data that conforms to the preset data structure.

[0010] In one possible implementation, the method further includes: 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; Iterate through multiple flushing steps in the project configuration file, and based on the association relationship in the variable set, replace the variable references in each flushing step with the instance data to obtain the multiple flushing steps after replacement. The replaced multiple flashing steps are used as executable flashing tasks.

[0011] In one possible implementation, the instance data set includes at least vehicle electronic control unit communication addressing information, software version identifier to be flashed, and flashing mode parameters.

[0012] In one possible implementation, the instance data set further includes a brushing step sequence; each step in the brushing step sequence is defined including a step type, a service identifier, and a step parameter object; the key-value pairs in the step parameter object are used to provide values ​​for variable placeholders in the unified diagnostic service definition corresponding to the service identifier.

[0013] In one possible implementation, the parsing and conversion rules include at least the following parameter items: communication configuration parameters, vehicle electronic control unit name parameters, physical addressing source address parameters, and physical addressing target address parameters; the parameter values ​​of each parameter item support variable referencing.

[0014] Secondly, embodiments of this application disclose an upgrade device for a vehicle electronic control unit, the device comprising: The receiving module is used to receive the mapping configuration and original upgrade configuration passed in when the application layer initiates a flashing task; The loading module is used to load the corresponding project configuration file according to the mapping configuration; the project configuration file declares a pre-parsing node, which is used to define the parsing and conversion rules for converting the original upgrade configurations of different standards into standard instance data; The conversion module is used to execute the pre-parsing node and convert the original upgrade configuration into a standard set of instance data according to the parsing and conversion rules; The generation module is used to generate an upgrade configuration file based on the instance data set; wherein the upgrade configuration file serves as the upgrade configuration input for the vehicle electronic control unit configuration file flashing process, so as to realize the upgrade of the vehicle electronic control unit.

[0015] In one possible implementation, the type of the preceding parsing node is declared as either a built-in parsing type or a plugin parsing type; The conversion module is specifically used to: if the preceding parsing node is a built-in parsing type, call the built-in parser to extract the upgrade configuration data in the original upgrade configuration according to the parsing conversion rules, convert and generate the instance data set; if the preceding parsing node is a plugin parsing type, call the external parsing plugin specified by the preceding parsing node to process the original upgrade configuration according to the parsing conversion rules, and output the instance data set.

[0016] In one possible implementation, the conversion module is specifically used to call the built-in parser to perform format parsing and data verification on the original upgrade configuration; according to the UDS service field definition and the preset field mapping relationship of the parsing and conversion rules, the extracted upgrade configuration data is encapsulated into a key-value pair structure corresponding to the standardized field names; based on the content of the upgrade file pointed to by the original upgrade configuration, a flashing step flow consistent with the step format in the project configuration file is generated in combination with the UDS specification; the content of the upgrade file is a preset standard format; and the key-value pair structure and the flashing step flow are used as the standard instance data set.

[0017] In one possible implementation, the conversion module 203 is specifically used to locate the execution path of the external parsing plugin according to the preset rules of the project configuration file; synchronize the file path and parsing conversion rules of the original upgrade configuration to the external parsing plugin; call the external parsing plugin to execute the parsing conversion rules to process the original upgrade configuration; and output the instance data set that conforms to the preset data structure according to the parsing conversion rules.

[0018] In one possible implementation, the device further includes an upgrade module, which is further configured 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; traverse multiple flashing steps in the project configuration file, and based on the association relationship in the variable set, replace the variable references in each flashing step with the instance data to obtain the multiple flashing steps after replacement; and use the multiple flashing steps after replacement as an executable flashing task.

[0019] In one possible implementation, the instance data set includes at least vehicle electronic control unit communication addressing information, software version identifier to be flashed, and flashing mode parameters.

[0020] In one possible implementation, the instance data set further includes a brushing step sequence; each step in the brushing step sequence is defined including a step type, a service identifier, and a step parameter object; the key-value pairs in the step parameter object are used to provide values ​​for variable placeholders in the unified diagnostic service definition corresponding to the service identifier.

[0021] In one possible implementation, the parsing and conversion rules include at least the following parameter items: communication configuration parameters, vehicle electronic control unit name parameters, physical addressing source address parameters, and physical addressing target address parameters; the parameter values ​​of each parameter item support variable referencing.

[0022] 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 upgrade method of the vehicle electronic control unit as described in any of the first aspects.

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

[0024] This application provides a method and apparatus for upgrading a vehicle electronic control unit (ECU). The method receives an initial upgrade configuration passed in when an application layer initiates a flashing task. Based on this initial upgrade configuration, a corresponding project configuration file is loaded. The project configuration file declares a pre-parsing node that defines rules for converting different standard initial upgrade configurations into standard instance data. The pre-parsing node is executed, and the initial upgrade configuration is converted into a standard instance data set according to the parsing conversion rules. Then, an upgrade configuration file is generated based on this instance data set. This upgrade configuration file serves as the upgrade configuration input for the vehicle ECU configuration file flashing process, thereby completing the upgrade of the vehicle ECU.

[0025] This application embodiment defines unified parsing and conversion rules through the pre-parsing nodes declared in the project configuration file. This enables the unified conversion of original upgrade configurations of different standards into standard instance datasets and the merging of them to generate corresponding upgrade configuration files. This decouples heterogeneous original upgrade configurations from the flashing process, eliminating the need to develop separate adaptation logic for original upgrade configurations of different standards. This significantly improves the adaptability and flexibility of the flashing process to original upgrade configurations of different formats. At the same time, the standardized parsing and conversion process ensures the standardization of the upgrade configuration files, providing reliable upgrade configuration input for the vehicle electronic control unit configuration file flashing process, ensuring the smooth execution of the flashing process, and reducing the flashing adaptation cost caused by differences in the original upgrade configuration format. Attached Figure Description

[0026] 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.

[0027] Figure 1 A flowchart illustrating a method for upgrading a vehicle electronic control unit provided in an embodiment of this application; Figure 2 This is a schematic diagram of the structure of an upgrade device for a vehicle electronic control unit provided in an embodiment of this application. Detailed Implementation

[0028] As described above, with the rapid development of automotive electronics technology towards multi-model and customized directions, ECU models and software versions are becoming increasingly diverse. ECU software flashing has become a core part of vehicle production and after-sales maintenance, which places higher demands on the standardization, reusability, and scalability of flashing tools, directly affecting vehicle production efficiency and maintenance costs.

[0029] Currently, there are two main technical approaches to ECU flashing in the industry: one is to use dedicated hard-coded tools for specific car models or ECUs, which deeply bind the flashing process to specific instance information; the other is to use configurable scripts to describe the flashing steps, attempting to separate the process logic from the parameters, but still still relying on specific data.

[0030] Hard-coded tools have poor reusability, require source code modification to adapt to new scenarios, have long development cycles and rigid architectures; while configurable scripts have improved, the process and instance data are still tightly coupled, templates cannot be directly reused, and there is a lack of ability to handle heterogeneous upgrade packages under different vendors and protocols. Either the upgrade package needs to be pre-formatted, or a separate script needs to be developed for each format, ultimately returning to the hard-coded dilemma, making it difficult to simultaneously meet the needs of standardized reuse of the flashing process and flexible expansion of heterogeneous scenarios.

[0031] To address this technical problem, this application provides a method and apparatus for upgrading a vehicle electronic control unit (ECU). The method receives the original upgrade configuration passed in when the application layer initiates a flashing task. Based on this original upgrade configuration, a corresponding project configuration file is loaded. The project configuration file declares a pre-parsing node that defines the conversion rules from different standard original upgrade configurations to standard instance data. The pre-parsing node is executed, and the original upgrade configuration is converted into a standard instance data set according to the parsing conversion rules. Then, an upgrade configuration file is generated based on this instance data set. This upgrade configuration file serves as the upgrade configuration input for the vehicle ECU configuration file flashing process, thereby completing the upgrade of the vehicle ECU.

[0032] This application embodiment defines unified parsing and conversion rules through the pre-parsing nodes declared in the project configuration file. This enables the unified conversion of original upgrade configurations of different standards into standard instance datasets and the merging of them to generate corresponding upgrade configuration files. This decouples heterogeneous original upgrade configurations from the flashing process, eliminating the need to develop separate adaptation logic for original upgrade configurations of different standards. This significantly improves the adaptability and flexibility of the flashing process to original upgrade configurations of different formats. At the same time, the standardized parsing and conversion process ensures the standardization of the upgrade configuration files, providing reliable upgrade configuration input for the vehicle electronic control unit configuration file flashing process, ensuring the smooth execution of the flashing process, and reducing the flashing adaptation cost caused by differences in the original upgrade configuration format.

[0033] The method provided in this application embodiment can be widely adapted to three core scenarios: vehicle manufacturing, after-sales maintenance, and cloud OTA upgrades. It relies on hardware devices such as production line workstation mainframes, portable diagnostic instruments, cloud servers, and vehicle communication modules to achieve efficient flashing.

[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 upgrading a vehicle electronic control unit, provided in an embodiment of this application. The method can be executed by a server, desktop computer, or other electronic device capable of computation. The following description uses an electronic device as the executing entity, and the method includes: S101: The electronic device receives the original upgrade configuration when the application layer initiates a flashing task.

[0036] The application layer refers to the specific application scenario carrier that initiates the flashing task, including terminals or systems with the ability to trigger flashing tasks, such as vehicle diagnostic tools, vehicle-side OTA applications, and production line testing tools.

[0037] The original upgrade configuration is a configuration data file that has not undergone standardized processing and is passed in when the application layer initiates the flashing task. It includes instance information related to the ECU to be flashed, and its format may vary depending on the supplier, communication protocol, or business scenario.

[0038] The application layer initiates a flashing task based on actual flashing requirements and inputs the original upgrade configuration. The original upgrade configuration includes core instance information such as the ECU to be flashed (e.g., name, diagnostic address), the target version after flashing, and upgrade package parameters. For example, in a production line scenario, the application layer (production line testing tool) automatically generates the original upgrade configuration, including ECU instance information, after reading the QR code of the ECU to be installed using a barcode scanner. In an after-sales scenario, repair personnel manually import or download the original upgrade configuration for the corresponding vehicle model using a diagnostic tool (application layer).

[0039] S102: The electronic device loads the corresponding project configuration file according to the original upgrade configuration.

[0040] The project configuration file declares a pre-parse node, which is used to define the parsing and transformation rules for converting the original upgrade configurations of different standards into standard instance data.

[0041] The project configuration file is a standardized flashing process template decoupled from specific instance data. It can be written in a structured format, including pre-parsing nodes and flashing step sequences, to standardize the execution logic of the flashing process. Pre-parsing nodes are pre-defined rule declaration units in the project configuration file, specifically used to define parsing and transformation rules, enabling the conversion of different standard original upgrade configurations to unified standard instance data.

[0042] The parsing and conversion rules refer to the standardized conversion logic defined in the front-end parsing node, which includes at least communication configuration parameters, vehicle electronic control unit name parameters, physical address source address parameters, and physical address target address parameters. The parameter values ​​of each parameter item can be dynamically filled through variable references.

[0043] Variable references refer to placeholders for parameter items in the parsing transformation rules (such as ${params.paSa}). Their specific values ​​are provided by the corresponding instance data in the original upgrade configuration file and will take effect after subsequent replacement.

[0044] In this embodiment, after receiving the original upgrade configuration file, the electronic device extracts key identification information such as vehicle model, ECU, and upgrade package type from the file and queries a preset configuration mapping table based on these identifiers. This mapping table predefines the correspondence between different types of original upgrade configurations and project configuration files, ensuring that the loaded project configuration file can adapt to the current flashing requirements. For example, if the vehicle model corresponding to the original upgrade configuration is "XXX" and the ECU name is "FSWM", the electronic device will locate and load a project configuration file specifically designed for that vehicle model and ECU through the mapping table.

[0045] In the loaded project configuration file, the pre-parsing node explicitly declares the parsing and conversion rules. These rules include at least the passing of common parameters: ECU name parameter, physical address source address parameter, and physical address target address parameter, with each parameter item presented as a variable reference. These variable references correspond one-to-one with the instance data fields in the original upgrade configuration file. For example, the physical address source address parameter reference is ${params.paSa}, which corresponds to "0x77C" recorded in the original upgrade configuration; the communication configuration parameter reference is ${params.commConfig}, corresponding to the communication protocol and parameter settings in the original upgrade configuration, providing a clear rule basis for subsequent standardized conversion.

[0046] S103: The electronic device executes the front-end parsing node to convert the original upgrade configuration into a standard set of instance data according to the parsing and conversion rules.

[0047] In this embodiment, the type of the pre-parsing node is declared as either an internal parsing type or a plugin parsing type. After the electronic device loads the project configuration file, it first identifies whether the type of the pre-parsing node is internal or plugin.

[0048] In one possible implementation, if the preceding parsing node is a built-in parsing type, the built-in parser is called to extract the upgrade configuration data in the original upgrade configuration according to the parsing conversion rules, and then converts and generates an instance data set.

[0049] Specifically, if it is a built-in parsing type, the electronic device calls its own built-in parser to directly read the field data in the original upgrade configuration file, and extracts core data such as ECU communication addressing information (e.g., physical addressing source address is "0x77C", physical addressing target address is "0x774"), software version identifier to be flashed (e.g., version number "8B200-3DZ-H010"), and flashing mode parameters (e.g., "ForcedFlash":false, "Anti-Downgrade":false).

[0050] In one possible implementation, if the preceding parsing node is a plugin parsing type, the external parsing plugin specified by the preceding parsing node is called to process the original upgrade configuration according to the parsing conversion rules and output the instance data set.

[0051] Specifically, if it's a plugin-based parsing type, the electronic device locates and calls the specified external parsing plugin according to the rules in the plugin configuration area of ​​the project configuration file. This plugin executes dedicated processing logic for the original upgrade configuration in a specific format, completing decryption, decompression, or format conversion, and then extracting the three types of core data mentioned above, as well as other extended data. Regardless of whether built-in parsing or plugin parsing is used, the electronic device will encapsulate the extracted valid data according to a unified structure, forming a standard set of instance data to ensure that the data format is standardized and the fields are complete.

[0052] This application further refines the execution flow of the built-in parser. Through the collaborative operation of format verification, standardized field encapsulation and brushing step flow generation, it ensures that the instance data set not only conforms to the unified specification, but also directly supports the efficient execution of the subsequent brushing process.

[0053] In one possible implementation, the invocation of the built-in parser extracts the upgrade configuration data from the original upgrade configuration according to the parsing and transformation rules, transforms it, and generates the instance data set, including: The electronic device calls the built-in parser to parse and verify the original upgrade configuration. According to the preset field mapping relationship of the UDS service field definition and parsing conversion rules, the extracted upgrade configuration data is encapsulated into a key-value pair structure corresponding to the standardized field names. Based on the content of the upgrade file pointed to by the original upgrade configuration, and combined with the UDS specification, a flashing step flow consistent with the step format in the project configuration file is generated. The content of the upgrade file is in a preset standard format. The key-value pair structure and the flashing step flow are used as a standard instance data set.

[0054] In this embodiment, when the current parsing node is a built-in parsing type, the electronic device calls the built-in parser to execute the standardized conversion process of the original upgrade configuration. First, the electronic device performs format parsing and data verification on the original upgrade configuration to ensure that the file format conforms to the basic specifications and that the data is complete and error-free, providing a reliable foundation for subsequent conversion. Then, based on the UDS service field definitions and the preset field mapping relationships in the parsing and conversion rules, the electronic device encapsulates the extracted upgrade configuration data (such as ECU communication addressing information, software version identifier to be flashed, flashing mode parameters, etc.) into key-value pair structures corresponding to standardized field names. For example, it maps "physical address source" in the original data to the standardized field "physical addressing source address" and forms the key-value pair "physical addressing source address": "0x77C". Simultaneously, the built-in parser reads the contents of the upgrade file (pre-set to a standard format) pointed to by the original upgrade configuration and, combined with the UDS specifications, generates a flashing step flow consistent with the step format in the project configuration file. This step flow is a universal flashing process that can be replaced with specific instructions for different projects based on the instructions defined in the project configuration file. A specific example is as follows: [ { "tag":"write_fingerprint", "params":{ "ts_str":"260305", "serial":"FFFFFFFFFFFF" } }, { "tag":"addr_erase", "params":{ "addr_length":"4", "length_length":"4", "erase_addr":"", "erase_length":"" } }, { "tag":"__flash34", "length": data_length, "title":f"{dataFormatIdentifier}{addr_length:X}{length_length:X}{start_addr:08X}{data_length:08X}", "data":flash_data.hex() }, { "tag":"check_crc", "params":{ "crc":"" } } ] This application further refines the execution logic under the plugin parsing type. Through standardized plugin positioning, parameter passing and parsing execution process, it ensures that external parsing plugins can accurately adapt to parsing and conversion rules and efficiently output standardized instance data sets.

[0055] In one possible implementation, the external parsing plugin specified by the preceding parsing node is invoked to process the original upgrade configuration according to the parsing transformation rules, including: The electronic device locates the execution path of the external parsing plugin according to the preset rules in the project configuration file; synchronizes the file path and parsing conversion rules of the original upgrade configuration to the external parsing plugin; calls the external parsing plugin to execute the parsing conversion rules to process the original upgrade configuration; and outputs a set of instance data that conforms to the preset data structure according to the parsing conversion rules.

[0056] After the electronic device determines that the preceding parsing node is a plugin parsing type, it first locates the execution path of the external parsing plugin according to the preset rules in the plugin configuration area of ​​the project configuration file. The preset rules clarify the plugin's base search directory and path traversal logic, ensuring that the external parsing plugin specified by the preceding parsing node can be found quickly and accurately, avoiding call failures due to plugin path confusion.

[0057] Subsequently, the electronic device synchronizes the original upgrade configuration file path and complete parsing and conversion rules to the external parsing plugin. The file path is used by the plugin to read the original upgrade configuration data, while the parsing and conversion rules specify the core parameter items to be extracted, field mapping relationships, and data format requirements, ensuring that the plugin parsing has clear rule guidelines.

[0058] After receiving the parameters, the external parsing plugin initiates its dedicated processing logic. If the original upgrade configuration is in encrypted format, decryption is performed first; if it is in compressed format or a manufacturer-defined structure format, preprocessing such as decompression and format conversion is performed before extracting the upgrade configuration data according to the parsing and conversion rules. During the parsing process, the plugin strictly follows the field mapping relationships in the rules, encapsulates the extracted data as required, and finally outputs a set of instance data containing core content such as ECU communication addressing information, the version identifier of the software to be flashed, and flashing mode parameters according to the preset data structure. This ensures that the set is completely consistent with the data structure generated by the built-in parser, guaranteeing a smooth transition in subsequent processes.

[0059] In one possible implementation, the instance data set also includes a flushing step sequence. Each step definition in the flushing step sequence includes a step type, a service identifier, and a step parameter object. The key-value pairs in the step parameter object are used to provide values ​​for variable placeholders in the service definition of the unified diagnostic service corresponding to the service identifier.

[0060] The write-through sequence is a core component of the instance data set, forming a complete standardized data input together with other parsed and transformed instance data. Each step definition includes a step type specifying the execution method, a service identifier corresponding to the specific service in the unified diagnostic service, and a step parameter object storing the specific parameter data required by the service in key-value pairs.

[0061] S104: The electronic device determines the upgrade configuration file based on the instance data set.

[0062] The upgrade configuration file is a structured configuration file based on a standard instance dataset, directly usable in the ECU flashing process. It includes all the core parameters and execution logic required for flashing and is a key input to the flashing process. The upgrade configuration file serves as the upgrade configuration input for the vehicle's electronic control unit (ECU) configuration file flashing process, enabling the upgrade of the ECU.

[0063] After obtaining the standard set of instance data, the electronic device initiates the upgrade configuration file generation process according to a unified preset format. This preset format has predefined the arrangement order, naming conventions, and structural hierarchy of data fields, including core modules such as physical address, ECU name, vehicle model information, timeout threshold, anti-downgrade flag, forced flashing flag, serial number, upgrade information (version number, part number), and flashing step sequence (uds_order).

[0064] The electronic device extracts each data item from the instance dataset and fills it into the corresponding fields according to the format requirements. Communication addressing information such as "Physical Address Source Address": "0x77C" and "Physical Address Target Address": "0x774" are filled into the basic configuration area; version information such as "version": "8B200-3DZ-H010" and "partNum": "38890GPFH010M1" are filled into the upgrade information area. The complete sequence of flashing steps, including id, type, service identifier, and parameter objects, is embedded into the uds_order field, ensuring that the step parameters accurately correspond to the variable placeholders in the UDS service definition. During the generation process, the electronic device verifies the data integrity and format validity to ensure that no fields are missing and the parameter format conforms to the flashing protocol requirements, ultimately forming a complete and standardized upgrade configuration file.

[0065] Based on the above embodiments, the present application further provides a process for ECU upgrade based on the upgrade configuration file. By parsing the associated variable references and instance data of the upgrade configuration file, parameters are dynamically filled during the flashing step, thereby achieving deep decoupling between the flashing process and the instance data.

[0066] In one possible implementation, the method further includes: Parse the upgrade configuration file to generate a variable set; traverse multiple flashing steps, and when executing the current flashing step, retrieve the instance data corresponding to the variable reference of the current flashing step from the variable set, and dynamically replace the variable reference in the step parameters; execute the operation corresponding to the current flashing step based on the replaced step parameters.

[0067] In this embodiment, the electronic device parses the upgrade configuration file to generate a variable set, and the variable set is associated with variable references and the instance data. The electronic device first parses the upgrade configuration file to generate a variable set that associates variable references with the instance data.

[0068] Subsequently, the electronic device traverses multiple flashing steps in the order defined by the workflow. When executing the current flashing step, it first scans the step parameters of that step and identifies all variable references. Based on the relationships within the variable set, the electronic device accurately extracts the instance data corresponding to the current variable reference from the variable set and dynamically replaces the variable references in the step parameters with the specific instance data.

[0069] After the variable reference replacement is completed, the electronic device performs the operation corresponding to the current flashing step based on the replaced complete step parameters.

[0070] By generating variable sets that associate variable references with instance data, the flashing process template and specific instance data are completely decoupled. The same project configuration file can quickly adapt to the flashing requirements of different vehicle models and ECUs by matching different variable sets, without modifying the process logic, significantly improving the reusability of the flashing process. The dynamic replacement mechanism during flashing step execution ensures that step parameters can match the current ECU instance information in real time, avoiding the adaptation limitations caused by fixed parameters, while reducing the number of manual intervention steps in parameter configuration and lowering the risk of flashing failure due to human input errors.

[0071] Based on the above embodiments, this application also provides an upgrade device for a vehicle electronic control unit, such as... Figure 2 As shown, the device includes: The receiving module 201 is used to receive the mapping configuration and the original upgrade configuration passed in when the application layer initiates the flashing task; The loading module 202 is used to load the corresponding project configuration file according to the mapping configuration; the project configuration file declares a pre-parsing node, which is used to define the parsing and conversion rules for converting the original upgrade configurations of different standards into standard instance data; The conversion module 203 is used to execute the pre-parsing node and convert the original upgrade configuration into a standard instance data set according to the parsing and conversion rules; The generation module 204 is used to generate an upgrade configuration file based on the instance data set; wherein the upgrade configuration file serves as the upgrade configuration input for the vehicle electronic control unit configuration file flashing process, so as to realize the upgrade of the vehicle electronic control unit.

[0072] In one possible implementation, the type of the preceding parsing node is declared as either a built-in parsing type or a plugin parsing type; The conversion module 203 is specifically used to: if the preceding parsing node is a built-in parsing type, call the built-in parser to extract the upgrade configuration data in the original upgrade configuration according to the parsing conversion rules, convert and generate the instance data set; if the preceding parsing node is a plugin parsing type, call the external parsing plugin specified by the preceding parsing node to process the original upgrade configuration according to the parsing conversion rules, and output the instance data set.

[0073] In one possible implementation, the conversion module 203 is specifically used to call the built-in parser to perform format parsing and data verification on the original upgrade configuration; according to the UDS service field definition and the preset field mapping relationship of the parsing and conversion rules, the extracted upgrade configuration data is encapsulated into a key-value pair structure corresponding to the standardized field names; based on the content of the upgrade file pointed to by the original upgrade configuration, a brushing step flow consistent with the step format in the project configuration file is generated in combination with the UDS specification; the content of the upgrade file is a preset standard format; and the key-value pair structure and the brushing step flow are used as the standard instance data set.

[0074] In one possible implementation, the conversion module 203 is specifically used to locate the execution path of the external parsing plugin according to the preset rules of the project configuration file; synchronize the file path and parsing conversion rules of the original upgrade configuration to the external parsing plugin; call the external parsing plugin to execute the parsing conversion rules to process the original upgrade configuration; and output the instance data set that conforms to the preset data structure according to the parsing conversion rules.

[0075] In one possible implementation, the device further includes an upgrade module, which is further configured 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; traverse multiple flashing steps in the project configuration file, and based on the association relationship in the variable set, replace the variable references in each flashing step with the instance data to obtain the multiple flashing steps after replacement; and use the multiple flashing steps after replacement as an executable flashing task.

[0076] In one possible implementation, the instance data set includes at least vehicle electronic control unit communication addressing information, software version identifier to be flashed, and flashing mode parameters.

[0077] In one possible implementation, the instance data set further includes a brushing step sequence; each step in the brushing step sequence is defined including a step type, a service identifier, and a step parameter object; the key-value pairs in the step parameter object are used to provide values ​​for variable placeholders in the unified diagnostic service definition corresponding to the service identifier.

[0078] In one possible implementation, the parsing and conversion rules include at least the following parameter items: communication configuration parameters, vehicle electronic control unit name parameters, physical addressing source address parameters, and physical addressing target address parameters; the parameter values ​​of each parameter item support variable referencing.

[0079] This application also provides a control device. The control device may include a memory and a processor. The processor is used to execute the vehicle electronic control unit upgrade method 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.

[0080] Memory can store computer instructions, which, when executed by a processor, can be used to implement upgrade methods for the vehicle's electronic control unit. Memory can also store data.

[0081] 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)).

[0082] 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.

[0083] 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.

[0084] 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.

[0085] 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 upgrading a vehicle electronic control unit, characterized in that, The method includes: Receive the original upgrade configuration when the application layer initiates a flashing task; The corresponding project configuration file is loaded according to the original upgrade configuration; the project configuration file declares a pre-parsing node, which is used to define the parsing and conversion rules for converting original upgrade configurations of different standards into standard instance data; The preceding parsing node is executed to convert the original upgrade configuration into a standard set of instance data according to the parsing and conversion rules. An upgrade configuration file is generated based on the instance data set; wherein, the upgrade configuration file serves as the upgrade configuration input for the vehicle electronic control unit configuration file flashing process, so as to realize the upgrade of the vehicle electronic control unit.

2. The method according to claim 1, characterized in that, The type of the preceding parsing node is declared as either a built-in parsing type or a plugin parsing type; The execution of the pre-parsing node includes: If the preceding parsing node is a built-in parsing type, the built-in parser is called to extract the upgrade configuration data in the original upgrade configuration according to the parsing conversion rules, and then converts and generates the instance data set. If the preceding parsing node is a plugin parsing type, the external parsing plugin specified by the preceding parsing node is invoked to process the original upgrade configuration according to the parsing conversion rules, and the instance data set is output.

3. The method according to claim 2, characterized in that, The process of calling the built-in parser to extract upgrade configuration data from the original upgrade configuration according to the parsing and transformation rules, transforming it, and generating the instance data set includes: The built-in parser is invoked to perform format parsing and data verification on the original upgrade configuration. According to the UDS service field definition and the preset field mapping relationship of the parsing and transformation rules, the extracted upgrade configuration data is encapsulated into a key-value pair structure corresponding to the standardized field names; Based on the content of the upgrade file pointed to by the original upgrade configuration, and in conjunction with the UDS specification, a flashing step flow consistent with the step format in the project configuration file is generated; the content of the upgrade file is a preset standard format; The key-value pair structure and the brushing step stream are used as the standard instance data set.

4. The method according to claim 2, characterized in that, The process of calling the external parsing plugin specified by the preceding parsing node to process the original upgrade configuration according to the parsing conversion rules includes: The execution path of the external parsing plugin is located according to the preset rules in the project configuration file; Synchronize the file path and parsing / conversion rules of the original upgrade configuration to the external parsing plugin; The external parsing plugin is invoked to execute the parsing and conversion rules to process the original upgrade configuration; The parsing and transformation rules are used to output the set of instance data that conforms to the preset data structure.

5. The method according to claim 1, characterized in that, The method further includes: 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; Iterate through multiple flushing steps in the project configuration file, and based on the association relationship in the variable set, replace the variable references in each flushing step with the instance data to obtain the multiple flushing steps after replacement. The replaced multiple flashing steps are used as executable flashing tasks.

6. The method according to claim 1, characterized in that, The instance data set includes at least the vehicle electronic control unit communication addressing information, the software version identifier to be flashed, and flashing mode parameters.

7. The method according to claim 6, characterized in that, The instance data set also includes a brushing step sequence; each step in the brushing step sequence is defined including a step type, a service identifier, and a step parameter object; the key-value pairs in the step parameter object are used to provide values ​​for variable placeholders in the unified diagnostic service definition corresponding to the service identifier.

8. The method according to claim 1, characterized in that, The parsing and conversion rules include at least the following parameters: communication configuration parameters, vehicle electronic control unit name parameters, physical address source address parameters, and physical address target address parameters; the parameter values ​​of each parameter item support variable referencing.

9. A configuration file processing device for upgrading a vehicle electronic control unit, characterized in that, The device includes: The receiving module is used to receive the mapping configuration and original upgrade configuration passed in when the application layer initiates a flashing task; The loading module is used to load the corresponding project configuration file according to the mapping configuration; the project configuration file declares a pre-parsing node, which is used to define the parsing and conversion rules for converting the original upgrade configurations of different standards into standard instance data; The conversion module is used to execute the pre-parsing node and convert the original upgrade configuration into a standard set of instance data according to the parsing and conversion rules; The generation module is used to generate an upgrade configuration file based on the instance data set; wherein the upgrade configuration file serves as the upgrade configuration input for the vehicle electronic control unit configuration file flashing process, so as to realize the upgrade of the vehicle electronic control unit.

10. 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 upgrade method for the vehicle electronic control unit as described in any one of claims 1-8.

11. A computer-readable storage medium, characterized in that, The system contains a computer program that is loaded by a processor to execute the vehicle electronic control unit upgrade method as described in any one of claims 1-8.

Images