Test language engine interaction method based on data-real fusion

Abstract

The invention discloses a test language engine interaction method based on data-real fusion. The test language engine interaction method comprises the steps that a test language engine analyzes an automatic test instruction sent by a user; the test language engine configures required test environment parameters; the test language engine sends a test instruction to the model simulation engine according to the analysis result, and the model simulation engine is called; after the model simulation engine receives a test instruction sent by the test language engine, the configured test environment is used as input, various conditions possibly encountered by a user in actual operation are simulated according to a preset process, and the digital-real fusion system is comprehensively tested; in the test process, the model simulation engine records a test result in real time; the test language engine regularly collects test results recorded by the model simulation engine in real time, analyzes the test results and identifies defects in the data-real fusion system; and after the automatic test is completed, the test language engine generates a test report. According to the invention, the test efficiency, accuracy, comprehensiveness and repeatability can be improved.

Description

Technical Field

[0001] The present invention relates to an interaction method of a test language engine based on digital - physical integration, belonging to the field of system testing. Background Art

[0002] In the field of digital - physical integration, any technological innovation requires a large amount of capital investment and is accompanied by potential risks. To ensure the return on investment and the successful execution of digital - physical integration tasks, the preliminary design and testing work are crucial. The cyber - physical interaction technology can integrate digital models with actual physical systems at the initial design stage, providing a more efficient and accurate testing method. This will undoubtedly significantly improve the accuracy of digital - physical integration systems, achieve resource savings, and enhance task security.

[0003] However, the testing process of digital - physical integration systems often involves a large number of repetitive operations. If relying on manual operation, it is not only time - consuming and labor - intensive, but also error - prone. The test language engine can automatically execute these repetitive tasks, greatly improving the execution speed of testing, thereby shortening the product development cycle. Secondly, human factors, such as fatigue and inattention, may lead to deviations in test results. Moreover, the testing of digital - physical integration systems needs to cover various possible scenarios and conditions, and it is often difficult for manual testing to cover comprehensively. In addition, during the development of digital - physical integration systems, the same function often needs to be tested multiple times to ensure its stability, which will waste a lot of human and material resources. Summary of the Invention

[0004] The technical problem to be solved by the present invention is: overcoming the deficiencies of the prior art, providing an interaction method of a test language engine based on digital - physical integration, improving the testing efficiency and accuracy, ensuring the comprehensiveness and repeatability of testing, and ultimately realizing the optimal allocation of resources.

[0005] The technical solution of the present invention is: an interaction method of a test language engine based on digital - physical integration, testing a digital - physical integration system based on a test language engine and a model simulation engine; the method includes:

[0006] The test language engine parses the automated test instructions sent by the user.

[0007] After completing the instruction parsing, the test language engine configures the required test environment parameters; after the test environment parameter configuration is completed, the test language engine sends a test instruction to the model simulation engine according to the parsing result and calls the model simulation engine.

[0008] After receiving the test instruction sent by the test language engine, the model simulation engine uses the configured test environment as input, simulates various situations that users may encounter in actual operations according to a preset process, and comprehensively tests the digital - physical integration system.

[0009] During the testing process, the model simulation engine records the test results in real time; the test language engine periodically collects the test results recorded in real time by the model simulation engine, analyzes them, and identifies the defects in the digital-physical fusion system by comparing the expected results with the actual results;

[0010] After completing the automated testing, the test language engine generates a test report.

[0011] Preferably, the model simulation engine provides a simulation test environment for the test language engine and provides the model and operating status for the digital-physical fusion system. Specifically:

[0012] The model simulation engine can simulate the operating environment of the actual digital-physical fusion system, provide a highly realistic scenario for testing. When the test language engine continuously inputs different test data and parameters to the model simulation engine, the model simulation engine can test the performance and stability of the software under different conditions.

[0013] Preferably, when the test language engine parses the automated test instructions sent by the user, the parsing includes: syntax checking, parameter verification, and logical analysis;

[0014] During the parsing process, the test language engine will optimize the instructions to improve the test efficiency and accuracy; the optimization process includes instruction rewriting, merging, and deleting redundant instructions.

[0015] Preferably, the test environment parameters include: test data, test parameters, and expected test results.

[0016] Preferably, the model simulation engine records the test results in real time, including: test instructions, parameter responses, response times, error rates, and resource consumption of the digital-physical fusion system.

[0017] Preferably, the test report generated by the test language engine contains statistical data of the test results and a comprehensive evaluation of the functions, performance, and defects of the digital-physical fusion system.

