A dynamic simulation method and device for vehicle-mounted ECU firmware

Abstract

The present application is applicable to the field of ECU testing technology, and in particular relates to a method and device for dynamic simulation of vehicle-mounted ECU firmware, the method comprising: obtaining firmware data of a target ECU to provide basic data information for subsequent analysis and testing; performing instruction translation on the firmware data of the target ECU to determine simulation customization parameters corresponding to the target ECU, so that the subsequent simulation environment can accurately simulate the operating status of the target ECU; dynamically simulating the firmware data of the target ECU according to the simulation customization parameters, and monitoring the relevant register data of the target ECU through a preset callback function to obtain the numerical change data of the relevant registers, providing key data for evaluating the operating stability and accuracy of the target ECU; performing absolute offset analysis on the target ECU based on the numerical change data of the relevant registers, determining a dynamic test report of the target ECU firmware, generating a detailed and targeted dynamic test report, shortening the development and testing cycle, improving development and testing efficiency, and reducing costs.

Description

Technical Field

[0001] The present application belongs to the field of ECU testing technology, and in particular relates to a dynamic simulation method and device for vehicle-mounted ECU firmware. Background Art

[0002] With the rapid development of automotive electronics technology, automotive electrical and electronic architecture has evolved from a distributed architecture to one based on domain centralization and a central computing platform. In a distributed architecture, each function is typically performed by a separate ECU, leading to complex wiring networks, difficult system integration, and difficult maintenance and upgrades. To address these pain points, automotive electrical and electronic architecture has gradually evolved towards domain centralization and a central computing platform. This reduces the number of ECUs per vehicle, but significantly increases the complexity of the tasks handled by each ECU.

[0003] During the development and testing of in-vehicle ECU firmware, the traditional development and testing process has problems such as long iteration time, limitations on prototype vehicles and test equipment, and a lack of effective development and testing tools, resulting in long and inefficient development and testing cycles and high testing hardware costs. Summary of the Invention

[0004] The embodiments of the present application provide a dynamic simulation method and device for vehicle-mounted ECU firmware, which can solve the problems of long development and testing cycles, low efficiency, and high testing hardware costs due to the lack of effective development and testing tools during the development and testing of vehicle-mounted ECUs.

[0005] In a first aspect, an embodiment of the present application provides a method for dynamic simulation of vehicle-mounted ECU firmware, comprising:

[0006] Get the firmware data of the target ECU;

[0007] Performing instruction translation on the firmware data of the target ECU to determine simulation customization parameters corresponding to the target ECU; wherein the simulation customization parameters are used to perform architecture adaptation on the target ECU;

[0008] Dynamically simulating the firmware data of the target ECU according to the simulation customization parameters, and monitoring the relevant register data of the target ECU through a preset callback function to obtain value change data of the relevant register;

[0009] An absolute offset analysis is performed on the target ECU based on the numerical change data of the relevant register to determine a dynamic test report of the target ECU firmware.

[0010] The above technical solutions in the embodiments of the present application have at least the following technical effects:

[0011] The dynamic simulation method of the vehicle-mounted ECU firmware provided in the embodiment of the present application obtains the firmware data of the target ECU to provide basic data for subsequent in-depth analysis and testing of the target ECU, and fully understands the original operating logic and configuration information of the target ECU. The firmware data of the target ECU is translated by instructions to determine the simulation customization parameters corresponding to the target ECU, so that the subsequent simulation environment can accurately simulate the operating status of the target ECU. The firmware data of the target ECU is dynamically simulated according to the simulation customization parameters, and the relevant register data of the target ECU is monitored through a preset callback function to obtain the numerical change data of the relevant registers, providing key data for evaluating the operating stability and accuracy of the target ECU. Based on the numerical change data of the relevant registers, the target ECU is subjected to absolute offset analysis, and the dynamic test report of the target ECU firmware is determined. The offset of the register numerical change is accurately analyzed, the performance and potential risks of the target ECU firmware are comprehensively evaluated, and a detailed and targeted dynamic test report is generated, which provides a strong basis for the optimization and improvement of the firmware, shortens the development and testing cycle, improves the development and testing efficiency, and reduces costs.

[0012] In a second aspect, an embodiment of the present application provides a dynamic simulation system for vehicle-mounted ECU firmware, comprising:

[0013] An acquisition unit, used to acquire firmware data of a target ECU;

[0014] a customization unit, configured to perform instruction translation on the firmware data of the target ECU and determine simulation customization parameters corresponding to the target ECU; wherein the simulation customization parameters are used to perform architecture adaptation on the target ECU;

[0015] a simulation unit, configured to dynamically simulate the firmware data of the target ECU according to the simulation customization parameters, and monitor the relevant register data of the target ECU through a preset callback function to obtain value change data of the relevant register;

[0016] A result unit is used to perform absolute offset analysis on the target ECU based on the value change data of the relevant register to determine a dynamic test report of the target ECU firmware.

[0017] In a third aspect, an embodiment of the present application provides an electronic device comprising a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor implements the method described in any one of the above aspects when executing the computer program.

[0018] In a fourth aspect, an embodiment of the present application provides a computer program product, which, when executed on an electronic device, enables the electronic device to execute the method according to any one of the above aspects.

[0019] It can be understood that the beneficial effects of the second to fourth aspects mentioned above can be found in the relevant descriptions of the above aspects and will not be repeated here. BRIEF DESCRIPTION OF THE DRAWINGS

