A virtual-real test integration management method and system

Abstract

This invention discloses a method and system for integrated management of virtual and real testing, an electronic device, and a storage medium, belonging to the field of intelligent equipment testing technology. This invention achieves unified configuration of multi-form access objects through an integrated configuration management module; drives Python / C++ algorithms to run via function calls through an algorithm-driven module, achieving low-latency iterative training; and supports the integrated verification of multi-protocol software modules through message interaction via an experimental data bus, supporting automatic conversion of internal and external data. This invention does not rely on a specific architecture, achieves dual-mode interaction and integrated management, and can significantly improve the efficiency of virtual and real testing integration, applicable to intelligent equipment development, algorithm iteration, and software verification testing scenarios.

Description

Technical Field

[0001] This invention relates to the field of intelligent equipment testing and system integration technology, specifically to a method, system, electronic device, and readable non-transitory storage medium for virtual and real test integration management. Background Technology

[0002] With the rapid development of intelligent equipment and autonomous decision-making systems, intelligent algorithms are playing an increasingly important role in the equipment development process. During the development and testing phase of intelligent equipment, it is typically necessary to integrate and verify various types of objects, mainly including the following categories: The first category consists of intelligent algorithm objects, existing in the form of Python code, C++ source code, or dynamic libraries. These require fast loading, real-time invocation, and iterative training to continuously optimize algorithm performance during experimentation. The second category comprises functional software module objects, existing as independent software modules, components, or services. These need to interface via standardized communication protocols, exchanging data and performing functional verification tests through message exchange. The third category consists of external real-world devices or system objects, which, in hybrid virtual-real experimental scenarios, need to interact with the internal simulation environment and operate collaboratively.

[0003] Existing virtual-real test integration solutions have the following technical shortcomings: First, the LVC (Live Virtual Construction) based integration solution mainly focuses on the unified management of distributed training resources, cloud platform architecture design, resource encapsulation and gateway access, etc. It emphasizes the construction and management of large-scale training environments, and does not specifically design for lightweight integration scenarios where algorithms and software coexist in a single test environment. This results in a high threshold for use and complex deployment in simple test scenarios.

[0004] Secondly, existing simulation platforms typically only support the embedding and calling of algorithms in a single programming language, lacking effective support for the mixed integration of algorithms in multiple languages ​​such as Python and C++, and thus failing to meet the needs of complex experimental scenarios where multiple forms of intelligent algorithms coexist.

[0005] Furthermore, traditional interface integration and protocol conversion solutions mainly implement message forwarding and data mapping functions, providing basic communication adaptation capabilities, but do not provide direct function call interfaces for algorithms or iterative training support functions. This results in algorithm calls needing to go through a complex message encapsulation and parsing process, increasing call latency, reducing execution efficiency, and hindering rapid iterative optimization of algorithms.

[0006] Furthermore, existing technical solutions lack a unified configuration management, dual-mode interaction, and integrated management mechanism, resulting in independent access processes for different types of objects, varying debugging methods, and fragmented and inconvenient integration management. This increases the complexity of experimental integration and reduces overall efficiency. Therefore, this application is submitted. Summary of the Invention

[0007] The integrated management method for virtual and real experiments provided by this invention includes the following technical features: The first step involves configuring the virtual and real-world test access objects through integrated configuration management, forming a unified access configuration. This configuration includes configuring the type, file path, and entry function for intelligent algorithm objects, and configuring the identifier, communication protocol, interface rules, and data conversion rules for software module objects. This unified configuration management mechanism achieves standardized management of access objects in different forms, avoiding the shortcomings of traditional solutions where various objects are configured independently and lack unified management.

[0008] The second step involves loading and driving the computation of intelligent algorithm objects via direct function calls from the algorithm-driven module, thereby obtaining the algorithm's output. This technical feature utilizes a direct function call interaction mode, eliminating intermediate steps such as message encapsulation and network forwarding. It directly passes input data to the algorithm's entry function and retrieves the return value, achieving low-latency algorithm calls and providing a technical foundation for rapid iterative training of intelligent algorithms.

[0009] The third step involves the experimental data bus interacting with software module objects via message communication, supporting multi-protocol communication and automatically converting data between external interfaces and the internal bus. As the core carrier for software module integration, the experimental data bus achieves data exchange with each software module through a standardized message interaction mechanism. Furthermore, its built-in protocol adaptation and data conversion functions resolve technical issues related to inconsistent communication protocols and data formats among different software modules.

[0010] The fourth step involves a unified scheduling and monitoring unit that enables unified start / stop, status monitoring, operation logging, anomaly location, and one-click retesting for various object types. This unified management mechanism centrally controls all access objects under both algorithm-driven and software module integration interaction modes, improving the overall efficiency and maintainability of the experimental integration.

[0011] Preferably, the form of the intelligent algorithm object includes Python code, C++ code, or a C++ dynamic library. By supporting algorithm objects in multiple programming languages ​​and code forms, the applicability of the method is expanded, enabling it to meet the development needs of intelligent equipment with different technology stacks.

[0012] Preferably, the direct function call method bypasses message encapsulation and network forwarding, directly loading and executing the algorithm code or dynamic library, and obtaining the function return value as the algorithm output. This technical feature further clarifies the implementation method of the algorithm-driven module, avoiding the latency overhead caused by network transmission and message parsing through direct function calls, and ensuring the real-time performance of algorithm calls.

[0013] Preferably, the algorithm-driven module supports iterative training of intelligent algorithms, including single-step debugging, loop calling, and parameter adjustment operation modes. The single-step debugging mode supports calling the algorithm sequentially and viewing the output results each time, which facilitates precise location of algorithm problems; the loop calling mode supports batch input of multiple sets of training data to achieve automated iterative optimization of the algorithm; the parameter adjustment mode supports directly modifying the input parameters without reloading the algorithm and observing the optimization effect in real time.

