Dynamic simulation method and device for vehicle-mounted ECU firmware

Abstract

The invention is suitable for the technical field of ECU testing, and particularly relates to a dynamic simulation method and device for vehicle-mounted ECU firmware, and the method comprises the steps: obtaining firmware data of a target ECU, and providing basic data information for subsequent analysis and testing; instruction translation is carried out on firmware data of the target ECU, and simulation customization parameters corresponding to the target ECU are determined, so that the running state of the target ECU can be accurately simulated in a subsequent simulation environment; performing dynamic simulation on firmware data of the target ECU according to the simulation customization parameters, and monitoring related register data of the target ECU through a preset callback function to obtain numerical value change data of a related register so as to provide key data for evaluating the operation stability and accuracy of the target ECU; the absolute offset analysis is carried out on the target ECU based on the numerical value change data of the related register, the dynamic test report of the target ECU firmware is determined, the detailed and targeted dynamic test report is generated, the development and test period is shortened, the development and test efficiency is improved, and the cost is reduced.

Description

Technical Field

[0001] This application belongs to the technical field of ECU testing, and particularly relates to a method and device for dynamically simulating in-vehicle ECU firmware. Background Art

[0002] With the rapid development of automotive electronics technology, the automotive electronic and electrical architecture has evolved from a distributed architecture to a domain centralized and central computing platform architecture. In the distributed architecture, each function is usually completed by an independent ECU, which leads to problems such as a complex wiring harness network, high system integration difficulty, and difficult maintenance and upgrade. To solve these pain points, the automotive electronic and electrical architecture has gradually developed towards domain centralization and central computing platforms, reducing the number of ECUs per vehicle, but the complexity of tasks that a single ECU needs to handle has increased significantly.

[0003] During the development and testing process of in-vehicle ECU firmware, the traditional development and testing process has problems such as a long iteration time, being restricted by prototype vehicles and testing equipment, and lacking effective development and testing tools, resulting in a long development and testing cycle, low efficiency, and high testing hardware costs. Summary of the Invention

[0004] Embodiments of this application provide a method and device for dynamically simulating in-vehicle ECU firmware, which can solve the problems of a long development and testing cycle, low efficiency, and high testing hardware costs in the development and testing process of in-vehicle ECUs due to the lack of effective development and testing tools.

[0005] In a first aspect, embodiments of this application provide a method for dynamically simulating in-vehicle ECU firmware, including: Obtaining the firmware data of the target ECU; Performing instruction translation on the firmware data of the target ECU to determine the simulation customization parameters corresponding to the target ECU; wherein, the simulation customization parameters are used for architecture adaptation of the target ECU; Performing dynamic simulation on 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; Performing absolute offset analysis on the target ECU based on the numerical change data of the relevant registers to determine the dynamic test report of the target ECU firmware.

[0006] The above technical solutions in the embodiments of this application have at least the following technical effects: The dynamic simulation method for in-vehicle ECU firmware provided by the embodiments of the present application obtains the firmware data of the target ECU, providing basic data for subsequent in-depth analysis and testing of the target ECU, and comprehensively understanding the original operation logic and configuration information of the target ECU. Instruction translation is performed on the firmware data of the target ECU to determine the simulation customization parameters corresponding to the target ECU, enabling the subsequent simulation environment to accurately simulate the operating state of the target ECU. Dynamic simulation is performed on the firmware data of the target ECU according to the simulation customization parameters, and the numerical change data of the relevant registers of the target ECU is monitored through a preset callback function, obtaining the numerical change data of the relevant registers, providing key data for evaluating the operating stability and accuracy of the target ECU. Absolute offset analysis is performed on the target ECU based on the numerical change data of the relevant registers to determine the dynamic test report of the target ECU firmware, accurately analyzing the offset of the register numerical changes, comprehensively evaluating the performance and potential risks of the target ECU firmware, generating a detailed and targeted dynamic test report, providing a strong basis for the optimization and improvement of the firmware, reducing the development and test cycle, improving the development and test efficiency, and reducing costs.

[0007] In a second aspect, the embodiments of the present application provide a dynamic simulation system for in-vehicle ECU firmware, including: An acquisition unit for acquiring the firmware data of the target ECU; A customization unit for performing instruction translation on the firmware data of the target ECU to determine the simulation customization parameters corresponding to the target ECU; wherein, the simulation customization parameters are used for architecture adaptation of the target ECU; A simulation unit for performing dynamic simulation on the firmware data of the target ECU according to the simulation customization parameters, and monitoring the numerical change data of the relevant registers of the target ECU through a preset callback function, obtaining the numerical change data of the relevant registers; A result unit for performing absolute offset analysis on the target ECU based on the numerical change data of the relevant registers to determine the dynamic test report of the target ECU firmware.

[0008] In a third aspect, the embodiments of the present application provide an electronic device, including a memory, a processor, and a computer program stored in the memory and executable on the processor, and when the processor executes the computer program, the method described in any one of the above aspects is implemented.

