Automobile motor and driving circuit hardware-in-the-loop test system and method

Abstract

The application discloses a hardware-in-loop test system and method for an automobile motor and a driving circuit, and particularly relates to the technical field of hardware-in-loop simulation testing, and the system comprises an HIL test host, a model development tool and a real-time acquisition host computer, the model development tool is internally provided with a model complexity quantitative evaluation module and a stage switching automatic decision module, in the development stage, an ARM fixed-step cycle is dynamically set according to a model complexity comprehensive index, and an ARM executable program is generated to run on an ARM processor, after the model is stable, an FPGA implementation file is generated to be deployed to an FPGA logic to run, and the real-time acquisition host computer receives test data according to a unified sampling frame to ensure the consistency of multi-source data. The application considers the development efficiency and real-time performance by two-stage deployment of the homologous model, and integrates various signal simulation modules, and is suitable for the hardware-in-loop test of the automobile motor and the driving controller.

Description

Technical Field

[0001] This invention relates to the field of hardware-in-the-loop simulation testing technology, and more specifically, to a hardware-in-the-loop testing system and method for automotive motors and drive circuits. Background Technology

[0002] Hardware-in-the-loop testing is an important verification method in the development process of automotive motor controllers. In hardware-in-the-loop testing, the controller under test is usually connected to a real-time simulation host. The real-time simulation host outputs test signals such as current, voltage, temperature, speed, position and bus communication, and receives the control output of the controller under test. In this way, control strategy verification, interface debugging and bench testing can be completed without using a real vehicle and a real motor.

[0003] Existing hardware-in-the-loop platforms for testing automotive motor controllers can be mainly divided into two categories based on their model deployment methods: The first type is to deploy the model directly to the FPGA from the early stage of development. For example, some commercial HIL systems use FPGA boards to run motor models directly to achieve high real-time performance. However, this approach requires developers to complete FPGA-appropriate modeling, partitioning, and timing processing in the early stages of model design. After each model modification, synthesis, compilation, and download must be re-executed, resulting in a long debugging cycle and low development efficiency. The second category is models that run using only CPU or ARM processors. For example, the HIL platform based on a pure processor architecture can generate runnable programs relatively quickly after the model is modified. However, when the model is complex, has many I / O channels, and has a large bus load, the fixed step size cycle is forced to be extended, resulting in insufficient real-time performance and determinism, making it difficult to meet the concurrent requirements of high-speed signals and multi-channel communication in motor control testing.

[0004] Furthermore, existing platforms generally suffer from incomplete interface coverage, making it difficult to simultaneously integrate programmable power supplies, multiple CAN FDs, temperature and resistance simulations, high-speed current and voltage signal simulations, and various speed and position signal simulations within a single platform. The host computer software also frequently lacks a unified sampling frame mechanism, leading to inconsistent time bases for multi-source data and inconsistent recording and playback.

[0005] Therefore, there is a need for a hardware-in-the-loop testing system and method that can ensure development efficiency, meet final real-time requirements, and provide complete interfaces and good data consistency. In view of this, the present invention provides a hardware-in-the-loop testing system and method for automotive motors and drive circuits. Summary of the Invention

[0006] To overcome the aforementioned deficiencies of the prior art, embodiments of the present invention provide a hardware-in-the-loop testing system and method for automotive motors and drive circuits to solve the problems mentioned in the background art.

[0007] To achieve the above objectives, the present invention provides the following technical solution: On one hand, the present invention provides a hardware-in-the-loop testing system for automotive motors and drive circuits, including: HIL test host, the HIL test host includes heterogeneous programmable SoC, signal conditioning board and junction board, the heterogeneous programmable SoC includes ARM processor and FPGA logic; A model development tool is connected to the HIL test host. The model development tool has a built-in model complexity quantification and evaluation module and a stage switching automation decision module. The model development tool is configured to: during the development phase, dynamically set the ARM fixed step size cycle according to the model complexity comprehensive index output by the model complexity quantification and evaluation module, and generate an ARM executable program to be deployed to the ARM processor for execution; when the stage switching automation decision module determines that the model has entered a stable state according to the changing trend of the model complexity comprehensive index, it generates an FPGA implementation file to be deployed to the FPGA logic for execution. The real-time acquisition host computer communicates with the HIL test host and is configured to receive and process test data from the HIL test host according to a unified sampling frame. The unified sampling frame includes at least a frame header, a unified timestamp, a frame sequence number, and a channel data area.