[0014] Preferably, the experimental data bus supports at least one of the following communication protocols: TCP, UDP, DDS, and MQTT. By supporting multiple mainstream communication protocols, it can adapt to the communication needs of different software modules, improving the compatibility of software module integration.

[0015] In a second aspect, the present invention provides an integrated management system for virtual and real testing, for implementing the above-described method.

[0016] The system includes the following core modules: The integrated configuration management module is used to configure the access object's form, type, file path, communication protocol, entry function, and data conversion rules, forming a unified access configuration. This module serves as the system's configuration hub, responsible for maintaining the configuration information of all access objects and providing configuration query and retrieval services to other modules.

[0017] The algorithm-driven module is used to load and execute intelligent algorithm code or dynamic libraries via direct function calls, obtain algorithm output results, and support iterative algorithm training. This module encapsulates core functions such as Python interpreter management, C++ dynamic library loading, and function call scheduling, providing independent driving services for intelligent algorithms.

[0018] The experimental data bus module is used to achieve software module integration and interaction in the form of messages. It supports multi-protocol communication and automatically completes bidirectional conversion between external interface data and internal bus data. This module has built-in adapters and data conversion engines for multiple communication protocols, and can support parallel interaction of multiple software modules simultaneously.

[0019] The unified scheduling and monitoring module is used to achieve unified start / stop, status monitoring, operation logs, anomaly location, and one-click retesting for various access objects. This module provides a unified user interface and monitoring and alarm functions, facilitating comprehensive management of the entire experimental integration process.

[0020] Preferably, the algorithm-driven module communicates with the intelligent algorithm via direct function calls, bypassing the message bus and not relying on the LVC architecture or cloud platform. This technical feature clearly defines the independent design principle of the algorithm-driven module, ensuring it does not depend on any external middleware or distributed architecture, thus guaranteeing the system's lightweight characteristics and independent operation capability.

[0021] Preferably, the experimental data bus module is independent of the training middleware and distributed resource encapsulation, and only performs protocol adaptation and data conversion. This technical feature clarifies the functional boundaries of the experimental data bus, allowing it to focus on solving the core problem of software module integration, without involving complex resource management or service coordination functions.

[0022] Preferably, the system supports lightweight deployment and can be deployed in standalone environments or embedded devices, making it suitable for various virtual-real hybrid testing scenarios such as laboratories, darkrooms, and outdoor fields. This technical feature ensures the system's environmental adaptability and can meet the deployment requirements of different testing scenarios.

[0023] A third aspect of the present invention provides an electronic device including a processor, a memory, and a program or instructions stored in the memory and executable on the processor, wherein the program or instructions, when executed by the processor, implement the steps of the virtual-real experiment integrated management method described in the first aspect.

[0024] A fourth aspect of the present invention provides a readable non-transitory storage medium storing a program or instructions that, when executed by a processor, implement the steps of the virtual-real experiment integrated management method described in the first aspect.

[0025] In summary, this application has the following beneficial effects: First, it achieves unified access management for multi-form objects. By integrating the configuration management module, it enables unified configuration and management of access objects of different forms, such as intelligent algorithms and software modules, without the need to develop independent adaptation interfaces for each type of object, significantly reducing access complexity and shortening the access cycle.

[0026] Second, it provides a dual-mode high-efficiency interaction mechanism. The algorithm-driven mode adopts a direct function call method, eliminating the overhead of message encapsulation and network forwarding, and achieving millisecond-level low-latency calls to support the rapid iterative training of intelligent algorithms; the software integration mode adopts message bus interaction, supports multi-protocol adaptation and automatic data conversion, and facilitates the integration and verification of software modules.

[0027] Third, it enables automatic conversion between internal and external data. The experimental data bus has a built-in data conversion engine that can automatically complete the format mapping and type conversion between external interface information and simulation internal bus data, reducing the workload of protocol development and lowering the probability of data conversion errors.

[0028] Fourth, it has good compatibility and scalability. It supports multiple algorithm formats such as Python and C++, and multiple communication protocols such as TCP, UDP, DDS, and MQTT, making it adaptable to various types of intelligent equipment development scenarios.

[0029] Fifth, the system is lightweight and easy to deploy. It does not rely on LVC architecture, cloud platforms, or distributed resource encapsulation, and can be deployed in standalone or embedded environments. It is suitable for various virtual-real hybrid testing scenarios such as laboratories, darkrooms, and outdoor fields, thus lowering the barrier to entry. Attached Figure Description

[0030] Figure 1 This is a schematic diagram of the overall system architecture of the virtual-real test integrated management system provided in the embodiment of the present invention.

[0031] Figure 2 This is a flowchart illustrating the integrated management method for virtual and real experiments provided in an embodiment of the present invention. Figure 3 This is a structural schematic diagram of the dual-mode interaction method provided in an embodiment of the present invention. Detailed Implementation

[0032] Exemplary embodiments will now be described in detail, examples of which are illustrated in the accompanying drawings. When the following description relates to the drawings, unless otherwise indicated, the same numbers in different drawings denote the same or similar elements. The embodiments described in the following exemplary embodiments do not represent all embodiments consistent with this application. Rather, they are merely examples of apparatuses and methods consistent with some aspects of this application as detailed in the appended claims.

[0033] The terminology used in this application is for the purpose of describing particular embodiments only and is not intended to be limiting of the application. The singular forms “a,” “the,” and “the” used in this application and the appended claims are also intended to include the plural forms unless the context clearly indicates otherwise. It should also be understood that the term “and / or” as used herein refers to and includes any or all possible combinations of one or more of the associated listed items.

