Software defined radar based on drive decoupling

Abstract

The application provides a software-defined radar based on driving decoupling, which comprises a radar front end, a front-end control component connected with a front-end component, a radar back end, a front-end driving connected with a back-end computing unit, interaction between the radar front end and the radar back end is realized through the front-end driving of the front-end control component, the front-end driving generates a corresponding resource scheduling scheme and sends it to the front-end control component in response to a task scheduling request generated by the back-end computing unit, the front-end control component generates a control instruction for controlling the front-end component based on the resource scheduling scheme, the front-end component generates corresponding echo data based on the control instruction and sends it to the front-end driving, the front-end driving pushes the echo data to the back-end computing unit, and a response closed loop is realized. The front-end driving component is implanted in the radar back end, an abstract front-end proxy object is provided for the back-end related application, and the radar system front-end and back-end are independently and efficiently developed in a loose-coupling mode.

Description

Technical Field

[0001] This invention relates to the field of radar technology, and in particular to a software-defined radar based on drive decoupling. Background Technology

[0002] Software-defined radar technology divides the radar system into two parts: the radar front-end (or front-end) and the radar back-end (or back-end). The front-end is mainly responsible for state perception and precise execution, while the back-end performs real-time analysis and scientific decision-making, thus completing a closed loop of "state perception – real-time analysis – scientific decision-making – precise execution," thereby achieving the detection and perception of targets and the environment. The back-end acts as the "processing and decision-making center," and the front-end acts as the "controlled execution end," which is consistent with the concept of software-defined sensors.

[0003] The front end of the radar system is responsible for target environment measurement and perception data generation. It receives back-end commands for definition and control, and while generating reference clock signals and a series of timing synchronization signals, it performs a series of measurement actions and data processing activities as needed, such as signal waveform generation / amplification and distribution / beam control scheduling / space radiation synthesis, acquisition of space echo / receive channel synthesis, low-noise amplification of echo signals / frequency conversion / digitization, and baseband signal preprocessing. In this way, it generates echo / beam perception data and real-time status data and transmits them in a timely manner.

[0004] Software-defined radar front-ends aim to achieve capabilities such as customizable beam energy settings, on-demand generation and adjustment of signal echoes, customized processing of sensing data, and flexible reconstruction and expansion of functional processes through the definable programming and recombination of hardware modules. They need to adapt to mission changes, adjust working modes and processes in a timely manner, carry out element recombination and process reshaping, and control the switching of related unit functions and parameter adjustments in a software-defined manner, change the timing of related signals, and transform information processing methods.

[0005] The radar front end is mainly composed of a series of modules with certain functions, such as antenna (antenna feeder and transceiver switch), transceiver components (receiver and transmitter), signal source components (frequency source, waveform generation and timing generation), echo digitization components, scheduling control and status monitoring components, pre-processing components, servo / follow-up mechanisms and supporting power supply units.

[0006] However, for a long time, the scheduling and control of the radar backend over the frontend has essentially been a combined definition and control of the aforementioned related modules at the frontend. That is, the backend "radar control unit" generates a series of control parameters for each of these modules according to the radar's detection and sensing mission requirements, and sends these parameters to the relevant module units in the form of instructions according to a certain timing. The relevant module units are responsible for adjusting the operating parameters by activating the instruction parameter switching function at a specified time, thereby changing the radar frontend's capability state. This is a centralized "one-to-many" control structure, where the backend directly defines and controls the related modules of the frontend, failing to define and control the frontend as an organic whole. This overly granular direct control of resources by the radar backend is detrimental to the design, implementation, maintenance, and upgrading of multi-functional, multi-mission radar systems, and creates considerable practical difficulties for the rapid matching and integration of different radar frontend and backend systems.

[0007] Many current radar systems employ a hierarchical control structure: "Radar Control Unit - Front-end Management Agent Unit - Multiple Related Functional Modules." This involves setting up a "Management Agent Unit" at the front end, responsible for communication, command parsing, and synchronous control distribution. This reduces the one-to-many communication burden on the back-end "Radar Control Unit" and facilitates hierarchical distributed synchronous control of related front-end functional modules. While this control structure physically simplifies the front-end and back-end connection of the radar system and alleviates some of the specific monitoring and control functions of the back end, the core control logic remains tightly coupled. The back end still directly defines and controls the modules belonging to the front end, requiring the back end to generate a series of control commands and parameters for specific related modules. Software-defined control planes, failing to achieve loose coupling, also fall under the category of back-end customized control for the front end. If the radar system is replaced with a different front end or back end, the workload of re-integration, development, and debugging is considerable. Summary of the Invention

