Debugging method and device of semi-physical simulation system and computer equipment

Abstract

The invention relates to a debugging method and device of a semi-physical simulation system and computer equipment. According to the method, a dual-mode dynamic switching architecture is utilized, a dynamic analysis scheme based on a configuration file is adopted during debugging, and the requirements of flexible adjustment and convenient and flexible debugging in the debugging stage can be met. After debugging is completed, the protocol conversion configuration file is compiled into a machine code in advance through the JIT compilation technology, one-time compilation and repeated use are achieved, configuration analysis and dynamic calculation during packing / unpacking each time can be reduced, delay is reduced, the throughput capacity is improved, and the simulation operation efficiency is improved. According to the method, the flexibility requirement in the debugging stage and the performance requirement in the operation stage can be met at the same time.

Description

Technical Field

[0001] This application relates to the field of hardware-in-the-loop simulation technology, and in particular to a debugging method, apparatus and computer equipment for a hardware-in-the-loop simulation system. Background Technology

[0002] In hardware-in-the-loop simulation systems, the data packet assembly and unpacking processing of bus communication protocols (such as ARINC 429 and MIL-STD-1553B) mainly adopts a static code generation scheme based on modeling tools and a dynamic parsing scheme based on configuration files.

[0003] One approach, based on modeling tools, uses a simulation modeling environment (such as Simulink or LabVIEW) to build an assembly / disassembly logic model and generate static executable code. This approach offers performance optimization but suffers from cumbersome debugging.

[0004] The configuration file-based dynamic parsing scheme loads and parses configuration files (JSON / XML, etc.) in real time during system runtime, dynamically constructing the assembly / unassembly logic. This scheme offers flexible debugging but suffers from poor performance.

[0005] It is evident that existing bus communication protocols (such as ARINC 429 and MIL-STD-1553B) have a trade-off between ease of debugging and performance in their data packet assembly and unpacking processes. Summary of the Invention

[0006] Therefore, it is necessary to provide a debugging method, apparatus, and computer equipment for a hardware-in-the-loop simulation system that meets the requirements of flexible debugging and simulation performance, in order to address the above-mentioned technical problems.

[0007] Firstly, this application provides a debugging method for a hardware-in-the-loop simulation system, the method comprising: In response to debugging commands, obtain the structured protocol conversion configuration file; Parse the protocol conversion configuration file to obtain the attribute values ​​of the protocol conversion parameters; Based on the attribute values ​​of the protocol conversion parameters and the input simulation control parameters, a simulation data packet is generated and sent to the simulation platform. The simulation platform unpacks the data packet according to the attribute values ​​of the protocol conversion parameters and inputs the unpacked physical quantities into the simulation model for execution, thereby verifying the protocol conversion configuration file. When the conditions are met, the machine code corresponding to the protocol conversion configuration file is generated using JIT technology and saved.

[0008] In one embodiment, generating the machine code corresponding to the protocol conversion configuration file using JIT technology includes: Freeze the current structured protocol conversion configuration file; Match the template file corresponding to the protocol conversion configuration file according to the protocol type; If a matching template file is found, the attribute values ​​of the protocol conversion parameters are filled into the template file, and packet assembly code and / or unpacking code are generated based on the template file. The JIT compiler is invoked to compile the assembly and / or unassembly code into machine code for the simulation platform.

[0009] In one embodiment, the method further includes: If no matching template file is found, the field definitions in the protocol replacement configuration file are recursively parsed to obtain a tree structure of field definitions. Instantiate the corresponding node based on the attribute values ​​of the protocol conversion parameters, establish reference relationships, and generate the AST; Traverse the AST and generate corresponding code snippets for each node; Generate assembly and / or unpacking code based on the code snippets of each node; The JIT compiler is invoked to compile the assembly and / or unassembly code into machine code for the simulation platform.

[0010] In one embodiment, the condition is determined to be met when a simulation compilation instruction triggered by the interface is detected.

