High-precision data automatic recharge test method and device, terminal and storage medium

Abstract

The invention discloses a high-precision data automatic recharge test method and device, a terminal and a storage medium. The method comprises the following steps: responding to a data playback test request of a test system based on an interface layer, determining a to-be-played-back data file from a plurality of external original record data, and recharging the to-be-played-back data file to a target system; parsing the to-be-played-back data file based on the data parsing layer to obtain parsed data, and putting the parsed data into a data pool; and simulating the running time based on the simulation running time layer, determining target data according to the running time and the timestamp of the analyzed data, and sending the target data to a test system based on the data sending layer, so that the test system performs playback test on the target data one by one. By means of the method, high-precision automatic data recharge testing is achieved, data analysis can be conducted continuously, and data integrity and continuity are guaranteed.

Description

Technical Field

[0001] The embodiments of the present invention relate to the field of computer technology, and in particular to a high-precision data automatic re-injection test method, device, terminal and storage medium. Background Art

[0002] In many complex systems (such as autopilot systems, flight control systems, etc.), it is necessary to accurately collect a variety of sensor data or device status data and accurately replay them in subsequent testing or analysis. This data playback must ensure synchronization with the original data acquisition time, data integrity and accuracy, so that the system can be reliably evaluated and debugged.

[0003] Traditional data playback testing technology usually faces the following challenges:

[0004] Insufficient time accuracy: The time difference between data playback and acquisition can cause errors, especially in systems that require high-precision time synchronization (such as radar data or precision motion control systems).

[0005] Large amount of data: As the amount of sensor data and the frequency of collection continue to increase, the playback test system needs to be able to process massive amounts of data, but traditional systems may have bottlenecks in continuous data analysis.

[0006] In order to solve the shortcomings of existing data playback, it is particularly necessary to propose a universal high-precision data playback test. This design not only supports different data formats, transmission protocols and playback scenarios, but also has high-precision timing and analysis of massive data. Summary of the invention

[0007] The purpose of the embodiments of the present invention is to provide a high-precision data automatic replay test method, device, terminal and storage medium, so as to solve the problems of insufficient accuracy and inability to continuously analyze due to large data volume in traditional data playback test technology.

[0008] To solve the above technical problems, an embodiment of the present invention provides a data playback method, which is applied to a target system, wherein the target system includes a data playback framework, and the data playback framework includes at least: an interface layer, a data parsing layer, a data sending layer and a simulation run time layer; the method includes: based on the interface layer responding to the data playback test request of the test system, determining the data file to be played back from multiple external original recorded data, and re-injecting it into the target system; wherein the data playback request at least includes the playback time; based on the data parsing layer, parsing the data file to be played back to obtain parsed data, and putting the parsed data into a data pool; wherein each of the parsed data includes at least data content and a first timestamp corresponding to the data content; when the number of the parsed data reaches a threshold or all the data files to be played back are parsed, simulating the run time of the target system based on the simulation run time layer, determining the target data according to the run time and the first timestamp, and sending the target data to the test system based on the data sending layer; so that the test system can perform playback tests on the target data one by one according to the run time.

[0009] The embodiment of the present invention also provides a data playback test device, which is applied to a target system, wherein the target system includes a data playback framework, and the data playback framework includes at least: an interface layer, a data parsing layer, a data sending layer and a simulation run time layer; the device includes: a data acquisition module: used to respond to the data playback test request of the test system based on the interface layer, determine the data file to be played back from multiple external original recorded data, and re-inject it into the target system; wherein the data playback request at least includes the playback time; a data parsing module: used to parse the data file to be played back based on the data parsing layer to obtain parsed data, and put the parsed data into a data pool; wherein each of the parsed data includes at least data content and a first timestamp corresponding to the data content; a time simulation module: used to simulate the run time of the target system based on the simulation run time layer after the number of the parsed data reaches a threshold or all the data files to be played back are parsed, and determine the target data according to the run time and the first timestamp; a data sending module: used to send the target data to the test system based on the data sending layer; so that the test system can perform playback tests on the target data one by one according to the run time.

[0010] An embodiment of the present invention also provides a terminal, comprising: at least one processor; and a memory communicatively connected to the at least one processor; wherein the memory stores instructions executable by the at least one processor, and the instructions are executed by the at least one processor so that the at least one processor can execute any of the high-precision data automatic re-injection test methods described above.

[0011] An embodiment of the present invention further provides a computer-readable storage medium storing a computer program, wherein the computer program implements the above-mentioned high-precision data automatic re-injection test method when executed by a processor.