[0008] Preferably, the model complexity quantification and evaluation module is configured to calculate the Model Complexity Index (MCI) from the following four dimensions: state space complexity, state space complexity, and so on. computation graph complexity I / O channel complexity Bus communication complexity And independently obtain ARM single-step execution time The measured evaluation value; State space complexity It is obtained by weighted summation of the number of model state variables and the differential order of each state variable; computation graph complexity It is obtained by multiplying the maximum depth of the calculated path by the logarithmic product of the branching factor; I / O channel complexity It is obtained by multiplying the number of analog channels, digital channels, and PWM channels by preset weighting coefficients and then summing the results; Bus communication complexity It is obtained by summing the message payloads of each CAN FD channel; The MCI is calculated using the following formula: ,in, - These are the normalized weighting coefficients.

[0009] Preferably, the ARM fixed-step period Dynamically set by the model development tool: ,in, To preset the minimum step size lower limit, It is a safety factor and its value ranges from 1.2 to 2.

[0010] Preferably, the stage switching automated decision module is configured to: when the continuous change of the Model Complexity Index (MCI) Three consecutive times the value is less than the preset rate of change threshold and the standard deviation of the MCI value When the value is less than the preset stability threshold, the percentage of ARM step size exceeding the limit is less than the preset threshold, and the current ARM running result has been evaluated and confirmed to have met the main performance verification requirements of the controller under test, a suggestion signal to switch from the development stage to the stable stage will be automatically generated. The percentage of ARM-side step size exceeding the limit refers to the actual step size execution time of the ARM processor exceeding the ARM fixed step size cycle. The proportion of the total number of samples taken; The main performance verification requirements include: the response time, control accuracy, steady-state error, CANFD communication packet loss rate, and real-time performance of the controller under test are all within the preset acceptable range.

[0011] Preferably, the model development tool also includes a built-in interface compatibility verification and conversion module, which is configured to perform the following operations during the model migration from the ARM side to the FPGA side: Extract all input and output interface signals of the model, including signal name, data type, sampling frequency, measurement range, and physical unit; The precision analysis is performed on the quantization error of the floating-point operation signal on the ARM side when it is used for fixed-point operation on the FPGA side. When the quantization error exceeds the preset threshold, the fixed-point bit width is automatically increased or a floating-point IP core is used instead. Timing alignment is achieved by inserting a configurable delay compensation register, with the delay compensation value... Calculate using the following formula: ,in, This represents the modulo operation. For ARM, set the step size period. This refers to the FPGA clock cycle. Using the interface input and output data recorded by the ARM side under typical operating conditions as the gold sample, and playing back the output data of the FPGA side under the same excitation, the interface compatibility verification is deemed to be passed when both the root mean square error and the maximum absolute error are lower than the preset tolerance threshold.

[0012] Preferably, the real-time acquisition host computer has a built-in dual-path parallel verification module. The dual-path parallel verification module is configured to simultaneously receive the ARM execution results output by the ARM processor and the FPGA execution results output by the FPGA logic in verification mode, perform real-time difference analysis on each sampling frame, calculate the absolute error and relative error of each channel, and plot the error trend curve. At the same time, it records the actual step size execution time of the ARM end and the combinational logic delay of the FPGA end, calculates the performance improvement ratio, and generates a dual-path verification report that includes error statistics and performance comparison.

[0013] Preferably, the HIL test host further includes: The programmable power supply module, connected to the terminal block, is used to provide programmable power to the controller under test, including output voltage setting, current limit setting, power-on sequence control and power-off sequence control; A multi-channel CAN FD module has two or more CAN FD channels, which are used for control message interaction, status message acquisition, calibration data transmission, and network environment simulation, respectively. The temperature signal simulation module, implemented using a resistor board, is used to provide resistive temperature sensor signals to the controller under test. The current and voltage signal simulation module uses a high-speed DAC as the core output unit to convert the model calculation results into analog voltage or analog current signals. The rotational speed and position signal simulation module is directly generated by FPGA logic and is used to output rotary transformer type signals and various magnetic encoder type signals.