[0008] The technical problem this invention aims to solve is how to simplify the software-defined control requirements of the radar backend on the frontend, thereby reducing the difficulty of radar system integration. In view of this, this invention provides a software-defined radar based on driver decoupling.

[0009] The technical solution adopted in this invention is a software-defined radar based on drive decoupling, comprising:

[0010] The radar front end includes a front end component and a front end control component that is communicatively connected to the front end component;

[0011] The radar backend includes a backend computing unit and a frontend driver connected to the backend computing unit;

[0012] The front-end control component enables the interaction between the radar front-end and the radar back-end through the front-end driver;

[0013] Furthermore, in response to the task scheduling request generated by the backend computing unit, the frontend driver generates a corresponding resource scheduling scheme and sends it to the frontend management component. Based on the resource scheduling scheme, the frontend management component generates control instructions for controlling the frontend component. Based on the control instructions, the frontend component generates corresponding echo data and sends it to the frontend driver. The frontend driver pushes the echo data to the backend computing unit to achieve a closed-loop response.

[0014] In one implementation, the front-end component includes:

[0015] The system includes a timing component, a frequency source, an amplification and distribution component, a beam control component, a follower / servo component, a receiving channel, and a pre-processing component for sending the echo data to the front-end driver.

[0016] In one implementation, the front-end control component communicates with each component in the front-end component through a multi-IO communication management interface to control the issuance of commands.

[0017] In one implementation, the front-end management component is further used to report the actual capability attributes of the front-end component and provide real-time status feedback to the front-end driver, which then summarizes and provides this information to the back-end computing unit.

[0018] In one implementation, the task scheduling request includes: a coarse-grained task scheduling request and a fine-grained task control request;

[0019] In response to the coarse-grained task scheduling request, the front-end driver generates a first control instruction describing the spatial, temporal, and data quality requirements, and forwards it to the front-end management component.

[0020] In addition, in response to the fine-grained task control request, the front-end driver generates a second control instruction for module control parameters and forwards it to the front-end management component.

[0021] In one implementation, the front-end driver is further used for:

[0022] It provides overall management functions for front-end devices and allows for the definition of programming services, which can be accessed and defined by relevant back-end components and services;

[0023] The agent's front-end devices interact with the back-end applications, handling task requests / control requirements, reporting capability attributes, and providing real-time operational status feedback.

[0024] In one implementation, the front-end driver is further used for:

[0025] Based on the reporting capabilities and real-time operating status feedback of the current front-end management components, a resource scheduling scheme for the entire front-end device is generated.

[0026] In one implementation, there is no actual connection between the radar front end and the radar back end.

[0027] In one embodiment, the radar front-end further includes a back-end driver; the back-end driver is used to provide proxy service capabilities to the radar front-end.

[0028] Another aspect of the present invention provides an electronic device including a software-defined radar based on drive decoupling as described in any of the preceding claims.

[0029] By adopting the above technical solution, the present invention has at least the following advantages:

[0030] This invention provides a software-defined radar based on driver decoupling, which embeds front-end driver components into the radar back-end. This provides back-end related applications with an abstract front-end proxy object that shields the complexity of specific control and is easy to identify and access. This reduces the requirements for back-end application development, simplifies the development of back-end control software, and facilitates the loosely coupled, independent, parallel, and efficient development of the radar system's front and back ends. Furthermore, while achieving full decoupling between the radar system's front and back control planes, it also reduces the difficulty of radar system integration, making it easy to freely combine any front-end and any back-end to quickly integrate and build new radar equipment. Attached Figure Description

[0031] Figure 1 This is a schematic diagram of a software-defined radar structure based on drive decoupling according to an embodiment of the present invention;

[0032] Figure 2 This is a schematic diagram illustrating the deployment and interaction relationship of the front-end driving components in the corresponding radar back-end according to an embodiment of the present invention;