[0012] Compared with the prior art, the target system of the embodiment of the present invention responds to the data playback request from the test system, determines the data to be played back from multiple original records stored locally, further parses the data to be played back, and stores it in the data pool; at the same time, the running time of the system is simulated, and the target data is determined according to the running time and the timestamp in the parsed data, so that the test system can play back the target data one by one. Obviously, the present invention sets the timestamp and simulates the running time for the playback data, and constructs a parsing pool to ensure that the data can be accurately synchronized with the sending time of the original data during playback. In the face of massive data, the stored data can be continuously parsed to ensure data integrity and continuity.

[0013] In addition, the interface layer responds to the data playback test request of the test system, determines the data file to be played back from multiple external original recorded data, and injects it back to the target system, including: the target system extracts the original recorded data, and determines the data to be played back in turn according to the playback time and the second timestamp of each original recorded data; wherein the second timestamp and the first timestamp indicate the same time.

[0014] In addition, the data pool includes at least two independent FIFO buffers, and the size of the data pool is at least half of the total memory size of the terminal running the target system.

[0015] In addition, the parsing of the parsed data obtained from the data file to be replayed and placing the parsed data into the data pool includes: after the parsed data is obtained from the data file to be replayed, the parsed data is written into the first FIFO buffer of the data pool; when the first FIFO buffer is full of data, the parsed data is written into the second FIFO buffer of the data pool; when both the first FIFO buffer and the second FIFO buffer are full, the data parsing is stopped. Theoretically, by setting up a data pool, the parsed data is cached into the data value because the speed of parsing the data will be much faster than sending it. Even in the face of massive data, the data can be continuously parsed to ensure the continuity and consistency of the transmission. BRIEF DESCRIPTION OF THE DRAWINGS

[0016] One or more embodiments are exemplarily described by pictures in the corresponding drawings, and these exemplified descriptions do not constitute limitations on the embodiments. Elements with the same reference numerals in the drawings represent similar elements, and unless otherwise stated, the figures in the drawings do not constitute proportional limitations.

[0017] Figure 1 It is a flowchart of a high-precision data automatic recharging test method provided according to an embodiment of the present invention;

[0018] Figure 2 is another flow chart of a high-precision data automatic recharging test method provided according to an embodiment of the present invention;

[0019] Figure 3 is a schematic diagram of a cache pool structure provided according to an embodiment of the present invention;

[0020] Figure 4 is another flow chart of a high-precision data automatic recharging test method provided according to an embodiment of the present invention;

[0021] Figure 5 is a structural schematic diagram of a data playback test device provided according to an embodiment of the present invention;

[0022] Figure 6 is a schematic diagram of the structure of a terminal provided according to an embodiment of the present invention. DETAILED DESCRIPTION

[0023] To make the purpose, technical scheme and advantages of the embodiments of the present invention clearer, the embodiments of the present invention will be described in detail below in conjunction with the accompanying drawings. However, it will be appreciated by those skilled in the art that in the embodiments of the present invention, many technical details are proposed in order to enable the reader to better understand the present application. However, even without these technical details and various changes and modifications based on the following embodiments, the technical scheme claimed in the present application can be implemented. The division of the following embodiments is for the convenience of description, and should not constitute any limitation on the specific implementation of the present invention. The various embodiments can be combined and referenced with each other without contradiction.

[0024] An embodiment of the present application relates to a high-precision data automatic re-injection test method. The specific process is as follows: Figure 1 As shown, the high-precision data automatic re-injection test method includes the following steps.

[0025] Step S101: responding to a data playback test request and determining a data file to be played back.

[0026] Specifically, the target system responds to the data playback test request of the test system based on the interface layer, determines the data file to be played back from multiple external original recorded data, and injects it back to the target system; wherein the data playback request at least includes the playback time.

[0027] The target system may be a complex control system such as an automatic driving system or a flight control system for testing, and the original recorded data may be control data, sensor data or other device data generated when the above-mentioned complex control system is running.

[0028] Among them, the target system and the test system can be heterogeneous, and the two systems can run on different terminals. Part or all of the above data is collected by the target system through a third-party tool, and is injected back into the target system and stored in the database of the terminal where the target system runs. The target system sends the playback data to the test system through the interface layer and the sending layer. Alternatively, the structure of the test system and the structure of the control system can also be isomorphic. In a homogeneous system, the data transmission module inside the system collects the data through the third-party tool, and transmits the data to be played back through the transmission layer inside the system.

[0029] The data to be replayed is a data file of the above-mentioned complex control system, which includes at least data content and timestamp, and may also include other custom added information. The data file may be data collected by various business modules, and different types of data may have different recording locations and recording methods, or may be a data file saved by other terminals other than the one executing the method.