[0011] In one embodiment, if no update to the protocol conversion configuration file is detected within a preset time period, it is determined that the condition is met.

[0012] In one embodiment, the response to switching to simulation mode includes: If no update is detected in the protocol configuration file within a preset time period, check whether it is in a preset prohibited compilation state; After the compilation ban is lifted, it is determined that the conditions are met.

[0013] In one embodiment, the method further includes: Obtain simulation control parameters; The machine code corresponding to the packet assembly function is called to convert the simulation control parameters into binary protocol data packets required by the simulation platform.

[0014] In one embodiment, the method further includes: Obtain the binary raw data packet to be sent by the simulation platform; The machine code corresponding to the unpacking function is invoked to convert the binary raw data packet into the corresponding physical quantity.

[0015] Secondly, this application also provides a debugging device for a hardware-in-the-loop simulation system, the device comprising: The configuration module is used to obtain a structured protocol conversion configuration file in response to debugging commands; The parsing module is used to parse the protocol conversion configuration file and obtain the attribute values ​​of the protocol conversion parameters; The verification module is used to assemble the simulation data packet according to the attribute value of the protocol conversion parameter and the input simulation control parameter, and send the simulation data packet to the simulation platform. The simulation platform unpacks the data packet according to the attribute value of the protocol conversion parameter and inputs the unpacked physical quantity into the simulation model for execution, so as to verify the protocol conversion configuration file. The compilation module is used to generate and save the machine code corresponding to the protocol conversion configuration file using JIT technology when the conditions are met.

[0016] Thirdly, this application also provides a computer device, including a memory and a processor, wherein the memory stores a computer program, and the processor executes the computer program to implement the steps of the above-described debugging method for a hardware-in-the-loop simulation system.

[0017] The aforementioned hardware-in-the-loop simulation system's debugging equipment and computer devices utilize a dual-mode dynamic switching architecture. During debugging, a configuration file-based dynamic parsing scheme is employed, meeting the needs for flexible adjustments and convenient debugging. After debugging, JIT compilation technology is used to pre-compile the protocol conversion configuration file into machine code, allowing for compilation once and reuse multiple times. This reduces configuration parsing and dynamic calculations during each packet assembly / disassembly, minimizing latency, increasing throughput, and improving simulation efficiency. This method achieves a balance between the flexibility required during debugging and the performance requirements during runtime. Attached Figure Description

[0018] Figure 1 This is a schematic diagram illustrating an application scenario of a debugging method for a semi-physical simulation system in one embodiment.

[0019] Figure 2 This is a flowchart illustrating the debugging method of a semi-physical simulation system in one embodiment.

[0020] Figure 3 This is a flowchart illustrating the steps of generating the machine code corresponding to the protocol conversion configuration file using JIT technology in one embodiment.

[0021] Figure 4 This is a flowchart illustrating the debugging mode in one embodiment.

[0022] Figure 5 This is a flowchart illustrating the JIT compilation mode in one embodiment.

[0023] Figure 6This is a schematic diagram of the debugging device of a semi-physical simulation system in one embodiment.

[0024] Figure 7 This is a schematic diagram of the structure of a computer device in one embodiment. Detailed Implementation

[0025] To make the objectives, technical solutions, and advantages of this application clearer, the following detailed description is provided in conjunction with the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are merely illustrative and not intended to limit the scope of this application.

[0026] This application provides a debugging method for a hardware-in-the-loop simulation system, applicable to, for example... Figure 1 The simulation environment shown. (As shown) Figure 1 As shown, the simulation environment includes a terminal 102 and a simulation platform 104 connected to the terminal. The terminal 102 can be configured with protocol conversion parameters and simulation control parameters, and can assemble packets according to these parameters, sending the assembled packets to the simulation platform. The simulation platform then unpacks and runs the packets to obtain the simulation results.

[0027] The debugging method for the hardware-in-the-loop simulation system provided in this application is used in applications such as... Figure 1 The terminal 102 shown is as follows: Figure 2 As shown, it includes the following steps: Step 202: In response to the debugging command, obtain the structured protocol conversion configuration file.

