Someip communication method, vehicle and medium

Abstract

The application provides a SOMEIP communication method, a vehicle and a medium, which are applied to an embedded real-time operation QNX system, the QNX system comprising a first application process and a SOMEIP daemon process, and the method comprises the following steps: the first application process sends a first request to the SOMEIP daemon process through a first channel, the first request is used for requesting to query a destination communication endpoint corresponding to to-be-sent data in the first application, and the first channel is determined based on a client identifier of the SOMEIP daemon process; after the SOMEIP daemon process queries the destination communication endpoint in response to the first request, the SOMEIP daemon process transmits the to-be-sent data of the first application to a second application based on the destination communication endpoint. In this way, the technical problems of the QNX system in the prior art, such as communication performance bottleneck, can be solved.

Description

SOMEIP communication methods, vehicles, and media Technical Field

[0001] This application relates to the field of automotive technology, specifically to a SOMEIP communication method, a vehicle, and a medium. Background Technology

[0002] Embedded real-time operating systems (Quick Unix, QNX) offer advantages such as real-time performance, stability, and security, and are frequently used in automotive applications such as intelligent driving controllers and cockpit instrument controllers. However, traditional inter-process communication in QNX systems presents some challenges. For instance, the use of Unix domain sockets can lead to performance bottlenecks, particularly when dealing with large amounts of communication data, significantly increasing the load on the central processing unit (CPU) and impacting system performance.

[0003] Therefore, there is an urgent need to propose a better communication scheme based on the QNX system. Summary of the Invention

[0004] In view of this, the embodiments of this application aim to provide a SOMEIP communication method, vehicle and medium, which can solve the technical problems such as communication performance bottlenecks in the existing QNX system.

[0005] In a first aspect, this application provides a SOMEIP communication method applied to an embedded real-time operating QNX system, wherein the QNX system includes a first application process and a SOMEIP daemon process, and the method includes:

[0006] The first application process sends a first request to the SOMEIP daemon process through a first channel. The first request is used to query the destination communication endpoint corresponding to the data to be sent in the first application. The first channel is determined based on the client identifier of the SOMEIP daemon process.

[0007] After the SOMEIP daemon responds to the first request and finds the destination communication endpoint, it transmits the data to be sent by the first application to the second application based on the destination communication endpoint.

[0008] In some embodiments, transmitting the data to be sent from the first application to the second application based on the destination communication endpoint includes:

[0009] Based on the domain communication method between the first application and the second application and the destination communication endpoint, the data to be sent by the first application is transmitted to the second application.

[0010] In some embodiments, the domain communication method is intra-domain communication, the destination communication endpoint is the communication endpoint of the second application process corresponding to the second application, and the step of transmitting the data to be sent from the first application to the second application based on the domain communication method between the first application and the second application and the destination communication endpoint includes:

[0011] The SOMEIP daemon sends a first response to the first application process through a second channel. The first response carries the client identifier of the second application process where the destination communication endpoint is located. The second channel is determined based on the client identifier of the first application process.

[0012] After receiving the client identifier of the second application process, the first application process sends a second request to the second application process through a third channel. The third channel is determined based on the client identifier of the second application process. The second request is used to request the second application process to forward the data to be sent by the first application to the second application.

[0013] In response to the second request, the second application process forwards the data to be sent by the first application to the second application.

[0014] In some embodiments, the method further includes:

[0015] The second application process sends a third request to the SOMEIP daemon through the first channel. The third request is used to request a query of the communication endpoint of the first application process corresponding to the response data in the second application.

[0016] In response to the third request, the SOMEIP daemon sends a third response to the second application process through the third channel, the third response carrying the client identifier of the first application process;

[0017] After receiving the client identifier of the first application process, the second application process sends a fourth request to the first application process through the corresponding second channel. The fourth request is used to request the first application process to forward the response data of the second application to the first application.

[0018] In response to the fourth request, the first application process forwards the response data from the second application to the first application.

[0019] In some embodiments, the domain communication method is inter-domain communication, the destination communication endpoint is an endpoint communicating with the domain where the second application resides, the first request carries the data to be sent by the first application, and the step of transmitting the data to be sent by the first application to the second application based on the domain communication method between the first application and the second application and the destination communication endpoint includes:

[0020] The SOMEIP daemon routes the data to be sent by the first application to the destination communication endpoint;

[0021] The destination communication endpoint forwards the data to be sent by the first application to the peer protocol stack, so that the peer protocol stack forwards the data to be sent by the first application to the second application again. The peer protocol stack is the SOMEIP protocol stack used by the domain where the second application is located.

[0022] In some embodiments, the method further includes:

[0023] After receiving the response data of the second application sent by the peer protocol stack, the destination communication endpoint routes the response data of the second application to the SOMEIP daemon.

[0024] After the SOMEIP daemon queries the client identifier of the first application process, it forwards the response data of the second application to the first application process through the second channel, which is determined based on the client identifier of the first application process.

[0025] The first application process then forwards the response data from the second application to the first application.

[0026] In some embodiments, the method further includes:

[0027] The target application process creates a temporary channel based on the process identifier of the target application process and the application identifier of the corresponding target application in the target application process. The temporary channel is used to transmit the client identifier of the target application process.

[0028] The SOMEIP daemon creates the first channel based on the client identifier of the SOMEIP daemon;

[0029] After the target application process and the SOMEIP daemon successfully connect, the target application process sends an allocation request to the SOMEIP daemon through the first channel. The allocation request is used to request the SOMEIP daemon to allocate a client identifier for the target application process.

[0030] The SOMEIP daemon sends an allocation response to the target application process through the temporary channel. The allocation response carries the client identifier of the target application process, enabling the target application process to determine the target communication channel based on the client identifier of the target application process.

[0031] Wherein, when the target application process is the first application process, the target channel is the second channel; and / or, when the target application process is the second application process, the target channel is the third channel.

[0032] In some embodiments, before the target application process and the SOMEIP daemon successfully connect, the method further includes:

[0033] The target application process sends a connection request for the first channel to the SOMEIP daemon, the connection request carrying the process identifier of the target application process and the application identifier of the target application;

[0034] After receiving the connection request, the SOMEIP daemon attempts to establish a connection with the target application process through a temporary channel to determine whether the target application process and the SOMEIP daemon have successfully connected.

[0035] Secondly, this application provides a SOMEIP communication device for use in an embedded real-time operating QNX system, wherein the QNX system includes a first application process and a SOMEIP daemon process, and the device includes:

[0036] The communication module is used to send a first request to the SOMEIP daemon process through a first channel based on the first application process. The first request is used to request a query for the destination communication endpoint corresponding to the data to be sent in the first application. The first channel is determined based on the client identifier of the SOMEIP daemon process.

