WO2024088194A1

WO2024088194A1 - Communication method and apparatus, and intelligent driving device

Info

Publication number: WO2024088194A1
Application number: PCT/CN2023/125866
Authority: WO
Inventors: 周广宇; 曹建龙
Original assignee: 华为技术有限公司
Priority date: 2022-10-28
Filing date: 2023-10-23
Publication date: 2024-05-02
Also published as: CN117955654A

Abstract

Embodiments of the present application provide a communication method and apparatus, and an intelligent driving device. The method comprises: allocating, in a kernel, a first memory to a first process, the first memory comprising a memory used for carrying identity information of the first process; filling the first memory with the identity information of the first process; and mapping the first memory to obtain a shared memory, such that a second process acquires the identity information of the first process by means of the shared memory. The embodiments of the present application can be applied to intelligent vehicles or electric vehicles, thereby facilitating the reduction of the delay in inter-process communication and also facilitating the improvement of the communication efficiency and certainty.

Description

A communication method, device and intelligent driving equipment

Technical Field

The present application relates to the field of communications, and more specifically, to a communication method, apparatus and intelligent driving equipment.

Background technique

Compared with traditional fuel vehicles, intelligent connected vehicles need to face attackers from the entire Internet. This brings huge challenges to vehicle practitioners, especially vehicle software practitioners. In the field of autonomous driving, vehicle software practitioners must deal with new security issues brought about by intelligence. Only by solving digital security issues can the autonomous driving platform ensure the safety of users' driving.

The commonly mentioned secure communication is more inclined to secure network communication or communication between electronic control units (ECUs). However, in actual vehicle operation, due to the service-oriented deployment and the development trend of the microkernel of the operating system, how to communicate efficiently and securely between processes has become an urgent problem to be solved.

Summary of the invention

The embodiments of the present application provide a communication method and device, which help to improve the efficiency and security of communication between processes.

The intelligent driving equipment in this application may include road vehicles, water vehicles, air vehicles, industrial equipment, agricultural equipment, or entertainment equipment, etc. For example, the intelligent driving equipment may be a vehicle, which is a vehicle in a broad sense, and may be a vehicle (such as a commercial vehicle, a passenger car, a motorcycle, a flying car, a train, etc.), an industrial vehicle (such as a forklift, a trailer, a tractor, etc.), an engineering vehicle (such as an excavator, a bulldozer, a crane, etc.), agricultural equipment (such as a mower, a harvester, etc.), amusement equipment, a toy vehicle, etc. The embodiment of this application does not specifically limit the type of intelligent driving equipment. For another example, the intelligent driving equipment may be a vehicle such as an airplane or a ship.

In a first aspect, a communication method is provided, the method comprising: allocating a first memory for a first process in a kernel, the first memory comprising a memory for carrying identity information of the first process; filling the identity information of the first process into the first memory; mapping the first memory to obtain a shared memory, so that a second process obtains the identity information of the first process through the shared memory.

In the embodiment of the present application, the shared memory is mapped by the kernel to the user-mode process for use, and the receiving process (second process) can obtain the identity information of the initiating process through the shared memory. In this way, the receiving process does not need to fall into the kernel again to obtain the identity information of the sending process (first process), which helps to reduce the delay of inter-process communication and also helps to improve the efficiency and certainty of communication.

In some possible implementations, mapping the first memory to obtain a shared memory includes: mapping the first memory from the kernel to a user state to obtain the shared memory.

In some possible implementations, the first process may be a client process or an initiator process.

In some possible implementations, the second process may be a server process or a receiver process.

In combination with the first aspect, in some implementations of the first aspect, the identity information of the first process includes service-based identity information of the first process.

Since the vehicle-mounted scenario involves various types of operating systems and a multi-component vehicle identity system, abstract identity information (e.g., user identification (UID), group identification (GID) or process identification (PID)) cannot fully reflect the identity information of the process in the vehicle-mounted scenario. In the embodiment of the present application, the second process can obtain the service-based identity information of the first process, and the service-based identity information of the first process can better reflect the identity information of the process in the vehicle-mounted scenario.

In some possible implementations, the service-based identity information of the first process includes, but is not limited to, vehicle-wide unique identification information used to define the first process (such as an application). For example, the service-based identity information of the first process may include deployment information of the first process (for example, identification information of the ECU where the application is located).

In combination with the first aspect, in certain implementations of the first aspect, the kernel stores a mapping relationship between the abstract identity information of the first process and the service identity information of the first process, and the method also includes: obtaining the abstract identity information of the first process; and determining the service identity information of the first process based on the abstract identity information of the first process and the mapping relationship.

In the embodiment of the present application, the kernel stores the mapping relationship between the abstract identity information of the first process and the service identity information of the first process. When the first process is started, the kernel can obtain the abstract identity information of the first process, and then determine the service identity information of the first process based on the abstract identity information and the mapping relationship. Thus, the service identity information of the first process can be filled into the first memory. In the example, after memory mapping, the second process can obtain the service identity information of the first process from the shared memory. In this way, the second process does not need to obtain the service identity information of the first process through the execution management module EM, which helps to reduce the delay of inter-process communication.

In some possible implementations, obtaining the abstracted identity information of the first process includes: obtaining the abstracted identity information of the first process when the first process is started.

In combination with the first aspect, in some implementations of the first aspect, the method further includes: when the first process exits, clearing the mapping relationship.

In an embodiment of the present application, when the first process exits, the mapping relationship saved in the kernel can be cleared, which helps to avoid leakage of the identity information of the first process.

In combination with the first aspect, in some implementations of the first aspect, the method further includes: controlling visibility of the first process and the second process to the first memory according to attribute information of the virtual address page table.

