A pipelined radar data processing system based on data stream driving

Abstract

The application discloses a kind of based on data stream driving's pipelined radar data processing system, it is related to radar signal processing technical field, the system includes the point track data receiving module, point track data processing module, condensation point output module and track processing module in turn in series, constitute a primary pipeline;The system is set in each module and between adjacent module Multiple data buffer, including detection point track data buffer, intra-frame condensation data buffer, inter-frame condensation data buffer, condensation point data buffer, remaining condensation point data buffer, each data buffer is by temporarily storing the output data of its upstream module, and asynchronously provides input data for its downstream module, so that primary pipeline is logically decomposed into multiple parallel executed secondary pipeline.By pipeline decoupling and parallelization design, effectively solve the low throughput, poor real-time, poor expansibility of traditional radar data processing system.

Description

Technical Field

[0001] This invention relates to the field of radar signal processing technology, and more specifically to a data stream-driven pipelined radar data processing system. Background Technology

[0002] With the rapid evolution of modern warfare and the increasing complexity of radar detection environments, radar systems require rapid iteration and updates. Their structures, functions, and operating modes are becoming increasingly complex, leading to a sharp increase in the amount of echo data, algorithm complexity, and computational load faced by radar terminal processing systems, as well as higher requirements for data processing rates. As a key subsystem of the radar system, the radar data processing system plays a crucial role in achieving accurate target detection and stable tracking.

[0003] Existing radar data processing systems are mainly divided into two types:

[0004] I. Event-Driven Radar Data Processing System: This system is highly dependent on other radar subsystems, resulting in low understandability and maintainability of the data processing flow, leading to poor versatility and slow upgrades. Furthermore, its processing latency is unstable due to the number and priority of current events, event state management is complex, and event accumulation in complex scenarios can cause related systems to crash. This architecture also has poor adaptability to continuous data streams.

[0005] II. Radar data processing systems based on serial sequential processing: These systems face significant real-time pressure in complex data environments, easily causing data flow congestion and blocking the radar front-end system. Their integrated, coupled processing flow also hinders functional expansion and system upgrades. Furthermore, they cannot achieve multi-node task parallelism in the distributed, multi-core, heterogeneous hardware processing systems widely used in the radar field today.

[0006] Therefore, the existing event-driven architecture suffers from unstable latency, and the serial processing architecture cannot fully utilize heterogeneous computing resources, resulting in problems such as insufficient real-time performance and poor scalability when processing high data rates and continuous radar data streams. Summary of the Invention

[0007] The technical problem to be solved by the present invention is that existing radar data processing systems suffer from insufficient real-time performance and poor scalability. The purpose is to provide a data stream-driven pipelined radar data processing system that solves the above problems.

[0008] This invention is achieved through the following technical solution:

[0009] In a first aspect, the present invention provides a data stream-driven, pipelined radar data processing system, comprising:

[0010] The dot data receiving module is used to receive and parse the detected dot data from the radar front end and output valid dot data;

[0011] The dot data processing module is used to perform agglomeration processing on the effective dot data to generate final agglomeration points;

[0012] A coalescence point output module is used to filter and output target coalescence points from the final coalescence points;

[0013] The trajectory processing module is used to perform trajectory processing tasks based on the target convergence point;

[0014] The point data receiving module, the point data processing module, the convergence point output module, and the trajectory processing module are connected in series to form a primary pipeline.

[0015] Multiple data buffers include a detection point data buffer located inside the point data receiving module, an intra-frame cohesion data buffer located inside the point data processing module, an inter-frame cohesion data buffer located between the point data processing module and the cohesion point output module, a cohesion point data buffer located between the cohesion point output module and the track processing module, and a remaining cohesion point data buffer located inside the track processing module.

[0016] Each of the data buffers is used to temporarily store the output data of its upstream module and asynchronously provide input data to its downstream module, thereby logically decomposing the first-level pipeline into multiple parallel second-level pipelines.

[0017] Optionally, the dot data receiving module includes:

[0018] A data receiving thread is used to write the received detection point data to the tail of the detection point data buffer;

[0019] The data parsing thread is used to extract the corresponding detection point data from the head of the detection point data buffer, parse and verify it, and generate valid point data.

[0020] The data receiving thread and the data parsing thread are executed in parallel, forming the first secondary pipeline.

[0021] Optionally, the detection point data buffer is a circular buffer, which is accessed and managed through a data head pointer and a data tail pointer;

[0022] The data receiving thread is specifically used to: write the received detection point data into the detection point data buffer at the position indicated by the data tail pointer, and update the data tail pointer;

[0023] The data parsing thread is specifically used to: extract a single-frame length of detection point data from the position indicated by the data head pointer in the detection point data buffer, parse and verify it, output valid point data that has passed the verification, and update the data tail pointer;

[0024] The acquisition and update operations of the data head pointer and the data tail pointer are protected by a mutex lock.

[0025] Optionally, the dot data receiving module includes:

[0026] The first point processing thread is used to perform point aggregation processing on the valid point data of a single frame, generate aggregated points within the coherent processing interval and store them in the intra-frame aggregated data buffer.

[0027] The second spot processing thread is used to extract all coherent processing intervals of the same beam from the intra-frame cohesion data buffer, perform intra-beam and inter-beam spot cohesion processing, and generate the final cohesion point.

[0028] The first trace processing thread and the second trace processing thread are executed in parallel, forming a second two-stage pipeline.

[0029] Optionally, the number of the first and second point processing threads can be dynamically configured based on at least one of the following parameters: radar operating waveform mode, computing resource status of the deployment platform, real-time requirements of the radar data processing system, and the proportion of the capacity occupied by the data already stored in the intra-frame cohesive data buffer.

[0030] Optionally, the first dot processing thread is specifically used for:

[0031] The effective point data of a single frame is parsed to obtain radar status control words and detection point information;

[0032] Calculate the parameters of the target point based on the radar status control word and the detection point information;

[0033] Based on the parameters of the target point trace, point trace association and aggregation processing are performed on the effective point trace data of the single frame to generate aggregated points within the coherent processing interval;

[0034] The cohesion points within the coherent processing interval are stored in the intra-frame cohesion data buffer.

[0035] Optionally, the second dot processing thread is specifically used for:

[0036] Monitor the radar status control word associated with each aggregation point in the intra-frame aggregation data buffer;

[0037] Based on the beam identifier and waveform sequence identifier information in the radar status control word, determine whether the convergence points within the coherent processing interval of each beam have arrived.

[0038] When it is determined that the cohesive point data within the coherent processing interval of a certain beam has arrived, all cohesive points within the coherent processing interval of that beam are extracted from the intra-frame cohesive data buffer.

[0039] Perform point correlation and agglomeration processing on all coherent processing intervals belonging to the same beam to generate beam-in-beam agglomeration points.

[0040] The intra-beam cohesion points between adjacent beams are correlated and coheded to generate the final cohesion point.

[0041] Optionally, the second spot processing thread is also used to write the final cohesion point into the inter-frame cohesion data buffer;

[0042] The cohesion point output module includes a cohesion point output thread, which is used to extract the target cohesion point of the output sector from the inter-frame cohesion data buffer and output the target cohesion point to the display control device for visualization.

[0043] The second point processing thread and the agglomeration point output thread are executed in parallel, forming a third secondary pipeline.

[0044] Optionally, the cohesion point output thread is further configured to write the target cohesion point extracted from the output sector to the tail of the cohesion point data buffer.

[0045] The trajectory processing module includes a stable trajectory management thread, which is used to: extract the target aggregation point of the corresponding processing sector from the head of the aggregation point data buffer;

[0046] The convergence point output thread and the stable trajectory management thread are executed in parallel, forming a fourth secondary pipeline.

[0047] Optionally, the stable track management thread is also used for:

[0048] The current task type is determined based on the radar status control word associated with the target convergence point of the processing sector;

[0049] Based on the current task type, extract the corresponding current stable track from the stable track data pool;

[0050] Associate the target convergence point of the processing sector with the current stable trajectory;

[0051] Based on the successfully associated convergence points, the current stable trajectory is updated, its disappearance is determined, filtered, predicted, and output.

[0052] Place the remaining agglomeration points that failed to associate into the remaining agglomeration point data buffer;

[0053] The track processing module also includes a temporary track management thread, which is used for:

[0054] Extract the remaining cohesion points for the current period from the remaining cohesion point data buffer;

[0055] Associate the remaining condensation points of the current cycle with the temporary track;

[0056] If the association is successful, the temporary trajectory is updated and predicted based on the remaining aggregation points of the current period;

[0057] If the association fails, a new temporary track is added based on the remaining aggregation points of the current cycle;

[0058] The stable trajectory management thread and the temporary trajectory management thread are executed in parallel, forming the fifth secondary pipeline.

[0059] Compared with the prior art, the present invention has the following advantages and beneficial effects:

[0060] This application provides a data flow-driven pipelined radar data processing system, employing a two-layer architecture combining a modular first-level pipeline and a data buffer-driven second-level parallel pipeline. By setting dedicated data buffers within each module and between adjacent modules, the complete processing chain is decomposed into multiple parallel-executable second-level pipelines. This allows tasks such as data reception, parsing, aggregation, and track processing to be executed asynchronously and overlappingly, effectively hiding I / O latency and inter-module communication overhead, thereby improving the overall processing efficiency and real-time performance of the radar data processing system. Furthermore, the system is clearly divided into four main modules: point track reception, point track processing, aggregation output, and track processing, connected through a standardized data buffer interface. This design results in functional cohesion among modules, clear interfaces, and low coupling. Algorithm upgrades, parameter adjustments, or troubleshooting of any module can be performed independently with minimal impact on the normal operation of other modules, significantly reducing the complexity of system development, debugging, and maintenance, thereby enhancing the scalability of the radar data processing system. Attached Figure Description

[0061] To more clearly illustrate the technical solutions of the exemplary embodiments of the present invention, the accompanying drawings used in the embodiments will be briefly described below. It should be understood that the following drawings only show some embodiments of the present invention and should not be considered as a limitation of the scope. For those skilled in the art, other related drawings can be obtained based on these drawings without creative effort. In the drawings:

[0062] Figure 1 A schematic diagram of the overall framework of a data stream-driven, pipelined radar data processing system provided in an embodiment of this application;

[0063] Figure 2 A schematic diagram illustrating the workflow of the dot data receiving module provided in this application embodiment;

[0064] Figure 3 A schematic diagram of the workflow of the dot data processing module provided in the embodiments of this application;

[0065] Figure 4 A schematic diagram illustrating the workflow of the condensation point output module provided in this application embodiment;

[0066] Figure 5 A schematic diagram illustrating the workflow of the track processing module provided in this application embodiment;

[0067] Figure 6 A schematic diagram illustrating the verification effect of a low-speed drone provided in an embodiment of this application;

[0068] Figure 7 A schematic diagram illustrating the verification effect of a single constant-speed UAV provided in an embodiment of this application;

[0069] Figure 8 This is a schematic diagram illustrating the verification effect of the dual constant-speed UAV provided in the embodiments of this application. Detailed Implementation

[0070] To make the objectives, technical solutions, and advantages of the present invention clearer, the present invention will be further described in detail below with reference to the embodiments and accompanying drawings. The illustrative embodiments and descriptions of the present invention are only used to explain the present invention and are not intended to limit the present invention.