[0028] The protocol configuration conversion file is a structured configuration file used to configure the communication protocol. It defines the communication conversion rules and represents the conversion protocol between physical quantities and raw data. It is typically in JOSN or XML format. The protocol conversion configuration file includes the attribute values ​​of the protocol conversion parameters. Commonly used protocol conversion parameters include, but are not limited to, scaling factors, field positions, validation rules, and nonlinearity rules.

[0029] In actual business operations, when signal conversion errors occur, field position conflicts arise, data validation fails, or nonlinear rules change, debugging is usually required, necessitating modification of the corresponding protocol conversion configuration file. At this point, users can enter debug mode via the interface's toggle button and modify the protocol conversion configuration file through the corresponding configuration interface.

[0030] Step 204: Parse the protocol conversion configuration file to obtain the attribute values ​​of the protocol conversion parameters.

[0031] Specifically, a parser corresponding to the file format is used to parse the protocol conversion configuration file and extract the values ​​of the protocol conversion parameters according to the predefined field names. The attribute values ​​of the protocol conversion parameters define how physical quantities (such as temperature, pressure, and speed) are converted into raw data in the communication protocol (such as byte data in a CAN frame), and how the raw data is converted back into physical quantities. For example, the scaling factor defines the proportional relationship between the physical quantity and the original value, and the field position value determines the position of the signal in the data frame.

[0032] Step 206: Based on the attribute values ​​of the protocol conversion parameters and the input simulation control parameters, a simulation data packet is generated and sent to the simulation platform. The simulation platform unpacks the data packet according to the attribute values ​​of the protocol conversion parameters and inputs the unpacked physical quantities into the simulation model to verify the protocol conversion configuration.

[0033] This step utilizes the attribute values ​​of the protocol conversion parameters to package the input simulation control parameters and send them to the simulation platform. The simulation platform then unpacks and runs the packages to obtain simulation results, thereby verifying the correctness of the protocol conversion configuration through the simulation results.

[0034] For example, during a debugging session, the scaling factor of the engine speed (Engine_RPM) signal was modified (from 0.25 to 0.125). To verify the correctness of the protocol modification, the simulation control parameter can be set to: Engine_RPM = 3000 (physical quantity, unit RPM). Then, based on the new scaling factor of 0.125, the original value is calculated as 3000 / 0.125 = 24000 (i.e., 0x5DC0). A CAN frame containing 0x5DC0 is sent to the simulation platform. The simulation platform uses the same scaling factor of 0.125 to unpack 0x5DC0 into 24000 × 0.125 = 3000 RPM. Using 3000 RPM as input, engine torque, etc., is calculated. The simulation platform may send the calculated torque value to the ECU according to the protocol or return it directly to the debugging environment. The debugging environment receives the torque value and verifies whether it matches expectations (e.g., at 3000 RPM, the expected torque is 450 Nm). If the speed obtained after unpacking is 3000 RPM and the torque output by the model is correct, then the protocol configuration has been modified correctly.

[0035] Step 208: When the conditions are met, use JIT technology to generate the machine code corresponding to the protocol conversion configuration file and save it.

[0036] When certain conditions are met (such as stable protocol configuration and the need for high-performance execution), JIT (Just-In-Time) compilation technology is used to compile the protocol conversion configuration (i.e., protocol conversion rules) into machine code. This machine code is used to assemble or unassemble packets based on real-time simulation control parameters. In subsequent real-time simulations, packet assembly and unassembly operations can directly call the efficient machine code, thereby improving performance.

[0037] In this embodiment, during debugging, the structured protocol conversion configuration file is parsed to obtain the attribute values ​​of the protocol conversion parameters. Packet assembly and decompression are then performed based on these attribute values ​​to verify the correctness of the protocol conversion configuration. When certain conditions are met, JIT technology is used to generate machine code corresponding to the protocol conversion configuration file. This allows for direct invocation of pre-generated machine code functions during real-time simulation when packet assembly or decompression is required. Because the machine code is highly optimized, its execution efficiency is far higher than interpreted execution or dynamic configuration parsing.

