A telemetry data real-time processing system for multi-model launch vehicles

Abstract

The present application relates to the field of spaceflight TT&C technology, and provides a telemetry data real-time processing system for multiple types of launch vehicles, which comprises a system framework, a component chain configuration module, at least one data processing component chain, and an optimization processing module. The system framework is used to receive raw telemetry data streams from a space-based telemetry system and / or a ground-based telemetry system. The component chain configuration module is used to store component chain configuration information corresponding to each type of rocket. The at least one data processing component chain is configured to be dynamically called by the system framework according to the configuration result of the component chain configuration module to perform corresponding data processing operations. The optimization processing module is used to finely optimize the processing result of the telemetry parameters. The present application adapts to the processing requirements of different rocket types, solves the problem of multi-type compatibility, compares and optimizes the processing result values of each data source horizontally according to the principle of minority serving majority for each telemetry parameter, dynamically adjusts the traversal order, finely optimizes the parameter granularity, and significantly improves the system versatility and the accuracy of the optimization result.

Description

Technical Field

[0001] This invention relates to the field of aerospace telemetry and control technology, and more specifically, to a real-time telemetry data processing system for multiple types of launch vehicles. Background Technology

[0002] In recent years, with the vigorous development of my country's commercial space industry, rocket launch missions serving commercial spaceflight have shown a trend of high density and frequent scheduling. During rocket launch and flight, telemetry data is an important source of information for obtaining rocket flight status, and the real-time generation of telemetry parameter processing results can provide decision-making basis and information support for command and decision-making personnel at all levels of the space launch site.

[0003] Compared to existing space launch sites, commercial space launch sites will serve both state-owned rocket companies and various commercial rocket companies, meaning they will handle a wider range of launch vehicle models. The real-time processing of rocket telemetry data includes telemetry data preprocessing, full-frame telemetry data processing, and the selection and release of optimal processing results.

[0004] Existing real-time rocket telemetry data processing systems have the following technical shortcomings when addressing the real-time processing needs of telemetry data from multiple launch vehicle models: First, there is the issue of compatibility across different models. The existing real-time telemetry data processing systems at each launch site are mostly designed for specific series of launch vehicles for their respective launch sites. When the rocket model or the rocket developer changes, corresponding adaptive modifications are required to the code and even the entire framework of the telemetry preprocessing and full-frame telemetry processing modules. This results in software-level code versions for different rocket models, causing inconvenience for system maintenance and standardization.

[0005] Second, the optimization strategy lacks refinement. The existing system's optimization strategy performs a uniform optimization process for all telemetry parameters. That is, the data source for the optimization of all telemetry parameters at the same time is unique, and it cannot perform differentiated optimization processes based on the characteristics of different types or even different individual parameters and their actual processing results.

[0006] Several existing technologies have attempted to address these issues. For example, CN103957134A discloses a modular and configurable telemetry parameter parsing and processing system. This system employs a modular architecture, dividing the telemetry parameter parsing and processing into multiple modules and using a basic database to flexibly configure various data processing methods. However, the relationships between the modules in this scheme are relatively fixed, constituting a static modular architecture that struggles to flexibly adapt to the differentiated data processing flows of different rocket models. Another example is CN116384917A, which discloses a component-based automated process data processing system. This system uses a pipeline approach to connect user-selected functional components to achieve data parsing. However, this scheme does not specifically design a component chain for the entire rocket telemetry data processing flow, nor does it address the componentization of the optimization and release stage. Regarding optimization techniques, existing technologies often employ methods based on signal quality, frame continuity, and priority lists, resulting in coarse-grained optimization that is difficult to achieve for fine-grained optimization of individual parameters. Summary of the Invention

[0007] In view of this, the present invention proposes a real-time telemetry data processing system for multiple types of launch vehicles. It achieves multi-model compatibility through a dynamically configurable component chain architecture and achieves refined selection through a "majority rule" horizontal comparison and selection strategy at the single-parameter granularity.

