Data transmission method based on inter-process communication, electronic device and chip

Abstract

This application discloses a data transmission method, electronic device, and chip based on inter-process communication (IPC), belonging to the field of computer technology. The method includes: receiving a target data packet sent by a second processing core through an IPC channel; wherein the target data packet is encapsulated by the second processing core according to a preset protocol format, including business data and protocol header information, the protocol header information including at least a target business identifier for identifying the business type to which the business data belongs; parsing the protocol header information to extract the target business identifier, and routing the business data in the target data packet to the target message queue mapped by the target business identifier; configuring a business read interface so that upper-layer applications can subscribe to the target message queue and read the business data therein by calling the business read interface, thus decoupling the business data from the IPC channel. This application improves the flexibility and scalability of data transmission between different processing cores in a multi-core processing system.

Description

Technical Field

[0001] This application belongs to the field of computer technology, and in particular relates to a data transmission method, electronic device and chip based on inter-process communication. Background Technology

[0002] In the architecture of autonomous driving chips, the collaborative work between different processing cores in the domain controller is crucial for real-time decision-making and control.

[0003] In related technologies, data transmission between different processing cores is usually achieved through inter-process communication (IPC) based on shared memory. The typical mechanism is that the sender writes data into a pre-allocated shared memory area and notifies the receiver to complete the data reading by triggering a hardware interrupt.

[0004] However, the aforementioned point-to-point communication method has limitations. Since each IPC channel only transmits one type of service data, there is a lack of flexible adaptation mechanisms when service data needs to dynamically switch IPC channels or change the processing core of the service. This results in fixed communication paths and high coupling, making it difficult to meet the multi-task, multi-channel, and high-concurrency data interaction requirements in autonomous driving scenarios.

[0005] Therefore, improving the flexibility and scalability of data transfer between processing cores is an urgent problem to be solved. Summary of the Invention

[0006] This application aims to address at least one of the technical problems existing in the related art. To this end, this application proposes a data transmission method, electronic device, and chip based on inter-process communication, which improves the flexibility and scalability of data transmission between different processing cores in a multi-core processing system.

[0007] In a first aspect, this application provides a data transmission method based on inter-process communication, applied to a first processing core in a multi-core processing system, wherein the first processing core and a second processing core communicate through an inter-process communication channel; the method includes: Receive target data packets sent by the second processing core through an inter-process communication channel; wherein the target data packets are encapsulated by the second processing core according to a preset protocol format, including service data and protocol header information, and the protocol header information includes at least a target service identifier for identifying the service type to which the service data belongs; Parse the protocol header information to extract the target service identifier, and route the service data in the target data packet to the target message queue mapped by the target service identifier; Configure a business read interface so that upper-layer applications can subscribe to the target message queue and read the business data therein by calling the business read interface, thereby decoupling the business data from the inter-process communication channel.

[0008] In the above technical solution, the first processing core receives the target data packet sent by the second processing core through an inter-process communication channel. The same inter-process communication channel can transmit data of different service types, making data transmission not limited to a fixed channel and processing core. This effectively decouples the data packet from the inter-process communication channel and its service processing path, improving the flexibility of data transmission. Furthermore, by embedding a service identifier corresponding to the service type in the protocol header, the first and second processing cores can identify the service type based on the protocol format, eliminating the need to bind service data to a fixed service channel. In addition, after extracting the target service identifier, the first processing core also processes the service data accordingly. According to the flexible routing to the corresponding message queue, business data can be dynamically distributed to different message queues based on the pre-configured mapping relationship, further decoupling the communication channel from specific business and reducing the channel adaptation complexity when expanding business. Then, the first processing core uses the subscribed business read interface to decouple business data from the inter-process communication channel, enabling upper-layer applications to flexibly obtain business data without having to pay attention to the details of the underlying process communication. This not only avoids direct operation of the underlying IPC channel, but also ensures that even if the inter-process communication channel changes, the upper-layer application does not need to be modified, thus improving the flexibility and scalability of data transmission between different processing cores in a multi-core processing system.

[0009] According to one embodiment of this application, routing the service data in the target data packet to the target message queue mapped by the service identifier includes: Based on a pre-established mapping table and the mapping relationship between the target service identifier and the message queue, the target message queue corresponding to the target service identifier is searched from multiple message queues. The mapping table maintains a mapping relationship between service identifiers corresponding to one or more service types and each message queue, with each service identifier corresponding to a message queue. Write the business data in the target data packet to the message queue of the target.

[0010] In the above technical solution, by using a pre-established mapping table, the message queue to which business data should be written can be quickly determined. In complex scenarios such as autonomous driving, where multiple business data are mixed, the efficiency of data transmission between different processing cores in a multi-core processing system is effectively improved. The business data in the target data packet is written to the target message queue. Subsequently, the upper-layer application can obtain the corresponding business data through the message queue, which helps to realize dynamic routing and decoupling of business data and improves the flexibility and scalability of data transmission between different processing cores in a multi-core processing system.

[0011] Secondly, this application provides a data transmission device based on inter-process communication, the device comprising: The receiving unit is configured to receive a target data packet sent by the second processing core through an inter-process communication channel; wherein the target data packet is encapsulated by the second processing core according to a preset protocol format, including service data and protocol header information, and the protocol header information includes at least a target service identifier for identifying the service type to which the service data belongs.

[0012] The parsing unit is used to parse the protocol header information to extract the target service identifier, and route the service data in the target data packet to the target message queue mapped by the target service identifier.

[0013] The configuration unit is used to configure the business read interface so that the upper layer application can subscribe to the target message queue and read the business data therein by calling the business read interface, thereby decoupling the business data from the inter-process communication channel.

[0014] Thirdly, this application provides an electronic device, comprising: The system comprises a first processing core, a second processing core, a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor, when executing the computer program, implements the data transmission method based on inter-process communication as described in the first aspect above.

[0015] Fourthly, this application provides a chip, the chip including a first processing core, a second processing core, a processor and a communication interface, the communication interface being coupled to the processor, the processor being used to run programs or instructions to implement the data transmission method based on inter-process communication as described in the first aspect.