[0030] The playback test request is issued by the test system, and the test system sends the playback test request through the communication interface. The playback test request at least includes a target playback time, which is determined by an operator of the test system. The playback time specifies the time range of the data to be played back, and multiple data to be played back are extracted according to the timestamp and the playback time sequence.

[0031] The above timestamp is in digital form, in milliseconds, and Unix timestamp is recommended. In local data files, each data file should have a timestamp, which allows the data to be reproduced in the original time sequence during playback. This can accurately restore the data sending status at that time.

[0032] Step S102: parse the playback data file and save the parsed data.

[0033] Specifically, the target system parses the to-be-played back data file based on the data parsing layer to obtain parsed data, and puts the parsed data into a data pool; wherein each parsed data at least includes data content and a first timestamp corresponding to the data content.

[0034] The playback data is processed through a preset data parsing interface, and after the parsing is completed, the parsed data is put into the corresponding data pool. The parsed data should at least include data content, data length and timestamp, and / or other information can be added by customizing.

[0035] After responding to the data playback test request and before parsing the data, a block of memory will be pre-applied for building a data pool, which stores the parsed data. The memory size can be modified and is set to half of the total memory size by default.

[0036] The storage structure of the data pool is a ping-pong buffer based on two independent FIFOs (hereinafter referred to as FIFO buffer or FIFO). When the data starts to be parsed, data will be written to one of the FIFOs. When it is full, it will be written to the other one. At the same time, the full FIFO starts to send data. If both FIFOs are full, parsing will be temporarily stopped, and data parsing will continue when there is an empty FIFO. In theory, the speed of parsing data will be much faster than sending. Therefore, even in the face of massive data, data can be continuously parsed to ensure the continuity and consistency of transmission.

[0037] The memory sizes occupied by the ping-pong buffers of the two independent FIFOs may be the same or different.

[0038] Step S103: Determine target playback data, and send the playback data to the test system for playback testing by the test system.

[0039] Specifically, when the number of parsed data reaches a threshold or the parsing of all data files to be replayed is completed, the running time of the target system is simulated based on the simulation running time layer, the target data is determined according to the running time and the first timestamp, and the target data is sent to the test system based on the data sending layer; the test system replays the target data one by one according to the running time.

[0040] The threshold is related to the memory size occupied by the data pool. If the memory is full, it means that the number of parsed data has reached the threshold. When the data pool stores a certain amount of parsed data or completes all data parsing, data can be sent to the test system.

[0041] The running time of the simulation system is also in digital form and is measured in milliseconds. By simulating the running time of the simulation system and the timestamp of the data, the local data can be reproduced in the original time sequence during playback. The data recording state at that time can be accurately restored by simulating the running time.

[0042] The simulated running time is related to the time slice in the playback request. The start time of the simulated running time is set by the start time specified by the time slice, that is, the start time of the test system operation is determined. When the test playback starts, the timer provided by the operating system is used to trigger once every 1ms, supporting 0.5, 2, 4, and 6 times the speed. After testing (windows 10, centos), for millisecond-level data, the accuracy meets the conditions; or based on the relevant interface, using custom time, the custom time value will be taken every 1ms, and the data at any time in the time slice can be taken for playback testing.

[0043] The target data is determined according to the running time and the timestamp of the parsed data. The running time may correspond to the timestamp of the parsed data, or the timestamp of the playback data may be later than the running time. When any of the above conditions is met, the parsed data can be used as the target data. When the timestamp of the parsed data is earlier than the running time, the running time is dormant for 1ms, that is, the simulation is stopped for 1ms, and the next data is obtained. The timestamp and the simulated running time are compared again to determine the target data.

[0044] For example, a system sent data from 8 to 9 yesterday. If you want to replay the data sent during testing, you can send a test request through the test system and set the start time of the time slice to 8 yesterday; or if you only want to replay the data after 8:30, you can change it to 8:30.

[0045] Among them, when the test system performs playback test on the target data, based on the mechanism of aligning the timestamp and the running time, the data playback process can be paused, sped up and dragged by adjusting the sleep time of the simulated running time.

[0046] The technical solution of this embodiment is to determine the data to be replayed from multiple original records stored locally by the target system in response to the data replay request from the test system, further parse the data to be replayed, and store it in the data pool; at the same time, simulate the running time of the system, determine the target data according to the running time and the timestamp in the parsed data, so that the test system can replay the target data one by one. Obviously, the present invention sets the timestamp and simulates the running time for the replayed data, and constructs a parsing pool to ensure that the data can be accurately synchronized with the sending time of the original data during playback. In the face of massive data, the stored data can be continuously parsed to ensure data integrity and continuity.