[0008] To achieve the above objectives, the present invention proposes the following technical solution: A real-time telemetry data processing system for multiple types of launch vehicles is characterized by comprising a system framework, a component chain configuration module, at least one data processing component chain, and an optimization processing module. The system framework is used to receive raw telemetry data streams from space-based telemetry systems and / or ground-based telemetry systems; The component chain configuration module stores the component chain configuration information corresponding to each type of rocket. The system framework dynamically calls each data processing component chain to perform data processing based on the configuration results of the component chain configuration module; The data processing component chain includes one or more data processing components that are called in sequence. The output of each data processing component carries a result type identifier and the component processing result, and serves as the input information for the next stage of the data processing component chain or data processing component. The optimization processing module is used to perform fine-grained optimization of the telemetry parameter processing results, including a timestamp alignment unit, a result comparison unit, an output determination unit, and a traversal order adjustment unit.

[0009] Furthermore, the component chain configuration information stored in the component chain configuration module includes the type of each component chain, the upstream and downstream dependencies between component chains, and the composition and calling order of the data processing components within each component chain; The component chain configuration module can change the upstream and downstream data flow and calling relationship between component chains. When adapting to a new model rocket, operators can add or modify the component chain configuration through the component chain configuration module without modifying the system framework layer code to achieve real-time processing of telemetry data of the new model rocket.

[0010] Furthermore, the data processing component chain includes preprocessing component A and preprocessing component B. Preprocessing component A receives the raw data stream output from the upstream system framework, and sequentially performs PDXP frame header verification, data field parsing and verification, preliminary extraction of full frame data, and full frame data verification, and outputs full frame data that has been verified without error. The preprocessing component B receives the full-frame data output by the preprocessing component A, performs the restoration and extraction of the next-level full-frame data, and forms higher-level telemetry full-frame data by deleting subframe ID and synchronization code information, identifying buffer synchronization codes, and performing full-frame verification operations.

[0011] Furthermore, the preliminary extraction of full-frame data performed by the preprocessing component A includes the following steps: The NextStep variable is introduced to represent the steps to be executed in the preprocessing cycle. The NextStep variable includes two enumerated values: finding the subframe synchronization code and checking whether the buffer array length is sufficient. The initial value is to find the subframe synchronization code. The system searches for a subframe that matches the subframe synchronization code in the synchronization code channel of the subframe buffer array queue, frame by frame. If the subframe is found, all subframe buffers in the buffer, including those before and within the subframe itself, are cleared. The system then checks if the buffer length reaches the subframe length Len. If the buffer length is less than Len, NextStep is set to check if the buffer array length is sufficient and the system returns to wait for subframe data. If the buffer length is greater than or equal to Len, the system checks if the synchronization code value of the subframe at position Len in the buffer is the subframe synchronization code. If the synchronization code value is not the subframe synchronization code, the first subframe in the buffer is removed and the search is repeated. If it is the subframe synchronization code, the first to Len subframes in the buffer are completely extracted to complete the initial extraction of the full frame data. Then, the buffer buffers from the first to the (Len-1)th subframe are cleared, and the Len subframe is retained.

[0012] Furthermore, the full-frame data verification performed by the preprocessing component A includes subframe synchronization code correctness verification, subframe ID order verification, and subframe ID validity verification; The method for verifying the validity of the subframe ID is as follows: the difference between the subframe ID of the full frame to be verified and the previous valid full frame is denoted as ΔδID, and the difference in timestamps is denoted as δt milliseconds. Let the full frame frequency be fHz. If δt / δID equals 1000 / f, then the subframe ID is valid and the full frame is set as the previous valid full frame; otherwise, the subframe ID of the full frame is invalid.

[0013] Furthermore, the preprocessing component B performs preliminary processing on the full-frame data output by the preprocessing component A, deleting the subframe IDs and synchronization code information of each subframe in the full-frame data, and appending the pre-processed full-frame data to the buffer. By traversing the buffer, the synchronization code is used to initially extract and form the original telemetry full-frame data on the rocket. The full-frame data is then verified in terms of the validity of the subframe synchronization code, the validity of the subframe ID, and the validity of the subframe ID. The full-frame data that has been verified without error is officially used as the full-frame data to be stitched and restored and handed over to the downstream module for further processing.