[0018] Preferably, the test language engine conducts a security check on the test environment during the testing process to avoid leaking sensitive information or causing system damage during the testing process; at the same time, the test language engine verifies the test results to ensure their accuracy and credibility;

[0019] The test methods supported by the test language engine include: stress testing, performance testing, and compatibility testing.

[0020] Preferably, the test language engine also provides interfaces and instructions for users to interact with the test language engine;

[0021] The simultaneous test language engine provides service message subscription based on the WebSocket protocol, and can connect to the subscription server to obtain the status of the model simulation engine during the automated test process.

[0022] Preferably, the interfaces provided by the test language engine include: an engineering list acquisition interface, an engineering model and port query interface, a model initial value setting interface, a simulation status control interface, and a simulation data acquisition interface; where:

[0023] The engineering list acquisition interface allows users to obtain all available engineering lists in the test language engine for viewing and management;

[0024] For the engineering model and port query interface, users can query the detailed information and related port configurations of a specified project, including: the test model used by the project, the type, address of the port, and the current status of the port;

[0025] The model initial value setting interface allows users to set initial values for the test model;

[0026] The simulation status control interface allows users to control the status of the simulation programmatically, including starting, pausing, resuming, and stopping the simulation;

[0027] The simulation data acquisition interface provides users with the function of obtaining simulation data, including the current value and historical data of variables.

[0028] Preferably, the instructions provided by the test language engine include:

[0029] Get the current cycle: Allows users to query the number of cycles of the current test or simulation to understand the test progress and status;

[0030] Get the value of the port: Allows users to obtain the current value of a specific port for verification or as part of the test logic;

[0031] Set the value of the port: Allows users to dynamically set the value of the port to simulate different input conditions;

[0032] Simulation wait: Causes the test language engine to wait for a period of time before continuing to execute the next instruction, simulating delays in the actual system or for synchronization operations;

[0033] Get the current simulation time: Obtain the simulation time in the current simulation environment;

[0034] Get the current real time: Obtain the real time of the system for timestamp recording or performance analysis;

[0035] Start the current simulation: Start the simulation process after all test conditions and parameters are ready;

[0036] Stop the current simulation: Safely stop the simulation when the test is completed or when interruption is required;

[0037] Pause the current simulation: Pause the simulation when it is necessary to pause at a specific point for inspection or adjustment;

[0038] Resume the current simulation: Resume the execution of the simulation after it has been paused;

[0039] Is the simulation running: Used to query whether the simulation is running, assisting in conditional judgment and process control in test scripts;

[0040] Engine wait: Cause the test language engine to pause execution until a specific condition is met or a specified time has elapsed;

[0041] Send message: Allow the test script to send messages to other systems or modules for communication or to trigger specific events;

[0042] Assertion: In testing, used to verify whether the behavior of the system meets expectations; allows users to define expected results and make comparisons;

[0043] End the current script: Used to safely end the execution of the script after the test script has completed all tasks.

[0044] The present invention has the following advantages compared with the prior art:

[0045] (1) The present invention can comprehensively simulate and emulate the working environment of the digital-physical fusion system, including the physical environment, digital models, and the interaction process between them; this comprehensive simulation and emulation ability makes the test more realistic and reliable, and can better evaluate the performance and security of the system;

[0046] (2) The present invention has the ability of adaptive error handling, and can automatically adjust the test strategy, re-execute the test cases or trigger corresponding emergency measures when encountering errors; this adaptive ability makes the test more robust and reliable, and can handle various complex test scenarios;

[0047] (3) The present invention can be integrated and work collaboratively with other development tools, test tools, and management systems; through integration and collaboration, seamless connection of the test process, real-time sharing of test data, and automatic feedback of test results can be achieved; this integration and collaboration ability makes the test more efficient and collaborative, and can improve the collaboration efficiency and quality of the entire development team. Brief Description of the Drawings

[0048] Figure 1 It is a schematic interaction diagram of the test language engine based on digital-physical fusion of the present invention. Detailed Embodiments

[0049] To implement the testing of the digital-physical integration system, the present invention designs and implements a method for interacting with a testing language engine based on digital-physical integration.

[0050] Through a preset test script, the testing language engine interface can automatically execute test cases, collect test data, and automatically analyze the test results and generate reports. This automated testing process not only speeds up the testing speed but also improves the test coverage and accuracy. At the same time, through automated error detection and location, problems can be quickly discovered and repaired, thus shortening the product development cycle.

