MCU end DDS communication method and device and computer equipment

Abstract

The embodiment of the application relates to the technical field of automatic driving communication, and discloses an MCU end DDS communication method, device and computer equipment, the method is realized based on an MCU end DDS communication device, the device at least includes a first core, a second core and a cross-core shared memory, the first core deploys a DCPS core component, the second core deploys an RTPS core component, and the DCPS core component and the RTPS core component realize data transmission through the cross-core shared memory.The application separates and deploys the DCPS core component and the RTPS core component in the dual core, realizes efficient data interaction through the cross-core shared memory, the dual-core separation deployment enables the parallel execution of the calculation-intensive task and the I / O-intensive task, so that the parallel processing capacity of the multi-core MCU is fully released, single-core resource preemption is avoided, and the waste of computing power is reduced; the asynchronous sending mechanism is adopted to reduce the communication delay and jitter, and the priority of key services is guaranteed; and the dual-core parallel processing improves the data transmission throughput, and simultaneously enhances the system running stability.

Description

Technical Field

[0001] This invention relates to the field of autonomous driving communication technology, specifically to a DDS communication method, apparatus, and computer device for an MCU. Background Technology

[0002] In multi-core MCU real-time operating processor systems, DDS services are mainly deployed through a lightweight solution with feature trimming and protocol simplification, with the core relying on a single-threaded model for data transmission and reception.

[0003] With the widespread adoption of multi-core architectures in modern high-performance MCUs, such as dual-core Cortex-M7, and the high-frequency communication requirements of multi-topic publish-subscribe, the adaptability shortcomings of traditional DDS services have become increasingly prominent. They have failed to fully utilize hardware parallel capabilities and have not been deeply optimized for MCU hardware and software characteristics and user scenario requirements.

[0004] Traditional DDS services integrate the DCPS control plane and RTPS data plane onto a single core. In multi-topic, high-bandwidth communication scenarios, this single core must simultaneously handle application services and network protocol stack processing, leading to excessive CPU load. This directly results in increased communication latency, jitter, and insufficient throughput for critical business topics, failing to meet real-time and deterministic requirements and creating a system performance bottleneck.

[0005] In addition, traditional DDS services are not designed for multi-core MCUs, and computationally intensive and I / O-intensive tasks are not properly allocated. Some cores are idle or under low load for a long time, resulting in low utilization of multi-core resources and wasted computing power. Data transmission adopts a synchronous blocking mode, which is susceptible to network congestion, causing application task response delays and uncertain execution times. Data reception relies on periodic polling, which wastes CPU cycles when there is no data, causing unnecessary context switching and resulting in an inefficient data transmission and reception mechanism. Summary of the Invention

[0006] To address the problem that existing DDS services concentrate the DCPS control plane and RTPS data plane on a single core, resulting in increased communication latency, jitter, and insufficient throughput for critical business topics, thus failing to meet real-time and deterministic requirements, this invention provides an MCU-side DDS communication method, apparatus, and computer device.

[0007] According to an embodiment of the present invention, an MCU-side DDS communication method is provided, which is implemented based on an MCU-side DDS communication device. The device includes at least a first core, a second core, and cross-core shared memory. The first core deploys a DCPS core component, and the second core deploys an RTPS core component. The DCPS core component and the RTPS core component achieve data transmission through cross-core shared memory. The method includes the following steps: S10. The DCPS core component receives business tasks, parses out topic sample data, stores the topic sample data into the dedicated cache of the corresponding writer according to the associated topic metadata, and pushes it into the priority queue of the corresponding level. S20. The DCPS core component sends a scheduling task, traverses the priority queue according to the priority of the topic metadata, and dynamically schedules the topic sample data out of the queue according to the priority. S30. The DCPS core component schedules the dequeued topic sample data into a specified area of ​​cross-core shared memory according to the topic metadata, and sends an RTPS send event to the RTPS core component; S40. The RTPS core component listens for and responds to RTPS send events, reads topic sample data from cross-core shared memory, encapsulates it, and sends it. S50. The RTPS core component listens to the network port, receives and parses the encapsulated topic sample data, writes the topic sample data into the corresponding area of ​​the cross-core shared memory according to the topic metadata, and sends an RTPS receive event to the DCPS core component. S60. The DCPS core component responds to RTPS receive events, reads topic sample data, and stores the topic sample data into the dedicated cache of the corresponding reader according to the associated topic metadata; The S70 DCPS core component sends event signals based on topic metadata to trigger events and wake up applications.

[0008] In some optional implementations, step S10 involves the DCPS core component receiving the business task, parsing the topic sample data, storing the topic sample data into the dedicated cache of the corresponding writer based on the associated topic metadata, and simultaneously pushing it into the priority queue of the corresponding level. Specifically, this includes: S101. The DCPS core component receives business tasks, generates corresponding topic sample data according to the business tasks, and predefines topic metadata for each topic sample data. S102. Call the asynchronous send interface to store the topic sample data into the dedicated cache of the corresponding writer according to the topic metadata; S103. The writer pushes its index into the priority queue of the corresponding level according to the priority in the topic metadata, and sends the asynchronous interface back. The topic metadata includes attribute classes, scheduling classes, and interaction classes; The attribute class includes topic ID, data type, and associated task ID; The scheduling class includes priority, bandwidth weight, minimum transmission interval, and transmission deadline; The interaction class includes lightweight event IDs and QoS policies.