[0014] Furthermore, the result type identifier includes ByteArray type, Int / UInt type and Double type. The downstream data processing component or data processing component chain parses the output result of the upstream component according to the result type identifier, so that different types of data results can be seamlessly transferred between component chains.

[0015] Furthermore, the timestamp alignment unit of the optimization processing module uses the timestamp of the first packet of data in the first data source queue as a benchmark to search for data in other data source queues whose time difference with the timestamp is within a threshold range. If no corresponding data is found in a certain data source queue, the search continues in the next cycle until all data source queues have found the parameter processing result with the corresponding timestamp. If no data source is found after the preset maximum number of waiting rounds, the subsequent optimization process is officially started with the current benchmark timestamp as the first round of optimization time.

[0016] Furthermore, the result comparison unit obtains the parameter processing result value corresponding to the timestamp of the current time period from each data source queue in the current optimization cycle, counts the occurrence frequency of each processing result value, and determines the processing result value with the most occurrence frequency as the final output value according to the principle of majority rule in horizontal comparison. The output determination unit selects the data source whose parameter processing result value meets the requirements and ranks first in the selection order from the data source that generates the final output value, according to the pre-set flight arc segment and telemetry data source selection order, and outputs the data source. The traversal order adjustment unit records the data sources selected in the current cycle. In the next optimization cycle, the traversal order is adjusted to start from the selected data source and traverse each data source in sequence to improve the data hit efficiency in the optimization process.

[0017] Compared with the prior art, the beneficial effects of the present invention are as follows: This invention utilizes a platform and component chain architecture to delegate the common aspects of telemetry data processing to the system framework, while the differentiated parts are implemented by various data processing component chains. The system framework can be customized to handle different real-time rocket telemetry data processing scenarios by flexibly combining, building, and configuring component chains and their upstream and downstream processing relationships. Thus, a single system can meet the real-time telemetry data processing needs of multiple launch vehicle models. When a new rocket model is added, only a new combination of component chains needs to be configured; no modification to the overall system framework is required, significantly reducing system maintenance costs and development cycles.

[0018] This invention optimizes parameters at the individual telemetry parameter level, refining the optimization precision from the data stream level to the individual parameter level. It adopts a majority-rule horizontal comparison mechanism, which selects the optimal result by directly comparing the parameter processing results of each data source at the same timestamp. This avoids errors that may be introduced by indirect indicators such as signal quality, and ensures the accuracy of the optimization results.

[0019] This invention ensures that all data sources are complete when the selection process starts by initializing a multi-round accumulation mechanism. By dynamically adjusting the traversal order based on the data sources selected in the previous cycle, it effectively improves the data hit efficiency and reduces latency during the selection process. Attached Figure Description

[0020] Various other advantages and benefits will become apparent to those skilled in the art upon reading the following detailed description of preferred embodiments. The accompanying drawings are for illustrative purposes only and are not intended to limit the invention. In the drawings: Figure 1 This is a schematic diagram of the overall architecture of the real-time telemetry data processing system of the present invention; Figure 2 This is a schematic diagram of the data processing component chain in an embodiment of the present invention; Figure 3 This is a schematic diagram of the optimization processing module in an embodiment of the present invention; Figure 4 This is a flowchart of the data preprocessing component chain in an embodiment of the present invention. Detailed Implementation

[0021] Exemplary embodiments of the present disclosure will now be described in more detail with reference to the accompanying drawings. While exemplary embodiments of the present disclosure are shown in the drawings, it should be understood that the present disclosure may be implemented in various forms and should not be limited to the embodiments set forth herein. Rather, these embodiments are provided to enable a more thorough understanding of the present disclosure and to fully convey the scope of the disclosure to those skilled in the art. It should be noted that, unless otherwise specified, the embodiments and features described herein can be combined with each other. The present invention will now be described in detail with reference to the accompanying drawings and embodiments.