[0051] In the field of digital-physical integration systems, the application of the digital-physical integration testing language engine interface also has special significance. Since the working environment of digital-physical integration systems is extremely harsh, high requirements are placed on the stability and reliability of equipment. Through the testing language engine interface, the performance of digital-physical integration systems under various extreme conditions can be comprehensively tested to ensure that they can work properly in a specific environment.

[0052] In addition, by combining the digital-physical integration testing language engine interface with the digital-physical integration system, more realistic and comprehensive testing can be achieved. Through the real-time interaction between the digital model and the physical device, combined with the efficient testing capabilities of the testing language engine, the working environment of the digital-physical integration system can be more accurately simulated, thus better evaluating its performance and security.

[0053] The design and usage method of a method for interacting with a testing language engine based on digital-physical integration designed by the present invention are as follows Figure 1 As shown, the digital-physical integration system is tested based on the testing language engine and the model simulation engine. The model simulation engine provides a simulation testing environment for the testing language engine and at the same time provides models and operating states for the digital-physical integration system. When the testing language engine receives an automated test instruction sent by the user, it will start the workflow from instruction parsing to instruction invocation, and then to the collection and analysis of test results.

[0054] 1. Instruction parsing

[0055] The testing language engine first parses the automated test instruction sent by the user in detail. This process includes syntax checking, parameter verification, and logical analysis. Syntax checking ensures that the instruction format is correct and there are no syntax errors; parameter verification verifies the parameters involved in the instruction to ensure their validity; logical analysis deeply understands the instruction intent to prepare for subsequent invocation of the model simulation engine. During the parsing process, the testing language engine also optimizes the instruction to improve testing efficiency and accuracy. Optimization may include instruction rewriting, merging and deleting redundant instructions, etc. These optimization measures are aimed at reducing unnecessary operations during the testing process, thereby improving the overall performance.

[0056] 2. Invoke the simulation execution engine

[0057] After completing the instruction parsing, the test language engine will call the model simulation engine for automated testing according to the parsing results. The model simulation engine is a powerful tool that can simulate the operating environment of the actual digital-physical fusion system and provide a highly realistic scenario for testing. Before invoking the model simulation engine, the test language engine will configure the required test environment, including test data, test parameters, and expected test results, etc. These configuration information will be used as the input of the model simulation engine to ensure that it can execute the test in the correct context. After receiving the test instructions, the model simulation engine will start executing the test according to the preset process. During this process, the engine will simulate various situations that users may encounter in actual operations and conduct a comprehensive test on the digital-physical fusion system. By continuously inputting different test instructions to the model simulation engine through the test language engine, the model simulation engine can verify the performance and stability of the software under different conditions.

[0058] 3. Test result collection and analysis

[0059] During the testing process, the model simulation engine will record the test results in real time, including key metrics such as the test instructions of the digital-physical fusion system, parameter responses, response times, error rates, resource consumption, etc. These data are crucial for evaluating the correctness of the functions and performance of the digital-physical fusion system and discovering potential problems. The test language engine will regularly collect these test results and conduct in-depth analysis. By comparing the expected results with the actual results, the test language engine can identify the defects and deficiencies in the digital-physical fusion system. These analysis results provide valuable feedback for the development team to help them improve the design of the digital-physical fusion system and enhance the system performance targeted.

[0060] 4. Generate test reports and feedback

[0061] Finally, generate test reports and provide feedback. After completing the automated testing, the test language engine will generate a detailed test report. This report not only includes the statistical data of the test results but also comprehensively evaluates the functions, performance, and defects of the digital-physical fusion system. The development team can intuitively understand the performance of the software in various aspects through this report for subsequent optimization and improvement. In addition, the test language engine also provides a feedback mechanism that allows the development team to adjust and optimize the test instructions according to the test results. This interactivity makes the automated testing process more flexible and efficient and can better meet the development needs.

[0062] Meanwhile, the test language engine always pays attention to the security and reliability issues during the testing process. It conducts strict security checks on the test environment to ensure that no sensitive information is leaked or the system is damaged during the testing process. At the same time, the test language engine also verifies the test results to ensure their accuracy and credibility. To improve the reliability of the testing, the test language engine also supports a variety of testing strategies and methods, including stress testing, performance testing, compatibility testing, etc. These testing methods can comprehensively evaluate the performance of the digital-physical integration system, helping the development team discover potential problems and solve them in advance.