[0009] In a fourth aspect, the embodiments of the present application provide a computer program product, which when running on an electronic device, causes the electronic device to execute the method described in any one of the above aspects.

[0010] It should be understood that for the beneficial effects of the above second to fourth aspects, reference may be made to the relevant descriptions in the above aspects, and details are not elaborated herein. BRIEF DESCRIPTION OF THE DRAWINGS

[0011] To 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 the description of the prior art. Obviously, the drawings in the following description are only some embodiments of the present application. For those of ordinary skill in the art, without creative efforts, other drawings can also be obtained based on these drawings.

[0012] Figure 1 is a schematic flowchart of a method for dynamically simulating in-vehicle ECU firmware provided by an embodiment of the present application; Figure 2 is a schematic operation diagram of a method for dynamically simulating in-vehicle ECU firmware provided by an embodiment of the present application; Figure 3 is a partial schematic diagram of a method for dynamically simulating in-vehicle ECU firmware provided by an embodiment of the present application; Figure 4 is a partial schematic diagram of a method for dynamically simulating in-vehicle ECU firmware provided by an embodiment of the present application; Figure 5 is a partial schematic diagram of a system for dynamically simulating in-vehicle ECU firmware provided by an embodiment of the present application Figure 6 is a schematic structural diagram of an electronic device provided by an embodiment of the present application. DETAILED DESCRIPTION OF THE EMBODIMENTS

[0013] In the following description, for the purpose of illustration rather than limitation, specific details such as specific system structures and technologies are presented to thoroughly understand the embodiments of the present application. However, those skilled in the art should clearly understand that the present application can also 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 unnecessary details from interfering with the description of the present application.

[0014] It should be understood that when used in the specification and the appended claims of the present application, the term "comprising" indicates the presence of the described features, wholes, steps, operations, elements, and / or components, but does not exclude the presence or addition of one or more other features, wholes, steps, operations, elements, components, and / or their combinations.

[0015] It should also be understood that the term "and / or" used in the specification and the appended claims of the present application refers to any combination and all possible combinations of one or more of the associated listed items, and includes these combinations.

[0016] As used in the specification of this application and the appended claims, the term "if" can be construed, depending on the context, as "when" or "once" or "in response to determining" or "in response to detecting". Similarly, the phrase "if determined" or "if the described condition or event is detected" can be construed, depending on the context, to mean "once determined" or "in response to determining" or "once the described condition or event is detected" or "in response to detecting the described condition or event".

[0017] In addition, in the description of the specification of this application and the appended claims, the terms "first", "second", "third", etc. are used only for distinguishing descriptions and cannot be construed as indicating or implying relative importance.

[0018] Reference to "one embodiment" or "some embodiments" or the like described in the specification of this application means that a particular feature, structure, or characteristic described in connection with that embodiment is included in one or more embodiments of this application. Thus, statements such as "in one embodiment", "in some embodiments", "in other some embodiments", "in still other embodiments", etc. that appear in different places in this specification do not necessarily all refer to the same embodiment, but mean "one or more but not all embodiments", unless otherwise specifically emphasized in other ways. The terms "comprising", "including", "having", and their variants all mean "including but not limited to", unless otherwise specifically emphasized in other ways.

[0019] In the development process of in-vehicle ECU firmware, the traditional development process has problems such as long iteration time and being restricted by prototype vehicles and test equipment. This patent combines the QEMU simulator and proposes a dynamic simulation method for in-vehicle ECU firmware, which better improves the test effect and efficiency and also reduces the test cost. The dynamic simulation method can simulate the operating environment of the ECU, enabling developers to simulate, calibrate, and measure software on a PC, thereby shortening the development cycle and reducing the dependence on scarce resources and actual hardware. In addition, through the dynamic simulation method, developers can observe and modify memory variables and even hardware states at any time, greatly improving work efficiency.

[0020] To solve the above problems, an embodiment of the present application provides a method and device for dynamically simulating in-vehicle ECU firmware. In this method, by obtaining the firmware data of the target ECU, it provides basic data for subsequent in-depth analysis and testing of the target ECU, and comprehensively understands the original operation logic and configuration information of the target ECU. Instruction translation is performed on the firmware data of the target ECU to determine the simulation customization parameters corresponding to the target ECU, so that the subsequent simulation environment can accurately simulate the operating state of the target ECU. Dynamic simulation is performed on the firmware data of the target ECU 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, absolute offset analysis is performed on the target ECU to determine the dynamic test report of the target ECU firmware, accurately analyze the offset of the register numerical changes, comprehensively evaluate the performance and potential risks of the target ECU firmware, generate a detailed and targeted dynamic test report, provide a strong basis for the optimization and improvement of the firmware, reduce the development and test cycle, improve the development and test efficiency, and reduce costs.