[0071] In typical radar operating scenarios, the radar front-end typically generates and transmits detection point data packets periodically, using each coherent processing interval (CPI), i.e., each frame, as a unit. The points in the data packets are arranged in order of range units (from smallest to largest or from largest to smallest). As the radar antenna sequentially scans in azimuth and elevation dimensions, the radar data processing system continuously receives and processes the detection point data packets for each CPI in sequence. To cope with this high real-time, continuous streaming data input, embodiments of this application provide a pipelined radar data processing system based on data stream driving. This system uses the sequentially arriving detection point data stream as the driving source and employs a pipelined architecture for efficient processing, aiming to improve system throughput, reduce processing latency, and ensure the correct timing of data processing.

[0072] Please refer to Figure 1 This is a schematic diagram of the overall framework of a data stream-driven pipelined radar data processing system provided in an embodiment of this application. The system includes a point data receiving module, a point data receiving module, a convergence point output module, and a track processing module connected in series, forming a single-stage pipeline. The function of each module is described below.

[0073] Dot data receiving module: Used to receive and parse the detected dot data from the radar front end, and output valid dot data.

[0074] Point data processing module: Used to perform agglomeration processing on valid point data to generate final agglomeration points.

[0075] Condensation point output module: Used to filter and output target condensation points from the final condensation points.

[0076] Track processing module: Used to perform track processing tasks based on the target convergence point.

[0077] To achieve efficient decoupling and parallel processing between modules, the system introduces multiple data buffers, specifically including:

[0078] A detection point data buffer is set inside the point data receiving module;

[0079] An intra-frame aggregated data buffer is set within the dot data processing module;

[0080] An inter-frame agglomeration data buffer is set between the dot data processing module and the agglomeration point output module;

[0081] A convergence point data buffer is set between the convergence point output module and the trajectory processing module;

[0082] The remaining aggregation point data buffer is set inside the track processing module.

[0083] Each data buffer temporarily stores the output data of its upstream module and asynchronously provides input data to its downstream module. Through this asynchronous buffering mechanism, the original single-stage pipeline is logically decomposed into multiple parallel second-stage pipelines. This greatly overlaps the computation time and I / O wait time of different processing stages, thereby significantly improving the overall processing efficiency and real-time performance of the system.

[0084] In one possible embodiment, the dot data receiving module includes:

[0085] The data receiving thread is used to write the received detection point data to the end of the detection point data buffer;

[0086] The data parsing thread is used to extract the corresponding detection point data from the head of the detection point data buffer, parse and verify it, and generate valid point data.

[0087] The data receiving thread and the data parsing thread execute in parallel, forming the first secondary pipeline.

[0088] In practice, the data receiving thread acts as the producer, running continuously to receive raw detection point data packets from the radar front end and sequentially writes successfully received packets to the end of the detection point data buffer. The data parsing thread acts as the consumer, running independently and in parallel, extracting detection point data packets sequentially from the head of the detection point data buffer and performing parsing and verification. The detection point data buffer acts as a bridge between the two, managing data using a first-in, first-out (FIFO) principle.

[0089] The radar data processing system can dynamically adjust or initialize the size of the detection point data buffer based on the real-time point data flow rate, the processing capacity of downstream modules, and the available memory resources of the deployment platform, ensuring that the system can maintain the best balance between memory usage efficiency and data buffering capacity under different load scenarios.

[0090] In this embodiment, by introducing a detection point data buffer, a two-stage pipeline is constructed in parallel by the data receiving thread and the data parsing thread. Once the data receiving thread receives a frame of point data, it can immediately write it to the end of the detection point data buffer and then receive the next frame of point data. Meanwhile, the data parsing thread can independently and asynchronously extract a frame of point data from the beginning of the detection point data buffer for parsing, thereby significantly reducing the processing latency of the point data receiving module.

[0091] To ensure the accuracy of data processing semantics and the scalability of the system, this application defines a unified detection point data packet format. Each data packet is divided into a data packet header and a data area. The data packet header is the radar status control word, including parameters such as radar operating mode, antenna beam azimuth / elevation angle, and waveform parameters. The waveform parameters include sampling frequency, pulse repetition interval, pulse number, beam identifier, and waveform sequence identifier information (pulse group number / total number of pulse groups, chip number / total number of chips). These parameters are the key basis for downstream processing modules to dynamically configure algorithm parameters, allocate resources, and control logic. The data area contains detection point information, including parameters such as distance, azimuth, elevation, and Doppler.

[0092] In one possible embodiment, please refer to Figure 2 This is a schematic diagram illustrating the workflow of the dot data receiving module provided in this embodiment. The dot data detection buffer is implemented as a circular buffer at the software level, and access and management are performed through a data head pointer and a data tail pointer.

[0093] The data receiving thread is specifically used to: receive detection point data sent by the radar front end at every pulse repetition interval according to the pre-configured communication protocol; write the received detection point data into the detection point data buffer at the position indicated by the data tail pointer, and update the data tail pointer.

[0094] The data parsing thread is specifically used to: extract a single-frame length of detection point data from the position indicated by the data header pointer in the detection point data buffer, parse and verify it, output the valid point data that passes the verification, and update the data header pointer.

[0095] In practical implementation, the point data receiving module is designed with multi-protocol communication support and dynamic switching capability. This module natively supports multiple mainstream high-speed industrial communication standards such as RapidIO, UDP, TCP, and PCIe, and can achieve dynamic switching of communication protocols through simple external configuration, realizing seamless integration between the radar data processing system and various radar front-end models, and improving the scalability and versatility of the radar data processing system.