[0014] Preferably, the real-time acquisition host computer uses a double buffer or a circular queue to receive unified sampling frames and separates the display thread from the storage thread. The unified sampling frame also includes a status word. When a certain type of data is not refreshed in the current sampling period, it is identified by the status word to avoid misalignment of multi-source data.

[0015] On the other hand, the present invention also provides a hardware-in-the-loop testing method for automotive motors and drive circuits, implemented using the above-mentioned system, including the following steps: S1. Use model development tools to build motor models, drive circuit models, interface models and sensor models, and use the built-in model complexity quantification and evaluation module to calculate the model complexity comprehensive index MCI and evaluate the ARM single-step execution time. S2. During the development phase, the ARM fixed step size cycle is dynamically set based on the Model Complexity Index (MCI) and ARM single-step execution time evaluation value calculated in step S1. The ARM executable program is generated by the model development tool and deployed to the ARM processor for execution. S3 is equipped with a programmable power supply module, a multi-channel CAN FD module, a temperature signal simulation module, a current and voltage signal simulation module, and a speed and position signal simulation module, forming a closed-loop test relationship with the controller under test; S4 and HIL test hosts organize test data according to a unified sampling frame. The host computer receives, displays and stores test data in real time in units of the unified sampling frame. The unified sampling frame includes at least a frame header, a unified timestamp, a frame number and a channel data area. S5. Monitor the trend of the Comprehensive Complexity Index (MCI) of the model. When the continuous change of MCI, standard deviation and the proportion of ARM step size exceeding the limit meet the preset stability conditions, and the ARM running results are evaluated and confirmed to have met the main performance verification requirements of the controller under test, the model is automatically determined to meet the conditions for switching to FPGA. S6. Start automatic interface compatibility verification. After confirming the consistency of interface behavior, generate FPGA implementation files from the same model and deploy them to the FPGA logic for execution. S7. During the stabilization phase, the external channel definition and data frame format used in the development phase are used to perform tests, and the real-time acquisition host computer outputs log files and playback results.

[0016] Preferably, the automatic interface compatibility verification in step S6 includes: extracting all interface signals of the model, analyzing fixed-point conversion quantization error, performing timing alignment through a configurable delay compensation register, and performing playback verification based on the ARM-side gold sample. The preset stability conditions in step S5 include: the continuous change in MCI. Three consecutive times the value is less than the preset rate of change threshold and the standard deviation of the MCI value The value is less than the preset stability threshold, and the percentage of ARM-side step size exceeding the limit is less than the preset threshold.

[0017] The technical effects and advantages of this invention are as follows: 1. This invention adopts a two-stage deployment strategy based on the same model. During the development stage, the model is generated into an ARM executable program and run on an ARM processor, which shortens the closed-loop verification waiting time after model modification and improves the efficiency of development iteration. After the model is stable, the same model is generated into an FPGA implementation file and migrated to the FPGA logic for execution. By utilizing the parallel processing capability and high-precision timing control of the FPGA, the real-time performance and determinism of the test system are significantly improved. The development stage and the stabilization stage share the same external interface definition and data frame format, eliminating the need to rewrite test scripts and reducing engineering implementation costs. 2. The present invention has a built-in interface compatibility verification and conversion module. During the migration of the model from the ARM end to the FPGA end, it automatically extracts interface signals, analyzes fixed-point conversion quantization errors, achieves timing alignment through a configurable delay compensation register, and performs playback verification based on the ARM end's golden sample to ensure the consistency of interface behavior before and after migration. At the same time, the dual-path parallel verification module receives the output results of ARM and FPGA simultaneously in verification mode, calculates errors in real time, and generates a performance comparison report, providing engineers with an objective basis for switching decisions and avoiding accuracy loss or timing deviation caused by migration. 3. This invention uses a unified sampling frame to organize test data. Each sampling frame includes at least a frame header, a unified timestamp, a frame sequence number, and a channel data area. Combined with dual-buffered or circular queue reception, separation of display and storage threads, and a status word identification mechanism, it effectively solves problems such as inconsistent time bases, misaligned channel data, and cache resource contention when multiple data sources are concurrent, ensuring the consistency and real-time performance of the collected data. In addition, a programmable power supply module, a multi-channel CAN FD module, a temperature signal simulation module, a current and voltage signal simulation module, and a speed and position signal simulation module are integrated in the same HIL test host, reducing the stacking of external devices and the debugging cycle, forming an integrated test platform with complete interface coverage. Attached Figure Description