[0034] To better understand the above technical solution, the following will provide a detailed explanation of the technical solution in conjunction with specific implementation methods.

[0035] In some embodiments of this application, an overall architecture for a method and system for integrated management of virtual and real experiments is provided. For example... Figure 1 As shown, the system consists of three core functional modules: an integrated configuration management module, an algorithm-driven module, and an experimental data bus module. The integrated configuration management module, located at the upper layer of the system architecture, is responsible for the unified configuration management of access objects. The algorithm-driven module, located at the lower layer of the system architecture, serves as the core driving engine for intelligent algorithms. The experimental data bus module, located at the upper layer of the system architecture, acts as the communication hub for software module integration. The integrated configuration management module interacts with both the algorithm-driven module and the experimental data bus module through configuration information flows, providing configuration parameters to these two lower-level modules.

[0036] In practice, the integrated configuration management module receives user-inputted access object configuration information, including object type, file path, protocol parameters, function interfaces, and data conversion rules, and persistently stores this configuration information. The algorithm-driven module and the experimental data bus module retrieve their respective configuration parameters from the integrated configuration management module upon startup and execute specific loading or communication operations according to these parameters.

[0037] By adopting the above technical solution and using a modular architecture design, the three core functions of configuration management, algorithm-driven and software integration are decoupled. Each module focuses on its own functional implementation, and the modules collaborate through standardized configuration interfaces, thereby improving the maintainability and scalability of the system.

[0038] Some implementation schemes of this application provide specific implementation methods for the integrated configuration management module. The core functions of the integrated configuration management module include access object configuration and morphological parameter management.

[0039] In the specific implementation process, for intelligent algorithm-type access objects, the integrated configuration management module needs to configure the following parameters: object type identifier, used to distinguish different access object types; file path, used to specify the storage location of algorithm code files or dynamic library files; entry function name, used to specify the name of the entry function for calling the algorithm module; call frequency, used to specify the execution frequency or triggering conditions of algorithm calls; input parameter type, used to define the input data format accepted by the algorithm, such as simulation situation data, image pixel data, etc.; output result format, used to define the standardized format of the algorithm's returned results.

[0040] For software module access objects, the integration configuration management module needs to configure the following parameters: object type identifier, used to distinguish software module types; communication protocol type, used to specify the communication protocol used by the module, such as TCP, UDP, DDS, MQTT, etc.; IP address and port number, used to specify the network communication address of the module; message format, used to define the structure and field definitions of interactive messages; data conversion rules, used to define the field mapping relationship and format conversion logic between external message data and internal bus data.

[0041] By adopting the above technical solution and through standardized configuration item definitions, a unified description and management of access objects of different forms is achieved. The configuration information is complete, accurate, and traceable, which facilitates subsequent module loading and interactive execution.

[0042] In some preferred embodiments of this application, the integrated configuration management module supports visual editing and batch import of configuration information. Users can view and edit the configuration parameters of various access objects through a graphical interface, and can also import predefined configuration information in batches through configuration files, thereby improving configuration efficiency.

[0043] In some implementation schemes of this application, specific implementation methods of the algorithm-driven module are provided. The algorithm-driven module is the core engine for intelligent algorithm integration, responsible for loading and executing Python code or C++ dynamic libraries through direct function calls.

[0044] In practice, the workflow of the algorithm-driven module includes three stages: initialization loading, function call execution, and result acquisition.

[0045] During the initialization and loading phase, the algorithm-driven module first reads the algorithm configuration parameters from the integrated configuration management module to obtain information such as the algorithm type, file path, and entry function name. For Python algorithms, the module initializes the Python interpreter environment, loads the specified Python source code file or dynamic link library, and establishes the function call chain. For C++ algorithms, the module dynamically loads the specified dynamic link library file, resolves the address of the entry function through dynamic linking technology, and establishes the function call interface. After the initialization and loading process is complete, the algorithm-driven module is in a ready state and can receive call requests at any time.

[0046] During the function call execution phase, when a call request arrives, the algorithm-driven module passes the input data to the algorithm's entry function, triggering algorithm execution. Input data is passed as function parameters; the module first converts the input data to the format defined in the configuration, and then passes it as a function parameter to the entry function. After the function execution is complete, the module obtains the algorithm's output result through the function's return value.

[0047] Combination Figure 3 The illustrated dual-mode interaction diagram provides a detailed explanation of the dual-mode interaction mechanism of this application. For example... Figure 3 As shown on the left, the algorithm-driven mode uses direct function calls to access intelligent algorithm objects in the form of Python code, C++ code, or C++ dynamic libraries. The algorithm-driven module directly loads the algorithm code file or dynamic link library, resolves the entry function address, passes the input data as function parameters to the algorithm, and returns the output result directly through the function return value after the algorithm completes execution. The algorithm-driven mode eliminates the need for intermediate steps such as message buses, message encapsulation, or network forwarding, avoiding the serialization and deserialization overhead during data transmission and the latency overhead of network communication. It achieves low-latency calls at the millisecond or even microsecond level, featuring low latency and suitability for iterative algorithm training.

[0048] like Figure 3 As shown on the right, the software integration mode uses a message bus interaction method for accessing external software modules or device objects. The test data bus, as the core carrier of software integration, has a built-in multi-protocol adaptation engine and data conversion engine, supporting multiple communication protocols such as TCP, UDP, DDS, and MQTT. External software modules send messages according to their supported protocols. After receiving the messages, the test data bus converts the external message format into the simulation internal bus data format according to pre-configured data conversion rules. Similarly, it converts the internal bus data into the external message format according to the conversion rules and then sends it to the software module. The software integration mode features good multi-protocol compatibility and is suitable for software module verification.