[0016] Fifthly, this application provides a non-transitory computer-readable storage medium having a computer program stored thereon, wherein the computer program, when executed by a processor, implements the data transmission method based on inter-process communication as described in the first aspect above.

[0017] In a sixth aspect, this application provides a computer program product, including a computer program that, when executed by a processor, implements the data transmission method based on inter-process communication as described in the first aspect above.

[0018] Additional aspects and advantages of this application will be set forth in part in the description which follows, and in part will be obvious from the description, or may be learned by practice of this application. Attached Figure Description

[0019] The above and / or additional aspects and advantages of this application will become apparent and readily understood from the description of the embodiments taken in conjunction with the following drawings, in which: Figure 1 This is a flowchart illustrating a data transmission method based on inter-process communication provided in some embodiments of this application; Figure 2 This is a timing diagram of a data transmission method based on inter-process communication provided in some embodiments of this application; Figure 3 This is a schematic diagram of the structure of a data transmission device based on inter-process communication provided in some embodiments of this application; Figure 4 These are schematic diagrams of the structure of electronic devices provided in some embodiments of this application. Detailed Implementation

[0020] The technical solutions of the embodiments of this application will be clearly described below with reference to the accompanying drawings. Obviously, the described embodiments are only some, not all, of the embodiments of this application. All other embodiments obtained by those skilled in the art based on the embodiments of this application are within the scope of protection of this application.

[0021] The terms "first," "second," etc., used in the specification and claims of this application are used to distinguish similar objects and not to describe a specific order or sequence. It should be understood that such use of data can be interchanged where appropriate so that embodiments of this application can be implemented in orders other than those illustrated or described herein, and the objects distinguished by "first," "second," etc., are generally of the same class and the number of objects is not limited; for example, a first object can be one or more. Furthermore, in the specification and claims, "and / or" indicates at least one of the connected objects, and the character " / " generally indicates that the preceding and following objects are in an "or" relationship.

[0022] The data transmission method, electronic device, and chip based on inter-process communication provided in this application will be described in detail below with reference to the accompanying drawings and through specific embodiments and application scenarios.

[0023] The data transmission method based on inter-process communication provided in this application is applied to the first processing core in a multi-core processing system. That is, the execution subject of the data transmission method based on inter-process communication can be the first processing core or a functional module or functional entity in the first processing core that can implement the data transmission method based on inter-process communication. The first processing core mentioned in this application includes, but is not limited to, a central processing unit (CPU) core, a graphics processing unit (GPU) core, and a processing core in a micro control unit (MCU). The data transmission method based on inter-process communication provided in this application will be described below using the first processing core as the execution subject as an example.

[0024] Figure 1 This is a flowchart illustrating a data transmission method based on inter-process communication provided in some embodiments of this application. For example... Figure 1 As shown, the data transmission method based on inter-process communication is applied to the first processing core in a multi-core processing system. The first processing core and the second processing core communicate through an inter-process communication channel. The method includes steps 110, 120 and 130.

[0025] A multi-core processing system refers to a hardware architecture with multiple processing cores, such as common multi-core CPUs, multi-core GPUs, embedded multi-core chips (such as multi-core processors in automotive electronic control units (ECUs)), and system-on-chips (SoCs) in mobile devices. For example, in vehicle-related scenarios, a multi-core processing system could be a vehicle domain controller unit (DCU) based on an Advanced Reduced Instruction Set Machine (ARM) architecture, where the first processing core is a Cortex-A core, and the second processing core could be an MCU, corresponding to a Cortex-R core or a Cortex-M core in the ARM architecture.

[0026] Step 110: Receive the target data packet sent by the second processing core through the inter-process communication channel; wherein the target data packet is encapsulated by the second processing core according to a preset protocol format, including service data and protocol header information, and the protocol header information includes at least a target service identifier for identifying the service type to which the service data belongs.

[0027] Inter-process communication (IPC) refers to the data transmission or interaction between different processes in a multi-core processing system. Common IPC channels include pipes, message queues, and shared memory.

[0028] In this embodiment, the first processing core can receive target data packets sent by the second processing core by listening to the IPC channel. The target data packet is encapsulated by the second processing core according to a preset protocol format and sent to the first processing core. It includes at least service data and protocol header information. The protocol header information refers to a specific data structure located in the header of the data packet. For example, the protocol header information may include information such as the service type identifier, verification information, data packet length, and timestamp of the target data packet.

[0029] The service type identifier is used to identify the service type of the service data. For example, the service type can be set according to the actual application scenario. In vehicle-related scenarios, it could be obstacle detection, path planning, or system status. After the data packet is transmitted from the second processing core to the first processing core through the IPC channel, the first processing core parses the protocol header information of the data packet so that the data packet (service data) can be routed and processed based on the parsing results of the protocol header information, so that the service data is transmitted to the corresponding message queue.

[0030] In some embodiments, the method further includes: initializing an inter-process communication channel between the first processing core and the second processing core, and establishing a bidirectional communication link between the first processing core and the second processing core.

[0031] Step 120: Parse the protocol header information to extract the target service identifier, and route the service data in the target data packet to the target message queue mapped by the target service identifier.

[0032] In this embodiment, after receiving the target data packet, the first processing core parses the protocol header information, for example, by using a preset parsing program. After extracting the target service identifier, the service data in the target data packet is routed to the target message queue mapped by the target service identifier. For example, in a multi-core processing system, a mapping relationship between service identifiers and message queues is usually pre-stored. The first processing core routes the service data to the corresponding message queue by looking up the message queue corresponding to the target service identifier. Since multiple service types of data may exist simultaneously in a multi-core processing system, the service type to which the data belongs is determined by parsing the protocol header information to extract the target service identifier, and then the data is routed to the corresponding message queue, ensuring that service data of each service type can be transmitted correctly.

[0033] Step 130: Configure the business read interface so that the upper layer application can subscribe to the target message queue and read the business data therein by calling the business read interface, thereby decoupling the business data from the inter-process communication channel.