In the embodiment of the present application, the visibility of the first process and the second process to the first memory can be controlled through the attribute information of the virtual address page table. In this way, the two ends of the communication can implement a strictly one-way zero-trust model, which helps to improve the security of the identity information transmission mechanism.

In combination with the first aspect, in certain implementations of the first aspect, the visibility of the first process and the second process to the first memory is controlled according to the attribute information of the virtual address page table, including: controlling the first process to be invisible to the first memory and controlling the second process to be readable but not writable to the first memory according to the attribute information of the virtual address page table.

In the embodiment of the present application, by controlling the first process to be invisible to the first memory and controlling the second process to be readable but not writable to the first memory, the identity information of the first process can be protected, thereby helping to improve the security of the identity information transmission mechanism.

In combination with the first aspect, in certain implementations of the first aspect, the first memory also includes a memory for carrying payload data of the first process, and the method also includes: filling the payload data in the shared memory so that the second process obtains the payload data through the shared memory.

In an embodiment of the present application, the memory used to carry identity information and the memory used to carry payload data can be allocated at one time, and the memory used to carry identity information can be filled in one time when allocated, which helps to reduce the impact of the identity information transmission mechanism on performance in the entire communication.

The memory used to carry the identity information of the first process and the memory used to carry the payload data of the first process are decoupled, so that the first memory can be fixed-length and the memory used to carry the payload data can achieve zero copy during the mapping process, which helps to further reduce the latency of inter-process communication.

In combination with the first aspect, in some implementations of the first aspect, the second process obtains the identity information of the first process through a pointer address offset.

In some possible implementations, the length of the memory in the first memory used to carry the identity information is a preset length.

In the embodiment of the present application, the length of the memory used to carry the identity information can be a preset length, so that the receiving end process can quickly obtain the identity information of the first process through the pointer address offset.

In a second aspect, a communication device is provided, which includes: a memory allocation unit, used to allocate a first memory for a first process in a kernel, the first memory including a memory for carrying identity information of the first process; a data filling unit, used to fill the identity information of the first process into the first memory; and a data mapping unit, used to map the first memory to obtain a shared memory, so that the second process obtains the identity information of the first process through the shared memory.

In combination with the second aspect, in some implementations of the second aspect, the identity information of the first process includes service-based identity information of the first process.

In combination with the second aspect, in certain implementations of the second aspect, the kernel stores a mapping relationship between the abstract identity information of the first process and the service identity information of the first process, and the device also includes: an acquisition unit for acquiring the abstract identity information of the first process; a determination unit for determining the service identity information of the first process based on the abstract identity information of the first process and the mapping relationship.

In combination with the second aspect, in some implementations of the second aspect, the device further includes: a data cleaning unit, configured to clean up the mapping relationship when the first process exits.

In combination with the second aspect, in some implementations of the second aspect, the device also includes: a control unit, used to control visibility of the first process and the second process to the first memory according to attribute information of the virtual address page table.

In combination with the second aspect, in some implementations of the second aspect, the control unit is used to: control the first process to be invisible to the first memory and control the second process to be readable but not writable to the first memory according to attribute information of the virtual address page table.

In conjunction with the second aspect, in some implementations of the second aspect, the first memory further includes a memory for carrying the payload data of the first process, and the data filling unit is further used to: fill the payload data in the shared memory so that the second process can Save and obtain the load data.

In combination with the second aspect, in some implementations of the second aspect, the second process obtains the identity information of the first process through a pointer address offset.

In a third aspect, a communication device is provided, which includes a processing unit and a storage unit, wherein the storage unit is used to store instructions, and the processing unit executes the instructions stored in the storage unit to enable the device to perform any possible method in the first aspect.

In a fourth aspect, an intelligent driving device is provided, which includes any possible device in the second aspect or the third aspect.

In some possible implementations, the intelligent driving device is a vehicle.

In a fifth aspect, a computer program product is provided, the computer program product comprising: a computer program code, when the computer program code is run on a computer, the computer executes any possible method in the above-mentioned first aspect.

It should be noted that the above-mentioned computer program code can be stored in whole or in part on the first storage medium, wherein the first storage medium can be packaged together with the processor or separately packaged with the processor, and the embodiments of the present application do not specifically limit this.

In a sixth aspect, a computer-readable medium is provided, wherein the computer-readable medium stores a program code, and when the computer program code is executed on a computer, the computer executes any possible method in the first aspect.

In a seventh aspect, an embodiment of the present application provides a chip system, which includes a processor for calling a computer program or computer instructions stored in a memory so that the processor executes any possible method in the above-mentioned first aspect.

In combination with the seventh aspect, in one possible implementation, the processor is coupled to the memory via an interface.

In combination with the seventh aspect, in a possible implementation, the chip system also includes a memory, in which a computer program or computer instructions are stored.

In an eighth aspect, an embodiment of the present application provides a chip, the chip comprising a circuit, and the circuit is used to execute any possible method in the above-mentioned first aspect.

BRIEF DESCRIPTION OF THE DRAWINGS

FIG1 is a functional block diagram of an intelligent driving device provided in an embodiment of the present application.

FIG2 is a diagram of an access control architecture of a vehicle-mounted system provided in an embodiment of the present application.

FIG3 is a schematic block diagram of an operating system provided in an embodiment of the present application.

FIG4 is a schematic flowchart of a communication method provided in an embodiment of the present application.

FIG5 is another schematic flowchart of the communication method provided in an embodiment of the present application.

FIG6 is a schematic diagram of secure inter-process communication provided in an embodiment of the present application.