[0018] Figure 1 This is a block diagram of the overall structure of the HIL testing system in an embodiment of the present invention.

[0019] Figure 2 This is a flowchart of the two-stage deployment of the model in an embodiment of the present invention.

[0020] Figure 3 This is a schematic diagram of data exchange between the ARM processor and the FPGA logic in an embodiment of the present invention.

[0021] Figure 4 This is a schematic diagram of real-time data acquisition and processing by the host computer in an embodiment of the present invention.

[0022] Figure 5 This is a flowchart of the method of the present invention.

[0023] The attached diagram is labeled as follows: 100, HIL test host; 110, heterogeneous programmable SoC; 111, ARM processor; 112, FPGA logic; 120, signal conditioning board; 130, junction box; 140, programmable power supply module; 150, multi-channel CAN FD module; 160, temperature signal simulation module; 170, current and voltage signal simulation module; 180, speed and position signal simulation module; 190, real-time acquisition host computer; 200, model development tool; 210, controller under test. Detailed Implementation

[0024] The technical solutions of the present invention will be clearly and completely described below with reference to the accompanying drawings in the embodiments of the present invention.

[0025] As attached Figure 1 As shown, this embodiment provides a hardware-in-the-loop (HIL) test system for automotive motors and drive circuits, including a HIL test host 100, a model development tool 200, a real-time acquisition host computer 190, and a controller under test 210.

[0026] The HIL test host 100 includes a heterogeneous programmable SoC 110, a signal conditioning board 120, and a junction box 130. The heterogeneous programmable SoC 110 further includes an ARM processor 111 and an FPGA logic 112. The ARM processor 111 is used to run ARM executable programs and complete device management, configuration management, communication management, and test process control. The FPGA logic 112 is used to complete high deterministic I / O scheduling, time base generation, high-speed signal generation, and execute FPGA implementation files during the stable phase. The signal conditioning board 120 is located between the heterogeneous programmable SoC 110 and the junction box 130 and is used to complete signal amplitude adjustment, impedance matching, filtering, and interface adaptation. The junction box 130 is used to bring out the test channels of each module inside the system and connect them to the controller under test 210.

[0027] The model development tool 200 communicates with the HIL test host 100 and is typically deployed on a host computer used by engineers. The model development tool 200 has a built-in model complexity quantification and evaluation module and a stage switching automation decision module. The model development tool 200 is configured to: dynamically set the ARM fixed step size cycle according to the model complexity comprehensive index output by the model complexity quantification and evaluation module during the development phase, and generate an ARM executable program to be deployed to the ARM processor 111 for execution; when the stage switching automation decision module determines that the model has entered a stable state based on the changing trend of the model complexity comprehensive index, it generates an FPGA implementation file to be deployed to the FPGA logic 112 for execution.

[0028] The real-time acquisition host computer 190 communicates with the HIL test host 100 and is configured to receive and process test data from the HIL test host 100 according to a unified sampling frame. The unified sampling frame includes at least a frame header, a unified timestamp, a frame sequence number, and a channel data area.

[0029] As attached Figure 1As shown, the HIL test host 100 also includes a programmable power supply module 140, a multi-channel CAN FD module 150, a temperature signal simulation module 160, a current and voltage signal simulation module 170, and a speed and position signal simulation module 180. The programmable power supply module 140 is connected to the terminal block 130 and is used to provide programmable power to the controller under test 210, including output voltage setting, current limit setting, power-on timing control, and power-off timing control. The multi-channel CAN FD module 150 has two or more CAN FD channels, which are used for control message interaction, status message acquisition, calibration data transmission, and network environment simulation, respectively. The temperature signal simulation module 160 is implemented using a resistor board and is used to provide resistive temperature sensor signals to the controller under test 210. The current and voltage signal simulation module 170 uses a high-speed DAC as the core output unit and is used to convert the model calculation results into analog voltage or analog current signals. The speed and position signal simulation module 180 is directly generated by the FPGA logic 112 and is used to output rotary transformer type signals and various magnetic encoder type signals.