[0033] Figure 3 This is a schematic diagram of the main software configuration items in an embodiment of the present invention.

[0034] Figure 4 This is a schematic diagram of the information interaction topology between the main software configuration items according to an embodiment of the present invention. Detailed Implementation

[0035] To further illustrate the technical means and effects of the present invention in achieving its intended purpose, the present invention will be described in detail below with reference to the accompanying drawings and preferred embodiments.

[0036] It should be understood that the terms "comprising," "including," "having," "containing," and / or "comprises," when used in this specification, indicate the presence of the stated features, integrals, steps, operations, elements, and / or components, but do not exclude the presence or addition of one or more other features, integrals, steps, operations, elements, components, and / or combinations thereof. Furthermore, when expressions such as "at least one of..." appear after a list of listed features, they modify the entire listed feature, not individual elements in the list. Additionally, when describing embodiments of this application, the word "may" is used to mean "one or more embodiments of this application." And the term "exemplary" is intended to refer to an example or illustration.

[0037] As used herein, the terms “basically,” “approximately,” and similar terms are used as terms of approximation rather than terms of degree, and are intended to describe inherent biases in measured or calculated values ​​that will be recognized by those skilled in the art.

[0038] Unless otherwise specified, all terms used herein (including technical and scientific terms) shall have the same meaning as commonly understood by one of ordinary skill in the art to which this application pertains. It should also be understood that terms (e.g., those defined in common dictionaries) shall be interpreted as having the meaning consistent with their meaning in the context of the relevant art and shall not be interpreted in an idealized or overly formal sense unless expressly so specified herein.

[0039] It should be noted that, unless otherwise specified, the embodiments and features described in this application can be combined with each other. The steps in the method flow description and flowcharts in the accompanying drawings are not necessarily strictly executed according to the step numbers; the execution order of the method steps can be changed. Furthermore, certain steps can be omitted, multiple steps can be combined into one step, and / or one step can be broken down into multiple steps.

[0040] The first embodiment of the present invention provides a software-defined radar based on drive decoupling, such as... Figure 1 As shown, it includes:

[0041] The radar front end includes a front end component and a front end control component that is communicatively connected to the front end component;

[0042] The radar backend includes a backend computing unit and a frontend driver connected to the backend computing unit;

[0043] The front-end management environment enables the interaction between the radar front-end and the radar back-end through the front-end driver;

[0044] Furthermore, in response to the task scheduling request generated by the backend computing unit, the frontend driver generates a corresponding resource scheduling scheme and sends it to the frontend management component. Based on the resource scheduling scheme, the frontend management component generates control instructions for controlling the frontend component. Based on the control instructions, the frontend component generates corresponding echo data and sends it to the frontend driver. The frontend driver pushes the echo data to the backend computing unit to achieve a closed-loop response.

[0045] In this embodiment, the front-end component may include, for example, a timing component, a frequency source, an amplification and distribution component, a beam control component, a follow-up / servo component, a receiving channel, and a pre-processing component for sending the echo data to the front-end driver.

[0046] In this embodiment, the front-end management component communicates with each component in the front-end component through a multi-IO communication management interface to control the issuance of commands.

[0047] In this embodiment, the front-end management component is further used to report the actual capability attributes of the front-end component and provide feedback on the real-time status to the front-end driver, and the front-end driver summarizes and organizes the information and provides it to the back-end computing unit.

[0048] In this embodiment, the task scheduling request includes: a coarse-grained task scheduling request and a fine-grained task control request;

[0049] In response to the coarse-grained task scheduling request, the front-end driver generates a first control instruction describing the spatial, temporal, and data quality requirements, and forwards it to the front-end management component.

[0050] In addition, in response to the fine-grained task control request, the front-end driver generates a second control instruction for module control parameters and forwards it to the front-end management component.

[0051] In this embodiment, the front-end driver can be further used for:

[0052] Provides programmable management services for the entire front-end device, allowing access and definition of related back-end components and services;

[0053] The agent's front-end devices interact with the back-end applications, handling task requests / control requirements, reporting capability attributes, and providing real-time operational status feedback.

[0054] In this embodiment, the front-end driver can be further used for:

[0055] Based on the reporting capabilities and real-time operating status feedback of the current front-end management components, a resource scheduling scheme for the entire front-end device is generated.