[0009] In some optional implementations, step S20. The DCPS core component sends a scheduling task, traverses the priority queue according to the priority of the topic metadata, and dynamically schedules the topic sample data out of the queue according to the priority, specifically including: S201. The DCPS core component sends a scheduling task to start the periodic scheduling, starting from the head of the highest priority queue and traversing the priority queue according to the priority of the topic metadata; S202. Calculate the expected bandwidth throughput of the topic sample data based on the bandwidth weight of the corresponding topic metadata. If the expected bandwidth throughput meets the standard, the topic sample data is downgraded; otherwise, the topic sample data is dequeued. S203. Perform a deadline check. Starting from the head of the lowest priority queue, check the topic sample data sequentially to see if it has reached the sending deadline. If so, upgrade the topic sample data. S204. Update the topic sample data statistics and priority queue status of the dequeuing node. If the number of topic sample data to be scheduled in a single cycle exceeds the preset threshold or the scheduling processing cycle time exceeds the scheduling deadline, immediately end the current scheduling cycle.

[0010] In some optional implementations, step S30, where the DCPS core component schedules the dequeued topic sample data into a specified area of ​​cross-core shared memory according to the topic metadata, and sends an RTPS transmission event to the RTPS core component, specifically includes: S301. The DCPS core component writes the dequeued topic sample data into a specified area of ​​cross-core shared memory according to the topic metadata. S302. The DCPS core component sends an RTPS transmission event to the RTPS core component.

[0011] In some optional implementations, step S40. The RTPS core component listens for and responds to RTPS send events, reads topic sample data from cross-core shared memory, encapsulates it, and sends it, specifically including: S401. The RTPS core component listens for and responds to RTPS transmission events, and obtains the data address and transmission rules in the cross-core shared memory based on the topic metadata associated with the topic sample data; S402. After reading the topic sample data, encapsulate it into an RTPS protocol message and send the RTPS protocol message through the network port; S403. After the RTPS core component completes the transmission of the RTPS protocol message, it sends back status information to the DCPS core component, and adjusts the status based on the number of topic sample data and the cache status.

[0012] In some optional implementations, step S50. The RTPS core component listens to the network port, receives and parses the encapsulated topic sample data, writes the topic sample data into the corresponding area of ​​the cross-core shared memory according to the topic metadata, and sends an RTPS receive event to the DCPS core component, specifically including: S501. The RTPS core component listens to the network port, receives RTPS protocol messages, parses them, and obtains topic sample data and topic metadata associated with the topic sample data; S502. Using the topic metadata, write the topic sample data into the corresponding area of ​​the cross-core shared memory; S503. Send an RTPS receive event to the DCPS core component to trigger receive processing.

[0013] In some optional implementations, step S60. The DCPS core component responds to the RTPS receive event and reads topic sample data from cross-core shared memory, storing the topic sample data into the dedicated cache of the corresponding reader according to the associated topic metadata, specifically including: S601. The DCPS core component responds to RTPS receive events and reads topic sample data from cross-core shared memory; S602. Based on the caching structure rules of the associated topic metadata, store the topic sample data into the dedicated cache of the corresponding reader and mark the cache status.

[0014] In some optional implementations, step S70. The DCPS core component sends event signals based on the topic metadata to trigger events and wake up the application, specifically including: S701. The DCPS core component calls the topic sample receiving and processing interface to send event signals to the business task based on the lightweight event ID of the topic metadata; S702. Upon receiving an event signal, the business task is immediately awakened, associates with the corresponding reader through the topic ID, reads topic sample data from the reader's dedicated cache, and performs business processing. S703. After processing is complete, the business task resets its cache state and returns to suspension, waiting for the next event notification.

[0015] According to another objective of the present invention, an MCU-side DDS communication device is provided, comprising at least a first core, a second core, and cross-core shared memory. The first core deploys a DCPS core component, and the second core deploys an RTPS core component. The DCPS core component and the RTPS core component communicate through the cross-core shared memory. The DCPS core component is used to receive business tasks, parse out topic sample data, store the topic sample data into the dedicated cache of the corresponding writer according to the associated topic metadata, and push it into the priority queue of the corresponding level; send scheduling tasks, traverse the priority queue according to the priority of the topic metadata, and dynamically schedule the topic sample data out of the queue according to the priority; write the scheduled topic sample data into a designated area of ​​cross-core shared memory according to the topic metadata, and send an RTPS send event to the RTPS core component; respond to RTPS receive events, read topic sample data, store the topic sample data into the dedicated cache of the corresponding reader according to the associated topic metadata; and send event signals according to the topic metadata to trigger events and wake up applications.

[0016] The RTPS core component is used to listen for and respond to RTPS send events, read topic sample data from cross-core shared memory and encapsulate and send it; listen to the network port, receive the encapsulated topic sample data, write the topic sample data into the corresponding area of ​​cross-core shared memory according to the topic metadata, and send RTPS receive events. The cross-core shared memory is used to cache the topic sample data scheduled out of the DCPS core component and send RTPS send events to the RTPS core component; it also caches the topic sample data parsed by the RTPS core component and sends RTPS receive events to the DCPS core component.

[0017] According to another objective of the present invention, a computer device is provided, comprising: a processor, a memory, a communication interface, and a communication bus, wherein the processor, the memory, and the communication interface communicate with each other through the communication bus; The memory is used to store at least one executable instruction that causes the processor to perform an operation of an MCU-side DDS communication method as described in any of the above.