[0034] Configuring the business read interface can specifically include defining the specification and functions of the business read interface, and associating each business read interface with its corresponding message queue. For example, the business read interface can be implemented through a dynamic link library or an interface class, allowing it to be called by different upper-layer applications. When an upper-layer application needs to read business data, it can call the business read interface to retrieve the data from the message queue. By configuring the business read interface, upper-layer applications do not need to concern themselves with the underlying inter-process communication details; they only need to call the business read interface to obtain data. Furthermore, when the IPC channel changes, as long as the business read interface remains unchanged, the upper-layer application does not need to be modified. This effectively decouples business data from the communication channel, enhancing the overall flexibility and scalability of the multi-core processing system.

[0035] Understandably, compared to the point-to-point communication method in related technologies (where each IPC channel transmits only one type of data), this application, by embedding a service identifier in the data packet as the basis for service data routing, decouples the IPC channel used by the data packet from its service processing path. This achieves multiplexing of the IPC channel. Even when the second processing core switches IPC channels to send data, the first processing core can still identify the mapped message queue based on the unchanged and unique service identifier, thereby correctly routing the service data without modifying any channel binding configuration or message queue mapping relationship, thus improving the system's scalability and robustness.

[0036] The data transmission method based on inter-process communication provided in this application embodiment involves a first processing core receiving a target data packet sent by a second processing core through an inter-process communication channel. The same inter-process communication channel can transmit data of different service types, making data transmission not limited to a fixed channel and processing core. This effectively decouples the data packet from its service processing path and improves the flexibility of data transmission. Furthermore, by embedding a service identifier corresponding to the service type in the protocol header, the first and second processing cores can identify the service type based on the protocol format, eliminating the need to bind service data to a fixed service channel. Additionally, after the first processing core extracts the target service identifier... Furthermore, it flexibly routes business data to corresponding message queues based on this, enabling dynamic distribution of business data to different message queues based on pre-configured mapping relationships. This further decouples the communication channel from specific business processes, reducing the complexity of channel adaptation during business expansion. Subsequently, the first processing core utilizes a subscribed business read interface to decouple business data from inter-process communication channels, allowing upper-layer applications to flexibly obtain business data without needing to concern themselves with the details of underlying process communication. This not only avoids direct manipulation of the underlying IPC channel but also ensures that even if the inter-process communication channel changes while the interface remains unchanged, the upper-layer application does not need to modify it, thus improving the flexibility and scalability of data transmission between different processing cores in a multi-core processing system.

[0037] In some embodiments of this application, routing the service data in the target data packet to the target message queue mapped by the service identifier includes: Based on a pre-established mapping table and the mapping relationship between the target service identifier and the message queue, the target message queue corresponding to the target service identifier is searched from multiple message queues. The mapping table maintains a mapping relationship between service identifiers corresponding to one or more service types and each message queue, with each service identifier corresponding to a message queue. Write the business data in the target data packet to the message queue of the target.

[0038] A pre-built mapping table is a data structure pre-constructed in a multi-core processing system. It can be a database table or a configuration file, and is used to store the mapping relationship between business identifier data and message queues. The mapping relationship between business identifiers and message queues defines the message queues corresponding to different business identifiers, enabling different types of business data to be accurately routed to the appropriate message queues for subsequent processing.

[0039] In this embodiment of the application, the first processing core searches for the target message queue that matches the target service identifier according to a predefined mapping table. Specifically, it can search for the corresponding message queue by using the target service identifier as the key in the mapping table. For example, if the mapping table uses a hash table of service identifiers as the key, the target service identifier can be used to calculate the key value through a hash function, and then the corresponding message queue can be quickly located in the hash table according to the key value.

[0040] After determining the target message queue, the first processing core writes the business data to that message queue. This process can be achieved by calling the write method or interface provided by the message queue to write the business data to the target message queue, so that the business data can be retrieved normally from the message queue and used for subsequent business logic processing. A pre-established mapping table can quickly determine the message queue to which business data should be written. This avoids the inefficient operation of searching through multiple message queues one by one, improving the efficiency and accuracy of data routing. Furthermore, subsequent upper-layer applications can directly retrieve the corresponding business data from the message queue through the business read interface without needing to concern themselves with the underlying inter-process communication details, thus effectively decoupling business data from the communication channel.

[0041] Figure 2 This is a timing diagram of a data transmission method based on inter-process communication provided in some embodiments of this application. For example... Figure 2 As shown, in some embodiments, the data transmission method based on inter-process communication includes: Data reception: The CommIpcTransfer (channel adapter) of the first processing core asynchronously receives data packets transmitted through all IPC channels. That is, the CommIpcTransfer class in the first processing core acts as a channel adapter, encapsulates the underlying IPC communication interface, and serves as a unified abstraction layer, capable of receiving data packets from different IPC channels. Multiplexing parsing: The MspIpcMultiplexer of the first processing core waits for data packets (WaitToGetMsg) from the channel adapter, and after the CommIpcTransfer returns the data packet, it parses the header of the data packet to extract the serviceInsId (service identifier) ​​from the header information and uses it as the basis for subsequent routing. Routing: The MspIpcMultiplexer of the first processing core determines the target message queue (GetMsgQueue) mapped by the service identifier from the pre-maintained <serviceInsId, message queue> mapping table (MspIpcMsgQueueMap), and routes or pushes the service data in the data packet to the corresponding target message queue (Limitedsize_queue, the target message queue is a message queue with a limited size); In the case where data packets are transmitted to the first processing core through the IPC channel, the above steps of data reception, multiplexing parsing and routing are executed in a Loop; Service consumption layer: The upper-layer application subscribes to the message queue mapped to the specified serviceInsId through CommMsgQueueReader (service reading interface). The CommMsgQueueReader interface supports popping (pop) or acquiring data from the message queue in a blocking or non-blocking manner to meet the requirements of different service scenarios.

