A software-based radar data stream communication method based on DDS

Abstract

The present invention proposes a software radar data stream communication method based on DDS, which mainly includes the encapsulation of data transceiver interface, the design of data caching mechanism and the implementation of data transceiver control strategy. The data transceiver interface is encapsulated according to the DDS entity specification, which provides a unified programming framework for the implementation of radar data stream communication and solves the problem of tight coupling between software modules; the data caching mechanism provides a set of universal cache models, which balances the rate difference between radar application operations and communications, and reduces data transmission delay and space overhead; the data transceiver control strategy provides a data packet format and data stream transmission protocol suitable for radar data, selects appropriate communication methods according to different application scenarios and user needs, and realizes the transceiver control and management of different types of radar data. The present invention provides a feasible implementation plan for data communication in software radar systems, which effectively improves the real-time, stability and flexible scalability of data transmission.

Description

Technical Field

[0001] The present invention relates to the field of software radar, in particular to a distributed data communication technology of software radar, and in particular to a data stream communication method based on DDS specification. Background Art

[0002] DDS (Data Distribution Service) is a new generation of distributed real-time communication middleware technical specifications developed by the Object Management Group (OMG) based on standards such as CORBA. DDS adopts a data-centric publish / subscribe model (DCPS), in which applications use specific APIs to establish corresponding DDS entities, and then use entities to implement publish / subscribe data communication. Being data-centric rather than service-centric makes it more in line with the main goal of data transmission in distributed systems. DDS provides minimal overhead for time-critical data flows, has a flexible and scalable architecture, and supports reliable data transmission and custom data types. It is suitable for data communication occasions with high requirements for real-time, reliability, and flexibility.

[0003] Software-based radar is based on a standardized digital platform, has an open architecture, and adopts an application-oriented development model. It is a new radar technology whose functions are defined, expanded, and reconstructed through software. In software-based radar, the radar signal processing system continuously receives echo data from the front end, and the echo data is mostly in a pulse structure, which is transmitted in the system as a data packet, suitable for data stream-driven computing mode. Since different algorithm processing links are distributed on different nodes, communication between different nodes in the radar signal processing system is difficult, and different communication interfaces also bring difficulties to developers. Therefore, a general data stream communication method is needed to ensure the real-time and stability of radar data transmission and support a variety of data types and transmission modes.

[0004] The existing technical solutions are as follows:

[0005] The invention application with publication number CN105554089A proposes a "request-response" data communication method based on the DDS standard. The method defines the corresponding domains, topics and message structures around the "request-response" model, creates request messages according to the unified message definition, publishes request messages according to the DDS standard, and then the subscriber filters the received information according to the field. The responder uses the corresponding technology to deserialize the request message to obtain the request parameters, thereby achieving point-to-point transmission under the same topic.

[0006] The invention application with publication number CN105554089A expands the interactive "request-response" application scenario based on the DDS publish / subscribe model. However, the request / response model itself is not suitable for the high real-time and high reliability requirements of radar data, and the data communication method limits specific application environments, adds some non-standard content, and weakens the advantages of the original DDS data-centric publish / subscribe model.

[0007] The invention application with publication number CN110740182A proposes a dynamic data communication method and device based on DDS technology, which includes: step 1, generating a communication channel according to the subject ID dynamically generated during the DDS communication process; step 2, judging whether the communication data needs to be routed according to the subject routing table, and transmitting the communication data through the communication channel; step 3, after the communication is completed, releasing the subject memory resources and updating the subject routing table. Users do not need to configure the subject in the communication process to adapt to the point-to-point communication requirements of each node; each communicating node only receives control information and does not receive information unrelated to its own node, thus avoiding redundant information.

[0008] The invention application with publication number CN110740182A mainly utilizes the characteristics of DDS topic publishing and subscription, and improves the communication efficiency of data by establishing a topic routing table. It only optimizes the dynamic synchronization of topics and the establishment process of communication channels, and does not improve the data transmission itself. In addition, this method is only conducive to the transmission of control information and is not suitable for the transmission of other types of data information.

[0009] The invention application with publication number CN110602188A proposes a data distribution method based on DDS middleware, which involves a distributed communication system. The DDS middleware is provided in the communication node of the distributed communication system. A heartbeat thread is opened on the DDS middleware. The heartbeat mechanism is used to detect the increase or decrease of subscribers, and the publisher is notified in time to stop sending data to the exiting subscribers, which can save data communication bandwidth.