[0020] In order to more clearly illustrate the technical solutions in the embodiments of the present application, the following briefly introduces the drawings required for use in the embodiments or descriptions of the prior art. Obviously, the drawings described below are only some embodiments of the present application. For ordinary technicians in this field, other drawings can be obtained based on these drawings without any creative work.

[0021] Figure 1 This is a flow chart of a dynamic simulation method for vehicle-mounted ECU firmware provided by an embodiment of the present application;

[0022] Figure 2 This is a schematic diagram of the operation of a dynamic simulation method for vehicle-mounted ECU firmware provided by an embodiment of the present application;

[0023] Figure 3 This is a partial schematic diagram of a dynamic simulation method for vehicle-mounted ECU firmware provided by an embodiment of the present application;

[0024] Figure 4 This is a partial schematic diagram of a dynamic simulation method for vehicle-mounted ECU firmware provided by an embodiment of the present application;

[0025] Figure 5 This is a partial schematic diagram of a dynamic simulation system for vehicle-mounted ECU firmware provided by an embodiment of the present application.

[0026] Figure 6 It is a structural diagram of an electronic device provided in one embodiment of the present application. DETAILED DESCRIPTION

[0027] In the following description, specific details such as specific system structures and techniques are provided for purposes of illustration rather than limitation to facilitate a thorough understanding of the embodiments of the present application. However, it will be apparent to those skilled in the art that the present application may be implemented in other embodiments without these specific details. In other cases, detailed descriptions of well-known systems, devices, circuits, and methods are omitted to avoid obscuring the description of the present application with unnecessary detail.

[0028] It should be understood that when used in the present specification and the appended claims, the term "comprising" indicates the presence of described features, integers, steps, operations, elements and / or components, but does not preclude the presence or addition of one or more other features, integers, steps, operations, elements, components and / or collections thereof.

[0029] It will also be understood that the term "and / or" used in this specification and the appended claims refers to and includes any and all possible combinations of one or more of the associated listed items.

[0030] As used in this specification and the appended claims, the term "if" can be interpreted as "when" or "upon" or "in response to determining" or "in response to detecting," depending on the context. Similarly, the phrases "if it is determined" or "if the described condition or event is detected" can be interpreted as meaning "upon determination" or "in response to determining" or "upon detection of the described condition or event" or "in response to detecting the described condition or event," depending on the context.

[0031] In addition, in the description of the present application specification and the appended claims, the terms "first", "second", "third", etc. are only used to distinguish the descriptions and cannot be understood as indicating or implying relative importance.

[0032] References to "one embodiment" or "some embodiments" in this specification mean that a particular feature, structure, or characteristic described in conjunction with that embodiment is included in one or more embodiments of the present application. Thus, phrases such as "in one embodiment," "in some embodiments," "in other embodiments," and "in other embodiments" appearing in various places in this specification do not necessarily refer to the same embodiment, but rather mean "one or more but not all embodiments," unless otherwise specifically emphasized. The terms "including," "comprising," "having," and variations thereof all mean "including but not limited to," unless otherwise specifically emphasized.

[0033] In the development of in-vehicle ECU firmware, traditional development processes suffer from long iteration times and limitations on prototype vehicles and test equipment. This patent, combined with the QEMU simulator, proposes a dynamic simulation method for in-vehicle ECU firmware, which improves testing effectiveness and efficiency while reducing testing costs. This dynamic simulation method simulates the ECU's operating environment, enabling developers to simulate, calibrate, and measure software on a PC, shortening the development cycle and reducing reliance on scarce resources and actual hardware. Furthermore, through the dynamic simulation method, developers can observe and modify memory variables and even hardware status at any time, greatly improving work efficiency.

[0034] To solve the above problems, an embodiment of the present application provides a method and device for dynamic simulation of vehicle-mounted ECU firmware. In this method, by obtaining the firmware data of the target ECU, basic data is provided for subsequent in-depth analysis and testing of the target ECU, and the original operating logic and configuration information of the target ECU are fully understood. The firmware data of the target ECU is translated, and the simulation customization parameters corresponding to the target ECU are determined, so that the subsequent simulation environment can accurately simulate the operating status of the target ECU. The firmware data of the target ECU is dynamically simulated according to the simulation customization parameters, and the relevant register data of the target ECU is monitored through a preset callback function to obtain the numerical change data of the relevant registers, providing key data for evaluating the operating stability and accuracy of the target ECU. Based on the numerical change data of the relevant registers, the target ECU is subjected to absolute offset analysis, and a dynamic test report of the target ECU firmware is determined. The offset of the register numerical change is accurately analyzed, the performance and potential risks of the target ECU firmware are comprehensively evaluated, and a detailed and targeted dynamic test report is generated, providing a strong basis for firmware optimization and improvement, shortening the development and testing cycle, improving development and testing efficiency, and reducing costs.

[0035] The dynamic simulation method of the vehicle-mounted ECU firmware provided in the embodiment of the present application can be applied to electronic devices. In this case, the electronic device is the executor of the dynamic simulation method of the vehicle-mounted ECU firmware provided in the embodiment of the present application. The embodiment of the present application does not impose any restrictions on the specific type of electronic device.

[0036] For example, the electronic device may be an ultra-mobile personal computer (UMPC), a netbook, a desktop computer, a computer, a laptop computer, a communication device, a computing device, a satellite wireless device, etc.

