Data communication method and device between application programs

Abstract

The embodiment of the invention provides a data communication method and device between application programs. In the data communication method between the application programs, the sizes of storage spaces occupied by predefined sending port data and receiving port data in a memory are determined respectively, the sending port data comprise port information related to a sending port, and the receiving port data comprise port information related to a receiving port; obtaining the number of sending ports and the number of receiving ports required by an application program group for communication based on the vehicle software middleware; according to the size of the storage space occupied by the sending port data and the receiving port data in the memory and the number of the sending ports and the number of the receiving ports, the size of the needed memory is determined; and applying for a shared memory from an operating system according to the determined memory size so as to manage the sending port data and the receiving port data.

Description

Technical Field

[0001] The embodiments in this specification generally relate to the field of communication technology, and more specifically, to methods and apparatus for data communication between applications. Background Technology

[0002] As vehicles become increasingly intelligent, the amount of data exchange between different processes and threads within the vehicle system is also growing. This has led to the development of "vehicle software middleware," which connects upper-layer applications and the underlying operating system. Vehicle software middleware refers to foundational software that sits above the hardware and operating system but below the application software. Its main function is to provide a runtime and development environment for upper-layer application software, helping developers shield themselves from the complexities of the underlying hardware and allowing them to focus on application-layer development.

[0003] Meanwhile, due to the rapid development of autonomous driving technology and the increasing diversity of vehicle functions, the importance of communication middleware has been further enhanced. Therefore, how to achieve high-quality communication functionality in vehicle software middleware has become a worthy research topic. Summary of the Invention

[0004] In view of the above, embodiments of this specification provide a data communication method and apparatus for inter-application systems. Using this data communication scheme, the actual storage space required by the application group communicating based on vehicle software middleware can be calculated based on the number of sending and receiving ports required and the predefined storage space occupied by sending and receiving port data in memory. Shared memory for storing the sending and receiving port data can then be requested based on the calculated actual required storage space. This allows for dynamic adjustment of the requested shared memory size according to the actual number of ports needed, minimizing unnecessary memory usage while ensuring normal communication services.

[0005] According to one aspect of an embodiment of this specification, a data communication method between applications is provided, comprising: determining the size of storage space occupied by predefined sending port data and receiving port data in memory, wherein the sending port data includes port information related to the sending port, and the receiving port data includes port information related to the receiving port; obtaining the number of sending ports and the number of receiving ports required by an application group communicating based on the vehicle software middleware; determining the required memory size based on the size of storage space occupied by the sending port data and receiving port data in memory, and the number of sending ports and the number of receiving ports; and requesting shared memory from the operating system based on the determined memory size to manage the sending port data and the receiving port data.

[0006] According to another aspect of the embodiments of this specification, an inter-application data communication apparatus is provided, comprising: a first space determination unit configured to determine the size of storage space occupied by predefined sending port data and receiving port data in memory, wherein the sending port data includes port information related to the sending port, and the receiving port data includes port information related to the receiving port; a port quantity acquisition unit configured to acquire the number of sending ports and the number of receiving ports required by an application group communicating based on the vehicle software middleware; a second space determination unit configured to determine the required memory size based on the size of storage space occupied by the sending port data and receiving port data in memory, and the number of sending ports and the number of receiving ports; and a shared memory request unit configured to request shared memory from the operating system based on the determined memory size to manage the sending port data and the receiving port data.

[0007] According to another aspect of the embodiments of this specification, a domain processor is provided, comprising: at least one processor, and a memory coupled to the at least one processor, the memory storing a computer program, the at least one processor executing the computer program to implement the data communication method between applications as described above.

[0008] According to another aspect of the embodiments of this specification, a computer program product is provided, including a computer program that, when executed by a processor, implements the data communication method between applications as described above. Attached Figure Description

[0009] A further understanding of the nature and advantages of this specification can be achieved by referring to the following figures. In the figures, similar components or features may have the same reference numerals.