[0063] Therefore, by parsing the automated test instructions sent by users and calling the model simulation engine for automated testing, the test language engine provides strong support for software development and quality assurance. From instruction parsing to test result collection and analysis, to the generation and feedback of test reports, the test language engine forms a complete and efficient closed-loop workflow. This not only improves the testing efficiency and quality but also provides valuable data support and improvement directions for the development team.

[0064] To facilitate users' use, the test language engine also exposes some ports and instructions. These designs enable users to interact with the test language engine more flexibly, meeting diverse testing needs.

[0065] First of all, the interfaces provided by the test language engine include interfaces such as all project list acquisition interfaces, project model and port query interfaces, model initial value setting interfaces, simulation status control interfaces, and simulation data acquisition interfaces. At the same time, it also provides service message subscriptions based on the WebSocket protocol, which can connect to the subscription server to obtain the status of the simulation execution engine during the automated testing process. Among them:

[0066] The all project list acquisition interface allows users to obtain all available project lists in the test language engine. Through this interface, users can conveniently view and manage their test projects and understand which projects are currently in progress or have been completed. This is very helpful for users to carry out project management and resource allocation.

[0067] Through the project model and port query interface, users can query the detailed information and related port configurations of a specified project. This includes the test model used by the project, the type, address of the port, and the current status of the port, etc. This interface helps users better understand the configuration of the test environment and ensures the smooth progress of the testing.

[0068] Before the test starts, the user may need to perform initialization settings on the test model to ensure that the test starts from a known and consistent state. The model initial value setting interface allows the user to set initial values for the test model, such as the initial values of variables, switch states, etc. By setting the model initial values, the user can ensure that each test starts under the same conditions, thereby improving the repeatability and accuracy of the test.

[0069] The simulation state control interface allows the user to control the state of the simulation programmatically, including starting, pausing, resuming, and stopping the simulation, etc. The user can call these interfaces at the appropriate time according to their test needs to control the progress of the simulation. This flexible control method enables the user to better grasp the rhythm and progress of the test.

[0070] During the test, the user may need to obtain the simulation data in real time for monitoring and analysis. The simulation data acquisition interface provides the function of obtaining simulation data, including the current values of variables, historical data, etc. The user can obtain the required data through this interface and use it for subsequent data processing and analysis work.

[0071] The specific definitions of the interfaces are as follows:

[0072] 1) Query all project lists

[0073] The request method is GET. The request parameters are shown in Table 1:

[0074] Table 1 Request parameter table for querying all project lists in GET method

[0075] Name Position Type Required isDefaultVer query string No

[0076] The response parameters are shown in Table 2:

[0077] Table 2 Response parameter table for querying all project lists in GET method

[0078]

[0079]

[0080] 2) Obtain the project model

[0081] The request method is GET, and the request parameters are shown in Table 3:

[0082] Table 3 Request parameter table for obtaining the project model in GET method

[0083] Name Position Type Required id query integer Yes

[0084] The response parameters are shown in Table 4:

[0085] Table 4 Response parameter table for obtaining the project model in GET method

[0086]

[0087]

[0088] 3) Set the initial value of the model

[0089] The request method is PUT, and the request parameters are shown in Table 5:

[0090] Table 5 Request Parameter Table for Setting the Initial Value of the Model in PUT Mode

[0091] Name Position Type Optional body bodv array[obj ect] No

[0092] The response parameters are shown in Table 6:

[0093] Table 6 Response Parameter Table for Setting the Initial Value of the Model in PUT Mode

[0094] Name Type Required code integer false data boolean false msg string false

[0095] 4) Modify the terminal simulation status

[0096] The request method is PUT, and the request body parameters are shown in Table 7:

[0097] Table 7 Request Body Parameter Table for Modifying the Terminal Simulation Status in PUT Mode

[0098] Name Position Type Required body body object No project_id body integer No task_id body integer No simulation_status body string No

[0099] The response parameters are shown in Table 8:

[0100] Table 8 Response Parameter Table for Modifying the Terminal Simulation Status in PUT Mode

[0101] Name Type Required code integer true data b00lean true msg string true

[0102] 5) Obtain the subscriber information

[0103] The request method is GET, and there are no request parameters.

[0104] The response parameters are shown in Table 9:

[0105] Table 9 Response Parameter Table for Obtaining the Subscriber Information in GET Mode

[0106] Name Type Required code integer false data object false ip string true httpPort integer true websocketPort integer true isOnLine boolean false id integer false createTime string false msg string false

