Address synchronization processing method and device, vehicle and medium
By employing a fully automated address synchronization method, the problem of low efficiency in synchronizing A2L and ELF files in automotive electronic control systems has been solved. This method achieves efficient and reliable address synchronization, supports batch processing and real-time progress feedback, and eliminates reliance on multiple tools and manual intervention.
Patent Information
- Application Number
- CN202511860554.3
- Authority / Receiving Office
- CN · China
- Patent Type
- Applications(China)
- Current Assignee / Owner
- Filing Date
- 2025-12-10
- Publication Date
- 2026-03-17
AI Technical Summary
In existing technologies, the address synchronization processing of A2L files and ELF files in the development of automotive electronic control systems suffers from fragmented processes and low efficiency. It requires multiple independent tools and suffers from data format incompatibility and frequent manual intervention.
This paper provides a fully automated address synchronization method. By obtaining the calibration data description A2L file and the executable ELF file, the variable information in the target script is extracted and processed. The actual address in the ELF file is integrated and synchronized to generate the target A2L file, eliminating the dependence on multiple tools and requiring no manual intervention.
It achieves high efficiency and reliability in address synchronization processing, solves the problems of process fragmentation and inefficiency, improves processing efficiency and reduces manual intervention, and supports batch processing of large-scale files and real-time progress feedback.
Smart Images

