Digital-real fusion test system, test method thereof and computer equipment

Through the testing method based on the digital real fusion test system and the digital real fusion higher-order testing language, the problem that the digital real fusion test in the existing technology is only suitable for specific fields, achieving higher versatility and adaptability.

CN120144458APending Publication Date: 2025-06-13ZHENGZHOU UNIV +1
View PDF 0 Cites 3 Cited by

Patent Information

Application Number
CN202510226919.0
Authority / Receiving Office
CN · China
Patent Type
Applications(China)
Current Assignee / Owner
Filing Date
2025-02-27
Publication Date
2025-06-13

AI Technical Summary

Technical Problem

The existing digital and real fusion testing technology is only suitable for specific fields, with low versatility and is difficult to adapt to the complex needs of parallel testing of multiple objects under test.

Method used

Using a test method based on a digital real fusion test system, test scripts are written through a digital real fusion advanced test language, parsing the script to obtain executable test atom sequences, and executing these sequences to complete the test.

Benefits of technology

It improves the versatility of digital and real fusion tests, can be applicable to multiple test scenarios, and solves the problem that testing in the prior art is only suitable for specific fields.

✦ Generated by Eureka AI based on patent content.

Smart Images

  • Figure CN120144458A_ABST
    Figure CN120144458A_ABST
Patent Text Reader

Abstract

The invention belongs to the technical field of data-real fusion testing, and particularly relates to a data-real fusion testing system, a testing method thereof and computer equipment. The method comprises the following steps: S1, acquiring a test script compiled by using a data-real fusion high-order test language according to a test requirement in advance; the data-real fusion high-order testing language comprises a simulation debugging instruction used for controlling subsystems in the data-real fusion testing system and a tested object of the data-real fusion testing system to complete testing, and the simulation debugging instruction comprises an execution part and a function part; the function part represents a function realized by the simulation debugging instruction, and the execution part represents an execution object of the simulation debugging instruction; the execution object is each subsystem or a tested object; s2, analyzing the test script to obtain an executable test atom sequence; and S3, executing the test atom sequence to complete the test so as to meet the test requirement. The technical problems that in the prior art, a number-real fusion test is only suitable for a specific field, and the universality is low are solved.
Need to check novelty before this filing date? Find Prior Art

Description

Technical Field

[0001] The present invention belongs to the technical field of digital-physical fusion testing, and specifically relates to a digital-physical fusion testing system, a testing method thereof, and a computer device. Background Art

[0002] Traditional testing means rely on documents to verify testing objectives, where both the testing objectives and the testing environment are in a real state, so the obtained test results are also authentic. However, some CPSs are too large in scale or too high in physical hardware cost to be suitable for testing with traditional testing means. Virtual simulation testing helps save costs and time while providing a more flexible testing environment. However, the real environment for CPS testing is difficult to fully simulate and has limited credibility. Therefore, the simulation testing of virtual-real fusion, that is, Live-Virtual-Construction (LVC) testing, is proposed, which not only retains the characteristic of reliable data in traditional testing but also can save testing costs and time through virtual simulation testing, improve testing efficiency, flexibility, and coverage, and at the same time can improve system performance according to evaluation results.

[0003] In the field of digital-physical fusion testing, existing testing technologies have shown their limitations. They often lack sufficient generality and scalability and are difficult to adapt to the complex requirements of parallel testing of multiple DUTs. Most of them are only applicable to a specific technical field, such as some vehicle tests only applicable to the automotive field. In addition, existing languages also have deficiencies in terms of coordination and real-time performance, which limits their application in high-performance testing environments. Summary of the Invention

[0004] The purpose of the present invention is to provide a digital-physical fusion testing system, a testing method thereof, and a computer device to solve the technical problem that digital-physical fusion testing in the prior art is only applicable to specific fields and has low generality.

[0005] To solve the above technical problem, a technical solution of a testing method based on a digital-physical fusion testing system provided by the present invention is: A testing method based on a digital-physical fusion testing system, the method comprising:

[0006] S1. Obtain a test script written in a digital-physical fusion high-order testing language in advance according to testing requirements;

[0007] The digital-physical fusion high-order testing language includes simulation debugging instructions for controlling each subsystem in the digital-physical fusion testing system and the DUT of the digital-physical fusion testing system to complete testing. The simulation debugging instructions include an execution part and a function part; the function part represents the function implemented by the simulation debugging instruction, and the execution part represents the execution object of the simulation debugging instruction; the execution object is each subsystem or DUT;

[0008] S2. Analyze the test script to obtain an executable sequence of test atoms;

[0009] S3. Execute the sequence of test atoms to complete the test and meet the test requirements.

[0010] The beneficial effects of the above technical solution are as follows: The technical solution of a test method based on a digital-physical fusion test system of the present invention belongs to an improved invention. The present invention writes a test script for testing using a test language suitable for digital-physical fusion testing, and completes digital-physical fusion testing based on the test script. The execution objects of the simulation debugging instructions of the test language for digital-physical fusion testing are all subsystems of the digital-physical fusion test system, rather than components of a specific object under test (such as the engine of a car). By shielding the heterogeneity of underlying devices, the generality of digital-physical fusion testing is improved. The present invention solves the technical problem in the prior art that digital-physical fusion testing is only applicable to specific fields and has low generality.

[0011] Further, the digital-physical fusion high-order test language further includes one or a combination of two or a combination of three or four of an engine waiting time instruction, a send information instruction, an assertion instruction, and a script end instruction;

[0012] The engine waiting time instruction is used to obtain the engine waiting time; the send information instruction is used to send information; the assertion instruction is an assertion instruction for verifying whether the logic of the test script is correct at a specific point; the script end instruction is used to end the currently executing test script.

[0013] Further, the functions implemented by the functional unit are to obtain the simulation cycle, obtain the port value, set the port value, set the behavior simulation waiting time, obtain the current simulation time, obtain the current real time, start the current simulation test, stop the current simulation test, pause the current simulation test, continue the current simulation test, perform initial parameter configuration, execute a parameter update instruction, or judge the simulation running state.

[0014] Further, S2 includes:

[0015] S21. Perform lexical analysis on the test script to obtain a sequence of lexical units and their types of the test script;

[0016] S22. Generate an abstract syntax tree through syntactic analysis based on the lexical units and their types;

[0017] S23. Supplement semantic information to the abstract syntax tree obtained in S22 through semantic analysis to obtain an abstract syntax tree with semantic information;