[0037] In order to better understand the dynamic simulation method of the vehicle-mounted ECU firmware provided in the embodiment of the present application, the specific implementation process of the dynamic simulation method of the vehicle-mounted ECU firmware provided in the embodiment of the present application is exemplarily introduced below.

[0038] Figure 1 A schematic flow chart of a dynamic simulation method for vehicle-mounted ECU firmware provided by an embodiment of the present application is shown. Figure 2 The following is a schematic diagram showing the operation of a dynamic simulation method for vehicle-mounted ECU firmware provided by an embodiment of the present application. The dynamic simulation method for vehicle-mounted ECU firmware includes:

[0039] S100, obtaining firmware data of the target ECU.

[0040] As you can understand, there are various ways to obtain the target ECU's firmware data. For example, an ECU programmer can connect to the target ECU using its compatible interface and directly read the firmware data from the ECU's memory chip using a specific communication protocol, such as the CAN (Controller Area Network) protocol. Alternatively, the vehicle's diagnostic interface can be used to send data read commands to the ECU using the OBD (On-Board Diagnostics) standard protocol to obtain the required firmware data. Alternatively, the firmware data can be downloaded from the official database provided by the vehicle manufacturer based on the ECU's model and version information.

[0041] S200 , performing instruction translation on the firmware data of the target ECU to determine simulation customization parameters corresponding to the target ECU; wherein the simulation customization parameters are used to perform architecture adaptation on the target ECU.

[0042] As can be understood, instruction translation involves converting the binary instructions in the target ECU firmware into a format that is easy to analyze and process. Professional chip simulation tools (such as QEMU, ModelSim, and Vivado Simulator) can be used to run the binary instructions in the ECU firmware and record the chip operation data. Based on the instruction set architecture (ISA) table lookup method, a mapping table containing the target ECU instruction set can be constructed. This table records the opcode, operand, and corresponding high-level language instruction description for each binary instruction. Translation is then performed by looking up the mapping table based on the binary instructions. Alternatively, a syntax analysis algorithm can be used to perform lexical and syntactic analysis of the instructions in the firmware data according to the syntax rules of the target ECU instruction set, identifying the various parts of the instruction and completing the translation. When determining customized simulation parameters, the translated instruction information can be used to analyze the target ECU's architectural requirements, such as the required clock frequency, memory allocation mode, and peripheral interface configuration, to ensure that the subsequent simulation environment is compatible with the target ECU's actual architecture.

[0043] In one possible implementation, S200 , performing instruction translation on the firmware data of the target ECU to determine the simulation customization parameters corresponding to the target ECU, includes:

[0044] S210 , performing instruction translation on the firmware data of the target ECU to determine the instruction translation completion of the target ECU; wherein the instruction translation completion has a value range of [0, 1].

[0045] It is understandable that simulation testing tools such as QEMU can be used to simulate the operation of the target ECU by translating instructions. When translating instructions from the target ECU's firmware data, a byte-by-byte parsing algorithm can be used. Starting from the starting position of the firmware data, the data is read byte by byte, and the instructions corresponding to each byte are gradually parsed according to the instruction set rules of the target ECU. Alternatively, a sliding window parsing algorithm can be used to set a fixed-size window, slide the window over the firmware data, and parse the instructions based on the data within the window each time. When determining the completion of the instruction translation, the progress of the translation can be measured by statistics. If an unrecognizable instruction is encountered during the translation process, the statistics are suspended and continued after the exception is handled.

[0046] Optionally, S210 , performing instruction translation on the firmware data of the target ECU and determining the completion degree of the instruction translation of the target ECU, includes:

[0047] S211 , performing instruction translation on the firmware data of the target ECU, and counting the total number of instructions in the firmware data and the number of completed instructions of the successfully translated instructions.

[0048] It is understood that when counting the total number of instructions, a traversal counting algorithm can be used. Starting from the starting address of the firmware data, the firmware data is traversed section by section according to the instruction length rules. Each time an instruction is recognized, the total number of instructions counter is incremented by 1. During the translation process, for each successfully parsed instruction, the number of completed instructions counter is incremented by 1. If an unrecognized instruction is encountered, its location can be marked and the total number of instructions can be counted backward to ensure the completeness of the statistics and accurately calculate the completion rate of the instruction translation.

[0049] S212 , performing a ratio calculation based on the number of completed instructions and the total number of instructions to determine the instruction translation completion degree of the target ECU.

[0050] It is understood that the instruction translation completion degree can be obtained by dividing the number of completed instructions by the total number of instructions using a division algorithm. For example, if the total number of instructions is n and the number of successfully translated instructions is m, then the instruction translation completion degree is m / n.

[0051] S220 , when the value of the instruction translation completion degree is equal to 1, determining the default simulation customization parameters as the simulation customization parameters corresponding to the target ECU.

[0052] As you can understand, the default simulation customization parameters are a pre-set set of parameters that apply to most common situations. When the instruction translation completion level reaches 1, meaning all instructions in the firmware data have been successfully translated, the current default simulation customization parameters are considered sufficient for the target ECU's simulation requirements. No additional parameter customization is required. Directly assigning the default parameters to the target ECU's corresponding simulation customization parameters improves processing efficiency and reduces unnecessary computing resource consumption.

[0053] S230: When the value of the instruction translation completion degree is not equal to 1, simulation parameters are customized according to the firmware data to determine simulation customization parameters corresponding to the target ECU.