[0021] The method for dynamically simulating in-vehicle ECU firmware provided by an embodiment of the present application can be applied to an electronic device. At this time, the electronic device is the execution subject of the method for dynamically simulating in-vehicle ECU firmware provided by an embodiment of the present application. The specific type of the electronic device is not limited in any way in the embodiment of the present application.

[0022] For example, the electronic device can 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.

[0023] To better understand the method for dynamically simulating in-vehicle ECU firmware provided by an embodiment of the present application, the following provides an exemplary introduction to the specific implementation process of the method for dynamically simulating in-vehicle ECU firmware provided by an embodiment of the present application.

[0024] Figure 1 The schematic flowchart of the method for dynamically simulating in-vehicle ECU firmware provided by an embodiment of the present application is shown. Figure 2 The operation schematic diagram of the method for dynamically simulating in-vehicle ECU firmware provided by an embodiment of the present application is shown. The method for dynamically simulating in-vehicle ECU firmware includes: S100, obtaining the firmware data of the target ECU.

[0025] It can be understood that the firmware data of the target ECU can be obtained through various means. For example, it can be obtained through an ECU programmer, which connects to the target ECU using its adapted interface and reads the firmware data directly from the storage chip of the ECU according to a specific communication protocol, such as the CAN (Controller Area Network) protocol. It can also be obtained through the automotive diagnostic interface by sending a data reading instruction to the ECU according to the OBD (On-Board Diagnostics) standard protocol. Additionally, the corresponding firmware data can be downloaded from the official database provided by the automotive manufacturer based on the model and version information of the ECU.

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

[0027] It can be understood that instruction translation is to convert the binary instructions in the target ECU firmware into a form that is convenient for analysis and processing. The binary instructions in the ECU firmware can be run through professional chip simulation tools (such as QEMU, ModelSim, Vivado Simulator, etc.) and the chip operation data can be recorded. A mapping table containing the instruction set of the target ECU can be constructed based on the look-up table method of the instruction set architecture (ISA). Each binary instruction in the table records the corresponding operation code, operand, and the corresponding high-level language instruction description. During translation, the mapping table is searched according to the binary instruction for conversion. It can also be achieved through a syntax analysis algorithm. According to the syntax rules of the target ECU instruction set, lexical and syntactic parsing of the instructions in the firmware data is performed to identify each part of the instruction, thereby completing the translation. When determining the analog customization parameters, the architecture requirements of the target ECU can be analyzed based on the translated instruction information, such as determining parameters such as the required clock frequency, memory allocation mode, and peripheral interface configuration, so that the subsequent simulation environment is adapted to the actual architecture of the target ECU.

[0028] In a possible implementation, S200, perform instruction translation on the firmware data of the target ECU to determine the analog customization parameters corresponding to the target ECU, including: S210, perform instruction translation on the firmware data of the target ECU to determine the instruction translation completion degree of the target ECU; wherein, the value range of the instruction translation completion degree is [0, 1].

[0029] It can be understood that simulation test tools such as QEMU can be used to simulate the operation of the target ECU by translating instructions. When translating instructions for the firmware data of the target ECU, a byte-by-byte parsing algorithm can be adopted. Starting from the starting position of the firmware data, read the data byte by byte, and gradually parse the instructions corresponding to each byte according to the instruction set rules of the target ECU. An algorithm based on a sliding window can also be used, setting a fixed-size window and sliding the window over the firmware data, and parsing the instructions according to the data within the window each time. When determining the completion degree of instruction translation, it can be measured by counting the translation progress. If an unrecognized instruction is encountered during the translation process, the statistics are paused and continued after the exception is processed.

[0030] Optionally, in S210, translating the instructions for the firmware data of the target ECU and determining the completion degree of the instruction translation of the target ECU includes: S211, translating the instructions for 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.

[0031] It can be 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, traverse the firmware data segment by segment according to the instruction length rule. Each time an instruction is recognized, the total number of instruction counter is incremented by 1. During the translation process, for the successfully parsed instructions, the completed instruction counter is incremented by 1. If an unrecognized instruction is encountered, its position can be marked and the total number of instructions is continued to be counted backward to ensure the integrity of the statistics for subsequent accurate calculation of the instruction translation completion degree.

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

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

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

[0035] It can be understood that the default simulation customization parameters are a set of parameters pre-set for most common situations. When the instruction translation completion degree is 1, that is, all instructions in the firmware data have been successfully translated. At this time, it is considered that the current default simulation customization parameters can meet the simulation requirements of the target ECU, and there is no need for additional parameter customization. Directly assigning the default parameters to the simulation customization parameters corresponding to the target ECU can improve the processing efficiency and reduce unnecessary consumption of computing resources.

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