[0010] Figure 1 An exemplary application architecture for an inter-application data communication method and apparatus according to embodiments of this specification is shown.

[0011] Figure 2 An exemplary scenario of a data communication method and apparatus between applications according to embodiments of this specification is shown.

[0012] Figure 3 A flowchart illustrating an example of an inter-application data communication method according to an embodiment of this specification is shown.

[0013] Figure 4 A flowchart illustrating an example of a process for obtaining the number of ports according to an embodiment of this specification is shown.

[0014] Figure 5 A flowchart illustrating yet another example of an inter-application data communication method according to an embodiment of this specification is shown.

[0015] Figure 6 A schematic diagram illustrating an example of shared memory according to an embodiment of this specification is shown.

[0016] Figure 7 A block diagram illustrating an example of an inter-application data communication apparatus according to an embodiment of this specification is shown.

[0017] Figure 8 A schematic diagram of an example of a domain controller according to an embodiment of this specification is shown. Detailed Implementation

[0018] The subject matter described herein will be discussed below with reference to exemplary embodiments. It should be understood that these embodiments are discussed merely to enable those skilled in the art to better understand and implement the subject matter described herein, and are not intended to limit the scope, applicability, or examples set forth in the claims. The function and arrangement of the elements discussed may be changed without departing from the scope of the embodiments described herein. Various processes or components may be omitted, substituted, or added as needed in the various examples. Furthermore, features described in some examples may be combined in other examples.

[0019] As used herein, the term "comprising" and its variations are open terms meaning "including but not limited to". The term "based on" means "at least partially based on". The terms "one embodiment" and "an embodiment" mean "at least one embodiment". The term "another embodiment" means "at least one other embodiment". The terms "first", "second", etc., may refer to different or the same objects. Other definitions, whether explicit or implicit, may be included below. Unless explicitly indicated by the context, the definition of a term shall remain consistent throughout the specification.

[0020] Currently, in some implemented methods, the maximum number of sending and receiving ports that a vehicle software middleware can support is determined once it is released. If the maximum number of sending and receiving ports supported by the vehicle software middleware is preset to a small value, communication failures may occur on some vehicle models with high port requirements. Conversely, if the maximum number of sending and receiving ports supported by the vehicle software middleware is preset to a large value, it will consume a significant amount of memory resources, resulting in resource waste on some vehicle models with low port requirements.

[0021] Therefore, embodiments of this specification propose an inter-application data communication scheme. In this scheme, the actual storage space required by the application group communicating via vehicle software middleware can be calculated based on the number of sending and receiving ports required and the predefined storage space occupied by the sending and receiving port data in memory. Shared memory for storing the sending and receiving port data is then requested based on the calculated required storage space. Thus, for different vehicle models or different stages of software development for the same vehicle model, the vehicle software middleware can dynamically adjust the size of the requested shared memory based on the actual number of ports required, instead of uniformly requesting a pre-specified size of shared memory each time after release. This minimizes unnecessary memory usage while ensuring normal communication services.

[0022] The flowcharts used in this specification illustrate operations implemented according to some embodiments of this specification. It should be clearly understood that the operations in the flowcharts may not be implemented in a sequential order. Instead, the operations may be implemented in reverse order or simultaneously. Furthermore, one or more additional operations may be added to the flowcharts. One or more operations may be removed from the flowcharts.

[0023] The data communication method and apparatus between applications according to embodiments of this specification will now be described in detail with reference to the accompanying drawings.

[0024] Figure 1 An exemplary application architecture 100 of a data communication method and apparatus between applications according to embodiments of this specification is shown.