[0022] Example 1 like Figure 1 As shown, this embodiment provides a real-time telemetry data processing system for multiple types of launch vehicles. The system includes: a system framework, a component chain configuration module, and at least one data processing component chain.

[0023] The system framework is responsible for receiving raw telemetry data streams from space-based and / or ground-based telemetry systems, and dynamically invoking each data processing component chain to perform data processing based on the configuration results of the component chain configuration module. The component chain configuration module stores the component chain configuration information corresponding to each rocket model, including the type of each component chain (such as data preprocessing component chain, data routing component chain, asynchronous data frame extraction component chain, parameter processing component chain, etc.), the upstream and downstream dependencies between component chains, and the composition and invocation order of the data processing components within each component chain.

[0024] It is important to note that configuring the component chain configuration module is not simply a matter of adjusting parameters; rather, it involves architecture-level configuration that can alter the upstream and downstream data flow and calling relationships between component chains. When adapting to a new rocket model, operators do not need to modify the system framework code; they can simply add or modify component chain configurations through the component chain configuration module to achieve real-time processing of telemetry data from the new rocket model.

[0025] Composition and Interaction of Data Processing Component Chain like Figure 2 As shown, each data processing component chain can include one or more data processing components called sequentially. Taking the data preprocessing component chain as an example, this chain includes preprocessing component A and preprocessing component B.

[0026] Preprocessing component A receives the raw data stream output from the upstream system framework and sequentially performs PDXP frame header verification, data field parsing and verification, preliminary extraction of full frame data (including subframe synchronization code lookup, buffer management and full frame extraction), and full frame data verification (including subframe synchronization code correctness verification, subframe ID order verification and subframe ID validity verification), and outputs full frame data with no verification errors.

[0027] Preprocessing component B receives the full-frame data output by preprocessing component A and performs the next-level full-frame data restoration and extraction, that is, by deleting subframe ID and synchronization code information, identifying buffer synchronization codes, and performing full-frame verification, a higher-level telemetry full-frame data is formed.

[0028] The output of each data processing component carries a result type identifier and the component processing result. The result type identifier includes ByteArray, Int / UInt, and Double types, etc. Downstream components can parse the output of upstream components based on the result type identifier, so that different types of data results can be seamlessly passed between component chains.

[0029] The output of the data processing component chain will serve as the input information for the next downstream component chain. For example, the output of the data preprocessing component chain will serve as the input of the data routing component chain; the output of the data routing component chain will serve as the input of the asynchronous data frame extraction component chain; and the output of the asynchronous data frame extraction component chain will serve as the input of the parameter processing component chain. Through this design, the entire telemetry data processing process is abstracted and decomposed into several flexibly configurable component chains, forming a highly modular and reusable processing system.

[0030] Optimal processing method like Figure 3 As shown, this system also includes an optimization processing module, used for fine-tuning the telemetry parameter processing results. The optimization processing module includes a timestamp alignment unit, a result comparison unit, an output determination unit, and a traversal order adjustment unit.

[0031] The following section, using the timing diagram in Table 1 as an example, illustrates the implementation method of the optimization process in a specific application scenario.

[0032] Table 1

[0033] Assume there are 5 telemetry data sources A, B, C, D, and E (corresponding to 5 telemetry devices or space-based telemetry and control systems), and the transmission period of the target telemetry parameters is known in advance. The system uses a timed polling method to periodically traverse the processing results of the parameter generated by each telemetry data source.

[0034] (1) Initialize the first round of selection time The timestamp alignment unit uses the timestamp of the first data packet in queue A of data source A as a benchmark, and searches for data in queues B, C, D, and E of other data sources whose timestamps are within a threshold range (e.g., ±10 milliseconds). If no corresponding data is found in a data source queue, the search continues in the next cycle until all five queues have found the parameter processing result for the corresponding timestamp. If no data source is found after three cycles, the timestamp alignment unit uses the current benchmark timestamp as the first round of optimization time and officially starts the subsequent optimization process.

