Method, device and equipment for building desktop-level hardware-in-the-loop test system

Abstract

The invention provides a desktop-level hardware-in-the-loop test system building method, device and equipment, and relates to the technical field of hardware-in-the-loop simulation, and the method comprises the steps: configuring a vehicle network simulation and vehicle dynamics model in an upper computer with a CAN development environment and vehicle dynamics simulation software, a real-time data channel between the two is established through a full duplex transmission protocol; a driver instruction is generated through the driving control panel, and a vehicle state signal is generated through vehicle dynamics software; the wheel speed in the vehicle state signal is converted into a physical excitation signal, and a wheel cylinder pressure signal returned by the controller is collected; the pressure signal is fed back to the vehicle dynamics model to form a closed loop, a test scene is executed, and the desktop-level hardware-in-loop test of the brake controller is completed. By using vehicle dynamics simulation software, the test confidence coefficient is improved; data exchange is carried out by utilizing an FDX protocol of a CAN development environment, and complexity and potential risks of self-development of a communication interface are avoided.

Description

TECHNICAL FIELD

[0001] The present disclosure relates to the technical field of hardware-in-the-loop simulation, and in particular to a desktop hardware-in-the-loop test system building method, device and equipment. BACKGROUND

[0002] With the rapid development of intelligent and electric technologies of automobiles, the functions of electronic control units (ECUs) of automobiles are increasingly complex, and higher requirements are put forward for the testing of software algorithms and system performance. In the development process of vehicle control systems, hardware-in-the-loop (HIL) testing has become a key link for verifying the functions of ECUs in the V-mode development process, and is of great significance for the development of safety-critical systems such as brake systems and chassis control systems.

[0003] At present, the HIL testing systems widely used in the industry are mainly system-level or vehicle-level HIL test benches. Such systems usually include high-performance real-time simulation computers, complex I / O interface boards, physical signal simulation and acquisition devices, and complete vehicle network simulation environments. Although such systems can provide a relatively realistic test environment, there are the following significant problems: high cost: the procurement cost of large HIL test bench equipment is high, and the deployment, maintenance and upgrading costs are expensive, which constitutes a great economic burden for small and medium-sized research and development teams or early research and development stages. Resource shortage: during the peak period of project parallel development, multiple teams need to share limited HIL testing resources, resulting in serious testing queuing, affecting development efficiency and project progress. Insufficient flexibility: traditional HIL systems are usually complex in configuration and long in environment building period, making it difficult to support rapid and frequent functional verification and iteration by software engineers in the early development stage, which is not conducive to the implementation of agile development mode. High use threshold: operating and maintaining large HIL systems requires professional technicians, and ordinary software engineers cannot independently complete the building and debugging of the test environment, which limits the autonomy and timeliness of testing.

[0004] Therefore, the industry urgently needs a desktop HIL testing solution with lower cost, more flexible configuration and easy use to support efficient and reliable closed-loop verification of automotive electronic control units in the early development stage, thereby accelerating the development process and reducing research and development costs. SUMMARY

[0005] The present disclosure provides a desktop hardware-in-the-loop test system building method. The main purpose is to solve the problems of high cost, resource shortage, insufficient flexibility and difficulty in operation and maintenance of the prior art.

[0006] According to a first aspect of the present disclosure, a desktop hardware-in-the-loop test system building method is provided, comprising: In the host computer installed with CAN development environment and vehicle dynamics simulation software, vehicle bus network simulation environment and high-precision vehicle dynamics model are configured respectively, and real-time data interaction channel between them is established through full-duplex transmission protocol of CAN development environment; Driver model instruction is generated by using preset driving control panel in the CAN development environment, and the driver model instruction is sent to the vehicle dynamics simulation software through the full-duplex transmission protocol to generate vehicle state variables; Wheel speed signal in the vehicle state variables is received by using the CAN development environment, and is converted into physical excitation signal output to the brake controller of the measured object, and wheel cylinder pressure signal is output; The wheel cylinder pressure signal is input into the vehicle dynamics model, preset test scene is executed in closed loop by operating the driving control panel, control strategy function of the brake controller in the closed loop simulation environment is verified, and desktop level hardware-in-the-loop test of the brake controller is completed.