[0018] Compared with the prior art, the present invention has the following advantages: This invention provides a DDS communication method for MCUs. By separately deploying the DCPS core component and the RTPS core component on a dual-core architecture and achieving efficient data interaction through cross-core shared memory, the separate deployment of the dual cores enables the parallel execution of computationally intensive and I / O-intensive tasks, thereby fully releasing the parallel processing capabilities of the multi-core MCU, avoiding single-core resource contention, and reducing computing power waste. The asynchronous transmission mechanism reduces communication latency and jitter, ensuring the priority of critical services. Furthermore, the dual-core parallel processing improves data transmission throughput and enhances system operational stability.

[0019] The above description is merely an overview of the technical solutions of the embodiments of the present invention. In order to better understand the technical means of the embodiments of the present invention and to implement them in accordance with the contents of the specification, and to make the above and other objects, features and advantages of the embodiments of the present invention more apparent and understandable, specific embodiments of the present invention are described below. Attached Figure Description

[0020] The accompanying drawings are for illustrative purposes only and are not intended to limit the invention. Furthermore, the same reference numerals denote the same parts throughout the drawings. In the drawings: Figure 1 The diagram shows a flowchart of a DDS communication method for an MCU provided by an embodiment of the present invention.

[0021] Figure 2 This diagram illustrates a dual-core shared interaction of a DDS communication method on an MCU side provided by an embodiment of the present invention.

[0022] Figure 3 The following is a schematic diagram illustrating the implementation process of step S10 of the MCU-side DDS communication method provided in an embodiment of the present invention.

[0023] Figure 4 The following is a schematic diagram illustrating step S10 of the MCU-side DDS communication method provided in this embodiment of the invention, which implements asynchronous enqueueing of service data.

[0024] Figure 5 The following is a schematic diagram illustrating the implementation process of step S20 of the MCU-side DDS communication method provided in an embodiment of the present invention.

[0025] Figure 6 The following is a schematic diagram illustrating step S20 of the MCU-side DDS communication method provided in this embodiment of the invention to implement priority dynamic scheduling and dequeueing.

[0026] Figure 7 The following is a schematic diagram illustrating step S20 of the MCU-side DDS communication method provided in this embodiment of the invention to implement priority dynamic scheduling and dequeueing.

[0027] Figure 8The following is a schematic diagram illustrating the implementation process of step S40 of the MCU-side DDS communication method provided in an embodiment of the present invention.

[0028] Figure 9 The following is a schematic diagram illustrating the implementation process of step S50 of the MCU-side DDS communication method provided in an embodiment of the present invention.

[0029] Figure 10 The following is a schematic diagram illustrating the implementation process of step S70 of the MCU-side DDS communication method provided in an embodiment of the present invention.

[0030] Figure 11 The diagram shows a structural block diagram of an MCU-side DDS communication device provided in an embodiment of the present invention.

[0031] Figure 12 A structural block diagram of a computer device provided by an embodiment of the present invention is shown. Detailed Implementation

[0032] Exemplary embodiments of the invention will now be described in more detail with reference to the accompanying drawings. While exemplary embodiments of the invention are shown in the drawings, it should be understood that the invention can be implemented in various forms and should not be limited to the embodiments set forth herein.

[0033] To address the problem that existing DDS services concentrate the DCPS control plane and RTPS data plane on a single core, resulting in increased communication latency, jitter, and insufficient throughput for critical business topics, thus failing to meet real-time and deterministic requirements, this invention provides a DDS communication method for MCU terminals.

[0034] This embodiment provides a MCU-side DDS communication method, implemented based on an MCU-side DDS communication device, such as... Figure 8 As shown, it includes at least a first core, a second core, and cross-core shared memory. The first core deploys the DCPS core component and is responsible for the DCPS layer logic. The second core deploys the RTPS core component and is responsible for the RTPS layer logic. The cross-core shared memory establishes two types of inter-core notification channels based on the CP AUTOSARIOC mechanism: RTPS sending events and RTPS receiving events. This enables the DCPS core component and the RTPS core component to transmit data through the cross-core shared memory.

[0035] In this embodiment, the first core is also called core 0, and the second core is also called core 1. The control plane and data plane of DDS are deployed separately on core 0 and core 1 to realize the physical isolation between computationally intensive tasks and I / O intensive tasks by utilizing the parallel capabilities of multiple cores.

[0036] In this embodiment, core 0 or the DCPS core component mainly implements functions such as topic management, cache control, and scheduling algorithms, while core 1 or the RTPS core component mainly implements functions such as network communication and protocol parsing.

[0037] This embodiment provides a DDS communication method for an MCU, such as... Figure 1-2 As shown, it includes the following steps: S10. The DCPS core component receives the business task, parses out the topic sample data, stores the topic sample data into the dedicated cache of the corresponding writer according to the associated topic metadata, and pushes it into the priority queue of the corresponding level.

[0038] In this step, after the business task submits topic sample data, the topic sample data is associated with topic metadata according to predefined rules, and the topic metadata is bound to the writer and stored in the priority queue of the corresponding level. This realizes the configuration of topic sample data and topic metadata, as well as the binding relationship between topic metadata and writer and queue.