[0047] Furthermore, in some embodiments, the target system and the test system are heterogeneous structures; the original recorded data is synthesized from the original data recorded by a third-party tool and a second timestamp; wherein the third-party tool includes at least a flight data recorder or an avionics equipment data acquisition system; the original data includes at least sensor data and a timestamp saved in binary form and / or a character string.

[0048] In this embodiment, the data recording tool should be able to automatically store the received data, such as a flight data recorder, an avionics equipment data acquisition system, etc. The original data at least includes the specific data received, which is saved in binary or character string, and a corresponding timestamp is generated according to the receiving time.

[0049] Furthermore, in some embodiments, the target system and the test system are heterogeneous structures; the original recorded data is synthesized from the original data recorded by a third-party tool and a second timestamp; wherein the target system is an autopilot system or a flight control system; the third-party tool includes at least a flight data recorder or an avionics equipment data acquisition tool; the original data is control data, sensor data or device data generated during the operation of the target system and saved in binary form and / or character string.

[0050] Furthermore, in some embodiments, the target system extracts the original recorded data, and determines the data to be played back in sequence according to the playback time and the second timestamp of each piece of the original recorded data; wherein the time indicated by the second timestamp is the same as the time indicated by the first timestamp.

[0051] Furthermore, in some embodiments, the data pool includes at least two independent FIFO buffers, and the size of the data pool is at least half of the total memory size of the terminal running the target system.

[0052] Further, in some embodiments, parsed data is obtained from the data file to be replayed, and the parsed data is placed in a data pool, including: after obtaining the parsed data from the data file to be replayed, the parsed data is written to a first FIFO cache of the data pool; when the first FIFO cache is full of data, the parsed data is written to a second FIFO cache of the data pool; when both the first FIFO cache and the second FIFO cache are full, the data parsing is stopped.

[0053] Further, in some embodiments, the running time of the target system is simulated based on the simulation running time layer, including: sequentially simulating the running time through a timer provided by the simulation running time layer, wherein the timer is triggered every 1ms; and / or providing a timer to customize several time values ​​through the time simulation layer, and obtaining a time value sequentially every 1ms.

[0054] Furthermore, in some embodiments, the target data is determined based on the running time and the first timestamp, including: if the first timestamp is later than the running time, the parsed data is the target data; if the first timestamp is earlier than the running time, the running time is hibernated until the target data corresponding to the running time is obtained.

[0055] See also Figure 2 Another embodiment of the present application relates to a high-precision data automatic recharging test method, the specific flow chart is as follows Figure 2 As shown, the high-precision data automatic re-injection test method includes the following steps.

[0056] Step S201: Parse to obtain parsed data.

[0057] Specifically, the target system parses the to-be-played back data file based on the data parsing layer to obtain parsed data, wherein each parsed data includes at least data content and a first timestamp corresponding to the data content.

[0058] The target system may be a complex control system such as an automatic driving system or a flight control system for testing, and the original recorded data may be control data, sensor data or other device data generated when the above-mentioned complex control system is running.

[0059] Among them, the target system and the test system can be heterogeneous, and the two systems can run on different terminals. Part or all of the above data is collected by the target system through a third-party tool, and the target system receives the collected data and stores it in the database of the terminal where the target system runs. The target system sends the playback data to the test system through the interface layer and the sending layer. Alternatively, the structure of the test system and the structure of the control system can also be isomorphic. In a homogeneous system, the data transmission module inside the system collects the data through the third-party tool, and transmits the data to be played back through the transmission layer inside the system.

[0060] The format of some or all of the above data is not limited, and is determined by the specific application scenario and data collection source of the target system. The target system parses the data through the data parsing layer and stores it in the memory. The parsed data must at least include data content, data length and timestamp, and other information can also be customized.

[0061] Step S202: putting the parsed data into a data pool.

[0062] The data pool structure is as follows: Figure 3As shown. The data pool is constructed based on the ping-pong buffer of two independent FIFOs. When data parsing starts, data will be written to one of the FIFOs. When it is full, it will be written to the other one. At the same time, the full FIFO starts to send data. If both FIFOs are full, parsing will be temporarily stopped, and data parsing will continue when there is an empty FIFO. In theory, the speed of parsing data will be much faster than sending. Therefore, even in the face of massive data, data can be continuously parsed, ensuring the continuity and consistency of sending.

[0063] Step S203: Simulate system running time.

[0064] Specifically, when a certain amount of parsed data is reached or all parsing is completed, the simulation runtime starts working.