[0037] The communication module is further configured to transmit the data to be sent by the first application to the second application based on the destination communication endpoint after the SOMEIP daemon queries the destination communication endpoint in response to the first request.

[0038] For any content not introduced or described in the embodiments of this application, please refer to the relevant descriptions in the foregoing method embodiments; they will not be repeated here.

[0039] Thirdly, this application provides a vehicle, including: a processor; a memory for storing processor-executable instructions; wherein the processor is configured to execute the executable instructions to implement the steps of the above-described SOMEIP communication method.

[0040] Fourthly, this application provides a computer-readable storage medium storing computer program instructions thereon, which, when executed by a processor, implement the steps of the above-described SOMEIP communication method.

[0041] The technical solution provided in this application embodiment can include the following beneficial effects: In this application, the first application process sends a first request to the SOMEIP daemon process through a first channel. The first request is used to query the destination communication endpoint corresponding to the data to be sent in the first application. The first channel is determined based on the client identifier of the SOMEIP daemon process. After the SOMEIP daemon process responds to the first request and finds the destination communication endpoint, it transmits the data to be sent by the first application to the second application based on the destination communication endpoint. In this way, the SOMEIP protocol can be used as an inter-process communication method in the QNX system. By leveraging the advantages of SOMEIP protocol communication, data transmission between the first application and the second application can be realized, thereby improving the communication performance of the entire QNX system. It also solves the technical problems of communication performance bottlenecks and impact on system performance in the prior art of the QNX system.

[0042] The above description is only an overview of the technical solution of this application. In order to better understand the technical means of this application and to implement it in accordance with the contents of the specification, and to make the above and other objects, features and advantages of this application more obvious and understandable, the following are specific embodiments of this application. Attached Figure Description

[0043] Various other advantages and benefits will become apparent to those skilled in the art upon reading the following detailed description of preferred embodiments. The accompanying drawings are for illustrative purposes only and are not intended to limit the scope of this application. Furthermore, the same reference numerals denote the same parts throughout the drawings.

[0044] Figure 1 is a schematic diagram of a SOMEIP protocol framework provided in an embodiment of this application.

[0045] Figure 2 is a flowchart illustrating a SOMEIP communication method provided in an embodiment of this application.

[0046] Figure 3 is a schematic diagram of a channel creation process provided in an embodiment of this application.

[0047] Figure 4 is a schematic diagram of channel creation provided in an embodiment of this application.

[0048] Figure 5 is a schematic diagram of a domain SOMEIP communication process provided in an embodiment of this application.

[0049] Figure 6 is a schematic diagram of an inter-domain SOMEIP communication process provided in an embodiment of this application.

[0050] Figure 7 is a schematic diagram of the structure of a SOMEIP communication device provided in an embodiment of this application.

[0051] Figure 8 is a schematic diagram of the structure of an electronic device provided in an embodiment of this application.

[0052] Figure 9 is a structural schematic diagram of a vehicle provided in an embodiment of this application. Detailed Implementation

[0053] The technical solutions of the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this application, and not all embodiments. Based on the embodiments of this application, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of this application.

[0054] Unless otherwise defined, the technical or scientific terms used in the embodiments of this specification shall have the ordinary meaning understood by one of ordinary skill in the art to which this specification pertains. The terms "first," "second," and similar terms used in the embodiments of this specification do not indicate any order, quantity, or importance, but are merely used to avoid confusion of constituent elements.

[0055] Unless the context otherwise requires, throughout this specification, "a plurality of" means "at least two," and "including" is interpreted as open-ended or encompassing, that is, "including, but not limited to." In the description of this specification, terms such as "one embodiment," "some embodiments," "exemplary embodiment," "example," "specific example," or "some examples" are intended to indicate that a particular feature, structure, material, or characteristic associated with that embodiment or example is included in at least one embodiment or example of this specification. The illustrative representations of the above terms do not necessarily refer to the same embodiment or example.

[0056] Exemplary embodiments of the present application will now be described in more detail with reference to the accompanying drawings. While exemplary embodiments of the present application are shown in the drawings, it should be understood that the present application may be implemented in various forms and should not be limited to the embodiments set forth herein. Rather, these embodiments are provided so that this application will be thorough and complete, and will fully convey the scope of the present application to those skilled in the art.

[0057] Please refer to Figure 1, which is a schematic diagram of a Scalable Service-Oriented Middleware over IP (SOMEIP) protocol framework provided in an embodiment of this application. As shown in Figure 1, the SOMEIP protocol framework 10 can be applied to a QNX system. The SOMEIP protocol can include two types of processes, namely, application process 100 and SOMEIP daemon process 200. Typically, there is only one SOMEIP daemon process in a QNX system. The application process 100 can include application 101, SOMEIP agent 102, and communication endpoint (hereinafter referred to as internal communication endpoint) 103 of the application process. Application 101 can refer to an application installed in the QNX system, simply referred to as an application. The aforementioned SOMEIP proxy 102 is primarily responsible for communication between application 102 and application process 100 or SOMEIP daemon 200. Specifically, application process 100 can communicate with the SOMEIP daemon or other application processes through its SOMEIP proxy. For example, it can receive data to be sent from application 101 and forward it to the SOMEIP daemon 200 or other application processes; or it can receive data from the SOMEIP daemon 200 or other application processes and forward it to application 101. The aforementioned internal communication endpoint 103 can refer to any endpoint in application process 100 that supports communication with the SOMEIP daemon 200 or other application processes; this application does not impose further limitations or details on this.

[0058] The aforementioned SOMEIP daemon 200 may include a configuration management module 201, a routing management module 202, a service discovery module 203, a service management module 204, a subscription management module 205, an identification management module (also known as a client identification management module) 206, a communication endpoint of the SOMEIP daemon (also known as an internal communication endpoint) 207, a Transmission Control Protocol (TCP) communication endpoint 208, a User Datagram Protocol (UDP) communication endpoint 209, or other custom functional modules / endpoints. The configuration management module 201 is primarily responsible for reading and parsing the SOMEIP protocol configuration file and managing related configuration parameters, such as the multicast address and multicast port for service discovery. This application does not elaborate further on these parameters. The routing management module 202 is primarily responsible for routing and forwarding messages from one endpoint to another. The service discovery module 203 is primarily responsible for implementing SOMEIP service discovery functions, such as service lookup (find) and service registration (offer). This application does not elaborate further on these parameters. The aforementioned service management module 204 is primarily responsible for recording and managing local and remote service information, such as managing application version numbers and instance identifiers. This application does not impose further limitations or details on this. The aforementioned subscription management module 205 is primarily responsible for managing the subscription status and subscription endpoints of local and remote events. For example, when these event data changes, the subscription management module 205 actively pushes and notifies the corresponding event data changes. The aforementioned identifier management module 206 is primarily responsible for managing client identifiers in the QNX system, assigning a unique client identifier to application process 100, and ensuring / avoiding duplicate client identifiers for application process 100. The aforementioned TCP communication endpoint 208 can refer to an endpoint that supports communication with other domains using the TCP protocol, such as communication at the transport layer using the TCP protocol. The aforementioned UDP communication endpoint 209 can refer to an endpoint that supports communication with other domains using the UDP protocol, such as communication at the transport layer using the UDP protocol. This application does not impose further limitations or details on this.