[0096] The workflow of the data receiving thread is as follows: First, it continuously receives the detection point data packets from the radar front end according to the pre-configured communication protocol. Then, it obtains the data tail pointer of the detection point data buffer, stores the received data in the position pointed to by the data tail pointer, and finally updates the data tail pointer.

[0097] The workflow of the data extraction and parsing thread is as follows: First, obtain the data header pointer of the detection point data buffer, read a single frame of data from the position pointed to by the data header pointer according to the pre-configured communication protocol, and then update the data header pointer. Next, verify the frame of data. If the verification fails, discard the erroneous point data; if the verification passes, output the valid point data, take the detected point as the current point data to be processed, and proceed to the next processing step.

[0098] In this embodiment, a circular buffer, coupled with precise head and tail pointer management, ensures a first-in, first-out (FIFO) processing order for the data. This allows the point data stream from the radar front end, which has strict spatiotemporal correlations, to be transmitted flawlessly to subsequent processing stages according to its original scanning order, preventing track errors caused by data out-of-order or loss from the source. Furthermore, the acquisition and updating operations of the data head and tail pointers are protected by mutex locks, ensuring data consistency under concurrent access and preventing errors or loss.

[0099] In one possible embodiment, please refer to Figure 3This is a schematic diagram illustrating the workflow of the dot data processing module provided in this embodiment. The dot data receiving module includes a dot parsing module, an intra-frame aggregation module, an inter-frame aggregation module, and a dot output module. The functions of each module are described below.

[0100] The target point resolution module receives valid target point data from the target point data receiving module. Based on the radar status control word and the detected target point information, it calculates the parameters of the target target point, including range resolution, velocity resolution, and parameters such as the target target point's range, azimuth, elevation, velocity, and amplitude.

[0101] The intra-frame aggregation module is responsible for the correlation and aggregation processing of detection points of the same target within the beam in the range dimension and Doppler dimension.

[0102] The inter-frame convergence module is responsible for the association and convergence processing of the same target's traces in the range, azimuth, and elevation dimensions between adjacent beams, generating the final convergence point.

[0103] The point output module is responsible for outputting the final condensation point to the subsequent condensation point output module.

[0104] In this embodiment of the application, the point data processing module is designed in a modular way, which allows for rapid functional expansion, such as adding deblurring and point filtering modules.

[0105] In one possible embodiment, a two-stage parallel pipeline architecture is adopted. The core processing logic of the point processing module and the intra-frame aggregation module is integrated and executed sequentially through the first point processing thread, and the core processing logic of the inter-frame aggregation module and the point output module is integrated and executed sequentially through the second point processing thread, as follows:

[0106] The first point processing thread is used to perform point aggregation processing on the valid point data of a single frame, generate aggregated points within the coherent processing interval, and store them in the intra-frame aggregated data buffer; the second point processing thread is used to extract all aggregated points within the coherent processing interval of the same beam from the intra-frame aggregated data buffer, perform intra-beam and inter-beam point aggregation processing, and generate the final aggregated points; wherein, the first point processing thread and the second point processing thread are executed in parallel, forming the second secondary pipeline.

[0107] In this embodiment, the dot clustering process is decomposed into two threads: the first dot clustering thread focuses on the rapid clustering of single-frame data, generating high-quality clustered points within the coherent processing interval; the second dot clustering thread focuses on cross-frame and cross-beam correlation clustering, generating the final target clustered points. By introducing an intra-frame clustering data buffer, a two-stage pipeline is constructed in which the first and second dot clustering threads execute in parallel, significantly reducing the processing latency of the dot clustering data processing module.

[0108] In one possible embodiment, the number of the first and second point processing threads can be dynamically configured based on at least one of the following parameters: radar operating waveform mode, computing resource status of the deployment platform, real-time requirements of the radar data processing system, and the proportion of the capacity occupied by the data already stored in the intra-frame cohesive data buffer.

[0109] (1) Radar operating waveform mode: refers to the transmitted signal waveform and scanning method currently used by the radar front end, such as: high pulse repetition frequency search, medium pulse repetition frequency tracking, single pulse angle measurement, frequency agility, etc. Different modes directly determine the amount of input data, the density of points, and the complexity of the processing algorithm per unit time.

[0110] For example, in the high pulse repetition frequency search mode, the data throughput is extremely high. At this time, the number of the first trace processing threads can be increased to improve the aggregation speed of single-frame traces through parallel processing and maintain high input throughput.

[0111] (2) The computing resource status of the deployment platform: refers to the real-time load indicators of the hardware platform running this radar data processing system, including overall CPU utilization, idle status of each core, available memory capacity, cache hit rate, etc.

[0112] For example, when the platform detects idle computing cores and a light overall load, the number of the first and / or second trace processing threads can be increased to convert idle resources into processing power and improve performance. Conversely, when platform resources are scarce or need to be reduced in frequency to save energy, the number of the first and / or second trace processing threads can be reduced to avoid system overload and ensure stable operation.

[0113] (3) Real-time requirements of radar data processing system: refers to the end-to-end processing delay index that the system needs to meet in the current task phase.

[0114] For example, wide-area search and surveillance can tolerate higher latency to optimize detection performance; while fire control or precision tracking requires extremely low latency to ensure the real-time performance of the control loop.

[0115] When the system enters high real-time mode, the configuration strategy prioritizes minimizing pipeline latency. To this end, the number of second track processing threads can be dynamically increased to reduce queuing time in critical stages such as beamforming, ensuring that track information can be updated and output quickly.

[0116] (4) The proportion of the capacity occupied by the data already stored in the intra-frame cohesive data buffer: obtained by calculation (currently stored data amount / total buffer capacity).

[0117] When this ratio continues to be higher than the set high threshold, it indicates that the production speed of the first trace processing thread is continuously higher than the consumption speed of the second trace processing thread. The number of second trace processing threads can be increased to improve downstream consumption capacity and alleviate backlog.

