Method, apparatus and system for bi-directional data communication across operating systems, vehicle and computer program product

Abstract

The invention relates to a method for bi-directional data communication across operating systems, which comprises the following steps of: responding to a received message sent by a host operating system through a message queue path, identifying a message type of the message, analyzing a service name of the message when the message type is to transmit the message to a node, determining a node corresponding to the service name, and transmitting the node to the host operating system. The address of the service name is randomly distributed, constructing an RPMsg message by using the node, and sending the RPMsg message to a client operating system through a VirtIO queue; and / or in response to a received interrupt request sent by the first guest operating system, receiving a message sent by the first guest operating system through the VirtIO queue, analyzing the received message in an RPMsg format, determining a node name based on a service name in the analyzed message, determining a corresponding message queue path based on the node name, and sending the message queue path to the first guest operating system. And sending the message to the host operating system through the determined message queue path.

Description

Technical Field

[0001] The present application relates to the field of vehicle communication, and in particular to a method for two-way data communication across operating systems, a device for two-way data communication across operating systems, a system for two-way data communication across operating systems, a vehicle including the system according to the present application, and a computer program product for at least assisting in implementing the steps of the method described in the present application. Background Art

[0002] In the vehicle's intelligent cockpit system, the QNX system is usually used as the host operating system to perform high-security tasks such as vehicle control and external communication, and the Android system and Linux system are used as client operating systems to provide users with various interactive interfaces and application services. This clear division of labor architecture requires the establishment of an efficient and reliable two-way data communication mechanism between the QNX system, Android system and Linux system.

[0003] However, the current communication mechanisms used in smart cockpit systems, such as CommonAPI based on SOME / IP, NFS shared partitions, and shared memory of VMM, are difficult to meet the requirements of high bandwidth, low latency, and high reliability. In addition, the existing static data sharing mechanisms, such as shared memory, are inefficient when processing dynamic and frequently changing data, which limits the ability of smart cockpit systems to handle high-speed data streams.

[0004] In order to meet the high efficiency and high reliability requirements of the intelligent cockpit system for data processing, developing an efficient and reliable two-way data communication mechanism for cross-operating systems has become a technical challenge that needs to be solved. Summary of the invention

[0005] The purpose of the present application is to provide a method for two-way data communication across operating systems, a device for two-way data communication across operating systems, a system for two-way data communication across operating systems, a vehicle including a system according to the present application, and a computer program product, so as to at least partially solve the problems in the prior art.

[0006] According to a first aspect of the present application, a method for bidirectional data communication across operating systems is provided, the method comprising:

[0007] - in response to a message received from a host operating system through a message queue path, identifying a message type of the message, and if the message type of the message is to pass a message to a node, resolving a service name of the message and determining a node corresponding to the service name, wherein an address of the service name is randomly assigned, constructing an RPMsg message using the node, and sending the constructed RPMsg message to the client operating system through a VirtIO queue; and / or

[0008] -In response to an interrupt request received from the first client operating system, receiving a message sent by the first client operating system through a VirtIO queue, parsing the received message in an RPMsg format, determining a node name based on a service name in the parsed message, and determining a corresponding message queue path based on the node name, and sending the message to the host operating system through the determined message queue path.

[0009] The core concept of this application includes: using POSIX standard message queues to replace conventional function calls for cross-process message transmission of RPMsg, so that multiple processes can use a set of RPMsg VirtIO queues for message transmission, and automatically generate random addresses of service names, message queue path names, and PRMsg message structures through macro definitions, so that through address and naming services, the host operating system and the client operating system can complete cross-operating system two-way data communication without determining the specific address of the service name. This two-way communication mechanism can be enabled at the beginning of system startup to ensure that various business needs, including safety-critical services, are met, while optimizing data transmission efficiency and meeting the transmission requirements of different data characteristics, thereby laying the foundation for the high-performance operation of the vehicle's intelligent cockpit system.