[0042] The data transmission method based on inter-process communication provided by the embodiments of the present application supports concurrent reading by multiple consumers, and adopts a lock-free design internally, thereby ensuring thread safety, improving the performance and reliability of the multi-core system. In addition, the message queue corresponding to the service data can be quickly determined according to the serviceInsId through the mapping table, and in some embodiments, the time complexity is O(1).

[0043] In the data transmission method based on inter-process communication provided by the embodiments of the present application, the message queue to which the service data should be written can be quickly determined by using the pre-established mapping table. In complex scenarios where multiple service data are mixed and transmitted, such as autonomous driving, the efficiency of data transmission between different processing cores of the multi-core processing system is effectively improved. The service data in the target data packet is written into the target message queue, and the subsequent upper-layer application can obtain the corresponding service data through the message queue, which facilitates the implementation of dynamic routing and decoupling of service data, and improves the flexibility and scalability of data transmission between different processing cores of the multi-core processing system.

[0044] In some embodiments of the present application, there are a plurality of the inter-process communication channels; the receiving the target data packet sent by the second processing core through the inter-process communication channel includes: configuring an independent thread pool for each inter-process communication channel respectively; wherein any thread pool is used for asynchronously monitoring the corresponding inter-process communication channel to detect the target data packet sent by the second processing core; When the arrival of the target data packet is detected, the first processing core reads the target data packet from the corresponding inter-process communication channel and performs parsing processing through the task instance in the corresponding thread pool.

[0045] A thread pool is a multi-threaded processing mechanism used to manage and schedule thread resources. A certain number of threads are pre-created in the thread pool. When a task needs to be executed, an idle thread can be obtained from the thread pool to execute the task. After the task is completed, the thread returns to the thread pool to wait for the next task.

[0046] In this embodiment, the first processing core creates an independent thread pool for each inter-process communication channel based on the actual number of inter-process communication channels. This avoids thread competition between different IPC channels and achieves isolation and specialization of thread resources. The specific size of the thread pool can be configured by the first processing core based on the expected load of the IPC channel and the resources of the multi-core processing system.

[0047] Each thread in the thread pool is responsible for listening to its corresponding IPC channel, enabling timely detection and parsing of arriving data packets. This can be achieved by the first processing core through setting listening events or a polling mechanism on the channel. By asynchronously listening to the channel through the threads in the thread pool, non-blocking mode data packet reception can be achieved. This means that threads can remain idle when no data packets arrive through the IPC channel, without consuming the processing resources of the first processing core. When a data packet arrives through the IPC channel, it can respond and process quickly, improving the system's concurrency and real-time performance.

[0048] Upon detecting the arrival of the target data packet, the first processing core creates a task instance in the thread pool corresponding to the IPC channel. Specifically, this task instance may contain logic for reading and parsing data from the channel. The task instance is submitted to the corresponding thread pool, which can allocate threads according to the scheduling policy to execute the task instance and complete the data reading and parsing processing.

[0049] The data transmission method based on inter-process communication provided in this application embodiment achieves thread resource isolation by configuring an independent thread pool for each inter-process communication channel. The thread pool is used to asynchronously listen to the corresponding inter-process communication channel to detect the target data packet sent by the second processing core through the inter-process communication channel, thereby improving the concurrent processing capability of the multi-core processing system. The first processing core reads and parses data through task instances, which improves thread reusability and resource utilization, enabling the multi-core processing system to handle the inter-core data interaction needs of multiple tasks and multiple channels more efficiently, and further improving the system's flexibility and scalability.

[0050] In some embodiments of this application, the service reading interface is configured with reading modes including blocking mode and non-blocking mode; the method further includes: Receive the call request from the upper-layer application and determine the read mode corresponding to the call request; Read business data from the target message queue according to the read mode, and return the read business data to the upper-layer application.

[0051] The read mode refers to the mode adopted by the upper-layer application when reading business data. Specifically, it can be a blocking mode or a non-blocking mode. Different read modes will affect the behavior of the business read interface and the way business data is obtained.

[0052] Specifically, in blocking mode, when an upper-layer application calls the business read interface to read business data, if there is no business data in the message queue, the call will be blocked until business data arrives or the blocking time expires. In non-blocking mode, when an upper-layer application calls the business read interface to read data, it will return immediately regardless of whether there is business data in the message queue. If there is no business data in the message queue, it can return a specific identifier indicating an empty result.

[0053] When configuring business read interfaces, upper-layer applications can specify either blocking or non-blocking read modes through interface parameters or configuration files. For example, a parameter can be added to the interface method of the business read interface to specify the read mode, or a default read mode can be configured for each business read interface in its configuration file. If the upper-layer application requires data with high real-time requirements, blocking mode can be used; while using non-blocking mode helps avoid thread blocking and improve efficiency. By configuring the read mode, the flexibility and adaptability of the business read interface can be improved, enabling it to be better applied to various scenarios.

[0054] When an upper-layer application calls the business read interface, the first processing core needs to receive and parse the call request to obtain the read mode parameters. This can be achieved, for example, by checking the parameters of the interface method or obtaining configuration information from the upper-layer application context. Based on the determined read mode, the first processing core reads business data from the target message queue. Specifically, in blocking mode, it waits for business data to arrive until data is available or a timeout occurs. In non-blocking mode, it immediately attempts to read business data, regardless of whether data is available. The read data is then returned to the upper-layer application through the interface. For example, in blocking mode, the blocking read method provided by the message queue can be used to return business data to the upper-layer application; in non-blocking mode, a non-blocking read method or a polling mechanism can be used to return business data to the upper-layer application.

[0055] The data transmission method based on inter-process communication provided in this application embodiment has a business reading interface configured with reading modes including blocking and non-blocking modes. This allows upper-layer applications to flexibly obtain business data according to their needs, improving the flexibility and adaptability of the business reading interface. The method receives the call request from the upper-layer application, determines the reading mode, executes the reading operation according to the method specified by the upper-layer application, and returns to the upper-layer application to meet the upper-layer application's need to obtain business data. This effectively improves the flexibility and efficiency of data transmission in multi-core processing systems, enabling multi-core processing systems to be applied more efficiently to complex business scenarios such as autonomous driving.