[0059] Based on the above embodiments, please refer to Figure 2, which is a flowchart illustrating a SOMEIP communication method provided in this application embodiment. The method shown in Figure 2 can be applied to the SOMEIP protocol framework shown in Figure 1 or its application in a QNX system, where the QNX system includes at least a first application process and a SOMEIP daemon process. The method shown in Figure 2 may include the following implementation steps:

[0060] S201. The first application process sends a first request to the SOMEIP daemon through a first channel. The first request is used to query the destination communication endpoint corresponding to the data to be sent in the first application. The first channel is determined based on the client identifier of the SOMEIP daemon.

[0061] The first channel mentioned above in this application may be a communication channel pre-created by the system based on the client identifier of the SOMEIP daemon as the SOMEIP daemon. The specific creation embodiment of this channel will be described in detail below in this application and will not be introduced here.

[0062] S202. After the SOMEIP daemon responds to the first request and finds the destination communication endpoint, it transmits the data to be sent by the first application to the second application based on the destination communication endpoint.

[0063] This application can transmit the data to be sent by the first application to the second application based on the aforementioned target communication endpoint and the domain communication method between the first application and the second application. The domain communication method can include intra-domain communication and inter-domain communication (also known as extra-domain communication). Intra-domain communication can refer to communication between applications or nodes within the same network domain, while inter-domain communication can refer to communication between different network domains. The aforementioned target communication endpoint can refer to the aforementioned internal communication endpoint, the aforementioned UDP communication endpoint, or the aforementioned TCP communication endpoint, which will be detailed below and will not be described here.

[0064] By implementing the embodiments of this application, the first application process sends a first request to the SOMEIP daemon process through a first channel. The first request is used to query the destination communication endpoint corresponding to the data to be sent in the first application. The first channel is determined based on the client identifier of the SOMEIP daemon process. After the SOMEIP daemon process finds the destination communication endpoint in response to the first request, it transmits the data to be sent from the first application to the second application based on the destination communication endpoint. In this way, the SOMEIP protocol can be used as an inter-process communication method in the QNX system. Leveraging the advantages of SOMEIP protocol communication, data transmission between the first and second applications can be achieved, thereby improving the overall communication performance of the QNX system. It also solves the technical problems of communication performance bottlenecks and impacts on system performance in existing QNX systems.

[0065] The following describes some specific and optional embodiments related to this application.

[0066] Before step S201, this application also needs to pre-set / create corresponding communication channels for each application process and the aforementioned SOMEIP daemon. Please refer to Figure 3, which is a schematic diagram of a channel creation process provided by an embodiment of this application. The process shown in Figure 3 may include the following implementation steps:

[0067] S301. The target application process creates a temporary channel based on the process identifier of the target application process and the application identifier of the corresponding target application in the target application process. The temporary channel is used to transmit the client identifier of the target application process.

[0068] When the target application process is started, the target application process can create a temporary channel based on its process ID and the application ID of the corresponding target application within the target application process. This temporary channel is used to transmit the unique client identifier assigned to the target application process by the SOMEIP daemon. Optionally, this application can use "someip" plus the client identifier to name or distinguish the corresponding channel. Please refer to Figure 4, which is a schematic diagram of channel creation provided by an embodiment of this application. As shown in Figure 4, the temporary channel can be represented as "someip-0000-00000003-0001", where "someip" is a fixed prefix, and "0000" is also fixed, indicating that it can communicate with the SOMEIP daemon. "00000003" represents the process ID of the target application process in the QNX system. "0001" represents the application ID of the corresponding application within the target application process.

[0069] S302, The SOMEIP daemon creates a first channel based on the client identifier of the SOMEIP daemon.

[0070] When the SOMEIP daemon is started, the SOMEIP daemon can create a first channel based on its unique client identifier. Since the SOMEIP daemon is globally unique in the QNX system, it can consistently use the first channel, such as someip-0000, to communicate with other processes, etc., and this application does not impose any further limitations on this.

[0071] The channel involved in this application can be represented as a channel server on the receiving side and as a corresponding channel client on the sending side. That is, the client represents the sending side of the corresponding channel, and the server represents the receiving side of the corresponding channel. For example, in Figure 4, someip-0000 server represents the receiving side of channel someip-0000, and someip-0000 client represents the sending side of channel someip-0000. The aforementioned someip-0000 server and someip-0000 client belong to two ends of the same channel someip-0000, and this application will not impose further limitations or details on this.

[0072] It should be noted that this application does not limit the order of execution of each of the above steps S301 and S302. For example, step S302 can be executed first and then step S301 can be executed. This application does not impose any restrictions on this.

[0073] S303, the target application process sends a connection request for the first channel to the SOMEIP daemon, the connection request carrying the process identifier of the target application process and the application identifier of the target application.

[0074] The target application process described in this application can actively connect to the first channel (such as the someip-0000 channel) of the SOMEIP daemon process. Specifically, it can actively send a connection request for the first channel to the SOMEIP daemon process, and send the process identifier (such as 00000003) and the application identifier (such as 0001) of the target application process to the SOMEIP daemon process in the connection request. This application does not impose any further limitations on this.

[0075] S304. After receiving the connection request, the SOMEIP daemon attempts to establish a connection with the temporary channel of the target application process to determine whether the target application process and the SOMEIP daemon have successfully connected.

[0076] After receiving the connection request, the SOMEIP daemon can actively connect to the temporary channel of the target application process (such as the someip-0000-00000003-0001 channel). If the connection is successful, it can be determined that the target application process and the SOMEIP daemon have successfully connected; otherwise, it can be determined that the target application process and the SOMEIP daemon have failed to connect. This application does not impose any further limitations on this.

[0077] S305. After the target application process and the SOMEIP daemon successfully connect, the target application process sends an allocation request to the SOMEIP daemon through the first channel. The allocation request is used to request the SOMEIP daemon to allocate a client identifier for the target application process.

[0078] After the target application process and the SOMEIP daemon successfully connect, the target application process can request the SOMEIP daemon to assign a unique client identifier to the target application process through the first channel (such as the someip-0000 channel). For example, the target application process can send an allocation request to the SOMEIP daemon through the first channel to request the SOMEIP daemon to assign a unique client identifier to the target application process.