[0038] This method utilizes a dual-mode dynamic switching architecture. During debugging, it employs a configuration file-based dynamic parsing scheme, meeting the needs for flexible adjustments and convenient debugging. After debugging, JIT compilation technology is used to pre-compile the protocol conversion configuration file into machine code. This "compile once, use multiple times" approach reduces configuration parsing and dynamic calculations during each packet assembly / disassembly, minimizing latency, increasing throughput, and improving simulation efficiency. This method achieves a balance between the flexibility required during debugging and the performance requirements during runtime.

[0039] In one embodiment, such as Figure 3 As shown, the machine code corresponding to the protocol conversion configuration file is generated using JIT technology, including: Step 302: Freeze the current structured protocol conversion configuration file.

[0040] Once the protocol conversion configuration file has been verified as correct, freeze and save it.

[0041] Step 304: Match the template file corresponding to the protocol conversion configuration file according to the protocol type.

[0042] The system maintains a template library that stores template files corresponding to different protocol types. Template files are predefined code files (usually in high-level languages ​​such as C / C++, Python, or a specific DSL) containing the skeleton of packet assembly / disassembly logic for a particular protocol. Based on the protocol type specified in the configuration file, the system searches the template library for the corresponding template file. Step 306: If a corresponding template file is matched, the attribute values ​​of the protocol conversion parameters are filled into the template file, and packet assembly code and / or unpacking code are generated according to the template file.

[0043] Specifically, templates typically include "placeholders" or "markers" to indicate the corresponding locations in the template file where the attribute values ​​for protocol conversion parameters should be entered. The content to be filled includes, but is not limited to: field name, field value (constant or variable reference), data type, length, offset, loop count, conditional judgment criteria, and validation algorithm parameters.

[0044] After the attribute values ​​of the protocol conversion parameters are populated into the template file, packet assembly and / or unpacking code is generated based on the template file. The generated code is high-level language source code (such as C / C++) specific to the specific protocol instance described in this configuration.

[0045] Step 308: Call the JIT compiler to compile the assembly code and / or unpacking code into machine code for the simulation platform.

[0046] Unlike traditional AOT (Ahead-of-Time) compilation, the JIT compiler dynamically compiles high-level language code into native machine code that can be directly executed by the simulation platform at runtime.

[0047] This avoids the overhead of interpreting and executing high-level language code, greatly improving the performance of protocol conversion.

[0048] In one embodiment, if no matching template file is found, the field definitions in the protocol conversion configuration file are recursively parsed to obtain a field definition tree structure; corresponding nodes are instantiated according to the attribute values ​​of the protocol conversion parameters, reference relationships are established, and an AST is generated; the AST is traversed to generate corresponding code snippets for each node, and packing and / or unpacking code is generated based on the code snippets of each node. The JIT compiler is called to compile the packing and / or unpacking code into machine code for the simulation platform.

[0049] Specifically, if no matching template file is found, the system parses the configuration file layer by layer, recursively processing each field definition starting from the root node to obtain a field definition tree structure. The field tree obtained in the previous step is then converted into an Abstract Syntax Tree (AST) with semantic relationships. The AST nodes are converted into code segments in the target language, and then the code segments are combined into compilable complete functions. Finally, the generated source code is compiled into executable machine code.

[0050] In this embodiment, if no template file corresponding to the protocol type is found in the template library, an Abstract Syntax Tree (AST) is dynamically constructed based on the protocol conversion configuration file. Platform-independent intermediate representation code is generated by depth-first traversing the AST nodes, and then compiled into native machine code for the target platform in real time using a JIT compiler. Thus, when a new protocol type appears, the system can automatically adapt to the unknown protocol structure without requiring manual template development or modification of the core engine, achieving end-to-end autonomous protocol processing capabilities while maintaining the same level of execution performance as predefined protocols.