[0025] like Figure 1As shown, the data communication method and apparatus between applications in the embodiments of this specification can be applied to a vehicle software system 100. The vehicle software system 100 may include an operating system 110, vehicle software middleware 120, and in-vehicle applications 131, 132, etc. In some examples, the operating system 110 may include Linux, Qnx, Android, etc. In some examples, the vehicle software middleware 120 may be a software development kit (SDK) for developing and running in-vehicle applications. In some examples, the vehicle software middleware 120 may include a runtime of a Portable Operating System Interface of UNIX (POSIX) based on a platform and development tools. In some examples, the vehicle software middleware 120 may include communication middleware, such as middleware for inter-process communication (IPC), such as Iceoryx. Iceoryx uses a shared memory method to implement zero-copy communication, that is, the publisher puts data into shared memory, and the subscriber reads data directly from shared memory, avoiding multiple copies of data in memory. In-vehicle applications 131 and 132 may include, for example, map navigation applications, music playback applications, etc.

[0026] It should be understood that the embodiments in this specification are not limited to the exemplary application architectures described above, but can also be applied to any variation of these exemplary application architectures and any other applicable application architectures.

[0027] Figure 2 An exemplary scenario 200 of an inter-application data communication method and apparatus according to embodiments of this specification is shown.

[0028] like Figure 2 As shown, vehicle application 231 can send data to vehicle application 232 via transmit port 241. Vehicle application 232 can receive the data via receive port 242. Transmit port 241 may have transmit port data to ensure that data can be transmitted correctly. Similarly, receive port 242 may also have receive port data to ensure that data can be transmitted correctly. It is understood that before vehicle application 231 uses transmit port 241, it needs to access the aforementioned transmit port data to obtain relevant information. Similarly, before vehicle application 232 uses receive port 242, it needs to access the aforementioned receive port data to obtain relevant information. Therefore, transmit port data and receive port data need to be stored in a storage area accessible to the corresponding vehicle application.

[0029] In this embodiment, the vehicle software middleware 120 can request shared memory from the operating system 110 and store transmit port data and receive port data in the requested shared memory. Thus, both the vehicle application 231 and the vehicle application 232 can access their respective required transmit port data and receive port data.

[0030] It should be understood that the embodiments in this specification are not limited to the exemplary scenarios described above, but can also be applied to any variation of these exemplary scenarios and any other applicable scenarios.

[0031] Figure 3 A flowchart illustrating an example of an inter-application data communication method 300 according to an embodiment of this specification is shown.

[0032] like Figure 3 As shown, in step S310, the storage space occupied by the predefined sending port data and receiving port data in memory can be determined respectively. In this embodiment, the sending port data may include port information related to the sending port. In some examples, the port information related to the sending port may include, for example, port usage status information indicating whether the port is active, the sequence number of the data to be sent, and the chunk address where the data to be sent is located. In this embodiment, the receiving port data may include port information related to the receiving port. In some examples, the port information related to the receiving port may include, for example, subscription status information for the subscription status, a chunk address container transmitted from the sending port, and a beacon for notifying the receipt of new data.

[0033] In one example, the send port data can be implemented as a predefined data structure `SenderPortData` containing the aforementioned information. In another example, the receive port data can be implemented as a predefined data structure `ReceiverPortData` containing the aforementioned information. In some examples, the keyword `sizeof` can be used to determine the amount of memory occupied by the send and receive port data, for example, `sizeof(SenderPortData)` and `sizeof(ReceiverPortData)`.

[0034] In step S320, the number of sending ports and receiving ports required for the application group communicating based on the vehicle software middleware can be obtained. In some examples, the number of sending ports and receiving ports required for the application group communicating based on the vehicle software middleware can be obtained through assignment operations. In some examples, the number of sending ports and receiving ports required for the application group can be represented by the variables m_max_sdr_port_number and m_max_rcv_port_number, respectively. In some examples, all applications for the same vehicle model can be grouped into an application group communicating based on the vehicle software middleware. In some examples, the number of sending ports and receiving ports required for the application group can be specified by the user of the vehicle software middleware or the developer of the vehicle model.