[0107] In addition, there is a service subscription interface based on WebSocket. The connection URI is ws: / / <ip> : <port> / ?task_id=<Project>. The response data is in JSON format as follows:

[0108]

[0109]

[0110] Meanwhile, the test language engine interaction method based on digital-physical fusion also provides many instructions to meet various operation requirements of users in digital-physical fusion testing. These instructions cover all aspects of testing, and corresponding instruction support can be found in the processes from test preparation to execution, etc. It mainly includes the following types of instructions:

[0111] 1) Get the current cycle: This instruction allows users to query the number of cycles of the current test or simulation, which helps to understand the test progress and status.

[0112] 2) Get the value of a port: Users can obtain the current value of a specific port through this instruction for verification or as part of the test logic.

[0113] 3) Set the value of a port: In testing, it is often necessary to simulate different input conditions, and this instruction allows users to dynamically set the value of a port.

[0114] 4) Simulation wait: This instruction will make the test language engine wait for a period of time before continuing to execute the next instruction, simulating delays in the actual system or for synchronization operations.

[0115] 5) Get the current simulation time: In a simulation environment, it is crucial to know the current simulation time for test synchronization and time-related functions, and this instruction provides this function.

[0116] 6) Get the current real time: In addition to the simulation time, sometimes it is also necessary to obtain the real time of the system for timestamp recording or performance analysis.

[0117] 7) Start the current simulation: After preparing all test conditions and parameters, use this instruction to start the simulation process.

[0118] 8) Stop the current simulation: When the test is completed or the simulation needs to be interrupted, this instruction can be used to safely stop the simulation.

[0119] 9) Pause the current simulation: If it is necessary to pause the simulation at a specific point for inspection or adjustment, this instruction can be used.

[0120] 10) Resume the current simulation: After pausing, use this instruction to resume the execution of the simulation.

[0121] 11) Whether in simulation run: This instruction is used to query whether the simulation is running, which helps with conditional judgment and process control in test scripts.

[0122] 12) Engine wait: Similar to "simulation wait", but this instruction pauses the execution of the entire test language engine until a specific condition is met or a specified time has elapsed.

[0123] 13) Send message: Allows the test script to send messages to other systems or modules for communication or to trigger specific events.

[0124] 14) Assertion: In testing, assertions are used to verify whether the behavior of the system meets expectations. This instruction allows users to define the expected results and make comparisons.

[0125] 15) End the current script: When the test script has completed all tasks, use this instruction to safely end the execution of the script.

[0126] The specific method implementation is as follows:

[0127] 1. The main engine engine manages the server and tasks. The server is responsible for providing an interface for the test platform, accepting HTTP request operation tasks, and the task is responsible for running the test project, running in a new thread each time, and only running one test project at a time.

[0128] Define the Engine class. When initializing, obtain the local IP address and HTTP port number from the configuration file and create an instance of APIServer. At the same time, set the HTTP request handler for handling PUT requests.

[0129] The start() method is used to start the server. It will print information about the server startup and start the server thread.

[0130] The proc_http_request() method is the HTTP request handler, which performs corresponding operations according to the cmd parameter in the request, such as start, stop, pause, and resume. If the request format is incorrect or an exception occurs, an error message will be returned.

[0131] The check_task() method is used to check the task status. If the task does not exist or the task ID does not match, the corresponding error message will be returned.

[0132] The start_task() method is used to start a new task. First, check whether there is a task currently running. If not, create a new Task instance and start the task thread.

[0133] 2. The server defines a simple API server based on the built-in Python HTTP server

[0134] First, a class named HTTPServerRequestHandler is defined, which inherits from BaseHTTPRequestHandler. This class processes HTTP requests, including GET, POST, and PUT methods. For each method, it records the request path and calls the process_request method to handle the request.

[0135] The process_request method checks if the request belongs to an instance of the APIServer class. If so, it looks for a handler function that matches the request path and method. If a matching handler function is found, it executes the function and sends the result back to the client. If no matching handler function is found, it returns a 404 status code and a "Not Found" message.

[0136] Second, a class named APIServer is defined, which inherits from HTTPServer. This class contains a dictionary named routes to store the mapping of URL paths and methods to handler functions. It also provides a method named set_http_proc to add a handler function to the routing dictionary.

[0137] The log_message method is overridden to disable the default logging behavior.

[0138] 3. The task contains all the test sequences under the test project

[0139] The sequence is responsible for scheduling the execution of the current test sequence, and each sequence is executed sequentially.