[0049] The two modes operate in parallel and work collaboratively within the same system. In a complete virtual-real integrated testing scenario, the algorithm-driven mode is responsible for driving the efficient invocation of intelligent algorithms, while the software integration mode is responsible for realizing the flexible integration of software modules with external devices. The two work together to achieve integrated management of multi-form access objects.

[0050] By adopting the above technical solution and implementing algorithm-driven processing through direct function calls, the real-time performance and efficiency of algorithm calls are guaranteed, providing a solid technical foundation for the rapid iterative training of intelligent algorithms. Experimental data shows that compared with traditional message interaction methods, direct function calls reduce latency by more than 90%, effectively supporting real-time algorithm calls and high-frequency iterations.

[0051] In some preferred embodiments of this application, the algorithm-driven module supports multiple calling modes to support the iterative training of intelligent algorithms.

[0052] In practical implementation, the invocation modes include the following three: The first mode is single-step debugging, suitable for precise algorithm localization and troubleshooting. In this mode, each time the user triggers an algorithm call, the algorithm-driven module executes the algorithm function call once and immediately returns the execution result, including algorithm output data, execution time, and status information. Users can observe the algorithm's behavior under different input conditions through multiple single-step calls to locate algorithm anomalies or performance bottlenecks. Typical application scenarios for single-step debugging mode include functional verification when introducing new algorithms, cause analysis when algorithms malfunction, and sensitivity analysis of algorithm parameters.

[0053] The second mode is the loop-call mode, suitable for automated processing and training of batch data. In this mode, the user prepares multiple sets of training data samples in advance. The algorithm-driven module calls the algorithm on each set of data sequentially according to the configured call frequency or trigger conditions, and automatically collects the algorithm output results. The loop-call mode supports two execution methods: sequential execution and parallel execution. The sequential execution method calls the algorithm in the order of the data samples, which is suitable for scenarios that require strict order preservation; the parallel execution method starts multiple algorithm call instances simultaneously, making full use of the parallel computing capabilities of multi-core processors, which is suitable for computationally intensive batch processing scenarios.

[0054] The third mode is parameter tuning, suitable for rapid optimization of algorithm performance. In this mode, users do not need to reload the algorithm code; they only need to adjust the input parameters during the call to observe the impact of different parameters on the algorithm's output in real time. Parameter tuning supports two methods: single-parameter scan and multi-parameter combination scan. The single-parameter scan method fixes other parameters and only changes the value range of one parameter, observing the impact curve of that parameter on the algorithm's performance. The multi-parameter combination scan method changes the values ​​of multiple parameters simultaneously, executes the algorithm call according to a preset parameter combination matrix, and generates a parameter-performance comparison table or surface plot.

[0055] By adopting the above technical solution and providing multiple calling modes, the needs of intelligent algorithms at different stages of research and development are met, covering the complete iterative process from functional verification to performance optimization, and significantly improving the efficiency of algorithm research and development.

[0056] In some preferred embodiments of this application, the algorithm-driven module has built-in operation monitoring and exception handling functions.

[0057] During implementation, the monitoring function records the execution information of each algorithm call in real time, including the call timestamp, input data summary, output data summary, execution time, and call status. This information is persistently stored in the form of structured logs, facilitating subsequent traceability analysis and performance evaluation. When an algorithm execution anomaly is detected, such as algorithm crash, timeout without response, or output data exceeding the preset range, the module automatically triggers an alarm mechanism, alerting the user through interface pop-ups, sound reminders, or message notifications. Simultaneously, it records the complete context information of the anomaly, providing data support for problem localization.

[0058] By adopting the above technical solution and through a sound operation monitoring and anomaly handling mechanism, the reliability and observability of the algorithm-driven process are guaranteed, making it easy to detect and handle problems in the algorithm execution process in a timely manner.

[0059] In some embodiments of this application, specific implementations of the test data bus module are provided. The test data bus is the core carrier for software module integration, responsible for data interaction with each software module in the form of messages.

[0060] In the specific implementation process, the workflow of the experimental data bus module includes three stages: bus initialization, message transmission and reception, and data conversion.

[0061] During the bus initialization phase, the test data bus obtains the communication parameters and data conversion rules of each software module from the integrated configuration management module. Based on the communication protocol type, the module initializes the corresponding protocol adapter, such as a TCP, UDP, DDS, or MQTT protocol adapter. The protocol adapter is responsible for establishing and managing the underlying network communication connection, configuring the network address and port of the software module to the underlying socket or protocol stack. After initialization, the test data bus establishes a communication channel with each software module, awaiting message exchange.

[0062] During the message transmission and reception phase, when the simulation internal bus has data to send to the software module, the data first arrives at the input interface of the experimental data bus. The experimental data bus queries the configuration information based on the target module's identifier to determine the corresponding protocol adapter and data conversion rules. The data conversion engine converts the internal bus data format into an external message format supported by the target software module according to predefined conversion rules. After conversion, the protocol adapter sends the converted message to the target software module via the underlying network connection.

[0063] When a software module returns data, the protocol adapter receives the message from the software module, parses the message content, and hands it over to the data conversion engine. The data conversion engine then converts the external message format into the simulation's internal bus data format according to the reverse conversion rules, and outputs it to the output interface of the experimental data bus for use by other modules within the simulation.

[0064] like Figure 3 As shown, the software integration mode adopts a message bus interaction method, where external software modules exchange data with the internal simulation bus through the experimental data bus. The experimental data bus has a built-in multi-protocol adaptation and data conversion engine, which can support the parallel interaction of multiple software modules simultaneously. Each channel is independently configured with protocol type and conversion rules, without interference between them.

[0065] By adopting the above technical solution, standardized message exchange and automated data conversion enable unified integration of software modules with different communication protocols and data formats. There is no need to develop dedicated adapter interfaces for each software module; simply defining the protocol type and conversion rules during the configuration phase allows for plug-and-play functionality.