[0056] In some embodiments of this application, the service reading interface supports multiple upper-layer applications simultaneously subscribing to the target message queue; the method further includes: When multiple upper-layer application call requests are received, and each call request points to the target message queue, an independent call path is assigned to each upper-layer application to isolate each call request. Based on each call path, business data is read from the target message queue, and the read business data is returned to the corresponding upper-layer application to perform concurrent reading of the target message queue.

[0057] In this embodiment of the application, when multiple upper-layer applications initiate call requests and each request points to the target message queue, the first processing core can create an independent thread for each upper-layer application or use an asynchronous task to process its call requests, so as to achieve isolation of each call request. For example, a thread pool can be used to allocate a thread for each application, or an asynchronous programming model can be used to create an asynchronous task so that the requests of each application are processed on an independent path.

[0058] The call path refers to the independent logical or resource path allocated by the multi-core processing system to handle the request when an upper-layer application calls a business read interface. Assigning an independent call path to each upper-layer application can avoid interference between request processing of different upper-layer applications, thereby enabling concurrent reading of the target message queue and ensuring that the call requests of each upper-layer application can be processed independently and efficiently.

[0059] In each independent call path, data is read from the target message queue. The specific read operation can be determined based on the call request from the upper-layer application, using either blocking or non-blocking mode. The read data is then returned to the corresponding upper-layer application through the appropriate call path. For example, a blocking read method of the message queue can be used to automatically wake up the corresponding thread to read the data when it arrives; or in non-blocking mode, the message queue can be periodically polled and data read. Concurrent reading improves the system's resource utilization and data transmission efficiency.

[0060] The data transmission method based on inter-process communication provided in this application provides thread safety for the business reading interface by allocating independent call paths to multiple upper-layer applications and reading business data from the target message queue based on each call path and returning it to the corresponding upper-layer application. This improves the concurrent processing capability and response speed of the multi-core processing system, supports multiple applications to read data from the same message queue at the same time, meets the data needs of multiple tasks and applications, improves resource utilization and data transmission efficiency, and enables the multi-core processing system to be applied more efficiently to complex business scenarios such as autonomous driving.

[0061] In some embodiments of this application, the protocol header information further includes verification information for indicating data integrity, length information for identifying the data packet length, and timestamp information for identifying the data time; after receiving the target data packet sent by the second processing core through the inter-process communication channel, the method further includes: The protocol header information is parsed to extract verification information, and the integrity of the target data packet is verified based on the verification information. The service data in the target data packet is preprocessed based on the length information and timestamp information.

[0062] The checksum information in the protocol header is used to verify the integrity and accuracy of data packets. Common checksums include Cyclic Redundancy Check (CRC) codes and checksums. The first processing core can determine whether an error occurred in the data packet during transmission by comparing the checksum information in the data packet header with its own calculated checksum.

[0063] For example, after receiving the target data packet, the first processing core can parse the protocol header information using a preset parsing program, extract the verification information, and perform integrity verification on the target data packet using the corresponding verification algorithm based on the type of verification information. For instance, if the verification information in the protocol header uses a CRC checksum, the first processing core can calculate the CRC checksum for the data packet according to the CRC checksum algorithm and then compare it with the CRC checksum in the protocol header. If they match, the data packet is considered complete and tamper-proof. The purpose of this step is to verify the integrity and accuracy of the data packet, which is particularly helpful in scenarios with extremely high data reliability requirements, such as autonomous driving, to avoid system failures or incorrect decisions caused by data errors.

[0064] Based on the length information parsed from the protocol header, the business data portion can be correctly extracted from the target data packet. The timestamp information can be used for operations such as sorting, deduplication, or determining data freshness. Preprocessing the business data in the target data packet based on the length and timestamp information is exemplified in autonomous driving scenarios. For instance, the data in each target data packet sent by the second data core can be sorted according to the timestamp information, allowing the business data in each target data packet to be processed in chronological order, or discarding outdated data to ensure data freshness. The length information allows for accurate extraction of the business data portion from the target data packet, avoiding data parsing errors and providing more accurate and reliable data support for upper-layer applications.

[0065] The data transmission method based on inter-process communication provided in this application can perform integrity verification on the received data packets by parsing the verification information in the protocol header information, so as to verify the integrity and accuracy of the data packets. Based on the length information and timestamp information in the protocol header information, the business data is preprocessed, which improves the data quality and availability of the business data routed to the corresponding target message queue, thereby improving the data transmission between different processing cores and the reliability and stability of multi-core processing systems, and can effectively reduce the risks caused by data problems.

[0066] In some embodiments of this application, the protocol header information further includes a sub-data packet number and a total number of packets; after receiving the target data packet sent by the second processing core through the inter-process communication channel, the method further includes: When multiple sub-data packets belonging to the same service identifier but with different sub-data packet numbers are received, the multiple sub-data packets are sequentially reassembled based on the sub-data packet numbers and the total number of packets to restore the target data packet.