[0018] S23. Convert the abstract syntax tree with semantic information into the sequence of test atoms.

[0019] Further, S21 includes:

[0020] S211. Preprocess the test script to remove invalid characters in the test script, and obtain a regular expression describing the lexical rules of the digital-physical fusion high-order test language;

[0021] S212. Convert the regular expression into a non-deterministic finite automaton through the Thompson algorithm;

[0022] S213. Convert the non-deterministic finite automaton into a deterministic finite automaton through the subset construction algorithm;

[0023] S214. Compress the deterministic finite automaton through the Hopcroft minimization algorithm to obtain a sequence of lexical units and their types.

[0024] Further, the lexical rules of the digital-physical fusion high-order test language include one or a combination of two or a combination of three or four of a time condition, a position condition, a speed upper limit condition, and a speed lower limit condition;

[0025] The time condition is used to represent after a set time length; the position condition is used to represent after a set displacement length; the speed upper limit condition is used to represent that the speed is lower than the set speed; the speed lower limit condition is used to represent that the speed is higher than the set speed.

[0026] Further, in S22, an improved LR(1) or LALR(1) parsing algorithm is used for syntax analysis to obtain an abstract syntax tree;

[0027] The reduction operation of the improved LR(1) or LALR(1) parsing algorithm is as follows: First, determine the production rule to be reduced, pop the stack elements equal to the number of right-side symbols of the reduction in sequence, connect the rule lists of all the popped stack elements in the popping order and connect them before the rule list being constructed; then pop the top stack element again, obtain the state and the rule list, retain the information of the reduction rule and the previous state information in the stack, look up the next state according to the GOTO table, and push the next state and a new empty rule list as elements onto the stack.

[0028] Further, the abstract syntax tree with semantic information in S23 is obtained through the following method:

[0029] S231. Traverse the abstract syntax tree to obtain identifier information;

[0030] S232. Perform semantic checks, and the semantic checks include type checks, scope checks, and other semantic rule checks;

[0031] The type checking is used to ensure type compatibility between expressions, variable assignments, and function arguments; the scope checking is used to ensure that variables have been declared before use and are within the correct scope; the other semantic rule checks are used to detect unused or uninitialized variables and illegal operation errors;

[0032] S233. Calculate the semantic attributes of nodes according to the semantic functions predefined for each node of the abstract syntax tree to obtain an abstract syntax tree with semantic information.

[0033] Further, the method of converting the abstract syntax tree with semantic information into the test atom sequence in S23 is as follows:

[0034] S234. Traverse the abstract syntax tree with semantic information, obtain the nodes related to the test atom tasks, parse their attributes and contents, and extract key information;

[0035] S235. Build a data structure based on the key information; the data structure details the logical order, execution conditions, and verification criteria of each test atom task;

[0036] S236. Convert the data structure into an executable test atom sequence.

[0037] Further, the Kennedy-Warren tree traversal algorithm is used to traverse the abstract syntax tree.

[0038] The present invention also provides a technical solution for a digital-physical fusion test system: including a test engine and a scenario server, the scenario server is used to write a test script in the digital-physical fusion high-order test language according to test requirements for the test engine to obtain, and the test engine is used to execute a computer program to implement the steps of the test method based on the digital-physical fusion test system as described above.

[0039] The present invention also provides a technical solution for a computer device: a computer device, including a processor, the processor is used to execute a computer program to implement the steps of the digital-physical fusion test method as described above. Description of the Drawings

[0040] Figure 1 It is a flowchart of test language parsing in an embodiment of the digital-physical fusion test method of the present invention;

[0041] Figure 2 It is a schematic diagram of the working process of the lexical analyzer in an embodiment of the digital-physical fusion test method of the present invention;

[0042] Figure 3 It is a diagram for describing the Thompson algorithm rules of the empty expression in an embodiment of the digital-physical fusion test method of the present invention;

[0043] Figure 4 It is a description diagram of the Thompson algorithm rule for the symbol a in the input alphabet in the embodiment of the digital-physical fusion test method of the present invention;

[0044] Figure 5 It is a description diagram of the Thompson algorithm rule for the merged expression in the embodiment of the digital-physical fusion test method of the present invention;

[0045] Figure 6 It is a description diagram of the Thompson algorithm rule for the concatenated expression in the embodiment of the digital-physical fusion test method of the present invention;

[0046] Figure 7 It is a description diagram of the Thompson algorithm rule for the Kleene star expression in the embodiment of the digital-physical fusion test method of the present invention;

[0047] Figure 8 It is a schematic diagram of syntactic analysis in the embodiment of the digital-physical fusion test method of the present invention;

[0048] Figure 9 It is a syntactic analysis algorithm diagram in the embodiment of the digital-physical fusion test method of the present invention;

[0049] Figure 10 It is an abstract syntax tree obtained through syntactic analysis in the embodiment of the digital-physical fusion test method of the present invention;

[0050] Figure 11 It is an architecture diagram of the digital-physical fusion test system in the embodiment of the digital-physical fusion test method of the present invention. Specific implementation manner

[0051] The present invention writes a test script for testing by using a test language applicable to digital-physical fusion testing, and completes digital-physical fusion testing based on the test script. The execution objects of the simulation debugging instructions of the test language for digital-physical fusion testing are all subsystems of the digital-physical fusion test system, rather than components of a specific device under test (such as the engine of an automobile). By shielding the heterogeneity of the underlying devices, the generality of digital-physical fusion testing is improved. The present invention solves the technical problem that digital-physical fusion testing in the prior art is only applicable to specific fields and has low generality.

[0052] Embodiment of the test method based on the digital-physical fusion test system:

[0053] A test method based on a digital-physical fusion test system, the method comprising:

[0054] S1. Obtain a test script written in advance using a digital-physical fusion high-order test language according to test requirements;

[0055] The digital - physical integration high - order test language includes simulation debugging instructions for controlling each subsystem and the DUT (Device Under Test) of the digital - physical integration test system to complete the test. The simulation debugging instructions include an execution part and a function part; the function part represents the function implemented by the simulation debugging instruction, and the execution part represents the execution object of the simulation debugging instruction; the execution object is each subsystem or the DUT.