[0054] It is understandable that when instruction translation is incomplete, it means that there are special or abnormal instructions in the firmware data, and the default simulation customization parameters may not meet the simulation requirements. The firmware data can be deeply analyzed to study the compatibility issues of untranslated instructions with the target ECU architecture. Starting from the instruction function, operand type, execution conditions and other aspects, the simulation parameters that need to be adjusted or added can be determined to ensure that the simulation environment can accurately simulate the operation of the target ECU. For example, for complex and heterogeneous ECU chips and special detection requirements, the original Qemu can be customized and optimized. Qemu natively supports general architectures, such as ARM, and does not support peripherals such as MPU. Therefore, the ARM version and Tricore version of Qemu with MPU function can be expanded. Please refer to Figure 3 ; Some instructions of the native version of Qemu are translated incorrectly or not translated at all, causing abnormal operation of the firmware. Therefore, multiple corresponding instructions can be supplemented through template matching.

[0055] Optionally, S230 , performing simulation parameter customization according to the firmware data to determine simulation customization parameters corresponding to the target ECU, includes:

[0056] S231, obtaining, according to the firmware data, an abnormal instruction set of all instructions in the firmware data that have not been completely translated.

[0057] It is understood that during the translation process, when instructions that cannot be parsed according to existing instruction set rules are encountered, these instructions can be collected into a set, forming an abnormal instruction set. A traversal marking algorithm can be used to evaluate each instruction during instruction translation. If the translation fails, it is marked and added to the abnormal instruction set. The location of the instruction in the firmware data is also recorded to facilitate subsequent detailed analysis of the abnormal instruction.

[0058] S232: Traverse all instructions in the abnormal instruction set to determine abnormal type data of each instruction in the abnormal instruction set.

[0059] As can be understood, when traversing the set of abnormal instructions, a feature matching algorithm can be used to match the abnormal instruction's binary code features, instruction length, operand location, and other information with pre-defined exception type templates. For example, if the instruction's opcode is unrecognizable, it can be classified as an "unknown opcode exception"; if the instruction's operand format does not conform to the instruction set specification, it can be classified as an "operand format exception." Through the feature matching algorithm, the corresponding exception type data is determined for each abnormal instruction, allowing for subsequent targeted processing.

[0060] S233, merging duplicated items of the exception type data of each instruction in the exception instruction set to obtain an exception type table corresponding to the exception instruction set.

[0061] As you can understand, a hash table statistical algorithm can be used to traverse the exception type data of each instruction in the exception instruction set, constructing a hash table with the exception type as the key and the number of occurrences as the value. If the same exception type is encountered, the corresponding value is incremented by 1. After the traversal is completed, an exception type table is generated based on the hash table, recording each exception type and its number of occurrences. This allows for a clearer understanding of the distribution of abnormal instructions and facilitates centralized processing of key exception types.

[0062] S234 , performing simulation parameter customization based on the abnormal type table corresponding to the abnormal instruction set, and determining simulation customization parameters corresponding to the target ECU.

[0063] It is understood that simulation parameters can be adjusted based on the characteristics and frequency of occurrence of different exception types in the exception type table. For frequently occurring "memory access exceptions," simulation parameters related to memory management can be adjusted, such as adding memory address verification rules and adjusting memory allocation strategies. For "unknown instruction exceptions," instruction set parsing rules can be expanded or special simulation processing logic can be set to ensure the correct simulation of the behavior of these abnormal instructions. Ultimately, simulation customization parameters suitable for the target ECU can be determined, and QEMU can be dynamically customized.

[0064] S300 , dynamically simulate the firmware data of the target ECU according to the simulation customization parameters, and monitor the relevant register data of the target ECU through a preset callback function to obtain the value change data of the relevant registers.

[0065] It is understood that in the process of simulating the firmware data of the target ECU by using QEMU customized according to the simulation customization parameters, please refer to Figure 4, triggering a preset callback function when executing instructions related to register operations. Regarding the execution algorithm of the preset callback function, for register read operations, one algorithm directly reads data from the simulated register storage area; for register write operations, one algorithm first checks the legality of the write operation, such as whether the address is out of bounds and whether the data format is correct. If legal, the data in the simulated register storage area is updated. By recording the register data after each read and write operation, the numerical change data of the relevant registers can be obtained. The register here is a high-speed storage unit inside the CPU used to temporarily store the data involved in the operation and the results of the operation. It plays a key role in data storage and processing during the operation of the ECU.

[0066] A preset callback function is a special, pre-defined function that is invoked when a specific event occurs to monitor, process, or perform other specific functions related to the target object. These callback functions include a first and a second. The first callback function primarily reads the target ECU's registers and obtains the return value from the read operation. This return value serves as the first return data, which provides a basis for analyzing the current register value. The second callback function primarily writes the target ECU's registers and obtains the return value from the write operation. This return value serves as the second return data. During dynamic simulation of the target ECU's firmware data, when the simulation executes instructions related to register operations, the corresponding preset callback function is automatically triggered. The preset callback function performs operations such as address mapping, data verification, and offset calculation according to pre-defined algorithms, enabling effective monitoring and processing of register data. This supports subsequent acquisition of register value change data, absolute offset analysis, and generation of dynamic test reports.