[0010] The invention application with publication number CN110602188A reduces unnecessary data transmission through a heartbeat mechanism, thereby saving communication bandwidth and system resource consumption. However, this method only solves the problem of data waste caused by node exit, and does not improve other performances of communication such as real-time performance and reliability from the specific transmission process. Summary of the invention

[0011] The technical problem to be solved by the present invention is to provide a DDS-based software radar data stream communication method to overcome the defects of low real-time performance, insufficient reliability and flexibility in communication between distributed application nodes in a software radar system.

[0012] The technical solution adopted by the present invention to solve the above technical problems is a software radar data stream communication method based on DDS, comprising the following steps:

[0013] Encapsulation steps of data transceiver interface: encapsulate the data transceiver interface according to the data distribution service DDS specification, create data writers and data readers through the interface, support the publish-subscribe communication model, and after the component establishes the publish-subscribe connection, submit the data to the data transceiver interface for processing, and use the data writer and data reader to complete the specific data stream transmission;

[0014] Data caching step: The data receiving and sending buffer is used to cache the data flow during the transmission process. Data structures such as buffer queues and linked lists are set up. The data caching model is built in combination with multi-threading. Appropriate buffers and sub-threads are allocated for sending and receiving data to realize real-time transmission of data flow.

[0015] The data cache model mainly uses queue and linked list data structures. The buffer adopts a circular queue design. The data writer / data reader copies the data to the buffer queue when sending / receiving data, and maintains a global sending / receiving management linked list respectively. The management linked list adopts a single linked list structure. Each node in the linked list records the management information related to each frame of data sent / received, including: IP address, port number, buffer address and frame size information.

[0016] Data transmission and reception control steps: Through the customized data packet format and data stream transmission protocol, the data transmission, reception and caching process are controlled to achieve the decoupling of data communication and radar component algorithms.

[0017] Specifically, the data sending and receiving interface mainly includes methods for creating data writer objects and data reader objects, as well as publishers / subscribers and domain participant members.

[0018] Specifically, when sending and receiving data, a buffer queue of appropriate size is allocated and multiple sub-threads for sending / receiving data are opened;

[0019] When sending data, first, each sending sub-thread function in the background allocates or adjusts the size of the sending buffer queue through management information, and then, combining thread synchronization and multi-thread concurrency, cyclically obtains data of a certain size from the buffer queue and sends it;

[0020] When receiving data, first, a thread pool is maintained at the receiving side. The receiving sub-thread is blocked in the receiving task queue of the receiving side through the condition variable. When data arrives, the corresponding receiving sub-thread is awakened to receive data of the corresponding size and dynamically store it in the receiving buffer queue.

[0021] Specifically, the data transmission and reception control strategy refers to the real-time message transmission protocol RTMP, and defines the data packet format and data stream transmission protocol in combination with the requirements of radar data transmission.

[0022] The data packet format consists of a control protocol header and a data frame. The control protocol header includes field information such as data frame size, frame sequence number, communication link protocol, data serialization protocol, component algorithm sequence number, etc. The data frame refers to the actual radar data frame to be transmitted. The specific implementation process includes:

[0023] First, the sender sets the fields in the control information packet header according to user requirements. The field options in the packet header are pre-written in the corresponding header file;

[0024] Then, the sender encapsulates the generated protocol header and data frame into a data packet through the data transceiver interface, and sends it to the receiver according to the corresponding link protocol in the protocol header;

[0025] Next, the receiver parses the protocol header of the data packet and converts the data into a byte sequence in a unified format based on the serialized protocol information obtained from the parsing. At the same time, it determines whether the data frame is complete based on the frame size and frame sequence number;

[0026] Finally, the receiver determines whether there is enough space in the buffer to receive the data frame. If the space is insufficient, the buffer is dynamically adjusted and allocated; if the space is sufficient, the receiving subthread is called to store each frame of data in the buffer. After that, according to the component algorithm number in the protocol header, the main program executes the corresponding algorithm processing.

[0027] The present invention is based on the DDS software framework, and specifically designs and implements the data transceiver part thereof. By designing the data stream cache mechanism and data transceiver control strategy, a set of data stream communication methods for software radar is realized.

[0028] The beneficial effects of the present invention are:

[0029] Encapsulates the data receiving and sending interface based on the standardized DDS entity, supports the publish-subscribe communication model, can better interact with the application layer, and is conducive to providing a unified and stable software architecture for data stream communication;

[0030] Design a data cache mechanism to balance the differences in component computing and communication rates by allocating appropriate buffers and communication subthreads for data flows between radar components, thus ensuring efficient, continuous, and reliable real-time transmission of data flows during transmission.

[0031] Implement data transmission and reception control strategies, and further control and manage data transmission, reception, and caching processes by defining data packet formats and data stream transmission protocols, thereby improving the flexibility of the data transmission process and facilitating the expansion of more data types and transmission protocols. BRIEF DESCRIPTION OF THE DRAWINGS

[0032] Figure 1 It is a schematic diagram of the software hierarchy based on DDS of the present invention;

[0033] Figure 2 Schematic diagram of data sending cache model;

[0034] Figure 3 This is a schematic diagram of the data receiving cache model;

[0035] Figure 4 It is a schematic diagram of the data packet protocol format;

[0036] Figure 5 It is a schematic diagram of data transmission and reception control strategy;

[0037] Figure 6 Test the embodiment for data communication. DETAILED DESCRIPTION

[0038] In order to make the purpose, technical solution and effect of the present invention more clear and understandable, the present invention is further described below in conjunction with the accompanying drawings and embodiments.

[0039] The data transceiver interface, data cache model and data stream transmission protocol related contents described in the present invention are all implemented by programming using C / C++ language, and are compiled through the compilation environment and method under the corresponding system.

[0040] like Figure 1 As shown, it is a schematic diagram of the software hierarchy based on DDS of the present invention, which includes the application component layer, the DDS interface layer, the data transceiver layer and the data link layer from top to bottom.

[0041] according to Figure 1 The DDS interface layer contains data sending and receiving interfaces, which correspond to DDS-related entities and build a publish-subscribe communication environment. Among them, the sending data interface contains entities related to the publisher, and a data writer is created to send data; the receiving data interface contains entities related to the subscriber, and a data reader is created to receive data;

[0042] according to Figure 1 ,The data transceiver layer is responsible for data caching and transceiver control, and the data caching mechanism and transceiver control strategy are implemented in this layer;

[0043] according to Figure 1 ,The data link layer transmits specific data streams, each data stream is composed of data packets, which is related to the specific link protocol.

[0044] like Figure 2As shown in FIG. 1 , a schematic diagram of a data sending cache model is shown, which mainly includes a data writer, a sending buffer queue, a sending management linked list, and a sending sub-thread, and includes the following steps:

[0045] Step 1: The data writer obtains a frame of radar data from the application layer by sending the relevant input parameters of the function, obtains the management information according to the parameters and the information of the data packet header, and writes it into the tail node of the management linked list;

[0046] Step 2: According to the management information in the sending management linked list, the corresponding data frame size and frame sequence number are obtained, and a data frame of a certain size is transferred to the sending buffer queue;

[0047] Step 3: Determine whether the sending buffer queue has enough space to accommodate the data frame. If the space is sufficient, copy the data frame to the corresponding address according to the sending buffer address in the linked list management information; if the space is insufficient, suspend and wait for the sending thread to finish reading the data, and the subsequent received radar data will be re-overwritten from the head of the queue;

[0048] Step 4: Based on the frame size in the management information and the link protocol and other fields in the packet header, call the corresponding sending sub-thread to read the data frame from the sending buffer queue. The main thread and the sending sub-thread need to be synchronized, and the reading and writing of the management linked list by multiple sub-threads must also be synchronized. After sending, delete the linked list header node.

[0049] like Figure 3 The figure shows a schematic diagram of a data receiving cache model, which mainly includes a data reader, a receiving buffer queue, a receiving management linked list, a receiving task queue, a receiving thread pool and a sub-thread, and includes the following steps:

[0050] Step 1: The receiver stores a certain number of receiving sub-threads in advance by setting up a thread pool. The thread pool will dynamically expand and destroy the receiving sub-threads according to the received data situation.

[0051] Step 2: The receiving sub-thread in the thread pool blocks the condition variable in the receiving task queue and waits for the arrival of data. When data is sent, the corresponding receiving sub-thread in the receiving task queue is awakened to read the data packet in the data stream.