[0039] Therefore, this step involves temporarily storing the topic sample data through an asynchronous queue.

[0040] S20. The DCPS core component sends a scheduling task, traverses the priority queue according to the priority of the topic metadata, and dynamically schedules the topic sample data out of the queue according to the priority.

[0041] In this step, independent scheduling tasks are processed according to topic metadata rules, avoiding network congestion from blocking application tasks, while dynamic priority ensures transmission fairness.

[0042] S30. The DCPS core component schedules the dequeued topic sample data into a specified area of ​​cross-core shared memory according to the topic metadata, and sends an RTPS send event to the RTPS core component.

[0043] S40. The RTPS core component listens for and responds to RTPS send events, reads topic sample data from cross-core shared memory, encapsulates it, and sends it.

[0044] S50. The RTPS core component listens to the network port, receives and parses the encapsulated topic sample data, writes the topic sample data into the corresponding area of ​​cross-core shared memory according to the topic metadata, and sends an RTPS receive event to the DCPS core component.

[0045] Steps S30-S50 above enable zero-copy transmission of topic sample data between dual cores based on cross-core shared memory. Event notifications trigger processing on the other end, avoiding the high overhead of inter-core task switching and ensuring efficient collaboration between the data plane and the control plane.

[0046] S60. The DCPS core component responds to RTPS receive events, reads topic sample data, and stores the topic sample data into the dedicated cache of the corresponding reader based on the associated topic metadata.

[0047] The S70 DCPS core component sends event signals based on topic metadata to trigger events and wake up applications.

[0048] Steps S60-S70 above replace traditional polling with event wake-up, allowing application subscribers to activate only when there is new topic sample data, eliminating CPU waste when there is no topic sample data, and ensuring the accuracy of topic sample data reading through dedicated caching.

[0049] This embodiment provides an MCU-side DDS communication method that separates the DCPS core component and the RTPS core component on a dual-core architecture and achieves efficient data interaction through cross-core shared memory. The separate deployment of the dual cores allows computationally intensive tasks and I / O-intensive tasks to be executed in parallel, thereby fully releasing the parallel processing capabilities of the multi-core MCU, avoiding contention for single core resources, and reducing computing power waste. The asynchronous transmission mechanism reduces communication latency and jitter, ensuring the priority of critical services. Furthermore, the dual-core parallel processing improves data transmission throughput and enhances system stability.

[0050] This embodiment, as a preferred embodiment, optimizes the implementation process of step S10, in which the DCPS core component receives the service task, parses out the topic sample data, stores the topic sample data into the dedicated cache of the corresponding writer according to the associated topic metadata, and pushes it into the priority queue of the corresponding level.

[0051] In this embodiment, step S10 involves the DCPS core component receiving a service task, parsing out the topic sample data, storing the topic sample data into the dedicated cache of the corresponding writer according to the associated topic metadata, and simultaneously pushing it into the priority queue of the corresponding level, such as... Figure 3 Specifically, it includes: S101. The DCPS core component receives business tasks, generates corresponding topic sample data based on the business tasks, and predefines topic metadata for each topic sample data.

[0052] In this step, topic metadata was predefined for each topic sample data.

[0053] The topic metadata includes attribute classes, scheduling classes, and interaction classes; The attribute class includes topic ID, data type, and associated task ID; The scheduling categories include priority (levels 1-5), bandwidth weight, minimum transmission interval, and transmission deadline; Interaction classes include lightweight event IDs and QoS policies.

[0054] S102. Call the asynchronous send interface to store the topic sample data into the dedicated cache of the corresponding writer based on the topic metadata.

[0055] S103. The writer pushes its index into the priority queue of the corresponding level according to the priority in the topic metadata, and the asynchronous sending interface returns the result.

[0056] The specific implementation process of this step is illustrated with an example, such as... Figure 4 As shown, the DCPS core component receives business tasks, namely the first business task1 and the second business task5. The first business task1 generates the first topic sample data 1, and the second business task5 generates the second topic sample data 5. The task1 calls the asynchronous sending interface of core 0, namely the topic sample sending interface, carrying the topic ID.

[0057] The topic sample sending interface queries the priority of the corresponding topic metadata. That is, the topic sample sending interface queries the priority of the first topic metadata 1 corresponding to the first topic sample data 1, and queries the priority of the second topic metadata 5 corresponding to the second topic sample data 5.

[0058] The first topic sample data 1 and the second topic sample data 5 are serialized and stored in the dedicated cache of the corresponding writer. That is, the first writer w1 caches the first topic sample data 1, and the second writer w5 caches the second topic sample data 5.

[0059] Extract the writer index and push the corresponding topic sample data into the corresponding priority queue according to the priority of the topic metadata.

[0060] After the topic sample data is asynchronously enqueued, the asynchronous sending interface returns, and the business task does not need to wait for the network to send the data, and can continue to execute its own logic.

[0061] This embodiment is a preferred embodiment, and the implementation process of step S20, whereby the DCPS core component sends a scheduling task, traverses the priority queue according to the priority of the topic metadata, and dynamically schedules the topic sample data out of the queue according to the priority, has been optimized.