[0010] According to one embodiment of the present application, the message queue is a message queue using the POSIX standard, wherein the message sent through the message queue path may include a message type, a node name, a data length, and message data, etc. Here, the message type may include registering a node, deregistering a node, and delivering a message to a node, etc.

[0011] According to another embodiment of the present application, the method may further include:

[0012] - In the case where the message type of the message is a registered node, the node can be registered based on the message, and the correspondence between the node name and the service name, and the correspondence between the node name and the message queue path can be defined through macros.

[0013] According to another embodiment of the present application, the method may further include:

[0014] - In the case where the message type of the message is to deregister a node, the node may be deregistered based on the message.

[0015] According to another embodiment of the present application, the host operating system may determine a message receiving end based on a target node address in a received message, and deliver the message to the determined message receiving end. In the case where the message receiving end is an application module of the host operating system, the host operating system may deliver the message to the application module of the host operating system through the determined message queue path; in the case where the message receiving end is an application module of a second client operating system, the host operating system may deliver the message to the second client operating system through the message queue path.

[0016] According to another embodiment of the present application, when the host operating system determines that the message receiving end is an application module of the second client operating system based on the target node address in the received message, the method may further include:

[0017] -In response to a message received and sent by the host operating system through a message queue path, identifying a message type of the message, and if the message type of the message is to pass a message to a node, parsing a service name of the message and determining a node corresponding to the service name, wherein an address of the service name is randomly assigned, constructing an RPMsg message using the node, and sending the constructed RPMsg message to a second guest operating system through a VirtIO queue.

[0018] According to another embodiment of the present application, based on the target node address in the received RPMsg message, the client operating system sends the received RPMsg message to the application module of the client operating system.

[0019] According to another embodiment of the present application, the service process of registering RPMsg may include a main thread and at least one child thread, wherein, after an interrupt request sent by the first client operating system is received by the main thread, the child thread is called to receive a message sent by the first client operating system from the VirtIO queue, and the received message is processed by the child thread.

[0020] According to another embodiment of the present application, when the application module of the host operating system, the first guest operating system and / or the second guest operating system is closed, all nodes related to the closed application module may be deregistered.

[0021] According to another embodiment of the present application, the host operating system is configured as a QNX system, for example; and / or the first client operating system is configured as an Andriod system and / or a Linux system, for example; and / or the second client operating system is configured as an Andriod system and / or a Linux system, for example.

[0022] According to a second aspect of the present application, a device for bidirectional data communication across operating systems is provided, wherein the device is used to execute the method according to the present application, wherein the device may include the following components:

[0023] a message queue processing unit configured to identify a message type of a message received and sent by the host operating system through a message queue path, and, if the message type of the message is to deliver a message to a node, parse a service name of the message and determine a node corresponding to the service name;

[0024] - an RPMsg message construction unit, configured to construct an RPMsg message using the node;

[0025] - an RPMsg message sending unit, configured to send the constructed RPMsg message to the guest operating system through the VirtIO queue;

[0026] - an interrupt processing unit, which is configured to receive and process an interrupt request sent by the first guest operating system;

[0027] - a message receiving unit, configured to receive, in response to the interrupt request, a message sent by the first guest operating system through a VirtIO queue;

[0028] - a message parsing unit configured to parse received messages in the format of RPMsg;

[0029] - a message queue determination unit configured to determine a node name based on a service name in the parsed message, and determine a corresponding message queue path based on the node name; and

[0030] / or

[0031] - A message sending unit, configured to send a message to a host operating system via the determined message queue path.

[0032] According to a third aspect of the present application, a system for bidirectional data communication across operating systems is provided, the system comprising the apparatus according to the present application, a host operating system, the first client operating system and / or the second client operating system.

[0033] According to a fourth aspect of the present application, a vehicle is provided, comprising a system according to the present application.