[0079] S306. The SOMEIP daemon sends an allocation response to the target application process through the temporary channel. The allocation response carries the client identifier of the target application process, enabling the target application process to determine the target communication channel based on the client identifier of the target application process. Wherein, when the target application process is the first application process, the target channel is the second channel; and / or, when the target application process is the second application process, the target channel is the third channel.

[0080] Upon receiving the allocation request, the SOMIP daemon selects an unused client identifier (e.g., 0001) and assigns it to the target application process. It then sends the client identifier of the target application process to the target application process via a temporary channel (e.g., someip-0000-00000003-0001). Specifically, the client identifier can be included in the allocation response and returned to the target application process. Upon receiving the allocation response, the target application process can parse and save its client identifier. Furthermore, the target application process can determine and create a corresponding target channel based on its own client identifier (e.g., 0001), such as someip-0001, to facilitate subsequent communication with other processes via this target channel.

[0081] The target application process mentioned above in this application may refer to a first application process and / or a second application process. Specifically, when the target application process is the first application process, the target channel created by this application may be a second channel. For example, if the client identifier of the first application process is 0001, then the second channel may be someip-0001, etc. When the target application process is the second application process, the target channel created by this application may be a third channel. For example, if the client identifier of the second application process is 0002, then the third channel may be someip-0002, etc. This application does not impose further limitations or details in this regard.

[0082] In step S201, the first application sends the data to be sent to the first application process to which it belongs / corresponds. After receiving the data to be sent by the first application through its own SOMEIP proxy, the first application process can send a first request to the SOMEIP daemon process through the first channel. This first request is used to query the destination communication endpoint corresponding to the data to be sent, such as which application's communication endpoint it is sent to.

[0083] In step S202, after receiving the first request, the SOMEIP daemon can query and obtain the destination communication endpoint in response to the first request. For example, if the data to be sent needs to be sent to a second application, the destination communication endpoint can be the communication endpoint corresponding to the second application, depending on the domain communication method between the first and second applications. For example, in intra-domain communication, the destination communication endpoint is the communication endpoint of the second application process to which the second application belongs; conversely, in inter-domain communication, the destination communication endpoint can be an endpoint that can communicate with the second application, such as a TCP / UDP communication endpoint, etc. This application does not impose further limitations on this.

[0084] This application does not limit the specific implementation method of transmitting the data to be sent. For example, in one implementation, the domain communication method is intra-domain communication, and the destination communication endpoint is the communication endpoint of the second application process to which the second application belongs / corresponds. After the SOMEIP daemon finds the destination communication endpoint, it can send a first response to the first application process through the second channel. The first response carries the client identifier of the second application process where the destination communication endpoint is located. The second channel is pre-determined and created based on the client identifier of the first application process, and can be referred to the relevant description in the embodiment described in Figure 3 above, which will not be repeated here.

[0085] Accordingly, after receiving the first response, the first application process can parse it to obtain the client identifier of the second application process (e.g., 0002), and then send a second request to the second application process through the third channel. This second request carries the data to be sent by the first application and requests the second application process to forward the data to the second application. The third channel is pre-determined and created based on the client identifier of the second application process, and its details can be found in the relevant description in the embodiment described in Figure 3 above; further elaboration is omitted here. Accordingly, after receiving the second request, the second application process can respond by forwarding the data to be sent by the first application to the second application, thereby realizing data transmission between the first and second applications.

[0086] In some optional embodiments, when the second application needs to return response data to the first application, the data return is performed similarly to the previous embodiment. Specifically, for example, the second application first sends its own response data to the second application process it belongs to. After receiving the response data through its own SOMEIP proxy, the second application process can send a third request to the SOMEIP daemon through the first channel. This third request is used to query the destination communication endpoint corresponding to the response data, which is the communication endpoint of the first application process to which the first application belongs. Correspondingly, upon receiving the third request, the SOMEIP daemon can respond by querying the communication endpoint of the first application process and sending a third response to the second application process through the third channel. This third response carries the client identifier of the first application process. Correspondingly, upon receiving the third response, the first application process can parse it to obtain the client identifier of the first application process, and then determine the second channel corresponding to the client identifier of the first application process. Then, a fourth request is sent to the first application process through the second channel. This fourth request carries the response data of the second application and requests the first application process to forward the response data of the second application to the first application. Accordingly, upon receiving the fourth request, the first application process can forward the response data of the second application to the first application in response to the fourth request.

[0087] To help better understand the embodiments of this application, examples are provided below. Please refer to Figure 5, which is a schematic diagram of a domain-wide SOMEIP communication process provided by an embodiment of this application. The process shown in Figure 5 may include the following implementation steps:

[0088] S501, the first application sends its data to be sent to the SOMEIP agent of the first application process. Accordingly, the SOMEIP agent of the first application process receives the data to be sent by the first application.

[0089] S502, the SOMEIP proxy of the first application process can send a first request to the SOMEIP daemon through the first channel soomeip-0000. This first request is used to query which application's destination communication endpoint the data to be sent is being sent to. Accordingly, the SOMEIP daemon receives the first request.

[0090] S503. In response to the first request, the SOMEIP daemon queries and obtains the destination communication endpoint, i.e., the communication endpoint of the second application process where the second application resides, and also obtains the client identifier 0002 of the second application process. The SOMEIP daemon sends a first response to the first application process through the second channel someip-0001, which carries the client identifier 0002 of the second application process. Accordingly, the first application process receives the first response, parses it to obtain the client identifier 0002 of the second application process, and then determines the third channel someip-0002 corresponding to the client identifier 0002.

[0091] S504. The first application process sends a second request to the second application process through the third channel someip-0002. This second request requests that the data to be sent by the first application be forwarded to the second application. Specifically, the SOMEIP proxy of the first application process can connect to the third channel someip-0002 and transmit the second request to the third channel someip-0002. Correspondingly, the second application process receives the second request, that is, the second application process receives the second request in the third channel someip-0002.

[0092] S505. In response to the second request, the second application process forwards the data to be sent by the first application to the second application for use or processing by the second application. This application does not impose any further limitations on this.

[0093] In this application, if the second application needs to reply to / send response data to the first application, step S506 can continue; otherwise, the process can be terminated.

[0094] S506, the second application sends its own response data to the SOMEIP agent of the second application process. Accordingly, the SOMEIP agent of the second application process receives the response data of the second application.

[0095] S507. The SOMEIP proxy of the second application process can send a third request to the SOMEIP daemon through the first channel soomeip-0000. This third request is used to query which application's destination communication endpoint the aforementioned response data was sent to. Accordingly, the SOMEIP daemon receives the aforementioned third request.