[0062] In this embodiment, as Figure 5 As shown, step S20. The DCPS core component sends a scheduling task, traverses the priority queue according to the priority of the topic metadata, and dynamically schedules the topic sample data out of the queue according to the priority, specifically including: S201. The DCPS core component sends a scheduling task to start the periodic scheduling, starting from the head of the highest priority queue and traversing the priority queue according to the priority of the topic metadata; S202. Calculate the expected bandwidth throughput of the topic sample data based on the bandwidth weight of the corresponding topic metadata. If the expected bandwidth throughput meets the standard, the topic sample data is dynamically downgraded; otherwise, the topic sample data is dequeued. S203. Perform a deadline check. Starting from the head of the lowest priority queue, check the topic sample data sequentially to see if it has reached the sending deadline. If so, upgrade the topic sample data. S204. Update the topic sample data statistics and priority queue status of the dequeuing node. If the number of topic sample data to be scheduled in a single cycle exceeds the preset threshold or the scheduling processing cycle time exceeds the scheduling deadline, immediately end the current scheduling cycle.

[0063] The implementation process of this step is illustrated with an example, such as... Figures 6-7 As shown, The core 0's sending scheduling task starts periodic scheduling, traversing from the priority 1 queue: checking the head node, such as the expected bandwidth throughput B of the first writer w1. If B ≥ the threshold, then dynamically downgrade, from priority 2 to priority 3. If B < the threshold, then the topic sample data is dequeued.

[0064] Where B = topic bandwidth throughput × bandwidth weight.

[0065] Perform a deadline check: Starting from the head of the priority 5 queue, if a node reaches its sending deadline, such as the second topic sample data 5 timeout, the priority is dynamically upgraded from priority 5 to priority 3 to ensure that critical topic sample data is not missed.

[0066] After the topic sample data corresponding to the node is dequeued, the update diagram is shown. Figure 6 The system tracks topic statistics and queue status. If the number of topic sample data processed in a single cycle reaches N or the scheduling cycle time exceeds the scheduling deadline T, the scheduling is terminated immediately to avoid consuming too much computing power on core 0.

[0067] This embodiment is a preferred embodiment, and the implementation process of step S30, in which the topic sample data scheduled out by the DCPS core component is written into a specified area of ​​cross-core shared memory according to the topic metadata, and an RTPS sending event is sent to the RTPS core component, has been optimized.

[0068] In this embodiment, step S30, where the DCPS core component schedules the dequeued topic sample data and writes it into a designated area of ​​cross-core shared memory according to topic metadata, and sends an RTPS transmission event to the RTPS core component, specifically includes: S301. The DCPS core component will schedule the dequeued topic sample data and write it into the specified area of ​​cross-core shared memory according to the topic metadata.

[0069] Specifically, this step involves: after the sample data is serialized by the DCPS layer of core 0, it is written into the transmission data area of ​​the cross-core shared memory according to the QoS policy of the topic metadata.

[0070] S302. The DCPS core component sends an RTPS transmission event to the RTPS core component.

[0071] Specifically, this step involves core 0 sending an RTPS transmission event to core 1 via the CP AUTOSAR IOC mechanism. The RTPS transmission event carries the topic ID and the cross-core shared memory address.

[0072] This embodiment is a preferred embodiment, and the implementation process of step S40, in which the RTPS core component listens for and responds to RTPS transmission events, reads topic sample data from cross-core shared memory, and encapsulates and sends the data, has been optimized.

[0073] In this embodiment, as Figure 8 As shown, step S40. The RTPS core component listens for and responds to RTPS send events, reads topic sample data from cross-core shared memory, encapsulates it, and sends it. Specifically, this includes: S401. The RTPS core component listens for and responds to RTPS transmission events, and obtains the data address and transmission rules in the cross-core shared memory based on the topic metadata associated with the topic sample data.

[0074] Specifically, this step involves the RTPS core component of core 1 listening for and responding to RTPS send events, and reading topic sample data from cross-core shared memory.

[0075] S402. After reading the topic sample data, encapsulate it into an RTPS protocol message and send the RTPS protocol message through the network port.

[0076] Specifically, this step involves encapsulating the read topic sample data into an RTPS protocol message and sending it through the network port.

[0077] S403. After the RTPS core component completes the transmission of the RTPS protocol message, it sends back status information to the DCPS core component, and adjusts the status based on the number of topic sample data and the cache status.

[0078] Specifically, after the RTPS core component completes the RTPS protocol message transmission, core 1 sends status information back to core 0, and core 0 updates the number of topic sample data statistics and cache status.

[0079] This embodiment is a preferred embodiment, and the implementation process of step S50, in which the RTPS core component listens to the network port, receives and parses the encapsulated topic sample data, writes the topic sample data into the corresponding area of ​​the cross-core shared memory according to the topic metadata, and sends the RTPS receive event to the DCPS core component, has been optimized.

[0080] In this embodiment, as Figure 9 As shown, step S50. The RTPS core component listens to the network port, receives and parses the encapsulated topic sample data, writes the topic sample data into the corresponding area of ​​the cross-core shared memory according to the topic metadata, and sends an RTPS receive event to the DCPS core component, specifically including: S501. The RTPS core component listens to the network port, receives RTPS protocol messages, parses them, and obtains topic sample data and topic metadata associated with the topic sample data.

[0081] Specifically, this step involves the RTPS core component of core 1 listening to the network port, receiving RTPS protocol messages sent by the RTPS core component, parsing them, and extracting topic sample data and topic IDs.

[0082] S502. Using the topic metadata, write the topic sample data into the corresponding area of ​​cross-core shared memory.