[0118] When this ratio remains below the set low threshold, it indicates insufficient production speed or excessive consumption speed. If system resources are strained at this time, the number of second trace processing threads can be reduced to free up resources; if throughput needs to be increased and upstream data is sufficient, the number of first trace processing threads can be increased.

[0119] In this embodiment, a dynamic configuration mechanism driven by multi-dimensional parameters achieves a leap from "static resource allocation" to "dynamic intelligent scheduling." This enables the system to automatically adapt to different radar missions, hardware environments, and performance targets, achieving an optimal balance between resource utilization, real-time processing, system stability, and energy efficiency. This significantly improves the overall performance and applicability of the radar data processing system in complex and ever-changing scenarios.

[0120] In one possible embodiment, the first dot processing thread is specifically used for:

[0121] The effective point data of a single frame is parsed to obtain the radar status control word and the detected point information; the parameters of the target point are calculated based on the radar status control word and the detected point information; based on the parameters of the target point, the effective point data of a single frame is subjected to point association and aggregation processing to generate aggregated points within the coherent processing interval; the aggregated points within the coherent processing interval are stored in the intra-frame aggregated data buffer.

[0122] In the specific implementation process, the first point trace processing thread receives valid point trace data streams from the upstream point trace data receiving module. It first parses each frame of valid point trace data, extracting the radar status control word from the data packet header according to a predefined data packet format. Then, using the parsed radar status control word as the system reference, it performs coordinate transformation and parameter calculation on the extracted detection point trace information to calculate the parameters of each target point trace. Next, in the two-dimensional processing space composed of the range dimension and Doppler dimension, based on the spatial proximity and motion consistency between the parameters of the target point traces, multiple points traces that may originate from the same real target are associated to form point trace clusters. Finally, for each successfully associated point trace cluster, a predetermined data fusion algorithm (such as weighted average or centroid calculation) is used to generate a representative point trace with higher accuracy and reliability, namely, the coherent processing interval convergence point. All coherent processing interval convergence points generated in this frame and the associated radar status control words are written together into a shared intra-frame convergence data buffer. After completing all processing for this frame, the first dot processing thread immediately enters the next work cycle to start processing the valid dot data for the next frame, thus achieving uninterrupted pipeline processing.

[0123] In this embodiment, the first point processing thread encapsulates all necessary calculations (parameter solving, correlation aggregation) from the raw data to the intermediate convergence point. This allows the subsequent second point processing thread to focus entirely on higher-level fusion logic across frames and beams, without needing to concern itself with the data processing details within a single frame. This functional decomposition and interface standardization reduces the coupling between system modules and improves the system's maintainability, testability, and algorithm evolution capabilities.

[0124] In one possible embodiment, the second dot processing thread is specifically used for:

[0125] The system monitors the radar status control words associated with each convergence point in the intra-frame convergence data buffer; based on the beam identifier and waveform sequence identifier information in the radar status control words, it determines whether the convergence points within the coherent processing interval of each beam are complete; when it is determined that the convergence point data within the coherent processing interval of a certain beam are complete, it extracts all convergence points within the coherent processing interval of that beam from the intra-frame convergence data buffer; it performs point trace association and convergence processing on all convergence points within the coherent processing interval belonging to the same beam to generate intra-beam convergence points; it performs association and convergence processing on the intra-beam convergence points between adjacent beams to generate the final convergence points.

[0126] In practice, the second point processing thread continuously and asynchronously monitors the intra-frame cohesive data buffer. For each cohesive point within the buffer during a coherent processing interval, the thread reads its associated radar status control word and extracts key identification information from it.

[0127] Beam identification: Determines which beam (azimuth / elevation) the focal point belongs to.

[0128] Waveform sequence identification information: Extract the sequence position information of the condensation point within the current beam irradiation cycle, such as pulse group number / total number of pulse groups or chip number / total number of chips.

[0129] When a waveform sequence identifier under a certain beam is detected, indicating that the data of the last coherent processing interval of that beam has been received (e.g., the current pulse group number equals the total number of pulse groups, or the current chip number equals the total number of chips), it is determined that all cohesive points within the coherent processing intervals of that beam have arrived. All cohesive points within the coherent processing intervals belonging to that beam are extracted from the intra-frame cohesive data buffer. These cohesive points belonging to the same beam but from different coherent processing intervals are associated. Cohesive processing is performed on the successfully associated cohesive points within the coherent processing intervals to generate intra-beam cohesive points.

[0130] After completing intra-beam convergence of a certain number of adjacent beams (e.g., processing one azimuth scan line), the intra-beam convergence points from adjacent beams in the azimuth and / or elevation dimensions are correlated in a three-dimensional space consisting of range, azimuth, and elevation dimensions. For points successfully correlated across beams, convergence processing is performed in three-dimensional space to ultimately generate the final convergence point representing the target.

[0131] In this embodiment, by monitoring the waveform sequence identification information in the radar status control word, it is intelligently determined that all cohesive point data within the same coherent processing interval (CPI) of the same beam are complete and ready in the intra-frame cohesive data buffer. The second point processing thread is in a low-power waiting state when the data is incomplete, without occupying computing resources. It is only precisely triggered and put into full-speed calculation when all the data is available, eliminating meaningless polling overhead and idle waiting time. This ensures that each processing task is started under the premise that the input data is complete, providing a reliable data foundation for executing complex intra-beam cohesive algorithms and avoiding incomplete processing results or decreased accuracy due to missing data.

[0132] In one possible embodiment, the second point processing thread is also used to write the final cohesion point into the inter-frame cohesion data buffer; the cohesion point output module includes a cohesion point output thread, which is used to extract the target cohesion point of the output sector from the inter-frame cohesion data buffer and output the target cohesion point to the display control device for visualization; wherein, the second point processing thread and the cohesion point output thread are executed in parallel, forming a third secondary pipeline.