[0007] Preferably, in the host computer installed with CAN development environment and vehicle dynamics simulation software, vehicle bus network simulation environment and high-precision vehicle dynamics model are configured respectively, and real-time data interaction channel between them is established through full-duplex transmission protocol of CAN development environment includes: In the CAN development environment, DBC file is loaded and CAPL script is written to simulate vehicle bus network; Driving control panel is designed to generate control interface including steering wheel, accelerator pedal and virtual brake pedal; Interaction signal variable list between the CAN development environment and the vehicle dynamics simulation software is defined, the interaction signals include vehicle body posture, wheel speed, steering wheel angle, accelerator opening and wheel cylinder pressure; Vehicle model and road model are configured, and interaction signal variables defined in the full-duplex transmission are mapped and unit converted with internal signals of the vehicle dynamics simulation software vehicle model based on API of the vehicle dynamics simulation software.

[0008] Preferably, the driver model instruction is generated by using the preset driving control panel in the CAN development environment, and the driver model instruction is sent to the vehicle dynamics simulation software through the full-duplex transmission protocol to generate vehicle state variables includes: Driver model instruction is generated based on driving control panel, and is sent to vehicle dynamics simulation software vehicle model through full-duplex transmission protocol to drive vehicle dynamics simulation to run; Based on the vehicle dynamics simulation running, vehicle state variables are calculated, and the vehicle state variables are sent to the CAN development environment through the full-duplex transmission protocol.

[0009] Preferably, the CAN development environment receives the wheel speed signal in the vehicle state variable and converts it into a physical excitation signal output to the brake controller of the object under test, and the output wheel cylinder pressure signal includes: The wheel speed signal of the vehicle state variable is converted into a CAN message and sent to the wheel speed simulator through the CAN development environment bus; The CAN wheel speed signal is output to the brake controller of the object under test through a hard-wired line, and the brake controller of the object under test is powered by a programmed power supply; Simulate the vehicle bus network, collect the wheel cylinder pressure signal output by the brake controller of the object under test in response to the wheel speed signal.

[0010] Preferably, the wheel cylinder pressure signal is input into the vehicle dynamics model, and the preset test scenario is executed in a closed loop by operating the driving control panel to verify the control strategy function of the brake controller in the closed loop simulation environment, and the desktop level hardware-in-the-loop test of the brake controller includes: The wheel cylinder pressure signal is fed back to the vehicle dynamics model through a full-duplex transmission protocol; Based on the driver model instruction, the wheel speed signal and the wheel cylinder pressure signal, the vehicle motion state is calculated, and the updated vehicle motion state is transmitted to the CAN development environment again through the full-duplex transmission protocol; Trigger the test scenario in the closed loop by operating the driving control panel, detect the control logic response of the brake controller of the object under test, and complete the closed loop verification of the control strategy of the brake controller.

[0011] Preferably, one of the test scenarios is an ABS function activation test, which includes: after the vehicle is accelerated to the target speed by the driving control panel, a virtual brake pedal signal is triggered to build pressure for the brake controller of the object under test, and the ABS function of the brake controller of the object under test is observed during the vehicle deceleration process. Whether it is activated correctly.

[0012] According to a second aspect of the present disclosure, a desktop level hardware-in-the-loop test system building device is provided, comprising: An environment configuration module, in a host computer installed with a CAN development environment and vehicle dynamics simulation software, respectively completes the configuration of a vehicle bus network simulation environment and a high-precision vehicle dynamics model, and establishes a real-time data interaction channel between the two through a full-duplex transmission protocol of the CAN development environment; A model building module generates a driver model instruction using a driving control panel preset in the CAN development environment, and sends the driver model instruction to the vehicle dynamics simulation software using the full-duplex transmission protocol to generate a vehicle state variable; The signal acquisition module receives wheel speed signals in the vehicle state variables by using the CAN development environment and converts the wheel speed signals into physical excitation signals output to the brake controller of the measured object and outputs wheel cylinder pressure signals; The closed-loop test module inputs the wheel cylinder pressure signals into a vehicle dynamics model, executes preset test scenarios in a closed-loop circuit by operating the driving control panel, verifies the control strategy function of the brake controller in the closed-loop simulation environment, and completes the desktop-level hardware-in-the-loop test of the brake controller.