[0067] The following is an example of an encoded protocol header: typedef struct { uint8_tchecksum; uint8_trollingcounter; uint16_t length; uint16_t serviceInsId; uint16_t totalnumber; uint16_t packstatus; uint16_t packid; uint32_t timestamp_H; uint32_t timestamp_L; Header; Among them, Header is the protocol header information; checksum is the verification information used to indicate data integrity; rollingcounter is incremented and used to indicate the number of data packets transmitted; length is the length information used to identify the length of the data packet; serviceInsId is the target service identifier used to identify the service type to which the service data belongs; totalnumber is the total number of packets; packstatus is the data packet status; packid is the sub-data packet number; timestamp_H and timestamp_L are the timestamp information used to identify the time of the data, with timestamp_H representing the high 32 bits of the timestamp and timestamp_L representing the low 32 bits of the timestamp.

[0068] In this embodiment of the application, during the process of the second processing core transmitting data to the first processing core through the IPC channel, a large data packet may be split into multiple sub-data packets belonging to the same service identifier for transmission. In this case, each sub-data packet will be assigned a unique number to identify its order in the complete data packet, that is, the sub-data packet number. The total number of packets refers to the total number of sub-data packets into which the original data packet is split. The first processing core obtains the total number of packets by parsing the protocol header information of the data packet, and then knows how many sub-data packets need to be received to completely restore the original data packet.

[0069] After parsing the sub-data packet numbers from the protocol header information of each sub-data packet, the first processing core can combine the sub-data packets into a complete original data packet according to the order of their numbers. Specifically, this can be achieved by arranging the sub-data packets in numerical order and then reading their data content sequentially. By comparing the sub-data packet numbers with the total number of packets, the first processing core can determine whether all sub-data packets have been received, and thus whether a complete original target data packet has been combined.

[0070] The data transmission method based on inter-process communication provided in this application reassembles sub-data packets belonging to the same service identifier in sequence based on the sub-data packet number and total number of packets in the data packet protocol header information, thereby restoring the sub-data packets to the original data packets. This can effectively avoid system failures or incorrect decisions caused by incomplete or out-of-order business data, realize the transmission of large data packets between different processing cores, and improve the applicability of inter-process communication in multi-core processing systems to complex business scenarios.

[0071] In some embodiments of this application, the first processing core and the second processing core are configured within a domain controller in an autonomous driving control system, and the target data packet includes business data related to autonomous driving services collected or generated by the second processing core; the business data related to autonomous driving services includes at least one of obstacle perception data, path planning data, and vehicle system status data.

[0072] Understandably, an autonomous driving control system refers to a system used to achieve autonomous driving functions. It typically includes modules for vehicle perception, decision-making, and control. This system needs to process a large amount of real-time data, such as obstacle perception data, path planning data, and system status data.

[0073] A domain controller (DCU) is an electronic control unit in a vehicle used for centralized control and management of a specific functional domain. A domain controller can integrate multiple functional modules to achieve complex functional coordination and data processing.

[0074] In this embodiment, the domain controller is designed to centrally manage functions related to autonomous driving. A first processing core and a second processing core are configured within the domain controller and connected via inter-process communication channels (such as pipes, message queues, and shared memory) to enable data transmission between the different processing cores. The second processing core can connect to various autonomous driving sensors (such as cameras, LiDAR, millimeter-wave radar, etc.) and actuators to collect obstacle perception data, vehicle status data, and other business data related to autonomous driving operations.

[0075] The second processing core encapsulates the collected or generated business data into target data packets according to a preset protocol format and sends them to the first processing core through an inter-process communication channel. Upon receiving the data packet, the first processing core parses it and routes the business data in the data packet to the corresponding message queue based on the business identifier parsed from the packet's protocol header. This allows upper-layer applications to subscribe to the message queue and read the business data by calling the business read interface, thus decoupling the business data from the inter-process communication channel.

[0076] The data transmission method based on inter-process communication provided in this application applies a multi-core data transmission method to autonomous driving scenarios. A first processing core and a second processing core are configured in the domain controller of the autonomous driving control system and can be connected via inter-process communication channels (such as pipes, message queues, and shared memory) to achieve data transmission between different processing cores. The business data can be obstacle perception data, path planning data, vehicle system status data, and other autonomous driving-related business data. This enables the transmission of autonomous driving business data between different processing cores within the domain controller. The second processing core can collect and generate real-time autonomous driving business data and send it to the first processing core via the inter-process communication channel. The same inter-process communication channel can transmit different types of business data, making data transmission not limited to fixed channels and processing cores. This effectively decouples the data packet from its business processing path via the inter-process communication channel, improving the applicability of the domain controller in complex autonomous driving scenarios, enhancing the flexibility and scalability of data transmission between different processing cores of the domain controller, and strengthening the real-time performance and stability of the vehicle's autonomous driving control system in multi-task parallel processing scenarios.

[0077] The data transmission method based on inter-process communication provided in this application can be executed by an inter-process communication data transmission device. This application uses an inter-process communication data transmission device executing the data transmission method as an example to illustrate the data transmission device based on inter-process communication provided in this application.

[0078] Figure 3 These are schematic diagrams illustrating the structure of a data transmission device based on inter-process communication provided in some embodiments of this application. Embodiments of this application also provide a data transmission device based on inter-process communication. For example... Figure 3 As shown, the data transmission device 300 based on inter-process communication includes: a receiving unit 301, a parsing unit 302, and a configuration unit 303.

[0079] The receiving unit 301 is used to receive a target data packet sent by the second processing core through an inter-process communication channel; wherein the target data packet is encapsulated by the second processing core according to a preset protocol format, including service data and protocol header information, and the protocol header information includes at least a target service identifier for identifying the service type to which the service data belongs.

[0080] The parsing unit 302 is used to parse the protocol header information to extract the target service identifier, and route the service data in the target data packet to the target message queue mapped by the target service identifier.

[0081] Configuration unit 303 is used to configure the business read interface so that the upper layer application can subscribe to the target message queue and read the business data therein by calling the business read interface, thereby decoupling the business data from the inter-process communication channel.

[0082] In some embodiments, routing the service data in the target data packet to the target message queue mapped by the service identifier includes: Based on a pre-established mapping table and the mapping relationship between the target service identifier and the message queue, the target message queue corresponding to the target service identifier is searched from multiple message queues. The mapping table maintains a mapping relationship between service identifiers corresponding to one or more service types and each message queue, with each service identifier corresponding to a message queue. Write the business data in the target data packet to the message queue of the target.

[0083] In some embodiments, there are multiple inter-process communication channels; receiving the target data packet sent by the second processing core through the inter-process communication channel includes: Each inter-process communication channel is configured with an independent thread pool; each thread pool is used to asynchronously listen to the corresponding inter-process communication channel to detect the target data packet sent by the second processing core. When the target data packet is detected to have arrived, the first processing core reads the target data packet from the corresponding inter-process communication channel and performs parsing processing through a task instance in the corresponding thread pool.

[0084] In some embodiments, the service read interface is configured with read modes including blocking mode and non-blocking mode; the method further includes: Receive the call request from the upper-layer application and determine the read mode corresponding to the call request; Read business data from the target message queue according to the read mode, and return the read business data to the upper-layer application.

[0085] In some embodiments, the service read interface supports multiple upper-layer applications simultaneously subscribing to the target message queue; the method further includes: When multiple upper-layer application call requests are received, and each call request points to the target message queue, an independent call path is assigned to each upper-layer application to isolate each call request. Based on each call path, business data is read from the target message queue, and the read business data is returned to the corresponding upper-layer application to perform concurrent reading of the target message queue.

[0086] In some embodiments, the protocol header information further includes verification information for indicating data integrity, length information for identifying the data packet length, and timestamp information for identifying the data time; after receiving the target data packet sent by the second processing core through the inter-process communication channel, the method further includes: The protocol header information is parsed to extract verification information, and the integrity of the target data packet is verified based on the verification information. The service data in the target data packet is preprocessed based on the length information and timestamp information.

[0087] In some embodiments, the protocol header information further includes sub-data packet numbers and total packet counts; after receiving the target data packet sent by the second processing core through the inter-process communication channel, the method further includes: When multiple sub-data packets belonging to the same service identifier but with different sub-data packet numbers are received, the multiple sub-data packets are sequentially reassembled based on the sub-data packet numbers and the total number of packets to restore the target data packet.

[0088] In some embodiments, the first and second processing cores are configured within a domain controller in the autonomous driving control system, and the target data packet includes business data related to autonomous driving services collected or generated by the second processing core; the business data related to autonomous driving services includes at least one of obstacle perception data, path planning data, and vehicle system status data.

[0089] The data transmission device based on inter-process communication in this application embodiment can be an electronic device or a component within an electronic device, such as an integrated circuit or a chip. The electronic device can be a terminal or other devices besides a terminal. For example, the electronic device can be a mobile phone, tablet computer, laptop computer, PDA, in-vehicle electronic device, mobile internet device (MID), augmented reality (AR) / virtual reality (VR) device, robot, wearable device, ultra-mobile personal computer (UMPC), netbook, or personal digital assistant (PDA), etc. It can also be a server, network attached storage (NAS), personal computer (PC), television (TV), ATM, or self-service machine, etc. This application embodiment does not specifically limit the specific implementation.

[0090] The data transmission device based on inter-process communication in this application embodiment can be a device with an operating system. This operating system can be a Microsoft (Windows) operating system, an Android operating system, an iOS operating system, or other possible operating systems; this application embodiment does not specifically limit it.

[0091] The data transmission device based on inter-process communication provided in this application can implement all the processes implemented in the above-described data transmission method embodiments based on inter-process communication, and can achieve the same technical effect. To avoid repetition, it will not be described again here.

[0092] In some embodiments, such as Figure 4 As shown, this application embodiment also provides an electronic device 400, including a processor 401, a memory 402, and a computer program stored in the memory 402 and executable on the processor 401. When the program is executed by the processor 401, it implements the various processes of the above-described data transmission method embodiment based on inter-process communication and achieves the same technical effect. To avoid repetition, it will not be described again here.

[0093] It should be noted that the electronic devices in the embodiments of this application include the mobile electronic devices and non-mobile electronic devices described above.

[0094] This application also provides a non-transitory computer-readable storage medium storing a computer program. When the computer program is executed by a processor, it implements the various processes of the above-described data transmission method embodiment based on inter-process communication and achieves the same technical effect. To avoid repetition, it will not be described again here.

[0095] The processor is the processor in the electronic device described in the above embodiments. The readable storage medium includes computer-readable storage media, such as computer read-only memory (ROM), random access memory (RAM), magnetic disk, or optical disk.

[0096] This application also provides a computer program product, including a computer program that, when executed by a processor, implements the above-described data transmission method based on inter-process communication.

[0097] The processor is the processor in the electronic device described in the above embodiments. The readable storage medium includes computer-readable storage media, such as computer read-only memory (ROM), random access memory (RAM), magnetic disk, or optical disk.

[0098] This application embodiment also provides a chip, which includes a processor and a communication interface. The communication interface is coupled to the processor. The processor is used to run programs or instructions to implement the various processes of the above-described data transmission method embodiment based on inter-process communication, and can achieve the same technical effect. To avoid repetition, it will not be described again here.

[0099] It should be understood that the chip mentioned in the embodiments of this application may also be referred to as a system-on-a-chip, system chip, chip system, or system-on-a-chip, etc.

[0100] It should be noted that, in this document, the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process, method, article, or apparatus. Without further limitations, an element defined by the phrase "comprising one..." does not exclude the presence of other identical elements in the process, method, article, or apparatus that includes that element. Furthermore, it should be noted that the scope of the methods and apparatuses in the embodiments of this application is not limited to performing functions in the order shown or discussed, but may also include performing functions substantially simultaneously or in the reverse order, depending on the functions involved. For example, the described methods may be performed in a different order than described, and various steps may be added, omitted, or combined. Additionally, features described with reference to certain examples may be combined in other examples.

[0101] In this application, the above-described embodiments, examples, technical solutions, and their technical features can be interleaved, combined, or superimposed, provided that no logical conflict or functional contradiction arises. Those skilled in the art will understand that the technical solutions obtained by reasonably combining the technical means in the different embodiments described above do not depart from the core concept and protection scope of this invention, and all fall within the scope of protection intended by this invention.

[0102] Through the above description of the embodiments, those skilled in the art can clearly understand that the methods of the above embodiments can be implemented by means of software plus necessary general-purpose hardware platforms. Of course, they can also be implemented by hardware, but in many cases the former is a better implementation method. Based on this understanding, the technical solution of this application, in essence, or the part that contributes to the related technology, can be embodied in the form of a computer software product. This computer software product is stored in a storage medium (such as ROM / RAM, magnetic disk, optical disk) and includes several instructions to cause a terminal (which may be a mobile phone, computer, server, or network device, etc.) to execute the methods described in the various embodiments of this application.

[0103] The embodiments of this application have been described above with reference to the accompanying drawings. However, this application is not limited to the specific embodiments described above. The specific embodiments described above are merely illustrative and not restrictive. Those skilled in the art can make many other forms under the guidance of this application without departing from the spirit and scope of the claims, and all of these forms are within the protection scope of this application.

[0104] In the description of this specification, the references to terms such as "one embodiment," "some embodiments," "illustrative embodiment," "example," "specific example," or "some examples," etc., indicate that a specific feature, structure, material, or characteristic described in connection with that embodiment or example is included in at least one embodiment or example of this application. In this specification, the illustrative expressions of the above terms do not necessarily refer to the same embodiment or example. Furthermore, the specific features, structures, materials, or characteristics described may be combined in any suitable manner in one or more embodiments or examples.

[0105] Although embodiments of this application have been shown and described, those skilled in the art will understand that various changes, modifications, substitutions and alterations can be made to these embodiments without departing from the principles and spirit of this application, the scope of which is defined by the claims and their equivalents.

Claims

1. A data transmission method based on inter-process communication, characterized in that, A first processing core applied in a multi-core processing system, wherein the first processing core and a second processing core communicate via an inter-process communication channel; the method includes: Receive target data packets sent by the second processing core through an inter-process communication channel; wherein the target data packets are encapsulated by the second processing core according to a preset protocol format, including service data and protocol header information, and the protocol header information includes at least a target service identifier for identifying the service type to which the service data belongs; Parse the protocol header information to extract the target service identifier, and route the service data in the target data packet to the target message queue mapped by the target service identifier; Configure a business read interface so that upper-layer applications can subscribe to the target message queue and read the business data therein by calling the business read interface, thereby decoupling the business data from the inter-process communication channel.

2. The data transmission method based on inter-process communication according to claim 1, characterized in that, The step of routing the service data in the target data packet to the target message queue mapped by the service identifier includes: Based on a pre-established mapping table and the mapping relationship between the target service identifier and the message queue, the target message queue corresponding to the target service identifier is searched from multiple message queues. The mapping table maintains a mapping relationship between service identifiers corresponding to one or more service types and each message queue, with each service identifier corresponding to a message queue. Write the business data in the target data packet to the message queue of the target.

3. The data transmission method based on inter-process communication according to claim 1, characterized in that, There are multiple inter-process communication channels; receiving the target data packet sent by the second processing core through the inter-process communication channel includes: Each inter-process communication channel is configured with an independent thread pool; each thread pool is used to asynchronously listen to the corresponding inter-process communication channel to detect the target data packet sent by the second processing core. When the target data packet is detected to have arrived, the first processing core reads the target data packet from the corresponding inter-process communication channel and performs parsing processing through a task instance in the corresponding thread pool.

4. The data transmission method based on inter-process communication according to claim 1, characterized in that, The service read interface is configured with read modes including blocking mode and non-blocking mode; the method further includes: Receive the call request from the upper-layer application and determine the read mode corresponding to the call request; Read business data from the target message queue according to the read mode, and return the read business data to the upper-layer application.

5. The data transmission method based on inter-process communication according to claim 1 or 4, characterized in that, The service read interface supports multiple upper-layer applications simultaneously subscribing to the target message queue; the method further includes: When multiple upper-layer application call requests are received, and each call request points to the target message queue, an independent call path is assigned to each upper-layer application to isolate each call request. Based on each call path, business data is read from the target message queue, and the read business data is returned to the corresponding upper-layer application to perform concurrent reading of the target message queue; Alternatively, the protocol header information may further include verification information indicating data integrity, length information indicating the length of the data packet, and timestamp information indicating the data time; after receiving the target data packet sent by the second processing core through the inter-process communication channel, the method further includes: The protocol header information is parsed to extract verification information, and the integrity of the target data packet is verified based on the verification information. The service data in the target data packet is preprocessed based on the length information and timestamp information.

6. The data transmission method based on inter-process communication according to claim 1, characterized in that, The protocol header information also includes sub-data packet numbers and total packet count; after receiving the target data packet sent by the second processing core through the inter-process communication channel, the method further includes: When multiple sub-data packets belonging to the same service identifier but with different sub-data packet numbers are received, the multiple sub-data packets are sequentially reassembled based on the sub-data packet numbers and the total number of packets to restore the target data packet; Alternatively, the first and second processing cores are configured within a domain controller in the autonomous driving control system, and the target data packet includes business data related to autonomous driving services collected or generated by the second processing core; the business data related to autonomous driving services includes at least one of obstacle perception data, path planning data, and vehicle system status data.

7. A data transmission device based on inter-process communication, characterized in that, include: The receiving unit is configured to receive a target data packet sent by the second processing core through an inter-process communication channel; wherein the target data packet is encapsulated by the second processing core according to a preset protocol format, including service data and protocol header information, and the protocol header information includes at least a target service identifier for identifying the service type to which the service data belongs; The parsing unit is used to parse the protocol header information to extract the target service identifier, and route the service data in the target data packet to the target message queue mapped by the target service identifier; The configuration unit is used to configure the business read interface so that the upper layer application can subscribe to the target message queue and read the business data therein by calling the business read interface, thereby decoupling the business data from the inter-process communication channel.

8. An electronic device, characterized in that, include: First processing core and second processing core; Memory; processor; The processor is communicatively connected to the memory and executes a computer program stored in the memory; when the processor executes the computer program, it implements the data transmission method based on inter-process communication as described in any one of claims 1-6.

9. A chip, characterized in that, The chip includes a first processing core, a second processing core, a processor, and a communication interface. The communication interface is coupled to the processor, and the processor is used to run programs or instructions to implement the data transmission method based on inter-process communication as described in any one of claims 1-6.

10. A non-transitory computer-readable storage medium / computer program product, characterized in that, The non-transitory computer-readable storage medium stores a computer program, which, when executed by a processor, implements the data transmission method based on inter-process communication as described in any one of claims 1-6. The computer program product includes a computer program that, when executed by a processor, implements the data transmission method based on inter-process communication as described in any one of claims 1-6.

Images