[0096] S508. In response to the third request, the SOMEIP daemon queries and obtains the destination communication endpoint, i.e., the communication endpoint of the first application process where the first application resides, and also obtains the client identifier 0001 of the first application process. The SOMEIP daemon sends a third response to the second application process through the third channel someip-0002, which carries the client identifier 0001 of the first application process. Accordingly, the second application process receives the third response, parses it to obtain the client identifier 0001 of the first application process, and then determines the second channel someip-0001 corresponding to the client identifier 0001.

[0097] S509. The second application process sends a fourth request to the first application process through the second channel someip-0001. This fourth request requests that the response data of the second application be forwarded to the first application. Specifically, the SOMEIP proxy of the second application process can connect to the second channel someip-0001 and transmit the fourth request to the second channel someip-0001. Correspondingly, the first application process receives the fourth request, that is, the first application process receives the fourth request in the second channel someip-0001.

[0098] S510. In response to the fourth request, the first application process forwards the response data of the second application to the first application for use or determination by the first application. This application does not impose any further limitations on this.

[0099] In another embodiment, the aforementioned domain communication method is inter-domain communication (also known as external-domain communication), and the aforementioned destination communication endpoint is an endpoint capable of communicating with the domain where the second application resides, such as a TCP / UDP communication endpoint. After the aforementioned SOMEIP daemon queries the aforementioned destination communication endpoint through the service management module, it can route the data to be sent by the aforementioned first application to the aforementioned destination communication endpoint. The routing involved in this application can refer to sending the corresponding data through the routing management module. For example, here, this application can send the data to be sent by the aforementioned first application to the aforementioned destination communication endpoint, such as a TCP / UDP communication endpoint, through the routing management module. Correspondingly, after the aforementioned destination communication endpoint receives the data to be sent by the aforementioned first application, it can send the data to be sent by the aforementioned first application to the peer protocol stack through a network such as Ethernet. The peer protocol stack can refer to the SOMEIP protocol stack used by the domain where the second application resides (specifically, it can be the client or server where the second application resides). This application will not impose further limitations or details on this. Accordingly, after receiving the data to be sent from the first application, the peer protocol stack can forward the data to be sent from the first application to the second application, thereby realizing data transmission between the first and second applications. In practical applications, the data to be sent from the first application can also be carried in corresponding requests / messages for easy forwarding to the second application; for example, the destination communication endpoint can send the data to be sent from the first application in a first message to the peer protocol stack, and the peer protocol stack can send the data to be sent from the first application in a second message to the second application, etc. This application will not impose further limitations or details on this.

[0100] In some alternative embodiments, when the second application needs to return response data to the first application, the data return is performed similarly to the previous embodiment. Specifically, for example, the second application first sends its response data to the peer protocol stack (specifically, the SOMEIP protocol stack). After receiving the response data from the second application, the peer protocol stack sends the response data to the destination communication endpoint (specifically, a TCP / UDP communication endpoint) corresponding to the SOMEIP daemon process via a network such as Ethernet. This destination communication endpoint can then send the response data from the second application to the SOMEIP daemon process via a routing management module. Correspondingly, after receiving the response data from the second application, the SOMEIP daemon process can query which application's communication endpoint the response data needs to be sent to, which is in this case, the communication endpoint of the first application process containing the first application. It also obtains the client identifier of the first application process. Based on the client identifier of the first application process, it determines the corresponding second channel and then sends the response data from the second application to the first application process via the second channel. Accordingly, after receiving the response data from the second application, the first application process forwards the response data from the second application back to the first application. In practical applications, the response data from the second application can also be transmitted within a corresponding request / message, facilitating layer-by-layer forwarding to the first application; for example, the SOMIP daemon can send the response data from the second application to the first application process in a third message, or the first application process can send the response data from the second application to the first application in a fourth message, etc. This application does not impose further limitations or details on this.

[0101] To help better understand the embodiments of this application, examples are provided below. Please refer to Figure 6, which is a schematic diagram of an inter-domain SOMEIP communication process provided by an embodiment of this application. The process shown in Figure 6 may include the following implementation steps:

[0102] S601, the first application sends its data to be sent to the SOMEIP agent of the first application process. Correspondingly, the SOMEIP agent of the first application process receives the data to be sent by the first application.

[0103] S602. The SOMEIP proxy of the first application process can send a first request to the SOMEIP daemon through the first channel soomeip-0000. This first request is used to query which application's destination communication endpoint the data to be sent is being sent to. Accordingly, the SOMEIP daemon receives the first request.

[0104] S603. In response to the first request, the SOMEIP daemon obtains the target communication endpoint, such as the TCP / UDP communication endpoint shown in the figure, through the service management module.

[0105] S604. The SOMEIP daemon then sends the data to be sent by the first application to the TCP / UDP communication endpoint via the routing management module. Correspondingly, the TCP / UDP communication endpoint receives the data to be sent by the first application.

[0106] S605. The aforementioned TCP / UDP communication endpoint sends the data to be sent by the first application to the peer protocol stack via Ethernet, as shown in the diagram as the SOMEIP protocol stack. Correspondingly, the aforementioned SOMEIP protocol stack receives the data to be sent by the first application.

[0107] S606. The SOMEIP protocol stack described above forwards the data to be sent by the first application to the second application for use or processing by the second application. This application does not impose any further restrictions on this.

[0108] In this application, if the second application needs to reply to / send response data to the first application, step S607 can continue; otherwise, the process can be terminated.

[0109] S607. The second application sends its response data to the SOMEIP protocol stack. Accordingly, the SOMEIP protocol stack receives the response data from the second application.

[0110] S608. The SOMEIP protocol stack described above sends the response data of the second application to the TCP / UDP communication endpoint corresponding to the SOMEIP daemon via Ethernet. Correspondingly, the TCP / UDP communication endpoint receives the response data of the second application.

[0111] S609. The aforementioned TCP / UDP communication endpoint sends the response data of the second application to the aforementioned SOMEIP daemon process through the routing management module. Correspondingly, the aforementioned SOMEIP daemon process receives the response data of the second application.

[0112] S610. After receiving the response data from the second application, the SOMEIP daemon queries which application's communication endpoint the response data needs to be sent to, which is the communication endpoint of the first application process where the first application resides. Simultaneously, it obtains the client identifier 0001 of the first application process. Then, it determines the second channel, someip-0001, corresponding to the client identifier 001.

[0113] S611. The SOMEIP daemon sends the response data of the second application to the first application process via the second channel someip-0001. Correspondingly, the first application process receives the response data of the second application.

[0114] S612. The first application process forwards the response data of the second application to the first application for use or determination by the first application, and this application does not impose any further limitations on this.