[0083] This step specifically involves: querying the topic metadata using the topic ID, and writing the topic sample data into the receive data area of ​​the cross-core shared memory.

[0084] S503. Send an RTPS receive event to the DCPS core component to trigger receive processing.

[0085] This embodiment, as a preferred embodiment, optimizes the implementation process of step S60: the DCPS core component responds to the RTPS receive event, reads topic sample data from cross-core shared memory, and stores the topic sample data into the dedicated cache of the corresponding reader according to the associated topic metadata.

[0086] In this implementation, step S60. The DCPS core component responds to the RTPS receive event and reads topic sample data from the cross-core shared memory. Based on the associated topic metadata, it stores the topic sample data into the dedicated cache of the corresponding reader, specifically including: S601. The DCPS core component responds to RTPS receive events and reads topic sample data from cross-core shared memory.

[0087] Specifically, this step involves the DCPS core component of core 0 responding to the RTPS receive event and reading topic sample data from the receive data area of ​​the cross-core shared memory.

[0088] S602. Based on the caching structure rules of the associated topic metadata, store the topic sample data into the dedicated cache of the corresponding reader and mark the cache status.

[0089] Specifically, this step involves storing the topic sample data into the dedicated cache of the corresponding reader based on the cache structure rules in the topic metadata, and marking the cache status as having new data.

[0090] This embodiment is a preferred embodiment, and the implementation process of step S70, whereby the DCPS core component sends an event signal based on the topic metadata to trigger the event and wake up the application, has been optimized.

[0091] In this implementation, such as Figure 10 As shown, step S70. The DCPS core component sends event signals based on the topic metadata to trigger events and wake up applications, specifically including: S701. The DCPS core component calls the topic sample receiving and processing interface to send event signals to the business task based on the lightweight event ID of the topic metadata.

[0092] Specifically, this step involves Core 0 calling the topic sample receiving and processing interface to send event signals to business tasks or application subscribers based on the lightweight event ID in the topic metadata.

[0093] S702. Upon receiving an event signal, the business task is immediately awakened, associates with the corresponding reader through the topic ID, reads topic sample data from the reader's dedicated cache, and performs business processing.

[0094] This step is as follows: Business tasks or application subscribers are usually in a suspended state while waiting for the event. Upon receiving the event signal, they are immediately awakened, associated with the corresponding reader through the topic ID, and read topic sample data from the reader's dedicated cache and process it. S703. After processing is complete, the business task resets its cache state and returns to suspension, waiting for the next event notification.

[0095] Specifically, after completing the business task for this period, the business task resets its cache state and returns to suspension, waiting for the next event notification.

[0096] In some optional embodiments, the present invention also discloses an MCU-side DDS communication device.

[0097] This embodiment provides a DDS communication device for an MCU, such as Figure 11As shown, it includes at least a first core, a second core, and cross-core shared memory. The first core deploys a DCPS core component, and the second core deploys an RTPS core component. The DCPS core component and the RTPS core component communicate through cross-core shared memory.

[0098] In this embodiment, the first core is also called core 0, and the second core is also called core 1. The control plane and data plane of DDS are deployed separately on core 0 and core 1 to realize the physical isolation between computationally intensive tasks and I / O intensive tasks by utilizing the parallel capabilities of multiple cores.

[0099] In this embodiment, the DCPS core component 100 is used to receive service tasks, parse out topic sample data, store the topic sample data into the dedicated cache of the corresponding writer according to the associated topic metadata, and push it into the priority queue of the corresponding level; send scheduling tasks, traverse the priority queue according to the priority of the topic metadata, and dynamically schedule the topic sample data out of the queue according to the priority; write the scheduled topic sample data into a designated area of ​​cross-core shared memory according to the topic metadata, and send an RTPS send event to the RTPS core component 200; respond to the RTPS receive event, read the topic sample data, store the topic sample data into the dedicated cache of the corresponding reader according to the associated topic metadata; and send event signals according to the topic metadata to trigger events and wake up applications.

[0100] The RTPS core component 200 is used to listen for and respond to RTPS send events, read topic sample data from cross-core shared memory and encapsulate and send it; listen to the network port, receive the encapsulated topic sample data, write the topic sample data into the corresponding area of ​​cross-core shared memory according to the topic metadata, and send RTPS receive events.

[0101] The cross-core shared memory 300 is used to cache the topic sample data scheduled out of the DCPS core component 100 and send RTPS send events to the RTPS core component 200; and to cache the topic sample data parsed by the RTPS core component 200 and send RTPS receive events to the DCPS core component 100.

[0102] In this embodiment, the specific implementation process of data interaction between the DCPS core component 100 and the RTPS core component 200 through cross-core shared memory 300 is described in detail in the specific implementation process of the MCU-side DDS communication method in the above embodiment, and will not be repeated in this embodiment.

[0103] In some alternative embodiments, the present invention also discloses a computer device.

[0104] This embodiment provides a computer device, such as... Figure 12As shown, it includes: processor 410, memory 420, communication interface 430 and communication bus 440. The processor 410, memory 420 and communication interface 430 communicate with each other through communication bus 440.

[0105] In this embodiment, the memory 420 stores at least one executable instruction, which causes the processor 420 to perform operations of an MCU-side DDS communication method as described in any of the above embodiments; the communication interface 430 is used to communicate with other network elements such as clients or other servers. The processor 410 is used to execute program 450, specifically performing the relevant steps in the above embodiments of the MCU-side DDS communication method.