[0067] The preset callback function includes a first preset callback function and a second preset callback function. In step S300, the preset callback function is used to monitor the relevant register data of the target ECU to obtain the value change data of the relevant register, including:

[0068] S310 , performing a register read operation on relevant registers of the target ECU through a first preset callback function to obtain first return data from the target ECU.

[0069] It is understood that when performing a register read operation, an address mapping algorithm can be used to convert the logical register address into an actual memory address based on the register address mapping relationship of the target ECU. The corresponding data can be read from the simulated memory area as a return value. When the first preset callback function is triggered, it will perform the read operation according to this address mapping rule and pass the read data as the first return data.

[0070] Optionally, S310, performing a register read operation on a relevant register of the target ECU through a first preset callback function to obtain first return data of the target ECU, includes:

[0071] S311 , performing a register read operation on relevant registers of the target ECU, and determining a first characteristic data segment of a memory protection unit of the relevant register based on the data characteristic of the memory protection unit.

[0072] It can be understood that the Memory Protection Unit (MPU) is a hardware unit used to protect the security of memory areas. It can set access permissions for different memory areas to prevent illegal memory access. It is used to protect the security and integrity of memory data. When performing a register read operation, the characteristic data segment of the memory area where the relevant register is located is determined based on the access permissions and data feature identifiers set by the MPU. For example, the MPU may set different read and write permission bits, data type identification bits, etc. By analyzing this bit information, the starting address, length, access permissions, and other characteristics of the first characteristic data segment are determined, providing a basis for subsequent accurate data reading.

[0073] S312 , performing relative position reading of the first characteristic data segment of the memory protection unit of the relevant register through the first preset callback function to obtain first return data of the target ECU.

[0074] As you can understand, after determining the first characteristic data segment, a read operation is performed based on the register's relative position within that data segment. Using an offset calculation algorithm, the starting address of the characteristic data segment is added to the register's relative offset address to determine the actual read address. The first preset callback function reads data from the simulated memory based on this calculated address and uses it as the first return data from the target ECU, ensuring that the read data accurately reflects the current value of the relevant register.

[0075] S320 , performing a write register operation on relevant registers of the target ECU through a second preset callback function to obtain second return data of the target ECU.

[0076] As you can understand, when writing to a register, a data verification algorithm can be used to first verify the format and range of the data to be written. If the data does not meet the requirements of the target ECU register, an error message is returned. If the data verification passes, the data is then written to the simulated register memory area according to the register address. After executing the write operation, the second preset callback function returns a second return data indicating the operation result. This data may include information such as whether the write was successful and whether a memory protection exception was triggered.

[0077] Optionally, S320, performing a write register operation on a relevant register of the target ECU through a second preset callback function to obtain second return data of the target ECU, including:

[0078] S321 , performing a write register operation on a relevant register of the target ECU, and determining a second characteristic data segment of the memory protection unit of the relevant register based on the data characteristic of the memory protection unit.

[0079] As can be understood, similar to register reads, when writing registers, the second characteristic data segment of the memory region where the relevant register is located is determined based on the data characteristics of the memory protection unit. By analyzing the permission control bits, data type identifiers, and other information in the memory protection unit, the boundaries and access rules of this data segment can be clarified to ensure that the write operation is performed within the legal memory region, avoiding simulation errors caused by illegal writes.

[0080] S322 , performing relative position reading of the second characteristic data segment of the memory protection unit of the relevant register through the first preset callback function to obtain second return data of the target ECU.

[0081] It can be understood that after the write operation completes, to obtain the write operation result information, the first preset callback function performs a relative read of the second characteristic data segment of the memory protection unit of the relevant register. The same offset calculation method as the read operation can be used to calculate the read address and read data from the simulated memory. This data can include information such as the register value after the write and the status change of the memory protection unit. This data is used as the second return data of the target ECU for subsequent analysis of the execution of the write operation.

[0082] S330: Obtain value change data of relevant registers according to the first return data and the second return data of the target ECU.

[0083] As you can understand, a data comparison algorithm can be used to compare the first return data (register value before the read operation) with the second return data (register value after the write operation). If the two data differ, the difference or change between them is calculated and recorded as the value change data for the relevant register. For example, for a numeric register, the difference is calculated by subtracting the first return data from the second return data; for a flag register, the flag bits are analyzed to determine which have changed. This comparison clearly captures the value changes of the register during the read and write operations, providing data support for subsequent absolute offset analysis.

[0084] S400 , performing absolute offset analysis on the target ECU based on the value change data of the relevant registers, and determining a dynamic test report of the target ECU firmware.

[0085] As you can understand, absolute offset analysis aims to determine the actual offset location of register data in memory to assess the accuracy and stability of ECU firmware operation. This can be done using a memory mapping offset calculation method. Using the target ECU's memory map (memory mapping is the process of establishing a correspondence between the program's logical address space and the physical memory address space; the memory map records this correspondence), register value changes are correlated with memory addresses to calculate absolute offsets. Alternatively, absolute offsets can be derived by tracking the sequence of register operations and memory access patterns during instruction execution, combined with memory base address information. The dynamic test report, based on the results of absolute offset analysis, determines whether register data changes fall within the expected memory range and whether there are any unusual offsets. This allows for an assessment of potential errors or risks in the ECU firmware. Ultimately, a dynamic test report is generated that includes test results, problem analysis, and recommendations.

[0086] In one possible implementation, S400 , performing absolute offset analysis on the target ECU based on value change data of relevant registers to determine a dynamic test report of the target ECU firmware includes:

[0087] S410 , performing position offset calculation based on the value change data of the relevant register to obtain absolute offset data of the memory protection unit of the relevant register.

[0088] It's understandable that an address offset calculation algorithm can be used to calculate the absolute offset of the memory protection unit based on the value changes of the relevant registers and the memory mapping rules of the target ECU. For example, if the register value represents the offset of the memory address and the base address of the memory protection unit is known, the absolute offset data can be obtained by performing an operation (such as addition or subtraction) on the register's change value and the base address. The absolute offset reflects the actual offset of the memory location pointed to by the relevant register in the memory space.

[0089] S420: Obtain a memory base address of a memory protection unit of a related register.

[0090] As you can understand, the memory base address is the starting address of the memory area managed by the Memory Protection Unit (MPU). This memory base address can be obtained by reading it from the target ECU's system configuration information, which may be stored in a specific memory area or set by the simulation environment's initialization parameters. Alternatively, the Memory Protection Unit's memory base address can be extracted by parsing the target ECU's startup code or related configuration files, providing the basis for subsequent calculation of the absolute starting address.

[0091] S430: Calculate an absolute start address based on the absolute offset data of the memory protection unit and the memory base address, and determine a dynamic test report of the target ECU firmware.

[0092] As you can understand, by adding the absolute offset data to the memory base address, you can obtain the absolute starting address of the relevant data in the memory protection unit. Based on this absolute starting address, you can analyze whether the target ECU firmware's memory access is legal during operation and whether there are any abnormalities such as out-of-bounds access. If an abnormality is found, the abnormality information is recorded in the dynamic test report, including the abnormality type, location, and relevant register information. If no abnormality is found, the report indicates that memory access is normal, thus completing the dynamic test report.

[0093] Optionally, S430, calculating an absolute start address based on the absolute offset data of the memory protection unit and the memory base address, and determining a dynamic test report of the target ECU firmware, includes:

[0094] S431, adding the absolute offset data of the memory protection unit and the memory base address to obtain corresponding configuration data of the memory protection unit.

[0095] It can be understood that the calculated absolute offset data can be added to the obtained memory base address using an addition algorithm. The result is the corresponding configuration data of the relevant data in the memory protection unit, which represents the actual location configuration information in the memory and provides key data for subsequent analysis of memory access.

[0096] S432: Perform an abnormality risk analysis based on the corresponding configuration data of the memory protection unit to determine a dynamic test report for the target ECU firmware.

[0097] As can be understood, a boundary checking algorithm can be used to compare the corresponding configuration data with the boundary range set by the memory protection unit. If the configuration data exceeds the legal memory range, it is determined that there is a memory out-of-bounds risk and recorded in the dynamic test report. At the same time, the access rights to the memory area corresponding to the configuration data can also be checked. If the current operation permissions do not match the configured permissions, it is also recorded as an abnormal situation. Based on the results of the abnormal risk analysis, a dynamic test report containing a detailed problem description and risk level is generated, providing a basis for evaluating the quality and stability of the target ECU firmware, thereby shortening the development and testing cycle and reducing dependence on scarce resources and actual hardware. In addition, through dynamic simulation methods, developers can observe and modify memory variables and even hardware status at any time, greatly improving work efficiency.

[0098] Corresponding to the dynamic simulation method of the vehicle-mounted ECU firmware in the above embodiment, the embodiment of the present application also provides a dynamic simulation system of the vehicle-mounted ECU firmware, and each unit of the system can implement each step of the dynamic simulation method of the vehicle-mounted ECU firmware. Figure 5 A structural block diagram of a dynamic simulation system for vehicle-mounted ECU firmware provided in an embodiment of the present application is shown. For ease of explanation, only the parts related to the embodiment of the present application are shown.

[0099] Reference Figure 5 The dynamic simulation system of the vehicle ECU firmware includes:

[0100] An acquisition unit, used to acquire firmware data of a target ECU;

[0101] a customization unit, configured to perform instruction translation on the firmware data of the target ECU and determine simulation customization parameters corresponding to the target ECU; wherein the simulation customization parameters are used to perform architecture adaptation on the target ECU;

[0102] a simulation unit, configured to dynamically simulate the firmware data of the target ECU according to the simulation customization parameters, and monitor the relevant register data of the target ECU through a preset callback function to obtain value change data of the relevant register;

[0103] A result unit is used to perform absolute offset analysis on the target ECU based on the value change data of the relevant register to determine a dynamic test report of the target ECU firmware.

[0104] It should be noted that the information interaction, execution process, etc. between the above-mentioned systems / units are based on the same concept as the method embodiment of this application. Their specific functions and technical effects can be found in the method embodiment section and will not be repeated here.

[0105] Those skilled in the art can clearly understand that, for the convenience and brevity of description, only the division of the above-mentioned functional units and modules is used as an example for illustration. In actual applications, the above-mentioned functions can be distributed and completed by different functional units and modules as needed, that is, the internal structure of the system can be divided into different functional units or modules to complete all or part of the functions described above. The functional units and modules in the embodiment can be integrated into one processing unit, or each unit module can exist physically alone, or two or more unit modules can be integrated into one unit. The above-mentioned integrated unit can be implemented in the form of hardware or in the form of software functional units. In addition, the specific names of the functional units and modules are only for the convenience of distinguishing each other and are not used to limit the scope of protection of this application. The specific working process of the units and modules in the above-mentioned system can refer to the corresponding process in the aforementioned method embodiment, which will not be repeated here.