[0034] According to a fifth aspect of the present application, a computer program product, such as a computer-readable program carrier, is provided, which contains or stores computer program instructions, and when the computer program instructions are executed by a processor, they at least assist in implementing the steps of the method described in the present application. BRIEF DESCRIPTION OF THE DRAWINGS

[0035] The principles, features and advantages of the present application may be better understood by describing the present application in more detail below with reference to the accompanying drawings. The accompanying drawings show:

[0036] Figure 1 A schematic block diagram showing a system for bidirectional data communication across operating systems according to an exemplary embodiment of the present application;

[0037] Figure 2 A flowchart showing a method for bidirectional data communication across operating systems according to an exemplary embodiment of the present application;

[0038] Figure 3 A flowchart showing a method for bidirectional data communication across operating systems according to another exemplary embodiment of the present application;

[0039] Figure 4 A flowchart showing a method for bidirectional data communication across operating systems according to another exemplary embodiment of the present application;

[0040] Figure 5 A flowchart showing a method for bidirectional data communication across operating systems according to another exemplary embodiment of the present application;

[0041] Figure 6 A flowchart showing a method for bidirectional data communication across operating systems according to another exemplary embodiment of the present application;

[0042] Figure 7 A schematic block diagram showing an apparatus for bidirectional data communication across operating systems according to an exemplary embodiment of the present application; and

[0043] Figure 8 A schematic diagram of a vehicle according to an exemplary embodiment of the present application is shown. DETAILED DESCRIPTION

[0044] In order to make the technical problems, technical solutions and beneficial technical effects to be solved by the present application clearer, the present application will be further described in detail below in conjunction with the accompanying drawings and multiple exemplary embodiments. It should be understood that the specific embodiments described herein are only used to explain the present application, rather than to limit the scope of protection of the present application.

[0045] Figure 1 A schematic block diagram of a system 10 for bidirectional data communication across operating systems according to an exemplary embodiment of the present application is shown.

[0046] like Figure 1 As shown, the system 10 may include a host operating system 2 and at least one client operating system. In the vehicle system, the host operating system 2 is configured as a QNX system, for example, which is a Unix-like real-time operating system that complies with the POSIX (Portable Operating System Interface) specification and is used to perform high-security tasks such as vehicle control and external communication; the client operating system is configured as an Andriod system and / or a Linux system, for example, to provide users with various interactive interfaces and application services. Here, a first client operating system 3 and a second client operating system 4 are shown as an example. The host operating system 2 and the first client operating system 3 can communicate bidirectionally through a device 1 for bidirectional data communication across operating systems, and the host operating system 2 and the second client operating system 4 can also communicate bidirectionally through another device 1.

[0047] The following combination Figures 2 to 6 The flowchart of the method for bidirectional data communication across operating systems according to an exemplary embodiment of the present application illustrates a data communication process between these operating systems in detail.

[0048] exist Figure 2 In the illustrated embodiment, the application module 21 of the host operating system 2 sends a message to the application module 31 of the first client operating system 3 through the device 1. First, the application module 21 of the host operating system 2 sends a message to the host operating system 2, for example, through an inter-process communication (IPC) method, and then the host operating system 2 sends the received message to the device 1 through a message queue path, wherein fixed message queue paths are established between the host operating system 2 and each device 1 when the system 1 is initialized.

[0049] The method according to the present application is performed in the device 1. Figure 2 As shown, the method comprises steps S1 to S3. In step S1, in response to receiving a message sent by the host operating system 2 through a message queue path, the message type of the message may be identified.

[0050] Here, the message queue is a message queue using the POSIX standard, wherein the POSIX standard defines a series of application program interfaces and command line tools, which stipulates the functions that each operating system should provide and the corresponding function call method, so as to solve the compatibility problems between different operating systems. The message sent through the message queue path may include a message type, a node name, a data length, and a message data, wherein the message type may include registering a node, deregistering a node, and delivering a message to a node, etc.