[0051] In one embodiment, the condition is determined to be met when an operation to switch to simulation mode triggered by the interface is detected. Specifically, after the protocol conversion configuration file is verified, the user can trigger the generation of machine code corresponding to the protocol conversion configuration file using JIT technology through the "compile" control on the interface.

[0052] In one embodiment, a condition is determined to be met when no update is detected in the protocol configuration file within a preset time period. Specifically, after the protocol conversion configuration file is verified, a condition is determined to be met when no update is detected in the protocol configuration file within a preset time period, thereby triggering the generation of machine code corresponding to the protocol conversion configuration file using JIT technology.

[0053] In one embodiment, if no update is detected in the protocol configuration file within a preset time period, it is checked whether the system is in a preset prohibited compilation state; after the prohibited compilation state is lifted, it is determined that the condition is met.

[0054] The prohibition of compilation is established based on a comprehensive consideration of system security, real-time performance assurance, and resource management.

[0055] Specifically, after the protocol conversion configuration file is verified, if no update to the protocol configuration file is detected within a preset time period, it is also checked whether it is in a preset prohibited compilation state to reduce memory safety risks and uncertainties introduced by compilation.

[0056] The default compilation prohibition states include the following situations: resource overload and system in a critical operation period (such as hot patch deployment in a production environment).

[0057] In other words, after the protocol conversion configuration file is verified, if no update is detected in the protocol configuration file within a preset time period, and if it is in a preset prohibited compilation state, compilation will not be performed temporarily. After the prohibited compilation state is lifted (for example, when resources are idle or not in a critical operation period), it is determined that the conditions are met, so as to trigger the use of JIT technology to generate the machine code corresponding to the protocol conversion configuration file.

[0058] After the protocol conversion configuration file is verified, if no update to the protocol configuration file is detected within a preset time period, and if it is not in a preset prohibited compilation state, then the condition is determined to be met, and the machine code corresponding to the protocol conversion configuration file is generated using JIT technology.

[0059] This approach can reduce the memory safety risks and uncertainties introduced by compilation.

[0060] The debugging method for the hardware-in-the-loop simulation system in this application has two modes: debugging mode and simulation mode. A flowchart of the debugging phase is shown below. Figure 4As shown, after the communication process is started, a structured protocol conversion configuration file is obtained and parsed. In non-JIT interpretation mode, i.e., debug mode, the attribute values ​​of the protocol conversion parameters are parsed, and packets are assembled based on these attribute values. Specifically, packets are assembled based on the attribute values ​​of the protocol conversion parameters and the input simulation control parameters to obtain simulation data packets. These simulation data packets are then sent to the simulation platform, which unpacks them based on the attribute values ​​of the protocol conversion parameters and inputs the unpacked physical quantities into the simulation model for execution, thereby verifying the protocol conversion configuration file.

[0061] If the verification passes, you can enter JIT compilation mode, such as... Figure 5 As shown, the current structured protocol conversion configuration file is frozen. The protocol conversion configuration file obtains the attribute values ​​of the protocol conversion parameters. If a corresponding template file is matched, the attribute values ​​of the protocol conversion parameters are filled into the template file, and packet assembly code and / or unpacking code are generated according to the template file. The JIT compiler is called to compile the packet assembly code and / or unpacking code into machine code for the simulation platform.

[0062] The debugging method of the hardware-in-the-loop simulation system proposed in this application employs a non-JIT mode during the debugging phase. This eliminates the need for recompilation when modifying the data packet format, and supports real-time configuration updates, enabling dynamic adjustment of the data packet format during debugging. After successful verification, when certain conditions are met, JIT technology is used to generate and save the machine code corresponding to the protocol conversion configuration file. This allows for direct invocation of pre-generated machine code functions during real-time simulation when packet assembly or decompression is required. This improves the efficiency of packet assembly / decompression during simulation. The JIT mode generates static executable code, eliminating the overhead of runtime configuration file parsing.