[0030] In this embodiment, the model complexity quantification and evaluation module is configured to calculate the Model Complexity Index (MCI) from four dimensions: state space complexity. computation graph complexity I / O channel complexity Bus communication complexity And independently obtain ARM single-step execution time The measured evaluation value; It is important to note that the ARM single-step execution time... It is not calculated by weighted summation using the formula above, but rather is another key parameter independent of the Model Complexity Index (MCI). In practical engineering applications, this... The value is obtained in the following ways: After compiling the current model, typical test cases are run on the actual target ARM processor for practical testing using hardware timers or performance counters; or, in the absence of practical testing conditions, engineers estimate the value based on historical project data or processor load experience, and a safety factor is added. Leave enough margin. That is, It reflects the actual processing capability of the real hardware platform for the current model, and its acquisition method is independent of the aforementioned theoretical weighted calculation process of MCI.

[0031] State space complexity The computational graph complexity is obtained by weighted summation of the number of model states and the differential order of each state; The I / O channel complexity is obtained by multiplying the maximum path depth by the logarithmic product of the branching factor; The complexity of bus communication is obtained by multiplying the number of analog channels, digital channels, and PWM channels by preset weighting coefficients and then summing the results. It is obtained by summing the message payloads of each CAN FD channel; Model Complexity Index (MCI) is calculated using the following formula:

[0032] in, - These are the normalized weighting coefficients.

[0033] In this embodiment, the ARM fixed-step period The model development tool 200 dynamically sets the following settings:

[0034] in, To preset the minimum step size lower limit, It is a safety factor and its value ranges from 1.2 to 2.

[0035] In this embodiment, the stage switching automated decision module is configured to: when the continuous change of the Model Complexity Index (MCI) Three consecutive times the value is less than the preset rate of change threshold and the standard deviation of the MCI value When the value is less than the preset stability threshold, the percentage of ARM step size exceeding the limit is less than the preset threshold, and the current ARM running result has been evaluated and confirmed to have met the main performance verification requirements of the controller under test, a suggestion signal to switch from the development stage to the stable stage will be automatically generated. It should be noted that the automated stage switching decision module does not rely solely on the statistical characteristics of the Model Complexity Index (MCI) for mechanical judgment. In the preferred embodiment of this invention, MCI stability is only a necessary prerequisite, not a sufficient condition, for switching. After the MCI stability condition is met, the system will automatically (or be manually triggered by an engineer) run a set of preset standard test cases to comprehensively evaluate the functionality and performance of the current running results on the ARM side.

[0036] The assessment covers at least the following aspects: Real-time performance: Whether the control cycle response of the controller under test meets the standard; Accuracy: Whether the steady-state error of key signals such as current, voltage, and speed is within the preset tolerance band; Communication integrity: Whether the packet loss rate and delay of the CAN FD bus under various load rates are acceptable; Operating condition coverage: Whether the controller behavior meets expectations under typical operating conditions (such as acceleration / deceleration, stall, field weakening, etc.).

[0037] A recommendation signal to switch to the FPGA is only generated after all the major performance requirements at the engineering level have been met. This is to ensure that each migration occurs only when the model is truly valuable enough to be migrated to the FPGA, avoiding premature switching that would require later modifications to the model on the ARM side, thus truly achieving the engineering goal of a successful migration in one go.

[0038] Among them, the percentage of ARM-side step size exceeding the limit refers to the actual step size execution time of the ARM processor 111 exceeding the ARM fixed step size cycle. The proportion of the total number of samples taken; The main performance verification requirements include: the response time, control accuracy, steady-state error, CAN FD communication packet loss rate, and real-time performance of the controller under test must all be within the preset acceptable range.

[0039] In this embodiment, the model development tool 200 also includes a built-in interface compatibility verification and conversion module, which is configured to perform the following operations during the model migration from the ARM side to the FPGA side: Extract all input and output interface signals of the model, including signal name, data type, sampling frequency, range, and physical unit; perform precision analysis on the quantization error of the ARM floating-point operation signals when using fixed-point operation on the FPGA; automatically increase the fixed-point bit width or switch to a floating-point IP core when the quantization error exceeds a preset threshold; achieve timing alignment by inserting a configurable delay compensation register, and set the delay compensation value. Calculate using the following formula:

[0040] in, This represents the modulo operation. For ARM, set the step size period. The FPGA clock cycle is used as the golden sample. The interface input and output data recorded by the ARM side under typical operating conditions are used as the golden sample. The output data of the FPGA side under the same excitation is played back for verification. When the root mean square error and the maximum absolute error are both lower than the preset tolerance threshold, the interface compatibility verification is deemed to be passed.

[0041] As attached Figure 3 As shown, the ARM processor 111 and the FPGA logic 112 exchange data through a shared memory area, DMA and a double buffering mechanism. The FPGA logic 112 writes the data collected in the current sampling period into buffer A, while the ARM processor 111 reads the data from the previous period in buffer B and performs calculations. After completion, the two parties exchange buffer identifiers, thereby reducing read and write conflicts and ensuring periodic operation. The raw data in the shared memory area is packaged by the unified sampling frame organization module and sent to the real-time acquisition host computer 190.

[0042] As attached Figure 4As shown, the real-time acquisition host computer 190 uses double buffering or a circular queue to receive unified sampling frames, and separates the display thread from the storage thread. The unified sampling frame also includes a status word. When a certain type of data has not been refreshed within the current sampling period, it is identified through the status word to avoid misalignment of multi-source data. The real-time acquisition host computer 190 also sets frame integrity check and frame loss detection logic. When frame loss is detected, the corresponding mark is recorded in the status word.

[0043] In this embodiment, the host computer 190 has a built-in dual-path parallel verification module for real-time acquisition. This module is configured to simultaneously receive the ARM execution results output by the ARM processor 111 and the FPGA execution results output by the FPGA logic 112 in verification mode. It performs real-time difference analysis on each sampling frame, calculates the absolute and relative errors of each channel, and plots error trend curves. At the same time, it records the actual step size execution time of the ARM end and the combinational logic delay of the FPGA end, calculates the performance improvement ratio, and generates a dual-path verification report that includes error statistics and performance comparison.

[0044] As attached Figure 2 , 5 This embodiment also provides a hardware-in-the-loop testing method for automotive motors and drive circuits. This method is implemented using the above-described system and includes the following steps: S1. Use the model development tool 200 to build motor models, drive circuit models, interface models and sensor models, and calculate the model complexity comprehensive index MCI and evaluate the ARM single-step execution time through the built-in model complexity quantification and evaluation module. S2. During the development phase, the ARM fixed step size cycle is dynamically set according to the model complexity comprehensive index MCI and ARM single-step execution time evaluation value calculated in step S1. The model development tool 200 generates the ARM executable program and deploys it to the ARM processor 111 for execution. S3. Configure a programmable power supply module 140, a multi-channel CAN FD module 150, a temperature signal simulation module 160, a current and voltage signal simulation module 170, and a speed and position signal simulation module 180 to form a closed-loop test relationship with the controller under test 210. S4 and HIL test host 100 organize test data according to unified sampling frames, and the host computer 190 receives, displays and stores test data in units of unified sampling frames in real time. The unified sampling frame includes at least a frame header, unified timestamp, frame sequence number and channel data area. S5. Monitor the trend of the Comprehensive Complexity Index (MCI) of the model. When the continuous change of MCI, standard deviation and the proportion of ARM step size exceeding the limit meet the preset stability conditions, and the ARM running results are evaluated and confirmed to have met the main performance verification requirements of the controller under test, the model is automatically determined to meet the conditions for switching to FPGA. S6. Start automatic interface compatibility verification. After confirming the consistency of interface behavior, generate FPGA implementation files from the same model and deploy them to FPGA logic 112 for operation. S7. During the stabilization phase, the external channel definition and data frame format used in the development phase are used to perform tests, and the real-time acquisition host computer 190 outputs log files and playback results.

[0045] The above description is merely a preferred embodiment of the present invention and is not intended to limit the present invention. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of the present invention should be included within the protection scope of the present invention.

Claims