[0035] In some examples, the application group may include in-vehicle applications. In-vehicle applications can be relatively independent applications adapted to an in-vehicle operating system to achieve a specific function, or they can be applications within a complex system used to achieve a specific sub-function. The aforementioned relatively independent applications may include, but are not limited to, at least one of the following: in-vehicle navigation applications, multimedia applications, information applications, AI assistant applications, communication applications, and cockpit voice control applications. The aforementioned complex system may, for example, be an autonomous driving system, which may contain various applications implementing multiple sub-functions such as environmental perception, parking and / or driving path planning, decision-making, and control. Therefore, in-vehicle applications can also be applications within an autonomous driving system used to implement a specific sub-function as described above.

[0036] In step S330, the required memory size can be determined based on the amount of storage space occupied by the transmitting port data and the receiving port data in memory, as well as the number of transmitting ports and the number of receiving ports. In some examples, the required memory size can be determined to be no less than the sum of the product of the amount of storage space occupied by the transmitting port data in memory and the number of transmitting ports, and the sum of the products of the amount of storage space occupied by the receiving port data in memory and the number of receiving ports.

[0037] In some implementations, additional storage space reserved for other data can be added to the sum of the products as determined above. In some examples, in Iceoryx, other data may include at least one of the following: port data associated with a dedicated gateway port (InterfacePort) (e.g., which can be implemented as a data structure InterfacePortData), port data associated with an application-specific port (e.g., which can be implemented as a data structure ApplicationPortData), and data associated with a runnable data structure (e.g., which can be implemented as a data structure RunnableData). In one example, the required memory size can be determined as sizeof(SenderPortData) × m_max_sdr_port_number + sizeof(ReceiverPortData) × m_max_rcv_port_number + (sizeof(InterfacePortData) + InterfacePortData::extraSize()) × m_max_interface_number + sizeof(ApplicationPortData) × m_max_process_number + sizeof(RunnableData) × m_max_runnable_number. The `InterfacePortData::extraSize()` function can be used to obtain the size of the extra data in the `InterfacePortData` structure, which can then be used as the size of the buffer. `m_max_interface_number`, `m_max_process_number`, and `m_max_runnable_number` can be used to indicate the number of elements in the corresponding `InterfacePortData`, `ApplicationPortData`, and `RunnableData` data structures, respectively. In some examples, these numbers can be specified through assignment operations.

[0038] In step S340, shared memory is requested from the operating system based on the determined memory size to manage send port data and receive port data. In some examples, shared memory not less than the memory size determined above can be requested from the operating system.

[0039] It should be understood that all steps in process 300 and their order are exemplary, and embodiments of this disclosure will also cover any modifications to process 300. For example, in some implementations, step S320 may be performed first, followed by step S310.

[0040] Figure 4 A flowchart illustrating an example of a port number acquisition process 400 according to an embodiment of this specification is provided. Acquisition process 400 is... Figure 3 An exemplary implementation of step S320.

[0041] like Figure 4 As shown, in S410, the number of sending ports and receiving ports required by each application in the application group that communicates based on the vehicle software middleware are obtained. In some examples, the number of sending ports and receiving ports required by each application can be obtained as specified by the user of the vehicle software middleware or the developer of each application in the aforementioned application group.

[0042] In some implementations, the vehicle software middleware daemon parses a JSON file containing the required number of send and receive ports for each application to obtain these port numbers. In some examples, users of the vehicle software middleware or application developers can set the required number of send and receive ports for their applications in a .json file. The vehicle software middleware daemon (such as the RouDi (Routing and Discovery) process in Iceoryx) can parse the JSON file corresponding to each application to obtain the required number of send and receive ports, thus achieving automatic parsing of the relevant file to obtain the required number of send and receive ports for each application.