[0056] The digital - physical integration test system of this embodiment is as Figure 11 shown. The test design scenario server writes test scripts using the digital - physical integration high - order test language according to test requirements. The digital - physical integration automated test engine obtains the test scripts from the test design scenario server, and then parses and executes the test scripts. The multidisciplinary joint simulation server receives the instructions from the automated test engine and performs simulation using different types of digital models; the simulation results are sent to the sensor simulation server, which simulates the sensor data of the unmanned equipment to provide multi - source information input for the test scenario; then, the hardware - in - the - loop or the unmanned equipment is operated and controlled to further provide feedback to the digital simulation model; the simulation subscription server is used to receive and obtain simulation test data and configuration information in real - time to achieve data synchronization and real - time information distribution during the simulation process. The evaluation server processes and evaluates the data results generated during the simulation and physical test processes to generate the performance indicators and analysis results of the equipment.

[0057] In this embodiment, the digital - physical integration high - order test language further includes an engine waiting time instruction, a send information instruction, an assertion instruction, and a script end instruction. Among them, the engine waiting time instruction is used to obtain the engine waiting time; the send information instruction is used to send information; the assertion instruction is used to verify whether the logic of the test script is correct at a specific point; the script end instruction is used to end the currently executing test script.

[0058] Specifically, in this embodiment, the digital - physical integration high - order test language includes:

[0059] simu_get_step() defines an instruction to obtain the current simulation cycle, which returns the current simulation cycle.

[0060] simu_get_port_value({model='m1' port='p1'}) defines an instruction to obtain the port value. The input m1 is the model name, p1 is the port name, and it returns the value of the current model port.

[0061] simu_set_port_value({model='m1' port='p1' value='v'}) provides an instruction to set the port value. The input m1 is the model name, p1 is the port name, and v is the value to be set. This instruction has no return value.

[0062] simu_sleep(5) defines the behavior simulation wait instruction, and the passed parameter is an integer value in seconds.

[0063] simu_get_current_time() defines the instruction to obtain the current simulation time, which directly returns the current simulation time without passing any parameters.

[0064] simu_get_actually_time() defines the instruction to obtain the current actual time, which returns the current actual time.

[0065] simu_start() defines the instruction to start the current simulation test, thus starting the simulation test.

[0066] simu_stop() defines the instruction to stop the current simulation test, which is used to stop the current simulation test.

[0067] simu_pause() defines the instruction to pause the current simulation test, which is used to pause the ongoing simulation test.

[0068] simu_resume() defines the instruction to continue the current simulation test, which is used to continue running the currently stopped simulation test.

[0069] simu_is_running() defines the instruction to judge the running state of the simulation test, which is used to judge whether the device is in simulation running, and it returns a boolean value.

[0070] assess_params_init("config_file_address\assess_conf.json") is the instruction to configure the evaluation server, which initializes the parameters of the evaluation module.

[0071] assess_result_plot() is the command to adjust the evaluation result. It adjusts the controller parameters according to the evaluation result and writes them into the configuration file for the next traversal test.

[0072] assess_start() is the instruction to start the evaluation server, which reads the evaluation configuration (index system, weight, algorithm, etc.) and starts the evaluation server.

[0073] assess_stop() is the instruction to stop the evaluation server, which displays the evaluation result and reads the evaluation result database.

[0074] assess_result_plot() is the command to adjust the evaluation result. It adjusts the controller parameters according to the evaluation result and writes them into the configuration file for the next traversal test.

[0075] The instruction controller_params_init("ile_address\controller_conf.json") initializes the commands for the device control server and reads the initial parameter configuration of the controller from the specified address or file.

[0076] The instruction controller_start() is the start command for the device controller to start the controller of the device under test.

[0077] The instruction controller_params_update() is the parameter update command for the controller of the unmanned equipment under test to update the controller parameters of the autonomous unmanned equipment under test.

[0078] The instruction sensor_params_init("config_file_address\sensor_conf.json") is the initialization instruction for the sensor simulation server to read the initial configuration of the sensor simulation server from the specified address or file.

[0079] The instruction sensor_start() is the start command for the sensor simulation server to start the sensor, read the initial configuration of the sensor, and establish a TCP connection with the simulator.

[0080] The instruction sensor_send_command("set_obstacle",{position={ox=px+d*cos(theta),oy=py+d*sin(theta)}}) is the command to set obstacle parameters for the sensor simulation server, calculate the obstacle position, store it in the sensor configuration data table, trigger the sensor to read the sensor configuration table through TCP communication, and display the obstacle.

[0081] The above are all simulation debugging instructions. Among them, simu, assess, controller, and sensor are all execution parts, and the corresponding execution objects are the simulator (including multiple pre-established digital models inside the simulator, corresponding to Figure 11 the multidisciplinary joint simulation server therein), the assessment server, the controller of the unmanned equipment under test, and the sensor simulation server, and the rest are functional parts.

[0082] The instruction engine_sleep(5) is the engine waiting time instruction that defines the instruction to obtain the engine waiting time.

[0083] The instruction engine_send_message('msg') is the instruction to send information and is used to send information. It is sent by the digital-physical fusion automated test engine to the simulation engine (i.e.,Figure 11 in the multidisciplinary joint simulation server).

[0084] The engine_assert(true) is an assertion instruction used to verify whether the logic of the program is correct at a specific point.

[0085] The engine_stop() is a script end instruction used to immediately end the execution of the current script.

[0086] In other embodiments, the digital - physical fusion high - order test language may include only one or a combination of two or a combination of three of the engine waiting time instruction, the sending information instruction, the assertion instruction, and the script end instruction. S2. Parse the test script to obtain an executable test atomic sequence;

[0087] Specifically, as Figure 1 shown, S2 includes:

[0088] S21. Perform lexical analysis on the test script to obtain a sequence of lexical units and their types of the test script.

[0089] As Figure 2 shown, in this embodiment, the main task of lexical analysis is to read the input characters of the source program, combine them into lexemes, and generate a series of lexical units as output for each lexeme in the source program. These lexical units are the basis for syntax analysis. Specifically, it includes the following steps:

[0090] 211) Use the Thompson algorithm to convert the regular expression describing the lexical rules into a non - deterministic finite automaton. The lexical rules of the test language are shown in Table 1. The Thompson algorithm works by recursively splitting an expression into its constituent sub - expressions and then using a set of rules to construct a non - deterministic finite automaton from these sub - expressions.

[0091] Specifically, the rules used include:

[0092] If it is the empty expression ε, it is converted to Figure 3 ;

[0093] If it is a symbol a in the input alphabet, it is converted to Figure 4 ;

[0094] If it is the union expression s|t, it is converted to Figure 5 , the state q reaches the initial state of N(s) or N(t) through ε. Their final states are the intermediate states of the entire non - deterministic finite automaton and are merged into the final state of the non - deterministic finite automaton through two ε - transitions;