[0115] As can be seen, this application embodiment uses the SOMEIP protocol as an inter-process communication method, which is beneficial to improving the communication performance of SOMEIP in the QNX system. Specifically, in this application, the first application process sends a first request to the SOMEIP daemon process through a first channel. The first request is used to query the destination communication endpoint corresponding to the data to be sent in the first application. The first channel is determined based on the client identifier of the SOMEIP daemon process. After the SOMEIP daemon process responds to the first request and finds the destination communication endpoint, it transmits the data to be sent from the first application to the second application based on the domain communication method between the first and second applications and the destination communication endpoint. Thus, the SOMEIP protocol can be used as an inter-process communication method in the QNX system. By leveraging the advantages of SOMEIP communication, data transmission between the first and second applications can be achieved, thereby improving the overall communication performance of the QNX system. It also solves the technical problems of communication performance bottlenecks and impacts on system performance in existing QNX systems.

[0116] Based on the foregoing embodiments, please refer to Figure 7, which is a structural schematic diagram of a SOMEIP communication device provided in an embodiment of this application. The device shown in Figure 7 can be applied to a QNX system, which includes a first application process and a SOMEIP daemon process. The device 700 includes a communication module 701, wherein:

[0117] The communication module 701 is used to send a first request to the SOMEIP daemon process through a first channel based on the first application process. The first request is used to request a query for the destination communication endpoint corresponding to the data to be sent in the first application. The first channel is determined based on the client identifier of the SOMEIP daemon process.

[0118] The communication module 701 is further configured to transmit the data to be sent by the first application to the second application based on the destination communication endpoint after the SOMEIP daemon queries the destination communication endpoint in response to the first request.

[0119] In some embodiments, the communication module 701 is specifically used for:

[0120] Based on the domain communication method between the first application and the second application and the destination communication endpoint, the data to be sent by the first application is transmitted to the second application.

[0121] In some embodiments, the domain communication method is intra-domain communication, the destination communication endpoint is the communication endpoint of the second application process corresponding to the second application, and the communication module 701 is specifically used for:

[0122] The SOMEIP daemon sends a first response to the first application process through a second channel. The first response carries the client identifier of the second application process where the destination communication endpoint is located. The second channel is determined based on the client identifier of the first application process.

[0123] After receiving the client identifier of the second application process, the first application process sends a second request to the second application process through a third channel. The third channel is determined based on the client identifier of the second application process. The second request is used to request the second application process to forward the data to be sent by the first application to the second application.

[0124] In response to the second request, the second application process forwards the data to be sent by the first application to the second application.

[0125] In some embodiments, the communication module 701 is further configured to:

[0126] The second application process sends a third request to the SOMEIP daemon through the first channel. The third request is used to request a query of the communication endpoint of the first application process corresponding to the response data in the second application.

[0127] In response to the third request, the SOMEIP daemon sends a third response to the second application process through the third channel, the third response carrying the client identifier of the first application process;

[0128] After receiving the client identifier of the first application process, the second application process sends a fourth request to the first application process through the corresponding second channel. The fourth request is used to request the first application process to forward the response data of the second application to the first application.

[0129] In response to the fourth request, the first application process forwards the response data from the second application to the first application.

[0130] In some embodiments, the domain communication method is inter-domain communication, the destination communication endpoint is an endpoint communicating with the domain where the second application resides, the first request carries the data to be sent by the first application, and the communication module 701 is specifically used for:

[0131] The SOMEIP daemon routes the data to be sent by the first application to the destination communication endpoint;

[0132] The destination communication endpoint forwards the data to be sent by the first application to the peer protocol stack, so that the peer protocol stack forwards the data to be sent by the first application to the second application again. The peer protocol stack is the SOMEIP protocol stack used by the domain where the second application is located.

[0133] In some embodiments, the communication module 701 is further configured to:

[0134] After receiving the response data of the second application sent by the peer protocol stack, the destination communication endpoint routes the response data of the second application to the SOMEIP daemon.

[0135] After the SOMEIP daemon queries the client identifier of the first application process, it forwards the response data of the second application to the first application process through the second channel, which is determined based on the client identifier of the first application process.

[0136] The first application process then forwards the response data from the second application to the first application.

[0137] In some embodiments, the communication module 701 is further configured to:

[0138] The target application process creates a temporary channel based on the process identifier of the target application process and the application identifier of the corresponding target application in the target application process. The temporary channel is used to transmit the client identifier of the target application process.

[0139] The SOMEIP daemon creates the first channel based on the client identifier of the SOMEIP daemon;

[0140] After the target application process and the SOMEIP daemon successfully connect, the target application process sends an allocation request to the SOMEIP daemon through the first channel. The allocation request is used to request the SOMEIP daemon to allocate a client identifier for the target application process.

[0141] The SOMEIP daemon sends an allocation response to the target application process through the temporary channel. The allocation response carries the client identifier of the target application process, enabling the target application process to determine the target communication channel based on the client identifier of the target application process.

[0142] Wherein, when the target application process is the first application process, the target channel is the second channel; and / or, when the target application process is the second application process, the target channel is the third channel.

[0143] In some embodiments, before the target application process and the SOMEIP daemon successfully connect, the communication module 701 is further configured to:

[0144] The target application process sends a connection request for the first channel to the SOMEIP daemon, the connection request carrying the process identifier of the target application process and the application identifier of the target application;

[0145] After receiving the connection request, the SOMEIP daemon attempts to establish a connection with the target application process through a temporary channel to determine whether the target application process and the SOMEIP daemon have successfully connected.

[0146] Please refer to Figure 8, which is a schematic diagram of the structure of an electronic device provided in an embodiment of this application. As shown in Figure 8, the electronic device has a QNX system with the framework shown in Figure 1 above. This electronic device can be a mobile phone, computer, digital broadcasting terminal, messaging device, game console, tablet device, medical device, fitness equipment, personal digital assistant, etc. The above-mentioned electronic device can be applied to various types of vehicles, etc., and this application does not impose further limitations on it.

[0147] Referring to FIG8, the electronic device 800 may include one or more of the following components: processing component 802, memory 804, power supply component 806, multimedia component 808, audio component 810, input / output interface 812, sensor component 814, and communication component 816.

[0148] Processing component 802 typically controls the overall operation of electronic device 800, such as operations associated with display, telephone calls, data communication, camera operation, and recording. Processing component 802 may include one or more processors 820 to execute instructions to complete all or part of the steps of the SOMEIP communication method described above. Furthermore, processing component 802 may include one or more modules to facilitate interaction between processing component 802 and other components. For example, processing component 802 may include a multimedia module to facilitate interaction between multimedia component 808 and processing component 802.