FIG. 7 is a schematic diagram of the service-based identity information saved by the calling identity management module provided in an embodiment of the present application.

FIG8 is a schematic diagram of the visibility of the processes at both ends in the inter-process communication IPC driver control identity data provided by an embodiment of the present application.

FIG9 is a schematic diagram of a receiving end process obtaining identity information of an initiating end process through a pointer address offset provided by an embodiment of the present application.

FIG. 10 is a schematic block diagram of a communication device provided in an embodiment of the application.

Detailed ways

The technical solution in the embodiment of the present application will be described below in conjunction with the drawings in the embodiment of the present application. In the description of the embodiment of the present application, unless otherwise specified, "/" means or, for example, A/B can mean A or B; "and/or" in this article is only a description of the association relationship of associated objects, indicating that there can be three relationships, for example, A and/or B can mean: A exists alone, A and B exist at the same time, and B exists alone.

In the embodiments of the present application, prefixes such as "first" and "second" are used only to distinguish different description objects, and have no limiting effect on the position, order, priority, quantity or content of the described objects. The use of prefixes such as ordinal numbers to distinguish description objects in the embodiments of the present application does not constitute a limitation on the described objects. For the statement of the described objects, please refer to the description in the context of the claims or embodiments, and no unnecessary limitation should be constituted due to the use of such prefixes. In addition, in the description of the present embodiment, unless otherwise specified, the meaning of "multiple" is two or more.

FIG1 is a functional block diagram of an intelligent driving device 100 provided in an embodiment of the present application. The intelligent driving device 100 may include a perception system 110 and a computing platform 120, wherein the perception system 110 may include one or more sensors for sensing information about the environment surrounding the intelligent driving device 100. For example, the perception system 110 may include a positioning system, and the positioning system may be a global positioning system (GPS), a Beidou system, or other positioning systems. The perception system 110 may also include an inertial measurement unit. One or more of an inertial measurement unit (IMU), a laser radar, a millimeter-wave radar, an ultrasonic radar, and a camera device.

Some or all functions of the intelligent driving device 100 may be controlled by the computing platform 120. The computing platform 120 may include one or more processors, such as processors 121 to 12n (n is a positive integer). The processor is a circuit with signal processing capability. In one implementation, the processor may be a circuit with instruction reading and execution capability, such as a central processing unit (CPU), a microprocessor, a graphics processing unit (GPU) (which can be understood as a microprocessor), or a digital signal processor (DSP); in another implementation, the processor may implement certain functions through the logical relationship of a hardware circuit, and the logical relationship of the hardware circuit is fixed or reconfigurable, such as a hardware circuit implemented by an application-specific integrated circuit (ASIC) or a programmable logic device (PLD), such as a field programmable gate array (FPGA). In a reconfigurable hardware circuit, the process of the processor loading a configuration document to implement the hardware circuit configuration can be understood as the process of the processor loading instructions to implement the functions of some or all of the above units. In addition, the processor can also be a hardware circuit designed for artificial intelligence, which can be understood as an ASIC, such as a neural network processing unit (NPU), a tensor processing unit (TPU), a deep learning processing unit (DPU), etc. In addition, the computing platform 120 can also include a memory, the memory is used to store instructions, and some or all of the processors 121 to 12n can call instructions in the memory to implement corresponding functions.

FIG2 shows a diagram of the vehicle system access control architecture provided by an embodiment of the present application. As shown in FIG2 , the vehicle system access control architecture includes a subject, an information system, a functional model, kernel services (KS) and a virtual memory manager (VMM). Among them, the subject includes over the air (OTA) upgrade service, vehicle history record (VHR), device authentication, vehicle cloud communication service, remote interaction, map update, AUTomotive open system architecture (AutoSAR) standard interface, AutoSAR internal interface and communication management (CM) agent. The information system includes a CM framework (CM skeleton), secure shared memory within the operating system (OS), and secure cryptographic identities between OSs. Functional modules include AutoSAR standard function modules (AutoSAR native function cluster) and AutoSAR internal function modules (AutoSAR function cluster), among which, AutoSAR standard function modules include AutoSAR log module, AutoSAR network management module, AutoSAR persistent storage module, AutoSAR execution management module (AutoSAR execution management, AutoSAR EM), AutoSAR process health management module, AutoSAR cryptographic service module, AutoSAR intrusion detection module, AutoSAR time synchronization module and AutoSAR upgrade management module, etc.; AutoSAR internal function modules include power management module, file management module, device management module and network protocol stack. KS includes trusted execution environment (TEE), kernel object and heterogeneous devices, among which TEE includes trusted application (TA), key, etc. Kernel objects include files, drivers, interrupts, networks, memory and processes, etc. Heterogeneous devices include microcontroller unit (MCU), acceleration engine, hardware security module (HSM), CPU, GPU, etc. VMM includes a virtual memory access control module and a trusted security base. The CM framework is used to query the permissions of the AutoSAR identity and access management module (AutoSAR IAM), and the AutoSAR standard function module is used to query the fine-grained access permissions (e.g., key slot) of AutoSAR IAM. AutoSAR IAM can communicate with ECU A and ECU B respectively.

FIG3 shows a schematic block diagram of an operating system 300 provided in an embodiment of the present application. As shown in FIG3 , the operating system 300 may include multiple user-mode processes (e.g., application (APP) 1 and APP2), a kernel/trusted base, virtual memory, and physical memory. For example, APP1 may be used as a client process (or, an initiator process), and APP2 may be used as a server process (or, a receiver process). Usually, two processes in an operating system are isolated from each other, and one process cannot directly access the memory address of another process.