[0095] If it is the concatenation expression st, it is converted to Figure 6, the initial state of N(s) is the initial state of the entire non-deterministic finite automaton, the final state of N(s) becomes the initial state of N(t), and the final state of N(t) is the final state of the entire NFA;

[0096] If it is a Kleene star expression s*, it is converted to Figure 7 .

[0097] Among them, an ε-transition connects the initial state and the final state of the non-deterministic finite automaton. In the middle is the sub-non-deterministic finite automaton N(s). Another ε-transition connects the internal final state and the internal initial state of N(s), allowing the expression s to be repeated according to the star operator; if it is an expression (s) within parentheses, it is converted to N(s) itself.

[0098] Table 1 Lexical Rule Table

[0099]

[0100] In other embodiments, the lexical rules may include only one or a combination of two or a combination of three of the time condition, the position condition, the upper speed limit condition, and the lower speed limit condition.

[0101] Use the subset construction algorithm to convert the non-deterministic finite automaton into a deterministic finite automaton. The subset construction algorithm first initializes the set Q as an empty set. Secondly, the state q0 of the non-deterministic finite automaton is put into the set Q. Now q is the initial state of the deterministic finite automaton M. Then for each state q in the set Q, this new state is added, and δ(q,a) = Up∈qδ(q,a) is added to δ, where the δ on the right-hand side is the transition function of the non-deterministic finite automaton M2. Finally, repeat the previous step until no new state needs to be added to Q. If a new state that needs to be added to Q is found, continue to repeat the previous step. If no new state needs to be added, the process terminates. All states in the set Q that contain the accepting states of M2 are the accepting states of M.

[0102] Use the Hopcroft minimization algorithm to compress the deterministic finite automaton. The Hopcroft minimization algorithm first divides all the states of the deterministic finite automaton into two parts: the accepting states A and the non-accepting states N. When there are still new states that can be refined into smaller subsets, for each subset s in the current partition set, call the split(s) function. For each input character, if the state set s can be split into multiple subsets, then perform the split operation.

[0103] 212) Read the source code file of the test program and put the character stream into the input buffer. The preprocessing subroutine filters out invalid characters such as spaces, line breaks, and carriage returns, and puts the processed string into the scan buffer.

[0104] 213) Characters are extracted from the scan buffer as input. Based on the current state and the input character, the state machine will transition to the next state. The state transition corresponds to the partial or complete matching logic of the regular expression. Some states in the state machine are marked as "accept states", indicating that a complete lexical unit has been recognized. When the state machine enters an accept state, it means that the current input sequence matches the regular expression of a lexical unit.

[0105] 214) When the state machine reaches an accept state, the lexical analyzer records the currently matched character sequence and its corresponding lexical unit type (such as identifier, keyword, operator, delimiter, etc.), and outputs it as a lexical unit. Subsequently, the state machine is reset to an appropriate initial state, or directly transitions to the next possible matching start state according to the rules, to prepare for processing the next lexical unit.

[0106] If at any time the input character cannot trigger a valid state transition, it indicates that a lexical error has occurred. At this time, the lexical analyzer reports the error and decides how to handle it, such as skipping the error character and continuing the analysis or stopping the analysis.

[0107] This process continues until the scan buffer is empty and all characters have been processed. Finally, the generated sequence of lexical units is output as input for the subsequent syntax analysis phase.

[0108] S22. Generate an abstract syntax tree based on the lexical unit and its type.

[0109] Syntax analysis is a process of combining a sequence of words into various grammar phrases and constructing an abstract syntax tree based on lexical analysis. An algorithm that improves on the standard LR(1) or LALR(1) parsing algorithm is used to complete the syntax analysis. It can generate a top-down parsing order during the bottom-up parsing process, and can maintain the intuitiveness of the top-down parsing order without sacrificing the expressive power and efficiency of the bottom-up parser. The parsing of the code is achieved by continuously performing shift and reduce operations to form an abstract syntax tree. As Figure 8 shown, the specific steps are as follows:

[0110] 221) Dynamically create a hash table that quickly maps strings of grammar symbols to their corresponding encoded values. If memory allocation fails, the execution ends; otherwise, use the name strings of the symbols in the terminal and non-terminal tables of the grammar symbols that have been statically initialized in the lexical analyzer as the input to the hash function to obtain the subscript index of the storage location of the grammar symbol in the hash table. Then, store the encoded value of this terminal or non-terminal in the storage unit of the hash table according to this index.

[0111] 222) Read the grammar set file stored in a specific format in advance, and parse all symbols in this grammar file; then use the string of grammar symbols as the input of the hash function in the first step to quickly obtain the encoded value of the grammar symbol string, and perform the encoding conversion of the grammar production set. Load all the productions after the encoding conversion of the entire grammar set into memory. If the loading fails, jump to the error handling phase; otherwise, execute the next step. Among them, the encoding conversion and loading are carried out simultaneously.

[0112] 223) Read the FOLLOW set file stored in a specific format, and parse all terminals and non-terminals in this file. Use each non-terminal and each terminal element in the FOLLOW set of this non-terminal as the input of the hash function in the first step to quickly obtain their encoded values. Perform the encoding conversion on the FOLLOW set of non-terminals. Then load all the FOLLOW sets of non-terminals after the encoding conversion into memory. If the loading fails, jump to the error handling phase; otherwise, continue to execute the next step.

[0113] 224) Sort the FOLLOW sets of non-terminals in the order of the encoded value sizes of the non-terminals in the FOLLOW set. Similarly, sort the elements in the FOLLOW set of each non-terminal in the order of the encoded value sizes of the terminals. Make the FOLLOW set of each non-terminal and each element in the set be ordered.

[0114] 225) Create a mapping index table from non-terminals to their FOLLOW sets. According to the loaded grammar production set, FOLLOW set, and encoded symbols, start to construct the ACTION table and GOTO table. Use the rules of the LR analysis method to traverse the production set, and determine the actions (shift, reduce, accept, error) in the ACTION table and the transfer states in the GOTO table for each state and input symbol. If any inconsistency or error is found during the construction process, the corresponding error handling needs to be executed.