[0051] It should be noted that when processing a message of the message type of passing a message to a node, the message can only be passed to a registered node. Therefore, the node can be registered in the initialization phase of the system 1, or the corresponding node can be registered according to actual needs during the message passing process. Figure 3 The flowchart of a method for bidirectional data communication across operating systems according to another exemplary embodiment of the present application illustrates a node registration process.

[0052] like Figure 3 As shown, the method may further include step S10. In step S10, when the message type of the message is a registered node, the node may be registered based on the message, and the correspondence between the node name and the service name may be defined through a macro so that the node name in the message may match the naming service of RPMsg (Remote Processor Messaging). RPMsg is a mechanism that provides inter-process communication functions between the kernel driver of the host operating system and the remote processor. The naming service of RPMsg may be compatible with the code solution of the Linux mainline kernel, and the device driver of RPMsg may be dynamically registered.

[0053] In addition, the correspondence between the node name and the message queue path may be defined, for example, through a macro, so that the message queue path used to transmit the message may be determined based on the node name in the message.

[0054] In step S2, when the message type of the message is to pass a message to a node, the service name of the message can be parsed, and the node corresponding to the service name can be determined, wherein the address of the service name is randomly assigned. Here, the random address of the service name can also be automatically generated by the macro definition method. In the process of two-way data communication across operating systems, the host operating system 2 and the client operating systems 3 and 4 do not need to determine the specific address of the service name to complete the data communication, but only need to find the node corresponding to the service name from the registered nodes based on the correspondence between the node name and the service name defined by the macro. In the meaning of this application, a "node" is a connection point that can be created at either end of each data transmission channel, which provides an infrastructure for data transmission between a sending end and a receiving end under multiple operating system architectures.

[0055] In step S3, the node can be used to construct an RPMsg message, and the constructed RPMsg message is sent to the client operating system through the VirtIO queue. Here, since the device driver for RPMsg is dynamically registered through the naming service, and the service name and the node have a corresponding relationship defined by a macro, the RPMsg message construction unit 12 can use the node, especially the target node address and the source node address contained in the message data to construct the RPMsg message transmitted between these device drivers. The constructed RPMsg message is implemented based on the message transmission mechanism of VirtIO. VirtIO is a standard for virtualizing I / O devices in a virtualized environment, which allows the client operating system 3, 4 to communicate with the virtual machine monitor of the host operating system 2, so that the virtual machine can access the device driver of the host operating system 2. When the system 1 is initialized, fixed VirtIO queues are established between the host operating system 1 and each client operating system 3, 4, so that the constructed RPMsg message is sent to the client operating system through the established VirtIO queue. Based on the target node address in the received RPMsg message, the client operating system 3 or 4 passes the received RPMsg message to its application module 31 or 41 through inter-process communication, thereby completing the communication process of the application module 21 of the host operating system 2 passing the message to the application module 31 of the first client operating system 3 or the application module 41 of the second client operating system 4.

[0056] It should be noted that the application modules that perform data communication with each other, such as application modules 21 , 31 , and 41 , are application modules that run in different operating systems and are used to perform the same application functions.

[0057] exist Figure 4In the flowchart of the method for bidirectional data communication across operating systems according to another exemplary embodiment of the present application, the method may further include step S11. In step S11, when the message type of the message is to deregister a node, the node may be deregistered based on the message. When the application module of the host operating system 2, the first client operating system 3 and / or the second client operating system 4 is closed, all nodes related to the closed application module may be deregistered. When the host operating system 2 is closed, a broadcast may also be sent to the service processes registered with RPMsg to terminate these service processes.

[0058] Next, combine Figure 5 The flowchart of a method for bidirectional data communication across operating systems according to another exemplary embodiment of the present application illustrates a communication process in which a guest operating system transmits a message to a host operating system.