[0043] In S420, the number of transmit and receive ports required by each application is determined based on the number of transmit and receive ports needed by each application. In some examples, the number of transmit and receive ports required by each application can be statistically analyzed (e.g., summed) to determine the number of transmit and receive ports required by the application group. In some examples, transmit and / or receive ports that meet certain conditions can be reused, thereby reducing the number of transmit and receive ports required by the application group to some extent, and consequently reducing the memory resource consumption of the vehicle software middleware.

[0044] Figure 5 A flowchart illustrating yet another example of an inter-application data communication method 500 according to an embodiment of this specification is shown. Figure 5 Based on Figure 3 Another example flow shown in the example flow diagram. Figure 5Steps S510-S540 shown can be referred to respectively. Figure 3 The difference between steps S310-S340 shown in the figure is that... Figure 5 Steps S550 and S560 are shown in the diagram. To avoid repetition, only the differences will be described here.

[0045] like Figure 5 As shown, in S550, the transmit port data of the transmit port used by the application in the application group and the receive port data of the receive port used by the application are stored in shared memory, so that the applications in the application group can obtain the required transmit port data and / or receive port data through the shared memory. In some examples, the transmit port data may be known to the first application as the producer, and the first application can obtain the receive port data of the second application as the consumer through the shared memory. Similarly, the receive port data may be known to the second application as the consumer, and the second application can obtain the transmit port data of the first application as the producer through the shared memory. Figure 2 Taking an exemplary scenario as an example, vehicle application 231 can act as the first application, in which case the transmission port data of transmission port 241 is known to vehicle application 231. Vehicle application 232 can act as the second application, in which case the reception port data of reception port 242 is known to vehicle application 232. Simultaneously, vehicle application 231 can obtain the reception port data of reception port 242 of vehicle application 232 through shared memory. Furthermore, vehicle application 232 can also obtain the transmission port data of transmission port 241 of vehicle application 231 through shared memory. Therefore, the first application and the second application can communicate through the transmission port corresponding to the aforementioned transmission port data and the reception port corresponding to the aforementioned reception port data.

[0046] In some implementations, step S560 can be performed further. In step S560, transmit port data and receive port data stored in shared memory are maintained so that applications in the application group can obtain port information related to the corresponding transmit port and / or receive port. In some examples, when an application in the application group needs to use a new transmit port or receive port, the corresponding transmit port data or receive port data can be stored in the shared memory. In some examples, when the information of a bound transmit port or receive port used by an application in the application group changes, the corresponding transmit port data or receive port data in the shared memory can be modified.

[0047] In some implementations, maintaining send and receive port data stored in shared memory can be achieved by instantiating a pre-built addressable container class using an initialization function. This addressable container class manages the send and receive port data stored in shared memory. In some examples, the addressable container class (e.g., PlacementVector) can be implemented as a container similar to "std::vector", with its capacity dynamically changing at runtime. In other examples, the addressable container class can also resemble "std::vector" and have functions such as begin(), end(), and push_back(). Furthermore, the addressable container class can be initialized by its member functions (e.g., the init() function). The parameters to be passed in the initialization function can include the number of send and receive ports required by the application group and the initial address of the shared memory. Thus, the addressable container object instantiated through the initialization function knows the amount of data it needs to manage (e.g., the number of send and receive ports) and the address where this data is located (e.g., the initial address of the shared memory). Furthermore, unlike the traditional "std::vector" container which manages data on the heap, the addressable container objects in this scheme manage data on shared memory, thus enabling the aforementioned inter-process communication.

[0048] use Figure 5 The method shown enables dynamic management of send and receive port data, thus providing a foundation for efficient communication between applications in an application group.

[0049] Figure 6 A schematic diagram of an example of shared memory 600 according to an embodiment of this specification is shown. The process for storing port data involving shared memory 600 is... Figure 5 An exemplary implementation of step S550.