[0056] In this embodiment, there is no actual connection between the radar front end and the radar back end.

[0057] In this embodiment, the radar front-end also includes a back-end driver; the back-end driver is used to provide proxy service capabilities to the radar front-end.

[0058] The second embodiment of the present invention corresponds to the first embodiment, and is described in conjunction with the appendix. Figures 1 to 4 This embodiment introduces an application example of a software-defined radar based on driver decoupling.

[0059] The software-defined radar front-end based on driver decoupling designed and implemented in this invention mainly consists of the following components: Figure 1 As shown, in addition to the definable and controllable functional modules such as timing, frequency source, amplification allocation, beam control, receiving channel, servo / follow-up, and pre-processing, there is also a "front-end management environment" module, on which the "front-end management" service component and multi-I / O communication management component are deployed and run, as well as the "front-end driver" plugin deployed and run in the back-end computing environment.

[0060] Among them, the relevant definable controllable function / functional modules are responsible for carrying out sensing measurement and data generation activities according to the defined control commands and parameters; the "Front-end Management Environment" module is responsible for providing the operating platform and enabling environment for the "Front-end Management" service and the multi-IO communication management component; the "Front-end Management" service is used to integrate front-end resources and provide overall capability services to the outside world; the multi-I / O communication management component is responsible for synchronously distributing command parameters to the relevant function / functional modules; the "Front-end Driver" plugin, as a proxy object, is responsible for interacting with the back-end, receiving requests, and feeding back data.

[0061] The achieved autonomous resource management of the radar front-end, simplified back-end definition of control requirements (reduced control granularity), and decoupling characteristics of the front-end and back-end control surfaces are manifested in the following steps during radar system operation:

[0062] 1) The radar backend perception task scheduling service (taking a single target tracking task as an example) submits a target tracking task scheduling request to the "frontend driver" plugin, which includes parameters such as "target position, data rate, accumulated number, window size, frequency agility number, and processing method" (reflecting time, space, and data requirements); (unlike before, the backend no longer sends command parameters of specific functions / functional modules to the frontend).

[0063] 2) The "Front-end Driven" plugin performs resource scheduling and orchestration to determine the rationality of the requirements (e.g., whether time resources match). If not rational, the requirement is rejected; if rational, the time, space, frequency, energy, and method / pattern of resources such as beams, signals / echoes, and data are determined, forming a resource scheduling scheme that includes working modes, time slot orchestration, beam layout, signal waveforms, reception methods, and echo data processing methods, and is sent to the "Front-end Control" service component.

[0064] 3) The “Front-end Management” service component generates management strategies based on the resource scheduling scheme and the capability characteristics of the relevant modules to which the front end belongs. It then forms defined control commands and parameters to be distributed to the relevant functional modules within the front end. Under certain timing constraints, it sends command parameters to the timing, frequency source, amplification allocation, beam control, receiving channel, follow-up / servo and other functional module objects through the multi-I / O communication management component and collects status feedback.

[0065] 4) The above-mentioned functional module objects accept command parameter definitions and control to execute a series of ordered sensing measurements (signal uplink - radiation / reception - echo downlink) and data processing activities under timing constraints, forming sensing echo data, and sending it to the "front-end driver" plugin;

[0066] 5) The "Front-end driven" plugin is responsible for pushing the sensing echo data to the back-end information processing service;

[0067] In this way, a task request cycle is completed.

[0068] The loosely coupled, parallel, independent, and efficient development features of the radar system's front and back ends, achieved by this invention, can be combined with... Figure 2 Please provide an explanation.

[0069] The "Front-end Driven" plugin is installed and deployed as a component service in the back-end radar computing environment (the environment enabling the radar system application software) using a digital twin approach. It serves as an abstract object of the front-end entity for access by relevant back-end component services, such as... Figure 2 As shown. The loosely coupled, parallel, independent, and efficient development features of the radar system's front and back ends achieved by this invention are reflected in the following aspects:

[0070] 1) The "Front-end driven" plugin interacts with the backend application service components through three ports. The information content is shown in Table 1.

[0071] Table 1: Summary of Interaction Information between "Front-end Driven" and Back-end Applications

[0072]