[0066] In some preferred embodiments of this application, the experimental data bus supports multi-protocol parallel interaction.

[0067] In practice, the test data bus maintains multiple independent protocol channels, each configured with a different communication protocol. A single test scenario may contain multiple software modules, such as a target tracking module using TCP, a data storage module using UDP, and a situation display module using DDS. The test data bus can simultaneously establish connections with and exchange data with these modules. The different protocol channels are independent of each other; an anomaly in one channel will not affect the normal operation of other channels.

[0068] The multi-protocol parallel interaction function solves the common heterogeneous system integration problem in virtual-real combined experiments. In actual experimental scenarios, various software modules are often developed by different teams and built using different communication protocols. Traditional point-to-point docking methods require the development of dedicated protocol conversion programs for each pair of communicating parties, causing system complexity to increase exponentially with the number of modules. By adopting the multi-protocol parallel interaction mechanism of this application, only the protocol parameters of each module need to be configured on the experimental data bus to achieve transparent conversion and unified management of multiple protocols, which greatly reduces the complexity of heterogeneous system integration.

[0069] By adopting the above technical solution, the multi-protocol parallel interaction capability of the test data bus effectively supports the software module integration requirements under complex test scenarios, and improves the system's flexibility and adaptability.

[0070] In some preferred embodiments of this application, the test data bus has built-in data quality monitoring and verification functions.

[0071] During implementation, the data quality monitoring function continuously monitors key metrics of message interaction, including message sending frequency, receiving frequency, packet loss rate, and conversion error rate. When abnormal metrics are detected, such as a message loss rate exceeding a threshold or incorrect data conversion format, the system automatically records the abnormal event and triggers an alarm. The data verification function performs integrity checks on input and output data during data conversion, ensuring that fields are complete, types are correct, and values ​​are within reasonable ranges. For data that fails verification, the system records an error log and marks the data as invalid to prevent abnormal data from spreading to the simulation system and affecting experimental results.

[0072] By adopting the above technical solution and through data quality monitoring and verification mechanisms, the reliability and integrity of the integrated data of the software modules are ensured, thus guaranteeing the accuracy of the test results.

[0073] In some implementation schemes of this application, specific implementation methods of the unified scheduling and monitoring module are provided. The unified scheduling and monitoring module is responsible for the unified management and control of the entire test integration process, including unified start and stop, status monitoring, operation logs, anomaly location, and one-click retesting.

[0074] In practice, the unified start / stop function provides centralized control over all access objects. Users can start all configured access objects with a single click through a graphical interface. The system activates the algorithm-driven module and the experimental data bus module sequentially according to a preset startup order, establishing communication connections with each object. Similarly, users can stop all access objects with a single click. The system safely shuts down each module in a preset shutdown order, releasing resources. The unified start / stop function simplifies user operations and avoids the tedious process of starting or stopping each object individually.

[0075] The status monitoring function displays the real-time operating status of each connected object, including connected, running, abnormal, and stopped states. The system uses a heartbeat mechanism to detect the connection status with each object. When an object is detected to be offline or abnormal, the interface updates the status display in real time and triggers an alarm. Users can quickly understand the operating status of the entire test environment through the status monitoring interface and promptly detect and handle abnormal situations.

[0076] The runtime log function comprehensively records all operations and events during the experiment, including configuration changes, module start-up and shutdown, function calls, message sending and receiving, and exception alarms. Log information includes timestamps, event types, detailed descriptions, and context data, and is persistently stored in a structured format. Users can query logs by time range, event type, keywords, and other criteria, and log export and offline analysis are supported.

[0077] When an anomaly is detected, the anomaly localization function automatically collects relevant information about the anomaly scene, including the anomaly type, occurrence time, involved objects, call stack, log fragments, etc., and generates an anomaly diagnostic report. The report includes an analysis of possible causes of the anomaly, suggested troubleshooting steps, and relevant log links to help users quickly locate the root cause of the problem.

[0078] The one-click retest function allows users to restart the testing process with a single click after troubleshooting and fixing the problem. The system automatically resets the status of each module according to the preset initialization process, loads the latest configuration, and executes the test verification. With the one-click retest function, users can quickly verify the repair effect without manually repeating the tedious startup steps, significantly shortening the problem troubleshooting and repair cycle.

[0079] By adopting the above technical solution and leveraging the one-stop management capabilities provided by the unified scheduling and monitoring module, users can complete the management and control operations of all access objects on a single interface without switching between multiple systems or interfaces, thereby improving the operational efficiency and user experience of the test integration.

[0080] In some embodiments of this application, combined with Figure 2 The flowchart shown illustrates the complete workflow for integrated management of virtual and real experiments.

[0081] In practice, the workflow includes the following five steps: Step S1 is the integration configuration phase. Users define all virtual and physical test objects to be connected through the integration configuration management module. Configuration details include object type, file path, communication protocol, function interface, and data conversion rules. After configuration, the system persistently stores the configuration information and generates a complete access configuration list.

[0082] Step S2 is the algorithm class access phase. Based on the algorithm type object in the configuration manifest, the algorithm-driven module performs a loading operation, initializes the Python interpreter or loads a C++ dynamic library, and establishes a function call chain. After loading is complete, the algorithm-driven module enters a ready state, waiting for call requests.

[0083] Step S3 is the software access phase. Based on the software module type objects in the configuration list, the test data bus module initializes each protocol adapter and establishes network connections with each software module. After the connections are established, the test data bus enters a ready state, preparing for message exchange.

[0084] Step S4 is the data conversion phase. During the test run, the test data bus continuously performs data conversion operations, converting the simulation internal bus data into the external message format corresponding to each software module, and simultaneously converting the software module return messages into the internal bus format.