[0140] start(self): The method to start executing the task. First, it sets the task status to "running", then traverses the sequence list, creates a Sequence object for each sequence and calls its start() method. If an exception occurs during the execution, the exception is caught and an error message is sent to the manager. After the task execution is completed, a completion message is sent to the manager.

[0141] stop(self): The method to stop the task. It sets the task status to "stopped" and attempts to stop the currently executing sequence (if any). After the stop is completed, a stop message is sent to the manager.

[0142] pause(self): A method to pause a task. Sets the task status to "pause" and sends a pause message to the manager.

[0143] resume(self): A method to resume a task. Sets the task status to "running" and sends a resume message to the manager.

[0144] get_task_id(self): A method to get the task ID. Returns the ID of the task.

[0145] 4. The sequence contains the lua_engine

[0146] The lua_engine is responsible for running lua scripts, and each script runs in a new process.

[0147] First, a class named Sequence is defined to handle task sequences. It receives two parameters: task_param and sequence_param, representing task parameters and sequence parameters respectively. During initialization, it attempts to extract the task ID and sequence ID from these two parameters and creates a message sender object. Then, it creates two queues (parent_2_child_queue and child_2_parent_queue) and a child process (lua_engine_process) to execute Lua scripts. Additionally, it creates a thread (receiving_from_child_thread) to listen for messages from the child process.

[0148] receiving_from_child: This method is an infinite loop that receives messages from the child process and sends them to the manager. When a stop command is received, it starts a new thread to stop the sequence.

[0149] start: This method is used to start the sequence. It first sends a start status message, then starts the thread for receiving messages and the child process. If an exception occurs during the execution of the child process, it catches the exception and sends an error message. Finally, it sends a completion status message.

[0150] stop: This method is used to stop the sequence. It sets the running flag to False, waits for the thread for receiving messages to end, and terminates the child process. If an exception occurs during the stop process, it catches the exception and sends an error message. Finally, it sends a stop status message.

[0151] stop_sequence: This method encapsulates the stop method and is used to call the stop method in another thread.

[0152] get_sequence_id: This method returns the sequence ID.

[0153] 5. The Lua script engine lua_engine, which includes simu_device and engine_device

[0154] simu_device is docked with the simulation platform and is responsible for executing simulation-related instructions in the Lua script.

[0155] engine_device is responsible for running engine-related instructions.

[0156] The script engine is mainly used to execute Lua scripts. It uses the loguru library for logging, the lupa library to run Lua scripts, and some classes and methods in the engine and utils modules.

[0157] The LuaEngine class is the main class. It accepts four parameters: task_param, sequence_param, child_2_parent_queue, and parent_2_child_queue. In the class constructor, it saves these parameters as instance variables and creates a series of virtual devices (simu_devices) according to the configuration information in sequence_param. Then, it uses the LuaRuntime library to create a Lua runtime environment called lua_engine and registers some Lua functions that allow functions in Lua scripts to be called from Python code.

[0158] The register_lua_function method registers Python functions into the Lua environment, enabling Lua scripts to call these functions. For example, functions such as simu_get_port_value and simu_set_port_value are registered into the Lua environment.

[0159] The run method is the main method of the LuaEngine class. It first starts all virtual devices and then attempts to execute the Lua script. If the execution is successful, it sends a status message to the parent process; if an exception occurs, it catches the exception and sends an error message; finally, whether successful or not, it stops all virtual devices.

[0160] 6. The simu_device is a Python module used to communicate with a simulation device. It contains functions and classes for operations such as setting initial values, injecting values, starting / stopping the simulation of the simulation device through an HTTP interface. At the same time, it also provides functions for parsing simulation data and status, and defines a virtual device interface for interaction with Lua.

[0161] simu_get_port_value: Get the value of a specified model and port. First, convert the Lua parameters to a Python dictionary, and then check if it is running. If it is running and there is simulation data, try to get the value of the specified model and port. If successful, return the value; otherwise, record the error and return an empty string.

[0162] simu_set_port_value: Set the value of a specified model and port. First, convert the Lua parameters to a Python dictionary, and then check if it is running. If it is running, try to inject the value into the backend server. If successful, send a message to the message queue; otherwise, record the error and send an error message.

[0163] simu_get_current_time: Get the current simulation time. If it is running and there is simulation data, return the simulation time; otherwise, return 0.

[0164] simu_get_step: Get the current simulation step. If it is running and there is simulation data, return the simulation step; otherwise, return 0.