[0115] 226) The parsing algorithm uses a standard LR(1) or LALR(1) parsing table, that is, an ACTION table and a GOTO table. First, the starting state and an empty rule list are pushed onto the stack for initialization. Then, an end symbol is appended to the input string to indicate the end of the input. Finally, the following steps are repeated until acceptance or error: Obtain the current state from the top of the stack and look it up in the ACTION table using the current state and symbol. If no matching operation is found in the parsing table, the parsing fails and an error is reported; if it is a shift operation, look up the jump state in the GOTO table according to the current state and the current input symbol, push the new state and a new empty rule list onto the stack, and move the input pointer forward to the next input symbol; if it is a reduce operation, first determine the production rule to be reduced, pop the stack elements equal to the number of right-side symbols of the reduction. For each popped stack element, concatenate its rule list to the front of the rule list. Then pop the top element of the stack again to obtain the state and rule list, retain the information of the reduction rule and the previous state information on the stack, look up the next state according to the GOTO table, and push the next state and a new empty rule list as elements onto the stack; if it is an accept operation, output the rule list at the top of the stack as the parsing result and end the parsing. At this time, the rule list of the top element of the stack is the top-down parsing order for generating the input string from the start symbol. The parsing algorithm is as Figure 9 shown.

[0116] Compared with the standard LR(1) or LALR(1) algorithm, the improved LR(1) or LALR(1) algorithm of this embodiment improves the reduction operation. In the traditional LR(1) or LALR(1) algorithm, when a rule is reduced, the rule number is directly output. However, in the improved LR(1) or LALR(1) algorithm, when a rule is reduced, instead of immediately outputting the rule number, the rule lists related to this reduction are concatenated, and the newly formed list is placed in front of the rule list currently being constructed. In addition, the reduced rule itself is also placed at the head of the result list. The purpose of this is to ensure that the final obtained rule list reflects the top-down parsing order, that is, the preorder traversal order of the parsing tree nodes.

[0117] 227) Create a mapping table from terminals and non-terminals to productions, record the occurrence positions of these symbols in the production set and their right-side position indices, and initialize the index values of the relevant table entries in the lexical analyzer.

[0118] 228) Execute the parser to construct the abstract syntax tree. During the execution of the parser, based on the loaded set of grammar production rules, FOLLOW set, ACTION table, and GOTO table, as well as the input source code, gradually analyze the syntax structure of the source code. For the identified syntax structures, create corresponding syntax tree nodes. Connect the created syntax tree nodes according to their hierarchical relationships in the source code to form a complete abstract syntax tree. After construction, the abstract syntax tree can be used for subsequent semantic analysis and code generation. Dynamically destroy the hash table created at the beginning and release the storage space it occupies. Clean up and release the memory resources occupied by the ACTION table and GOTO table, and end the execution.

[0119] S23. Supplement semantic information to the abstract syntax tree obtained in S22 through semantic analysis to obtain an abstract syntax tree with semantic information, and convert the abstract syntax tree with semantic information into the test atom sequence.

[0120] Semantic analysis calculates the semantic information of the abstract syntax tree through the Kennedy-Warren tree traversal evaluation algorithm (Kennedy-Warren Algorithm), ensures the semantic correctness of the source program, and prepares for generating test atom sequences that can be executed by the test engine. The specific steps are as follows:

[0121] 231) Traverse the abstract syntax tree, collect identifier information such as variables, functions, types, etc., and construct a symbol table to facilitate quick access to information such as the name, type, scope, and memory address of identifiers.

[0122] 232) Conduct semantic checks, including type checking, scope checking, and other semantic rule checks. Type checking ensures type compatibility between expressions, variable assignments, function parameters, etc.; scope checking ensures that variables are declared before use and within the correct scope; other checks are used to detect errors such as unused or uninitialized variables and illegal operations.

[0123] 233) Define semantic functions for each node of the abstract syntax tree to calculate the semantic attributes of the nodes, such as the value of an expression, the type of a variable, etc. Use the Kennedy-Warren tree traversal algorithm to calculate the node attribute values based on these functions. Multiple traversals may involve different types of attributes, thus preparing for subsequent operations.

[0124] 234) If an error is found, report it to the user in a timely manner, including the specific location (such as file name, line number), error type (such as type mismatch, scope error), and correction suggestions, to help the user quickly locate and fix the error, improving development efficiency and code quality.

[0125] When processing the abstract syntax tree after semantic completion, the system first traverses the tree structure systematically, identifies the nodes related to the test atomic tasks, parses their attributes and content, and extracts the key information (such as task identifiers, input parameters, expected results, test steps). Then, based on this information, an internal data structure is constructed to describe in detail the logical sequence, execution conditions, and verification criteria of each test task. Finally, these structures are converted into a sequence of test atoms executable by the test engine.

[0126] The following takes a part of the statements as an example to further illustrate the parsing method of the present invention. Taking the following statement as an example:

[0127]

[0128] First, read this test statement and put it into the buffer.

[0129] The preprocessing subroutine removes invalid characters such as spaces and line breaks, and places the processed string into the scan buffer. In this embodiment, the string processed by the preprocessing subroutine is:

[0130] "engine_assert((tonumber(simu_get_port_value({model='FlCiPuCoUniAt',port='Output LoopSelfManage'}))==1),'assertion statement 1');"

[0131] Take a character from the scan buffer as the input. According to the current state and the input character, the state machine transfers to the next state. Among them, each edge, that is, the state transition, corresponds to a part or complete matching logic of the regular expression. Some states in the state machine are marked as "accepting states", indicating that a complete lexical unit has been recognized. When the state machine enters such a state, it means that the current input sequence matches the regular expression of a lexical unit.

[0132] Whenever the state machine reaches an accepting state, record the currently matched character sequence and its corresponding lexical unit type, such as identifier, keyword, operator, delimiter, etc., and output it as a lexical unit. At the same time, the state machine is reset to an appropriate initial state or directly transfers to the next possible matching start state according to the rules, ready to process the next lexical unit.

[0133] If there is no legal transition at any time, that is, the input character cannot make the state machine enter a valid new state, it indicates that a lexical error has occurred. At this time, the lexical analyzer needs to report the error and decide how to handle it, such as skipping the error character and continuing the analysis, or stopping the analysis.

[0134] The lexical analyzer repeats the process of character input, state transition, and token generation until the scan buffer is empty and all characters have been processed.

[0135] Finally, the generated token sequence is used as the output, providing input for the subsequent syntax analysis phase. In this embodiment, the generated token sequence is:

[0136] <engine_assert, identifier>