[0052] Step 3, the receiving thread reads the frame size information in the packet header, calculates the remaining space of the receiving buffer according to the buffer addresses stored in the first node and the last node in the existing receiving management linked list, and receives the data frame into the corresponding receiving buffer queue;

[0053] Step 4: The receiver allocates a new management linked list node for the currently received data frame, and writes management information such as the data frame size and the address of the data in the receiving buffer into the node. After that, the main thread and the receiving sub-thread use thread synchronization to access the management information in the management linked list, obtain the corresponding data from the buffer queue, copy it to the user array for calculation and processing, and the original buffer area is released.

[0054] like Figure 4 The following table shows the data packet protocol format defined in the data transmission and reception control strategy. It is improved to a protocol for radar real-time data stream communication with reference to the RTMP real-time message transmission protocol. The description of each field in the protocol is shown in Table 1:

[0055] Table 1 Data stream header protocol field description

[0056]

[0057] according to Figure 4 As shown in Table 1, the data packet header in the data stream is the key to the implementation of data transmission and reception control. As a packet header containing control information, the protocol field inside contains a structure of information such as data frame size, frame sequence number, data serialization protocol (byte alignment issues in different platforms and languages), link protocol or scheduled transmission time (optional), etc., indicating what kind of data to be transmitted and how to transmit it.

[0058] Among them, the frame size information will be used for the specific sending and receiving of the sending and receiving buffer after the data sending and receiving function. Other relevant information will also be stored in the node of the management linked list to record various status information of data sending and receiving. Using the C++ namespace, the commonly used field options are defined with the enumeration type for users to choose. In the actual application process, the user will operate a protocol unit class, which contains the header structure members of the control information and the function methods for setting the fields in the header.

[0059] According to Table 1, the protocol of the data packet header is implemented in the form of a structure, including the fields: stag, version, type, proto, checksum, funcid, framid, length and reserve, as follows:

[0060]

[0061] The main fields in the data packet header are described using enumeration types, where the options for proto and funcid are as follows:

[0062]

[0063]

[0064] like Figure 5 As shown in the figure, it is a schematic diagram of the data sending and receiving control strategy. The main program of the publisher / subscriber is used to execute the algorithm operation. At the same time, a listening thread will be opened to complete the establishment of the DDS-based publish-subscribe connection; then, in order to realize the parallel of data communication and functional algorithm, a data sending / receiving control thread will be opened under the current component. This thread is responsible for the implementation of the data sending and receiving control strategy, including the following steps:

[0065] Step 1: The sender first sets the frame length, sequence number, protocol and other field information according to user requirements, generates a control information packet header structure, and the data transmission control thread encapsulates the incoming input data stream into a custom data packet format;

[0066] Step 2: Use the data sending function interface to create a data writer, read the frame size and link protocol fields in the packet header, use the data cache mechanism to write the data frame into the sending buffer, and call the sending subthread of the corresponding protocol to send a data packet of a certain size;

[0067] Step 3: The receiver parses the control information in the data packet header, converts the data packet into a byte sequence in a unified format according to the serialization protocol obtained by the parsing, and processes the serialized data frame using a data cache mechanism;

[0068] Step 4: The receiver dynamically adjusts and allocates the buffer according to the buffer queue space and the current data frame size, and calls the receiving subthread to continuously read the data frame into the receiving buffer. Then, according to the component algorithm sequence number in the control information, the main program is notified to perform the corresponding algorithm processing on the current data frame.

[0069] The control strategy for data transmission and reception specifies what radar data needs to be transmitted and how it is transmitted. The specific data transmission process is achieved through a data caching mechanism. The two complement each other and constitute a communication method for software-based radar data streams.

[0070] like Figure 6 FIG. 1 is an embodiment of a data communication test, which describes a communication test of radar data with different functions under different communication link protocols based on the method of the present invention, including the following steps:

[0071] Step 1: Build a radar communication system consisting of a radar transceiver and multiple processor platforms. Based on a Gigabit Ethernet link, the front-end node obtains the input data stream from the radar receiving antenna.

[0072] Step 2: The front-end node starts a publisher program, and the back-end processing node starts a subscriber program. The method of the present invention is used to realize the real-time transmission of antenna echo data from the publisher to the subscriber, and the transmission bandwidth under different communication protocols is tested;