[0165] simu_get_actually_time: Get the actual Unix timestamp.

[0166] simu_start: Start the simulation. If it is already running, record the log and send a start message to the message queue. Then try to set the simulation status to "start", if successful, wait for 2 seconds; otherwise, record the error and send an error message.

[0167] simu_stop: Stop the simulation. If it is already running, record the log and send a stop message to the message queue. Then try to set the simulation status to "stop", if successful, wait for 2 seconds; otherwise, record the error and send an error message.

[0168] simu_pause(self): Pause the simulation device. First, check if the device is running. If it is, send a pause message to the message queue and try to set the simulation status to paused. If the setting fails, send an error message; otherwise, wait for 2 seconds.

[0169] simu_resume(self): Resume the simulation device. Similar to simu_pause, first check if the device is running, then send a resume message to the message queue and attempt to set the simulation status to resumed. If the setting fails, send an error message; otherwise, wait for 2 seconds.

[0170] simu_sleep(self,seconds): Put the simulation device to sleep for a certain period of time. First check if the device is running, then pause the simulation, wait for the specified number of seconds, and finally resume the simulation.

[0171] simu_is_running(self): Check if the simulation device is running. If the device is running and the simulation status is "running", return True; otherwise, return False.

[0172] 7. engine_device is used to manage the engine device, and a class named EngineDevice is defined.

[0173] engine_sleep(self,seconds): Pause the engine from running for the specified number of seconds and send status messages to the message queue before and after the pause.

[0174] engine_stop(self): Stop the engine and send a status message to the message queue.

[0175] engine_send_message(self,msg): Send a message to the message queue.

[0176] engine_task_start(self,msg): Start executing a task and send a status message indicating the start of the task to the message queue.

[0177] engine_task_success(self,msg): The task execution is successful, and send a status message indicating the success of the task to the message queue.

[0178] engine_task_error(self,msg): An error occurs during the task execution, and send a status message indicating the task error to the message queue.

[0179] engine_assert(self,condition,msg): Assert whether a certain condition is true and send an assertion status message to the message queue.

[0180] In addition, the loguru library is imported for logging, the time library for pausing operations, and the config_manager and utils modules for configuration management and message sending.

[0181] 8. The state.machine implements a simple StateMachine class for handling different events and performing corresponding operations based on the current state.

[0182] 9. The web_socket defines a class named WebSocketClient for creating and managing WebSocket clients. It uses the websocket library to handle WebSocket connections and the threading library to run WebSocket connections in the background. At the same time, it also uses the loguru library for logging.

[0183] The present invention provides an innovative method for interacting with a test language engine based on digital-physical fusion, which brings significant advantages and efficiency improvements to the design and testing of digital-physical fusion systems and their related systems.

[0184] The core of the method for interacting with a test language engine based on digital-physical fusion lies in a powerful simulation execution engine that can receive user-defined automated test instructions and construct and simulate the complex working environment and states of digital-physical fusion systems and their related systems according to the instructions. By interacting with the interface module of physical devices in real time, the system can accurately obtain actual physical data and reflect these changes in the simulation model in real time, thus ensuring the high authenticity and accuracy of the test.

[0185] Therefore, the application of digital-physical fusion testing in the design of digital-physical fusion systems is indispensable. It can not only improve the test efficiency and accuracy but also ensure the comprehensiveness and repeatability of the test, ultimately achieving the optimal allocation of resources. Therefore, digital-physical fusion testing is an important technical support for promoting the continuous development of digital-physical fusion systems.

[0186] The content not detailedly described in the specification of the present invention belongs to the prior art well-known to those skilled in the art.< / port> < / ip>

Claims

1. A method for interacting between a test language engine based on digital-physical integration, characterized in that Testing the digital - physical fusion system based on a test language engine and a model simulation engine, the method includes: The test language engine parses the automated test instructions sent by the user; After completing the instruction parsing, the test language engine configures the required test environment parameters; after the test environment parameters are configured, the test language engine sends a test instruction to the model simulation engine according to the parsing result and invokes the model simulation engine; After receiving the test instruction sent by the test language engine, the model simulation engine uses the configured test environment as input and simulates various situations that users may encounter in actual operations according to a preset process to comprehensively test the digital - physical fusion system; During the test process, the model simulation engine records the test results in real - time; the test language engine regularly collects the test results recorded in real - time by the model simulation engine and analyzes them. By comparing the expected results with the actual results, defects in the digital - physical fusion system are identified; After completing the automated test, the test language engine generates a test report.