1. A hardware-in-the-loop testing system for automotive motors and drive circuits, characterized in that: include: HIL test host (100), the HIL test host (100) includes a heterogeneous programmable SoC (110), a signal conditioning board (120) and a junction box (130), the heterogeneous programmable SoC (110) includes an ARM processor (111) and FPGA logic (112). The model development tool (200) is connected to the HIL test host (100). The model development tool (200) has a built-in model complexity quantification evaluation module and a stage switching automation decision module. The model development tool (200) is configured to: during the development stage, dynamically set the ARM fixed step size cycle according to the model complexity comprehensive index output by the model complexity quantification evaluation module, and generate an ARM executable program to be deployed to the ARM processor (111) for running; when the stage switching automation decision module determines that the model has entered a stable state according to the changing trend of the model complexity comprehensive index, it generates an FPGA implementation file to be deployed to the FPGA logic (112) for running. The real-time acquisition host computer (190) is connected to the HIL test host (100) and is configured to receive and process test data from the HIL test host (100) according to a unified sampling frame. The unified sampling frame includes at least a frame header, a unified timestamp, a frame number and a channel data area.

2. The hardware-in-the-loop testing system for automotive motors and drive circuits according to claim 1, characterized in that: The model complexity quantification and evaluation module is configured to calculate the Model Complexity Index (MCI) from the following four dimensions: state space complexity, state space complexity, and so on. computation graph complexity I / O channel complexity Bus communication complexity And independently obtain ARM single-step execution time The measured evaluation value; State space complexity It is obtained by weighted summation of the number of model state variables and the differential order of each state variable; computation graph complexity It is obtained by multiplying the maximum depth of the calculated path by the logarithmic product of the branching factor; I / O channel complexity It is obtained by multiplying the number of analog channels, digital channels, and PWM channels by preset weighting coefficients and then summing the results; Bus communication complexity It is obtained by summing the message payloads of each CAN FD channel; The MCI is calculated using the following formula: ,in, - These are the normalized weighting coefficients.

3. The hardware-in-the-loop testing system for automotive motors and drive circuits according to claim 2, characterized in that: The ARM fixed-step period The model development tool (200) dynamically sets the following settings: ,in, To preset the minimum step size lower limit, It is a safety factor and its value ranges from 1.2 to 2.

4. The hardware-in-the-loop testing system for automotive motors and drive circuits according to claim 2, characterized in that: The stage switching automated decision module is configured to: when the continuous change of the Model Complexity Index (MCI) Three consecutive times the value is less than the preset rate of change threshold and the standard deviation of the MCI value When the value is less than the preset stability threshold, the percentage of ARM step size exceeding the limit is less than the preset threshold, and the current ARM running result has been evaluated and confirmed to have met the main performance verification requirements of the controller under test, a suggestion signal to switch from the development stage to the stable stage will be automatically generated. The percentage of ARM-side step size exceeding the limit refers to the actual step size execution time of the ARM processor (111) exceeding the ARM fixed step size cycle. The proportion of the total number of samples taken; The main performance verification requirements include that the response time, control accuracy, steady-state error, CAN FD communication packet loss rate, and real-time performance of the controller under test are all within the preset acceptable range.

5. The automotive motor and drive circuit hardware-in-the-loop testing system according to claim 1, characterized in that: The model development tool (200) also has a built-in interface compatibility verification and conversion module, which is configured to perform the following operations during the migration of the model from the ARM side to the FPGA side: Extract all input and output interface signals of the model, including signal name, data type, sampling frequency, measurement range, and physical unit; The precision analysis is performed on the quantization error of the floating-point operation signal on the ARM side when it is used for fixed-point operation on the FPGA side. When the quantization error exceeds the preset threshold, the fixed-point bit width is automatically increased or a floating-point IP core is used instead. Timing alignment is achieved by inserting a configurable delay compensation register, with the delay compensation value... Calculate using the following formula: ,in, This represents the modulo operation. For ARM, set the step size period. This refers to the FPGA clock cycle. Using the interface input and output data recorded by the ARM side under typical operating conditions as the gold sample, and playing back the output data of the FPGA side under the same excitation, the interface compatibility verification is deemed to be passed when both the root mean square error and the maximum absolute error are lower than the preset tolerance threshold.