[0013] According to a third aspect of the present disclosure, an electronic device is provided, comprising: at least one processor; and a memory in communication with the at least one processor; wherein The memory stores instructions executable by the at least one processor, and the instructions are executed by the at least one processor to enable the at least one processor to perform the method of the first aspect.

[0014] According to a fourth aspect of the present disclosure, a non-transitory computer-readable storage medium storing computer instructions is provided, wherein the computer instructions are used to enable the computer to perform the method of the first aspect.

[0015] According to a fifth aspect of the present disclosure, a computer program product is provided, comprising a computer program which, when executed by a processor, implements the method of the first aspect.

[0016] In the embodiments provided by the present disclosure, the CarSim software is used as a high-precision vehicle model of professional vehicle dynamics simulation software, which can realistically simulate the dynamic response of a real vehicle under various working conditions, so that the verification result of the desktop-level hardware-in-the-loop test is closer to the performance of the real vehicle, greatly improving the credibility and effectiveness of the functional test; the original FDX protocol of the CANoe software is used as the data interaction channel between CarSim and CANoe. This protocol is designed for efficient data exchange, avoiding the problems of long development cycle, complicated debugging, high stability risk and the like caused by developing a communication interface, realizing stable, efficient and low-delay real-time data communication between the two simulation environments, and ensuring the real-time requirement of the closed-loop test; the FDX Editor tool of the CANoe is used to predefine and uniformly manage the interactive signal variables, so that the user does not need to pay close attention to the underlying communication details, and only needs to complete the standardized configuration such as signal mapping and unit conversion, so as to quickly build the test environment. This significantly reduces the technical threshold of the hardware-in-the-loop test, so that software engineers can conveniently perform independent testing at an early stage of development, supporting agile development processes.

[0017] It is to be understood that the details set forth herein do not limit the key or critical features of the present disclosure. Other features of the present disclosure will be apparent from the following specification, and the claims. BRIEF DESCRIPTION OF DRAWINGS

[0018] The accompanying drawings are used to better understand the present scheme and do not limit the present disclosure. Among them: Figure 1 A flowchart of a desktop hardware-in-the-loop test system building method provided by the related art; Figure 2 A system diagram of a desktop hardware-in-the-loop test system building method provided by an embodiment of the present disclosure; Figure 3 A structural diagram of a desktop hardware-in-the-loop test system building device provided by an embodiment of the present disclosure. DETAILED DESCRIPTION

[0019] Exemplary embodiments of the present disclosure are described below with reference to the accompanying drawings, which include various details of the embodiments of the present disclosure to help understanding. They should be considered only as exemplary. Therefore, those of ordinary skill in the art should recognize that various changes and modifications can be made to the embodiments described herein without departing from the scope and spirit of the present disclosure. Also, for the sake of clarity and conciseness, descriptions of well-known functions and structures are omitted in the following description.

[0020] A desktop hardware-in-the-loop test system building method, device and equipment of an embodiment of the present disclosure are described below with reference to the accompanying drawings.

[0021] Figure 1 A flowchart of a desktop hardware-in-the-loop test system building method provided by an embodiment of the present disclosure. As shown in Figure 1 The method comprises the following steps: Step S101: In a host computer installed with a CAN development environment and vehicle dynamics simulation software, a vehicle bus network simulation environment and a high-precision vehicle dynamics model are respectively configured, and a real-time data interaction channel between the two is established through a full-duplex transmission protocol of the CAN development environment; Step S102: A driver model instruction is generated by using a preset driving control panel in the CAN development environment, and the driver model instruction is sent to the vehicle dynamics simulation software by using the full-duplex transmission protocol to generate a vehicle state variable; Step S103: A wheel speed signal in the vehicle state variable is received by using the CAN development environment and converted into a physical excitation signal output to a brake controller of a measured object to output a wheel cylinder pressure signal; Step S104: input the wheel cylinder pressure signal into the vehicle dynamics model, execute a preset test scene in a closed loop by operating the driving control panel, verify the control strategy function of the brake controller in the closed loop simulation environment, and complete the desktop level hardware-in-the-loop test of the brake controller.