It should be understood that the operating system 300 shown in FIG. 3 may be located in the computing platform 120 shown in FIG. 1 .

System services or middleware of general operating systems are usually built in user mode. Because the kernel cannot be too bloated, otherwise it will cause problems such as a larger attack surface and poor reliability and stability. Therefore, the microkernel architecture is becoming more and more popular in mainstream operating systems. In operating systems that have built middleware or more system services, inter-process communication (IPC) has become a very important means of communication. The performance and security of IPC have become very important indicators of operating systems.

For example, the inter-process communication method (Unix domain socket, UDS) provided by the Linux kernel can enable the server process to obtain the abstract identity information (for example, UID, GID or PID) of the client process. Because the transmission of identity information through UDS requires additional system call overhead. As shown in Figure 3, APP2 must make at least one additional system call to obtain the abstract identity information of APP1 from the kernel. This system call will affect the latency and determinism of communication.

In addition, the implementation of a common IPC usually requires the help of the kernel or a trusted base. The acquisition of identity information in the current solution is Access cannot be integrated with the acquisition of payload data, and additional communication or system calls are required to obtain the identity information of the corresponding process from the kernel. At the same time, in the vehicle-oriented service-oriented scenario, the transmission of abstract identity information cannot well reflect the service-oriented identity of the vehicle software, which brings difficulties to the implementation of further access control.

In an embodiment of the present application, by constructing a mapping of identity information through the software trusted base of the middleware and integrating it with the inter-process communication framework of the kernel, the binding of payload data and identity information in IPC can be achieved, which helps to reduce the latency of inter-process communication and also helps to improve the efficiency and certainty of communication.

FIG4 shows a schematic flow chart of a communication method 400 provided in an embodiment of the present application. The method 400 may be executed by the intelligent driving device 100, or the method 400 may be executed by the computing platform 120, or the method 400 may be executed by a system-on-a-chip (SoC) in the computing platform 120, or the method 400 may be executed by a processor in the computing platform 120. The method 400 includes:

S410: Allocate a first memory for a first process in a kernel, where the first memory includes a memory for carrying identity information of the first process.

Exemplarily, the first process may be a client process or an initiator process. For example, the first process may be the application 1 in FIG. 3 .

Optionally, the method 400 further includes: allocating a second memory for the first process in the kernel, the second memory being a memory for carrying payload data. Before mapping from the kernel to the user state, the payload data may not be filled in the second memory. In this way, zero copy of the payload data during the mapping process can be achieved, thereby helping to reduce the latency of inter-process communication.

S420: Fill the identity information of the first process into the first memory.

Optionally, the identity information of the first process may be abstract identity information of the first process.

Exemplarily, the abstract identity information of the first process includes but is not limited to one or more of UID, GID or PID.

Optionally, the identity information of the first process may be service-based identity information of the first process.

Exemplarily, the service-based identity information of the first process includes, but is not limited to, vehicle-wide unique identification information for defining the first process (such as an application). For example, the service-based identity information of the first process may include deployment information of the first process (for example, identification information of the ECU where the application is located).

Optionally, the kernel stores a mapping relationship between the abstract identity information of the first process and the service identity information of the first process. The method 400 also includes: obtaining the abstract identity information of the first process; and determining the service identity information of the first process based on the abstract identity information of the first process and the mapping relationship.

S430: Map the first memory to obtain a shared memory, so that the second process obtains the identity information of the first process through the shared memory.

Exemplarily, the second process may be a server process or a receiver process.

Optionally, mapping the first memory includes: mapping the first memory from a kernel to a user state.

Optionally, the method 400 further includes: when the first process exits, clearing the mapping relationship.

Optionally, if the abstract identity information of the first process is filled into the first memory in S410, the second process may obtain the abstract identity information of the first process through the shared memory. The second process may send the abstract identity information of the first process to the EM. The EM may send the service identity information of the first process to the second process based on the abstract identity information of the first process.

Optionally, the method 400 further includes: controlling visibility of the first process and the second process to the first memory according to attribute information of the virtual address page table.

Optionally, the visibility of the first process and the second process to the first memory is controlled according to the attribute information of the virtual address page table, including: according to the attribute information of the virtual address page table, the first process is controlled to be invisible to the first memory and the second process is controlled to be readable but not writable to the first memory.

Optionally, the first memory also includes a memory for carrying payload data of the first process, and the method 400 further includes: filling the payload data in the shared memory, so that the second process obtains the payload data through the shared memory.

Optionally, the first memory includes a third memory and a fourth memory, the third memory is used to carry the identity information of the first process and the fourth memory is used to carry the payload data of the first process. The identity information of the first process can be filled in the third memory and the payload data of the first process is not filled in the fourth memory. In this way, the shared memory obtained after mapping from the kernel to the user state includes the identity information of the first process. And the payload data of the first process is not included. The first process can fill the payload data of the first process in the memory used to carry the payload data of the first process in the shared memory. In this way, zero copy of the payload data in the memory mapping process is achieved.

Optionally, the length of the memory in the first memory used to carry the identity information is a preset length.

In the embodiment of the present application, the memory used to carry identity information and the memory used to carry payload data can be decoupled, so that the fixed length of the memory used to carry identity information can be achieved, and the second process can quickly obtain the identity information of the first process, which helps to improve the efficiency of inter-process communication and also helps to reduce the latency of inter-process communication. At the same time, when mapping from the kernel to the user state, the payload data is zero-copied throughout the process, which also helps to further reduce the latency of inter-process communication.

Optionally, the second process obtains the identity information of the first process through a pointer address offset.