[0037] It can be understood that when there is an unfinished instruction translation, 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. For the untranslated instructions, study their compatibility with the target ECU architecture, starting from aspects such as instruction functions, operand types, and execution conditions, to determine the simulation parameters that need to be adjusted or added to ensure that the simulation environment can accurately simulate the operation of the target ECU. For example, for complex heterogeneous ECU chips and special detection requirements, the original Qemu can be customized and optimized. The architectures natively supported by Qemu are mostly general architectures, such as ARM, and do not support peripherals such as MPU. Therefore, the ARM version and Tricore version of Qemu with MPU functions can be extended. Please refer to Figure 3 ; Individual instructions in the native Qemu version are translated incorrectly or not translated at all, resulting in abnormal firmware operation. Therefore, multiple corresponding instructions can be supplemented through template matching.

[0038] Optionally, S230. Customize the simulation parameters according to the firmware data to determine the simulation customization parameters corresponding to the target ECU, including: S231. Obtain the abnormal instruction set of all untranslated instructions in the firmware data according to the firmware data.

[0039] It can be understood that during the translation process, when encountering instructions that cannot be parsed according to the existing instruction set rules, these instructions can be collected into a set to form an abnormal instruction set. The traversal marking algorithm can be used. When translating instructions, each instruction is judged. If the translation fails, it is marked and added to the abnormal instruction set. At the same time, record the position information of the instruction in the firmware data to facilitate subsequent detailed analysis of the abnormal instructions.

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

[0041] It can be understood that when traversing the set of exception instructions, a feature matching algorithm can be used to match the binary code features, instruction length, operand position, etc. of the exception instructions with the predefined exception type templates. For example, if the opcode of an instruction cannot be recognized, it can be classified as an "unknown opcode exception"; if the operand format of an instruction 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 exception instruction for subsequent targeted processing.

[0042] S233. Merge the duplicate items of the exception type data of each instruction in the set of exception instructions to obtain the exception type table corresponding to the set of exception instructions.

[0043] It can be understood that a hash table statistical algorithm can be used to traverse the exception type data of each instruction in the set of exception instructions, construct 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, an exception type table is generated based on the hash table, which records each exception type and its number of occurrences, so that the distribution of exception instructions can be understood more clearly, facilitating the centralized processing of the main exception types.

[0044] S234. Based on the exception type table corresponding to the set of exception instructions, perform simulation parameter customization to determine the simulation customization parameters corresponding to the target ECU.

[0045] It can be understood that the simulation parameters are adjusted according to the characteristics and occurrence frequencies of different exception types in the exception type table. For the frequently occurring "memory access exception" type, the simulation parameters related to memory management can be adjusted, such as adding memory address verification rules and adjusting the memory allocation strategy; for the "unknown instruction exception", the instruction set parsing rules can be extended, or special simulation processing logic can be set to ensure that the behavior of these exception instructions can be correctly simulated, and finally the simulation customization parameters suitable for the target ECU are determined for dynamic customization of QEMU.

[0046] 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 numerical change data of the relevant registers.

[0047] It can be understood that during the process of simulating the firmware data of the target ECU by QEMU customized according to the simulation customization parameters, please refer to Figure 4, a preset callback function can be triggered when an instruction related to register operation is executed. Regarding the execution algorithm of the preset callback function, for the register read operation, one algorithm is to directly read data from the simulated register storage area; for the register write operation, one algorithm is to first check the legality of the write operation, such as whether the address is out of bounds and whether the data format is correct. If it is 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. Here, the register is a high-speed storage unit inside the CPU used to temporarily store the data and operation results involved in the operation, and plays a key role in data storage and processing during the operation of the ECU.

[0048] The preset callback function is a type of special function that is preset and is used to be called when a specific event occurs to implement the monitoring, processing, or other specific functions of the relevant data of the target object. The preset callback function includes the first preset callback function and the second preset callback function. The first preset callback function is mainly used to perform a register read operation on the relevant registers of the target ECU to obtain the return value of the register read operation of the target ECU. The return value of the register read operation is the first return data, and the first return data can provide a basis for analyzing the current value of the register. The second preset callback function is mainly responsible for performing a register write operation on the relevant registers of the target ECU and obtaining the return value of the register write operation of the target ECU. The return value of the register write operation is the second return data. When dynamically simulating the firmware data of the target ECU, when the simulation process executes an instruction related to register operation, the corresponding preset callback function can be automatically triggered. The preset callback function executes operations according to the preset algorithm, such as address mapping, data verification, offset calculation, etc., so as to effectively monitor and process the register data, and provide support for subsequent obtaining the numerical change data of the relevant registers, performing absolute offset analysis, and generating a dynamic test report.

[0049] The preset callback function includes the first preset callback function and the second preset callback function; in step S300, the relevant register data of the target ECU is monitored through the preset callback function to obtain the numerical change data of the relevant registers, including: S310, perform a register read operation on the relevant registers of the target ECU through the first preset callback function to obtain the first return data of the target ECU.

[0050] It can be understood that when performing a register read operation, an address mapping algorithm can be adopted. According to the register address mapping relationship of the target ECU, the logical register address is converted into the actual memory address. The corresponding data can be read from the simulated memory area as the return value. When the first preset callback function is triggered, a read operation is performed according to this address mapping rule, and the read data is passed out as the first return data.