[0106] Specifically, program 450 may include program code, which includes computer-executable instructions.

[0107] Processor 410 may be a central processing unit (CPU), an application-specific integrated circuit (ASIC), or one or more integrated circuits configured to implement embodiments of the present invention. The computer device includes one or more processors, which may be processors of the same type, such as one or more CPUs; or processors of different types, such as one or more CPUs and one or more ASICs.

[0108] Memory 420 is used to store program 450. Memory 420 may include high-speed RAM memory, and may also include non-volatile memory, such as at least one disk storage device.

[0109] Specifically, program 450 can be called by processor 410 to cause the computer device to perform the operation of the MCU-side DDS communication method described in any of the above embodiments.

[0110] In some optional embodiments, the present invention also discloses a computer-readable storage medium storing at least one executable instruction that, when executed on a computer device, causes the computer device to perform the steps of an MCU-side DDS communication method in any of the above method embodiments.

[0111] The specific implementation process of the MCU-side DDS communication method described in this embodiment can be found in any of the above method embodiments, and will not be repeated in this embodiment.

[0112] Numerous specific details are set forth in the specification provided herein. However, it will be understood that embodiments of the invention may be practiced without these specific details. Similarly, for the sake of brevity and to aid in understanding one or more aspects of the invention, in the description of exemplary embodiments of the invention above, various features of the embodiments are sometimes grouped together in a single embodiment, figure, or description thereof. The claims, which follow the detailed description, are hereby expressly incorporated into that detailed description, wherein each claim itself is a separate embodiment of the invention.

[0113] Those skilled in the art will understand that the modules in the device of the embodiment can be adaptively changed and placed in one or more devices different from that embodiment. Modules, units, or components in the embodiment can be combined into a single module, unit, or component, and further, they can be divided into multiple sub-modules, sub-units, or sub-components, except that at least some of such features and / or processes or units are mutually exclusive.

[0114] It should be noted that the above embodiments are illustrative of the invention and not restrictive, and that those skilled in the art can devise alternative embodiments without departing from the scope of the appended claims. In the claims, any reference signs placed between parentheses should not be construed as limiting the claims. The word "comprising" does not exclude the presence of elements or steps not listed in the claims. The word "a" or "an" preceding an element does not exclude the presence of a plurality of such elements. The invention can be implemented by means of hardware comprising several different elements and by means of a suitably programmed computer. In the unit claims enumerating several means, several of these means may be embodied by the same item of hardware. The use of the words first, second, and third, etc., does not indicate any order. These words can be interpreted as names. The steps in the above embodiments, unless otherwise specified, should not be construed as limiting the order of execution.

Claims

1. A DDS communication method for an MCU, characterized in that, Implemented based on MCU-side DDS communication device, the device includes at least a first core, a second core and cross-core shared memory, the first core deploys DCPS core components, the second core deploys RTPS core components, and the DCPS core components and the RTPS core components realize data transmission through cross-core shared memory; The method includes the following steps: S10. The DCPS core component receives business tasks, parses out topic sample data, stores the topic sample data into the dedicated cache of the corresponding writer according to the associated topic metadata, and pushes it into the priority queue of the corresponding level. S20. The DCPS core component sends a scheduling task, traverses the priority queue according to the priority of the topic metadata, and dynamically schedules the topic sample data out of the queue according to the priority. S30. The DCPS core component schedules the dequeued topic sample data into a specified area of ​​cross-core shared memory according to the topic metadata, and sends an RTPS send event to the RTPS core component; S40. The RTPS core component listens for and responds to RTPS send events, reads topic sample data from cross-core shared memory, encapsulates it, and sends it. S50. The RTPS core component listens to the network port, receives and parses the encapsulated topic sample data, writes the topic sample data into the corresponding area of ​​the cross-core shared memory according to the topic metadata, and sends an RTPS receive event to the DCPS core component. S60. The DCPS core component responds to RTPS receive events, reads topic sample data, and stores the topic sample data into the dedicated cache of the corresponding reader according to the associated topic metadata; The S70 DCPS core component sends event signals based on topic metadata to trigger events and wake up applications.

2. The MCU-side DDS communication method according to claim 1, characterized in that, Step S10: The DCPS core component receives the business task, parses out the topic sample data, stores the topic sample data into the dedicated cache of the corresponding writer according to the associated topic metadata, and pushes it into the priority queue of the corresponding level. Specifically, this includes: S101. The DCPS core component receives business tasks, generates corresponding topic sample data according to the business tasks, and predefines topic metadata for each topic sample data. S102. Call the asynchronous send interface to store the topic sample data into the dedicated cache of the corresponding writer according to the topic metadata; S103. The writer pushes its index into the priority queue of the corresponding level according to the priority in the topic metadata, and sends the asynchronous interface back. The topic metadata includes attribute classes, scheduling classes, and interaction classes; The attribute class includes topic ID, data type, and associated task ID; The scheduling class includes priority, bandwidth weight, minimum transmission interval, and transmission deadline; The interaction class includes lightweight event IDs and QoS policies.