In an embodiment of the present application, the memory used to carry identity information can be of fixed length, so that the second process can quickly obtain the identity information of the first process by means of pointer address offset, which helps to reduce the delay of communication between processes.

FIG5 shows a schematic diagram of a communication method 500 provided in an embodiment of the present application. The data transmitted by an IPC may include two parts, such as payload data and notification information, wherein the payload data may include information indicating the memory address of the data, and the receiving process may read the data according to the memory address; the notification information may include the identity information of the initiating process. In order to achieve the ultimate performance of communication, the payload data may be transmitted between processes through a zero-copy mechanism, such as shared memory. The transmission of notification information is usually implemented based on some synchronization mechanism of the kernel, such as a pipe, a semaphore or a socket. In an embodiment of the present application, the transmission of identity information can be transmitted along with the notification between processes.

As shown in FIG. 5 , the inter-process communication method 500 provided in the embodiment of the present application may include the following steps:

S501, the execution management module (EM) obtains the identity information of the application from the configuration file of the application.

For example, the EM may be the AutoSAR EM shown in FIG2. The EM may be used to provide environment variables required by the application at runtime, or may be used by the application to control resource usage.

For example, Fig. 6 shows a schematic diagram of secure inter-process communication provided by an embodiment of the present application. When the application is compiled and packaged, a configuration file may be generated, and the configuration file may include the identity information of the application.

Optionally, the identity information of the application may include abstract identity information and service identity information of the application.

Exemplarily, the abstract identity information of the application includes but is not limited to the UID, GID or PID of the application.

In general operating systems, the identity information of a process is generally represented by the process ID, or PID. Some operating systems set different UIDs for different processes and use UID as the identity information of the process. Since the in-vehicle scenario involves multiple types of operating systems and a multi-component vehicle identity system, neither PID nor UID can fully reflect the identity information of the process in the in-vehicle scenario. Service-based identity information can better reflect the identity information of the process in the in-vehicle scenario.

Exemplarily, the service-based identity information of the application includes, but is not limited to, the vehicle-wide unique identification information used to define the application. The vehicle-wide unique identification information may be defined according to product requirements. For example, the vehicle-wide unique identification information may include the deployment information of the application (e.g., the identification information of the ECU where the application is located).

Exemplarily, the identification information of the ECU where the application is located may be the serial number of the ECU where the application is located. S502, when the EM controls the start-up of the initiating end process (application 1), the EM sets the abstract identity information of the process to the identity management module of the kernel through a system call.

In the vehicle scenario, the client process and the server process can be started by EM. EM has a parent-child relationship with the client process and the server process, so EM has the service identity information of all processes. These service identity information actually comes from the identity information statically configured by the user. Finally, these service identity information are injected by EM into the identity management module in the kernel with a higher security level for storage.

FIG7 shows a schematic diagram of calling the service-based identity information saved by the identity management module provided in an embodiment of the present application. As shown in FIG7, when the EM starts the process, the abstract identity information of the process is set to the kernel through a system call. The identity management module in the kernel can establish a mapping relationship between the abstract identity information of the process and the service-based identity information. When the process exits, the EM can notify the identity management module to complete the cleanup of the identity information to avoid resource leakage. When the EM in FIG7 starts the process, the EM can send an indication message 1 to the identity management module, and the indication message 1 is used to instruct the identity management module to establish a mapping relationship between the abstract identity information (for example, PID) of the process and the service-based identity information (the identification information of the ECU where the process is located). For example, when the identity management module receives the indication message 1, it can establish a mapping relationship between the abstract identity information of the process and the service-based identity information. When the process exits, the EM can send an indication message 2 to the identity management module, and the indication message 2 is used to instruct the identity management module to clean up the mapping relationship between the abstract identity information of the process and the service-based identity information. For example, when the identity management module receives the indication message 2, it can clean up the mapping relationship between the abstract identity information of the process and the service-based identity information.

S503, the EM controls the initiator process (application 1) to start.

EM controlling the start of application 1 can also be understood as EM launching application 1 .

S504, the initiator process (application 1) instructs the IPC driver to perform IPC initialization.

Application 1 instructing the IPC driver to perform IPC initialization can also be understood as application 1 calling the IPC initialization interface. As shown in Figure 6, the IPC driver handle (IPC handle) is the return value of the IPC driver initialization.

S505, the IPC driver receives the instruction of IPC initialization and allocates a notification memory block for the initiator process (application 1).

The above notification memory block may be the first memory in the above method 400 .

In one embodiment, the notification memory block may include an identity data memory, wherein the identity data memory may be used to carry identity information of the application 1 .

In one embodiment, the notification memory block may include a memory for carrying payload data and the identity data memory.

S506, the IPC driver obtains the identity information of the initiator process (application 1) from the identity management module and fills it into the identity data memory.

After the identity management module and EM establish the mapping relationship of the above identity information, the kernel has the ability to obtain the abstract identity information of the process. When IPC initialization occurs, the IPC driver can obtain the service identity information of application 1 from the identity management module and bind the IPC handle to the service identity information of application 1.

Since both the IPC driver and the identity management module are in the kernel, the identity management module can obtain the abstract identity information (e.g., PID) of application 1 through the task control block (TCB) of application 1, and then obtain the service identity information of application 1 injected by EM according to the mapping relationship between the abstract identity information and the service identity information. The service identity information can be filled into the identity data memory by the IPC driver module.

S507, the IPC driver performs memory mapping for the sending process (application 1) and the receiving process (application 2), obtains shared memory and records the mapping information in the IPC description blocks (notification blocks) at both ends of the communication.

In one embodiment, since the identity data memory is mapped by the IPC driver for the processes at both ends, the IPC driver can control the visibility of the identity data memory in the processes at both ends by controlling the mapped virtual address page table.