[0137] <(, action parameter start symbol>

[0138] <(, action parameter start symbol>

[0139] <tonumber, identifier>

[0140] <(, action parameter start symbol>

[0141] <simu_get_port_value, identifier>

[0142] <(, action parameter start symbol>

[0143] <{, delimiter>

[0144] <model, identifier>

[0145] <=, operator>

[0146] <‘FlCiPuCoUniAt’, string>

[0147] <,, action parameter separator>

[0148] <port, identifier>

[0149] <=, operator>

[0150] <‘Output_LoopSelfManage’, string>

[0151] <}, delimiter>

[0152] <), action parameter end symbol>

[0153] <), action parameter end symbol>

[0154] <==, operator>

[0155] <1, decimal integer>

[0156] <), action parameter end symbol>

[0157] <,, action parameter separator>

[0158] <‘Assertion statement 1’, string>

[0159] <), end of action parameter>

[0160] <;, end symbol>

[0161] After lexical analysis, the test statements in this embodiment are subjected to syntax analysis. Figure 10 The abstract syntax tree obtained through syntax analysis of this embodiment is shown.

[0162] Finally, after semantic analysis of the code in this embodiment, these structures are converted into a test atom sequence executable by the test engine. Through semantic analysis of the code in this embodiment, it can be known that the meaning of this code is: call the engine_assert function to check an assertion. The content of the assertion is to check whether the value of the Output_LoopSelfManage port of the FlCiPuCoUniAt module is 1. If not, return an error message: 'Assertion statement 1'.

[0163] Through semantic analysis of the code in this embodiment, it can be known that there is no semantic error in this code, and the single test atom obtained is as follows:

[0164] Precondition:

[0165] The simulation model FlCiPuCoUniAt has been started and is in a running state.

[0166] The port Output_LoopSelfManage is ready to provide data.

[0167] Action to be performed:

[0168] Read the value from the Output_LoopSelfManage port of the simulation model FlCiPuCoUniAt.

[0169] Convert the read value to a numeric type.

[0170] Check whether the converted value is equal to 1.

[0171] Postcondition / Expected result:

[0172] If the value is equal to 1, the assertion passes, and the subsequent test steps are continued.

[0173] If the value is not equal to 1, throw an error with the message 'Assertion statement 1', stop the current test process, and record the failure information.

[0174] S3. Execute the test atom sequence to complete the test to meet the test requirements.

[0175] Taking the unmanned boat test as an example, the present invention will be further introduced. The assumed test plan is as follows:

[0176] Simulate 10 times, and set the initial speed of the unmanned boat progressively each time. After 10 s of simulation, read the position of the unmanned boat. Set the obstacle companion test boat online according to the command, and the position is 20 meters directly in front of the unmanned boat. Set the position according to the obtained position of the test boat, aiming to test the obstacle avoidance performance of the unmanned boat, including the perception ability and the path replanning ability.

[0177] During the simulation process, the evaluation module calculates relevant indicators, including: stable tracking time, total mission time, target recognition accuracy, trajectory similarity, target positioning accuracy, path planning time, total navigation range, count of less than the safe distance, etc.;

[0178] After the simulation ends, draw the evaluation result graph. Include the line graph of relevant indicators under different initial speeds; according to the evaluation results, adjust the controller parameters, generate the controller configuration file, and repeat the call of this test case.

[0179] The specific process is as follows:

[0180] 1) Set the number of simulations and perform initial parameter configuration. Convert the test scenario into parameters that can be read by the sensor and write them into the json configuration file. Read the configuration from the json configuration file and send it to the visual simulation, evaluation module, and controller. Each module performs initial parameter configuration and stores the configuration parameters in their respective configuration data tables as needed. Set the initial speed of the unmanned boat for a single test according to the test requirements. Modify the speed according to the loop variable. Send the initial speed to the unmanned boat controller. Compared with the traditional test method, the digital-physical fusion test method provided by the present invention allows the configuration of test conditions at the beginning of the test, making the task reliability test of the device under test in different test scenarios more credible.

[0181] 2) Start the simulation. Start the visual simulation, evaluation module, and simulator in sequence. By default, the controller has been started automatically. First, obtain the connection simulation platform information through the command and create a connection. Then, obtain the current subscription server address through the simulation platform connection and create a subscription server connection to obtain and save the data during the simulation process in the cache in real time; then obtain the initial value from the configuration information of the currently running sequence in the command, and send the initial value to the simulation platform through the simulation platform HTTP interface to set the model initial value. Compared with the previous test language method, the present invention relies on the B / S architecture, making the execution of the test not limited to the offline real scenario. And separating the simulation module from the test language method module enhances the versatility and portability of this method.

[0182] 3) Determine the trigger condition of the online test command. Call the function provided by the simulator to read the model parameters, and read the simulation time. If the simulation time reaches 10 s, obtain the current position of the unmanned boat through visual simulation. Next, send an online command: set the position of the obstacles in the visual simulation. Calculate the obstacle position, store it in the visual simulation configuration data table, trigger the visual simulation to read the visual simulation configuration table through TCP communication, and display the obstacles. Read the model variables in the visual simulation. If the task completion condition is reached, stop the simulation and stop the evaluation. Repeat the loop 10 times to implement 10 tests under different initial speeds of the unmanned boat. The high-order test language method of virtual-real fusion provided by the present invention performs uniform processing on the interfaces of real devices and simulation devices, so that this method shields the heterogeneity of the test devices, and testers only need to focus on the execution of the test process.

[0183] 4) Display the evaluation results. Read the evaluation result database, draw a line chart of relevant indicators under different initial speeds according to the evaluation results, and provide a test report for testers. The report includes the data exchange and status changes of relevant devices during the test. Adjust the controller parameters according to the evaluation results. Testers can configure the controller parameters according to the evaluation report and write them into the configuration file to optimize the next traversal test.

[0184] The above test process is converted into a test script written in the high-order test language of digital-physical fusion as follows:

[0185] ① Initial parameter configuration. Read the configuration from the json configuration file and send it to the visual simulation (i.e., the sensor simulation server), the evaluation module (i.e., the evaluation server), and the controller (i.e., the controller of the unmanned equipment under test). Each module performs initial parameter configuration and stores the configuration parameters in their respective configuration data tables as needed.

[0186] vrsim_params_init('config_file_address\\vrsim_conf.json')

[0187] assess_params_init('config_file_address\\assess_conf.json')

[0188] controller_params_init('config_file_address\\controller_conf.json')

[0189] Among them, vrsim, assess, and controller are the execution parts corresponding to the visual simulation, the evaluation module, and the controller respectively.