[0073] Step 3: After receiving the data, the back-end processing node completes the radar basic function operation, and uses the method of the present invention to publish the calculated data stream to the next processing node containing the subscriber program to test the transmission bandwidth under different communication protocols;

[0074] Step 4: After the subscriber node obtains the data, it calls the component of the target detection algorithm and publishes the target detection result data to the output node using the method of the present invention to test the transmission bandwidth under different communication protocols.

[0075] The test results show that the method of the present invention can select different communication link protocols for transmission according to radar data in different functional states, verifying the flexible scalability of radar data communication. At the same time, according to the bandwidth results, the data transmission under each protocol can approach the optimal performance index of the current environment, verifying that the radar data communication is efficient and has good real-time performance.

Claims

1. A software radar data stream communication method based on DDS, characterized in that: The following steps are involved: Encapsulation steps of data transceiver interface: encapsulate the data transceiver interface according to the data distribution service DDS specification, create data writers and data readers through the interface, support the publish-subscribe communication model, and after the component establishes the publish-subscribe connection, submit the data to the data transceiver interface for processing, and use the data writer and data reader to complete the specific data stream transmission; Data caching step: The data receiving and sending buffer is used to cache the data flow during the transmission process. Data structures such as buffer queues and linked lists are set up. The data caching model is built in combination with multi-threading. Appropriate buffers and sub-threads are allocated for sending and receiving data to realize real-time transmission of data flow. The data cache model mainly uses queue and linked list data structures, and the buffer adopts a circular queue design; the data writer / data reader copies the data to the buffer queue when sending / receiving data, and maintains a global sending / receiving management linked list respectively; The management linked list adopts a single linked list structure. Each node in the linked list records the management information related to each frame of data sent / received, including: IP address, port number, buffer address and frame size information; Data transmission and reception control step: Through the custom data packet format and data stream transmission protocol, the data transmission, reception and caching process are controlled to achieve the decoupling of data communication and radar component algorithms; The data transmission and reception control refers to the real-time message transmission protocol RTMP, and the data packet format and data stream transmission protocol are defined in combination with the requirements of radar data transmission; The data packet format consists of a control protocol header and a data frame; the control protocol header includes data frame size, frame sequence number, communication link protocol, data serialization protocol and component algorithm sequence number field information, and the data frame refers to the actual radar data frame to be transmitted; The specific implementation process includes: First, the sender sets the fields in the control information packet header according to user requirements. The field options in the packet header are pre-written in the corresponding header file; Then, the sender encapsulates the generated protocol header and data frame into a data packet through the data transceiver interface, and sends it to the receiver according to the corresponding link protocol in the protocol header; Next, the receiver parses the protocol header of the data packet and converts the data into a byte sequence in a unified format based on the serialized protocol information obtained from the parsing. At the same time, the receiver determines whether the data frame is complete based on the frame size and frame sequence number. Finally, the receiver determines whether there is enough space in the buffer to receive the data frame. If the space is insufficient, the buffer is dynamically adjusted and allocated. If the space is sufficient, the receiving subthread is called to store each frame of data in the buffer. Afterwards, according to the component algorithm serial number in the protocol header, the main program executes the algorithm processing corresponding to the serial number.

2. The DDS-based software radar data stream communication method according to claim 1, characterized in that: The entity interfaces in the DDS specification include domains, domain participants, publishers, subscribers, topics, data writers, and data readers, through which the publish-subscribe model is constructed; publishers or domain participants are used to create data writers to send data, and subscribers or domain participants are used to create data readers to receive data; The data sending and receiving interface includes methods for creating data writer objects and data reader objects as well as publisher / subscriber and domain participant members.

3. The DDS-based software radar data stream communication method according to claim 1, characterized in that: When sending and receiving data, a buffer queue of appropriate size is allocated and multiple sub-threads for sending / receiving data are opened; When sending data, first, each sending sub-thread function in the background allocates or adjusts the size of the sending buffer queue through management information, and then, combining thread synchronization and multi-thread concurrency, cyclically obtains data of a certain size from the buffer queue and sends it; When receiving data, first, a thread pool is maintained at the receiving side. The receiving sub-thread is blocked in the receiving task queue of the receiving side through the condition variable. When data arrives, the corresponding receiving sub-thread is awakened to receive data of the corresponding size and dynamically store it in the receiving buffer queue.

Images