[0022] Based on the above embodiment, step S101 is described in detail in this embodiment: In one embodiment, in the CAN development environment (CANoe), a DBC file is loaded and a CAPL script is written to simulate the vehicle bus network; A driving control panel is designed to generate a control interface including a steering wheel, an accelerator pedal, and a virtual brake pedal; Define the interactive signal variable list between the CAN development environment and the vehicle dynamics simulation software (CarSim), including vehicle body attitude, wheel speed, steering wheel angle, throttle opening, and wheel cylinder pressure; Configure the vehicle model and the road model, and map and convert the internal signals of the vehicle dynamics simulation software vehicle model based on the API of the vehicle dynamics simulation software to the interactive signal variables defined in the full duplex transmission (FDX Editor).

[0023] Specifically, CANoe simulates vehicle bus network communication with the controlled object brake controller (IBC) through DBC file and CAPL script, designs a driving control panel including steering wheel, accelerator pedal, virtual brake pedal, etc. through CANoe Panel Designer, defines the interactive signals between CANoe and Carsim through FDX Editor, including vehicle body attitude, wheel speed, steering wheel, throttle, wheel cylinder pressure, etc.

[0024] Based on the above embodiment, step S102 is described in detail in this embodiment: In one embodiment, the driver model instruction is generated based on the driving control panel, sent to the vehicle dynamics simulation software vehicle model through the full duplex transmission protocol, and the vehicle dynamics simulation is driven to run; Based on the vehicle dynamics simulation running, the vehicle state variables are calculated, and the vehicle state variables are sent to the CAN development environment using the full duplex transmission protocol.

[0025] Specifically, first, the basic simulation environment is built in the user interface of the CarSim software. An operator selects a reference vehicle model template from a vehicle model library built in CarSim, and adjusts or inputs relevant vehicle parameters such as wheelbase, track, mass distribution, suspension characteristics, and tire model in a graphical configuration interface according to test requirements. Meanwhile, in the road modeling module, environmental conditions such as road profile, road adhesion coefficient, and slope required for testing are defined. These configurations together constitute a runnable high-precision vehicle dynamics simulation scene; Subsequently, key signal interface configuration is performed to realize integration with an external test system (CANoe). Previously, a structured interactive signal variable list has been defined in the FDX Editor tool of CANoe. The operator calls an application programming interface provided by the CarSim software. Through the API, the internal signal database of the CarSim vehicle model is accessed in a programmed manner, and each external signal variable listed in the FDX Editor list is accurately associated with the corresponding internal dynamics variable in the CarSim model, i.e., signal mapping is completed; After the above mapping and configuration are completed, the CarSim simulation model is endowed with a standardized external data interface. When the simulation is running, the dynamic signals generated by internal calculation of the model will be automatically output in real time through the FDX channel; at the same time, external control instructions from the FDX channel can also be accurately received and used as input driving of the model. At this point, CarSim has transformed from an independent simulation tool into a real-time interactive "virtual vehicle" module in the entire hardware-in-the-loop test system, laying a foundation for subsequent closed-loop testing.

[0026] Based on the above embodiment, step S103 is described in detail: In one embodiment, the wheel speed signal of the vehicle state variable is converted into a CAN message and sent to a wheel speed simulator through a CAN development environment bus; The CAN wheel speed signal is output to the brake controller of the object under test through a hard-wired line, and the brake controller of the object under test is powered through a programmed power supply; The vehicle bus network is simulated, and the wheel cylinder pressure signal output by the brake controller of the object under test in response to the wheel speed signal is collected.

[0027] Specifically, first, in the simulation environment of the CANoe software, the wheel speed signals output in real time by the CarSim vehicle dynamics model through the FDX protocol are received as simulation variables. These wheel speed signals contain the rotational speed information of each wheel of the vehicle.