[0073] 2) Backend applications can obtain the service attributes of specific frontend devices by accessing the "Frontend Driver" status port, and understand the capabilities and definability of the frontend of the controlled object, as shown in Table 1, so as to ensure that reasonable tasks and control requests can be generated.

[0074] Table 2 Description of Front-End Device Capabilities

[0075]

[0076]

[0077] 3) Backend applications can obtain the newly generated echo sensing data address by reading the "frontend driver" data port and carry out subsequent signal processing and data processing processes.

[0078] 4) Backend applications can read the real-time health status data of specific frontends through the "frontend-driven" status port to carry out health status management applications.

[0079] 5) If it is necessary to set the function parameters of specific modules in the front end, commands and parameters can be sent through the "Front End Driver" status port.

[0080] By implementing the above five aspects, independent development of backend applications based on the "front-end driven" plugin can be achieved.

[0081] In this embodiment, resource management, function scheduling, and module control are empowered to the front-end, making it an autonomous and organic whole. It self-manages its resources, schedules all functions, and controls its modules, distributing them appropriately across different locations. Each module manages its own resources or objects, ensuring decoupling of the control plane logic layer. This means decoupling the front-end and back-end task interfaces, decoupling the front-end's internal resource orchestration and function scheduling, and decoupling function scheduling and module control. This can be seen from... Figure 3 Software configuration and Figure 4 The information exchange and flow relationship will be explained.

[0082] See Figure 3 In the software-defined radar front-end based on driver decoupling, the main software configuration items involved include the "front-end driver" plug-in service, the "front-end control" service, and the multi-I / O communication management component. These services can be further subdivided into several functional components, as detailed in Table 3. The input / output information of each functional item can be combined... Figure 4 Please provide an explanation.

[0083] The "Front-end Driven" plug-in service carries high-level abstract resource orchestration (beam, signal / echo, data, etc.) and proposes resource scheduling schemes in response to task requests. The "Front-end Control" service is responsible for adjusting the priority of execution task sequences and the allocation of execution resources in real time (functional scheduling), and determining the definition control commands and parameters of the relevant modules corresponding to the new task sequence (including a series of requirements for synchronous timing signals, waveform control, frequency control, timing control, beam control, receiver control, power control, servo / follow-up control, information processing, etc.). The multi-I / O communication management component distributes the relevant definition control commands and parameters synchronously to the relevant functional modules using appropriate communication methods based on the deployment of the managed modules, communication conditions, and control timing requirements.

[0084] Table 3 Description of Front-End Device Capability Attributes

[0085]

[0086] See Figure 4 The backend task planning is responsible for generating new task requirements, focusing on task submission (time, space, and data quality requirements); resource scheduling and orchestration focus on resource usage, planning resource requirements such as time, space, frequency, energy, and methods / styles for dynamic task events; control strategy generation focuses on function scheduling, generating orderly function control requirements based on resource usage requirements; and synchronous distribution control focuses on control execution, generating precise control commands and parameters as required. This forms a layered and decoupled software-defined control flow: external "task scheduling request" → "resource scheduling scheme" → "related module control requirements" → "control commands and parameters" → synchronous distribution → orderly and precise execution by related modules. Figure 4 The detailed content of the corresponding interactive information is shown in Table 4.

[0087] Table 4 Figure 4 The corresponding information content

[0088] Serial Number Information content (1) Task scheduling request (2) Intervention / Control Instructions (3) Ability attributes and real-time status (4) Resource scheduling scheme (5) Orderly control requirements (6) Front-end capability attributes & real-time status (7) Related module control requirements (8) Surveillance requirements (9) Task monitoring deviation (10) Command execution status information (11) Control commands and parameters (12) Module health information and execution status

[0089] Compared with the prior art, the present invention has at least the following advantages:

[0090] 1) The radar's front end has the ability to autonomously manage and schedule its resources in response to dynamic mission requests, and to control its functional modules in real time to perform sensing and measurement and data processing actions in an orderly manner, thereby completing the mission of target environment measurement and sensing data generation.

[0091] 2) The front-end driver plugin provided by the radar provides proxy services to the back-end in the form of a digital twin. It abstracts the complex radar front-end, which is tightly coupled with hardware and software and has strong timing constraints, into a software scheduling object that can be easily and flexibly defined by the back-end application, which facilitates independent and efficient development of the back-end.