3. The MCU-side DDS communication method according to claim 1, characterized in that, Step S20. The DCPS core component sends a scheduling task, traverses the priority queue according to the priority of the topic metadata, and dynamically schedules the topic sample data out of the queue according to the priority, specifically including: S201. The DCPS core component sends a scheduling task to start the periodic scheduling, starting from the head of the highest priority queue and traversing the priority queue according to the priority of the topic metadata; S202. Calculate the expected bandwidth throughput of the topic sample data based on the bandwidth weight of the corresponding topic metadata. If the expected bandwidth throughput meets the standard, the topic sample data is downgraded; otherwise, the topic sample data is dequeued. S203. Perform a deadline check. Starting from the head of the lowest priority queue, check the topic sample data sequentially to see if it has reached the sending deadline. If so, upgrade the topic sample data. S204. Update the topic sample data statistics and priority queue status of the dequeuing node. If the number of topic sample data to be scheduled in a single cycle exceeds the preset threshold or the scheduling processing cycle time exceeds the scheduling deadline, immediately end the current scheduling cycle.

4. The MCU-side DDS communication method according to claim 1, characterized in that, Step S30. The DCPS core component schedules the dequeued topic sample data into a designated area of ​​cross-core shared memory according to the topic metadata, and sends an RTPS transmission event to the RTPS core component, specifically including: S301. The DCPS core component writes the dequeued topic sample data into a specified area of ​​cross-core shared memory according to the topic metadata. S302. The DCPS core component sends an RTPS transmission event to the RTPS core component.

5. The MCU-side DDS communication method according to claim 1, characterized in that, Step S40. The RTPS core component listens for and responds to RTPS send events, reads topic sample data from cross-core shared memory, encapsulates it, and sends it. Specifically, this includes: S401. The RTPS core component listens for and responds to RTPS transmission events, and obtains the data address and transmission rules in the cross-core shared memory based on the topic metadata associated with the topic sample data; S402. After reading the topic sample data, encapsulate it into an RTPS protocol message and send the RTPS protocol message through the network port; S403. After the RTPS core component completes the transmission of the RTPS protocol message, it sends back status information to the DCPS core component and updates the number of topic sample data and cache status.

6. A DDS communication method for an MCU terminal according to claim 5, characterized in that, Step S50. The RTPS core component listens to the network port, receives and parses the encapsulated topic sample data, writes the topic sample data into the corresponding area of ​​the cross-core shared memory according to the topic metadata, and sends an RTPS receive event to the DCPS core component, specifically including: S501. The RTPS core component listens to the network port, receives RTPS protocol messages, parses them, and obtains topic sample data and topic metadata associated with the topic sample data; S502. Using the topic metadata, write the topic sample data into the corresponding area of ​​the cross-core shared memory; S503. Send an RTPS receive event to the DCPS core component to trigger receive processing.

7. The MCU-side DDS communication method according to claim 1, characterized in that, Step S60. The DCPS core component responds to the RTPS receive event, reads the topic sample data, and stores the topic sample data into the corresponding reader's dedicated cache according to the associated topic metadata. Specifically, this includes: S601. The DCPS core component responds to RTPS receive events and reads topic sample data from cross-core shared memory; S602. Based on the caching structure rules of the associated topic metadata, store the topic sample data into the dedicated cache of the corresponding reader and mark the cache status.

8. The MCU-side DDS communication method according to claim 1, characterized in that, Step S70. The DCPS core component sends event signals based on the topic metadata to trigger events and wake up applications, specifically including: S701. The DCPS core component calls the topic sample receiving and processing interface to send event signals to the business task based on the lightweight event ID of the topic metadata; S702. Upon receiving an event signal, the business task is immediately awakened, associates with the corresponding reader through the topic ID, reads topic sample data from the reader's dedicated cache, and performs business processing. S703. After processing is complete, the business task resets its cache state and returns to suspension, waiting for the next event notification.

9. A DDS communication device for an MCU, characterized in that, It includes at least a first core, a second core, and cross-core shared memory. The first core deploys a DCPS core component, and the second core deploys an RTPS core component. The DCPS core component and the RTPS core component communicate through cross-core shared memory. The DCPS core component is used to receive business tasks, parse out topic sample data, store the topic sample data into the dedicated cache of the corresponding writer according to the associated topic metadata, and push it into the priority queue of the corresponding level. Send a scheduling task, traverse the priority queue according to the priority of the topic metadata, and dynamically schedule the topic sample data out of the queue according to the priority; write the scheduled topic sample data into a specified area of ​​cross-core shared memory according to the topic metadata, and send an RTPS send event to the RTPS core component; respond to the RTPS receive event, read the topic sample data, and store the topic sample data into the dedicated cache of the corresponding reader according to the associated topic metadata; And send event signals based on topic metadata to trigger events and wake up applications; The RTPS core component is used to listen for and respond to RTPS send events, read topic sample data from cross-core shared memory and encapsulate and send it; listen to the network port, receive the encapsulated topic sample data, write the topic sample data into the corresponding area of ​​cross-core shared memory according to the topic metadata, and send RTPS receive events. The cross-core shared memory is used to cache the topic sample data scheduled out of the DCPS core components; The topic sample data parsed by the RTPS core component is cached.

10. A computer device, characterized in that, include: The processor, memory, communication interface, and communication bus are provided, wherein the processor, memory, and communication interface communicate with each other via the communication bus. The memory is used to store at least one executable instruction, which causes the processor to perform the operation of the MCU-side DDS communication method as described in any one of claims 1-8.

Images