[0065] The running time of the simulation system is also in digital form and is measured in milliseconds. By simulating the running time of the simulation system and the timestamp of the data, the local data can be reproduced in the original time sequence during playback. The data recording state at that time can be accurately restored by simulating the running time.

[0066] The simulated running time is related to the time slice in the playback request. The start time of the simulated running time is set by the start time specified by the time slice, that is, the start time of the test system operation is determined. When the test playback starts, the timer provided by the operating system is triggered every 1ms, supporting 0.5, 2, 4 or 6 times the speed. After testing (windows 10, centos), for millisecond-level data, the accuracy meets the conditions; or, based on the relevant interface, using custom time, the custom time value will be taken every 1ms, and the data at any time in the time slice can be taken for playback testing.

[0067] Step S204: Take out a piece of parsed data with a timestamp.

[0068] Specifically, data is retrieved from the data pool in order of the timestamp of each parsed data.

[0069] Step S205: Determine target data according to the timestamp and simulation time.

[0070] Specifically, the target data is determined according to the running time and the timestamp of the parsed data, and the data can be taken out from the data pool according to the timestamp sequence of each parsed data, and whether it is the target data is determined according to the relationship between the timestamp of the data and the simulation time. Among them, the running time can correspond to the timestamp of the parsed data, or the timestamp of the playback data should be later than the running time. When any of the above conditions is met, the parsed data can be sent to the test system as the target data.

[0071] Further, when the timestamp of the parsed data is earlier than the running time, step S207 is executed, the running time is dormant for 1ms, that is, after stopping the simulation for 1ms, the next data is obtained, and the relationship between the timestamp and the running time of the simulation is compared again to determine the target data.

[0072] Step S206: Send data.

[0073] Specifically, after the target data is determined, the corresponding data sending function is called based on the data sending layer to send the data to the test system, so that the test system can perform a playback test on the target data.

[0074] Among them, the test system can also achieve the data playback process pause, speed up and drag operations by adjusting the sleep duration of the simulated running time based on the mechanism of timestamp and running time alignment.

[0075] The technical solution of this embodiment is to parse the playback data and store it in the data pool; at the same time, simulate the running time of the system, determine the target data according to the running time and the timestamp in the parsed data, and provide the test system with a playback test on the target data one by one. Obviously, the present invention sets a timestamp and simulates the running time for the playback data, and constructs a parsing pool to ensure that the data can be accurately synchronized with the sending time of the original data during playback. In the face of massive data, the stored data can be continuously parsed to ensure data integrity and continuity.

[0076] See also Figure 4 Another embodiment of the present application relates to a high-precision data automatic recharging test method, the specific flow chart is as follows Figure 4 As shown, the high-precision data automatic re-injection test method includes the following steps:

[0077] Step S401: respond to a data playback request and add locally stored data.

[0078] Specifically, in response to the data playback request sent by the test system, the target system prepares a local data file to be played back, and the local data file at least includes the sent data content and a timestamp.

[0079] The target system may be a complex control system such as an automatic driving system or a flight control system for testing, and the original recorded data may be control data, sensor data or other device data generated when the above-mentioned complex control system is running.

[0080] Among them, the target system and the test system can be heterogeneous, and the two systems can run on different terminals. Part or all of the above data is collected by the target system through a third-party tool, and the target system receives the collected data and stores it in the database of the terminal where the target system runs. The target system sends the playback data to the test system through the interface layer and the sending layer. Alternatively, the structure of the test system and the structure of the control system can also be isomorphic. In a homogeneous system, the data transmission module inside the system collects the data through the third-party tool, and transmits the data to be played back through the transmission layer inside the system.

[0081] The locally stored data file includes at least data content and timestamp, and may also include other custom added information. The data file may be data collected by various business modules, and different types of data may have different recording locations and recording methods. It may also be a data file saved by other terminals other than the one executing the method.

[0082] Step S402: Setting the playback start or end time according to the playback time of the playback request.

[0083] Specifically, the playback request includes the playback time, and the playback time is the time segment that the user sets to be played back, that is, the start time and the end time of the playback are set.

[0084] Step S403: Acquire and parse the locally stored data, and save the parsed data.

[0085] Specifically, according to the time segment that needs to be replayed, the user sets the start time and end time of the replay, collects the locally stored data that meets the start time and end time interval, and saves the parsed data in the data pool of the target system.

[0086] For example, the target system sent data from 8 to 9 yesterday. If you want to replay the data sent during the test, you can send a test request through the test system and set the start time of the time slice to 8 yesterday; or if you only want to replay the data after 8:30, you can change it to 8:30.