[0028] In the CAPL script, the signal conversion and message encapsulation functions are completed. The script periodically reads the wheel speed simulation variables from CarSim transmitted through the FDX channel. Then, the script converts the wheel speed simulation variables into integer raw values in accordance with the predefined communication rules, and constructs CAN messages containing valid wheel speed information in accordance with the definition of the target DBC file; Subsequently, the CANoe software sends the CAN message to the CAN bus connected to the CAN interface of the wheel speed simulator. As a dedicated signal conversion device, the wheel speed simulator receives and analyzes the wheel speed message from the CAN bus through its internal firmware. The analysis process accurately extracts the speed raw values of each wheel from the message according to the same DBC specification; Finally, the wheel speed simulator converts the speed values of each wheel into corresponding continuous hard-wire electrical signals.

[0029] Based on the above embodiment, step S104 is described in detail: In one embodiment, the wheel cylinder pressure signal is fed back to the vehicle dynamics model through a full-duplex transmission protocol; Based on the driver model instructions, the wheel speed signal and the wheel cylinder pressure signal, the vehicle motion state is calculated, and the updated vehicle motion state is transmitted again to the CAN development environment through a full-duplex transmission protocol; By operating the driving control panel, the test scenarios in the closed loop are triggered to detect the control logic response of the brake controller of the measured object, and the closed loop verification of the control strategy of the brake controller is completed, wherein one of the test scenarios is ABS function activation test, including: after controlling the vehicle to accelerate to the target speed through the driving control panel, triggering the virtual brake pedal signal to make the measured object brake controller build pressure, and observing whether the ABS function of the measured object brake controller is correctly activated during the vehicle deceleration process through the closed loop.

[0030] Specifically, the tester operates the graphical driving control panel created by Panel Designer in the CANoe software, generates the throttle opening control instruction by adjusting the virtual throttle pedal control on the panel. The instruction is input as a driver model, transmitted in real time to the CarSim vehicle dynamics model through the FDX protocol, and drives the virtual vehicle to start accelerating motion in the simulation road environment. By continuously controlling the throttle opening, the vehicle simulated by the CarSim model gradually increases the speed until the preset target speed condition is reached. At this time, the tester sends a brake request signal through the virtual brake pedal control on the same driving control panel. The signal is transmitted to the measured object, the integrated brake controller IBC, through the CANoe simulation bus, triggering the IBC to enter the pressure building control logic; The IBC calculates and outputs the wheel cylinder pressure control instruction according to the real-time received wheel speed hard-wired signal and its internal algorithm. The actual pressure signal is captured in real time through the CAN card and is taken as a key feedback variable, which is returned to the CarSim vehicle model through CANoe and FDX protocol and acts on the brake system interface of the model. After the CarSim model receives the actual wheel cylinder pressure feedback, the vehicle motion state is updated in real time based on high-precision dynamic calculation, especially the slip state change of the wheel during braking. When the model calculation shows that a wheel tends to lock, the corresponding wheel speed change signal is fed back to the IBC through a closed loop. The IBC identifies the anti-lock braking condition and executes the ABS control strategy to dynamically adjust the wheel cylinder pressure. The pressure change is collected again and fed back to the model, so that the closed-loop control process of "vehicle braking-slip generation-ABS intervention-pressure regulation-vehicle state update" is completely reproduced in the simulation environment, and the dynamic verification of the ABS function of the IBC in the desktop environment is realized.

[0031] The embodiment provides a desktop-level hardware-in-the-loop test system building method, which uses CarSim software as a high-precision vehicle model of professional vehicle dynamics simulation software, can realistically simulate the dynamic response of a real vehicle under various working conditions, makes the verification result of the desktop-level hardware-in-the-loop test closer to the real vehicle performance, and greatly improves the credibility and effectiveness of the functional test; the original FDX protocol of the CANoe software is used as the data interaction channel between CarSim and CANoe. The protocol is specially designed for efficient data exchange, avoids the problems of long development cycle, complicated debugging, high stability risk and the like caused by developing a communication interface, realizes stable, efficient and low-delay real-time data communication between the two simulation environments, and guarantees the real-time requirement of the closed-loop test; the FDX Editor tool of the CANoe is used to predefine and uniformly manage the interactive signal variables, users do not need to pay close attention to the underlying communication details, only need to complete standardized configurations such as signal mapping and unit conversion, and the test environment can be quickly built. This significantly reduces the technical threshold of the hardware-in-the-loop test, enables software engineers to conveniently perform independent testing in the early development stage, and supports the agile development process.