[0063] Specifically, after compiling the machine code corresponding to the packet assembly function, the simulation control parameters are obtained during the packet assembly operation in the simulation phase. The machine code corresponding to the packet assembly function is then called to convert the simulation control parameters into binary protocol data packets required by the simulation platform. For example, if simulation control parameters (such as throttle opening, braking pressure, and other structured data) are input, the pre-compiled packet assembly machine code function is directly called to output binary protocol packets. This eliminates the overhead of field-by-field parsing and type conversion during interpreted execution.

[0064] Furthermore, after compiling the machine code corresponding to the unpacking function, during the unpacking operation in the simulation phase, the binary raw data packet to be sent by the simulation platform is obtained; the machine code corresponding to the unpacking function is called to convert the binary raw data packet into the corresponding physical quantity. For example, the raw binary data packet received from the simulation platform is passed in, the pre-compiled unpacking machine code function is called, and the structured physical quantity (such as vehicle speed, temperature) is output.

[0065] The debugging method of the hardware-in-the-loop simulation system proposed in this application transplants JIT compilation technology from the general computing field (such as JavaScript engine) to the real-time communication field. It has both JIT compilation mode and non-JIT interpretation mode. The non-JIT mode retains the flexibility of dynamic schemes, while the JIT mode inherits the performance advantages of static code, thus achieving the best of both worlds.

[0066] The debugging method for the hardware-in-the-loop simulation system in this application has the following advantages: 1. Performance Improvement (1) Optimized packet assembly / unpacking execution efficiency, improving by 3-5 times compared to dynamic parsing scheme.

[0067] JIT mode generates statically executable code, eliminating runtime configuration file parsing overhead; the compiler can apply deep optimizations (such as loop unrolling and instruction-level parallelism). Actual test data shows that ARINC 429 package assembly latency decreased from 15μs (dynamic parsing) to 3μs (JIT mode).

[0068] (2) Reduced system resource consumption CPU utilization decreased by 40-60%; the additional computational load of real-time JSON / XML parsing was avoided; static code reduced memory access redundancy (actual cache hit rate increased by 70%).

[0069] 2. Improved debugging efficiency (1) Dynamic adjustment at zero cost; no recompilation required when modifying data packet format. In non-JIT mode, it supports real-time configuration updates (such as adjusting the 1553B sub-address mapping); it saves 90% of debugging time compared to traditional static code solutions (single modification time is reduced from 3 minutes to seconds).

[0070] (2) Visualization of fault location It retains the debuggability advantages of static code; JIT-generated code supports standard debugging tools (such as GDB breakpoints and Valgrind memory checks); compared to dynamic parsing solutions, problem localization time is reduced by 80%.

[0071] It should be understood that although the steps in the flowcharts of the embodiments described above are shown sequentially according to the arrows, these steps are not necessarily executed in the order indicated by the arrows. Unless explicitly stated herein, there is no strict order restriction on the execution of these steps, and they can be executed in other orders. Moreover, at least some steps in the flowcharts of the embodiments described above may include multiple steps or multiple stages. These steps or stages are not necessarily completed at the same time, but can be executed at different times. The execution order of these steps or stages is not necessarily sequential, but can be performed alternately or in turn with other steps or at least some of the steps or stages in other steps.

[0072] Based on the same inventive concept, this application also provides a debugging device for a hardware-in-the-loop simulation system for implementing the debugging method of the hardware-in-the-loop simulation system described above. The solution provided by this device is similar to the solution described in the above method. Therefore, the specific limitations of the one or more hardware-in-the-loop simulation system debugging device embodiments provided below can be found in the limitations of the hardware-in-the-loop simulation system debugging method described above, and will not be repeated here.

[0073] In one embodiment, such as Figure 6 As shown, a debugging device for a hardware-in-the-loop simulation system is provided, the device comprising: Configuration module 602 is used to obtain a structured protocol conversion configuration file in response to debugging commands.