[0035] (2) Single-cycle selection comparison In the current optimization cycle, the result comparison unit retrieves the parameter processing result value corresponding to the timestamp of each data source queue. Assuming the parameter processing result value for data sources A, B, C, and D is all 'x', and the parameter processing result value for data source E is 'y', then the value 'x' appears 4 times, and the value 'y' appears 1 time. The result comparison unit determines the value 'x' as the final output value.

[0036] (3) Output source selection The output determination unit selects the highest-ranking data source from the data sources (A, B, C, and D) that generate the final output value, according to a pre-defined order of preference for flight arc segments and telemetry data sources. For example, if the preference order is A→B→C→D→E, then the output of data source A is selected as the final processing result for that parameter.

[0037] (4) Dynamic adjustment of traversal order The traversal order adjustment unit records the selected data source C for the current cycle (assuming that data source C is selected after the optimization order and output source selection). In the next optimization cycle, the traversal order adjustment unit adjusts the traversal order to C→D→E→A→B, that is, starting from the selected data source C, it traverses each data source sequentially. This allows for faster data matching when the optimization results are stable, improving optimization efficiency.

[0038] Example 2 This embodiment uses a data preprocessing component chain as an example to illustrate the data preprocessing component chain designed by the present invention for the CZ-10B model launch vehicle for commercial space launch sites.

[0039] The second-stage telemetry integration of the CZ-10B rocket asynchronously sends the integrated and framed data from the first stage to the next stage in a data integration frame format for further integration and framing, forming a new telemetry PCM data stream framing format. Therefore, this invention designs two data preprocessing components for the CZ-10B model's data preprocessing component chain, which sequentially perform the corresponding data framing and reconstruction work.

[0040] Preprocessing component 1 is responsible for extracting and outputting the second-level telemetry full-frame data, providing a foundation for the subsequent restoration and extraction of the first-level full-frame data. For example... Figure 4 As shown, the processing flow of this component is as follows: (1) PDXP frame header verification. The telemetry data preprocessing process first verifies the PDXP frame header of the received full telemetry frame raw data. Data frames whose frame length does not meet the requirements, whose data field length in the frame header does not match the actual data field length, and whose validity of fields such as VER, MID, SID, BID, and packet sequence number in the PDXP frame header does not meet the requirements are directly discarded.

[0041] (2) Data Domain Parsing and Verification. Next, the relevant fields in the data domain are parsed, verified, and filtered accordingly. The status code field in the data domain includes information such as baseband telemetry stream, telemetry status, baseband lock status, and tracking mode. For full-frame data where the telemetry stream / telemetry status does not match the currently processed full-frame data or where the telemetry baseband is out of lock, the data is discarded directly. The time stamp information and subframe content information of all subframes under the full-frame data whose status codes have passed the verification are parsed and extracted, and the newly extracted subframe data is used in step (3).

[0042] (3) Second-level preliminary extraction of full-frame data. This step iterates through the subframe buffer queue and introduces the variable NextStep to represent the steps to be executed in this preprocessing cycle. The NextStep variable includes two enumeration values: "find subframe synchronization code" (hereinafter referred to as A) and "check if the buffer array length is sufficient" (hereinafter referred to as B), with its initial value being A. The pseudocode flow of the preliminary extraction of full-frame data is as follows.