[0085] Step S5 is the integrated scheduling and monitoring phase. The unified scheduling and monitoring module manages all access objects started in steps S2 and S3, enabling unified start / stop, status monitoring, operation logs, anomaly location, and one-click retesting.

[0086] like Figure 2 As shown, the processing results of steps S2 and S3 converge in step S5, where they are managed uniformly by the unified scheduling and monitoring module. Simultaneously, step S5 supports iterative optimization and closed-loop processing. If the experimental verification results do not meet expectations, the user can return to step S1 to adjust configuration parameters and re-execute the complete integration process until the expected experimental objective is achieved.

[0087] By adopting the above technical solution, and through step-by-step process design and modular functional division, the standardization and automation of virtual and real experiment integration are achieved. Users only need to follow the process to perform configuration, access, interaction, conversion and management operations in sequence to complete complex multi-form object integration tasks.

[0088] In some specific embodiments of this application, the implementation process is described in detail using an intelligent algorithm integration test scenario as an example.

[0089] Example 1: Intelligent Algorithm Integration Experiment (Function Call Mode) In the path planning algorithm verification test of a certain type of intelligent equipment, it is necessary to integrate the path decision algorithm implemented in Python and the target recognition algorithm implemented in C++ into the simulation test system to verify the decision accuracy and real-time performance of the algorithm.

[0090] During the S1 integration configuration phase, the Python path decision algorithm is first added as the first access object through the integration configuration management module. The object type is configured as algorithm type, and the storage path for the Python source code file is specified as the `decision_algorithm.py` file in the preset directory. The entry function is configured as `decision_main`. The input parameter type of the entry function `decision_main` is simulation situation data, including target location coordinates, obstacle distribution information, and path planning constraints; the output result type is a path point sequence, representing the optimal path from the current location to the target location. The algorithm is configured to be called every 100 milliseconds, without requiring configuration of communication protocols and network parameters.

[0091] Then, a C++ target recognition algorithm is added as the second access object. The object type is configured as algorithm type, the storage path of the C++ dynamic library file is specified as the target_recognition.dll file in the preset directory, and the entry function is configured to be named TargetRecognition. The input parameter type of the entry function TargetRecognition is image pixel data, including image resolution, pixel matrix and detection threshold; the output result type is target list, including the number of recognized targets, target category, bounding box coordinates and confidence score.

[0092] During the S2 algorithm-driven execution and iterative training phase, the algorithm-driven module first reads the configuration information of the two algorithms and performs initialization loading operations. For the Python path decision algorithm, the module initializes the Python interpreter environment, loads the decision_algorithm.py module, resolves the reference to the decision_main function, and establishes the call chain. For the C++ target recognition algorithm, the module calls the operating system's dynamic link loading interface to load target_recognition.dll into the process space, obtains the address of the TargetRecognition function through symbol resolution, and establishes the call interface. After initialization loading is complete, the loading latency is controlled within 500 milliseconds.

[0093] After initialization, the algorithm enters the ready-to-run state. When the simulation system generates new situational data, the algorithm-driven module encapsulates the situational data into the parameter format required by the `decision_main` function and passes it to the path decision algorithm via function call. After the algorithm executes, the return value contains a path point sequence, which the module parses and outputs to the simulation system for subsequent use. Similarly, when the simulation system acquires a new image frame, the algorithm-driven module passes the image data to the target recognition algorithm to obtain the recognition result.

[0094] The latency of a single function call is controlled within 1 millisecond, which is more than 90% lower than the latency of traditional message interaction methods.

[0095] During the iterative training phase, a single-step debugging mode was first used to verify the correctness of the algorithm's functionality. Input data was recorded before each call, and output results and execution time were recorded after each call. By observing the algorithm's behavior under different input conditions through multiple single-step calls, the correctness of the algorithm's logic was verified.

[0096] After single-step debugging, batch training is performed using a loop-based call mode. 100 sets of simulation training data samples are prepared, including situational and image data from different scenarios. The loop-based call mode is configured for parallel execution, starting multiple algorithm call instances to process multiple sets of data samples simultaneously. The system automatically records the algorithm output, decision accuracy, and execution time for each set of data.

[0097] After the loop is completed, the algorithm's performance metrics on the training data are analyzed, including decision accuracy, average execution time, and anomaly rate. For aspects where performance metrics do not meet expectations, optimization is performed using a parameter tuning mode. In parameter tuning mode, the algorithm code remains unchanged, and the impact curves of parameter changes on the output results are observed by adjusting input parameters such as the weight coefficients of path planning constraints and the target recognition confidence threshold. Based on the analysis results, the optimal parameter combination is determined, the configuration parameters are updated, and the loop is re-executed to verify the optimization effect.

[0098] During operation, the monitoring function records the number of algorithm calls, cumulative execution time, and output result distribution in real time. When an algorithm execution anomaly is detected, such as an empty output path point sequence or an abnormal number of target recognitions, an alarm is automatically triggered and the input data and call context of the anomaly are recorded.

[0099] During the S3 trial verification and result evaluation phase, after multiple rounds of iterative optimization, the path decision algorithm achieved an average decision accuracy of over 92% on 100 sets of test data, with an average execution time of 0.8 milliseconds; the target recognition algorithm achieved an average recognition accuracy of over 95% on test images, with an average execution time of 0.5 milliseconds.

[0100] Summary of implementation results: By adopting the function call mode of this application for algorithm integration, the algorithm access configuration time is shortened by 85% compared with the traditional solution, the iterative training efficiency is improved by 60%, the single call latency is reduced by more than 90%, and there is no need to develop a special algorithm adaptation interface, which can directly complete the integration and iterative verification of multi-language algorithms.

[0101] In some specific embodiments of this application, the implementation process is described in detail using a software module integration test scenario as an example.