[0106] The embodiment of the present application also provides an electronic device, Figure 6 This is a schematic diagram of the structure of an electronic device provided in one embodiment of the present application. Figure 6 As shown, the electronic device 6 of this embodiment includes: at least one processor 60 ( Figure 6 Only one is shown), at least one memory 61 ( Figure 6 Only one is shown) and a computer program 62 stored in the at least one memory 61 and executable on the at least one processor 60. When the processor 60 executes the computer program 62, the electronic device 6 implements the steps of any of the above-mentioned embodiments of the dynamic simulation method for vehicle-mounted ECU firmware, or implements the functions of each unit in the above-mentioned system embodiments.

[0107] For example, the computer program 62 may be divided into one or more units, which are stored in the memory 61 and executed by the processor 60 to implement the present application. The one or more units may be a series of computer program instruction segments capable of implementing specific functions, and the instruction segments are used to describe the execution process of the computer program 62 in the electronic device 6.

[0108] The electronic device 6 can be a computing device or terminal device such as a desktop computer, a notebook, a PDA, or a cloud server. The electronic device may include, but is not limited to, a processor 60 and a memory 61. Those skilled in the art will understand that Figure 6 It is only an example of the electronic device 6 and does not constitute a limitation on the electronic device 6. It may include more or fewer components than shown in the figure, or a combination of certain components, or different components. For example, it may also include input and output devices, network access devices, buses, etc.

[0109] The processor 60 may be a central processing unit (CPU), or other general-purpose processors, digital signal processors (DSP), application-specific integrated circuits (ASIC), field-programmable gate arrays (FPGA), or other programmable logic devices, discrete gate or transistor logic devices, discrete hardware components, etc. A general-purpose processor may be a microprocessor or any conventional processor.

[0110] In some embodiments, the memory 61 may be an internal storage unit of the electronic device 6, such as a hard drive or memory of the electronic device 6. In other embodiments, the memory 61 may also be an external storage device of the electronic device 6, such as a plug-in hard drive, a Smart Media Card (SMC), a Secure Digital (SD) card, a flash memory card, etc. equipped on the electronic device 6. Furthermore, the memory 61 may include both an internal storage unit of the electronic device 6 and an external storage device. The memory 61 is used to store an operating system, application programs, a boot loader, data, and other programs, such as the program code of the computer program. The memory 61 may also be used to temporarily store data that has been output or is about to be output.

[0111] An embodiment of the present application further provides a computer-readable storage medium, wherein the computer-readable storage medium stores a computer program, and when the computer program is executed by a processor, the steps in any of the above method embodiments are implemented.

[0112] An embodiment of the present application provides a computer program product. When the computer program product is run on an electronic device, the electronic device implements the steps of any of the above method embodiments.

[0113] If the integrated unit is implemented as a software functional unit and sold or used as a standalone product, it can be stored in a computer-readable storage medium. Based on this understanding, the present application implements all or part of the process steps in the above-mentioned method embodiments by instructing the relevant hardware through a computer program. The computer program can be stored in a computer-readable storage medium. When executed by a processor, the computer program can implement the steps of each of the above-mentioned method embodiments. The computer program includes computer program code, which can be in source code form, object code form, executable file, or some intermediate form. The computer-readable medium can include at least: any entity or device capable of carrying computer program code to an electronic device, recording medium, computer memory, read-only memory (ROM), random access memory (RAM), electric carrier signals, telecommunication signals, and software distribution media. Examples include USB flash drives, removable hard drives, magnetic disks, or optical disks. In some jurisdictions, based on legislation and patent practice, computer-readable media cannot be electric carrier signals or telecommunication signals.

[0114] In the above embodiments, the description of each embodiment has its own focus. For parts that are not described or recorded in detail in a certain embodiment, reference can be made to the relevant description of other embodiments.

[0115] Those skilled in the art will appreciate that the units and algorithm steps of each example described in conjunction with the embodiments disclosed herein can be implemented in electronic hardware, or a combination of computer software and electronic hardware. Whether these functions are performed in hardware or software depends on the specific application and design constraints of the technical solution. Professional and technical personnel can use different methods to implement the described functions for each specific application, but such implementation should not be considered beyond the scope of this application.

[0116] In the embodiments provided in the present application, it should be understood that the disclosed dynamic simulation system / electronic device and method for vehicle-mounted ECU firmware can be implemented in other ways. For example, the above-described embodiment of the dynamic simulation system / electronic device for vehicle-mounted ECU firmware is merely illustrative. For example, the division of the units is merely a logical function division. In actual implementation, there may be other division methods, such as multiple units or components can be combined or integrated into another system, or some features can be ignored or not executed. Another point is that the mutual coupling or direct coupling or communication connection shown or discussed can be an indirect coupling or communication connection through some interfaces, devices or units, which can be electrical, mechanical or other forms.

[0117] The units described as separate components may or may not be physically separate, and the components shown as units may or may not be physical units, that is, they may be located in one place or distributed across multiple network units. Some or all of these units may be selected to achieve the purpose of this embodiment according to actual needs.