[0043] ① Wait to receive the verified subframe data provided in step (2), append it to the cache[] buffer, and then execute step ②; ② Determine the value of the NextStep variable. If it is A, proceed to step ③; if it is B, proceed to step ④. ③ Search for a subframe that matches the synchronization code of the subframe in the synchronization code channel of the cache[] subframe buffer array queue. If the subframe is found, clear all subframe buffers in the cache[] before the subframe (including the subframe itself) and proceed to step ④. If no subframe that matches the synchronization code of the subframe is found, clear the cache[] and return to step ①. ④ Assuming the subframe length of the full frame data is Len, if the current cache[] buffer length is less than Len, then set NextStep to B and return to step ①; if the buffer length is greater than or equal to Len, determine whether the synchronization code value of the subframe corresponding to the Len position in the cache[] buffer is the subframe synchronization code. If its value is not the subframe synchronization code, then remove the first subframe from the cache[] buffer and return to step ③; if its value is the subframe synchronization code, then completely extract the first to Len subframes from the cache[] buffer, thus completing the initial extraction of the full frame data, and outputting it for subsequent full frame data verification. Then, clear the cache[] buffer from the first to the Len-1 subframes (keeping the Len subframe synchronization code subframe is to correctly start the subsequent full frame extraction work), and return to step ③.

[0044] (4) Second-level full-frame data verification and output. The full-frame data verified in this step comes from the second-level full-frame data initially extracted and output in step (3). The verification content mainly includes the following aspects: a) Verify that the synchronization codes of all subframes in the full frame data are correct; b) Verify that the subframe IDs of each subframe in the full frame data are sequentially increasing and not lost; c) Verify whether the subframe ID of the full frame is valid. The specific method is as follows: Let the difference between the subframe ID of the full frame to be verified and the previous valid full frame be ΔδID, and the difference in timestamps be δt milliseconds. Let the full frame frequency be fHz. If δt / δID equals 1000 / f, then the subframe ID is valid, and the full frame is set as the "previous valid full frame"; otherwise, the subframe ID of the full frame is invalid.

[0045] If any of the above verification items fail, the process will return to step (3) and wait for the full frame data output from the preliminary extraction step of the second-level full frame data. If all verification items pass, the data block after removing the subframe / subframe ID and subframe / subframe synchronization code will be used as the second-level full frame data after splicing, extraction and verification, and output to the downstream data preprocessing component chain. The process will continue to loop and wait for the preliminary extraction of the second-level full frame data for verification.

[0046] Preprocessing component 2, based on the second-level telemetry full-frame data extracted from component 1, restores and extracts the original first-level telemetry full-frame data from the rocket. The processing flow of this component is as follows: (1) Perform preliminary processing on the full frame data output by preprocessing component 1: delete the subframe ID and synchronization code information of each subframe in the full frame data, and append the pre-processed full frame data to the buffer cache.

[0047] (2) Similar to step (3) of preprocessing component 1, by traversing the cache[] buffer and using the recognition of the synchronization code, the first-level telemetry full frame data on the rocket is initially extracted.

[0048] (3) Similar to step (4) of preprocessing component 1, the full frame data output in the previous step is verified in three aspects: the validity of the subframe synchronization code, the validity of the subframe ID, and the validity of the subframe ID. The full frame data that is verified without error will be officially used as the full frame data formed by splicing and restoration, and handed over to the relevant data processing components / component chain of the downstream full frame data processing module to perform further real-time telemetry data processing.

[0049] Other telemetry data processing tasks, such as data routing, asynchronous data frame splicing and reconstruction, parameter extraction and processing, can be implemented through different data processing components / component chains. The output of each component / component chain will serve as the input information for the next downstream component / component chain. The output of each data processing component includes the following information: result type and component processing result. Result types include byte stream data (ByteArray), Int / UInt data, and Double data. Downstream components / component chains can obtain the output processing result of the previous component through result type parsing.

[0050] As the main framework of the real-time telemetry data processing system, it can call various customized processing components / component chains through flexible combination and configuration, thereby realizing the service capability of real-time processing of telemetry data of multiple types of launch vehicles through a single system.