[0050] like Figure 6 As shown, shared memory 600 may include a transmit port data storage area 610 and a receive port data storage area 620. When an application in the application group (e.g., application A) needs to use a transmit port (e.g., transmit port 2), the transmit port data of the aforementioned transmit port (e.g., transmit port 2) can be stored in the transmit port data storage area 610 of shared memory 600. When an application in the application group (e.g., application C) needs to use a receive port (e.g., receive port 3), the receive port data of the aforementioned receive port (e.g., receive port 3) can be stored in the receive port data storage area 620 of shared memory 600.

[0051] use Figure 6 The shared memory shown allows for the storage of transmit port data and receive port data in pre-defined transmit port data storage areas and receive port data storage areas, respectively, rather than storing the transmit port data and receive port data sequentially in the order of their use. This facilitates efficient management of transmit port data and receive port data separately.

[0052] use Figures 1-6 The disclosed inter-application data communication method calculates the actual storage space required by an application group communicating via vehicle software middleware, based on the number of sending and receiving ports required and the predefined storage space occupied by sending and receiving port data in memory. It then allocates shared memory to store the calculated data. This allows the vehicle software middleware to dynamically adjust the allocated shared memory size based on the actual number of ports needed for different vehicle models or different stages of software development for the same vehicle model, instead of uniformly allocating a pre-defined block of shared memory after each release. This minimizes unnecessary memory usage while ensuring normal communication services.

[0053] Figure 7 A block diagram illustrating an example of an inter-application data communication device 700 according to an embodiment of this specification is shown. This device embodiment can be used with... Figures 1-6 Corresponding to the method embodiments shown, the device can be implemented using software, hardware, or a combination of both, and can be applied to various electronic devices.

[0054] like Figure 7 As shown, the data communication device 700 between applications may include a first space determination unit 710, a port quantity acquisition unit 720, a second space determination unit 730, and a shared memory allocation unit 740.

[0055] The first space determination unit 710 is configured to determine the size of the storage space occupied by predefined transmission port data and reception port data in memory, wherein the transmission port data includes port information related to the transmission port, and the reception port data includes port information related to the reception port.

[0056] The port quantity acquisition unit 720 is configured to acquire the number of sending ports and the number of receiving ports required by the application group communicating based on the vehicle software middleware.

[0057] The second space determination unit 730 is configured to determine the required memory size based on the size of the storage space occupied by the transmitting port data and the receiving port data in memory, as well as the number of transmitting ports and the number of receiving ports.

[0058] The shared memory request unit 740 is configured to request shared memory from the operating system based on a determined memory size in order to manage the transmit port data and the receive port data.

[0059] It is understood that the detailed descriptions of the first space determination unit 710, the port quantity acquisition unit 720, the second space determination unit 730, and the shared memory allocation unit 740 can be found in the foregoing. Figures 1-6 The specific steps in the embodiments will not be repeated here.

[0060] Reference above Figures 1 to 7 Embodiments of the data communication method and apparatus between applications according to the embodiments of this specification have been described.

[0061] The data communication device between applications in the embodiments of this specification can be implemented in hardware, software, or a combination of hardware and software. Taking software implementation as an example, as a logical device, it is formed by the processor of its host device reading the corresponding computer program instructions from memory into memory and executing them. In the embodiments of this specification, the data communication device between applications can, for example, be implemented using a domain controller.

[0062] Figure 8 A schematic diagram of an example of a domain controller 800 according to an embodiment of this specification is shown.

[0063] like Figure 8 As shown, the domain controller 800 may include at least one processor 810, a memory (e.g., non-volatile memory) 820, a memory 830, and a communication interface 840, and the at least one processor 810, the memory 820, the memory 830, and the communication interface 840 are connected together via a bus 850. The at least one processor 810 executes at least one computer-readable instruction (i.e., the elements implemented in software above) stored or encoded in the memory.