[0051] Optionally, in S310, a register read operation is performed on the relevant registers of the target ECU through the first preset callback function to obtain the first return data of the target ECU, including: In S311, a register read operation is performed on the relevant registers of the target ECU, and the first characteristic data segment of the memory protection unit of the relevant registers is determined based on the data characteristics of the memory protection unit.

[0052] It can be understood that the memory protection unit (MPU, Memory Protection Unit, is a hardware unit used to protect the security of memory areas, which can set the access permissions of different memory areas to prevent illegal memory access) 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 registers are located is determined according to the access permissions and data characteristic identifiers set by the memory protection unit. For example, the memory protection unit may set different read / write permission bits, data type identifier bits, etc. By parsing this bit information, the characteristics such as the start address, length, and access permissions of the first characteristic data segment are determined, providing a basis for accurately reading data subsequently.

[0053] In S312, a relative position read is performed on the first characteristic data segment of the memory protection unit of the relevant registers through the first preset callback function to obtain the first return data of the target ECU.

[0054] It can be understood that after determining the first characteristic data segment, a read operation is performed according to the relative position of the register in this data segment. An offset calculation algorithm is adopted to add the start address of the characteristic data segment and the relative offset address of the register to obtain the actual read address. The first preset callback function reads data from the simulated memory according to this calculated address and uses it as the first return data of the target ECU to ensure that the read data accurately reflects the current value of the relevant register.

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

[0056] It can be understood that when writing register operations, a data verification algorithm can be adopted to first verify the data to be written in terms of format, range, etc. 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 written to the simulated register memory area according to the register address. After the second preset callback function executes the write operation, it will return a second return data representing the operation result, which can include information such as whether the write is successful and whether a memory protection exception is triggered.

[0057] Optionally, S320, perform a write register operation on the relevant registers of the target ECU through the second preset callback function to obtain the second return data of the target ECU, including: S321, perform a write register operation on the relevant registers of the target ECU, and determine the second characteristic data segment of the memory protection unit of the relevant registers based on the data characteristics of the memory protection unit.

[0058] It can be understood that similar to the read register operation, when writing a register, the second characteristic data segment of the memory area where the relevant register is located is determined according to the data characteristics of the memory protection unit. By parsing information such as the permission control bits and data type identifiers in the memory protection unit, the characteristics such as the boundary and access rules of this data segment can be clarified to ensure that the write operation is performed within a legal memory area and avoid simulation errors caused by illegal writing.

[0059] S322, perform a relative position read on the second characteristic data segment of the memory protection unit of the relevant register through the first preset callback function to obtain the second return data of the target ECU.

[0060] It can be understood that after the write operation is completed, in order to obtain the result information of the write operation, a relative position read is performed on the second characteristic data segment of the memory protection unit of the relevant register through the first preset callback function. The same offset calculation method as the read operation can be adopted to calculate the address to be read and read the data from the simulated memory. These data can include information such as the value of the register after writing and the state change of the memory protection unit, and are used as the second return data of the target ECU for subsequent analysis of the execution situation of the write operation.

[0061] S330, obtain the numerical change data of the relevant register according to the first return data and the second return data of the target ECU.

[0062] It can be understood that a data comparison algorithm can be used to compare the first return data (the value of the register before the read operation) with the second return data (the value of the register after the write operation). If the two data are different, calculate the difference or change between them and record it as the numerical change data of the relevant register. For example, for a numerical register, calculate the difference between the second return data minus the first return data; for a flag register, analyze which flag bits have changed. Through this comparison, the numerical change of the register during the read and write operations can be clearly obtained, providing data support for subsequent absolute offset analysis.

[0063] S400, perform absolute offset analysis on the target ECU based on the numerical change data of the relevant registers to determine the dynamic test report of the target ECU firmware.

[0064] It can be understood that the purpose of absolute offset analysis is to determine the actual offset position of the register data in memory to evaluate the accuracy and stability of the ECU firmware operation. It can be based on the offset calculation method of the memory mapping. According to the memory mapping table of the target ECU (memory mapping is the process of establishing a correspondence between the logical address space in the program and the physical memory address space, and the memory mapping table records this correspondence), associate the numerical change data of the register with the memory address and calculate the absolute offset. It can also derive the absolute offset by tracking the operation sequence of the register and the memory access pattern during the instruction execution process and combining the memory base address information. When determining the dynamic test report, based on the results of the absolute offset analysis, it is judged whether the register data changes within the expected memory range and whether there are abnormal offset situations, so as to evaluate whether there are potential errors or risks in the ECU firmware, and finally generate a dynamic test report including test results, problem analysis, and suggestions.

[0065] In a possible implementation, S400, perform absolute offset analysis on the target ECU based on the numerical change data of the relevant registers to determine the dynamic test report of the target ECU firmware, including: S410, calculate the position offset based on the numerical change data of the relevant registers to obtain the absolute offset data of the memory protection unit of the relevant register.