Figure CN121680346A_ABST
Abstract
Description
Technical Field
[0001] This application relates to the field of automotive development technology, specifically to an address synchronization processing method, apparatus, vehicle, and medium. Background Technology
[0002] In the field of automotive electronic control system development, the Automotive Open System Architecture (AUTOSAR) has become an industry-recognized software architecture standard. This software architecture standard requires that the variable addresses in the calibration data description A2L file and the executable (Executable and Linkable Format, ELF) file of the Electronic Control Unit (ECU) be strictly synchronized to ensure that calibration tools can accurately access and modify the parameter data of the ECU during operation.
[0003] However, existing technologies require the use of multiple independent commercial tools to complete the address extraction and synchronization of the A2L and ELF files. For example, compilers such as IAR, KeIL, or GHS are used to generate ELF files, and calibration tools such as CANape or INCA are used to perform address extraction and address synchronization in the A2L files. This results in serious process fragmentation and inefficiency.
[0004] Therefore, there is an urgent need to propose a better address synchronization processing scheme. Summary of the Invention
[0005] In view of this, the embodiments of this application aim to provide an address synchronization processing method, apparatus, vehicle and medium that can solve the technical problems of process fragmentation and low efficiency in the prior art.
[0006] Firstly, this application provides an address synchronization processing method, including: Obtain the calibration data description A2L file and the executable ELF file, wherein the A2L file includes the observation script, the calibration script, and other quantity scripts besides the observation script and the calibration script; The target script in the A2L file is subjected to variable extraction and processing to obtain the target variable information in the target script. The target variable information includes the variable address of the first variable. The target script includes the observation script, the calibration script, and the other quantity scripts in sequence. The variable address is extracted from the ELF file to obtain the actual address of the second variable in the ELF file; The A2L file is integrated and synchronized based on the actual address of the second variable in the ELF file and the variable address of the first variable in the target variable information to obtain the target A2L file.
[0007] In some embodiments, the step of extracting and processing variables from the target script in the A2L file to obtain target variable information in the target script includes: Variables are extracted from the target script in the A2L file to obtain the initial variable information in the target script; The initial variable information in the target script is formatted to obtain the target variable information. The formatting process includes at least one of numeric formatting, field formatting, and information repair.
[0008] In some embodiments, When the target script is the observation script, both the initial variable information and the target variable information are the corresponding feature code blocks in the observation script; or, When the target script is the calibration script, both the initial variable information and the target variable information are the corresponding measurement code blocks in the calibration script; or, When the target script is the other variable script, both the initial variable information and the target variable information are the corresponding tag code blocks in the other variable script.
[0009] In some embodiments, the process of integrating and synchronizing the A2L file based on the actual address of the second variable in the ELF file and the variable address of the first variable in the target variable information to obtain the target A2L file includes: Based on the actual address of the second variable in the ELF file, the address of the first variable in the target variable information is matched and replaced to obtain the replaced target variable information; The replaced target variable information is integrated into the A2L file to obtain the target A2L file.
[0010] In some embodiments, the step of matching and replacing the variable address of the first variable in the target variable information based on the actual address of the second variable in the ELF file to obtain the replaced target variable information includes: Based on the actual address of the second variable in the ELF file, address matching is performed on the target variable information to obtain the variable address of the second variable in the target variable information, wherein the first variable includes at least a portion of the second variable; Based on the actual address of the second variable in the ELF file, the variable address of the second variable in the target variable information is replaced to obtain the replaced target variable information.
[0011] In some embodiments, the method further includes at least one of the following: Record the address information of variables that are not matched in the ELF file and the target variable information; Display the target variable information and the replaced target variable information; Perform success rate statistics on address replacement of the second variable; Backup the A2L file; Generate and output the corresponding log file, which is used at least to indicate the progress of the address synchronization process.
[0012] In some embodiments, before performing variable extraction and processing on the target script in the A2L file, the method further includes: Check if the storage paths of the observation script, calibration script, and other quantity scripts in the A2L file exist. If so, continue with the steps of extracting and processing variables from the target script in the A2L file.
[0013] Secondly, this application provides an address synchronization processing apparatus, comprising: The acquisition module is used to acquire a calibration data description A2L file and an executable ELF file. The A2L file includes an observation script, a calibration script, and other quantity scripts besides the observation script and the calibration script. The processing module is used to extract and process variables from the target script in the A2L file to obtain target variable information in the target script. The target variable information includes the variable address of the first variable. The target script includes the observation script, the calibration script, and the other quantity scripts in sequence. The processing module is also used to extract variable addresses from the ELF file to obtain the actual address of the second variable in the ELF file; The processing module is also used to integrate and synchronize the A2L file based on the actual address of the second variable in the ELF file and the variable address of the first variable in the target variable information to obtain the target A2L file.
[0014] For any content not introduced or described in the embodiments of this application, please refer to the relevant descriptions in the foregoing method embodiments; they will not be repeated here.
[0015] Thirdly, this application provides a vehicle, including: a processor; a memory for storing processor-executable instructions; wherein the processor is configured to execute the executable instructions to implement the steps of the above-described address synchronization processing method.
[0016] Fourthly, this application provides a computer-readable storage medium storing computer program instructions thereon, which, when executed by a processor, implement the steps of the above-described address synchronization processing method.
[0017] The technical solution provided in this application embodiment can include the following beneficial effects: This application obtains a calibration data description A2L file and an executable ELF file. The A2L file includes an observation script, a calibration script, and other quantity scripts besides the observation script and the calibration script. Variable extraction and processing are performed on the target script in the A2L file to obtain target variable information in the target script. The target variable information includes the variable address of a first variable. The target script sequentially includes the observation script, the calibration script, and the other quantity scripts. Variable address extraction is performed on the ELF file to obtain the actual address of a second variable in the ELF file. Based on the actual address of the second variable in the ELF file and the variable address of the first variable in the target variable information, the A2L file is integrated and synchronized to obtain the target A2L file. This application develops a fully automated address synchronization processing scheme, eliminating the dependence on multiple tools and requiring no manual intervention. This improves the efficiency and reliability of address synchronization processing and solves the problems of process fragmentation and low efficiency in the prior art.
[0018] The above description is only an overview of the technical solution of this application. In order to better understand the technical means of this application and to implement it in accordance with the contents of the specification, and to make the above and other objects, features and advantages of this application more obvious and understandable, the following are specific embodiments of this application. Attached Figure Description
[0019] Various other advantages and benefits will become apparent to those skilled in the art upon reading the following detailed description of preferred embodiments. The accompanying drawings are for illustrative purposes only and are not intended to limit the scope of this application. Furthermore, the same reference numerals denote the same parts throughout the drawings.
[0020] Figure 1 This is a schematic diagram of the structure of an address synchronization processing system provided in an embodiment of this application.
[0021] Figure 2 This is a flowchart illustrating an address synchronization processing method provided in an embodiment of this application.
[0022] Figure 3 This is a schematic diagram of an address synchronization processing device provided in an embodiment of this application.
[0023] Figure 4 This is a schematic diagram of another address synchronization processing device provided in an embodiment of this application.
[0024] Figure 5 This is a structural schematic diagram of a vehicle provided in an embodiment of this application. Detailed Implementation
[0025] The technical solutions of the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this application, and not all embodiments. Based on the embodiments of this application, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of this application.
[0026] Unless otherwise defined, the technical or scientific terms used in the embodiments of this specification shall have the ordinary meaning understood by one of ordinary skill in the art to which this specification pertains. The terms "first," "second," and similar terms used in the embodiments of this specification do not indicate any order, quantity, or importance, but are merely used to avoid confusion of constituent elements.
[0027] Unless the context otherwise requires, throughout this specification, "a plurality of" means "at least two," and "including" is interpreted as open-ended or encompassing, that is, "including, but not limited to." In the description of this specification, terms such as "one embodiment," "some embodiments," "exemplary embodiment," "example," "specific example," or "some examples" are intended to indicate that a particular feature, structure, material, or characteristic associated with that embodiment or example is included in at least one embodiment or example of this specification. The illustrative representations of the above terms do not necessarily refer to the same embodiment or example.
[0028] Exemplary embodiments of the present application will now be described in more detail with reference to the accompanying drawings. While exemplary embodiments of the present application are shown in the drawings, it should be understood that the present application may be implemented in various forms and should not be limited to the embodiments set forth herein. Rather, these embodiments are provided so that this application will be thorough and complete, and will fully convey the scope of the present application to those skilled in the art.
[0029] In the process of filing this application, the applicant also discovered that: in the aforementioned prior art, because multiple tools may come from different manufacturers, there are problems such as incompatibility in data formats and interface protocols, which leads to frequent format conversions and manual intervention during data flow, resulting in insufficient automation. Furthermore, the various processing steps are independent of each other, lacking a unified scheduling and management mechanism, making it difficult to quickly locate and recover from errors when they occur.
[0030] To address the aforementioned problems, this application proposes an address synchronization processing method, apparatus, vehicle, and medium. Please refer to [link / reference]. Figure 1 This is a schematic diagram of the structure of an address synchronization processing system provided in an embodiment of this application. For example... Figure 1 The system 10 shown may include: an input unit 101, an identification unit 102, an intelligent scheduling unit 103, a data formatting unit 104, an address mapping unit 105, a batch processing execution unit 106, a data integration unit 107, a security backup unit 108, a log recording unit 109, and a status feedback unit 110. It should be noted that any two units in the figure can communicate / transmit data according to actual needs. The figure only shows some components of the address synchronization processing system; these components can be arbitrarily combined or separated according to actual needs, and this application does not constitute a limitation. The above system can also add or remove corresponding components according to actual needs, and this application will not impose further limitations or details on this.
[0031] The input unit 101 is primarily responsible for inputting calibration data description A2L files and executable ELF files, such as .a2l and merge.a2l debug configuration files, .elf program executable files, and other key files. The identification unit 102 is primarily responsible for code recognition of the A2L and ELF files, such as identifying file types, code block tags, abnormal code content, and observation scripts, calibration scripts, and other quantity scripts in the A2L files. This application does not impose further limitations on these aspects. The intelligent scheduling unit 103 is primarily responsible for task sorting and resource allocation. For example, it schedules the data formatting unit 104 and the batch processing execution unit 106 to sequentially process the observation scripts, calibration scripts, and other quantity scripts in the A2L files, and schedules corresponding memory resources for data storage or caching. This application does not impose further limitations or details on these aspects. The data formatting unit 104 is primarily responsible for data formatting, such as numerical formatting, field formatting, and repair of other data information. Its specific implementation will be detailed below in this application and will not be described here. The address mapping unit 105 is mainly responsible for extracting variable addresses, matching addresses, and mapping / replacing addresses in the ELF file. Its specific implementation will be detailed below and will not be described here. The batch processing execution unit 106 is mainly responsible for batch processing the A2L file (specifically, it can be the observation script, calibration script, and other quantity scripts within the A2L file), such as checking whether the storage path of the corresponding file or script is abnormal / exists, and performing variable extraction processing. Its specific implementation will be detailed below and will not be described here. The data integration unit 107 is mainly responsible for data integration, such as integrating the actual addresses of the corresponding variables in the ELF file processed by the address mapping unit 105 into the original A2L file to obtain a new target A2L file. The security backup unit 108 is mainly responsible for data backup, such as performing a security backup of the original A2L file to avoid data loss. The log recording unit 109 is mainly responsible for generating and recording corresponding log files, such as generating a progress log file to indicate the current progress of the entire address synchronization process. The aforementioned status feedback unit 110 is mainly responsible for data feedback, such as feedback on task execution progress, feedback on code execution exceptions or error information, or feedback on other custom data information, so as to provide the corresponding data to the user or other devices for use. This application will not make any further limitations or details in this regard.
[0032] Based on the above embodiments, please refer to Figure 2 This is a flowchart illustrating an address synchronization processing method provided in an embodiment of this application. Figure 2 The method shown may include the following implementation steps: S201. Obtain the calibration data description A2L file and the executable ELF file. The A2L file includes the observation script, the calibration script, and other quantity scripts besides the observation script and the calibration script.
[0033] In this application, the A2L file mentioned above can refer to a standard file used in the automotive electronics field to define data related to the calibration and measurement of electronic control units. The ELF file mentioned above can refer to an executable file in the Linux system that uses standard file formats such as binary files, object code, and shared libraries. The observation script mentioned above can refer to a code script containing observations within an A2L file, such as the observation.bat script. The calibration script mentioned above can refer to a code script containing calibration values within an A2L file, such as the calibration.bat script. The other quantity scripts mentioned above can refer to other code scripts within an A2L file besides the observation script and calibration script, such as the others.bat script, etc., and this application does not impose further limitations on them.
[0034] This application does not limit the implementation methods for obtaining the A2L file and the ELF file mentioned above. For example, they can be obtained directly from a local database, or they can be obtained from other devices (such as servers) through a network. This application will not limit or elaborate on these methods.
[0035] S202. Extract and process variables from the target script in the A2L file to obtain target variable information in the target script. The target variable information includes the variable address of the first variable. The target script includes the observation script, the calibration script, and the other quantity scripts in sequence.
[0036] The target variable information mentioned above in this application may include all the first variables in the target script and the variable addresses of those first variables. The type of the first variable varies depending on the type of target script. For example, when the target script is an observation script, the first variable may specifically be an observation, which can refer to measurement data obtained during the actual measurement process, such as battery temperature collected by a temperature sensor, motor speed of the motor controller, and input voltage of the vehicle power supply. When the target script is a calibration script, the first variable may specifically be a calibration quantity, which can refer to standard data used for verification or calibration during experiments or measurements, such as the fuel injection pulse width of the vehicle, the output torque limit value under different battery charge states, etc. When the target script is another quantity script, the first variable may specifically be other quantities besides the observation and calibration quantities, such as the speed axis, relevant calculation formulas related to the vehicle, etc. This application does not impose further limitations or details on these.
[0037] S203. Extract the variable address from the ELF file to obtain the actual address of the second variable in the ELF file.
[0038] In this application, the aforementioned second variable may refer to all or some variables in the ELF file, specifically an observation, a calibrated quantity, or other quantities, which this application does not limit in detail. The actual address of the aforementioned second variable may refer to the physical address or memory address of the second variable, which this application does not limit or elaborate on in detail.
[0039] S204. Based on the actual address of the second variable in the ELF file and the variable address of the first variable in the target variable information, the A2L file is integrated and synchronized to obtain the target A2L file.
[0040] This application can perform address matching and replacement based on the actual address of the second variable in the above ELF file and the variable address of the first variable in the above target variable information, and integrate them into the original A2L file to obtain a new target A2L file.
[0041] By implementing the embodiments of this application, this application obtains a calibration data description A2L file and an executable ELF file. The A2L file includes an observation script, a calibration script, and other quantity scripts besides the observation script and the calibration script. Variable extraction and processing are performed on the target script in the A2L file to obtain target variable information in the target script. The target variable information includes the variable address of a first variable. The target script sequentially includes the observation script, the calibration script, and the other quantity scripts. Variable address extraction is performed on the ELF file to obtain the actual address of a second variable in the ELF file. Based on the actual address of the second variable in the ELF file and the variable address of the first variable in the target variable information, the A2L file is integrated and synchronized to obtain the target A2L file. This application develops a fully automated address synchronization processing scheme, eliminating the dependence on multiple tools and requiring no manual intervention. This improves the efficiency and reliability of address synchronization processing and solves the problems of process fragmentation and inefficiency in the prior art.
[0042] The following describes some specific and optional embodiments related to this application.
[0043] Before step S201, this application can start the process and trigger the main function main() of the script file to start executing the process of this application. For example, the path is initialized first, specifically, the storage path on which the script involved in this application depends is defined, such as base_dir base directory, biasingl_dir standard directory and others_dir other directories, etc. Then, copy the aforementioned A2L and ELF files (specifically, .a2l and merge.a2l debug configuration files and .elf executable files) to the corresponding directories to run and execute the corresponding target scripts. For example, copy the .a2l and merge.a2l debug configuration files and .elf executable files to the base_dir directory, and run the observation script (e.g., observation.bat) in the base_dir directory; copy the .a2l and merge.a2l debug configuration files and .elf executable files to the biaodingl_dir calibration directory, and run the calibration script (e.g., calibration.bat) in the biaodingl_dir calibration directory; copy the .a2l and merge.a2l debug configuration files and .elf executable files to other directories in the others_dir directory, and run other quantity scripts (e.g., others.bat) in the other others_dir directories, etc. Specific implementation examples of the above scripts will be detailed below in this application. Understandably, if any of the above files fails to copy during the copying process, the system can automatically report an error and exit the current copying process. Similarly, if any of the above scripts encounters an exception or fails during execution, this application can also automatically report an error and exit the current script execution process, for example, by returning a non-zero fault code to prompt the user to check and locate the corresponding problem. This application does not impose further limitations or details on this.
[0044] Before step S202, this application also needs to set the storage path SCRIPT_PATH for the corresponding files or scripts, and then check whether the storage path exists. If it does not exist, this application can automatically report an error and exit / end the process. Specifically, for example, after obtaining the A2L file, this application can check whether the storage paths of the observation script, calibration script, and other quantity scripts in the A2L file exist. If they exist, step S202 can be continued; otherwise, if they do not exist, an error can be automatically reported and the current process can be exited. This application will not impose further limitations or details on this.
[0045] In step S202, this application does not limit the specific implementation of the above variable extraction and processing. For example, this application can first extract variables from the target script in the above A2L file to obtain the initial variable information in the target script; then, it can format the initial variable information in the target script to obtain the target variable information in the target script. This application does not limit the specific implementation of the above formatting processing. For example, it can include, but is not limited to, any combination of one or more of the following: numerical formatting, field formatting, data information repair, or other custom processing. The specific details of the above numerical formatting, field formatting, and data information repair will be described in detail below, and will not be elaborated on here. In practical applications, this application can use code 1 extract_meas.py to extract variables from the corresponding script, and then use code 2 format_meas.py to format the corresponding data information, etc. This application will not limit or elaborate on this. The above target script can sequentially include observation scripts, calibration scripts, and other quantity scripts. Several possible implementation methods are exemplarily described below.
[0046] In one implementation, the target script is a measurement script, and the initial variable information and target variable information can be corresponding feature code blocks. Specifically, this application can iteratively search and extract feature code blocks containing the ` / begin CHARACTERISTIC` start tag and the ` / end CHARACTERISTIC` end tag from the A2L file to ensure complete feature code extraction and avoid code omissions or truncation. If the feature code block is not found, a corresponding empty file can be generated for automatic error reporting and termination of the current process. Next, this application formats the feature code blocks, for example, in numerical formatting (convert_number), unifying zero values to 0, such as processing "0.000" as "0"; and using scientific notation, such as formatting extremely small values like 1e... -11 Processed to 1.0000e -11 Examples of data formatting techniques include: removing decimal places from integers (e.g., changing 123.0 to 123); removing extra zeros from decimals (e.g., changing 123.4500 to 123.45); generating FORMAT fields in field formatting (e.g., fixed mapping according to the RECORD_LAYOUT structure, such as mapping record_float32_ieee to %8.6); and dynamically generating axis descriptions according to numerical ranges (e.g., processing the range 0-1 as %1.0, the range 0-255 as %3.0). Data repair can also be performed, for example, correcting a DISPLAY field where the scientific notation exponent is 3 digits (e.g., 1e). -2 Repair processing is 1e -002; Generate LINK_MAP hexadecimal value, such as repairing lookup2d_float32_ieee to 0x87; retain reserved fields, such as retaining the MATRIX_DIM field, etc., this application will not impose too many restrictions or details on this.
[0047] In another implementation, the target script is a calibration script, and the initial variable information and target variable information can be corresponding measurement code blocks. Specifically, this application can iteratively search and extract measurement code blocks (MEASUREMENT) containing the start and end tags ( / begin MEASUREMENT) from the A2L file to ensure complete extraction and avoid code omissions or truncation. If the measurement code block is not found, a corresponding empty file can be generated for automatic error reporting and termination of the current process. Next, this application formats the measurement code blocks, for example, uniformly using scientific notation to retain 11 significant digits, removing decimal places from integers, and removing trailing zeros from decimals; it also completes field structures by automatically adding preset fields such as CANAPE_EXT; and it repairs special data information, such as supporting escaped double quotes in long identifiers to avoid parsing interruptions. For details on the formatting process, please refer to the relevant descriptions in the previous implementation; they will not be repeated here.
[0048] In another implementation, the target script can be a different type of script, and the initial variable information and the target variable information can be corresponding tag code blocks. Specifically, this application can extract tag code blocks of preset tags from an A2L file. These tag code blocks include, but are not limited to, code blocks of tags such as GROUP, FUNCTION, AXIS_PTS, COMPU_METHOD, COMPU_VTAB, or other custom tags. Taking the FUNCTION and AXIS_PTS tags as examples, this application can iteratively search and extract the FUNCTION tag code block containing the / begin FUNCTION start tag and the / end FUNCTION end tag, and the AXIS_PTS tag code block containing the / begin AXIS_PTS start tag and the / end AXIS_PTS end tag from the A2L file. Next, this application performs formatting processing on each of the aforementioned tag code blocks. For example, for the GROUP tag code block, this application can perform processing such as extracting the root field, preserving the internal line structure of SUB_GROUP / REF_MEASUREMENT, and merging extra spaces in each line. For the FUNCTION tag code block, this application can perform processing such as standardizing the IN_MEASUREMENT format, completing indentation and delimiters, etc. For the AXIS_PTS tag code block, this application can perform processing such as parsing the Electronic Control Unit (ECU) address (e.g., parsing from comments or extracting directly), completing the field ECU_ADDRESS_EXTENSION 0x0 / FORMAT, etc. For the COMPU_METHOD tag code block, this application can perform processing such as uniformly converting types (e.g., IDENTICAL) and format strings (e.g., "%8.6"). For the COMPU_VTAB tag code block, this application can perform processing such as extracting table elements and completing the field DEFAULT_VALUE, etc. Specific implementation details of the formatting processing can be found in the descriptions in the foregoing embodiments, and will not be repeated here.
[0049] This application does not limit the specific representation of the initial variable information and the target variable information (which may be the feature code block, measurement code block and label code block). For example, they may be represented in the form of a text file (such as .txt). This application will not impose any restrictions or details on this.
[0050] In some optional embodiments, during the execution of the above address synchronization processing scheme, this application may also automatically generate corresponding log files, such as generating a characteristic_formatter.log log file, to record corresponding data processing exception information, such as numerical conversion warnings, unrecognized numerical types, etc. This application does not impose any restrictions on this.
[0051] In steps S203 and S204, this application can extract and replace variable addresses from the ELF file using code 3 add_elf_addr.py, and integrate and synchronize using code 4 insert_to_a2l.py to obtain a new target A2L file. Specifically, after obtaining the actual address of the second variable in the ELF file, this application can perform address matching and replacement based on the actual address of the second variable in the ELF file and the variable address of the first variable in the target variable information to obtain the replaced target variable information. This application does not limit the specific implementation of the address matching and replacement. For example, this application can perform address matching or mapping on the target variable information based on the actual address of the second variable in the ELF file to find the variable address of the second variable in the target variable information. The first variable may include some or all of the second variable. Further, this application replaces the variable address of the second variable in the target variable information based on the actual address of the second variable in the ELF file to obtain the replaced target variable information; finally, the replaced target variable information is integrated into the original A2L file to obtain a new target A2L file. The following section describes several possible implementation methods for the target variable information, which includes feature code blocks, measurement code blocks, and label code blocks.
[0052] In one implementation, the aforementioned target variable information is a feature code block. Specifically, this application can parse the .symtab symbol table in the ELF file, filter and extract valid variable addresses (specifically, the actual addresses of the aforementioned second variable), for example, filtering valid variable addresses such as data object type STT_OBJECT, global / weak symbol STB_GLOBAL / STB_WEAK, or non-zero addresses, and then sorting them by address to output a mapping table from address to variable name. Next, this application can use address matching strategies based on the above mapping table, such as exact matching (e.g., variable names are completely identical) or compatible matching (e.g., removing prefix underscores _Var to Var matching), to replace the variable addresses extracted from the ELF file into the feature code block. For example, replacing the default address 0x0000 of the formatted feature code block, thus obtaining the replaced feature code block. Furthermore, this application can integrate the replaced feature code block back into the original A2L file, for example, by first writing it to a temporary file, ensuring accuracy, and then overwriting the original A2L file. This application does not impose further limitations or details on this.
[0053] In another implementation, the target variable information mentioned above is a measurement code block. Specifically, this application can parse the .symtab symbol table in the ELF file, filter and extract valid variable addresses (specifically, the actual address of the second variable mentioned above), for example, filtering valid variable addresses such as data object type STT_OBJECT, global / weak symbol STB_GLOBAL / STB_WEAK, or non-zero addresses, and then sorting them by address to output a mapping table from address to variable name. Next, this application can use address matching strategies based on the above mapping table, such as exact matching (e.g., variable names are completely identical) or compatible matching (e.g., removing prefix underscores _Var to Var matching), to replace the variable addresses extracted from the ELF file into the measurement code block. For example, it can precisely replace the ECU_ADDRESS address, LINK_MAP address, or the default address 0x0000 in the measurement code block, thereby obtaining the replaced measurement code block. Furthermore, this application can integrate the aforementioned replaced measurement code block back into the original A2L file, such as PowerONE_WuHanZhiXin.a2l, etc. This application will not impose further limitations or details on this.
[0054] In another implementation, the target variable information mentioned above is a tag code block. Specifically, this application can parse the .symtab symbol table in the ELF file, filter and extract valid variable addresses (specifically, the actual address of the second variable mentioned above), for example, filtering / selecting valid variable addresses such as data object type STT_OBJECT, global / weak symbol STB_GLOBAL / STB_WEAK, or non-zero addresses, and then sorting them by address to output a mapping table from address to variable name. Next, this application can use address matching strategies based on the above mapping table, such as exact matching (e.g., variable names are completely identical), compatibility matching (e.g., matching with prefix underscores removed), or inclusion relationship matching (e.g., variable names mutually contain each other), to replace the variable addresses extracted from the ELF file into the corresponding tag code blocks. For example, replacing the default address 0x0000 in the AXIS_PTS tag block, thus obtaining the replaced tag code block. Furthermore, this application can integrate the replaced tag code block back into the original A2L file; this application will not impose further limitations or details on this.
[0055] Optionally, after integrating the replaced tag code blocks back into the A2L file, this application can further revise the version and dimensions of the integrated A2L file to obtain the target A2L file. Specifically, considering the compatibility requirements of calibration tools, to adapt to the lower version requirements of calibration tools, this application can downgrade the integrated A2L file, for example, modifying ASAP2_VERSION 1 70 (ASAP2 version 1.70) to ASAP2_VERSION 1 61, etc. Dimensional padding can be performed on the corresponding fields in the integrated A2L file, for example, padding the MATRIX_DIM field to "1 1", etc.; encoding compatibility can be ensured for the integrated A2L file, for example, converting the ASCII-encoded A2L file to the UTF-8 encoded target A2L file, etc. This application does not impose further limitations or details on these aspects.
[0056] In some optional embodiments, this application may also record the address information of unmatched variables in the above-mentioned ELF file and target variable information, such as recording and saving the unmatched observations, calibrations and other quantities and their respective addresses in the form of a text file (such as .txt), etc. This application does not impose too many limitations on this.
[0057] In some alternative embodiments, in order to avoid data loss, script processing failure or abnormality and restore the data, this application can also perform a secure backup of the original A2L file, for example, the backup A2L file can be PowerONE_WuHanZhiXin.a2l.backup, etc.
[0058] In some alternative embodiments, this application may also display the target variable information before and after the replacement, for example, by showing the code content before and after the corresponding variable address is replaced in the display interface. This application will not make any further limitations or details in this regard. In some alternative embodiments, this application may also perform success rate statistics on the address replacement of the second variable, that is, to count the success rate of variable address replacement. The success rate may be the number of matched variable address replacements being equal to the total number of variable addresses, etc. This application will not impose further limitations or details on this.
[0059] In some alternative embodiments, this application may also automatically generate and output corresponding log files, such as a progress log file a2l_process_progress.log, which is used to indicate the current progress or progress bar of the above address synchronization processing scheme. This application will not impose further limitations or details on this.
[0060] It should be noted that the above-mentioned optional embodiments can be implemented by selecting one or more of the solutions according to the actual needs of the system, and this application does not impose any restrictions or details on this.
[0061] As can be seen, this application's solution integrates processing steps (such as observation extraction, formatting, address replacement, and file integration) that were originally scattered across multiple independent tools into a continuous automated process through batch processing scripts. This eliminates the need for manual switching between tools and data conversion, freeing users from the dependency on multiple tools. Before execution, the validity of all file or script paths must be verified, fundamentally avoiding process interruptions due to incorrect paths and solving the problem of manual intervention required when files cannot be found in traditional methods. This application's solution requires no manual intervention throughout the entire process, supports batch processing of large-scale files, and processing time no longer increases linearly with the number of files, significantly improving the efficiency of parallel development of multiple electronic control units. Each processing step / stage automatically transfers data through standardized interfaces, eliminating the risks of misalignment and omissions caused by manual copying and pasting. It also supports real-time progress feedback for operators / users, lowering the barrier to entry; when problems occur, the system can provide specific error location or error description information, greatly shortening troubleshooting time and reducing reliance on external expert experience. In specific implementation, this application obtains a calibration data description A2L file and an executable ELF file. The A2L file includes an observation script, a calibration script, and other quantity scripts besides the observation script and the calibration script. Variable extraction and processing are performed on the target script in the A2L file to obtain target variable information, including the variable address of a first variable. The target script sequentially includes the observation script, the calibration script, and the other quantity scripts. Variable address extraction is performed on the ELF file to obtain the actual address of a second variable in the ELF file. Based on the actual address of the second variable in the ELF file and the variable address of the first variable in the target variable information, the A2L file is integrated and synchronized to obtain the target A2L file. This application develops a fully automated address synchronization processing scheme, eliminating reliance on multiple tools and requiring no manual intervention. This improves the efficiency and reliability of address synchronization processing and solves the problems of process fragmentation and inefficiency in existing technologies.
[0062] Based on the foregoing embodiments, please refer to Figure 3 This is a schematic diagram of the structure of an address synchronization processing device provided in an embodiment of this application. Figure 3 The device 300 shown may include an acquisition module 301 and a processing module 302, wherein: The acquisition module 301 is used to acquire a calibration data description A2L file and an executable ELF file. The A2L file includes an observation script, a calibration script, and other quantity scripts besides the observation script and the calibration script. The processing module 302 is used to extract and process variables from the target script in the A2L file to obtain target variable information in the target script. The target variable information includes the variable address of the first variable. The target script includes the observation script, the calibration script, and the other quantity scripts in sequence. The processing module 302 is further configured to extract variable addresses from the ELF file to obtain the actual address of the second variable in the ELF file; The processing module 302 is also used to integrate and synchronize the A2L file based on the actual address of the second variable in the ELF file and the variable address of the first variable in the target variable information to obtain the target A2L file.
[0063] In some embodiments, the processing module 302 is specifically used for: Variables are extracted from the target script in the A2L file to obtain the initial variable information in the target script; The initial variable information in the target script is formatted to obtain the target variable information. The formatting process includes at least one of numeric formatting, field formatting, and information repair.
[0064] In some embodiments, When the target script is the observation script, both the initial variable information and the target variable information are the corresponding feature code blocks in the observation script; or, When the target script is the calibration script, both the initial variable information and the target variable information are the corresponding measurement code blocks in the calibration script; or, When the target script is the other variable script, both the initial variable information and the target variable information are the corresponding tag code blocks in the other variable script.
[0065] In some embodiments, the processing module 302 is specifically used for: Based on the actual address of the second variable in the ELF file, the address of the first variable in the target variable information is matched and replaced to obtain the replaced target variable information; The replaced target variable information is integrated into the A2L file to obtain the target A2L file.
[0066] In some embodiments, the processing module 302 is specifically used for: Based on the actual address of the second variable in the ELF file, address matching is performed on the target variable information to obtain the variable address of the second variable in the target variable information, wherein the first variable includes at least a portion of the second variable; Based on the actual address of the second variable in the ELF file, the variable address of the second variable in the target variable information is replaced to obtain the replaced target variable information.
[0067] In some embodiments, the processing module 302 is further configured to perform at least one of the following: Record the address information of variables that are not matched in the ELF file and the target variable information; Display the target variable information and the replaced target variable information; Perform success rate statistics on address replacement of the second variable; Backup the A2L file; Generate and output the corresponding log file, which is used at least to indicate the progress of the address synchronization process.
[0068] In some embodiments, before performing variable extraction and processing on the target script in the A2L file, the processing module 302 is further configured to: Check if the storage paths of the observation script, calibration script, and other quantity scripts in the A2L file exist. If so, continue with the steps of extracting and processing variables from the target script in the A2L file.
[0069] By implementing the embodiments of this application, the apparatus described above can acquire a calibration data description A2L file and an executable ELF file. The A2L file includes an observation script, a calibration script, and other quantity scripts besides the observation script and the calibration script. Variables are extracted and processed from the target script in the A2L file to obtain target variable information, including the variable address of a first variable. The target script sequentially includes the observation script, the calibration script, and the other quantity scripts. Variable addresses are extracted from the ELF file to obtain the actual address of a second variable in the ELF file. Based on the actual address of the second variable in the ELF file and the variable address of the first variable in the target variable information, the A2L file is integrated and synchronized to obtain the target A2L file. This application develops a fully automated address synchronization processing scheme, eliminating reliance on multiple tools and requiring no manual intervention. This improves the efficiency and reliability of address synchronization processing and solves the problems of process fragmentation and inefficiency in existing technologies.
[0070] Please see Figure 4 This is a schematic diagram of another address synchronization processing device provided in an embodiment of this application. For example... Figure 4The device shown can be a mobile phone, computer, digital broadcasting terminal, messaging device, game console, tablet device, medical device, fitness equipment, personal digital assistant, etc. This electronic device can be used in various types of vehicles, etc.
[0071] Reference Figure 4 The device 400 may include one or more of the following components: processing component 402, memory 404, power supply component 406, multimedia component 408, audio component 410, input / output interface 412, sensor component 414, and communication component 416.
[0072] Processing component 402 typically controls the overall operation of device 400, such as operations associated with display, telephone calls, data communication, camera operation, and recording. Processing component 402 may include one or more processors 420 to execute instructions to complete all or part of the steps of the address synchronization processing method described above. Furthermore, processing component 402 may include one or more modules to facilitate interaction between processing component 402 and other components. For example, processing component 402 may include a multimedia module to facilitate interaction between multimedia component 408 and processing component 402.
[0073] Memory 404 is configured to store various types of data to support the operation of device 400. Examples of such data include instructions for any application or method operating on device 400, contact data, phonebook data, messages, pictures, videos, etc. Memory 404 can be implemented by any type of volatile or non-volatile storage device or a combination thereof, such as static random access memory (SRAM), electrically erasable programmable read-only memory (EEPROM), erasable programmable read-only memory (EPROM), programmable read-only memory (PROM), read-only memory (ROM), magnetic storage, flash memory, magnetic disk, or optical disk.
[0074] Power supply component 406 provides power to various components of device 400. Power supply component 406 may include a power management system, one or more power supplies, and other components associated with generating, managing, and distributing power to device 400.
[0075] Multimedia component 408 includes a screen that provides an output interface between the device 400 and the user. In some embodiments, the screen may include a liquid crystal display (LCD) and a touch panel (TP). If the screen includes a touch panel, the screen may be implemented as a touchscreen to receive input signals from the user. The touch panel includes one or more touch sensors to sense touches, swipes, and gestures on the touch panel. The touch sensors may sense not only the boundaries of the touch or swipe action but also the duration and pressure associated with the touch or swipe operation. In some embodiments, multimedia component 408 includes a front-facing camera and / or a rear-facing camera. When the device 400 is in an operating mode, such as a shooting mode or a video mode, the front-facing camera and / or the rear-facing camera may receive external multimedia data. Each front-facing camera and rear-facing camera may be a fixed optical lens system or have focal length and optical zoom capabilities.
[0076] Audio component 410 is configured to output and / or input audio signals. For example, audio component 410 includes a microphone (MIC) configured to receive external audio signals when device 400 is in an operating mode, such as call mode, recording mode, and voice recognition mode. The received audio signals may be further stored in memory 404 or transmitted via communication component 416. In some embodiments, audio component 410 also includes a speaker for outputting audio signals.
[0077] Input / output interface 412 provides an interface between processing component 402 and peripheral interface modules, which may be keyboards, click wheels, buttons, etc. These buttons may include, but are not limited to, home buttons, volume buttons, start buttons, and lock buttons.
[0078] Sensor assembly 414 includes one or more sensors for providing status assessments of various aspects of device 400. For example, sensor assembly 414 may detect the on / off state of device 400, the relative positioning of components such as the display and keypad of device 400, changes in the position of device 400 or a component of device 400, the presence or absence of user contact with device 400, the orientation or acceleration / deceleration of device 400, and temperature changes of device 400. Sensor assembly 414 may include a proximity sensor configured to detect the presence of nearby objects without any physical contact. Sensor assembly 414 may also include a light sensor, such as a CMOS or CCD image sensor, for use in imaging applications. In some embodiments, sensor assembly 414 may also include an accelerometer, a gyroscope, a magnetometer, a pressure sensor, or a temperature sensor.
[0079] Communication component 416 is configured to facilitate wired or wireless communication between device 400 and other devices. Device 400 can access wireless networks based on communication standards, such as WiFi, 2G, or 3G, or combinations thereof. In one exemplary embodiment, communication component 416 receives broadcast signals or broadcast-related information from an external broadcast management system via a broadcast channel. In one exemplary embodiment, communication component 416 also includes a near-field communication (NFC) module to facilitate short-range communication. For example, the NFC module may be implemented based on radio frequency identification (RFID) technology, Infrared Data Association (IrDA) technology, ultra-wideband (UWB) technology, Bluetooth (BT) technology, and other technologies.
[0080] In an exemplary embodiment, the apparatus 400 may be implemented by one or more application-specific integrated circuits (ASICs), digital signal processors (DSPs), digital signal processing devices (DSPDs), programmable logic devices (PLDs), field-programmable gate arrays (FPGAs), controllers, microcontrollers, microprocessors, or other electronic components to perform the address synchronization processing method described above.
[0081] Understandably, the processor 420 in this application embodiment can be an integrated circuit chip with signal processing capabilities. During implementation, each step of the above method embodiment can be completed by integrated logic circuits in the processor's hardware or by instructions in software form. The processor described above can be a general-purpose processor, a digital signal processor (DSP), an application-specific integrated circuit (ASIC), a field-programmable gate array (FPGA), or other programmable logic devices, discrete gate or transistor logic devices, or discrete hardware components.
[0082] Understandably, the memory 404 in the embodiments of this application can be volatile memory or non-volatile memory, or may include both volatile and non-volatile memory. The non-volatile memory can be read-only memory (ROM), programmable read-only memory (PROM), erasable programmable read-only memory (EPROM), electrically erasable programmable read-only memory (EEPROM), or flash memory. The volatile memory can be random access memory (RAM), which is used as an external cache. By way of example, but not limitation, many forms of RAM are available, such as static random access memory (SRAM), dynamic random access memory (DRAM), synchronous dynamic random access memory (SDRAM), double data rate synchronous dynamic random access memory (DDRSDRAM), enhanced synchronous dynamic random access memory (ESDRAM), synchronous linked dynamic random access memory (SLDRAM), and direct rambus RAM (DR RAM). It should be noted that the memory used in the systems and methods described herein is intended to include, but is not limited to, these and any other suitable types of memory.
[0083] In an exemplary embodiment, a non-transitory computer-readable storage medium including instructions is also provided, such as a memory 404 including instructions, which can be executed by the processor 420 of the device 400 to complete the above-described upper address synchronization processing method. For example, the non-transitory computer-readable storage medium may be a ROM, random access memory (RAM), CD-ROM, magnetic tape, floppy disk, and optical data storage device, etc.
[0084] The aforementioned device can be a standalone electronic device or a part of a standalone electronic device. For example, in one embodiment, the device can be an integrated circuit (IC) or a chip, wherein the integrated circuit can be a single IC or a collection of multiple ICs. The chip can include, but is not limited to, the following types: GPU (Graphics Processing Unit), CPU (Central Processing Unit), FPGA (Field Programmable Gate Array), DSP (Digital Signal Processor), ASIC (Application Specific Integrated Circuit), and SoC (System on Chip). The aforementioned integrated circuit or chip can be used to execute executable instructions (or code) to implement the aforementioned address synchronization processing method. The executable instructions can be stored in the integrated circuit or chip or obtained from other devices or equipment. For example, the integrated circuit or chip includes a processor, memory, and an interface for communicating with other devices. The executable instruction can be stored in the memory, and when the executable instruction is executed by the processor, the above-mentioned address synchronization processing method is implemented; or, the integrated circuit or chip can receive the executable instruction through the interface and transmit it to the processor for execution to implement the above-mentioned address synchronization processing method.
[0085] Please see Figure 5 This is a schematic diagram of the structure of a vehicle provided in an embodiment of this application. For example, as shown... Figure 5 As shown, the vehicle 500 includes a memory 501 and a processor 502. The memory 501 stores executable program code 5011, and the processor 502 is used to call and execute the executable program code 5011 to perform the address synchronization processing method.
[0086] This application embodiment can divide the vehicle into functional modules according to the above method embodiment. For example, each function can be assigned to a separate module, or two or more functions can be integrated into a processing module. The integrated module can be implemented in hardware. It should be noted that the module division in this embodiment is illustrative and only represents one logical functional division. In actual implementation, there may be other division methods. When dividing each functional module according to its corresponding function, the vehicle may include a processing module and a communication module, etc.
[0087] It should be noted that all relevant content of each step involved in the above method embodiments can be referenced from the functional description of the corresponding functional module, and will not be repeated here. The vehicle provided in this embodiment is used to execute the above-described address synchronization processing method, and therefore can achieve the same effect as the above implementation method.
[0088] In another exemplary embodiment, a computer program product is also provided, the computer program product comprising a computer program executable by a programmable device, the computer program having a code portion for performing the above-described address synchronization processing method when executed by the programmable device.
[0089] It should be noted that the descriptions of the above embodiments of storage media, devices, and equipment are similar to the descriptions of the above method embodiments, and have similar beneficial effects. For technical details not disclosed in the embodiments of storage media, devices, and equipment of this application, please refer to the descriptions of the method embodiments of this application for understanding.
[0090] Other embodiments of this application will readily occur to those skilled in the art upon consideration of the specification and practice of this application. This application is intended to cover any variations, uses, or adaptations of this application that follow the general principles of this application and include common knowledge or customary techniques in the art not disclosed in this application. The specification and embodiments are to be considered exemplary only, and the true scope and spirit of this application are indicated by the following claims.
[0091] The above description is merely a preferred embodiment of this application and is not intended to limit this application. Any modifications or equivalent substitutions made within the spirit and principles of this application should be included within the protection scope of this application.
Claims
1. An address synchronization processing method, characterized by, The method comprises: obtaining a calibration data description A2L file and an executable ELF file, the A2L file comprising a measurement script, a calibration quantity script, and other quantity scripts other than the measurement script and the calibration quantity script; performing variable extraction and processing on a target script in the A2L file to obtain target variable information in the target script, the target variable information comprising a variable address of a first variable, and the target script sequentially comprising the measurement script, the calibration quantity script, and the other quantity scripts; performing variable address extraction on the ELF file to obtain an actual address of a second variable in the ELF file; synchronizing the A2L file based on the actual address of the second variable in the ELF file and the variable address of the first variable in the target variable information to obtain a target A2L file.
2. The method of claim 1, wherein, The variable extraction and processing on the target script in the A2L file to obtain the target variable information in the target script comprises: performing variable extraction on the target script in the A2L file to obtain initial variable information in the target script; performing format processing on the initial variable information in the target script to obtain the target variable information, the format processing comprising at least one of value formatting, field formatting, and information repair.
3. The method of claim 2, wherein: when the target script is the measurement script, the initial variable information and the target variable information are both corresponding feature code blocks in the measurement script; or, when the target script is the calibration quantity script, the initial variable information and the target variable information are both corresponding measurement code blocks in the calibration quantity script; or, when the target script is the other quantity script, the initial variable information and the target variable information are both corresponding label code blocks in the other quantity script.
4. The method of claim 1, wherein, The synchronizing the A2L file based on the actual address of the second variable in the ELF file and the variable address of the first variable in the target variable information to obtain a target A2L file comprises: performing address matching and replacement on the variable address of the first variable in the target variable information based on the actual address of the second variable in the ELF file to obtain the target variable information after replacement; integrating the target variable information after replacement into the A2L file to obtain the target A2L file.
5. The method of claim 4, wherein, The performing address matching and replacement on the variable address of the first variable in the target variable information based on the actual address of the second variable in the ELF file to obtain the target variable information after replacement comprises: performing address matching on the target variable information based on the actual address of the second variable in the ELF file to obtain a variable address of the second variable in the target variable information, the first variable comprising at least part of the second variable; performing replacement on the variable address of the second variable in the target variable information based on the actual address of the second variable in the ELF file to obtain the target variable information after replacement.
6. The method of claim 5, wherein, The method further comprises at least one of: record the variable address information that is not matched in the ELF file and the target variable information; display the target variable information and the replaced target variable information; carry out success rate statistics on the address replacement of the second variable; backup the A2L file; generate and output a corresponding log file, which is used at least to indicate the progress of the address synchronization processing.
7. The method according to any one of claims 1 to 6, characterized in that, Before the variable extraction and processing of the target script in the A2L file, the method further comprises: detecting whether the storage paths of the observation script, the calibration script and the other script in the A2L file exist respectively; if yes, continue to execute the steps of the variable extraction and processing of the target script in the A2L file.
8. An address synchronization processing apparatus characterized by comprising: comprise: an acquisition module, configured to acquire a calibration data description A2L file and an executable ELF file, the A2L file comprising an observation script, a calibration script and other scripts except the observation script and the calibration script; a processing module, configured to extract and process a target script in the A2L file to obtain target variable information in the target script, the target variable information comprising a variable address of a first variable, and the target script sequentially comprising the observation script, the calibration script and the other scripts; the processing module is further configured to extract a variable address from the ELF file to obtain an actual address of a second variable in the ELF file; the processing module is further configured to synchronize the A2L file based on the actual address of the second variable in the ELF file and the variable address of the first variable in the target variable information to obtain a target A2L file.
9. A vehicle characterized by comprising: comprise: a processor; a memory for storing processor-executable instructions; wherein the processor is configured to execute the executable instructions to implement the steps of the method in any one of claims 1-7.
10. A computer-readable storage medium having stored thereon computer program instructions, wherein, the computer program instructions are executed by the processor to implement the steps of the method in any one of claims 1-7. the computer program instructions are executed by the processor to implement the steps of the method in any one of claims 1-7.