[0074] The parsing module 604 is used to parse the protocol conversion configuration file and obtain the attribute values ​​of the protocol conversion parameters.

[0075] The verification module 606 is used to assemble a simulation data packet according to the attribute values ​​of the protocol conversion parameters and the input simulation control parameters, and send the simulation data packet to the simulation platform. The simulation platform unpacks the data packet according to the attribute values ​​of the protocol conversion parameters and inputs the unpacked physical quantities into the simulation model for execution, so as to verify the protocol conversion configuration file.

[0076] The compilation module 608 is used to generate and save the machine code corresponding to the protocol conversion configuration file using JIT technology when the conditions are met.

[0077] Each module in the debugging device of the aforementioned hardware-in-the-loop simulation system can be implemented entirely or partially through software, hardware, or a combination thereof. These modules can be embedded in the processor of a computer device in hardware form or independent of it, or stored in the memory of the computer device in software form, so that the processor can call and execute the operations corresponding to each module.

[0078] In one embodiment, a computer device is provided, which may be a terminal, and its internal structure diagram may be as follows: Figure 7 As shown, the computer device includes a processor, memory, and a network interface connected via a system bus. The processor provides computing and control capabilities. The memory includes non-volatile storage media and internal memory. The non-volatile storage media stores the operating system, computer programs, and a database. The internal memory provides an environment for the operation of the operating system and computer programs stored in the non-volatile storage media. The network interface is used to communicate with external terminals via a network connection. The computer program is executed by the processor to implement a debugging method for a hardware-in-the-loop simulation system.

[0079] Those skilled in the art will understand that Figure 7 The structure shown is merely a block diagram of a portion of the structure related to the present application and does not constitute a limitation on the computer device to which the present application is applied. Specific computer devices may include more or fewer components than those shown in the figure, or combine certain components, or have different component arrangements.

[0080] In one embodiment, a computer-readable storage medium is provided, on which a computer program is stored, which, when executed by a processor, implements the steps of the debugging method for the above-described hardware-in-the-loop simulation system.

[0081] In one embodiment, a computer program product is provided, including a computer program that, when executed by a processor, implements the steps of the debugging method for the above-described hardware-in-the-loop simulation system.

[0082] Those skilled in the art will understand that all or part of the processes in the above embodiments can be implemented by a computer program instructing related hardware. The computer program can be stored in a non-volatile computer-readable storage medium, and when executed, it can include the processes of the embodiments described above. Any references to memory, databases, or other media used in the embodiments provided in this application can include at least one of non-volatile and volatile memory. Non-volatile memory can include read-only memory (ROM), magnetic tape, floppy disk, flash memory, optical memory, high-density embedded non-volatile memory, resistive random access memory (ReRAM), magnetic random access memory (MRAM), ferroelectric random access memory (FRAM), phase change memory (PCM), graphene memory, etc. Volatile memory can include random access memory (RAM) or external cache memory, etc. By way of illustration and not limitation, RAM can take many forms, such as Static Random Access Memory (SRAM) or Dynamic Random Access Memory (DRAM). The databases involved in the embodiments provided in this application may include at least one type of relational database and non-relational database. Non-relational databases may include, but are not limited to, blockchain-based distributed databases. The processors involved in the embodiments provided in this application may be general-purpose processors, central processing units, graphics processing units, digital signal processors, programmable logic devices, quantum computing-based data processing logic devices, etc., and are not limited to these.

[0083] The technical features of the above embodiments can be combined in any way. For the sake of brevity, not all possible combinations of the technical features in the above embodiments are described. However, as long as there is no contradiction in the combination of these technical features, they should be considered to be within the scope of this specification.

[0084] The embodiments described above are merely illustrative of several implementation methods of this application, and while the descriptions are specific and detailed, they should not be construed as limiting the scope of this application. It should be noted that those skilled in the art can make various modifications and improvements without departing from the concept of this application, and these all fall within the protection scope of this application. Therefore, the protection scope of this application should be determined by the appended claims.