[0149] Memory 804 is configured to store various types of data to support the operation of electronic device 800. Examples of such data include instructions for any application or method operating on electronic device 800, contact data, phonebook data, messages, pictures, videos, etc. Memory 804 can be implemented by any type of volatile or non-volatile storage device or a combination thereof, such as static random access memory (SRAM), electrically erasable programmable read-only memory (EEPROM), erasable programmable read-only memory (EPROM), programmable read-only memory (PROM), read-only memory (ROM), magnetic storage, flash memory, magnetic disk, or optical disk.

[0150] Power supply component 806 provides power to various components of electronic device 800. Power supply component 806 may include a power management system, one or more power supplies, and other components associated with generating, managing, and distributing power to electronic device 800.

[0151] Multimedia component 808 includes a screen that provides an output interface between the electronic device 800 and the user. In some embodiments, the screen may include a liquid crystal display (LCD) and a touch panel (TP). If the screen includes a touch panel, the screen may be implemented as a touchscreen to receive input signals from the user. The touch panel includes one or more touch sensors to sense touches, swipes, and gestures on the touch panel. The touch sensors may sense not only the boundaries of the touch or swipe action but also the duration and pressure associated with the touch or swipe operation. In some embodiments, multimedia component 808 includes a front-facing camera and / or a rear-facing camera. When the electronic device 800 is in an operating mode, such as a shooting mode or a video mode, the front-facing camera and / or the rear-facing camera may receive external multimedia data. Each front-facing camera and rear-facing camera may be a fixed optical lens system or have focal length and optical zoom capabilities.

[0152] Audio component 810 is configured to output and / or input audio signals. For example, audio component 810 includes a microphone (MIC) configured to receive external audio signals when electronic device 800 is in an operating mode, such as call mode, recording mode, and voice recognition mode. The received audio signals may be further stored in memory 804 or transmitted via communication component 816. In some embodiments, audio component 810 also includes a speaker for outputting audio signals.

[0153] Input / output interface 812 provides an interface between processing component 802 and peripheral interface modules, such as keyboards, click wheels, buttons, etc. These buttons may include, but are not limited to, home buttons, volume buttons, power buttons, and lock buttons.

[0154] Sensor assembly 814 includes one or more sensors for providing state assessments of various aspects of electronic device 800. For example, sensor assembly 814 can detect the on / off state of electronic device 800, the relative positioning of components such as the display and keypad of electronic device 800, changes in position of electronic device 800 or a component of electronic device 800, the presence or absence of user contact with electronic device 800, orientation or acceleration / deceleration of electronic device 800, and temperature changes of electronic device 800. Sensor assembly 814 may include a proximity sensor configured to detect the presence of nearby objects without any physical contact. Sensor assembly 814 may also include a light sensor, such as a CMOS or CCD image sensor, for use in imaging applications. In some embodiments, sensor assembly 814 may also include an accelerometer, gyroscope, magnetometer, pressure sensor, or temperature sensor.

[0155] Communication component 816 is configured to facilitate wired or wireless communication between electronic device 800 and other devices. Electronic device 800 can access wireless networks based on communication standards, such as WiFi, 2G, or 3G, or combinations thereof. In one exemplary embodiment, communication component 816 receives broadcast signals or broadcast-related information from an external broadcast management system via a broadcast channel. In one exemplary embodiment, communication component 816 also includes a near-field communication (NFC) module to facilitate short-range communication. For example, the NFC module may be implemented based on radio frequency identification (RFID) technology, Infrared Data Association (IrDA) technology, ultra-wideband (UWB) technology, Bluetooth (BT) technology, and other technologies.

[0156] In an exemplary embodiment, the electronic device 800 may be implemented by one or more application-specific integrated circuits (ASICs), digital signal processors (DSPs), digital signal processing devices (DSPDs), programmable logic devices (PLDs), field-programmable gate arrays (FPGAs), controllers, microcontrollers, microprocessors, or other electronic components to perform the SOMEIP communication method described above.

[0157] Understandably, the processor 820 in this application embodiment can be an integrated circuit chip with signal processing capabilities. In implementation, each step of the above method embodiment can be completed by integrated logic circuits in the processor's hardware or by software instructions. The processor described above can be a general-purpose processor, a digital signal processor (DSP), an application-specific integrated circuit (ASIC), a field-programmable gate array (FPGA), or other programmable logic devices, discrete gate or transistor logic devices, or discrete hardware components.

[0158] Understandably, the memory 804 in the embodiments of this application can be volatile memory or non-volatile memory, or may include both volatile and non-volatile memory. The non-volatile memory can be read-only memory (ROM), programmable read-only memory (PROM), erasable programmable read-only memory (EPROM), electrically erasable programmable read-only memory (EEPROM), or flash memory. The volatile memory can be random access memory (RAM), which is used as an external cache. By way of example, but not limitation, many forms of RAM are available, such as static random access memory (SRAM), dynamic random access memory (DRAM), synchronous dynamic random access memory (SDRAM), double data rate synchronous dynamic random access memory (DDRSDRAM), enhanced synchronous dynamic random access memory (ESDRAM), synchronous linked dynamic random access memory (SLDRAM), and direct rambus RAM (DR RAM). It should be noted that the memory used in the systems and methods described herein is intended to include, but is not limited to, these and any other suitable types of memory.

[0159] In an exemplary embodiment, a non-transitory computer-readable storage medium including instructions is also provided, such as a memory 804 including instructions, which can be executed by a processor 820 of an electronic device 800 to complete the aforementioned upper-level SOMEIP communication method. For example, the non-transitory computer-readable storage medium may be a ROM, random access memory (RAM), CD-ROM, magnetic tape, floppy disk, and optical data storage device, etc.

[0160] The aforementioned device can be a standalone electronic device or a part of a standalone electronic device. For example, in one embodiment, the device can be an integrated circuit (IC) or a chip, wherein the integrated circuit can be a single IC or a collection of multiple ICs. The chip can include, but is not limited to, the following types: GPU (Graphics Processing Unit), CPU (Central Processing Unit), FPGA (Field Programmable Gate Array), DSP (Digital Signal Processor), ASIC (Application Specific Integrated Circuit), and SoC (System on Chip). The aforementioned integrated circuit or chip can be used to execute executable instructions (or code) to implement the SOMEIP communication method. These executable instructions can be stored in the integrated circuit or chip or obtained from other devices or equipment. For example, the integrated circuit or chip may include a processor, memory, and an interface for communicating with other devices. The executable instruction can be stored in the memory, and when the executable instruction is executed by the processor, it implements the above-mentioned SOMEIP communication method; or, the integrated circuit or chip can receive the executable instruction through the interface and transmit it to the processor for execution to implement the above-mentioned SOMEIP communication method.