[0087] The parsing of the locally stored data may be to implement the parsing of specific data by implementing the relevant interface, and after the parsing is completed, the parsed data is placed into the corresponding data pool. The parsed data must at least include the data content, data length and timestamp, and other information may also be added by custom means.

[0088] Before data analysis, the system will pre-apply a piece of memory to build a data pool, which stores the analyzed data. The memory size can be modified and is set to half of the total memory size by default.

[0089] The storage structure of the data pool is a ping-pong buffer based on two independent FIFOs. When the data starts to be parsed, data will be written to one of the FIFOs. When it is full, it will be written to the other one. At the same time, the full FIFO starts to send data. If both FIFOs are full, parsing will be temporarily stopped, and data parsing will continue when there is an empty FIFO. In theory, the speed of parsing data will be much faster than sending. Therefore, even in the face of massive data, data can be continuously parsed to ensure the continuity and consistency of transmission.

[0090] The memory sizes occupied by the ping-pong buffers of the two independent FIFOs may be the same or different.

[0091] Step S404: Send the target playback data according to the timestamp.

[0092] Specifically, after a certain amount of parsed data has been reached, the simulation runtime starts working, and the data will be sent in chronological order according to the timestamp.

[0093] The running time of the simulation system is also in digital form and is measured in milliseconds. By simulating the running time of the simulation system and the timestamp of the data, the local data can be reproduced in the original time sequence during playback. The data recording state at that time can be accurately restored by simulating the running time.

[0094] The simulated running time is related to the time slice in the playback request. The start time of the simulated running time is set by the start time specified by the time slice, that is, the start time of the test system operation is determined. When the test playback starts, the timer provided by the operating system is used to trigger once every 1ms, supporting 0.5, 2, 4, and 6 times the speed. After testing (windows 10, centos), for millisecond-level data, the accuracy meets the conditions; or, based on the relevant interface, using custom time, the custom time value will be taken every 1ms, and the data at any time in the time slice can be taken for playback testing.

[0095] The target data is determined according to the running time and the timestamp of the parsed data. The running time may correspond to the timestamp of the parsed data, or the timestamp of the playback data may be later than the running time. When any of the above conditions is met, the parsed data can be used as the target data. When the timestamp of the parsed data is earlier than the running time, the running time is dormant for 1ms, that is, the simulation is stopped for 1ms, and the next data is obtained. The timestamp and the simulated running time are compared again to determine the target data.

[0096] Step S405: Check whether all test data are played back.

[0097] Specifically, the test system replays each target data and also checks whether all the data have been replayed. If all the data have been replayed, the test ends; otherwise, step S404 is executed to send new target data to the test system for replay.

[0098] The technical solution of this embodiment is to determine the data to be replayed from multiple original records stored locally by the target system in response to the data replay request from the test system, further parse the data to be replayed, and store it in the data pool; at the same time, simulate the running time of the system, determine the target data according to the running time and the timestamp in the parsed data, so that the test system can replay the target data one by one. Obviously, the present invention sets the timestamp and simulates the running time for the replayed data, and constructs a parsing pool to ensure that the data can be accurately synchronized with the sending time of the original data during playback. In the face of massive data, the stored data can be continuously parsed to ensure data integrity and continuity.

[0099] The step division of the above methods is only for the purpose of clear description. When implemented, they can be combined into one step or some steps can be split and decomposed into multiple steps. As long as they include the same logical relationship, they are all within the scope of protection of this patent; adding insignificant modifications to the algorithm or process or introducing insignificant designs without changing the core design of the algorithm and process are all within the scope of protection of this patent.

[0100] Another embodiment of the present invention relates to a data playback test device. This embodiment can be applied to data playback test. The device can be implemented in software and / or hardware. The device can be integrated in any device that provides data playback test function. Figure 5 As shown, the device includes: a data acquisition module, a data analysis module, a time simulation module and a data sending module.

[0101] Among them, the data acquisition module is used to respond to the data playback test request of the test system based on the interface layer, determine the data file to be played back from multiple external original recorded data, and re-inject it into the target system; the data playback request at least includes the playback time.

[0102] The data parsing module is used to parse the to-be-played data file based on the data parsing layer to obtain parsed data, and put the parsed data into a data pool, each parsed data at least including data content and a first timestamp corresponding to the data content.

[0103] The time simulation module is used to simulate the running time of the target system based on the simulation running time layer after the number of parsed data reaches a threshold or all the data files to be replayed are parsed, and determine the target data according to the running time and the first timestamp.

[0104] The data sending module is used to send the target data to the test system based on the data sending layer; the test system is used to replay the target data one by one according to the running time.