[0051] 2) Addressing the problem of "low refinement of selection strategies" This invention enables differentiated optimization of processing results for each telemetry parameter or each channel of telemetry image data. Taking a single telemetry parameter as an example, the system uses a timed polling method to periodically traverse the processing results of this parameter from each telemetry data source. Assume there are 5 telemetry data sources (i.e., 5 telemetry devices or space-based telemetry and control systems), designated A, B, C, D, and E. The transmission period of this parameter is known in advance; therefore, after one round of result optimization, the next optimization period for this parameter is easily obtained. The key to the problem lies in initializing the timestamp information for the first round of optimization. The system will sequentially traverse each processing result queue in the order A→B→C→D→E. Taking the timestamp of the first data packet in queue A as the benchmark, it will traverse each data in each other data source queue, searching for data whose time difference with the timestamp is within the threshold range in each data source queue. If any queue B, C, D, or E does not find the data, it will wait for the next cycle to continue traversing and searching for the missing queue, until all queues A, B, C, D, and E have found the parameter processing result corresponding to the timestamp. This time will then be used as the time for the first round of optimization. If, after waiting for 3 cycles, there are still data source queues that have not found the data with the timestamp, it is not a problem. At this time, each data queue has accumulated data for several time cycles, and this timestamp will still be used as the time for the first round of optimization, officially starting its optimization process.

[0052] During each round of optimization, the parameter processing results for the corresponding timestamp of each time period are first retrieved from each data source queue. Only data sources that have retrieved parameter results are eligible to proceed to the next optimization step. The next step is crucial for the optimization strategy: the processing results of each parameter at that timestamp are compared horizontally. Following the principle of "majority rule," the "most numerous" processing results are selected as the final results. Based on this, a designated data source is selected for output from the "most numerous" results. The specific method is similar to the traditional optimization strategy: according to the flight arc segment where the timestamp is located and the pre-defined optimization order of telemetry data sources within that arc segment, the data source whose parameter processing results meet the requirements and rank highest in the optimization order is selected for output. At this point, the optimization processing of a certain parameter for that time period is completed.

[0053] Assuming that the data source selected in the previous selection cycle was C, the next selection cycle will perform the traversal work in the order of C→D→E→A→B to improve the efficiency of selection.

[0054] Finally, it should be noted that the above embodiments are only used to illustrate the technical solutions of the present invention and not to limit it. Although the present invention has been described in detail with reference to the above embodiments, those skilled in the art should understand that modifications or equivalent substitutions can still be made to the specific implementation of the present invention. Any modifications or equivalent substitutions that do not depart from the spirit and scope of the present invention should be covered within the protection scope of the claims of the present invention.

Claims

1. A real-time telemetry data processing system for multiple types of launch vehicles, characterized in that, It includes a system framework, a component chain configuration module, at least one data processing component chain, and an optimization processing module; The system framework is used to receive raw telemetry data streams from space-based telemetry systems and / or ground-based telemetry systems; The component chain configuration module stores the component chain configuration information corresponding to each type of rocket. The system framework dynamically calls each data processing component chain to perform data processing based on the configuration results of the component chain configuration module; The data processing component chain includes one or more data processing components that are called in sequence. The output of each data processing component carries a result type identifier and the component processing result, and serves as the input information for the next stage of the data processing component chain or data processing component. The optimization processing module is used to perform fine-grained optimization of the telemetry parameter processing results, including a timestamp alignment unit, a result comparison unit, an output determination unit, and a traversal order adjustment unit.

2. The system according to claim 1, characterized in that, The component chain configuration module stores component chain configuration information including the type of each component chain, the upstream and downstream dependencies between component chains, and the composition and calling order of data processing components within each component chain. The component chain configuration module can change the upstream and downstream data flow and calling relationship between component chains. When adapting to a new model rocket, operators can add or modify the component chain configuration through the component chain configuration module without modifying the system framework layer code to achieve real-time processing of telemetry data of the new model rocket.

3. The system according to claim 1, characterized in that, The data processing component chain includes preprocessing component A and preprocessing component B. Preprocessing component A receives the raw data stream output by the upstream system framework, and sequentially performs PDXP frame header verification, data field parsing and verification, preliminary extraction of full frame data, and full frame data verification, and outputs full frame data that has been verified without error. The preprocessing component B receives the full-frame data output by the preprocessing component A, performs the restoration and extraction of the next-level full-frame data, and forms higher-level telemetry full-frame data by deleting subframe ID and synchronization code information, identifying buffer synchronization codes, and performing full-frame verification operations.