6. The hardware-in-the-loop testing system for automotive motors and drive circuits according to claim 1, characterized in that: The real-time acquisition host computer (190) has a built-in dual-path parallel verification module. The dual-path parallel verification module is configured to simultaneously receive the ARM execution result output by the ARM processor (111) and the FPGA execution result output by the FPGA logic (112) in the verification mode, perform real-time difference analysis on each sampling frame, calculate the absolute error and relative error of each channel, and draw the error trend curve. At the same time, it records the actual step size execution time of the ARM end and the combinational logic delay of the FPGA end, calculates the performance improvement ratio, and generates a dual-path verification report containing error statistics and performance comparison.

7. The hardware-in-the-loop testing system for automotive motors and drive circuits according to claim 1, characterized in that: The HIL test host (100) also includes: The programmable power supply module (140) is connected to the terminal block (130) and is used to provide programmable power supply to the controller under test (210), including output voltage setting, current limit setting, power-on sequence control and power-off sequence control; The multi-channel CAN FD module (150) has two or more CAN FD channels, which are used for control message interaction, status message acquisition, calibration data transmission and network environment simulation, respectively. The temperature signal simulation module (160) is implemented using a resistor board and is used to provide a resistive temperature sensor signal to the controller under test (210). The current and voltage signal simulation module (170) uses a high-speed DAC as the core output unit to convert the model calculation results into analog voltage or analog current signals; The rotational speed position signal simulation module (180) is directly generated by FPGA logic (112) and is used to output rotary transformer type signals and various magnetic encoder type signals.

8. The hardware-in-the-loop testing system for automotive motors and drive circuits according to claim 1, characterized in that: The real-time acquisition host computer (190) uses a double buffer or circular queue to receive unified sampling frames and separates the display thread from the storage thread. The unified sampling frame also includes a status word. When a certain type of data is not refreshed in the current sampling period, it is identified by the status word to avoid misalignment of multi-source data.

9. A hardware-in-the-loop testing method for automotive motors and drive circuits, implemented using the hardware-in-the-loop testing system for automotive motors and drive circuits as described in any one of claims 1-8, characterized in that: Includes the following steps: S1. Use the model development tool (200) to build the motor model, drive circuit model, interface model and sensor model, and calculate the model complexity comprehensive index MCI and evaluate the ARM single-step execution time through the built-in model complexity quantification and evaluation module. S2. During the development phase, the ARM fixed step size cycle is dynamically set according to the model complexity comprehensive index MCI and ARM single-step execution time evaluation value calculated in step S1. The ARM executable program is generated by the model development tool (200) and deployed to the ARM processor (111) for execution. S3. Configure a programmable power supply module (140), a multi-channel CAN FD module (150), a temperature signal simulation module (160), a current and voltage signal simulation module (170), and a speed and position signal simulation module (180) to form a closed-loop test relationship with the controller under test (210); S4, HIL test host (100) organizes test data according to unified sampling frames, and the host computer (190) receives, displays and stores test data in units of unified sampling frames in real time. The unified sampling frame includes at least a frame header, unified timestamp, frame number and channel data area. S5. Monitor the trend of the Comprehensive Complexity Index (MCI) of the model. When the continuous change of MCI, standard deviation and the proportion of ARM step size exceeding the limit meet the preset stability conditions, and the ARM running results are evaluated and confirmed to have met the main performance verification requirements of the controller under test, the model is automatically determined to meet the conditions for switching to FPGA. S6. Start automatic interface compatibility verification. After confirming the consistency of interface behavior, generate FPGA implementation files from the same model and deploy them to the FPGA logic (112) for operation. S7. During the stabilization phase, the external channel definition and data frame format used in the development phase are used to perform tests, and the real-time acquisition host computer (190) outputs the record file and playback results.

10. The method according to claim 9, characterized in that, The automatic interface compatibility verification in step S6 includes: extracting all interface signals of the model, analyzing fixed-point conversion quantization errors, performing timing alignment through a configurable delay compensation register, and performing playback verification based on the ARM-side gold sample. The preset stability conditions in step S5 include: the continuous change in MCI. Three consecutive times the value is less than the preset rate of change threshold and the standard deviation of the MCI value The value is less than the preset stability threshold, and the percentage of ARM-side step size exceeding the limit is less than the preset threshold.

Images