[0066] It can be understood that an address offset calculation algorithm can be used to calculate the absolute offset of the memory protection unit according to the numerical change of the relevant register and the memory mapping rule of the target ECU. For example, if the value of the register represents the offset of the memory address and the base address of the memory protection unit is known, then perform an operation (such as addition or subtraction) on the change value of the register and the base address to obtain the absolute offset data. The absolute offset reflects the actual offset situation of the memory location pointed to by the relevant register in the memory space.

[0067] S420, obtain the memory base address of the memory protection unit of the relevant register.

[0068] It can be understood that the memory base address is the starting address of the memory area managed by the memory protection unit. The way to obtain the memory base address can be to read from the system configuration information of the target ECU, and these configuration information may be stored in a specific memory area or set by the initialization parameters of the simulation environment. It can also be to parse the startup code or relevant configuration files of the target ECU to extract the memory base address information of the memory protection unit, providing basic data for subsequent calculation of the absolute starting address.

[0069] S430, calculate the absolute starting address based on the absolute offset data of the memory protection unit and the memory base address, and determine the dynamic test report of the target ECU firmware.

[0070] It can be understood that the absolute starting address of the relevant data in the memory protection unit can be obtained by adding the absolute offset data to the memory base address. Based on the absolute starting address, it can be analyzed whether the memory access of the target ECU firmware during operation is legal and whether there are exceptions such as out-of-bounds. If there are exceptions, record the exception information in the dynamic test report, including the exception type, occurrence location, relevant register information, etc.; if no exceptions are found, it is stated in the report that the memory access is normal, thus completing the determination of the dynamic test report.

[0071] Optionally, S430, calculate the absolute starting address based on the absolute offset data of the memory protection unit and the memory base address, and determine the dynamic test report of the target ECU firmware, including: S431, add the absolute offset data of the memory protection unit and the memory base address to obtain the corresponding configuration data of the memory protection unit.

[0072] It can be understood that the addition operation algorithm can be used to add the calculated absolute offset data to the obtained memory base address. The result obtained 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 the memory access situation.

[0073] S432, perform an abnormal risk analysis based on the corresponding configuration data of the memory protection unit, and determine the dynamic test report of the target ECU firmware.

[0074] It can be understood that a boundary check algorithm can be adopted 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 risk of memory out-of-bounds and recorded in the dynamic test report. At the same time, it is also possible to check the access rights of the memory area corresponding to the configuration data. If the current operation right does not match the configured right, it is also recorded as an abnormal situation. According to the analysis results of the abnormal risks, a dynamic test report including detailed problem descriptions and risk levels is generated, providing a basis for evaluating the quality and stability of the target ECU firmware, thereby shortening the development and test cycle and reducing the dependence on scarce resources and actual hardware. In addition, through the dynamic simulation method, developers can observe and modify memory variables and even hardware states at any time, greatly improving work efficiency.

[0075] Corresponding to the dynamic simulation method of the in-vehicle ECU firmware in the above embodiment, the embodiment of the present application further provides a dynamic simulation system for the in-vehicle ECU firmware, and each unit of the system can implement each step of the dynamic simulation method of the in-vehicle ECU firmware. Figure 5 The structural block diagram of the dynamic simulation system for the in-vehicle ECU firmware provided by the embodiment of the present application is shown. For the sake of convenience of description, only the parts related to the embodiment of the present application are shown.

[0076] Referring to Figure 5 , the dynamic simulation system for the in-vehicle ECU firmware includes: An acquisition unit for acquiring the firmware data of the target ECU; A customization unit for performing instruction translation on the firmware data of the target ECU to determine the simulation customization parameters corresponding to the target ECU; wherein, the simulation customization parameters are used for architecture adaptation of the target ECU; A simulation unit for 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; A result unit for performing absolute offset analysis on the target ECU based on the numerical change data of the relevant registers to determine the dynamic test report of the target ECU firmware.

[0077] It should be noted that the information interaction, execution process, etc. between the above systems / units, due to being based on the same concept as the method embodiment of the present application, for their specific functions and the technical effects brought, reference can be specifically made to the method embodiment part, and details are not described here again.

[0078] Those skilled in the art can clearly understand that, for the convenience and conciseness of description, only the above-mentioned division of each functional unit and module is used as an example. In practical applications, the above-mentioned functions can be allocated to different functional units and modules according to needs, 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. Each functional unit and module in the embodiment can be integrated into a 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 a software functional unit. In addition, the specific names of each functional unit and module are only for the convenience of mutual distinction and do not limit the protection scope of this application. The specific working process of the units and modules in the above system can refer to the corresponding process in the foregoing method embodiment and will not be elaborated here.

[0079] The embodiment of the present application also provides an electronic device. Figure 6 It is a schematic structural diagram of the electronic device provided by an embodiment of the present application. As Figure 6 shown, the electronic device 6 of this embodiment includes: at least one processor 60 ( Figure 6 only one is shown here), at least one memory 61 ( Figure 6 only one is shown here), 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 in any of the foregoing method embodiments of the dynamic simulation method for in-vehicle ECU firmware, or enables the electronic device 6 to implement the functions of each unit in the foregoing system embodiments.