Claims

1. A debugging method for a hardware-in-the-loop simulation system, characterized in that, The method includes: In response to debugging commands, obtain the structured protocol conversion configuration file; Parse the protocol conversion configuration file to obtain the attribute values ​​of the protocol conversion parameters; Based on the attribute values ​​of the protocol conversion parameters and the input simulation control parameters, a simulation data packet is generated and sent to the simulation platform. The simulation platform unpacks the data packet according to the attribute values ​​of the protocol conversion parameters and inputs the unpacked physical quantities into the simulation model for execution, thereby verifying the protocol conversion configuration file. When the conditions are met, the machine code corresponding to the protocol conversion configuration file is generated using JIT technology and saved.

2. The debugging method for the hardware-in-the-loop simulation system according to claim 1, characterized in that, The step of generating the machine code corresponding to the protocol conversion configuration file using JIT technology includes: Freeze the current structured protocol conversion configuration file; Match the template file corresponding to the protocol conversion configuration file according to the protocol type; If a matching template file is found, the attribute values ​​of the protocol conversion parameters are filled into the template file, and packet assembly code and / or unpacking code are generated based on the template file. The JIT compiler is invoked to compile the assembly and / or unassembly code into machine code for the simulation platform.

3. The debugging method for the hardware-in-the-loop simulation system according to claim 2, characterized in that, The method further includes: If no matching template file is found, the field definitions in the protocol replacement configuration file are recursively parsed to obtain a tree structure of field definitions. Instantiate the corresponding node based on the attribute values ​​of the protocol conversion parameters, establish reference relationships, and generate the AST; Traverse the AST and generate corresponding code snippets for each node; Generate assembly and / or unpacking code based on the code snippets of each node; The JIT compiler is invoked to compile the assembly and / or unassembly code into machine code for the simulation platform.

4. The debugging method for the hardware-in-the-loop simulation system according to claim 1, characterized in that, When a simulation compilation instruction triggered through the interface is detected, it is determined that the condition is met.

5. The debugging method for the hardware-in-the-loop simulation system according to claim 1, characterized in that, If no update to the protocol conversion configuration file is detected within a preset time period, the condition is determined to be met.

6. The debugging method for the hardware-in-the-loop simulation system according to claim 1, characterized in that, The response to switching to simulation mode includes: If no update is detected in the protocol configuration file within a preset time period, check whether it is in a preset prohibited compilation state; After the compilation ban is lifted, it is determined that the conditions are met.

7. The debugging method for the hardware-in-the-loop simulation system according to any one of claims 1 to 6, characterized in that, The method further includes: Obtain simulation control parameters; The machine code corresponding to the packet assembly function is called to convert the simulation control parameters into binary protocol data packets required by the simulation platform.

8. The debugging method for the hardware-in-the-loop simulation system according to any one of claims 1 to 6, characterized in that, The method further includes: Obtain the binary raw data packet to be sent by the simulation platform; The machine code corresponding to the unpacking function is invoked to convert the binary raw data packet into the corresponding physical quantity.

9. A debugging device for a hardware-in-the-loop simulation system, characterized in that, The device includes: The configuration module is used to obtain a structured protocol conversion configuration file in response to debugging commands; The parsing module is used to parse the protocol conversion configuration file and obtain the attribute values ​​of the protocol conversion parameters; The verification module is used to assemble the simulation data packet according to the attribute value of the protocol conversion parameter and the input simulation control parameter, and send the simulation data packet to the simulation platform. The simulation platform unpacks the data packet according to the attribute value of the protocol conversion parameter and inputs the unpacked physical quantity into the simulation model for execution, so as to verify the protocol conversion configuration file. The compilation module is used to generate and save the machine code corresponding to the protocol conversion configuration file using JIT technology when the conditions are met.

10. A computer device comprising a memory and a processor, wherein the memory stores a computer program, characterized in that, When the processor executes the computer program, it implements the steps of the method according to any one of claims 1 to 8.

Images