[0118] The above-described embodiments are only used to illustrate the technical solutions of the present application, rather than to limit them. Although the present application has been described in detail with reference to the aforementioned embodiments, those skilled in the art should understand that they can still modify the technical solutions described in the aforementioned embodiments, or make equivalent replacements for some of the technical features therein. These modifications or replacements do not deviate the essence of the corresponding technical solutions from the spirit and scope of the technical solutions of the various embodiments of the present application, and should all be included in the scope of protection of the present application.

Claims

1. A dynamic simulation method for vehicle-mounted ECU firmware, characterized in that: include: Get the firmware data of the target ECU; Performing instruction translation on the firmware data of the target ECU to determine simulation customization parameters corresponding to the target ECU; wherein the simulation customization parameters are used to perform architecture adaptation on the target ECU; Dynamically simulating the firmware data of the target ECU according to the simulation customization parameters, and monitoring the relevant register data of the target ECU through a preset callback function to obtain value change data of the relevant register; Performing absolute offset analysis on the target ECU based on the value change data of the relevant register to determine a dynamic test report of the target ECU firmware; Wherein, the preset callback function includes a first preset callback function and a second preset callback function; The relevant register data of the target ECU is monitored by a preset callback function to obtain the value change data of the relevant register, including: Performing a read register operation on a relevant register of the target ECU through a first preset callback function to obtain first return data of the target ECU; Performing a write register operation on a relevant register of the target ECU through a second preset callback function to obtain second return data of the target ECU; According to the first return data and the second return data of the target ECU, the value change data of the relevant register is obtained.

2. The dynamic simulation method of vehicle-mounted ECU firmware according to claim 1, characterized in that: Performing instruction translation on the firmware data of the target ECU to determine simulation customization parameters corresponding to the target ECU includes: Performing instruction translation on the firmware data of the target ECU to determine the instruction translation completion degree of the target ECU; wherein the instruction translation completion degree has a value interval of [0, 1]; When the value of the instruction translation completion degree is equal to 1, determining the default simulation customization parameters as the simulation customization parameters corresponding to the target ECU; When the value of the instruction translation completion degree is not equal to 1, simulation parameters are customized according to the firmware data to determine simulation customization parameters corresponding to the target ECU.

3. The dynamic simulation method of vehicle-mounted ECU firmware according to claim 2, characterized in that: The performing instruction translation on the firmware data of the target ECU and determining the instruction translation completion degree of the target ECU includes: performing instruction translation on the firmware data of the target ECU, and counting the total number of instructions in the firmware data and the number of completed instructions of the successfully translated instructions; A ratio calculation is performed based on the number of completed instructions and the total number of instructions to determine the completion degree of instruction translation of the target ECU.

4. The method for dynamic simulation of vehicle-mounted ECU firmware according to claim 3, wherein: Customizing simulation parameters according to the firmware data to determine simulation customization parameters corresponding to the target ECU includes: Obtaining, according to the firmware data, an abnormal instruction set of all instructions in the firmware data that have not been translated; Traversing all instructions in the abnormal instruction set to determine abnormal type data of each instruction in the abnormal instruction set; Merging duplicate items of the exception type data of each instruction in the exception instruction set to obtain an exception type table corresponding to the exception instruction set; Simulation parameters are customized based on the abnormal type table corresponding to the abnormal instruction set, and simulation customization parameters corresponding to the target ECU are determined.

5. The method for dynamic simulation of vehicle-mounted ECU firmware according to claim 1, wherein: The step of performing a register read operation on a relevant register of the target ECU through a first preset callback function to obtain first return data of the target ECU includes: Performing a register read operation on a relevant register of the target ECU, and determining a first characteristic data segment of a memory protection unit of the relevant register based on a memory protection unit data characteristic; The first characteristic data segment of the memory protection unit of the relevant register is read relative to the position through a first preset callback function to obtain first return data of the target ECU.

6. The method for dynamic simulation of vehicle-mounted ECU firmware according to claim 1, wherein: The step of performing a write register operation on a relevant register of the target ECU through a second preset callback function to obtain second return data of the target ECU includes: Performing a write register operation on a relevant register of the target ECU, and determining a second characteristic data segment of a memory protection unit of the relevant register based on a memory protection unit data characteristic; The second characteristic data segment of the memory protection unit of the relevant register is read relative to the position through the first preset callback function to obtain the second return data of the target ECU.

7. The method for dynamic simulation of vehicle-mounted ECU firmware according to claim 1, wherein: The performing absolute offset analysis on the target ECU based on the value change data of the relevant register to determine a dynamic test report of the target ECU firmware includes: Performing position offset calculation based on the value change data of the relevant register to obtain absolute offset data of the memory protection unit of the relevant register; Obtaining a memory base address of the memory protection unit of the relevant register; An absolute starting address is calculated according to the absolute offset data of the memory protection unit and the memory base address, and a dynamic test report of the target ECU firmware is determined.

8. The method for dynamic simulation of vehicle-mounted ECU firmware according to claim 7, wherein: The step of calculating an absolute start address according to the absolute offset data of the memory protection unit and the memory base address, and determining a dynamic test report of the target ECU firmware, includes: Adding the absolute offset data of the memory protection unit and the memory base address to obtain corresponding configuration data of the memory protection unit; An abnormality risk analysis is performed based on the corresponding configuration data of the memory protection unit to determine a dynamic test report of the target ECU firmware.

9. An electronic device comprising a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein: When the processor executes the computer program, the method according to any one of claims 1 to 8 is implemented.

Images