[0059] exist Figure 5 In the illustrated embodiment, the application module 31 of the first client operating system 3 sends a message to the application module 21 of the host operating system 2 through the device 1. First, the application module 31 of the first client operating system 3 sends a message to the first client operating system 3, for example, through an inter-process communication method, and then the first client operating system 3 transmits the message to the device 1 through a message queue path, wherein a fixed VirtIO queue is established between the first client operating system 3 and the device 1 when the system 1 is initialized. It should be noted that all applications or all processes of the first client operating system 3 can use this fixed VirtIO queue for message transmission.

[0060] Next, execute in device 1 Figure 5 Steps S4 to S6 shown. In step S4, in response to the interrupt request sent by the first client operating system 3, a message sent by the first client operating system 3 can be received through the VirtIO queue. Here, the service process for registering RPMsg can include a main thread and at least one child thread, wherein, after the interrupt request sent by the first client operating system 3 is received by the main thread, the child thread can be called to receive the message sent by the first client operating system 3 from the VirtIO queue, and the received message can be processed by the child thread, thereby using multiple threads to perform non-blocking sending and receiving of RPMsg messages.

[0061] In step S5, the received message can be parsed in the format of RPMsg, the node name can be determined based on the service name in the parsed message, and the corresponding message queue path can be determined based on the node name. Since the correspondence between the node name and the service name and the correspondence between the node name and the message queue path have been defined by macros when registering the node, the node name and the message queue path can be determined based only on the service name without determining the specific address of the service name.

[0062] In step S6, a message can be sent to the host operating system 2 through the determined message queue path. The host operating system 2 can determine the message receiving end based on the target node address in the received message, and pass the message to the determined message receiving end. In the case where the message receiving end is the application module 21 of the host operating system 2, the host operating system 2 can send the message to the application module 21 of the host operating system 2 through the determined message queue path. In the case where the message receiving end is the application module 41 of the second client operating system 4, the host operating system 2 can pass the message to the second client operating system 4 via another device 1 through the message queue path. In this case, the process of the host operating system 2 passing the message to the second client operating system 4 can also be implemented in the other device 1, which will be Figure 6 The flowchart of the method for bidirectional data communication across operating systems according to another exemplary embodiment of the present application is described in detail in FIG. Figure 5 The differences between the embodiments shown in FIG. 1 and FIG. 2 are shown in FIG. 3 , and the same steps are not described repeatedly for the sake of brevity.

[0063] like Figure 6 As shown, the method may further include steps S1 to S3. In step S1, in response to receiving a message sent by the host operating system 2 through a message queue path, the message type of the message may be identified.

[0064] In step S2, when the message type of the message is to pass a message to a node, the service name of the message can be parsed and the node corresponding to the service name can be determined, wherein the address of the service name is randomly assigned. Here, the random address of the service name can also be automatically generated by a macro definition method, and the node corresponding to the service name can be found based on the correspondence between the node name and the service name defined by the macro.

[0065] In step S3, the node can be used to construct an RPMsg message, and the constructed RPMsg message can be sent to the second client operating system 4 through the VirtIO queue. Here, the constructed RPMsg message can be transmitted by using the fixed VirtIO queue between the host operating system 2 and the second client operating system 4 established when the system 1 is initialized. Based on the target node address in the received RPMsg message, the second client operating system 4 can pass the received RPMsg message to the application module 41 of the second client operating system 4 through inter-process communication, thereby completing the communication process of the application module 31 of the first client operating system 3 transmitting the message to the application module 41 of the second client operating system 4.

[0066] According to the above-mentioned embodiment of the present application, by using the POSIX standard message queue to replace the conventional function call for RPMsg cross-process message transmission, multiple processes can use a group of RPMsg VirtIO queues for message transmission, and automatically generate the random address of the service name, the message queue path name and the structure of the PRMsg message through macro definition, so that through the address and naming service, the host operating system and the client operating system can complete the two-way data communication across operating systems without determining the specific address of the service name. This two-way communication mechanism can be enabled at the beginning of system startup to ensure that various business requirements including safety-critical services are met, while optimizing data transmission efficiency and meeting the transmission requirements of different data characteristics, thereby laying the foundation for the high-performance operation of the vehicle's intelligent cockpit system.