For example, Figure 8 shows a schematic diagram of the visibility of the identity data memory in the two end processes provided by the IPC driver provided in the embodiment of the present application. As shown in Figure 8, the initiating end process (application 1) is not visible to the identity data memory, and the receiving end process (application 2) can read but not write to the identity data memory.

In one embodiment, the IPC driver can control the visibility of the identity data memory to the processes at both ends by setting the attribute information of the virtual address page table.

Exemplarily, the IPC driver can control the application 1 to be invisible to the identity data memory and control the application 2 to be readable but not writable to the identity data memory by setting the attribute information of the virtual address page table.

In the embodiment of the present application, due to the high security of the identity mechanism, the two ends of the communication can implement a strictly one-way zero-trust model. The receiving end process can have zero trust in the initiating end process, and the receiving end process can safely and efficiently obtain the identity information of the initiating end process.

S508, the initiator process (application 1) writes the payload data into the shared memory.

In one embodiment, after mapping the notification memory block from the kernel to the user state, the shared memory can be obtained. The initiator process (application 1) writes the payload data into the memory used to carry the payload data in the shared memory.

In one embodiment, the payload data may include information for indicating a memory address of the data.

S509, the initiating end process (application 1) sends a notification to the receiving end process (application 2) using the kernel synchronization mechanism.

Exemplarily, the kernel synchronization mechanism includes a Futex mechanism.

It should be understood that the process of the initiator process sending a notification to the receiver process through the kernel synchronization mechanism can refer to the implementation method in the prior art, and this is not specifically limited in the embodiments of the present application.

S510, the receiving end process (application 2) reads the payload data and identity information of the sending end process (application 1) through the shared memory.

FIG9 shows a schematic diagram of a receiving end process obtaining the identity information of an initiating end process through a pointer address offset provided by an embodiment of the present application. When the IPC driver performs memory mapping, it can determine that the virtual addresses of the entire notification memory block sequence are continuous. In this way, the receiving end process can simply use the pointer address offset to access the identity data memory, thereby obtaining the identity information of the initiating end process.

Exemplarily, as shown in FIG. 9 , the notification memory block may be of fixed length (eg, 8 KB), wherein the length of the memory used to carry the payload data may be 6 KB, and the length of the identity data memory may be 2 KB.

In the embodiment of the present application, the memory used to carry the payload data can be decoupled from the identity data memory, so that the identity data memory can be fixed-length and the payload data can be zero-copy throughout the process.

The memory used to carry the payload data and the identity data memory are allocated once when the IPC is initialized. The identity data memory is filled once when it is allocated. The receiving process does not need to fall into the kernel again to obtain the identity information of the initiating process, which reduces the identity transmission mechanism in the entire communication. The impact of the communication process on communication performance.

In one embodiment, the receiving end process (application 2) can verify the access rights of the initiating end process based on the middleware access control mechanism and the identity information of the initiating end process (application 1) obtained from the shared memory.

In one embodiment, if the access permission is allowed, the receiving end process (application 2) can obtain the payload data in the shared memory. The receiving end process (application 2) can also access the data memory according to the memory address of the data indicated in the payload data.

In the embodiment of the present application, the shared memory is mapped by the kernel to the user-mode process for use. After the receiving end process is notified and awakened, the identity information of the initiating end process can be obtained through the shared memory. In this way, the receiving end process does not need to fall into the kernel again to obtain the identity information of the sending end process, which helps to reduce the delay of inter-process communication and also helps to improve the efficiency and certainty of communication.

An embodiment of the present application also provides a device for implementing any of the above methods. For example, a device is provided including units (or means) for implementing each step performed by an intelligent driving device or a computing platform in any of the above methods.

FIG10 shows a schematic block diagram of a communication device 1000 provided in an embodiment of the present application. As shown in FIG10 , the communication device 1000 includes:

A memory allocation unit 1010, configured to allocate a first memory to a first process in the kernel, wherein the first memory includes a memory for carrying identity information of the first process;

A data filling unit 1020, configured to fill the identity information of the first process into the first memory;

The data mapping unit 1030 is used to map the first memory to obtain a shared memory, so that the second process obtains the identity information of the first process through the shared memory.

Optionally, the identity information of the first process includes service-based identity information of the first process.

Optionally, the kernel stores a mapping relationship between the abstract identity information of the first process and the service identity information of the first process, and the device 1000 also includes: an acquisition unit for acquiring the abstract identity information of the first process; a determination unit for determining the service identity information of the first process based on the abstract identity information of the first process and the mapping relationship.

Optionally, the device 1000 further includes: a data cleaning unit, configured to clean up the mapping relationship when the first process exits.

Optionally, the device 1000 further includes: a control unit, configured to control visibility of the first process and the second process to the first memory according to attribute information of the virtual address page table.

Optionally, the control unit is used to: control the first process to be invisible to the first memory and control the second process to be readable but not writable to the first memory according to attribute information of the virtual address page table.

Optionally, the first memory also includes a memory for carrying the payload data of the first process, and the data filling unit 1020 is further used to fill the payload data in the shared memory so that the second process obtains the payload data through the shared memory.

For example, the memory allocation unit 1010 may be the computing platform in Figure 1 or a processing circuit, processor or controller in the computing platform. Taking the memory allocation unit 1010 as the processor 121 in the computing platform as an example, the processor 121 may allocate the first memory for the first process in the kernel.

For another example, the data filling unit 1020 may be the computing platform in Figure 1 or a processing circuit, processor or controller in the computing platform. Taking the data filling unit 1020 as the processor 122 in the computing platform as an example, the processor 122 may fill the identity information of the first process in the first memory allocated by the processor 121 in the kernel.