[0064] In one embodiment, computer-executable instructions are stored in memory, which, when executed, cause at least one processor 810 to: determine the size of the storage space occupied by predefined transmit port data and receive port data in memory, wherein the transmit port data includes port information associated with the transmit port, and the receive port data includes port information associated with the receive port; obtain the number of transmit ports and the number of receive ports required by the application group communicating based on the vehicle software middleware; determine the required memory size based on the size of the storage space occupied by the transmit port data and receive port data in memory, as well as the number of transmit ports and the number of receive ports; and request shared memory from the operating system based on the determined memory size to manage the transmit port data and the receive port data.

[0065] It should be understood that the computer-executable instructions stored in memory, when executed, cause at least one processor 810 to perform the above-described combinations in the various embodiments of this specification. Figures 1-6 The description includes various operations and functions.

[0066] According to one embodiment, a computer program product is provided, for example. The computer program product may include a computer program. The computer program may be executable instructions (i.e., the elements implemented in software above) stored on a computer-readable storage medium, which, when executed by a computer, cause the computer to perform the above-described combinations of the various embodiments of this specification. Figures 1-6 The description includes various operations and functions.

[0067] Specifically, a system or apparatus equipped with a readable storage medium may be provided, on which software program code implementing the functions of any of the embodiments described above is stored, and the computer or processor of the system or apparatus can read and execute the instructions stored in the readable storage medium.

[0068] In this case, the program code itself, which can be read from a readable medium, can perform the functions of any of the above embodiments. Therefore, the machine-readable code and the readable storage medium storing the machine-readable code constitute a part of the present invention.

[0069] The computer program code required for the operation of each part of this manual can be written in any one or more programming languages, including object-oriented programming languages ​​such as Java, Scala, Smalltalk, Eiffel, JADE, Emerald, C++, C#, VB, .NET, and Python; conventional procedural programming languages ​​such as C, Visual Basic 2003, Perl, COBOL 2002, PHP, and ABAP; dynamic programming languages ​​such as Python, Ruby, and Groovy; or other programming languages. This program code can run on the user's computer, or as a standalone software package on the user's computer, or partially on the user's computer and partially on a remote computer, or entirely on a remote computer or server. In the latter case, the remote computer can be connected to the user's computer via any network, such as a local area network (LAN) or wide area network (WAN), or connected to an external computer (e.g., via the Internet), or in a cloud computing environment, or used as a service, such as Software as a Service (SaaS).

[0070] Examples of readable storage media include floppy disks, hard disks, magneto-optical disks, optical disks (such as CD-ROM, CD-R, CD-RW, DVD-ROM, DVD-RAM, DVD-RW, DVD-RW), magnetic tapes, non-volatile memory cards, and ROMs. Alternatively, program code can be downloaded from a server computer or the cloud via a communication network.

[0071] The foregoing has described specific embodiments of this specification. Other embodiments are within the scope of the appended claims. In some cases, the actions or steps recited in the claims may be performed in a different order than that shown in the embodiments and may still achieve the desired result. Furthermore, the processes depicted in the drawings do not necessarily require the specific or sequential order shown to achieve the desired result. In some embodiments, multitasking and parallel processing are possible or may be advantageous.

[0072] Not all steps and units in the above process and system structure diagrams are mandatory; some steps or units can be omitted as needed. The execution order of each step is not fixed and can be determined as required. The device structure described in the above embodiments can be a physical structure or a logical structure. That is, some units may be implemented by the same physical entity, or some units may be implemented by multiple physical entities, or they may be jointly implemented by certain components in multiple independent devices.

[0073] The term "exemplary" as used throughout this specification means "serving as an example, instance, or illustration" and does not imply that it is "preferred" or "advantageous" over other embodiments. Detailed descriptions are included for the purpose of providing an understanding of the described techniques. However, these techniques may be practiced without these detailed descriptions. In some instances, well-known structures and apparatuses are shown in block diagram form to avoid obscuring the concepts of the described embodiments.