[0080] Exemplarily, the computer program 62 can be divided into one or more units. The one or more units are stored in the memory 61 and executed by the processor 60 to complete the present application. The one or more units can be a series of computer program instruction segments capable of completing specific functions, and this instruction segment is used to describe the execution process of the computer program 62 in the electronic device 6.

[0081] The electronic device 6 can be a computing device or a terminal device such as a desktop computer, a notebook, a palm computer, and 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 can understand that Figure 6 merely an example of the electronic device 6, which does not constitute a limitation on the electronic device 6, and may include more or fewer components than shown in the figure, or combine certain components, or different components. For example, it may also include input and output devices, network access devices, buses, etc.

[0082] The processor 60 may be a Central Processing Unit (CPU), and the processor 60 may also be other general-purpose processors, Digital Signal Processors (DSPs), Application Specific Integrated Circuits (ASICs), Field-Programmable Gate Arrays (FPGAs), or other programmable logic devices, discrete gate or transistor logic devices, discrete hardware components, etc. The general-purpose processor may be a microprocessor or any conventional processor, etc.

[0083] In some embodiments, the memory 61 may be an internal storage unit of the electronic device 6, such as the hard disk 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 disk, Smart Media Card (SMC), Secure Digital (SD) card, Flash Card, etc., equipped on the electronic device 6. Further, the memory 61 may also include both the internal storage unit and the external storage device of the electronic device 6. The memory 61 is used to store an operating system, application programs, a BootLoader, data, and other programs, such as the program code of the computer program, etc. The memory 61 may also be used to temporarily store data that has been output or will be output.

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

[0085] An embodiment of the present application provides a computer program product, and when the computer program product runs on an electronic device, the electronic device implements the steps in any of the above method embodiments.

[0086] When the integrated unit is implemented in the form of a software functional unit and sold or used as an independent product, it can be stored in a computer-readable storage medium. Based on this understanding, to implement all or part of the processes in the above-described embodiment methods of this application, a computer program can be used to instruct relevant hardware to complete. The computer program can be stored in a computer-readable storage medium. When the computer program is executed by a processor, the steps of the above-described method embodiments can be implemented. Among them, the computer program includes computer program code, and the computer program code can be in the form of source code, object code, executable file, or some intermediate form, etc. The computer-readable medium can at least include: any entity or device capable of carrying the computer program code to an electronic device, a recording medium, a computer memory, a read-only memory (ROM, Read-Only Memory), a random access memory (RAM, Random Access Memory), an electrical carrier signal, a telecommunication signal, and a software distribution medium. For example, a USB flash drive, a mobile hard disk, a magnetic disk, or an optical disc, etc. In some jurisdictions, according to legislation and patent practice, the computer-readable medium cannot be an electrical carrier signal and a telecommunication signal.

[0087] In the above embodiments, the descriptions of each embodiment have their own emphases. For the parts not detailed or recorded in a certain embodiment, reference can be made to the relevant descriptions of other embodiments.

[0088] Those of ordinary skill in the art can realize that the units and algorithm steps of the examples described in combination with the embodiments disclosed herein can be implemented by electronic hardware, or a combination of computer software and electronic hardware. Whether these functions are executed in a hardware or software manner depends on the specific application and design constraints of the technical solution. A professional technician can use different methods to implement the described functions for each specific application, but such implementation should not be considered to exceed the scope of this application.

[0089] In the embodiments provided in this application, it should be understood that the disclosed dynamic simulation system / electronic device and method of in-vehicle ECU firmware can be implemented in other ways. For example, the above-described embodiments of the dynamic simulation system / electronic device of in-vehicle ECU firmware are merely illustrative. For example, the division of the units is only a logical function division. In actual implementation, there can be other division methods. For example, 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 displayed or discussed couplings or direct couplings or communication connections to each other can be through some interfaces, and the indirect couplings or communication connections of devices or units can be in electrical, mechanical, or other forms.

[0090] The unit described as a separation component may or may not be physically separated. The component shown as a unit may or may not be a physical unit, that is, it may be located in one place or may be distributed across multiple network units. Some or all of the units can be selected according to actual needs to achieve the purpose of the solution of this embodiment.

[0091] The above 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 foregoing embodiments, those of ordinary skill in the art should understand that they can still modify the technical solutions recorded in the foregoing embodiments, or perform equivalent replacements on some of the technical features; and these modifications or replacements do not cause the essence of the corresponding technical solutions to deviate from the spirit and scope of the technical solutions of the embodiments of the present application, and should all be included in the protection scope of the present application.

Claims