[0067] In addition, it should be noted that the step numbers described herein do not necessarily represent a chronological order, but are merely a figure mark. The order can be changed according to specific circumstances as long as the technical purpose of the present application can be achieved.

[0068] Figure 7 A schematic block diagram of an apparatus 1 for bidirectional data communication across operating systems according to an exemplary embodiment of the present application is shown.

[0069] like Figure 7 As shown, the device 1 may include the following components:

[0070] a message queue processing unit 11, configured to identify a message type of a message received and sent by the host operating system 2 through a message queue path, and in the case where the message type of the message is a message delivery to a node, parse a service name of the message and determine a node corresponding to the service name;

[0071] - an RPMsg message building unit 12, which is configured to build an RPMsg message using the node;

[0072] - an RPMsg message sending unit 13, which is configured to send the constructed RPMsg message to the first guest operating system 3 or the second guest operating system 4 through the VirtIO queue;

[0073] - an interrupt processing unit 14, which is configured to receive and process an interrupt request sent by the first guest operating system 3;

[0074] - a message receiving unit 15, which is configured to receive a message sent by the first guest operating system 3 through the VirtIO queue in response to the interrupt request;

[0075] - a message parsing unit 16 configured to parse received messages in the format of RPMsg;

[0076] - a message queue determination unit 17, which is configured to determine a node name based on a service name in the parsed message, and determine a corresponding message queue path based on the node name;

[0077] and / or

[0078] A message sending unit 18, which is configured to send a message to the host operating system 2 via the determined message queue path.

[0079] Figure 8 1 is a schematic diagram of a vehicle 100 according to an exemplary embodiment of the present application. Figure 8 As shown, the vehicle 100 includes the system 10 .

[0080] It should be understood that, in this document, the expressions "first", "second", "third", etc. are used for descriptive purposes only and should not be understood as indicating or implying relative importance, nor should they be understood as implicitly indicating the number of the indicated technical features.

[0081] If an embodiment includes an “and / or” relationship between a first feature and a second feature, it should be interpreted as follows: according to one embodiment, the embodiment has both the first feature and the second feature, and according to another embodiment, the embodiment has either only the first feature or only the second feature.

[0082] Although specific embodiments have been described above, these embodiments are not intended to limit the scope of the present disclosure, even when only a single embodiment is described with respect to specific features. The feature examples provided in the present disclosure are intended to be illustrative, not restrictive, unless otherwise stated. In specific implementations, multiple features may be combined with each other, where technically feasible, according to actual needs. Various substitutions, changes, and modifications may also be conceived without departing from the spirit and scope of the present application.

Claims

1. A method for bidirectional data communication across operating systems, the method comprising: In response to a message received from a host operating system (2) through a message queue path, identifying a message type of the message, and if the message type of the message is to pass a message to a node, resolving a service name of the message and determining a node corresponding to the service name, wherein the address of the service name is randomly assigned, constructing an RPMsg message using the node, and sending the constructed RPMsg message to the client operating system (3, 4) through a VirtIO queue; and / or In response to an interrupt request received from a first client operating system (3), a message sent by the first client operating system (3) is received through a VirtIO queue, the received message is parsed in an RPMsg format, a node name is determined based on a service name in the parsed message, a corresponding message queue path is determined based on the node name, and a message is sent to a host operating system (2) through the determined message queue path.

2. The method according to claim 1, wherein: The message queue is a message queue that adopts the POSIX standard, wherein the message sent through the message queue path includes a message type, a node name, a data length, and message data, wherein the message type includes registering a node, deregistering a node, and delivering a message to a node.