2. The interactive method of a test language engine based on digital-physical integration according to claim 1, wherein: The model simulation engine provides a simulation test environment for the test language engine and also provides models and operating states for the digital - physical fusion system. Specifically: The model simulation engine can simulate the operating environment of the actual digital - physical fusion system, providing a highly realistic scenario for testing. When the test language engine continuously inputs different test data and parameters to the model simulation engine, the model simulation engine can test the performance and stability of the software under different conditions.

3. A method for interacting with a test language engine based on the integration of digital and physical, as claimed in claim 1, wherein: When the test language engine parses the automated test instructions sent by the user, the parsing includes: syntax checking, parameter verification, and logical analysis; During the parsing process, the test language engine will perform optimization processing on the instructions to improve the test efficiency and accuracy; the optimization processing includes instruction rewriting, merging, and deleting redundant instructions.

4. A method for interacting with a test language engine based on the integration of digital and physical realities according to claim 1, characterized in that: The test environment parameters include: test data, test parameters, and expected test results.

5. A method for interacting with a test language engine based on the integration of digital and physical worlds according to claim 1, characterized in that: The model simulation engine records the test results in real - time, including: test instructions of the digital - physical fusion system, parameter responses, response times, error rates, and resource consumption.

6. The interactive method of a test language engine based on digital-physical integration according to claim 1, wherein: The test report generated by the test language engine contains statistical data of the test results and a comprehensive evaluation of the functions, performance, and defects of the digital - physical fusion system.

7. A method for interacting with a test language engine based on the integration of digital and physical worlds according to claim 1, characterized in that: The test language engine will perform a security check on the test environment during the test process to avoid leaking sensitive information or causing system damage during the test; at the same time, the test language engine will verify the test results to ensure their accuracy and credibility; The test methods supported by the test language engine include: stress testing, performance testing, and compatibility testing.

8. A method for interacting with a test language engine based on digital-physical integration according to claim 1, characterized in that: The test language engine also provides interfaces and instructions for users to interact with the test language engine; At the same time, the test language engine provides service message subscriptions based on the WebSocket protocol, which can connect to the subscription server to obtain the status of the model simulation engine during the automated test process.

9. A method for interacting with a test language engine based on digital-physical integration according to claim 8, characterized in that: The interfaces provided by the test language engine include: project list acquisition interface, project model and port query interface, model initial value setting interface, simulation state control interface, and simulation data acquisition interface; among them: The project list acquisition interface allows users to obtain all available project lists in the test language engine for viewing and management; Engineering model and port query interface, allowing users to query the detailed information of a specified project and related port configurations, including: the test model used by the project, the type, address of the port, and the current status of the port; The model initial value setting interface allows users to set initial values for the test model; The simulation status control interface allows users to control the status of the simulation programmatically, including starting, pausing, resuming, and stopping the simulation; The simulation data acquisition interface provides users with the function of acquiring simulation data, including the current values of variables and historical data.

10. A method for interacting with a test language engine based on digital-physical integration according to claim 8, characterized in that: The instructions provided by the test language engine include: Get the current cycle: Allows users to query the number of cycles of the current test or simulation to understand the test progress and status; Get the value of the port: Allows users to obtain the current value of a specific port for verification or as part of the test logic; Set the value of the port: Allows users to dynamically set the value of the port to simulate different input conditions; Simulation wait: Causes the test language engine to wait for a period of time before continuing to execute the next instruction, simulating delays in the actual system or for synchronization operations; Get the current simulation time: Obtain the simulation time in the current simulation environment; Get the current real time: Obtain the real time of the system for timestamp recording or performance analysis; Start the current simulation: Start the simulation process after all test conditions and parameters are ready; Stop the current simulation: Safely stop the simulation when the test is completed or when the simulation needs to be interrupted; Pause the current simulation: Pause the simulation when it is necessary to pause at a specific point for inspection or adjustment; Resume the current simulation: Resume the execution of the simulation after pausing; Is the simulation running: Used to query whether the simulation is running, assisting in conditional judgment and process control in the test script; Engine wait: Causes the test language engine to suspend execution until a specific condition is met or a specified time is reached; Send a message: Allows the test script to send messages to other systems or modules for communication or to trigger specific events; Assertion: In testing, it is used to verify whether the behavior of the system meets the expectations; allows users to define the expected results and make comparisons; End the current script: Used to safely end the execution of the script after the test script has completed all tasks.

Images