[0102] Example 2: Software Module Integration Experiment (Message Bus Mode) In the integration testing of a certain type of integrated electronic system, it is necessary to integrate three independent software systems—target tracking software module, data storage software module, and situation display software module—into a unified test platform for collaborative verification. The three software modules communicate using TCP, UDP, and DDS protocols respectively, with different data formats, requiring unified protocol adaptation and automatic data conversion.

[0103] During the S1 software module integration and configuration phase, the target tracking software module is added as the first access object through the integration configuration management module. The object type is configured as a software module, the communication protocol is specified as TCP, and the target tracking module's IP address is configured as 192.168.1.100, with port number 8080. The message format is configured as a custom binary format, including a frame header, target quantity field, target data array, and checksum field. Simultaneously, data conversion rules are configured to convert the standardized target data format of the simulation internal bus to the message format of the target tracking module, as well as reverse conversion rules.

[0104] Add a data storage software module as the second access object. Configure the object type as a software module, specify the communication protocol as UDP, and configure the data storage module's IP address as 192.168.1.101 and port number as 9090. Configure the message format as JSON text format, including timestamp, event type, and data content fields. Configure the corresponding data conversion rules.

[0105] Add a situation display software module as the third access object, configure the object type as software module, specify the communication protocol as DDS protocol, and configure the DDS topic name and quality of service parameters for the situation display module. Configure the message format as Protocol Buffers binary format, including an array of situation elements and metadata fields. Configure the corresponding data conversion rules.

[0106] During the S2 experimental data bus interaction and verification test phase, the experimental data bus module reads the configuration information of the three software modules and initializes the corresponding protocol adapters. The TCP adapter creates a socket to connect to the specified address of the target tracking module and establishes a long TCP connection. The UDP adapter creates a socket and binds it to the address of the data storage module, preparing to send UDP datagrams. The DDS adapter initializes DDS domain participants, joins the specified topic, and completes the matching of publishers and subscribers.

[0107] After initialization, all three protocol channels were successfully connected, achieving a 100% connection success rate.

[0108] In the data transmission process, when the simulation internal bus needs to send situational data to the target tracking module, the data first arrives at the input interface of the test data bus. The bus queries the configuration information based on the target module identifier to determine the conversion rules between the TCP adapter and the target tracking module. The data conversion engine converts the target data in its internal format into a TCP packet binary format, organizes the data fields according to a custom frame structure, and adds a frame header, target quantity, and checksum. The TCP adapter then sends the packet to the target tracking module through the established connection.

[0109] Similarly, when event data needs to be sent to the data storage module, the conversion engine converts the data into JSON text format and sends it to the specified address via the UDP adapter. When situation updates need to be sent to the situation display module, the conversion engine converts the data into Protocol Buffers binary format and publishes it to the specified topic via the DDS adapter.

[0110] In the data reception process, when the target tracking module returns a tracking result message, the TCP adapter receives the message and parses its binary content. The data conversion engine, following the reverse conversion rules, converts the tracking result data in the message into the simulation's internal bus format and outputs it to the bus's output interface. When the data storage module returns a storage confirmation message, the UDP adapter receives and parses the JSON content, completing the reverse conversion. When the situation display module publishes display feedback, the DDS adapter receives and parses the Protocol Buffers content, completing the reverse conversion.

[0111] The conversion engine performs data validation during the data conversion process, checking the completeness of fields, the correctness of data types, and the range of values. For messages that fail validation, an error log is logged and the data is marked as invalid to prevent abnormal data from entering the simulation system. The measured data conversion accuracy reaches over 99.8%.

[0112] The multi-protocol parallel interaction function ensures that the three software modules can exchange data with the simulation system simultaneously and without interference. An abnormality or delay in any module will not affect the normal operation of other modules.

[0113] During the S3 integrated monitoring and retesting optimization phase, a unified monitoring interface for the scheduling monitoring module displays key indicators such as the connection status, message sending and receiving frequency, and data conversion accuracy of the three software modules in real time. When the message loss rate of the target tracking module exceeds 1%, the interface displays an alarm message and records the alarm event and related logs.

[0114] Regarding the packet loss issue, the anomaly localization process was initiated. The system automatically collected context information at the time of the alarm, including the content of the preceding and following packets, the time interval, and transition logs. Analysis indicated that the problem was caused by network congestion leading to a brief interruption of the TCP connection.

[0115] After troubleshooting, the one-click retest function was used for re-verification. The system automatically reset the TCP channel of the test data bus, re-established the connection, and started a new round of message interaction testing. The retest results showed that the TCP connection was stable, the message loss rate was reduced to below 0.1%, and the integration verification of all three software modules passed.

[0116] Summary of implementation results: By adopting the message bus mode of this application for software module integration, the software module access cycle is shortened by 75% compared with the traditional solution. There is no need to develop a dedicated protocol adaptation layer for each module. The multi-protocol software integration compatibility reaches more than 95%, and the data conversion accuracy reaches 99.8%, effectively supporting the rapid integration verification and testing of software modules.

[0117] In some specific embodiments of this application, a complete process of integrated management of virtual and real experiments is shown, which combines the algorithm-driven mode with the software integration mode to achieve integrated management of multi-form objects.

[0118] Comprehensive Implementation Example: Integrated Experiment of Multi-Form Objects In a hardware-in-the-loop simulation test of a certain type of intelligent unmanned system, it is necessary to integrate multiple types of access objects simultaneously, including a path decision algorithm implemented in Python, a target recognition algorithm implemented in C++, an external target tracking software module, a situation display software module, and real radar equipment. Joint verification tests are required for the algorithm decision-making, target tracking, and situation display functions.