For another example, the data mapping unit 1030 may be the computing platform in FIG1 or a processing circuit, a processor, or a controller in the computing platform. Taking the data mapping unit 1030 as the processor 12n in the computing platform as an example, the processor 12n may map the first memory to obtain a shared memory, so that the second process obtains the identity information of the first process through the shared memory. For example, the processor 12n may map the first memory in the kernel state to the user state, so that the second process obtains the identity information of the first process through the shared memory mapped to the user state.

The functions implemented by the above memory allocation unit 1010, the functions implemented by the data filling unit 1020 and the functions implemented by the data mapping unit 1030 can be implemented by different processors respectively, or some functions can be implemented by the same processor, or all functions can be implemented by the same processor, and the embodiments of the present application are not limited to this.

It should be understood that the division of the units in the above device is only a division of logical functions. In actual implementation, they can be fully or partially integrated into one physical entity, or they can be physically separated. In addition, the units in the device can be implemented in the form of a processor calling software; for example, the device includes a processor, the processor is connected to a memory, the memory stores instructions, and the processor calls the instructions stored in the memory to implement any of the above methods or to implement the functions of the units of the device, wherein the processor is, for example, a general-purpose processor, such as a CPU or a microprocessor, and the memory is a memory inside the device or a memory outside the device. Alternatively, the units in the device can be implemented in the form of hardware circuits, and the functions of some or all units can be realized by designing the hardware circuits. The hardware circuit can be understood as one or more processors; for example, in one implementation In the present invention, the hardware circuit is an ASIC, and the functions of some or all of the above units are realized by designing the logical relationship of the components in the circuit; for example, in another implementation, the hardware circuit can be realized by PLD, taking FPGA as an example, which can include a large number of logic gate circuits, and the connection relationship between the logic gate circuits is configured by the configuration file, so as to realize the functions of some or all of the above units. All units of the above device can be realized in the form of software called by the processor, or in the form of hardware circuit, or in part by software called by the processor, and the rest by hardware circuit.

In an embodiment of the present application, a processor is a circuit with the ability to process signals. In one implementation, the processor may be a circuit with the ability to read and run instructions, such as a CPU, a microprocessor, a GPU, or a DSP; in another implementation, the processor may implement certain functions through the logical relationship of a hardware circuit, and the logical relationship of the hardware circuit is fixed or reconfigurable, such as a hardware circuit implemented by an ASIC or PLD, such as an FPGA. In a reconfigurable hardware circuit, the process of the processor loading a configuration document to implement the hardware circuit configuration can be understood as the process of the processor loading instructions to implement the functions of some or all of the above units. In addition, it can also be a hardware circuit designed for artificial intelligence, which can be understood as an ASIC, such as an NPU, TPU, DPU, etc.

It can be seen that each unit in the above device can be one or more processors (or processing circuits) configured to implement the above method, such as: CPU, GPU, NPU, TPU, DPU, microprocessor, DSP, ASIC, FPGA, or a combination of at least two of these processor forms.

In addition, all or part of the units in the above device can be integrated together, or can be implemented independently. In one implementation, these units are integrated together and implemented in the form of a SOC. The SOC may include at least one processor for implementing any of the above methods or implementing the functions of each unit of the device. The type of the at least one processor may be different, for example, including a CPU and an FPGA, a CPU and an artificial intelligence processor, a CPU and a GPU, etc.

An embodiment of the present application also provides a device, which includes a processing unit and a storage unit, wherein the storage unit is used to store instructions, and the processing unit executes the instructions stored in the storage unit so that the device executes the method or steps executed by the above embodiment.

Optionally, if the device is located in an intelligent driving device, the processing unit may be the processor 121 - 12n shown in FIG. 1 .

An embodiment of the present application also provides an intelligent driving device, which may include the above-mentioned communication device 1000.

Optionally, the intelligent driving device may be a vehicle.

The embodiment of the present application further provides a computer program product, which includes: a computer program code, and when the computer program code is executed on a computer, the computer executes the above method.

The embodiment of the present application further provides a computer-readable medium, wherein the computer-readable medium stores a program code. When the computer program code is executed on a computer, the computer executes the above method.

In the implementation process, each step of the above method can be completed by an integrated logic circuit of hardware in a processor or an instruction in the form of software. The method disclosed in conjunction with the embodiment of the present application can be directly embodied as a hardware processor for execution, or a combination of hardware and software modules in a processor for execution. The software module can be located in a mature storage medium in the art such as a random access memory, a flash memory, a read-only memory, a programmable read-only memory, or a power-on erasable programmable memory, a register, etc. The storage medium is located in a memory, and the processor reads the information in the memory and completes the steps of the above method in conjunction with its hardware. To avoid repetition, it is not described in detail here.

It should be understood that in the embodiment of the present application, the memory may include a read-only memory and a random access memory, and provide instructions and data to the processor.

It should also be understood that in the various embodiments of the present application, the size of the serial numbers of the above-mentioned processes does not mean the order of execution. The execution order of each process should be determined by its function and internal logic, and should not constitute any limitation on the implementation process of the embodiments of the present application.

Those of ordinary skill in the art will appreciate that the units and algorithm steps of each example described in conjunction with the embodiments disclosed herein can be implemented in electronic hardware, or a combination of computer software and electronic hardware. Whether these functions are performed in hardware or software depends on the specific application and design constraints of the technical solution. Professional and technical personnel can use different methods to implement the described functions for each specific application, but such implementation should not be considered to be beyond the scope of this application.