[0161] Please refer to Figure 9, which is a structural schematic diagram of a vehicle provided in an embodiment of this application. As exemplarily shown in Figure 9, the vehicle 900 includes a memory 901 and a processor 902, wherein the memory 901 stores executable program code 9011, and the processor 902 is used to call and execute the executable program code 9011 to perform the SOMEIP communication method.

[0162] This application embodiment can divide the vehicle into functional modules according to the above method embodiment. For example, each function can be assigned to a separate module, or two or more functions can be integrated into a processing module. The integrated module can be implemented in hardware. It should be noted that the module division in this embodiment is illustrative and only represents one logical functional division. In actual implementation, there may be other division methods. When dividing each functional module according to its corresponding function, the vehicle may include a processing module and a communication module, etc.

[0163] It should be noted that all relevant content of each step involved in the above method embodiments can be referenced from the functional description of the corresponding functional module, and will not be repeated here. The vehicle provided in this embodiment is used to execute the above-described SOMEIP communication method, and therefore can achieve the same effect as the above implementation method.

[0164] In another exemplary embodiment, a computer program product is also provided, the computer program product comprising a computer program executable by a programmable device, the computer program having a code portion for performing the SOMEIP communication method described above when executed by the programmable device.

[0165] It should be noted that the descriptions of the above embodiments of storage media, devices, and equipment are similar to the descriptions of the above method embodiments, and have similar beneficial effects. For technical details not disclosed in the embodiments of storage media, devices, and equipment of this application, please refer to the descriptions of the method embodiments of this application for understanding.

[0166] Other embodiments of this application will readily occur to those skilled in the art upon consideration of the specification and practice of this application. This application is intended to cover any variations, uses, or adaptations of this application that follow the general principles of this application and include common knowledge or customary techniques in the art not disclosed in this application. The specification and embodiments are to be considered exemplary only, and the true scope and spirit of this application are indicated by the following claims.

[0167] The above description is merely a preferred embodiment of this application and is not intended to limit this application. Any modifications or equivalent substitutions made within the spirit and principles of this application should be included within the protection scope of this application.

Claims

1. A scalable service-oriented middleware protocol SOMEIP communication method, characterized in that, An embedded real-time operation QNX system is used, the QNX system including a first application process and a SOMEIP daemon process. The method includes: the first application process sending a first request to the SOMEIP daemon process through a first channel, the first request being used to query the destination communication endpoint corresponding to the data to be sent in the first application, the first channel being determined based on the client identifier of the SOMEIP daemon process; after the SOMEIP daemon process responds to the first request and finds the destination communication endpoint, it transmits the data to be sent from the first application to a second application based on the destination communication endpoint.

2. The method according to claim 1, characterized in that, The step of transmitting the data to be sent from the first application to the second application based on the destination communication endpoint includes: transmitting the data to be sent from the first application to the second application based on the domain communication method between the first application and the second application and the destination communication endpoint.

3. The method according to claim 2, characterized in that, The domain communication method is intra-domain communication, and the destination communication endpoint is the communication endpoint of the second application process corresponding to the second application. The step of transmitting the data to be sent from the first application to the second application based on the domain communication method between the first and second applications and the destination communication endpoint includes: the SOMEIP daemon sending a first response to the first application process through a second channel, the first response carrying the client identifier of the second application process where the destination communication endpoint is located, the second channel being determined based on the client identifier of the first application process; after receiving the client identifier of the second application process, the first application process sending a second request to the second application process through a third channel, the third channel being determined based on the client identifier of the second application process, the second request requesting the second application process to forward the data to be sent from the first application to the second application; and the second application process responding to the second request forwarding the data to be sent from the first application to the second application.

4. The method according to claim 3, characterized in that, The method further includes: the second application process sending a third request to the SOMEIP daemon through the first channel, the third request being used to request a query of the communication endpoint of the first application process corresponding to the response data in the second application; the SOMEIP daemon responding to the third request sending a third response to the second application process through the third channel, the third response carrying the client identifier of the first application process; after receiving the client identifier of the first application process, the second application process sending a fourth request to the first application process through the corresponding second channel, the fourth request being used to request the first application process to forward the response data of the second application to the first application; the first application process responding to the fourth request forwarding the response data of the second application to the first application.

5. The method according to claim 2, characterized in that, The domain communication method is inter-domain communication, and the destination communication endpoint is an endpoint that communicates with the domain where the second application is located. The first request carries the data to be sent by the first application. The step of transmitting the data to be sent by the first application to the second application based on the domain communication method between the first application and the second application and the destination communication endpoint includes: the SOMEIP daemon routing the data to be sent by the first application to the destination communication endpoint; the destination communication endpoint forwarding the data to be sent by the first application to the peer protocol stack, so that the peer protocol stack forwards the data to be sent by the first application to the second application again, and the peer protocol stack is the SOMEIP protocol stack used by the domain where the second application is located.

6. The method according to claim 5, characterized in that, The method further includes: after receiving the response data of the second application sent by the peer protocol stack, the destination communication endpoint routes the response data of the second application to the SOMEIP daemon; after the SOMEIP daemon queries the client identifier of the first application process, it forwards the response data of the second application to the first application process through a second channel, the second channel being determined based on the client identifier of the first application process; the first application process then forwards the response data of the second application to the first application.

7. The method according to claim 4, characterized in that, The method further includes: a target application process creating a temporary channel based on its process identifier and the application identifier of the corresponding target application within the target application process, the temporary channel being used to transmit the client identifier of the target application process; the SOMEIP daemon creating a first channel based on its client identifier; after the target application process and the SOMEIP daemon successfully connect, the target application process sending an allocation request to the SOMEIP daemon through the first channel, the allocation request being used to request the SOMEIP daemon to allocate its client identifier; the SOMEIP daemon sending an allocation response to the target application process through the temporary channel, the allocation response carrying the client identifier of the target application process, such that the target application process determines the corresponding target communication channel based on its client identifier; wherein, when the target application process is the first application process, the target channel is the second channel; and / or, when the target application process is the second application process, the target channel is the third channel.

8. The method according to claim 7, characterized in that, Before the target application process and the SOMEIP daemon successfully connect, the method further includes: the target application process sending a connection request for the first channel to the SOMEIP daemon, the connection request carrying the process identifier of the target application process and the application identifier of the target application; after receiving the connection request, the SOMEIP daemon attempts to establish a connection with the temporary channel of the target application process to determine whether the target application process and the SOMEIP daemon have successfully connected.

9. A vehicle, characterized in that, include: processor; A memory for storing processor-executable instructions; wherein the processor is configured to execute the executable instructions to implement the steps of the method according to any one of claims 1 to 8.

10. A computer-readable storage medium having computer program instructions stored thereon, characterized in that, When the computer program instructions are executed by the processor, they implement the steps of the method according to any one of claims 1 to 8.

Images