[0119] During the S1 integration configuration phase, all access objects are uniformly configured through the integration configuration management module. For the Python path decision algorithm, the configuration type is set to "algorithm type," the file path is "decision_algorithm.py," and the entry function is "decision_main." For the C++ target recognition algorithm, the configuration type is set to "algorithm type," the file path is "target_recognition.dll," and the entry function is "TargetRecognition." For the target tracking software module, the configuration type is set to "software module type," the protocol is TCP, and the IP address, port number, and message format are configured. For the situation display software module, the configuration type is set to "software module type," the protocol is DDS, and the topic name and data format are configured. For real radar equipment, the configuration type is set to "software module type," the protocol is UDP, and the IP address, port number, and data conversion rules are configured. Simultaneously, the data dependencies between each access object are configured, such as using the output of the target recognition algorithm as the input of the path decision algorithm, and using radar data as the input of the target recognition algorithm.

[0120] In phases S2 to S5, the system coordinates the operation of each access object according to the configured dependencies. The algorithm-driven module loads and drives the Python path decision algorithm and the C++ target recognition algorithm, obtaining the algorithm output through function calls. The experimental data bus interacts with the target tracking module, situation display module, and radar equipment via messages, sending control commands and receiving return data. The unified scheduling and monitoring module monitors the status of all access objects in real time, coordinates the timing of algorithm calls and data interactions, and ensures smooth data flow between objects.

[0121] During the test operation, when the radar equipment detects a new target, it sends the target data to the test data bus via the UDP protocol. The bus converts the data into an internal format and outputs it in two paths: one path is passed as input parameters to the target recognition algorithm to obtain the target recognition result; the other path is directly passed to the path decision algorithm as situational awareness data. The target recognition result and the path decision result are then sent to the target tracking module and the situational awareness display module for display via message exchange, respectively.

[0122] Throughout the experiment, the unified scheduling and monitoring module monitored the running status, algorithm call frequency, message exchange rate, and other metrics of each access object in real time. When an anomaly was detected, the anomaly context was automatically recorded and an alarm was triggered. Users could view the complete running logs and performance metrics through the monitoring interface, and complete one-click retesting or rerun after adjusting the configuration.

[0123] Summary of implementation results: By adopting the integrated management method of this application, a complex virtual-real combined experiment integrating multiple intelligent algorithms and multiple software modules was successfully realized. The algorithm iteration efficiency was improved by more than 60%, the software module access cycle was shortened by more than 80%, and the integrated management significantly reduced the complexity and maintenance cost of the experiment integration.

[0124] The embodiments of this application have been described above with reference to the accompanying drawings. However, this application is not limited to the specific embodiments described above. The specific embodiments described above are merely illustrative and not restrictive. Those skilled in the art can make many other forms under the guidance of this application without departing from the spirit and scope of the claims, and all of these forms are within the protection scope of this application.

Claims

1. A method for integrated management of virtual and real experiments, characterized in that, include: Through integrated configuration management, the virtual and real test access objects are configured in a morphological manner to form a unified access configuration. The morphological configuration includes intelligent algorithm type, file path, entry function, as well as software module identifier, communication protocol, interface rules and data conversion rules. For intelligent algorithm objects, the algorithm-driven module loads and drives the operation by directly calling functions to obtain the algorithm output results. For software module objects, the test data bus interacts with them in the form of messages, supporting multi-protocol communication and completing the automatic conversion of external interface and internal bus data. The unified scheduling and monitoring unit enables unified start / stop, status monitoring, operation logs, anomaly location, and one-click retesting for multiple types of objects.

2. The method according to claim 1, characterized in that, The form of the intelligent algorithm class object includes Python code, C++ code, or C++ dynamic library.

3. The method according to claim 1, characterized in that, The direct function call method bypasses message encapsulation and network forwarding, directly loading and executing the algorithm code or dynamic library, and obtaining the function return value as the algorithm output.

4. The method according to claim 1, characterized in that, The algorithm-driven module supports iterative training of intelligent algorithms, including single-step debugging, loop calling, and parameter adjustment operation modes.

5. The method according to claim 1, characterized in that, The experimental data bus supports at least one of the following communication protocols: TCP, UDP, DDS, and MQTT.

6. An integrated management system for virtual and real testing, characterized in that, include: The integrated configuration management module is used to configure the access object's form, type, file path, communication protocol, entry function, and data conversion rules to form a unified access configuration; the algorithm-driven module is used to load and execute intelligent algorithm code or dynamic libraries by directly calling functions to obtain algorithm output results and support algorithm iterative training; the experimental data bus module is used to realize the integration and interaction of software modules in the form of messages, support multi-protocol communication, and automatically complete the bidirectional conversion between external interface data and internal bus data. The unified scheduling and monitoring module is used to enable unified start / stop, status monitoring, operation logs, anomaly location, and one-click retesting for multi-form access objects.

7. The system according to claim 6, characterized in that, The algorithm-driven module communicates with the intelligent algorithm via direct function calls, without going through a message bus or relying on the LVC architecture and cloud platform.

8. The system according to claim 6, characterized in that, The experimental data bus module is independent of the training middleware and distributed resource encapsulation, and only performs protocol adaptation and data conversion.

9. The system according to claim 6, characterized in that, The system supports lightweight deployment and can be deployed in standalone environments or embedded devices, making it suitable for various virtual-real combined testing scenarios such as laboratories, darkrooms, and outdoor fields.

10. An electronic device, characterized in that, It includes a processor, a memory, and a program or instructions stored in the memory and executable on the processor, wherein when the program or instructions are executed by the processor, they implement the steps of the virtual-real experiment integrated management method as described in any one of claims 1 to 5.

11. A readable non-transitory storage medium, characterized in that, The storage medium stores a program or instructions, which, when executed by a processor, implement the steps of the virtual-real experiment integrated management method as described in any one of claims 1 to 5.

Images