[0133] In the specific implementation process, after generating the final convergence point, the second point processing thread writes the final convergence point into the inter-frame convergence data buffer. The convergence point output thread filters the target convergence points located within the pre-defined output sector configuration (e.g., a specific azimuth, elevation, or distance range) from the inter-frame convergence data buffer. These target convergence points are then formatted and encapsulated according to a target display protocol predefined and strictly followed by the accompanying display control device, and sent to the display control device for visualization via the communication interface.

[0134] In this embodiment, by introducing an inter-frame cohesive data buffer, a two-stage pipeline is constructed in which the second point processing thread and the cohesive point output thread execute in parallel. Once the second point processing thread generates a cohesive point, it can immediately write it into the inter-frame cohesive data buffer and return to process the next batch of data. Meanwhile, the cohesive point output thread can independently and asynchronously extract cohesive points from the inter-frame cohesive data buffer and drive the display, thereby significantly shortening the end-to-end latency from the point data processing module to the cohesive point output module.

[0135] In one possible embodiment, the convergence point output thread is also used to write the target convergence point extracted from the output sector to the tail of the convergence point data buffer; the trajectory processing module includes a stable trajectory management thread, which is used to extract the target convergence point of the corresponding processing sector from the head of the convergence point data buffer; wherein, the convergence point output thread and the stable trajectory management thread are executed in parallel, forming a fourth secondary pipeline.

[0136] Please refer to Figure 4 This is a schematic diagram illustrating the workflow of the convergence point output module provided in this embodiment. The convergence point data buffer is implemented as a buffer queue at the software level, and access and management are performed through the queue head pointer and queue tail pointer.

[0137] The workflow of the cohesion point output thread is as follows: obtain the queue tail pointer of the cohesion point data buffer; write the target cohesion point extracted from the output sector into the cohesion point data buffer at the position indicated by the queue tail pointer, and update the queue tail pointer.

[0138] The workflow of the stable track management thread is as follows: obtain the queue head pointer of the convergence point data buffer; extract the target convergence point of the current processing sector from the position indicated by the queue head pointer in the convergence point data buffer, and update the queue head pointer.

[0139] In this embodiment, a two-stage pipeline is constructed by introducing a convergence point data buffer, in which the convergence point output thread and the track processing thread execute in parallel. Once the convergence point output thread extracts the target convergence point, it immediately writes it into the convergence point data buffer and returns to process the next batch of data. Meanwhile, the stable track management thread can independently and asynchronously extract convergence points from the convergence point data buffer for subsequent track processing, thereby significantly reducing the end-to-end latency from the convergence point output module to the track processing module.

[0140] In one possible embodiment, the size of the convergence point data buffer can be dynamically configured based on at least one of the following parameters: the processing latency difference between the point data processing module and the track processing module, the resource utilization rate of the radar data processing system, and the total resources of the deployment platform.

[0141] (1) Processing delay difference between point data processing module and track processing module: refers to the difference between the average time or the longest time required for point data processing module and track processing module to complete one full processing under the same input load.

[0142] The greater the delay difference, the more mismatched the speeds of the point data processing module and the track processing module are. A larger capacity convergence point data buffer needs to be configured to smooth out this speed difference and absorb instantaneous fluctuations.

[0143] (2) Resource utilization rate of radar data processing system: refers to the real-time resource consumption status of the deployment platform of this radar data processing system, including CPU utilization rate, memory utilization rate, I / O utilization rate, cache hit rate, etc.

[0144] When the overall system load is high, the processing latency may increase and become more unstable. A larger capacity convergence point data buffer can be configured to provide greater fault tolerance and resist short-term processing delays caused by resource contention.

[0145] (3) Total resources of the deployment platform: refers to the upper limit of the physical hardware specifications of the deployment platform, including the total number of CPU cores / threads, total physical memory capacity, total cache size, number of PCIe channels, etc.

[0146] On resource-rich deployment platforms, a larger converging point data buffer should be allocated within the limits of memory capacity. On resource-constrained deployment platforms, a balance must be struck between performance and memory overhead, requiring precise design to allocate a smaller converging point data buffer.

[0147] In this embodiment, by comprehensively considering latency differences (performance matching requirements), resource utilization (real-time health status), and total resource volume (physical constraints), the system can intelligently determine the optimal capacity of the convergence point data buffer. This transforms the buffer from a static component into an intrinsic adaptive flow regulator within the system. It not only optimizes the data flow efficiency from point traces to flight paths but also constructs a dynamic, system-state-based flow control defense, effectively preventing systemic performance degradation or even crashes caused by partial congestion or resource contention in the data processing pipeline. This significantly improves the system's adaptability, robustness, and deployment flexibility in complex and ever-changing environments.

[0148] In one possible embodiment, please refer to Figure 5 This is a schematic diagram illustrating the workflow of the track processing module provided in this embodiment. The track processing module includes a track association module, a track initiation module, a track update module, a track termination module, and a track output module. The functions of each module are described below.

[0149] The track association module extracts convergence points and track data based on radar status control words, completes the association processing between point tracks and stable tracks, and realizes target trajectory updates. The track initiation module generates stable tracks through the association processing of point tracks and temporary tracks, and completes the detection of new targets and the updating of temporary tracks. The track update module completes the status update of stable tracks in the current processing cycle, track filtering, and prediction of the next target position. The track disappearance module performs stable track disappearance processing for lost, concealed, or disappeared targets. The track output module outputs updated stable track data to the display and control equipment for target status observation.