[0074] The optional embodiments of the present specification have been described in detail above with reference to the accompanying drawings. However, the embodiments of the present specification are not limited to the specific details in the above embodiments. Within the scope of the technical concept of the embodiments of the present specification, various simple modifications can be made to the technical solutions of the embodiments of the present specification, and these simple modifications all fall within the protection scope of the embodiments of the present specification.

[0075] The foregoing description of this specification is provided to enable any person skilled in the art to implement or use the content of this specification. Various modifications to the content of this specification will be apparent to those skilled in the art, and the general principles defined herein can be applied to other variations without departing from the scope of protection of this specification. Therefore, this specification is not limited to the examples and designs described herein, but is consistent with the widest scope of the principles and novel features disclosed herein.

Claims

1. A method for data communication between applications, comprising: The storage space occupied by predefined sending port data and receiving port data in memory is determined respectively, wherein the sending port data includes port information related to the sending port, and the receiving port data includes port information related to the receiving port; Obtain the number of sending ports and the number of receiving ports required for the application group to communicate based on the vehicle software middleware; Based on the storage space occupied by the transmitting and receiving port data in memory, and the number of transmitting and receiving ports, determine the required memory size; and The system requests shared memory from the operating system based on the determined memory size to manage the data sent from the port and the data received from the port.

2. The data communication method as described in claim 1, wherein, The number of sending ports and the number of receiving ports required to obtain the application group communicating based on the vehicle software middleware include: Obtain the number of sending ports and the number of receiving ports required by each application in the application group that communicates based on the vehicle software middleware; and The number of sending ports and the number of receiving ports required by the application group are determined based on the number of sending ports and the number of receiving ports required by each application.

3. The data communication method as described in claim 2, wherein, The method of obtaining the number of sending ports and the number of receiving ports required for each application in the application group that communicates based on the vehicle software middleware includes: The daemon process of the vehicle software middleware parses a JSON file containing the number of sending ports and receiving ports required by each application to obtain the number of sending ports and receiving ports required by each application.

4. The data communication method as described in claim 1, wherein, The method further includes: The send port data of the send port used by the application in the application group and the receive port data of the receive port used by the application are stored in the shared memory, so that the application in the application group can obtain the required send port data and / or receive port data through the shared memory.

5. The data communication method as described in claim 4, wherein, The shared memory includes a transmit port data storage area and a receive port data storage area. The step of storing the transmit port data of the transmit port used by the application in the application group and the receive port data of the receive port used by the application in the application group into the shared memory includes: Store the send port data of the send ports used by the applications in the application group into the send port data storage area in the shared memory; and The receive port data used by the applications in the application group is stored in the receive port data storage area in the shared memory.

6. The data communication method as described in claim 4, wherein, The method further includes: Maintain transmit port data and receive port data stored in the shared memory so that applications in the application group can obtain port information related to the corresponding transmit port and / or receive port.

7. The data communication method as described in claim 6, wherein, The maintenance of send port data and receive port data stored in the shared memory is achieved by instantiating a pre-built addressable container class using an initialization function. The addressable container class is used to manage the send port data and receive port data stored in the shared memory. The parameters to be passed in the initialization function include the number of send ports and the number of receive ports required by the application group, as well as the initial address of the shared memory.

8. The data communication method according to any one of claims 1 to 7, wherein, The application group includes in-vehicle applications, which include at least one of the following: in-vehicle navigation applications, multimedia applications, information applications, artificial intelligence assistant applications, communication applications, cockpit voice control applications, and applications in autonomous driving systems used to achieve at least one of the functions of environmental perception, parking and / or driving path planning, decision-making, and control.

9. A domain controller, comprising: At least one processor, and a memory coupled to the at least one processor, the memory storing a computer program, the at least one processor executing the computer program to implement the data communication method between applications as described in any one of claims 1 to 7.

10. A computer program product comprising a computer program that, when executed by a processor, implements the inter-application data communication method as described in any one of claims 1 to 7.

Images