3. A method according to any one of the preceding claims, wherein: The method further comprises: In the case that the message type of the message is a registered node, the node is registered based on the message, and the correspondence between the node name and the service name, and the correspondence between the node name and the message queue path are defined through macros.

4. A method according to any one of the preceding claims, wherein: The method further comprises: In case the message type of the message is to deregister a node, the node is deregistered based on the message.

5. A method according to any one of the preceding claims, wherein: The host operating system (2) determines a message receiving end based on a target node address in a received message, and transmits the message to the determined message receiving end, wherein: When the message receiving end is an application module (21) of the host operating system (2), the host operating system (2) transmits the message to the application module (21) of the host operating system (2) through the determined message queue path; When the message receiving end is an application module (41) of a second client operating system (4), the host operating system (2) transmits the message to the second client operating system (4) via a message queue path.

6. A method according to any one of the preceding claims, wherein: In the case where the host operating system (2) determines that the message receiving end is an application module (41) of the second client operating system (4) based on the target node address in the received message, the method further comprises: In response to a message received from a host operating system (2) through a message queue path, a message type of the message is identified, and if the message type of the message is to pass a message to a node, a service name of the message is parsed, and a node corresponding to the service name is determined, wherein the address of the service name is randomly assigned, an RPMsg message is constructed using the node, and the constructed RPMsg message is sent to a second client operating system (4) through a VirtIO queue.

7. A method according to any one of the preceding claims, wherein: Based on the target node address in the received RPMsg message, the client operating system (3, 4) sends the received RPMsg message to the application module (31, 41) of the client operating system (3, 4).

8. A method according to any one of the preceding claims, wherein: The service process of registering RPMsg includes a main thread and at least one child thread, wherein after an interrupt request sent by the first client operating system (3) is received by the main thread, the child thread is called to receive a message sent by the first client operating system (3) from the VirtIO queue, and the received message is processed by the child thread.

9. A method according to any one of the preceding claims, wherein: When the application module of the host operating system (2), the first client operating system (3) and / or the second client operating system (4) is closed, all nodes related to the closed application module are deregistered.

10. A method according to any one of the preceding claims, wherein: The host operating system (2) is configured as a QNX system; and / or The first client operating system (3) is configured as an Android system and / or a Linux system; and / or The second guest operating system (4) is configured as an Android system and / or a Linux system.

11. A device (1) for bidirectional data communication across operating systems, the device (1) being used to execute the method according to any one of the preceding claims, wherein: The device (1) comprises the following components: A message queue processing unit (11) configured to identify a message type of a message received and sent by a host operating system (2) through a message queue path, and, if the message type of the message is a message delivered to a node, parse a service name of the message and determine a node corresponding to the service name; An RPMsg message construction unit (12), configured to construct an RPMsg message using the node; An RPMsg message sending unit (13), configured to send the constructed RPMsg message to the client operating system (3, 4) via a VirtIO queue; An interrupt processing unit (14) configured to receive and process an interrupt request sent by the first client operating system (3); A message receiving unit (15), configured to receive a message sent by the first client operating system (3) through a VirtIO queue in response to the interrupt request; A message parsing unit (16) configured to parse a received message in the format of RPMsg; A message queue determination unit (17), configured to determine a node name based on a service name in the parsed message, and determine a corresponding message queue path based on the node name; and / or A message sending unit (18) is configured to send a message to a host operating system (2) via the determined message queue path.

12. A system (10) for bidirectional data communication across operating systems, the system (10) comprising the apparatus (1) according to claim 11, a host operating system (2), the first client operating system (3) and / or the second client operating system (4).

13. A vehicle (100) comprising the system (10) according to claim 12. 14 . A computer program product, such as a computer-readable program carrier, comprising or storing computer program instructions, which, when executed by a processor, at least assist in implementing the steps of the method according to claim 1 .

Images