[0150] In one possible implementation, a two-stage parallel pipeline architecture is employed. A stable track management thread handles the updating of target status, position prediction, and organization of stable tracks within the current cycle. A temporary track management thread handles the batching, correlation, de-batching, and conversion to stable tracks for temporary tracks. Specifically:

[0151] The stable track management thread is used for: extracting the target convergence point of the corresponding processing sector from the header of the convergence point data buffer; determining the current task type based on the radar status control word associated with the target convergence point of the processing sector; extracting the corresponding current stable track from the stable track data pool based on the current task type; associating the target convergence point of the processing sector with the current stable track; updating, determining the disappearance of the current stable track, filtering and predicting based on the successfully associated convergence points; and placing the remaining convergence points that failed to associate into the remaining convergence point data buffer.

[0152] The temporary track management thread is used to: extract the remaining cohesion points of the current period from the remaining cohesion point data buffer; associate the remaining cohesion points of the current period with temporary tracks; if the association is successful, update and predict the temporary tracks based on the remaining cohesion points of the current period; if the association fails, add new temporary tracks based on the remaining cohesion points of the current period.

[0153] Among them, the stable track management thread and the temporary track management thread are executed in parallel, forming the fifth secondary pipeline.

[0154] In this embodiment, the track processing process is decomposed into two threads: a stable track management thread is specifically responsible for maintaining the continuous tracking and status updates of existing high-value targets (stable tracks); and a temporary track management thread is responsible for processing remaining points not associated with stable tracks, and for discovering new targets and maintaining temporary tracks. By introducing a remaining aggregate point data buffer, a fifth secondary pipeline is constructed in which the stable track management thread and the temporary track management thread execute in parallel, significantly reducing the processing latency of the track processing module.

[0155] To verify the actual performance and effect of the data stream-driven pipelined radar data processing system provided in this application, it was deployed on a standard CPU processing platform. The system was configured to receive point data from the radar front-end via the UDP protocol. Field measurement data from a certain L-band three-coordinate two-dimensional digital array antenna radar was used as input to verify the system. In the experiment, the radar front-end operated in the search mission sector scanning mode to detect low-altitude flying UAV targets. The system's target focusing, tracking, and display effects were observed in real time using the accompanying display and control software.

[0156] like Figure 6As shown, the radar scanned within the sector [-30°, 30°] and the system successfully tracked a low-speed UAV (target number 1, altitude 100m, speed approximately 1m / s) within a 1km range and at an azimuth of approximately 356°. The results demonstrate that this system can effectively process point data from low-speed, low-altitude targets, forming and maintaining stable tracks.

[0157] like Figure 7 As shown, the radar scanned within the sector [-45°, 45°] and successfully tracked a UAV flying at a normal speed near azimuth 312°. The target batch number was 26 (altitude 400m, speed approximately 13m / s). Simultaneously, it also tracked moving targets such as electric vehicles and cars within the detection range. This result fully demonstrates that the system possesses excellent target resolution, track initiation and maintenance capabilities, and stable data processing throughput in real-world complex scenarios with multiple targets and clutter.

[0158] like Figure 8 As shown, the radar scanned within the sector [-45°, 45°], and the system successfully achieved stable parallel tracking of two targets: UAV 1 target batch number 72 (altitude 200m, speed approximately 11m / s) was tracked near azimuth 355°, and UAV 2 target batch number 77 (altitude 380m, speed approximately 11m / s) was tracked near azimuth 45°. This result directly verifies the efficiency of the multi-stage parallel pipeline architecture of this system, demonstrating its ability to process multiple target point flows in real time and in parallel, forming independent and unmixed accurate tracks for each target.

[0159] In summary, this application also provides a data stream-driven pipelined radar data processing system. The system redesigns the radar data processing system architecture and, through hierarchical pipelined processing, first implements data stream reception buffering and segmented processing to adapt to the continuous input of front-end radar data. Then, based on the characteristics of the input data, it implements inter-beam and intra-beam point track data processing. Next, it implements convergent point data stream output buffering to construct asynchronous processing conditions for point tracks. Finally, it implements track data processing for different cycles and stages, completing continuous tracking and display of multiple targets within the radar detection range. Simultaneously, each processing stage forms a pipeline sequentially. Through multi-level pipeline construction, parallel processing is achieved, improving data throughput and reducing end-to-end processing latency. Furthermore, each stage continuously compresses the amount of data involved in processing, effectively reducing the data volume and complexity at each stage and minimizing processing latency. The loosely coupled data stream interface improves the system's flexibility and versatility, supporting rapid integration of new radar front-ends. Furthermore, the modular design and dynamic resource allocation of the radar data processing system were realized, which effectively improved the system's real-time processing capability for high-speed, high-dimensional radar data, while also taking into account the system's flexibility and versatility.

[0160] It should be noted that, in this document, the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or system that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process, method, article, or system. Unless otherwise specified, an element defined by the phrase "comprising one..." does not exclude the presence of other identical elements in the process, method, article, or system that includes that element.

[0161] The sequence numbers of the embodiments in this application are for descriptive purposes only and do not represent the superiority or inferiority of the embodiments.

[0162] The above specific embodiments further illustrate the purpose, technical solution, and beneficial effects of the present invention. It should be understood that the above are merely specific embodiments of the present invention and are not intended to limit the scope of protection of the present invention. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of the present invention should be included within the scope of protection of the present invention.

Claims