Those skilled in the art can clearly understand that, for the convenience and brevity of description, the specific working processes of the systems, devices and units described above can refer to the corresponding processes in the aforementioned method embodiments and will not be repeated here.

In the several embodiments provided in the present application, it should be understood that the disclosed systems, devices and methods can be implemented in other ways. For example, the device embodiments described above are only schematic. For example, the division of the units is only a logical function division. There may be other division methods in actual implementation, such as multiple units or components can be combined or integrated into another system, or some features can be ignored or not executed. Another point is that the mutual coupling or direct coupling or communication connection shown or discussed can be through some interfaces, indirect coupling or communication connection of devices or units, which can be electrical, mechanical or other forms.

The units described as separate components may or may not be physically separated, and the components shown as units may or may not be physical units, that is, they may be located in one place or distributed over multiple network units. Some or all of the units may be selected to achieve the purpose of the solution of this embodiment.

In addition, each functional unit in each embodiment of the present application may be integrated into one processing unit, or each unit may exist physically separately, or two or more units may be integrated into one unit.

If the functions are implemented in the form of software functional units and sold or used as independent products, they can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of the present application, or the part that contributes to the prior art or the part of the technical solution, can be embodied in the form of a software product. The computer software product is stored in a storage medium, including several instructions for a computer device (which can be a personal computer, server, or network device, etc.) to perform all or part of the steps of the methods described in each embodiment of the present application. The aforementioned storage media include: U disk, mobile hard disk, read-only memory (ROM), random access memory (RAM), disk or optical disk, and other media that can store program codes.

The above is only a specific implementation of the present application, but the protection scope of the present application is not limited thereto. Any technician familiar with the technical field can easily think of changes or substitutions within the technical scope disclosed in the present application, which should be covered. Within the protection scope of the present application. Therefore, the protection scope of the present application shall be based on the protection scope of the claims.

Claims

A communication method, comprising:

Allocate a first memory for a first process in a kernel, wherein the first memory includes a memory for carrying identity information of the first process;

Filling the identity information of the first process into the first memory;

The first memory is mapped to obtain a shared memory, so that the second process obtains the identity information of the first process through the shared memory.
The method according to claim 1 is characterized in that the identity information of the first process includes service-based identity information of the first process.
The method according to claim 2 is characterized in that the kernel stores a mapping relationship between the abstract identity information of the first process and the service identity information of the first process, and the method further comprises:

Obtaining abstract identity information of the first process;

The service identity information of the first process is determined according to the abstract identity information of the first process and the mapping relationship.
The method according to claim 3, characterized in that the method further comprises:

When the first process exits, the mapping relationship is cleared.
The method according to any one of claims 1 to 4, characterized in that the method further comprises:

According to the attribute information of the virtual address page table, visibility of the first process and the second process to the first memory is controlled.
The method according to claim 5, characterized in that controlling the visibility of the first process and the second process to the first memory according to the attribute information of the virtual address page table comprises:

According to the attribute information of the virtual address page table, the first process is controlled to be invisible to the first memory and the second process is controlled to be readable but not writable to the first memory.
The method according to any one of claims 1 to 6, characterized in that the first memory also includes a memory for carrying payload data of the first process, and the method further includes:

The payload data is filled in the shared memory, so that the second process obtains the payload data through the shared memory.
The method according to any one of claims 1 to 7 is characterized in that the second process obtains the identity information of the first process through a pointer address offset.
A communication device, comprising:

a memory allocation unit, configured to allocate a first memory for a first process in a kernel, wherein the first memory includes a memory for carrying identity information of the first process;

A data filling unit, used to fill the identity information of the first process into the first memory;

A data mapping unit is used to map the first memory to obtain a shared memory, so that the second process obtains the identity information of the first process through the shared memory.
The device according to claim 9 is characterized in that the identity information of the first process includes service-based identity information of the first process.
The device according to claim 10, characterized in that the kernel stores a mapping relationship between the abstract identity information of the first process and the service identity information of the first process, and the device further comprises:

An acquiring unit, configured to acquire the abstract identity information of the first process;

A determining unit is used to determine the service identity information of the first process according to the abstract identity information of the first process and the mapping relationship.
The device according to claim 11, characterized in that the device further comprises:

A data cleaning unit is used to clean up the mapping relationship when the first process exits.
The device according to any one of claims 9 to 12, characterized in that the device further comprises:

A control unit is used to control visibility of the first process and the second process to the first memory according to attribute information of the virtual address page table.
The device according to claim 13, characterized in that the control unit is used to:

According to the attribute information of the virtual address page table, the first process is controlled to be invisible to the first memory and the second process is controlled to be readable but not writable to the first memory.
The device according to any one of claims 9 to 14, characterized in that the first memory further includes a memory for carrying payload data of the first process, and the data filling unit is further used to:

The payload data is filled in the shared memory, so that the second process obtains the payload data through the shared memory.
The device according to any one of claims 9 to 15 is characterized in that the second process obtains the identity information of the first process through a pointer address offset.
A communication device, comprising:

Memory for storing computer programs;

A processor, configured to execute the computer program stored in the memory, so that the apparatus performs the method according to any one of claims 1 to 8.
An intelligent driving device, characterized in that it comprises the device as claimed in any one of claims 9 to 17.
The intelligent driving device according to claim 18 is characterized in that the intelligent driving device is a vehicle.
A computer-readable storage medium, characterized in that a computer program is stored thereon, and when the computer program is executed by a computer, the method according to any one of claims 1 to 8 is implemented.
A chip, characterized in that it comprises a circuit, wherein the circuit is used to execute the method according to any one of claims 1 to 8.