4. The system according to claim 3, characterized in that, The preliminary extraction of full-frame data performed by preprocessing component A includes the following steps: The NextStep variable is introduced to represent the steps to be executed in the preprocessing cycle. The NextStep variable includes two enumerated values: finding the subframe synchronization code and checking whether the buffer array length is sufficient. The initial value is to find the subframe synchronization code. The system searches for a subframe that matches the subframe synchronization code in the synchronization code channel of the subframe buffer array queue, frame by frame. If the subframe is found, all subframe buffers in the buffer, including those before and within the subframe itself, are cleared. The system then checks if the buffer length reaches the subframe length Len. If the buffer length is less than Len, NextStep is set to check if the buffer array length is sufficient and the system returns to wait for subframe data. If the buffer length is greater than or equal to Len, the system checks if the synchronization code value of the subframe at position Len in the buffer is the subframe synchronization code. If the synchronization code value is not the subframe synchronization code, the first subframe in the buffer is removed and the search is repeated. If it is the subframe synchronization code, the first to Len subframes in the buffer are completely extracted to complete the initial extraction of the full frame data. Then, the buffer buffers from the first to the (Len-1)th subframe are cleared, and the Len subframe is retained.

5. The system according to claim 3, characterized in that, The full-frame data verification performed by the preprocessing component A includes subframe synchronization code correctness verification, subframe ID order verification, and subframe ID validity verification. The method for verifying the validity of the subframe ID is as follows: the difference between the subframe ID of the full frame to be verified and the previous valid full frame is denoted as ΔδID, and the difference in timestamps is denoted as δt milliseconds. Let the full frame frequency be fHz. If δt / δID equals 1000 / f, then the subframe ID is valid and the full frame is set as the previous valid full frame; otherwise, the subframe ID of the full frame is invalid.

6. The system according to claim 3, characterized in that, The preprocessing component B performs preliminary processing on the full-frame data output by the preprocessing component A, deleting the subframe IDs and synchronization code information of each subframe in the full-frame data, and appending the pre-processed full-frame data to the buffer. By traversing the buffer, the synchronization code is used to initially extract and form the original telemetry full-frame data on the rocket. The full-frame data is then verified in terms of the validity of the subframe synchronization code, the validity of the subframe ID, and the validity of the subframe ID. The full-frame data that has been verified without error is officially used as the full-frame data to be stitched and restored and handed over to the downstream module for further processing.

7. The system according to claim 1, characterized in that, The result type identifier includes ByteArray, Int / UInt, and Double types. Downstream data processing components or data processing component chains parse the output results of upstream components according to the result type identifier, enabling seamless transfer of different types of data results between component chains.

8. The system according to claim 1, characterized in that, The timestamp alignment unit of the optimization processing module uses the timestamp of the first packet of data in the first data source queue as a benchmark to search for data in other data source queues whose time difference with the timestamp is within a threshold range. If no corresponding data is found in a certain data source queue, the search continues in the next cycle until all data source queues have found the parameter processing result with the corresponding timestamp. If no data source is found after the preset maximum number of waiting rounds, the current benchmark timestamp is used as the first round of optimization time to officially start the subsequent optimization process.

9. The system according to claim 1, characterized in that, The result comparison unit retrieves the parameter processing result value corresponding to the timestamp of the current time period from each data source queue in the current optimization cycle, counts the occurrence frequency of each processing result value, and determines the processing result value with the most occurrences as the final output value according to the principle of majority rule in horizontal comparison. The output determination unit selects the data source whose parameter processing result value meets the requirements and ranks first in the selection order from the data source that generates the final output value, according to the pre-set flight arc segment and telemetry data source selection order, and outputs the data source. The traversal order adjustment unit records the data sources selected in the current cycle. In the next optimization cycle, the traversal order is adjusted to start from the selected data source and traverse each data source in sequence to improve the data hit efficiency in the optimization process.

Images