1. A dynamic simulation method for in-vehicle ECU firmware, characterized in that, Including: Obtain the firmware data of the target ECU; Perform instruction translation on the firmware data of the target ECU to determine the analog customization parameters corresponding to the target ECU; wherein, the analog customization parameters are used for architecture adaptation of the target ECU; Dynamically simulate the firmware data of the target ECU according to the analog customization parameters, and monitor the relevant register data of the target ECU through a preset callback function to obtain the numerical change data of the relevant registers; Perform absolute offset analysis on the target ECU based on the numerical change data of the relevant registers to determine the dynamic test report of the target ECU firmware.

2. The dynamic simulation method of in-vehicle ECU firmware according to claim 1, characterized in that Performing instruction translation on the firmware data of the target ECU to determine the analog customization parameters corresponding to the target ECU includes: Perform instruction translation on the firmware data of the target ECU to determine the instruction translation completion degree of the target ECU; wherein, the value range of the instruction translation completion degree is [0, 1]; When the value of the instruction translation completion degree is equal to 1, determine the default analog customization parameters as the analog customization parameters corresponding to the target ECU; When the value of the instruction translation completion degree is not equal to 1, perform analog parameter customization according to the firmware data to determine the analog customization parameters corresponding to the target ECU.

3. The dynamic simulation method of in-vehicle ECU firmware according to claim 2, wherein, The performing instruction translation on the firmware data of the target ECU to determine the instruction translation completion degree of the target ECU includes: Perform instruction translation on the firmware data of the target ECU, and count the total number of instructions in the firmware data and the number of completed instructions of the successfully translated instructions; Perform 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.

4. The dynamic simulation method of in-vehicle ECU firmware according to claim 3, characterized in that, Performing analog parameter customization according to the firmware data to determine the analog customization parameters corresponding to the target ECU includes: Obtain the abnormal instruction set of all uncompleted translated instructions in the firmware data according to the firmware data; Traverse all instructions in the abnormal instruction set to determine the abnormal type data of each instruction in the abnormal instruction set; Merge the duplicate items of the abnormal type data of each instruction in the abnormal instruction set to obtain the abnormal type table corresponding to the abnormal instruction set; Perform analog parameter customization based on the abnormal type table corresponding to the abnormal instruction set to determine the analog customization parameters corresponding to the target ECU.

5. The dynamic simulation method of in-vehicle ECU firmware according to claim 1, characterized in that The preset callback function includes a first preset callback function and a second preset callback function; Monitoring the relevant register data of the target ECU through a preset callback function to obtain the numerical change data of the relevant registers includes: Perform a read register operation on the relevant registers of the target ECU through the first preset callback function to obtain the first return data of the target ECU; Perform a write register operation on the relevant registers of the target ECU through the second preset callback function to obtain the second return data of the target ECU; Based on the first return data and the second return data of the target ECU, obtain the numerical change data of the relevant register.

6. The dynamic simulation method of in-vehicle ECU firmware according to claim 5, characterized in that, The operation of reading the relevant register of the target ECU through the first preset callback function to obtain the first return data of the target ECU includes: Perform a register reading operation on the relevant register of the target ECU, and determine the first characteristic data segment of the memory protection unit of the relevant register based on the data characteristics of the memory protection unit; Perform a relative position reading on the first characteristic data segment of the memory protection unit of the relevant register through the first preset callback function to obtain the first return data of the target ECU.

7. The dynamic simulation method of in-vehicle ECU firmware according to claim 5, characterized in that, The operation of writing the relevant register of the target ECU through the second preset callback function to obtain the second return data of the target ECU includes: Perform a register writing operation on the relevant register of the target ECU, and determine the second characteristic data segment of the memory protection unit of the relevant register based on the data characteristics of the memory protection unit; Perform a relative position reading on the second characteristic data segment of the memory protection unit of the relevant register through the first preset callback function to obtain the second return data of the target ECU.

8. The dynamic simulation method of in-vehicle ECU firmware according to claim 1, characterized in that The absolute offset analysis of the target ECU based on the numerical change data of the relevant register to determine the dynamic test report of the target ECU firmware includes: Calculate the position offset amount based on the numerical change data of the relevant register to obtain the absolute offset amount data of the memory protection unit of the relevant register; Obtain the memory base address of the memory protection unit of the relevant register; Calculate the absolute starting address according to the absolute offset amount data and the memory base address of the memory protection unit, and determine the dynamic test report of the target ECU firmware.

9. The dynamic simulation method of in-vehicle ECU firmware according to claim 8, characterized in that The calculation of the absolute starting address according to the absolute offset amount data and the memory base address of the memory protection unit to determine the dynamic test report of the target ECU firmware includes: Add the absolute offset amount data and the memory base address of the memory protection unit to obtain the corresponding configuration data of the memory protection unit; Perform an abnormal risk analysis according to the corresponding configuration data of the memory protection unit to determine the dynamic test report of the target ECU firmware.

10. An electronic device, comprising a memory, a processor, and a computer program stored in the memory and executable on the processor, characterized in that, When the processor executes the computer program, it implements the method according to any one of claims 1 to 9.

Images