[0032] Based on the above embodiment, the embodiment briefly describes a system built by the desktop-level hardware-in-the-loop test system building method, as shown in Figure 2 , and the specific implementation is as follows. The system consists of the following parts: host computer (running CANoe and CarSim), program-controlled power supply (powering IBC), wheel speed simulator (generating wheel speed hardwire signal), acquisition CAN card (acquiring IBC output wheel cylinder pressure), and Vector board card (simulating the whole vehicle CAN network). Each component works cooperatively through explicit connection relationship, and the core is to use the FDX protocol of CANoe to seamlessly bridge the high-precision vehicle dynamics simulation environment and the real hardware test environment.

[0033] The system core connection and data flow relationship are as follows: Virtual simulation closed loop: a special data channel is established between CANoe and CarSim through FDX protocol to form an inter-software closed loop. CarSim transmits vehicle model state variables (such as wheel speed and acceleration) to CANoe in real time; CANoe feeds back the driver's instructions and the wheel cylinder pressure collected from the real IBC to CarSim to drive the model to update.

[0034] Signal injection link: for the wheel speed input required by IBC, a physical signal generation link is built: CarSim wheel speed → (FDX) → CANoe → (CAN message) → wheel speed simulator → (hardwire) → IBC.

[0035] Real hardware interaction: for the input and output of IBC, two hardware interaction channels are built: Input channel: IBC receives bus signals such as vehicle body attitude from CANoe through the CAN network simulated by the Vector board card.

[0036] Output and feedback channel: the wheel cylinder pressure instructions calculated by IBC are captured by the acquisition CAN card and fed back to CANoe, and then injected into the CarSim model through the FDX protocol.

[0037] Complete control closed loop: finally, the system realizes the hardware-in-the-loop closed loop control including the real controller IBC through the complete data flow of "driver's instruction driving model → model state output and converted into physical signal exciting IBC → IBC response being captured and fed back to the model", so as to be able to verify the control strategy (such as ABS function) with high confidence.

[0038] Through the description of the above implementation mode, those skilled in the art can clearly understand that the method according to the above embodiment can be realized by means of software and necessary general hardware platform, of course, it can also be realized by hardware, but in many cases the former is a better implementation mode.

[0039] According to the embodiments of the present disclosure, the present disclosure also provides a desktop-level hardware-in-the-loop test system building device. Exemplarily, Figure 3A structural schematic diagram of a desktop hardware-in-the-loop test system building device provided by an embodiment of the present disclosure. The desktop hardware-in-the-loop test system building device 300 comprises: An environment configuration module 310, in a host computer installed with a CAN development environment and vehicle dynamics simulation software, respectively completes configuration of a vehicle bus network simulation environment and a high-precision vehicle dynamics model, and establishes a real-time data interaction channel between the two through a full-duplex transmission protocol of the CAN development environment; A model construction module 320 generates a driver model instruction using a preset driving control panel in the CAN development environment, and sends the driver model instruction to the vehicle dynamics simulation software using the full-duplex transmission protocol to generate a vehicle state variable; A signal acquisition module 330 receives a wheel speed signal in the vehicle state variable using the CAN development environment, and converts the wheel speed signal into a physical excitation signal output to a brake controller of a measured object and outputs a wheel cylinder pressure signal; A closed-loop test module 340 inputs the wheel cylinder pressure signal into the vehicle dynamics model, executes a preset test scene in a closed-loop circuit by operating the driving control panel, verifies a control strategy function of the brake controller in the closed-loop simulation environment, and completes desktop hardware-in-the-loop test of the brake controller.