[0105] Optionally, the data acquisition module is specifically used to: extract original recorded data, and determine the data to be replayed in sequence according to the playback time and the second timestamp of each original recorded data; wherein the time indicated by the second timestamp is the same as the time indicated by the first timestamp.

[0106] Optionally, the data parsing module is specifically used to: construct a data pool, the data pool includes at least 2 independent FIFO buffers, and the size of the data pool is at least half of the total memory size of the terminal executing the test system.

[0107] After obtaining the parsed data from the data file to be replayed, the parsed data is written to the first FIFO buffer of the data pool. When the first FIFO buffer is full of data, the parsed data is written to the second FIFO buffer of the data pool. When both the first FIFO buffer and the second FIFO buffer are full, the data parsing stops.

[0108] Optionally, the time simulation module is specifically used to: simulate the running time sequentially through the timer provided by the simulation running time layer, wherein the timer is triggered once every 1ms; and / or provide a timer to customize several time values ​​through the time simulation layer, and obtain one of the time values ​​sequentially every 1ms.

[0109] If the first timestamp is later than the running time, the parsed data is the target data; if the first timestamp is earlier than the running time, the running time is dormant until the target data corresponding to the running time is obtained.

[0110] The technical solution of this embodiment is to determine the data to be replayed from multiple original records stored locally by the target system in response to the data replay request from the test system, further parse the data to be replayed, and store it in the data pool; at the same time, simulate the running time of the system, determine the target data according to the running time and the timestamp in the parsed data, so that the test system can replay the target data one by one. Obviously, the present invention sets the timestamp and simulates the running time for the replayed data, and constructs a parsing pool to ensure that the data can be accurately synchronized with the sending time of the original data during playback. In the face of massive data, the stored data can be continuously parsed to ensure data integrity and continuity.

[0111] It is not difficult to find that this embodiment is a system embodiment corresponding to the aforementioned method embodiment, and this embodiment is implemented in conjunction with the aforementioned method embodiment. The relevant technical details mentioned in the aforementioned method embodiment are still valid in this embodiment, and in order to reduce repetition, they are not repeated here. Accordingly, the relevant technical details mentioned in this embodiment can also be applied in the aforementioned method embodiment.

[0112] It is worth mentioning that all modules involved in this embodiment are logic modules. In practical applications, a logic unit can be a physical unit, a part of a physical unit, or a combination of multiple physical units. In addition, in order to highlight the innovative part of the present invention, this embodiment does not introduce units that are not closely related to solving the technical problem proposed by the present invention, but this does not mean that there are no other units in this embodiment.

[0113] Another embodiment of the present invention relates to a terminal, such as Figure 6 As shown, it includes at least one processor; and a memory communicatively connected to the at least one processor; wherein the memory stores instructions executable by the at least one processor, and the instructions are executed by the at least one processor so that the at least one processor can perform the above-mentioned high-precision data automatic re-injection test method.

[0114] Among them, the memory and the processor are connected in a bus manner, and the bus may include any number of interconnected buses and bridges, and the bus connects various circuits of one or more processors and memories together. The bus can also connect various other circuits such as peripherals, voltage regulators, and power management circuits, which are well known in the art and are therefore not further described herein. The bus interface provides an interface between the bus and the transceiver. The transceiver can be one element or multiple elements, such as multiple receivers and transmitters, providing a unit for communicating with various other devices on a transmission medium. The data processed by the processor is transmitted on a wireless medium via an antenna, and further, the antenna also receives data and transmits the data to the processor.

[0115] The processor is responsible for managing the bus and general processing, and can also provide various functions, including timing, peripheral interfaces, voltage regulation, power management, and other control functions. Memory can be used to store data used by the processor when performing operations.

[0116] Another embodiment of the present invention relates to a computer-readable storage medium storing a computer program, which implements the above method embodiment when executed by a processor.

[0117] That is, those skilled in the art can understand that all or part of the steps in the above-mentioned embodiment method can be completed by instructing the relevant hardware through a program, and the program is stored in a storage medium, including several instructions to enable a device (which can be a single-chip microcomputer, chip, etc.) or a processor to execute all or part of the steps of the method described in each embodiment of the present application. The aforementioned storage medium includes: U disk, mobile hard disk, read-only memory (ROM, Read-Only Memory), random access memory (RAM, Random Access Memory), disk or optical disk and other media that can store program codes.

[0118] Those skilled in the art will appreciate that the above embodiments are specific embodiments for implementing the present invention, and that in actual applications, various changes may be made in form and detail without departing from the spirit and scope of the present invention.

Claims