[0190] It should be noted that vrsim_params_init here has the same meaning as sensor_params_init mentioned above. Similarly, vrsim_start() and others in the following all have the same meaning as the corresponding ones.

[0191] ② Set the initial speed of the unmanned boat for a single test. Modify the speed according to the loop variable. Send the initial speed v to the vessel_speed port of the dynamicsModel module of the unmanned boat controller.

[0192] v0 = 10;

[0193] vessel_speed = v0 + 2 * i

[0194] simu_set_port_value({model = 'dynamicsModel', port ='vessel_speed', value =

[0195] vessel_speed})

[0196] 3) Start the simulation. Start the visual simulation, evaluation module, and simulator (i.e., the multi-disciplinary joint simulation server) in sequence. The default controller has been started automatically.

[0197] vrsim_start()

[0198] assess_start()

[0199] simu_start()

[0200] controller_start()

[0201] Among them, the functions of the vrsim_start() function include reading the initial configuration of the visual simulation and establishing a TCP connection with the simulator.

[0202] The functions of the simu_start() function include establishing a WebSocket connection with the simulation platform, creating a subscription server connection, and configuring the initial values of the simulation model.

[0203] The function of the Assess_start() function is to start the assessment. The engine calls the existing functions of the evaluation module, including reading the evaluation configuration (such as the index system, weights, algorithms, etc.), starting the evaluation process, reading the deduction data table, calculating the evaluation indicators, and storing the indicators in the evaluation result data table.

[0204] The function of controller_start() is to start the controller according to the configuration parameters in ①.

[0205] ④ Determine the triggering condition of the online test command. Call the function simu_get_port_value provided by the simulator to read the simulation time from the out_time port of the time module. If the simulation time reaches 10s, obtain the current position and heading angle of the unmanned boat through the vername port of the visual simulation, and then send an online command.

[0206] local out_time = simu_get_port_value({model = 'time', port = 'out_time'})

[0207] while(out_time < 10)

[0208] do

[0209] simu_sleep(10)

[0210] out_time = simu_get_port_value({model = 'time', port = 'out_time'})

[0211] end

[0212] local px = vrsim_get_port_value({varname ='vessel_position_x'})

[0213] local py = vrsim_get_port_value({varname ='vessel_position_y'})

[0214] local theta = vrsim_get_port_value({varname ='vessel_theta'})

[0215] ⑤ Send a command to set obstacles to the visual simulation and set the position of the visual simulation obstacles. Calculate the obstacle position.

[0216] local d = 20;

[0217] vrsim_send_command("set_obstacle", {position = {ox = px + d * cos(theta), oy = py + d * sin(theta)}})

[0218] 6) Determine the task completion condition: Obtain the coordinates of the co-tested unmanned boat from supportvesselX and supportvesselY in the visual simulation, and obtain the position of the tested unmanned boat from vessel_position_x and vessel_position_y in the visual simulation. Determine whether the test is over based on the positions of the two and the test area. If both boats have left the test area, the test ends, and call simu_stop() to stop the simulation, assess_stop() to stop the assessment, and controller_stop() to stop the control.

[0219] while(true)

[0220] do

[0221] local supportVessel_x = vrsim_get_port_value({varname='supportvesselX'})

[0222] local supportVessel_y = vrsim_get_port_value({varname='supportvesselY'})

[0223] local testVessel_x = vrsim_get_port_value({varname='vessel_position_x'})

[0224] local testVessel_y = vrsim_get_port_value({varname='vessel_position_y'})

[0225] local istestVesselIn = testVessel_x <= bottomRight.x and testVessel_x >= topleft.x and testVessel_y >= topleft.y and testVessel_y <= bottomRight.y

[0226] local issupVesselIn = supportVessel_x <= bottomRight.x and supportVessel_x >= topleft.x and supportVessel_y >= topleft.y and supportVessel_y <= bottomRight.y

[0227] if (not (istestVesselIn) && not (issupVesselIn)) then

[0228] break

[0229] end

[0230] end

[0231] simu_stop()

[0232] assess_stop()

[0233] controller_stop()

[0234] Example of digital - physical fusion test system:

[0235] A digital - physical fusion test system includes a test engine and a scenario server. The scenario server is used to write test scripts in a digital - physical fusion high - level test language according to test requirements. The test engine is used to obtain the test scripts from the scenario server and execute computer programs to implement the steps of the above - mentioned test method based on the digital - physical fusion test system. Specifically, the test method based on the digital - physical fusion test system has been introduced in sufficient detail in the above - mentioned embodiments of the test method based on the digital - physical fusion test system, and will not be repeated here.

[0236] Example of computer device:

[0237] A computer device includes a processor, and the processor is used to execute computer programs to implement the steps of the above - mentioned test method based on the digital - physical fusion test system. Specifically, the test method based on the digital - physical fusion test system has been introduced in sufficient detail in the above - mentioned embodiments of the test method based on the digital - physical fusion test system, and will not be repeated here.

[0238] The present invention has the following characteristics:

[0239] By shielding the heterogeneity of underlying devices, the generality of the test language is improved, making the language of the present invention more widely applicable. By introducing digital - physical fusion simulation test technology, digital - physical fusion tests are made more economical and complex. Traditional test languages rely on physical real - world tests, however, most complex situations cannot be tested in the physical world. The digital - physical fusion - based simulation test of the present invention enables many complex, difficult - to - implement, and economically demanding tests to be carried out in simulation tests through the simulation of the real test environment, thus making the test results more reliable.

[0240] The syntax analysis and lexical analysis methods mentioned in the present invention compared with previous analysis methods:

[0241] When performing lexical analysis on the test language, according to the lexical rules of the test language, the Thompson algorithm, subset construction algorithm, and Hopcroft minimization algorithm are used to obtain a deterministic finite automaton, and then a series of scanning and matching operations are performed to perform lexical analysis on the source program; in the syntax analysis stage, an algorithm that improves the standard LR(1) and LALR(1) parsing algorithms is used to complete the syntax analysis; in the semantic analysis stage, the Kennedy-Warren tree traversal algorithm is used to calculate the attribute values of the abstract syntax tree.

[0242] Performing lexical analysis, syntax analysis, and semantic analysis on the test language can ensure that the statements of the test program written in the test language have correct structures, meanings, and logical relationships, ensuring the accuracy, reliability, and ease of use of the test language, thereby improving the efficiency and quality of the testing work.