[0040] It should be noted that the description of the features in the embodiment corresponding to the desktop hardware-in-the-loop test system building device can refer to the related description of the embodiment corresponding to the method, which will not be repeated here.

[0041] An electronic device is also provided by an embodiment of the present disclosure, comprising a memory and a processor, the memory stores a computer program, and the processor is configured to run the computer program to execute the steps in any of the above method embodiments.

[0042] An embodiment of the present disclosure also provides a computer readable storage medium, which stores a computer program, wherein the computer program is configured to execute the steps in any of the above method embodiments when running.

[0043] In an example embodiment, the above computer readable storage medium can include, but is not limited to, a U disk, a read-only memory (ROM), a random access memory (RAM), a mobile hard disk, a magnetic disk or an optical disk, and various media that can store computer programs.

[0044] Embodiments of the present disclosure further provide a computer program product including a computer program, the computer program being executed by a processor to implement the steps in any of the method embodiments.

[0045] Embodiments of the present disclosure further provide another computer program product including a non-volatile computer readable storage medium, the non-volatile computer readable storage medium storing a computer program, the computer program being executed by a processor to implement the steps in any of the method embodiments.

[0046] Those skilled in the art will further appreciate that the units and algorithm steps of the examples described in connection with the embodiments disclosed herein can be implemented in electronic hardware, computer software, or both, and that the implementation decisions are within the skill of an ordinary designer of such products. The functions of the examples described herein have been described in general terms as being performed by the various units and algorithm steps. Whether such functions are performed in hardware or software depends on the particular application and design constraints imposed on the overall system. Skilled artisans can implement the described functionality in varying ways for each particular application, but such implementation decisions should not be interpreted as causing a departure from the scope of the present disclosure.

[0047] The above describes in detail a target detection method provided by the present disclosure. The principles and implementation manners of the present disclosure are described by applying specific examples. The above description of the embodiments is only for helping to understand the method of the present disclosure and its core idea. It should be noted that, for those skilled in the art, without departing from the principles of the present disclosure, the present disclosure can be improved and modified in several ways. These improvements and modifications also fall within the protection scope of the claims of the present disclosure.

Claims

1. A desktop hardware-in-the-loop test system building method, characterized in that, The application relates to a desktop-level hardware-in-the-loop test method for a brake controller. The application comprises the following steps: In a host computer installed with a CAN development environment and vehicle dynamics simulation software, a vehicle bus network simulation environment and a high-precision vehicle dynamics model are respectively configured, and a real-time data interaction channel between the two is established through a full-duplex transmission protocol of the CAN development environment; Driver model instructions are generated by using a preset driving control panel in the CAN development environment, and the driver model instructions are sent to the vehicle dynamics simulation software through the full-duplex transmission protocol to generate vehicle state variables; Wheel speed signals in the vehicle state variables are received by using the CAN development environment, and are converted into physical excitation signals which are output to a brake controller of a measured object to output a wheel cylinder pressure signal; 2. The desktop hardware-in-the-loop test system building method according to claim 1, wherein, The wheel cylinder pressure signal is input into the vehicle dynamics model, a preset test scene is executed in a closed loop by operating the driving control panel, the control strategy function of the brake controller in the closed loop simulation environment is verified, and the desktop-level hardware-in-the-loop test of the brake controller is completed. The application comprises the following steps: In the CAN development environment, a DBC file is loaded and a CAPL script is written to simulate a vehicle bus network; A driving control panel is designed to generate a control interface containing a steering wheel, an accelerator pedal and a virtual brake pedal; An interactive signal variable list between the CAN development environment and the vehicle dynamics simulation software is defined, and the interactive signals include a vehicle body posture, a wheel speed, a steering wheel rotation angle, an accelerator opening degree and a wheel cylinder pressure; 3. The desktop hardware-in-the-loop testing system building method of claim 1, wherein, A vehicle model and a road model are configured, and the interactive signal variables defined in the full-duplex transmission are mapped and unit-converted with internal signals of the vehicle model of the vehicle dynamics simulation software based on an API of the vehicle dynamics simulation software. The application comprises the following steps: Driver model instructions are generated based on the driving control panel, and are sent to the vehicle model of the vehicle dynamics simulation software through the full-duplex transmission protocol to drive the vehicle dynamics simulation to run; 4. The desktop hardware-in-the-loop test system building method of claim 3, wherein, Based on the vehicle dynamics simulation running, vehicle state variables are calculated, and the vehicle state variables are sent to the CAN development environment through the full-duplex transmission protocol. The application comprises the following steps: Wheel speed signals of the vehicle state variables are converted into CAN messages, and are sent to a wheel speed simulator through a bus of the CAN development environment; CAN wheel speed signals are output to the brake controller of the measured object through a hard wire, and the brake controller of the measured object is powered through a programmed power supply; The application comprises the following steps: Wheel speed signals of the vehicle state variables are converted into CAN messages, and are sent to a wheel speed simulator through a bus of the CAN development environment; CAN wheel speed signals are output to the brake controller of the measured object through a hard wire, and the brake controller of the measured object is powered through a programmed power supply; An analog vehicle bus network is simulated, and a wheel cylinder pressure signal output by a brake controller of a measured object in response to the wheel speed signal is collected.