[0092] 3) The radar's front-end driver plugin can be easily upgraded and improved, facilitating independent and flexible upgrade and expansion capabilities of the radar system's front and back ends.

[0093] 4) The front end of the radar can effectively simplify the back-end management and control requirements, avoid overly fine-grained definition control, reduce the difficulty of radar system integration, and improve equipment development efficiency.

[0094] 5) The front end of the radar effectively reduces the coupling between the front and back control surfaces of the radar system, making it easy to achieve arbitrary, open, modular, independent procurement and efficient integration of the front and back ends to form a new type of radar equipment.

[0095] 6) The radar's front-end has effectively redesigned the radar system's mission planning, resource scheduling and arrangement, control strategy generation, and command synchronization and distribution functions, which will help more talents enter the field of radar management and control research.

[0096] 7) The front end of this radar is easy to build into a distributed collaborative detection and networking radar system.

[0097] The third embodiment of the present invention provides an electronic device, which can be understood as a physical device, including a software-defined radar front-end based on drive decoupling as mentioned in any of the above embodiments.

[0098] Through the description of specific embodiments, a more in-depth and specific understanding should be gained of the technical means and effects adopted by the present invention to achieve the intended purpose. However, the accompanying drawings are only provided for reference and illustration and are not intended to limit the present invention.

Claims

1. A software-defined radar based on drive decoupling, characterized in that, include: The radar front end includes a front end component and a front end control component that is communicatively connected to the front end component; The radar backend includes a backend computing unit and a frontend driver connected to the backend computing unit; The front-end control component enables the interaction between the radar front-end and the radar back-end through the front-end driver; Furthermore, in response to the task scheduling request generated by the backend computing unit, the frontend driver generates a corresponding resource scheduling scheme and sends it to the frontend management component. Based on the resource scheduling scheme, the frontend management component generates control instructions for controlling the frontend component. Based on the control instructions, the frontend component generates corresponding echo data and sends it to the frontend driver. The frontend driver pushes the echo data to the backend computing unit to achieve a closed-loop response.

2. The software-defined radar based on drive decoupling according to claim 1, characterized in that, The front-end component includes: The system includes a timing component, a frequency source, an amplification and distribution component, a beam control component, a follower / servo component, a receiving channel, and a pre-processing component for sending the echo data to the front-end driver.

3. The software-defined radar based on drive decoupling according to claim 2, characterized in that, The front-end management component communicates with each component in the front-end component through a multi-IO communication management interface to control the issuance of commands.

4. The software-defined radar based on drive decoupling according to claim 1, characterized in that, The front-end management component is further used to report the actual capability attributes of the front-end component and provide feedback on the real-time status to the front-end driver, which then summarizes and organizes the information and provides it to the back-end computing unit.

5. The software-defined radar based on drive decoupling according to claim 1, characterized in that, The task scheduling request includes: coarse-grained task scheduling request and fine-grained task control request; In response to the coarse-grained task scheduling request, the front-end driver generates a first control instruction describing the spatial, temporal, and data quality requirements, and forwards it to the front-end management component. In addition, in response to the fine-grained task control request, the front-end driver generates a second control instruction for module control parameters and forwards it to the front-end management component.

6. The software-defined radar based on drive decoupling according to claim 5, characterized in that, The front-end driver is further used for: Provides a customizable programmable service for the entire front-end device, allowing for the definition and access of related back-end component services; The agent's front-end devices interact with the back-end applications, handling task requests / control requirements, reporting capability attributes, and providing real-time operational status feedback.

7. The software-defined radar based on drive decoupling according to claim 6, characterized in that, The front-end driver is further used for: Based on the reporting capabilities and real-time feedback of the current front-end components, a resource scheduling scheme for the entire front-end device is generated.

8. The software-defined radar based on drive decoupling according to claim 1, characterized in that, There is no actual connection between the radar front end and the radar back end.

9. The software-defined radar based on drive decoupling according to claim 1, characterized in that, The radar front-end also includes a back-end driver; the back-end driver is used to provide proxy service capabilities to the radar front-end.

10. An electronic device comprising a software-defined radar based on drive decoupling as claimed in any one of claims 1 to 9.

Images