1. A data stream-driven, pipelined radar data processing system, characterized in that, include: The dot data receiving module is used to receive and parse the detected dot data from the radar front end and output valid dot data; The dot data processing module is used to perform agglomeration processing on the effective dot data to generate final agglomeration points; A coalescence point output module is used to filter and output target coalescence points from the final coalescence points; The trajectory processing module is used to perform trajectory processing tasks based on the target convergence point; The point data receiving module, the point data processing module, the convergence point output module, and the trajectory processing module are connected in series to form a primary pipeline. Multiple data buffers include a detection point data buffer located inside the point data receiving module, an intra-frame cohesion data buffer located inside the point data processing module, an inter-frame cohesion data buffer located between the point data processing module and the cohesion point output module, a cohesion point data buffer located between the cohesion point output module and the track processing module, and a remaining cohesion point data buffer located inside the track processing module. Each of the data buffers is used to temporarily store the output data of its upstream module and asynchronously provide input data to its downstream module, thereby logically decomposing the first-level pipeline into multiple parallel second-level pipelines.

2. The data stream-driven pipelined radar data processing system according to claim 1, characterized in that, The dot data receiving module includes: A data receiving thread is used to write the received detection point data to the tail of the detection point data buffer; The data parsing thread is used to extract the corresponding detection point data from the head of the detection point data buffer, parse and verify it, and generate valid point data. The data receiving thread and the data parsing thread are executed in parallel, forming the first secondary pipeline.

3. The data stream-driven pipelined radar data processing system according to claim 2, characterized in that, The detection point data buffer is a circular buffer, which is accessed and managed through a data head pointer and a data tail pointer. The data receiving thread is specifically used to: write the received detection point data into the detection point data buffer at the position indicated by the data tail pointer, and update the data tail pointer; The data parsing thread is specifically used to: extract a single-frame length of detection point data from the position indicated by the data head pointer in the detection point data buffer, parse and verify it, output valid point data that has passed the verification, and update the data tail pointer; The acquisition and update operations of the data head pointer and the data tail pointer are protected by a mutex lock.

4. The data stream-driven pipelined radar data processing system according to claim 1, characterized in that, The dot data receiving module includes: The first point processing thread is used to perform point aggregation processing on the valid point data of a single frame, generate aggregated points within the coherent processing interval and store them in the intra-frame aggregated data buffer. The second spot processing thread is used to extract all coherent processing intervals of the same beam from the intra-frame cohesion data buffer, perform intra-beam and inter-beam spot cohesion processing, and generate the final cohesion point. The first trace processing thread and the second trace processing thread are executed in parallel, forming a second two-stage pipeline.

5. A data stream-driven, pipelined radar data processing system according to claim 4, characterized in that, The number of the first point processing thread and the second point processing thread is dynamically configured based on at least one of the following parameters: radar operating waveform mode, computing resource status of the deployment platform, real-time requirements of the radar data processing system, and the proportion of the capacity occupied by the data already stored in the intra-frame cohesive data buffer.

6. A data stream-driven, pipelined radar data processing system according to claim 4, characterized in that, The first dot processing thread is specifically used for: The effective point data of a single frame is parsed to obtain radar status control words and detection point information; Calculate the parameters of the target point based on the radar status control word and the detection point information; Based on the parameters of the target point trace, point trace association and aggregation processing are performed on the effective point trace data of the single frame to generate aggregated points within the coherent processing interval; The cohesion points within the coherent processing interval are stored in the intra-frame cohesion data buffer.

7. A data stream-driven, pipelined radar data processing system according to claim 4, characterized in that, The second dot processing thread is specifically used for: Monitor the radar status control word associated with each aggregation point in the intra-frame aggregation data buffer; Based on the beam identifier and waveform sequence identifier information in the radar status control word, determine whether the convergence points within the coherent processing interval of each beam have arrived. When it is determined that the cohesive point data within the coherent processing interval of a certain beam has arrived, all cohesive points within the coherent processing interval of that beam are extracted from the intra-frame cohesive data buffer. Perform point correlation and agglomeration processing on all coherent processing intervals belonging to the same beam to generate beam-in-beam agglomeration points. The intra-beam cohesion points between adjacent beams are correlated and coheded to generate the final cohesion point.

8. A data stream-driven, pipelined radar data processing system according to claim 4, characterized in that, The second point processing thread is also used to write the final cohesion point into the inter-frame cohesion data buffer; The cohesion point output module includes a cohesion point output thread, which is used to extract the target cohesion point of the output sector from the inter-frame cohesion data buffer and output the target cohesion point to the display control device for visualization. The second point processing thread and the agglomeration point output thread are executed in parallel, forming a third secondary pipeline.

9. A data stream-driven, pipelined radar data processing system according to claim 8, characterized in that, The cohesion point output thread is also used to write the target cohesion point extracted from the output sector to the tail of the cohesion point data buffer. The trajectory processing module includes a stable trajectory management thread, which is used to: extract the target aggregation point of the corresponding processing sector from the head of the aggregation point data buffer; The convergence point output thread and the stable trajectory management thread are executed in parallel, forming a fourth secondary pipeline.

10. A data stream-driven, pipelined radar data processing system according to claim 9, characterized in that, The stable trajectory management thread is also used for: The current task type is determined based on the radar status control word associated with the target convergence point of the processing sector; Based on the current task type, extract the corresponding current stable track from the stable track data pool; Associate the target convergence point of the processing sector with the current stable trajectory; Based on the successfully associated convergence points, the current stable trajectory is updated, its disappearance is determined, filtered, predicted, and output. Place the remaining agglomeration points that failed to associate into the remaining agglomeration point data buffer; The track processing module also includes a temporary track management thread, which is used for: Extract the remaining cohesion points for the current period from the remaining cohesion point data buffer; Associate the remaining condensation points of the current cycle with the temporary track; If the association is successful, the temporary trajectory is updated and predicted based on the remaining aggregation points of the current period; If the association fails, a new temporary track is added based on the remaining aggregation points of the current period; The stable trajectory management thread and the temporary trajectory management thread are executed in parallel, forming the fifth secondary pipeline.

Images