5. The desktop hardware-in-the-loop test system building method according to claim 4, characterized in that, The wheel cylinder pressure signal is input into a vehicle dynamics model, preset test scenarios are executed in a closed loop by operating the driving control panel, the control strategy function of the brake controller in the closed loop simulation environment is verified, and the desktop level hardware-in-the-loop test of the brake controller is completed. The wheel cylinder pressure signal is fed back to the vehicle dynamics model through a full-duplex transmission protocol. Based on the driver model instruction, the wheel speed signal and the wheel cylinder pressure signal, the vehicle motion state is calculated, and the updated vehicle motion state is transmitted to the CAN development environment again through the full-duplex transmission protocol. The test scenarios are triggered in the closed loop by operating the driving control panel, the response of the control logic of the brake controller of the measured object is detected, and the closed loop verification of the control strategy of the brake controller is completed.

6. The desktop hardware-in-the-loop testing system building method of claim 1, wherein, The ABS function activation test is one of the test scenarios, which includes triggering a virtual brake pedal signal to make the brake controller of the measured object build pressure after the vehicle is accelerated to a target speed by the driving control panel, and observing whether the ABS function of the brake controller of the measured object is activated correctly during the vehicle deceleration process through the closed loop.

7. A desktop hardware-in-the-loop test system building device, characterized in that, It comprises: An environment configuration module, which is installed in an upper computer with a CAN development environment and vehicle dynamics simulation software, respectively completes the configuration of a vehicle bus network simulation environment and a high-precision vehicle dynamics model, and establishes a real-time data interaction channel between the two through a full-duplex transmission protocol of the CAN development environment; A model building module, which generates a driver model instruction using a preset driving control panel in the CAN development environment, and sends the driver model instruction to the vehicle dynamics simulation software using the full-duplex transmission protocol to generate vehicle state variables; A signal collection module, which receives a wheel speed signal in the vehicle state variables using the CAN development environment, and converts the wheel speed signal into a physical excitation signal output to the brake controller of the measured object to output a wheel cylinder pressure signal; A closed loop test module, which inputs the wheel cylinder pressure signal into the vehicle dynamics model, executes preset test scenarios in a closed loop by operating the driving control panel, verifies the control strategy function of the brake controller in the closed loop simulation environment, and completes the desktop level hardware-in-the-loop test of the brake controller.

8. An electronic device, comprising: It comprises: At least one processor; And A memory connected in communication with the at least one processor; wherein The memory stores instructions executable by the at least one processor, and the instructions are executed by the at least one processor to enable the at least one processor to execute the method of any one of claims 1-6.

9. A non-transitory computer-readable storage medium having stored thereon computer instructions, wherein, The computer instructions are used to enable the computer to execute the method of any one of claims 1-6.

10. A computer program product, characterised in that, It comprises a computer program, which, when executed by a processor, implements the method of any one of claims 1-6. It comprises a computer program, which, when executed by a processor, implements the method of any one of claims 1-6.

Images