1. A high-precision data automatic re-injection test method, characterized in that: Applied to a target system, the target system includes a data playback framework, the data playback framework includes at least: an interface layer, a data parsing layer, a data sending layer and a simulation runtime layer; The method comprises: Based on the interface layer responding to the data playback test request of the test system, determining the data file to be played back from the plurality of external original recorded data, and injecting it back into the target system; wherein the data playback request at least includes the playback time; Based on the data parsing layer, the parsed data is obtained from the data file to be replayed, and the parsed data is placed in a data pool; wherein each piece of the parsed data at least includes data content and a first timestamp corresponding to the data content; After the number of parsed data reaches a threshold or parsing of all the data files to be replayed is completed, the running time of the target system is simulated based on the simulation running time layer, the target data is determined according to the running time and the first timestamp, and the target data is sent to the test system based on the data sending layer; the test system performs playback tests on the target data one by one according to the running time.

2. The high-precision data automatic re-injection test method according to claim 1 is characterized in that: The target system and the test system are heterogeneous structures; the external original recorded data is synthesized from the original data recorded by the third-party tool and the second timestamp; wherein, The target system is an autopilot system or a flight control system; The third-party tools include at least a flight data recorder or an avionics equipment data acquisition tool; The original data is control data, sensor data or device data generated when the target system is running and saved in binary form and / or character string.

3. The high-precision data automatic re-injection test method according to claim 1 is characterized in that: The step of responding to the data playback test request of the test system based on the interface layer, determining the data file to be played back from multiple external original recorded data, and re-injecting the data file to the target system includes: The target system extracts the original recorded data, determines the data to be replayed in sequence according to the playback time included in the playback test request and the second timestamp of each original recorded data, and re-injects it into the target system; wherein the time indicated by the second timestamp is the same as the time indicated by the first timestamp.

4. The high-precision data automatic re-injection test method according to claim 1 is characterized in that: The data pool includes at least two independent FIFO buffers, and the size of the data pool is at least half of the total memory size of the terminal running the target system.

5. The high-precision data automatic re-injection test method according to claim 4 is characterized in that: The step of parsing the to-be-played data file based on the data parsing layer to obtain parsed data and placing the parsed data into a data pool comprises: After obtaining parsed data from the to-be-played data file based on the data parsing layer, the parsed data is written into a first FIFO buffer of the data pool, and when the first FIFO buffer is full of data, the parsed data is written into a second FIFO buffer of the data pool; When both the first FIFO buffer and the second FIFO buffer are full, data parsing stops.

6. The high-precision data automatic re-injection test method according to claim 1 is characterized in that: The simulating the runtime of the target system based on the simulated runtime layer includes: Simulating the running time sequentially through the timer provided by the simulation running time layer, wherein the timer is triggered once every 1ms; And / or provide a timer to customize several time values ​​through the time simulation layer, and sequentially obtain one of the time values ​​every 1 ms.

7. The high-precision data automatic re-injection test method according to claim 1 is characterized in that: Determining the target data according to the running time and the first timestamp includes: If the first timestamp is later than the running time, the piece of parsed data is the target data; If the first timestamp is earlier than the running time, the running time is dormant until the target data corresponding to the running time is acquired.

8. A data playback test device, characterized in that: Applied to a target system, the target system includes a data playback framework, the data playback framework includes at least: an interface layer, a data parsing layer, a data sending layer and a simulation runtime layer; The device comprises: Data acquisition module: used to determine the data file to be replayed from multiple external original recorded data based on the data replay test request of the interface layer response test system, and re-inject it into the target system; wherein the data replay request at least includes the replay time; Data parsing module: used for parsing the to-be-played data file from the to-be-played data file based on the data parsing layer to obtain parsed data, and putting the parsed data into a data pool; wherein each of the parsed data includes at least data content and a first timestamp corresponding to the data content; Time simulation module: used for simulating the running time of the target system based on the simulation running time layer when the number of parsed data reaches a threshold or all the data files to be replayed are parsed, and determining the target data according to the running time and the first timestamp; Data sending module: used for sending the target data to the test system based on the data sending layer; and for the test system to perform playback test on the target data one by one according to the running time.

9. A terminal, characterized in that: include: at least one processor; as well as, a memory communicatively connected to the at least one processor; wherein, The memory stores instructions executable by the at least one processor, and the instructions are executed by the at least one processor so that the at least one processor can execute the high-precision data automatic re-injection test method as described in any one of claims 1 to 7.

10. A computer-readable storage medium storing a computer program, characterized in that: When the computer program is executed by a processor, the high-precision data automatic re-injection test method described in any one of claims 1 to 7 is implemented.

Images