[0243] The test language parsing method converts the test program into a sequence of test atoms that can be understood and executed by the test engine for subsequent test tasks and operations.

[0244] The test language parsing method can save testing time and costs and can achieve a more efficient testing process.

[0245] Finally, it should be noted that the above are only the preferred embodiments of the present invention and are not used to limit the present invention. Although the present invention has been described in detail with reference to the foregoing embodiments, for those skilled in the art, they can still make modifications to the technical solutions described in the foregoing embodiments without creative efforts, or perform equivalent replacements on some of the technical features. Any modifications, equivalent replacements, improvements, etc. made within the spirit and principle of the present invention shall be included within the protection scope of the present invention.

Claims

1. A testing method based on a digital-real fusion testing system, characterized in that: The method includes: S1. Obtain a test script written in advance using a high-level test language that integrates data and reality according to test requirements; The digital-real fusion high-level test language includes simulation debugging instructions for controlling each subsystem in the digital-real fusion test system and the object under test of the digital-real fusion test system to complete the test, and the simulation debugging instructions include an execution part and a function part; the function part represents the function implemented by the simulation debugging instruction, and the execution part represents the execution object of the simulation debugging instruction; the execution object is each subsystem or the object under test; S2, parsing the test script to obtain an executable test atomic sequence; S3. Execute the test atomic sequence to complete the test to meet the test requirements.

2. The test method based on the digital-real fusion test system according to claim 1 is characterized in that: The digital-real fusion high-level test language also includes one or a combination of two or a combination of three or four of an engine waiting time instruction, a send information instruction, an assertion instruction, and a script end instruction; The engine waiting time instruction is used to obtain the engine waiting time; the sending information instruction is used to send information; the assertion instruction is used to verify whether the logic of the test script at a specific point is correct; the script end instruction is used to end the test script currently being executed.

3. The test method based on the digital-real fusion test system according to claim 1 is characterized in that: The functions implemented by the functional unit are to obtain the simulation cycle, obtain the port value, set the port value, set the behavior simulation waiting time, obtain the previous simulation time, obtain the current real time, start the current simulation test, stop the current simulation test, pause the current simulation test, continue the current simulation test, initial parameter configuration, parameter update instructions or judge the simulation running status.

4. The test method based on the digital-real fusion test system according to claim 1, characterized in that S2 include: S21, performing lexical analysis on the test script to obtain a sequence of lexical units and their types of the test script; S22, performing grammatical analysis according to lexical units and their types to generate an abstract syntax tree; S23. Supplementing semantic information to the abstract syntax tree obtained in S22 through semantic analysis to obtain an abstract syntax tree with semantic information, and converting the abstract syntax tree with semantic information into the test atomic sequence.

5. The test method based on the digital-real fusion test system according to claim 4 is characterized in that: S21 includes: S211, preprocessing the test script to remove invalid characters in the test script, and obtaining a regular expression describing the lexical rules of the digital-real fusion high-order test language; S212, converting the regular expression into a non-deterministic automatic finite machine by Thompson algorithm; S213, converting the non-deterministic automatic finite machine into a deterministic automatic finite machine through a subset construction algorithm; S214, compressing the determined automatic finite machine by the Hopcroft minimization algorithm to obtain a sequence of lexical units and their types.

6. The test method based on the digital-real fusion test system according to claim 5 is characterized in that: The digital-real fusion high-level test language lexical rules include one or a combination of two or a combination of three or four of a time condition, a position condition, an upper speed limit condition and a lower speed limit condition; The time condition is used to indicate after a set time length; The position condition is used to indicate after a set displacement length; the upper speed limit condition is used to indicate that the speed is lower than the set speed; and the lower speed limit condition is used to indicate that the speed is higher than the set speed.

7. The test method based on the digital-real fusion test system according to claim 4 is characterized in that: In S22, an improved LR(1) or LALR(1) parsing algorithm is used to perform syntax analysis to obtain an abstract syntax tree; The reduction operation of the improved LR(1) or LALR(1) parsing algorithm includes: first, determining the production rule to be reduced, popping out stack elements equal to the number of right-hand side symbols to be reduced in sequence, connecting the rule lists of all the popped stack elements in the order of popping and connecting them before the rule list being constructed; then popping out the top element of the stack again, obtaining the state and the rule list, retaining the information of the reduction rule and the previous state information in the stack, searching for the next state according to the GOTO table, and pushing the next state and a new empty rule list as elements into the stack.

8. The test method based on the digital-real fusion test system according to claim 4 is characterized in that: The abstract syntax tree with semantic information in S23 is obtained in the following way: S231, traverse the abstract syntax tree to obtain identifier information; S232, performing semantic checking, wherein the semantic checking includes type checking, scope checking, and other semantic rule checking; The type check is used to ensure type compatibility between expressions, variable assignments, and function parameters; the scope check is used to ensure that variables have been declared before use and are in the correct scope; the other semantic rule checks are used to detect unused or uninitialized variables and illegal operation errors; S233: Calculate the semantic attributes of the nodes according to the semantic functions pre-defined for each node of the abstract syntax tree to obtain an abstract syntax tree with semantic information.

9. The test method based on the digital-real fusion test system according to claim 4 is characterized in that: The method of converting the abstract syntax tree with semantic information into the test atomic sequence in S23 is: S234, traverse the abstract syntax tree with semantic information, obtain nodes related to the test atomic task, parse their attributes and contents, and extract key information; S235, constructing a data structure based on the key information; the data structure describes in detail the logical sequence, execution conditions and verification criteria of each test atomic task; S236: Convert the data structure into an executable test atom sequence.

10. The test method based on the digital-real fusion test system according to claim 8 or 9, characterized in that: The Kennedy-Warren tree traversal algorithm is used to traverse the abstract syntax tree.

11. A digital-real fusion testing system, characterized in that: It includes a test engine and a hypothetical server. The hypothetical server is used to write test scripts using a high-level test language for digital-real fusion according to test requirements for acquisition by the test engine. The test engine is used to execute computer programs to implement the steps of the test method based on the digital-real fusion test system as described in any one of claims 1 to 10.

12. A computer device comprising a processor, characterized in that: The processor is used to execute a computer program to implement the steps of the test method based on the digital-real fusion test system as described in any one of claims 1 to 10.

Citation Information

Cited By

  • State machine checking method and device and computer equipment

    CN121303008A

  • Joint simulation data processing system

    CN122285236A

  • Data processing system for co-simulation

    CN122285236B